Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.3. Configuration d’un Red Hat OpenShift Service sur AWS cluster pour les pods

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

En gardant votre cluster efficace, vous pouvez fournir un meilleur environnement à vos développeurs en utilisant des outils tels que ce qu’un pod fait quand il sort, en veillant à ce que le nombre requis de gousses est toujours en cours d’exécution, quand redémarrer les pods conçus pour fonctionner une seule fois, limiter la bande passante disponible aux pods, et comment garder les pods en cours d’exécution pendant les perturbations.

La politique de redémarrage du pod détermine comment Red Hat OpenShift Service sur AWS répond lorsque Containers dans cette sortie de pod. La politique s’applique à tous les conteneurs de cette pod.

Les valeurs possibles sont:

  • Toujours - Tries redémarrant un conteneur sorti avec succès sur la gousse en continu, avec un retard exponentiel de recul (10s, 20s, 40s) plafonné à 5 minutes. La valeur par défaut est Toujours.
  • Les essais reprennent un conteneur échoué sur la gousse avec un retard exponentiel (10s, 20s, 40s) plafonné à 5 minutes.
  • Jamais - n’essayez pas de redémarrer les conteneurs sortis ou échoués sur la gousse. Les gousses échouent immédiatement et sortent.

Après que la gousse est liée à un nœud, la gousse ne sera jamais liée à un autre nœud. Cela signifie qu’un contrôleur est nécessaire pour qu’une gousse puisse survivre à l’échec du nœud:

Expand
État de l’étatContrôleur typeLa politique de redémarrage

Les pods qui devraient se terminer (tels que les calculs par lots)

Emploi

À l’échec ou jamais

Les pods qui ne devraient pas se terminer (tels que les serveurs Web)

Contrôleur de réplication

C’est toujours ça.

Des gousses qui doivent fonctionner une par machine

Jeu de démon

A) Tout

En cas d’échec d’un conteneur sur un pod et que la politique de redémarrage est définie sur OnFailure, la gousse reste sur le nœud et le conteneur est redémarré. Lorsque vous ne voulez pas que le Conteneur redémarre, utilisez une politique de redémarrage de Never.

En cas d’échec d’un groupe, Red Hat OpenShift Service sur AWS démarre un nouveau pod. Les développeurs doivent aborder la possibilité que les applications puissent être redémarrées dans un nouveau pod. En particulier, les applications doivent gérer des fichiers temporaires, des verrouillages, des sorties incomplètes, etc. causées par des exécutions précédentes.

Note

L’architecture Kubernetes attend des terminaux fiables des fournisseurs de cloud. Lorsqu’un fournisseur de cloud est en panne, le kubelet empêche Red Hat OpenShift Service sur AWS de redémarrer.

Lorsque les points de terminaison des fournisseurs de cloud sous-jacents ne sont pas fiables, n’installez pas un cluster à l’aide de l’intégration des fournisseurs de cloud. Installez le cluster comme s’il était dans un environnement sans cloud. Il n’est pas recommandé d’activer l’intégration d’un fournisseur de cloud sur ou hors d’un cluster installé.

En savoir plus sur la façon dont Red Hat OpenShift Service sur AWS utilise une stratégie de redémarrage avec des conteneurs défaillants, consultez l’exemple des États dans la documentation de Kubernetes.

2.3.2. Limiter la bande passante disponible aux pods
Copier lien

Il est possible d’appliquer une configuration de trafic de qualité de service à un pod et de limiter efficacement sa bande passante disponible. Le trafic d’égress (à partir de la pod) est géré par la police, qui laisse simplement tomber les paquets au-delà du taux configuré. Le trafic d’entrée (vers le pod) est géré en formant des paquets en file d’attente pour gérer efficacement les données. Les limites que vous placez sur une gousse n’affectent pas la bande passante d’autres gousses.

Procédure

Limiter la bande passante sur un pod:

  1. Écrivez un fichier JSON de définition d’objet, et spécifiez la vitesse de trafic de données à l’aide des annotations kubernetes.io/ingress-bandwidth et kubernetes.io/egress-bandwidth. À titre d’exemple, limiter à la fois la bande passante de sortie de pod et la bande passante d’entrée à 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"
        }
    }
}
    Copy to Clipboard Toggle word wrap

  2. Créez le pod à l’aide de la définition d’objet: 

    $ oc create -f <file_or_dir_path>
    Copy to Clipboard Toggle word wrap

Le budget de perturbation des gousses permet de spécifier les contraintes de sécurité sur les gousses pendant les opérations, comme l’évacuation d’un nœud pour l’entretien.

Le PodDisruptionBudget est un objet API qui spécifie le nombre minimum ou le pourcentage de répliques qui doivent être en hausse à la fois. Les configurer dans les projets peut être utile lors de la maintenance des nœuds (comme la mise à l’échelle d’un cluster vers le bas ou une mise à niveau de cluster) et n’est honoré que sur les expulsions volontaires (pas sur les défaillances des nœuds).

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

  • Le sélecteur d’étiquette, qui est une requête d’étiquette sur un ensemble de pods.

  • Le niveau de disponibilité, qui spécifie le nombre minimum de pods qui doivent être disponibles simultanément, soit:

    • le minAvailable est le nombre de gousses doit toujours être disponible, même lors d’une perturbation.
    • le nombre de pods peut être indisponible lors d’une perturbation.
Note

Disponible fait référence au nombre de pods qui ont la condition Ready=True. Ready=True fait référence au pod capable de répondre aux demandes et devrait être ajouté aux pools d’équilibrage de charge de tous les services correspondants.

A maxIndisponible de 0% ou 0 ou un minDisponible de 100% ou égal au nombre de répliques est autorisé mais peut empêcher les nœuds d’être drainés.

Avertissement

Le paramètre par défaut pour maxUnavailable est 1 pour tous les pools de configuration de la machine dans Red Hat OpenShift Service sur AWS. Il est recommandé de ne pas modifier cette valeur et de mettre à jour un nœud de plan de contrôle à la fois. Il ne faut pas changer cette valeur à 3 pour le pool de plan de contrôle.

Il est possible de vérifier les budgets de perturbation des pod pour tous les projets avec ce qui suit: 

$ oc get poddisruptionbudget --all-namespaces
Copy to Clipboard Toggle word wrap
Note

L’exemple suivant contient certaines valeurs spécifiques au service Red Hat OpenShift sur AWS sur AWS.

Exemple de sortie

NAMESPACE                              NAME                                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
openshift-apiserver                    openshift-apiserver-pdb                 N/A             1                 1                     121m
openshift-cloud-controller-manager     aws-cloud-controller-manager            1               N/A               1                     125m
openshift-cloud-credential-operator    pod-identity-webhook                    1               N/A               1                     117m
openshift-cluster-csi-drivers          aws-ebs-csi-driver-controller-pdb       N/A             1                 1                     121m
openshift-cluster-storage-operator     csi-snapshot-controller-pdb             N/A             1                 1                     122m
openshift-cluster-storage-operator     csi-snapshot-webhook-pdb                N/A             1                 1                     122m
openshift-console                      console                                 N/A             1                 1                     116m
#...
Copy to Clipboard Toggle word wrap

Le PodDisruptionBudget est considéré comme sain lorsqu’il y a au moins des gousses disponibles dans le système. Chaque gousse au-dessus de cette limite peut être expulsée.

Note

En fonction des paramètres de priorité et de préemption de votre pod, les pods de priorité inférieure peuvent être supprimés malgré leurs besoins budgétaires de perturbation de la pod.

Il est possible d’utiliser un objet PodDisruptionBudget pour spécifier le nombre minimum ou le pourcentage de répliques qui doivent être en hausse à la fois.

Procédure

Configurer un budget de perturbation de pod:

  1. Créez un fichier YAML avec la définition d’un objet similaire à ce qui suit: 

    apiVersion: policy/v1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
    2 
    
  selector:
    3 
    
    matchLabels:
      name: my-pod
    Copy to Clipboard Toggle word wrap
    1
    Le PodDisruptionBudget fait partie du groupe policy/v1 API.
    2
    Le nombre minimum de gousses qui doivent être disponibles simultanément. Il peut s’agir d’un entier ou d’une chaîne spécifiant un pourcentage, par exemple 20%.
    3
    Il s’agit d’une requête d’étiquette sur un ensemble de ressources. Le résultat de matchLabels et matchExpressions sont logiquement associés. Laissez ce paramètre vide, par exemple sélecteur {}, pour sélectionner tous les pods dans le projet.

    A) ou: 

    apiVersion: policy/v1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25%
    2 
    
  selector:
    3 
    
    matchLabels:
      name: my-pod
    Copy to Clipboard Toggle word wrap
    1
    Le PodDisruptionBudget fait partie du groupe policy/v1 API.
    2
    Le nombre maximum de gousses qui peuvent être indisponibles simultanément. Il peut s’agir d’un entier ou d’une chaîne spécifiant un pourcentage, par exemple 20%.
    3
    Il s’agit d’une requête d’étiquette sur un ensemble de ressources. Le résultat de matchLabels et matchExpressions sont logiquement associés. Laissez ce paramètre vide, par exemple sélecteur {}, pour sélectionner tous les pods dans le projet.

  2. Exécutez la commande suivante pour ajouter l’objet au projet: 

    $ oc create -f </path/to/file> -n <project_name>
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat