Esegui il deployment dei carichi di lavoro

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

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

Quando il rack Google Distributed Cloud arriva a destinazione, è preconfigurato con hardware, Google Cloude alcune impostazioni di rete che hai specificato al momento dell'ordine di Distributed Cloud.

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

Panoramica del deployment

Per eseguire il deployment di un workload sull'hardware Distributed Cloud, completa i seguenti passaggi:

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

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

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

  4. Crea un cluster Distributed Cloud.

  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 cripta i dati dei workload, 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.

  11. (Facoltativo) Attiva il supporto GPU per eseguire workload basati su GPU su Distributed Cloud.

  12. (Facoltativo) Connetti il cluster Distributed Cloud a Google Cloud:

    1. Crea una connessione VPN al tuo progetto Google Cloud .

    2. Verifica che la connessione VPN sia operativa.

  13. (Facoltativo) Configura l'accesso privato Google per consentire ai pod di accedere alle API e ai serviziGoogle Cloud utilizzando Cloud VPN.

  14. (Facoltativo) Configura Private Service Connect per consentire ai tuoi pod di accedere Google Cloud a API e servizi utilizzando Cloud VPN.

Esegui 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 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

Esegui il deployment di un container con funzioni SR-IOV

Il seguente esempio mostra come eseguire il deployment di un pod che utilizza le funzionalità dell'operatore di funzioni di rete SR-IOV di Distributed Cloud.

Crea i componenti di rete Distributed Cloud

Crea i componenti di rete Distributed Cloud richiesti nel seguente modo. Per saperne di più su questi componenti, consulta Funzionalità di networking di Distributed Cloud.

  1. Crea una rete:

    gcloud edge-cloud networking networks create NETWORK_NAME \
    --location=REGION \
    --zone=ZONE_NAME \
    --mtu=MTU_SIZE

    Sostituisci quanto segue:

    • NETWORK_NAME: un nome descrittivo che identifica in modo univoco questa rete.
    • REGION: la regione Google Cloud a cui appartiene la zona Distributed Cloud di destinazione.
    • ZONE_NAME: il nome della zona Distributed Cloud di destinazione.
    • MTU_SIZE: la dimensione dell'unità massima di trasmissione (MTU) per questa rete. I valori validi sono 1500 e 9000. Questo valore deve corrispondere alle dimensioni MTU della rete default ed essere uguale per tutte le reti.

  2. Creare una subnet:

    gcloud edge-cloud networking subnets create SUBNETWORK_NAME \
    --network=NETWORK_NAME \
    --ipv4-range=IPV4_RANGE \
    --vlan-id=VLAN_ID \
    --location=REGION \
    --zone=ZONE_NAME

    Sostituisci quanto segue:

    • SUBNETWORK_NAME: un nome descrittivo che identifica in modo univoco questa subnet.
    • NETWORK_NAME: la rete che incapsula questa subnet.
    • IPV4_RANGE: l'intervallo di indirizzi IPv4 coperto da questa subnet nel formato indirizzo IP/prefisso.
    • VLAN_ID: l'ID VLAN di destinazione per questa subnet.
    • REGION: la regione Google Cloud a cui appartiene la zona Distributed Cloud di destinazione.
    • ZONE_NAME: il nome della zona Distributed Cloud di destinazione.

  3. Monitora lo stato della subnet finché non viene creata correttamente:

    watch -n 30 'gcloud edge-cloud networking subnets list \
    --location=REGION \
    --zone=ZONE_NAME

    Sostituisci quanto segue:

    • REGION: la regione Google Cloud a cui appartiene la zona Distributed Cloud di destinazione.
    • ZONE_NAME: il nome della zona Distributed Cloud di destinazione.

    Lo stato passa da PENDING a PROVISIONING e infine a RUNNING.

    Registra l'ID VLAN, il blocco CIDR della subnet e l'indirizzo IP gateway per il blocco CIDR. Utilizzerai questi valori più avanti in questa procedura.

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 gli switch ToR per le funzioni di rete SR-IOV

Segui i passaggi descritti in questa sezione per configurare le interfacce di rete in ogni switch ToR Distributed Cloud nel rack Distributed Cloud per il funzionamento delle funzioni di rete SR-IOV.

  1. Crea un file denominato mlnc6-pcie1-tor1-sriov.yaml con i seguenti contenuti. Questo file configura la prima interfaccia di rete sul primo switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor1_sriov

  2. Crea un file denominato mlnc6-pcie1-tor2-sriov.yaml con i seguenti contenuti. Questo file configura la seconda interfaccia di rete sul primo switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor2_sriov

  3. Crea un file denominato mlnc6-pcie2-tor1-sriov.yaml con i seguenti contenuti. Questo file configura la prima interfaccia di rete sul secondo switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor1_sriov

  4. Crea un file denominato mlnc6-pcie2-tor2-sriov.yaml con i seguenti contenuti. Questo file configura la seconda interfaccia di rete sul secondo switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor2_sriov

  5. Applica i file di configurazione ToR al cluster utilizzando i seguenti comandi:

    kubectl apply -f mlnc6-pcie1-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie1-tor2-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor2-sriov.yaml

    I nodi interessati vengono isolati, svuotati e riavviati.

  6. Monitora lo stato dei nodi utilizzando il seguente comando:

    watch -n 5 'kubectl get sriovnetworknodestates -o yaml -A | \ 
grep "syncStatus\|pool-"|sed "N;s/\n/ /"'

    Quando tutti i nodi interessati mostrano syncStatus: Succeeded, premi Ctrl+C per uscire dal ciclo del comando di monitoraggio.

    Il comando restituisce un output simile al seguente, che indica che le funzionalità della funzione di rete SR-IOV sono state abilitate sugli switch ToR:

    Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource                       Requests     Limits
--------                       --------     ------
cpu                            2520m (3%)   7310m (9%)
memory                         3044Mi (1%)  9774Mi (3%)
ephemeral-storage              0 (0%)       0 (0%)
hugepages-1Gi                  0 (0%)       0 (0%)
hugepages-2Mi                  0 (0%)       0 (0%)
devices.kubevirt.io/kvm        0            0
devices.kubevirt.io/tun        0            0
devices.kubevirt.io/vhost-net  0            0
gke.io/mlnx6_pcie1_tor1_sriov  3            3
gke.io/mlnx6_pcie1_tor2_sriov  0            0
gke.io/mlnx6_pcie2_tor1_sriov  0            0
gke.io/mlnx6_pcie2_tor2_sriov  0            0

Configurare una risorsa NetworkAttachmentDefinition

Configura una risorsa NetworkAttachmentDefinition per il cluster nel seguente modo:

  1. Crea un file denominato network-attachment-definition.yaml con il seguente contenuto:

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net1
annotations:
  k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_pcie1_tor1_sriov
spec:
config: '{
"type": "sriov",
"cniVersion": "0.3.1",
"vlan": VLAN_ID,
"name": "sriov-network",
"ipam": {
  "type": "host-local",
  "subnet": "SUBNETWORK_CIDR",
  "routes": [{
     "dst": "0.0.0.0/0"
  }],
  "gateway": "GATEWAY_ADDRESS"
}
}'

Sostituisci quanto segue:

  • VLAN_ID: l'ID VLAN della subnet che hai creato in precedenza in questa guida.
  • SUBNETWORK_CIDR: il blocco CIDR per la subnet.
  • GATEWAY_ADDRESS: l'indirizzo IP del gateway per la subnet.

  1. Applica la risorsa al cluster utilizzando questo comando:

    kubectl apply -f network-attachment-definition.yaml

Esegui il deployment di un pod con funzioni di rete SR-IOV

Completa i passaggi descritti in questa sezione per eseguire il deployment di un pod con funzioni di rete SR-IOV sul cluster. Il campo annotations nel file di configurazione del pod specifica il nome della risorsa NetworkAttachmentDefinition che hai creato in precedenza in questa guida e lo spazio dei nomi in cui è stato eseguito il deployment (default in questo esempio).

  1. Crea un file di specifiche del pod denominato sriovpod.yaml con i seguenti contenuti:

         apiVersion: v1
     kind: Pod
     metadata:
     name: sriovpod
     annotations:
        k8s.v1.cni.cncf.io/networks: default/sriov-net1
     spec:
     containers:
     - name: sleeppodsriov
        command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
        image: busybox
        securityContext:
           capabilities:
           add:
              - NET_ADMIN

  2. Applica il file di specifica del pod al cluster utilizzando il seguente comando:

    kubectl apply -f sriovpod.yaml

  3. Verifica che il pod sia stato avviato correttamente utilizzando il seguente comando:

    kubectl get pods

  4. Stabilisci una shell della riga di comando per il pod utilizzando questo comando:

    kubectl exec -it sriovpod -- sh

  5. Verifica che il pod comunichi con gli switch ToR utilizzando la funzionalità dell'operatore della funzione di rete SR-IOV utilizzando il seguente comando nella shell del pod:

    ip addr

    Il comando restituisce un output simile al seguente:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host 
      valid_lft forever preferred_lft forever
51: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq qlen 1000
   link/ether 2a:af:96:a5:42:ab brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.11/25 brd 192.168.100.127 scope global net1
      valid_lft forever preferred_lft forever
228: eth0@if229: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
   link/ether 46:c9:1d:4c:bf:32 brd ff:ff:ff:ff:ff:ff
   inet 10.10.3.159/32 scope global eth0
      valid_lft forever preferred_lft forever
   inet6 fe80::44c9:1dff:fe4c:bf32/64 scope link 
      valid_lft forever preferred_lft forever

    Le informazioni restituite per l'interfaccia net1 indicano che è stata stabilita la connettività di rete tra gli switch ToR e il pod.

Limitazioni per i carichi di lavoro Distributed Cloud

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

Limitazioni dei carichi di lavoro Linux

Distributed Cloud 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_RESOURCE
  • SYS_TIME

Limitazioni dello spazio dei nomi

Distributed Cloud non supporta i seguenti spazi dei nomi:

  • hostPID
  • hostIPC
  • hostNetwork

Limitazioni del tipo di risorsa

Distributed Cloud 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 non supporta il contesto di sicurezza della modalità con privilegi.

Limitazioni del binding dei pod

Distributed Cloud 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 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 consente solo i seguenti tipi di risorse PersistentVolumeClaim:

  • csi
  • nfs
  • local

Limitazioni relative al tipo di volume

Distributed Cloud consente solo i seguenti tipi di volumi:

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

Limitazioni di tolleranza dei pod

Distributed Cloud non consente i pod creati dagli utenti sui nodi del piano di controllo. In particolare, Distributed Cloud 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 non supporta l'impersonificazione di utenti o gruppi.

Limitazioni dello spazio dei nomi di gestione

Distributed Cloud non consente agli utenti di accedere ai seguenti spazi dei nomi:

  • kube-system, ad eccezione dell'eliminazione di ippools.whereabouts.cni.cncf.io
  • anthos-identity-service
  • cert-manager
  • gke-connect
  • kubevirt
  • metallb-system, ad eccezione della modifica delle risorse configMap per impostare gli intervalli di indirizzi IP di bilanciamento del carico
  • nf-operator
  • sriov-network-operator

Limitazioni dei webhook

Distributed Cloud limita i webhook come segue:

  • 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

Passaggi successivi