OpenShift Container Platform

Utilisez l'API autoscaling/v2.

Spécifiez un nom pour cet objet autoscaler de pods horizontaux.

Indiquez la version API de l'objet à mettre à l'échelle :

Pour un objet Deployment, ReplicaSet, ou Statefulset, utilisez apps/v1.
Pour un ReplicationController, utilisez v1.
Pour un DeploymentConfig, utilisez apps.openshift.io/v1.

Spécifiez le type d'objet. L'objet doit être un Deployment, DeploymentConfig, ReplicaSet, ReplicationController, ou StatefulSet.

Indiquez le nom de l'objet à mettre à l'échelle. L'objet doit exister.

Spécifiez le nombre minimum de répliques lors de la réduction d'échelle.

Spécifiez le nombre maximum de répliques lors de la mise à l'échelle.

Utilisez le paramètre metrics pour l'utilisation de la mémoire.

Spécifiez memory pour l'utilisation de la mémoire.

Réglez le type sur AverageValue.

11

Spécifiez averageValue et une valeur de mémoire spécifique.

12

Facultatif : Spécifiez une politique de mise à l'échelle pour contrôler le taux de mise à l'échelle vers le haut ou vers le bas.

Pour mettre à l'échelle un pourcentage, créez un objet HorizontalPodAutoscaler similaire au suivant pour un objet existant :

apiVersion: autoscaling/v2 
kind: HorizontalPodAutoscaler
metadata:
  name: memory-autoscale 
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1 
    kind: Deployment 
    name: example 
  minReplicas: 1 
  maxReplicas: 10 
  metrics: 
  - type: Resource
    resource:
      name: memory 
      target:
        type: Utilization 
        averageUtilization: 50 
  behavior: 
    scaleUp:
      stabilizationWindowSeconds: 180
      policies:
      - type: Pods
        value: 6
        periodSeconds: 120
      - type: Percent
        value: 10
        periodSeconds: 120
      selectPolicy: Max

apiVersion: autoscaling/v2


kind: HorizontalPodAutoscaler
metadata:
  name: memory-autoscale


  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1


    kind: Deployment


    name: example


  minReplicas: 1


  maxReplicas: 10


  metrics:


  - type: Resource
    resource:
      name: memory


      target:
        type: Utilization


        averageUtilization: 50


  behavior:


    scaleUp:
      stabilizationWindowSeconds: 180
      policies:
      - type: Pods
        value: 6
        periodSeconds: 120
      - type: Percent
        value: 10
        periodSeconds: 120
      selectPolicy: Max

Copy to Clipboard

Toggle word wrap

Utilisez l'API autoscaling/v2.

Spécifiez un nom pour cet objet autoscaler de pods horizontaux.

Indiquez la version API de l'objet à mettre à l'échelle :

Pour un ReplicationController, utilisez v1.
Pour un DeploymentConfig, utilisez apps.openshift.io/v1.
Pour un objet Deployment, ReplicaSet, Statefulset, utilisez apps/v1.

Spécifiez le type d'objet. L'objet doit être un Deployment, DeploymentConfig, ReplicaSet, ReplicationController, ou StatefulSet.

Indiquez le nom de l'objet à mettre à l'échelle. L'objet doit exister.

Spécifiez le nombre minimum de répliques lors de la réduction d'échelle.

Spécifiez le nombre maximum de répliques lors de la mise à l'échelle.

Utilisez le paramètre metrics pour l'utilisation de la mémoire.

Spécifiez memory pour l'utilisation de la mémoire.

Régler sur Utilization.

11

Spécifiez averageUtilization et un objectif d'utilisation moyenne de la mémoire sur tous les pods, représenté en pourcentage de la mémoire demandée. Les pods cibles doivent avoir des demandes de mémoire configurées.

12

Facultatif : Spécifiez une politique de mise à l'échelle pour contrôler le taux de mise à l'échelle vers le haut ou vers le bas.

Créer le pod autoscaler horizontal :

oc create -f <nom-de-fichier>.yaml

oc create -f <nom-de-fichier>.yaml

Copy to Clipboard

Toggle word wrap

Par exemple :

oc create -f hpa.yaml

$ oc create -f hpa.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

Copy to Clipboard

Toggle word wrap

Vérifiez que le pod horizontal autoscaler a été créé :

oc get hpa hpa-resource-metrics-memory

$ oc get hpa hpa-resource-metrics-memory

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                          REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
hpa-resource-metrics-memory   Deployment/example   2441216/500Mi   1         10        1          20m

NAME                          REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
hpa-resource-metrics-memory   Deployment/example   2441216/500Mi   1         10        1          20m

Copy to Clipboard

Toggle word wrap

oc describe hpa hpa-resource-metrics-memory

$ oc describe hpa hpa-resource-metrics-memory

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:                        hpa-resource-metrics-memory
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
Reference:                   Deployment/example
Metrics:                     ( current / target )
  resource memory on pods:   2441216 / 500Mi
Min replicas:                1
Max replicas:                10
ReplicationController pods:  1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type     Reason                   Age                 From                       Message
  ----     ------                   ----                ----                       -------
  Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target

Name:                        hpa-resource-metrics-memory
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
Reference:                   Deployment/example
Metrics:                     ( current / target )
  resource memory on pods:   2441216 / 500Mi
Min replicas:                1
Max replicas:                10
ReplicationController pods:  1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type     Reason                   Age                 From                       Message
  ----     ------                   ----                ----                       -------
  Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target

Copy to Clipboard

Toggle word wrap

2.4.8. Comprendre les conditions d'état du pod autoscaler horizontal à l'aide de la CLI
Copier lien

Vous pouvez utiliser les conditions d'état définies pour déterminer si l'autoscaler de pods horizontaux (HPA) est capable ou non de se mettre à l'échelle et s'il est actuellement limité de quelque manière que ce soit.

Les conditions d'état HPA sont disponibles avec la version v2 de l'API de mise à l'échelle automatique.

L'APH répond par les états suivants :

La condition AbleToScale indique si HPA est en mesure de récupérer et de mettre à jour les mesures, et si des conditions liées au backoff risquent d'empêcher la mise à l'échelle.
- Une condition True indique que la mise à l'échelle est autorisée.
- Une condition False indique que la mise à l'échelle n'est pas autorisée pour la raison spécifiée.
La condition ScalingActive indique si le HPA est activé (par exemple, le nombre de répliques de la cible n'est pas nul) et s'il est en mesure de calculer les mesures souhaitées.
- Une condition True indique que les mesures fonctionnent correctement.
- Une condition False indique généralement un problème de récupération des données.

La condition ScalingLimited indique que l'échelle souhaitée a été plafonnée par le maximum ou le minimum de l'échelle automatique du pod horizontal.

Une condition True indique que vous devez augmenter ou diminuer le nombre minimum ou maximum de répliques afin de procéder à une mise à l'échelle.

La condition False indique que la mise à l'échelle demandée est autorisée.

oc describe hpa cm-test

$ oc describe hpa cm-test

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions: 
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:

Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:


  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:

Copy to Clipboard

Toggle word wrap

1: Les messages d'état de l'autoscaler du pod horizontal.

Voici un exemple d'un module qui ne peut pas être mis à l'échelle :

Exemple de sortie

Conditions:
  Type         Status  Reason          Message
  ----         ------  ------          -------
  AbleToScale  False   FailedGetScale  the HPA controller was unable to get the target's current scale: no matches for kind "ReplicationController" in group "apps"
Events:
  Type     Reason          Age               From                       Message
  ----     ------          ----              ----                       -------
  Warning  FailedGetScale  6s (x3 over 36s)  horizontal-pod-autoscaler  no matches for kind "ReplicationController" in group "apps"

Conditions:
  Type         Status  Reason          Message
  ----         ------  ------          -------
  AbleToScale  False   FailedGetScale  the HPA controller was unable to get the target's current scale: no matches for kind "ReplicationController" in group "apps"
Events:
  Type     Reason          Age               From                       Message
  ----     ------          ----              ----                       -------
  Warning  FailedGetScale  6s (x3 over 36s)  horizontal-pod-autoscaler  no matches for kind "ReplicationController" in group "apps"

Copy to Clipboard

Toggle word wrap

Voici un exemple de pod qui n'a pas pu obtenir les métriques nécessaires à la mise à l'échelle :

Exemple de sortie

Conditions:
  Type                  Status    Reason                    Message
  ----                  ------    ------                    -------
  AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
  ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API

Conditions:
  Type                  Status    Reason                    Message
  ----                  ------    ------                    -------
  AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
  ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API

Copy to Clipboard

Toggle word wrap

Voici un exemple de pod où l'autoscaling demandé était inférieur aux minimums requis :

Exemple de sortie

Conditions:
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range

Conditions:
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range

Copy to Clipboard

Toggle word wrap

2.4.8.1. Visualisation des conditions d'état des pods horizontaux autoscaler à l'aide de la CLI
Copier lien

Vous pouvez visualiser les conditions d'état définies sur un pod par le pod autoscaler horizontal (HPA).

Note

Les conditions d'état de l'autoscaler de pods horizontaux sont disponibles avec la version v2 de l'API d'autoscaling.

Conditions préalables

oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>

Copy to Clipboard

Toggle word wrap

Procédure

Pour afficher les conditions d'état d'un module, utilisez la commande suivante avec le nom du module :

oc describe hpa <pod-name> $ oc describe hpa <pod-name>

oc describe hpa <pod-name> $ oc describe hpa <pod-name>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc describe hpa cm-test

$ oc describe hpa cm-test

Copy to Clipboard

Toggle word wrap

Les conditions apparaissent dans le champ Conditions de la sortie.

Exemple de sortie

Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions: 
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range

Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:


  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range

Copy to Clipboard

Toggle word wrap

2.5. Mise à l'échelle automatique des pods en fonction de mesures personnalisées
Copier lien

En tant que développeur, vous pouvez utiliser le custom metrics autoscaler pour spécifier comment OpenShift Container Platform doit automatiquement augmenter ou diminuer le nombre de pods pour un déploiement, un stateful set, une ressource personnalisée ou un job basé sur des métriques personnalisées qui ne sont pas basées uniquement sur le CPU ou la mémoire.

L'opérateur Custom Metrics Autoscaler pour Red Hat OpenShift est un opérateur optionnel, basé sur Kubernetes Event Driven Autoscaler (KEDA), qui permet aux charges de travail d'être mises à l'échelle en utilisant des sources de métriques supplémentaires autres que les métriques de pod.

Note

L'autoscaler de métriques personnalisées ne prend actuellement en charge que les métriques Prometheus, CPU, mémoire et Apache Kafka.

Important

L'autoscaler de métriques personnalisé est une fonctionnalité d'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 sur le plan 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.

2.5.1. Notes de mise à jour de Custom Metrics Autoscaler Operator
Copier lien

Les notes de mise à jour de Custom Metrics Autoscaler Operator pour Red Hat Openshift décrivent les nouvelles fonctionnalités et améliorations, les fonctionnalités obsolètes et les problèmes connus.

Le Custom Metrics Autoscaler Operator utilise l'Event Driven Autoscaler (KEDA) basé sur Kubernetes et est construit sur le pod autoscaler horizontal (HPA) d'OpenShift Container Platform.

Note

Custom Metrics Autoscaler Operator pour Red Hat OpenShift est fourni en tant que composant installable, avec un cycle de publication distinct de celui de la plate-forme OpenShift Container Platform. La politique de cycle de vie de Red Hat OpenShift Container Platform décrit la compatibilité des versions.

2.5.1.1. Versions prises en charge
Copier lien

Le tableau suivant définit les versions de Custom Metrics Autoscaler Operator pour chaque version d'OpenShift Container Platform.

Expand

Version	Version d'OpenShift Container Platform	Disponibilité générale
2.8.2-174	4.12	Avant-première technologique
2.8.2-174	4.11	Avant-première technologique
2.8.2-174	4.10	Avant-première technologique

2.5.1.2. Notes de publication de Custom Metrics Autoscaler Operator 2.8.2-174
Copier lien

Cette version de Custom Metrics Autoscaler Operator 2.8.2-174 fournit de nouvelles fonctionnalités et des corrections de bugs pour l'exécution de l'Operator dans un cluster OpenShift Container Platform. Les composants de Custom Metrics Autoscaler Operator 2.8.2-174 ont été publiés dans RHEA-2023:1683.

Important

Le Custom Metrics Autoscaler Operator est actuellement une fonctionnalité en avant-première technologique.

2.5.1.2.1. Nouvelles fonctionnalités et améliorations
Copier lien

2.5.1.2.1.1. Aide à la mise à niveau de l'opérateur
Copier lien

Vous pouvez désormais mettre à niveau une version antérieure de l'opérateur Custom Metrics Autoscaler. Voir "Changer le canal de mise à jour d'un opérateur" dans "Ressources supplémentaires" pour plus d'informations sur la mise à niveau d'un opérateur.

2.5.1.2.1.2. soutien indispensable
Copier lien

Vous pouvez désormais collecter des données sur l'opérateur Custom Metrics Autoscaler et ses composants en utilisant l'outil OpenShift Container Platform must-gather. Actuellement, le processus d'utilisation de l'outil must-gather avec Custom Metrics Autoscaler est différent de celui des autres opérateurs. Voir "Gathering debugging data in the \N- Additional resources\N" (Collecte de données de débogage dans les ressources supplémentaires) pour plus d'informations.

2.5.1.3. Notes de publication de Custom Metrics Autoscaler Operator 2.8.2
Copier lien

Cette version de Custom Metrics Autoscaler Operator 2.8.2 apporte de nouvelles fonctionnalités et des corrections de bugs pour l'exécution de l'Operator dans un cluster OpenShift Container Platform. Les composants de Custom Metrics Autoscaler Operator 2.8.2 ont été publiés dans la RHSA-2023:1042.

Important

Le Custom Metrics Autoscaler Operator est actuellement une fonctionnalité en avant-première technologique.

2.5.1.3.1. Nouvelles fonctionnalités et améliorations
Copier lien

2.5.1.3.1.1. Enregistrement des audits
Copier lien

Vous pouvez désormais rassembler et afficher les journaux d'audit de Custom Metrics Autoscaler Operator et de ses composants associés. Les journaux d'audit sont des ensembles chronologiques d'enregistrements relatifs à la sécurité qui documentent la séquence des activités qui ont affecté le système par des utilisateurs individuels, des administrateurs ou d'autres composants du système.

2.5.1.3.1.2. Faire évoluer les applications en fonction des mesures d'Apache Kafka
Copier lien

Vous pouvez maintenant utiliser le KEDA Apache kafka trigger/scaler pour mettre à l'échelle des déploiements basés sur un sujet Apache Kafka.

Important

L'autoscaling basé sur les métriques Apache Kafka est une fonctionnalité Technology Preview (TP) dans toutes les versions TP de Custom Metrics Autoscaler et dans la version Custom Metrics Autoscaler General Availability.

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 sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production.

2.5.1.3.1.3. Mise à l'échelle des applications en fonction des paramètres de l'unité centrale
Copier lien

Vous pouvez désormais utiliser le déclencheur/échelle de CPU de KEDA pour échelonner les déploiements en fonction des métriques de CPU.

2.5.1.3.1.4. Mise à l'échelle des applications en fonction des mesures de la mémoire
Copier lien

Vous pouvez désormais utiliser le déclencheur/échelle de mémoire KEDA pour échelonner les déploiements en fonction des mesures de mémoire.

Ressources supplémentaires

2.5.2. Comprendre l'autoscaler de métriques personnalisées
Copier lien

L'opérateur Autoscaler Custom Metrics fait évoluer vos pods vers le haut ou vers le bas en fonction de mesures externes personnalisées provenant d'applications spécifiques. Vos autres applications continuent d'utiliser d'autres méthodes de mise à l'échelle. Vous configurez triggers, également appelé scalers, qui est la source d'événements et de métriques que l'autoscaler de métriques personnalisées utilise pour déterminer comment procéder à la mise à l'échelle. L'autoscaler de métriques personnalisées utilise une API de métriques pour convertir les métriques externes en une forme utilisable par OpenShift Container Platform. Le custom metrics autoscaler crée un pod autoscaler horizontal (HPA) qui effectue la mise à l'échelle réelle.

Pour utiliser l'autoscaler de métriques personnalisées, vous devez créer un objet ScaledObject ou ScaledJob, qui est une ressource personnalisée (CR) définissant les métadonnées de mise à l'échelle. Vous spécifiez le déploiement ou le travail à mettre à l'échelle, la source des métriques à mettre à l'échelle (déclencheur) et d'autres paramètres tels que les nombres minimum et maximum de réplicas autorisés.

Note

Vous ne pouvez créer qu'un seul objet ou travail mis à l'échelle pour chaque charge de travail que vous souhaitez mettre à l'échelle. Vous ne pouvez pas non plus utiliser un objet ou un travail mis à l'échelle et le pod autoscaler horizontal (HPA) sur la même charge de travail.

Contrairement au HPA, l'autoscaler de métriques personnalisé peut s'adapter à zéro. Si vous définissez la valeur minReplicaCount dans le Custom Metrics Autoscaler CR sur 0, le Custom Metrics Autoscaler met à l'échelle la charge de travail de 1 à 0 réplica ou de 0 à 1 réplica. C'est ce qu'on appelle activation phase. Après avoir mis à l'échelle jusqu'à 1 réplica, le HPA prend le contrôle de la mise à l'échelle. C'est ce qu'on appelle scaling phase.

Certains déclencheurs permettent de modifier le nombre de répliques mises à l'échelle par l'autoscaler de métriques de cluster. Dans tous les cas, le paramètre permettant de configurer la phase d'activation utilise toujours la même phrase, préfixée par activation. Par exemple, si le paramètre threshold configure la mise à l'échelle, activationThreshold configure l'activation. La configuration des phases d'activation et de mise à l'échelle vous offre une plus grande flexibilité dans vos politiques de mise à l'échelle. Par exemple, vous pouvez configurer une phase d'activation plus élevée pour empêcher la mise à l'échelle vers le haut ou vers le bas si la métrique est particulièrement basse.

La valeur d'activation est plus prioritaire que la valeur de mise à l'échelle en cas de décisions différentes pour chacune d'entre elles. Par exemple, si threshold est défini sur 10 et activationThreshold sur 50, si la métrique indique 40, le scaler n'est pas actif et les pods sont mis à l'échelle à zéro, même si l'APH nécessite 4 instances.

Vous pouvez vérifier que la mise à l'échelle automatique a eu lieu en examinant le nombre de pods dans votre ressource personnalisée ou en examinant les journaux de l'opérateur Autoscaler de Custom Metrics à la recherche de messages similaires à ceux qui suivent :

Successfully set ScaleTarget replica count

Successfully set ScaleTarget replica count

Copy to Clipboard

Toggle word wrap

Successfully updated ScaleTarget

Successfully updated ScaleTarget

Copy to Clipboard

Toggle word wrap

Vous pouvez interrompre temporairement la mise à l'échelle automatique d'un objet de charge de travail, si nécessaire. Par exemple, vous pouvez interrompre la mise à l'échelle automatique avant d'effectuer la maintenance du cluster.

2.5.3. Installation de l'autoscaler de métriques personnalisé
Copier lien

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Custom Metrics Autoscaler.

L'installation crée cinq CRD :

ClusterTriggerAuthentication
KedaController
ScaledJob
ScaledObject
TriggerAuthentication

Conditions préalables

Si vous utilisez la communauté KEDA :
- Désinstallez la communauté KEDA. Vous ne pouvez pas exécuter à la fois KEDA et l'autoscaler de métriques personnalisé sur le même cluster OpenShift Container Platform.
- Supprimez les définitions de ressources personnalisées de KEDA 1.x en exécutant les commandes suivantes :
  $ oc delete crd scaledobjects.keda.k8s.io
  Copy to Clipboard Toggle word wrap
  $ oc delete crd triggerauthentications.keda.k8s.io
  Copy to Clipboard Toggle word wrap

Procédure

Dans la console Web OpenShift Container Platform, cliquez sur Operators → OperatorHub.
Choisissez Custom Metrics Autoscaler dans la liste des opérateurs disponibles et cliquez sur Install.
Sur la page Install Operator, assurez-vous que l'option All namespaces on the cluster (default) est sélectionnée pour Installation Mode. Cela permet d'installer l'opérateur dans tous les espaces de noms.
Assurez-vous que l'espace de noms openshift-keda est sélectionné pour Installed Namespace. OpenShift Container Platform crée l'espace de noms, s'il n'est pas présent dans votre cluster.
Cliquez sur Install.
Vérifiez l'installation en listant les composants de Custom Metrics Autoscaler Operator :
1. Navigate to Workloads → Pods.
2. Sélectionnez le projet openshift-keda dans le menu déroulant et vérifiez que le module custom-metrics-autoscaler-operator-* est en cours d'exécution.
3. Naviguez jusqu'à Workloads → Deployments pour vérifier que le déploiement custom-metrics-autoscaler-operator est en cours.

Facultatif : Vérifiez l'installation dans le CLI OpenShift à l'aide des commandes suivantes :

oc get all -n openshift-keda

$ oc get all -n openshift-keda

Copy to Clipboard

Toggle word wrap

Le résultat ressemble à ce qui suit :

Exemple de sortie

NAME                                                      READY   STATUS    RESTARTS   AGE
pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m

NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m

NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

NAME                                                      READY   STATUS    RESTARTS   AGE
pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m

NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m

NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

Copy to Clipboard

Toggle word wrap

Installez la ressource personnalisée KedaController, qui crée les CRD nécessaires :
1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → Installed Operators.
2. Cliquez sur Custom Metrics Autoscaler.
3. Sur la page Operator Details, cliquez sur l'onglet KedaController.
4. Dans l'onglet KedaController, cliquez sur Create KedaController et modifiez le fichier.
  kind: KedaController apiVersion: keda.sh/v1alpha1 metadata: name: keda namespace: openshift-keda spec: watchNamespace: ''
  1
  operator: logLevel: info
  2
  logEncoder: console
  3
  metricsServer: logLevel: '0'
  4
  auditConfig:
  5
  logFormat: "json" logOutputVolumeClaim: "persistentVolumeClaimName" policy: rules: - level: Metadata omitStages: "RequestReceived" omitManagedFields: false lifetime: maxAge: "2" maxBackup: "1" maxSize: "50" serviceAccount: {}
  Copy to Clipboard Toggle word wrap
  1 1
  Spécifie les espaces de noms que l'autoscaler personnalisé doit surveiller. Saisissez les noms dans une liste séparée par des virgules. Omettre ou définir empty pour surveiller tous les espaces de noms. La valeur par défaut est empty.
  2
  Spécifie le niveau de verbosité des messages du journal de l'opérateur Autoscaler de Custom Metrics. Les valeurs autorisées sont debug, info, error. La valeur par défaut est info.
  3
  Spécifie le format de consignation des messages de consignation de l'opérateur Autoscaler de Custom Metrics. Les valeurs autorisées sont console ou json. La valeur par défaut est console.
  4
  Spécifie le niveau de journalisation pour le serveur Autoscaler Metrics de Custom Metrics. Les valeurs autorisées sont 0 pour info et 4 ou debug. La valeur par défaut est 0.
  5
  Active la journalisation des audits pour l'opérateur Custom Metrics Autoscaler et spécifie la politique d'audit à utiliser, comme décrit dans la section "Configuration de la journalisation des audits".
5. Cliquez sur Create pour créer le contrôleur KEDAC.

2.5.4. Comprendre les déclencheurs d'autoscaler de métriques personnalisées
Copier lien

Les déclencheurs, également appelés scalers, fournissent les métriques que l'opérateur Custom Metrics Autoscaler utilise pour mettre à l'échelle vos pods.

Note

L'autoscaler de métriques personnalisé ne prend actuellement en charge que les déclencheurs Prometheus, CPU, memory et Apache Kafka.

Vous utilisez une ressource personnalisée ScaledObject ou ScaledJob pour configurer des déclencheurs pour des objets spécifiques, comme décrit dans les sections suivantes.

2.5.4.1. Comprendre le déclencheur Prometheus
Copier lien

Vous pouvez mettre à l'échelle les pods en fonction des métriques Prometheus, qui peuvent utiliser la surveillance OpenShift Container Platform installée ou un serveur Prometheus externe comme source de métriques. Voir Additional resources pour plus d'informations sur les configurations requises pour utiliser la surveillance OpenShift Container Platform comme source de métriques.

Note

Si Prometheus prend des mesures de l'application que l'autoscaler de mesures personnalisé met à l'échelle, ne définissez pas les répliques minimales à 0 dans la ressource personnalisée. S'il n'y a pas de pods d'application, l'autoscaler de métriques personnalisé n'a pas de métriques à mettre à l'échelle.

Exemple d'objet mis à l'échelle avec une cible Prometheus

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
 ...
  triggers:
  - type: prometheus 
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 
      namespace: kedatest 
      metricName: http_requests_total 
      threshold: '5' 
      query: sum(rate(http_requests_total{job="test-app"}[1m])) 
      authModes: "basic" 
      cortexOrgID: my-org 
      ignoreNullValues: false 
      unsafeSsl: "false"

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
 ...
  triggers:
  - type: prometheus


    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092


      namespace: kedatest


      metricName: http_requests_total


      threshold: '5'


      query: sum(rate(http_requests_total{job="test-app"}[1m]))


      authModes: "basic"


      cortexOrgID: my-org


      ignoreNullValues: false


      unsafeSsl: "false"

Copy to Clipboard

Toggle word wrap

Spécifie Prometheus comme type de mesureur/déclencheur.

Spécifie l'adresse du serveur Prometheus. Cet exemple utilise la surveillance de OpenShift Container Platform.

Facultatif : Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle. Ce paramètre est obligatoire si la surveillance de OpenShift Container Platform sert de source pour les métriques.

Spécifie le nom permettant d'identifier la métrique dans l'API external.metrics.k8s.io. Si vous utilisez plusieurs déclencheurs, tous les noms de métriques doivent être uniques.

Spécifie la valeur pour laquelle la mise à l'échelle doit commencer.

Spécifie la requête Prometheus à utiliser.

Spécifie la méthode d'authentification à utiliser. Les scalers Prometheus prennent en charge l'authentification par support (bearer), l'authentification de base (basic) ou l'authentification TLS (tls). Vous configurez les paramètres d'authentification spécifiques dans un déclencheur d'authentification, comme indiqué dans la section suivante. Si nécessaire, vous pouvez également utiliser un secret.

Facultatif : Transmet l'en-tête X-Scope-OrgID au stockage multi-tenant Cortex ou Mimir pour Prometheus. Ce paramètre n'est requis qu'avec le stockage Prometheus multi-tenant, afin d'indiquer les données que Prometheus doit renvoyer.

Facultatif : Spécifie comment le déclencheur doit procéder si la cible Prometheus est perdue.

Si true, le déclencheur continue à fonctionner si la cible Prometheus est perdue. Il s'agit de la valeur par défaut.
Si false, le déclencheur renvoie une erreur si la cible Prometheus est perdue.

Facultatif : Indique si la vérification du certificat doit être ignorée. Par exemple, vous pouvez ignorer la vérification si vous utilisez des certificats auto-signés au niveau du point final Prometheus.

Si true, la vérification du certificat est effectuée.
Si false, la vérification du certificat n'est pas effectuée. Il s'agit de la valeur par défaut.

2.5.4.2. Comprendre le déclenchement de l'unité centrale
Copier lien

Vous pouvez dimensionner les pods en fonction des métriques de CPU. Ce déclencheur utilise les métriques de cluster comme source de métriques.

L'autoscaler de métriques personnalisées met à l'échelle les pods associés à un objet afin de maintenir l'utilisation du CPU que vous avez spécifiée. L'autoscaler augmente ou diminue le nombre de répliques entre les nombres minimum et maximum pour maintenir l'utilisation de l'UC spécifiée dans tous les pods. Le déclencheur de mémoire prend en compte l'utilisation de la mémoire de l'ensemble du module. Si le pod a plusieurs conteneurs, l'utilisation de la mémoire est la somme de tous les conteneurs.

Note

Ce déclencheur ne peut pas être utilisé avec la ressource personnalisée ScaledJob.
Lorsque vous utilisez un déclencheur de mémoire pour mettre un objet à l'échelle, l'objet n'est pas mis à l'échelle sur 0, même si vous utilisez plusieurs déclencheurs.

Exemple d'objet mis à l'échelle avec une cible CPU

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:

 ...

  triggers:
  - type: cpu 
    metricType: Utilization 
    metadata:
      value: "60" 
      containerName: "api"

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:

 ...

  triggers:
  - type: cpu


    metricType: Utilization


    metadata:
      value: "60"


      containerName: "api"

Copy to Clipboard

Toggle word wrap

Spécifie l'unité centrale comme type d'échelle/déclencheur.

Spécifie le type de métrique à utiliser, soit Utilization ou AverageValue.

Spécifie la valeur à partir de laquelle les actions de mise à l'échelle doivent être déclenchées :

Lorsque l'on utilise Utilization, la valeur cible est la moyenne des mesures de la ressource pour tous les pods concernés, représentée en pourcentage de la valeur demandée de la ressource pour les pods.
Lorsque l'on utilise AverageValue, la valeur cible est la moyenne des mesures de tous les pods concernés.

Facultatif. Spécifie un conteneur individuel à mettre à l'échelle, en fonction de l'utilisation de la mémoire de ce conteneur uniquement, plutôt que de l'ensemble du pod. Ici, seul le conteneur nommé api doit être mis à l'échelle.

2.5.4.3. Comprendre le déclenchement de la mémoire
Copier lien

Vous pouvez mettre à l'échelle les pods en fonction des métriques de mémoire. Ce déclencheur utilise les métriques de cluster comme source de métriques.

L'autoscaler de métriques personnalisées met à l'échelle les pods associés à un objet afin de maintenir l'utilisation moyenne de la mémoire que vous avez spécifiée. L'autoscaler augmente et diminue le nombre de réplicas entre les nombres minimum et maximum pour maintenir l'utilisation de la mémoire spécifiée dans tous les pods. Le déclencheur de mémoire prend en compte l'utilisation de la mémoire de l'ensemble du module. Si le pod possède plusieurs conteneurs, l'utilisation de la mémoire est la somme de tous les conteneurs.

Note

Ce déclencheur ne peut pas être utilisé avec la ressource personnalisée ScaledJob.
Lorsque vous utilisez un déclencheur de mémoire pour mettre un objet à l'échelle, l'objet n'est pas mis à l'échelle sur 0, même si vous utilisez plusieurs déclencheurs.

Exemple d'objet mis à l'échelle avec une cible de mémoire

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:

 ...

  triggers:
  - type: memory 
    metricType: Utilization 
    metadata:
      value: "60" 
      containerName: "api"

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:

 ...

  triggers:
  - type: memory


    metricType: Utilization


    metadata:
      value: "60"


      containerName: "api"

Copy to Clipboard

Toggle word wrap

Spécifie la mémoire comme type d'échelle/déclencheur.

Spécifie le type de métrique à utiliser, soit Utilization ou AverageValue.

Spécifie la valeur pour laquelle des actions de mise à l'échelle doivent être déclenchées :

Lorsque l'on utilise Utilization, la valeur cible est la moyenne des mesures de la ressource pour tous les pods concernés, représentée en pourcentage de la valeur demandée de la ressource pour les pods.
Lorsque l'on utilise AverageValue, la valeur cible est la moyenne des mesures de tous les pods concernés.

2.5.4.4. Comprendre le déclencheur Kafka
Copier lien

Vous pouvez mettre à l'échelle les pods en fonction d'un sujet Apache Kafka ou d'autres services qui prennent en charge le protocole Kafka. L'autoscaler de métriques personnalisées n'augmente pas le nombre de partitions Kafka, sauf si vous définissez le paramètre allowIdleConsumers sur true dans l'objet ou le travail mis à l'échelle.

Note

Si le nombre de groupes de consommateurs dépasse le nombre de partitions d'un thème, les groupes de consommateurs supplémentaires restent inactifs.

Pour éviter cela, le nombre de répliques est limité par défaut :

Le nombre de partitions sur un sujet, si un sujet est spécifié.
Le nombre de partitions de tous les thèmes du groupe de consommateurs, si aucun thème n'est spécifié.
Le site maxReplicaCount spécifié dans l'objet mis à l'échelle ou le travail mis à l'échelle CR.

Vous pouvez utiliser le paramètre allowIdleConsumers pour désactiver ces comportements par défaut.

Exemple d'objet mis à l'échelle avec une cible Kafka

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
 ...
  triggers:
  - type: kafka 
    metadata:
      topic: my-topic 
      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 
      consumerGroup: my-group 
      lagThreshold: '10' 
      activationLagThreshold 
      offsetResetPolicy: 'latest' 
      allowIdleConsumers: true 
      scaleToZeroOnInvalidOffset: false 
      excludePersistentLag: false 
      version: 1.0.0 
      partitionLimitation: '1,2,10-20,31'

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
 ...
  triggers:
  - type: kafka


    metadata:
      topic: my-topic


      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092


      consumerGroup: my-group


      lagThreshold: '10'


      activationLagThreshold


      offsetResetPolicy: 'latest'


      allowIdleConsumers: true


      scaleToZeroOnInvalidOffset: false


      excludePersistentLag: false


      version: 1.0.0


      partitionLimitation: '1,2,10-20,31'

Copy to Clipboard

Toggle word wrap

Spécifie Kafka comme type de scaler/déclencheur.

Spécifie le nom du sujet Kafka sur lequel Kafka traite le décalage.

Spécifie une liste de brokers Kafka séparés par des virgules à laquelle se connecter.

Spécifie le nom du groupe de consommateurs Kafka utilisé pour vérifier le décalage sur le sujet et traiter le lag correspondant.

Facultatif : Spécifie la valeur cible moyenne pour déclencher les actions de mise à l'échelle. La valeur par défaut est 5.

Facultatif : Spécifie la valeur cible pour la phase d'activation.

Facultatif : Spécifie la politique de réinitialisation du décalage Kafka pour le consommateur Kafka. Les valeurs disponibles sont : latest et earliest. La valeur par défaut est latest.

Facultatif : Indique si le nombre de répliques Kafka peut dépasser le nombre de partitions sur un sujet.

Si true, le nombre de répliques Kafka peut dépasser le nombre de partitions sur un sujet. Cela permet d'avoir des consommateurs Kafka inactifs.
Si false, le nombre de répliques Kafka ne peut pas dépasser le nombre de partitions sur un sujet. Il s'agit de la valeur par défaut.

Spécifie le comportement du déclencheur lorsqu'une partition Kafka n'a pas de décalage valide.

Si true, les consommateurs sont ramenés à zéro pour cette partition.
Si false, le scaler conserve un seul consommateur pour cette partition. Il s'agit de la valeur par défaut.

Facultatif : Spécifie si le déclencheur inclut ou exclut le décalage de partition pour les partitions dont le décalage actuel est le même que le décalage actuel du cycle d'interrogation précédent.

Si true, le mesureur exclut le décalage de partition dans ces partitions.
Si false, le déclencheur inclut tous les décalages de consommation dans toutes les partitions. Il s'agit de la valeur par défaut.

11

Facultatif : Spécifie la version de vos brokers Kafka. La valeur par défaut est 1.0.0.

12

Facultatif : Spécifie une liste d'ID de partitions séparées par des virgules pour étendre la mise à l'échelle. Si cette option est activée, seuls les ID répertoriés sont pris en compte lors du calcul du décalage. Par défaut, toutes les partitions sont prises en compte.

Ressources supplémentaires

Configurer l'autoscaler de métriques personnalisé pour utiliser la surveillance de OpenShift Container Platform

2.5.5. Comprendre les métriques personnalisées Autoscaler trigger authentications
Copier lien

Une authentification de déclenchement vous permet d'inclure des informations d'authentification dans un objet ou un travail de mise à l'échelle qui peut être utilisé par les conteneurs associés. Vous pouvez utiliser des authentifications de déclenchement pour transmettre des secrets OpenShift Container Platform, des mécanismes d'authentification de pods natifs de la plateforme, des variables d'environnement, etc.

Vous définissez un objet TriggerAuthentication dans le même espace de noms que l'objet que vous souhaitez mettre à l'échelle. Cette authentification de déclenchement ne peut être utilisée que par les objets de cet espace de noms.

Pour partager des informations d'identification entre des objets de plusieurs espaces de noms, vous pouvez également créer un objet ClusterTriggerAuthentication qui peut être utilisé dans tous les espaces de noms.

Les authentifications par déclenchement et les authentifications par déclenchement en grappe utilisent la même configuration. Toutefois, l'authentification par déclenchement de grappe nécessite un paramètre supplémentaire kind dans la référence d'authentification de l'objet mis à l'échelle.

Exemple : déclencher l'authentification avec un secret

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: secret-triggerauthentication
  namespace: my-namespace 
spec:
  secretTargetRef: 
  - parameter: user-name 
    name: my-secret 
    key: USER_NAME 
  - parameter: password
    name: my-secret
    key: USER_PASSWORD

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: secret-triggerauthentication
  namespace: my-namespace


spec:
  secretTargetRef:


  - parameter: user-name


    name: my-secret


    key: USER_NAME


  - parameter: password
    name: my-secret
    key: USER_PASSWORD

Copy to Clipboard

Toggle word wrap

1: Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.
2: Spécifie que l'authentification de ce déclencheur utilise un secret pour l'autorisation.
3: Spécifie le paramètre d'authentification à fournir en utilisant le secret.
4: Spécifie le nom du secret à utiliser.
5: Spécifie la clé du secret à utiliser avec le paramètre spécifié.

Exemple d'authentification par déclenchement de cluster avec un secret

kind: ClusterTriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata: 
  name: secret-cluster-triggerauthentication
spec:
  secretTargetRef: 
  - parameter: user-name 
    name: secret-name 
    key: USER_NAME 
  - parameter: user-password
    name: secret-name
    key: USER_PASSWORD

kind: ClusterTriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:


  name: secret-cluster-triggerauthentication
spec:
  secretTargetRef:


  - parameter: user-name


    name: secret-name


    key: USER_NAME


  - parameter: user-password
    name: secret-name
    key: USER_PASSWORD

Copy to Clipboard

Toggle word wrap

1: Notez qu'aucun espace de noms n'est utilisé avec un déclencheur d'authentification en grappe.
2: Spécifie que l'authentification de ce déclencheur utilise un secret pour l'autorisation.
3: Spécifie le paramètre d'authentification à fournir en utilisant le secret.
4: Spécifie le nom du secret à utiliser.
5: Spécifie la clé du secret à utiliser avec le paramètre spécifié.

Exemple de déclenchement de l'authentification avec un jeton

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: token-triggerauthentication
  namespace: my-namespace 
spec:
  secretTargetRef: 
  - parameter: bearerToken 
    name: my-token-2vzfq 
    key: token 
  - parameter: ca
    name: my-token-2vzfq
    key: ca.crt

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: token-triggerauthentication
  namespace: my-namespace


spec:
  secretTargetRef:


  - parameter: bearerToken


    name: my-token-2vzfq


    key: token


  - parameter: ca
    name: my-token-2vzfq
    key: ca.crt

Copy to Clipboard

Toggle word wrap

1: Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.
2: Spécifie que l'authentification de ce déclencheur utilise un secret pour l'autorisation.
3: Spécifie le paramètre d'authentification à fournir en utilisant le jeton.
4: Spécifie le nom du jeton à utiliser.
5: Spécifie la clé du jeton à utiliser avec le paramètre spécifié.

Exemple de déclenchement de l'authentification à l'aide d'une variable d'environnement

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: env-var-triggerauthentication
  namespace: my-namespace 
spec:
  env: 
  - parameter: access_key 
    name: ACCESS_KEY 
    containerName: my-container

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: env-var-triggerauthentication
  namespace: my-namespace


spec:
  env:


  - parameter: access_key


    name: ACCESS_KEY


    containerName: my-container

Copy to Clipboard

Toggle word wrap

1: Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.
2: Spécifie que ce déclencheur d'authentification utilise des variables d'environnement pour l'autorisation.
3: Spécifiez le paramètre à définir avec cette variable.
4: Indiquez le nom de la variable d'environnement.
5: Facultatif : Indiquez un conteneur qui nécessite une authentification. Le conteneur doit se trouver dans la même ressource que celle référencée par scaleTargetRef dans l'objet mis à l'échelle.

Exemple d'authentification par déclenchement avec des fournisseurs d'authentification de pods

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: pod-id-triggerauthentication
  namespace: my-namespace 
spec:
  podIdentity: 
    provider: aws-eks

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: pod-id-triggerauthentication
  namespace: my-namespace


spec:
  podIdentity:


    provider: aws-eks

Copy to Clipboard

Toggle word wrap

1: Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.
2: Spécifie que ce déclencheur d'authentification utilise une méthode d'authentification podale native pour l'autorisation.
3: Spécifie l'identité d'un pod. Les valeurs prises en charge sont none, azure, aws-eks ou aws-kiam. La valeur par défaut est none.

Ressources supplémentaires

Pour plus d'informations sur les secrets de OpenShift Container Platform, voir Fournir des données sensibles aux pods.

2.5.5.1. Utilisation des authentifications par déclenchement
Copier lien

Vous utilisez les authentifications de déclenchement et les authentifications de déclenchement de cluster en utilisant une ressource personnalisée pour créer l'authentification, puis en ajoutant une référence à un objet ou à un travail mis à l'échelle.

Conditions préalables

L'opérateur Custom Metrics Autoscaler doit être installé.

Si vous utilisez un secret, l'objet Secret doit exister, par exemple :

Exemple de secret

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  user-name: <base64_USER_NAME>
  password: <base64_USER_PASSWORD>

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  user-name: <base64_USER_NAME>
  password: <base64_USER_PASSWORD>

Copy to Clipboard

Toggle word wrap

Procédure

Créer l'objet TriggerAuthentication ou ClusterTriggerAuthentication.

Créer un fichier YAML qui définit l'objet :

Exemple : déclencher l'authentification avec un secret

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: prom-triggerauthentication
  namespace: my-namespace
spec:
  secretTargetRef:
  - parameter: user-name
    name: my-secret
    key: USER_NAME
  - parameter: password
    name: my-secret
    key: USER_PASSWORD

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: prom-triggerauthentication
  namespace: my-namespace
spec:
  secretTargetRef:
  - parameter: user-name
    name: my-secret
    key: USER_NAME
  - parameter: password
    name: my-secret
    key: USER_PASSWORD

Copy to Clipboard

Toggle word wrap

Créer l'objet TriggerAuthentication:
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Créer ou modifier un fichier YAML ScaledObject:

Exemple d'objet mis à l'échelle

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    name: example-deployment
  maxReplicaCount: 100
  minReplicaCount: 0
  pollingInterval: 30
  triggers:
  - authenticationRef:
    type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest # replace <NAMESPACE>
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "basic"
    - authenticationRef: 
        name: prom-triggerauthentication
      metadata:
        name: prom-triggerauthentication
      type: object
    - authenticationRef: 
        name: prom-cluster-triggerauthentication
        kind: ClusterTriggerAuthentication
      metadata:
        name: prom-cluster-triggerauthentication
      type: object

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    name: example-deployment
  maxReplicaCount: 100
  minReplicaCount: 0
  pollingInterval: 30
  triggers:
  - authenticationRef:
    type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest # replace <NAMESPACE>
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "basic"
    - authenticationRef:


        name: prom-triggerauthentication
      metadata:
        name: prom-triggerauthentication
      type: object
    - authenticationRef:


        name: prom-cluster-triggerauthentication
        kind: ClusterTriggerAuthentication
      metadata:
        name: prom-cluster-triggerauthentication
      type: object

Copy to Clipboard

Toggle word wrap

1: Facultatif : Spécifiez un déclencheur d'authentification.
2: Facultatif : Spécifiez une authentification de déclenchement de cluster. Vous devez inclure le paramètre kind: ClusterTriggerAuthentication.

Note

Il n'est pas nécessaire de spécifier à la fois une authentification de déclenchement de l'espace de noms et une authentification de déclenchement du cluster.

Créer l'objet. Par exemple :
```
oc apply -f <nom-de-fichier>
```
```
$ oc apply -f <nom-de-fichier>
```
Copy to Clipboard Toggle word wrap

2.5.6. Configurer l'autoscaler de métriques personnalisé pour utiliser la surveillance de OpenShift Container Platform
Copier lien

Vous pouvez utiliser la surveillance Prometheus de OpenShift Container Platform installée comme source pour les métriques utilisées par l'autoscaler de métriques personnalisé. Cependant, vous devez effectuer quelques configurations supplémentaires.

Note

Ces étapes ne sont pas nécessaires pour une source Prometheus externe.

Vous devez effectuer les tâches suivantes, décrites dans cette section :

Créer un compte de service pour obtenir un jeton.
Créer un rôle.
Ajoutez ce rôle au compte de service.
Référencer le jeton dans l'objet d'authentification du déclencheur utilisé par Prometheus.

Conditions préalables

La surveillance de OpenShift Container Platform doit être installée.
La surveillance des charges de travail définies par l'utilisateur doit être activée dans la surveillance de OpenShift Container Platform, comme décrit dans la section Creating a user-defined workload monitoring config map.
L'opérateur Custom Metrics Autoscaler doit être installé.

Procédure

Passez au projet contenant l'objet que vous souhaitez mettre à l'échelle :
```
oc project my-project
```
```
$ oc project my-project
```
Copy to Clipboard Toggle word wrap
Utilisez la commande suivante pour créer un compte de service, si votre cluster n'en possède pas :
```
oc create serviceaccount <service_account> $ oc create serviceaccount <service_account>
```
```
oc create serviceaccount <service_account> $ oc create serviceaccount <service_account>
```
Copy to Clipboard Toggle word wrap
où :
-YRFFGUNA_compte_de_service>
Spécifie le nom du compte de service.

Utilisez la commande suivante pour localiser le jeton attribué au compte de service :

oc describe serviceaccount <service_account> $ oc describe serviceaccount <service_account>

oc describe serviceaccount <service_account> $ oc describe serviceaccount <service_account>

Copy to Clipboard

Toggle word wrap

où :

-YRFFGUNA_compte_de_service>: Spécifie le nom du compte de service.

Exemple de sortie

Name:                thanos
Namespace:           my-project
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-nnwgj
Mountable secrets:   thanos-dockercfg-nnwgj
Tokens:              thanos-token-9g4n5 
Events:              <none>

Name:                thanos
Namespace:           my-project
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-nnwgj
Mountable secrets:   thanos-dockercfg-nnwgj
Tokens:              thanos-token-9g4n5


Events:              <none>

Copy to Clipboard

Toggle word wrap

1: Utilisez ce jeton dans l'authentification du déclencheur.

Créer un déclencheur d'authentification avec le jeton de compte de service :

Créez un fichier YAML similaire au suivant :

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
spec:
  secretTargetRef: 
  - parameter: bearerToken 
    name: thanos-token-9g4n5 
    key: token 
  - parameter: ca
    name: thanos-token-9g4n5
    key: ca.crt

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
spec:
  secretTargetRef:


  - parameter: bearerToken


    name: thanos-token-9g4n5


    key: token


  - parameter: ca
    name: thanos-token-9g4n5
    key: ca.crt

Copy to Clipboard

Toggle word wrap

1: Spécifie que cet objet utilise un secret pour l'autorisation.
2: Spécifie le paramètre d'authentification à fournir en utilisant le jeton.
3: Spécifie le nom du jeton à utiliser.
4: Spécifie la clé du jeton à utiliser avec le paramètre spécifié.

Créer l'objet CR :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Créer un rôle pour lire les métriques de Thanos :

Créez un fichier YAML avec les paramètres suivants :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

Copy to Clipboard

Toggle word wrap

Créer l'objet CR :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Créer un lien de rôle pour la lecture des métriques de Thanos :

Créez un fichier YAML similaire au suivant :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: thanos-metrics-reader 
  namespace: my-project 
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: thanos-metrics-reader
subjects:
- kind: ServiceAccount
  name: thanos 
  namespace: my-project

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: thanos-metrics-reader


  namespace: my-project


roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: thanos-metrics-reader
subjects:
- kind: ServiceAccount
  name: thanos


  namespace: my-project

Copy to Clipboard

Toggle word wrap

1: Spécifie le nom du rôle que vous avez créé.
2: Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.
3: Spécifie le nom du compte de service à lier au rôle.
4: Spécifie l'espace de noms de l'objet que vous souhaitez mettre à l'échelle.

Créer l'objet CR :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Vous pouvez maintenant déployer un objet ou un travail mis à l'échelle pour activer la mise à l'échelle automatique de votre application, comme décrit dans les sections suivantes. Pour utiliser la surveillance d'OpenShift Container Platform comme source, dans le déclencheur ou le scaler, spécifiez le type prometheus et utilisez https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 comme serverAddress.

Ressources supplémentaires

Pour plus d'informations sur l'activation de la surveillance des charges de travail définies par l'utilisateur, voir Création d'une carte de configuration pour la surveillance des charges de travail définies par l'utilisateur.

2.5.7. Mise en pause de l'autoscaler de métriques personnalisées pour une charge de travail
Copier lien

Vous pouvez interrompre la mise à l'échelle automatique d'une charge de travail, si nécessaire, en ajoutant l'annotation autoscaling.keda.sh/paused-replicas à l'autoscaler de métriques personnalisé pour cette charge de travail. L'autoscaler de métriques personnalisées met à l'échelle les réplicas pour cette charge de travail jusqu'à la valeur spécifiée et interrompt l'autoscaling jusqu'à ce que l'annotation soit supprimée.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "4"
...

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "4"
...

Copy to Clipboard

Toggle word wrap

Pour redémarrer l'autoscaling, modifiez le CR ScaledObject pour supprimer l'annotation.

Par exemple, vous pouvez vouloir mettre en pause l'autoscaling avant d'effectuer la maintenance du cluster ou pour éviter la pénurie de ressources en supprimant les charges de travail non critiques.

Procédure

Utilisez la commande suivante pour éditer le ScaledObject CR pour votre charge de travail :
```
oc edit ScaledObject scaledobject
```
```
$ oc edit ScaledObject scaledobject
```
Copy to Clipboard Toggle word wrap

Ajouter l'annotation autoscaling.keda.sh/paused-replicas avec n'importe quelle valeur :

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "4" 
  creationTimestamp: "2023-02-08T14:41:01Z"
  generation: 1
  name: scaledobject
  namespace: my-project
  resourceVersion: "65729"
  uid: f5aec682-acdf-4232-a783-58b5b82f5dd0

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "4"


  creationTimestamp: "2023-02-08T14:41:01Z"
  generation: 1
  name: scaledobject
  namespace: my-project
  resourceVersion: "65729"
  uid: f5aec682-acdf-4232-a783-58b5b82f5dd0

Copy to Clipboard

Toggle word wrap

1: Spécifie que l'opérateur de mise à l'échelle automatique des métriques personnalisées doit mettre à l'échelle les répliques jusqu'à la valeur spécifiée et arrêter la mise à l'échelle automatique.

2.5.8. Configuration de la journalisation des audits
Copier lien

Vous pouvez rassembler des journaux d'audit, qui sont un ensemble chronologique d'enregistrements relatifs à la sécurité documentant la séquence des activités qui ont affecté le système par des utilisateurs individuels, des administrateurs ou d'autres composants du système.

Par exemple, les journaux d'audit peuvent vous aider à comprendre d'où provient une demande d'autoscaling. Il s'agit d'une information clé lorsque les backends sont surchargés par des requêtes d'autoscaling effectuées par des applications utilisateur et que vous devez déterminer quelle est l'application qui pose problème. Vous pouvez configurer l'audit pour le Custom Metrics Autoscaler Operator en modifiant la ressource personnalisée KedaController. Les journaux sont envoyés à un fichier journal d'audit sur un volume sécurisé à l'aide d'une revendication de volume persistant dans le CR KedaController.

Conditions préalables

L'opérateur Custom Metrics Autoscaler doit être installé.

Procédure

Modifiez la ressource personnalisée KedaController pour ajouter la strophe auditConfig:
```
kind: KedaController
apiVersion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: openshift-keda
spec:
 ...
  metricsServer:
 ...
    auditConfig:
      logFormat: "json" 
      logOutputVolumeClaim: "pvc-audit-log" 
      policy:
        rules: 
        - level: Metadata
        omitStages: "RequestReceived" 
        omitManagedFields: false 
      lifetime: 
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
```
```
kind: KedaController
apiVersion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: openshift-keda
spec:
 ...
  metricsServer:
 ...
    auditConfig:
      logFormat: "json" 
```
1
```
      logOutputVolumeClaim: "pvc-audit-log" 
```
2
```
      policy:
        rules: 
```
3
```
        - level: Metadata
        omitStages: "RequestReceived" 
```
4
```
        omitManagedFields: false 
```
5
```
      lifetime: 
```
6
```
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
```
Copy to Clipboard Toggle word wrap
1
Spécifie le format de sortie du journal d'audit, soit legacy ou json.
2
Spécifie une revendication de volume persistant existante pour le stockage des données de journalisation. Toutes les demandes adressées au serveur API sont consignées dans cette revendication de volume persistant. Si vous laissez ce champ vide, les données du journal sont envoyées à stdout.
3
Spécifie quels événements doivent être enregistrés et quelles données doivent être incluses :
None: Ne pas enregistrer les événements.
Metadata: N'enregistrez que les métadonnées de la demande, telles que l'utilisateur, l'horodatage, etc. Ne pas enregistrer le texte de la demande et le texte de la réponse. Il s'agit de la valeur par défaut.
Request: Enregistrer uniquement les métadonnées et le texte de la demande, mais pas le texte de la réponse. Cette option ne s'applique pas aux demandes ne portant pas sur des ressources.
RequestResponse: Métadonnées de l'événement, texte de la demande et texte de la réponse. Cette option ne s'applique pas aux demandes ne portant pas sur des ressources.
4
Spécifie les étapes pour lesquelles aucun événement n'est créé.
5
Indique s'il faut omettre les champs gérés des corps de demande et de réponse dans le journal d'audit de l'API, soit true pour omettre les champs, soit false pour les inclure.
6
Spécifie la taille et la durée de vie des journaux d'audit.
maxAge: Nombre maximal de jours pendant lesquels les fichiers journaux d'audit doivent être conservés, sur la base de l'horodatage encodé dans leur nom de fichier.
maxBackup: Nombre maximal de fichiers journaux d'audit à conserver. La valeur 0 permet de conserver tous les fichiers journaux d'audit.
maxSize: Taille maximale en mégaoctets d'un fichier journal d'audit avant qu'il ne fasse l'objet d'une rotation.

Vérification

Consulter directement le fichier journal de l'audit :

Obtenir le nom du pod keda-metrics-apiserver-*:

oc get pod -n openshift-keda

oc get pod -n openshift-keda

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                                  READY   STATUS    RESTARTS   AGE
custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv   1/1     Running   0          8m20s
keda-metrics-apiserver-65c7cc44fd-rrl4r               1/1     Running   0          2m55s
keda-operator-776cbb6768-zpj5b                        1/1     Running   0          2m55s

NAME                                                  READY   STATUS    RESTARTS   AGE
custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv   1/1     Running   0          8m20s
keda-metrics-apiserver-65c7cc44fd-rrl4r               1/1     Running   0          2m55s
keda-operator-776cbb6768-zpj5b                        1/1     Running   0          2m55s

Copy to Clipboard

Toggle word wrap

Affichez les données du journal à l'aide d'une commande similaire à la suivante :

oc logs keda-metrics-apiserver-<hash>|grep -i metadata

oc logs keda-metrics-apiserver-<hash>|grep -i metadata

Copy to Clipboard

Toggle word wrap

1: Facultatif : vous pouvez utiliser la commande grep pour spécifier le niveau de journal à afficher : Metadata, Request, RequestResponse.

Par exemple :

oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata

$ oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata

Copy to Clipboard

Toggle word wrap

Exemple de sortie

 ...
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.26","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
 ...

 ...
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.26","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
 ...

Copy to Clipboard

Toggle word wrap

Vous pouvez également consulter un journal spécifique :

Utilisez une commande similaire à la suivante pour vous connecter au pod keda-metrics-apiserver-*:

oc rsh pod/keda-metrics-apiserver-<hash> -n openshift-keda

oc rsh pod/keda-metrics-apiserver-<hash> -n openshift-keda

Copy to Clipboard

Toggle word wrap

Par exemple :

oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-keda

$ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-keda

Copy to Clipboard

Toggle word wrap

Allez dans le répertoire /var/audit-policy/:
```
cd /var/audit-policy/
```
```
sh-4.4$ cd /var/audit-policy/
```
Copy to Clipboard Toggle word wrap
Liste des journaux disponibles :
```
ls
```
```
sh-4.4$ ls
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
log-2023.02.17-14:50  policy.yaml
```
```
log-2023.02.17-14:50  policy.yaml
```
Copy to Clipboard Toggle word wrap

Consulter le journal, si nécessaire :

cat <log_name>/<pvc_name>|grep -i <log_level>

sh-4.4$ cat <log_name>/<pvc_name>|grep -i <log_level>

Copy to Clipboard

Toggle word wrap

1: Facultatif : vous pouvez utiliser la commande grep pour spécifier le niveau de journal à afficher : Metadata, Request, RequestResponse.

Par exemple :

cat log-2023.02.17-14:50/pvc-audit-log|grep -i Request

sh-4.4$ cat log-2023.02.17-14:50/pvc-audit-log|grep -i Request

Copy to Clipboard

Toggle word wrap

Exemple de sortie

 ...
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}}
 ...

 ...
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}}
 ...

Copy to Clipboard

Toggle word wrap

Ressources supplémentaires

Configuration de la journalisation des audits

2.5.9. Collecte de données de débogage
Copier lien

Lorsque vous ouvrez un dossier d'assistance, il est utile de fournir des informations de débogage sur votre cluster à l'équipe d'assistance de Red Hat.

Il est recommandé de fournir les informations suivantes :

Données recueillies à l'aide de l'outil must-gather.
L'identifiant unique du cluster.

Vous pouvez utiliser l'outil must-gather pour collecter des données sur l'opérateur Custom Metrics Autoscaler et ses composants, notamment

L'espace de noms openshift-keda et ses objets enfants.
Les objets d'installation Custom Metric Autoscaler Operator.
Les objets Custom Metric Autoscaler Operator CRD.

La commande suivante exécute l'outil must-gather pour l'opérateur Custom Metrics Autoscaler :

oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

$ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

Copy to Clipboard

Toggle word wrap

Note

La commande standard d'OpenShift Container Platform must-gather, oc adm must-gather, ne collecte pas les données Custom Metrics Autoscaler Operator.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
L'OpenShift Container Platform CLI (oc) est installé.

Procédure

Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.
Note
Si votre cluster utilise un réseau restreint, vous devez prendre des mesures supplémentaires. Si votre registre miroir dispose d'une autorité de certification approuvée, vous devez d'abord ajouter cette dernière au cluster. Pour tous les clusters sur des réseaux restreints, vous devez importer l'image par défaut must-gather en tant que flux d'images en exécutant la commande suivante.
$ oc import-image is/must-gather -n openshift
Copy to Clipboard Toggle word wrap

Effectuez l'une des opérations suivantes :

Pour obtenir uniquement les données Custom Metrics Autoscaler Operator must-gather, utilisez la commande suivante :

oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

$ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

Copy to Clipboard

Toggle word wrap

L'image personnalisée de la commande must-gather est tirée directement des manifestes du paquet Operator, de sorte qu'elle fonctionne sur n'importe quel cluster où l'opérateur Custom Metric Autoscaler est disponible.

Pour collecter les données par défaut must-gather en plus des informations de l'opérateur Autoscaler de métriques personnalisées :

Utilisez la commande suivante pour obtenir l'image Custom Metrics Autoscaler Operator et la définir comme variable d'environnement :

IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
  -n openshift-marketplace \
  -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

$ IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
  -n openshift-marketplace \
  -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

Copy to Clipboard

Toggle word wrap

Utilisez le site oc adm must-gather avec l'image Custom Metrics Autoscaler Operator :

oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}

$ oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}

Copy to Clipboard

Toggle word wrap

Exemple 2.1. Exemple de sortie de collecte obligatoire pour le Custom Metric Autoscaler :

└── openshift-keda
    ├── apps
    │   ├── daemonsets.yaml
    │   ├── deployments.yaml
    │   ├── replicasets.yaml
    │   └── statefulsets.yaml
    ├── apps.openshift.io
    │   └── deploymentconfigs.yaml
    ├── autoscaling
    │   └── horizontalpodautoscalers.yaml
    ├── batch
    │   ├── cronjobs.yaml
    │   └── jobs.yaml
    ├── build.openshift.io
    │   ├── buildconfigs.yaml
    │   └── builds.yaml
    ├── core
    │   ├── configmaps.yaml
    │   ├── endpoints.yaml
    │   ├── events.yaml
    │   ├── persistentvolumeclaims.yaml
    │   ├── pods.yaml
    │   ├── replicationcontrollers.yaml
    │   ├── secrets.yaml
    │   └── services.yaml
    ├── discovery.k8s.io
    │   └── endpointslices.yaml
    ├── image.openshift.io
    │   └── imagestreams.yaml
    ├── k8s.ovn.org
    │   ├── egressfirewalls.yaml
    │   └── egressqoses.yaml
    ├── keda.sh
    │   ├── kedacontrollers
    │   │   └── keda.yaml
    │   ├── scaledobjects
    │   │   └── example-scaledobject.yaml
    │   └── triggerauthentications
    │       └── example-triggerauthentication.yaml
    ├── monitoring.coreos.com
    │   └── servicemonitors.yaml
    ├── networking.k8s.io
    │   └── networkpolicies.yaml
    ├── openshift-keda.yaml
    ├── pods
    │   ├── custom-metrics-autoscaler-operator-58bd9f458-ptgwx
    │   │   ├── custom-metrics-autoscaler-operator
    │   │   │   └── custom-metrics-autoscaler-operator
    │   │   │       └── logs
    │   │   │           ├── current.log
    │   │   │           ├── previous.insecure.log
    │   │   │           └── previous.log
    │   │   └── custom-metrics-autoscaler-operator-58bd9f458-ptgwx.yaml
    │   ├── custom-metrics-autoscaler-operator-58bd9f458-thbsh
    │   │   └── custom-metrics-autoscaler-operator
    │   │       └── custom-metrics-autoscaler-operator
    │   │           └── logs
    │   ├── keda-metrics-apiserver-65c7cc44fd-6wq4g
    │   │   ├── keda-metrics-apiserver
    │   │   │   └── keda-metrics-apiserver
    │   │   │       └── logs
    │   │   │           ├── current.log
    │   │   │           ├── previous.insecure.log
    │   │   │           └── previous.log
    │   │   └── keda-metrics-apiserver-65c7cc44fd-6wq4g.yaml
    │   └── keda-operator-776cbb6768-fb6m5
    │       ├── keda-operator
    │       │   └── keda-operator
    │       │       └── logs
    │       │           ├── current.log
    │       │           ├── previous.insecure.log
    │       │           └── previous.log
    │       └── keda-operator-776cbb6768-fb6m5.yaml
    ├── policy
    │   └── poddisruptionbudgets.yaml
    └── route.openshift.io
        └── routes.yaml

└── openshift-keda
    ├── apps
    │   ├── daemonsets.yaml
    │   ├── deployments.yaml
    │   ├── replicasets.yaml
    │   └── statefulsets.yaml
    ├── apps.openshift.io
    │   └── deploymentconfigs.yaml
    ├── autoscaling
    │   └── horizontalpodautoscalers.yaml
    ├── batch
    │   ├── cronjobs.yaml
    │   └── jobs.yaml
    ├── build.openshift.io
    │   ├── buildconfigs.yaml
    │   └── builds.yaml
    ├── core
    │   ├── configmaps.yaml
    │   ├── endpoints.yaml
    │   ├── events.yaml
    │   ├── persistentvolumeclaims.yaml
    │   ├── pods.yaml
    │   ├── replicationcontrollers.yaml
    │   ├── secrets.yaml
    │   └── services.yaml
    ├── discovery.k8s.io
    │   └── endpointslices.yaml
    ├── image.openshift.io
    │   └── imagestreams.yaml
    ├── k8s.ovn.org
    │   ├── egressfirewalls.yaml
    │   └── egressqoses.yaml
    ├── keda.sh
    │   ├── kedacontrollers
    │   │   └── keda.yaml
    │   ├── scaledobjects
    │   │   └── example-scaledobject.yaml
    │   └── triggerauthentications
    │       └── example-triggerauthentication.yaml
    ├── monitoring.coreos.com
    │   └── servicemonitors.yaml
    ├── networking.k8s.io
    │   └── networkpolicies.yaml
    ├── openshift-keda.yaml
    ├── pods
    │   ├── custom-metrics-autoscaler-operator-58bd9f458-ptgwx
    │   │   ├── custom-metrics-autoscaler-operator
    │   │   │   └── custom-metrics-autoscaler-operator
    │   │   │       └── logs
    │   │   │           ├── current.log
    │   │   │           ├── previous.insecure.log
    │   │   │           └── previous.log
    │   │   └── custom-metrics-autoscaler-operator-58bd9f458-ptgwx.yaml
    │   ├── custom-metrics-autoscaler-operator-58bd9f458-thbsh
    │   │   └── custom-metrics-autoscaler-operator
    │   │       └── custom-metrics-autoscaler-operator
    │   │           └── logs
    │   ├── keda-metrics-apiserver-65c7cc44fd-6wq4g
    │   │   ├── keda-metrics-apiserver
    │   │   │   └── keda-metrics-apiserver
    │   │   │       └── logs
    │   │   │           ├── current.log
    │   │   │           ├── previous.insecure.log
    │   │   │           └── previous.log
    │   │   └── keda-metrics-apiserver-65c7cc44fd-6wq4g.yaml
    │   └── keda-operator-776cbb6768-fb6m5
    │       ├── keda-operator
    │       │   └── keda-operator
    │       │       └── logs
    │       │           ├── current.log
    │       │           ├── previous.insecure.log
    │       │           └── previous.log
    │       └── keda-operator-776cbb6768-fb6m5.yaml
    ├── policy
    │   └── poddisruptionbudgets.yaml
    └── route.openshift.io
        └── routes.yaml

Copy to Clipboard

Toggle word wrap

Créez un fichier compressé à partir du répertoire must-gather qui a été créé dans votre répertoire de travail. Par exemple, sur un ordinateur utilisant un système d'exploitation Linux, exécutez la commande suivante :
```
tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/
```
```
$ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 
```
1
Copy to Clipboard Toggle word wrap
1
Remplacez must-gather-local.5421342344627712289/ par le nom du répertoire.
Joignez le fichier compressé à votre demande d'assistance sur le portail client de Red Hat.

Ressources supplémentaires

2.5.10. Accès aux métriques de performance
Copier lien

L'opérateur Autoscaler Custom Metrics expose des mesures prêtes à l'emploi qu'il extrait du composant de surveillance du cluster. Vous pouvez interroger les mesures à l'aide du Prometheus Query Language (PromQL) pour analyser et diagnostiquer les problèmes. Toutes les mesures sont réinitialisées lorsque le pod contrôleur redémarre.

Vous pouvez accéder aux métriques et exécuter des requêtes en utilisant la console web d'OpenShift Container Platform.

Procédure

Sélectionnez la perspective Administrator dans la console web de OpenShift Container Platform.
Sélectionnez Observe → Metrics.
Pour créer une requête personnalisée, ajoutez votre requête PromQL au champ Expression.
Pour ajouter plusieurs requêtes, sélectionnez Add Query.

2.5.10.1. Métriques fournies
Copier lien

Le Custom Metrics Autoscaler Operator expose les métriques suivantes, que vous pouvez visualiser en utilisant la console web d'OpenShift Container Platform.

Expand

Tableau 2.2. Métriques personnalisées de l'opérateur Autoscaler
Nom de la métrique	Description
`keda_scaler_activity`	Indique si l'analyseur est actif ou inactif. Une valeur de `1` indique que le mesureur est actif ; une valeur de `0` indique que le mesureur est inactif.
`keda_scaler_metrics_value`	Valeur actuelle de la métrique de chaque scaler, utilisée par l'Horizontal Pod Autoscaler (HPA) dans le calcul de la moyenne cible.
`keda_scaler_metrics_latency`	Le temps de latence pour récupérer la métrique actuelle de chaque mesureur.
`keda_scaler_errors`	Le nombre d'erreurs qui se sont produites pour chaque mesureur.
`keda_scaler_errors_total`	Le nombre total d'erreurs rencontrées pour tous les scalers.
`keda_scaled_object_errors`	Le nombre d'erreurs qui se sont produites pour chaque objet mis à l'échelle.
`keda_resource_totals`	Nombre total de ressources personnalisées Custom Metrics Autoscaler dans chaque espace de noms pour chaque type de ressource personnalisée.
`keda_trigger_totals`	Le nombre total de déclencheurs par type de déclencheur.

Métriques personnalisées Métriques Autoscaler Admission webhook

Le webhook Custom Metrics Autoscaler Admission expose également les métriques Prometheus suivantes.

Expand

Nom de la métrique	Description
`keda_scaled_object_validation_total`	Le nombre de validations d'objets mis à l'échelle.
`keda_scaled_object_validation_errors`	Le nombre d'erreurs de validation.

2.5.11. Comprendre comment ajouter des autoscalers de métriques personnalisés
Copier lien

Pour ajouter un autoscaler de métriques personnalisé, créez une ressource personnalisée ScaledObject pour un déploiement, un ensemble avec état ou une ressource personnalisée. Créez une ressource personnalisée ScaledJob pour un travail.

2.5.11.1. Ajout d'un autoscaler de métriques personnalisé à une charge de travail
Copier lien

Vous pouvez créer un autoscaler de métriques personnalisé pour une charge de travail créée par un objet Deployment, StatefulSet ou custom resource.

Conditions préalables

L'opérateur Custom Metrics Autoscaler doit être installé.

Si vous utilisez un autoscaler de métriques personnalisé pour une mise à l'échelle basée sur le CPU ou la mémoire :

L'administrateur de votre cluster doit avoir correctement configuré les métriques du cluster. Vous pouvez utiliser la commande oc describe PodMetrics <pod-name> pour déterminer si les métriques sont configurées. Si les métriques sont configurées, la sortie est similaire à ce qui suit, avec le CPU et la mémoire affichés sous Usage.

oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>

Copy to Clipboard

Toggle word wrap

Les pods associés à l'objet que vous souhaitez mettre à l'échelle doivent inclure les limites de mémoire et de CPU spécifiées. Par exemple :

Exemple de spécification de pod

apiVersion: v1
kind: Pod
 ...
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

apiVersion: v1
kind: Pod
 ...
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

Copy to Clipboard

Toggle word wrap

Procédure

Créez un fichier YAML similaire au suivant. Seuls le nom <2>, le nom de l'objet <4> et le type d'objet <5> sont nécessaires :

Exemple d'objet mis à l'échelle

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "0" 
  name: scaledobject 
  namespace: my-namespace
spec:
  scaleTargetRef:
    apiVersion: apps/v1 
    name: example-deployment 
    kind: Deployment 
    envSourceContainerName: .spec.template.spec.containers[0] 
  cooldownPeriod:  200 
  maxReplicaCount: 100 
  minReplicaCount: 0 
  metricsServer: 
    auditConfig:
      logFormat: "json"
      logOutputVolumeClaim: "persistentVolumeClaimName"
      policy:
        rules:
        - level: Metadata
        omitStages: "RequestReceived"
        omitManagedFields: false
      lifetime:
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
  fallback: 
    failureThreshold: 3
    replicas: 6
  pollingInterval: 30 
  advanced:
    restoreToOriginalReplicaCount: false 
    horizontalPodAutoscalerConfig:
      name: keda-hpa-scale-down 
      behavior: 
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Percent
            value: 100
            periodSeconds: 15
  triggers:
  - type: prometheus 
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "basic"
  - authenticationRef: 
      name: prom-triggerauthentication
    metadata:
      name: prom-triggerauthentication
    type: object
  - authenticationRef: 
      name: prom-cluster-triggerauthentication
    metadata:
      name: prom-cluster-triggerauthentication
    type: object

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "0"


  name: scaledobject


  namespace: my-namespace
spec:
  scaleTargetRef:
    apiVersion: apps/v1


    name: example-deployment


    kind: Deployment


    envSourceContainerName: .spec.template.spec.containers[0]


  cooldownPeriod:  200


  maxReplicaCount: 100


  minReplicaCount: 0


  metricsServer:


    auditConfig:
      logFormat: "json"
      logOutputVolumeClaim: "persistentVolumeClaimName"
      policy:
        rules:
        - level: Metadata
        omitStages: "RequestReceived"
        omitManagedFields: false
      lifetime:
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
  fallback:


    failureThreshold: 3
    replicas: 6
  pollingInterval: 30


  advanced:
    restoreToOriginalReplicaCount: false


    horizontalPodAutoscalerConfig:
      name: keda-hpa-scale-down


      behavior:


        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Percent
            value: 100
            periodSeconds: 15
  triggers:
  - type: prometheus


    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "basic"
  - authenticationRef:


      name: prom-triggerauthentication
    metadata:
      name: prom-triggerauthentication
    type: object
  - authenticationRef:


      name: prom-cluster-triggerauthentication
    metadata:
      name: prom-cluster-triggerauthentication
    type: object

Copy to Clipboard

Toggle word wrap

1: Facultatif : Spécifie que l'opérateur Custom Metrics Autoscaler doit mettre à l'échelle les répliques jusqu'à la valeur spécifiée et arrêter la mise à l'échelle automatique, comme décrit dans la section "Mise en pause du Custom Metrics Autoscaler pour une charge de travail".
2: Spécifie un nom pour cet autoscaler de métriques personnalisé.
3: Facultatif : Spécifie la version API de la ressource cible. La valeur par défaut est apps/v1.
4: Spécifie le nom de l'objet que vous souhaitez mettre à l'échelle.
5: Spécifie que le site kind est Deployment, StatefulSet ou CustomResource.
6: Facultatif : Spécifie le nom du conteneur dans la ressource cible, à partir duquel l'autoscaler de métriques personnalisées obtient les variables d'environnement contenant les secrets, etc. La valeur par défaut est .spec.template.spec.containers[0].
7: Facultatif. Spécifie la période en secondes à attendre après le signalement du dernier déclencheur avant de ramener le déploiement à 0 si minReplicaCount est défini sur 0. La valeur par défaut est 300.
8: Facultatif : Spécifie le nombre maximum de répliques lors de la mise à l'échelle. La valeur par défaut est 100.
9: Facultatif : Spécifie le nombre minimum de répliques lors de la réduction d'échelle.
10: Facultatif : Spécifie les paramètres des journaux d'audit, comme décrit dans la section "Configuration de la journalisation des audits".
11: Facultatif : Spécifie le nombre de répliques à utiliser si un scaler ne parvient pas à obtenir les métriques de la source pendant le nombre de fois défini par le paramètre failureThreshold. Pour plus d'informations sur le comportement de repli, voir la documentation KEDA.
12: Facultatif : Spécifie l'intervalle en secondes pour vérifier chaque déclencheur. La valeur par défaut est 30.
13: Facultatif : Indique s'il faut ramener la ressource cible au nombre de répliques d'origine après la suppression de l'objet mis à l'échelle. La valeur par défaut est false, qui conserve le nombre de répliques tel qu'il est lorsque l'objet mis à l'échelle est supprimé.
14: Facultatif : Spécifie un nom pour le pod horizontal autoscaler. La valeur par défaut est keda-hpa-{scaled-object-name}.
15: Facultatif : Spécifie une politique de mise à l'échelle à utiliser pour contrôler le taux de mise à l'échelle des pods à la hausse ou à la baisse, comme décrit dans la section "Politiques de mise à l'échelle".
16: Spécifie le déclencheur à utiliser comme base pour la mise à l'échelle, comme décrit dans la section "Understanding the custom metrics autoscaler triggers" (Comprendre les déclencheurs d'autoscaler de métriques personnalisées). Cet exemple utilise la surveillance de OpenShift Container Platform.
17: Facultatif : Spécifie une authentification de déclenchement, comme décrit dans la section "Création d'une authentification de déclenchement autoscaler de métriques personnalisée".
18: Facultatif : Spécifie une authentification de déclenchement de cluster, comme décrit dans la section "Création d'une authentification de déclenchement autoscaler de métriques personnalisée".

Note

Il n'est pas nécessaire de spécifier à la fois une authentification de déclenchement de l'espace de noms et une authentification de déclenchement du cluster.

Créez l'autoscaler de métriques personnalisé :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Affichez la sortie de la commande pour vérifier que l'autoscaler de métriques personnalisé a été créé :

oc get scaledobject <scaled_object_name>

oc get scaledobject <scaled_object_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME            SCALETARGETKIND      SCALETARGETNAME        MIN   MAX   TRIGGERS     AUTHENTICATION               READY   ACTIVE   FALLBACK   AGE
scaledobject    apps/v1.Deployment   example-deployment     0     50    prometheus   prom-triggerauthentication   True    True     True       17s

NAME            SCALETARGETKIND      SCALETARGETNAME        MIN   MAX   TRIGGERS     AUTHENTICATION               READY   ACTIVE   FALLBACK   AGE
scaledobject    apps/v1.Deployment   example-deployment     0     50    prometheus   prom-triggerauthentication   True    True     True       17s

Copy to Clipboard

Toggle word wrap

Notez les champs suivants dans le résultat :

TRIGGERS: Indique le déclencheur, ou l'échelle, utilisé.
AUTHENTICATION: Indique le nom de l'authentification de déclenchement utilisée.
READY: Indique si l'objet mis à l'échelle est prêt à commencer la mise à l'échelle :
- Si True, l'objet mis à l'échelle est prêt.
- Si False, l'objet mis à l'échelle n'est pas prêt en raison d'un problème dans un ou plusieurs des objets que vous avez créés.
ACTIVE: Indique si la mise à l'échelle est en cours :
- Si True, il y a mise à l'échelle.
- Si False, la mise à l'échelle n'a pas lieu parce qu'il n'y a pas de métriques ou qu'il y a un problème dans un ou plusieurs des objets que vous avez créés.
FALLBACK: Indique si l'autoscaler de métriques personnalisé est capable d'obtenir des métriques de la source
- Si False, l'autoscaler de métriques personnalisées reçoit des métriques.
- Si True, l'autoscaler de métriques personnalisées reçoit des métriques parce qu'il n'y en a pas ou qu'il y a un problème dans un ou plusieurs des objets que vous avez créés.

Ressources supplémentaires

2.5.11.2. Ajout d'un autoscaler de métriques personnalisé à une tâche
Copier lien

Vous pouvez créer un autoscaler de métriques personnalisé pour n'importe quel objet Job.

Conditions préalables

L'opérateur Custom Metrics Autoscaler doit être installé.

Procédure

Créez un fichier YAML similaire au suivant :
```
kind: ScaledJob
apiVersion: keda.sh/v1alpha1
metadata:
  name: scaledjob
  namespace: my-namespace
spec:
  failedJobsHistoryLimit: 5
  jobTargetRef:
    activeDeadlineSeconds: 600 
    backoffLimit: 6 
    parallelism: 1 
    completions: 1 
    template:  
      metadata:
        name: pi
      spec:
        containers:
        - name: pi
          image: perl
          command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  maxReplicaCount: 100 
  pollingInterval: 30 
  successfulJobsHistoryLimit: 5 
  failedJobsHistoryLimit: 5 
  envSourceContainerName: 
  rolloutStrategy: gradual 
  scalingStrategy: 
    strategy: "custom"
    customScalingQueueLengthDeduction: 1
    customScalingRunningJobPercentage: "0.5"
    pendingPodConditions:
      - "Ready"
      - "PodScheduled"
      - "AnyOtherCustomPodCondition"
    multipleScalersCalculation : "max"
  triggers:
  - type: prometheus 
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "bearer"
  - authenticationRef: 
      name: prom-triggerauthentication
    metadata:
      name: prom-triggerauthentication
     type: object
  - authenticationRef: 
      name: prom-cluster-triggerauthentication
    metadata:
      name: prom-cluster-triggerauthentication
    type: object
```
```
kind: ScaledJob
apiVersion: keda.sh/v1alpha1
metadata:
  name: scaledjob
  namespace: my-namespace
spec:
  failedJobsHistoryLimit: 5
  jobTargetRef:
    activeDeadlineSeconds: 600 
```
1
```
    backoffLimit: 6 
```
2
```
    parallelism: 1 
```
3
```
    completions: 1 
```
4
```
    template:  
```
5
```
      metadata:
        name: pi
      spec:
        containers:
        - name: pi
          image: perl
          command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  maxReplicaCount: 100 
```
6
```
  pollingInterval: 30 
```
7
```
  successfulJobsHistoryLimit: 5 
```
8
```
  failedJobsHistoryLimit: 5 
```
9
```
  envSourceContainerName: 
```
10
```
  rolloutStrategy: gradual 
```
11
```
  scalingStrategy: 
```
12
```
    strategy: "custom"
    customScalingQueueLengthDeduction: 1
    customScalingRunningJobPercentage: "0.5"
    pendingPodConditions:
      - "Ready"
      - "PodScheduled"
      - "AnyOtherCustomPodCondition"
    multipleScalersCalculation : "max"
  triggers:
  - type: prometheus 
```
13
```
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "bearer"
  - authenticationRef: 
```
14
```
      name: prom-triggerauthentication
    metadata:
      name: prom-triggerauthentication
     type: object
  - authenticationRef: 
```
15
```
      name: prom-cluster-triggerauthentication
    metadata:
      name: prom-cluster-triggerauthentication
    type: object
```
Copy to Clipboard Toggle word wrap
1
Spécifie la durée maximale d'exécution du travail.
2
Spécifie le nombre de tentatives pour un travail. La valeur par défaut est 6.
3
Facultatif : Spécifie le nombre de répliques de pods qu'un travail doit exécuter en parallèle ; la valeur par défaut est 1.
Pour les travaux non parallèles, laissez le paramètre non défini. Si elle n'est pas définie, la valeur par défaut est 1.
4
Facultatif : Indique le nombre de pods terminés avec succès pour qu'un travail soit considéré comme terminé.
Pour les travaux non parallèles, laissez le paramètre non défini. Si elle n'est pas définie, la valeur par défaut est 1.
Pour les travaux parallèles avec un nombre d'achèvements fixe, indiquez le nombre d'achèvements.
Pour les travaux parallèles avec une file d'attente, laissez le paramètre non défini. Lorsqu'il n'est pas défini, la valeur par défaut est celle du paramètre parallelism.
5
Spécifie le modèle du module créé par le contrôleur.
6
Facultatif : Spécifie le nombre maximum de répliques lors de la mise à l'échelle. La valeur par défaut est 100.
7
Facultatif : Spécifie l'intervalle en secondes pour vérifier chaque déclencheur. La valeur par défaut est 30.
8
Facultatif : Spécifie le nombre de travaux terminés avec succès qui doivent être conservés. La valeur par défaut est 100.
9
Facultatif : Spécifie le nombre de travaux ayant échoué qui doivent être conservés. La valeur par défaut est 100.
10
Facultatif : Spécifie le nom du conteneur dans la ressource cible, à partir duquel l'autoscaler personnalisé obtient les variables d'environnement contenant les secrets, etc. La valeur par défaut est .spec.template.spec.containers[0].
11
Facultatif : Indique si les travaux existants sont interrompus lorsqu'un travail mis à l'échelle est mis à jour :
default: L'autoscaler met fin à un travail existant si le travail de mise à l'échelle qui lui est associé est mis à jour. L'autoscaler recrée le travail avec les dernières spécifications.
gradual: L'autoscaler ne met pas fin à un travail existant si le travail de mise à l'échelle qui lui est associé est mis à jour. L'autoscaler crée de nouveaux travaux avec les dernières spécifications.
12
Facultatif : Spécifie une stratégie de mise à l'échelle : default custom ou accurate. La valeur par défaut est default. Pour plus d'informations, voir le lien dans la section "Ressources supplémentaires" qui suit.
13
Spécifie le déclencheur à utiliser comme base pour la mise à l'échelle, comme décrit dans la section "Understanding the custom metrics autoscaler triggers" (Comprendre les déclencheurs d'autoscaler de mesures personnalisées).
14
Facultatif : Spécifie une authentification de déclenchement, comme décrit dans la section "Création d'une authentification de déclenchement autoscaler de métriques personnalisée".
15
Facultatif : Spécifie une authentification de déclenchement de cluster, comme décrit dans la section "Création d'une authentification de déclenchement autoscaler de métriques personnalisée".
Note
Il n'est pas nécessaire de spécifier à la fois une authentification de déclenchement de l'espace de noms et une authentification de déclenchement du cluster.
Créez l'autoscaler de métriques personnalisé :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Affichez la sortie de la commande pour vérifier que l'autoscaler de métriques personnalisé a été créé :

oc get scaledjob <scaled_job_name>

oc get scaledjob <scaled_job_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME        MAX   TRIGGERS     AUTHENTICATION              READY   ACTIVE    AGE
scaledjob   100   prometheus   prom-triggerauthentication  True    True      8s

NAME        MAX   TRIGGERS     AUTHENTICATION              READY   ACTIVE    AGE
scaledjob   100   prometheus   prom-triggerauthentication  True    True      8s

Copy to Clipboard

Toggle word wrap

Notez les champs suivants dans le résultat :

TRIGGERS: Indique le déclencheur, ou l'échelle, utilisé.
AUTHENTICATION: Indique le nom de l'authentification de déclenchement utilisée.
READY: Indique si l'objet mis à l'échelle est prêt à commencer la mise à l'échelle :
- Si True, l'objet mis à l'échelle est prêt.
- Si False, l'objet mis à l'échelle n'est pas prêt en raison d'un problème dans un ou plusieurs des objets que vous avez créés.
ACTIVE: Indique si la mise à l'échelle est en cours :
- Si True, il y a mise à l'échelle.
- Si False, la mise à l'échelle n'a pas lieu parce qu'il n'y a pas de métriques ou qu'il y a un problème dans un ou plusieurs des objets que vous avez créés.

Ressources supplémentaires

2.5.12. Désinstallation de l'opérateur Autoscaler de mesures personnalisées
Copier lien

Vous pouvez supprimer le Custom Metrics Autoscaler de votre cluster OpenShift Container Platform. Après avoir supprimé l'opérateur Custom Metrics Autoscaler, supprimez les autres composants associés à l'opérateur afin d'éviter tout problème potentiel.

Note

Vous devez d'abord supprimer la ressource personnalisée (CR) KedaController. Si vous ne supprimez pas spécifiquement la CR, OpenShift Container Platform peut se bloquer lorsque vous supprimez le projet openshift-keda. Si vous supprimez le Custom Metrics Autoscaler Operator avant de supprimer la CR, vous ne pourrez pas supprimer la CR.

Conditions préalables

L'opérateur Custom Metrics Autoscaler doit être installé.

Procédure

Dans la console web d'OpenShift Container Platform, cliquez sur Operators → Installed Operators.
Passez au projet openshift-keda.
Supprimer la ressource personnalisée KedaController.
1. Trouvez l'opérateur CustomMetricsAutoscaler et cliquez sur l'onglet KedaController.
2. Recherchez la ressource personnalisée, puis cliquez sur Delete KedaController.
3. Cliquez sur Uninstall.
Supprimez l'opérateur Autoscaler de métriques personnalisées :
1. Cliquez sur Operators → Installed Operators.
2. Trouvez l'opérateur CustomMetricsAutoscaler et cliquez sur le menu Options et sélectionnez Uninstall Operator.
3. Cliquez sur Uninstall.
Optionnel : Utilisez le CLI OpenShift pour supprimer les composants autoscaler des métriques personnalisées :
1. Supprimez les CRD de métriques personnalisées autoscaler :
  - clustertriggerauthentications.keda.sh
  - kedacontrollers.keda.sh
  - scaledjobs.keda.sh
  - scaledobjects.keda.sh
  - triggerauthentications.keda.sh
  $ oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.sh
  Copy to Clipboard Toggle word wrap
  La suppression des CRD supprime les rôles associés, les rôles de cluster et les liaisons de rôles. Toutefois, il se peut que quelques rôles de cluster doivent être supprimés manuellement.
2. Liste des rôles de cluster autoscaler de métriques personnalisées :
  $ oc get clusterrole | grep keda.sh
  Copy to Clipboard Toggle word wrap
3. Supprimez les rôles de cluster autoscaler de métriques personnalisées répertoriés. Par exemple :
  $ oc delete clusterrole.keda.sh-v1alpha1-admin
  Copy to Clipboard Toggle word wrap
4. Liste de toutes les liaisons de rôles de cluster autoscaler de métriques personnalisées :
  $ oc get clusterrolebinding | grep keda.sh
  Copy to Clipboard Toggle word wrap
5. Supprimez les liaisons de rôles de cluster autoscaler de métriques personnalisées répertoriées. Par exemple :
  $ oc delete clusterrolebinding.keda.sh-v1alpha1-admin
  Copy to Clipboard Toggle word wrap
Supprimez le projet custom metrics autoscaler :
```
oc delete project openshift-keda
```
```
$ oc delete project openshift-keda
```
Copy to Clipboard Toggle word wrap

Supprimez l'opérateur Autoscaler de métrique de cluster :

oc delete operator/openshift-custom-metrics-autoscaler-operator.openshift-keda

$ oc delete operator/openshift-custom-metrics-autoscaler-operator.openshift-keda

Copy to Clipboard

Toggle word wrap

2.6. Ajustez automatiquement les niveaux de ressources des pods grâce à l'autoscaler vertical de pods
Copier lien

Le Vertical Pod Autoscaler Operator (VPA) d'OpenShift Container Platform examine automatiquement les ressources historiques et actuelles de CPU et de mémoire pour les conteneurs dans les pods et peut mettre à jour les limites de ressources et les demandes en fonction des valeurs d'utilisation qu'il apprend. Le VPA utilise des ressources personnalisées individuelles (CR) pour mettre à jour tous les pods associés à un objet de charge de travail, tel que Deployment, DeploymentConfig, StatefulSet, Job, DaemonSet, ReplicaSet, ou ReplicationController, dans un projet.

L'APV vous aide à comprendre l'utilisation optimale du CPU et de la mémoire pour vos pods et peut automatiquement maintenir les ressources des pods tout au long de leur cycle de vie.

2.6.1. À propos de l'opérateur de l'autoscaler à nacelle verticale
Copier lien

Le Vertical Pod Autoscaler Operator (VPA) est implémenté en tant que ressource API et ressource personnalisée (CR). La CR détermine les actions que le Vertical Pod Autoscaler Operator doit entreprendre avec les pods associés à un objet de charge de travail spécifique, tel qu'un ensemble de démons, un contrôleur de réplication, etc. dans un projet.

Vous pouvez utiliser le système de recommandation par défaut ou utiliser votre propre système de recommandation pour procéder à une mise à l'échelle automatique sur la base de vos propres algorithmes.

Le recommandeur par défaut calcule automatiquement l'utilisation historique et actuelle du processeur et de la mémoire pour les conteneurs de ces modules et utilise ces données pour déterminer des limites de ressources et des demandes optimisées afin de garantir que ces modules fonctionnent efficacement à tout moment. Par exemple, le recommandeur par défaut suggère de réduire les ressources pour les conteneurs qui demandent plus de ressources qu'ils n'en utilisent et d'augmenter les ressources pour les conteneurs qui n'en demandent pas assez.

L'APV supprime ensuite automatiquement tous les pods qui ne sont pas conformes à ces recommandations, un par un, afin que vos applications puissent continuer à répondre aux demandes sans interruption de service. Les objets de charge de travail redéploient ensuite les pods avec les limites de ressources et les demandes d'origine. L'APV utilise un webhook d'admission en mutation pour mettre à jour les modules avec des limites de ressources et des demandes optimisées avant que les modules ne soient admis sur un nœud. Si vous ne souhaitez pas que l'APV supprime des modules, vous pouvez afficher les limites de ressources et les demandes de l'APV et mettre à jour manuellement les modules si nécessaire.

Note

Par défaut, les objets de charge de travail doivent spécifier un minimum de deux répliques pour que l'APV supprime automatiquement leurs pods. Les objets de charge de travail qui spécifient moins de répliques que ce minimum ne sont pas supprimés. Si vous supprimez manuellement ces modules, lorsque l'objet de charge de travail redéploie les modules, l'APV met à jour les nouveaux modules avec ses recommandations. Vous pouvez modifier ce minimum en modifiant l'objet VerticalPodAutoscalerController comme indiqué à l'adresse Changing the VPA minimum value.

Par exemple, si vous avez un module qui utilise 50 % de l'UC mais n'en demande que 10 %, l'APV détermine que le module consomme plus d'UC que ce qui est demandé et le supprime. L'objet de charge de travail, tel que l'ensemble de répliques, redémarre les modules et l'APV met à jour le nouveau module avec les ressources recommandées.

Pour les développeurs, vous pouvez utiliser l'APV pour vous assurer que vos pods restent opérationnels pendant les périodes de forte demande en planifiant les pods sur des nœuds qui disposent des ressources appropriées pour chaque pod.

Les administrateurs peuvent utiliser l'APV pour mieux utiliser les ressources du cluster, par exemple en empêchant les pods de réserver plus de ressources CPU que nécessaire. L'APV surveille les ressources que les charges de travail utilisent réellement et ajuste les besoins en ressources afin que la capacité soit disponible pour d'autres charges de travail. L'APV maintient également les ratios entre les limites et les demandes qui sont spécifiés dans la configuration initiale du conteneur.

Note

Si vous arrêtez de faire fonctionner l'APV ou si vous supprimez un CR APV spécifique dans votre cluster, les demandes de ressources pour les pods déjà modifiés par l'APV ne changent pas. Tout nouveau module obtient les ressources définies dans l'objet de charge de travail, et non les recommandations précédentes faites par l'APPV.

2.6.2. Installation de l'opérateur Autoscaler Vertical Pod
Copier lien

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Vertical Pod Autoscaler (VPA).

Procédure

Dans la console Web OpenShift Container Platform, cliquez sur Operators → OperatorHub.
Choisissez VerticalPodAutoscaler dans la liste des opérateurs disponibles et cliquez sur Install.
Sur la page Install Operator, assurez-vous que l'option Operator recommended namespace est sélectionnée. Cela permet d'installer l'opérateur dans l'espace de noms obligatoire openshift-vertical-pod-autoscaler, qui est automatiquement créé s'il n'existe pas.
Cliquez sur Install.
Vérifiez l'installation en dressant la liste des composants de l'opérateur VPA :
1. Navigate to Workloads → Pods.
2. Sélectionnez le projet openshift-vertical-pod-autoscaler dans le menu déroulant et vérifiez que quatre pods sont en cours d'exécution.
3. Naviguez jusqu'à Workloads → Deployments pour vérifier que quatre déploiements sont en cours.

Facultatif. Vérifiez l'installation dans le CLI de OpenShift Container Platform à l'aide de la commande suivante :

oc get all -n openshift-vertical-pod-autoscaler

$ oc get all -n openshift-vertical-pod-autoscaler

Copy to Clipboard

Toggle word wrap

La sortie montre quatre pods et quatre déploiements :

Exemple de sortie

NAME                                                    READY   STATUS    RESTARTS   AGE
pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
deployment.apps/vpa-updater-default                1/1     1            1           2m56s

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s

NAME                                                    READY   STATUS    RESTARTS   AGE
pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
deployment.apps/vpa-updater-default                1/1     1            1           2m56s

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s

Copy to Clipboard

Toggle word wrap

2.6.3. À propos de l'utilisation de l'opérateur d'autoscaler de nacelles verticales
Copier lien

Pour utiliser l'opérateur Vertical Pod Autoscaler (VPA), vous créez une ressource personnalisée (CR) VPA pour un objet de charge de travail dans votre cluster. Le VPA apprend et applique les ressources optimales de CPU et de mémoire pour les pods associés à cet objet de charge de travail. Vous pouvez utiliser une APV avec un déploiement, un ensemble avec état, un travail, un ensemble de démons, un ensemble de réplicas ou un objet de charge de travail de contrôleur de réplication. L'APV CR doit se trouver dans le même projet que les modules que vous souhaitez surveiller.

La CR APV permet d'associer un objet de charge de travail et de spécifier le mode de fonctionnement de l'APV :

Les modes Auto et Recreate appliquent automatiquement les recommandations de l'APV en matière de CPU et de mémoire tout au long de la durée de vie du pod. L'APV supprime tous les modules du projet qui ne sont pas conformes à ses recommandations. Lorsqu'il est redéployé par l'objet de charge de travail, l'APV met à jour les nouveaux modules avec ses recommandations.
Le mode Initial applique automatiquement les recommandations de l'APV uniquement lors de la création d'un pod.
Le mode Off ne fournit que les limites de ressources et les demandes recommandées, ce qui vous permet d'appliquer manuellement les recommandations. Le mode off ne met pas à jour les pods.

Vous pouvez également utiliser le CR pour exclure certains conteneurs de l'évaluation et des mises à jour de l'APV.

Par exemple, un pod a les limites et les demandes suivantes :

resources:
  limits:
    cpu: 1
    memory: 500Mi
  requests:
    cpu: 500m
    memory: 100Mi

resources:
  limits:
    cpu: 1
    memory: 500Mi
  requests:
    cpu: 500m
    memory: 100Mi

Copy to Clipboard

Toggle word wrap

Après la création d'une APV configurée sur auto, l'APV apprend l'utilisation des ressources et supprime le module. Lorsqu'il est redéployé, le module utilise les nouvelles limites et demandes de ressources :

resources:
  limits:
    cpu: 50m
    memory: 1250Mi
  requests:
    cpu: 25m
    memory: 262144k

resources:
  limits:
    cpu: 50m
    memory: 1250Mi
  requests:
    cpu: 25m
    memory: 262144k

Copy to Clipboard

Toggle word wrap

Vous pouvez afficher les recommandations de l'APV à l'aide de la commande suivante :

oc get vpa <vpa-name> --output yaml

$ oc get vpa <vpa-name> --output yaml

Copy to Clipboard

Toggle word wrap

Après quelques minutes, l'écran affiche les recommandations pour les demandes de CPU et de mémoire, comme suit :

Exemple de sortie

...
status:
...
  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
        cpu: 25m
        memory: 262144k
      target:
        cpu: 25m
        memory: 262144k
      uncappedTarget:
        cpu: 25m
        memory: 262144k
      upperBound:
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"
...

...
status:
...
  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
        cpu: 25m
        memory: 262144k
      target:
        cpu: 25m
        memory: 262144k
      uncappedTarget:
        cpu: 25m
        memory: 262144k
      upperBound:
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"
...

Copy to Clipboard

Toggle word wrap

Le résultat montre les ressources recommandées, target, les ressources minimales recommandées, lowerBound, les ressources les plus élevées recommandées, upperBound, et les recommandations de ressources les plus récentes, uncappedTarget.

L'APV utilise les valeurs lowerBound et upperBound pour déterminer si un module doit être mis à jour. Si un module a des demandes de ressources inférieures aux valeurs lowerBound ou supérieures aux valeurs upperBound, l'APV met fin au module et le recrée avec les valeurs target.

2.6.3.1. Modification de la valeur minimale de l'APV
Copier lien

Par défaut, les objets de charge de travail doivent spécifier un minimum de deux répliques pour que l'APV supprime et mette à jour automatiquement leurs pods. Par conséquent, les objets de charge de travail qui spécifient moins de deux répliques ne sont pas automatiquement pris en compte par l'APPV. L'APP met à jour les nouveaux modules de ces objets de charge de travail si les modules sont redémarrés par un processus externe à l'APP. Vous pouvez modifier cette valeur minimale à l'échelle du cluster en modifiant le paramètre minReplicas dans la ressource personnalisée (CR) VerticalPodAutoscalerController.

Par exemple, si vous définissez minReplicas sur 3, l'APV ne supprime pas et ne met pas à jour les pods pour les objets de charge de travail qui spécifient moins de trois répliques.

Note

Si vous définissez minReplicas sur 1, l'APV peut supprimer le seul module d'un objet de charge de travail qui ne spécifie qu'une seule réplique. Vous ne devez utiliser ce paramètre avec les objets à une réplique que si votre charge de travail peut tolérer des temps d'arrêt chaque fois que l'APV supprime un module pour ajuster ses ressources. Pour éviter les temps d'arrêt indésirables avec les objets à réplique unique, configurez les CR de l'APV avec le paramètre podUpdatePolicy défini sur Initial, qui met automatiquement à jour le module uniquement lorsqu'il est redémarré par un processus externe à l'APV, ou Off, qui vous permet de mettre à jour le module manuellement à un moment approprié pour votre application.

Exemple d'objet VerticalPodAutoscalerController

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
  creationTimestamp: "2021-04-21T19:29:49Z"
  generation: 2
  name: default
  namespace: openshift-vertical-pod-autoscaler
  resourceVersion: "142172"
  uid: 180e17e9-03cc-427f-9955-3b4d7aeb2d59
spec:
  minReplicas: 3 
  podMinCPUMillicores: 25
  podMinMemoryMb: 250
  recommendationOnly: false
  safetyMarginFraction: 0.15

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
  creationTimestamp: "2021-04-21T19:29:49Z"
  generation: 2
  name: default
  namespace: openshift-vertical-pod-autoscaler
  resourceVersion: "142172"
  uid: 180e17e9-03cc-427f-9955-3b4d7aeb2d59
spec:
  minReplicas: 3


  podMinCPUMillicores: 25
  podMinMemoryMb: 250
  recommendationOnly: false
  safetyMarginFraction: 0.15

Copy to Clipboard

Toggle word wrap

1: Spécifiez le nombre minimum de répliques d'un objet de charge de travail sur lequel l'APV doit agir. Les objets dont le nombre de répliques est inférieur au minimum ne sont pas automatiquement supprimés par l'APV.

2.6.3.2. Appliquer automatiquement les recommandations de l'APV
Copier lien

Pour utiliser l'APV afin de mettre à jour automatiquement les modules, créez un CR APV pour un objet de charge de travail spécifique avec updateMode défini sur Auto ou Recreate.

Lorsque les modules sont créés pour l'objet de charge de travail, l'APV surveille constamment les conteneurs pour analyser leurs besoins en CPU et en mémoire. L'APV supprime tous les modules qui ne répondent pas aux recommandations de l'APV en matière de CPU et de mémoire. Lors du redéploiement, les modules utilisent les nouvelles limites de ressources et les demandes basées sur les recommandations de l'APV, tout en respectant le budget de perturbation des modules défini pour vos applications. Les recommandations sont ajoutées au champ status du CR VPA pour référence.

Note

Exemple d'APV CR pour le mode Auto

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Auto"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Auto"

Copy to Clipboard

Toggle word wrap

Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.

Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.

Réglez le mode sur Auto ou Recreate:

Auto. L'APV attribue des demandes de ressources lors de la création d'un module et met à jour les modules existants en les supprimant lorsque les ressources demandées diffèrent sensiblement de la nouvelle recommandation.
Recreate. L'APV attribue des demandes de ressources lors de la création d'un pod et met à jour les pods existants en les terminant lorsque les ressources demandées diffèrent de manière significative de la nouvelle recommandation. Ce mode ne doit être utilisé que rarement, uniquement si vous devez vous assurer que les modules sont redémarrés chaque fois que la demande de ressources change.

Note

Il faut qu'il y ait des nacelles en fonctionnement dans le projet pour que l'APV puisse déterminer les ressources recommandées et appliquer les recommandations aux nouvelles nacelles.

2.6.3.3. Appliquer automatiquement les recommandations de l'APV lors de la création d'un pod
Copier lien

Pour utiliser l'APV afin d'appliquer les ressources recommandées uniquement lorsqu'un module est déployé pour la première fois, créez un APV CR pour un objet de charge de travail spécifique avec updateMode défini sur Initial.

Ensuite, supprimez manuellement tous les modules associés à l'objet de charge de travail pour lequel vous souhaitez utiliser les recommandations de l'APV. En mode Initial, l'APV ne supprime pas les modules et ne les met pas à jour lorsqu'il apprend de nouvelles recommandations de ressources.

Exemple d'APV CR pour le mode Initial

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Initial"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Initial"

Copy to Clipboard

Toggle word wrap

1: Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2: Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3: Définissez le mode sur Initial. L'APV attribue des ressources lors de la création des pods et ne modifie pas les ressources pendant la durée de vie du pod.

Note

Il faut qu'il y ait des nacelles en fonctionnement dans le projet pour qu'une APV puisse déterminer les ressources recommandées et appliquer les recommandations aux nouvelles nacelles.

2.6.3.4. Application manuelle des recommandations de l'APV
Copier lien

Pour utiliser l'APV afin de déterminer uniquement les valeurs recommandées pour l'unité centrale et la mémoire, créez un APV CR pour un objet de charge de travail spécifique avec updateMode défini sur off.

Lorsque les modules sont créés pour cet objet de charge de travail, l'APPV analyse les besoins en CPU et en mémoire des conteneurs et enregistre ces recommandations dans le champ status du CR de l'APPV. L'APV ne met pas à jour les modules au fur et à mesure qu'il détermine de nouvelles recommandations de ressources.

Exemple d'APV CR pour le mode Off

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Off"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Off"

Copy to Clipboard

Toggle word wrap

1: Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2: Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3: Réglez le mode sur Off.

Vous pouvez consulter les recommandations à l'aide de la commande suivante.

oc get vpa <vpa-name> --output yaml

$ oc get vpa <vpa-name> --output yaml

Copy to Clipboard

Toggle word wrap

Avec les recommandations, vous pouvez modifier l'objet de charge de travail pour ajouter des demandes de CPU et de mémoire, puis supprimer et redéployer les pods en utilisant les ressources recommandées.

Note

Pour qu'un APV puisse déterminer les ressources recommandées, il faut qu'il y ait des modules d'exploitation dans le projet.

2.6.3.5. Exempter les conteneurs de l'application des recommandations de l'APV
Copier lien

Si votre objet de charge de travail a plusieurs conteneurs et que vous ne voulez pas que l'APV évalue et agisse sur tous les conteneurs, créez une CR APV pour un objet de charge de travail spécifique et ajoutez une resourcePolicy pour exclure des conteneurs spécifiques.

Lorsque l'APV met à jour les pods avec les ressources recommandées, tous les conteneurs avec resourcePolicy ne sont pas mis à jour et l'APV ne présente pas de recommandations pour ces conteneurs dans le pod.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Auto" 
  resourcePolicy: 
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Auto"


  resourcePolicy:


    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"

Copy to Clipboard

Toggle word wrap

1: Le type d'objet de charge de travail que vous voulez que ce CR VPA gère.
2: Le nom de l'objet de charge de travail que vous voulez que ce CR VPA gère.
3: Définissez le mode sur Auto, Recreate ou Off. Le mode Recreate ne doit être utilisé que rarement, uniquement si vous devez vous assurer que les pods sont redémarrés à chaque fois que la demande de ressources change.
4: Spécifiez les conteneurs que vous souhaitez exclure et définissez mode comme Off.

Par exemple, un pod a deux conteneurs, les mêmes demandes de ressources et les mêmes limites :

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...

Copy to Clipboard

Toggle word wrap

Après avoir lancé un VPA CR avec le conteneur backend en opt-out, le VPA se termine et recrée le pod avec les ressources recommandées appliquées uniquement au conteneur frontend:

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...

Copy to Clipboard

Toggle word wrap

2.6.3.6. Utilisation d'un autre système de recommandation
Copier lien

Vous pouvez utiliser votre propre recommandeur pour une mise à l'échelle automatique basée sur vos propres algorithmes. Si vous ne spécifiez pas de recommandation alternative, OpenShift Container Platform utilise la recommandation par défaut, qui suggère des demandes de CPU et de mémoire basées sur l'utilisation historique. Comme il n'existe pas de politique de recommandation universelle qui s'applique à tous les types de charges de travail, vous pouvez vouloir créer et déployer différents recommandeurs pour des charges de travail spécifiques.

Par exemple, le recommandeur par défaut peut ne pas prédire avec précision l'utilisation future des ressources lorsque les conteneurs présentent certains comportements en matière de ressources, tels que les modèles cycliques qui alternent entre les pics d'utilisation et la marche au ralenti, tels qu'utilisés par les applications de surveillance, ou les modèles récurrents et répétitifs utilisés avec les applications d'apprentissage en profondeur. L'utilisation de la recommandation par défaut avec ces comportements d'utilisation peut entraîner un surprovisionnement important et des pertes de mémoire (OOM) pour vos applications.

Note

Les instructions relatives à la création d'un recommandeur dépassent le cadre de cette documentation,

Procédure

Pour utiliser un recommandeur alternatif pour vos pods :

Créez un compte de service pour le recommandeur alternatif et liez ce compte de service au rôle de cluster requis :

apiVersion: v1 
kind: ServiceAccount
metadata:
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding
metadata:
  name: system:example-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-actor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-actor
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-target-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-target-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>

apiVersion: v1


kind: ServiceAccount
metadata:
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1


kind: ClusterRoleBinding
metadata:
  name: system:example-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1


kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-actor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-actor
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1


kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-target-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-target-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>

Copy to Clipboard

Toggle word wrap

1: Crée un compte de service pour le recommandeur dans l'espace de noms où le recommandeur est déployé.
2: Lier le compte du service de recommandation au rôle metrics-reader. Spécifier l'espace de noms dans lequel le service de recommandation doit être déployé.
3: Lier le compte du service de recommandation au rôle vpa-actor. Spécifier l'espace de noms dans lequel le service de recommandation doit être déployé.
4: Lier le compte du service de recommandation au rôle vpa-target-reader. Spécifier l'espace de noms dans lequel le service de recommandation doit être déployé.

Pour ajouter le recommandeur alternatif au cluster, créez un objet de déploiement similaire au suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alt-vpa-recommender
  namespace: <namespace_name>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alt-vpa-recommender
  template:
    metadata:
      labels:
        app: alt-vpa-recommender
    spec:
      containers: 
      - name: recommender
        image: quay.io/example/alt-recommender:latest 
        imagePullPolicy: Always
        resources:
          limits:
            cpu: 200m
            memory: 1000Mi
          requests:
            cpu: 50m
            memory: 500Mi
        ports:
        - name: prometheus
          containerPort: 8942
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
          seccompProfile:
            type: RuntimeDefault
      serviceAccountName: alt-vpa-recommender-sa 
      securityContext:
        runAsNonRoot: true

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alt-vpa-recommender
  namespace: <namespace_name>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alt-vpa-recommender
  template:
    metadata:
      labels:
        app: alt-vpa-recommender
    spec:
      containers:


      - name: recommender
        image: quay.io/example/alt-recommender:latest


        imagePullPolicy: Always
        resources:
          limits:
            cpu: 200m
            memory: 1000Mi
          requests:
            cpu: 50m
            memory: 500Mi
        ports:
        - name: prometheus
          containerPort: 8942
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
          seccompProfile:
            type: RuntimeDefault
      serviceAccountName: alt-vpa-recommender-sa


      securityContext:
        runAsNonRoot: true

Copy to Clipboard

Toggle word wrap

1: Crée un conteneur pour votre recommandeur alternatif.
2: Spécifie votre image de recommandation.
3: Associe le compte de service que vous avez créé pour le recommandeur.

Un nouveau module est créé pour le recommandeur alternatif dans le même espace de noms.

oc get pods

$ oc get pods

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                        READY   STATUS    RESTARTS   AGE
frontend-845d5478d-558zf                    1/1     Running   0          4m25s
frontend-845d5478d-7z9gx                    1/1     Running   0          4m25s
frontend-845d5478d-b7l4j                    1/1     Running   0          4m25s
vpa-alt-recommender-55878867f9-6tp5v        1/1     Running   0          9s

NAME                                        READY   STATUS    RESTARTS   AGE
frontend-845d5478d-558zf                    1/1     Running   0          4m25s
frontend-845d5478d-7z9gx                    1/1     Running   0          4m25s
frontend-845d5478d-b7l4j                    1/1     Running   0          4m25s
vpa-alt-recommender-55878867f9-6tp5v        1/1     Running   0          9s

Copy to Clipboard

Toggle word wrap

Configurez un CR APV qui inclut le nom de l'objet de recommandation alternatif Deployment.

Exemple d'APV CR incluant le recommandeur alternatif

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
  namespace: <namespace_name>
spec:
  recommenders:
    - name: alt-vpa-recommender 
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
  namespace: <namespace_name>
spec:
  recommenders:
    - name: alt-vpa-recommender


  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend

Copy to Clipboard

Toggle word wrap

1: Spécifie le nom de l'autre déploiement de recommandation.
2: Spécifie le nom d'un objet de charge de travail existant que l'APV doit gérer.

2.6.4. Utilisation de l'opérateur de l'autoscaler à nacelle verticale
Copier lien

Vous pouvez utiliser le Vertical Pod Autoscaler Operator (VPA) en créant une ressource personnalisée (CR) VPA. La CR indique les pods qu'elle doit analyser et détermine les actions que l'APV doit entreprendre avec ces pods.

Conditions préalables

L'objet de charge de travail que vous souhaitez mettre à l'échelle doit exister.
Si vous souhaitez utiliser un autre recommandeur, un déploiement incluant ce recommandeur doit exister.

Procédure

Pour créer un CR APV pour un objet de charge de travail spécifique :

Passez au projet dans lequel se trouve l'objet de charge de travail que vous souhaitez mettre à l'échelle.
1. Créer un fichier YAML VPA CR :
  apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: vpa-recommender spec: targetRef: apiVersion: "apps/v1" kind: Deployment
  1
  name: frontend
  2
  updatePolicy: updateMode: "Auto"
  3
  resourcePolicy:
  4
  containerPolicies: - containerName: my-opt-sidecar mode: "Off" recommenders:
  5
  - name: my-recommender
  Copy to Clipboard Toggle word wrap
  1
  Spécifiez le type d'objet de charge de travail que vous voulez que cette APV gère : Deployment, StatefulSet, Job, DaemonSet, ReplicaSet, ou ReplicationController.
  2
  Spécifiez le nom d'un objet de charge de travail existant que vous voulez que cette APV gère.
  3
  Spécifier le mode VPA :
  auto pour appliquer automatiquement les ressources recommandées aux modules associés au contrôleur. L'APV met fin aux pods existants et crée de nouveaux pods avec les limites de ressources et les demandes recommandées.
  recreate pour appliquer automatiquement les ressources recommandées aux modules associés à l'objet de charge de travail. L'APV met fin aux modules existants et en crée de nouveaux avec les limites et les demandes de ressources recommandées. Le mode recreate ne doit être utilisé que rarement, uniquement si vous devez vous assurer que les modules sont redémarrés chaque fois que la demande de ressources change.
  initial pour appliquer automatiquement les ressources recommandées lorsque les modules associés à l'objet de charge de travail sont créés. L'APV ne met pas à jour les modules au fur et à mesure qu'il apprend de nouvelles recommandations de ressources.
  off de ne générer des recommandations de ressources que pour les modules associés à l'objet de charge de travail. L'APV ne met pas à jour les modules au fur et à mesure qu'il apprend de nouvelles recommandations de ressources et n'applique pas les recommandations à de nouveaux modules.
  4
  Facultatif. Indiquez les conteneurs que vous souhaitez exclure et définissez le mode sur Off.
  5
  Optionnel. Indiquez un autre recommandeur.
2. Créer l'APV CR :
  oc create -f <nom-de-fichier>.yaml
  Copy to Clipboard Toggle word wrap
  Après quelques instants, l'APV apprend l'utilisation des ressources des conteneurs dans les pods associés à l'objet de charge de travail.
  Vous pouvez afficher les recommandations de l'APV à l'aide de la commande suivante :
  $ oc get vpa <vpa-name> --output yaml
  Copy to Clipboard Toggle word wrap
  La sortie montre les recommandations pour les demandes de CPU et de mémoire, comme suit :
  Exemple de sortie
  ... status: ... recommendation: containerRecommendations: - containerName: frontend lowerBound:
  1
  cpu: 25m memory: 262144k target:
  2
  cpu: 25m memory: 262144k uncappedTarget:
  3
  cpu: 25m memory: 262144k upperBound:
  4
  cpu: 262m memory: "274357142" - containerName: backend lowerBound: cpu: 12m memory: 131072k target: cpu: 12m memory: 131072k uncappedTarget: cpu: 12m memory: 131072k upperBound: cpu: 476m memory: "498558823" ...
  
  Copy to Clipboard Toggle word wrap
  1
  lowerBound est le niveau minimum de ressources recommandé.
  2
  target est le niveau de ressources recommandé.
  3
  upperBound est le niveau de ressources recommandé le plus élevé.
  4
  uncappedTarget est la recommandation la plus récente en matière de ressources.

2.6.5. Désinstallation de l'opérateur d'autoscaler de nacelles verticales
Copier lien

Vous pouvez supprimer l'opérateur Vertical Pod Autoscaler (VPA) de votre cluster OpenShift Container Platform. Après la désinstallation, les demandes de ressources pour les pods déjà modifiés par un VPA CR existant ne changent pas. Tout nouveau pod obtient les ressources définies dans l'objet de charge de travail, et non les recommandations précédentes faites par le Vertical Pod Autoscaler Operator.

Note

Vous pouvez supprimer un VPA CR spécifique à l'aide de la commande oc delete vpa <vpa-name>. Les mêmes actions s'appliquent aux demandes de ressources que la désinstallation de l'autoscaler de pods verticaux.

Après avoir retiré l'Opérateur VPA, il est recommandé de retirer les autres composants associés à l'Opérateur afin d'éviter tout problème potentiel.

Conditions préalables

L'opérateur Autoscaler Vertical Pod doit être installé.

Procédure

Dans la console web d'OpenShift Container Platform, cliquez sur Operators → Installed Operators.
Passez au projet openshift-vertical-pod-autoscaler.
Pour l'opérateur VerticalPodAutoscaler, cliquez sur le menu Options et sélectionnez Uninstall Operator.
Facultatif : Pour supprimer tous les opérandes associés à l'opérateur, cochez la case Delete all operand instances for this operator dans la boîte de dialogue.
Cliquez sur Uninstall.
Optionnel : Utilisez la CLI d'OpenShift pour supprimer les composants de l'APV :
1. Supprimer l'espace de noms de l'APV :
  $ oc delete namespace openshift-vertical-pod-autoscaler
  Copy to Clipboard Toggle word wrap
2. Supprimer les objets de définition des ressources personnalisées (CRD) de l'APV :
  $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io
  Copy to Clipboard Toggle word wrap
  $ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io
  Copy to Clipboard Toggle word wrap
  $ oc delete crd verticalpodautoscalers.autoscaling.k8s.io
  Copy to Clipboard Toggle word wrap
  La suppression des CRD supprime les rôles associés, les rôles de cluster et les liaisons de rôles.
  Note
  Cette action supprime du cluster tous les CR d'APV créés par l'utilisateur. Si vous réinstallez l'APV, vous devez à nouveau créer ces objets.
3. Supprimer l'opérateur APV :
  $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
  Copy to Clipboard Toggle word wrap

2.7. Fournir des données sensibles aux pods
Copier lien

Certaines applications nécessitent des informations sensibles, telles que des mots de passe et des noms d'utilisateur, que vous ne voulez pas que les développeurs possèdent.

En tant qu'administrateur, vous pouvez utiliser les objets Secret pour fournir ces informations sans les exposer en clair.

2.7.1. Comprendre les secrets
Copier lien

Le type d'objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, les fichiers de configuration du client OpenShift Container Platform, les informations d'identification du référentiel source privé, etc. Les secrets découplent le contenu sensible des pods. Vous pouvez monter des secrets dans des conteneurs à l'aide d'un plugin de volume ou le système peut utiliser des secrets pour effectuer des actions au nom d'un pod.

Les principales propriétés sont les suivantes

Les données secrètes peuvent être référencées indépendamment de leur définition.
Les volumes de données secrètes sont sauvegardés par des installations de stockage de fichiers temporaires (tmpfs) et ne s'arrêtent jamais sur un nœud.
Les données secrètes peuvent être partagées au sein d'un espace de noms.

YAML Secret définition de l'objet

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 
data: 
  username: dmFsdWUtMQ0K 
  password: dmFsdWUtMg0KDQo=
stringData: 
  hostname: myapp.mydomain.com

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque


data:


  username: dmFsdWUtMQ0K


  password: dmFsdWUtMg0KDQo=
stringData:


  hostname: myapp.mydomain.com

Copy to Clipboard

Toggle word wrap

1: Indique la structure des noms et des valeurs des clés du secret.
2: Le format autorisé pour les clés du champ data doit respecter les directives de la valeur DNS_SUBDOMAIN dans le glossaire des identifiants Kubernetes.
3: La valeur associée aux clés de la carte data doit être encodée en base64.
4: Les entrées de la carte stringData sont converties en base64 et l'entrée est alors déplacée automatiquement vers la carte data. Ce champ est en écriture seule ; la valeur ne sera renvoyée que via le champ data.
5: La valeur associée aux clés de la carte stringData est constituée de chaînes de texte en clair.

Vous devez créer un secret avant de créer les modules qui dépendent de ce secret.

Lors de la création de secrets :

Créer un objet secret avec des données secrètes.
Mettre à jour le compte de service du pod pour autoriser la référence au secret.
Créer un pod, qui consomme le secret comme une variable d'environnement ou comme un fichier (en utilisant un volume secret ).

2.7.1.1. Types de secrets
Copier lien

La valeur du champ type indique la structure des noms et des valeurs des clés du secret. Le type peut être utilisé pour imposer la présence de noms d'utilisateur et de clés dans l'objet secret. Si vous ne souhaitez pas de validation, utilisez le type opaque, qui est le type par défaut.

Indiquez l'un des types suivants pour déclencher une validation minimale côté serveur afin de garantir la présence de noms de clés spécifiques dans les données secrètes :

kubernetes.io/service-account-token. Utilise un jeton de compte de service.
kubernetes.io/basic-auth. Utilisation avec l'authentification de base.
kubernetes.io/ssh-auth. Utiliser avec l'authentification par clé SSH.
kubernetes.io/tls. A utiliser avec les autorités de certification TLS.

Indiquez type: Opaque si vous ne souhaitez pas de validation, ce qui signifie que le secret ne prétend pas se conformer à une convention pour les noms de clés ou les valeurs. Un secret opaque permet d'utiliser des paires key:value non structurées pouvant contenir des valeurs arbitraires.

Note

Vous pouvez spécifier d'autres types arbitraires, tels que example.com/my-secret-type. Ces types ne sont pas appliqués côté serveur, mais ils indiquent que le créateur du secret avait l'intention de se conformer aux exigences clé/valeur de ce type.

Pour des exemples de différents types de secrets, voir les exemples de code sur Using Secrets.

2.7.1.2. Clés de données secrètes
Copier lien

Les clés secrètes doivent se trouver dans un sous-domaine DNS.

2.7.1.3. À propos des secrets de jetons de compte de service générés automatiquement
Copier lien

Dans la version 4.12, OpenShift Container Platform adopte une amélioration de Kubernetes en amont, qui active la fonctionnalité LegacyServiceAccountTokenNoAutoGeneration par défaut. Par conséquent, lors de la création de nouveaux comptes de service (SA), un secret de jeton de compte de service n'est plus automatiquement généré. Auparavant, OpenShift Container Platform ajoutait automatiquement un jeton de compte de service à un secret pour chaque nouveau SA.

Cependant, certaines fonctionnalités et charges de travail ont besoin de secrets de jetons de compte de service pour communiquer avec le serveur API Kubernetes, par exemple, OpenShift Controller Manager. Cette exigence sera modifiée dans une prochaine version, mais elle demeure dans OpenShift Container Platform 4.12. Par conséquent, si vous avez besoin d'un secret de jeton de compte de service, vous devez utiliser manuellement l'API TokenRequest pour demander des jetons de compte de service liés ou créer un secret de jeton de compte de service.

Après la mise à jour vers la version 4.12, les secrets de jetons de compte de service existants ne sont pas supprimés et continuent de fonctionner comme prévu.

Note

Dans la version 4.12, les secrets des jetons des comptes de service sont toujours générés automatiquement. Au lieu de créer deux secrets par compte de service, OpenShift Container Platform n'en crée plus qu'un. Dans une prochaine version, ce nombre sera encore réduit à zéro. Notez que les secrets dockercfg sont toujours générés et qu'aucun secret n'est supprimé lors des mises à jour.

Ressources supplémentaires

Pour plus d'informations sur la demande de jetons de compte de service liés, voir Utilisation de jetons de compte de service liés
Pour plus d'informations sur la création d'un jeton secret de compte de service, voir Création d'un jeton secret de compte de service.

2.7.2. Comprendre comment créer des secrets
Copier lien

En tant qu'administrateur, vous devez créer un secret avant que les développeurs puissent créer les modules qui dépendent de ce secret.

Lors de la création de secrets :

Créez un objet secret contenant les données que vous souhaitez garder secrètes. Les données spécifiques requises pour chaque type de secret sont décrites dans les sections suivantes.

Exemple d'objet YAML qui crée un secret opaque

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque 
data: 
  username: dmFsdWUtMQ0K
  password: dmFsdWUtMQ0KDQo=
stringData: 
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque


data:


  username: dmFsdWUtMQ0K
  password: dmFsdWUtMQ0KDQo=
stringData:


  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB

Copy to Clipboard

Toggle word wrap

1: Spécifie le type de secret.
2: Spécifie la chaîne et les données encodées.
3: Spécifie la chaîne et les données décodées.

Utilisez soit le champ data, soit le champ stringdata, mais pas les deux.

Mettre à jour le compte de service du pod pour référencer le secret :
YAML d'un compte de service qui utilise un secret
```
apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
```
```
apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
```
Copy to Clipboard Toggle word wrap

Créer un pod, qui consomme le secret comme une variable d'environnement ou comme un fichier (en utilisant un volume secret ) :

YAML d'un pod remplissant les fichiers d'un volume avec des données secrètes

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts: 
          - name: secret-volume
            mountPath: /etc/secret-volume 
            readOnly: true 
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:


          - name: secret-volume
            mountPath: /etc/secret-volume


            readOnly: true


  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Ajoutez un champ volumeMounts à chaque conteneur qui a besoin du secret.
2: Spécifie un nom de répertoire inutilisé dans lequel vous souhaitez que le secret apparaisse. Chaque clé de la carte de données secrètes devient le nom de fichier sous mountPath.
3: Défini à true. S'il est vrai, cela indique au pilote de fournir un volume en lecture seule.
4: Spécifie le nom du secret.

YAML d'un pod remplissant les variables d'environnement avec des données secrètes

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef: 
              name: test-secret
              key: username
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:


              name: test-secret
              key: username
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Spécifie la variable d'environnement qui consomme la clé secrète.

YAML d'une configuration de construction remplissant les variables d'environnement avec des données secrètes

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef: 
            name: test-secret
            key: username

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:


            name: test-secret
            key: username

Copy to Clipboard

Toggle word wrap

1: Spécifie la variable d'environnement qui consomme la clé secrète.

2.7.2.1. Restrictions à la création de secrets
Copier lien

Pour utiliser un secret, un module doit faire référence au secret. Un secret peut être utilisé avec un module de trois façons :

Pour remplir les variables d'environnement des conteneurs.
En tant que fichiers dans un volume monté sur un ou plusieurs de ses conteneurs.
Par kubelet lors de l'extraction des images pour le pod.

Les secrets de type volume écrivent des données dans le conteneur sous forme de fichier en utilisant le mécanisme de volume. Les secrets de type image pull utilisent des comptes de service pour l'injection automatique du secret dans tous les pods d'un espace de noms.

Lorsqu'un modèle contient une définition de secret, le seul moyen pour le modèle d'utiliser le secret fourni est de s'assurer que les sources de volume du secret sont validées et que la référence d'objet spécifiée pointe effectivement vers un objet Secret. Par conséquent, un secret doit être créé avant tout pod qui en dépend. Le moyen le plus efficace de s'en assurer est de l'injecter automatiquement par l'intermédiaire d'un compte de service.

Les objets API secrets résident dans un espace de noms. Ils ne peuvent être référencés que par les pods de ce même espace de noms.

La taille des secrets individuels est limitée à 1 Mo. Il s'agit de décourager la création de secrets volumineux qui pourraient épuiser la mémoire de l'apiserver et du kubelet. Cependant, la création d'un certain nombre de secrets plus petits pourrait également épuiser la mémoire.

2.7.2.2. Création d'un secret opaque
Copier lien

En tant qu'administrateur, vous pouvez créer un secret opaque, qui vous permet de stocker des paires key:value non structurées pouvant contenir des valeurs arbitraires.

Procédure

Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle.

Par exemple :

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 
data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque


data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=

Copy to Clipboard

Toggle word wrap

1: Spécifie un secret opaque.

La commande suivante permet de créer un objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pour utiliser le secret dans une dosette :
1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

2.7.2.3. Création d'un jeton secret de compte de service
Copier lien

En tant qu'administrateur, vous pouvez créer un secret de jeton de compte de service, qui vous permet de distribuer un jeton de compte de service aux applications qui doivent s'authentifier auprès de l'API.

Note

Il est recommandé d'obtenir des jetons de compte de service liés à l'aide de l'API TokenRequest plutôt que d'utiliser des jetons de compte de service secrets. Les jetons obtenus à l'aide de l'API TokenRequest sont plus sûrs que les jetons stockés dans les secrets, car ils ont une durée de vie limitée et ne sont pas lisibles par d'autres clients de l'API.

Vous ne devez créer un secret de jeton de compte de service que si vous ne pouvez pas utiliser l'API TokenRequest et si l'exposition à la sécurité d'un jeton n'expirant pas dans un objet API lisible est acceptable pour vous.

Pour plus d'informations sur la création de jetons de compte de service lié, reportez-vous à la section Ressources supplémentaires.

Procédure

Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle :

Exemple secret objet :

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
type: kubernetes.io/service-account-token

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"


type: kubernetes.io/service-account-token

Copy to Clipboard

Toggle word wrap

1: Spécifie un nom de compte de service existant. Si vous créez les objets ServiceAccount et Secret, créez d'abord l'objet ServiceAccount.
2: Spécifie un secret de jeton de compte de service.

La commande suivante permet de créer l'objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pour utiliser le secret dans une dosette :
1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

2.7.2.4. Création d'un secret d'authentification de base
Copier lien

En tant qu'administrateur, vous pouvez créer un secret d'authentification de base, qui vous permet de stocker les informations d'identification nécessaires à l'authentification de base. Lorsque vous utilisez ce type de secret, le paramètre data de l'objet Secret doit contenir les clés suivantes encodées au format base64 :

usernamele nom d'utilisateur pour l'authentification
passwordle mot de passe ou le jeton d'authentification

Note

Vous pouvez utiliser le paramètre stringData pour utiliser un contenu en texte clair.

Procédure

Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle :

Exemple d'objet secret

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth 
data:
stringData: 
  username: admin
  password: t0p-Secret

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth


data:
stringData:


  username: admin
  password: t0p-Secret

Copy to Clipboard

Toggle word wrap

1: Spécifie un secret d'authentification de base.
2: Spécifie les valeurs d'authentification de base à utiliser.

La commande suivante permet de créer l'objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pour utiliser le secret dans une dosette :
1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

2.7.2.5. Création d'un secret d'authentification SSH
Copier lien

En tant qu'administrateur, vous pouvez créer un secret d'authentification SSH, qui vous permet de stocker les données utilisées pour l'authentification SSH. Lorsque vous utilisez ce type de secret, le paramètre data de l'objet Secret doit contenir l'identifiant SSH à utiliser.

Procédure

Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle :

Exemple secret objet :

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth 
data:
  ssh-privatekey: | 
          MIIEpQIBAAKCAQEAulqb/Y ...

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth


data:
  ssh-privatekey: |


          MIIEpQIBAAKCAQEAulqb/Y ...

Copy to Clipboard

Toggle word wrap

1: Spécifie un secret d'authentification SSH.
2: Spécifie la paire clé/valeur SSH en tant qu'identifiant SSH à utiliser.

La commande suivante permet de créer l'objet Secret:
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pour utiliser le secret dans une dosette :
1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

2.7.2.6. Création d'un secret de configuration Docker
Copier lien

En tant qu'administrateur, vous pouvez créer un secret de configuration Docker, qui vous permet de stocker les informations d'identification pour accéder à un registre d'images de conteneurs.

kubernetes.io/dockercfg. Utilisez ce type de secret pour stocker votre fichier de configuration Docker local. Le paramètre data de l'objet secret doit contenir le contenu d'un fichier .dockercfg encodé au format base64.
kubernetes.io/dockerconfigjson. Utilisez ce type de secret pour stocker votre fichier JSON de configuration Docker local. Le paramètre data de l'objet secret doit contenir le contenu d'un fichier .docker/config.json encodé au format base64.

Procédure

Créer un objet Secret dans un fichier YAML sur un nœud de plan de contrôle.

Exemple de configuration Docker secret object

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig 
data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig


data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

Copy to Clipboard

Toggle word wrap

1: Spécifie que le secret utilise un fichier de configuration Docker.
2: La sortie d'un fichier de configuration Docker encodé en base64

Exemple de configuration Docker JSON secret object

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig 
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig


data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

Copy to Clipboard

Toggle word wrap

1: Spécifie que le secret utilise un fichier JSON de configuration Docker.
2: La sortie d'un fichier JSON de configuration Docker encodé en base64

La commande suivante permet de créer l'objet Secret
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pour utiliser le secret dans une dosette :
1. Mettez à jour le compte de service du pod pour référencer le secret, comme indiqué dans la section "Comprendre comment créer des secrets".
2. Créer le pod, qui consomme le secret sous forme de variable d'environnement ou de fichier (à l'aide d'un volume secret ), comme indiqué dans la section "Comprendre comment créer des secrets".

2.7.3. Comprendre comment mettre à jour les secrets
Copier lien

Lorsque vous modifiez la valeur d'un secret, la valeur (utilisée par un pod déjà en cours d'exécution) ne change pas dynamiquement. Pour modifier un secret, vous devez supprimer le module d'origine et en créer un nouveau (éventuellement avec un PodSpec identique).

La mise à jour d'un secret suit le même processus que le déploiement d'une nouvelle image de conteneur. Vous pouvez utiliser la commande kubectl rolling-update.

La valeur resourceVersion d'un secret n'est pas spécifiée lorsqu'il est référencé. Par conséquent, si un secret est mis à jour au moment où les modules démarrent, la version du secret utilisée pour le module n'est pas définie.

Note

Actuellement, il n'est pas possible de vérifier la version de la ressource d'un objet secret qui a été utilisé lors de la création d'un pod. Il est prévu que les modules communiquent cette information, de sorte qu'un contrôleur puisse redémarrer ceux qui utilisent un ancien resourceVersion. Dans l'intervalle, ne mettez pas à jour les données des secrets existants, mais créez-en de nouveaux avec des noms distincts.

2.7.4. Créer et utiliser des secrets
Copier lien

En tant qu'administrateur, vous pouvez créer un jeton de service secret. Cela vous permet de distribuer un jeton de compte de service aux applications qui doivent s'authentifier auprès de l'API.

Procédure

Créez un compte de service dans votre espace de noms en exécutant la commande suivante :
```
oc create sa <service_account_name> -n <your_namespace>
```
```
$ oc create sa <service_account_name> -n <your_namespace>
```
Copy to Clipboard Toggle word wrap
Enregistrez l'exemple YAML suivant dans un fichier nommé service-account-token-secret.yaml. L'exemple inclut une configuration d'objet Secret que vous pouvez utiliser pour générer un jeton de compte de service :
```
apiVersion: v1
kind: Secret
metadata:
  name: <secret_name> 
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
type: kubernetes.io/service-account-token 
```
```
apiVersion: v1
kind: Secret
metadata:
  name: <secret_name> 
```
1
```
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
```
2
```
type: kubernetes.io/service-account-token 
```
3
Copy to Clipboard Toggle word wrap
1
Remplacez <secret_name> par le nom de votre jeton de service secret.
2
Spécifie un nom de compte de service existant. Si vous créez les objets ServiceAccount et Secret, créez d'abord l'objet ServiceAccount.
3
Spécifie un type de secret de jeton de compte de service.
Générer le jeton de compte de service en appliquant le fichier :
```
oc apply -f service-account-token-secret.yaml
```
```
$ oc apply -f service-account-token-secret.yaml
```
Copy to Clipboard Toggle word wrap

Obtenez le jeton du compte de service à partir du secret en exécutant la commande suivante :

oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode)

oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode)

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

Copy to Clipboard

Toggle word wrap

1: Remplacez <sa_token_secret> par le nom de votre jeton de service secret.

Utilisez votre jeton de compte de service pour vous authentifier auprès de l'API de votre cluster :
```
curl -X GET <openshift_cluster_api> --header "Authorization : Bearer <token>"
```
```
$ curl -X GET <openshift_cluster_api> --header "Authorization : Bearer <token>" 
```
1
```
 
```
2
Copy to Clipboard Toggle word wrap
1
Remplacez <openshift_cluster_api> par l'API de cluster OpenShift.
2
Remplacez <token> par le jeton de compte de service qui apparaît dans la commande précédente.

2.7.5. Utilisation de certificats signés avec des secrets
Copier lien

Pour sécuriser la communication avec votre service, vous pouvez configurer OpenShift Container Platform pour générer un couple certificat/clé de service signé que vous pouvez ajouter à un secret dans un projet.

Un site service serving certificate secret est destiné à prendre en charge des applications intergicielles complexes qui nécessitent des certificats prêts à l'emploi. Il possède les mêmes paramètres que les certificats de serveur générés par l'outil d'administration pour les nœuds et les maîtres.

Service Pod spec configuré pour un service servant des certificats secrets.

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert
# ...

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert


# ...

Copy to Clipboard

Toggle word wrap

1: Spécifier le nom du certificat

Les autres modules peuvent faire confiance aux certificats créés par le cluster (qui ne sont signés que pour les noms DNS internes), en utilisant le paquet d'autorités de certification dans le fichier /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt qui est automatiquement monté dans leur module.

L'algorithme de signature pour cette fonctionnalité est x509.SHA256WithRSA. Pour effectuer une rotation manuelle, supprimez le secret généré. Un nouveau certificat est créé.

2.7.5.1. Génération de certificats signés à utiliser avec des secrets
Copier lien

Pour utiliser une paire certificat/clé de service signée avec un pod, créez ou modifiez le service pour ajouter l'annotation service.beta.openshift.io/serving-cert-secret-name, puis ajoutez le secret au pod.

Procédure

Pour créer un site service serving certificate secret:

Modifiez la spécification Pod pour votre service.

Ajoutez l'annotation service.beta.openshift.io/serving-cert-secret-name avec le nom que vous voulez utiliser pour votre secret.

kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert 
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert


spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

Copy to Clipboard

Toggle word wrap

Le certificat et la clé sont au format PEM et sont stockés respectivement dans tls.crt et tls.key.

Créer le service :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Consultez le secret pour vous assurer qu'il a bien été créé :

Afficher une liste de tous les secrets :

oc get secrets

$ oc get secrets

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m

NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m

Copy to Clipboard

Toggle word wrap

Voir les détails de votre secret :

oc describe secret my-cert

$ oc describe secret my-cert

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes

Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes

Copy to Clipboard

Toggle word wrap

Modifiez votre spécification Pod avec ce secret.
```
apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511
```
```
apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511
```
Copy to Clipboard Toggle word wrap
Lorsqu'il sera disponible, votre pod s'exécutera. Le certificat sera valable pour le nom DNS du service interne, <service.name>.<service.namespace>.svc.
La paire certificat/clé est automatiquement remplacée lorsqu'elle est proche de l'expiration. La date d'expiration est indiquée dans l'annotation service.beta.openshift.io/expiry sur le secret, au format RFC3339.
Note
Dans la plupart des cas, le nom DNS du service <service.name>.<service.namespace>.svc n'est pas routable de l'extérieur. L'utilisation principale de <service.name>.<service.namespace>.svc est pour la communication à l'intérieur d'un cluster ou d'un service, et avec des itinéraires de re-cryptage.

2.7.6. Secrets de dépannage
Copier lien

Si la génération d'un certificat de service échoue avec (l'annotation service.beta.openshift.io/serving-cert-generation-error du service contient) :

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

Copy to Clipboard

Toggle word wrap

Le service qui a généré le certificat n'existe plus, ou a un autre serviceUID. Vous devez forcer la régénération des certificats en supprimant l'ancien secret et en supprimant les annotations suivantes sur le service service.beta.openshift.io/serving-cert-generation-error, service.beta.openshift.io/serving-cert-generation-error-num:

Supprimer le secret :
```
oc delete secret <secret_name>
```
```
oc delete secret <secret_name>
```
Copy to Clipboard Toggle word wrap

Effacer les annotations :

oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

Copy to Clipboard

Toggle word wrap

oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

Copy to Clipboard

Toggle word wrap

Note

La commande de suppression d'une annotation comporte une adresse - après le nom de l'annotation à supprimer.

2.8. Créer et utiliser des cartes de configuration
Copier lien

Les sections suivantes définissent les cartes de configuration et expliquent comment les créer et les utiliser.

2.8.1. Comprendre les cartes de configuration
Copier lien

De nombreuses applications doivent être configurées à l'aide d'une combinaison de fichiers de configuration, d'arguments de ligne de commande et de variables d'environnement. Dans OpenShift Container Platform, ces artefacts de configuration sont découplés du contenu de l'image afin de maintenir la portabilité des applications conteneurisées.

L'objet ConfigMap fournit des mécanismes pour injecter des conteneurs avec des données de configuration tout en gardant les conteneurs agnostiques de OpenShift Container Platform. Une carte de configuration peut être utilisée pour stocker des informations fines comme des propriétés individuelles ou des informations grossières comme des fichiers de configuration entiers ou des blobs JSON.

L'objet API ConfigMap contient des paires clé-valeur de données de configuration qui peuvent être consommées dans des pods ou utilisées pour stocker des données de configuration pour des composants système tels que des contrôleurs. Par exemple, l'objet

ConfigMap Définition de l'objet

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data: 
  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:


  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw

Copy to Clipboard

Toggle word wrap

1 1: Contient les données de configuration.
2: Pointe vers un fichier qui contient des données non-UTF8, par exemple un fichier keystore Java binaire. Saisissez les données du fichier en base 64.

Note

Vous pouvez utiliser le champ binaryData lorsque vous créez une carte de configuration à partir d'un fichier binaire, tel qu'une image.

Les données de configuration peuvent être consommées dans les pods de différentes manières. Une carte de configuration peut être utilisée pour :

Remplir les valeurs des variables d'environnement dans les conteneurs
Définir les arguments de la ligne de commande dans un conteneur
Remplir les fichiers de configuration d'un volume

Les utilisateurs et les composants du système peuvent stocker des données de configuration dans une carte de configuration.

Une carte de configuration est similaire à un secret, mais elle est conçue pour faciliter le travail avec des chaînes de caractères qui ne contiennent pas d'informations sensibles.

Restrictions de la carte de configuration

A config map must be created before its contents can be consumed in pods.

Les contrôleurs peuvent être écrits de manière à tolérer les données de configuration manquantes. Consultez les composants individuels configurés à l'aide de cartes de configuration au cas par cas.

ConfigMap objects reside in a project.

Ils ne peuvent être référencés que par les pods du même projet.

The Kubelet only supports the use of a config map for pods it gets from the API server.

Cela inclut tous les pods créés en utilisant le CLI, ou indirectement à partir d'un contrôleur de réplication. Cela n'inclut pas les pods créés en utilisant le drapeau --manifest-url, le drapeau --config ou l'API REST du nœud OpenShift Container Platform, car ce ne sont pas des moyens courants de créer des pods.

2.8.2. Créer une carte de configuration dans la console web de OpenShift Container Platform
Copier lien

Vous pouvez créer une carte de configuration dans la console web d'OpenShift Container Platform.

Procédure

Pour créer une carte de configuration en tant qu'administrateur de cluster :
1. Dans la perspective de l'administrateur, sélectionnez Workloads → Config Maps.
2. En haut à droite de la page, sélectionnez Create Config Map.
3. Entrez le contenu de votre carte de configuration.
4. Sélectionnez Create.
Pour créer une carte de configuration en tant que développeur :
1. Dans la perspective du développeur, sélectionnez Config Maps.
2. En haut à droite de la page, sélectionnez Create Config Map.
3. Entrez le contenu de votre carte de configuration.
4. Sélectionnez Create.

2.8.3. Création d'une carte de configuration à l'aide de la CLI
Copier lien

Vous pouvez utiliser la commande suivante pour créer une carte de configuration à partir de répertoires, de fichiers spécifiques ou de valeurs littérales.

Procédure

Créer une carte de configuration :

oc create configmap <configmap_name> [options] $ oc create configmap <configmap_name> [options]

oc create configmap <configmap_name> [options] $ oc create configmap <configmap_name> [options]

Copy to Clipboard

Toggle word wrap

2.8.3.1. Création d'une carte de configuration à partir d'un répertoire
Copier lien

Vous pouvez créer une carte de configuration à partir d'un répertoire. Cette méthode vous permet d'utiliser plusieurs fichiers d'un répertoire pour créer une carte de configuration.

Procédure

L'exemple de procédure suivant explique comment créer une carte de configuration à partir d'un répertoire.

Commencez par un répertoire contenant quelques fichiers qui contiennent déjà les données avec lesquelles vous voulez remplir une carte de configuration :

ls example-files

$ ls example-files

Copy to Clipboard

Toggle word wrap

Exemple de sortie

game.properties
ui.properties

game.properties
ui.properties

Copy to Clipboard

Toggle word wrap

cat example-files/game.properties

$ cat example-files/game.properties

Copy to Clipboard

Toggle word wrap

Exemple de sortie

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

Copy to Clipboard

Toggle word wrap

cat example-files/ui.properties

$ cat example-files/ui.properties

Copy to Clipboard

Toggle word wrap

Exemple de sortie

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Copy to Clipboard

Toggle word wrap

Créez une carte de configuration contenant le contenu de chaque fichier de ce répertoire en entrant la commande suivante :
```
oc create configmap game-config \
    --from-file=example-files/
```
```
$ oc create configmap game-config \
    --from-file=example-files/
```
Copy to Clipboard Toggle word wrap
Lorsque l'option --from-file pointe vers un répertoire, chaque fichier directement dans ce répertoire est utilisé pour remplir une clé dans la carte de configuration, où le nom de la clé est le nom du fichier, et la valeur de la clé est le contenu du fichier.
Par exemple, la commande précédente crée la carte de configuration suivante :
```
oc describe configmaps game-config
```
```
$ oc describe configmaps game-config
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes
```
```
Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes
```
Copy to Clipboard Toggle word wrap
Vous pouvez voir que les deux clés de la carte sont créées à partir des noms de fichiers du répertoire spécifié dans la commande. Le contenu de ces clés pouvant être volumineux, la sortie de oc describe n'indique que les noms des clés et leur taille.

Entrez la commande oc get pour l'objet avec l'option -o pour voir les valeurs des clés :

oc get configmaps game-config -o yaml

$ oc get configmaps game-config -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

2.8.3.2. Création d'une carte de configuration à partir d'un fichier
Copier lien

Vous pouvez créer une carte de configuration à partir d'un fichier.

Procédure

L'exemple de procédure suivant explique comment créer une carte de configuration à partir d'un fichier.

Note

Si vous créez une carte de configuration à partir d'un fichier, vous pouvez inclure des fichiers contenant des données non-UTF8 qui sont placées dans ce champ sans corrompre les données non-UTF8. OpenShift Container Platform détecte les fichiers binaires et encode de manière transparente le fichier en tant que MIME. Sur le serveur, la charge utile MIME est décodée et stockée sans corrompre les données.

Vous pouvez transmettre l'option --from-file plusieurs fois à l'interface de programmation. L'exemple suivant donne des résultats équivalents à ceux de l'exemple de création à partir de répertoires.

Créer une carte de configuration en spécifiant un fichier spécifique :

oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties

$ oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties

Copy to Clipboard

Toggle word wrap

Vérifier les résultats :

oc get configmaps game-config-2 -o yaml

$ oc get configmaps game-config-2 -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

Vous pouvez spécifier la clé à définir dans une carte de configuration pour le contenu importé à partir d'un fichier. Cette clé peut être définie en passant une expression key=value à l'option --from-file. Par exemple :

Créer une carte de configuration en spécifiant une paire clé-valeur :

oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties

$ oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties

Copy to Clipboard

Toggle word wrap

Vérifier les résultats :

oc get configmaps game-config-3 -o yaml

$ oc get configmaps game-config-3 -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
data:
  game-special-key: |- 
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  game-special-key: |-


    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

1: Il s'agit de la clé que vous avez définie à l'étape précédente.

2.8.3.3. Création d'une carte de configuration à partir de valeurs littérales
Copier lien

Vous pouvez fournir des valeurs littérales pour une carte de configuration.

Procédure

L'option --from-literal utilise une syntaxe key=value qui permet de fournir des valeurs littérales directement sur la ligne de commande.

Créer une carte de configuration en spécifiant une valeur littérale :

oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm

$ oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm

Copy to Clipboard

Toggle word wrap

Vérifier les résultats :

oc get configmaps special-config -o yaml

$ oc get configmaps special-config -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

2.8.4. Cas d'utilisation : Consommer des cartes de configuration dans les pods
Copier lien

Les sections suivantes décrivent quelques cas d'utilisation des objets ConfigMap dans les pods.

2.8.4.1. Remplir les variables d'environnement dans les conteneurs à l'aide de cartes de configuration
Copier lien

Les cartes de configuration peuvent être utilisées pour remplir des variables d'environnement individuelles dans des conteneurs ou pour remplir des variables d'environnement dans des conteneurs à partir de toutes les clés qui forment des noms de variables d'environnement valides.

Prenons l'exemple de la carte de configuration suivante :

ConfigMap avec deux variables d'environnement

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config 
  namespace: default 
data:
  special.how: very 
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config


  namespace: default


data:
  special.how: very


  special.type: charm

Copy to Clipboard

Toggle word wrap

1: Nom de la carte de configuration.
2: Le projet dans lequel se trouve la carte de configuration. Les cartes de configuration ne peuvent être référencées que par les pods du même projet.
3 4: Variables d'environnement à injecter.

ConfigMap avec une variable d'environnement

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config 
  namespace: default
data:
  log_level: INFO

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config


  namespace: default
data:
  log_level: INFO

Copy to Clipboard

Toggle word wrap

1: Nom de la carte de configuration.
2: Variable d'environnement à injecter.

Procédure

Vous pouvez consommer les clés de ce ConfigMap dans un pod en utilisant les sections configMapKeyRef.

Exemple de spécification Pod configurée pour injecter des variables d'environnement spécifiques

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env: 
        - name: SPECIAL_LEVEL_KEY 
          valueFrom:
            configMapKeyRef:
              name: special-config 
              key: special.how 
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config 
              key: special.type 
              optional: true 
      envFrom: 
        - configMapRef:
            name: env-config 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:


        - name: SPECIAL_LEVEL_KEY


          valueFrom:
            configMapKeyRef:
              name: special-config


              key: special.how


        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config


              key: special.type


              optional: true


      envFrom:


        - configMapRef:
            name: env-config


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Stanza pour extraire les variables d'environnement spécifiées d'un site ConfigMap.
2: Nom de la variable d'environnement du pod dans laquelle vous injectez la valeur de la clé.
3 5: Nom de l'adresse ConfigMap à partir de laquelle des variables d'environnement spécifiques doivent être extraites.
4 6: Variable d'environnement à extraire de ConfigMap.
7: Rend la variable d'environnement facultative. En tant qu'optionnel, le pod sera démarré même si les ConfigMap et les clés spécifiés n'existent pas.
8: Stanza pour extraire toutes les variables d'environnement d'un site ConfigMap.
9: Nom de l'adresse ConfigMap à partir de laquelle toutes les variables d'environnement doivent être extraites.

Lorsque ce module est exécuté, les journaux du module incluent la sortie suivante :

SPECIAL_LEVEL_KEY=very
log_level=INFO

SPECIAL_LEVEL_KEY=very
log_level=INFO

Copy to Clipboard

Toggle word wrap

Note

SPECIAL_TYPE_KEY=charm n'est pas listé dans l'exemple de sortie car optional: true est activé.

2.8.4.2. Définition des arguments de ligne de commande pour les commandes de conteneurs avec les cartes de configuration
Copier lien

Une carte de configuration peut également être utilisée pour définir la valeur des commandes ou des arguments dans un conteneur. Pour ce faire, on utilise la syntaxe de substitution de Kubernetes $(VAR_NAME). Considérons la carte de configuration suivante :

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Copy to Clipboard

Toggle word wrap

Procédure

Pour injecter des valeurs dans une commande dans un conteneur, vous devez consommer les clés que vous souhaitez utiliser comme variables d'environnement, comme dans le cas d'utilisation de ConfigMaps dans des variables d'environnement. Vous pouvez ensuite y faire référence dans la commande d'un conteneur à l'aide de la syntaxe $(VAR_NAME).

Exemple de spécification Pod configurée pour injecter des variables d'environnement spécifiques

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] 
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]


      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Injectez les valeurs dans une commande dans un conteneur en utilisant les clés que vous souhaitez utiliser comme variables d'environnement.

Lorsque ce module est exécuté, la sortie de la commande echo exécutée dans le conteneur test-container est la suivante :

very charm

very charm

Copy to Clipboard

Toggle word wrap

2.8.4.3. Injecter du contenu dans un volume en utilisant des cartes de configuration
Copier lien

Vous pouvez injecter du contenu dans un volume en utilisant des cartes de configuration.

Exemple ConfigMap ressource personnalisée (CR)

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Copy to Clipboard

Toggle word wrap

Procédure

Vous disposez de plusieurs options pour injecter du contenu dans un volume à l'aide de cartes de configuration.

La façon la plus simple d'injecter du contenu dans un volume à l'aide d'une carte de configuration consiste à remplir le volume avec des fichiers dont la clé est le nom et le contenu la valeur de la clé :

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Fichier contenant la clé.

Lorsque ce pod est exécuté, la sortie de la commande cat sera la suivante :

very

very

Copy to Clipboard

Toggle word wrap

Vous pouvez également contrôler les chemins à l'intérieur du volume où les clés de configuration sont projetées :

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: Chemin d'accès à la clé de la carte de configuration.

Lorsque ce pod est exécuté, la sortie de la commande cat sera la suivante :

very

very

Copy to Clipboard

Toggle word wrap

2.9. Utilisation de plugins de périphériques pour accéder à des ressources externes avec des pods
Copier lien

Les plugins de périphériques vous permettent d'utiliser un type de périphérique particulier (GPU, InfiniBand, ou d'autres ressources informatiques similaires qui nécessitent une initialisation et une configuration spécifiques au fournisseur) dans votre pod OpenShift Container Platform sans avoir besoin d'écrire du code personnalisé.

2.9.1. Comprendre les plugins d'appareils
Copier lien

Le plugin device fournit une solution cohérente et portable pour consommer des périphériques matériels à travers les clusters. Le plugin device fournit un support pour ces dispositifs à travers un mécanisme d'extension, qui rend ces dispositifs disponibles pour les conteneurs, fournit des contrôles de santé de ces dispositifs, et les partage de manière sécurisée.

Important

OpenShift Container Platform prend en charge l'API du plugin de périphérique, mais les conteneurs de plugin de périphérique sont pris en charge par des fournisseurs individuels.

Un plugin de périphérique est un service gRPC fonctionnant sur les nœuds (en dehors du site kubelet) et chargé de gérer des ressources matérielles spécifiques. Tout plugin de périphérique doit prendre en charge les appels de procédure à distance (RPC) suivants :

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as reseting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as reseting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}

Copy to Clipboard

Toggle word wrap

Exemples de plugins d'appareils

Note

Pour faciliter la mise en œuvre de la référence du plugin de périphérique, il existe un plugin de périphérique fictif dans le code du gestionnaire de périphériques : vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go.

2.9.1.1. Méthodes de déploiement d'un module d'extension de dispositif
Copier lien

Les ensembles de démons constituent l'approche recommandée pour les déploiements de plugins de périphériques.
Au démarrage, le plugin de périphérique essaiera de créer un socket de domaine UNIX à l'adresse /var/lib/kubelet/device-plugin/ sur le nœud pour servir les RPC du gestionnaire de périphériques.
Comme les plugins de périphérique doivent gérer les ressources matérielles, l'accès au système de fichiers de l'hôte, ainsi que la création de sockets, ils doivent être exécutés dans un contexte de sécurité privilégié.
Des détails plus spécifiques concernant les étapes de déploiement peuvent être trouvés avec chaque implémentation de plugin d'appareil.

2.9.2. Comprendre le gestionnaire de périphériques
Copier lien

Device Manager fournit un mécanisme pour annoncer les ressources matérielles spécialisées des nœuds à l'aide de plugins connus sous le nom de "device plugins".

Vous pouvez annoncer du matériel spécialisé sans avoir à modifier le code en amont.

Important

OpenShift Container Platform prend en charge l'API du plugin de périphérique, mais les conteneurs de plugin de périphérique sont pris en charge par des fournisseurs individuels.

Le gestionnaire de dispositifs annonce les dispositifs en tant que Extended Resources. Les pods utilisateurs peuvent consommer les dispositifs annoncés par le Device Manager en utilisant le même mécanisme Limit/Request que celui utilisé pour demander n'importe quel autre Extended Resource.

Au démarrage, le plugin de périphérique s'enregistre auprès du gestionnaire de périphériques en invoquant Register sur l'adresse /var/lib/kubelet/device-plugins/kubelet.sock et lance un service gRPC à l'adresse /var/lib/kubelet/device-plugins/<plugin>.sock pour répondre aux demandes du gestionnaire d'appareils.

Lors du traitement d'une nouvelle demande d'enregistrement, le gestionnaire de périphérique invoque l'appel de procédure à distance (RPC) ListAndWatch auprès du service d'extension de périphérique. En réponse, le gestionnaire de périphérique obtient une liste d'objets Device du plugin via un flux gRPC. Le gestionnaire de périphérique surveillera le flux pour les nouvelles mises à jour du module d'extension. Du côté du plugin, le plugin gardera également le flux ouvert et chaque fois qu'il y a un changement dans l'état de l'un des appareils, une nouvelle liste d'appareils est envoyée au gestionnaire de périphériques via la même connexion de flux.

Lors du traitement d'une nouvelle demande d'admission d'un pod, Kubelet transmet la demande Extended Resources au Device Manager pour l'attribution d'un dispositif. Le gestionnaire de périphériques vérifie dans sa base de données si un plugin correspondant existe ou non. Si le plugin existe et qu'il y a des dispositifs allouables libres ainsi que dans le cache local, Allocate RPC est invoqué au niveau de ce plugin de dispositif particulier.

En outre, les plugins d'appareil peuvent également effectuer plusieurs autres opérations spécifiques à l'appareil, telles que l'installation du pilote, l'initialisation de l'appareil et la réinitialisation de l'appareil. Ces fonctionnalités varient d'une implémentation à l'autre.

2.9.3. Activation du gestionnaire de périphériques
Copier lien

Permettre au gestionnaire de périphériques de mettre en œuvre un plugin de périphérique pour annoncer du matériel spécialisé sans aucune modification du code en amont.

Device Manager fournit un mécanisme pour annoncer les ressources matérielles spécialisées des nœuds à l'aide de plugins connus sous le nom de "device plugins".

Obtenez l'étiquette associée au CRD statique MachineConfigPool pour le type de nœud que vous souhaitez configurer en entrant la commande suivante. Effectuez l'une des étapes suivantes :
1. Voir la configuration de la machine :
  # oc describe machineconfig <name>
  Copy to Clipboard Toggle word wrap
  Par exemple :
  # oc describe machineconfig 00-worker
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  Name: 00-worker Namespace: Labels: machineconfiguration.openshift.io/role=worker
  1
  
  Copy to Clipboard Toggle word wrap
  1
  Étiquette requise pour le gestionnaire de périphériques.

Procédure

Créez une ressource personnalisée (CR) pour votre changement de configuration.

Exemple de configuration pour un gestionnaire de périphérique CR

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr 
spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr 
  kubeletConfig:
    feature-gates:
      - DevicePlugins=true

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr


spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr


  kubeletConfig:
    feature-gates:
      - DevicePlugins=true

Copy to Clipboard

Toggle word wrap

1: Attribuer un nom au CR.
2: Saisissez l'étiquette du pool de configuration de la machine.
3: Définissez DevicePlugins sur "true".

Créer le gestionnaire de périphériques :

oc create -f devicemgr.yaml

$ oc create -f devicemgr.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

kubeletconfig.machineconfiguration.openshift.io/devicemgr created

kubeletconfig.machineconfiguration.openshift.io/devicemgr created

Copy to Clipboard

Toggle word wrap

Assurez-vous que le gestionnaire de périphériques a bien été activé en confirmant que l'option /var/lib/kubelet/device-plugins/kubelet.sock est créé sur le nœud. Il s'agit du socket de domaine UNIX sur lequel le serveur gRPC du Device Manager écoute les nouveaux enregistrements de plugins. Ce fichier sock est créé au démarrage de la Kubelet uniquement si Device Manager est activé.

2.10. Prise en compte de la priorité des pods dans les décisions d'ordonnancement des pods
Copier lien

Vous pouvez activer la priorité et la préemption des pods dans votre cluster. La priorité des pods indique l'importance d'un pod par rapport aux autres pods et met les pods en file d'attente en fonction de cette priorité. La préemption des pods permet au cluster d'expulser, ou de préempter, les pods de priorité inférieure afin que les pods de priorité supérieure puissent être planifiés s'il n'y a pas d'espace disponible sur un nœud approprié. La priorité des pods affecte également l'ordre de planification des pods et l'ordre d'expulsion en cas d'absence de ressources sur le nœud.

Pour utiliser la priorité et la préemption, vous devez créer des classes de priorité qui définissent le poids relatif de vos modules. Ensuite, faites référence à une classe de priorité dans la spécification du pod pour appliquer ce poids à la planification.

2.10.1. Comprendre la priorité des pods
Copier lien

Lorsque vous utilisez la fonctionnalité de priorité et de préemption des pods, l'ordonnanceur classe les pods en attente en fonction de leur priorité, et un pod en attente est placé devant d'autres pods en attente ayant une priorité inférieure dans la file d'attente d'ordonnancement. Par conséquent, le pod le plus prioritaire peut être programmé plus tôt que les pods moins prioritaires si ses besoins de programmation sont satisfaits. Si un module ne peut pas être programmé, l'ordonnanceur continue à programmer d'autres modules moins prioritaires.

2.10.1.1. Classes de priorité pour les pods
Copier lien

Vous pouvez attribuer aux pods une classe de priorité, qui est un objet sans espace de noms définissant une correspondance entre un nom et la valeur entière de la priorité. Plus la valeur est élevée, plus la priorité est importante.

Un objet de classe de priorité peut prendre n'importe quelle valeur entière de 32 bits inférieure ou égale à 1000000000 (un milliard). Réservez les nombres supérieurs ou égaux à un milliard aux pods critiques qui ne doivent pas être préemptés ou évincés. Par défaut, OpenShift Container Platform a deux classes de priorité réservées pour les pods système critiques afin de garantir l'ordonnancement.

oc get priorityclasses

$ oc get priorityclasses

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s

Copy to Clipboard

Toggle word wrap

system-node-critical - Cette classe de priorité a une valeur de 2000001000 et est utilisée pour tous les pods qui ne doivent jamais être expulsés d'un nœud. Les exemples de pods ayant cette classe de priorité sont sdn-ovs, sdn, et ainsi de suite. Un certain nombre de composants critiques incluent la classe de priorité system-node-critical par défaut, par exemple :
- master-api
- maître-contrôleur
- master-etcd
- sdn
- sdn-ovs
- synchronisation
system-cluster-critical - Cette classe de priorité a une valeur de 2000000000 (deux milliards) et est utilisée avec les pods qui sont importants pour le cluster. Les modules de cette classe de priorité peuvent être expulsés d'un nœud dans certaines circonstances. Par exemple, les modules configurés avec la classe de priorité system-node-critical peuvent être prioritaires. Toutefois, cette classe de priorité garantit la planification. Les pods qui peuvent avoir cette classe de priorité sont par exemple fluentd, des composants complémentaires comme descheduler, etc. Un certain nombre de composants critiques incluent la classe de priorité system-cluster-critical par défaut, par exemple :
- fluentd
- serveur de métrologie
- déscheduler
openshift-user-critical - Vous pouvez utiliser le champ priorityClassName avec des pods importants qui ne peuvent pas lier leur consommation de ressources et qui n'ont pas de comportement prévisible en matière de consommation de ressources. Les pods Prometheus sous les espaces de noms openshift-monitoring et openshift-user-workload-monitoring utilisent le champ openshift-user-critical priorityClassName . Les charges de travail de surveillance utilisent system-critical comme premier priorityClass, mais cela pose des problèmes lorsque la surveillance utilise trop de mémoire et que les nœuds ne peuvent pas les expulser. Par conséquent, la surveillance perd sa priorité pour donner de la flexibilité au planificateur, qui déplace les charges de travail lourdes pour maintenir les nœuds critiques en fonctionnement.
cluster-logging - Cette priorité est utilisée par Fluentd pour s'assurer que les pods Fluentd sont programmés sur les nœuds avant les autres applications.

2.10.1.2. Noms de priorité des pods
Copier lien

Une fois que vous avez une ou plusieurs classes de priorité, vous pouvez créer des pods qui spécifient un nom de classe de priorité dans une spécification Pod. Le contrôleur d'admission des priorités utilise le champ du nom de la classe de priorité pour remplir la valeur entière de la priorité. Si la classe de priorité nommée n'est pas trouvée, le pod est rejeté.

2.10.2. Comprendre la préemption des pods
Copier lien

Lorsqu'un développeur crée un module, celui-ci est placé dans une file d'attente. Si le développeur a configuré le module pour une priorité ou une préemption, l'ordonnanceur sélectionne un module dans la file d'attente et tente de le programmer sur un nœud. Si l'ordonnanceur ne trouve pas d'espace sur un nœud approprié qui réponde à toutes les exigences du module, la logique de préemption est déclenchée pour le module en attente.

Lorsque l'ordonnanceur préempte un ou plusieurs pods sur un nœud, le champ nominatedNodeName du spec Pod de priorité supérieure est défini sur le nom du nœud, ainsi que sur le champ nodename. L'ordonnanceur utilise le champ nominatedNodeName pour garder une trace des ressources réservées aux pods et fournit également des informations à l'utilisateur sur les préemptions dans les clusters.

Une fois que l'ordonnanceur a préempté un module de priorité inférieure, il respecte la période de terminaison gracieuse du module. Si un autre nœud devient disponible pendant que l'ordonnanceur attend la fin du pod de priorité inférieure, l'ordonnanceur peut programmer le pod de priorité supérieure sur ce nœud. Par conséquent, les champs nominatedNodeName et nodeName de la spécification Pod peuvent être différents.

De même, si l'ordonnanceur préempte des pods sur un nœud et attend la fin, et qu'un pod ayant une priorité plus élevée que le pod en attente doit être programmé, l'ordonnanceur peut programmer le pod ayant la priorité la plus élevée à la place. Dans ce cas, l'ordonnanceur efface le site nominatedNodeName du pod en attente, rendant le pod éligible pour un autre nœud.

La préemption ne supprime pas nécessairement tous les modules de priorité inférieure d'un nœud. L'ordonnanceur peut programmer un module en attente en supprimant une partie des modules de priorité inférieure.

L'ordonnanceur ne considère un nœud pour la préemption de pods que si le pod en attente peut être programmé sur le nœud.

2.10.2.1. Classes de priorité non prioritaires (Technology Preview)
Copier lien

Les modules dont la politique de préemption est définie sur Never sont placés dans la file d'attente d'ordonnancement avant les modules de priorité inférieure, mais ils ne peuvent pas préempter d'autres modules. Un pod non préempté en attente d'ordonnancement reste dans la file d'attente d'ordonnancement jusqu'à ce que des ressources suffisantes soient disponibles et qu'il puisse être ordonnancé. Les modules non préemptés, comme les autres modules, sont soumis à l'arrêt de l'ordonnanceur. Cela signifie que si l'ordonnanceur tente sans succès de programmer ces modules, ils sont relancés à une fréquence moindre, ce qui permet à d'autres modules moins prioritaires d'être programmés avant eux.

Les pods non préemptés peuvent toujours être préemptés par d'autres pods à priorité élevée.

2.10.2.2. Préemption des pods et autres paramètres de l'ordonnanceur
Copier lien

Si vous activez la priorité et la préemption des pods, tenez compte des autres paramètres de votre ordonnanceur :

Priorité aux pods et budget de perturbation des pods: Un budget d'interruption de pod spécifie le nombre ou le pourcentage minimum de répliques qui doivent être opérationnelles à un moment donné. Si vous spécifiez des budgets de perturbation de pods, OpenShift Container Platform les respecte lors de la préemption de pods à un niveau de meilleur effort. L'ordonnanceur tente de préempter des pods sans violer le budget de perturbation des pods. Si aucun pod n'est trouvé, les pods de priorité inférieure peuvent être préemptés malgré leurs exigences en matière de budget de perturbation des pods.
Priorité et affinité des pods: L'affinité des pods exige qu'un nouveau pod soit programmé sur le même nœud que d'autres pods ayant la même étiquette.

Si un pod en attente a une affinité inter-pods avec un ou plusieurs pods de priorité inférieure sur un nœud, l'ordonnanceur ne peut pas préempter les pods de priorité inférieure sans violer les exigences d'affinité. Dans ce cas, l'ordonnanceur recherche un autre nœud pour planifier le module en attente. Cependant, il n'est pas garanti que l'ordonnanceur puisse trouver un nœud approprié et le module en attente peut ne pas être programmé.

Pour éviter cette situation, configurez soigneusement l'affinité des pods avec des pods de priorité égale.

2.10.2.3. Fin gracieuse des pods préemptés
Copier lien

Lorsqu'il préempte un module, l'ordonnanceur attend l'expiration de la période de terminaison gracieuse du module, ce qui permet au module de terminer son travail et de quitter le système. Si le module ne se termine pas à l'issue de cette période, l'ordonnanceur tue le module. Ce délai d'expiration crée un décalage entre le moment où l'ordonnanceur préempte le module et le moment où le module en attente peut être programmé sur le nœud.

Pour réduire cet écart, configurez une petite période de terminaison gracieuse pour les pods de moindre priorité.

2.10.3. Configuration de la priorité et de la préemption
Copier lien

Vous appliquez la priorité et la préemption des pods en créant un objet de classe de priorité et en associant les pods à la priorité à l'aide de priorityClassName dans vos spécifications Pod.

Exemple d'objet de classe de priorité

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority 
value: 1000000 
preemptionPolicy: PreemptLowerPriority 
globalDefault: false 
description: "This priority class should be used for XYZ service pods only."

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority


value: 1000000


preemptionPolicy: PreemptLowerPriority


globalDefault: false


description: "This priority class should be used for XYZ service pods only."

Copy to Clipboard

Toggle word wrap

1: Le nom de l'objet de la classe de priorité.
2: La valeur de priorité de l'objet.
3: Champ facultatif indiquant si cette classe de priorité est préemptable ou non préemptable. La politique de préemption est définie par défaut sur PreemptLowerPriority, ce qui permet aux pods de cette classe de priorité de préempter les pods de priorité inférieure. Si la politique de préemption est définie sur Never, les pods de cette classe de priorité ne sont pas préemptés.
4: Champ facultatif indiquant si cette classe de priorité doit être utilisée pour les pods sans nom de classe de priorité spécifié. Ce champ vaut false par défaut. Il ne peut y avoir qu'une seule classe de priorité avec globalDefault défini sur true dans le cluster. S'il n'y a pas de classe de priorité avec globalDefault:true, la priorité des modules sans nom de classe de priorité est zéro. L'ajout d'une classe de priorité avec globalDefault:true n'affecte que les modules créés après l'ajout de la classe de priorité et ne modifie pas les priorités des modules existants.
5: Chaîne de texte arbitraire facultative décrivant les pods que les développeurs doivent utiliser avec cette classe de priorité.

Procédure

Pour configurer votre cluster afin d'utiliser la priorité et la préemption :

Créer une ou plusieurs classes de priorité :
1. Spécifiez un nom et une valeur pour la priorité.
2. Il est possible de spécifier le champ globalDefault dans la classe de priorité et une description.

Créez un spec Pod ou modifiez les pods existants pour inclure le nom d'une classe de priorité, comme suit :

Exemple de Pod spec avec le nom de la classe de priorité

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

Copy to Clipboard

Toggle word wrap

1: Spécifiez la classe de priorité à utiliser avec ce pod.

Créer la capsule :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap
Vous pouvez ajouter le nom de la priorité directement à la configuration du module ou à un modèle de module.

2.11. Placer des pods sur des nœuds spécifiques en utilisant des sélecteurs de nœuds
Copier lien

Un site node selector spécifie une carte de paires clé-valeur. Les règles sont définies à l'aide d'étiquettes personnalisées sur les nœuds et de sélecteurs spécifiés dans les pods.

Pour qu'un module puisse être exécuté sur un nœud, les paires clé-valeur indiquées doivent figurer sur l'étiquette du nœud.

Si vous utilisez l'affinité de nœuds et les sélecteurs de nœuds dans la même configuration de pods, consultez les considérations importantes ci-dessous.

2.11.1. Utilisation de sélecteurs de nœuds pour contrôler le placement des pods
Copier lien

Vous pouvez utiliser des sélecteurs de nœuds sur les pods et des étiquettes sur les nœuds pour contrôler l'endroit où le pod est planifié. Avec les sélecteurs de nœuds, OpenShift Container Platform planifie les pods sur les nœuds qui contiennent les étiquettes correspondantes.

Vous ajoutez des étiquettes à un nœud, à un ensemble de machines de calcul ou à une configuration de machine. L'ajout de l'étiquette à l'ensemble de machines de calcul garantit que si le nœud ou la machine tombe en panne, les nouveaux nœuds disposent de l'étiquette. Les étiquettes ajoutées à un nœud ou à une configuration de machine ne persistent pas si le nœud ou la machine tombe en panne.

Pour ajouter des sélecteurs de nœuds à un module existant, ajoutez un sélecteur de nœuds à l'objet de contrôle de ce module, tel que l'objet ReplicaSet, l'objet DaemonSet, l'objet StatefulSet, l'objet Deployment ou l'objet DeploymentConfig. Tous les modules existants sous cet objet de contrôle sont recréés sur un nœud avec une étiquette correspondante. Si vous créez un nouveau module, vous pouvez ajouter le sélecteur de nœud directement à la spécification Pod.

Note

Vous ne pouvez pas ajouter un sélecteur de nœud directement à un module planifié existant.

Conditions préalables

Pour ajouter un sélecteur de nœud à des modules existants, déterminez l'objet de contrôle de ce module. Par exemple, le module router-default-66d5cf9464-m2g75 est contrôlé par l'ensemble de répliques router-default-66d5cf9464:

oc describe pod router-default-66d5cf9464-7pwkc

Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress

....

Controlled By:      ReplicaSet/router-default-66d5cf9464

$ oc describe pod router-default-66d5cf9464-7pwkc

Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress

....

Controlled By:      ReplicaSet/router-default-66d5cf9464

Copy to Clipboard

Toggle word wrap

La console web liste l'objet de contrôle sous ownerReferences dans le pod YAML :

  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true

  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true

Copy to Clipboard

Toggle word wrap

Procédure

Ajoutez des étiquettes à un nœud en utilisant un ensemble de machines de calcul ou en éditant le nœud directement :

Utilisez un objet MachineSet pour ajouter des étiquettes aux nœuds gérés par l'ensemble de machines de calcul lors de la création d'un nœud :

Exécutez la commande suivante pour ajouter des étiquettes à un objet MachineSet:

oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Par exemple :

oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

$ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter des étiquettes à un ensemble de machines de calcul :

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées à l'objet MachineSet en utilisant la commande oc edit:

Par exemple :

oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Exemple d'objet MachineSet

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

....

spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
....

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

....

spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
....

Copy to Clipboard

Toggle word wrap

Ajouter des étiquettes directement à un nœud :

Modifiez l'objet Node pour le nœud :

oc label nodes <name> <key>=<value>

$ oc label nodes <name> <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple, pour étiqueter un nœud :

oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

$ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le langage YAML suivant pour ajouter des étiquettes à un nœud :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées au nœud :

oc get nodes -l type=user-node,region=east

$ oc get nodes -l type=user-node,region=east

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.25.0

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.25.0

Copy to Clipboard

Toggle word wrap

Ajouter le sélecteur de nœud correspondant à un pod :

Pour ajouter un sélecteur de nœud aux modules existants et futurs, ajoutez un sélecteur de nœud à l'objet de contrôle des modules :

Exemple ReplicaSet objet avec étiquettes

kind: ReplicaSet

....

spec:

....

  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node

kind: ReplicaSet

....

spec:

....

  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node

Copy to Clipboard

Toggle word wrap

1: Ajouter le sélecteur de nœud.

Pour ajouter un sélecteur de nœud à un nouveau pod spécifique, ajoutez le sélecteur à l'objet Pod directement :
Exemple d'objet Pod avec un sélecteur de nœud
```
apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:
    region: east
    type: user-node
```
```
apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:
    region: east
    type: user-node
```
Copy to Clipboard Toggle word wrap
Note
Vous ne pouvez pas ajouter un sélecteur de nœud directement à un module planifié existant.

Chapitre 3. Contrôle du placement des pods sur les nœuds (scheduling)
Copier lien

3.1. Contrôler le placement des pods à l'aide de l'ordonnanceur
Copier lien

L'ordonnancement des pods est un processus interne qui détermine le placement des nouveaux pods sur les nœuds du cluster.

Le code de l'ordonnanceur a une séparation propre qui observe les nouveaux pods lorsqu'ils sont créés et identifie le nœud le plus approprié pour les héberger. Il crée ensuite des liens (liens entre le pod et le nœud) pour les pods à l'aide de l'API principale.

Ordonnancement par défaut des pods

OpenShift Container Platform est livré avec un planificateur par défaut qui répond aux besoins de la plupart des utilisateurs. Le planificateur par défaut utilise à la fois des outils inhérents et des outils de personnalisation pour déterminer ce qui convient le mieux à un pod.

Programmation avancée des nacelles

Dans les situations où vous souhaiteriez avoir plus de contrôle sur l'emplacement des nouveaux pods, les fonctionnalités de planification avancées d'OpenShift Container Platform vous permettent de configurer un pod de manière à ce qu'il soit nécessaire ou qu'il ait une préférence pour s'exécuter sur un nœud particulier ou aux côtés d'un pod spécifique.

Vous pouvez contrôler le placement des pods en utilisant les fonctions de planification suivantes :

3.1.1. À propos de l'ordonnanceur par défaut
Copier lien

Le planificateur de pods par défaut d'OpenShift Container Platform est chargé de déterminer le placement des nouveaux pods sur les nœuds du cluster. Il lit les données du pod et trouve un nœud qui convient en fonction des profils configurés. Il est complètement indépendant et existe en tant que solution autonome. Il ne modifie pas le module ; il crée une liaison pour le module qui lie le module à un nœud particulier.

3.1.1.1. Comprendre la programmation par défaut
Copier lien

L'ordonnanceur générique existant est l'ordonnanceur par défaut fourni par la plateforme engine qui sélectionne un nœud pour héberger le module en trois étapes :

Filtre les nœuds: Les nœuds disponibles sont filtrés en fonction des contraintes ou des exigences spécifiées. Pour ce faire, chaque nœud est soumis à la liste des fonctions de filtrage appelée predicates, ou filters.
Hiérarchise la liste filtrée des nœuds: Pour ce faire, chaque nœud est soumis à une série de fonctions priority ou scoring, qui lui attribuent une note comprise entre 0 et 10, 0 indiquant une mauvaise adaptation et 10 une bonne adaptation à l'hébergement du module. La configuration de l'ordonnanceur peut également prendre en compte un simple weight (valeur numérique positive) pour chaque fonction d'évaluation. La note du nœud fournie par chaque fonction de notation est multipliée par le poids (le poids par défaut pour la plupart des notes est de 1), puis combinée en ajoutant les notes de chaque nœud fournies par toutes les notes. Cet attribut de poids peut être utilisé par les administrateurs pour donner plus d'importance à certaines notes.
Sélectionne le nœud le mieux adapté: Les nœuds sont triés en fonction de leur score et le nœud ayant le score le plus élevé est sélectionné pour héberger le pod. Si plusieurs nœuds ont le même score, l'un d'entre eux est choisi au hasard.

3.1.2. Cas d'utilisation de l'ordonnanceur
Copier lien

L'un des principaux cas d'utilisation de l'ordonnancement dans OpenShift Container Platform est la prise en charge de politiques d'affinité et d'anti-affinité flexibles.

3.1.2.1. Niveaux topologiques de l'infrastructure
Copier lien

Les administrateurs peuvent définir plusieurs niveaux topologiques pour leur infrastructure (nœuds) en spécifiant des étiquettes sur les nœuds. Par exemple : region=r1 zone=z1 , rack=s1.

Ces noms d'étiquettes n'ont pas de signification particulière et les administrateurs sont libres de donner n'importe quel nom à leurs niveaux d'infrastructure, par exemple ville/bâtiment/chambre. En outre, les administrateurs peuvent définir un nombre quelconque de niveaux pour leur topologie d'infrastructure, trois niveaux étant généralement suffisants (par exemple : regions → zones → racks). Les administrateurs peuvent spécifier des règles d'affinité et d'anti-affinité à chacun de ces niveaux, dans n'importe quelle combinaison.

3.1.2.2. Affinité
Copier lien

Les administrateurs doivent pouvoir configurer l'ordonnanceur pour spécifier l'affinité à n'importe quel niveau topologique, voire à plusieurs niveaux. L'affinité à un niveau particulier indique que tous les pods appartenant au même service sont programmés sur des nœuds appartenant au même niveau. Cela permet de répondre aux exigences de latence des applications en permettant aux administrateurs de s'assurer que les pods homologues ne sont pas trop éloignés géographiquement les uns des autres. Si aucun nœud n'est disponible dans le même groupe d'affinité pour héberger le module, celui-ci n'est pas planifié.

Si vous avez besoin d'un meilleur contrôle sur l'emplacement des pods, consultez les sections Contrôle du placement des pods sur les nœuds à l'aide des règles d'affinité des nœuds et Placement des pods par rapport à d'autres pods à l'aide des règles d'affinité et d'anti-affinité.

Ces fonctions de planification avancées permettent aux administrateurs de spécifier le nœud sur lequel un pod peut être planifié et de forcer ou de rejeter la planification par rapport à d'autres pods.

3.1.2.3. Anti-affinité
Copier lien

Les administrateurs doivent pouvoir configurer l'ordonnanceur pour spécifier l'anti-affinité à n'importe quel niveau topologique, voire à plusieurs niveaux. L'anti-affinité (ou la "répartition") à un niveau particulier indique que tous les pods qui appartiennent au même service sont répartis sur les nœuds qui appartiennent à ce niveau. Cela garantit que l'application est bien répartie à des fins de haute disponibilité. L'ordonnanceur tente d'équilibrer les modules de service sur tous les nœuds concernés de la manière la plus homogène possible.

3.2. Ordonnancement de pods à l'aide d'un profil d'ordonnateur
Copier lien

Vous pouvez configurer OpenShift Container Platform pour utiliser un profil de planification afin de planifier les pods sur les nœuds du cluster.

3.2.1. À propos des profils de l'ordonnanceur
Copier lien

Vous pouvez spécifier un profil de planificateur pour contrôler la manière dont les pods sont planifiés sur les nœuds.

Les profils de planificateur suivants sont disponibles :

LowNodeUtilization: Ce profil tente de répartir les pods de manière égale sur les nœuds afin d'obtenir une faible utilisation des ressources par nœud. Ce profil fournit le comportement par défaut de l'ordonnanceur.
HighNodeUtilization: Ce profil tente de placer le plus grand nombre de pods possible sur le plus petit nombre de nœuds possible. Cela minimise le nombre de nœuds et permet une utilisation élevée des ressources par nœud.
NoScoring: Il s'agit d'un profil à faible latence qui s'efforce d'obtenir le cycle de programmation le plus rapide en désactivant tous les plugins de score. Il se peut que de meilleures décisions de programmation soient sacrifiées au profit de décisions plus rapides.

3.2.2. Configuration d'un profil d'ordonnanceur
Copier lien

Vous pouvez configurer l'ordonnanceur pour qu'il utilise un profil d'ordonnanceur.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

Modifiez l'objet Scheduler:
```
oc edit scheduler cluster
```
```
$ oc edit scheduler cluster
```
Copy to Clipboard Toggle word wrap

Spécifiez le profil à utiliser dans le champ spec.profile:

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  ...
  name: cluster
  resourceVersion: "601"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: b351d6d0-d06f-4a99-a26b-87af62e79f59
spec:
  mastersSchedulable: false
  profile: HighNodeUtilization

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  ...
  name: cluster
  resourceVersion: "601"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: b351d6d0-d06f-4a99-a26b-87af62e79f59
spec:
  mastersSchedulable: false
  profile: HighNodeUtilization

Copy to Clipboard

Toggle word wrap

1: Régler sur LowNodeUtilization, HighNodeUtilization, ou NoScoring.

Enregistrez le fichier pour appliquer les modifications.

3.3. Placement de nacelles par rapport à d'autres nacelles à l'aide de règles d'affinité et d'anti-affinité
Copier lien

L'affinité est une propriété des modules qui contrôle les nœuds sur lesquels ils préfèrent être programmés. L'anti-affinité est une propriété des modules qui empêche un module d'être programmé sur un nœud.

Dans OpenShift Container Platform, pod affinity et pod anti-affinity vous permettent de limiter les nœuds sur lesquels votre pod peut être planifié en fonction des étiquettes clé/valeur des autres pods.

3.3.1. Comprendre l'affinité des pods
Copier lien

Pod affinity et pod anti-affinity vous permettent de limiter les nœuds sur lesquels votre module peut être planifié en fonction des étiquettes clé/valeur des autres modules.

L'affinité de pod peut indiquer à l'ordonnanceur de placer un nouveau pod sur le même nœud que d'autres pods si le sélecteur d'étiquette du nouveau pod correspond à l'étiquette du pod actuel.
L'anti-affinité des pods peut empêcher l'ordonnanceur de localiser un nouveau pod sur le même nœud que les pods ayant les mêmes étiquettes si le sélecteur d'étiquette du nouveau pod correspond à l'étiquette du pod actuel.

Par exemple, les règles d'affinité permettent de répartir ou de regrouper les modules au sein d'un service ou par rapport aux modules d'autres services. Les règles anti-affinité vous permettent d'empêcher les pods d'un service particulier d'être planifiés sur les mêmes nœuds que les pods d'un autre service dont on sait qu'ils interfèrent avec les performances des pods du premier service. Vous pouvez également répartir les modules d'un service entre les nœuds, les zones de disponibilité ou les ensembles de disponibilité afin de réduire les défaillances corrélées.

Note

Un sélecteur d'étiquettes peut faire correspondre des pods avec plusieurs déploiements de pods. Utilisez des combinaisons uniques d'étiquettes lors de la configuration des règles d'anti-affinité afin d'éviter de faire correspondre les pods.

Il existe deux types de règles d'affinité pour les pods : required et preferred.

Les règles obligatoires must doivent être respectées pour qu'un pod puisse être programmé sur un nœud. Les règles préférentielles précisent que, si la règle est respectée, l'ordonnanceur tente de l'appliquer, mais ne la garantit pas.

Note

En fonction des paramètres de priorité et de préemption des modules, il se peut que l'ordonnanceur ne soit pas en mesure de trouver un nœud approprié pour un module sans enfreindre les exigences d'affinité. Dans ce cas, il se peut qu'un module ne soit pas planifié.

Pour éviter cette situation, configurez soigneusement l'affinité des pods avec des pods de priorité égale.

Vous configurez l'affinité/anti-affinité des pods par le biais des fichiers spec de Pod. Vous pouvez spécifier une règle obligatoire, une règle préférentielle ou les deux. Si vous spécifiez les deux, le nœud doit d'abord satisfaire à la règle requise, puis tente de satisfaire à la règle préférée.

L'exemple suivant montre une spécification Pod configurée pour l'affinité et l'anti-affinité des pods.

Dans cet exemple, la règle d'affinité des pods indique que le pod ne peut être programmé sur un nœud que si ce nœud possède au moins un pod déjà en cours d'exécution dont l'étiquette a la clé security et la valeur S1. La règle d'anti-affinité du pod indique que le pod préfère ne pas être programmé sur un nœud si ce nœud exécute déjà un pod avec une étiquette ayant la clé security et la valeur S2.

Exemple de fichier de configuration Pod avec pod affinity

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution: 
      - labelSelector:
          matchExpressions:
          - key: security 
            operator: In 
            values:
            - S1 
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:


      requiredDuringSchedulingIgnoredDuringExecution:


      - labelSelector:
          matchExpressions:
          - key: security


            operator: In


            values:
            - S1


        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

1: Stanza pour configurer l'affinité des pods.
2: Définit une règle obligatoire.
3 5: La clé et la valeur (étiquette) qui doivent correspondre pour appliquer la règle.
4: L'opérateur représente la relation entre l'étiquette de la capsule existante et l'ensemble des valeurs des paramètres matchExpression dans la spécification de la nouvelle capsule. Il peut s'agir de In, NotIn, Exists ou DoesNotExist.

Exemple de fichier de configuration Pod avec pod anti-affinité

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 
      preferredDuringSchedulingIgnoredDuringExecution: 
      - weight: 100  
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security 
              operator: In 
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity:


      preferredDuringSchedulingIgnoredDuringExecution:


      - weight: 100


        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security


              operator: In


              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

1: Stanza pour configurer l'anti-affinité du pod.
2: Définit une règle préférentielle.
3: Spécifie un poids pour une règle préférentielle. Le nœud ayant le poids le plus élevé est privilégié.
4: Description de l'étiquette du pod qui détermine quand la règle anti-affinité s'applique. Spécifiez une clé et une valeur pour l'étiquette.
5: L'opérateur représente la relation entre l'étiquette de la capsule existante et l'ensemble des valeurs des paramètres matchExpression dans la spécification de la nouvelle capsule. Il peut s'agir de In, NotIn, Exists ou DoesNotExist.

Note

Si les étiquettes d'un nœud changent au moment de l'exécution, de sorte que les règles d'affinité d'un module ne sont plus respectées, le module continue de fonctionner sur le nœud.

3.3.2. Configuration d'une règle d'affinité pour les pods
Copier lien

Les étapes suivantes illustrent une configuration simple à deux pods qui crée un pod avec une étiquette et un pod qui utilise l'affinité pour permettre la planification avec ce pod.

Procédure

Créer un pod avec une étiquette spécifique dans la spécification Pod:

cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-s1
  labels:
    security: S1
spec:
  containers:
  - name: security-s1
    image: docker.io/ocpqe/hello-pod

$ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-s1
  labels:
    security: S1
spec:
  containers:
  - name: security-s1
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Lors de la création d'autres pods, modifiez la spécification Pod comme suit :
1. Utilisez la strophe podAffinity pour configurer le paramètre requiredDuringSchedulingIgnoredDuringExecution ou le paramètre preferredDuringSchedulingIgnoredDuringExecution:
2. Spécifiez la clé et la valeur qui doivent être respectées. Si vous souhaitez que le nouveau module soit programmé avec l'autre module, utilisez les mêmes paramètres key et value que l'étiquette du premier module.
  podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone
  Copy to Clipboard Toggle word wrap
3. operatorL'opérateur peut être In, NotIn, Exists ou DoesNotExist. Par exemple, utilisez l'opérateur In pour exiger que l'étiquette soit dans le nœud.
4. Spécifiez un topologyKey, qui est un label Kubernetes prérempli que le système utilise pour désigner un tel domaine topologique.
Créer la capsule.
```
oc create -f <pod-spec>.yaml
```
```
oc create -f <pod-spec>.yaml
```
Copy to Clipboard Toggle word wrap

3.3.3. Configuration d'une règle d'anti-affinité pour les pods
Copier lien

Les étapes suivantes illustrent une configuration simple à deux pods qui crée un pod avec une étiquette et un pod qui utilise une règle préférentielle anti-affinité pour tenter d'empêcher l'ordonnancement avec ce pod.

Procédure

Créer un pod avec une étiquette spécifique dans la spécification Pod:

$ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-s2
  labels:
    security: S2
spec:
  containers:
  - name: security-s2
    image: docker.io/ocpqe/hello-pod

$ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-s2
  labels:
    security: S2
spec:
  containers:
  - name: security-s2
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Lorsque vous créez d'autres pods, modifiez la spécification Pod pour définir les paramètres suivants :

Utilisez la strophe podAntiAffinity pour configurer le paramètre requiredDuringSchedulingIgnoredDuringExecution ou le paramètre preferredDuringSchedulingIgnoredDuringExecution:

Spécifiez un poids pour le nœud, de 1 à 100. Le nœud ayant le poids le plus élevé est privilégié.

Spécifiez la clé et les valeurs qui doivent être respectées. Si vous souhaitez que le nouveau module ne soit pas programmé avec l'autre module, utilisez les mêmes paramètres key et value que l'étiquette du premier module.

    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname

    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname

Copy to Clipboard

Toggle word wrap

Pour une règle préférentielle, spécifiez un poids, 1-100.
operatorL'opérateur peut être In, NotIn, Exists ou DoesNotExist. Par exemple, utilisez l'opérateur In pour exiger que l'étiquette soit dans le nœud.

Spécifiez un topologyKey, qui est un label Kubernetes prérempli que le système utilise pour désigner un tel domaine topologique.
Créer la capsule.
```
oc create -f <pod-spec>.yaml
```
```
oc create -f <pod-spec>.yaml
```
Copy to Clipboard Toggle word wrap

3.3.4. Exemple de règles d'affinité et d'anti-affinité pour les pods
Copier lien

Les exemples suivants illustrent l'affinité et l'anti-affinité des pods.

3.3.4.1. Pod Affinity
Copier lien

L'exemple suivant illustre l'affinité des pods avec des étiquettes et des sélecteurs d'étiquettes correspondants.

Le pod team4 porte l'étiquette team:4.

cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: team4
  labels:
     team: "4"
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod

$ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: team4
  labels:
     team: "4"
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Le pod team4a a le sélecteur d'étiquettes team:4 sous podAffinity.

$ cat pod-team4a.yaml
apiVersion: v1
kind: Pod
metadata:
  name: team4a
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: team
            operator: In
            values:
            - "4"
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod

$ cat pod-team4a.yaml
apiVersion: v1
kind: Pod
metadata:
  name: team4a
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: team
            operator: In
            values:
            - "4"
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Le module team4a est programmé sur le même nœud que le module team4.

3.3.4.2. Pod Anti-affinité
Copier lien

L'exemple suivant illustre l'anti-affinité des pods pour les pods dont les étiquettes et les sélecteurs d'étiquettes correspondent.

Le pod pod-s1 porte l'étiquette security:s1.

cat pod-s1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod

cat pod-s1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Le pod pod-s2 a le sélecteur d'étiquettes security:s1 sous podAntiAffinity.

cat pod-s2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s1
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-antiaffinity
    image: docker.io/ocpqe/hello-pod

cat pod-s2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s1
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-antiaffinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Le pod pod-s2 ne peut pas être programmé sur le même nœud que pod-s1.

3.3.4.3. Affinité podale sans étiquettes correspondantes
Copier lien

L'exemple suivant illustre l'affinité des pods pour les pods ne correspondant pas aux étiquettes et aux sélecteurs d'étiquettes.

Le pod pod-s1 porte l'étiquette security:s1.

cat pod-s1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod

$ cat pod-s1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Le pod pod-s2 possède le sélecteur d'étiquettes security:s2.

cat pod-s2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s2
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod

$ cat pod-s2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s2
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

Le pod pod-s2 n'est pas planifié à moins qu'il n'y ait un nœud avec un pod ayant le label security:s2. S'il n'y a pas d'autre pod avec ce label, le nouveau pod reste en attente :
Exemple de sortie
```
NAME      READY     STATUS    RESTARTS   AGE       IP        NODE
pod-s2    0/1       Pending   0          32s       <none>
```
```
NAME      READY     STATUS    RESTARTS   AGE       IP        NODE
pod-s2    0/1       Pending   0          32s       <none>
```
Copy to Clipboard Toggle word wrap

3.3.5. Utilisation de l'affinité et de l'anti-affinité du pod pour contrôler l'endroit où un opérateur est installé
Copier lien

Par défaut, lorsque vous installez un Operator, OpenShift Container Platform installe le pod Operator sur l'un de vos nœuds de travail de manière aléatoire. Cependant, il peut y avoir des situations où vous voulez que ce pod soit planifié sur un nœud spécifique ou un ensemble de nœuds.

Les exemples suivants décrivent des situations dans lesquelles vous pourriez vouloir planifier un pod opérateur sur un nœud ou un ensemble de nœuds spécifique :

Si un opérateur a besoin d'une plateforme particulière, telle que amd64 ou arm64
Si un opérateur nécessite un système d'exploitation particulier, tel que Linux ou Windows
Si vous souhaitez que les opérateurs qui travaillent ensemble soient programmés sur le même hôte ou sur des hôtes situés sur le même rack
Si vous souhaitez que les opérateurs soient dispersés dans l'infrastructure afin d'éviter les temps d'arrêt dus à des problèmes de réseau ou de matériel

Vous pouvez contrôler l'endroit où un pod d'opérateur est installé en ajoutant une affinité ou une anti-affinité de pod à l'objet Subscription de l'opérateur.

L'exemple suivant montre comment utiliser l'anti-affinité des pods pour empêcher l'installation de Custom Metrics Autoscaler Operator à partir de n'importe quel nœud ayant des pods avec une étiquette spécifique :

Exemple d'affinité de pod qui place le pod de l'opérateur sur un ou plusieurs nœuds spécifiques

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAffinity: 
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test
          topologyKey: kubernetes.io/hostname

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAffinity:


        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test
          topologyKey: kubernetes.io/hostname

Copy to Clipboard

Toggle word wrap

1: Une affinité de pod qui place le pod de l'opérateur sur un nœud qui a des pods avec le label app=test.

Exemple d'anti-affinité de pods qui empêche le pod Operator d'accéder à un ou plusieurs nœuds spécifiques

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity: 
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: cpu
              operator: In
              values:
              - high
          topologyKey: kubernetes.io/hostname
 ...

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity:


        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: cpu
              operator: In
              values:
              - high
          topologyKey: kubernetes.io/hostname
 ...

Copy to Clipboard

Toggle word wrap

1: Une anti-affinité de pods qui empêche le pod de l'opérateur d'être planifié sur un nœud qui a des pods avec le label cpu=high.

Procédure

Pour contrôler l'emplacement d'une nacelle d'opérateur, procédez comme suit :

Installez l'opérateur comme d'habitude.
Si nécessaire, assurez-vous que vos nœuds sont étiquetés de manière à répondre correctement à l'affinité.

Modifiez l'objet Operator Subscription pour ajouter une affinité :

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity: 
        requiredDuringSchedulingIgnoredDuringExecution:
          podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - ip-10-0-185-229.ec2.internal
            topologyKey: topology.kubernetes.io/zone
 ...

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity:


        requiredDuringSchedulingIgnoredDuringExecution:
          podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - ip-10-0-185-229.ec2.internal
            topologyKey: topology.kubernetes.io/zone
 ...

Copy to Clipboard

Toggle word wrap

1: Ajouter un podAffinity ou un podAntiAffinity.

Vérification

Pour s'assurer que le pod est déployé sur le nœud spécifique, exécutez la commande suivante :

oc get pods -o wide

$ oc get pods -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>

NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>

Copy to Clipboard

Toggle word wrap

3.4. Contrôle du placement des pods sur les nœuds à l'aide de règles d'affinité des nœuds
Copier lien

L'affinité est une propriété des pods qui contrôle les nœuds sur lesquels ils préfèrent être programmés.

Dans OpenShift Container Platform, l'affinité des nœuds est un ensemble de règles utilisées par le planificateur pour déterminer où un pod peut être placé. Les règles sont définies à l'aide d'étiquettes personnalisées sur les nœuds et de sélecteurs d'étiquettes spécifiés dans les pods.

3.4.1. Comprendre l'affinité des nœuds
Copier lien

L'affinité de nœud permet à un pod de spécifier une affinité envers un groupe de nœuds sur lesquels il peut être placé. Le nœud n'a pas de contrôle sur le placement.

Par exemple, vous pouvez configurer un module pour qu'il ne s'exécute que sur un nœud doté d'une unité centrale spécifique ou dans une zone de disponibilité spécifique.

Il existe deux types de règles d'affinité entre les nœuds : required et preferred.

Note

Si les étiquettes d'un nœud changent au moment de l'exécution et que la règle d'affinité d'un nœud pour un module n'est plus respectée, le module continue de fonctionner sur le nœud.

Vous configurez l'affinité des nœuds par le biais du fichier Pod spec. Vous pouvez spécifier une règle obligatoire, une règle préférentielle ou les deux. Si vous spécifiez les deux, le nœud doit d'abord satisfaire à la règle requise, puis tente de satisfaire à la règle préférée.

L'exemple suivant est une spécification Pod avec une règle qui exige que le pod soit placé sur un nœud avec une étiquette dont la clé est e2e-az-NorthSouth et dont la valeur est soit e2e-az-North soit e2e-az-South:

Exemple de fichier de configuration d'un pod avec une règle d'affinité de nœud requise

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution: 
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-NorthSouth 
            operator: In 
            values:
            - e2e-az-North 
            - e2e-az-South 
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:


      requiredDuringSchedulingIgnoredDuringExecution:


        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-NorthSouth


            operator: In


            values:
            - e2e-az-North


            - e2e-az-South


  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

1: La strophe pour configurer l'affinité des nœuds.
2: Définit une règle obligatoire.
3 5 6: La paire clé/valeur (étiquette) qui doit être prise en compte pour appliquer la règle.
4: L'opérateur représente la relation entre l'étiquette du nœud et l'ensemble des valeurs des paramètres matchExpression dans la spécification Pod. Cette valeur peut être In, NotIn, Exists, ou DoesNotExist, Lt, ou Gt.

L'exemple suivant est une spécification de nœud avec une règle de préférence selon laquelle un nœud avec une étiquette dont la clé est e2e-az-EastWest et dont la valeur est soit e2e-az-East soit e2e-az-West est préféré pour le pod :

Exemple de fichier de configuration d'un pod avec une règle préférentielle d'affinité de nœud

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 
      preferredDuringSchedulingIgnoredDuringExecution: 
      - weight: 1 
        preference:
          matchExpressions:
          - key: e2e-az-EastWest 
            operator: In 
            values:
            - e2e-az-East 
            - e2e-az-West 
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:


      preferredDuringSchedulingIgnoredDuringExecution:


      - weight: 1


        preference:
          matchExpressions:
          - key: e2e-az-EastWest


            operator: In


            values:
            - e2e-az-East


            - e2e-az-West


  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

1: La strophe pour configurer l'affinité des nœuds.
2: Définit une règle préférentielle.
3: Spécifie un poids pour une règle préférentielle. Le nœud ayant le poids le plus élevé est privilégié.
4 6 7: La paire clé/valeur (étiquette) qui doit être prise en compte pour appliquer la règle.
5: L'opérateur représente la relation entre l'étiquette du nœud et l'ensemble des valeurs des paramètres matchExpression dans la spécification Pod. Cette valeur peut être In, NotIn, Exists, ou DoesNotExist, Lt, ou Gt.

Il n'existe pas de concept explicite node anti-affinity, mais l'utilisation de l'opérateur NotIn ou DoesNotExist reproduit ce comportement.

Note

Si vous utilisez l'affinité de nœuds et les sélecteurs de nœuds dans la même configuration de pods, notez ce qui suit :

Si vous configurez à la fois nodeSelector et nodeAffinity, les deux conditions doivent être remplies pour que le pod soit planifié sur un nœud candidat.
Si vous spécifiez plusieurs nodeSelectorTerms associés à des types nodeAffinity, le module peut être programmé sur un nœud si l'un des nodeSelectorTerms est satisfait.
Si vous spécifiez plusieurs matchExpressions associés à nodeSelectorTerms, le module ne peut être programmé sur un nœud que si tous les matchExpressions sont satisfaits.

3.4.2. Configuration d'une règle d'affinité de nœud requise
Copier lien

Les règles requises must doivent être respectées avant qu'un pod puisse être programmé sur un nœud.

Procédure

Les étapes suivantes présentent une configuration simple qui crée un nœud et un module que l'ordonnanceur doit placer sur le nœud.

Ajoutez une étiquette à un nœud à l'aide de la commande oc label node:

oc label node node1 e2e-az-name=e2e-az1

$ oc label node node1 e2e-az-name=e2e-az1

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le code YAML suivant pour ajouter l'étiquette :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    e2e-az-name: e2e-az1

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    e2e-az-name: e2e-az1

Copy to Clipboard

Toggle word wrap

Dans la spécification Pod, utilisez la strophe nodeAffinity pour configurer le paramètre requiredDuringSchedulingIgnoredDuringExecution:

Spécifiez la clé et les valeurs qui doivent être respectées. Si vous souhaitez que le nouveau module soit planifié sur le nœud que vous avez modifié, utilisez les mêmes paramètres key et value que l'étiquette du nœud.

operatorL'opérateur peut être In, NotIn, Exists, DoesNotExist, Lt ou Gt. Par exemple, utilisez l'opérateur In pour exiger que l'étiquette soit dans le nœud :

Exemple de sortie

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2

Copy to Clipboard

Toggle word wrap

Créer la capsule :
```
oc create -f e2e-az2.yaml
```
```
$ oc create -f e2e-az2.yaml
```
Copy to Clipboard Toggle word wrap

3.4.3. Configuration d'une règle d'affinité pour les nœuds préférés
Copier lien

Les règles préférentielles précisent que, si la règle est respectée, l'ordonnanceur tente d'appliquer les règles, mais n'en garantit pas l'application.

Procédure

Les étapes suivantes présentent une configuration simple qui crée un nœud et un module que l'ordonnanceur tente de placer sur le nœud.

Ajoutez une étiquette à un nœud à l'aide de la commande oc label node:
```
oc label node node1 e2e-az-name=e2e-az3
```
```
$ oc label node node1 e2e-az-name=e2e-az3
```
Copy to Clipboard Toggle word wrap
Dans la spécification Pod, utilisez la strophe nodeAffinity pour configurer le paramètre preferredDuringSchedulingIgnoredDuringExecution:
1. Spécifiez un poids pour le nœud, sous la forme d'un nombre de 1 à 100. Le nœud ayant le poids le plus élevé est privilégié.
2. Spécifiez la clé et les valeurs qui doivent être respectées. Si vous souhaitez que le nouveau module soit planifié sur le nœud que vous avez modifié, utilisez les mêmes paramètres key et value que l'étiquette du nœud :
  spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: e2e-az-name operator: In values: - e2e-az3
  Copy to Clipboard Toggle word wrap
3. operatorL'opérateur peut être In, NotIn, Exists, DoesNotExist, Lt ou Gt. Par exemple, utilisez l'opérateur In pour exiger que l'étiquette soit dans le nœud.
Créer la capsule.
```
oc create -f e2e-az3.yaml
```
```
$ oc create -f e2e-az3.yaml
```
Copy to Clipboard Toggle word wrap

3.4.4. Exemple de règles d'affinité entre les nœuds
Copier lien

Les exemples suivants illustrent l'affinité entre les nœuds.

3.4.4.1. Affinité des nœuds avec les étiquettes correspondantes
Copier lien

L'exemple suivant illustre l'affinité d'un nœud et d'un module avec des étiquettes correspondantes :

Le nœud Node1 porte l'étiquette zone:us:
```
oc label node node1 zone=us
```
```
$ oc label node node1 zone=us
```
Copy to Clipboard Toggle word wrap
Astuce
Vous pouvez également appliquer le code YAML suivant pour ajouter l'étiquette :
kind: Node apiVersion: v1 metadata: name: <node_name> labels: zone: us
Copy to Clipboard Toggle word wrap

Le pod-s1 possède la paire clé/valeur zone et us en vertu d'une règle d'affinité de nœud requise :

cat pod-s1.yaml

$ cat pod-s1.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: "zone"
              operator: In
              values:
              - us

apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: "zone"
              operator: In
              values:
              - us

Copy to Clipboard

Toggle word wrap

Le pod-s1 peut être programmé sur le nœud 1 :

oc get pod -o wide

$ oc get pod -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME     READY     STATUS       RESTARTS   AGE      IP      NODE
pod-s1   1/1       Running      0          4m       IP1     node1

NAME     READY     STATUS       RESTARTS   AGE      IP      NODE
pod-s1   1/1       Running      0          4m       IP1     node1

Copy to Clipboard

Toggle word wrap

3.4.4.2. Affinité des nœuds sans étiquettes correspondantes
Copier lien

L'exemple suivant illustre l'affinité de nœud pour un nœud et un module sans étiquettes correspondantes :

Le nœud Node1 porte l'étiquette zone:emea:

oc label node node1 zone=emea

$ oc label node node1 zone=emea

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le code YAML suivant pour ajouter l'étiquette :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    zone: emea

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    zone: emea

Copy to Clipboard

Toggle word wrap

Le pod-s1 possède la paire clé/valeur zone et us en vertu d'une règle d'affinité de nœud requise :

cat pod-s1.yaml

$ cat pod-s1.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: "zone"
              operator: In
              values:
              - us

apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: "zone"
              operator: In
              values:
              - us

Copy to Clipboard

Toggle word wrap

Le pod-s1 ne peut pas être planifié sur le nœud 1 :

oc describe pod pod-s1

$ oc describe pod pod-s1

Copy to Clipboard

Toggle word wrap

Exemple de sortie

...

Events:
 FirstSeen LastSeen Count From              SubObjectPath  Type                Reason
 --------- -------- ----- ----              -------------  --------            ------
 1m        33s      8     default-scheduler Warning        FailedScheduling    No nodes are available that match all of the following predicates:: MatchNodeSelector (1).

...

Events:
 FirstSeen LastSeen Count From              SubObjectPath  Type                Reason
 --------- -------- ----- ----              -------------  --------            ------
 1m        33s      8     default-scheduler Warning        FailedScheduling    No nodes are available that match all of the following predicates:: MatchNodeSelector (1).

Copy to Clipboard

Toggle word wrap

3.4.5. Utilisation de l'affinité des nœuds pour contrôler l'emplacement d'installation d'un opérateur
Copier lien

Les exemples suivants décrivent des situations dans lesquelles vous pourriez vouloir planifier un pod opérateur sur un nœud ou un ensemble de nœuds spécifique :

Si un opérateur a besoin d'une plateforme particulière, telle que amd64 ou arm64
Si un opérateur nécessite un système d'exploitation particulier, tel que Linux ou Windows
Si vous souhaitez que les opérateurs qui travaillent ensemble soient programmés sur le même hôte ou sur des hôtes situés sur le même rack
Si vous souhaitez que les opérateurs soient dispersés dans l'infrastructure afin d'éviter les temps d'arrêt dus à des problèmes de réseau ou de matériel

Vous pouvez contrôler l'endroit où un pod d'opérateur est installé en ajoutant des contraintes d'affinité de nœud à l'objet Subscription de l'opérateur.

Les exemples suivants montrent comment utiliser l'affinité entre les nœuds pour installer une instance de Custom Metrics Autoscaler Operator sur un nœud spécifique de la grappe :

Exemple d'affinité de nœud qui place le pod de l'opérateur sur un nœud spécifique

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-163-94.us-west-2.compute.internal
 ...

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity:


        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-163-94.us-west-2.compute.internal
 ...

Copy to Clipboard

Toggle word wrap

1: Une affinité de nœud qui exige que le pod de l'opérateur soit programmé sur un nœud nommé ip-10-0-163-94.us-west-2.compute.internal.

Exemple d'affinité de nœud qui place le pod de l'opérateur sur un nœud avec une plate-forme spécifique

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
            - key: kubernetes.io/os
              operator: In
              values:
              - linux

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity:


        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
            - key: kubernetes.io/os
              operator: In
              values:
              - linux

Copy to Clipboard

Toggle word wrap

1: Une affinité de nœud qui exige que le pod de l'opérateur soit programmé sur un nœud avec les étiquettes kubernetes.io/arch=arm64 et kubernetes.io/os=linux.

Procédure

Pour contrôler l'emplacement d'une nacelle d'opérateur, procédez comme suit :

Installez l'opérateur comme d'habitude.
Si nécessaire, assurez-vous que vos nœuds sont étiquetés de manière à répondre correctement à l'affinité.

Modifiez l'objet Operator Subscription pour ajouter une affinité :

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity: 
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-185-229.ec2.internal
 ...

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:


      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-185-229.ec2.internal
 ...

Copy to Clipboard

Toggle word wrap

1: Ajouter un nodeAffinity.

Vérification

Pour s'assurer que le pod est déployé sur le nœud spécifique, exécutez la commande suivante :

oc get pods -o wide

$ oc get pods -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>

NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>

Copy to Clipboard

Toggle word wrap

3.5. Placer des pods sur des nœuds sur-engagés
Copier lien

Dans l'état overcommited, la somme des demandes et des limites des ressources de calcul du conteneur dépasse les ressources disponibles sur le système. Le surengagement peut être souhaitable dans les environnements de développement où un compromis entre les performances garanties et la capacité est acceptable.

Les demandes et les limites permettent aux administrateurs d'autoriser et de gérer le surengagement des ressources sur un nœud. L'ordonnanceur utilise les demandes pour planifier votre conteneur et fournir une garantie de service minimum. Les limites restreignent la quantité de ressources de calcul qui peuvent être consommées sur votre nœud.

3.5.1. Comprendre le surengagement
Copier lien

Les administrateurs d'OpenShift Container Platform peuvent contrôler le niveau de surengagement et gérer la densité des conteneurs sur les nœuds en configurant les maîtres pour remplacer le rapport entre la demande et la limite définie sur les conteneurs de développement. En conjonction avec un objet LimitRange par projet spécifiant les limites et les valeurs par défaut, cela ajuste la limite et la demande du conteneur pour atteindre le niveau souhaité de surengagement.

Note

Ces dérogations n'ont aucun effet si aucune limite n'a été fixée pour les conteneurs. Créez un objet LimitRange avec des limites par défaut, par projet individuel ou dans le modèle de projet, pour vous assurer que les dérogations s'appliquent.

Après ces dérogations, les limites et les demandes des conteneurs doivent toujours être validées par tout objet LimitRange dans le projet. Il est possible, par exemple, que les développeurs spécifient une limite proche de la limite minimale, et que la demande soit ensuite remplacée en dessous de la limite minimale, ce qui entraînerait l'interdiction du pod. Cette expérience malheureuse devrait être résolue dans le cadre de travaux futurs, mais pour l'instant, il convient de configurer cette capacité et les objets LimitRange avec prudence.

3.5.2. Comprendre le surengagement des nœuds
Copier lien

Dans un environnement surchargé, il est important de configurer correctement votre nœud afin d'obtenir le meilleur comportement possible du système.

Lorsque le nœud démarre, il s'assure que les drapeaux ajustables du noyau pour la gestion de la mémoire sont correctement définis. Le noyau ne devrait jamais échouer dans l'allocation de la mémoire à moins qu'il ne soit à court de mémoire physique.

Pour garantir ce comportement, OpenShift Container Platform configure le noyau pour qu'il surengage toujours de la mémoire en définissant le paramètre vm.overcommit_memory sur 1, ce qui annule le paramètre par défaut du système d'exploitation.

OpenShift Container Platform configure également le noyau pour qu'il ne panique pas lorsqu'il manque de mémoire en définissant le paramètre vm.panic_on_oom sur 0. Un paramètre de 0 indique au noyau d'appeler oom_killer dans une condition de manque de mémoire (OOM), ce qui tue les processus en fonction de leur priorité

Vous pouvez afficher le paramètre actuel en exécutant les commandes suivantes sur vos nœuds :

sysctl -a |grep commit

$ sysctl -a |grep commit

Copy to Clipboard

Toggle word wrap

Exemple de sortie

vm.overcommit_memory = 1

vm.overcommit_memory = 1

Copy to Clipboard

Toggle word wrap

sysctl -a |grep panic

$ sysctl -a |grep panic

Copy to Clipboard

Toggle word wrap

Exemple de sortie

vm.panic_on_oom = 0

vm.panic_on_oom = 0

Copy to Clipboard

Toggle word wrap

Note

Les drapeaux ci-dessus devraient déjà être activés sur les nœuds, et aucune autre action n'est nécessaire.

Vous pouvez également effectuer les configurations suivantes pour chaque nœud :

Désactiver ou appliquer les limites de l'unité centrale à l'aide des quotas CFS de l'unité centrale
Réserver des ressources pour les processus du système
Réserve de mémoire pour les différents niveaux de qualité de service

3.6. Contrôle du placement de pods à l'aide de taches de nœuds
Copier lien

Les taches et les tolérances permettent au nœud de contrôler quels pods doivent (ou ne doivent pas) être programmés sur eux.

3.6.1. Comprendre les taches et les tolérances
Copier lien

Un taint permet à un nœud de refuser qu'un module soit programmé à moins que ce module n'ait un toleration correspondant.

Vous appliquez des taches à un nœud par le biais de la spécification Node (NodeSpec) et vous appliquez des tolérances à un pod par le biais de la spécification Pod (PodSpec). Lorsque vous appliquez une tare à un nœud, l'ordonnanceur ne peut pas placer un module sur ce nœud à moins que le module ne puisse tolérer la tare.

Exemple d'altération dans la spécification d'un nœud

spec:
  taints:
  - effect: NoExecute
    key: key1
    value: value1
....

spec:
  taints:
  - effect: NoExecute
    key: key1
    value: value1
....

Copy to Clipboard

Toggle word wrap

Exemple de tolérance dans une spécification Pod

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600
....

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600
....

Copy to Clipboard

Toggle word wrap

Les plaintes et les tolérances se composent d'une clé, d'une valeur et d'un effet.

Expand

Paramètres Description

key

Le site key est une chaîne de caractères quelconque, d'une longueur maximale de 253 caractères. La clé doit commencer par une lettre ou un chiffre et peut contenir des lettres, des chiffres, des traits d'union, des points et des traits de soulignement.

value

Le site value est une chaîne de caractères de 63 caractères maximum. La valeur doit commencer par une lettre ou un chiffre et peut contenir des lettres, des chiffres, des traits d'union, des points et des traits de soulignement.

effect

L'effet est l'un des suivants :

Expand

`NoSchedule` ^[1]	Les nouveaux pods qui ne correspondent pas à l'altération ne sont pas programmés sur ce nœud. Les pods existants sur le nœud sont conservés.
`PreferNoSchedule`	Les nouveaux pods qui ne correspondent pas à l'altération peuvent être programmés sur ce nœud, mais l'ordonnanceur essaie de ne pas le faire. Les pods existants sur le nœud sont conservés.
`NoExecute`	Les nouveaux pods qui ne correspondent pas à l'altération ne peuvent pas être programmés sur ce nœud. Les pods existants sur le nœud qui n'ont pas de tolérance correspondante sont supprimés.

operator

Expand

`Equal`	Les paramètres `key`/`value`/`effect` doivent correspondre. Il s'agit de la valeur par défaut.
`Exists`	Les paramètres `key`/`effect` doivent correspondre. Vous devez laisser vide le paramètre `value`, qui correspond à n'importe quel paramètre.

Si vous ajoutez une erreur NoSchedule à un nœud du plan de contrôle, le nœud doit avoir l'erreur node-role.kubernetes.io/master=:NoSchedule, qui est ajoutée par défaut.

Par exemple :

apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...

apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...

Copy to Clipboard

Toggle word wrap

Une tolérance correspond à une souillure :

Si le paramètre operator est réglé sur Equal:
- les paramètres de key sont les mêmes ;
- les paramètres de value sont les mêmes ;
- les paramètres de effect sont les mêmes.
Si le paramètre operator est réglé sur Exists:
- les paramètres de key sont les mêmes ;
- les paramètres de effect sont les mêmes.

Les plaintes suivantes sont intégrées à OpenShift Container Platform :

node.kubernetes.io/not-ready: Le nœud n'est pas prêt. Cela correspond à la condition du nœud Ready=False.
node.kubernetes.io/unreachable: Le nœud est inaccessible depuis le contrôleur de nœud. Cela correspond à l'état du nœud Ready=Unknown.
node.kubernetes.io/memory-pressure: Le nœud a des problèmes de pression de mémoire. Cela correspond à la condition du nœud MemoryPressure=True.
node.kubernetes.io/disk-pressure: Le nœud a des problèmes de pression de disque. Cela correspond à l'état du nœud DiskPressure=True.
node.kubernetes.io/network-unavailable: Le réseau du nœud est indisponible.
node.kubernetes.io/unschedulable: Le nœud n'est pas ordonnançable.
node.cloudprovider.kubernetes.io/uninitialized: Lorsque le contrôleur de nœuds est démarré avec un fournisseur de nuage externe, cette altération est définie sur un nœud pour le marquer comme inutilisable. Après qu'un contrôleur du cloud-controller-manager initialise ce nœud, le kubelet supprime cette taint.
node.kubernetes.io/pid-pressure: Le nœud a un pid de pression. Cela correspond à la condition du nœud PIDPressure=True.
Important
OpenShift Container Platform ne définit pas de pid par défaut.available evictionHard.

3.6.1.1. Comprendre comment utiliser les secondes de tolérance pour retarder les expulsions de nacelles
Copier lien

Vous pouvez spécifier la durée pendant laquelle un pod peut rester lié à un nœud avant d'être expulsé en spécifiant le paramètre tolerationSeconds dans la spécification Pod ou l'objet MachineSet. Si une altération ayant l'effet NoExecute est ajoutée à un nœud, un module qui tolère l'altération, qui a le paramètre tolerationSeconds, le module n'est pas expulsé avant l'expiration de ce délai.

Exemple de sortie

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600

Copy to Clipboard

Toggle word wrap

Ici, si ce pod est en cours d'exécution mais n'a pas de tolérance correspondante, le pod reste lié au nœud pendant 3 600 secondes avant d'être expulsé. Si l'altération est supprimée avant ce délai, le module n'est pas expulsé.

3.6.1.2. Comprendre comment utiliser des teintes multiples
Copier lien

Vous pouvez placer plusieurs taints sur le même nœud et plusieurs tolérances sur le même pod. OpenShift Container Platform traite les plaintes et tolérances multiples de la manière suivante :

Traiter les plaintes pour lesquelles le pod a une tolérance correspondante.
Les autres souillures non appariées ont les effets indiqués sur la cosse :
- S'il y a au moins une taint non appariée avec l'effet NoSchedule, OpenShift Container Platform ne peut pas planifier un pod sur ce nœud.
- S'il n'y a pas de taint non apparié avec l'effet NoSchedule mais qu'il y a au moins un taint non apparié avec l'effet PreferNoSchedule, OpenShift Container Platform essaie de ne pas planifier le pod sur le nœud.
- S'il y a au moins une taint non appariée avec l'effet NoExecute, OpenShift Container Platform expulse le pod du nœud s'il est déjà en cours d'exécution sur le nœud, ou le pod n'est pas planifié sur le nœud s'il n'est pas encore en cours d'exécution sur le nœud.
  - Les pods qui ne tolèrent pas la souillure sont immédiatement expulsés.
  - Les pods qui tolèrent l'altération sans spécifier tolerationSeconds dans leur spécification Pod restent liés pour toujours.
  - Les pods qui tolèrent l'altération à l'aide d'une adresse tolerationSeconds spécifiée restent liés pendant la durée spécifiée.

Par exemple :

Ajoutez au nœud les taches suivantes :

oc adm taint nodes node1 key1=value1:NoSchedule

$ oc adm taint nodes node1 key1=value1:NoSchedule

Copy to Clipboard

Toggle word wrap

oc adm taint nodes node1 key1=value1:NoExecute

$ oc adm taint nodes node1 key1=value1:NoExecute

Copy to Clipboard

Toggle word wrap

oc adm taint nodes node1 key2=value2:NoSchedule

$ oc adm taint nodes node1 key2=value2:NoSchedule

Copy to Clipboard

Toggle word wrap

Les tolérances suivantes s'appliquent à la nacelle :

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"

Copy to Clipboard

Toggle word wrap

Dans ce cas, le module ne peut pas être programmé sur le nœud, car il n'y a pas de tolérance correspondant à la troisième tare. Le module continue de fonctionner s'il est déjà en cours d'exécution sur le nœud lorsque la tare est ajoutée, car la troisième tare est la seule des trois qui n'est pas tolérée par le module.

3.6.1.3. Comprendre l'ordonnancement des pods et les conditions des nœuds (taint node by condition)
Copier lien

La fonction d'altération des nœuds par condition, activée par défaut, altère automatiquement les nœuds qui signalent des conditions telles que la pression de la mémoire et la pression du disque. Lorsqu'un nœud signale une condition, une erreur est ajoutée jusqu'à ce que la condition disparaisse. Les taches ont l'effet NoSchedule, ce qui signifie qu'aucun pod ne peut être planifié sur le nœud à moins que le pod n'ait une tolérance correspondante.

L'ordonnanceur vérifie la présence de ces anomalies sur les nœuds avant de planifier les modules. Si l'erreur est présente, le module est planifié sur un nœud différent. Comme l'ordonnanceur vérifie les anomalies et non les conditions réelles des nœuds, vous pouvez configurer l'ordonnanceur pour qu'il ignore certaines de ces conditions en ajoutant des tolérances appropriées pour les nœuds.

Pour assurer la compatibilité ascendante, le contrôleur de jeu de démons ajoute automatiquement les tolérances suivantes à tous les démons :

node.kubernetes.io/memory-pressure
node.kubernetes.io/disk-pressure
node.kubernetes.io/unschedulable (1.10 ou ultérieur)
node.kubernetes.io/network-unavailable (réseau hôte uniquement)

Vous pouvez également ajouter des tolérances arbitraires aux ensembles de démons.

Note

Le plan de contrôle ajoute également la tolérance node.kubernetes.io/memory-pressure sur les pods qui ont une classe QoS. En effet, Kubernetes gère les pods dans les classes de QoS Guaranteed ou Burstable. Les nouveaux pods BestEffort ne sont pas planifiés sur le nœud affecté.

3.6.1.4. Comprendre l'éviction des pods par condition (évictions basées sur les taches)
Copier lien

La fonction Taint-Based Evictions, qui est activée par défaut, expulse les pods d'un nœud qui présente des conditions spécifiques, telles que not-ready et unreachable. Lorsqu'un nœud est confronté à l'une de ces conditions, OpenShift Container Platform ajoute automatiquement des taints au nœud et commence à expulser et à replanifier les pods sur différents nœuds.

Les évictions basées sur l'altération ont un effet NoExecute, où tout pod qui ne tolère pas l'altération est évincé immédiatement et tout pod qui tolère l'altération ne sera jamais évincé, à moins que le pod n'utilise le paramètre tolerationSeconds.

Le paramètre tolerationSeconds vous permet de spécifier la durée pendant laquelle un pod reste lié à un nœud qui a une condition de nœud. Si la condition existe toujours après la période tolerationSeconds, l'altération reste sur le nœud et les pods avec une tolérance correspondante sont expulsés. Si la condition disparaît avant la période tolerationSeconds, les pods avec les tolérances correspondantes ne sont pas supprimés.

Si vous utilisez le paramètre tolerationSeconds sans valeur, les pods ne sont jamais expulsés en raison des conditions "not ready" et "unreachable node".

Note

OpenShift Container Platform évince les pods de manière limitée afin d'éviter les évictions massives de pods dans des scénarios tels que la partition du maître par rapport aux nœuds.

Par défaut, si plus de 55 % des nœuds d'une zone donnée sont malsains, le contrôleur du cycle de vie des nœuds fait passer l'état de cette zone à PartialDisruption et le taux d'expulsion des pods est réduit. Pour les petits clusters (par défaut, 50 nœuds ou moins) dans cet état, les nœuds de cette zone ne sont pas altérés et les expulsions sont arrêtées.

Pour plus d'informations, voir Rate limits on eviction dans la documentation Kubernetes.

OpenShift Container Platform ajoute automatiquement une tolérance pour node.kubernetes.io/not-ready et node.kubernetes.io/unreachable avec tolerationSeconds=300, à moins que la configuration Pod ne spécifie l'une ou l'autre tolérance.

spec:
  tolerations:
  - key: node.kubernetes.io/not-ready
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300 
  - key: node.kubernetes.io/unreachable
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300

spec:
  tolerations:
  - key: node.kubernetes.io/not-ready
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300


  - key: node.kubernetes.io/unreachable
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300

Copy to Clipboard

Toggle word wrap

1: Ces tolérances garantissent que le comportement par défaut du pod est de rester lié pendant cinq minutes après la détection d'un de ces problèmes de conditions de nœuds.

Vous pouvez configurer ces tolérances selon vos besoins. Par exemple, si vous avez une application avec beaucoup d'état local, vous pourriez vouloir garder les pods liés au nœud plus longtemps en cas de partition du réseau, ce qui permettrait à la partition de se rétablir et d'éviter l'éviction des pods.

Les pods générés par un ensemble de démons sont créés avec des tolérances de NoExecute pour les taches suivantes, sans tolerationSeconds:

node.kubernetes.io/unreachable
node.kubernetes.io/not-ready

Par conséquent, les pods de l'ensemble des démons ne sont jamais expulsés en raison de ces conditions de nœuds.

3.6.1.5. Tolérer toutes les tares
Copier lien

Vous pouvez configurer un pod pour qu'il tolère toutes les plaintes en ajoutant une tolérance operator: "Exists" sans paramètres key et value. Les pods ayant cette tolérance ne sont pas retirés d'un nœud qui a des taches.

Pod spécification pour la tolérance de toutes les taches

spec:
  tolerations:
  - operator: "Exists"

spec:
  tolerations:
  - operator: "Exists"

Copy to Clipboard

Toggle word wrap

3.6.2. Ajout de taches et de tolérances
Copier lien

Vous ajoutez des tolérances aux modules et des taches aux nœuds pour permettre au nœud de contrôler les modules qui doivent ou ne doivent pas être planifiés sur eux. Pour les pods et les nœuds existants, vous devez d'abord ajouter la tolérance au pod, puis ajouter la taint au nœud afin d'éviter que les pods ne soient retirés du nœud avant que vous ne puissiez ajouter la tolérance.

Procédure

Ajouter une tolérance à un pod en modifiant la spécification Pod pour y inclure une strophe tolerations:
Exemple de fichier de configuration d'un pod avec un opérateur Equal
```
spec:
  tolerations:
  - key: "key1" 
    value: "value1"
    operator: "Equal"
    effect: "NoExecute"
    tolerationSeconds: 3600 
```
```
spec:
  tolerations:
  - key: "key1" 
```
1
```
    value: "value1"
    operator: "Equal"
    effect: "NoExecute"
    tolerationSeconds: 3600 
```
2
Copy to Clipboard Toggle word wrap
1
Les paramètres de tolérance, tels que décrits dans le tableau Taint and toleration components.
2
Le paramètre tolerationSeconds indique la durée pendant laquelle un pod peut rester lié à un nœud avant d'être expulsé.
Par exemple :
Exemple de fichier de configuration d'un pod avec un opérateur Exists
```
spec:
   tolerations:
    - key: "key1"
      operator: "Exists" 
      effect: "NoExecute"
      tolerationSeconds: 3600
```
```
spec:
   tolerations:
    - key: "key1"
      operator: "Exists" 
```
1
```
      effect: "NoExecute"
      tolerationSeconds: 3600
```
Copy to Clipboard Toggle word wrap
1
L'opérateur Exists ne prend pas de value.
Cet exemple place une tare sur node1 qui a la clé key1, la valeur value1, et l'effet de tare NoExecute.

Ajoutez une tare à un nœud en utilisant la commande suivante avec les paramètres décrits dans le tableau Taint and toleration components:

oc adm taint nodes <node_name> <key>=<value>:<effect>

$ oc adm taint nodes <node_name> <key>=<value>:<effect>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc adm taint nodes node1 key1=value1:NoExecute

$ oc adm taint nodes node1 key1=value1:NoExecute

Copy to Clipboard

Toggle word wrap

Cette commande place une tare sur node1 qui a pour clé key1, pour valeur value1, et pour effet NoExecute.

Note

Si vous ajoutez une erreur NoSchedule à un nœud du plan de contrôle, le nœud doit avoir l'erreur node-role.kubernetes.io/master=:NoSchedule, qui est ajoutée par défaut.

Par exemple :

apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...

apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...

Copy to Clipboard

Toggle word wrap

Les tolérances du module correspondent à l'altération du nœud. Un pod avec l'une ou l'autre des tolérances peut être programmé sur node1.

3.6.2.1. Ajout de taches et de tolérances à l'aide d'un ensemble de machines de calcul
Copier lien

Vous pouvez ajouter des taches aux nœuds à l'aide d'un ensemble de machines de calcul. Tous les nœuds associés à l'objet MachineSet sont mis à jour avec l'erreur. Les tolérances réagissent aux taches ajoutées par un ensemble de machines de calcul de la même manière que les taches ajoutées directement aux nœuds.

Procédure

Ajouter une tolérance à un pod en modifiant la spécification Pod pour y inclure une strophe tolerations:
Exemple de fichier de configuration d'un pod avec l'opérateur Equal
```
spec:
  tolerations:
  - key: "key1" 
    value: "value1"
    operator: "Equal"
    effect: "NoExecute"
    tolerationSeconds: 3600 
```
```
spec:
  tolerations:
  - key: "key1" 
```
1
```
    value: "value1"
    operator: "Equal"
    effect: "NoExecute"
    tolerationSeconds: 3600 
```
2
Copy to Clipboard Toggle word wrap
1
Les paramètres de tolérance, tels que décrits dans le tableau Taint and toleration components.
2
Le paramètre tolerationSeconds spécifie la durée pendant laquelle un pod est lié à un nœud avant d'être expulsé.
Par exemple :
Exemple de fichier de configuration d'un pod avec l'opérateur Exists
```
spec:
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 3600
```
```
spec:
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 3600
```
Copy to Clipboard Toggle word wrap
Ajouter l'altération à l'objet MachineSet:
1. Modifiez le fichier YAML de MachineSet pour les nœuds que vous souhaitez altérer ou créez un nouvel objet MachineSet:
  $ oc edit machineset <machineset>
  Copy to Clipboard Toggle word wrap
2. Ajoutez la souillure à la section spec.template.spec:
  Exemple d'altération dans la spécification d'un ensemble de machines de calcul
  spec: .... template: .... spec: taints: - effect: NoExecute key: key1 value: value1 ....
  
  Copy to Clipboard Toggle word wrap
  Cet exemple place une taint qui a la clé key1, la valeur value1, et l'effet de taint NoExecute sur les nœuds.
3. Réduire l'échelle de la machine de calcul à 0 :
  $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api
  Copy to Clipboard Toggle word wrap
  Astuce
  Vous pouvez également appliquer le YAML suivant pour mettre à l'échelle l'ensemble des machines de calcul :
  
  apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: <machineset> namespace: openshift-machine-api spec: replicas: 0
  
  Copy to Clipboard Toggle word wrap
  Attendez que les machines soient retirées.
4. Augmenter l'ensemble des machines de calcul en fonction des besoins :
  $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
  Copy to Clipboard Toggle word wrap
  Ou bien :
  $ oc edit machineset <machineset> -n openshift-machine-api
  Copy to Clipboard Toggle word wrap
  Attendez que les machines démarrent. L'altération est ajoutée aux nœuds associés à l'objet MachineSet.

3.6.2.2. Lier un utilisateur à un nœud à l'aide de taches et de tolérances
Copier lien

Si vous souhaitez réserver un ensemble de nœuds à l'usage exclusif d'un groupe particulier d'utilisateurs, ajoutez une tolérance à leurs pods. Ajoutez ensuite une altération correspondante à ces nœuds. Les pods avec les tolérances sont autorisés à utiliser les nœuds altérés ou tout autre nœud du cluster.

Si vous voulez vous assurer que les pods sont programmés uniquement sur les nœuds altérés, ajoutez également une étiquette au même ensemble de nœuds et ajoutez une affinité de nœud aux pods de sorte que les pods ne puissent être programmés que sur des nœuds avec cette étiquette.

Procédure

Pour configurer un nœud de manière à ce que les utilisateurs ne puissent utiliser que ce nœud :

Ajouter une tare correspondante à ces nœuds :

Par exemple :

oc adm taint nodes node1 dedicated=groupName:NoSchedule

$ oc adm taint nodes node1 dedicated=groupName:NoSchedule

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter l'altération :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    ...
spec:
  taints:
    - key: dedicated
      value: groupName
      effect: NoSchedule

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    ...
spec:
  taints:
    - key: dedicated
      value: groupName
      effect: NoSchedule

Copy to Clipboard

Toggle word wrap

Ajoutez une tolérance aux pods en écrivant un contrôleur d'admission personnalisé.

3.6.2.3. Créer un projet avec un sélecteur de nœuds et une tolérance
Copier lien

Vous pouvez créer un projet qui utilise un sélecteur de nœud et une tolérance, qui sont définis comme des annotations, pour contrôler le placement des pods sur des nœuds spécifiques. Toutes les ressources ultérieures créées dans le projet sont alors planifiées sur des nœuds dont l'altération correspond à la tolérance.

Conditions préalables

Une étiquette de sélection de nœuds a été ajoutée à un ou plusieurs nœuds en utilisant un ensemble de machines de calcul ou en éditant le nœud directement.
Une tare a été ajoutée à un ou plusieurs nœuds en utilisant un ensemble de machines de calcul ou en modifiant le nœud directement.

Procédure

Créer une définition de ressource Project, en spécifiant un sélecteur de nœud et une tolérance dans la section metadata.annotations:

Exemple de fichier project.yaml

kind: Project
apiVersion: project.openshift.io/v1
metadata:
  name: <project_name> 
  annotations:
    openshift.io/node-selector: '<label>' 
    scheduler.alpha.kubernetes.io/defaultTolerations: >-
      [{"operator": "Exists", "effect": "NoSchedule", "key":
      "<key_name>"} 
      ]

kind: Project
apiVersion: project.openshift.io/v1
metadata:
  name: <project_name>


  annotations:
    openshift.io/node-selector: '<label>'


    scheduler.alpha.kubernetes.io/defaultTolerations: >-
      [{"operator": "Exists", "effect": "NoSchedule", "key":
      "<key_name>"}

Copy to Clipboard

Toggle word wrap

1: Le nom du projet.
2: L'étiquette par défaut du sélecteur de nœud.
3: Les paramètres de tolérance, tels que décrits dans le tableau Taint and toleration components. Cet exemple utilise l'effet NoSchedule, qui permet aux pods existants sur le nœud de rester, et l'opérateur Exists, qui ne prend pas de valeur.

Utilisez la commande oc apply pour créer le projet :
```
oc apply -f project.yaml
```
```
$ oc apply -f project.yaml
```
Copy to Clipboard Toggle word wrap

Toutes les ressources créées ultérieurement dans l'espace de noms <project_name> doivent désormais être planifiées sur les nœuds spécifiés.

3.6.2.4. Contrôle des nœuds avec du matériel spécial à l'aide de taches et de tolérances
Copier lien

Dans un cluster où un petit sous-ensemble de nœuds dispose d'un matériel spécialisé, vous pouvez utiliser les taints et les tolérances pour empêcher les pods qui n'ont pas besoin de ce matériel spécialisé d'utiliser ces nœuds, laissant ainsi les nœuds aux pods qui ont besoin de ce matériel spécialisé. Vous pouvez également exiger que les modules qui ont besoin d'un matériel spécialisé utilisent des nœuds spécifiques.

Vous pouvez y parvenir en ajoutant une tolérance aux pods qui ont besoin d'un matériel spécial et en altérant les nœuds qui disposent de ce matériel.

Procédure

Pour s'assurer que les nœuds dotés d'un matériel spécialisé sont réservés à des modules spécifiques :

Ajouter une tolérance aux nacelles qui ont besoin d'un matériel spécial.

Par exemple :

spec:
  tolerations:
    - key: "disktype"
      value: "ssd"
      operator: "Equal"
      effect: "NoSchedule"
      tolerationSeconds: 3600

spec:
  tolerations:
    - key: "disktype"
      value: "ssd"
      operator: "Equal"
      effect: "NoSchedule"
      tolerationSeconds: 3600

Copy to Clipboard

Toggle word wrap

Attaquez les nœuds dotés du matériel spécialisé à l'aide de l'une des commandes suivantes :

oc adm taint nodes <node-name> disktype=ssd:NoSchedule

oc adm taint nodes <node-name> disktype=ssd:NoSchedule

Copy to Clipboard

Toggle word wrap

Ou bien :

oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter l'altération :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    ...
spec:
  taints:
    - key: disktype
      value: ssd
      effect: PreferNoSchedule

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    ...
spec:
  taints:
    - key: disktype
      value: ssd
      effect: PreferNoSchedule

Copy to Clipboard

Toggle word wrap

3.6.3. Supprimer les tares et les tolérances
Copier lien

Vous pouvez supprimer les tares des nœuds et les tolérances des nacelles si nécessaire. Vous devez d'abord ajouter la tolérance au module, puis ajouter l'altération au nœud afin d'éviter que des modules soient retirés du nœud avant que vous ne puissiez ajouter la tolérance.

Procédure

Éliminer les tares et les tolérances :

Pour supprimer une tare d'un nœud :

oc adm taint nodes <node-name> <key>-

$ oc adm taint nodes <node-name> <key>-

Copy to Clipboard

Toggle word wrap

Par exemple :

oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

$ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

Copy to Clipboard

Toggle word wrap

Exemple de sortie

node/ip-10-0-132-248.ec2.internal untainted

node/ip-10-0-132-248.ec2.internal untainted

Copy to Clipboard

Toggle word wrap

Pour supprimer une tolérance d'un pod, modifiez la spécification de Pod pour supprimer la tolérance :

spec:
  tolerations:
  - key: "key2"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 3600

spec:
  tolerations:
  - key: "key2"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 3600

Copy to Clipboard

Toggle word wrap

3.7. Placer des pods sur des nœuds spécifiques en utilisant des sélecteurs de nœuds
Copier lien

Un site node selector spécifie une carte de paires clé/valeur définies à l'aide d'étiquettes personnalisées sur les nœuds et de sélecteurs spécifiés dans les pods.

Pour qu'un module puisse être exécuté sur un nœud, il doit avoir le même sélecteur de nœud clé/valeur que l'étiquette du nœud.

3.7.1. À propos des sélecteurs de nœuds
Copier lien

Vous pouvez utiliser un sélecteur de nœud pour placer des pods spécifiques sur des nœuds spécifiques, des sélecteurs de nœuds à l'échelle du cluster pour placer de nouveaux pods sur des nœuds spécifiques n'importe où dans le cluster, et des sélecteurs de nœuds de projet pour placer de nouveaux pods dans un projet sur des nœuds spécifiques.

Par exemple, en tant qu'administrateur de cluster, vous pouvez créer une infrastructure dans laquelle les développeurs d'applications peuvent déployer des pods uniquement sur les nœuds les plus proches de leur emplacement géographique en incluant un sélecteur de nœud dans chaque pod qu'ils créent. Dans cet exemple, le cluster se compose de cinq centres de données répartis dans deux régions. Aux États-Unis, les nœuds sont étiquetés us-east, us-central ou us-west. Dans la région Asie-Pacifique (APAC), les nœuds sont étiquetés apac-east ou apac-west. Les développeurs peuvent ajouter un sélecteur de nœud aux pods qu'ils créent pour s'assurer que les pods sont planifiés sur ces nœuds.

Un pod n'est pas programmé si l'objet Pod contient un sélecteur de nœud, mais qu'aucun nœud n'a d'étiquette correspondante.

Important

Si vous utilisez des sélecteurs de nœuds et des affinités de nœuds dans la même configuration de pods, les règles suivantes contrôlent le placement des pods sur les nœuds :

Si vous configurez à la fois nodeSelector et nodeAffinity, les deux conditions doivent être remplies pour que le pod soit planifié sur un nœud candidat.
Si vous spécifiez plusieurs nodeSelectorTerms associés à des types nodeAffinity, le module peut être programmé sur un nœud si l'un des nodeSelectorTerms est satisfait.
Si vous spécifiez plusieurs matchExpressions associés à nodeSelectorTerms, le module ne peut être programmé sur un nœud que si tous les matchExpressions sont satisfaits.

Sélecteurs de nœuds sur des pods et des nœuds spécifiques

Vous pouvez contrôler le nœud sur lequel un pod spécifique est programmé en utilisant des sélecteurs de nœuds et des étiquettes.

Pour utiliser les sélecteurs de nœuds et les étiquettes, il faut d'abord étiqueter le nœud afin d'éviter que les modules ne soient désordonnés, puis ajouter le sélecteur de nœud au module.

Note

Vous ne pouvez pas ajouter un sélecteur de nœud directement à un module programmé existant. Vous devez étiqueter l'objet qui contrôle le module, tel que la configuration de déploiement.

Par exemple, l'objet Node suivant porte l'étiquette region: east:

Exemple d'objet Node avec une étiquette

kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-131-14.ec2.internal
  selfLink: /api/v1/nodes/ip-10-0-131-14.ec2.internal
  uid: 7bc2580a-8b8e-11e9-8e01-021ab4174c74
  resourceVersion: '478704'
  creationTimestamp: '2019-06-10T14:46:08Z'
  labels:
    kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/zone: us-east-1a
    node.openshift.io/os_version: '4.5'
    node-role.kubernetes.io/worker: ''
    failure-domain.beta.kubernetes.io/region: us-east-1
    node.openshift.io/os_id: rhcos
    beta.kubernetes.io/instance-type: m4.large
    kubernetes.io/hostname: ip-10-0-131-14
    beta.kubernetes.io/arch: amd64
    region: east 
    type: user-node

kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-131-14.ec2.internal
  selfLink: /api/v1/nodes/ip-10-0-131-14.ec2.internal
  uid: 7bc2580a-8b8e-11e9-8e01-021ab4174c74
  resourceVersion: '478704'
  creationTimestamp: '2019-06-10T14:46:08Z'
  labels:
    kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/zone: us-east-1a
    node.openshift.io/os_version: '4.5'
    node-role.kubernetes.io/worker: ''
    failure-domain.beta.kubernetes.io/region: us-east-1
    node.openshift.io/os_id: rhcos
    beta.kubernetes.io/instance-type: m4.large
    kubernetes.io/hostname: ip-10-0-131-14
    beta.kubernetes.io/arch: amd64
    region: east


    type: user-node

Copy to Clipboard

Toggle word wrap

1: Étiquettes correspondant au sélecteur de nœuds de pods.

Un pod possède le sélecteur de nœuds type: user-node,region: east:

Exemple d'objet Pod avec des sélecteurs de nœuds

apiVersion: v1
kind: Pod

....

spec:
  nodeSelector: 
    region: east
    type: user-node

apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:


    region: east
    type: user-node

Copy to Clipboard

Toggle word wrap

1: Sélecteurs de nœuds correspondant à l'étiquette du nœud. Le nœud doit avoir une étiquette pour chaque sélecteur de nœud.

Lorsque vous créez le pod à l'aide de la spécification de pod d'exemple, il peut être planifié sur le nœud d'exemple.

Sélecteurs de nœuds par défaut pour l'ensemble du cluster

Avec des sélecteurs de nœuds par défaut à l'échelle du cluster, lorsque vous créez un pod dans ce cluster, OpenShift Container Platform ajoute les sélecteurs de nœuds par défaut au pod et planifie le pod sur des nœuds avec des étiquettes correspondantes.

Par exemple, l'objet Scheduler suivant possède les sélecteurs de nœuds par défaut pour l'ensemble du cluster region=east et type=user-node:

Exemple d'ordonnanceur Opérateur Ressource personnalisée

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...

spec:
  defaultNodeSelector: type=user-node,region=east
...

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...

spec:
  defaultNodeSelector: type=user-node,region=east
...

Copy to Clipboard

Toggle word wrap

Un nœud de cette grappe possède les étiquettes type=user-node,region=east:

Exemple d'objet Node

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
...
  labels:
    region: east
    type: user-node
...

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
...
  labels:
    region: east
    type: user-node
...

Copy to Clipboard

Toggle word wrap

Exemple d'objet Pod avec un sélecteur de nœud

apiVersion: v1
kind: Pod
...

spec:
  nodeSelector:
    region: east
...

apiVersion: v1
kind: Pod
...

spec:
  nodeSelector:
    region: east
...

Copy to Clipboard

Toggle word wrap

Lorsque vous créez le pod à l'aide de la spécification de pod d'exemple dans le cluster d'exemple, le pod est créé avec le sélecteur de nœud à l'échelle du cluster et est planifié sur le nœud étiqueté :

Exemple de liste de pods avec le pod sur le nœud étiqueté

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>

Copy to Clipboard

Toggle word wrap

Note

Si le projet dans lequel vous créez le module dispose d'un sélecteur de nœud de projet, ce sélecteur a la préférence sur un sélecteur de nœud à l'échelle du cluster. Votre module n'est pas créé ou planifié s'il n'a pas de sélecteur de nœud de projet.

Sélecteurs de nœuds de projet

Avec les sélecteurs de nœuds de projet, lorsque vous créez un pod dans ce projet, OpenShift Container Platform ajoute les sélecteurs de nœuds au pod et planifie les pods sur un nœud avec les étiquettes correspondantes. S'il existe un sélecteur de nœuds par défaut à l'échelle du cluster, le sélecteur de nœuds du projet est privilégié.

Par exemple, le projet suivant possède le sélecteur de nœuds region=east:

Exemple d'objet Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: east-region
  annotations:
    openshift.io/node-selector: "region=east"
...

apiVersion: v1
kind: Namespace
metadata:
  name: east-region
  annotations:
    openshift.io/node-selector: "region=east"
...

Copy to Clipboard

Toggle word wrap

Le nœud suivant possède les étiquettes type=user-node,region=east:

Exemple d'objet Node

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
...
  labels:
    region: east
    type: user-node
...

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
...
  labels:
    region: east
    type: user-node
...

Copy to Clipboard

Toggle word wrap

Lorsque vous créez le pod à l'aide de l'exemple de spécification de pod dans cet exemple de projet, le pod est créé avec les sélecteurs de nœuds du projet et est planifié sur le nœud étiqueté :

Exemple d'objet Pod

apiVersion: v1
kind: Pod
metadata:
  namespace: east-region
...
spec:
  nodeSelector:
    region: east
    type: user-node
...

apiVersion: v1
kind: Pod
metadata:
  namespace: east-region
...
spec:
  nodeSelector:
    region: east
    type: user-node
...

Copy to Clipboard

Toggle word wrap

Exemple de liste de pods avec le pod sur le nœud étiqueté

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>

Copy to Clipboard

Toggle word wrap

Un module du projet n'est pas créé ou planifié s'il contient des sélecteurs de nœuds différents. Par exemple, si vous déployez le module suivant dans le projet d'exemple, il ne sera pas créé :

Exemple Pod objet avec un sélecteur de nœud invalide

apiVersion: v1
kind: Pod
...

spec:
  nodeSelector:
    region: west

....

apiVersion: v1
kind: Pod
...

spec:
  nodeSelector:
    region: west

....

Copy to Clipboard

Toggle word wrap

3.7.2. Utilisation de sélecteurs de nœuds pour contrôler le placement des pods
Copier lien

Note

Vous ne pouvez pas ajouter un sélecteur de nœud directement à un module planifié existant.

Conditions préalables

oc describe pod router-default-66d5cf9464-7pwkc

Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress

....

Controlled By:      ReplicaSet/router-default-66d5cf9464

$ oc describe pod router-default-66d5cf9464-7pwkc

Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress

....

Controlled By:      ReplicaSet/router-default-66d5cf9464

Copy to Clipboard

Toggle word wrap

La console web liste l'objet de contrôle sous ownerReferences dans le pod YAML :

  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true

  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true

Copy to Clipboard

Toggle word wrap

Procédure

Ajoutez des étiquettes à un nœud en utilisant un ensemble de machines de calcul ou en éditant le nœud directement :

Utilisez un objet MachineSet pour ajouter des étiquettes aux nœuds gérés par l'ensemble de machines de calcul lors de la création d'un nœud :

Exécutez la commande suivante pour ajouter des étiquettes à un objet MachineSet:

oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Par exemple :

oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

$ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter des étiquettes à un ensemble de machines de calcul :

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées à l'objet MachineSet en utilisant la commande oc edit:

Par exemple :

oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Exemple d'objet MachineSet

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

....

spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
....

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

....

spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
....

Copy to Clipboard

Toggle word wrap

Ajouter des étiquettes directement à un nœud :

Modifiez l'objet Node pour le nœud :

oc label nodes <name> <key>=<value>

$ oc label nodes <name> <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple, pour étiqueter un nœud :

oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

$ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le langage YAML suivant pour ajouter des étiquettes à un nœud :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées au nœud :

oc get nodes -l type=user-node,region=east

$ oc get nodes -l type=user-node,region=east

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.25.0

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.25.0

Copy to Clipboard

Toggle word wrap

Ajouter le sélecteur de nœud correspondant à un pod :

Pour ajouter un sélecteur de nœud aux modules existants et futurs, ajoutez un sélecteur de nœud à l'objet de contrôle des modules :

Exemple ReplicaSet objet avec étiquettes

kind: ReplicaSet

....

spec:

....

  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node

kind: ReplicaSet

....

spec:

....

  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node

Copy to Clipboard

Toggle word wrap

1: Ajouter le sélecteur de nœud.

Pour ajouter un sélecteur de nœud à un nouveau pod spécifique, ajoutez le sélecteur à l'objet Pod directement :
Exemple d'objet Pod avec un sélecteur de nœud
```
apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:
    region: east
    type: user-node
```
```
apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:
    region: east
    type: user-node
```
Copy to Clipboard Toggle word wrap
Note
Vous ne pouvez pas ajouter un sélecteur de nœud directement à un module planifié existant.

3.7.3. Création de sélecteurs de nœuds par défaut pour l'ensemble du cluster
Copier lien

Vous pouvez utiliser des sélecteurs de nœuds par défaut à l'échelle du cluster sur les pods ainsi que des étiquettes sur les nœuds pour contraindre tous les pods créés dans un cluster à des nœuds spécifiques.

Avec des sélecteurs de nœuds à l'échelle du cluster, lorsque vous créez un pod dans ce cluster, OpenShift Container Platform ajoute les sélecteurs de nœuds par défaut au pod et planifie le pod sur des nœuds avec des étiquettes correspondantes.

Vous configurez les sélecteurs de nœuds à l'échelle du cluster en modifiant la ressource personnalisée (CR) de l'opérateur d'ordonnancement. Vous ajoutez des étiquettes à un nœud, à un ensemble de machines de calcul ou à une configuration de machine. L'ajout de l'étiquette à l'ensemble de machines de calcul garantit que si le nœud ou la machine tombe en panne, les nouveaux nœuds disposent de l'étiquette. Les étiquettes ajoutées à un nœud ou à une configuration de machine ne persistent pas si le nœud ou la machine tombe en panne.

Note

Vous pouvez ajouter des paires clé/valeur supplémentaires à un pod. Mais vous ne pouvez pas ajouter une valeur différente pour une clé par défaut.

Procédure

Pour ajouter un sélecteur de nœuds par défaut à l'échelle du cluster :

Modifiez le CR de l'opérateur d'ordonnancement pour ajouter les sélecteurs de nœuds par défaut à l'échelle du cluster :
```
oc edit scheduler cluster
```
```
$ oc edit scheduler cluster
```
Copy to Clipboard Toggle word wrap
Exemple d'opérateur d'ordonnancement CR avec un sélecteur de nœuds
```
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...
spec:
  defaultNodeSelector: type=user-node,region=east 
  mastersSchedulable: false
```
```
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...
spec:
  defaultNodeSelector: type=user-node,region=east 
```
1
```
  mastersSchedulable: false
```
Copy to Clipboard Toggle word wrap
1
Ajouter un sélecteur de nœud avec les paires <key>:<value> appropriées.
Après avoir effectué cette modification, attendez que les pods du projet openshift-kube-apiserver soient redéployés. Cela peut prendre plusieurs minutes. Le sélecteur de nœuds par défaut à l'échelle du cluster ne prend pas effet tant que les pods ne sont pas redéployés.

Ajoutez des étiquettes à un nœud en utilisant un ensemble de machines de calcul ou en éditant le nœud directement :

Utiliser un ensemble de machines de calcul pour ajouter des étiquettes aux nœuds gérés par l'ensemble de machines de calcul lors de la création d'un nœud :

Exécutez la commande suivante pour ajouter des étiquettes à un objet MachineSet:

oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

1: Ajouter une paire <key>/<value> pour chaque étiquette.

Par exemple :

oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

$ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter des étiquettes à un ensemble de machines de calcul :

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées à l'objet MachineSet en utilisant la commande oc edit:

Par exemple :

oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Exemple d'objet MachineSet

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
  ...
spec:
  ...
  template:
    metadata:
  ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
  ...

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
  ...
spec:
  ...
  template:
    metadata:
  ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
  ...

Copy to Clipboard

Toggle word wrap

Redéployez les nœuds associés à cet ensemble de machines de calcul en réduisant l'échelle à 0 et en augmentant l'échelle des nœuds :

Par exemple :

oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

$ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

$ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Lorsque les nœuds sont prêts et disponibles, vérifiez que l'étiquette a été ajoutée aux nœuds à l'aide de la commande oc get:

oc get nodes -l <key>=<value>

$ oc get nodes -l <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc get nodes -l type=user-node

$ oc get nodes -l type=user-node

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.25.0

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.25.0

Copy to Clipboard

Toggle word wrap

Ajouter des étiquettes directement à un nœud :

Modifiez l'objet Node pour le nœud :

oc label nodes <name> <key>=<value>

$ oc label nodes <name> <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple, pour étiqueter un nœud :

oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

$ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le langage YAML suivant pour ajouter des étiquettes à un nœud :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées au nœud à l'aide de la commande oc get:

oc get nodes -l <key>=<value>,<key>=<valeur>

$ oc get nodes -l <key>=<value>,<key>=<valeur>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc get nodes -l type=user-node,region=east

$ oc get nodes -l type=user-node,region=east

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.25.0

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.25.0

Copy to Clipboard

Toggle word wrap

3.7.4. Création de sélecteurs de nœuds pour l'ensemble du projet
Copier lien

Vous pouvez utiliser des sélecteurs de nœuds dans un projet ainsi que des étiquettes sur les nœuds pour contraindre tous les pods créés dans ce projet aux nœuds étiquetés.

Lorsque vous créez un pod dans ce projet, OpenShift Container Platform ajoute les sélecteurs de nœuds aux pods du projet et planifie les pods sur un nœud avec des étiquettes correspondantes dans le projet. S'il existe un sélecteur de nœud par défaut à l'échelle du cluster, le sélecteur de nœud du projet a la préférence.

Vous ajoutez des sélecteurs de nœuds à un projet en modifiant l'objet Namespace pour ajouter le paramètre openshift.io/node-selector. Vous ajoutez des étiquettes à un nœud, à un ensemble de machines de calcul ou à une configuration de machine. L'ajout de l'étiquette à l'ensemble de machines de calcul garantit que si le nœud ou la machine tombe en panne, les nouveaux nœuds disposent de l'étiquette. Les étiquettes ajoutées à un nœud ou à une configuration de machine ne persistent pas si le nœud ou la machine tombe en panne.

Un pod n'est pas planifié si l'objet Pod contient un sélecteur de nœuds, mais qu'aucun projet n'a de sélecteur de nœuds correspondant. Lorsque vous créez un pod à partir de cette spécification, vous recevez une erreur similaire au message suivant :

Exemple de message d'erreur

Error from server (Forbidden): error when creating "pod.yaml": pods "pod-4" is forbidden: pod node label selector conflicts with its project node label selector

Error from server (Forbidden): error when creating "pod.yaml": pods "pod-4" is forbidden: pod node label selector conflicts with its project node label selector

Copy to Clipboard

Toggle word wrap

Note

Vous pouvez ajouter des paires clé/valeur supplémentaires à un module. Mais vous ne pouvez pas ajouter une valeur différente pour une clé de projet.

Procédure

Pour ajouter un sélecteur de nœud de projet par défaut :

Créez un espace de noms ou modifiez un espace de noms existant pour ajouter le paramètre openshift.io/node-selector:

oc edit namespace <name> $ oc edit namespace <name>

oc edit namespace <name> $ oc edit namespace <name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: "type=user-node,region=east" 
    openshift.io/description: ""
    openshift.io/display-name: ""
    openshift.io/requester: kube:admin
    openshift.io/sa.scc.mcs: s0:c30,c5
    openshift.io/sa.scc.supplemental-groups: 1000880000/10000
    openshift.io/sa.scc.uid-range: 1000880000/10000
  creationTimestamp: "2021-05-10T12:35:04Z"
  labels:
    kubernetes.io/metadata.name: demo
  name: demo
  resourceVersion: "145537"
  uid: 3f8786e3-1fcb-42e3-a0e3-e2ac54d15001
spec:
  finalizers:
  - kubernetes

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: "type=user-node,region=east"


    openshift.io/description: ""
    openshift.io/display-name: ""
    openshift.io/requester: kube:admin
    openshift.io/sa.scc.mcs: s0:c30,c5
    openshift.io/sa.scc.supplemental-groups: 1000880000/10000
    openshift.io/sa.scc.uid-range: 1000880000/10000
  creationTimestamp: "2021-05-10T12:35:04Z"
  labels:
    kubernetes.io/metadata.name: demo
  name: demo
  resourceVersion: "145537"
  uid: 3f8786e3-1fcb-42e3-a0e3-e2ac54d15001
spec:
  finalizers:
  - kubernetes

Copy to Clipboard

Toggle word wrap

1: Ajoutez les paires openshift.io/node-selector et <key>:<value> appropriées.

Ajoutez des étiquettes à un nœud en utilisant un ensemble de machines de calcul ou en éditant le nœud directement :

Utilisez un objet MachineSet pour ajouter des étiquettes aux nœuds gérés par l'ensemble de machines de calcul lors de la création d'un nœud :

Exécutez la commande suivante pour ajouter des étiquettes à un objet MachineSet:

oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Par exemple :

oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

$ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour ajouter des étiquettes à un ensemble de machines de calcul :

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées à l'objet MachineSet en utilisant la commande oc edit:

Par exemple :

oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

$ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
...
spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
...
spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node

Copy to Clipboard

Toggle word wrap

Redéployer les nœuds associés à cet ensemble de machines de calcul :

Par exemple :

oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

$ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

$ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Lorsque les nœuds sont prêts et disponibles, vérifiez que l'étiquette a été ajoutée aux nœuds à l'aide de la commande oc get:

oc get nodes -l <key>=<value>

$ oc get nodes -l <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc get nodes -l type=user-node,region=east

$ oc get nodes -l type=user-node,region=east

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.25.0

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.25.0

Copy to Clipboard

Toggle word wrap

Ajouter des étiquettes directement à un nœud :

Modifiez l'objet Node pour ajouter des étiquettes :

oc label <resource> <name> <key>=<value>

$ oc label <resource> <name> <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple, pour étiqueter un nœud :

oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-c-tgq49 type=user-node region=east

$ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-c-tgq49 type=user-node region=east

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le langage YAML suivant pour ajouter des étiquettes à un nœud :

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

Copy to Clipboard

Toggle word wrap

Vérifiez que les étiquettes sont ajoutées à l'objet Node à l'aide de la commande oc get:

oc get nodes -l <key>=<value>

$ oc get nodes -l <key>=<value>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc get nodes -l type=user-node,region=east

$ oc get nodes -l type=user-node,region=east

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.25.0

NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.25.0

Copy to Clipboard

Toggle word wrap

3.8. Contrôle du placement des pods à l'aide de contraintes d'étalement de la topologie des pods
Copier lien

Vous pouvez utiliser les contraintes d'étalement de la topologie des pods pour contrôler le placement de vos pods sur des nœuds, des zones, des régions ou d'autres domaines topologiques définis par l'utilisateur.

3.8.1. A propos des contraintes d'étalement de la topologie des pods
Copier lien

L'utilisation de pod topology spread constraint permet de contrôler finement la distribution des pods dans les domaines de défaillance afin d'obtenir une haute disponibilité et une utilisation plus efficace des ressources.

Les administrateurs d'OpenShift Container Platform peuvent étiqueter les nœuds pour fournir des informations topologiques, telles que des régions, des zones, des nœuds ou d'autres domaines définis par l'utilisateur. Une fois ces étiquettes définies sur les nœuds, les utilisateurs peuvent alors définir des contraintes d'étalement de la topologie des pods pour contrôler le placement des pods dans ces domaines topologiques.

Vous spécifiez les pods à regrouper, les domaines topologiques dans lesquels ils sont répartis et l'inclinaison acceptable. Seuls les pods situés dans le même espace de noms sont mis en correspondance et regroupés lorsqu'ils sont répartis en raison d'une contrainte.

3.8.2. Configuration des contraintes d'étalement de la topologie des pods
Copier lien

Les étapes suivantes montrent comment configurer les contraintes d'étalement de la topologie des pods pour distribuer les pods qui correspondent aux étiquettes spécifiées en fonction de leur zone.

Vous pouvez spécifier plusieurs contraintes d'étalement de la topologie des pods, mais vous devez vous assurer qu'elles n'entrent pas en conflit les unes avec les autres. Toutes les contraintes d'étalement de la topologie du pod doivent être satisfaites pour qu'un pod soit placé.

Conditions préalables

Un administrateur de cluster a ajouté les étiquettes requises aux nœuds.

Procédure

Créez une spécification Pod et spécifiez une contrainte d'étalement de la topologie du pod :
Exemple de fichier pod-spec.yaml
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1 
    topologyKey: topology.kubernetes.io/zone 
    whenUnsatisfiable: DoNotSchedule 
    labelSelector: 
      matchLabels:
        foo: bar 
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod
```
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1 
```
1
```
    topologyKey: topology.kubernetes.io/zone 
```
2
```
    whenUnsatisfiable: DoNotSchedule 
```
3
```
    labelSelector: 
```
4
```
      matchLabels:
        foo: bar 
```
5
```
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod
```
Copy to Clipboard Toggle word wrap
1
La différence maximale en nombre de pods entre deux domaines topologiques. La valeur par défaut est 1, et vous ne pouvez pas spécifier une valeur de 0.
2
Clé de l'étiquette d'un nœud. Les nœuds ayant cette clé et une valeur identique sont considérés comme faisant partie de la même topologie.
3
Comment traiter un pod s'il ne satisfait pas à la contrainte d'étalement. La valeur par défaut est DoNotSchedule, ce qui indique au planificateur de ne pas planifier le module. La valeur ScheduleAnyway permet de planifier le module, mais l'ordonnanceur donne la priorité au respect de la contrainte de dispersion afin de ne pas aggraver le déséquilibre de la grappe.
4
Les gousses qui correspondent à ce sélecteur d'étiquette sont comptées et reconnues comme un groupe lorsqu'elles sont étalées pour satisfaire à la contrainte. Veillez à spécifier un sélecteur d'étiquette, sinon aucune cosse ne pourra être prise en compte.
5
Veillez à ce que cette spécification Pod définisse également ses étiquettes en fonction de ce sélecteur d'étiquettes si vous voulez qu'elle soit comptée correctement à l'avenir.
Créer la capsule :
```
oc create -f pod-spec.yaml
```
```
$ oc create -f pod-spec.yaml
```
Copy to Clipboard Toggle word wrap

3.8.3. Exemple de contraintes de répartition de la topologie des pods
Copier lien

Les exemples suivants illustrent les configurations de contraintes de propagation de la topologie des pods.

3.8.3.1. Exemple de contrainte de diffusion d'une topologie de pod unique
Copier lien

Cet exemple de spécification Pod définit une contrainte d'étalement de la topologie du pod. Elle s'applique aux pods étiquetés foo:bar, se répartit entre les zones, spécifie une inclinaison de 1 et ne planifie pas le pod s'il ne répond pas à ces exigences.

kind: Pod
apiVersion: v1
metadata:
  name: my-pod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod

kind: Pod
apiVersion: v1
metadata:
  name: my-pod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod

Copy to Clipboard

Toggle word wrap

3.8.3.2. Exemple de contraintes d'étalement de la topologie des pods multiples
Copier lien

Cet exemple de spécification Pod définit deux contraintes d'étalement de la topologie des pods. Les deux correspondent aux pods étiquetés foo:bar, spécifient une inclinaison de 1, et ne planifient pas le pod s'il ne répond pas à ces exigences.

La première contrainte distribue les nacelles en fonction d'une étiquette définie par l'utilisateur node et la deuxième contrainte distribue les nacelles en fonction d'une étiquette définie par l'utilisateur rack. Les deux contraintes doivent être respectées pour que le module soit programmé.

kind: Pod
apiVersion: v1
metadata:
  name: my-pod-2
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: rack
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod

kind: Pod
apiVersion: v1
metadata:
  name: my-pod-2
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: rack
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - image: "docker.io/ocpqe/hello-pod"
    name: hello-pod

Copy to Clipboard

Toggle word wrap

3.9. Éviction des pods à l'aide de l'ordonnanceur
Copier lien

Alors que le planificateur est utilisé pour déterminer le nœud le plus approprié pour héberger un nouveau pod, le déscheduler peut être utilisé pour évincer un pod en cours d'exécution afin qu'il puisse être reprogrammé sur un nœud plus approprié.

3.9.1. À propos du déschedulateur
Copier lien

Vous pouvez utiliser l'ordonnanceur pour expulser les pods sur la base de stratégies spécifiques afin que les pods puissent être replanifiés sur des nœuds plus appropriés.

Vous pouvez bénéficier de la désimplantation des pods en cours d'exécution dans des situations telles que les suivantes :

Les nœuds sont sous-utilisés ou surutilisés.
Les exigences relatives aux pods et aux affinités entre nœuds, telles que les taches ou les étiquettes, ont changé et les décisions d'ordonnancement initiales ne sont plus appropriées pour certains nœuds.
En cas de défaillance d'un nœud, les pods doivent être déplacés.
De nouveaux nœuds sont ajoutés aux grappes.
Les pods ont été redémarrés trop souvent.

Important

L'ordonnanceur ne planifie pas le remplacement des pods expulsés. Le planificateur effectue automatiquement cette tâche pour les pods évincés.

Lorsque l'ordonnanceur décide d'expulser des pods d'un nœud, il utilise le mécanisme général suivant :

Les pods des espaces de noms openshift-* et kube-system ne sont jamais expulsés.
Les pods critiques dont la valeur de priorityClassName est system-cluster-critical ou system-node-critical ne sont jamais expulsés.
Les pods statiques, en miroir ou autonomes qui ne font pas partie d'un contrôleur de réplication, d'un ensemble de réplicas, d'un déploiement ou d'un travail ne sont jamais expulsés car ces pods ne seront pas recréés.
Les pods associés aux ensembles de démons ne sont jamais expulsés.
Les pods disposant d'un stockage local ne sont jamais expulsés.
Les pods "best effort" sont éliminés avant les pods "burstable" et "guaranteed".
Tous les types de pods ayant l'annotation descheduler.alpha.kubernetes.io/evict sont éligibles à l'expulsion. Cette annotation est utilisée pour passer outre les contrôles qui empêchent l'expulsion, et l'utilisateur peut choisir le pod qui sera expulsé. Les utilisateurs doivent savoir comment et si le pod sera recréé.
Les pods soumis au budget de perturbation des pods (PDB) ne sont pas expulsés si la désynchronisation viole leur budget de perturbation des pods (PDB). Les pods sont expulsés en utilisant la sous-ressource d'expulsion pour gérer le PDB.

3.9.2. Profils du déschedulateur
Copier lien

Les profils suivants sont disponibles :

AffinityAndTaints

Ce profil expulse les pods qui violent l'anti-affinité inter-pods, l'affinité des nœuds et les taches des nœuds.

Il permet de mettre en œuvre les stratégies suivantes :

RemovePodsViolatingInterPodAntiAffinity: élimine les pods qui violent l'anti-affinité inter-pods.
RemovePodsViolatingNodeAffinity: supprime les pods qui ne respectent pas l'affinité des nœuds.
RemovePodsViolatingNodeTaints: supprime les pods qui violent NoSchedule taints sur les nœuds.
Les pods dont le type d'affinité de nœud est requiredDuringSchedulingIgnoredDuringExecution sont supprimés.

TopologyAndDuplicates

Ce profil expulse les pods afin de répartir uniformément les pods similaires ou les pods du même domaine topologique entre les nœuds.

Il permet de mettre en œuvre les stratégies suivantes :

RemovePodsViolatingTopologySpreadConstraintil détecte les domaines topologiques déséquilibrés et tente d'expulser les pods des domaines les plus vastes lorsque les contraintes de DoNotSchedule sont violées.
RemoveDuplicates: garantit qu'il n'y a qu'un seul pod associé à un ensemble de répliques, à un contrôleur de réplication, à un déploiement ou à un travail s'exécutant sur le même nœud. S'il y en a plus, ces pods dupliqués sont évincés pour une meilleure distribution des pods dans un cluster.

LifecycleAndUtilization

Ce profil permet d'expulser les pods qui fonctionnent depuis longtemps et d'équilibrer l'utilisation des ressources entre les nœuds.

Il permet de mettre en œuvre les stratégies suivantes :

RemovePodsHavingTooManyRestarts: supprime les pods dont les conteneurs ont été redémarrés trop souvent.
Pods où la somme des redémarrages de tous les conteneurs (y compris les conteneurs d'initialisation) est supérieure à 100.
LowNodeUtilizationle système de gestion des pods : trouve les nœuds qui sont sous-utilisés et expulse les pods, si possible, des nœuds surutilisés dans l'espoir que la recréation des pods expulsés sera programmée sur ces nœuds sous-utilisés.
Un nœud est considéré comme sous-utilisé si son utilisation est inférieure à 20 ou à tous les seuils (CPU, mémoire et nombre de pods).
Un nœud est considéré comme surutilisé si son utilisation est supérieure à 50 ou à l'un des seuils (CPU, mémoire et nombre de pods).
PodLifeTime: évince les nacelles trop anciennes.
Par défaut, les pods datant de plus de 24 heures sont supprimés. Vous pouvez personnaliser la valeur de la durée de vie des pods.

SoftTopologyAndDuplicates

Ce profil est le même que celui de TopologyAndDuplicates, sauf que les pods ayant des contraintes topologiques douces, comme whenUnsatisfiable: ScheduleAnyway, sont également pris en compte pour l'expulsion.

Note

N'activez pas à la fois SoftTopologyAndDuplicates et TopologyAndDuplicates. L'activation des deux entraîne un conflit.

EvictPodsWithLocalStorage

Ce profil permet aux pods disposant d'un stockage local d'être éligibles à l'éviction.

EvictPodsWithPVC

Ce profil permet aux pods ayant des réclamations de volumes persistants d'être éligibles à l'éviction. Si vous utilisez Kubernetes NFS Subdir External Provisioner, vous devez ajouter un espace de noms exclu pour l'espace de noms où le provisionneur est installé.

3.9.3. Installation du déschedulateur
Copier lien

Le descheduler n'est pas disponible par défaut. Pour l'activer, vous devez installer Kube Descheduler Operator depuis OperatorHub et activer un ou plusieurs profils de descheduler.

Par défaut, le descheduler fonctionne en mode prédictif, ce qui signifie qu'il ne fait que simuler les évictions de pods. Vous devez changer le mode en mode automatique pour que le descheduler effectue les évictions de pods.

Important

Si vous avez activé les plans de contrôle hébergés dans votre cluster, définissez un seuil de priorité personnalisé pour réduire le risque d'éviction des pods dans les espaces de noms des plans de contrôle hébergés. Définissez le nom de la classe de seuil de priorité sur hypershift-control-plane, car elle a la valeur de priorité la plus basse (100000000) des classes de priorité du plan de contrôle hébergé.

Conditions préalables

Privilèges d'administrateur de cluster.
Accès à la console web d'OpenShift Container Platform.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.
Créer l'espace de noms requis pour l'opérateur Kube Descheduler.
1. Naviguez jusqu'à Administration → Namespaces et cliquez sur Create Namespace.
2. Entrez openshift-kube-descheduler-operator dans le champ Name, entrez openshift.io/cluster-monitoring=true dans le champ Labels pour activer les métriques du déscheduler, et cliquez sur Create.
Installez l'opérateur Kube Descheduler.
1. Naviguez jusqu'à Operators → OperatorHub.
2. Tapez Kube Descheduler Operator dans le champ de filtre.
3. Sélectionnez le site Kube Descheduler Operator et cliquez sur Install.
4. Sur la page Install Operator, sélectionnez A specific namespace on the cluster. Sélectionnez openshift-kube-descheduler-operator dans le menu déroulant.
5. Ajustez les valeurs de Update Channel et Approval Strategy aux valeurs souhaitées.
6. Cliquez sur Install.
Créer une instance de déscheduler.
1. Dans la page Operators → Installed Operators, cliquez sur Kube Descheduler Operator.
2. Sélectionnez l'onglet Kube Descheduler et cliquez sur Create KubeDescheduler.
3. Modifiez les paramètres si nécessaire.
  1. Pour expulser des pods au lieu de simuler les expulsions, remplacez le champ Mode par Automatic.
  2. Développez la section Profiles pour sélectionner un ou plusieurs profils à activer. Le profil AffinityAndTaints est activé par défaut. Cliquez sur Add Profile pour sélectionner d'autres profils.
    Note
    N'activez pas à la fois TopologyAndDuplicates et SoftTopologyAndDuplicates. L'activation des deux entraîne un conflit.
  3. Optionnel : Développez la section Profile Customizations pour définir des configurations optionnelles pour le déscheduler.
    Définissez une valeur personnalisée de durée de vie des pods pour le profil LifecycleAndUtilization. Utilisez le champ podLifetime pour définir une valeur numérique et une unité valide (s, m, ou h). La durée de vie par défaut est de 24 heures (24h).
    Définissez un seuil de priorité personnalisé pour que les pods soient pris en compte pour l'expulsion uniquement si leur priorité est inférieure à un niveau de priorité spécifié. Utilisez le champ thresholdPriority pour définir un seuil de priorité numérique ou utilisez le champ thresholdPriorityClassName pour spécifier un certain nom de classe de priorité.
    Note
    Ne spécifiez pas à la fois thresholdPriority et thresholdPriorityClassName pour le déscheduler.
    Définissez des espaces de noms spécifiques à exclure ou à inclure dans les opérations du déscheduler. Développez le champ namespaces et ajoutez des espaces de noms à la liste excluded ou included. Vous ne pouvez définir qu'une liste d'espaces de noms à exclure ou une liste d'espaces de noms à inclure. Notez que les espaces de noms protégés (openshift-*, kube-system, hypershift) sont exclus par défaut.
    Important
    La stratégie LowNodeUtilization ne prend pas en charge l'exclusion d'espaces de noms. Si le profil LifecycleAndUtilization est défini, ce qui active la stratégie LowNodeUtilization, aucun espace de noms n'est exclu, même les espaces de noms protégés. Pour éviter les expulsions des espaces de noms protégés lorsque la stratégie LowNodeUtilization est activée, définissez le nom de la classe de priorité sur system-cluster-critical ou system-node-critical.
    Expérimental : Définir les seuils de sous-utilisation et de surutilisation pour la stratégie LowNodeUtilization. Utilisez le champ devLowNodeUtilizationThresholds pour définir l'une des valeurs suivantes :
    Low: 10 % sous-utilisés et 30 % surutilisés
    Medium20% de sous-utilisation et 50% de sur-utilisation (par défaut)
    High: 40 % sous-utilisés et 70 % surutilisés
    Note
    Ce paramètre est expérimental et ne doit pas être utilisé dans un environnement de production.
  4. En option : Utilisez le champ Descheduling Interval Seconds pour modifier le nombre de secondes entre les exécutions du descheduler. La valeur par défaut est 3600 secondes.
4. Cliquez sur Create.

Vous pouvez également configurer les profils et les paramètres du descheduler ultérieurement en utilisant le CLI OpenShift (oc). Si vous n'avez pas ajusté les profils lors de la création de l'instance de descheduler depuis la console web, le profil AffinityAndTaints est activé par défaut.

3.9.4. Configuration des profils de désordre
Copier lien

Vous pouvez configurer les profils utilisés par le descheduler pour évincer les pods.

Conditions préalables

Privilèges de l'administrateur du cluster

Procédure

Modifiez l'objet KubeDescheduler:

oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

$ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

Copy to Clipboard

Toggle word wrap

Spécifiez un ou plusieurs profils dans la section spec.profiles.
```
apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600
  logLevel: Normal
  managementState: Managed
  operatorLogLevel: Normal
  mode: Predictive                                     
  profileCustomizations:
    namespaces:                                        
      excluded:
      - my-namespace
    podLifetime: 48h                                   
    thresholdPriorityClassName: my-priority-class-name 
  profiles:                                            
  - AffinityAndTaints
  - TopologyAndDuplicates                              
  - LifecycleAndUtilization
  - EvictPodsWithLocalStorage
  - EvictPodsWithPVC
```
```
apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600
  logLevel: Normal
  managementState: Managed
  operatorLogLevel: Normal
  mode: Predictive                                     
```
1
```
  profileCustomizations:
    namespaces:                                        
```
2
```
      excluded:
      - my-namespace
    podLifetime: 48h                                   
```
3
```
    thresholdPriorityClassName: my-priority-class-name 
```
4
```
  profiles:                                            
```
5
```
  - AffinityAndTaints
  - TopologyAndDuplicates                              
```
6
```
  - LifecycleAndUtilization
  - EvictPodsWithLocalStorage
  - EvictPodsWithPVC
```
Copy to Clipboard Toggle word wrap
1
Facultatif : Par défaut, le descheduler n'expulse pas les pods. Pour évincer les modules, définissez mode sur Automatic.
2
Facultatif : Définissez une liste d'espaces de noms créés par l'utilisateur à inclure ou à exclure des opérations de déscheduler. Utilisez excluded pour définir une liste d'espaces de noms à exclure ou utilisez included pour définir une liste d'espaces de noms à inclure. Notez que les espaces de noms protégés (openshift-*, kube-system, hypershift) sont exclus par défaut.
Important
La stratégie LowNodeUtilization ne prend pas en charge l'exclusion d'espaces de noms. Si le profil LifecycleAndUtilization est défini, ce qui active la stratégie LowNodeUtilization, aucun espace de noms n'est exclu, même les espaces de noms protégés. Pour éviter les expulsions des espaces de noms protégés lorsque la stratégie LowNodeUtilization est activée, définissez le nom de la classe de priorité sur system-cluster-critical ou system-node-critical.
3
Facultatif : Activez une valeur personnalisée de durée de vie du pod pour le profil LifecycleAndUtilization. Les unités valides sont s, m, ou h. La durée de vie du pod par défaut est de 24 heures.
4
Facultatif : Spécifiez un seuil de priorité pour que les pods soient pris en compte pour l'expulsion uniquement si leur priorité est inférieure au niveau spécifié. Utilisez le champ thresholdPriority pour définir un seuil de priorité numérique (par exemple, 10000) ou utilisez le champ thresholdPriorityClassName pour spécifier un certain nom de classe de priorité (par exemple, my-priority-class-name). Si vous spécifiez un nom de classe de priorité, il doit déjà exister ou le descheduler lancera une erreur. Ne définissez pas à la fois thresholdPriority et thresholdPriorityClassName.
5
Ajouter un ou plusieurs profils à activer. Profils disponibles : AffinityAndTaints, TopologyAndDuplicates, LifecycleAndUtilization, SoftTopologyAndDuplicates, EvictPodsWithLocalStorage, et EvictPodsWithPVC.
6
N'activez pas à la fois TopologyAndDuplicates et SoftTopologyAndDuplicates. L'activation des deux entraîne un conflit.
Vous pouvez activer plusieurs profils ; l'ordre dans lequel les profils sont spécifiés n'est pas important.
Enregistrez le fichier pour appliquer les modifications.

3.9.5. Configuration de l'intervalle de déschedulation
Copier lien

Vous pouvez configurer le temps qui s'écoule entre deux exécutions du Descheduler. La valeur par défaut est de 3600 secondes (une heure).

Conditions préalables

Privilèges de l'administrateur du cluster

Procédure

Modifiez l'objet KubeDescheduler:

oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

$ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

Copy to Clipboard

Toggle word wrap

Mettez à jour le champ deschedulingIntervalSeconds avec la valeur souhaitée :

apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600 
...

apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600

...

Copy to Clipboard

Toggle word wrap

1: Définit le nombre de secondes entre les exécutions du planificateur. Une valeur de 0 dans ce champ permet d'exécuter le descheduler une fois et de le quitter.

Enregistrez le fichier pour appliquer les modifications.

3.9.6. Désinstallation du déscheduler
Copier lien

Vous pouvez supprimer le descheduler de votre cluster en supprimant l'instance du descheduler et en désinstallant Kube Descheduler Operator. Cette procédure nettoie également l'espace de noms KubeDescheduler CRD et openshift-kube-descheduler-operator.

Conditions préalables

Privilèges d'administrateur de cluster.
Accès à la console web d'OpenShift Container Platform.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.
Supprime l'instance du déscheduler.
1. Sur la page Operators → Installed Operators, cliquez sur Kube Descheduler Operator.
2. Sélectionnez l'onglet Kube Descheduler.
3. Cliquez sur le menu Options à côté de l'entrée cluster et sélectionnez Delete KubeDescheduler.
4. Dans la boîte de dialogue de confirmation, cliquez sur Delete.
Désinstaller l'opérateur Kube Descheduler.
1. Naviguez jusqu'à Operators → Installed Operators.
2. Cliquez sur le menu Options à côté de l'entrée Kube Descheduler Operator et sélectionnez Uninstall Operator.
3. Dans la boîte de dialogue de confirmation, cliquez sur Uninstall.
Supprimer l'espace de noms openshift-kube-descheduler-operator.
1. Naviguez jusqu'à Administration → Namespaces.
2. Saisissez openshift-kube-descheduler-operator dans le champ de filtre.
3. Cliquez sur le menu Options à côté de l'entrée openshift-kube-descheduler-operator et sélectionnez Delete Namespace.
4. Dans la boîte de dialogue de confirmation, saisissez openshift-kube-descheduler-operator et cliquez sur Delete.
Supprimer le CRD KubeDescheduler.
1. Naviguez jusqu'à Administration → Custom Resource Definitions.
2. Saisissez KubeDescheduler dans le champ de filtre.
3. Cliquez sur le menu Options à côté de l'entrée KubeDescheduler et sélectionnez Delete CustomResourceDefinition.
4. Dans la boîte de dialogue de confirmation, cliquez sur Delete.

3.10. Ordonnanceur secondaire
Copier lien

3.10.1. Vue d'ensemble de l'ordonnanceur secondaire
Copier lien

Vous pouvez installer l'opérateur de planification secondaire pour exécuter un planificateur secondaire personnalisé parallèlement au planificateur par défaut afin de planifier les pods.

3.10.1.1. À propos de l'opérateur de planification secondaire
Copier lien

L'opérateur de planificateur secondaire pour Red Hat OpenShift permet de déployer un planificateur secondaire personnalisé dans OpenShift Container Platform. Le planificateur secondaire s'exécute en même temps que le planificateur par défaut pour planifier les pods. Les configurations des pods peuvent spécifier le planificateur à utiliser.

Le planificateur personnalisé doit avoir le binaire /bin/kube-scheduler et être basé sur le cadre de planification Kubernetes.

Important

Vous pouvez utiliser l'opérateur de planificateur secondaire pour déployer un planificateur secondaire personnalisé dans OpenShift Container Platform, mais Red Hat ne prend pas directement en charge la fonctionnalité du planificateur secondaire personnalisé.

L'opérateur d'ordonnancement secondaire crée les rôles par défaut et les liaisons de rôles nécessaires à l'ordonnateur secondaire. Vous pouvez spécifier les plugins de planification à activer ou à désactiver en configurant la ressource KubeSchedulerConfiguration pour l'ordonnanceur secondaire.

3.10.2. Notes de publication de Secondary Scheduler Operator pour Red Hat OpenShift
Copier lien

L'opérateur de planificateur secondaire pour Red Hat OpenShift vous permet de déployer un planificateur secondaire personnalisé dans votre cluster OpenShift Container Platform.

Ces notes de version suivent le développement de l'opérateur d'ordonnancement secondaire pour Red Hat OpenShift.

Pour plus d'informations, voir À propos de l'opérateur de planification secondaire.

3.10.2.1. Notes de version pour Secondary Scheduler Operator pour Red Hat OpenShift 1.1.0
Copier lien

Publié : 2022-9-1

L'avis suivant est disponible pour le Secondary Scheduler Operator pour Red Hat OpenShift 1.1.0 :

RHSA-2022:6152

3.10.2.1.1. Nouvelles fonctionnalités et améliorations
Copier lien

La configuration du contexte de sécurité de l'opérateur de planification secondaire a été mise à jour pour se conformer à l'application de l'admission à la sécurité des pods.

3.10.2.1.2. Problèmes connus
Copier lien

Actuellement, vous ne pouvez pas déployer de ressources supplémentaires, telles que des cartes de configuration, des CRD ou des stratégies RBAC par l'intermédiaire de l'opérateur de planification secondaire. Toutes les ressources autres que les rôles et les liaisons de rôles requises par votre planificateur secondaire personnalisé doivent être appliquées en externe. (BZ#2071684)

3.10.3. Ordonnancement de pods à l'aide d'un ordonnanceur secondaire
Copier lien

Vous pouvez exécuter un planificateur secondaire personnalisé dans OpenShift Container Platform en installant l'opérateur de planificateur secondaire, en déployant le planificateur secondaire et en définissant le planificateur secondaire dans la définition du pod.

3.10.3.1. Installation de l'opérateur de planification secondaire
Copier lien

Vous pouvez utiliser la console web pour installer l'opérateur de planification secondaire pour Red Hat OpenShift.

Conditions préalables

Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez accès à la console web de OpenShift Container Platform.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.
Créez l'espace de noms requis pour l'opérateur de planification secondaire pour Red Hat OpenShift.
1. Naviguez jusqu'à Administration → Namespaces et cliquez sur Create Namespace.
2. Saisissez openshift-secondary-scheduler-operator dans le champ Name et cliquez sur Create.
Installez l'opérateur de planification secondaire pour Red Hat OpenShift.
1. Naviguez jusqu'à Operators → OperatorHub.
2. Saisissez Secondary Scheduler Operator for Red Hat OpenShift dans le champ de filtre.
3. Sélectionnez le site Secondary Scheduler Operator for Red Hat OpenShift et cliquez sur Install.
4. Sur la page Install Operator:
  1. Le site Update channel est défini sur stable, ce qui installe la dernière version stable du Secondary Scheduler Operator pour Red Hat OpenShift.
  2. Sélectionnez A specific namespace on the cluster et sélectionnez openshift-secondary-scheduler-operator dans le menu déroulant.
  3. Sélectionnez une stratégie Update approval.
    La stratégie Automatic permet à Operator Lifecycle Manager (OLM) de mettre automatiquement à jour l'opérateur lorsqu'une nouvelle version est disponible.
    La stratégie Manual exige qu'un utilisateur disposant des informations d'identification appropriées approuve la mise à jour de l'opérateur.
  4. Cliquez sur Install.

Vérification

Naviguez jusqu'à Operators → Installed Operators.
Vérifiez que Secondary Scheduler Operator for Red Hat OpenShift est répertorié avec Status de Succeeded.

3.10.3.2. Déploiement d'un planificateur secondaire
Copier lien

Après avoir installé l'opérateur de planification secondaire, vous pouvez déployer un planificateur secondaire.

Conditions préalables

Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez accès à la console web de OpenShift Container Platform.
L'opérateur de planificateur secondaire pour Red Hat OpenShift est installé.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.

Créer une carte de configuration pour contenir la configuration de l'ordonnanceur secondaire.

Naviguez jusqu'à Workloads → ConfigMaps.
Cliquez sur Create ConfigMap.

Dans l'éditeur YAML, entrez la définition de la carte de configuration qui contient la configuration nécessaire de KubeSchedulerConfiguration. Par exemple :

apiVersion: v1
kind: ConfigMap
metadata:
  name: "secondary-scheduler-config"                  
  namespace: "openshift-secondary-scheduler-operator" 
data:
  "config.yaml": |
    apiVersion: kubescheduler.config.k8s.io/v1beta3
    kind: KubeSchedulerConfiguration                  
    leaderElection:
      leaderElect: false
    profiles:
      - schedulerName: secondary-scheduler            
        plugins:                                      
          score:
            disabled:
              - name: NodeResourcesBalancedAllocation
              - name: NodeResourcesLeastAllocated

apiVersion: v1
kind: ConfigMap
metadata:
  name: "secondary-scheduler-config"


  namespace: "openshift-secondary-scheduler-operator"


data:
  "config.yaml": |
    apiVersion: kubescheduler.config.k8s.io/v1beta3
    kind: KubeSchedulerConfiguration


    leaderElection:
      leaderElect: false
    profiles:
      - schedulerName: secondary-scheduler


        plugins:


          score:
            disabled:
              - name: NodeResourcesBalancedAllocation
              - name: NodeResourcesLeastAllocated

Copy to Clipboard

Toggle word wrap

1: Le nom de la carte de configuration. Il est utilisé dans le champ Scheduler Config lors de la création du CR SecondaryScheduler.
2: La carte de configuration doit être créée dans l'espace de noms openshift-secondary-scheduler-operator.
3: La ressource KubeSchedulerConfiguration pour l'ordonnanceur secondaire. Pour plus d'informations, voir KubeSchedulerConfiguration dans la documentation de l'API Kubernetes.
4: Nom de l'ordonnanceur secondaire. Les pods dont le champ spec.schedulerName contient cette valeur sont planifiés avec cet ordonnanceur secondaire.
5: Les plugins à activer ou désactiver pour l'ordonnanceur secondaire. Pour une liste des plugins d'ordonnancement par défaut, voir Scheduling plugins dans la documentation Kubernetes.

Cliquez sur Create.

Créer le CR SecondaryScheduler:
1. Naviguez jusqu'à Operators → Installed Operators.
2. Sélectionnez Secondary Scheduler Operator for Red Hat OpenShift.
3. Sélectionnez l'onglet Secondary Scheduler et cliquez sur Create SecondaryScheduler.
4. La valeur par défaut du champ Name est cluster; ne modifiez pas ce nom.
5. Le champ Scheduler Config a pour valeur par défaut secondary-scheduler-config. Assurez-vous que cette valeur correspond au nom de la carte de configuration créée plus tôt dans cette procédure.
6. Dans le champ Scheduler Image, saisissez le nom de l'image de votre programmateur personnalisé.
  Important
  Red Hat ne prend pas directement en charge la fonctionnalité de votre planificateur secondaire personnalisé.
7. Cliquez sur Create.

3.10.3.3. Programmation d'un pod à l'aide de l'ordonnanceur secondaire
Copier lien

Pour planifier un pod à l'aide du planificateur secondaire, définissez le champ schedulerName dans la définition du pod.

Conditions préalables

Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez accès à la console web de OpenShift Container Platform.
L'opérateur de planificateur secondaire pour Red Hat OpenShift est installé.
Un planificateur secondaire est configuré.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.
Navigate to Workloads → Pods.
Cliquez sur Create Pod.

Dans l'éditeur YAML, entrez la configuration de pod souhaitée et ajoutez le champ schedulerName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
        - containerPort: 80
  schedulerName: secondary-scheduler

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
        - containerPort: 80
  schedulerName: secondary-scheduler

Copy to Clipboard

Toggle word wrap

1: Le champ schedulerName doit correspondre au nom défini dans la carte de configuration lorsque vous avez configuré l'ordonnanceur secondaire.

Cliquez sur Create.

Vérification

Connectez-vous à l'interface CLI d'OpenShift.

Décrivez le pod à l'aide de la commande suivante :

oc describe pod nginx -n default

$ oc describe pod nginx -n default

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         nginx
Namespace:    default
Priority:     0
Node:         ci-ln-t0w4r1k-72292-xkqs4-worker-b-xqkxp/10.0.128.3
...
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  Scheduled       12s   secondary-scheduler  Successfully assigned default/nginx to ci-ln-t0w4r1k-72292-xkqs4-worker-b-xqkxp
...

Name:         nginx
Namespace:    default
Priority:     0
Node:         ci-ln-t0w4r1k-72292-xkqs4-worker-b-xqkxp/10.0.128.3
...
Events:
  Type    Reason          Age   From                 Message
  ----    ------          ----  ----                 -------
  Normal  Scheduled       12s   secondary-scheduler  Successfully assigned default/nginx to ci-ln-t0w4r1k-72292-xkqs4-worker-b-xqkxp
...

Copy to Clipboard

Toggle word wrap

Dans le tableau des événements, recherchez l'événement dont le message est similaire à Successfully assigned <namespace>/<pod_name> to <node_name>.
Dans la colonne "From", vérifiez que l'événement a été généré par le planificateur secondaire et non par le planificateur par défaut.
Note
Vous pouvez également consulter les journaux de pods de secondary-scheduler-* dans openshift-secondary-scheduler-namespace pour vérifier que le pod a été planifié par le planificateur secondaire.

3.10.4. Désinstallation de l'opérateur de planification secondaire
Copier lien

Vous pouvez supprimer l'opérateur Secondary Scheduler Operator for Red Hat OpenShift de OpenShift Container Platform en désinstallant l'opérateur et en supprimant ses ressources associées.

3.10.4.1. Désinstallation de l'opérateur de planification secondaire
Copier lien

Vous pouvez désinstaller l'opérateur de planification secondaire pour Red Hat OpenShift à l'aide de la console web.

Conditions préalables

Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez accès à la console web de OpenShift Container Platform.
L'opérateur de planificateur secondaire pour Red Hat OpenShift est installé.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.
Désinstallez l'opérateur de planification secondaire pour Red Hat OpenShift Operator.
1. Naviguez jusqu'à Operators → Installed Operators.
2. Cliquez sur le menu Options à côté de l'entrée Secondary Scheduler Operator et cliquez sur Uninstall Operator.
3. Dans la boîte de dialogue de confirmation, cliquez sur Uninstall.

3.10.4.2. Suppression des ressources de l'opérateur de planification secondaire
Copier lien

En option, après avoir désinstallé l'opérateur de planificateur secondaire pour Red Hat OpenShift, vous pouvez supprimer ses ressources connexes de votre cluster.

Conditions préalables

Vous avez accès au cluster avec les privilèges cluster-admin.
Vous avez accès à la console web de OpenShift Container Platform.

Procédure

Connectez-vous à la console web de OpenShift Container Platform.
Supprimez les CRD qui ont été installés par l'opérateur de planification secondaire :
1. Naviguez jusqu'à Administration → CustomResourceDefinitions.
2. Saisissez SecondaryScheduler dans le champ Name pour filtrer les CRD.
3. Cliquez sur le menu Options à côté du CRD SecondaryScheduler et sélectionnez Delete Custom Resource Definition:
Supprimer l'espace de noms openshift-secondary-scheduler-operator.
1. Naviguez jusqu'à Administration → Namespaces.
2. Cliquez sur le menu Options à côté de openshift-secondary-scheduler-operator et sélectionnez Delete Namespace.
3. Dans la boîte de dialogue de confirmation, saisissez openshift-secondary-scheduler-operator dans le champ et cliquez sur Delete.

Chapitre 4. Utilisation des Jobs et des DaemonSets
Copier lien

4.1. Exécution automatique des tâches d'arrière-plan sur les nœuds à l'aide d'ensembles de démons
Copier lien

En tant qu'administrateur, vous pouvez créer et utiliser des ensembles de démons pour exécuter des répliques d'un pod sur des nœuds spécifiques ou sur tous les nœuds d'un cluster OpenShift Container Platform.

Un ensemble de démons garantit que tous les nœuds (ou certains d'entre eux) exécutent une copie d'un module. Au fur et à mesure que des nœuds sont ajoutés au cluster, des pods sont ajoutés au cluster. Lorsque des nœuds sont supprimés du cluster, ces pods sont supprimés par le biais du garbage collection. La suppression d'un ensemble de démons nettoie les modules qu'il a créés.

Vous pouvez utiliser des ensembles de démons pour créer un stockage partagé, exécuter un pod de journalisation sur chaque nœud de votre cluster ou déployer un agent de surveillance sur chaque nœud.

Pour des raisons de sécurité, les administrateurs de clusters et les administrateurs de projets peuvent créer des jeux de démons.

Pour plus d'informations sur les ensembles de démons, voir la documentation Kubernetes.

Important

La planification du jeu de démons est incompatible avec le sélecteur de nœuds par défaut du projet. Si vous ne le désactivez pas, l'ensemble de démons est restreint par la fusion avec le sélecteur de nœuds par défaut. Il en résulte des recréations fréquentes de pods sur les nœuds qui n'ont pas été sélectionnés par le sélecteur de nœuds fusionné, ce qui entraîne une charge indésirable sur le cluster.

4.1.1. Planifié par le planificateur par défaut
Copier lien

Un ensemble de démons garantit que tous les nœuds éligibles exécutent une copie d'un pod. Normalement, le nœud sur lequel un pod s'exécute est sélectionné par le planificateur Kubernetes. Cependant, auparavant, les pods daemon set sont créés et planifiés par le contrôleur daemon set. Cela pose les problèmes suivants :

Comportement incohérent des pods : Les pods normaux qui attendent d'être planifiés sont créés et se trouvent dans l'état Pending, mais les pods daemon set ne sont pas créés dans l'état Pending. Cette situation est source de confusion pour l'utilisateur.
La préemption des pods est gérée par l'ordonnanceur par défaut. Lorsque la préemption est activée, le contrôleur de l'ensemble des démons prend des décisions d'ordonnancement sans tenir compte de la priorité et de la préemption des pods.

La fonctionnalité ScheduleDaemonSetPods, activée par défaut dans OpenShift Container Platform, vous permet de planifier des ensembles de démons en utilisant le planificateur par défaut au lieu du contrôleur d'ensembles de démons, en ajoutant le terme NodeAffinity aux pods d'ensembles de démons, au lieu du terme spec.nodeName. L'ordonnanceur par défaut est alors utilisé pour lier le pod à l'hôte cible. Si l'affinité de nœud du pod de l'ensemble de démons existe déjà, elle est remplacée. Le contrôleur de l'ensemble de démons n'effectue ces opérations que lors de la création ou de la modification des modules de l'ensemble de démons, et aucune modification n'est apportée à l'adresse spec.template de l'ensemble de démons.

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name

Copy to Clipboard

Toggle word wrap

En outre, une tolérance node.kubernetes.io/unschedulable:NoSchedule est ajoutée automatiquement aux pods de l'ensemble des démons. L'ordonnanceur par défaut ignore les nœuds non ordonnançables lors de l'ordonnancement des pods du jeu de démons.

4.1.2. Création de jeux de démons
Copier lien

Lors de la création d'ensembles de démons, le champ nodeSelector est utilisé pour indiquer les nœuds sur lesquels l'ensemble de démons doit déployer des répliques.

Conditions préalables

Avant de commencer à utiliser les ensembles de démons, désactivez le sélecteur de nœuds par défaut pour l'ensemble du projet dans votre espace de noms, en définissant l'annotation de l'espace de noms openshift.io/node-selector comme une chaîne vide :
```
oc patch namespace myproject -p \
    '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'
```
```
$ oc patch namespace myproject -p \
    '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'
```
Copy to Clipboard Toggle word wrap
Astuce
Vous pouvez également appliquer le YAML suivant pour désactiver le sélecteur de nœuds par défaut du projet pour un espace de noms :
apiVersion: v1 kind: Namespace metadata: name: <namespace> annotations: openshift.io/node-selector: ''
Copy to Clipboard Toggle word wrap
Si vous créez un nouveau projet, écrasez le sélecteur de nœuds par défaut :
```
oc adm new-project <name> --node-selector=""
```
```
$ oc adm new-project <name> --node-selector=""
```
Copy to Clipboard Toggle word wrap

Procédure

Pour créer un ensemble de démons :

Définir le fichier yaml du daemon :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: hello-daemonset
spec:
  selector:
      matchLabels:
        name: hello-daemonset 
  template:
    metadata:
      labels:
        name: hello-daemonset 
    spec:
      nodeSelector: 
        role: worker
      containers:
      - image: openshift/hello-openshift
        imagePullPolicy: Always
        name: registry
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
      serviceAccount: default
      terminationGracePeriodSeconds: 10

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: hello-daemonset
spec:
  selector:
      matchLabels:
        name: hello-daemonset


  template:
    metadata:
      labels:
        name: hello-daemonset


    spec:
      nodeSelector:


        role: worker
      containers:
      - image: openshift/hello-openshift
        imagePullPolicy: Always
        name: registry
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
      serviceAccount: default
      terminationGracePeriodSeconds: 10

Copy to Clipboard

Toggle word wrap

1: Le sélecteur d'étiquettes qui détermine quels pods appartiennent à l'ensemble de démons.
2: Le sélecteur d'étiquette du modèle de pod. Il doit correspondre au sélecteur d'étiquette ci-dessus.
3: Le sélecteur de nœud qui détermine sur quels nœuds les répliques de pods doivent être déployées. Un label correspondant doit être présent sur le nœud.

Créer l'objet daemon set :
```
oc create -f daemonset.yaml
```
```
$ oc create -f daemonset.yaml
```
Copy to Clipboard Toggle word wrap

Vérifier que les pods ont été créés et que chaque nœud dispose d'une réplique de pod :

Trouver les pods du daemonset :

oc get pods

$ oc get pods

Copy to Clipboard

Toggle word wrap

Exemple de sortie

hello-daemonset-cx6md   1/1       Running   0          2m
hello-daemonset-e3md9   1/1       Running   0          2m

hello-daemonset-cx6md   1/1       Running   0          2m
hello-daemonset-e3md9   1/1       Running   0          2m

Copy to Clipboard

Toggle word wrap

Affichez les modules pour vérifier qu'ils ont bien été placés sur le nœud :

oc describe pod/hello-daemonset-cx6md|grep Node

$ oc describe pod/hello-daemonset-cx6md|grep Node

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Node:        openshift-node01.hostname.com/10.14.20.134

Node:        openshift-node01.hostname.com/10.14.20.134

Copy to Clipboard

Toggle word wrap

oc describe pod/hello-daemonset-e3md9|grep Node

$ oc describe pod/hello-daemonset-e3md9|grep Node

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Node:        openshift-node02.hostname.com/10.14.20.137

Node:        openshift-node02.hostname.com/10.14.20.137

Copy to Clipboard

Toggle word wrap

Important

Si vous mettez à jour un modèle de pod de daemon set, les répliques de pod existantes ne sont pas affectées.
Si vous supprimez un ensemble de démons et que vous en créez un nouveau avec un modèle différent mais le même sélecteur d'étiquettes, il reconnaît les réplicas de pods existants comme ayant des étiquettes correspondantes et ne les met donc pas à jour ou ne crée pas de nouveaux réplicas en dépit d'une incohérence dans le modèle de pod.
Si vous modifiez les étiquettes des nœuds, l'ensemble de démons ajoute des modules aux nœuds qui correspondent aux nouvelles étiquettes et supprime les modules des nœuds qui ne correspondent pas aux nouvelles étiquettes.

Pour mettre à jour un ensemble de démons, il faut forcer la création de nouvelles répliques de pods en supprimant les anciennes répliques ou les nœuds.

4.2. Exécuter des tâches dans des pods à l'aide de jobs
Copier lien

Un job exécute une tâche dans votre cluster OpenShift Container Platform.

Un job suit la progression globale d'une tâche et met à jour son statut avec des informations sur les pods actifs, réussis et échoués. La suppression d'un job nettoiera toutes les répliques de pods qu'il a créées. Les tâches font partie de l'API Kubernetes, qui peut être gérée avec des commandes oc comme d'autres types d'objets.

Exemple de cahier des charges

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    
  completions: 1    
  activeDeadlineSeconds: 1800 
  backoffLimit: 6   
  template:         
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1


  completions: 1


  activeDeadlineSeconds: 1800


  backoffLimit: 6


  template:


    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure

Copy to Clipboard

Toggle word wrap

1: Les répliques de pods qu'un travail doit exécuter en parallèle.
2: Pour qu'un travail soit considéré comme achevé, il faut que les pods soient terminés avec succès.
3: Durée maximale d'exécution du travail.
4: Nombre de tentatives pour un travail.
5: Le modèle du module créé par le contrôleur.
6: La politique de redémarrage du pod.

Voir la documentation de Kubernetes pour plus d'informations sur les travaux.

4.2.1. Comprendre les jobs et les cron jobs
Copier lien

Un travail permet de suivre la progression globale d'une tâche et de mettre à jour son état avec des informations sur les modules actifs, réussis et échoués. La suppression d'un job nettoie tous les pods qu'il a créés. Les tâches font partie de l'API Kubernetes, qui peut être gérée avec des commandes oc comme d'autres types d'objets.

Il existe deux types de ressources possibles qui permettent de créer des objets run-once dans OpenShift Container Platform :

Emploi: Un travail régulier est un objet à exécution unique qui crée une tâche et s'assure qu'elle se termine.

Il existe trois principaux types de tâches susceptibles d'être exécutées en tant que travaux :

Travaux non parallèles :
- Un travail qui ne démarre qu'un seul module, à moins que le module n'échoue.
- Le travail est terminé dès que le pod se termine avec succès.
Travaux parallèles avec un nombre fixe d'achèvements :
- un travail qui démarre plusieurs pods.
- Le travail représente la tâche globale et est terminé lorsqu'il y a un pod réussi pour chaque valeur comprise entre 1 et la valeur completions.
Travaux parallèles avec une file d'attente :
- Un travail avec plusieurs processus de travail en parallèle dans un pod donné.
- OpenShift Container Platform coordonne les pods pour déterminer ce sur quoi chacun doit travailler ou utiliser un service de file d'attente externe.
- Chaque pod est capable de déterminer indépendamment si tous les pods pairs sont complets et si le travail est terminé.
- Lorsqu'un pod de la tâche se termine avec succès, aucun nouveau pod n'est créé.
- Lorsqu'au moins un pod s'est terminé avec succès et que tous les pods sont terminés, le travail est terminé avec succès.
- Lorsqu'un module est sorti avec succès, aucun autre module ne doit être en train de travailler sur cette tâche ou d'écrire une sortie. Les modules doivent tous être en train de se terminer.

Pour plus d'informations sur l'utilisation des différents types de tâches, voir Job Patterns dans la documentation Kubernetes.

Travail Cron: Une tâche peut être programmée pour être exécutée plusieurs fois, à l'aide d'une tâche cron.

Un cron job s'appuie sur un travail normal en vous permettant de spécifier comment le travail doit être exécuté. Les tâches Cron font partie de l'API Kubernetes, qui peut être gérée avec des commandes oc comme d'autres types d'objets.

Les tâches Cron sont utiles pour créer des tâches périodiques et récurrentes, comme l'exécution de sauvegardes ou l'envoi d'e-mails. Les tâches cron peuvent également planifier des tâches individuelles à un moment précis, par exemple si vous souhaitez planifier une tâche pendant une période de faible activité. Un travail cron crée un objet Job basé sur le fuseau horaire configuré sur le nœud du plan de contrôle qui exécute le contrôleur de travail cron.

Avertissement

Un travail cron crée un objet Job environ une fois par heure d'exécution de sa programmation, mais il peut arriver qu'il ne crée pas de travail ou que deux travaux soient créés. Par conséquent, les tâches doivent être idempotentes et vous devez configurer des limites d'historique.

4.2.1.1. Comprendre comment créer des emplois
Copier lien

Les deux types de ressources nécessitent une configuration de travail qui se compose des éléments clés suivants :

Un modèle de pod, qui décrit le pod créé par OpenShift Container Platform.
Le paramètre parallelism, qui indique combien de pods fonctionnant en parallèle à un moment donné doivent exécuter un travail.
- Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
Le paramètre completions, qui spécifie le nombre d'achèvements de pods réussis nécessaires pour terminer un travail.
- Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
- Pour les travaux parallèles avec un nombre d'achèvements fixe, indiquez une valeur.
- Pour les travaux parallèles avec une file d'attente, laissez la valeur non définie. Lorsqu'il n'est pas défini, il prend par défaut la valeur parallelism.

4.2.1.2. Comprendre comment fixer une durée maximale pour les travaux
Copier lien

Lors de la définition d'un travail, vous pouvez définir sa durée maximale en définissant le champ activeDeadlineSeconds. Ce champ est spécifié en secondes et n'est pas défini par défaut. S'il n'est pas défini, aucune durée maximale n'est imposée.

La durée maximale est calculée à partir du moment où un premier module est programmé dans le système et définit la durée pendant laquelle un travail peut être actif. Elle permet de suivre la durée totale d'une exécution. Après avoir atteint le délai spécifié, le travail est terminé par OpenShift Container Platform.

4.2.1.3. Comprendre comment mettre en place une politique de reprise des travaux en cas de défaillance d'un pod
Copier lien

Un travail peut être considéré comme échoué après un certain nombre de tentatives en raison d'une erreur logique dans la configuration ou d'autres raisons similaires. Les modules défaillants associés au travail sont recréés par le contrôleur avec un délai exponentiel (10s, 20s, 40s...) plafonné à six minutes. La limite est réinitialisée si aucun nouveau pod échoué n'apparaît entre les vérifications du contrôleur.

Le paramètre spec.backoffLimit permet de définir le nombre de tentatives pour un travail.

4.2.1.4. Comprendre comment configurer une tâche cron pour supprimer les artefacts
Copier lien

Les tâches Cron peuvent laisser des ressources artéfactuelles telles que des tâches ou des pods. En tant qu'utilisateur, il est important de configurer les limites de l'historique afin que les anciens travaux et leurs pods soient correctement nettoyés. Il y a deux champs dans la spécification du job cron qui sont responsables de cela :

.spec.successfulJobsHistoryLimit. Nombre de travaux terminés avec succès à conserver (3 par défaut).
.spec.failedJobsHistoryLimit. Nombre d'échecs de travaux terminés à conserver (1 par défaut).

Astuce

Supprimez les tâches cron dont vous n'avez plus besoin :
```
oc delete cronjob/<cron_job_name>
```
```
oc delete cronjob/<cron_job_name>
```
Copy to Clipboard Toggle word wrap
Cela leur évite de générer des artefacts inutiles.
Vous pouvez suspendre les exécutions ultérieures en fixant la valeur de spec.suspend à true. Toutes les exécutions suivantes sont suspendues jusqu'à ce que vous réinitialisiez false.

4.2.1.5. Limites connues
Copier lien

La politique de redémarrage de la spécification des tâches ne s'applique qu'à pods, et non à job controller. Cependant, le contrôleur de tâches est codé en dur pour continuer à relancer les tâches jusqu'à ce qu'elles soient terminées.

Ainsi, restartPolicy: Never ou --restart=Never a le même comportement que restartPolicy: OnFailure ou --restart=OnFailure, c'est-à-dire que lorsqu'un travail échoue, il est redémarré automatiquement jusqu'à ce qu'il réussisse (ou qu'il soit écarté manuellement). La politique définit uniquement le sous-système qui effectue le redémarrage.

Avec la politique Never, c'est job controller qui effectue le redémarrage. À chaque tentative, le contrôleur de tâches incrémente le nombre d'échecs dans l'état de la tâche et crée de nouveaux modules. Cela signifie qu'à chaque tentative échouée, le nombre de pods augmente.

Avec la politique OnFailure, kubelet effectue le redémarrage. Chaque tentative n'incrémente pas le nombre d'échecs dans le statut du travail. De plus, kubelet réessayera les tâches qui ont échoué en démarrant des pods sur les mêmes nœuds.

4.2.2. Créer des emplois
Copier lien

Vous créez un job dans OpenShift Container Platform en créant un objet job.

Procédure

Créer un emploi :

Créez un fichier YAML similaire au suivant :
```
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    
  completions: 1    
  activeDeadlineSeconds: 1800 
  backoffLimit: 6   
  template:         
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure    
```
```
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    
```
1
```
  completions: 1    
```
2
```
  activeDeadlineSeconds: 1800 
```
3
```
  backoffLimit: 6   
```
4
```
  template:         
```
5
```
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure    
```
6
Copy to Clipboard Toggle word wrap
1
Facultatif : Spécifiez le nombre de répliques de pods qu'un travail doit exécuter en parallèle ; la valeur par défaut est 1.
Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
2
Facultatif : Indiquez le nombre de pods terminés avec succès pour qu'un travail soit considéré comme terminé.
Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
Pour les travaux parallèles avec un nombre d'achèvements fixe, indiquez le nombre d'achèvements.
Pour les travaux parallèles avec une file d'attente, laissez la valeur non définie. Lorsqu'il n'est pas défini, il prend par défaut la valeur parallelism.
3
Facultatif : Indiquez la durée maximale d'exécution du travail.
4
Facultatif : Indiquez le nombre de tentatives pour un travail. La valeur par défaut de ce champ est de six.
5
Spécifiez le modèle du module créé par le contrôleur.
6
Spécifiez la politique de redémarrage du module :
Never. Ne pas relancer le travail.
OnFailure. Ne redémarrez le travail qu'en cas d'échec.
Always. Il faut toujours redémarrer le travail.
Pour plus de détails sur la façon dont OpenShift Container Platform utilise la politique de redémarrage avec les conteneurs en panne, voir les États d'exemple dans la documentation Kubernetes.
Créer l'emploi :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Note

Vous pouvez également créer et lancer un travail à partir d'une seule commande en utilisant oc create job. La commande suivante crée et lance un travail similaire à celui spécifié dans l'exemple précédent :

oc create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'

$ oc create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'

Copy to Clipboard

Toggle word wrap

4.2.3. Création de tâches cron
Copier lien

Vous créez un job cron dans OpenShift Container Platform en créant un objet job.

Procédure

Pour créer une tâche cron :

Créez un fichier YAML similaire au suivant :
```
apiVersion: batch/v1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "*/1 * * * *"          
  timeZone: Etc/UTC                
  concurrencyPolicy: "Replace"     
  startingDeadlineSeconds: 200     
  suspend: true                    
  successfulJobsHistoryLimit: 3    
  failedJobsHistoryLimit: 1        
  jobTemplate:                     
    spec:
      template:
        metadata:
          labels:                  
            parent: "cronjobpi"
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: OnFailure 
```
```
apiVersion: batch/v1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "*/1 * * * *"          
```
1
```
  timeZone: Etc/UTC                
```
2
```
  concurrencyPolicy: "Replace"     
```
3
```
  startingDeadlineSeconds: 200     
```
4
```
  suspend: true                    
```
5
```
  successfulJobsHistoryLimit: 3    
```
6
```
  failedJobsHistoryLimit: 1        
```
7
```
  jobTemplate:                     
```
8
```
    spec:
      template:
        metadata:
          labels:                  
```
9
```
            parent: "cronjobpi"
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: OnFailure 
```
10
Copy to Clipboard Toggle word wrap
1
Planification de la tâche spécifiée au format cron. Dans cet exemple, le travail sera exécuté toutes les minutes.
2
Un fuseau horaire facultatif pour la programmation. Voir Liste des fuseaux horaires de la base de données tz pour les options valides. S'il n'est pas spécifié, le gestionnaire de contrôleur Kubernetes interprète la planification par rapport à son fuseau horaire local. Ce paramètre est proposé en tant qu'aperçu technologique.
3
Une politique de concurrence optionnelle, spécifiant comment traiter les tâches concurrentes au sein d'une tâche cron. Seule l'une des politiques de concurrence suivantes peut être spécifiée. Si elle n'est pas spécifiée, elle autorise par défaut les exécutions simultanées.
Allow permet aux tâches cron de s'exécuter simultanément.
Forbid interdit les exécutions simultanées, en sautant l'exécution suivante si la précédente n'est pas encore terminée.
Replace annule le travail en cours et le remplace par un nouveau.
4
Délai facultatif (en secondes) pour lancer le travail s'il dépasse l'heure prévue pour une raison quelconque. Les exécutions manquées seront considérées comme des échecs. Si ce délai n'est pas spécifié, il n'y a pas de date limite.
5
Un drapeau optionnel permettant de suspendre une tâche cron. S'il vaut true, toutes les exécutions suivantes seront suspendues.
6
Nombre de travaux terminés avec succès à conserver (3 par défaut).
7
Nombre d'échecs de travaux terminés à conserver (valeur par défaut : 1).
8
Modèle d'emploi. Ce modèle est similaire à l'exemple d'emploi.
9
Définit une étiquette pour les travaux créés par ce travail cron.
10
La politique de redémarrage du module. Elle ne s'applique pas au contrôleur de tâches.
Note
Les champs .spec.successfulJobsHistoryLimit et .spec.failedJobsHistoryLimit sont facultatifs. Ils indiquent le nombre de tâches terminées et échouées à conserver. Par défaut, ils sont respectivement fixés à 3 et 1. Définir une limite à 0 correspond à ne conserver aucun des travaux du type correspondant une fois qu'ils sont terminés.
Créez la tâche cron :
```
oc create -f <nom-de-fichier>.yaml
```
```
oc create -f <nom-de-fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Note

Vous pouvez également créer et lancer une tâche cron à partir d'une seule commande en utilisant oc create cronjob. La commande suivante crée et lance une tâche cron similaire à celle spécifiée dans l'exemple précédent :

oc create cronjob pi --image=perl --schedule='*/1 * * * *' -- perl -Mbignum=bpi -wle 'print bpi(2000)'

$ oc create cronjob pi --image=perl --schedule='*/1 * * * *' -- perl -Mbignum=bpi -wle 'print bpi(2000)'

Copy to Clipboard

Toggle word wrap

Avec oc create cronjob, l'option --schedule accepte les programmes au format cron.

Chapitre 5. Travailler avec des nœuds
Copier lien

5.1. Afficher et lister les nœuds de votre cluster OpenShift Container Platform
Copier lien

Vous pouvez dresser la liste de tous les nœuds de votre cluster afin d'obtenir des informations telles que l'état, l'âge, l'utilisation de la mémoire et des détails sur les nœuds.

Lorsque vous effectuez des opérations de gestion de nœuds, l'interface CLI interagit avec des objets de nœuds qui sont des représentations d'hôtes de nœuds réels. Le maître utilise les informations des objets de nœuds pour valider les nœuds à l'aide de contrôles de santé.

5.1.1. A propos de la liste de tous les nœuds d'une grappe
Copier lien

Vous pouvez obtenir des informations détaillées sur les nœuds du cluster.

La commande suivante permet de dresser la liste de tous les nœuds :

oc get nodes

$ oc get nodes

Copy to Clipboard

Toggle word wrap

L'exemple suivant est celui d'un cluster dont les nœuds sont sains :

oc get nodes

$ oc get nodes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                   STATUS    ROLES     AGE       VERSION
master.example.com     Ready     master    7h        v1.25.0
node1.example.com      Ready     worker    7h        v1.25.0
node2.example.com      Ready     worker    7h        v1.25.0

NAME                   STATUS    ROLES     AGE       VERSION
master.example.com     Ready     master    7h        v1.25.0
node1.example.com      Ready     worker    7h        v1.25.0
node2.example.com      Ready     worker    7h        v1.25.0

Copy to Clipboard

Toggle word wrap

L'exemple suivant est celui d'un cluster avec un nœud en mauvaise santé :

oc get nodes

$ oc get nodes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                   STATUS                      ROLES     AGE       VERSION
master.example.com     Ready                       master    7h        v1.25.0
node1.example.com      NotReady,SchedulingDisabled worker    7h        v1.25.0
node2.example.com      Ready                       worker    7h        v1.25.0

NAME                   STATUS                      ROLES     AGE       VERSION
master.example.com     Ready                       master    7h        v1.25.0
node1.example.com      NotReady,SchedulingDisabled worker    7h        v1.25.0
node2.example.com      Ready                       worker    7h        v1.25.0

Copy to Clipboard

Toggle word wrap

Les conditions qui déclenchent l'état NotReady sont présentées plus loin dans cette section.

L'option -o wide fournit des informations supplémentaires sur les nœuds.

oc get nodes -o wide

$ oc get nodes -o wide

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                STATUS   ROLES    AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                 CONTAINER-RUNTIME
master.example.com  Ready    master   171m   v1.25.0   10.0.129.108   <none>        Red Hat Enterprise Linux CoreOS 48.83.202103210901-0 (Ootpa)   4.18.0-240.15.1.el8_3.x86_64   cri-o://1.25.0-30.rhaos4.10.gitf2f339d.el8-dev
node1.example.com   Ready    worker   72m    v1.25.0   10.0.129.222   <none>        Red Hat Enterprise Linux CoreOS 48.83.202103210901-0 (Ootpa)   4.18.0-240.15.1.el8_3.x86_64   cri-o://1.25.0-30.rhaos4.10.gitf2f339d.el8-dev
node2.example.com   Ready    worker   164m   v1.25.0   10.0.142.150   <none>        Red Hat Enterprise Linux CoreOS 48.83.202103210901-0 (Ootpa)   4.18.0-240.15.1.el8_3.x86_64   cri-o://1.25.0-30.rhaos4.10.gitf2f339d.el8-dev

NAME                STATUS   ROLES    AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                                                       KERNEL-VERSION                 CONTAINER-RUNTIME
master.example.com  Ready    master   171m   v1.25.0   10.0.129.108   <none>        Red Hat Enterprise Linux CoreOS 48.83.202103210901-0 (Ootpa)   4.18.0-240.15.1.el8_3.x86_64   cri-o://1.25.0-30.rhaos4.10.gitf2f339d.el8-dev
node1.example.com   Ready    worker   72m    v1.25.0   10.0.129.222   <none>        Red Hat Enterprise Linux CoreOS 48.83.202103210901-0 (Ootpa)   4.18.0-240.15.1.el8_3.x86_64   cri-o://1.25.0-30.rhaos4.10.gitf2f339d.el8-dev
node2.example.com   Ready    worker   164m   v1.25.0   10.0.142.150   <none>        Red Hat Enterprise Linux CoreOS 48.83.202103210901-0 (Ootpa)   4.18.0-240.15.1.el8_3.x86_64   cri-o://1.25.0-30.rhaos4.10.gitf2f339d.el8-dev

Copy to Clipboard

Toggle word wrap

La commande suivante répertorie les informations relatives à un seul nœud :

oc get node <node> $ oc get node <node>

oc get node <node> $ oc get node <node>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc get node node1.example.com

$ oc get node node1.example.com

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                   STATUS    ROLES     AGE       VERSION
node1.example.com      Ready     worker    7h        v1.25.0

NAME                   STATUS    ROLES     AGE       VERSION
node1.example.com      Ready     worker    7h        v1.25.0

Copy to Clipboard

Toggle word wrap

La commande suivante fournit des informations plus détaillées sur un nœud spécifique, y compris la raison de l'état actuel :

oc describe node <node>

$ oc describe node <node>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc describe node node1.example.com

$ oc describe node node1.example.com

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:               node1.example.com 
Roles:              worker 
Labels:             beta.kubernetes.io/arch=amd64   
                    beta.kubernetes.io/instance-type=m4.large
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=us-east-2
                    failure-domain.beta.kubernetes.io/zone=us-east-2a
                    kubernetes.io/hostname=ip-10-0-140-16
                    node-role.kubernetes.io/worker=
Annotations:        cluster.k8s.io/machine: openshift-machine-api/ahardin-worker-us-east-2a-q5dzc  
                    machineconfiguration.openshift.io/currentConfig: worker-309c228e8b3a92e2235edd544c62fea8
                    machineconfiguration.openshift.io/desiredConfig: worker-309c228e8b3a92e2235edd544c62fea8
                    machineconfiguration.openshift.io/state: Done
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Wed, 13 Feb 2019 11:05:57 -0500
Taints:             <none>  
Unschedulable:      false
Conditions:                 
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  OutOfDisk        False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure   False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:07:09 -0500   KubeletReady                 kubelet is posting ready status
Addresses:   
  InternalIP:   10.0.140.16
  InternalDNS:  ip-10-0-140-16.us-east-2.compute.internal
  Hostname:     ip-10-0-140-16.us-east-2.compute.internal
Capacity:    
 attachable-volumes-aws-ebs:  39
 cpu:                         2
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8172516Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7558116Ki
 pods:                        250
System Info:    
 Machine ID:                              63787c9534c24fde9a0cde35c13f1f66
 System UUID:                             EC22BF97-A006-4A58-6AF8-0A38DEEA122A
 Boot ID:                                 f24ad37d-2594-46b4-8830-7f7555918325
 Kernel Version:                          3.10.0-957.5.1.el7.x86_64
 OS Image:                                Red Hat Enterprise Linux CoreOS 410.8.20190520.0 (Ootpa)
 Operating System:                        linux
 Architecture:                            amd64
 Container Runtime Version:               cri-o://1.25.0-0.6.dev.rhaos4.3.git9ad059b.el8-rc2
 Kubelet Version:                         v1.25.0
 Kube-Proxy Version:                      v1.25.0
PodCIDR:                                  10.128.4.0/24
ProviderID:                               aws:///us-east-2a/i-04e87b31dc6b3e171
Non-terminated Pods:                      (12 in total)  
  Namespace                               Name                                   CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                               ----                                   ------------  ----------  ---------------  -------------
  openshift-cluster-node-tuning-operator  tuned-hdl5q                            0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-dns                           dns-default-l69zr                      0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-image-registry                node-ca-9hmcg                          0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-ingress                       router-default-76455c45c-c5ptv         0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-machine-config-operator       machine-config-daemon-cvqw9            20m (1%)      0 (0%)      50Mi (0%)        0 (0%)
  openshift-marketplace                   community-operators-f67fh              0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-monitoring                    alertmanager-main-0                    50m (3%)      50m (3%)    210Mi (2%)       10Mi (0%)
  openshift-monitoring                    node-exporter-l7q8d                    10m (0%)      20m (1%)    20Mi (0%)        40Mi (0%)
  openshift-monitoring                    prometheus-adapter-75d769c874-hvb85    0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-multus                        multus-kw8w5                           0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-sdn                           ovs-t4dsn                              100m (6%)     0 (0%)      300Mi (4%)       0 (0%)
  openshift-sdn                           sdn-g79hg                              100m (6%)     0 (0%)      200Mi (2%)       0 (0%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests     Limits
  --------                    --------     ------
  cpu                         380m (25%)   270m (18%)
  memory                      880Mi (11%)  250Mi (3%)
  attachable-volumes-aws-ebs  0            0
Events:     
  Type     Reason                   Age                From                      Message
  ----     ------                   ----               ----                      -------
  Normal   NodeHasSufficientPID     6d (x5 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientPID
  Normal   NodeAllocatableEnforced  6d                 kubelet, m01.example.com  Updated Node Allocatable limit across pods
  Normal   NodeHasSufficientMemory  6d (x6 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientMemory
  Normal   NodeHasNoDiskPressure    6d (x6 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientDisk    6d (x6 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientDisk
  Normal   NodeHasSufficientPID     6d                 kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientPID
  Normal   Starting                 6d                 kubelet, m01.example.com  Starting kubelet.
 ...

Name:               node1.example.com


Roles:              worker


Labels:             beta.kubernetes.io/arch=amd64


                    beta.kubernetes.io/instance-type=m4.large
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=us-east-2
                    failure-domain.beta.kubernetes.io/zone=us-east-2a
                    kubernetes.io/hostname=ip-10-0-140-16
                    node-role.kubernetes.io/worker=
Annotations:        cluster.k8s.io/machine: openshift-machine-api/ahardin-worker-us-east-2a-q5dzc


                    machineconfiguration.openshift.io/currentConfig: worker-309c228e8b3a92e2235edd544c62fea8
                    machineconfiguration.openshift.io/desiredConfig: worker-309c228e8b3a92e2235edd544c62fea8
                    machineconfiguration.openshift.io/state: Done
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Wed, 13 Feb 2019 11:05:57 -0500
Taints:             <none>


Unschedulable:      false
Conditions:


  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  OutOfDisk        False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure   False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:05:57 -0500   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Wed, 13 Feb 2019 15:09:42 -0500   Wed, 13 Feb 2019 11:07:09 -0500   KubeletReady                 kubelet is posting ready status
Addresses:


  InternalIP:   10.0.140.16
  InternalDNS:  ip-10-0-140-16.us-east-2.compute.internal
  Hostname:     ip-10-0-140-16.us-east-2.compute.internal
Capacity:


 attachable-volumes-aws-ebs:  39
 cpu:                         2
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8172516Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7558116Ki
 pods:                        250
System Info:


 Machine ID:                              63787c9534c24fde9a0cde35c13f1f66
 System UUID:                             EC22BF97-A006-4A58-6AF8-0A38DEEA122A
 Boot ID:                                 f24ad37d-2594-46b4-8830-7f7555918325
 Kernel Version:                          3.10.0-957.5.1.el7.x86_64
 OS Image:                                Red Hat Enterprise Linux CoreOS 410.8.20190520.0 (Ootpa)
 Operating System:                        linux
 Architecture:                            amd64
 Container Runtime Version:               cri-o://1.25.0-0.6.dev.rhaos4.3.git9ad059b.el8-rc2
 Kubelet Version:                         v1.25.0
 Kube-Proxy Version:                      v1.25.0
PodCIDR:                                  10.128.4.0/24
ProviderID:                               aws:///us-east-2a/i-04e87b31dc6b3e171
Non-terminated Pods:                      (12 in total)


  Namespace                               Name                                   CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                               ----                                   ------------  ----------  ---------------  -------------
  openshift-cluster-node-tuning-operator  tuned-hdl5q                            0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-dns                           dns-default-l69zr                      0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-image-registry                node-ca-9hmcg                          0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-ingress                       router-default-76455c45c-c5ptv         0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-machine-config-operator       machine-config-daemon-cvqw9            20m (1%)      0 (0%)      50Mi (0%)        0 (0%)
  openshift-marketplace                   community-operators-f67fh              0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-monitoring                    alertmanager-main-0                    50m (3%)      50m (3%)    210Mi (2%)       10Mi (0%)
  openshift-monitoring                    node-exporter-l7q8d                    10m (0%)      20m (1%)    20Mi (0%)        40Mi (0%)
  openshift-monitoring                    prometheus-adapter-75d769c874-hvb85    0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-multus                        multus-kw8w5                           0 (0%)        0 (0%)      0 (0%)           0 (0%)
  openshift-sdn                           ovs-t4dsn                              100m (6%)     0 (0%)      300Mi (4%)       0 (0%)
  openshift-sdn                           sdn-g79hg                              100m (6%)     0 (0%)      200Mi (2%)       0 (0%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests     Limits
  --------                    --------     ------
  cpu                         380m (25%)   270m (18%)
  memory                      880Mi (11%)  250Mi (3%)
  attachable-volumes-aws-ebs  0            0
Events:


  Type     Reason                   Age                From                      Message
  ----     ------                   ----               ----                      -------
  Normal   NodeHasSufficientPID     6d (x5 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientPID
  Normal   NodeAllocatableEnforced  6d                 kubelet, m01.example.com  Updated Node Allocatable limit across pods
  Normal   NodeHasSufficientMemory  6d (x6 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientMemory
  Normal   NodeHasNoDiskPressure    6d (x6 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientDisk    6d (x6 over 6d)    kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientDisk
  Normal   NodeHasSufficientPID     6d                 kubelet, m01.example.com  Node m01.example.com status is now: NodeHasSufficientPID
  Normal   Starting                 6d                 kubelet, m01.example.com  Starting kubelet.
 ...

Copy to Clipboard

Toggle word wrap

1: Le nom du nœud.
2: Le rôle du nœud, soit master ou worker.
3: Les étiquettes appliquées au nœud.
4: Les annotations appliquées au nœud.
5: Les taches appliquées au nœud.
6: Les conditions et l'état du nœud. La strophe conditions énumère les états Ready, PIDPressure, PIDPressure, MemoryPressure, DiskPressure et OutOfDisk. Ces conditions sont décrites plus loin dans cette section.
7: L'adresse IP et le nom d'hôte du nœud.
8: Les ressources pods et les ressources allouables.
9: Informations sur l'hôte du nœud.
10: Les pods sur le nœud.
11: Les événements signalés par le nœud.

Parmi les informations affichées pour les nœuds, les conditions suivantes apparaissent dans la sortie des commandes présentées dans cette section :

Expand

Tableau 5.1. Conditions du nœud
Condition	Description
`Ready`	Si `true`, le nœud est sain et prêt à accepter des pods. Si `false`, le nœud n'est pas sain et n'accepte pas de modules. Si `unknown`, le contrôleur de nœud n'a pas reçu de battement de cœur du nœud depuis `node-monitor-grace-period` (la valeur par défaut est de 40 secondes).
`DiskPressure`	Si `true`, la capacité du disque est faible.
`MemoryPressure`	Si `true`, la mémoire du nœud est faible.
`PIDPressure`	Si `true`, il y a trop de processus sur le nœud.
`OutOfDisk`	Si `true`, le nœud ne dispose pas de suffisamment d'espace libre pour ajouter de nouveaux modules.
`NetworkUnavailable`	Si `true`, le réseau du nœud n'est pas correctement configuré.
`NotReady`	Si `true`, l'un des composants sous-jacents, comme l'exécution du conteneur ou le réseau, rencontre des problèmes ou n'est pas encore configuré.
`SchedulingDisabled`	Les pods ne peuvent pas être planifiés pour être placés sur le nœud.

5.1.2. Lister les pods sur un nœud de votre cluster
Copier lien

Vous pouvez répertorier tous les pods sur un nœud spécifique.

Procédure

Pour dresser la liste de tous les pods ou d'une sélection de pods sur un ou plusieurs nœuds :
```
oc describe node <node1> <node2>
```
```
$ oc describe node <node1> <node2>
```
Copy to Clipboard Toggle word wrap
Par exemple :
```
oc describe node ip-10-0-128-218.ec2.internal
```
```
$ oc describe node ip-10-0-128-218.ec2.internal
```
Copy to Clipboard Toggle word wrap

Pour répertorier tous les pods ou certains pods sur les nœuds sélectionnés :

oc describe --selector=<node_selector>

oc describe --selector=<node_selector>

Copy to Clipboard

Toggle word wrap

oc describe node  --selector=kubernetes.io/os

$ oc describe node  --selector=kubernetes.io/os

Copy to Clipboard

Toggle word wrap

Ou bien :

oc describe -l=<pod_selector> $ oc describe -l=<pod_selector>

oc describe -l=<pod_selector> $ oc describe -l=<pod_selector>

Copy to Clipboard

Toggle word wrap

oc describe node -l node-role.kubernetes.io/worker

$ oc describe node -l node-role.kubernetes.io/worker

Copy to Clipboard

Toggle word wrap

Pour lister tous les pods sur un nœud spécifique, y compris les pods terminés :

oc get pod --all-namespaces --field-selector=spec.nodeName=<nodename> $ oc get pod --all-namespaces --field-selector=spec.nodeName=<nodename>

oc get pod --all-namespaces --field-selector=spec.nodeName=<nodename> $ oc get pod --all-namespaces --field-selector=spec.nodeName=<nodename>

Copy to Clipboard

Toggle word wrap

5.1.3. Affichage des statistiques d'utilisation de la mémoire et de l'unité centrale sur vos nœuds
Copier lien

Vous pouvez afficher les statistiques d'utilisation des nœuds, qui fournissent les environnements d'exécution des conteneurs. Ces statistiques d'utilisation comprennent la consommation de CPU, de mémoire et de stockage.

Conditions préalables

Vous devez avoir l'autorisation cluster-reader pour voir les statistiques d'utilisation.
Metrics doit être installé pour afficher les statistiques d'utilisation.

Procédure

Pour consulter les statistiques d'utilisation :

oc adm top nodes

$ oc adm top nodes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                   CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
ip-10-0-12-143.ec2.compute.internal    1503m        100%      4533Mi          61%
ip-10-0-132-16.ec2.compute.internal    76m          5%        1391Mi          18%
ip-10-0-140-137.ec2.compute.internal   398m         26%       2473Mi          33%
ip-10-0-142-44.ec2.compute.internal    656m         43%       6119Mi          82%
ip-10-0-146-165.ec2.compute.internal   188m         12%       3367Mi          45%
ip-10-0-19-62.ec2.compute.internal     896m         59%       5754Mi          77%
ip-10-0-44-193.ec2.compute.internal    632m         42%       5349Mi          72%

NAME                                   CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
ip-10-0-12-143.ec2.compute.internal    1503m        100%      4533Mi          61%
ip-10-0-132-16.ec2.compute.internal    76m          5%        1391Mi          18%
ip-10-0-140-137.ec2.compute.internal   398m         26%       2473Mi          33%
ip-10-0-142-44.ec2.compute.internal    656m         43%       6119Mi          82%
ip-10-0-146-165.ec2.compute.internal   188m         12%       3367Mi          45%
ip-10-0-19-62.ec2.compute.internal     896m         59%       5754Mi          77%
ip-10-0-44-193.ec2.compute.internal    632m         42%       5349Mi          72%

Copy to Clipboard

Toggle word wrap

Pour afficher les statistiques d'utilisation des nœuds avec étiquettes :
```
oc adm top node --selector=''
```
```
$ oc adm top node --selector=''
```
Copy to Clipboard Toggle word wrap
Vous devez choisir le sélecteur (requête d'étiquette) sur lequel filtrer. Prend en charge =, ==, et !=.

5.2. Travailler avec des nœuds
Copier lien

En tant qu'administrateur, vous pouvez effectuer un certain nombre de tâches pour rendre vos grappes plus efficaces.

5.2.1. Comprendre comment évacuer les pods sur les nœuds
Copier lien

L'évacuation des pods permet de migrer tous les pods ou certains pods d'un ou de plusieurs nœuds donnés.

Vous ne pouvez évacuer que les modules soutenus par un contrôleur de réplication. Le contrôleur de réplication crée de nouveaux pods sur d'autres nœuds et supprime les pods existants sur le(s) nœud(s) spécifié(s).

Les pods nus, c'est-à-dire ceux qui ne sont pas soutenus par un contrôleur de réplication, ne sont pas affectés par défaut. Vous pouvez évacuer un sous-ensemble de modules en spécifiant un sélecteur de modules. Les sélecteurs de modules sont basés sur des étiquettes, de sorte que tous les modules portant l'étiquette spécifiée seront évacués.

Procédure

Marquer les nœuds inséparables avant d'effectuer l'évacuation des nacelles.

Marquer le nœud comme non ordonnançable :
```
oc adm cordon <node1> $ oc adm cordon <node1>
```
```
oc adm cordon <node1> $ oc adm cordon <node1>
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
node/<node1> cordonné
```
```
node/<node1> cordonné
```
Copy to Clipboard Toggle word wrap

Vérifiez que l'état du nœud est bien Ready,SchedulingDisabled:

oc get node <node1> $ oc get node <node1>

oc get node <node1> $ oc get node <node1>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME        STATUS                     ROLES     AGE       VERSION
<node1>     Ready,SchedulingDisabled   worker    1d        v1.25.0

NAME        STATUS                     ROLES     AGE       VERSION
<node1>     Ready,SchedulingDisabled   worker    1d        v1.25.0

Copy to Clipboard

Toggle word wrap

Évacuez les nacelles en utilisant l'une des méthodes suivantes :
- Évacuer tous les pods ou certains pods sur un ou plusieurs nœuds :
  $ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
  Copy to Clipboard Toggle word wrap
- Forcez la suppression des pods nus à l'aide de l'option --force. Lorsque l'option est définie sur true, la suppression se poursuit même si des pods ne sont pas gérés par un contrôleur de réplication, un ensemble de réplicas, un job, un ensemble de démons ou un ensemble avec état :
  $ oc adm drain <node1> <node2> --force=true
  Copy to Clipboard Toggle word wrap
- Définir une période de temps en secondes pour que chaque pod se termine gracieusement, utiliser --grace-period. Si elle est négative, la valeur par défaut spécifiée dans le pod sera utilisée :
  $ oc adm drain <node1> <node2> --grace-period=-1
  Copy to Clipboard Toggle word wrap
- Ignorer les pods gérés par des ensembles de démons utilisant l'indicateur --ignore-daemonsets avec la valeur true:
  $ oc adm drain <node1> <node2> --ignore-daemonsets=true
  Copy to Clipboard Toggle word wrap
- Fixe le temps d'attente avant d'abandonner en utilisant le drapeau --timeout. Une valeur de 0 définit une durée infinie :
  $ oc adm drain <node1> <node2> --timeout=5s
  Copy to Clipboard Toggle word wrap
- Supprimez les pods même s'il existe des pods utilisant des volumes emptyDir en définissant l'indicateur --delete-emptydir-data sur true. Les données locales sont supprimées lorsque le nœud est vidé :
  $ oc adm drain <node1> <node2> --delete-emptydir-data=true
  Copy to Clipboard Toggle word wrap
- Lister les objets qui seront migrés sans effectuer l'évacuation, en utilisant l'option --dry-run réglée sur true:
  $ oc adm drain <node1> <node2> --dry-run=true
  Copy to Clipboard Toggle word wrap
  Au lieu de spécifier des noms de nœuds spécifiques (par exemple, <node1> <node2>), vous pouvez utiliser l'option --selector=<node_selector> pour évacuer les pods sur des nœuds sélectionnés.
Marquer le nœud comme planifiable lorsqu'il est terminé.
```
oc adm uncordon <node1> $ oc adm uncordon <node1>
```
```
oc adm uncordon <node1> $ oc adm uncordon <node1>
```
Copy to Clipboard Toggle word wrap

5.2.2. Comprendre comment mettre à jour les étiquettes sur les nœuds
Copier lien

Vous pouvez mettre à jour n'importe quelle étiquette d'un nœud.

Les étiquettes de nœuds ne sont pas conservées après la suppression d'un nœud, même si le nœud est sauvegardé par une machine.

Note

Toute modification apportée à un objet MachineSet n'est pas appliquée aux machines existantes appartenant à l'ensemble de machines de calcul. Par exemple, les étiquettes modifiées ou ajoutées à un objet MachineSet existant ne sont pas propagées aux machines et nœuds existants associés à l'ensemble de machines de calcul.

La commande suivante permet d'ajouter ou de mettre à jour des étiquettes sur un nœud :

oc label node <node> <key_1>=<value_1> ... <clé_n>=<valeur_n>

$ oc label node <node> <key_1>=<value_1> ... <clé_n>=<valeur_n>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc label nodes webconsole-7f7f6 unhealthy=true

$ oc label nodes webconsole-7f7f6 unhealthy=true

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour appliquer l'étiquette :

kind: Node
apiVersion: v1
metadata:
  name: webconsole-7f7f6
  labels:
    unhealthy: 'true'

kind: Node
apiVersion: v1
metadata:
  name: webconsole-7f7f6
  labels:
    unhealthy: 'true'

Copy to Clipboard

Toggle word wrap

La commande suivante met à jour tous les pods de l'espace de noms :
```
oc label pods --all <key_1>=<value_1>
```
```
$ oc label pods --all <key_1>=<value_1>
```
Copy to Clipboard Toggle word wrap
Par exemple :
```
oc label pods --all status=unhealthy
```
```
$ oc label pods --all status=unhealthy
```
Copy to Clipboard Toggle word wrap

5.2.3. Comprendre comment marquer les nœuds comme non planifiables ou planifiables
Copier lien

Par défaut, les nœuds sains avec un statut Ready sont marqués comme planifiables, ce qui signifie que vous pouvez placer de nouveaux pods sur le nœud. Le fait de marquer manuellement un nœud comme non planifiable empêche la planification de nouveaux modules sur ce nœud. Les pods existants sur le nœud ne sont pas affectés.

La commande suivante marque un ou plusieurs nœuds comme non ordonnançables :

Exemple de sortie

oc adm cordon <node>

$ oc adm cordon <node>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc adm cordon node1.example.com

$ oc adm cordon node1.example.com

Copy to Clipboard

Toggle word wrap

Exemple de sortie

node/node1.example.com cordoned

NAME                 LABELS                                        STATUS
node1.example.com    kubernetes.io/hostname=node1.example.com      Ready,SchedulingDisabled

node/node1.example.com cordoned

NAME                 LABELS                                        STATUS
node1.example.com    kubernetes.io/hostname=node1.example.com      Ready,SchedulingDisabled

Copy to Clipboard

Toggle word wrap

La commande suivante marque un ou plusieurs nœuds non ordonnançables comme ordonnançables :
```
oc adm uncordon <node1> $ oc adm uncordon <node1>
```
```
oc adm uncordon <node1> $ oc adm uncordon <node1>
```
Copy to Clipboard Toggle word wrap
Au lieu de spécifier des noms de nœuds spécifiques (par exemple, <node>), vous pouvez utiliser l'option --selector=<node_selector> pour marquer les nœuds sélectionnés comme ordonnançables ou non ordonnançables.

5.2.4. Suppression de nœuds
Copier lien

5.2.4.1. Suppression de nœuds d'une grappe
Copier lien

Lorsque vous supprimez un nœud à l'aide de la CLI, l'objet nœud est supprimé dans Kubernetes, mais les pods qui existent sur le nœud ne sont pas supprimés. Tous les pods nus qui ne sont pas soutenus par un contrôleur de réplication deviennent inaccessibles à OpenShift Container Platform. Les pods soutenus par des contrôleurs de réplication sont replanifiés sur d'autres nœuds disponibles. Vous devez supprimer les pods de manifeste locaux.

Procédure

Pour supprimer un nœud du cluster OpenShift Container Platform, modifiez l'objet MachineSet approprié :

Note

Si vous exécutez un cluster sur du métal nu, vous ne pouvez pas supprimer un nœud en modifiant les objets MachineSet. Les ensembles de machines de calcul ne sont disponibles que lorsqu'un cluster est intégré à un fournisseur de cloud. Au lieu de cela, vous devez déprogrammer et vidanger le nœud avant de le supprimer manuellement.

Affichez les ensembles de machines de calcul qui se trouvent dans la grappe :
```
oc get machinesets -n openshift-machine-api
```
```
$ oc get machinesets -n openshift-machine-api
```
Copy to Clipboard Toggle word wrap
Les ensembles de machines de calcul sont répertoriés sous la forme <clusterid>-worker-<aws-region-az>.

Mettre à l'échelle l'ensemble des machines de calcul :

oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Ou bien :

oc edit machineset <machineset> -n openshift-machine-api

$ oc edit machineset <machineset> -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Astuce

Vous pouvez également appliquer le YAML suivant pour mettre à l'échelle l'ensemble des machines de calcul :

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2

Copy to Clipboard

Toggle word wrap

5.2.4.2. Suppression de nœuds d'un cluster bare metal
Copier lien

Procédure

Supprimez un nœud d'un cluster OpenShift Container Platform fonctionnant sur du métal nu en effectuant les étapes suivantes :

Marquer le nœud comme non ordonnançable :
```
oc adm cordon <node_name>
```
```
$ oc adm cordon <node_name>
```
Copy to Clipboard Toggle word wrap
Drainer tous les pods sur le nœud :
```
oc adm drain <node_name> --force=true
```
```
oc adm drain <node_name> --force=true
```
Copy to Clipboard Toggle word wrap
Cette étape peut échouer si le nœud est hors ligne ou ne répond pas. Même si le nœud ne répond pas, il est possible qu'il exécute toujours une charge de travail qui écrit dans le stockage partagé. Pour éviter toute corruption de données, mettez le matériel physique hors tension avant de poursuivre.
Supprimer le nœud de la grappe :
```
oc delete node <node_name> $ oc delete node <node_name>
```
```
oc delete node <node_name> $ oc delete node <node_name>
```
Copy to Clipboard Toggle word wrap
Bien que l'objet nœud soit désormais supprimé du cluster, il peut toujours rejoindre le cluster après un redémarrage ou si le service kubelet est redémarré. Pour supprimer définitivement le nœud et toutes ses données, vous devez le déclasser.
Si vous avez mis le matériel physique hors tension, remettez-le sous tension pour que le nœud puisse rejoindre le cluster.

5.3. Gestion des nœuds
Copier lien

OpenShift Container Platform utilise une ressource personnalisée KubeletConfig (CR) pour gérer la configuration des nœuds. En créant une instance d'un objet KubeletConfig, une configuration de machine gérée est créée pour remplacer les paramètres du nœud.

Note

Logging in to remote machines for the purpose of changing their configuration is not supported.

5.3.1. Modification des nœuds
Copier lien

Pour apporter des modifications à la configuration d'un cluster ou d'un pool de machines, vous devez créer une définition de ressource personnalisée (CRD) ou un objet kubeletConfig. OpenShift Container Platform utilise le Machine Config Controller pour surveiller les changements introduits par le CRD afin d'appliquer les changements au cluster.

Note

Comme les champs d'un objet kubeletConfig sont transmis directement au kubelet par Kubernetes en amont, la validation de ces champs est gérée directement par le kubelet lui-même. Veuillez vous référer à la documentation Kubernetes pertinente pour connaître les valeurs valides de ces champs. Des valeurs invalides dans l'objet kubeletConfig peuvent rendre les nœuds de cluster inutilisables.

Procédure

Obtenez l'étiquette associée au CRD statique, Machine Config Pool, pour le type de nœud que vous souhaitez configurer. Effectuez l'une des étapes suivantes :

Vérifier les étiquettes actuelles du pool de configuration de la machine souhaitée.

Par exemple :

 oc get machineconfigpool  --show-labels

$  oc get machineconfigpool  --show-labels

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME      CONFIG                                             UPDATED   UPDATING   DEGRADED   LABELS
master    rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd   True      False      False      operator.machineconfiguration.openshift.io/required-for-upgrade=
worker    rendered-worker-f50e78e1bc06d8e82327763145bfcf62   True      False      False

NAME      CONFIG                                             UPDATED   UPDATING   DEGRADED   LABELS
master    rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd   True      False      False      operator.machineconfiguration.openshift.io/required-for-upgrade=
worker    rendered-worker-f50e78e1bc06d8e82327763145bfcf62   True      False      False

Copy to Clipboard

Toggle word wrap

Ajoutez une étiquette personnalisée au pool de configuration de la machine souhaitée.
Par exemple :
```
oc label machineconfigpool worker custom-kubelet=enabled
```
```
$ oc label machineconfigpool worker custom-kubelet=enabled
```
Copy to Clipboard Toggle word wrap

Créez une ressource personnalisée (CR) kubeletconfig pour votre changement de configuration.

Par exemple :

Exemple de configuration pour un CR custom-config

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: custom-config 
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: enabled 
  kubeletConfig: 
    podsPerCore: 10
    maxPods: 250
    systemReserved:
      cpu: 2000m
      memory: 1Gi

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: custom-config


spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: enabled


  kubeletConfig:


    podsPerCore: 10
    maxPods: 250
    systemReserved:
      cpu: 2000m
      memory: 1Gi

Copy to Clipboard

Toggle word wrap

1: Attribuer un nom au CR.
2: Spécifiez l'étiquette pour appliquer le changement de configuration, il s'agit de l'étiquette que vous avez ajoutée au pool de configuration de la machine.
3: Indiquez la ou les nouvelles valeurs à modifier.

Créer l'objet CR.
```
oc create -f <nom-de-fichier>
```
```
$ oc create -f <nom-de-fichier>
```
Copy to Clipboard Toggle word wrap
Par exemple :
```
oc create -f master-kube-config.yaml
```
```
$ oc create -f master-kube-config.yaml
```
Copy to Clipboard Toggle word wrap

La plupart des options de configuration de Kubelet peuvent être définies par l'utilisateur. Les options suivantes ne peuvent pas être écrasées :

CgroupDriver
ClusterDNS
Domaine de regroupement
StaticPodPath

Note

Si un seul nœud contient plus de 50 images, la planification des pods peut être déséquilibrée entre les nœuds. En effet, la liste des images sur un nœud est réduite à 50 par défaut. Vous pouvez désactiver la limite d'images en modifiant l'objet KubeletConfig et en définissant la valeur de nodeStatusMaxImages à -1.

5.3.2. Configuration des nœuds du plan de contrôle comme planifiables
Copier lien

Vous pouvez configurer les nœuds du plan de contrôle pour qu'ils soient programmables, ce qui signifie que les nouveaux pods sont autorisés à être placés sur les nœuds maîtres. Par défaut, les nœuds du plan de contrôle ne sont pas programmables.

Vous pouvez faire en sorte que les maîtres soient programmables, mais vous devez conserver les nœuds de travail.

Note

Vous pouvez déployer OpenShift Container Platform sans nœuds de travail sur un cluster bare metal. Dans ce cas, les nœuds du plan de contrôle sont marqués comme planifiables par défaut.

Vous pouvez autoriser ou non les nœuds du plan de contrôle à être planifiables en configurant le champ mastersSchedulable.

Important

Lorsque vous configurez les nœuds du plan de contrôle pour qu'ils soient planifiables au lieu d'être non planifiables par défaut, des abonnements supplémentaires sont nécessaires. En effet, les nœuds du plan de contrôle deviennent alors des nœuds de travail.

Procédure

Modifier la ressource schedulers.config.openshift.io.
```
oc edit schedulers.config.openshift.io cluster
```
```
$ oc edit schedulers.config.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

Configurez le champ mastersSchedulable.

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: "2019-09-10T03:04:05Z"
  generation: 1
  name: cluster
  resourceVersion: "433"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: a636d30a-d377-11e9-88d4-0a60097bee62
spec:
  mastersSchedulable: false 
status: {}

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: "2019-09-10T03:04:05Z"
  generation: 1
  name: cluster
  resourceVersion: "433"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: a636d30a-d377-11e9-88d4-0a60097bee62
spec:
  mastersSchedulable: false


status: {}

Copy to Clipboard

Toggle word wrap

1: La valeur true permet aux nœuds du plan de contrôle d'être programmables ou la valeur false interdit aux nœuds du plan de contrôle d'être programmables.

Enregistrez le fichier pour appliquer les modifications.

5.3.3. Définition des booléens SELinux
Copier lien

OpenShift Container Platform vous permet d'activer et de désactiver un booléen SELinux sur un nœud Red Hat Enterprise Linux CoreOS (RHCOS). La procédure suivante explique comment modifier les booléens SELinux sur les nœuds à l'aide de l'opérateur de configuration de machine (MCO). Cette procédure utilise container_manage_cgroup comme exemple de booléen. Vous pouvez modifier cette valeur pour obtenir le booléen dont vous avez besoin.

Conditions préalables

Vous avez installé le CLI OpenShift (oc).

Procédure

Créez un nouveau fichier YAML avec un objet MachineConfig, comme dans l'exemple suivant :

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-setsebool
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - contents: |
          [Unit]
          Description=Set SELinux booleans
          Before=kubelet.service

          [Service]
          Type=oneshot
          ExecStart=/sbin/setsebool container_manage_cgroup=on
          RemainAfterExit=true

          [Install]
          WantedBy=multi-user.target graphical.target
        enabled: true
        name: setsebool.service

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-setsebool
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - contents: |
          [Unit]
          Description=Set SELinux booleans
          Before=kubelet.service

          [Service]
          Type=oneshot
          ExecStart=/sbin/setsebool container_manage_cgroup=on
          RemainAfterExit=true

          [Install]
          WantedBy=multi-user.target graphical.target
        enabled: true
        name: setsebool.service

Copy to Clipboard

Toggle word wrap

Créez le nouvel objet MachineConfig en exécutant la commande suivante :
```
oc create -f 99-worker-setsebool.yaml
```
```
$ oc create -f 99-worker-setsebool.yaml
```
Copy to Clipboard Toggle word wrap

Note

L'application de toute modification à l'objet MachineConfig entraîne un redémarrage en douceur de tous les nœuds concernés après l'application de la modification.

5.3.4. Ajout d'arguments de noyau aux nœuds
Copier lien

Dans certains cas particuliers, vous pouvez ajouter des arguments de noyau à un ensemble de nœuds de votre cluster. Cela ne doit être fait qu'avec prudence et en comprenant bien les implications des arguments que vous définissez.

Avertissement

Une mauvaise utilisation des arguments du noyau peut rendre vos systèmes non amorçables.

Voici quelques exemples d'arguments de noyau que vous pouvez définir :

enforcing=0: Configure Security Enhanced Linux (SELinux) pour qu'il fonctionne en mode permissif. En mode permissif, le système agit comme si SELinux appliquait la politique de sécurité chargée, notamment en étiquetant les objets et en émettant des entrées de refus d'accès dans les journaux, mais il ne refuse en fait aucune opération. Bien qu'il ne soit pas pris en charge par les systèmes de production, le mode permissif peut s'avérer utile pour le débogage.
nosmt: Désactive le multithreading symétrique (SMT) dans le noyau. Le multithreading permet d'avoir plusieurs threads logiques pour chaque unité centrale. Vous pouvez envisager d'utiliser nosmt dans les environnements multi-locataires afin de réduire les risques d'attaques croisées. En désactivant le SMT, vous choisissez essentiellement la sécurité au détriment des performances.
systemd.unified_cgroup_hierarchy: Active le groupe de contrôle Linux version 2 (cgroup v2). cgroup v2 est la prochaine version du groupe de contrôle du noyau et offre de nombreuses améliorations.
Important
OpenShift Container Platform cgroups version 2 support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
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.

Voir Kernel.org kernel parameters pour une liste et une description des arguments du noyau.

Dans la procédure suivante, vous créez un objet MachineConfig qui identifie :

Ensemble de machines auxquelles vous souhaitez ajouter l'argument du noyau. Dans ce cas, il s'agit des machines ayant un rôle de travailleur.
Arguments du noyau qui sont ajoutés à la fin des arguments du noyau existants.
Une étiquette qui indique à quel endroit de la liste des configurations de machines la modification est appliquée.

Conditions préalables

Disposer de privilèges administratifs sur un cluster OpenShift Container Platform opérationnel.

Procédure

Listez les objets MachineConfig existants pour votre cluster OpenShift Container Platform afin de déterminer comment étiqueter votre machine config :

oc get MachineConfig

$ oc get MachineConfig

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

Copy to Clipboard

Toggle word wrap

Créer un fichier objet MachineConfig qui identifie l'argument du noyau (par exemple, 05-worker-kernelarg-selinuxpermissive.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 05-worker-kernelarg-selinuxpermissive
spec:
  kernelArguments:
    - enforcing=0

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker


  name: 05-worker-kernelarg-selinuxpermissive


spec:
  kernelArguments:
    - enforcing=0

Copy to Clipboard

Toggle word wrap

1: Applique le nouvel argument du noyau uniquement aux nœuds de travail.
2: Nommé pour identifier sa place dans les configurations de la machine (05) et ce qu'il fait (ajoute un argument au noyau pour configurer le mode permissif de SELinux).
3: Identifie l'argument exact du noyau comme enforcing=0.

Créer la nouvelle configuration de la machine :

oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

$ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

Copy to Clipboard

Toggle word wrap

Vérifiez les configurations de la machine pour voir si le nouveau a été ajouté :

oc get MachineConfig

$ oc get MachineConfig

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-master-ssh                                                                                 3.2.0             40m
99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
99-worker-ssh                                                                                 3.2.0             40m
rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

Copy to Clipboard

Toggle word wrap

Vérifier les nœuds :

oc get nodes

$ oc get nodes

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.25.0
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.25.0
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.25.0
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.25.0
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.25.0
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.25.0

NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.25.0
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.25.0
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.25.0
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.25.0
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.25.0
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.25.0

Copy to Clipboard

Toggle word wrap

Vous pouvez voir que la planification sur chaque nœud de travailleur est désactivée pendant que la modification est appliquée.

Vérifiez que l'argument du noyau a fonctionné en vous rendant sur l'un des nœuds de travail et en listant les arguments de la ligne de commande du noyau (dans /proc/cmdline sur l'hôte) :

oc debug node/ip-10-0-141-105.ec2.internal

$ oc debug node/ip-10-0-141-105.ec2.internal

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Starting pod/ip-10-0-141-105ec2internal-debug ...
To use host binaries, run `chroot /host`

sh-4.2# cat /host/proc/cmdline
BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0

sh-4.2# exit

Starting pod/ip-10-0-141-105ec2internal-debug ...
To use host binaries, run `chroot /host`

sh-4.2# cat /host/proc/cmdline
BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0

sh-4.2# exit

Copy to Clipboard

Toggle word wrap

Vous devriez voir l'argument enforcing=0 ajouté aux autres arguments du noyau.

5.3.5. Activation de l'utilisation de la mémoire d'échange sur les nœuds
Copier lien

Important

L'activation de l'utilisation de la mémoire d'échange sur les nœuds est une fonctionnalité d'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 sur le plan 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.

Vous pouvez activer l'utilisation de la mémoire d'échange pour les charges de travail d'OpenShift Container Platform sur une base par nœud.

Avertissement

L'activation de la mémoire d'échange peut avoir un impact négatif sur les performances de la charge de travail et sur la gestion des ressources manquantes. N'activez pas la mémoire d'échange sur les nœuds du plan de contrôle.

Pour activer la mémoire tampon, créez une ressource personnalisée (CR) kubeletconfig afin de définir le paramètre swapbehavior. Vous pouvez définir une mémoire d'échange limitée ou illimitée :

Limité : Utilisez la valeur LimitedSwap pour limiter la quantité de mémoire d'échange que les charges de travail peuvent utiliser. Toutes les charges de travail sur le nœud qui ne sont pas gérées par OpenShift Container Platform peuvent toujours utiliser la mémoire d'échange. Le comportement de LimitedSwap dépend de l'exécution du nœud avec les groupes de contrôle Linux version 1 (cgroups v1) ou version 2 (cgroup v2):
- cgroup v1 : Les charges de travail d'OpenShift Container Platform peuvent utiliser n'importe quelle combinaison de mémoire et de swap, jusqu'à la limite de mémoire du pod, si elle est définie.
- cgroup v2 : Les charges de travail d'OpenShift Container Platform ne peuvent pas utiliser de mémoire d'échange.
Illimité : Utilisez la valeur UnlimitedSwap pour permettre aux charges de travail d'utiliser autant de mémoire d'échange qu'elles le souhaitent, jusqu'à la limite du système.

Comme le kubelet ne démarrera pas en présence de mémoire d'échange sans cette configuration, vous devez activer la mémoire d'échange dans OpenShift Container Platform avant d'activer la mémoire d'échange sur les nœuds. S'il n'y a pas de mémoire d'échange sur un nœud, l'activation de la mémoire d'échange dans OpenShift Container Platform n'a aucun effet.

Conditions préalables

Vous disposez d'un cluster OpenShift Container Platform en cours d'exécution qui utilise la version 4.10 ou une version ultérieure.
You are logged in to the cluster as a user with administrative privileges.
Vous avez activé le jeu de fonctionnalités TechPreviewNoUpgrade sur le cluster (voir Nodes → Working with clusters → Enabling features using feature gates).
Note
L'activation de l'ensemble de fonctionnalités TechPreviewNoUpgrade ne peut être annulée et empêche les mises à jour mineures de la version. Ces jeux de fonctionnalités ne sont pas recommandés sur les clusters de production.
Si le cgroup v2 est activé sur un nœud, vous devez activer la comptabilité de swap sur le nœud, en définissant l'argument du noyau swapaccount=1.

Procédure

Appliquez une étiquette personnalisée au pool de configuration de la machine dans lequel vous souhaitez autoriser la mémoire d'échange.
```
oc label machineconfigpool worker kubelet-swap=enabled
```
```
$ oc label machineconfigpool worker kubelet-swap=enabled
```
Copy to Clipboard Toggle word wrap

Créer une ressource personnalisée (CR) pour activer et configurer les paramètres d'échange.

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: swap-config
spec:
  machineConfigPoolSelector:
    matchLabels:
      kubelet-swap: enabled
  kubeletConfig:
    failSwapOn: false 
    memorySwap:
      swapBehavior: LimitedSwap

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: swap-config
spec:
  machineConfigPoolSelector:
    matchLabels:
      kubelet-swap: enabled
  kubeletConfig:
    failSwapOn: false


    memorySwap:
      swapBehavior: LimitedSwap

Copy to Clipboard

Toggle word wrap

1: La valeur false permet d'activer l'utilisation de la mémoire d'échange sur les nœuds associés. La valeur true désactive l'utilisation de la mémoire d'échange.
2: Spécifier le comportement de la mémoire d'échange. S'il n'est pas spécifié, la valeur par défaut est LimitedSwap.

Activer la mémoire tampon sur les machines.

5.3.6. Migration des nœuds du plan de contrôle d'un hôte RHOSP à un autre
Copier lien

Vous pouvez exécuter un script qui déplace un nœud de plan de contrôle d'un nœud Red Hat OpenStack Platform (RHOSP) à un autre.

Conditions préalables

La variable d'environnement OS_CLOUD fait référence à une entrée clouds qui contient des informations d'identification administratives dans un fichier clouds.yaml.
La variable d'environnement KUBECONFIG fait référence à une configuration qui contient les identifiants administratifs de OpenShift Container Platform.

Procédure

À partir d'une ligne de commande, exécutez le script suivant :

#!/usr/bin/env bash

set -Eeuo pipefail

if [ $# -lt 1 ]; then
	echo "Usage: '$0 node_name'"
	exit 64
fi

# Check for admin OpenStack credentials
openstack server list --all-projects >/dev/null || { >&2 echo "The script needs OpenStack admin credentials. Exiting"; exit 77; }

# Check for admin OpenShift credentials
oc adm top node >/dev/null || { >&2 echo "The script needs OpenShift admin credentials. Exiting"; exit 77; }

set -x

declare -r node_name="$1"
declare server_id
server_id="$(openstack server list --all-projects -f value -c ID -c Name | grep "$node_name" | cut -d' ' -f1)"
readonly server_id

# Drain the node
oc adm cordon "$node_name"
oc adm drain "$node_name" --delete-emptydir-data --ignore-daemonsets --force

# Power off the server
oc debug "node/${node_name}" -- chroot /host shutdown -h 1

# Verify the server is shut off
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Migrate the node
openstack server migrate --wait "$server_id"

# Resize the VM
openstack server resize confirm "$server_id"

# Wait for the resize confirm to finish
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Restart the VM
openstack server start "$server_id"

# Wait for the node to show up as Ready:
until oc get node "$node_name" | grep -q "^${node_name}[[:space:]]\+Ready"; do sleep 5; done

# Uncordon the node
oc adm uncordon "$node_name"

# Wait for cluster operators to stabilize
until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done

#!/usr/bin/env bash

set -Eeuo pipefail

if [ $# -lt 1 ]; then
	echo "Usage: '$0 node_name'"
	exit 64
fi

# Check for admin OpenStack credentials
openstack server list --all-projects >/dev/null || { >&2 echo "The script needs OpenStack admin credentials. Exiting"; exit 77; }

# Check for admin OpenShift credentials
oc adm top node >/dev/null || { >&2 echo "The script needs OpenShift admin credentials. Exiting"; exit 77; }

set -x

declare -r node_name="$1"
declare server_id
server_id="$(openstack server list --all-projects -f value -c ID -c Name | grep "$node_name" | cut -d' ' -f1)"
readonly server_id

# Drain the node
oc adm cordon "$node_name"
oc adm drain "$node_name" --delete-emptydir-data --ignore-daemonsets --force

# Power off the server
oc debug "node/${node_name}" -- chroot /host shutdown -h 1

# Verify the server is shut off
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Migrate the node
openstack server migrate --wait "$server_id"

# Resize the VM
openstack server resize confirm "$server_id"

# Wait for the resize confirm to finish
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Restart the VM
openstack server start "$server_id"

# Wait for the node to show up as Ready:
until oc get node "$node_name" | grep -q "^${node_name}[[:space:]]\+Ready"; do sleep 5; done

# Uncordon the node
oc adm uncordon "$node_name"

# Wait for cluster operators to stabilize
until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done

Copy to Clipboard

Toggle word wrap

Si le script aboutit, la machine du plan de contrôle est migrée vers un nouveau nœud RHOSP.

5.4. Gérer le nombre maximum de pods par nœud
Copier lien

Dans OpenShift Container Platform, vous pouvez configurer le nombre de pods qui peuvent s'exécuter sur un nœud en fonction du nombre de cœurs de processeur sur le nœud, d'une limite stricte ou des deux. Si vous utilisez les deux options, la moins élevée des deux limite le nombre de pods sur un nœud.

Le dépassement de ces valeurs peut entraîner

Augmentation de l'utilisation du processeur par OpenShift Container Platform.
Lenteur de la programmation des pods.
Scénarios potentiels de dépassement de mémoire, en fonction de la quantité de mémoire dans le nœud.
Epuisement du pool d'adresses IP.
Surcharge des ressources, entraînant de mauvaises performances pour les applications utilisateur.

Note

Un pod qui contient un seul conteneur utilise en réalité deux conteneurs. Le deuxième conteneur met en place le réseau avant le démarrage du conteneur proprement dit. Par conséquent, un nœud exécutant 10 pods a en réalité 20 conteneurs en cours d'exécution.

Le paramètre podsPerCore limite le nombre de modules que le nœud peut exécuter en fonction du nombre de cœurs de processeur du nœud. Par exemple, si podsPerCore est défini sur 10 sur un nœud avec 4 cœurs de processeur, le nombre maximum de modules autorisés sur le nœud est de 40.

Le paramètre maxPods limite le nombre de pods que le nœud peut exécuter à une valeur fixe, quelles que soient les propriétés du nœud.

5.4.1. Configurer le nombre maximum de pods par nœud
Copier lien

Deux paramètres contrôlent le nombre maximal de modules qui peuvent être planifiés sur un nœud : podsPerCore et maxPods. Si vous utilisez les deux options, la moins élevée des deux limite le nombre de modules sur un nœud.

Par exemple, si podsPerCore est défini sur 10 sur un nœud avec 4 cœurs de processeur, le nombre maximum de pods autorisé sur le nœud sera de 40.

Conditions préalables

Obtenez l'étiquette associée au CRD statique MachineConfigPool pour le type de nœud que vous souhaitez configurer en entrant la commande suivante :

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc edit machineconfigpool worker

$ oc edit machineconfigpool worker

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: "" 
  name: worker

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: ""


  name: worker

Copy to Clipboard

Toggle word wrap

1: L'étiquette apparaît sous Étiquettes.

Astuce

Si l'étiquette n'est pas présente, ajoutez une paire clé/valeur comme par exemple :

oc label machineconfigpool worker custom-kubelet=small-pods

$ oc label machineconfigpool worker custom-kubelet=small-pods

Copy to Clipboard

Toggle word wrap

Procédure

Créez une ressource personnalisée (CR) pour votre changement de configuration.
Exemple de configuration pour un CR max-pods
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods 
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
  kubeletConfig:
    podsPerCore: 10 
    maxPods: 250 
```
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods 
```
1
```
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
```
2
```
  kubeletConfig:
    podsPerCore: 10 
```
3
```
    maxPods: 250 
```
4
Copy to Clipboard Toggle word wrap
1
Attribuer un nom au CR.
2
Spécifiez l'étiquette du pool de configuration de la machine.
3
Indiquez le nombre de modules que le nœud peut exécuter en fonction du nombre de cœurs de processeur du nœud.
4
Spécifie le nombre de pods que le nœud peut exécuter à une valeur fixe, indépendamment des propriétés du nœud.
Note
Le fait de régler podsPerCore sur 0 désactive cette limite.
Dans l'exemple ci-dessus, la valeur par défaut pour podsPerCore est 10 et la valeur par défaut pour maxPods est 250. Cela signifie qu'à moins que le nœud ne dispose de 25 cœurs ou plus, par défaut, podsPerCore sera le facteur limitant.
Exécutez la commande suivante pour créer le CR :
```
oc create -f <nom_du_fichier>.yaml
```
```
oc create -f <nom_du_fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Lister les CRDs MachineConfigPool pour voir si le changement est appliqué. La colonne UPDATING indique True si la modification est prise en compte par le contrôleur de configuration de la machine :

oc get machineconfigpools

$ oc get machineconfigpools

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
master   master-9cc2c72f205e103bb534   False     False      False
worker   worker-8cecd1236b33ee3f8a5e   False     True       False

NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
master   master-9cc2c72f205e103bb534   False     False      False
worker   worker-8cecd1236b33ee3f8a5e   False     True       False

Copy to Clipboard

Toggle word wrap

Une fois la modification effectuée, la colonne UPDATED indique True.

oc get machineconfigpools

$ oc get machineconfigpools

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
master   master-9cc2c72f205e103bb534   False     True       False
worker   worker-8cecd1236b33ee3f8a5e   True      False      False

NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
master   master-9cc2c72f205e103bb534   False     True       False
worker   worker-8cecd1236b33ee3f8a5e   True      False      False

Copy to Clipboard

Toggle word wrap

5.5. Utilisation de l'opérateur Node Tuning
Copier lien

Découvrez l'opérateur d'optimisation des nœuds et la manière dont vous pouvez l'utiliser pour gérer l'optimisation au niveau des nœuds en orchestrant le démon d'optimisation.

L'opérateur d'optimisation des nœuds vous aide à gérer l'optimisation au niveau des nœuds en orchestrant le démon TuneD et à obtenir des performances à faible latence en utilisant le contrôleur de profil de performance. La majorité des applications à hautes performances nécessitent un certain niveau de réglage du noyau. Le Node Tuning Operator offre une interface de gestion unifiée aux utilisateurs de sysctls au niveau des nœuds et plus de flexibilité pour ajouter des réglages personnalisés en fonction des besoins de l'utilisateur.

L'opérateur gère le démon TuneD conteneurisé pour OpenShift Container Platform en tant qu'ensemble de démons Kubernetes. Il s'assure que la spécification de réglage personnalisé est transmise à tous les démons TuneD conteneurisés s'exécutant dans le cluster dans le format que les démons comprennent. Les démons s'exécutent sur tous les nœuds du cluster, un par nœud.

Les paramètres de niveau nœud appliqués par le démon TuneD conteneurisé sont annulés lors d'un événement qui déclenche un changement de profil ou lorsque le démon TuneD conteneurisé se termine de manière élégante en recevant et en gérant un signal de fin.

L'opérateur de réglage des nœuds utilise le contrôleur de profil de performance pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. L'administrateur du cluster configure un profil de performance pour définir des paramètres au niveau du nœud, tels que les suivants :

Mise à jour du noyau vers kernel-rt.
Choix des unités centrales de traitement pour l'entretien ménager.
Choix des unités centrales pour l'exécution des charges de travail.

Note

Actuellement, la désactivation de l'équilibrage de la charge du CPU n'est pas prise en charge par cgroup v2. Par conséquent, il se peut que vous n'obteniez pas le comportement souhaité des profils de performance si vous avez activé cgroup v2. L'activation de cgroup v2 n'est pas recommandée si vous utilisez des profils de performance.

L'opérateur Node Tuning fait partie de l'installation standard d'OpenShift Container Platform à partir de la version 4.1.

Note

Dans les versions antérieures d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift. Dans OpenShift Container Platform 4.11 et les versions ultérieures, cette fonctionnalité fait partie de l'opérateur Node Tuning.

5.5.1. Accéder à un exemple de spécification de l'opérateur Node Tuning
Copier lien

Cette procédure permet d'accéder à un exemple de spécification de l'opérateur de réglage des nœuds.

Procédure

Exécutez la commande suivante pour accéder à un exemple de spécification de l'opérateur Node Tuning :
```
oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator
```
```
$ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator
```
Copy to Clipboard Toggle word wrap

Le CR par défaut est destiné à fournir un réglage standard au niveau du nœud pour la plateforme OpenShift Container Platform et il ne peut être modifié que pour définir l'état de gestion de l'opérateur. Toute autre modification personnalisée de la CR par défaut sera écrasée par l'opérateur. Pour un réglage personnalisé, créez vos propres CR réglés. Les CR nouvellement créés seront combinés avec le CR par défaut et les réglages personnalisés appliqués aux nœuds d'OpenShift Container Platform en fonction des étiquettes de nœuds ou de pods et des priorités de profil.

Avertissement

Bien que dans certaines situations, la prise en charge des étiquettes de pods puisse être un moyen pratique de fournir automatiquement les réglages nécessaires, cette pratique est déconseillée et fortement déconseillée, en particulier dans les clusters à grande échelle. Le CR Tuned par défaut est livré sans correspondance d'étiquettes de pods. Si un profil personnalisé est créé avec la correspondance des étiquettes de pods, alors la fonctionnalité sera activée à ce moment-là. La fonctionnalité d'étiquetage de pods sera obsolète dans les versions futures de l'opérateur de tuning de nœuds.

5.5.2. Spécification de réglage personnalisé
Copier lien

La ressource personnalisée (CR) de l'opérateur comporte deux sections principales. La première section, profile:, est une liste de profils TuneD et de leurs noms. La seconde, recommend:, définit la logique de sélection des profils.

Plusieurs spécifications de réglage personnalisées peuvent coexister en tant que CR multiples dans l'espace de noms de l'opérateur. L'existence de nouveaux CR ou la suppression d'anciens CR est détectée par l'Opérateur. Toutes les spécifications de réglage personnalisées existantes sont fusionnées et les objets appropriés pour les démons TuneD conteneurisés sont mis à jour.

Management state

L'état de gestion de l'opérateur est défini en ajustant le CR accordé par défaut. Par défaut, l'opérateur est en état de gestion et le champ spec.managementState n'est pas présent dans le CR accordé par défaut. Les valeurs valides pour l'état de gestion de l'opérateur sont les suivantes :

Géré : l'opérateur met à jour ses opérandes au fur et à mesure que les ressources de configuration sont mises à jour
Non géré : l'opérateur ignore les changements apportés aux ressources de configuration
Retiré : l'opérateur retire ses opérandes et les ressources qu'il a fournies

Profile data

La section profile: dresse la liste des profils TuneD et de leurs noms.

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

Copy to Clipboard

Toggle word wrap

Recommended profiles

La logique de sélection de profile: est définie par la section recommend: du CR. La section recommend: est une liste d'éléments permettant de recommander les profils sur la base d'un critère de sélection.

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

Copy to Clipboard

Toggle word wrap

Les différents éléments de la liste :

- machineConfigLabels: 
    <mcLabels> 
  match: 
    <match> 
  priority: <priority> 
  profile: <tuned_profile_name> 
  operand: 
    debug: <bool> 
    tunedConfig:
      reapply_sysctl: <bool>

- machineConfigLabels:


    <mcLabels>


  match:


    <match>


  priority: <priority>


  profile: <tuned_profile_name>


  operand:


    debug: <bool>


    tunedConfig:
      reapply_sysctl: <bool>

Copy to Clipboard

Toggle word wrap

1: En option.
2: Un dictionnaire d'étiquettes clé/valeur MachineConfig. Les clés doivent être uniques.
3: En cas d'omission, la correspondance des profils est présumée, sauf si un profil ayant une priorité plus élevée correspond en premier ou si machineConfigLabels est défini.
4: Une liste facultative.
5: Ordre de priorité des profils. Les chiffres les plus bas signifient une priorité plus élevée (0 est la priorité la plus élevée).
6: Un profil TuneD à appliquer sur un match. Par exemple tuned_profile_1.
7: Configuration facultative de l'opérande.
8: Active ou désactive le débogage du démon TuneD. Les options sont true pour on ou false pour off. La valeur par défaut est false.
9: Active ou désactive la fonctionnalité reapply_sysctl pour le démon TuneD. Les options sont true pour on et false pour off.

<match> est une liste optionnelle définie récursivement comme suit :

- label: <label_name> 
  value: <label_value> 
  type: <label_type> 
    <match>

- label: <label_name>


  value: <label_value>


  type: <label_type>


    <match>

Copy to Clipboard

Toggle word wrap

1: Nom de l'étiquette du nœud ou du pod.
2: Valeur facultative de l'étiquette du nœud ou du pod. Si elle est omise, la présence de <label_name> suffit à établir une correspondance.
3: Type d'objet facultatif (node ou pod). En cas d'omission, node est considéré comme tel.
4: Une liste facultative <match>.

Si <match> n'est pas omis, toutes les sections imbriquées <match> doivent également être évaluées à true. Sinon, false est supposé et le profil avec la section <match> correspondante ne sera pas appliqué ou recommandé. Par conséquent, l'imbrication (sections <match> enfant) fonctionne comme un opérateur logique ET. Inversement, si un élément de la liste <match> correspond, toute la liste <match> est évaluée à true. La liste agit donc comme un opérateur logique OU.

Si machineConfigLabels est défini, la correspondance basée sur le pool de configuration de la machine est activée pour l'élément de liste recommend: donné. <mcLabels> spécifie les étiquettes d'une configuration de la machine. La configuration de la machine est créée automatiquement pour appliquer les paramètres de l'hôte, tels que les paramètres de démarrage du noyau, pour le profil <tuned_profile_name>. Il s'agit de trouver tous les pools de configuration de machine dont le sélecteur de configuration de machine correspond à <mcLabels> et de définir le profil <tuned_profile_name> sur tous les nœuds auxquels sont attribués les pools de configuration de machine trouvés. Pour cibler les nœuds qui ont à la fois un rôle de maître et de travailleur, vous devez utiliser le rôle de maître.

Les éléments de la liste match et machineConfigLabels sont reliés par l'opérateur logique OR. L'élément match est évalué en premier, en court-circuit. Par conséquent, s'il est évalué à true, l'élément machineConfigLabels n'est pas pris en compte.

Important

Lors de l'utilisation de la correspondance basée sur le pool de configuration machine, il est conseillé de regrouper les nœuds ayant la même configuration matérielle dans le même pool de configuration machine. Si cette pratique n'est pas respectée, les opérandes TuneD peuvent calculer des paramètres de noyau contradictoires pour deux nœuds ou plus partageant le même pool de configuration de machine.

Exemple : correspondance basée sur l'étiquette d'un nœud ou d'un pod

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

Copy to Clipboard

Toggle word wrap

Le CR ci-dessus est traduit pour le démon TuneD conteneurisé dans son fichier recommend.conf en fonction des priorités du profil. Le profil ayant la priorité la plus élevée (10) est openshift-control-plane-es et, par conséquent, il est considéré en premier. Le démon TuneD conteneurisé fonctionnant sur un nœud donné vérifie s'il existe un pod fonctionnant sur le même nœud avec l'étiquette tuned.openshift.io/elasticsearch définie. Si ce n'est pas le cas, toute la section <match> est évaluée comme false. S'il existe un pod avec le label, pour que la section <match> soit évaluée comme true, le label du nœud doit également être node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Si les étiquettes du profil ayant la priorité 10 correspondent, le profil openshift-control-plane-es est appliqué et aucun autre profil n'est pris en considération. Si la combinaison d'étiquettes nœud/pod ne correspond pas, le deuxième profil le plus prioritaire (openshift-control-plane) est pris en compte. Ce profil est appliqué si le pod TuneD conteneurisé fonctionne sur un nœud avec les étiquettes node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Enfin, le profil openshift-node a la priorité la plus basse de 30. Il ne contient pas la section <match> et, par conséquent, correspondra toujours. Il sert de profil fourre-tout pour définir le profil openshift-node si aucun autre profil ayant une priorité plus élevée ne correspond à un nœud donné.

Exemple : correspondance basée sur le pool de configuration de la machine

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

Copy to Clipboard

Toggle word wrap

Pour minimiser les redémarrages de nœuds, il faut étiqueter les nœuds cibles avec une étiquette que le sélecteur de nœuds du pool de configuration de la machine fera correspondre, puis créer le Tuned CR ci-dessus et enfin créer le pool de configuration de la machine personnalisé lui-même.

Cloud provider-specific TuneD profiles

Avec cette fonctionnalité, tous les nœuds spécifiques à un fournisseur de Cloud peuvent commodément se voir attribuer un profil TuneD spécifiquement adapté à un fournisseur de Cloud donné sur un cluster OpenShift Container Platform. Cela peut être accompli sans ajouter d'étiquettes de nœuds supplémentaires ou regrouper les nœuds dans des pools de configuration de machines.

Cette fonctionnalité tire parti des valeurs de l'objet de nœud spec.providerID sous la forme de <cloud-provider>://<cloud-provider-specific-id> et écrit le fichier /var/lib/tuned/provider avec la valeur <cloud-provider> dans les conteneurs d'opérandes NTO. Le contenu de ce fichier est ensuite utilisé par TuneD pour charger le profil provider-<cloud-provider> s'il existe.

Le profil openshift dont les profils openshift-control-plane et openshift-node héritent des paramètres est maintenant mis à jour pour utiliser cette fonctionnalité grâce à l'utilisation du chargement conditionnel de profil. Ni NTO ni TuneD ne fournissent actuellement de profils spécifiques aux fournisseurs de Cloud. Cependant, il est possible de créer un profil personnalisé provider-<cloud-provider> qui sera appliqué à tous les nœuds de cluster spécifiques au fournisseur de cloud.

Exemple de profil de fournisseur GCE Cloud

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

Copy to Clipboard

Toggle word wrap

Note

En raison de l'héritage des profils, tout paramètre spécifié dans le profil provider-<cloud-provider> sera remplacé par le profil openshift et ses profils enfants.

5.5.3. Profils par défaut définis sur un cluster
Copier lien

Les profils par défaut définis sur un cluster sont les suivants.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

Copy to Clipboard

Toggle word wrap

Depuis OpenShift Container Platform 4.9, tous les profils OpenShift TuneD sont livrés avec le package TuneD. Vous pouvez utiliser la commande oc exec pour voir le contenu de ces profils :

oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

Copy to Clipboard

Toggle word wrap

5.5.4. Plugins de démon TuneD pris en charge
Copier lien

À l'exception de la section [main], les plugins TuneD suivants sont pris en charge lors de l'utilisation des profils personnalisés définis dans la section profile: du CR Tuned :

audio
cpu
disque
eeepc_she
modules
montures
net
planificateur
scsi_host
selinux
sysctl
sysfs
uSB
vidéo
vm
chargeur de démarrage

Certains de ces plugins offrent une fonctionnalité d'accord dynamique qui n'est pas prise en charge. Les plugins TuneD suivants ne sont actuellement pas pris en charge :

scénario
systemd

Avertissement

Le plugin TuneD bootloader est actuellement pris en charge sur les nœuds de travail Red Hat Enterprise Linux CoreOS (RHCOS) 8.x. Pour les nœuds de travail Red Hat Enterprise Linux (RHEL) 7.x, le plugin de chargeur de démarrage TuneD n'est actuellement pas pris en charge.

Voir Plugins TuneD disponibles et Démarrer avec TuneD pour plus d'informations.

5.6. Assainissement, clôtures et entretien
Copier lien

5.6.1. À propos de l'assainissement des nœuds, des clôtures et de l'entretien
Copier lien

Le matériel est imparfait et les logiciels contiennent des bogues. Lorsque des défaillances au niveau des nœuds, telles que le blocage du noyau ou des contrôleurs d'interface réseau (NIC), surviennent, le travail demandé à la grappe ne diminue pas et les charges de travail des nœuds concernés doivent être redémarrées quelque part. Cependant, certaines charges de travail, telles que les volumes ReadWriteOnce (RWO) et les StatefulSets, peuvent nécessiter une sémantique "at-most-one".

Les défaillances affectant ces charges de travail risquent d'entraîner la perte ou la corruption de données, voire les deux. Il est important de veiller à ce que le nœud atteigne un état sûr ( fencing ) avant d'entamer la reprise de la charge de travail ( remediation ) et, idéalement, la reprise du nœud.

Il n'est pas toujours pratique de dépendre de l'intervention de l'administrateur pour confirmer l'état réel des nœuds et des charges de travail. Pour faciliter cette intervention, OpenShift Container Platform fournit plusieurs composants pour l'automatisation de la détection des défaillances, de la clôture et de la remédiation.

5.6.1.1. Remédiation autonome des nœuds
Copier lien

Le Self Node Remediation Operator est un opérateur complémentaire d'OpenShift Container Platform qui met en œuvre un système externe de clôture et de remédiation qui redémarre les nœuds malsains et supprime les ressources, telles que les Pods et les VolumeAttachments. Le redémarrage garantit que les charges de travail sont clôturées et la suppression des ressources accélère la reprogrammation des charges de travail affectées. Contrairement à d'autres systèmes externes, Self Node Remediation ne nécessite aucune interface de gestion, comme, par exemple, Intelligent Platform Management Interface (IPMI) ou une API pour le provisionnement des nœuds.

L'auto-remédiation des nœuds peut être utilisée par les systèmes de détection des défaillances, comme le bilan de santé de la machine ou le bilan de santé du nœud.

5.6.1.2. Bilan de santé de la machine
Copier lien

Machine Health Check utilise un système intégré de détection des défaillances, de clôture et de remédiation d'OpenShift Container Platform, qui surveille l'état des machines et les conditions des nœuds. Les bilans de santé des machines peuvent être configurés pour déclencher des systèmes de clôture et de remédiation externes, tels que Self Node Remediation.

5.6.1.3. Bilan de santé du nœud
Copier lien

L'opérateur Node Health Check est un opérateur complémentaire d'OpenShift Container Platform qui met en œuvre un système de détection des défaillances qui surveille l'état des nœuds. Il ne dispose pas d'un système de clôture ou de remédiation intégré et doit donc être configuré avec un système externe qui fournit de telles fonctionnalités. Par défaut, il est configuré pour utiliser le système Self Node Remediation.

5.6.1.4. Maintenance des nœuds
Copier lien

Les administrateurs sont confrontés à des situations où ils doivent interrompre la grappe, par exemple pour remplacer un disque, de la mémoire vive ou une carte d'interface réseau.

Avant cette maintenance, les nœuds concernés doivent être isolés et vidés. Lorsqu'un nœud est isolé, il n'est pas possible de programmer de nouvelles charges de travail sur ce nœud. Lorsqu'un nœud est vidé, pour éviter ou minimiser les temps d'arrêt, les charges de travail sur le nœud affecté sont transférées vers d'autres nœuds.

Bien que cette maintenance puisse être réalisée à l'aide d'outils de ligne de commande, l'opérateur de maintenance de nœuds offre une approche déclarative pour y parvenir en utilisant une ressource personnalisée. Lorsqu'une telle ressource existe pour un nœud, l'opérateur cordonne et draine le nœud jusqu'à ce que la ressource soit supprimée.

5.6.2. Utilisation de l'auto-remédiation des nœuds
Copier lien

Vous pouvez utiliser l'opérateur Self Node Remediation pour redémarrer automatiquement les nœuds en mauvais état. Cette stratégie de remédiation minimise les temps d'arrêt pour les applications avec état et les volumes ReadWriteOnce (RWO), et rétablit la capacité de calcul en cas de défaillances transitoires.

5.6.2.1. À propos de l'opérateur d'assainissement autonome des nœuds
Copier lien

L'opérateur Self Node Remediation s'exécute sur les nœuds de la grappe et redémarre les nœuds identifiés comme étant en mauvaise santé. L'opérateur utilise le contrôleur MachineHealthCheck ou NodeHealthCheck pour détecter l'état d'un nœud dans la grappe. Lorsqu'un nœud est identifié comme étant en mauvaise santé, la ressource MachineHealthCheck ou NodeHealthCheck crée la ressource personnalisée (CR) SelfNodeRemediation, qui déclenche l'opérateur Self Node Remediation.

Le CR SelfNodeRemediation ressemble au fichier YAML suivant :

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-operators
spec:
status:
  lastError: <last_error_message>

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-operators
spec:
status:
  lastError: <last_error_message>

Copy to Clipboard

Toggle word wrap

1: Affiche la dernière erreur survenue pendant la remédiation. Lorsque la remédiation réussit ou qu'aucune erreur ne se produit, le champ reste vide.

L'opérateur Self Node Remediation minimise les temps d'arrêt des applications avec état et rétablit la capacité de calcul en cas de défaillance transitoire. Vous pouvez utiliser cet opérateur quelle que soit l'interface de gestion (IPMI ou API pour le provisionnement d'un nœud) et quel que soit le type d'installation du cluster (infrastructure provisionnée par l'installateur ou par l'utilisateur).

5.6.2.1.1. À propos des dispositifs de surveillance
Copier lien

Les dispositifs de surveillance peuvent être l'un des suivants :

Dispositifs matériels alimentés de manière indépendante
Dispositifs matériels qui partagent l'énergie avec les hôtes qu'ils contrôlent
Dispositifs virtuels mis en œuvre dans un logiciel, ou softdog

Les dispositifs matériels de surveillance (watchdog) et softdog disposent respectivement d'une minuterie électronique ou logicielle. Ces dispositifs de surveillance sont utilisés pour garantir que la machine entre dans un état sûr lorsqu'une condition d'erreur est détectée. Le cluster doit réinitialiser à plusieurs reprises la minuterie du chien de garde pour prouver qu'il est dans un état sain. Cette minuterie peut s'écouler en raison de conditions d'erreur, telles que des blocages, des pannes de CPU et des pertes d'accès au réseau ou au disque. Si le délai expire, le dispositif de chien de garde suppose qu'une erreur s'est produite et déclenche une réinitialisation forcée du nœud.

Les dispositifs de surveillance matériels sont plus fiables que les dispositifs softdog.

5.6.2.1.1.1. Comprendre le comportement de l'opérateur de remédiation des nœuds autonomes avec les dispositifs de surveillance
Copier lien

L'opérateur de remédiation du nœud autonome détermine la stratégie de remédiation en fonction des dispositifs de surveillance présents.

Si un dispositif de surveillance matériel est configuré et disponible, l'opérateur l'utilise pour la remédiation. Si un dispositif de surveillance matériel n'est pas configuré, l'opérateur active et utilise un dispositif softdog pour la remédiation.

Si aucun dispositif de surveillance n'est pris en charge, que ce soit par le système ou par la configuration, l'opérateur remédie aux nœuds en utilisant le redémarrage du logiciel.

5.6.2.2. Clôture du plan de contrôle
Copier lien

Dans les versions précédentes, vous pouviez activer les fonctions Self Node Remediation et Node Health Check sur les nœuds de travail. En cas de défaillance d'un nœud, vous pouvez désormais suivre des stratégies de remédiation sur les nœuds du plan de contrôle.

L'auto-assainissement d'un nœud se produit dans deux scénarios principaux.

Connectivité au serveur API
- Dans ce scénario, le nœud du plan de contrôle à assainir n'est pas isolé. Il peut être directement connecté au serveur API ou indirectement connecté au serveur API par l'intermédiaire de nœuds de travail ou de nœuds du plan de contrôle, qui sont directement connectés au serveur API.
- En cas de connectivité avec le serveur API, le nœud du plan de contrôle ne fait l'objet d'une remédiation que si l'opérateur du bilan de santé du nœud a créé une ressource personnalisée (CR) SelfNodeRemediation pour le nœud.
Pas de connectivité avec le serveur API
- Dans ce scénario, le nœud du plan de contrôle à assainir est isolé du serveur API. Le nœud ne peut pas se connecter directement ou indirectement au serveur API.
- Lorsqu'il n'y a pas de connectivité avec le serveur API, le nœud du plan de contrôle sera remédié comme indiqué dans les étapes suivantes :
  - Vérifier l'état du nœud du plan de contrôle auprès de la majorité des nœuds homologues. Si la majorité des nœuds homologues ne peut être jointe, le nœud sera analysé plus en détail.
    Autodiagnostic de l'état du nœud du plan de contrôle
    Si l'autodiagnostic est réussi, aucune action n'est entreprise.
    Si l'autodiagnostic a échoué, le nœud sera clôturé et remédié.
    Les autodiagnostics actuellement pris en charge sont la vérification de l'état du service kubelet et la vérification de la disponibilité des points d'extrémité à l'aide de la configuration opt in.
  - Si le nœud n'a pas réussi à communiquer avec la plupart de ses homologues, vérifiez la connectivité du nœud de plan de contrôle avec d'autres nœuds de plan de contrôle. Si le nœud peut communiquer avec n'importe quel autre homologue du plan de contrôle, aucune mesure ne sera prise. Dans le cas contraire, le nœud sera clôturé et remédié.

5.6.2.3. Installation du Self Node Remediation Operator à l'aide de la console web
Copier lien

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer le Self Node Remediation Operator.

Note

L'opérateur du bilan de santé du nœud installe également l'opérateur de remédiation du nœud lui-même en tant que fournisseur de remédiation par défaut.

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.
Recherchez l'opérateur d'assainissement autonome dans la liste des opérateurs disponibles, puis cliquez sur Install.
Conservez la sélection par défaut de Installation mode et namespace pour vous assurer que l'opérateur est installé dans l'espace de noms openshift-operators.
Cliquez sur Install.

Vérification

Pour confirmer que l'installation a réussi :

Naviguez jusqu'à la page Operators → Installed Operators.
Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.

Si l'opérateur n'est pas installé correctement :

Naviguez jusqu'à la page Operators → Installed Operators et vérifiez que la colonne Status ne contient pas d'erreurs ou de défaillances.
Naviguez jusqu'à la page Workloads → Pods et vérifiez les journaux de tous les pods du projet self-node-remediation-controller-manager qui signalent des problèmes.

5.6.2.4. Installation du Self Node Remediation Operator à l'aide de la CLI
Copier lien

Vous pouvez utiliser l'OpenShift CLI (oc) pour installer le Self Node Remediation Operator.

Vous pouvez installer le Self Node Remediation Operator dans votre propre espace de noms ou dans l'espace de noms openshift-operators.

Pour installer l'opérateur dans votre propre espace de noms, suivez les étapes de la procédure.

Pour installer l'opérateur dans l'espace de noms openshift-operators, passez à l'étape 3 de la procédure car les étapes de création d'une nouvelle ressource personnalisée (CR) Namespace et d'une CR OperatorGroup ne sont pas nécessaires.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer une ressource personnalisée (CR) Namespace pour l'opérateur de remédiation de nœud autonome :
1. Définissez le CR Namespace et enregistrez le fichier YAML, par exemple self-node-remediation-namespace.yaml:
  apiVersion: v1 kind: Namespace metadata: name: self-node-remediation
  Copy to Clipboard Toggle word wrap
2. Pour créer le CR Namespace, exécutez la commande suivante :
  $ oc create -f self-node-remediation-namespace.yaml
  Copy to Clipboard Toggle word wrap

Créer un CR OperatorGroup:

Définissez le CR OperatorGroup et enregistrez le fichier YAML, par exemple self-node-remediation-operator-group.yaml:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: self-node-remediation-operator
  namespace: self-node-remediation

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: self-node-remediation-operator
  namespace: self-node-remediation

Copy to Clipboard

Toggle word wrap

Pour créer le CR OperatorGroup, exécutez la commande suivante :
```
oc create -f self-node-remediation-operator-group.yaml
```
```
$ oc create -f self-node-remediation-operator-group.yaml
```
Copy to Clipboard Toggle word wrap

Créer un CR Subscription:
1. Définissez le CR Subscription et enregistrez le fichier YAML, par exemple self-node-remediation-subscription.yaml:
  apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: self-node-remediation-operator namespace: self-node-remediation
  1
  spec: channel: stable installPlanApproval: Manual
  2
  name: self-node-remediation-operator source: redhat-operators sourceNamespace: openshift-marketplace package: self-node-remediation
  Copy to Clipboard Toggle word wrap
  1
  Indiquez le site Namespace où vous souhaitez installer l'opérateur d'assainissement de l'auto-nœud. Pour installer l'opérateur d'auto-assainissement de nœud dans l'espace de noms openshift-operators, spécifiez openshift-operators dans le CR Subscription.
  2
  Définissez la stratégie d'approbation sur Manuel au cas où la version spécifiée serait remplacée par une version ultérieure dans le catalogue. Ce plan empêche une mise à niveau automatique vers une version ultérieure et nécessite une approbation manuelle avant que le CSV de départ ne puisse terminer l'installation.
2. Pour créer le CR Subscription, exécutez la commande suivante :
  $ oc create -f self-node-remediation-subscription.yaml
  Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que l'installation a réussi en inspectant la ressource CSV :

oc get csv -n self-node-remediation

$ oc get csv -n self-node-remediation

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                               DISPLAY                          VERSION   REPLACES   PHASE
self-node-remediation.v.0.4.0      Self Node Remediation Operator   v.0.4.0              Succeeded

NAME                               DISPLAY                          VERSION   REPLACES   PHASE
self-node-remediation.v.0.4.0      Self Node Remediation Operator   v.0.4.0              Succeeded

Copy to Clipboard

Toggle word wrap

Vérifiez que l'opérateur de remédiation de nœuds autonomes est opérationnel :

oc get deploy -n self-node-remediation

$ oc get deploy -n self-node-remediation

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
self-node-remediation-controller-manager    1/1     1            1           28h

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
self-node-remediation-controller-manager    1/1     1            1           28h

Copy to Clipboard

Toggle word wrap

Vérifier que l'opérateur d'assainissement autonome a créé la CR SelfNodeRemediationConfig:

oc get selfnoderemediationconfig -n self-node-remediation

$ oc get selfnoderemediationconfig -n self-node-remediation

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                           AGE
self-node-remediation-config   28h

NAME                           AGE
self-node-remediation-config   28h

Copy to Clipboard

Toggle word wrap

Vérifiez que chaque pod de remédiation de nœud autonome est planifié et en cours d'exécution sur chaque nœud de travail :

oc get daemonset -n self-node-remediation

$ oc get daemonset -n self-node-remediation

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                      DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
self-node-remediation-ds  3        3        3      3           3          <none>         28h

NAME                      DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
self-node-remediation-ds  3        3        3      3           3          <none>         28h

Copy to Clipboard

Toggle word wrap

Note

Cette commande n'est pas prise en charge pour les nœuds du plan de contrôle.

5.6.2.5. Configuration de l'opérateur de remédiation du nœud autonome
Copier lien

L'opérateur de remédiation du nœud autonome crée la CR SelfNodeRemediationConfig et la définition de ressource personnalisée (CRD) SelfNodeRemediationTemplate.

5.6.2.5.1. Comprendre la configuration de l'opérateur de remédiation du nœud autonome
Copier lien

L'opérateur d'assainissement de l'auto-nœud crée le CR SelfNodeRemediationConfig avec le nom self-node-remediation-config. Le CR est créé dans l'espace de noms de l'opérateur d'assainissement de l'auto-nœud.

Un changement dans le CR SelfNodeRemediationConfig recrée le jeu de démons Self Node Remediation.

Le CR SelfNodeRemediationConfig ressemble au fichier YAML suivant :

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-operators
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180 
  watchdogFilePath: /dev/watchdog 
  isSoftwareRebootEnabled: true 
  apiServerTimeout: 15s 
  apiCheckInterval: 5s 
  maxApiErrorThreshold: 3 
  peerApiServerTimeout: 5s 
  peerDialTimeout: 5s 
  peerRequestTimeout: 5s 
  peerUpdateInterval: 15m

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-operators
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180


  watchdogFilePath: /dev/watchdog


  isSoftwareRebootEnabled: true


  apiServerTimeout: 15s


  apiCheckInterval: 5s


  maxApiErrorThreshold: 3


  peerApiServerTimeout: 5s


  peerDialTimeout: 5s


  peerRequestTimeout: 5s


  peerUpdateInterval: 15m

Copy to Clipboard

Toggle word wrap

1: Indiquez le délai d'attente pour l'homologue survivant, après lequel l'opérateur peut supposer qu'un nœud malsain a été redémarré. L'opérateur calcule automatiquement la limite inférieure de cette valeur. Toutefois, si différents nœuds ont des délais d'attente différents, vous devez remplacer cette valeur par une valeur plus élevée.
2: Indiquez le chemin d'accès au fichier du dispositif de surveillance dans les nœuds. Si vous saisissez un chemin d'accès incorrect au dispositif de surveillance, l'opérateur de remédiation des nœuds détecte automatiquement le chemin d'accès au dispositif de surveillance.
Si un dispositif de surveillance n'est pas disponible, le CR SelfNodeRemediationConfig utilise un redémarrage logiciel.
3: Indiquez si vous souhaitez activer le redémarrage du logiciel des nœuds malades. Par défaut, la valeur de isSoftwareRebootEnabled est fixée à true. Pour désactiver le redémarrage du logiciel, fixez la valeur du paramètre à false.
4: Spécifiez le délai d'attente pour vérifier la connectivité avec chaque serveur API. Lorsque ce délai est écoulé, l'opérateur lance la remédiation. Le délai d'attente doit être supérieur ou égal à 10 millisecondes.
5: Spécifiez la fréquence de vérification de la connectivité avec chaque serveur API. Le délai d'attente doit être supérieur ou égal à 1 seconde.
6: Spécifier une valeur seuil. Une fois ce seuil atteint, le nœud commence à contacter ses homologues. La valeur du seuil doit être supérieure ou égale à 1 seconde.
7: Spécifiez la durée du délai d'attente pour que l'homologue se connecte au serveur API. La durée du délai d'attente doit être supérieure ou égale à 10 millisecondes.
8: Spécifiez la durée du délai d'attente pour l'établissement de la connexion avec l'homologue. La durée du délai doit être supérieure ou égale à 10 millisecondes.
9: Spécifiez la durée du délai d'attente pour obtenir une réponse de l'homologue. La durée du délai doit être supérieure ou égale à 10 millisecondes.
10: Spécifiez la fréquence de mise à jour des informations sur l'homologue, telles que l'adresse IP. Le délai d'attente doit être supérieur ou égal à 10 secondes.

Note

Vous pouvez modifier la CR self-node-remediation-config créée par l'opérateur d'assainissement autonome. Cependant, lorsque vous essayez de créer un nouveau CR pour l'opérateur d'assainissement autonome, le message suivant s'affiche dans les journaux :

controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}

controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}

Copy to Clipboard

Toggle word wrap

5.6.2.5.2. Comprendre la configuration du modèle d'auto-assainissement des nœuds
Copier lien

L'opérateur d'assainissement autonome des nœuds crée également la définition de ressource personnalisée (CRD) SelfNodeRemediationTemplate. Ce CRD définit la stratégie de remédiation pour les nœuds. Les stratégies de remédiation suivantes sont disponibles :

ResourceDeletion: Cette stratégie de remédiation supprime les pods et les attachements de volume associés sur le nœud plutôt que sur l'objet nœud. Cette stratégie permet de récupérer les charges de travail plus rapidement. ResourceDeletion est la stratégie de remédiation par défaut.
NodeDeletion: Cette stratégie de remédiation est obsolète et sera supprimée dans une prochaine version. Dans la version actuelle, la stratégie ResourceDeletion est utilisée même si la stratégie NodeDeletion est sélectionnée.

L'opérateur de remédiation du nœud autonome crée le CR SelfNodeRemediationTemplate pour la stratégie self-node-remediation-resource-deletion-template, que la stratégie de remédiation ResourceDeletion utilise.

Le CR SelfNodeRemediationTemplate ressemble au fichier YAML suivant :

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template 
  namespace: openshift-operators
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template


  namespace: openshift-operators
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>

Copy to Clipboard

Toggle word wrap

1: Spécifie le type de modèle de remédiation basé sur la stratégie de remédiation. Remplacez <remediation_object> par resource ou node; par exemple, self-node-remediation-resource-deletion-template.
2: Spécifie la stratégie de remédiation. La stratégie de remédiation est ResourceDeletion.

5.6.2.6. Dépannage de l'opérateur d'auto-assainissement des nœuds
Copier lien

5.6.2.6.1. Dépannage général
Copier lien

Enjeu: Vous souhaitez résoudre les problèmes liés à l'opérateur de remédiation des nœuds autonomes.
Résolution: Vérifier les journaux de l'opérateur.

5.6.2.6.2. Vérification du jeu de démons
Copier lien

Enjeu: Le Self Node Remediation Operator est installé mais le jeu de démons n'est pas disponible.
Résolution: Vérifiez que les journaux de l'opérateur ne contiennent pas d'erreurs ou d'avertissements.

5.6.2.6.3. Remédiation infructueuse
Copier lien

Enjeu

Un nœud malsain n'a pas été remédié.

Résolution

Vérifiez que le CR SelfNodeRemediation a été créé en exécutant la commande suivante :

oc get snr -A

$ oc get snr -A

Copy to Clipboard

Toggle word wrap

Si le contrôleur MachineHealthCheck n'a pas créé la CR SelfNodeRemediation lorsque le nœud est devenu malsain, vérifiez les journaux du contrôleur MachineHealthCheck. En outre, assurez-vous que le CR MachineHealthCheck inclut les spécifications requises pour utiliser le modèle de remédiation.

Si le CR SelfNodeRemediation a été créé, assurez-vous que son nom correspond au nœud malsain ou à l'objet machine.

5.6.2.6.4. L'ensemble de démons et d'autres ressources de l'opérateur de remédiation des nœuds autonomes existent même après la désinstallation de l'opérateur
Copier lien

Enjeu

Les ressources de l'opérateur de remédiation du nœud autonome, telles que le jeu de démons, la CR de configuration et la CR du modèle de remédiation, existent même après la désinstallation de l'opérateur.

Résolution

Pour supprimer les ressources de l'opérateur de remédiation du nœud autonome, supprimez les ressources en exécutant les commandes suivantes pour chaque type de ressource :

oc delete ds <self-node-remediation-ds> -n <namespace>

$ oc delete ds <self-node-remediation-ds> -n <namespace>

Copy to Clipboard

Toggle word wrap

oc delete snrc <self-node-remediation-config> -n <namespace>

oc delete snrc <self-node-remediation-config> -n <namespace>

Copy to Clipboard

Toggle word wrap

oc delete snrt <self-node-remediation-template> -n <namespace>

oc delete snrt <self-node-remediation-template> -n <namespace>

Copy to Clipboard

Toggle word wrap

5.6.2.7. Collecte de données sur l'opérateur de remédiation de l'auto-nœud
Copier lien

Pour collecter des informations de débogage sur l'opérateur d'assainissement autonome des nœuds, utilisez l'outil must-gather. Pour plus d'informations sur l'image must-gather de l'opérateur d'assainissement autonome des nœuds, voir Collecte de données sur des fonctionnalités spécifiques.

5.6.2.8. Ressources supplémentaires
Copier lien

5.6.3. Remédier aux nœuds avec les bilans de santé des machines
Copier lien

Les contrôles de santé des machines réparent automatiquement les machines en mauvais état dans un pool de machines particulier.

5.6.3.1. À propos des contrôles de santé des machines
Copier lien

Note

Vous ne pouvez appliquer un contrôle de l'état des machines qu'aux machines du plan de contrôle des clusters qui utilisent des jeux de machines du plan de contrôle.

Pour surveiller l'état des machines, créez une ressource afin de définir la configuration d'un contrôleur. Définissez une condition à vérifier, telle que le maintien de l'état NotReady pendant cinq minutes ou l'affichage d'une condition permanente dans le détecteur de problèmes de nœuds, ainsi qu'une étiquette pour l'ensemble des machines à surveiller.

Le contrôleur qui observe une ressource MachineHealthCheck vérifie la condition définie. Si une machine échoue au contrôle de santé, elle est automatiquement supprimée et une autre est créée pour la remplacer. Lorsqu'une machine est supprimée, un événement machine deleted s'affiche.

Pour limiter l'impact perturbateur de la suppression des machines, le contrôleur ne draine et ne supprime qu'un seul nœud à la fois. S'il y a plus de machines malsaines que le seuil maxUnhealthy ne le permet dans le groupe de machines ciblées, la remédiation s'arrête et permet donc une intervention manuelle.

Note

Les délais d'attente doivent être étudiés avec soin, en tenant compte de la charge de travail et des besoins.

Les délais d'attente prolongés peuvent entraîner de longues périodes d'indisponibilité de la charge de travail sur la machine en état d'insalubrité.
Des délais trop courts peuvent entraîner une boucle de remédiation. Par exemple, le délai de vérification de l'état de NotReady doit être suffisamment long pour permettre à la machine de terminer le processus de démarrage.

Pour arrêter le contrôle, retirez la ressource.

5.6.3.1.1. Limitations lors du déploiement des contrôles de santé des machines
Copier lien

Il y a des limites à prendre en compte avant de déployer un bilan de santé machine :

Seules les machines appartenant à un jeu de machines sont remédiées par un bilan de santé de la machine.
Si le nœud d'une machine est supprimé du cluster, un contrôle de santé de la machine considère que la machine n'est pas en bonne santé et y remédie immédiatement.
Si le nœud correspondant à une machine ne rejoint pas le cluster après le nodeStartupTimeout, la machine est remédiée.
Une machine est remédiée immédiatement si la phase de ressource Machine est Failed.

5.6.3.2. Configurer les contrôles de santé des machines pour utiliser l'opérateur de remédiation de nœuds autonomes (Self Node Remediation Operator)
Copier lien

Utilisez la procédure suivante pour configurer les contrôles de santé des machines du plan de travail ou du plan de contrôle afin d'utiliser l'opérateur de remédiation du nœud autonome en tant que fournisseur de remédiation.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un CR SelfNodeRemediationTemplate:

Définir le CR SelfNodeRemediationTemplate:

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  namespace: openshift-machine-api
  name: selfnoderemediationtemplate-sample
spec:
  template:
    spec:
      remediationStrategy: ResourceDeletion

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  namespace: openshift-machine-api
  name: selfnoderemediationtemplate-sample
spec:
  template:
    spec:
      remediationStrategy: ResourceDeletion

Copy to Clipboard

Toggle word wrap

1: Spécifie la stratégie de remédiation. La stratégie par défaut est ResourceDeletion.

Pour créer le CR SelfNodeRemediationTemplate, exécutez la commande suivante :
```
oc create -f <snrt-name>.yaml
```
```
oc create -f <snrt-name>.yaml
```
Copy to Clipboard Toggle word wrap

Créez ou mettez à jour le CR MachineHealthCheck pour qu'il pointe vers le CR SelfNodeRemediationTemplate:

Définir ou mettre à jour le CR MachineHealthCheck:

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: machine-health-check
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels: 
      machine.openshift.io/cluster-api-machine-role: "worker"
      machine.openshift.io/cluster-api-machine-type: "worker"
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
    status: "False"
  - type:    "Ready"
    timeout: "300s"
    status: "Unknown"
  maxUnhealthy: "40%"
  nodeStartupTimeout: "10m"
  remediationTemplate: 
    kind: SelfNodeRemediationTemplate
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: selfnoderemediationtemplate-sample

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: machine-health-check
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:


      machine.openshift.io/cluster-api-machine-role: "worker"
      machine.openshift.io/cluster-api-machine-type: "worker"
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
    status: "False"
  - type:    "Ready"
    timeout: "300s"
    status: "Unknown"
  maxUnhealthy: "40%"
  nodeStartupTimeout: "10m"
  remediationTemplate:


    kind: SelfNodeRemediationTemplate
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: selfnoderemediationtemplate-sample

Copy to Clipboard

Toggle word wrap

1: Indique si le contrôle de l'état de la machine concerne les nœuds worker ou control-plane. L'étiquette peut également être définie par l'utilisateur.
2: Spécifie les détails du modèle de remédiation.

Pour créer un CR MachineHealthCheck, exécutez la commande suivante :
```
oc create -f <mhc-name>.yaml
```
```
oc create -f <mhc-name>.yaml
```
Copy to Clipboard Toggle word wrap
Pour mettre à jour un CR MachineHealthCheck, exécutez la commande suivante :
```
oc apply -f <mhc-name>.yaml
```
```
$ oc apply -f <mhc-name>.yaml
```
Copy to Clipboard Toggle word wrap

5.6.4. Remédier aux nœuds avec les contrôles de santé des nœuds
Copier lien

Vous pouvez utiliser l'opérateur de contrôle de l'état des nœuds pour identifier les nœuds en mauvais état. L'opérateur utilise l'opérateur d'auto-remédiation des nœuds pour remédier aux nœuds malsains.

5.6.4.1. À propos de l'opérateur du bilan de santé du nœud
Copier lien

L'opérateur Node Health Check détecte l'état de santé des nœuds d'une grappe. Le contrôleur NodeHealthCheck crée la ressource personnalisée (CR) NodeHealthCheck, qui définit un ensemble de critères et de seuils permettant de déterminer l'état d'un nœud.

L'opérateur du bilan de santé du nœud installe également l'opérateur de remédiation du nœud lui-même en tant que fournisseur de remédiation par défaut.

Lorsque l'opérateur de contrôle de l'état des nœuds détecte un nœud malsain, il crée un CR de remédiation qui déclenche le fournisseur de remédiation. Par exemple, le contrôleur crée la CR SelfNodeRemediation, qui déclenche l'opérateur de remédiation de nœud autonome pour remédier au nœud malsain.

Le CR NodeHealthCheck ressemble au fichier YAML suivant :

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nodehealthcheck-sample
spec:
  minHealthy: 51% 
  pauseRequests: 
    - <pause-test-cluster>
  remediationTemplate: 
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: self-node-remediation-resource-deletion-template
    namespace: openshift-operators
    kind: SelfNodeRemediationTemplate
  selector: 
    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions: 
    - type: Ready
      status: "False"
      duration: 300s 
    - type: Ready
      status: Unknown
      duration: 300s

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nodehealthcheck-sample
spec:
  minHealthy: 51%


  pauseRequests:


    - <pause-test-cluster>
  remediationTemplate:


    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: self-node-remediation-resource-deletion-template
    namespace: openshift-operators
    kind: SelfNodeRemediationTemplate
  selector:


    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions:


    - type: Ready
      status: "False"
      duration: 300s


    - type: Ready
      status: Unknown
      duration: 300s

Copy to Clipboard

Toggle word wrap

1: Spécifie le nombre de nœuds sains (en pourcentage ou en nombre) requis pour qu'un fournisseur de remédiation remédie simultanément aux nœuds du pool ciblé. Si le nombre de nœuds sains est égal ou supérieur à la limite définie par minHealthy, la remédiation a lieu. La valeur par défaut est 51 %.
2: Empêche le démarrage de toute nouvelle remédiation, tout en permettant aux remédiations en cours de persister. La valeur par défaut est vide. Cependant, vous pouvez saisir un tableau de chaînes de caractères qui identifient la cause de la mise en pause de la remédiation. Par exemple, pause-test-cluster.
Note
Au cours du processus de mise à niveau, les nœuds de la grappe peuvent devenir temporairement indisponibles et être identifiés comme malsains. Dans le cas des nœuds de travail, lorsque l'opérateur détecte que la grappe est en cours de mise à niveau, il cesse de remédier aux nouveaux nœuds malsains afin d'éviter que ces nœuds ne redémarrent.
3: Spécifie un modèle de remédiation à partir du fournisseur de remédiation. Par exemple, de l'opérateur de remédiation Self Node.
4: Spécifie une adresse selector qui correspond aux étiquettes ou aux expressions que vous souhaitez vérifier. La valeur par défaut est empty, qui sélectionne tous les nœuds.
5: Spécifie une liste des conditions qui déterminent si un nœud est considéré comme malsain.
6 7: Spécifie la durée du délai d'attente pour une condition de nœud. Si une condition est remplie pendant la durée du délai, le nœud sera remédié. Les délais d'attente prolongés peuvent entraîner de longues périodes d'indisponibilité pour une charge de travail sur un nœud malsain.

5.6.4.1.1. Comprendre le flux de travail de l'opérateur du bilan de santé du nœud
Copier lien

Lorsqu'un nœud est identifié comme étant en mauvaise santé, l'opérateur de contrôle de la santé des nœuds vérifie combien d'autres nœuds sont en mauvaise santé. Si le nombre de nœuds sains dépasse la quantité spécifiée dans le champ minHealthy du CR NodeHealthCheck, le contrôleur crée un CR de remédiation à partir des détails fournis dans le modèle de remédiation externe par le fournisseur de remédiation. Après la remédiation, le kubelet met à jour l'état de santé du nœud.

Lorsque le nœud devient sain, le contrôleur supprime le modèle de remédiation externe.

5.6.4.1.2. Comment les contrôles de santé des nœuds évitent les conflits avec les contrôles de santé des machines
Copier lien

Lorsque des contrôles de santé des nœuds et des contrôles de santé des machines sont déployés, le contrôle de santé des nœuds évite tout conflit avec le contrôle de santé des machines.

Note

OpenShift Container Platform déploie machine-api-termination-handler comme ressource par défaut MachineHealthCheck.

La liste suivante résume le comportement du système lorsque les contrôles de santé des nœuds et des machines sont déployés :

Si seul le contrôle de l'état de la machine par défaut existe, le contrôle de l'état des nœuds continue d'identifier les nœuds en mauvaise santé. Toutefois, le bilan de santé des nœuds ignore les nœuds malsains en état d'arrêt. Le contrôle de l'état de santé de la machine par défaut traite les nœuds malsains dont l'état est en voie d'achèvement.
Exemple de message du journal
```
INFO MHCChecker	ignoring unhealthy Node, it is terminating and will be handled by MHC	{"NodeName": "node-1.example.com"}
```
```
INFO MHCChecker	ignoring unhealthy Node, it is terminating and will be handled by MHC	{"NodeName": "node-1.example.com"}
```
Copy to Clipboard Toggle word wrap

Si le contrôle de l'état de la machine par défaut est modifié (par exemple, unhealthyConditions est Ready) ou si des contrôles de l'état de la machine supplémentaires sont créés, le contrôle de l'état du nœud est désactivé.

Exemple de message du journal

INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

Copy to Clipboard

Toggle word wrap

Lorsque, à nouveau, seul le bilan de santé par défaut de la machine existe, le bilan de santé du nœud est réactivé.

Exemple de message du journal

INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

Copy to Clipboard

Toggle word wrap

5.6.4.2. Clôture du plan de contrôle
Copier lien

N'utilisez pas le même NodeHealthCheck CR pour les nœuds de travail et les nœuds de plan de contrôle. Le regroupement de nœuds de travail et de nœuds de plan de contrôle peut entraîner une évaluation incorrecte du nombre minimal de nœuds sains et provoquer des mesures correctives inattendues ou manquantes. Cela est dû à la manière dont l'opérateur du bilan de santé des nœuds gère les nœuds de plan de contrôle. Vous devez regrouper les nœuds de plan de contrôle dans leur propre groupe et les nœuds de travail dans leur propre groupe. Si nécessaire, vous pouvez également créer plusieurs groupes de nœuds de travail.

Considérations relatives aux stratégies de remédiation :

Évitez les configurations du bilan de santé des nœuds qui impliquent plusieurs configurations chevauchant les mêmes nœuds, car elles peuvent entraîner un comportement inattendu. Cette suggestion s'applique aux nœuds du plan de travail et du plan de contrôle.
L'opérateur de contrôle de l'état des nœuds met en œuvre une limitation codée en dur consistant à remédier à un maximum d'un nœud de plan de contrôle à la fois. Plusieurs nœuds de plan de contrôle ne doivent pas être assainis en même temps.

5.6.4.3. Installation du Node Health Check Operator à l'aide de la console web
Copier lien

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Node Health Check.

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.
Recherchez l'opérateur du bilan de santé du nœud, puis cliquez sur Install.
Conservez la sélection par défaut de Installation mode et namespace pour vous assurer que l'opérateur sera installé dans l'espace de noms openshift-operators.
Assurez-vous que l'adresse Console plug-in est réglée sur Enable.
Cliquez sur Install.

Vérification

Pour confirmer que l'installation a réussi :

Naviguez jusqu'à la page Operators → Installed Operators.
Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.

Si l'opérateur n'est pas installé correctement :

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

5.6.4.4. Installation de l'opérateur de contrôle de santé des nœuds à l'aide de la CLI
Copier lien

Vous pouvez utiliser le CLI OpenShift (oc) pour installer l'opérateur Node Health Check.

Pour installer l'opérateur dans votre propre espace de noms, suivez les étapes de la procédure.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer une ressource personnalisée (CR) Namespace pour l'opérateur du bilan de santé du nœud :
1. Définissez le CR Namespace et enregistrez le fichier YAML, par exemple node-health-check-namespace.yaml:
  apiVersion: v1 kind: Namespace metadata: name: node-health-check
  Copy to Clipboard Toggle word wrap
2. Pour créer le CR Namespace, exécutez la commande suivante :
  $ oc create -f node-health-check-namespace.yaml
  Copy to Clipboard Toggle word wrap

Créer un CR OperatorGroup:

Définissez le CR OperatorGroup et enregistrez le fichier YAML, par exemple node-health-check-operator-group.yaml:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-health-check-operator
  namespace: node-health-check

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-health-check-operator
  namespace: node-health-check

Copy to Clipboard

Toggle word wrap

Pour créer le CR OperatorGroup, exécutez la commande suivante :
```
oc create -f node-health-check-operator-group.yaml
```
```
$ oc create -f node-health-check-operator-group.yaml
```
Copy to Clipboard Toggle word wrap

Créer un CR Subscription:
1. Définissez le CR Subscription et enregistrez le fichier YAML, par exemple node-health-check-subscription.yaml:
  apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: node-health-check-operator namespace: node-health-check
  1
  spec: channel: stable
  2
  installPlanApproval: Manual
  3
  name: node-healthcheck-operator source: redhat-operators sourceNamespace: openshift-marketplace package: node-healthcheck-operator
  Copy to Clipboard Toggle word wrap
  1
  Indiquez le site Namespace où vous souhaitez installer l'opérateur de contrôle de santé des nœuds. Pour installer l'opérateur de contrôle de santé des nœuds dans l'espace de noms openshift-operators, indiquez openshift-operators dans le CR Subscription.
  2
  Indiquez le nom du canal pour votre abonnement. Pour passer à la dernière version du Node Health Check Operator, vous devez modifier manuellement le nom du canal de votre abonnement de candidate à stable.
  3
  Définissez la stratégie d'approbation sur Manuel au cas où la version spécifiée serait remplacée par une version ultérieure dans le catalogue. Ce plan empêche une mise à niveau automatique vers une version ultérieure et nécessite une approbation manuelle avant que le CSV de départ ne puisse terminer l'installation.
2. Pour créer le CR Subscription, exécutez la commande suivante :
  $ oc create -f node-health-check-subscription.yaml
  Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que l'installation a réussi en inspectant la ressource CSV :

oc get csv -n openshift-operators

$ oc get csv -n openshift-operators

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                              DISPLAY                     VERSION  REPLACES PHASE
node-healthcheck-operator.v0.2.0. Node Health Check Operator  0.2.0             Succeeded

NAME                              DISPLAY                     VERSION  REPLACES PHASE
node-healthcheck-operator.v0.2.0. Node Health Check Operator  0.2.0             Succeeded

Copy to Clipboard

Toggle word wrap

Vérifiez que l'opérateur du bilan de santé du nœud est opérationnel :

oc get deploy -n openshift-operators

$ oc get deploy -n openshift-operators

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-health-check-operator-controller-manager  1/1     1            1           10d

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-health-check-operator-controller-manager  1/1     1            1           10d

Copy to Clipboard

Toggle word wrap

5.6.4.5. Création d'un bilan de santé d'un nœud
Copier lien

À l'aide de la console web, vous pouvez créer un bilan de santé des nœuds afin d'identifier les nœuds en mauvaise santé et de spécifier le type et la stratégie de remédiation pour y remédier.

Procédure

Dans la perspective Administrator de la console web OpenShift Container Platform, cliquez sur Compute → NodeHealthChecks → CreateNodeHealthCheck.
Indiquez si vous souhaitez configurer le contrôle de santé du nœud à l'aide de Form view ou de YAML view.
Saisissez une adresse Name pour le contrôle de santé du nœud. Le nom doit être composé de minuscules, de caractères alphanumériques, de "-" ou de ".", et doit commencer et se terminer par un caractère alphanumérique.
Spécifiez le type Remediator et Self node remediation ou Other. L'option Self node remediation fait partie de l'opérateur Self Node Remediation qui est installé avec l'opérateur Node Health Check. La sélection de Other nécessite la saisie de API version, Kind, Name et Namespace, qui pointent ensuite vers la ressource de modèle de remédiation d'un remédiateur.
Effectuez une sélection sur Nodes en spécifiant les étiquettes des nœuds que vous souhaitez assainir. La sélection correspond aux étiquettes que vous souhaitez vérifier. Si plusieurs étiquettes sont spécifiées, les nœuds doivent contenir chacune d'entre elles. La valeur par défaut est empty, ce qui permet de sélectionner à la fois les nœuds du plan de travail et les nœuds du plan de contrôle.
Note
Lors de la création d'un contrôle de l'état d'un nœud à l'aide de l'opérateur d'auto-remédiation des nœuds, vous devez sélectionner node-role.kubernetes.io/worker ou node-role.kubernetes.io/control-plane comme valeur.
Spécifiez le nombre minimum de nœuds sains, sous la forme d'un pourcentage ou d'un nombre, requis pour qu'un site NodeHealthCheck remédie aux nœuds du pool ciblé. Si le nombre de nœuds sains est égal ou supérieur à la limite définie par Min healthy, la remédiation a lieu. La valeur par défaut est 51 %.
Spécifiez une liste de Unhealthy conditions qui, si un nœud y répond, détermine si le nœud est considéré comme malsain et nécessite une remédiation. Vous pouvez spécifier les types Type, Status et Duration. Vous pouvez également créer votre propre type personnalisé.
Cliquez sur Create pour créer le bilan de santé du nœud.

Vérification

Accédez à la page Compute → NodeHealthCheck et vérifiez que le contrôle de santé du nœud correspondant est répertorié et que son état est affiché. Une fois créés, les contrôles de santé des nœuds peuvent être interrompus, modifiés et supprimés.

5.6.4.6. Collecte de données sur l'opérateur du bilan de santé du nœud
Copier lien

Pour collecter des informations de débogage sur le Node Health Check Operator, utilisez l'outil must-gather. Pour plus d'informations sur l'image must-gather de l'opérateur de contrôle de santé des nœuds, voir Collecte de données sur des fonctionnalités spécifiques.

5.6.4.7. Ressources supplémentaires
Copier lien

5.6.5. Mise en mode maintenance des nœuds avec l'opérateur de maintenance des nœuds
Copier lien

Vous pouvez utiliser l'opérateur de maintenance des nœuds pour placer les nœuds en mode maintenance à l'aide de l'utilitaire oc adm ou des ressources personnalisées (CR) NodeMaintenance.

5.6.5.1. À propos de l'opérateur de maintenance des nœuds
Copier lien

L'opérateur de maintenance des nœuds surveille les CR NodeMaintenance nouveaux ou supprimés. Lorsqu'un nouveau CR NodeMaintenance est détecté, aucune nouvelle charge de travail n'est programmée et le nœud est isolé du reste du cluster. Tous les pods qui peuvent être expulsés le sont du nœud. Lorsqu'un CR NodeMaintenance est supprimé, le nœud référencé dans le CR est rendu disponible pour de nouvelles charges de travail.

Note

L'utilisation d'un CR NodeMaintenance pour les tâches de maintenance des nœuds permet d'obtenir les mêmes résultats que les commandes oc adm cordon et oc adm drain à l'aide du traitement CR standard de OpenShift Container Platform.

5.6.5.2. Installation de l'opérateur de maintenance des nœuds
Copier lien

Vous pouvez installer l'opérateur de maintenance de nœuds à l'aide de la console Web ou de la CLI OpenShift (oc).

Note

Si la version 4.10 ou moins d'OpenShift Virtualization est installée dans votre cluster, elle inclut une version obsolète de l'opérateur de maintenance Node.

5.6.5.2.1. Installation de l'opérateur de maintenance de nœuds à l'aide de la console web
Copier lien

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur de maintenance Node.

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.
Recherchez l'opérateur de maintenance du nœud, puis cliquez sur Install.
Conservez la sélection par défaut de Installation mode et namespace pour vous assurer que l'opérateur sera installé dans l'espace de noms openshift-operators.
Cliquez sur Install.

Vérification

Pour confirmer que l'installation a réussi :

Naviguez jusqu'à la page Operators → Installed Operators.
Vérifiez que l'Opérateur est installé dans l'espace de noms openshift-operators et que son statut est Succeeded.

Si l'opérateur n'est pas installé correctement :

Naviguez jusqu'à la page Operators → Installed Operators et vérifiez que la colonne Status ne contient pas d'erreurs ou de défaillances.
Naviguez jusqu'à la page Operators → Installed Operators → Node Maintenance Operator → Details, et vérifiez que la section Conditions ne contient pas d'erreurs avant la création du pod.
Naviguez jusqu'à la page Workloads → Pods, recherchez le pod Node Maintenance Operator dans l'espace de noms installé et vérifiez les journaux dans l'onglet Logs.

5.6.5.2.2. Installation de l'opérateur de maintenance de nœuds à l'aide de la CLI
Copier lien

Vous pouvez utiliser le CLI OpenShift (oc) pour installer l'opérateur de maintenance Node.

Vous pouvez installer l'opérateur de maintenance de nœuds dans votre propre espace de noms ou dans l'espace de noms openshift-operators.

Pour installer l'opérateur dans votre propre espace de noms, suivez les étapes de la procédure.

Conditions préalables

Installez le CLI OpenShift (oc).
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créer un CR Namespace pour l'opérateur de maintenance des nœuds :
1. Définissez le CR Namespace et enregistrez le fichier YAML, par exemple node-maintenance-namespace.yaml:
  apiVersion: v1 kind: Namespace metadata: name: nmo-test
  Copy to Clipboard Toggle word wrap
2. Pour créer le CR Namespace, exécutez la commande suivante :
  $ oc create -f node-maintenance-namespace.yaml
  Copy to Clipboard Toggle word wrap

Créer un CR OperatorGroup:

Définissez le CR OperatorGroup et enregistrez le fichier YAML, par exemple node-maintenance-operator-group.yaml:

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-maintenance-operator
  namespace: nmo-test

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-maintenance-operator
  namespace: nmo-test

Copy to Clipboard

Toggle word wrap

Pour créer le CR OperatorGroup, exécutez la commande suivante :
```
oc create -f node-maintenance-operator-group.yaml
```
```
$ oc create -f node-maintenance-operator-group.yaml
```
Copy to Clipboard Toggle word wrap

Créer un CR Subscription:

Définissez le CR Subscription et enregistrez le fichier YAML, par exemple node-maintenance-subscription.yaml:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: node-maintenance-operator
  namespace: nmo-test 
spec:
  channel: stable
  InstallPlaneApproval: Automatic
  name: node-maintenance-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  StartingCSV: node-maintenance-operator.v4.12.0

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: node-maintenance-operator
  namespace: nmo-test


spec:
  channel: stable
  InstallPlaneApproval: Automatic
  name: node-maintenance-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  StartingCSV: node-maintenance-operator.v4.12.0

Copy to Clipboard

Toggle word wrap

1: Spécifiez le site Namespace où vous souhaitez installer l'opérateur de maintenance de nœuds.

Important

Pour installer l'opérateur de maintenance de nœuds dans l'espace de noms openshift-operators, spécifiez openshift-operators dans le CR Subscription.

Pour créer le CR Subscription, exécutez la commande suivante :
```
oc create -f node-maintenance-subscription.yaml
```
```
$ oc create -f node-maintenance-subscription.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Vérifiez que l'installation a réussi en inspectant la ressource CSV :

oc get csv -n openshift-operators

$ oc get csv -n openshift-operators

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                               DISPLAY                     VERSION   REPLACES  PHASE
node-maintenance-operator.v4.12    Node Maintenance Operator   4.12                Succeeded

NAME                               DISPLAY                     VERSION   REPLACES  PHASE
node-maintenance-operator.v4.12    Node Maintenance Operator   4.12                Succeeded

Copy to Clipboard

Toggle word wrap

Vérifiez que l'opérateur de maintenance des nœuds est en cours d'exécution :

oc get deploy -n openshift-operators

$ oc get deploy -n openshift-operators

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-maintenance-operator-controller-manager   1/1     1            1           10d

NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-maintenance-operator-controller-manager   1/1     1            1           10d

Copy to Clipboard

Toggle word wrap

L'opérateur de maintenance de nœuds est pris en charge dans un environnement de réseau restreint. Pour plus d'informations, voir Utilisation d'Operator Lifecycle Manager sur des réseaux restreints.

5.6.5.3. Mise en mode maintenance d'un nœud
Copier lien

Vous pouvez placer un nœud en mode maintenance à partir de la console Web ou de la CLI en utilisant NodeMaintenance CR.

5.6.5.3.1. Mise en mode maintenance d'un nœud à l'aide de la console web
Copier lien

Pour mettre un nœud en mode maintenance, vous pouvez créer une ressource personnalisée (CR) NodeMaintenance à l'aide de la console web.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installez l'opérateur de maintenance du nœud à partir du site OperatorHub.

Procédure

Depuis la perspective Administrator dans la console web, naviguez vers Operators → Installed Operators.
Sélectionnez l'opérateur de maintenance du nœud dans la liste des opérateurs.
Dans l'onglet Node Maintenance, cliquez sur Create NodeMaintenance.
Dans la page Create NodeMaintenance, sélectionnez Form view ou YAML view pour configurer le CR NodeMaintenance.
Pour appliquer la CR NodeMaintenance que vous avez configurée, cliquez sur Create.

Vérification

Dans l'onglet Node Maintenance, inspectez la colonne Status et vérifiez que son statut est Succeeded.

5.6.5.3.2. Mise en mode maintenance d'un nœud à l'aide de la CLI
Copier lien

Vous pouvez mettre un nœud en mode maintenance avec une ressource personnalisée (CR) NodeMaintenance. Lorsque vous appliquez une CR NodeMaintenance, tous les pods autorisés sont expulsés et le nœud devient inutilisable. Les pods expulsés sont mis en file d'attente pour être déplacés vers un autre nœud du cluster.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous au cluster en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Créez le document NodeMaintenance CR suivant et enregistrez le fichier sous nodemaintenance-cr.yaml:

apiVersion: nodemaintenance.medik8s.io/v1beta1
kind: NodeMaintenance
metadata:
  name: nodemaintenance-cr  
spec:
  nodeName: node-1.example.com 
  reason: "NIC replacement"

apiVersion: nodemaintenance.medik8s.io/v1beta1
kind: NodeMaintenance
metadata:
  name: nodemaintenance-cr


spec:
  nodeName: node-1.example.com


  reason: "NIC replacement"

Copy to Clipboard

Toggle word wrap

1: Le nom du CR de maintenance du nœud.
2: Le nom du nœud à mettre en mode maintenance.
3: Description en texte clair du motif de la maintenance.

Appliquez le CR de maintenance des nœuds en exécutant la commande suivante :
```
oc apply -f nodemaintenance-cr.yaml
```
```
$ oc apply -f nodemaintenance-cr.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Vérifiez l'état d'avancement de la tâche de maintenance en exécutant la commande suivante :
```
oc describe node <node-name>
```
```
$ oc describe node <node-name>
```
Copy to Clipboard Toggle word wrap
où <node-name> est le nom de votre nœud ; par exemple, node-1.example.com

Vérifier la sortie de l'exemple :

Events:
  Type     Reason                     Age                   From     Message
  ----     ------                     ----                  ----     -------
  Normal   NodeNotSchedulable         61m                   kubelet  Node node-1.example.com status is now: NodeNotSchedulable

Events:
  Type     Reason                     Age                   From     Message
  ----     ------                     ----                  ----     -------
  Normal   NodeNotSchedulable         61m                   kubelet  Node node-1.example.com status is now: NodeNotSchedulable

Copy to Clipboard

Toggle word wrap

5.6.5.3.3. Vérification de l'état des tâches de maintenance des nœuds en cours de CR
Copier lien

Vous pouvez vérifier l'état des tâches NodeMaintenance CR en cours.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Vérifiez l'état des tâches de maintenance des nœuds en cours, par exemple l'objet NodeMaintenance CR ou nm, en exécutant la commande suivante :

oc get nm -o yaml

$ oc get nm -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: v1
items:
- apiVersion: nodemaintenance.medik8s.io/v1beta1
  kind: NodeMaintenance
  metadata:
...
  spec:
    nodeName: node-1.example.com
    reason: Node maintenance
  status:
    drainProgress: 100   
    evictionPods: 3   
    lastError: "Last failure message" 
    lastUpdate: "2022-06-23T11:43:18Z" 
    phase: Succeeded
    totalpods: 5 
...

apiVersion: v1
items:
- apiVersion: nodemaintenance.medik8s.io/v1beta1
  kind: NodeMaintenance
  metadata:
...
  spec:
    nodeName: node-1.example.com
    reason: Node maintenance
  status:
    drainProgress: 100


    evictionPods: 3


    lastError: "Last failure message"


    lastUpdate: "2022-06-23T11:43:18Z"


    phase: Succeeded
    totalpods: 5

...

Copy to Clipboard

Toggle word wrap

1: Le pourcentage d'achèvement de la vidange du nœud.
2: Le nombre de nacelles dont l'expulsion est prévue.
3: La dernière erreur d'expulsion, le cas échéant.
4: La dernière fois que le statut a été mis à jour.
5: Nombre total de pods avant que le nœud ne passe en mode maintenance.

5.6.5.4. Reprise d'un nœud en mode maintenance
Copier lien

Vous pouvez reprendre un nœud depuis le mode de maintenance à partir de la console Web ou de l'interface CLI en utilisant NodeMaintenance CR. La reprise d'un nœud le fait sortir du mode de maintenance et le rend à nouveau planifiable.

5.6.5.4.1. Reprise d'un nœud en mode maintenance à l'aide de la console web
Copier lien

Pour reprendre un nœud en mode maintenance, vous pouvez supprimer une ressource personnalisée (CR) NodeMaintenance à l'aide de la console web.

Conditions préalables

Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
Installez l'opérateur de maintenance du nœud à partir du site OperatorHub.

Procédure

Depuis la perspective Administrator dans la console web, naviguez vers Operators → Installed Operators.
Sélectionnez l'opérateur de maintenance du nœud dans la liste des opérateurs.
Dans l'onglet Node Maintenance, sélectionnez le CR NodeMaintenance que vous souhaitez supprimer.
Cliquez sur le menu Options à l'extrémité du nœud et sélectionnez Delete NodeMaintenance.

Vérification

Dans la console OpenShift Container Platform, cliquez sur Compute → Nodes.
Inspectez la colonne Status du nœud pour lequel vous avez supprimé le CR NodeMaintenance et vérifiez que son statut est Ready.

5.6.5.4.2. Reprise d'un nœud en mode maintenance à l'aide de la CLI
Copier lien

Vous pouvez reprendre un nœud en mode maintenance qui a été initié avec un CR NodeMaintenance en supprimant le CR NodeMaintenance.

Conditions préalables

Install the OpenShift Container Platform CLI oc.
Connectez-vous au cluster en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

Lorsque votre tâche de maintenance du nœud est terminée, supprimez le CR actif NodeMaintenance:
```
oc delete -f nodemaintenance-cr.yaml
```
```
$ oc delete -f nodemaintenance-cr.yaml
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted
```
```
nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted
```
Copy to Clipboard Toggle word wrap

Vérification

Vérifiez l'état d'avancement de la tâche de maintenance en exécutant la commande suivante :
```
oc describe node <node-name>
```
```
$ oc describe node <node-name>
```
Copy to Clipboard Toggle word wrap
où <node-name> est le nom de votre nœud ; par exemple, node-1.example.com

Vérifier la sortie de l'exemple :

Events:
  Type     Reason                  Age                   From     Message
  ----     ------                  ----                  ----     -------
  Normal   NodeSchedulable         2m                    kubelet  Node node-1.example.com status is now: NodeSchedulable

Events:
  Type     Reason                  Age                   From     Message
  ----     ------                  ----                  ----     -------
  Normal   NodeSchedulable         2m                    kubelet  Node node-1.example.com status is now: NodeSchedulable

Copy to Clipboard

Toggle word wrap

5.6.5.5. Travailler avec des nœuds nus
Copier lien

Pour les clusters avec nœuds bare-metal, vous pouvez placer un nœud en mode maintenance et reprendre un nœud depuis le mode maintenance en utilisant le contrôle de la console web Actions.

Note

Les grappes dotées de nœuds nus peuvent également placer un nœud en mode de maintenance et reprendre un nœud en mode de maintenance à l'aide de la console web et de l'interface de ligne de commande (CLI), comme indiqué. Ces méthodes, qui font appel à la console web Actions, ne s'appliquent qu'aux clusters bare-metal.

5.6.5.5.1. Maintenance des nœuds nus
Copier lien

Lorsque vous déployez OpenShift Container Platform sur une infrastructure bare-metal, vous devez prendre en compte des considérations supplémentaires par rapport au déploiement sur une infrastructure cloud. Contrairement aux environnements cloud, où les nœuds de cluster sont considérés comme éphémères, le reprovisionnement d'un nœud bare-metal nécessite beaucoup plus de temps et d'efforts pour les tâches de maintenance.

Lorsqu'un nœud bare-metal tombe en panne à cause d'une erreur du noyau ou d'une défaillance matérielle de la carte NIC, les charges de travail sur le nœud en panne doivent être redémarrées sur un autre nœud de la grappe pendant que le nœud en panne est réparé ou remplacé. Le mode de maintenance des nœuds permet aux administrateurs de grappes d'éteindre les nœuds avec élégance, de déplacer les charges de travail vers d'autres parties de la grappe et de s'assurer que les charges de travail ne sont pas interrompues. Des informations détaillées sur la progression et l'état des nœuds sont fournies pendant la maintenance.

5.6.5.5.2. Passage d'un nœud bare-metal en mode maintenance
Copier lien

Mettre un nœud bare-metal en mode maintenance à l'aide du menu Options kebab qui se trouve sur chaque nœud dans la liste Compute → Nodes, ou en utilisant la commande Actions de l'écran Node Details.

Procédure

Dans la perspective Administrator de la console web, cliquez sur Compute → Nodes.
Vous pouvez définir le nœud à gérer à partir de cet écran, ce qui facilite l'exécution d'actions sur plusieurs nœuds, ou à partir de l'écran Node Details, où vous pouvez afficher des détails complets sur le nœud sélectionné :
- Cliquez sur le menu Options à l'extrémité du nœud et sélectionnez Start Maintenance.
- Cliquez sur le nom du nœud pour ouvrir l'écran Node Details et cliquez sur Actions → Start Maintenance.
Cliquez sur Start Maintenance dans la fenêtre de confirmation.

Le nœud n'est plus planifiable. S'il avait des machines virtuelles avec la stratégie d'éviction LiveMigration, il les migrera en direct. Tous les autres pods et machines virtuelles sur le nœud sont supprimés et recréés sur un autre nœud.

Vérification

Naviguez jusqu'à la page Compute → Nodes et vérifiez que le nœud correspondant a le statut Under maintenance.

5.6.5.5.3. Reprise d'un nœud bare-metal depuis le mode maintenance
Copier lien

Reprendre un nœud bare-metal depuis le mode maintenance à l'aide du menu Options kebab qui se trouve sur chaque nœud dans la liste Compute → Nodes, ou en utilisant la commande Actions de l'écran Node Details.

Procédure

Dans la perspective Administrator de la console web, cliquez sur Compute → Nodes.
Vous pouvez reprendre le nœud à partir de cet écran, ce qui facilite l'exécution d'actions sur plusieurs nœuds, ou à partir de l'écran Node Details, où vous pouvez afficher des détails complets sur le nœud sélectionné :
- Cliquez sur le menu Options à l'extrémité du nœud et sélectionnez Stop Maintenance.
- Cliquez sur le nom du nœud pour ouvrir l'écran Node Details et cliquez sur Actions → Stop Maintenance.
Cliquez sur Stop Maintenance dans la fenêtre de confirmation.

Le nœud devient planifiable. Si des instances de machines virtuelles fonctionnaient sur le nœud avant la maintenance, elles ne migreront pas automatiquement vers ce nœud.

Vérification

Naviguez jusqu'à la page Compute → Nodes et vérifiez que le nœud correspondant a le statut Ready.

5.6.5.6. Collecte de données sur l'opérateur de maintenance du nœud
Copier lien

Pour collecter des informations de débogage sur l'opérateur de maintenance de nœuds, utilisez l'outil must-gather. Pour plus d'informations sur l'image must-gather de l'opérateur de maintenance de nœuds, voir Collecte de données sur des fonctionnalités spécifiques.

5.7. Comprendre le redémarrage des nœuds
Copier lien

Pour redémarrer un nœud sans provoquer de panne pour les applications fonctionnant sur la plate-forme, il est important d'évacuer d'abord les pods. Pour les pods qui sont rendus hautement disponibles par le niveau de routage, il n'y a rien d'autre à faire. Pour les autres modules qui ont besoin de stockage, généralement des bases de données, il est essentiel de s'assurer qu'ils peuvent continuer à fonctionner même si l'un d'entre eux est temporairement hors ligne. Bien que la mise en œuvre de la résilience pour les pods avec état soit différente pour chaque application, dans tous les cas, il est important de configurer l'ordonnanceur pour utiliser l'anti-affinité des nœuds afin de s'assurer que les pods sont correctement répartis sur les nœuds disponibles.

Un autre défi consiste à gérer les nœuds qui gèrent une infrastructure critique telle que le routeur ou le registre. Le même processus d'évacuation des nœuds s'applique, bien qu'il soit important de comprendre certains cas limites.

5.7.1. À propos du redémarrage des nœuds exécutant une infrastructure critique
Copier lien

Lors du redémarrage des nœuds qui hébergent des composants d'infrastructure critiques d'OpenShift Container Platform, tels que les pods de routeur, les pods de registre et les pods de surveillance, assurez-vous qu'il y a au moins trois nœuds disponibles pour exécuter ces composants.

Le scénario suivant montre comment des interruptions de service peuvent se produire avec des applications exécutées sur OpenShift Container Platform lorsque seuls deux nœuds sont disponibles :

Le nœud A est déclaré inséparable et toutes les nacelles sont évacuées.
Le pod de registre fonctionnant sur ce nœud est maintenant redéployé sur le nœud B. Le nœud B exécute maintenant les deux pods de registre.
Le nœud B est maintenant considéré comme non planifiable et est évacué.
Le service exposant les deux points d'extrémité de pods sur le nœud B perd tous les points d'extrémité, pendant une brève période, jusqu'à ce qu'ils soient redéployés sur le nœud A.

Lorsque trois nœuds sont utilisés pour les composants d'infrastructure, ce processus n'entraîne pas d'interruption de service. Toutefois, en raison de la planification des pods, le dernier nœud évacué et remis en rotation n'a pas de pod de registre. L'un des autres nœuds dispose de deux modules de registre. Pour planifier le troisième module de registre sur le dernier nœud, utilisez l'anti-affinité de module pour empêcher l'ordonnanceur de placer deux modules de registre sur le même nœud.

Informations complémentaires

Pour plus d'informations sur l'anti-affinité des pods, voir Placement des pods par rapport à d'autres pods à l'aide de règles d'affinité et d'anti-affinité.

5.7.2. Redémarrage d'un nœud à l'aide d'un pod anti-affinité
Copier lien

L'anti-affinité des pods est légèrement différente de l'anti-affinité des nœuds. L'anti-affinité de nœud peut être violée s'il n'y a pas d'autres emplacements appropriés pour déployer un pod. L'anti-affinité des pods peut être définie comme requise ou préférée.

Ainsi, si seuls deux nœuds d'infrastructure sont disponibles et que l'un d'entre eux est redémarré, le pod de registre d'images de conteneurs ne peut pas s'exécuter sur l'autre nœud. oc get pods signale le pod comme étant non prêt jusqu'à ce qu'un nœud approprié soit disponible. Une fois qu'un nœud est disponible et que tous les pods sont de nouveau prêts, le nœud suivant peut être redémarré.

Procédure

Pour redémarrer un nœud en utilisant l'anti-affinité des pods :

Modifiez la spécification du nœud pour configurer l'anti-affinité du pod :

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 
      preferredDuringSchedulingIgnoredDuringExecution: 
      - weight: 100 
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: registry 
              operator: In 
              values:
              - default
          topologyKey: kubernetes.io/hostname

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity:


      preferredDuringSchedulingIgnoredDuringExecution:


      - weight: 100


        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: registry


              operator: In


              values:
              - default
          topologyKey: kubernetes.io/hostname

Copy to Clipboard

Toggle word wrap

1: Stanza pour configurer l'anti-affinité du pod.
2: Définit une règle préférentielle.
3: Spécifie un poids pour une règle préférentielle. Le nœud ayant le poids le plus élevé est privilégié.
4: Description de l'étiquette du pod qui détermine quand la règle anti-affinité s'applique. Spécifiez une clé et une valeur pour l'étiquette.
5: L'opérateur représente la relation entre l'étiquette de la capsule existante et l'ensemble des valeurs des paramètres matchExpression dans la spécification de la nouvelle capsule. Il peut s'agir de In, NotIn, Exists ou DoesNotExist.

Cet exemple suppose que le pod du registre d'images de conteneurs a une étiquette de registry=default. L'anti-affinité de pod peut utiliser n'importe quelle expression de correspondance de Kubernetes.

Activer le prédicat de l'ordonnanceur MatchInterPodAffinity dans le fichier de stratégie d'ordonnancement.
Effectuer un redémarrage gracieux du nœud.

5.7.3. Comprendre comment redémarrer les nœuds utilisant des routeurs
Copier lien

Dans la plupart des cas, un pod exécutant un routeur OpenShift Container Platform expose un port hôte.

Le prédicat de l'ordonnanceur PodFitsPorts garantit qu'aucun pod de routeur utilisant le même port ne peut s'exécuter sur le même nœud, et que l'anti-affinité des pods est réalisée. Si les routeurs s'appuient sur le basculement IP pour la haute disponibilité, il n'y a rien d'autre à faire.

Pour les router pods qui dépendent d'un service externe tel que AWS Elastic Load Balancing pour la haute disponibilité, il est de la responsabilité de ce service de réagir aux redémarrages des router pods.

Dans de rares cas, un router pod peut ne pas avoir de port hôte configuré. Dans ce cas, il est important de suivre la procédure de redémarrage recommandée pour les nœuds d'infrastructure.

5.7.4. Redémarrer un nœud avec élégance
Copier lien

Avant de redémarrer un nœud, il est recommandé de sauvegarder les données etcd afin d'éviter toute perte de données sur le nœud.

Note

Pour les clusters OpenShift à un seul nœud qui nécessitent que les utilisateurs exécutent la commande oc login plutôt que d'avoir les certificats dans le fichier kubeconfig pour gérer le cluster, les commandes oc adm peuvent ne pas être disponibles après le cordon et la vidange du nœud. Cela est dû au fait que le pod openshift-oauth-apiserver n'est pas en cours d'exécution en raison du cordon. Vous pouvez utiliser SSH pour accéder aux nœuds comme indiqué dans la procédure suivante.

Dans un cluster OpenShift à un seul nœud, les pods ne peuvent pas être reprogrammés lors du cordonage et de la vidange. Cependant, cela donne aux pods, en particulier à vos pods de charge de travail, le temps de s'arrêter correctement et de libérer les ressources associées.

Procédure

Pour effectuer un redémarrage gracieux d'un nœud :

Marquer le nœud comme non ordonnançable :
```
oc adm cordon <node1> $ oc adm cordon <node1>
```
```
oc adm cordon <node1> $ oc adm cordon <node1>
```
Copy to Clipboard Toggle word wrap

Drainer le nœud pour supprimer tous les pods en cours d'exécution :

oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

$ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

Copy to Clipboard

Toggle word wrap

Il se peut que vous receviez des erreurs indiquant que les pods associés à des budgets de perturbation de pods personnalisés (PDB) ne peuvent pas être expulsés.

Exemple d'erreur

error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

Copy to Clipboard

Toggle word wrap

Dans ce cas, exécutez à nouveau la commande drain, en ajoutant le drapeau disable-eviction, ce qui permet de contourner les contrôles PDB :

oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction

$ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction

Copy to Clipboard

Toggle word wrap

Accéder au nœud en mode débogage :
```
oc debug node/<node1>
```
```
$ oc debug node/<node1>
```
Copy to Clipboard Toggle word wrap
Changez votre répertoire racine en /host:
```
chroot /host
```
```
$ chroot /host
```
Copy to Clipboard Toggle word wrap
Redémarrer le nœud :
```
systemctl reboot
```
```
$ systemctl reboot
```
Copy to Clipboard Toggle word wrap
En un instant, le nœud entre dans l'état NotReady.
Note
Avec certains clusters OpenShift à un seul nœud, les commandes oc peuvent ne pas être disponibles après avoir cordonné et drainé le nœud parce que le pod openshift-oauth-apiserver n'est pas en cours d'exécution. Vous pouvez utiliser SSH pour vous connecter au nœud et effectuer le redémarrage.
$ ssh core@<master-node>.<cluster_name>.<base_domain>
Copy to Clipboard Toggle word wrap
$ sudo systemctl reboot
Copy to Clipboard Toggle word wrap
Une fois le redémarrage terminé, marquez le nœud comme planifiable en exécutant la commande suivante :
```
oc adm uncordon <node1> $ oc adm uncordon <node1>
```
```
oc adm uncordon <node1> $ oc adm uncordon <node1>
```
Copy to Clipboard Toggle word wrap
Note
Avec certains clusters OpenShift à nœud unique, les commandes oc peuvent ne pas être disponibles après avoir cordonné et drainé le nœud parce que le pod openshift-oauth-apiserver n'est pas en cours d'exécution. Vous pouvez utiliser SSH pour vous connecter au nœud et le déconnecter.
$ ssh core@<target_node>
Copy to Clipboard Toggle word wrap
$ sudo oc adm uncordon <node> --kubeconfig /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost.kubeconfig
Copy to Clipboard Toggle word wrap

Vérifiez que le nœud est prêt :

oc get node <node1> $ oc get node <node1>

oc get node <node1> $ oc get node <node1>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME    STATUS  ROLES    AGE     VERSION
<node1> Ready   worker   6d22h   v1.18.3+b0068a8

NAME    STATUS  ROLES    AGE     VERSION
<node1> Ready   worker   6d22h   v1.18.3+b0068a8

Copy to Clipboard

Toggle word wrap

Informations complémentaires

Pour plus d'informations sur la sauvegarde des données etcd, voir Sauvegarde des données etcd.

5.8. Libérer les ressources des nœuds à l'aide du ramassage des ordures
Copier lien

En tant qu'administrateur, vous pouvez utiliser OpenShift Container Platform pour vous assurer que vos nœuds fonctionnent efficacement en libérant des ressources grâce au garbage collection.

Le nœud OpenShift Container Platform effectue deux types de collecte de déchets :

Collecte des déchets des conteneurs : Supprime les conteneurs terminés.
Ramassage des images : Supprime les images non référencées par les pods en cours d'exécution.

5.8.1. Comprendre comment les conteneurs terminés sont supprimés par le ramasse-miettes (garbage collection)
Copier lien

Le ramassage des ordures du conteneur peut être effectué à l'aide de seuils d'éviction.

Lorsque des seuils d'éviction sont définis pour le ramassage des ordures, le nœud tente de conserver tout conteneur pour tout module accessible à partir de l'API. Si le module a été supprimé, les conteneurs le seront également. Les conteneurs sont conservés tant que le module n'est pas supprimé et que le seuil d'éviction n'est pas atteint. Si le nœud est soumis à une pression de disque, il supprimera les conteneurs et leurs journaux ne seront plus accessibles à l'aide de oc logs.

eviction-soft - Un seuil d'expulsion souple associe un seuil d'expulsion à un délai de grâce spécifié par l'administrateur.
eviction-hard - Un seuil d'éviction dur n'a pas de période de grâce, et s'il est observé, OpenShift Container Platform prend des mesures immédiates.

Le tableau suivant énumère les seuils d'éviction :

Expand

Tableau 5.2. Variables pour configurer le ramassage des ordures du conteneur
État du nœud	Signal d'expulsion	Description
MémoirePression	`memory.available`	Mémoire disponible sur le nœud.
Pression du disque	`nodefs.available` `nodefs.inodesFree` `imagefs.available` `imagefs.inodesFree`	L'espace disque ou les inodes disponibles sur le système de fichiers racine du nœud, `nodefs`, ou sur le système de fichiers image, `imagefs`.

Note

Pour evictionHard, vous devez spécifier tous ces paramètres. Si vous ne les spécifiez pas tous, seuls les paramètres spécifiés seront appliqués et le ramassage des ordures ne fonctionnera pas correctement.

Si un nœud oscille au-dessus et au-dessous d'un seuil d'éviction souple, mais sans dépasser le délai de grâce qui lui est associé, le nœud correspondant oscille constamment entre true et false. En conséquence, l'ordonnanceur pourrait prendre de mauvaises décisions en matière d'ordonnancement.

Pour se protéger contre cette oscillation, utilisez le drapeau eviction-pressure-transition-period pour contrôler la durée pendant laquelle OpenShift Container Platform doit attendre avant de sortir d'une condition de pression. OpenShift Container Platform ne définira pas un seuil d'éviction comme étant atteint pour la condition de pression spécifiée pendant la période spécifiée avant de basculer la condition sur false.

5.8.2. Comprendre comment les images sont supprimées par le ramassage des ordures
Copier lien

La collecte d'images s'appuie sur l'utilisation du disque telle qu'elle est rapportée par cAdvisor sur le nœud pour décider quelles images doivent être supprimées du nœud.

La politique de collecte des images est basée sur deux conditions :

Le pourcentage d'utilisation du disque (exprimé sous forme d'un nombre entier) qui déclenche le ramassage des images. La valeur par défaut est 85.
Pourcentage d'utilisation du disque (exprimé sous forme d'un nombre entier) que le ramasse-miettes tente de libérer. La valeur par défaut est 80.

Pour le ramassage des images, vous pouvez modifier l'une des variables suivantes à l'aide d'une ressource personnalisée.

Expand

Tableau 5.3. Variables pour configurer le ramassage des images
Paramètres	Description
`imageMinimumGCAge`	L'âge minimum d'une image inutilisée avant qu'elle ne soit supprimée par le ramasse-miettes. La valeur par défaut est 2m.
`imageGCHighThresholdPercent`	Le pourcentage d'utilisation du disque, exprimé sous la forme d'un entier, qui déclenche le ramassage des images. La valeur par défaut est 85.
`imageGCLowThresholdPercent`	Le pourcentage d'utilisation du disque, exprimé sous forme d'un nombre entier, que le ramasse-miettes tente de libérer. La valeur par défaut est 80.

Deux listes d'images sont récupérées à chaque passage de l'éboueur :

Liste des images en cours d'exécution dans au moins un module.
Liste des images disponibles sur un hôte.

Au fur et à mesure que de nouveaux conteneurs sont lancés, de nouvelles images apparaissent. Toutes les images sont marquées d'un horodatage. Si l'image est en cours d'exécution (première liste ci-dessus) ou nouvellement détectée (deuxième liste ci-dessus), elle est marquée avec l'heure actuelle. Les autres images sont déjà marquées lors des tours précédents. Toutes les images sont ensuite triées en fonction de l'horodatage.

Une fois la collecte commencée, les images les plus anciennes sont supprimées en premier jusqu'à ce que le critère d'arrêt soit rempli.

5.8.3. Configuration du ramassage des ordures pour les conteneurs et les images
Copier lien

En tant qu'administrateur, vous pouvez configurer la façon dont OpenShift Container Platform effectue la collecte des ordures en créant un objet kubeletConfig pour chaque pool de configuration de machine.

Note

OpenShift Container Platform ne prend en charge qu'un seul objet kubeletConfig pour chaque pool de configuration de machine.

Vous pouvez configurer une combinaison des éléments suivants :

Expulsion douce pour les conteneurs
Expulsion dure pour les conteneurs
Expulsion pour des images

Conditions préalables

Obtenez l'étiquette associée au CRD statique MachineConfigPool pour le type de nœud que vous souhaitez configurer en entrant la commande suivante :

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc edit machineconfigpool worker

$ oc edit machineconfigpool worker

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: "" 
  name: worker

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: ""


  name: worker

Copy to Clipboard

Toggle word wrap

1: L'étiquette apparaît sous Étiquettes.

Astuce

Si l'étiquette n'est pas présente, ajoutez une paire clé/valeur comme par exemple :

oc label machineconfigpool worker custom-kubelet=small-pods

$ oc label machineconfigpool worker custom-kubelet=small-pods

Copy to Clipboard

Toggle word wrap

Procédure

Créez une ressource personnalisée (CR) pour votre changement de configuration.

Important

S'il n'y a qu'un seul système de fichiers, ou si /var/lib/kubelet et /var/lib/containers/ se trouvent dans le même système de fichiers, ce sont les paramètres ayant les valeurs les plus élevées qui déclenchent les expulsions, car ils sont respectés en premier. C'est le système de fichiers qui déclenche l'expulsion.

Exemple de configuration pour un conteneur de collecte de déchets CR :

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: worker-kubeconfig 
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
  kubeletConfig:
    evictionSoft: 
      memory.available: "500Mi" 
      nodefs.available: "10%"
      nodefs.inodesFree: "5%"
      imagefs.available: "15%"
      imagefs.inodesFree: "10%"
    evictionSoftGracePeriod:  
      memory.available: "1m30s"
      nodefs.available: "1m30s"
      nodefs.inodesFree: "1m30s"
      imagefs.available: "1m30s"
      imagefs.inodesFree: "1m30s"
    evictionHard: 
      memory.available: "200Mi"
      nodefs.available: "5%"
      nodefs.inodesFree: "4%"
      imagefs.available: "10%"
      imagefs.inodesFree: "5%"
    evictionPressureTransitionPeriod: 0s 
    imageMinimumGCAge: 5m 
    imageGCHighThresholdPercent: 80 
    imageGCLowThresholdPercent: 75

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: worker-kubeconfig


spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""


  kubeletConfig:
    evictionSoft:


      memory.available: "500Mi"


      nodefs.available: "10%"
      nodefs.inodesFree: "5%"
      imagefs.available: "15%"
      imagefs.inodesFree: "10%"
    evictionSoftGracePeriod:


      memory.available: "1m30s"
      nodefs.available: "1m30s"
      nodefs.inodesFree: "1m30s"
      imagefs.available: "1m30s"
      imagefs.inodesFree: "1m30s"
    evictionHard:


      memory.available: "200Mi"
      nodefs.available: "5%"
      nodefs.inodesFree: "4%"
      imagefs.available: "10%"
      imagefs.inodesFree: "5%"
    evictionPressureTransitionPeriod: 0s


    imageMinimumGCAge: 5m


    imageGCHighThresholdPercent: 80


    imageGCLowThresholdPercent: 75

Copy to Clipboard

Toggle word wrap

1: Nom de l'objet.
2: Spécifiez l'étiquette du pool de configuration de la machine.
3: Type d'expulsion : evictionSoft ou evictionHard.
4: Seuils d'expulsion basés sur un signal de déclenchement d'expulsion spécifique.
5: Délais de grâce pour l'expulsion douce. Ce paramètre ne s'applique pas à eviction-hard.
6: Seuils d'éviction basés sur un signal de déclenchement d'éviction spécifique. Pour evictionHard, vous devez spécifier tous ces paramètres. Si vous ne les spécifiez pas tous, seuls les paramètres spécifiés seront appliqués et le ramassage des ordures ne fonctionnera pas correctement.
7: Durée d'attente avant de sortir d'une condition de pression d'expulsion.
8: L'âge minimum d'une image inutilisée avant qu'elle ne soit supprimée par le ramasse-miettes.
9: Pourcentage d'utilisation du disque (exprimé sous forme d'un nombre entier) qui déclenche le ramassage des images.
10: Pourcentage de l'utilisation du disque (exprimé sous forme d'un entier) que le système de collecte des images tente de libérer.

Exécutez la commande suivante pour créer le CR :

oc create -f <nom_du_fichier>.yaml

oc create -f <nom_du_fichier>.yaml

Copy to Clipboard

Toggle word wrap

Par exemple :

oc create -f gc-container.yaml

$ oc create -f gc-container.yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

kubeletconfig.machineconfiguration.openshift.io/gc-container created

kubeletconfig.machineconfiguration.openshift.io/gc-container created

Copy to Clipboard

Toggle word wrap

Vérification

Vérifiez que le ramassage des ordures est actif en entrant la commande suivante. Le pool de configuration de la machine que vous avez spécifié dans la ressource personnalisée apparaît avec UPDATING comme 'true' jusqu'à ce que le changement soit complètement implémenté :

oc get machineconfigpool

$ oc get machineconfigpool

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME     CONFIG                                   UPDATED   UPDATING
master   rendered-master-546383f80705bd5aeaba93   True      False
worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False     True

NAME     CONFIG                                   UPDATED   UPDATING
master   rendered-master-546383f80705bd5aeaba93   True      False
worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False     True

Copy to Clipboard

Toggle word wrap

5.9. Allocation de ressources pour les nœuds d'un cluster OpenShift Container Platform
Copier lien

Pour assurer une planification plus fiable et minimiser le surengagement des ressources du nœud, réservez une partie des ressources CPU et mémoire aux composants sous-jacents du nœud, tels que kubelet et kube-proxy, et aux autres composants du système, tels que sshd et NetworkManager. En spécifiant les ressources à réserver, vous fournissez au planificateur davantage d'informations sur les ressources de CPU et de mémoire restantes qu'un nœud peut utiliser pour les pods. Vous pouvez permettre à OpenShift Container Platform de déterminer automatiquement les ressources optimales de mémoire et de CPU system-reserved pour vos nœuds ou vous pouvez déterminer et définir manuellement les meilleures ressources pour vos nœuds.

Important

Pour définir manuellement les valeurs des ressources, vous devez utiliser un CR de configuration de kubelet. Vous ne pouvez pas utiliser un CR de configuration de machine.

5.9.1. Comprendre comment allouer des ressources aux nœuds
Copier lien

Les ressources de CPU et de mémoire réservées aux composants de nœuds dans OpenShift Container Platform sont basées sur deux paramètres de nœuds :

Expand

Paramètres	Description
`kube-reserved`	Ce paramètre n'est pas utilisé avec OpenShift Container Platform. Ajoutez les ressources CPU et mémoire que vous avez prévu de réserver au paramètre `system-reserved`.
`system-reserved`	Ce paramètre identifie les ressources à réserver pour les composants du nœud et les composants du système, tels que CRI-O et Kubelet. Les paramètres par défaut dépendent des versions d'OpenShift Container Platform et de Machine Config Operator. Confirmez le paramètre par défaut `systemReserved` sur le référentiel `machine-config-operator`.

Si un indicateur n'est pas défini, les valeurs par défaut sont utilisées. Si aucun indicateur n'est défini, la ressource allouée correspond à la capacité du nœud telle qu'elle était avant l'introduction des ressources allouables.

Note

Les unités centrales spécifiquement réservées à l'aide du paramètre reservedSystemCPUs ne sont pas disponibles pour une allocation à l'aide des paramètres kube-reserved ou system-reserved.

5.9.1.1. Comment OpenShift Container Platform calcule les ressources allouées
Copier lien

La quantité allouée d'une ressource est calculée sur la base de la formule suivante :

[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]

[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]

Copy to Clipboard

Toggle word wrap

Note

L'exclusion de Hard-Eviction-Thresholds de Allocatable améliore la fiabilité du système car la valeur de Allocatable est appliquée aux pods au niveau du nœud.

Si Allocatable est négatif, il est fixé à 0.

Chaque nœud indique les ressources système utilisées par l'exécution du conteneur et le kubelet. Pour simplifier la configuration du paramètre system-reserved, affichez l'utilisation des ressources pour le nœud en utilisant l'API de résumé du nœud. Le résumé du nœud est disponible à l'adresse /api/v1/nodes/<node>/proxy/stats/summary.

5.9.1.2. Comment les nœuds appliquent les contraintes de ressources
Copier lien

Le nœud peut limiter la quantité totale de ressources que les modules peuvent consommer en fonction de la valeur d'allocation configurée. Cette fonction améliore considérablement la fiabilité du nœud en empêchant les modules d'utiliser les ressources de CPU et de mémoire dont ont besoin les services système tels que le moteur d'exécution du conteneur et l'agent du nœud. Pour améliorer la fiabilité du nœud, les administrateurs doivent réserver des ressources en fonction d'un objectif d'utilisation des ressources.

Le nœud impose des contraintes de ressources en utilisant une nouvelle hiérarchie de cgroupes qui assure la qualité du service. Tous les pods sont lancés dans une hiérarchie de cgroup dédiée, séparée des démons du système.

Les administrateurs doivent traiter les démons système de la même manière que les pods qui ont une qualité de service garantie. Les démons système peuvent éclater au sein de leurs groupes de contrôle et ce comportement doit être géré dans le cadre des déploiements de clusters. Réservez des ressources de CPU et de mémoire aux démons système en spécifiant la quantité de ressources de CPU et de mémoire dans system-reserved.

L'application des limites de system-reserved peut empêcher les services système critiques de recevoir des ressources de CPU et de mémoire. Par conséquent, un service système critique peut être interrompu par le "out-of-memory killer". Il est recommandé d'appliquer system-reserved uniquement si vous avez profilé les nœuds de manière exhaustive afin de déterminer des estimations précises et si vous êtes certain que les services système critiques peuvent se rétablir si l'un des processus de ce groupe est interrompu par le tueur de mémoire.

5.9.1.3. Comprendre les seuils d'expulsion
Copier lien

Si un nœud subit une pression de mémoire, cela peut avoir un impact sur l'ensemble du nœud et sur tous les pods s'exécutant sur le nœud. Par exemple, un démon système qui utilise plus que la quantité de mémoire qui lui est réservée peut déclencher un événement de sortie de mémoire. Pour éviter ou réduire la probabilité d'événements de sortie de mémoire du système, le nœud fournit une gestion des ressources manquantes.

Vous pouvez réserver de la mémoire en utilisant l'option --eviction-hard. Le nœud tente d'expulser les modules chaque fois que la disponibilité de la mémoire sur le nœud tombe en dessous de la valeur absolue ou du pourcentage. Si les démons système n'existent pas sur un nœud, les modules sont limités à la mémoire capacity - eviction-hard. Pour cette raison, les ressources mises de côté en tant que tampon pour l'expulsion avant d'atteindre les conditions d'épuisement de la mémoire ne sont pas disponibles pour les modules.

L'exemple suivant illustre l'impact du nœud allouable pour la mémoire :

La capacité des nœuds est de 32Gi
--réservé au système est 3Gi
--eviction-hard est fixé à 100Mi.

Pour ce nœud, la valeur allouable effective du nœud est 28.9Gi. Si le nœud et les composants du système utilisent toutes leurs réservations, la mémoire disponible pour les pods est 28.9Gi, et le kubelet évince les pods lorsqu'elle dépasse ce seuil.

Si vous imposez l'allocation de nœuds, 28.9Gi, avec des cgroups de premier niveau, les pods ne peuvent jamais dépasser 28.9Gi. Les expulsions ne sont pas effectuées à moins que les démons du système ne consomment plus de 3.1Gi de mémoire.

Si les démons du système n'utilisent pas toute leur réservation, dans l'exemple ci-dessus, les pods devraient faire face à des destructions OOM memcg de leur cgroup limitant avant que les évictions de nœuds ne démarrent. Pour mieux appliquer la QoS dans cette situation, le nœud applique les seuils d'éviction durs au cgroup de niveau supérieur pour tous les pods devant être Node Allocatable Eviction Hard Thresholds.

Si les démons du système n'utilisent pas toute leur réserve, le nœud expulse les modules dès qu'ils consomment plus de 28.9Gi de mémoire. Si l'éviction n'a pas lieu à temps, un pod sera tué par OOM si les pods consomment 29Gi de mémoire.

5.9.1.4. Comment l'ordonnanceur détermine la disponibilité des ressources
Copier lien

L'ordonnanceur utilise la valeur de node.Status.Allocatable au lieu de node.Status.Capacity pour décider si un nœud sera candidat à l'ordonnancement de pods.

Par défaut, le nœud indique que la capacité de sa machine est entièrement planifiable par le cluster.

5.9.2. Attribution automatique de ressources aux nœuds
Copier lien

OpenShift Container Platform peut déterminer automatiquement les ressources optimales system-reserved CPU et mémoire pour les nœuds associés à un pool de configuration machine spécifique et mettre à jour les nœuds avec ces valeurs lorsque les nœuds démarrent. Par défaut, le CPU de system-reserved est 500m et la mémoire de system-reserved est 1Gi.

Pour déterminer et allouer automatiquement les ressources system-reserved sur les nœuds, créez une ressource personnalisée (CR) KubeletConfig pour définir le paramètre autoSizingReserved: true. Un script sur chaque nœud calcule les valeurs optimales pour les ressources réservées respectives sur la base de la capacité de CPU et de mémoire installée sur chaque nœud. Le script tient compte du fait qu'une augmentation de la capacité nécessite une augmentation correspondante des ressources réservées.

La détermination automatique des paramètres system-reserved optimaux garantit l'efficacité de votre cluster et prévient les défaillances de nœuds dues à la pénurie de ressources des composants du système, tels que CRI-O et kubelet, sans que vous ayez besoin de calculer et de mettre à jour manuellement les valeurs.

Cette fonction est désactivée par défaut.

Conditions préalables

Obtenez l'étiquette associée à l'objet statique MachineConfigPool pour le type de nœud que vous souhaitez configurer en entrant la commande suivante :

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc edit machineconfigpool worker

$ oc edit machineconfigpool worker

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: "" 
  name: worker
 ...

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: ""


  name: worker
 ...

Copy to Clipboard

Toggle word wrap

1: L'étiquette apparaît sous Labels.

Astuce

Si l'étiquette n'est pas présente, ajoutez une paire clé/valeur comme par exemple :

oc label machineconfigpool worker custom-kubelet=small-pods

$ oc label machineconfigpool worker custom-kubelet=small-pods

Copy to Clipboard

Toggle word wrap

Procédure

Créez une ressource personnalisée (CR) pour votre changement de configuration :
Exemple de configuration pour un CR d'allocation de ressources
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: dynamic-node 
spec:
  autoSizingReserved: true 
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
```
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: dynamic-node 
```
1
```
spec:
  autoSizingReserved: true 
```
2
```
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
```
3
Copy to Clipboard Toggle word wrap
1
Attribuer un nom au CR.
2
Ajoutez le paramètre autoSizingReserved défini sur true pour permettre à OpenShift Container Platform de déterminer et d'allouer automatiquement les ressources system-reserved sur les nœuds associés à l'étiquette spécifiée. Pour désactiver l'allocation automatique sur ces nœuds, définissez ce paramètre à false.
3
Spécifiez l'étiquette du pool de configuration de la machine.
L'exemple précédent active l'allocation automatique des ressources sur tous les nœuds de travail. OpenShift Container Platform draine les nœuds, applique la configuration kubelet et redémarre les nœuds.
Créez le CR en entrant la commande suivante :
```
oc create -f <nom_du_fichier>.yaml
```
```
oc create -f <nom_du_fichier>.yaml
```
Copy to Clipboard Toggle word wrap

Vérification

Connectez-vous à un nœud que vous avez configuré en entrant la commande suivante :
```
oc debug node/<node_name>
```
```
oc debug node/<node_name>
```
Copy to Clipboard Toggle word wrap
Définir /host comme répertoire racine dans l'interpréteur de commandes de débogage :
```
chroot /host
```
```
# chroot /host
```
Copy to Clipboard Toggle word wrap
Consulter le fichier /etc/node-sizing.env:
Exemple de sortie
```
SYSTEM_RESERVED_MEMORY=3Gi
SYSTEM_RESERVED_CPU=0.08
```
```
SYSTEM_RESERVED_MEMORY=3Gi
SYSTEM_RESERVED_CPU=0.08
```
Copy to Clipboard Toggle word wrap
Le kubelet utilise les valeurs de system-reserved dans le fichier /etc/node-sizing.env. Dans l'exemple précédent, les nœuds de travail se voient attribuer 0.08 CPU et 3 Gi de mémoire. L'apparition des valeurs optimales peut prendre plusieurs minutes.

5.9.3. Attribution manuelle de ressources aux nœuds
Copier lien

OpenShift Container Platform prend en charge les types de ressources CPU et mémoire pour l'allocation. Le type de ressource ephemeral-resource est également pris en charge. Pour le type cpu, vous spécifiez la quantité de ressources en unités de cœurs, telles que 200m, 0.5, ou 1. Pour memory et ephemeral-storage, vous spécifiez la quantité de ressources en unités d'octets, comme 200Ki, 50Mi ou 5Gi. Par défaut, l'unité centrale system-reserved est 500m et la mémoire system-reserved est 1Gi.

En tant qu'administrateur, vous pouvez définir ces valeurs en utilisant une ressource personnalisée (CR) de configuration kubelet par le biais d'un ensemble de paires <resource_type>=<resource_quantity> (par exemple, cpu=200m,memory=512Mi).

Important

Vous devez utiliser un CR de configuration de kubelet pour définir manuellement les valeurs des ressources. Vous ne pouvez pas utiliser un CR de configuration de machine.

Pour plus de détails sur les valeurs recommandées pour system-reserved, voir les valeurs recommandées pour les réserves du système.

Conditions préalables

Obtenez l'étiquette associée au CRD statique MachineConfigPool pour le type de nœud que vous souhaitez configurer en entrant la commande suivante :

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc edit machineconfigpool worker

$ oc edit machineconfigpool worker

Copy to Clipboard

Toggle word wrap

Exemple de sortie

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: "" 
  name: worker

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2022-11-16T15:34:25Z"
  generation: 4
  labels:
    pools.operator.machineconfiguration.openshift.io/worker: ""


  name: worker

Copy to Clipboard

Toggle word wrap

1: L'étiquette apparaît sous Étiquettes.

Astuce

Si l'étiquette n'est pas présente, ajoutez une paire clé/valeur comme par exemple :

oc label machineconfigpool worker custom-kubelet=small-pods

$ oc label machineconfigpool worker custom-kubelet=small-pods

Copy to Clipboard

Toggle word wrap

Procédure

Créez une ressource personnalisée (CR) pour votre changement de configuration.

Exemple de configuration pour un CR d'allocation de ressources

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-allocatable 
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 
  kubeletConfig:
    systemReserved: 
      cpu: 1000m
      memory: 1Gi

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-allocatable


spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""


  kubeletConfig:
    systemReserved:


      cpu: 1000m
      memory: 1Gi

Copy to Clipboard

Toggle word wrap

1: Attribuer un nom au CR.
2: Spécifiez l'étiquette du pool de configuration de la machine.
3: Spécifiez les ressources à réserver pour les composants du nœud et du système.

Exécutez la commande suivante pour créer le CR :
```
oc create -f <nom_du_fichier>.yaml
```
```
oc create -f <nom_du_fichier>.yaml
```
Copy to Clipboard Toggle word wrap

5.10. Attribution d'unités centrales spécifiques aux nœuds d'un cluster
Copier lien

Lorsque vous utilisez la stratégie statique du gestionnaire de CPU, vous pouvez réserver des CPU spécifiques à l'usage de nœuds spécifiques dans votre cluster. Par exemple, sur un système doté de 24 CPU, vous pouvez réserver les CPU numérotés de 0 à 3 pour le plan de contrôle, ce qui permet aux nœuds de calcul d'utiliser les CPU 4 à 23.

5.10.1. Réserver des CPU pour les nœuds
Copier lien

Pour définir explicitement une liste d'unités centrales réservées à des nœuds spécifiques, créez une ressource personnalisée (CR) KubeletConfig pour définir le paramètre reservedSystemCPUs. Cette liste remplace les unités centrales qui peuvent être réservées à l'aide des paramètres systemReserved et kubeReserved.

Procédure

Obtenez l'étiquette associée au pool de configuration de la machine (MCP) pour le type de nœud que vous souhaitez configurer :

oc describe machineconfigpool <name> $ oc describe machineconfigpool <name>

oc describe machineconfigpool <name> $ oc describe machineconfigpool <name>

Copy to Clipboard

Toggle word wrap

Par exemple :

oc describe machineconfigpool worker

$ oc describe machineconfigpool worker

Copy to Clipboard

Toggle word wrap

Exemple de sortie

Name:         worker
Namespace:
Labels:       machineconfiguration.openshift.io/mco-built-in=
              pools.operator.machineconfiguration.openshift.io/worker= 
Annotations:  <none>
API Version:  machineconfiguration.openshift.io/v1
Kind:         MachineConfigPool
...

Name:         worker
Namespace:
Labels:       machineconfiguration.openshift.io/mco-built-in=
              pools.operator.machineconfiguration.openshift.io/worker=


Annotations:  <none>
API Version:  machineconfiguration.openshift.io/v1
Kind:         MachineConfigPool
...

Copy to Clipboard

Toggle word wrap

1: Obtenir le label MCP.

Créer un fichier YAML pour le CR KubeletConfig:

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-reserved-cpus 
spec:
  kubeletConfig:
    reservedSystemCPUs: "0,1,2,3" 
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-reserved-cpus


spec:
  kubeletConfig:
    reservedSystemCPUs: "0,1,2,3"


  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""

Copy to Clipboard

Toggle word wrap

1: Spécifiez un nom pour le CR.
2: Spécifiez les ID de cœur des CPU que vous souhaitez réserver pour les nœuds associés au MCP.
3: Spécifier l'étiquette à partir du MCP.

Créer l'objet CR :
```
oc create -f <nom_du_fichier>.yaml
```
```
oc create -f <nom_du_fichier>.yaml
```
Copy to Clipboard Toggle word wrap

5.11. Activation des profils de sécurité TLS pour le kubelet
Copier lien

Vous pouvez utiliser un profil de sécurité TLS (Transport Layer Security) pour définir les codes TLS requis par le kubelet lorsqu'il agit en tant que serveur HTTP. Le kubelet utilise son serveur HTTP/GRPC pour communiquer avec le serveur API Kubernetes, qui envoie des commandes aux pods, collecte des journaux et exécute des commandes exec sur les pods par l'intermédiaire du kubelet.

Un profil de sécurité TLS définit les algorithmes de chiffrement TLS que le serveur API Kubernetes doit utiliser lors de la connexion avec le kubelet pour protéger la communication entre le kubelet et le serveur API Kubernetes.

Note

Par défaut, lorsque le kubelet agit en tant que client avec le serveur API de Kubernetes, il négocie automatiquement les paramètres TLS avec le serveur API.

5.11.1. Comprendre les profils de sécurité TLS
Copier lien

Vous pouvez utiliser un profil de sécurité TLS (Transport Layer Security) pour définir les algorithmes TLS requis par les différents composants d'OpenShift Container Platform. Les profils de sécurité TLS d'OpenShift Container Platform sont basés sur les configurations recommandées par Mozilla.

Vous pouvez spécifier l'un des profils de sécurité TLS suivants pour chaque composant :

Expand

Tableau 5.4. Profils de sécurité TLS
Profile	Description
`Old`	Ce profil est destiné à être utilisé avec des clients ou des bibliothèques anciens. Il est basé sur l'ancienne configuration recommandée pour la rétrocompatibilité. Le profil `Old` nécessite une version TLS minimale de 1.0. Note Pour le contrôleur d'entrée, la version minimale de TLS passe de 1.0 à 1.1.
`Intermediate`	Ce profil est la configuration recommandée pour la majorité des clients. Il s'agit du profil de sécurité TLS par défaut pour le contrôleur d'entrée, le kubelet et le plan de contrôle. Le profil est basé sur la configuration recommandée pour la compatibilité intermédiaire. Le profil `Intermediate` nécessite une version TLS minimale de 1.2.
`Modern`	Ce profil est destiné à être utilisé avec des clients modernes qui n'ont pas besoin de rétrocompatibilité. Ce profil est basé sur la configuration recommandée pour la compatibilité moderne. Le profil `Modern` nécessite une version TLS minimale de 1.3.
`Custom`	Ce profil permet de définir la version de TLS et les algorithmes de chiffrement à utiliser. Avertissement Soyez prudent lorsque vous utilisez un profil `Custom`, car des configurations non valides peuvent causer des problèmes.

Note

Lorsque l'on utilise l'un des types de profil prédéfinis, la configuration effective du profil est susceptible d'être modifiée entre les versions. Par exemple, si l'on spécifie l'utilisation du profil intermédiaire déployé dans la version X.Y.Z, une mise à niveau vers la version X.Y.Z 1 peut entraîner l'application d'une nouvelle configuration de profil, ce qui se traduit par un déploiement.

5.11.2. Configuration du profil de sécurité TLS pour le kubelet
Copier lien

Pour configurer un profil de sécurité TLS pour le kubelet lorsqu'il agit en tant que serveur HTTP, créez une ressource personnalisée (CR) KubeletConfig pour spécifier un profil de sécurité TLS prédéfini ou personnalisé pour des nœuds spécifiques. Si aucun profil de sécurité TLS n'est configuré, le profil de sécurité TLS par défaut est Intermediate.

Exemple de CR KubeletConfig qui configure le profil de sécurité TLS Old sur les nœuds de travail

apiVersion: config.openshift.io/v1
kind: KubeletConfig
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""

apiVersion: config.openshift.io/v1
kind: KubeletConfig
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""

Copy to Clipboard

Toggle word wrap

Vous pouvez voir les codes et la version TLS minimale du profil de sécurité TLS configuré dans le fichier kubelet.conf sur un nœud configuré.

Conditions préalables

Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

Créez un CR KubeletConfig pour configurer le profil de sécurité TLS :

Exemple de CR KubeletConfig pour un profil Custom

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-kubelet-tls-security-profile
spec:
  tlsSecurityProfile:
    type: Custom 
    custom: 
      ciphers: 
      - ECDHE-ECDSA-CHACHA20-POLY1305
      - ECDHE-RSA-CHACHA20-POLY1305
      - ECDHE-RSA-AES128-GCM-SHA256
      - ECDHE-ECDSA-AES128-GCM-SHA256
      minTLSVersion: VersionTLS11
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-kubelet-tls-security-profile
spec:
  tlsSecurityProfile:
    type: Custom


    custom:


      ciphers:


      - ECDHE-ECDSA-CHACHA20-POLY1305
      - ECDHE-RSA-CHACHA20-POLY1305
      - ECDHE-RSA-AES128-GCM-SHA256
      - ECDHE-ECDSA-AES128-GCM-SHA256
      minTLSVersion: VersionTLS11
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""

Copy to Clipboard

Toggle word wrap

Spécifiez le type de profil de sécurité TLS (Old, Intermediate, ou Custom). La valeur par défaut est Intermediate.

Spécifiez le champ approprié pour le type sélectionné :

old: {}
intermediate: {}
custom:

Pour le type custom, spécifiez une liste de chiffrements TLS et la version TLS minimale acceptée.