Déployer des charges de travail

Cette page décrit les étapes à suivre pour déployer des charges de travail sur votre matériel connecté Google Distributed Cloud, ainsi que les limites à respecter lors de la configuration de vos charges de travail.

Avant de suivre ces étapes, vous devez satisfaire les exigences d'installation connectée de Distributed Cloud et commander le matériel Distributed Cloud.

Lorsque le matériel Google Distributed Cloud connecté arrive à la destination de votre choix, il est préconfiguré avec du matériel, Google Cloudet certains paramètres réseau que vous avez spécifiés lors de la commande de Distributed Cloud connecté.

Les installateurs Google effectuent l'installation physique, et votre administrateur système connecte Distributed Cloud à votre réseau local.

Une fois le matériel connecté à votre réseau local, il communique avec Google Cloud pour télécharger les mises à jour logicielles et se connecter à votre projetGoogle Cloud . Vous pourrez ensuite provisionner des pools de nœuds et déployer des charges de travail sur Distributed Cloud connecté.

Présentation du déploiement

Pour déployer une charge de travail sur votre matériel connecté Distributed Cloud, procédez comme suit :

  1. Facultatif : activez l'API Distributed Cloud Edge Network.

  2. Facultatif : Initialisez la configuration réseau de votre zone Distributed Cloud connecté.

  3. Facultatif : Configurez la mise en réseau Distributed Cloud.

  4. Créez un cluster connecté Distributed Cloud.

  5. Facultatif : Activez la prise en charge des clés de chiffrement gérées par le client (CMEK) pour le stockage local si vous souhaitez intégrer Cloud Key Management Service pour activer la prise en charge des CMEK pour les données de votre charge de travail. Pour en savoir plus sur la façon dont Distributed Cloud Connected chiffre les données de charge de travail, consultez Sécurité du stockage local.

  6. Créez un pool de nœuds. Dans cette étape, vous attribuez des nœuds à un pool de nœuds et vous pouvez éventuellement configurer le pool de nœuds pour qu'il utilise Cloud KMS afin d'encapsuler et de désencapsuler la phrase secrète LUKS (Linux Unified Key Setup) pour chiffrer les données de charge de travail.

  7. Obtenez les identifiants d'un cluster pour le tester.

  8. Accordez aux utilisateurs l'accès au cluster en leur attribuant le rôle Lecteur Edge Container (roles/edgecontainer.viewer) ou Administrateur Edge Container (roles/edgecontainer.admin) sur le projet.

  9. Attribuez aux utilisateurs un accès précis basé sur les rôles aux ressources du cluster à l'aide de RoleBinding et ClusterRoleBinding.

  10. Facultatif : activez la prise en charge de l'environnement d'exécution des VM sur Google Distributed Cloud pour exécuter des charges de travail sur des machines virtuelles sur Distributed Cloud connecté.

  11. Facultatif : Activez la prise en charge des GPU pour exécuter des charges de travail basées sur les GPU sur Distributed Cloud connecté.

Déployer l'équilibreur de charge NGINX en tant que service

L'exemple suivant montre comment déployer le serveur NGINX et l'exposer en tant que service sur un cluster connecté Distributed Cloud :

  1. Créez un fichier YAML nommé nginx-deployment.yaml avec le contenu suivant :

    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. Appliquez le fichier YAML au cluster à l'aide de la commande suivante :

    kubectl apply -f nginx-deployment.yaml

  3. Créez un fichier YAML nommé nginx-service.yaml avec le contenu suivant :

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

  4. Appliquez le fichier YAML au cluster à l'aide de la commande suivante :

    kubectl apply -f nginx-deployment.yaml

  5. Obtenez l'adresse IP externe attribuée au service par l'équilibreur de charge MetalLB à l'aide de la commande suivante :

    kubectl get services

    La commande renvoie un résultat semblable à celui-ci :

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

Configurer les ressources NodeSystemConfigUpdate

Configurez une ressource d'opérateur de fonction réseau NodeSystemConfigUpdate pour chaque nœud du cluster comme suit.

  1. Répertoriez les nœuds exécutés dans le pool de nœuds du cluster cible à l'aide de la commande suivante :

    kubectl get nodes | grep -v master

    La commande renvoie un résultat semblable à celui-ci :

    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

    Enregistrez les noms des nœuds renvoyés et dérivez leurs noms courts. Par exemple, pour le nœud pool-example-node-1-01-b2d82cc7, son nom court est node101.

  2. Pour chaque nœud que vous avez enregistré à l'étape précédente, créez un fichier de ressources NodeSystemConfigUpdate dédié avec le contenu suivant :

    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"

    Remplacez les éléments suivants :

    • NODE_NAME : nom complet du nœud cible. Exemple : pool-example-node-1-01-b2d82cc7.
    • NODE_SHORT_NAME : nom abrégé du nœud cible dérivé de son nom complet. Exemple :node101

    Nommez chaque fichier node-system-config-update-NODE_SHORT_NAME.yaml.

  3. Appliquez chacun des fichiers de ressources NodeSystemConfigUpdate au cluster à l'aide de la commande suivante :

    kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml

    Remplacez NODE_SHORT_NAME par le nom abrégé du nœud cible correspondant.

    Lorsque vous appliquez les ressources au cluster, chaque nœud concerné redémarre, ce qui peut prendre jusqu'à 30 minutes.

    1. Surveillez l'état des nœuds concernés jusqu'à ce qu'ils aient tous redémarré correctement :
    kubectl get nodes | grep -v master

    L'état de chaque nœud passe de not-ready à ready une fois le redémarrage terminé.

Configurer un pod pour la mise en cache d'images

Vous pouvez configurer un pod s'exécutant sur un cluster Distributed Cloud connecté pour mettre en cache son image. Le pod commence à utiliser l'image mise en cache après l'avoir extraite du dépôt pour la première fois. Si le nœud hébergeant le pod manque d'espace de stockage, les nouvelles images ne sont pas mises en cache et le cache d'images existant est vidé pour garantir que vos charges de travail continuent de s'exécuter sans interruption.

La configuration de votre pod doit répondre aux conditions préalables suivantes :

  • Vous devez définir le libellé gdce.baremetal.cluster.gke.io/cache-image: true sur le pod.
  • Si vous utilisez un dépôt d'images privé, votre ressource ImagePullSecret doit être de type kubernetes.io/dockerconfigjson.
  • Vous devez définir la règle d'extraction du pod sur IfNotPresent pour vous assurer que la copie mise en cache de l'image cible est toujours utilisée. Si aucune copie mise en cache n'est disponible localement, l'image est extraite du dépôt.

L'exemple suivant illustre une configuration de pod avec la mise en cache activée :

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'exemple suivant illustre une configuration de déploiement avec la mise en cache activée :

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

Limites pour les charges de travail Distributed Cloud

Lorsque vous configurez vos charges de travail connectées Distributed Cloud, vous devez respecter les limites décrites dans cette section. Ces limites sont appliquées par Distributed Cloud Connected à toutes les charges de travail que vous déployez sur votre matériel Distributed Cloud Connected.

Limites des charges de travail Linux

Distributed Cloud Connected n'est compatible qu'avec les fonctionnalités Linux suivantes pour les charges de travail :

  • 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

Restrictions concernant les espaces de noms

Distributed Cloud Connected n'est pas compatible avec les espaces de noms suivants :

  • hostPID
  • hostIPC
  • hostNetwork

Restrictions concernant les types de ressources

Distributed Cloud Connected n'est pas compatible avec le type de ressource CertificateSigningRequest, qui permet à un client de demander l'émission d'un certificat X.509 en fonction d'une demande de signature.

Restrictions du contexte de sécurité

Distributed Cloud Connected n'est pas compatible avec le contexte de sécurité en mode privilégié.

Restrictions liées à l'association de pods

Distributed Cloud Connected n'est pas compatible avec l'association de pods à des ports hôtes dans l'espace de noms HostNetwork. De plus, l'espace de noms HostNetwork n'est pas disponible.

hostPath restrictions de volume

Distributed Cloud Connected n'autorise que les volumes hostPath suivants avec un accès en lecture/écriture :

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

Restrictions de type de ressource PersistentVolumeClaim

Distributed Cloud connecté uniquement autorise les types de ressources PersistentVolumeClaim suivants :

  • csi
  • nfs
  • local

Restrictions concernant les types de volumes

Distributed Cloud connecté n'autorise que les types de volumes suivants :

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

Restrictions de tolérance des pods

Le Cloud distribué de Google connecté n'autorise pas les pods créés par l'utilisateur sur les nœuds du plan de contrôle. Plus précisément, Distributed Cloud Connected ne permet pas de planifier les pods qui comportent les clés de tolérance suivantes :

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

Restrictions concernant l'usurpation d'identité

Distributed Cloud Connected n'est pas compatible avec l'usurpation d'identité d'utilisateurs ou de groupes.

Restrictions concernant l'espace de noms de gestion

Distributed Cloud Connected n'autorise pas l'accès aux espaces de noms suivants :

  • 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, à l'exception de la suppression de ippools.whereabouts.cni.cncf.io
  • metallb-system, à l'exception de la modification des ressources configMap pour définir les plages d'adresses IP d'équilibrage de charge
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

PROJECT_ID désigne l'ID du projet Google Cloud cible.

Évitez d'utiliser un espace de noms dont le nom commence par le préfixe g-. Ces espaces de noms sont généralement des espaces de noms réservés utilisés par Distributed Cloud connecté.

Restrictions concernant les webhooks

Distributed Cloud connected limite les webhook comme suit :

  • Tout webhook de mutation que vous créez exclut automatiquement l'espace de noms kube-system.
  • Les webhooks de mutation sont désactivés pour les types de ressources suivants :
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Restrictions de priorité des pods

Pour que Distributed Cloud soit connecté, vous devez définir la priorité de vos pods de charge de travail sur une valeur inférieure à 500000000.

Configurer la classe d'exécution pour un pod

Distributed Cloud Connected vous permet de spécifier la classe d'exécution d'un pod dans sa configuration à l'aide du champ runtimeClassName. Cela remplace la classe d'exécution par défaut spécifiée au niveau du cluster. Les classes d'exécution disponibles sont runc et gvisor. Exemple :

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

Si vous omettez cette option dans la configuration de votre pod, celui-ci utilise la classe spécifiée au niveau du cluster. La classe d'exécution par défaut au niveau du cluster est runc, sauf si vous configurez une classe d'exécution par défaut à l'aide du paramètre --default-container-runtime, comme décrit dans Créer et gérer des clusters.

Si vous modifiez la classe d'exécution au niveau du pod ou du cluster, vous devez redémarrer les pods concernés pour que la modification prenne effet.

Classe d'exécution gvisor

Si vous spécifiez la classe d'exécution gvisor, le pod passe à l'exécution sécurisée Open Container Initiative (OCI) basée sur gVisor. gVisor est une solution de bac à sable qui introduit une forte isolation entre la charge de travail et son hôte.

Étapes suivantes