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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Esegui il deployment dei carichi di lavoro

Questa pagina descrive i passaggi per eseguire il deployment dei workload sull'hardware Google Distributed Cloud connesso 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 connesso e ordinare l'hardware Distributed Cloud.

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

Gli installatori di Google completano l'installazione fisica e l'amministratore di sistema connette Distributed Cloud connesso 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 connesso.

Panoramica del deployment

Per eseguire il deployment di un workload sull'hardware Distributed Cloud connesso, 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 connesso 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 di 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 connesso.
(Facoltativo): Abilita il supporto GPU per eseguire i workload basati su GPU su Distributed Cloud connesso.

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 successivo 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 connesso a tutti i workload di cui esegui il deployment sull'hardware Distributed Cloud connesso.

Limitazioni dei workload Linux

Distributed Cloud connesso 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

Restrizioni relative agli spazi dei nomi

Distributed Cloud connesso non supporta i seguenti spazi dei nomi:

hostPID
hostIPC
hostNetwork

Restrizioni relative al tipo di risorsa

Distributed Cloud connesso 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.

Restrizioni relative al contesto di sicurezza

Distributed Cloud connesso non supporta il contesto di sicurezza della modalità con privilegi.

Restrizioni relative al binding dei pod

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

Restrizioni relative al volume `hostPath`

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

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

Restrizioni relative al tipo di risorsa `PersistentVolumeClaim`

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

csi
nfs
local

Restrizioni relative al tipo di volume

Distributed Cloud connesso consente solo i seguenti tipi di volumi:

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Restrizioni relative alle tolleranze dei pod

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

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

Restrizioni relative alla rappresentazione

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

Restrizioni relative allo spazio dei nomi di gestione

Distributed Cloud connesso 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 connesso.

Restrizioni relative ai webhook

Distributed Cloud connesso limita i webhook come segue:

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

Configurare la classe di runtime per un pod

Distributed Cloud connesso ti 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:

Specificare la priorità di runtime per un pod

Distributed Cloud connesso ti consente di specificare una classe di priorità per un pod nella sua configurazione utilizzando il campo priorityClassName. Questo campo accetta il nome di una risorsa PriorityClass che specifica la priorità di destinazione. Ad esempio:

kind: PriorityClass
metadata:
  name: high-priority-class
value: 5100000
globalDefault: false
description: "High priority class for user workloads."

Specifica il nome della classe di priorità nella configurazione del pod, come mostrato nell'esempio seguente:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  priorityClassName: high-priority-class
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Se specifichi una classe di priorità, la priorità predefinita del pod (0) viene sostituita. Per i workload critici, imposta la priorità su un valore compreso tra 5000001 e 1000000000. Distributed Cloud connesso esegue automaticamente la prelazione dei workload con priorità inferiore.

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 è 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.