2.3. Configurer un cluster OpenShift Container Platform pour les pods

En tant qu'administrateur, vous pouvez créer et maintenir un cluster efficace pour les pods.

En veillant à l'efficacité de votre cluster, vous pouvez fournir un meilleur environnement à vos développeurs en utilisant des outils tels que ce que fait un pod lorsqu'il quitte, en veillant à ce que le nombre requis de pods soit toujours en cours d'exécution, quand redémarrer les pods conçus pour ne fonctionner qu'une seule fois, limiter la bande passante disponible pour les pods et comment maintenir les pods en cours d'exécution pendant les perturbations.

2.3.1. Configurer le comportement des pods après le redémarrage

Une politique de redémarrage de pod détermine comment OpenShift Container Platform réagit lorsque les conteneurs de ce pod quittent le pod. La politique s'applique à tous les conteneurs de ce pod.

Les valeurs possibles sont les suivantes :

Always - Tente de redémarrer un conteneur quitté avec succès sur le pod en continu, avec un délai exponentiel (10s, 20s, 40s) plafonné à 5 minutes. La valeur par défaut est Always.
OnFailure - Tente de redémarrer un conteneur défaillant sur le pod avec un délai exponentiel (10s, 20s, 40s) plafonné à 5 minutes.
Never - N'essaie pas de redémarrer les conteneurs qui sont sortis ou qui ont échoué sur le pod. Les pods échouent immédiatement et quittent le système.

Une fois que le module est lié à un nœud, il ne sera jamais lié à un autre nœud. Cela signifie qu'un contrôleur est nécessaire pour qu'un module puisse survivre à la défaillance d'un nœud :

Condition	Type de contrôleur	Politique de redémarrage
Les pods qui sont censés se terminer (tels que les calculs par lots)	Emploi	`OnFailure` ou `Never`
Les pods qui sont censés ne pas se terminer (tels que les serveurs web)	Contrôleur de réplication	`Always`.
Pods qui doivent fonctionner une fois par machine	Jeu de démons	Tous

Si un conteneur sur un pod échoue et que la politique de redémarrage est définie sur OnFailure, le pod reste sur le nœud et le conteneur est redémarré. Si vous ne souhaitez pas que le conteneur redémarre, utilisez la stratégie de redémarrage Never.

Si un pod entier tombe en panne, OpenShift Container Platform démarre un nouveau pod. Les développeurs doivent prendre en compte la possibilité que les applications soient redémarrées dans un nouveau pod. En particulier, les applications doivent gérer les fichiers temporaires, les verrous, les résultats incomplets, etc. causés par les exécutions précédentes.

Note

L'architecture Kubernetes attend des points d'extrémité fiables de la part des fournisseurs de cloud. Lorsqu'un fournisseur de cloud est en panne, le kubelet empêche OpenShift Container Platform de redémarrer.

Si les points d'extrémité du fournisseur de cloud sous-jacent ne sont pas fiables, n'installez pas un cluster en utilisant l'intégration du fournisseur de cloud. Installez le cluster comme s'il était dans un environnement sans nuage. Il n'est pas recommandé d'activer ou de désactiver l'intégration des fournisseurs de cloud dans un cluster installé.

Pour plus de détails sur la façon dont OpenShift Container Platform utilise la politique de redémarrage avec les conteneurs défaillants, voir les États d'exemple dans la documentation Kubernetes.

2.3.2. Limiter la bande passante disponible pour les pods

Vous pouvez appliquer la mise en forme du trafic de qualité de service à un pod et limiter efficacement sa bande passante disponible. Le trafic sortant (du pod) est géré par la police, qui laisse simplement tomber les paquets dépassant le taux configuré. Le trafic entrant (vers le module) est géré par la mise en forme des paquets en file d'attente afin de traiter efficacement les données. Les limites que vous imposez à un module n'affectent pas la bande passante des autres modules.

Procédure

Pour limiter la bande passante sur un pod :

Rédigez un fichier JSON de définition d'objet et spécifiez la vitesse de circulation des données à l'aide des annotations kubernetes.io/ingress-bandwidth et kubernetes.io/egress-bandwidth. Par exemple, pour limiter la bande passante de sortie et d'entrée des pods à 10M/s :

Définition limitée de l'objet Pod

{
    "kind": "Pod",
    "spec": {
        "containers": [
            {
                "image": "openshift/hello-openshift",
                "name": "hello-openshift"
            }
        ]
    },
    "apiVersion": "v1",
    "metadata": {
        "name": "iperf-slow",
        "annotations": {
            "kubernetes.io/ingress-bandwidth": "10M",
            "kubernetes.io/egress-bandwidth": "10M"
        }
    }
}

Créer le pod à l'aide de la définition de l'objet :
```
oc create -f <file_ou_dir_path>
```

2.3.3. Comprendre comment utiliser les budgets de perturbation des pods pour spécifier le nombre de pods qui doivent être opérationnels

Un pod disruption budget fait partie de l'API Kubernetes, qui peut être géré avec des commandes oc comme d'autres types d'objets. Ils permettent de spécifier des contraintes de sécurité sur les pods pendant les opérations, comme la vidange d'un nœud pour la maintenance.

PodDisruptionBudget est un objet API qui spécifie le nombre ou le pourcentage minimum de répliques qui doivent être en service à un moment donné. La définition de ces valeurs dans les projets peut être utile lors de la maintenance des nœuds (par exemple, lors de la réduction ou de la mise à niveau d'un cluster) et n'est honorée qu'en cas d'éviction volontaire (et non en cas de défaillance d'un nœud).

La configuration d'un objet PodDisruptionBudget se compose des éléments clés suivants :

Un sélecteur d'étiquettes, qui est une requête d'étiquettes sur un ensemble de pods.
Un niveau de disponibilité, qui spécifie le nombre minimum de pods qui doivent être disponibles simultanément, soit :
- minAvailable est le nombre de pods qui doivent toujours être disponibles, même en cas d'interruption.
- maxUnavailable est le nombre de pods qui peuvent être indisponibles lors d'une perturbation.

Note

Available fait référence au nombre de pods qui ont la condition Ready=True. Ready=True fait référence au pod qui est capable de servir les requêtes et qui devrait être ajouté aux pools d'équilibrage de charge de tous les services correspondants.

Un maxUnavailable de 0% ou 0 ou un minAvailable de 100% ou égal au nombre de répliques est autorisé mais peut bloquer la vidange des nœuds.

Vous pouvez vérifier les budgets de perturbation des pods dans tous les projets en procédant comme suit :

$ oc get poddisruptionbudget --all-namespaces

Exemple de sortie

NAMESPACE         NAME          MIN-AVAILABLE   SELECTOR
another-project   another-pdb   4               bar=foo
test-project      my-pdb        2               foo=bar

Le site PodDisruptionBudget est considéré comme sain lorsqu'il y a au moins minAvailable pods en cours d'exécution dans le système. Chaque pod dépassant cette limite peut être expulsé.

Note

En fonction des paramètres de priorité et de préemption des pods, les pods de moindre priorité peuvent être supprimés en dépit de leurs exigences en matière de budget de perturbation des pods.

2.3.3.1. Spécification du nombre de pods qui doivent être opérationnels avec des budgets de perturbation de pods

Vous pouvez utiliser un objet PodDisruptionBudget pour spécifier le nombre ou le pourcentage minimum de répliques qui doivent être opérationnelles à un moment donné.

Procédure

Pour configurer un budget de perturbation de pods :

Créez un fichier YAML avec une définition d'objet similaire à la suivante :
```
apiVersion: policy/v1 1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2  2
  selector:  3
    matchLabels:
      foo: bar
```
1
PodDisruptionBudget fait partie du groupe policy/v1 API.
2
Le nombre minimum de pods qui doivent être disponibles simultanément. Il peut s'agir d'un nombre entier ou d'une chaîne de caractères spécifiant un pourcentage, par exemple 20%.
3
Une requête d'étiquette sur un ensemble de ressources. Les résultats de matchLabels et matchExpressions sont logiquement joints. Laissez ce paramètre vide, par exemple selector {}, pour sélectionner tous les pods du projet.
Ou bien :
```
apiVersion: policy/v1 1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25% 2
  selector: 3
    matchLabels:
      foo: bar
```
1
PodDisruptionBudget fait partie du groupe policy/v1 API.
2
Le nombre maximum de pods qui peuvent être indisponibles simultanément. Il peut s'agir d'un nombre entier ou d'une chaîne de caractères spécifiant un pourcentage, par exemple 20%.
3
Une requête d'étiquette sur un ensemble de ressources. Les résultats de matchLabels et matchExpressions sont logiquement joints. Laissez ce paramètre vide, par exemple selector {}, pour sélectionner tous les pods du projet.
Exécutez la commande suivante pour ajouter l'objet au projet :
```
$ oc create -f </path/to/file> -n <project_name>
```

2.3.4. Prévenir l'enlèvement des nacelles à l'aide de nacelles critiques

Un certain nombre de composants essentiels au bon fonctionnement d'une grappe sont exécutés sur un nœud ordinaire de la grappe plutôt que sur le nœud principal. Un cluster peut cesser de fonctionner correctement si un add-on critique est expulsé.

Les pods marqués comme critiques ne sont pas autorisés à être expulsés.

Procédure

Rendre une nacelle critique :

Créer un spec Pod ou modifier les pods existants pour inclure la classe de priorité system-cluster-critical:
```
spec:
  template:
    metadata:
      name: critical-pod
    priorityClassName: system-cluster-critical 1
```
1
Classe de priorité par défaut pour les pods qui ne doivent jamais être expulsés d'un nœud.
Vous pouvez également spécifier system-node-critical pour les pods qui sont importants pour le cluster mais qui peuvent être supprimés si nécessaire.
Créer la capsule :
```
oc create -f <nom-de-fichier>.yaml
```

2.3.5. Réduction des délais d'attente des pods lors de l'utilisation de volumes persistants avec un nombre élevé de fichiers

Si un volume de stockage contient de nombreux fichiers (~1.000.000 ou plus), vous pouvez rencontrer des dépassements de temps de pod.

Cela peut se produire car, lorsque les volumes sont montés, OpenShift Container Platform modifie récursivement la propriété et les permissions du contenu de chaque volume afin de correspondre à l'adresse fsGroup spécifiée dans un pod securityContext. Pour les gros volumes, la vérification et la modification de la propriété et des autorisations peuvent prendre du temps, ce qui entraîne un démarrage très lent du pod.

Vous pouvez réduire ce délai en appliquant l'une des solutions suivantes :

Utilisez une contrainte de contexte de sécurité (SCC) pour ignorer le réétiquetage SELinux d'un volume.
Utilisez le champ fsGroupChangePolicy dans un SCC pour contrôler la façon dont OpenShift Container Platform vérifie et gère la propriété et les permissions pour un volume.
Utiliser une classe d'exécution pour ignorer le réétiquetage SELinux d'un volume.

Pour plus d'informations, voir Lors de l'utilisation de volumes persistants avec un nombre élevé de fichiers dans OpenShift, pourquoi les pods ne démarrent-ils pas ou prennent-ils un temps excessif pour atteindre l'état " Ready " ?

2.3. Configurer un cluster OpenShift Container Platform pour les pods

2.3.1. Configurer le comportement des pods après le redémarrage

2.3.2. Limiter la bande passante disponible pour les pods

2.3.3. Comprendre comment utiliser les budgets de perturbation des pods pour spécifier le nombre de pods qui doivent être opérationnels

2.3.3.1. Spécification du nombre de pods qui doivent être opérationnels avec des budgets de perturbation de pods

2.3.4. Prévenir l'enlèvement des nacelles à l'aide de nacelles critiques

2.3.5. Réduction des délais d'attente des pods lors de l'utilisation de volumes persistants avec un nombre élevé de fichiers

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links