32.2. Installation de l'opérateur MetalLB


En tant qu'administrateur de cluster, vous pouvez ajouter l'Opérateur MetallB afin qu'il puisse gérer le cycle de vie d'une instance de MetalLB sur votre cluster.

La MetalLB et le basculement IP sont incompatibles. Si vous avez configuré le basculement IP pour votre cluster, effectuez les étapes pour supprimer le basculement IP avant d'installer l'Opérateur.

32.2.1. Installer l'Opérateur MetalLB à partir de l'OperatorHub en utilisant la console web

En tant qu'administrateur de cluster, vous pouvez installer l'opérateur MetalLB en utilisant la console web d'OpenShift Container Platform.

Conditions préalables

  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Dans la console web d'OpenShift Container Platform, naviguez vers Operators OperatorHub.
  2. Tapez un mot-clé dans la case Filter by keyword ou faites défiler l'écran pour trouver l'opérateur souhaité. Par exemple, tapez metallb pour trouver l'opérateur MetalLB.

    Vous pouvez également filtrer les options par Infrastructure Features. Par exemple, sélectionnez Disconnected si vous voulez voir les opérateurs qui travaillent dans des environnements déconnectés, également connus sous le nom d'environnements réseau restreints.

  3. Sur la page Install Operator acceptez les valeurs par défaut et cliquez sur Install.

Vérification

  1. Pour confirmer que l'installation a réussi :

    1. Naviguez jusqu'à l'écran Operators Installed Operators page.
    2. Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.
  2. Si l'opérateur n'est pas installé correctement, vérifiez l'état de l'opérateur et consultez les journaux :

    1. Naviguez jusqu'à l'écran Operators Installed Operators et vérifiez que la colonne Status ne présente pas d'erreurs ou de défaillances.
    2. Naviguez jusqu'à l'écran Workloads Pods et vérifiez les journaux de tous les pods du projet openshift-operators qui signalent des problèmes.

32.2.2. Installation à partir d'OperatorHub en utilisant le CLI

Au lieu d'utiliser la console web d'OpenShift Container Platform, vous pouvez installer un Operator depuis OperatorHub en utilisant le CLI. Vous pouvez utiliser l'OpenShift CLI (oc) pour installer l'opérateur MetalLB.

Il est recommandé d'installer l'opérateur dans l'espace de noms metallb-system lors de l'utilisation de l'interface de programmation.

Conditions préalables

  • Un cluster installé sur du matériel bare-metal.
  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créez un espace de noms pour l'opérateur MetalLB en entrant la commande suivante :

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb-system
    EOF
  2. Créer une ressource personnalisée (CR) de groupe d'opérateurs dans l'espace de noms :

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator
      namespace: metallb-system
    EOF
  3. Confirmez que le groupe Operator est installé dans l'espace de noms :

    $ oc get operatorgroup -n metallb-system

    Exemple de sortie

    NAME               AGE
    metallb-operator   14m

  4. Créer un CR Subscription:

    1. Définissez le CR Subscription et enregistrez le fichier YAML, par exemple metallb-sub.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator-sub
        namespace: metallb-system
      spec:
        channel: stable
        name: metallb-operator
        source: redhat-operators 1
        sourceNamespace: openshift-marketplace
      1
      Vous devez spécifier la valeur redhat-operators.
    2. Pour créer le CR Subscription, exécutez la commande suivante :

      $ oc create -f metallb-sub.yaml
  5. Facultatif : Pour que les mesures BGP et BFD apparaissent dans Prometheus, vous pouvez étiqueter l'espace de noms comme dans la commande suivante :

    $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"

Vérification

Les étapes de vérification supposent que l'opérateur MetalLB est installé dans l'espace de noms metallb-system.

  1. Confirmer que le plan d'installation se trouve dans l'espace de noms :

    $ oc get installplan -n metallb-system

    Exemple de sortie

    NAME            CSV                                   APPROVAL    APPROVED
    install-wzg94   metallb-operator.4.12.0-nnnnnnnnnnnn   Automatic   true

    Note

    L'installation de l'opérateur peut prendre quelques secondes.

  2. Pour vérifier que l'opérateur est installé, entrez la commande suivante :

    $ oc get clusterserviceversion -n metallb-system \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase

    Exemple de sortie

    Name                                  Phase
    metallb-operator.4.12.0-nnnnnnnnnnnn   Succeeded

32.2.3. Démarrer MetalLB sur votre cluster

Après avoir installé l'Opérateur, vous devez configurer une instance unique d'une ressource personnalisée MetalLB. Après avoir configuré la ressource personnalisée, l'Opérateur démarre MetalLB sur votre cluster.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
  • Installer l'opérateur MetalLB.

Procédure

Cette procédure suppose que le MetalLB Operator est installé dans l'espace de noms metallb-system. Si vous avez effectué l'installation à l'aide de la console web, remplacez l'espace de noms par openshift-operators.

  1. Créer une instance unique d'une ressource personnalisée MetalLB :

    $ cat << EOF | oc apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    EOF

Vérification

Confirmez que le déploiement du contrôleur MetalLB et le jeu de démons pour l'enceinte MetalLB sont en cours d'exécution.

  1. Vérifiez que le déploiement du contrôleur est en cours :

    $ oc get deployment -n metallb-system controller

    Exemple de sortie

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    controller   1/1     1            1           11m

  2. Vérifiez que le démon défini pour l'orateur est en cours d'exécution :

    $ oc get daemonset -n metallb-system speaker

    Exemple de sortie

    NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
    speaker   6         6         6       6            6           kubernetes.io/os=linux   18m

    L'exemple indique 6 enceintes. Le nombre de modules de haut-parleurs dans votre cluster peut être différent de celui indiqué dans l'exemple. Assurez-vous que la sortie indique un module pour chaque nœud de votre cluster.

32.2.4. Spécifications de déploiement pour MetalLB

Lorsque vous démarrez une instance de MetalLB à l'aide de la ressource personnalisée MetalLB, vous pouvez configurer des spécifications de déploiement dans la ressource personnalisée MetalLB pour gérer le déploiement et l'exécution des pods controller ou speaker dans votre cluster. Utilisez ces spécifications de déploiement pour gérer les tâches suivantes :

  • Sélectionner les nœuds pour le déploiement des pods MetalLB.
  • Gérer la programmation en utilisant la priorité et l'affinité des pods.
  • Attribuer des limites de CPU pour les pods MetalLB.
  • Attribuer une classe d'exécution de conteneur pour les pods MetalLB.
  • Attribuer des métadonnées aux pods MetalLB.

32.2.4.1. Limiter les pods d'orateurs à des nœuds spécifiques

Par défaut, lorsque vous démarrez MetalLB avec l'Opérateur MetalLB, l'Opérateur démarre une instance d'un pod speaker sur chaque nœud du cluster. Seuls les nœuds avec un pod speaker peuvent annoncer une adresse IP d'équilibreur de charge. Vous pouvez configurer la ressource personnalisée MetalLB avec un sélecteur de nœud pour spécifier quels nœuds exécutent les pods speaker.

La raison la plus courante de limiter les pods speaker à des nœuds spécifiques est de s'assurer que seuls les nœuds disposant d'interfaces réseau sur des réseaux spécifiques annoncent les adresses IP de l'équilibreur de charge. Seuls les nœuds disposant d'un pod speaker en cours d'exécution sont annoncés comme destinations de l'adresse IP de l'équilibreur de charge.

Si vous limitez les pods speaker à des nœuds spécifiques et que vous spécifiez local pour la stratégie de trafic externe d'un service, vous devez vous assurer que les pods d'application du service sont déployés sur les mêmes nœuds.

Exemple de configuration pour limiter les pods de haut-parleurs aux nœuds de travail

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:  <.>
    node-role.kubernetes.io/worker: ""
  speakerTolerations:   <.>
  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"

<.> L'exemple de configuration spécifie d'affecter les modules de haut-parleurs aux nœuds de travailleurs, mais vous pouvez spécifier les étiquettes que vous avez affectées aux nœuds ou tout sélecteur de nœud valide. <.> Dans cet exemple de configuration, le module auquel cette tolérance est attachée tolère toute souillure correspondant à la valeur key et à la valeur effect à l'aide de l'option operator.

Après avoir appliqué un manifeste avec le champ spec.nodeSelector, vous pouvez vérifier le nombre de pods que l'opérateur a déployés avec la commande oc get daemonset -n metallb-system speaker. De même, vous pouvez afficher les nœuds qui correspondent à vos étiquettes à l'aide d'une commande telle que oc get nodes -l node-role.kubernetes.io/worker=.

Vous pouvez éventuellement autoriser le nœud à contrôler les modules de haut-parleurs qui doivent ou ne doivent pas être programmés sur lui à l'aide de règles d'affinité. Vous pouvez également limiter ces modules en appliquant une liste de tolérances. Pour plus d'informations sur les règles d'affinité, les taches et les tolérances, consultez les ressources supplémentaires.

32.2.4.2. Configurer la priorité et l'affinité des pods dans un déploiement MetalLB

Vous pouvez éventuellement attribuer des règles de priorité et d'affinité aux modules controller et speaker en configurant la ressource personnalisée MetalLB. La priorité du pod indique l'importance relative d'un pod sur un nœud et planifie le pod en fonction de cette priorité. Définissez une priorité élevée pour votre module controller ou speaker afin de garantir la priorité de planification par rapport aux autres modules sur le nœud.

L'affinité de pod gère les relations entre les pods. Attribuez une affinité de pod à controller ou speaker pods pour contrôler le nœud sur lequel l'ordonnanceur place le pod dans le contexte des relations entre les pods. Par exemple, vous pouvez autoriser des modules avec des charges de travail logiquement liées sur le même nœud, ou vous assurer que les modules avec des charges de travail conflictuelles sont sur des nœuds séparés.

Conditions préalables

  • Vous êtes connecté en tant qu'utilisateur avec des privilèges cluster-admin.
  • Vous avez installé l'opérateur MetalLB.

Procédure

  1. Créez une ressource personnalisée PriorityClass, telle que myPriorityClass.yaml, pour configurer le niveau de priorité. Cet exemple utilise une classe de haute priorité :

    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: high-priority
    value: 1000000
  2. Appliquer la configuration des ressources personnalisées PriorityClass:

    $ oc apply -f myPriorityClass.yaml
  3. Créez une ressource personnalisée MetalLB, telle que MetalLBPodConfig.yaml, pour spécifier les valeurs priorityClassName et podAffinity:

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        priorityClassName: high-priority
        runtimeClassName: myclass
      speakerConfig:
        priorityClassName: high-priority
        runtimeClassName: myclass
      affinity:
          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
  4. Appliquer la configuration des ressources personnalisées MetalLB:

    $ oc apply -f MetalLBPodConfig.yaml

Vérification

  • Pour afficher la classe de priorité que vous avez attribuée aux pods dans un espace de noms, exécutez la commande suivante, en remplaçant <namespace> par votre espace de noms cible :

    $ oc get pods -n <namespace> -o custom-columns=NAME :.metadata.name,PRIORITY :.spec.priorityClassName
  • Pour vérifier que le planificateur a placé les pods conformément aux règles d'affinité des pods, affichez les métadonnées du nœud du pod en exécutant la commande suivante, en remplaçant <namespace> par votre espace de noms cible :

    $ oc get pod -o=custom-columns=NODE :.spec.nodeName,NAME :.metadata.name -n <namespace>

32.2.4.3. Configurer les limites de CPU des pods dans un déploiement MetalLB

Vous pouvez optionnellement assigner des limites de CPU aux pods controller et speaker en configurant la ressource personnalisée MetalLB. La définition de limites de CPU pour les modules controller ou speaker vous aide à gérer les ressources de calcul sur le nœud. Cela permet de s'assurer que tous les modules du nœud disposent des ressources de calcul nécessaires pour gérer les charges de travail et l'entretien du cluster.

Conditions préalables

  • Vous êtes connecté en tant qu'utilisateur avec des privilèges cluster-admin.
  • Vous avez installé l'opérateur MetalLB.

Procédure

  1. Créez un fichier de ressources personnalisé MetalLB, tel que CPULimits.yaml, afin de spécifier la valeur cpu pour les modules controller et speaker:

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        resources:
          limits:
            cpu: "200m"
      speakerConfig:
        resources:
          limits:
            cpu: "300m"
  2. Appliquer la configuration des ressources personnalisées MetalLB:

    $ oc apply -f CPULimits.yaml

Vérification

  • Pour afficher les ressources informatiques d'un module, exécutez la commande suivante, en remplaçant <pod_name> par votre module cible :

    oc describe pod <nom_du_pod>

32.2.4.4. Configurer une classe d'exécution de conteneur dans un déploiement MetalLB

Vous pouvez éventuellement affecter une classe d'exécution de conteneur aux modules controller et speaker en configurant la ressource personnalisée MetalLB. Par exemple, pour les charges de travail Windows, vous pouvez affecter une classe d'exécution Windows au module, qui utilise cette classe d'exécution pour tous les conteneurs du module.

Conditions préalables

  • Vous êtes connecté en tant qu'utilisateur avec des privilèges cluster-admin.
  • Vous avez installé l'opérateur MetalLB.

Procédure

  1. Créez une ressource personnalisée RuntimeClass, telle que myRuntimeClass.yaml, pour définir votre classe d'exécution :

    apiVersion: node.k8s.io/v1
    kind: RuntimeClass
    metadata:
      name: myclass
    handler: myconfiguration
  2. Appliquer la configuration des ressources personnalisées RuntimeClass:

    $ oc apply -f myRuntimeClass.yaml
  3. Créez une ressource personnalisée MetalLB, telle que MetalLBRuntime.yaml, pour spécifier la valeur runtimeClassName:

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        runtimeClassName: myclass
        annotations: 1
          controller: demo
      speakerConfig:
        runtimeClassName: myclass
        annotations: 2
          speaker: demo
    1 2
    Cet exemple utilise annotations pour ajouter des métadonnées telles que des informations sur la version de construction ou des informations sur les demandes d'extraction GitHub. Les annotations peuvent contenir des caractères non autorisés dans les étiquettes. Cependant, vous ne pouvez pas utiliser les annotations pour identifier ou sélectionner des objets.
  4. Appliquer la configuration des ressources personnalisées MetalLB:

    $ oc apply -f MetalLBRuntime.yaml

Vérification

  • Pour afficher la durée d'exécution d'un conteneur pour un module, exécutez la commande suivante :

    $ oc get pod -o custom-columns=NAME:metadata.name,STATUS:.status.phase,RUNTIME_CLASS:.spec.runtimeClassName

32.2.5. Ressources supplémentaires

32.2.6. Prochaines étapes

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.