Per informazioni sulla versione, consulta le note di rilascio di Distributed Cloud connesso.

Esegui il deployment dei carichi di lavoro

Questa pagina descrive i passaggi per eseguire il deployment dei workload sull'hardware Google Distributed Cloud connected e le limitazioni a cui devi attenerti durante la configurazione dei workload.

Prima di completare questi passaggi, devi soddisfare i requisiti di installazione di Distributed Cloud connected e ordinare l'hardware Distributed Cloud.

Quando l'hardware Google Distributed Cloud connesso arriva alla destinazione scelta, è preconfigurato con l'hardware Google Cloude alcune impostazioni della rete che hai specificato quando hai ordinato Google Distributed Cloud connesso.

Gli installatori di Google completano l'installazione fisica e l'amministratore di sistema connette Distributed Cloud connected alla rete locale.

Dopo che l'hardware è connesso alla rete locale, comunica con Google Cloud per scaricare gli aggiornamenti software e connettersi al Google Cloud progetto. A questo punto, puoi eseguire il provisioning dei pool di nodi e il deployment dei workload su Distributed Cloud connected.

Panoramica del deployment

Per eseguire il deployment di un workload sull'hardware Distributed Cloud connected, segui questi passaggi:

(Facoltativo) Abilita l'API Distributed Cloud Edge Network.
(Facoltativo) Inizializza la configurazione di rete della zona connessa a Distributed Cloud.
(Facoltativo) Configura la rete Distributed Cloud.
Crea un cluster connesso a Distributed Cloud.
(Facoltativo) Abilita il supporto per le chiavi di crittografia gestite dal cliente (CMEK) per l'archiviazione locale se vuoi eseguire l'integrazione con Cloud Key Management Service per abilitare il supporto per CMEK per i dati dei workload. Per informazioni su come Distributed Cloud connected cripta i dati dei workload, consulta Sicurezza dell'archiviazione locale.
Crea un pool di nodi. In questo passaggio, assegna i nodi a un pool di nodi e, facoltativamente, configura il pool di nodi in modo che utilizzi Cloud KMS per eseguire il wrapping e l'unwrap della passphrase Linux Unified Key Setup (LUKS) per la crittografia dei dati dei workload.
Ottieni le credenziali per un cluster per testarlo.
Concedi agli utenti l'accesso al cluster assegnando loro il ruolo Visualizzatore container Edge (roles/edgecontainer.viewer) o il ruolo Amministratore container Edge (roles/edgecontainer.admin) nel progetto.
Assegna agli utenti l'accesso granulare basato sui ruoli alle risorse del cluster utilizzando RoleBinding e ClusterRoleBinding.
(Facoltativo) Abilita il supporto del runtime VM su Google Distributed Cloud per eseguire i workload sulle macchine virtuali su Distributed Cloud connected.
(Facoltativo): Abilita il supporto GPU per eseguire i workload basati su GPU su Distributed Cloud connected.

Eseguire il deployment del bilanciatore del carico NGINX come servizio

L'esempio seguente illustra come eseguire il deployment del server NGINX ed esporlo come servizio su un cluster connesso a Distributed Cloud:

Crea un file YAML denominato nginx-deployment.yaml con i seguenti contenuti:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

Applica il file YAML al cluster utilizzando il seguente comando:
```
kubectl apply -f nginx-deployment.yaml
```

Crea un file YAML denominato nginx-service.yaml con i seguenti contenuti:

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

Applica il file YAML al cluster utilizzando il seguente comando:
```
kubectl apply -f nginx-deployment.yaml
```

Ottieni l'indirizzo IP esterno assegnato al servizio dal bilanciatore del carico MetalLB utilizzando il seguente comando:

kubectl get services

Il comando restituisce un output simile al seguente:

NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

Configurare le risorse `NodeSystemConfigUpdate`

Configura una risorsa dell'operatore della funzione di rete NodeSystemConfigUpdate per ogni nodo del cluster come segue.

Elenca i nodi in esecuzione nel pool di nodi del cluster di destinazione utilizzando il seguente comando:
```
kubectl get nodes | grep -v master
```
Il comando restituisce un output simile al seguente:
```
NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200
```
Registra i nomi dei nodi restituiti e ricava i relativi nomi brevi. Ad esempio, per il nodo pool-example-node-1-01-b2d82cc7, il nome breve è node101.

Per ogni nodo registrato nel passaggio precedente, crea un file di risorse NodeSystemConfigUpdate dedicato con i seguenti contenuti:

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

Sostituisci quanto segue:

NODE_NAME: il nome completo del nodo di destinazione. Ad esempio, pool-example-node-1-01-b2d82cc7.
NODE_SHORT_NAME: il nome breve del nodo di destinazione derivato dal nome completo. Ad esempio, node101.

Assegna a ogni file il nome node-system-config-update-NODE_SHORT_NAME.yaml.

Applica ogni file di risorse NodeSystemConfigUpdate al cluster utilizzando il seguente comando:
```
kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml
```
Sostituisci NODE_SHORT_NAME con il nome breve del nodo di destinazione corrispondente.

Quando applichi le risorse al cluster, ogni nodo interessato viene riavviato. Questa operazione può richiedere fino a 30 minuti.
1. Monitora lo stato dei nodi interessati finché non sono stati riavviati correttamente:
```
kubectl get nodes | grep -v master
```
Lo stato di ogni nodo passa da not-ready a ready al termine del riavvio.

Configurare un pod per la memorizzazione nella cache delle immagini

Puoi configurare un pod in esecuzione su un cluster connesso a Distributed Cloud per memorizzare nella cache la sua immagine. Il pod inizia a utilizzare l'immagine memorizzata nella cache dopo che è stata estratta dal repository per la prima volta. Se il nodo che ospita il pod esaurisce lo spazio di archiviazione, le nuove immagini non vengono memorizzate nella cache e la cache delle immagini esistente viene eliminata per garantire che i workload continuino a essere eseguiti senza interruzioni.

La configurazione del pod deve soddisfare i seguenti prerequisiti:

Devi impostare l'etichetta gdce.baremetal.cluster.gke.io/cache-image: true sul pod.
Se utilizzi un repository di immagini private, la risorsa ImagePullSecret deve essere di tipo kubernetes.io/dockerconfigjson.
Devi impostare la policy di pull del pod su IfNotPresent per assicurarti che venga sempre utilizzata la copia memorizzata nella cache dell'immagine di destinazione. Se una copia memorizzata nella cache non è disponibile localmente, l'immagine viene estratta dal repository.

L'esempio seguente illustra una configurazione del pod con la memorizzazione nella cache abilitata:

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

L'esempio seguente illustra una configurazione del deployment con la memorizzazione nella cache abilitata:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Limitazioni per i workload di Distributed Cloud

Quando configuri i workload connessi a Distributed Cloud, devi rispettare le limitazioni descritte in questa sezione. Queste limitazioni vengono applicate da Distributed Cloud connected a tutti i workload di cui esegui il deployment sull'hardware Distributed Cloud connected.

Limitazioni dei workload Linux

Distributed Cloud connected supporta solo le seguenti funzionalità Linux per i workload:

AUDIT_READ
AUDIT_WRITE
CHOWN
DAC_OVERRIDE
FOWNER
FSETID
IPC_LOCK
IPC_OWNER
KILL
MKNOD
NET_ADMIN
NET_BIND_SERVICE
NET_RAW
SETFCAP
SETGID
SETPCAP
SETUID
SYS_CHROOT
SYS_NICE
SYS_PACCT
SYS_PTRACE
SYS_RESOURCE
SYS_TIME

Limitazioni degli spazi dei nomi

Distributed Cloud connected non supporta i seguenti spazi dei nomi:

hostPID
hostIPC
hostNetwork

Limitazioni dei tipi di risorse

Distributed Cloud connected non supporta il tipo di risorsa CertificateSigningRequest, che consente a un client di richiedere l'emissione di un certificato X.509, in base a una richiesta di firma.

Limitazioni del contesto di sicurezza

Distributed Cloud connected non supporta il contesto di sicurezza in modalità con privilegi.

Limitazioni del binding dei pod

Distributed Cloud connected non supporta il binding dei pod alle porte host nello spazio dei nomi HostNetwork. Inoltre, lo spazio dei nomi HostNetwork non è disponibile.

Limitazioni dei volumi `hostPath`

Distributed Cloud connected consente solo i seguenti volumi hostPath con accesso in lettura/scrittura:

/dev/hugepages
/dev/infiniband
/dev/vfio
/dev/char
/sys/devices

Limitazioni del tipo di risorsa `PersistentVolumeClaim`

Distributed Cloud connected consente solo i seguenti tipi di risorse PersistentVolumeClaim:

csi
nfs
local

Limitazioni dei tipi di volumi

Distributed Cloud connected consente solo i seguenti tipi di volumi:

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Limitazioni delle tolleranze dei pod

Distributed Cloud connected non consente i pod creati dall'utente sui nodi del piano di controllo. In particolare, Distributed Cloud connected non consente la pianificazione dei pod con le seguenti chiavi di tolleranza:

""
node-role.kubernetes.io/master
node-role.kubernetes.io/control-plane

Limitazioni della rappresentazione

Distributed Cloud connected non supporta la rappresentazione di utenti o gruppi.

Limitazioni dello spazio dei nomi di gestione

Distributed Cloud connected non consente l'accesso ai seguenti spazi dei nomi:

ai-system
ai-speech-system
ai-ocr-system
ai-translation-system
anthos-identity-service
cert-manager
dataproc-system
dataproc-PROJECT_ID
dns-system
g-istio-system
gke-connect
gke-managed-metrics-server
gke-operators
g-ospf-servicecontrol-system
g-ospf-system
g-pspf-system
gke-system
gpc-backup-system
iam-system
kube-node-lease
kube-public
kube-system, ad eccezione dell'eliminazione di ippools.whereabouts.cni.cncf.io
metallb-system , ad eccezione della modifica delle risorse configMap per impostare gli intervalli di indirizzi IP del bilanciamento del carico
nf-operator
oclcm-system
prediction
rm-system
robinio
saas-system
vm-system

PROJECT_ID indica l'ID del progetto di destinazione Google Cloud .

Evita di utilizzare spazi dei nomi con il prefisso g- nel nome. Questi spazi dei nomi sono in genere spazi dei nomi riservati utilizzati da Distributed Cloud connected.

Limitazioni dei webhook

Distributed Cloud connected limita i webhook nel seguente modo:

Qualsiasi webhook di mutazione creato esclude automaticamente lo spazio dei nomi kube-system.
I webhook di mutazione sono disabilitati per i seguenti tipi di risorse:
- nodes
- persistentvolumes
- certificatesigningrequests
- tokenreviews

Limitazioni della priorità dei pod

Distributed Cloud connected richiede di impostare la priorità dei pod dei workload su un valore inferiore a 500000000.

Configurare la classe di runtime per un pod

Distributed Cloud connected consente di specificare la classe di runtime per un pod nella sua configurazione utilizzando il campo runtimeClassName. Questa impostazione sostituisce la classe di runtime predefinita specificata a livello di cluster. Le classi di runtime disponibili sono runc e gvisor. Ad esempio:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage
  restartPolicy: OnFailure

Se ometti questa impostazione nella configurazione del pod, il pod utilizza la classe specificata a livello di cluster. La classe di runtime predefinita a livello di cluster è runc, a meno che tu non configuri una classe di runtime predefinita utilizzando il parametro --default-container-runtime, come descritto in Creare e gestire i cluster.

Se modifichi la classe di runtime a livello di pod o di cluster, devi riavviare i pod interessati affinché la modifica venga applicata.

Classe di runtime `gvisor`

Se specifichi la classe di runtime gvisor, il pod passa al runtime sicuro Open Container Initiative (OCI) basato su gVisor. gVisor è una soluzione di sandboxing che introduce un forte isolamento tra il workload e il relativo host.

Configurare l'integrazione dei Controlli di servizio VPC

Completa i passaggi descritti in questa sezione per configurare l'integrazione dell'API Distributed Cloud Edge Container con i Controlli di servizio VPC. Per ulteriori informazioni, consulta le seguenti risorse:

Regole in uscita obbligatorie

Devi configurare le regole in uscita descritte in questa sezione per integrare l'API Distributed Cloud Edge Container con i Controlli di servizio VPC. Per informazioni sulla sintassi delle regole in uscita, consulta Riferimento per le regole in uscita.

Accesso alla zona e al Google Cloud progetto della macchina

Questa regola consente all'identità chiamante di accedere alla zona e al Google Cloud progetto della macchina quando effettua chiamate utilizzando l'API Distributed Cloud Edge Container. Questa regola si applica quando la macchina e il cluster non si trovano nello stesso Google Cloud progetto e il progetto della macchina Google Cloud è al di fuori del perimetro. Questa regola è obbligatoria se hai limitato l'API Distributed Cloud Edge Container all'interno del perimetro utilizzando i Controlli di servizio VPC.

Di seguito è riportato un esempio di configurazione egressFrom per questa regola in formato JSON:

egressFrom:
  identityType: ANY_SERVICE_ACCOUNT
  sources:
    - accessLevel: "*"

Di seguito è riportato un esempio di configurazione egressTo per questa regola:

egressTo:
 resources:
 - "projects/280968151686"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Regole in entrata obbligatorie

Devi configurare le regole in entrata descritte in questa sezione per integrare l'API Distributed Cloud Edge Container con i Controlli di servizio VPC. Per informazioni sulla sintassi delle regole in entrata, consulta Riferimento per le regole in entrata.

Accesso all'API Distributed Cloud Edge Container

Questa regola consente a identità specifiche di accedere all'API Distributed Cloud Edge Container e interagire con essa. Devi configurare questa regola se hai limitato l'API Distributed Cloud Edge Container all'interno del perimetro utilizzando i Controlli di servizio VPC e l'identità che chiama l'API Distributed Cloud Edge Container si trova al di fuori del perimetro.

Di seguito è riportato un esempio di configurazione ingressFrom per questa regola:

ingressFrom:
   sources:
     - accessLevel: '*'
   identities:
     - serviceAccount:testuser@kubernetesedge-e2e-testing.iam.gserviceaccount.com

Di seguito è riportato un esempio di configurazione ingressTo per questa regola:

ingressTo:
 resources:
 - "*"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Accesso all'API Connect e all'API Security Token Service

Questa regola consente ai workload di accedere all'API Connect e all'API Security Token Service. Devi configurare questa regola se hai limitato l'accesso all'API Connect e all'API Security Token Service all'interno del perimetro utilizzando i Controlli di servizio VPC. Per informazioni sulla configurazione delle policy di accesso a livello di indirizzo IP, consulta Indirizzo IP.