Pour en savoir plus sur les versions, consultez les notes de version de Distributed Cloud Connected.

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

Déployer des charges de travail

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

Avant de suivre ces étapes, vous devez respecter les exigences d'installation de Distributed Cloud connecté 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 Cloud, et certains paramètres réseau que vous avez spécifiés lorsque vous avez commandé Distributed Cloud connecté.

Les installateurs Google effectuent l'installation physique, et votre administrateur système connecte Distributed Cloud connecté à 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 Google Cloud projet. Vous êtes alors prêt à 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 Distributed Cloud connecté, procédez comme suit :

Facultatif : activez l'API Distributed Cloud Edge Network.
Facultatif : initialisez la configuration réseau de votre zone Distributed Cloud connecté.
Facultatif : configurez la mise en réseau Distributed Cloud.
Créez un cluster Distributed Cloud connecté.
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 savoir comment Distributed Cloud connecté chiffre les données de charge de travail, consultez la section Sécurité du stockage local.
Créez un pool de nœuds. Lors de cette étape, vous attribuez des nœuds à un pool de nœuds et, si vous le souhaitez, vous configurez le pool de nœuds pour qu'il utilise Cloud KMS afin d'encapsuler et de désencapsuler la phrase secrète Linux Unified Key Setup (LUKS) pour chiffrer les données de charge de travail.
Obtenez les identifiants d'un cluster pour le tester.
Accordez aux utilisateurs l'accès au cluster en leur attribuant le rôle Lecteur de conteneur Edge (roles/edgecontainer.viewer) ou le rôle Administrateur de conteneur Edge (roles/edgecontainer.admin) dans le projet.
Attribuez aux utilisateurs un accès précis basé sur les rôles aux ressources du cluster à l'aide de RoleBinding et ClusterRoleBinding.
Facultatif : configurez l'environnement d'exécution de VM sur GDC pour exécuter des charges de travail sur des machines virtuelles sur Distributed Cloud connecté.
Facultatif : activez la prise en charge des GPU pour exécuter des charges de travail basées sur des 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 Distributed Cloud connecté :

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

Appliquez le fichier YAML au cluster à l'aide de la commande suivante :
```
kubectl apply -f nginx-deployment.yaml
```

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

Appliquez le fichier YAML au cluster à l'aide de la commande suivante :
```
kubectl apply -f nginx-deployment.yaml
```

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.

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

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 court du nœud cible dérivé de son nom complet. Exemple : node101.

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

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 court du nœud cible correspondant.

Lorsque vous appliquez les ressources au cluster, chaque nœud affecté redémarre, ce qui peut prendre jusqu'à 30 minutes.
1. Surveillez l'état des nœuds affectés jusqu'à ce qu'ils aient tous redémarré :
```
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 des images

Vous pouvez configurer un pod exécuté sur un cluster Distributed Cloud connecté pour mettre en cache son image. Le pod commence à utiliser l'image mise en cache après avoir été extrait 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 supprimé 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 Distributed Cloud connecté, vous devez respecter les limites décrites dans cette section. Ces limites sont appliquées par Distributed Cloud connecté à toutes les charges de travail que vous déployez sur votre matériel Distributed Cloud connecté.

Limites des charges de travail Linux

Distributed Cloud connecté 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 d'espace de noms

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

hostPID
hostIPC
hostNetwork

Restrictions de type de ressource

Distributed Cloud connecté 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 de contexte de sécurité

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

Restrictions de liaison de pod

Distributed Cloud connecté n'est pas compatible avec la liaison de pods aux ports hôtes dans l'espace de noms HostNetwork. De plus, l'espace de noms HostNetwork n'est pas disponible.

Restrictions de volume `hostPath`

Distributed Cloud connecté 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é n'autorise que les types de ressources PersistentVolumeClaim suivants :

csi
nfs
local

Restrictions de type de volume

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

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Restrictions de tolérance de pod

Distributed Cloud 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 connecté n'autorise pas la planification des pods qui comportent les clés de tolérance suivantes :

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

Restrictions d'emprunt d'identité

Distributed Cloud connecté n'est pas compatible avec l'emprunt d'identité d'utilisateur ou de groupe.

Restrictions d'espace de noms de gestion

Distributed Cloud connecté 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 des 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 cible Google Cloud .

Évitez d'utiliser un espace de noms dont le nom comporte 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 de webhook

Distributed Cloud connecté limite les webhooks 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

Configurer la classe d'exécution pour un pod

Distributed Cloud connecté 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 configuration dans 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 affectés pour que la modification prenne effet.

Classe d'exécution `gvisor`

La spécification de la classe d'exécution gvisor fait passer le pod à l'environnement d'exécution sécurisé Open Container Initiative (OCI) basé sur gVisor. gVisor est une solution de bac à sable qui introduit une forte isolation entre la charge de travail et son hôte.

Configurer l'intégration de VPC Service Controls

Suivez les étapes de cette section pour configurer l'intégration de l'API Distributed Cloud Edge Container à VPC Service Controls. Pour en savoir plus, consultez les ressources suivantes :

Spécifier la priorité d'exécution d'un pod

Distributed Cloud connecté vous permet de spécifier une classe de priorité pour un pod dans sa configuration à l'aide du champ priorityClassName. Ce champ accepte le nom d'une ressource PriorityClass qui spécifie la priorité cible. Exemple :

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

Spécifiez le nom de la classe de priorité dans la configuration de votre pod, comme indiqué dans l'exemple suivant :

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

La spécification d'une classe de priorité remplace la priorité de pod par défaut, qui est de 0. Pour les charges de travail critiques, définissez leur priorité sur une valeur comprise entre 5000001 et 1000000000. Distributed Cloud connecté préempte automatiquement les charges de travail de priorité inférieure.

Règles de sortie requises

Vous devez configurer les règles de sortie décrites dans cette section pour intégrer l'API Distributed Cloud Edge Container à VPC Service Controls. Pour en savoir plus sur la syntaxe des règles de sortie, consultez la documentation de référence sur les règles de sortie. Egress rules reference.

Accès à la zone de la machine et au Google Cloud projet

Cette règle permet à l'identité appelante d'accéder à la zone de la machine et au Google Cloud projet lors d'appels à l'aide de l'API Distributed Cloud Edge Container. Cette règle s'applique lorsque la machine et le cluster ne résident pas dans le même Google Cloud projet et que leprojet de la machine se trouve en dehors du périmètre. Google Cloud Cette règle est requise si vous avez limité l'API Distributed Cloud Edge Container dans le périmètre à l'aide de VPC Service Controls.

Voici un exemple de configuration egressFrom pour cette règle au format JSON :

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

Voici un exemple de configuration egressTo pour cette règle :

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

Règles d'entrée requises

Vous devez configurer les règles d'entrée décrites dans cette section pour intégrer l'API Distributed Cloud Edge Container à VPC Service Controls. Pour en savoir plus sur la syntaxe des règles d'entrée, consultez la documentation de référence sur les règles d'entrée. Ingress rules reference.

Accès à l'API Distributed Cloud Edge Container

Cette règle permet à des identités spécifiques d'accéder à l'API Distributed Cloud Edge Container et d'interagir avec elle. Vous devez configurer cette règle si vous avez limité l'API Distributed Cloud Edge Container dans le périmètre à l'aide de VPC Service Controls et que l'identité appelant l'API Distributed Cloud Edge Container se trouve en dehors du périmètre.

Voici un exemple de configuration ingressFrom pour cette règle :

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

Voici un exemple de configuration ingressTo pour cette règle :

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

Accès à l'API Connect et à l'API Security Token Service

Cette règle permet aux charges de travail d'accéder à l'API Connect et à l'API Security Token Service. Vous devez configurer cette règle si vous avez limité l'accès à l'API Connect et à l'API Security Token Service dans le périmètre à l'aide de VPC Service Controls. Pour en savoir plus sur la configuration des règles d'accès au niveau de l'adresse IP, consultez la section Adresse IP.