Esegui il deployment dei carichi di lavoro

Questa pagina descrive i passaggi per eseguire il deployment dei carichi di lavoro sull'hardware Google Distributed Cloud connected e le limitazioni che devi rispettare durante la configurazione dei carichi di lavoro.

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 hardware, Google Cloude alcune impostazioni di rete specificate al momento dell'ordine di Distributed Cloud connesso.

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

Una volta connesso alla rete locale, l'hardware comunica con Google Cloud per scaricare gli aggiornamenti software e connettersi al tuo progettoGoogle Cloud . A questo punto, puoi eseguire il provisioning dei node pool e il deployment dei carichi di lavoro su Distributed Cloud connected.

Panoramica del deployment

Per eseguire il deployment di un carico di lavoro sull'hardware connesso a Distributed Cloud, completa i seguenti passaggi:

  1. (Facoltativo) Abilita l'API Distributed Cloud Edge Network.

  2. (Facoltativo) Inizializza la configurazione di rete della zona connessa a Distributed Cloud.

  3. (Facoltativo) Configura il networking di Distributed Cloud.

  4. Crea un cluster Distributed Cloud connesso.

  5. (Facoltativo) Attiva 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 attivare il supporto per le CMEK per i dati del tuo workload. Per informazioni su come Distributed Cloud connected cripta i dati dei carichi di lavoro, consulta Sicurezza dell'archiviazione locale.

  6. Crea un node pool. In questo passaggio, assegni i nodi a un pool di nodi e, se vuoi, configuri il pool di nodi in modo che utilizzi Cloud KMS per eseguire il wrapping e l'unwrapping della passphrase Linux Unified Key Setup (LUKS) per criptare i dati del workload.

  7. Ottieni le credenziali per un cluster per testarlo.

  8. Concedi agli utenti l'accesso al cluster assegnando loro il ruolo Visualizzatore Edge Container (roles/edgecontainer.viewer) o il ruolo Amministratore Edge Container (roles/edgecontainer.admin) nel progetto.

  9. Assegna agli utenti l'accesso granulare basato sui ruoli alle risorse del cluster utilizzando RoleBinding e ClusterRoleBinding.

  10. (Facoltativo) Attiva il supporto del runtime VM su Google Distributed Cloud per eseguire i carichi di lavoro su macchine virtuali su Distributed Cloud connected.

  11. (Facoltativo) Attiva il supporto GPU per eseguire carichi di lavoro basati su GPU su Distributed Cloud connected.

Esegui il deployment del bilanciatore del carico NGINX come servizio

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

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

  2. Applica il file YAML al cluster utilizzando questo comando:

    kubectl apply -f nginx-deployment.yaml

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

  4. Applica il file YAML al cluster utilizzando questo comando:

    kubectl apply -f nginx-deployment.yaml

  5. Recupera l'indirizzo IP esterno assegnato al servizio dal bilanciatore del carico MetalLB utilizzando questo 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 operatore di funzione di rete NodeSystemConfigUpdate per ogni nodo nel cluster nel seguente modo.

  1. Elenca i nodi in esecuzione nel pool di nodi del cluster di destinazione utilizzando questo 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 deriva i relativi nomi brevi. Ad esempio, per il nodo pool-example-node-1-01-b2d82cc7, il nome breve è node101.

  2. 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 suo nome completo. Ad esempio, node101.

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

  3. Applica ciascuno dei 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, il che 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 dei riavvii.

Configura un pod per la memorizzazione nella cache delle immagini

Puoi configurare un pod in esecuzione su un cluster connesso 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 tuoi 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 privato, la risorsa ImagePullSecret deve essere di tipo kubernetes.io/dockerconfigjson.
  • Devi impostare il criterio 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 di deployment con la memorizzazione nella cache attivata:

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 carichi di lavoro Distributed Cloud

Quando configuri i carichi di lavoro connessi di Distributed Cloud, devi rispettare le limitazioni descritte in questa sezione. Queste limitazioni vengono applicate da Distributed Cloud connected a tutti i carichi di lavoro che deploy sull'hardware Distributed Cloud connected.

Limitazioni dei carichi di lavoro Linux

Distributed Cloud connected supporta solo le seguenti funzionalità Linux per i carichi di lavoro:

  • 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 dello spazio dei nomi

Distributed Cloud connesso non supporta i seguenti spazi dei nomi:

  • hostPID
  • hostIPC
  • hostNetwork

Limitazioni del tipo di risorsa

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 della modalità privilegiata.

Limitazioni del 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.

hostPath limitazioni del volume

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

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

Limitazioni dei tipi di risorse PersistentVolumeClaim

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

  • csi
  • nfs
  • local

Limitazioni relative al tipo di volume

Distributed Cloud connesso consente solo i seguenti tipi di volumi:

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim
  • projected
  • secret

Limitazioni di tolleranza 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 di pod con le seguenti chiavi di tolleranza:

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

Limitazioni relative alla rappresentazione

Distributed Cloud Connected non supporta l'impersonificazione di utenti o gruppi.

Limitazioni dello 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 di bilanciamento del carico
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

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

Evita l'utilizzo di spazi dei nomi con il prefisso g- nel nome. Questi spazi dei nomi sono in genere uno spazio dei nomi riservato utilizzato da Distributed Cloud connesso.

Limitazioni dei webhook

Distributed Cloud connected limita i webhook nel seguente modo:

  • Qualsiasi webhook di mutazione che crei esclude automaticamente lo spazio dei nomi kube-system.
  • I webhook di modifica sono disattivati per i seguenti tipi di risorse:
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Limitazioni della priorità dei pod

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

Configura 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 questo valore 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 cluster.

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

Classe di runtime gvisor

La specifica della classe di runtime gvisor passa il pod al runtime sicuro Open Container Initiative (OCI) basato su gVisor. gVisor è una soluzione di sandboxing che introduce un forte isolamento tra il carico di lavoro e il relativo host.

Passaggi successivi