Configurer des cgroups accessibles en écriture pour les conteneurs

Autopilot Standard

Vous pouvez autoriser les charges de travail Google Kubernetes Engine (GKE) à gérer les ressources, telles que le processeur et la mémoire, pour les processus enfants à l'aide de l'API cgroups Linux. Ce document vous explique comment fournir aux conteneurs un accès en lecture et en écriture à l'API cgroups sans exécuter ces conteneurs en mode privilégié.

Quand utiliser des cgroups accessibles en écriture ?

Par défaut, Kubernetes fournit à tous les conteneurs Linux un accès en lecture seule à l'API cgroups en installant le système de fichiers /sys/fs/cgroup dans chaque conteneur. Vous pouvez éventuellement autoriser GKE à monter ce système de fichiers en mode lecture-écriture dans des pods spécifiques pour permettre aux processus racine de gérer et de limiter les ressources pour les processus enfants.

Ces cgroups accessibles en écriture permettent d'améliorer la fiabilité des applications telles que Ray, qui exécutent des processus système et du code utilisateur dans le même conteneur. En écrivant dans le système de fichiers /sys/fs/cgroup, Ray peut réserver des portions des ressources d'un conteneur pour les processus critiques. Vous pouvez utiliser des cgroups accessibles en écriture pour améliorer la fiabilité de ces applications sans le risque de sécurité lié à l'utilisation du mode privilégié pour les conteneurs.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Assurez-vous de disposer d'un cluster Autopilot ou Standard exécutant la version 1.34.1-gke.2541000 ou ultérieure. Pour créer un cluster, consultez la page Créer un cluster Autopilot.
Assurez-vous que votre cluster utilise cgroup v2. Pour en savoir plus, consultez Migrer des nœuds vers Linux cgroup v2.

Activer les cgroups accessibles en écriture pour vos nœuds

Activez les cgroups accessibles en écriture sur vos pools de nœuds en personnalisant la configuration containerd. Vous pouvez appliquer cette configuration à l'ensemble de votre cluster ou à des pools de nœuds spécifiques dans les clusters standards.

Dans votre fichier de configuration containerd, ajoutez une section writableCgroups et définissez le champ enabled sur true. Pour en savoir plus, consultez Personnaliser la configuration containerd dans les nœuds GKE.

writableCgroups:
  enabled: true

Spécifiez le fichier de configuration mis à jour lorsque vous créez ou mettez à jour un cluster ou un pool de nœuds.

Utiliser des cgroups accessibles en écriture dans les charges de travail

Une fois que vous avez activé les cgroups accessibles en écriture pour votre cluster ou vos pools de nœuds, configurez vos charges de travail pour qu'elles répondent à toutes les exigences suivantes :

Sélectionnez un nœud pour lequel les cgroups accessibles en écriture sont activés.
Activez les cgroups accessibles en écriture pour un ou plusieurs conteneurs du pod.
Utilisez la classe de qualité de service (QoS) garantie en remplissant l'une des conditions suivantes :
- Pour les charges de travail qui spécifient des ressources au niveau du pod, définissez des valeurs égales pour resources.requests et resources.limits dans la spécification du pod.
- Pour les charges de travail qui spécifient des ressources pour chaque conteneur, définissez des valeurs égales pour resources.requests et resources.limits dans la spécification de chaque conteneur du pod, y compris les conteneurs d'initialisation.

Pour configurer ces exigences, procédez comme suit :

Pour sélectionner les nœuds sur lesquels les cgroups accessibles en écriture sont activés, ajoutez le libellé node.gke.io/enable-writable-cgroups: "true" au champ spec.nodeSelector de la spécification de votre pod :
```
node.gke.io/enable-writable-cgroups: "true"
```
Pour activer les cgroups accessibles en écriture pour votre charge de travail, ajoutez l'un des libellés suivants au champ metadata.annotations de la spécification de votre pod :
- Activer pour l'ensemble du pod :
```
node.gke.io/enable-writable-cgroups: "true"
```
- Activer pour un conteneur spécifique dans le pod :
```
node.gke.io/enable-writable-cgroups.CONTAINER_NAME: "true"
```
  Remplacez CONTAINER_NAME par le nom du conteneur.
Pour configurer la classe QoS garantie pour votre pod, spécifiez des demandes et des limites de processeur et de mémoire égales pour chaque conteneur du pod ou pour l'ensemble du pod, comme dans l'exemple suivant :
```
resources:
  requests:
    cpu: "100m"
    memory: "100Mi"
  limits:
    cpu: "100m"
    memory: "100Mi"
```
Vous devez spécifier des demandes et des limites égales pour chaque conteneur, même si vous n'activez les cgroups accessibles en écriture que pour l'un des conteneurs du pod.

La spécification de votre pod final doit ressembler aux exemples suivants.

Cet exemple active les cgroups accessibles en écriture pour tous les conteneurs du pod :

apiVersion: v1
kind: Pod
metadata:
  name: writable-cgroups-pod
  annotations:
    node.gke.io/enable-writable-cgroups: "true"
spec:
  nodeSelector:
    node.gke.io/enable-writable-cgroups: "true"
  containers:
  - name: container
    image: busybox:stable
    command: ["/bin/sh", "-c"]
    args:
    -   |
      trap 'echo "Caught SIGTERM, exiting..."; exit 0' TERM
      echo "Waiting for termination signal..."
      while true; do sleep 1; done
  resources:
    requests:
      cpu: "100m"
      memory: "100Mi"
    limits:
      cpu: "100m"
      memory: "100Mi"

Cet exemple active les cgroups accessibles en écriture pour un conteneur spécifique dans un pod multiconteneur :

apiVersion: v1
kind: Pod
metadata:
  name: writable-cgroups-per-container
  annotations:
    node.gke.io/enable-writable-cgroups.busybox-container: "true"
spec:
  nodeSelector:
    node.gke.io/enable-writable-cgroups: "true"
  containers:
  - name: busybox-container
    image: busybox:stable
    command: ["/bin/sh", "-c"]
    args:
    -   |
      trap 'echo "Caught SIGTERM, exiting..."; exit 0' TERM
      echo "Waiting for termination signal..."
      while true; do sleep 1; done
    resources:
      requests:
        cpu: "100m"
        memory: "100Mi"
      limits:
        cpu: "100m"
        memory: "100Mi"
  - name: container-disabled
    image: busybox:stable
    command: ["/bin/sh", "-c"]
    args:
    -   |
      trap 'echo "Caught SIGTERM, exiting..."; exit 0' TERM
      echo "Waiting for termination signal..."
      while true; do sleep 1; done
    resources:
      requests:
        cpu: "100m"
        memory: "100Mi"
      limits:
        cpu: "100m"
        memory: "100Mi"

Vérifier que le système de fichiers cgroup est accessible en écriture

Pour vérifier les autorisations sur le système de fichiers /sys/fs/cgroup pour un pod ou un conteneur, procédez comme suit :

Identifiez le pod que vous souhaitez vérifier. Vous pouvez utiliser l'un des exemples de pods de la section Utiliser des cgroups accessibles en écriture dans les charges de travail.
Ouvrez une session shell dans le pod :
```
kubectl exec -it POD_NAME -- /bin/sh
```
Remplacez POD_NAME par le nom du pod.
Décrivez le système de fichiers cgroup installé :
```
mount | grep cgroup
```
Le résultat ressemble à ce qui suit :
```
cgroup on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
```
Dans ce résultat, rw indique que le système de fichiers est accessible en écriture. Si ro apparaît dans le résultat, le système de fichiers est en lecture seule.

Étapes suivantes

Personnaliser la configuration containerd

Configurer des cgroups accessibles en écriture pour les conteneurs Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.