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
-
Dans la console web d'OpenShift Container Platform, naviguez vers Operators
OperatorHub. 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.
- Sur la page Install Operator acceptez les valeurs par défaut et cliquez sur Install.
Vérification
Pour confirmer que l'installation a réussi :
-
Naviguez jusqu'à l'écran Operators
Installed Operators page. -
Vérifiez que l'Opérateur est installé dans l'espace de noms
openshift-operators
et que son statut estSucceeded
.
-
Naviguez jusqu'à l'écran Operators
Si l'opérateur n'est pas installé correctement, vérifiez l'état de l'opérateur et consultez les journaux :
-
Naviguez jusqu'à l'écran Operators
Installed Operators et vérifiez que la colonne Status
ne présente pas d'erreurs ou de défaillances. -
Naviguez jusqu'à l'écran Workloads
Pods et vérifiez les journaux de tous les pods du projet openshift-operators
qui signalent des problèmes.
-
Naviguez jusqu'à l'écran Operators
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
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
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
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
Créer un CR
Subscription
:Définissez le CR
Subscription
et enregistrez le fichier YAML, par exemplemetallb-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
.
Pour créer le CR
Subscription
, exécutez la commande suivante :$ oc create -f metallb-sub.yaml
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
.
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
NoteL'installation de l'opérateur peut prendre quelques secondes.
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
.
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.
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
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
Créez une ressource personnalisée
PriorityClass
, telle quemyPriorityClass.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
Appliquer la configuration des ressources personnalisées
PriorityClass
:$ oc apply -f myPriorityClass.yaml
Créez une ressource personnalisée
MetalLB
, telle queMetalLBPodConfig.yaml
, pour spécifier les valeurspriorityClassName
etpodAffinity
: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
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
Créez un fichier de ressources personnalisé
MetalLB
, tel queCPULimits.yaml
, afin de spécifier la valeurcpu
pour les modulescontroller
etspeaker
: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"
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
Créez une ressource personnalisée
RuntimeClass
, telle quemyRuntimeClass.yaml
, pour définir votre classe d'exécution :apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: myclass handler: myconfiguration
Appliquer la configuration des ressources personnalisées
RuntimeClass
:$ oc apply -f myRuntimeClass.yaml
Créez une ressource personnalisée
MetalLB
, telle queMetalLBRuntime.yaml
, pour spécifier la valeurruntimeClassName
: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.
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