Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

6.9. Utilisation de sysctls dans les conteneurs

Les paramètres sysctl sont exposés à travers Kubernetes, ce qui permet aux utilisateurs de modifier certains paramètres du noyau au moment de l'exécution. Seuls les sysctls qui sont namespaced peuvent être définis indépendamment sur les pods. Si un sysctl n'est pas namespaced, appelé node-level, vous devez utiliser une autre méthode pour définir le sysctl, par exemple en utilisant l'opérateur Node Tuning.

Les sysctls de réseau sont une catégorie spéciale de sysctl. Les sysctls de réseau comprennent

  • Les sysctls de l'ensemble du système, par exemple net.ipv4.ip_local_port_range, qui sont valables pour toute la mise en réseau. Vous pouvez les définir indépendamment pour chaque module d'un nœud.
  • Les sysctls spécifiques à l'interface, par exemple net.ipv4.conf.IFNAME.accept_local, qui ne s'appliquent qu'à une interface réseau supplémentaire spécifique pour un pod donné. Vous pouvez les définir indépendamment pour chaque configuration de réseau supplémentaire. Vous les définissez à l'aide d'une configuration sur le site tuning-cni après la création des interfaces réseau.

En outre, seuls les sysctls considérés comme safe sont inscrits sur la liste blanche par défaut ; vous pouvez activer manuellement d'autres sysctls unsafe sur le nœud pour qu'ils soient accessibles à l'utilisateur.

6.9.1. À propos de sysctls
Copier lien

Sous Linux, l'interface sysctl permet à un administrateur de modifier les paramètres du noyau au moment de l'exécution. Les paramètres sont disponibles dans le système de fichiers /proc/sys/ le système de fichiers des processus virtuels. Les paramètres couvrent différents sous-systèmes, tels que :

  • noyau (préfixe commun : kernel.)
  • la mise en réseau (préfixe commun : net.)
  • la mémoire virtuelle (préfixe commun : vm.)
  • MDADM (préfixe commun : dev.)

D'autres sous-systèmes sont décrits dans la documentation du noyau. Pour obtenir une liste de tous les paramètres, exécutez : 

$ sudo sysctl -a
Copy to Clipboard Toggle word wrap

6.9.2. Sysctl à espace de noms et à niveau de nœud
Copier lien

Un certain nombre de sysctls se trouvent à l'adresse namespaced dans les noyaux Linux. Cela signifie que vous pouvez les définir indépendamment pour chaque pod sur un nœud. Le fait d'être namespaced est une exigence pour que les sysctls soient accessibles dans un contexte de pod au sein de Kubernetes.

Les sysctls suivants sont connus pour être des espaces de noms :

  • kernel.shm*
  • kernel.msg*
  • kernel.sem
  • fs.mqueue.*

En outre, la plupart des sysctls du groupe net.* sont connus pour leur espace de noms. Leur adoption de l'espace de noms diffère en fonction de la version du noyau et du distributeur.

Les sysctls qui n'ont pas d'espace de noms sont appelés node-level et doivent être définis manuellement par l'administrateur du cluster, soit au moyen de la distribution Linux sous-jacente des nœuds, par exemple en modifiant le fichier /etc/sysctls.conf ou en utilisant un démon avec des conteneurs privilégiés. Vous pouvez utiliser l'opérateur Node Tuning pour définir node-level sysctls.

Note

Envisager de marquer les nœuds avec des sysctls spéciaux comme tainted. Ne planifiez sur ces nœuds que les pods qui ont besoin de ces paramètres sysctl. Utilisez la fonctionnalité taints and toleration pour marquer les noeuds.

6.9.3. Sysctls sûrs et non sûrs
Copier lien

Les sysctls sont regroupés en safe et unsafe sysctls.

Pour que les sysctls à l'échelle du système soient considérés comme sûrs, ils doivent avoir un espace de noms. Un sysctl à espace de noms garantit l'isolation entre les espaces de noms et, par conséquent, entre les modules. Si vous définissez un sysctl pour un pod, il ne doit ajouter aucun des éléments suivants :

  • Influencer tout autre pod sur le nœud
  • Nuisent à la santé du nœud
  • Obtenir des ressources de CPU ou de mémoire en dehors des limites de ressources d'un pod
Note

L'espacement des noms n'est pas suffisant pour que le sysctl soit considéré comme sûr.

Tout sysctl qui n'est pas ajouté à la liste des sysctls autorisés sur OpenShift Container Platform est considéré comme dangereux pour OpenShift Container Platform.

Les sysctls non sécurisés ne sont pas autorisés par défaut. Pour les sysctls à l'échelle du système, l'administrateur du cluster doit les activer manuellement pour chaque nœud. Les pods dont les sysctls non sécurisés sont désactivés sont planifiés mais ne se lancent pas.

Note

Vous ne pouvez pas activer manuellement les sysctls non sécurisés spécifiques à l'interface.

OpenShift Container Platform ajoute les sysctls sûrs suivants à l'échelle du système et spécifiques à l'interface à une liste de sysctls sûrs autorisés :

Expand
Tableau 6.4. Sysctls sûrs pour l'ensemble du système
sysctlDescription

kernel.shm_rmid_forced

Lorsqu'il vaut 1, tous les objets de mémoire partagée dans l'espace de noms IPC actuel sont automatiquement forcés d'utiliser IPC_RMID. Pour plus d'informations, voir shm_rmid_forced.

net.ipv4.ip_local_port_range

Définit la plage de ports locaux utilisée par TCP et UDP pour choisir le port local. Le premier chiffre est le premier numéro de port, et le second est le dernier numéro de port local. Si possible, il est préférable que ces numéros aient une parité différente (une valeur paire et une valeur impaire). Ils doivent être supérieurs ou égaux à ip_unprivileged_port_start. Les valeurs par défaut sont respectivement 32768 et 60999. Pour plus d'informations, voir ip_local_port_range.

net.ipv4.tcp_syncookies

Lorsque net.ipv4.tcp_syncookies est activé, le noyau traite les paquets TCP SYN normalement jusqu'à ce que la file d'attente des connexions semi-ouvertes soit pleine, moment où la fonctionnalité de cookie SYN entre en jeu. Cette fonctionnalité permet au système de continuer à accepter des connexions valides, même en cas d'attaque par déni de service. Pour plus d'informations, voir tcp_syncookies.

net.ipv4.ping_group_range

Cela limite les sockets de datagramme ICMP_PROTO aux utilisateurs de l'intervalle de groupes. La valeur par défaut est 1 0, ce qui signifie que personne, pas même root, ne peut créer de sockets ping. Pour plus d'informations, voir ping_group_range.

net.ipv4.ip_unprivileged_port_start

Cette valeur définit le premier port non privilégié dans l'espace de noms du réseau. Pour désactiver tous les ports privilégiés, définissez cette valeur à 0. Les ports privilégiés ne doivent pas chevaucher le port ip_local_port_range. Pour plus d'informations, voir ip_unprivileged_port_start.

Expand
Tableau 6.5. Sysctls de sécurité spécifiques à l'interface
sysctlDescription

net.ipv4.conf.IFNAME.accept_redirects

Accepter les messages de redirection ICMP IPv4.

net.ipv4.conf.IFNAME.accept_source_route

Accepter les paquets IPv4 avec l'option strict source route (SRR).

net.ipv4.conf.IFNAME.arp_accept

Définir le comportement pour les trames ARP gratuites avec une adresse IPv4 qui n'est pas déjà présente dans la table ARP :

  • 0 - Ne pas créer de nouvelles entrées dans la table ARP.
  • 1 - Créer de nouvelles entrées dans la table ARP.

net.ipv4.conf.IFNAME.arp_notify

Définir le mode de notification des changements d'adresse IPv4 et de périphérique.

net.ipv4.conf.IFNAME.disable_policy

Désactiver la politique IPSEC (SPD) pour cette interface IPv4.

net.ipv4.conf.IFNAME.secure_redirects

Accepter les messages de redirection ICMP uniquement vers les passerelles figurant dans la liste des passerelles actuelles de l'interface.

net.ipv4.conf.IFNAME.send_redirects

L'option Envoyer des redirections n'est activée que si le nœud agit comme un routeur. En d'autres termes, un hôte ne doit pas envoyer de message de redirection ICMP. Il est utilisé par les routeurs pour informer l'hôte de l'existence d'un meilleur chemin de routage pour une destination donnée.

net.ipv6.conf.IFNAME.accept_ra

Accepter les annonces de routeur IPv6 ; autoconfigurer à l'aide de ces annonces. Il détermine également s'il faut ou non transmettre les sollicitations du routeur. Les sollicitations de routeur ne sont transmises que si le paramètre fonctionnel est l'acceptation des annonces de routeur.

net.ipv6.conf.IFNAME.accept_redirects

Accepter les messages de redirection ICMP IPv6.

net.ipv6.conf.IFNAME.accept_source_route

Accepter les paquets IPv6 avec l'option SRR.

net.ipv6.conf.IFNAME.arp_accept

Définir le comportement pour les trames ARP gratuites avec une adresse IPv6 qui n'est pas déjà présente dans la table ARP :

  • 0 - Ne pas créer de nouvelles entrées dans la table ARP.
  • 1 - Créer de nouvelles entrées dans la table ARP.

net.ipv6.conf.IFNAME.arp_notify

Définir le mode de notification des changements d'adresse IPv6 et de périphérique.

net.ipv6.neigh.IFNAME.base_reachable_time_ms

Ce paramètre contrôle la durée de vie de la correspondance entre l'adresse matérielle et l'adresse IP dans la table de voisinage pour IPv6.

net.ipv6.neigh.IFNAME.retrans_time_ms

Définir le délai de retransmission des messages de découverte du voisin.

Note

Lorsque vous définissez ces valeurs à l'aide du plugin CNI tuning, utilisez littéralement la valeur IFNAME. Le nom de l'interface est représenté par le jeton IFNAME et est remplacé par le nom réel de l'interface au moment de l'exécution.

OpenShift Container Platform inclut une liste prédéfinie d'interfaces sûres spécifiques sysctls. Vous pouvez modifier cette liste en mettant à jour le cni-sysctl-allowlist dans l'espace de noms openshift-multus.

Important

La prise en charge de la mise à jour de la liste des sysctls sûrs spécifiques à l'interface est une fonctionnalité de l'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes d'un point de vue fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Suivez cette procédure pour modifier la liste prédéfinie des sites sûrs sysctls. Cette procédure décrit comment étendre la liste d'autorisations par défaut.

Procédure

  1. Affichez la liste prédéfinie existante en exécutant la commande suivante : 

    $ oc get cm -n openshift-multus cni-sysctl-allowlist -oyaml
    Copy to Clipboard Toggle word wrap

    Résultats attendus

    apiVersion: v1
data:
  allowlist.conf: |-
    ^net.ipv4.conf.IFNAME.accept_redirects$
    ^net.ipv4.conf.IFNAME.accept_source_route$
    ^net.ipv4.conf.IFNAME.arp_accept$
    ^net.ipv4.conf.IFNAME.arp_notify$
    ^net.ipv4.conf.IFNAME.disable_policy$
    ^net.ipv4.conf.IFNAME.secure_redirects$
    ^net.ipv4.conf.IFNAME.send_redirects$
    ^net.ipv6.conf.IFNAME.accept_ra$
    ^net.ipv6.conf.IFNAME.accept_redirects$
    ^net.ipv6.conf.IFNAME.accept_source_route$
    ^net.ipv6.conf.IFNAME.arp_accept$
    ^net.ipv6.conf.IFNAME.arp_notify$
    ^net.ipv6.neigh.IFNAME.base_reachable_time_ms$
    ^net.ipv6.neigh.IFNAME.retrans_time_ms$
kind: ConfigMap
metadata:
  annotations:
    kubernetes.io/description: |
      Sysctl allowlist for nodes.
    release.openshift.io/version: 4.12.0-0.nightly-2022-11-16-003434
  creationTimestamp: "2022-11-17T14:09:27Z"
  name: cni-sysctl-allowlist
  namespace: openshift-multus
  resourceVersion: "2422"
  uid: 96d138a3-160e-4943-90ff-6108fa7c50c3
    Copy to Clipboard Toggle word wrap

  2. Modifiez la liste à l'aide de la commande suivante : 

    $ oc edit cm -n openshift-multus cni-sysctl-allowlist -oyaml
    Copy to Clipboard Toggle word wrap

    Par exemple, pour vous permettre de mettre en œuvre un transfert de chemin inverse plus strict, vous devez ajouter ^net.ipv4.conf.IFNAME.rp_filter$ et ^net.ipv6.conf.IFNAME.rp_filter$ à la liste, comme indiqué ici : 

    # Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  allowlist.conf: |-
    ^net.ipv4.conf.IFNAME.accept_redirects$
    ^net.ipv4.conf.IFNAME.accept_source_route$
    ^net.ipv4.conf.IFNAME.arp_accept$
    ^net.ipv4.conf.IFNAME.arp_notify$
    ^net.ipv4.conf.IFNAME.disable_policy$
    ^net.ipv4.conf.IFNAME.secure_redirects$
    ^net.ipv4.conf.IFNAME.send_redirects$
    ^net.ipv4.conf.IFNAME.rp_filter$
    ^net.ipv6.conf.IFNAME.accept_ra$
    ^net.ipv6.conf.IFNAME.accept_redirects$
    ^net.ipv6.conf.IFNAME.accept_source_route$
    ^net.ipv6.conf.IFNAME.arp_accept$
    ^net.ipv6.conf.IFNAME.arp_notify$
    ^net.ipv6.neigh.IFNAME.base_reachable_time_ms$
    ^net.ipv6.neigh.IFNAME.retrans_time_ms$
    ^net.ipv6.conf.IFNAME.rp_filter$
    Copy to Clipboard Toggle word wrap

  3. Enregistrez les modifications dans le fichier et quittez.

    Note

    La suppression de sysctls est également possible. Modifiez le fichier, supprimez sysctl ou sysctls, puis enregistrez les modifications et quittez.

Vérification

Suivez cette procédure pour mettre en œuvre un transfert de chemin inverse plus strict pour IPv4. Pour plus d'informations sur le transfert de chemin inverse, voir Transfert de chemin inverse .

  1. Créez une définition de pièce jointe au réseau, telle que reverse-path-fwd-example.yaml, avec le contenu suivant : 

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: tuningnad
  namespace: default
spec:
  config: '{
    "cniVersion": "0.4.0",
    "name": "tuningnad",
    "plugins": [{
      "type": "bridge"
      },
      {
      "type": "tuning",
      "sysctl": {
         "net.ipv4.conf.IFNAME.rp_filter": "1"
        }
    }
  ]
}'
    Copy to Clipboard Toggle word wrap

  2. Appliquez le fichier yaml en exécutant la commande suivante : 

    $ oc apply -f reverse-path-fwd-example.yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
    Copy to Clipboard Toggle word wrap

  3. Créez un pod tel que examplepod.yaml en utilisant le YAML suivant : 

    apiVersion: v1
kind: Pod
metadata:
  name: example
  labels:
    app: httpd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: tuningnad
    1 
    
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: httpd
      image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest'
      ports:
        - containerPort: 8080
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    Copy to Clipboard Toggle word wrap
    1
    Spécifiez le nom du site configuré NetworkAttachmentDefinition.

  4. Appliquez le fichier yaml en exécutant la commande suivante : 

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap

  5. Vérifiez que le module est créé en exécutant la commande suivante : 

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME      READY   STATUS    RESTARTS   AGE
example   1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  6. Connectez-vous au module en exécutant la commande suivante : 

    $ oc rsh example
    Copy to Clipboard Toggle word wrap

  7. Vérifiez la valeur de l'indicateur sysctl configuré. Par exemple, trouvez la valeur net.ipv4.conf.net1.rp_filter en exécutant la commande suivante : 

    sh-4.4# sysctl net.ipv4.conf.net1.rp_filter
    Copy to Clipboard Toggle word wrap

    Résultats attendus

    net.ipv4.conf.net1.rp_filter = 1
    Copy to Clipboard Toggle word wrap

6.9.5. Démarrer un pod avec des sysctls sûrs
Copier lien

Vous pouvez définir des sysctls sur les pods à l'aide de la page securityContext du pod. Le site securityContext s'applique à tous les conteneurs du même pod.

Les sysctls sûrs sont autorisés par défaut.

Cet exemple utilise le pod securityContext pour définir les sysctls de sécurité suivants :

  • kernel.shm_rmid_forced
  • net.ipv4.ip_local_port_range
  • net.ipv4.tcp_syncookies
  • net.ipv4.ping_group_range
Avertissement

Pour éviter de déstabiliser votre système d'exploitation, ne modifiez les paramètres sysctl qu'après avoir compris leurs effets.

Cette procédure permet de démarrer un pod avec les paramètres sysctl configurés.

Note

Dans la plupart des cas, vous modifiez une définition de pod existante et ajoutez la spécification securityContext.

Procédure

  1. Créez un fichier YAML sysctl_pod.yaml qui définit un exemple de pod et ajoutez la spécification securityContext, comme le montre l'exemple suivant : 

    apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
  namespace: default
spec:
  containers:
  - name: podexample
    image: centos
    command: ["bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
    1 
    
      runAsGroup: 3000
    2 
    
      allowPrivilegeEscalation: false
    3 
    
      capabilities:
    4 
    
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    5 
    
    seccompProfile:
    6 
    
      type: RuntimeDefault
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "1"
    - name: net.ipv4.ip_local_port_range
      value: "32770       60666"
    - name: net.ipv4.tcp_syncookies
      value: "0"
    - name: net.ipv4.ping_group_range
      value: "0           200000000"
    Copy to Clipboard Toggle word wrap
    1
    runAsUser contrôle l'identifiant de l'utilisateur avec lequel le conteneur est exécuté.
    2
    runAsGroup contrôle l'identifiant du groupe primaire avec lequel les conteneurs sont exécutés.
    3
    allowPrivilegeEscalation détermine si un pod peut demander à autoriser l'escalade des privilèges. S'il n'est pas spécifié, la valeur par défaut est true. Ce booléen contrôle directement si le drapeau no_new_privs est activé sur le processus du conteneur.
    4
    capabilities permettent des actions privilégiées sans donner un accès complet à la racine. Cette politique permet de s'assurer que toutes les capacités sont supprimées du pod.
    5
    runAsNonRoot: true exige que le conteneur fonctionne avec un utilisateur dont l'UID est différent de 0.
    6
    RuntimeDefault active le profil seccomp par défaut pour un pod ou une charge de travail de conteneur.

  2. Créez le pod en exécutant la commande suivante : 

    $ oc apply -f sysctl_pod.yaml
    Copy to Clipboard Toggle word wrap

  3. Vérifiez que le module est créé en exécutant la commande suivante : 

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME              READY   STATUS            RESTARTS   AGE
sysctl-example    1/1     Running           0          14s
    Copy to Clipboard Toggle word wrap

  4. Connectez-vous au module en exécutant la commande suivante : 

    $ oc rsh sysctl-example
    Copy to Clipboard Toggle word wrap

  5. Vérifiez les valeurs des drapeaux sysctl configurés. Par exemple, trouvez la valeur kernel.shm_rmid_forced en exécutant la commande suivante : 

    sh-4.4# sysctl kernel.shm_rmid_forced
    Copy to Clipboard Toggle word wrap

    Résultats attendus

    kernel.shm_rmid_forced = 1
    Copy to Clipboard Toggle word wrap

6.9.6. Démarrer un pod avec des sysctls non sécurisés
Copier lien

Un pod avec des sysctls non sécurisés ne peut être lancé sur aucun nœud à moins que l'administrateur du cluster n'active explicitement les sysctls non sécurisés pour ce nœud. Comme pour les sysctls au niveau du nœud, utilisez la fonctionnalité de taints et de tolérance ou les étiquettes sur les nœuds pour planifier ces pods sur les bons nœuds.

L'exemple suivant utilise le pod securityContext pour définir un sysctl sûr kernel.shm_rmid_forced et deux sysctls non sûrs, net.core.somaxconn et kernel.msgmax. La spécification ne fait aucune distinction entre les sysctls safe et unsafe.

Avertissement

Pour éviter de déstabiliser votre système d'exploitation, ne modifiez les paramètres sysctl qu'après avoir compris leurs effets.

L'exemple suivant illustre ce qui se passe lorsque vous ajoutez des sysctls sûrs et non sûrs à une spécification de pod :

Procédure

  1. Créez un fichier YAML sysctl-example-unsafe.yaml qui définit un exemple de pod et ajoutez la spécification securityContext, comme le montre l'exemple suivant : 

    apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example-unsafe
spec:
  containers:
  - name: podexample
    image: centos
    command: ["bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.core.somaxconn
      value: "1024"
    - name: kernel.msgmax
      value: "65536"
    Copy to Clipboard Toggle word wrap

  2. Créez le pod à l'aide de la commande suivante : 

    $ oc apply -f sysctl-example-unsafe.yaml
    Copy to Clipboard Toggle word wrap

  3. Vérifiez que le pod est planifié mais qu'il ne se déploie pas parce que les sysctls non sécurisés ne sont pas autorisés pour le nœud à l'aide de la commande suivante : 

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                       READY             STATUS            RESTARTS   AGE
sysctl-example-unsafe      0/1               SysctlForbidden   0          14s
    Copy to Clipboard Toggle word wrap

6.9.7. Activation des sysctls non sûrs
Copier lien

Un administrateur de cluster peut autoriser certains sysctls non sécurisés dans des situations très particulières telles que des performances élevées ou le réglage d'applications en temps réel.

Si vous souhaitez utiliser des sysctls non sécurisés, un administrateur de cluster doit les activer individuellement pour un type de nœud spécifique. Les sysctls doivent être nommés dans l'espace de noms.

Vous pouvez contrôler davantage les sysctls définis dans les pods en spécifiant des listes de sysctls ou des modèles de sysctl dans le champ allowedUnsafeSysctls des contraintes du contexte de sécurité.

  • L'option allowedUnsafeSysctls permet de répondre à des besoins spécifiques tels que l'optimisation d'applications à haute performance ou en temps réel.
Avertissement

En raison de leur nature non sûre, l'utilisation de sysctls non sûrs est à vos propres risques et peut entraîner de graves problèmes, tels qu'un comportement inapproprié des conteneurs, une pénurie de ressources ou la rupture d'un nœud.

Procédure

  1. Listez les objets MachineConfig existants pour votre cluster OpenShift Container Platform afin de décider comment étiqueter votre machine config en exécutant la commande suivante : 

    $ oc get machineconfigpool
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-bfb92f0cd1684e54d8e234ab7423cc96   True      False      False      3              3                   3                     0                      42m
worker   rendered-worker-21b6cb9a0f8919c88caf39db80ac1fce   True      False      False      3              3                   3                     0                      42m
    Copy to Clipboard Toggle word wrap

  2. Ajoutez une étiquette au pool de configuration de la machine où les conteneurs avec les sysctls non sécurisés seront exécutés en exécutant la commande suivante : 

    $ oc label machineconfigpool worker custom-kubelet=sysctl
    Copy to Clipboard Toggle word wrap

  3. Créer un fichier YAML set-sysctl-worker.yaml qui définit une ressource personnalisée (CR) KubeletConfig: 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: custom-kubelet
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: sysctl
    1 
    
  kubeletConfig:
    allowedUnsafeSysctls:
    2 
    
      - "kernel.msg*"
      - "net.core.somaxconn"
    Copy to Clipboard Toggle word wrap
    1
    Spécifiez l'étiquette du pool de configuration de la machine.
    2
    Dressez la liste des sysctls non sûrs que vous souhaitez autoriser.

  4. Créez l'objet en exécutant la commande suivante : 

    $ oc apply -f set-sysctl-worker.yaml
    Copy to Clipboard Toggle word wrap

  5. Attendez que le Machine Config Operator génère la nouvelle configuration rendue et appliquez-la aux machines en exécutant la commande suivante : 

    $ oc get machineconfigpool worker -w
    Copy to Clipboard Toggle word wrap

    Après quelques minutes, l'état de UPDATING passe de Vrai à Faux : 

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-f1704a00fc6f30d3a7de9a15fd68a800   False     True       False      3              2                   2                     0                      71m
worker   rendered-worker-f1704a00fc6f30d3a7de9a15fd68a800   False     True       False      3              2                   3                     0                      72m
worker   rendered-worker-0188658afe1f3a183ec8c4f14186f4d5   True      False      False      3              3                   3                     0                      72m
    Copy to Clipboard Toggle word wrap

  6. Créez un fichier YAML sysctl-example-safe-unsafe.yaml qui définit un exemple de pod et ajoutez la spécification securityContext, comme le montre l'exemple suivant : 

    apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example-safe-unsafe
spec:
  containers:
  - name: podexample
    image: centos
    command: ["bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.core.somaxconn
      value: "1024"
    - name: kernel.msgmax
      value: "65536"
    Copy to Clipboard Toggle word wrap

  7. Créez le pod en exécutant la commande suivante : 

    $ oc apply -f sysctl-example-safe-unsafe.yaml
    Copy to Clipboard Toggle word wrap

    Résultats attendus

    Warning: would violate PodSecurity "restricted:latest": forbidden sysctls (net.core.somaxconn, kernel.msgmax)
pod/sysctl-example-safe-unsafe created
    Copy to Clipboard Toggle word wrap

  8. Vérifiez que le module est créé en exécutant la commande suivante : 

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                         READY   STATUS    RESTARTS   AGE
sysctl-example-safe-unsafe   1/1     Running   0          19s
    Copy to Clipboard Toggle word wrap

  9. Connectez-vous au module en exécutant la commande suivante : 

    $ oc rsh sysctl-example-safe-unsafe
    Copy to Clipboard Toggle word wrap

  10. Vérifiez les valeurs des drapeaux sysctl configurés. Par exemple, trouvez la valeur net.core.somaxconn en exécutant la commande suivante : 

    sh-4.4# sysctl net.core.somaxconn
    Copy to Clipboard Toggle word wrap

    Résultats attendus

    net.core.somaxconn = 1024
    Copy to Clipboard Toggle word wrap

Le sysctl non sécurisé est désormais autorisé et la valeur est définie comme indiqué dans la spécification securityContext de la spécification pod mise à jour.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat