Chapitre 16. Configuration des sysctl de réseau au niveau de l'interface


Sous Linux, sysctl permet à un administrateur de modifier les paramètres du noyau au moment de l'exécution. Vous pouvez modifier les sysctls réseau au niveau de l'interface en utilisant le méta plugin tuning Container Network Interface (CNI). Le méta plugin CNI de réglage fonctionne en chaîne avec un plugin CNI principal, comme illustré.

CNI plugin

Le plugin CNI principal attribue l'interface et la transmet au méta plugin CNI de réglage au moment de l'exécution. Vous pouvez modifier certains sysctls et plusieurs attributs d'interface (mode promiscuous, mode all-multicast, MTU et adresse MAC) dans l'espace de noms du réseau en utilisant le méta plugin CNI tuning. Dans la configuration du méta plugin CNI tuning, 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.

Note

Dans OpenShift Container Platform, le méta plugin CNI tuning ne prend en charge que la modification des sysctls réseau au niveau de l'interface.

16.1. Configuration du CNI d'accord

La procédure suivante configure le CNI de réglage pour modifier le réseau au niveau de l'interface net.ipv4.conf.IFNAME.accept_redirects sysctl. Cet exemple permet d'accepter et d'envoyer des paquets ICMP redirigés.

Procédure

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

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: <name> 1
      namespace: default 2
    spec:
      config: '{
        "cniVersion": "0.4.0", 3
        "name": "<name>", 4
        "plugins": [{
           "type": "<main_CNI_plugin>" 5
          },
          {
           "type": "tuning", 6
           "sysctl": {
                "net.ipv4.conf.IFNAME.accept_redirects": "1" 7
            }
          }
         ]
    }
    1
    Spécifie le nom de la pièce jointe réseau supplémentaire à créer. Le nom doit être unique dans l'espace de noms spécifié.
    2
    Spécifie l'espace de noms auquel l'objet est associé.
    3
    Spécifie la version de la spécification CNI.
    4
    Spécifie le nom de la configuration. Il est recommandé de faire correspondre le nom de la configuration à la valeur du nom de la définition de l'attachement au réseau.
    5
    Spécifie le nom du plugin CNI principal à configurer.
    6
    Spécifie le nom du méta plugin CNI.
    7
    Spécifie le sysctl à définir.

    Un exemple de fichier yaml est présenté ici :

    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.accept_redirects": "1"
            }
        }
      ]
    }'
  2. Appliquez le fichier yaml en exécutant la commande suivante :

    $ oc apply -f tuning-example.yaml

    Exemple de sortie

    networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

  3. Créez un pod tel que examplepod.yaml avec la définition de l'attachement réseau similaire à ce qui suit :

    apiVersion: v1
    kind: Pod
    metadata:
      name: tunepod
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/networks: tuningnad 1
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000 2
          runAsGroup: 3000 3
          allowPrivilegeEscalation: false 4
          capabilities: 5
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true 6
        seccompProfile: 7
          type: RuntimeDefault
    1
    Spécifiez le nom du site configuré NetworkAttachmentDefinition.
    2
    runAsUser contrôle l'identifiant de l'utilisateur avec lequel le conteneur est exécuté.
    3
    runAsGroup contrôle l'identifiant du groupe primaire avec lequel les conteneurs sont exécutés.
    4
    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.
    5
    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.
    6
    runAsNonRoot: true exige que le conteneur fonctionne avec un utilisateur dont l'UID est différent de 0.
    7
    RuntimeDefault active le profil seccomp par défaut pour un pod ou une charge de travail de conteneur.
  4. Appliquez le fichier yaml en exécutant la commande suivante :

    $ oc apply -f examplepod.yaml
  5. Vérifiez que le module est créé en exécutant la commande suivante :

    $ oc get pod

    Exemple de sortie

    NAME      READY   STATUS    RESTARTS   AGE
    tunepod   1/1     Running   0          47s

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

    $ oc rsh tunepod
  7. Vérifiez les valeurs des drapeaux sysctl configurés. Par exemple, trouvez la valeur net.ipv4.conf.net1.accept_redirects en exécutant la commande suivante :

    sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects

    Résultats attendus

    net.ipv4.conf.net1.accept_redirects = 1

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.

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

© 2024 Red Hat, Inc.