Les nœuds
Le Red Hat OpenShift Service sur AWS Nodes
Résumé
Chapitre 1. Aperçu des nœuds Copier lienLien copié sur presse-papiers!
1.1. À propos des nœuds Copier lienLien copié sur presse-papiers!
Le nœud est une machine virtuelle ou en métal nu dans un cluster Kubernetes. Les nœuds de travail hébergent vos conteneurs d’application, regroupés comme des pods. Les nœuds de plan de contrôle exécutent les services nécessaires pour contrôler le cluster Kubernetes. Dans Red Hat OpenShift Service sur AWS, les nœuds d’avion de contrôle contiennent plus que les services Kubernetes pour gérer le service Red Hat OpenShift sur AWS cluster.
Avoir des nœuds stables et sains dans un cluster est fondamental pour le bon fonctionnement de votre application hébergée. Dans Red Hat OpenShift Service sur AWS, vous pouvez accéder, gérer et surveiller un nœud via l’objet Node représentant le nœud. En utilisant OpenShift CLI (oc) ou la console Web, vous pouvez effectuer les opérations suivantes sur un nœud.
Les composants suivants d’un nœud sont chargés de maintenir le fonctionnement des pods et de fournir l’environnement d’exécution Kubernetes.
- Durée d’exécution du conteneur
- Le temps d’exécution du conteneur est responsable de l’exécution des conteneurs. Kubernetes offre plusieurs temps d’exécution tels que conteneur, cri-o, rktlet et Docker.
- Kubelet
- Kubelet fonctionne sur les nœuds et lit le conteneur se manifeste. Il garantit que les conteneurs définis ont commencé et sont en cours d’exécution. Le processus kubelet maintient l’état de travail et le serveur de nœuds. Kubelet gère les règles du réseau et le transfert de ports. Le kubelet gère les conteneurs créés uniquement par Kubernetes.
- Kube-proxy
- Kube-proxy fonctionne sur tous les nœuds du cluster et maintient le trafic réseau entre les ressources Kubernetes. Kube-proxy garantit que l’environnement de réseautage est isolé et accessible.
- DNS
- Cluster DNS est un serveur DNS qui sert des enregistrements DNS pour les services Kubernetes. Les conteneurs lancés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS.
Lire les opérations
Les opérations de lecture permettent à un administrateur ou à un développeur d’obtenir des informations sur les nœuds dans un Red Hat OpenShift Service sur le cluster AWS.
- Énumérez tous les nœuds d’un cluster.
- Obtenir des informations sur un nœud, tels que l’utilisation de la mémoire et du CPU, la santé, l’état et l’âge.
- Liste des gousses fonctionnant sur un nœud.
Les opérations d’amélioration
Le service OpenShift Red Hat sur AWS vous permet de faire plus que d’accéder et de gérer des nœuds; en tant qu’administrateur, vous pouvez effectuer les tâches suivantes sur les nœuds pour rendre le cluster plus efficace, plus convivial pour les applications et pour fournir un meilleur environnement pour vos développeurs.
- Gérez le réglage au niveau des nœuds pour les applications haute performance qui nécessitent un certain niveau de réglage du noyau à l’aide de l’opérateur de tuning de nœud.
- Exécutez automatiquement des tâches d’arrière-plan sur les nœuds avec les ensembles de démons. Il est possible de créer et d’utiliser des ensembles de démons pour créer un stockage partagé, exécuter un pod de journalisation sur chaque nœud ou déployer un agent de surveillance sur tous les nœuds.
1.2. À propos des pods Copier lienLien copié sur presse-papiers!
La gousse est un ou plusieurs conteneurs déployés ensemble sur un nœud. En tant qu’administrateur de cluster, vous pouvez définir un pod, l’affecter à exécuter sur un nœud sain qui est prêt pour la planification, et gérer. La gousse coule aussi longtemps que les conteneurs sont en cours d’exécution. Il est impossible de modifier un pod une fois qu’il est défini et qu’il est en cours d’exécution. Certaines opérations que vous pouvez effectuer lorsque vous travaillez avec des pods sont:
Lire les opérations
En tant qu’administrateur, vous pouvez obtenir des informations sur les pods dans un projet grâce aux tâches suivantes:
- Liste des pods associés à un projet, y compris des informations telles que le nombre de répliques et de redémarrages, l’état actuel et l’âge.
- Affichez les statistiques d’utilisation des pod telles que CPU, mémoire et consommation de stockage.
Les opérations de gestion
La liste suivante de tâches fournit un aperçu de la façon dont un administrateur peut gérer les pods dans un Red Hat OpenShift Service sur AWS cluster.
Contrôlez la planification des pods en utilisant les fonctionnalités avancées de planification disponibles dans Red Hat OpenShift Service sur AWS:
- Des règles contraignantes telles que l’affinité des pod, l’affinité des nœuds et l’antiaffinité.
- Étiquettes et sélecteurs de nœuds.
- La topologie des pods étend les contraintes.
- Configurez comment les pods se comportent après un redémarrage en utilisant des contrôleurs de pod et des stratégies de redémarrage.
- Limitez à la fois le trafic de sortie et d’entrée sur une gousse.
- Ajoutez et supprimez des volumes vers et depuis n’importe quel objet qui a un modèle de pod. Le volume est un système de fichiers monté disponible pour tous les conteneurs dans un pod. Le stockage de conteneurs est éphémère; vous pouvez utiliser des volumes pour persister les données de conteneur.
Les opérations d’amélioration
Grâce à divers outils et fonctionnalités disponibles dans Red Hat OpenShift Service sur AWS, vous pouvez travailler avec des pods plus facilement et plus efficacement. Les opérations suivantes impliquent l’utilisation de ces outils et fonctionnalités pour mieux gérer les pods.
- Certaines applications ont besoin d’informations sensibles, telles que les mots de passe et les noms d’utilisateur. L’administrateur peut utiliser l’objet Secret pour fournir des données sensibles aux pods à l’aide de l’objet Secret.
1.3. À propos des conteneurs Copier lienLien copié sur presse-papiers!
Le conteneur est l’unité de base d’un service Red Hat OpenShift sur l’application AWS, qui comprend le code d’application emballé avec ses dépendances, ses bibliothèques et ses binaires. Les conteneurs offrent une cohérence entre les environnements et plusieurs cibles de déploiement : serveurs physiques, machines virtuelles (VM) et cloud privé ou public.
Les technologies de conteneurs Linux sont des mécanismes légers pour isoler les processus en cours d’exécution et limiter l’accès aux seules ressources désignées. En tant qu’administrateur, vous pouvez effectuer diverses tâches sur un conteneur Linux, telles que:
- Copiez des fichiers vers et à partir d’un conteneur.
- Autoriser les conteneurs à consommer des objets API.
- Exécutez des commandes à distance dans un conteneur.
- Le transfert de port permet d’accéder aux applications dans un conteneur.
Le service OpenShift Red Hat sur AWS fournit des conteneurs spécialisés appelés conteneurs Init. Les conteneurs init s’exécutent avant les conteneurs de l’application et peuvent contenir des utilitaires ou des scripts de configuration qui ne sont pas présents dans une image d’application. Il est possible d’utiliser un conteneur Init pour effectuer des tâches avant le déploiement du reste d’un pod.
En plus d’effectuer des tâches spécifiques sur les nœuds, les pods et les conteneurs, vous pouvez travailler avec l’ensemble du service OpenShift Red Hat sur AWS cluster pour garder le cluster efficace et les pods d’applications hautement disponibles.
1.4. Glossaire des termes communs pour Red Hat OpenShift Service sur les nœuds AWS Copier lienLien copié sur presse-papiers!
Ce glossaire définit des termes communs qui sont utilisés dans le contenu des nœuds.
- Conteneur
- C’est une image légère et exécutable qui comprend des logiciels et toutes ses dépendances. Les conteneurs virtualisent le système d’exploitation, en conséquence, vous pouvez exécuter des conteneurs n’importe où d’un centre de données à un cloud public ou privé jusqu’à l’ordinateur portable d’un développeur.
- Jeu de démon
- Assure qu’une réplique du pod fonctionne sur les nœuds éligibles dans un service OpenShift Red Hat sur le cluster AWS.
- Egress
- Le processus de partage de données à l’extérieur via le trafic sortant d’un réseau à partir d’un pod.
- collecte des ordures
- Le processus de nettoyage des ressources de cluster, tels que les conteneurs terminés et les images qui ne sont pas référencées par les pods en cours d’exécution.
- Ingress
- Le trafic entrant vers un pod.
- Emploi
- C’est un processus qui s’achève. Le travail crée un ou plusieurs objets pod et veille à ce que les gousses spécifiées soient remplies avec succès.
- Étiquettes
- Il est possible d’utiliser des étiquettes, qui sont des paires clé-valeur, pour organiser et sélectionner des sous-ensembles d’objets, tels qu’un pod.
- Le nœud
- D’une machine ouvrier dans le Red Hat OpenShift Service sur le cluster AWS. Il peut s’agir soit d’une machine virtuelle (VM) soit d’une machine physique.
- Opérateur de Tuning de Node
- Il est possible d’utiliser l’opérateur de réglage des nœuds pour gérer l’accord au niveau des nœuds à l’aide du démon TuneD. Il garantit que les spécifications de réglage personnalisées sont transmises à tous les démons TuneD conteneurisés fonctionnant dans le cluster dans le format que les démons comprennent. Les démons s’exécutent sur tous les nœuds de l’amas, un par nœud.
- Opérateur de dépollution de nœuds automatiques
- L’opérateur fonctionne sur les nœuds de cluster et identifie et redémarre les nœuds qui sont malsains.
- La pod
- Il y a un ou plusieurs conteneurs avec des ressources partagées, telles que des adresses de volume et IP, qui s’exécutent dans votre Red Hat OpenShift Service sur AWS cluster. Le pod est la plus petite unité de calcul définie, déployée et gérée.
- La tolérance
- Indique que le pod est autorisé (mais pas requis) à être programmé sur les nœuds ou les groupes de nœuds avec des taintes correspondantes. Il est possible d’utiliser des tolérances pour permettre au programmeur de programmer des pods avec des taintes correspondantes.
- La tainte
- C’est un objet de base qui comprend une clé, une valeur et un effet. Les taintes et les tolérances travaillent ensemble pour s’assurer que les pods ne sont pas programmés sur des nœuds non pertinents.
Chapitre 2. En travaillant avec des gousses Copier lienLien copié sur presse-papiers!
2.1. En utilisant des gousses Copier lienLien copié sur presse-papiers!
Le pod est un ou plusieurs conteneurs déployés ensemble sur un hôte, et la plus petite unité de calcul pouvant être définie, déployée et gérée.
2.1.1. Comprendre les gousses Copier lienLien copié sur presse-papiers!
Les gousses sont l’équivalent brut d’une instance de machine (physique ou virtuelle) à un conteneur. Chaque pod se voit attribuer sa propre adresse IP interne, possédant ainsi l’ensemble de son espace portuaire, et les conteneurs à l’intérieur des pods peuvent partager leur stockage et leur réseau local.
Les gousses ont un cycle de vie; ils sont définis, puis ils sont assignés à courir sur un nœud, puis ils courent jusqu’à la sortie de leur(s) conteneur(s) ou ils sont retirés pour une autre raison. Les pods, en fonction de la politique et du code de sortie, peuvent être supprimés après la sortie, ou peuvent être conservés pour permettre l’accès aux journaux de leurs conteneurs.
Le Red Hat OpenShift Service sur AWS traite les pods comme en grande partie immuables; les modifications ne peuvent pas être apportées à une définition de pod pendant qu’elle est en cours d’exécution. Le service OpenShift Red Hat sur AWS implémente les modifications en mettant fin à un pod existant et en le recréant avec une configuration modifiée, une image de base ou les deux. Les gousses sont également traitées comme consommables, et ne maintiennent pas l’état lorsqu’elles sont recréées. Les pods doivent donc généralement être gérés par des contrôleurs de niveau supérieur, plutôt que directement par les utilisateurs.
Les gousses nues qui ne sont pas gérées par un contrôleur de réplication ne seront pas reprogrammées lors de la perturbation du nœud.
2.1.2. Exemples de configurations de pod Copier lienLien copié sur presse-papiers!
Le service OpenShift Red Hat sur AWS exploite le concept Kubernetes d’un pod, qui est un ou plusieurs conteneurs déployés ensemble sur un hôte, et la plus petite unité de calcul pouvant être définie, déployée et gérée.
Ce qui suit est une définition d’exemple d’un pod. Il présente de nombreuses caractéristiques des pods, dont la plupart sont discutées dans d’autres sujets et donc brièvement mentionnées ici:
Définition d’objet pod (YAML)
- 1
- Les pods peuvent être "étiquetés" avec une ou plusieurs étiquettes, qui peuvent ensuite être utilisées pour sélectionner et gérer des groupes de pods en une seule opération. Les étiquettes sont stockées au format clé/valeur dans le hachage des métadonnées.
- 2
- Le pod redémarre la politique avec des valeurs possibles Toujours, OnFailure et jamais. La valeur par défaut est Toujours.
- 3
- Le service OpenShift Red Hat sur AWS définit un contexte de sécurité pour les conteneurs qui spécifie s’ils sont autorisés à fonctionner en tant que conteneurs privilégiés, exécutés en tant qu’utilisateur de leur choix, et plus encore. Le contexte par défaut est très restrictif, mais les administrateurs peuvent le modifier au besoin.
- 4
- les conteneurs spécifient un tableau d’une ou plusieurs définitions de conteneurs.
- 5
- Le conteneur spécifie l’endroit où les volumes de stockage externes sont montés à l’intérieur du conteneur.
- 6
- Indiquez les volumes à prévoir pour le pod. Les volumes montent sur le chemin spécifié. Il ne faut pas monter sur la racine du conteneur, /, ou tout chemin qui est le même dans l’hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme les fichiers hôte /dev/pts. Il est sûr de monter l’hôte en utilisant /host.
- 7
- Chaque conteneur dans la gousse est instancié à partir de sa propre image de conteneur.
- 8
- La gousse définit les volumes de stockage qui sont à la disposition de son(s) conteneur(s) à utiliser.
Lorsque vous attachez des volumes persistants qui ont un nombre élevé de fichiers à des pods, ces gousses peuvent échouer ou peuvent prendre beaucoup de temps pour démarrer. Lorsque vous utilisez des volumes persistants avec des nombres de fichiers élevés dans OpenShift, pourquoi les pods ne commencent-ils pas ou prennent-ils trop de temps pour atteindre l’état « Ready »?
Cette définition de pod n’inclut pas les attributs qui sont remplis par Red Hat OpenShift Service sur AWS automatiquement après la création du pod et son cycle de vie commence. La documentation du pod Kubernetes contient des détails sur la fonctionnalité et le but des pods.
2.2. Affichage des gousses Copier lienLien copié sur presse-papiers!
En tant qu’administrateur, vous pouvez voir les pods dans votre cluster et déterminer la santé de ces gousses et de l’ensemble du cluster.
2.2.1. À propos des pods Copier lienLien copié sur presse-papiers!
Le service OpenShift Red Hat sur AWS exploite le concept Kubernetes d’un pod, qui est un ou plusieurs conteneurs déployés ensemble sur un hôte, et la plus petite unité de calcul pouvant être définie, déployée et gérée. Les gousses sont l’équivalent brut d’une instance de machine (physique ou virtuelle) à un conteneur.
Il est possible d’afficher une liste de pods associés à un projet spécifique ou d’afficher des statistiques d’utilisation sur les pods.
2.2.2. Affichage des gousses dans un projet Copier lienLien copié sur presse-papiers!
Il est possible d’afficher une liste de pods associés au projet en cours, y compris le nombre de répliques, l’état actuel, le nombre ou le redémarrage et l’âge du pod.
Procédure
Afficher les pods dans un projet:
Changement au projet:
oc project <project-name>
$ oc project <project-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE console-698d866b78-bnshf 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165m
NAME READY STATUS RESTARTS AGE console-698d866b78-bnshf 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ajoutez les drapeaux -o larges pour afficher l’adresse IP du pod et le nœud où se trouve le pod.
oc get pods -o wide
$ oc get pods -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE console-698d866b78-bnshf 1/1 Running 2 166m 10.128.0.24 ip-10-0-152-71.ec2.internal <none> console-698d866b78-m87pm 1/1 Running 2 166m 10.129.0.23 ip-10-0-173-237.ec2.internal <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE console-698d866b78-bnshf 1/1 Running 2 166m 10.128.0.24 ip-10-0-152-71.ec2.internal <none> console-698d866b78-m87pm 1/1 Running 2 166m 10.129.0.23 ip-10-0-173-237.ec2.internal <none>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.3. Affichage des statistiques d’utilisation des pod Copier lienLien copié sur presse-papiers!
Il est possible d’afficher des statistiques d’utilisation sur les pods, qui fournissent les environnements d’exécution pour les conteneurs. Ces statistiques d’utilisation incluent CPU, mémoire et consommation de stockage.
Conditions préalables
- Il faut avoir l’autorisation de lire des clusters pour afficher les statistiques d’utilisation.
- Les métriques doivent être installées pour afficher les statistiques d’utilisation.
Procédure
Consulter les statistiques d’utilisation:
Exécutez la commande suivante:
oc adm top pods
$ oc adm top pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc adm top pods -n openshift-console
$ oc adm top pods -n openshift-console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME CPU(cores) MEMORY(bytes) console-7f58c69899-q8c8k 0m 22Mi console-7f58c69899-xhbgg 0m 25Mi downloads-594fcccf94-bcxk8 3m 18Mi downloads-594fcccf94-kv4p6 2m 15Mi
NAME CPU(cores) MEMORY(bytes) console-7f58c69899-q8c8k 0m 22Mi console-7f58c69899-xhbgg 0m 25Mi downloads-594fcccf94-bcxk8 3m 18Mi downloads-594fcccf94-kv4p6 2m 15Mi
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour afficher les statistiques d’utilisation des pods avec des étiquettes:
oc adm top pod --selector=''
$ oc adm top pod --selector=''
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il faut choisir le sélecteur (requête d’étiquette) pour filtrer. Appuis =, ==, et !=.
À titre d’exemple:
oc adm top pod --selector='name=my-pod'
$ oc adm top pod --selector='name=my-pod'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.4. Affichage des journaux des ressources Copier lienLien copié sur presse-papiers!
Il est possible d’afficher le journal pour diverses ressources dans OpenShift CLI (oc) et la console Web. Journaux lus à partir de la queue, ou de la fin, du journal.
Conditions préalables
- Accès à l’OpenShift CLI (oc).
La procédure (UI)
Dans le Red Hat OpenShift Service sur la console AWS, accédez à Workloads → Pods ou accédez au pod à travers la ressource que vous souhaitez enquêter.
NoteCertaines ressources, telles que les builds, n’ont pas de pods à interroger directement. Dans de tels cas, vous pouvez localiser le lien Logs sur la page Détails de la ressource.
- Choisissez un projet dans le menu déroulant.
- Cliquez sur le nom du pod que vous souhaitez enquêter.
- Cliquez sur Logs.
La procédure (CLI)
Consultez le journal pour un pod spécifique:
oc logs -f <pod_name> -c <container_name>
$ oc logs -f <pod_name> -c <container_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
-F
- Facultatif : Spécifie que la sortie suit ce qui est écrit dans les journaux.
<pod_name>
- Indique le nom du pod.
<container_name>
- Facultatif: Spécifie le nom d’un conteneur. Lorsqu’une gousse a plus d’un conteneur, vous devez spécifier le nom du conteneur.
À titre d’exemple:
oc logs ruby-58cd97df55-mww7r
$ oc logs ruby-58cd97df55-mww7r
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs -f ruby-57f7f4855b-znl92 -c ruby
$ oc logs -f ruby-57f7f4855b-znl92 -c ruby
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le contenu des fichiers journaux est imprimé.
Consultez le journal pour une ressource spécifique:
oc logs <object_type>/<resource_name>
$ oc logs <object_type>/<resource_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le type de ressource et le nom.
À titre d’exemple:
oc logs deployment/ruby
$ oc logs deployment/ruby
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le contenu des fichiers journaux est imprimé.
2.3. Configuration d’un Red Hat OpenShift Service sur AWS cluster pour les pods Copier lienLien copié sur presse-papiers!
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.
2.3.1. Configuration de la façon dont les pods se comportent après le redémarrage Copier lienLien copié sur presse-papiers!
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:
État de l’état | Contrôleur type | La 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.
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 lienLien copié sur presse-papiers!
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:
É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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod à l’aide de la définition d’objet:
oc create -f <file_or_dir_path>
$ oc create -f <file_or_dir_path>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.3. Comprendre comment utiliser les budgets de perturbation de pod pour spécifier le nombre de pods qui doivent être augmentés Copier lienLien copié sur presse-papiers!
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.
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.
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
$ oc get poddisruptionbudget --all-namespaces
L’exemple suivant contient certaines valeurs spécifiques au service Red Hat OpenShift sur AWS sur AWS.
Exemple de sortie
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.
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.
2.3.3.1. En spécifiant le nombre de pods qui doivent être en hausse avec les budgets de perturbation de pod Copier lienLien copié sur presse-papiers!
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:
Créez un fichier YAML avec la définition d’un objet similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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.
Exécutez la commande suivante pour ajouter l’objet au projet:
oc create -f </path/to/file> -n <project_name>
$ oc create -f </path/to/file> -n <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. Création et utilisation de cartes de configuration Copier lienLien copié sur presse-papiers!
Les sections suivantes définissent les cartes de configuration et comment les créer et les utiliser.
2.5.1. Comprendre les cartes de configuration Copier lienLien copié sur presse-papiers!
De nombreuses applications nécessitent une configuration en utilisant une combinaison de fichiers de configuration, d’arguments de ligne de commande et de variables d’environnement. Dans Red Hat OpenShift Service sur AWS, ces artefacts de configuration sont découplés du contenu de l’image pour garder les applications conteneurisées portables.
L’objet ConfigMap fournit des mécanismes pour injecter des conteneurs avec des données de configuration tout en gardant les conteneurs agnostiques de Red Hat OpenShift Service sur AWS. La carte de configuration peut être utilisée pour stocker des informations fines telles que des propriétés individuelles ou des informations grossières comme des fichiers de configuration entiers ou des blobs JSON.
L’objet ConfigMap contient des paires clés-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. À titre d’exemple:
Définition d’objet de ConfigMap
Lorsque vous créez une carte de configuration à partir d’un fichier binaire, vous pouvez utiliser le champ de données binaires, comme une image.
Les données de configuration peuvent être consommées en pods de diverses manières. La carte de configuration peut être utilisée pour:
- Peupler les valeurs variables d’environnement dans les conteneurs
- Définir les arguments de ligne de commande dans un conteneur
- Populer des fichiers de configuration dans un volume
Les utilisateurs et les composants système peuvent stocker les données de configuration dans une carte de configuration.
La carte de configuration est similaire à un secret, mais conçue pour prendre en charge plus facilement le travail avec des chaînes qui ne contiennent pas d’informations sensibles.
Configuration des restrictions de carte
Il faut créer une carte de configuration avant que son contenu puisse être consommé en pods.
Les contrôleurs peuvent être écrits pour tolérer les données de configuration manquantes. Consultez les composants individuels configurés en utilisant des cartes de configuration au cas par cas.
Les objets ConfigMap résident dans un projet.
Ils ne peuvent être référencés que par des pods dans le même projet.
Le Kubelet ne prend en charge que l’utilisation d’une carte de configuration pour les pods qu’il obtient du serveur API.
Cela inclut tous les pods créés en utilisant le CLI, ou indirectement à partir d’un contrôleur de réplication. Il n’inclut pas les pods créés en utilisant le service Red Hat OpenShift sur le drapeau --manifest-url d’AWS node, son drapeau --config ou son API REST parce que ce ne sont pas des moyens courants de créer des pods.
2.5.2. Création d’une carte de configuration dans le Red Hat OpenShift Service sur la console web AWS Copier lienLien copié sur presse-papiers!
Il est possible de créer une carte de configuration dans le service Red Hat OpenShift sur la console web AWS.
Procédure
Créer une carte de configuration en tant qu’administrateur de cluster:
- Dans la perspective Administrateur, sélectionnez Charges de travail → Config Maps.
- En haut à droite de la page, sélectionnez Créer une carte de configuration.
- Entrez le contenu de votre carte de configuration.
- Choisissez Créer.
Créer une carte de configuration en tant que développeur:
- Dans la perspective Développeur, sélectionnez Config Maps.
- En haut à droite de la page, sélectionnez Créer une carte de configuration.
- Entrez le contenu de votre carte de configuration.
- Choisissez Créer.
2.5.3. Création d’une carte de configuration à l’aide du CLI Copier lienLien copié sur presse-papiers!
La commande suivante permet de créer une carte de configuration à partir d’annuaires, 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]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3.1. Création d’une carte de configuration à partir d’un répertoire Copier lienLien copié sur presse-papiers!
Il est possible de créer une carte de configuration à partir d’un répertoire à l’aide du drapeau --from-file. Cette méthode vous permet d’utiliser plusieurs fichiers dans un répertoire pour créer une carte de configuration.
Chaque fichier dans le 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.
À titre d’exemple, la commande suivante crée une carte de configuration avec le contenu du répertoire example-files:
oc create configmap game-config --from-file=example-files/
$ oc create configmap game-config --from-file=example-files/
Affichez les clés dans la carte de configuration:
oc describe configmaps game-config
$ oc describe configmaps game-config
Exemple de sortie
Les deux touches de la carte sont créées à partir des noms de fichiers dans le répertoire spécifié dans la commande. Le contenu de ces touches peut être grand, de sorte que la sortie d’oc décrit uniquement les noms des clés et leurs tailles.
Conditions préalables
Il faut avoir un répertoire avec des fichiers contenant les données avec lesquelles vous souhaitez remplir une carte de configuration.
La procédure suivante utilise ces exemples de fichiers: game.properties et ui.properties:
cat example-files/game.properties
$ cat example-files/game.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat example-files/ui.properties
$ cat example-files/ui.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow
Procédure
Créer une carte de configuration contenant le contenu de chaque fichier dans 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 Copied! Toggle word wrap Toggle overflow
La vérification
Entrez la commande oc get pour l’objet avec l’option -o pour voir les valeurs des touches:
oc get configmaps game-config -o yaml
$ oc get configmaps game-config -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3.2. Créer une carte de configuration à partir d’un fichier Copier lienLien copié sur presse-papiers!
Il est possible de créer une carte de configuration à partir d’un fichier à l’aide du drapeau --from-file. L’option --from-file peut être transmise plusieurs fois au CLI.
Il est également possible de spécifier la clé à définir dans une carte de configuration pour le contenu importé à partir d’un fichier en passant une expression key=value à l’option --from-file. À titre d’exemple:
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
Lorsque 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. Le service Red Hat OpenShift sur AWS détecte les fichiers binaires et encode de manière transparente le fichier en tant que MIME. Dans le serveur, la charge utile MIME est décodée et stockée sans corrompre les données.
Conditions préalables
Il faut avoir un répertoire avec des fichiers contenant les données avec lesquelles vous souhaitez remplir une carte de configuration.
La procédure suivante utilise ces exemples de fichiers: game.properties et ui.properties:
cat example-files/game.properties
$ cat example-files/game.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat example-files/ui.properties
$ cat example-files/ui.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow
Procédure
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 Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow
La vérification
Entrez la commande oc get pour l’objet avec l’option -o pour voir les valeurs des touches à partir du fichier:
oc get configmaps game-config-2 -o yaml
$ oc get configmaps game-config-2 -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande oc get pour l’objet avec l’option -o pour voir les valeurs des touches à partir de la paire clé-valeur:
oc get configmaps game-config-3 -o yaml
$ oc get configmaps game-config-3 -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- C’est la clé que vous avez définie à l’étape précédente.
2.5.3.3. Création d’une carte de configuration à partir de valeurs littérales Copier lienLien copié sur presse-papiers!
Il est possible de fournir des valeurs littérales pour une carte de configuration.
L’option --from-littérale prend une syntaxe key=valeur, qui permet de fournir des valeurs littérales directement sur la ligne de commande.
Procédure
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 Copied! Toggle word wrap Toggle overflow
La vérification
Entrez la commande oc get pour l’objet avec l’option -o pour voir les valeurs des touches:
oc get configmaps special-config -o yaml
$ oc get configmaps special-config -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.4. Cas d’utilisation: Consommer des cartes de configuration dans des pods Copier lienLien copié sur presse-papiers!
Les sections suivantes décrivent certains cas d’utilisation lors de la consommation d’objets ConfigMap dans des pods.
2.5.4.1. Populer des variables d’environnement dans les conteneurs en utilisant des cartes de configuration Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser des cartes de configuration 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.
À titre d’exemple, considérez la carte de configuration suivante:
ConfigMap avec deux variables d’environnement
ConfigMap avec une variable d’environnement
Procédure
Il est possible de consommer les clés de ce ConfigMap dans un pod à l’aide des sections configMapKeyRef.
Exemple de spécification de Pod configurée pour injecter des variables d’environnement spécifiques
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Il permet d’extraire les variables d’environnement spécifiées à partir d’un ConfigMap.
- 2
- Le nom d’une variable d’environnement de pod dans laquelle vous injectez la valeur d’une clé.
- 3 5
- Le nom du ConfigMap pour tirer des variables d’environnement spécifiques.
- 4 6
- Environnement variable à tirer du ConfigMap.
- 7
- Rend l’environnement variable optionnel. En option, le pod sera démarré même si le ConfigMap spécifié et les clés n’existent pas.
- 8
- Il permet d’extraire toutes les variables d’environnement d’un ConfigMap.
- 9
- Le nom du ConfigMap pour tirer toutes les variables d’environnement.
Lorsque ce pod est exécuté, les logs de pod incluront la sortie suivante:
SPECIAL_LEVEL_KEY=very log_level=INFO
SPECIAL_LEVEL_KEY=very log_level=INFO
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Le code SPECIAL_TYPE_KEY=charm n’est pas listé dans la sortie de l’exemple car optionnel: true est défini.
2.5.4.2. Définition des arguments de ligne de commande pour les commandes de conteneur avec des cartes de configuration Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser une carte de configuration pour définir la valeur des commandes ou des arguments dans un conteneur à l’aide de la syntaxe de substitution de Kubernetes $(VAR_NAME).
À titre d’exemple, considérez la carte de configuration suivante:
Procédure
Afin d’injecter des valeurs dans une commande dans un conteneur, vous devez consommer les clés que vous souhaitez utiliser comme variables d’environnement. Ensuite, vous pouvez vous référer à eux dans la commande d’un conteneur en utilisant la syntaxe $(VAR_NAME).
Exemple de spécification de la gousse configurée pour injecter des variables d’environnement spécifiques
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 pod est exécuté, la sortie de la commande écho s’exécute dans le conteneur test-conteneur comme suit:
very charm
very charm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.4.3. Injecter du contenu dans un volume en utilisant des cartes de configuration Copier lienLien copié sur presse-papiers!
Il est possible d’injecter du contenu dans un volume en utilisant des cartes de configuration.
Exemple de ressource personnalisée ConfigMap (CR)
Procédure
Il existe plusieurs options différentes pour injecter du contenu dans un volume en utilisant des cartes de configuration.
La façon la plus basique d’injecter du contenu dans un volume en utilisant une carte de configuration est de remplir le volume avec des fichiers où la clé est le nom du fichier et le contenu du fichier est la valeur de la clé:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Fichier contenant la clé.
Lorsque ce pod est exécuté, la sortie de la commande chat sera:
very
very
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il est également possible de contrôler les chemins dans le volume où sont projetées les touches cartographiques de configuration:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Chemin vers la configuration de la clé map.
Lorsque ce pod est exécuté, la sortie de la commande chat sera:
very
very
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. Inclure la priorité pod dans les décisions relatives à la programmation des pod Copier lienLien copié sur presse-papiers!
Dans votre cluster, vous pouvez activer la priorité de pod et la préemption. La priorité des pod indique l’importance d’un pod par rapport aux autres gousses et file d’attente sur la base de cette priorité.
Afin d’utiliser la priorité et la préemption, faites référence à une classe de priorité dans la spécification de pod pour appliquer ce poids à l’horaire.
2.6.1. Comprendre la priorité des pod Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez la fonction Pod Priority and Preemption, les commandes de planificateurs en attente par leur priorité, et un pod en attente est placé en avance sur d’autres pods en attente avec une priorité inférieure dans la file d’attente. En conséquence, le pod de priorité plus élevé pourrait être programmé plus tôt que les pods avec une priorité moindre si ses exigences en matière de planification sont respectées. Dans le cas où une gousse ne peut pas être programmée, le programmeur continue de planifier d’autres gousses de priorité inférieure.
2.6.1.1. Classes prioritaires de pod Copier lienLien copié sur presse-papiers!
Il est possible d’attribuer des pods à une classe de priorité, qui est un objet non-namespace qui définit un mappage d’un nom à la valeur entière de la priorité. La valeur est élevée, plus la priorité est élevée.
L’objet de classe prioritaire peut prendre n’importe quelle valeur entière 32 bits inférieure ou égale à 1000000000 (un milliard). Le nombre de réserves est supérieur ou égal à un milliard pour les gousses critiques qui ne doivent pas être prévenues ou expulsées. Le Red Hat OpenShift Service sur AWS dispose par défaut de deux classes de priorité réservées aux modules de système critiques afin d’avoir une planification garantie.
oc get priorityclasses
$ oc get priorityclasses
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
critique du nœud système - Cette classe prioritaire a une valeur de 2000001000 et est utilisée pour toutes les gousses qui ne devraient jamais être expulsées d’un nœud. Des exemples de gousses qui ont cette classe prioritaire sont ovnkube-node, et ainsi de suite. La classe de priorité critique par défaut comprend un certain nombre de composants critiques, par exemple:
- le maître-api
- le maître-contrôleur
- le maître-etcd
- les ovn-kubernetes
- la synchronisation
cette classe prioritaire a une valeur de 2000000000 (deux milliards) et est utilisée avec des gousses qui sont importantes pour le cluster. Les pods de cette classe prioritaire peuvent être expulsés d’un nœud dans certaines circonstances. À titre d’exemple, les pods configurés avec la classe de priorité critique du nœud système peuvent prendre la priorité. Cependant, cette classe prioritaire assure une planification garantie. Des exemples de gousses qui peuvent avoir cette classe de priorité sont des composants fluides, des composants complémentaires comme un programmeur, et ainsi de suite. La classe de priorité critique par défaut comprend un certain nombre de composants critiques, par exemple:
- Fluentd
- métriques-serveur
- Descheduler
- critique d’OpenShift - Vous pouvez utiliser le champ prioritéClassName avec des pods importants qui ne peuvent pas lier leur consommation de ressources et n’ont pas un comportement prévisible de consommation de ressources. Les pods Prometheus sous les espaces de noms openshift-monitoring et openshift-user-workload-monitoring utilisent l’openshift-user-responsable prioritéClassName. Les charges de travail de surveillance utilisent le système critique comme première classe prioritaire, mais cela pose des problèmes lorsque la surveillance utilise une mémoire excessive et que les nœuds ne peuvent pas les expulser. En conséquence, la surveillance laisse tomber la priorité pour donner de la flexibilité au programmeur, en déplaçant de lourdes charges de travail pour maintenir les nœuds critiques en fonctionnement.
- cluster-logging - Cette priorité est utilisée par Fluentd pour s’assurer que les gousses Fluentd sont programmées pour les nœuds sur d’autres applications.
2.6.1.2. Les noms de priorité pod Copier lienLien copié sur presse-papiers!
Après avoir une ou plusieurs classes prioritaires, vous pouvez créer des pods qui spécifient un nom de classe prioritaire dans une spécification Pod. Le contrôleur d’admission prioritaire utilise le champ de nom de la classe de priorité pour remplir la valeur entière de la priorité. Lorsque la classe de priorité nommée n’est pas trouvée, le pod est rejeté.
2.6.2. Comprendre la préemption de la gousse Copier lienLien copié sur presse-papiers!
Lorsqu’un développeur crée un pod, le pod entre dans une file d’attente. Lorsque le développeur a configuré le pod pour la priorité ou la préemption de la pod, le planificateur choisit un pod dans la file d’attente et essaie de programmer le pod sur un nœud. Lorsque le planificateur ne trouve pas d’espace sur un nœud approprié qui satisfait à toutes les exigences spécifiées de la gousse, la logique de préemption est déclenchée pour la gousse en attente.
Lorsque le planificateur préempte un ou plusieurs pods sur un nœud, le champ nodeName nominé de la spécification Pod à priorité supérieure est défini sur le nom du nœud, ainsi que le champ nodename. Le planificateur utilise le champ nominatifNodeName 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.
Après que le planificateur préempte un pod de priorité inférieure, le planificateur honore la période de résiliation gracieuse du pod. Lorsqu’un autre nœud devient disponible pendant que le planificateur attend la fin de la pod de priorité inférieure, le planificateur peut programmer la pod de priorité plus élevée sur ce nœud. En conséquence, le champ nominatifNodeName et le champ nodeName du Pod spec peuvent être différents.
En outre, si le planificateur préempte les pods sur un nœud et attend la résiliation, et un pod avec un pod de priorité plus élevé que la gousse en attente doit être programmé, le programmeur peut planifier la pod de priorité plus élevée à la place. Dans un tel cas, le planificateur annule le nom nodeNodeName de la gousse en attente, ce qui rend la gousse éligible à un autre nœud.
La préemption n’enlève pas nécessairement toutes les gousses de priorité inférieure d’un nœud. Le programmeur peut programmer une pod en attente en supprimant une partie des gousses de priorité inférieure.
Le planificateur ne considère un nœud pour la prévention de la gousse que si la gousse en attente peut être programmée sur le nœud.
2.6.2.1. Classes prioritaires non préventives Copier lienLien copié sur presse-papiers!
Les pods avec la politique de préemption définie à Never ne sont jamais placés dans la file d’attente avant les pods de priorité inférieure, mais ils ne peuvent pas préempter d’autres gousses. Dans la file d’attente, une pod non préventive attend d’être programmée jusqu’à ce que des ressources suffisantes soient gratuites et qu’elles puissent être programmées. Les gousses non préventives, comme les autres gousses, sont sujettes à un recul du planning. Cela signifie que si le planificateur essaie sans succès de programmer ces gousses, ils sont récupérés avec une fréquence inférieure, permettant à d’autres gousses avec une priorité inférieure d’être programmées avant eux.
Les gousses non préventives peuvent encore être évitées par d’autres gousses hautement prioritaires.
2.6.2.2. La préemption de pod et d’autres paramètres de programmeur Copier lienLien copié sur presse-papiers!
Lorsque vous activez la priorité et la préemption de pod, considérez vos autres paramètres de planning:
- Budget prioritaire de la pod et perturbation des pods
- Le budget de perturbation de la pod spécifie le nombre ou le pourcentage minimum de répliques qui doivent être en hausse à la fois. Lorsque vous spécifiez des budgets de perturbation de pod, Red Hat OpenShift Service sur AWS les respecte lorsque vous préemptez les pods au meilleur niveau d’effort. Le planificateur tente de prévenir les pods sans violer le budget de perturbation de la pod. En l’absence de telles gousses, des gousses à priorité inférieure pourraient être évitées malgré leurs besoins budgétaires de perturbation de la pod.
- La priorité des pod et l’affinité des pod
- L’affinité des gousses exige qu’une nouvelle gousse soit programmée sur le même nœud que les autres gousses portant la même étiquette.
Lorsqu’une gousse en attente a une affinité interpodique avec une ou plusieurs des gousses de priorité inférieures sur un nœud, le planificateur ne peut pas préjuger les pods de priorité inférieure sans enfreindre les exigences en matière d’affinité. Dans ce cas, le planificateur cherche un autre nœud pour programmer le pod en attente. Cependant, il n’y a aucune garantie que le programmeur puisse trouver un nœud approprié et que la gousse en attente pourrait ne pas être programmée.
Afin d’éviter cette situation, configurez soigneusement l’affinité des pods avec des pods de priorité égale.
2.6.2.3. Cessation gracieuse des gousses préemptées Copier lienLien copié sur presse-papiers!
Lors de la préemption d’un pod, le planificateur attend que le délai de résiliation gracieux de la pod expire, permettant à la gousse de terminer le travail et la sortie. Lorsque la gousse ne sort pas après la période, le planificateur tue la gousse. Ce délai de résiliation gracieux crée un écart de temps entre le point que le planificateur préempte le pod et le moment où la gousse en attente peut être programmée sur le nœud.
Afin de minimiser cet écart, configurez un petit délai de résiliation gracieux pour les pods de priorité inférieure.
2.6.3. Configuration de la priorité et de la préemption Copier lienLien copié sur presse-papiers!
Appliquez la priorité pod et la préemption en créant un objet de classe prioritaire et en associant des pods à la priorité en utilisant la prioritéClassName dans vos spécifications de pod.
Il n’est pas possible d’ajouter une classe de priorité directement à une pod existante.
Procédure
Configurer votre cluster pour utiliser la priorité et la préemption:
Définissez une spécification de pod pour inclure le nom d’une classe de priorité en créant un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez la classe de priorité à utiliser avec ce pod.
Créer le pod:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il est possible d’ajouter le nom de priorité directement à la configuration du pod ou à un modèle de pod.
2.7. Placer des pods sur des nœuds spécifiques à l’aide de sélecteurs de nœuds Copier lienLien copié sur presse-papiers!
Le sélecteur de nœuds spécifie une carte des paires clé-valeur. Les règles sont définies à l’aide d’étiquettes personnalisées sur les nœuds et les sélecteurs spécifiés dans les pods.
Afin que la gousse puisse fonctionner sur un nœud, la gousse doit avoir les paires clé-valeur indiquées comme étiquette sur le nœud.
Lorsque vous utilisez l’affinité des nœuds et les sélecteurs de nœuds dans la même configuration, consultez les considérations importantes ci-dessous.
2.7.1. En utilisant des sélecteurs de nœuds pour contrôler le placement des pod Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser des sélecteurs de nœuds sur les gousses et les étiquettes sur les nœuds pour contrôler l’endroit où la gousse est programmée. Avec les sélecteurs de nœuds, Red Hat OpenShift Service sur AWS programme les pods sur les nœuds qui contiennent des étiquettes correspondantes.
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 la machine de calcul garantit que si le nœud ou la machine descend, les nouveaux nœuds ont l’étiquette. Les étiquettes ajoutées à un nœud ou à une configuration de machine ne persistent pas si le nœud ou la machine descend.
Ajouter des sélecteurs de nœuds à un pod existant, ajouter un sélecteur de nœud à l’objet de contrôle pour ce pod, tel qu’un objet ReplicaSet, DaemonSet objet, StatefulSet objet, Deployment object, ou DeploymentConfig objet. Les gousses existantes sous cet objet de contrôle sont recréées sur un nœud avec une étiquette correspondante. Lorsque vous créez un nouveau pod, vous pouvez ajouter le sélecteur de nœud directement au pod spec. Dans le cas où le pod n’a pas d’objet de contrôle, vous devez supprimer le pod, modifier la spécification du pod et recréer le pod.
Il n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant.
Conditions préalables
Afin d’ajouter un sélecteur de nœud à des pods existants, déterminez l’objet de contrôle de ce pod. À titre d’exemple, la gousse routeur-default-66d5cf9464-m2g75 est contrôlée par la réplique routeur-default-66d5cf9464:
oc describe pod router-default-66d5cf9464-7pwkc
$ oc describe pod router-default-66d5cf9464-7pwkc
Exemple de sortie
La console web répertorie l’objet de contrôle sous OwnerReferences dans le pod YAML:
Procédure
Ajouter le sélecteur de nœud correspondant à un pod:
Ajouter un sélecteur de nœuds aux pods existants et futurs, ajouter un sélecteur de nœud à l’objet de contrôle pour les pods:
Exemple ReplicaSet objet avec des étiquettes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoutez le sélecteur de nœud.
Ajouter un sélecteur de nœud à un nouveau pod spécifique, ajouter le sélecteur directement à l’objet Pod:
Exemple Pod objet avec un sélecteur de nœud
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIl n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant.
Chapitre 3. Evoluer automatiquement les pods avec le Custom Metrics Autoscaler Operator Copier lienLien copié sur presse-papiers!
3.1. Libération des notes Copier lienLien copié sur presse-papiers!
3.1.1. Custom Metrics Autoscaler Notes de sortie de l’opérateur Copier lienLien copié sur presse-papiers!
Les notes de sortie de Custom Metrics Autoscaler Operator for Red Hat OpenShift décrivent de nouvelles fonctionnalités et améliorations, des fonctionnalités obsolètes et des problèmes connus.
Le Custom Metrics Autoscaler Operator utilise l’Event Driven Autoscaler (KEDA) basé sur Kubernetes et est construit sur le Red Hat OpenShift Service sur AWS horizontal pod autoscaler (HPA).
Le Custom Metrics Autoscaler Operator for Red Hat OpenShift est fourni en tant que composant installable, avec un cycle de sortie distinct du service Core Red Hat OpenShift sur AWS. La politique sur le cycle de vie de la plate-forme de conteneur Red Hat OpenShift décrit la compatibilité des versions.
3.1.1.1. Les versions prises en charge Copier lienLien copié sur presse-papiers!
Le tableau suivant définit les versions de Custom Metrics Autoscaler Operator pour chaque service Red Hat OpenShift sur AWS.
La version | Le Red Hat OpenShift Service sur AWS | Disponibilité générale |
---|---|---|
2.14.1 | 4.16 | Disponibilité générale |
2.14.1 | 4.15 | Disponibilité générale |
2.14.1 | 4.14 | Disponibilité générale |
2.14.1 | 4.13 | Disponibilité générale |
2.14.1 | 4.12 | Disponibilité générale |
3.1.1.2. Custom Metrics Autoscaler Operator 2.14.1-467 Notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.14.1-467 fournit un CVE et un correctif de bogues pour exécuter l’opérateur dans un service Red Hat OpenShift sur le cluster AWS. L’avis suivant est disponible pour le RHSA-2024:7348.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté d’Event Driven Autoscaler (KEDA) basée sur Kubernetes.
3.1.1.2.1. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, le système de fichiers racine de la pod Custom Metrics Autoscaler Operator était accessible en écriture, ce qui n’est pas nécessaire et pourrait présenter des problèmes de sécurité. Cette mise à jour rend le système de fichiers racine pod en lecture seule, qui répond au problème de sécurité potentiel. (OCPBUGS-37989)
3.1.2. Les notes de sortie pour les versions antérieures de l’opérateur d’autoscale de mesure personnalisée Copier lienLien copié sur presse-papiers!
Les notes de sortie suivantes sont pour les versions précédentes de Custom Metrics Autoscaler Operator.
Dans la version actuelle, consultez les notes de sortie de Custom Metrics Autoscaler Operator.
3.1.2.1. Custom Metrics Autoscaler Operator 2.14.1-454 Notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.14.1-454 fournit un CVE, une nouvelle fonctionnalité et des corrections de bogues pour exécuter l’opérateur dans un service Red Hat OpenShift sur le cluster AWS. L’avis suivant est disponible pour le RHBA-2024:5865.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté d’Event Driven Autoscaler (KEDA) basée sur Kubernetes.
3.1.2.1.1. De nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
3.1.2.1.1.1. La prise en charge du déclencheur Cron avec le Custom Metrics Autoscaler Operator Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator peut maintenant utiliser le déclencheur Cron pour mettre à l’échelle les pods en fonction d’un horaire horaire. Lorsque votre délai spécifié commence, le Custom Metrics Autoscaler Operator met à l’échelle les pods à votre montant souhaité. Lorsque le délai se termine, l’opérateur recule au niveau précédent.
En savoir plus, voir Comprendre le Cron déclencheur.
3.1.2.1.2. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, si vous avez apporté des modifications aux paramètres de configuration de l’audit dans la ressource personnalisée KedaController, la carte de configuration keda-metrics-server-audit-policy ne serait pas mise à jour. En conséquence, vous ne pouvez pas modifier les paramètres de configuration de l’audit après le déploiement initial de Custom Metrics Autoscaler. Avec ce correctif, les modifications apportées à la configuration d’audit sont maintenant correctement rendues dans la carte de configuration, ce qui vous permet de modifier la configuration de l’audit à tout moment après l’installation. (OCPBUGS-32521)
3.1.2.2. Custom Metrics Autoscaler Operator 2.13.1 Notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.13.1-421 fournit une nouvelle fonctionnalité et un correctif de bogues pour exécuter l’opérateur dans un service Red Hat OpenShift sur le cluster AWS. L’avis suivant est disponible pour le RHBA-2024:4837.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté d’Event Driven Autoscaler (KEDA) basée sur Kubernetes.
3.1.2.2.1. De nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
3.1.2.2.1.1. Assistance pour les certificats personnalisés avec le Custom Metrics Autoscaler Operator Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator peut désormais utiliser des certificats CA de service personnalisé pour se connecter en toute sécurité à des sources de mesures compatibles avec TLS, telles qu’un cluster Kafka externe ou un service Prometheus externe. L’opérateur utilise par défaut des certificats de service générés automatiquement pour se connecter uniquement aux services on-cluster. Il y a un nouveau champ dans l’objet KedaController qui vous permet de charger des certificats CA serveur personnalisés pour se connecter à des services externes en utilisant des cartes de configuration.
Consultez les certificats Custom CA pour le Custom Metrics Autoscaler.
3.1.2.2.2. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, les images custom-metrics-autoscaler et custom-metrics-autoscaler-adaptateurs étaient manquantes d’informations de fuseau horaire. En conséquence, les objets mis à l’échelle avec des déclencheurs cron n’ont pas fonctionné parce que les contrôleurs étaient incapables de trouver des informations sur le fuseau horaire. Avec ce correctif, les builds d’image sont mis à jour pour inclure des informations sur le fuseau horaire. En conséquence, les objets à échelle contenant des déclencheurs cron fonctionnent maintenant correctement. Les objets à échelle contenant des déclencheurs cron ne sont actuellement pas pris en charge pour les métriques personnalisées autoscaler. (OCPBUGS-34018)
3.1.2.3. Custom Metrics Autoscaler Operator 2.12.1-394 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.12.1-394 fournit un correctif de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur le cluster AWS. L’avis suivant est disponible pour le RHSA-2024:2901.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté d’Event Driven Autoscaler (KEDA) basée sur Kubernetes.
3.1.2.3.1. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, la fonction protojson.Unmarshal entrait dans une boucle infinie lorsqu’elle démarquait certaines formes de JSON invalide. Cette condition peut se produire lors du démarshaing dans un message qui contient une valeur google.protobuf.Toute valeur ou lorsque l’option UnmarshalOptions.DiscardUnknown est définie. Cette version corrige ce problème. (OCPBUGS-30305)
- Auparavant, lors de l’analyse d’un formulaire multipart, soit explicitement avec la méthode Request.ParseMultipartForm ou implicitement avec la méthode Request.FormValue, Request.PostFormValue, ou Request.FormFile, les limites sur la taille totale du formulaire analysé n’étaient pas appliquées à la mémoire consommée. Cela pourrait causer l’épuisement de la mémoire. Avec cette correction, le processus d’analyse limite maintenant correctement la taille maximale des lignes de forme tout en lisant une seule ligne de formulaire. (OCPBUGS-30360)
- Auparavant, lorsque vous suivez une redirection HTTP vers un domaine qui n’est pas sur un sous-domaine correspondant ou sur une correspondance exacte du domaine initial, un client HTTP ne transmettrait pas d’en-têtes sensibles, tels que l’autorisation ou le cookie. À titre d’exemple, une redirection de example.com vers www.example.com transmettrait l’en-tête d’autorisation, mais une redirection vers www.example.org ne transmettrait pas l’en-tête. Cette version corrige ce problème. (OCPBUGS-30365)
- Auparavant, la vérification d’une chaîne de certificats qui contient un certificat avec un algorithme de clé publique inconnu a provoqué la panique du processus de vérification du certificat. Cette condition a affecté tous les clients et serveurs de crypto et de sécurité des couches de transport (TLS) qui définissent le paramètre Config.ClientAuth sur la valeur VerifyClientCertIfGiven ou RequireAndVerifyClientCertCert. Le comportement par défaut est pour les serveurs TLS de ne pas vérifier les certificats clients. Cette version corrige ce problème. (OCPBUGS-30370)
- Auparavant, si les erreurs retournées à partir de la méthode MarshalJSON contenaient des données contrôlées par l’utilisateur, un attaquant aurait pu utiliser les données pour briser le comportement contextuel de l’escapage automatique du paquet de modèles HTML. Cette condition permettrait aux actions ultérieures d’injecter du contenu inattendu dans les modèles. Cette version corrige ce problème. (OCPBUGS-30397)
- Auparavant, les paquets net/http et golang.org/x/net/http2 Go ne limitaient pas le nombre de cadres CONTINUATION pour une requête HTTP/2. Cette condition pourrait entraîner une consommation excessive de CPU. Cette version corrige ce problème. (OCPBUGS-30894)
3.1.2.4. Custom Metrics Autoscaler Operator 2.12.1-384 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.12.1-384 fournit un correctif de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur le cluster AWS. L’avis suivant est disponible pour le RHBA-2024:2043.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté de KEDA.
3.1.2.4.1. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, les images custom-metrics-autoscaler et custom-metrics-autoscaler-adaptateurs étaient manquantes d’informations de fuseau horaire. En conséquence, les objets mis à l’échelle avec des déclencheurs cron n’ont pas fonctionné parce que les contrôleurs étaient incapables de trouver des informations sur le fuseau horaire. Avec ce correctif, les builds d’image sont mis à jour pour inclure des informations sur le fuseau horaire. En conséquence, les objets à échelle contenant des déclencheurs cron fonctionnent maintenant correctement. (OCPBUGS-32395)
3.1.2.5. Custom Metrics Autoscaler Operator 2.12.1-376 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.12.1-376 fournit des mises à jour de sécurité et des corrections de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur le cluster AWS. L’avis suivant est disponible pour le RHSA-2024:1812.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté de KEDA.
3.1.2.5.1. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, si des valeurs invalides telles que des espaces de noms inexistants étaient spécifiées dans des métadonnées d’objets à échelle, les clients de scaler sous-jacents ne libéreraient pas ou fermeraient leurs descripteurs clients, entraînant une fuite de mémoire lente. Ce correctif ferme correctement les descripteurs clients sous-jacents lorsqu’il y a des erreurs, empêchant ainsi la mémoire de fuir. (OCPBUGS-30145)
- Auparavant, la ressource personnalisée ServiceMonitor (CR) pour le pod keda-metrics-apiserver ne fonctionnait pas, car le CR faisait référence à un nom incorrect de port de métriques de http. Ceci corrige le ServiceMonitor CR pour faire référence au nom de port approprié des métriques. En conséquence, le Service Monitor fonctionne correctement. (OCPBUGS-25806)
3.1.2.6. Custom Metrics Autoscaler Operator 2.11.2-322 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.11.2-322 fournit des mises à jour de sécurité et des corrections de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur le cluster AWS. L’avis suivant est disponible pour le RHSA-2023:6144.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté de KEDA.
3.1.2.6.1. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Étant donné que la version 3.11.2-311 de Custom Metrics Autoscaler Operator a été publiée sans montage de volume requis dans le déploiement de l’opérateur, le pod Custom Metrics Autoscaler Operator redémarrait toutes les 15 minutes. Ce correctif ajoute le montage de volume requis au déploiement de l’opérateur. En conséquence, l’opérateur ne redémarre plus toutes les 15 minutes. (OCPBUGS-22361)
3.1.2.7. Custom Metrics Autoscaler Operator 2.11.2-311 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.11.2-311 fournit de nouvelles fonctionnalités et corrections de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur AWS cluster. Les composants du Custom Metrics Autoscaler Operator 2.11.2-311 ont été libérés dans RHBA-2023:5981.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté de KEDA.
3.1.2.7.1. De nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
3.1.2.7.1.1. Le service Red Hat OpenShift sur AWS (ROSA) et OpenShift Dedicated sont maintenant pris en charge Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator 2.11.2-311 peut être installé sur OpenShift ROSA et OpenShift Dedicated clusters gérés. Les versions précédentes de Custom Metrics Autoscaler Operator ne pouvaient être installées que dans l’espace de noms openshift-keda. Cela a empêché l’opérateur d’être installé sur OpenShift ROSA et OpenShift Dedicated clusters. Cette version de Custom Metrics Autoscaler permet l’installation d’autres espaces de noms tels que les opérateurs openshift ou keda, permettant l’installation dans des clusters ROSA et dédiés.
3.1.2.7.2. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, si l’opérateur automatique de mesure personnalisée a été installé et configuré, mais pas utilisé, le CLI OpenShift a signalé que la liste de ressources n’a pas pu obtenir la liste de ressources pour l’erreur externe.metrics.k8s.io/v1beta1: Got vide réponse pour: external.metrics.k8s.io/v1beta1 erreur après l’entrée d’une commande oc. Le message, bien qu’inoffensif, aurait pu causer de la confusion. Avec ce correctif, l’erreur Got vide pour: externe.metrics… L’erreur n’apparaît plus de manière inappropriée. (OCPBUGS-15779)
- Auparavant, toute annotation ou modification d’étiquette d’objets gérés par le Custom Metrics Autoscaler a été retournée par Custom Metrics Autoscaler Operator chaque fois que le contrôleur Keda a été modifié, par exemple après un changement de configuration. Cela a provoqué un changement continu d’étiquettes dans vos objets. Le Custom Metrics Autoscaler utilise désormais sa propre annotation pour gérer les étiquettes et les annotations, et l’annotation ou l’étiquette ne sont plus retournées de manière inappropriée. (OCPBUGS-15590)
3.1.2.8. Custom Metrics Autoscaler Operator 2.10.1-267 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.10.1-267 fournit de nouvelles fonctionnalités et corrections de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur AWS cluster. Les composants du Custom Metrics Autoscaler Operator 2.10.1-267 ont été libérés dans RHBA-2023:4089.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté de KEDA.
3.1.2.8.1. Corrections de bogues Copier lienLien copié sur presse-papiers!
- Auparavant, les images custom-metrics-autoscaler et custom-metrics-autoscaler-adaptateurs ne contenaient pas d’informations sur le fuseau horaire. À cause de cela, les objets mis à l’échelle avec des déclencheurs cron n’ont pas fonctionné parce que les contrôleurs étaient incapables de trouver des informations sur le fuseau horaire. Avec ce correctif, les builds d’image incluent maintenant des informations sur le fuseau horaire. En conséquence, les objets à échelle contenant des déclencheurs cron fonctionnent maintenant correctement. (OCPBUGS-15264)
- Auparavant, le Custom Metrics Autoscaler Operator tenterait de prendre possession de tous les objets gérés, y compris les objets dans d’autres espaces de noms et objets à portée de cluster. À cause de cela, l’opérateur automatique de mesure personnalisée n’a pas été en mesure de créer la liaison de rôle pour lire les informations d’identification nécessaires pour être un serveur API. Cela a causé des erreurs dans l’espace de noms du système kube. Avec ce correctif, le Custom Metrics Autoscaler Operator saute en ajoutant le champ OwnerReference à n’importe quel objet dans un autre espace de noms ou tout objet à portée de cluster. En conséquence, la liaison de rôle est maintenant créée sans aucune erreur. (OCPBUGS-15038)
- Auparavant, le Custom Metrics Autoscaler Operator a ajouté un champ OwnerReferences à l’espace de noms openshift-keda. Bien que cela n’ait pas causé de problèmes de fonctionnalité, la présence de ce champ aurait pu causer de la confusion pour les administrateurs de clusters. Avec ce correctif, le Custom Metrics Autoscaler Operator n’ajoute pas le champ de référence propriétaire à l’espace de noms openshift-keda. En conséquence, l’espace de noms openshift-keda n’a plus de champ de référence propriétaire superflu. (OCPBUGS-15293)
- Auparavant, si vous utilisiez un déclencheur Prometheus configuré avec une méthode d’authentification autre que l’identité de pod, et que le paramètre podIdentity n’était défini à aucun, le déclencheur ne serait pas à l’échelle. Avec ce correctif, le Custom Metrics Autoscaler pour OpenShift gère désormais correctement le type de fournisseur d’identité aucun pod. En conséquence, un déclencheur Prometheus configuré avec une méthode d’authentification autre que l’identité de pod, et le paramètre podIdentity sset à aucune échelle maintenant correctement. (OCPBUGS-15274)
3.1.2.9. Custom Metrics Autoscaler Operator 2.10.1 Notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.10.1 fournit de nouvelles fonctionnalités et corrections de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur le cluster AWS. Les composants du Custom Metrics Autoscaler Operator 2.10.1 ont été libérés dans RHEA-2023:3199.
Avant d’installer cette version de Custom Metrics Autoscaler Operator, supprimer toutes les versions précédemment installées Technology Preview ou la version prise en charge par la communauté de KEDA.
3.1.2.9.1. De nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
3.1.2.9.1.1. Custom Metrics Autoscaler Disponibilité générale de l’opérateur Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator est désormais disponible à partir de la version 2.10.1 de Custom Metrics Autoscaler Operator.
La mise à l’échelle à l’aide d’un travail à l’échelle est une fonctionnalité d’aperçu technologique seulement. Les fonctionnalités d’aperçu technologique ne sont pas prises en charge avec les accords de niveau de service de production de Red Hat (SLA) et pourraient ne pas être fonctionnellement complètes. Le Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès précoce aux fonctionnalités du produit à venir, permettant aux clients de tester les fonctionnalités et de fournir des commentaires pendant le processus de développement.
En savoir plus sur la portée du support des fonctionnalités de Red Hat Technology Preview, voir la portée du support des fonctionnalités d’aperçu de la technologie.
3.1.2.9.1.2. Indicateurs de performance Copier lienLien copié sur presse-papiers!
Il est maintenant possible d’utiliser le Prometheus Query Language (PromQL) pour interroger les métriques sur l’opérateur automatique de mesure personnalisée.
3.1.2.9.1.3. La mise à l’échelle automatique des métriques personnalisées pour les objets mis à l’échelle Copier lienLien copié sur presse-papiers!
Il est maintenant possible de mettre un terme à l’autoscaling d’un objet à l’échelle, au besoin, et de reprendre l’autoscaling lorsqu’il est prêt.
3.1.2.9.1.4. La réplique tombe en arrière pour les objets mis à l’échelle Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez spécifier le nombre de répliques à laquelle revenir si un objet mis à l’échelle ne parvient pas à obtenir des métriques de la source.
3.1.2.9.1.5. Dénomination HPA personnalisable pour les objets mis à l’échelle Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez spécifier un nom personnalisé pour le pod horizontal autoscaler dans les objets à échelle.
3.1.2.9.1.6. Les seuils d’activation et de mise à l’échelle Copier lienLien copié sur presse-papiers!
Comme le pod autoscaler horizontal (HPA) ne peut pas mettre à l’échelle vers ou à partir de 0 répliques, le Custom Metrics Autoscaler Operator fait cette mise à l’échelle, après quoi la HPA effectue la mise à l’échelle. Désormais, vous pouvez spécifier quand l’HPA prend la relève de l’autoscaling, en fonction du nombre de répliques. Cela permet une plus grande flexibilité avec vos politiques de mise à l’échelle.
3.1.2.10. Custom Metrics Autoscaler Operator 2.8.2-174 notes de sortie Copier lienLien copié sur presse-papiers!
Cette version de Custom Metrics Autoscaler Operator 2.8.2-174 fournit de nouvelles fonctionnalités et corrections de bogues pour exécuter l’opérateur dans un service Red Hat OpenShift sur AWS cluster. Les composants du Custom Metrics Autoscaler Operator 2.8.2-174 ont été publiés dans RHEA-2023:1683.
La version 2.8.2-174 de Custom Metrics Autoscaler Operator est une fonctionnalité d’aperçu technologique.
3.1.2.10.1. De nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
3.1.2.10.1.1. Appui à la mise à niveau de l’opérateur Copier lienLien copié sur presse-papiers!
Il est maintenant possible de mettre à niveau à partir d’une version antérieure de Custom Metrics Autoscaler Operator. Consultez « Modifier le canal de mise à jour pour un opérateur » dans les « Ressources supplémentaires » pour obtenir des informations sur la mise à niveau d’un opérateur.
3.1.2.10.1.2. appui à la collecte obligatoire Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez collecter des données sur l’opérateur automatique Custom Metrics et ses composants à l’aide du service Red Hat OpenShift sur l’outil AWS must-collectther. Actuellement, le processus d’utilisation de l’outil must-collectther avec le Custom Metrics Autoscaler est différent de celui des autres opérateurs. Consultez « Rassembler des données de débogage dans les « ressources supplémentaires » pour plus d’informations.
3.1.2.11. Custom Metrics Autoscaler Operator 2.8.2 Notes de sortie Copier lienLien copié sur presse-papiers!
Cette version du Custom Metrics Autoscaler Operator 2.8.2 fournit de nouvelles fonctionnalités et corrections de bogues pour exécuter l’opérateur dans un service OpenShift Red Hat sur le cluster AWS. Les composants du Custom Metrics Autoscaler Operator 2.8.2 ont été publiés dans RHSA-2023:1042.
La version 2.8.2 de Custom Metrics Autoscaler Operator est une fonctionnalité d’aperçu technologique.
3.1.2.11.1. De nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
3.1.2.11.1.1. Enregistrement de l’audit Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez rassembler et afficher les journaux d’audit de l’opérateur automatique Custom Metrics et de ses composants associés. Les journaux d’audit sont des ensembles chronologiques d’enregistrements pertinents pour 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.
3.1.2.11.1.2. Applications à l’échelle basées sur les métriques Apache Kafka Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez utiliser le déclencheur/scale KEDA Apache kafka pour mettre à l’échelle les déploiements basés sur un sujet Apache Kafka.
3.1.2.11.1.3. Applications à l’échelle basées sur les métriques CPU Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez utiliser le déclencheur/scaler CPU KEDA pour mettre à l’échelle les déploiements basés sur les métriques CPU.
3.1.2.11.1.4. Applications à l’échelle basées sur des métriques de mémoire Copier lienLien copié sur presse-papiers!
Désormais, vous pouvez utiliser le déclencheur/scale de mémoire KEDA pour mettre à l’échelle les déploiements basés sur des métriques de mémoire.
3.2. Custom Metrics Autoscaler Vue d’ensemble de l’opérateur Copier lienLien copié sur presse-papiers!
En tant que développeur, vous pouvez utiliser Custom Metrics Autoscaler Operator pour Red Hat OpenShift pour spécifier comment Red Hat OpenShift Service sur AWS devrait automatiquement augmenter ou diminuer le nombre de pods pour un déploiement, un ensemble d’état, une ressource personnalisée ou un travail basé sur des métriques personnalisées qui ne sont pas basées uniquement sur le CPU ou la mémoire.
Le Custom Metrics Autoscaler Operator est un opérateur optionnel, basé sur le Kubernetes Event Driven Autoscaler (KEDA), qui permet de mettre à l’échelle les charges de travail à l’aide de sources de mesures supplémentaires autres que les métriques de pod.
L’autoscaler de mesures personnalisées ne prend actuellement en charge que les métriques Prometheus, CPU, mémoire et Apache Kafka.
Le Custom Metrics Autoscaler Operator met à l’échelle vos pods de haut en bas en fonction de mesures externes personnalisées provenant d’applications spécifiques. Les autres applications continuent d’utiliser d’autres méthodes de mise à l’échelle. Configurez les déclencheurs, également connus sous le nom de scalers, qui sont la source des événements et des métriques que les métriques automatiques personnalisables utilisent pour déterminer comment mettre à l’échelle. L’autoscaler de mesures personnalisées utilise une API de métriques pour convertir les métriques externes en une forme que Red Hat OpenShift Service sur AWS peut utiliser. L’autoscaler de mesures personnalisées crée un autoscaleur de pod horizontal (HPA) qui effectue la mise à l’échelle réelle.
Afin d’utiliser le programmeur automatique de mesures personnalisées, vous créez un objet ScaledObject ou ScaledJob pour une charge de travail, qui est une ressource personnalisée (CR) qui définit les métadonnées de mise à l’échelle. Le déploiement ou la tâche à mettre à l’échelle, la source des métriques à mettre à l’échelle (déclenchant) et d’autres paramètres tels que les nombres de répliques minimum et maximum autorisés.
Il n’est possible de créer qu’un seul objet à l’échelle ou un travail à l’échelle pour chaque charge de travail que vous souhaitez mettre à l’échelle. En outre, vous ne pouvez pas utiliser un objet à l’échelle ou un travail à l’échelle et le pod horizontal autoscaler (HPA) sur la même charge de travail.
L’autoscaleur de mesures personnalisées, contrairement à l’HPA, peut atteindre zéro. Lorsque vous définissez la valeur minReplicaCount dans les métriques personnalisées autoscaler CR à 0, les métriques personnalisées autoscaler réduit la charge de travail de 1 à 0 répliques à ou plus de 0 répliques à 1. C’est ce qu’on appelle la phase d’activation. Après avoir mis à l’échelle jusqu’à 1 réplique, l’HPA prend le contrôle de la mise à l’échelle. C’est ce qu’on appelle la phase de mise à l’échelle.
Certains déclencheurs vous permettent de modifier le nombre de répliques qui sont mises à l’échelle par le cluster métrique autoscaler. Dans tous les cas, le paramètre pour configurer la phase d’activation utilise toujours la même phrase, préfixée avec activation. Ainsi, si le paramètre seuil configure la mise à l’échelle, activationThreshold configurerait l’activation. La configuration des phases d’activation et de mise à l’échelle vous permet une plus grande flexibilité avec vos stratégies de mise à l’échelle. À titre d’exemple, vous pouvez configurer une phase d’activation plus élevée pour éviter une mise à l’échelle vers le haut ou vers le bas si la métrique est particulièrement faible.
La valeur d’activation a plus de priorité que la valeur de mise à l’échelle en cas de décisions différentes pour chacune. À titre d’exemple, si le seuil est fixé à 10, et que le seuil d’activation est de 50, si la métrique rapporte 40, l’échelle n’est pas active et les pods sont mis à l’échelle à zéro même si l’HPA nécessite 4 instances.
Figure 3.1. Flux de travail autoscaler de mesures personnalisées
- Créez ou modifiez une ressource personnalisée d’objet à échelle pour une charge de travail sur un cluster. L’objet contient la configuration de mise à l’échelle de cette charge de travail. Avant d’accepter le nouvel objet, le serveur API OpenShift l’envoie au processus d’admission autoscaler personnalisé pour s’assurer que l’objet est valide. En cas de réussite de la validation, le serveur API persiste l’objet.
- Le contrôleur autoscaleur de mesure personnalisé montre des objets nouveaux ou modifiés à l’échelle. Lorsque le serveur API OpenShift informe le contrôleur d’une modification, le contrôleur surveille toutes les sources de déclenchement externes, également connues sous le nom de sources de données, qui sont spécifiées dans l’objet pour les modifications apportées aux données métriques. Il y a un ou plusieurs évolutifs qui demandent des données de mise à l’échelle à partir de la source de déclenchement externe. Ainsi, pour un type de déclenchement Kafka, le contrôleur utilise l’échelle Kafka pour communiquer avec une instance Kafka afin d’obtenir les données demandées par le déclencheur.
- Le contrôleur crée un objet horizontal pod autoscaler pour l’objet mis à l’échelle. En conséquence, l’opérateur Horizontal Pod Autoscaler (HPA) commence à surveiller les données de mise à l’échelle associées au déclencheur. Le HPA demande des données de mise à l’échelle à partir du point d’extrémité du serveur API OpenShift cluster.
- Le point d’extrémité du serveur de l’API OpenShift est servi par l’adaptateur métriques autoscaler personnalisé. Lorsque l’adaptateur métrique reçoit une demande de mesures personnalisées, il utilise une connexion GRPC au contrôleur pour la demander pour les données de déclenchement les plus récentes reçues de l’échelleur.
- La HPA prend des décisions de mise à l’échelle en fonction des données reçues de l’adaptateur métrique et augmente ou diminue la charge de travail en augmentant ou en diminuant les répliques.
- En tant qu’il fonctionne, une charge de travail peut affecter les métriques de mise à l’échelle. Ainsi, si une charge de travail est mise à l’échelle pour gérer le travail dans une file d’attente Kafka, la taille de la file d’attente diminue après que la charge de travail traite tout le travail. En conséquence, la charge de travail est réduite.
- Lorsque les métriques sont dans une plage spécifiée par la valeur minReplicaCount, le contrôleur autoscaleur métrique personnalisé désactive toute mise à l’échelle et laisse le compte de réplique à un niveau fixe. Lorsque les métriques dépassent cette plage, le contrôleur d’échelle automatique de mesures personnalisées permet la mise à l’échelle et permet à l’HPA de mettre à l’échelle la charge de travail. Bien que la mise à l’échelle soit désactivée, la HPA ne prend aucune mesure.
3.2.1. Certificats CA personnalisés pour le Custom Metrics Autoscaler Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator utilise par défaut des certificats CA de service générés automatiquement pour se connecter aux services on-cluster.
Lorsque vous souhaitez utiliser des services hors-clus qui nécessitent des certificats CA personnalisés, vous pouvez ajouter les certificats requis à une carte de configuration. Ensuite, ajoutez la carte de configuration à la ressource personnalisée KedaController comme décrit dans Installation des métriques personnalisées autoscaler. L’Opérateur charge ces certificats lors du démarrage et les enregistre selon la confiance de l’Opérateur.
Les cartes de configuration peuvent contenir un ou plusieurs fichiers de certificats contenant un ou plusieurs certificats CA codés PEM. En outre, vous pouvez utiliser des cartes de configuration séparées pour chaque fichier de certificat.
Lorsque vous mettez à jour la carte de configuration pour ajouter des certificats supplémentaires, vous devez redémarrer le pod keda-operator-* pour que les modifications entrent en vigueur.
3.3. Installation des mesures personnalisées autoscaler Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser le service Red Hat OpenShift sur la console web AWS pour installer le Custom Metrics Autoscaler Operator.
L’installation crée les cinq CRD suivants:
-
ClusterTriggerAuthentication
-
KedaController
-
ScaledJob
-
À l’échelle de l’objet
-
Authentification de Trigger
3.3.1. Installation des mesures personnalisées autoscaler Copier lienLien copié sur presse-papiers!
La procédure suivante vous permet d’installer Custom Metrics Autoscaler Operator.
Conditions préalables
- En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
- Enlevez toutes les versions d’aperçu technologique précédemment installées du Cluster Metrics Autoscaler Operator.
Enlevez toutes les versions de la KEDA basée sur la communauté.
En outre, supprimez les définitions de ressources personnalisées KEDA 1.x en exécutant les commandes suivantes:
oc delete crd scaledobjects.keda.k8s.io
$ oc delete crd scaledobjects.keda.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd triggerauthentications.keda.k8s.io
$ oc delete crd triggerauthentications.keda.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Assurez-vous que l’espace de noms keda existe. Dans le cas contraire, vous devez créer manaully l’espace de noms keda.
Facultatif: Si vous avez besoin de l’opérateur d’échelle automatique de mesures personnalisées pour vous connecter à des services hors-clus, tels qu’un cluster Kafka externe ou un service externe Prometheus, mettez tous les certificats CA de service requis dans une carte de configuration. La carte de configuration doit exister dans le même espace de noms où l’opérateur est installé. À titre d’exemple:
oc create configmap -n openshift-keda thanos-cert --from-file=ca-cert.pem
$ oc create configmap -n openshift-keda thanos-cert --from-file=ca-cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procédure
- Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → OperatorHub.
- Choisissez Custom Metrics Autoscaler dans la liste des opérateurs disponibles, puis cliquez sur Installer.
- Dans la page Installer l’opérateur, assurez-vous que l’espace de noms A de l’option cluster est sélectionné pour le mode d’installation.
- Dans Namespace installé, cliquez sur Sélectionner un espace de noms.
Cliquez sur Sélectionner le projet:
- Dans le cas où l’espace de noms keda existe, sélectionnez keda dans la liste.
Dans le cas où l’espace de noms keda n’existe pas:
- Choisissez Créer un projet pour ouvrir la fenêtre Créer un projet.
- Dans le champ Nom, entrez keda.
- Dans le champ Nom d’affichage, entrez un nom descriptif, tel que keda.
- Facultatif: Dans le champ Nom d’affichage, ajoutez une description de l’espace de noms.
- Cliquez sur Create.
- Cliquez sur Install.
Contrôlez l’installation en listant les composants de Custom Metrics Autoscaler Operator:
- Accédez à Workloads → Pods.
- Choisissez le projet keda dans le menu déroulant et vérifiez que le pod personnalisé-metrics-autoscaler-operator-* est en cours d’exécution.
- Accédez à Charges de travail → Déploiements pour vérifier que le déploiement custom-metrics-autoscaler-operator est en cours d’exécution.
Facultatif: Vérifiez l’installation dans le CLI OpenShift en utilisant la commande suivante:
oc get all -n keda
$ oc get all -n keda
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le résultat semble similaire à ce qui suit:
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Installez la ressource personnalisée KedaController, qui crée les CRD requis:
- Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → Opérateurs installés.
- Cliquez sur Custom Metrics Autoscaler.
- Dans la page Détails de l’opérateur, cliquez sur l’onglet KedaController.
Dans l’onglet KedaController, cliquez sur Créer KedaController et modifiez le fichier.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique un espace de noms unique dans lequel l’opérateur automatique de mesure personnalisée devrait mettre à l’échelle les applications. Laissez-le vide ou laissez-le vide pour mettre à l’échelle les applications dans tous les espaces de noms. Ce champ doit avoir un espace de noms ou être vide. La valeur par défaut est vide.
- 2
- Indique le niveau de verbosité des messages de log Custom Metrics Autoscaler Operator. Les valeurs autorisées sont debug, info, erreur. La valeur par défaut est info.
- 3
- Indique le format d’enregistrement des messages de log Custom Metrics Autoscaler Operator. Les valeurs autorisées sont console ou json. La valeur par défaut est console.
- 4
- Facultatif: Spécifie une ou plusieurs cartes de configuration avec des certificats CA, que l’opérateur automatique de mesure personnalisée peut utiliser pour se connecter en toute sécurité aux sources de métriques compatibles avec TLS.
- 5
- Indique le niveau de journalisation du serveur Metrics Autoscaler Custom Metrics. Les valeurs autorisées sont 0 pour info et 4 pour debug. La valeur par défaut est 0.
- 6
- Active l’enregistrement de l’audit pour l’opérateur automatique de mesure personnalisée et spécifie la politique d’audit à utiliser, comme décrit dans la section « Configuring Audit logging ».
- Cliquez sur Créer pour créer le contrôleur KEDA.
3.4. Comprendre les déclencheurs automatiques des mesures personnalisées Copier lienLien copié sur presse-papiers!
Les déclencheurs, également connus sous le nom de balanceurs, fournissent les métriques que le Custom Metrics Autoscaler Operator utilise pour mettre à l’échelle vos pods.
L’autoscaler de mesures personnalisées prend actuellement en charge les déclencheurs Prometheus, CPU, mémoire, Apache Kafka et cron.
Dans les sections qui suivent, vous utilisez une ressource personnalisée ScaledObject ou ScaledJob pour configurer des déclencheurs pour des objets spécifiques.
Il est possible de configurer une autorité de certification à utiliser avec vos objets mis à l’échelle ou pour tous les planificateurs du cluster.
3.4.1. Comprendre le déclencheur Prométhée Copier lienLien copié sur presse-papiers!
Les pods peuvent être mis à l’échelle en fonction des métriques Prometheus, qui peuvent utiliser le Red Hat OpenShift Service installé sur la surveillance AWS ou un serveur Prometheus externe comme source de métriques. Consultez "Configurer les métriques personnalisées autoscaler pour utiliser Red Hat OpenShift Service sur la surveillance AWS" pour obtenir des informations sur les configurations requises pour utiliser le service Red Hat OpenShift sur la surveillance AWS comme source de métriques.
Lorsque Prometheus collecte des métriques à partir de l’application que l’échelle automatique des métriques personnalisées s’évolue, ne définissez pas les répliques minimales à 0 dans la ressource personnalisée. En l’absence de pods d’application, l’autoscaler de métriques personnalisées n’a pas de métriques à mettre à l’échelle.
Exemple d’objet mis à l’échelle avec une cible Prometheus
- 1
- Indique Prometheus comme type de déclencheur.
- 2
- Indique l’adresse du serveur Prometheus. Cet exemple utilise Red Hat OpenShift Service sur la surveillance AWS.
- 3
- Facultatif : Spécifie l’espace de noms de l’objet que vous souhaitez mettre à l’échelle. Ce paramètre est obligatoire si vous utilisez Red Hat OpenShift Service sur la surveillance AWS comme source pour les métriques.
- 4
- Indique le nom pour identifier la métrique dans l’API externe.metrics.k8s.io. Lorsque vous utilisez plus d’un déclencheur, tous les noms métriques doivent être uniques.
- 5
- Indique la valeur qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée.
- 6
- Indique la requête Prometheus à utiliser.
- 7
- Indique la méthode d’authentification à utiliser. Les échelles Prometheus prennent en charge l’authentification au porteur (porteur), l’authentification de base (basique) ou l’authentification TLS (tls). Comme indiqué dans une section suivante, vous configurez les paramètres d’authentification spécifiques dans une authentification de déclencheur. Au besoin, vous pouvez également utiliser un secret.
- 8
- Facultatif : Passe l’en-tête X-Scope-OrgID à un stockage multi-locataires Cortex ou Mimir pour Prometheus. Ce paramètre n’est requis qu’avec le stockage Prometheus multi-locataires, pour indiquer quelles données Prometheus doit retourner.
- 9
- Facultatif : Spécifie comment le déclencheur doit procéder si la cible Prometheus est perdue.
- Dans l’affirmative, le déclencheur continue de fonctionner si la cible Prometheus est perdue. C’est le comportement par défaut.
- En cas de faux, le déclencheur renvoie une erreur si la cible Prometheus est perdue.
- 10
- Facultatif: Spécifie si la vérification du certificat doit être ignorée. À titre d’exemple, vous pouvez sauter la vérification si vous êtes en cours d’exécution dans un environnement de test et en utilisant des certificats autosignés au point de terminaison Prometheus.
- En cas de faux, la vérification du certificat est effectuée. C’est le comportement par défaut.
Dans l’affirmative, la vérification du certificat n’est pas effectuée.
ImportantIl n’est pas recommandé de sauter le chèque.
3.4.1.1. Configuration de l’échelle automatique de mesures personnalisées pour utiliser Red Hat OpenShift Service sur la surveillance AWS Copier lienLien copié sur presse-papiers!
Le service Red Hat OpenShift installé sur AWS Prometheus peut être utilisé comme source pour les métriques utilisées par l’autoscaleur de mesures personnalisées. Cependant, il y a quelques configurations supplémentaires que vous devez effectuer.
Afin que vos objets mis à l’échelle puissent lire le service Red Hat OpenShift sur les métriques AWS Prometheus, vous devez utiliser une authentification de déclencheur ou une authentification de déclencheur de cluster afin de fournir les informations d’authentification requises. La procédure suivante diffère selon la méthode d’authentification de déclenchement que vous utilisez. En savoir plus sur les authentifications de déclenchement, voir « Comprendre les authentifications automatiques des métriques personnalisées ».
Ces étapes ne sont pas nécessaires pour une source externe de Prometheus.
Comme décrit dans cette section, vous devez effectuer les tâches suivantes:
- Créer un compte de service.
- Créez un secret qui génère un jeton pour le compte de service.
- Créez l’authentification de déclencheur.
- Créer un rôle.
- Ajoutez ce rôle au compte de service.
- Faites référence au jeton dans l’objet d’authentification de déclenchement utilisé par Prometheus.
Conditions préalables
- Le service OpenShift Red Hat sur la surveillance AWS doit être installé.
- La surveillance des charges de travail définies par l’utilisateur doit être activée dans Red Hat OpenShift Service sur la surveillance AWS, comme décrit dans la section Création d’une carte de configuration de la charge de travail définie par l’utilisateur.
- Le Custom Metrics Autoscaler Operator doit être installé.
Procédure
Changement au projet approprié:
oc project <project_name>
$ oc project <project_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique l’un des projets suivants:
- Lorsque vous utilisez une authentification de déclencheur, spécifiez le projet avec l’objet que vous souhaitez mettre à l’échelle.
- Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez le projet openshift-keda.
Créez un compte de service et un jeton, si votre cluster n’en a pas:
Créer un objet de compte de service en utilisant la commande suivante:
oc create serviceaccount thanos
$ oc create serviceaccount thanos
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le nom du compte de service.
Créez un YAML secret pour générer un jeton de compte de service:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le nom du compte de service.
Créez l’objet secret en utilisant la commande suivante:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À l’aide de la commande suivante pour localiser le jeton attribué au compte de service:
oc describe serviceaccount thanos
$ oc describe serviceaccount thanos
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le nom du compte de service.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Utilisez ce jeton dans l’authentification de déclencheur.
Créer une authentification de déclenchement avec le jeton de compte de service:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique l’une des méthodes d’authentification de déclenchement suivantes:
- Lorsque vous utilisez une authentification de déclencheur, spécifiez TriggerAuthentication. Cet exemple configure une authentification de déclenchement.
- Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez ClusterTriggerAuthentication.
- 2
- Indique que cet objet utilise un secret pour l’autorisation.
- 3
- Indique le paramètre d’authentification à fournir en utilisant le jeton.
- 4
- Indique le nom du jeton à utiliser.
- 5
- Indique la clé dans le jeton à utiliser avec le paramètre spécifié.
Créer l’objet CR:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créer un rôle pour lire les métriques Thanos:
Créez un fichier YAML avec les paramètres suivants:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer l’objet CR:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créer une liaison de rôle pour lire les métriques Thanos:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique l’un des types d’objets suivants:
- Lorsque vous utilisez une authentification de déclencheur, spécifiez RoleBinding.
- Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez ClusterRoleBinding.
- 2
- Indique le nom du rôle que vous avez créé.
- 3
- Indique l’un des projets suivants:
- Lorsque vous utilisez une authentification de déclencheur, spécifiez le projet avec l’objet que vous souhaitez mettre à l’échelle.
- Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez le projet openshift-keda.
- 4
- Indique le nom du compte de service pour se lier au rôle.
- 5
- Indique le projet où vous avez précédemment créé le compte de service.
Créer l’objet CR:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Comme décrit dans « Comprendre comment ajouter des métriques personnalisées », vous pouvez maintenant déployer un objet à l’échelle ou une tâche mise à l’échelle pour activer l’autoscaling de votre application. Afin d’utiliser Red Hat OpenShift Service sur la surveillance AWS comme source, dans le déclencheur ou dans l’échelle, vous devez inclure les paramètres suivants:
- triggers.type doit être promisheus
- triggers.metadata.serverAdresse doit être https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
- triggers.metadata.authModes doivent être porteurs
- triggers.metadata.namespace doit être réglé sur l’espace de noms de l’objet à l’échelle
- triggers.authenticationRef doit pointer vers la ressource d’authentification de déclencheur spécifiée à l’étape précédente
3.4.2. Comprendre le déclencheur CPU Copier lienLien copié sur presse-papiers!
Les pods peuvent être mis à l’échelle en fonction des métriques CPU. Ce déclencheur utilise les métriques de cluster comme source pour les métriques.
Les mesures personnalisées autoscaler met à l’échelle les pods associés à un objet pour maintenir l’utilisation du CPU que vous spécifiez. L’autoscaler augmente ou diminue le nombre de répliques entre les nombres minimum et maximum pour maintenir l’utilisation spécifiée du CPU dans toutes les gousses. Le déclencheur de mémoire tient compte de l’utilisation de la mémoire de l’ensemble de la gousse. Lorsque la gousse a plusieurs conteneurs, le déclencheur de mémoire prend en compte l’utilisation totale de la mémoire de tous les conteneurs dans le pod.
- Ce déclencheur ne peut pas être utilisé avec la ressource personnalisée ScaledJob.
- Lors de l’utilisation d’un déclencheur de mémoire pour mettre à l’échelle un objet, l’objet ne se met pas à l’échelle à 0, même si vous utilisez plusieurs déclencheurs.
Exemple d’objet mis à l’échelle avec une cible CPU
- 1
- Indique CPU comme type de déclencheur.
- 2
- Indique le type de métrique à utiliser, soit l’utilisation ou la valeur moyenne.
- 3
- Indique la valeur qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée.
- Lors de l’utilisation, la valeur cible est la moyenne des métriques de ressources pour tous les pods pertinents, représentée en pourcentage de la valeur demandée de la ressource pour les pods.
- Lors de l’utilisation de la valeur moyenne, la valeur cible est la moyenne des métriques de tous les pods pertinents.
- 4
- Indique le nombre minimum de répliques lors de la mise à l’échelle. Dans le cas d’un déclencheur CPU, entrez une valeur de 1 ou plus, car le HPA ne peut pas atteindre zéro si vous utilisez uniquement des métriques CPU.
3.4.3. Comprendre le déclencheur de la mémoire Copier lienLien copié sur presse-papiers!
Les pods peuvent être mis à l’échelle en fonction des métriques de mémoire. Ce déclencheur utilise les métriques de cluster comme source pour les métriques.
Les mesures personnalisées autoscaler met à l’échelle les pods associés à un objet pour maintenir l’utilisation moyenne de la mémoire que vous spécifiez. L’autoscaler augmente et diminue le nombre de répliques entre les nombres minimum et maximum pour maintenir l’utilisation de la mémoire spécifiée dans toutes les gousses. Le déclencheur de mémoire considère l’utilisation de la mémoire de la gousse entière. Lorsque la gousse a plusieurs conteneurs, l’utilisation de la mémoire est la somme de tous les conteneurs.
- Ce déclencheur ne peut pas être utilisé avec la ressource personnalisée ScaledJob.
- Lors de l’utilisation d’un déclencheur de mémoire pour mettre à l’échelle un objet, l’objet ne se met pas à l’échelle à 0, même si vous utilisez plusieurs déclencheurs.
Exemple d’objet mis à l’échelle avec une cible mémoire
- 1
- Indique la mémoire comme type de déclenchement.
- 2
- Indique le type de métrique à utiliser, soit l’utilisation ou la valeur moyenne.
- 3
- Indique la valeur qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée.
- Lors de l’utilisation, la valeur cible est la moyenne des métriques de ressources pour tous les pods pertinents, représentée en pourcentage de la valeur demandée de la ressource pour les pods.
- Lors de l’utilisation de la valeur moyenne, la valeur cible est la moyenne des métriques de tous les pods pertinents.
- 4
- Facultatif: Spécifie un conteneur individuel à l’échelle, en fonction de l’utilisation de la mémoire seulement de ce conteneur, plutôt que de l’ensemble de la gousse. Dans cet exemple, seul le conteneur nommé api doit être mis à l’échelle.
3.4.4. Comprendre le déclencheur Kafka Copier lienLien copié sur presse-papiers!
Les pods peuvent être mis à l’échelle en fonction d’un sujet Apache Kafka ou d’autres services prenant en charge le protocole Kafka. L’échelle automatique des métriques personnalisées ne dépasse pas le nombre de partitions Kafka, à moins que vous n’ayez défini le paramètre allowIdleConsumers sur true dans l’objet mis à l’échelle ou le travail mis à l’échelle.
Lorsque le nombre de groupes de consommateurs dépasse le nombre de partitions dans un sujet, les groupes de consommateurs supplémentaires restent inactifs. Afin d’éviter cela, le nombre de répliques par défaut ne dépasse pas:
- Le nombre de partitions sur un sujet, si un sujet est spécifié
- Le nombre de partitions de tous les sujets du groupe de consommateurs, si aucun sujet n’est spécifié
- Le maxReplicaCount spécifié dans l’objet mis à l’échelle ou le travail mis à l’échelle CR
Le paramètre allowIdleConsumers permet de désactiver ces comportements par défaut.
Exemple d’objet mis à l’échelle avec une cible Kafka
- 1
- Indique Kafka comme type de déclencheur.
- 2
- Indique le nom du sujet Kafka sur lequel Kafka traite le décalage.
- 3
- Indique une liste séparée par virgule des courtiers Kafka auxquels se connecter.
- 4
- Indique le nom du groupe de consommateurs Kafka utilisé pour vérifier le décalage sur le sujet et traiter le décalage associé.
- 5
- Facultatif : Spécifie la valeur cible moyenne qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée. La valeur par défaut est 5.
- 6
- Facultatif : Spécifie la valeur cible pour la phase d’activation. Doit être spécifié comme une valeur de chaîne citée.
- 7
- Facultatif: Spécifie la politique de réinitialisation de l’offset Kafka pour le consommateur Kafka. Les valeurs disponibles sont les suivantes: les plus récentes et les plus anciennes. La valeur par défaut est la dernière.
- 8
- Facultatif : Spécifie si le nombre de répliques Kafka peut dépasser le nombre de partitions sur un sujet.
- Dans l’affirmative, le nombre de répliques Kafka peut dépasser le nombre de partitions sur un sujet. Cela permet aux consommateurs de Kafka oisifs.
- En cas de faux, le nombre de répliques Kafka ne peut pas dépasser le nombre de partitions sur un sujet. C’est la valeur par défaut.
- 9
- Indique comment le déclencheur se comporte lorsqu’une partition Kafka n’a pas de décalage valide.
- Dans l’affirmative, les consommateurs sont réduits à zéro pour cette partition.
- En cas de faux, l’échelle garde un seul consommateur pour cette partition. C’est la valeur par défaut.
- 10
- Facultatif : Spécifie si le déclencheur inclut ou exclut le décalage de partition pour les partitions dont le décalage courant est le même que le décalage courant du cycle de sondage précédent.
- Dans l’affirmative, l’échelle exclut le décalage de partition dans ces partitions.
- En cas de faux, le déclencheur inclut tous les décalages du consommateur dans toutes les partitions. C’est la valeur par défaut.
- 11
- Facultatif: Spécifie la version de vos courtiers Kafka. Doit être spécifié comme une valeur de chaîne citée. La valeur par défaut est 1.0.0.
- 12
- Facultatif: Spécifie une liste séparée par virgule d’IDs de partition pour étendre la mise à l’échelle. Lorsqu’il est défini, seuls les identifiants listés sont pris en compte lors du calcul du décalage. Doit être spécifié comme une valeur de chaîne citée. La valeur par défaut est de prendre en compte toutes les partitions.
- 13
- Facultatif : Spécifie s’il faut utiliser l’authentification client TSL pour Kafka. La valeur par défaut est désactivée. Informations sur la configuration de TLS, voir « Comprendre les authentifications automatiques des métriques personnalisées ».
3.4.5. Comprendre le déclencheur Cron Copier lienLien copié sur presse-papiers!
Les pods peuvent être mis à l’échelle en fonction d’une plage de temps.
Lorsque la plage de temps démarre, les métriques personnalisées autoscalent les pods associés à un objet à partir du nombre minimum configuré de pods au nombre spécifié de gousses souhaitées. À la fin de la plage de temps, les pods sont réduits au minimum configuré. La période de temps doit être configurée au format cron.
L’exemple suivant met à l’échelle les pods associés à cet objet mis à l’échelle de 0 à 100 de 6h00 à 18h30 heure normale de l’Inde.
Exemple d’objet mis à l’échelle avec un déclencheur Cron
- 1
- Indique le nombre minimum de gousses à réduire à la fin du délai.
- 2
- Indique le nombre maximal de répliques lors de la mise à l’échelle. Cette valeur devrait être la même que celle souhaitéeReplicas. La valeur par défaut est 100.
- 3
- Indique un déclencheur Cron.
- 4
- Indique le fuseau horaire pour la période de temps. Cette valeur doit provenir de la base de données du fuseau horaire IANA.
- 5
- Indique le début de la période de temps.
- 6
- Indique la fin du délai.
- 7
- Indique le nombre de gousses à mettre à l’échelle entre le début et la fin du délai. Cette valeur devrait être la même que maxReplicaCount.
3.5. Comprendre les mesures personnalisées autoscaler déclenchent les authentifications Copier lienLien copié sur presse-papiers!
L’authentification de déclencheur vous permet d’inclure des informations d’authentification dans un objet mis à l’échelle ou un travail à l’échelle qui peut être utilisé par les conteneurs associés. Il est possible d’utiliser des authentifications de déclenchement pour transmettre Red Hat OpenShift Service sur les secrets AWS, les mécanismes d’authentification pod natifs de plate-forme, les variables d’environnement, etc.
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.
Alternativement, pour partager des informations d’identification entre des objets dans plusieurs espaces de noms, vous pouvez créer un objet ClusterTriggerAuthentication qui peut être utilisé dans tous les espaces de noms.
Les authentifications de déclenchement et l’authentification de déclenchement de cluster utilisent la même configuration. Cependant, une authentification de déclencheur de cluster nécessite un paramètre de type supplémentaire dans la référence d’authentification de l’objet mis à l’échelle.
Exemple secret pour l’authentification de base
- 1
- Le nom d’utilisateur et le mot de passe à fournir à l’authentification de déclenchement. Les valeurs d’une strophe de données doivent être codées en base-64.
Exemple d’authentification de déclenchement à l’aide d’un secret pour l’authentification de base
- 1
- Indique l’espace de noms de l’objet que vous souhaitez mettre à l’échelle.
- 2
- Indique que cette authentification déclencheur utilise un secret pour l’autorisation lors de la connexion au point de terminaison des métriques.
- 3
- Indique le paramètre d’authentification à fournir en utilisant le secret.
- 4
- Indique le nom du secret à utiliser.
- 5
- Indique la clé dans le secret à utiliser avec le paramètre spécifié.
Exemple d’authentification de cluster avec un secret pour l’authentification de base
- 1
- Il est à noter qu’aucun espace de noms n’est utilisé avec une authentification de déclenchement de cluster.
- 2
- Indique que cette authentification déclencheur utilise un secret pour l’autorisation lors de la connexion au point de terminaison des métriques.
- 3
- Indique le paramètre d’authentification à fournir en utilisant le secret.
- 4
- Indique le nom du secret à utiliser.
- 5
- Indique la clé dans le secret à utiliser avec le paramètre spécifié.
Exemple secret avec les détails de l’autorité de certification (CA)
Exemple d’authentification de déclenchement à l’aide d’un secret pour les détails de l’AC
- 1
- Indique l’espace de noms de l’objet que vous souhaitez mettre à l’échelle.
- 2
- Indique que cette authentification déclencheur utilise un secret pour l’autorisation lors de la connexion au point de terminaison des métriques.
- 3
- Indique le type d’authentification à utiliser.
- 4
- Indique le nom du secret à utiliser.
- 5
- Indique la clé dans le secret à utiliser avec le paramètre spécifié.
- 6
- Indique le paramètre d’authentification pour une CA personnalisée lors de la connexion au point de terminaison des métriques.
- 7
- Indique le nom du secret à utiliser.
- 8
- Indique la clé dans le secret à utiliser avec le paramètre spécifié.
Exemple secret avec un jeton porteur
- 1
- Indique un jeton porteur à utiliser avec l’authentification du porteur. La valeur d’une strophe de données doit être encodée base-64.
Exemple d’authentification de déclenchement avec un jeton porteur
- 1
- Indique l’espace de noms de l’objet que vous souhaitez mettre à l’échelle.
- 2
- Indique que cette authentification déclencheur utilise un secret pour l’autorisation lors de la connexion au point de terminaison des métriques.
- 3
- Indique le type d’authentification à utiliser.
- 4
- Indique le nom du secret à utiliser.
- 5
- Indique la clé dans le jeton à utiliser avec le paramètre spécifié.
Exemple d’authentification de déclenchement avec une variable d’environnement
- 1
- Indique l’espace de noms de l’objet que vous souhaitez mettre à l’échelle.
- 2
- Indique que cette authentification de déclenchement utilise des variables d’environnement pour l’autorisation lors de la connexion au point de terminaison des métriques.
- 3
- Indiquez le paramètre à définir avec cette variable.
- 4
- Indiquez le nom de la variable d’environnement.
- 5
- Facultatif : Spécifiez un conteneur qui nécessite une authentification. Le conteneur doit être dans la même ressource que celle référencée par scaleTargetRef dans l’objet mis à l’échelle.
Exemple d’authentification de déclenchement avec les fournisseurs d’authentification de pod
- 1
- Indique l’espace de noms de l’objet que vous souhaitez mettre à l’échelle.
- 2
- Indique que cette authentification de déclencheur utilise une authentification pod native de plate-forme lors de la connexion au point de terminaison des métriques.
- 3
- Indique une identité de pod. Les valeurs prises en charge ne sont pas, azure, gcp, aws-eks, ou aws-kiam. La valeur par défaut n’est pas.
Ressources supplémentaires
- Informations sur Red Hat OpenShift Service sur AWS secrets, voir Fournir des données sensibles aux pods.
3.5.1. À l’aide d’authentifications de déclenchement Copier lienLien copié sur presse-papiers!
Les authentifications de déclenchement et les authentifications de déclenchement de clusters sont utilisées en utilisant une ressource personnalisée pour créer l’authentification, puis ajouter une référence à un objet à l’échelle ou à une tâche mise à l’échelle.
Conditions préalables
- Le Custom Metrics Autoscaler Operator doit être installé.
Lorsque vous utilisez un secret, l’objet secret doit exister, par exemple:
Exemple secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procédure
Créez l’objet TriggerAuthentication ou ClusterTriggerAuthentication.
Créer un fichier YAML qui définit l’objet:
Exemple d’authentification de déclenchement avec un secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer l’objet TriggerAuthentication:
oc create -f <filename>.yaml
$ oc create -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créer ou modifier un fichier ScaledObject YAML qui utilise l’authentification de déclencheur:
Créez un fichier YAML qui définit l’objet en exécutant la commande suivante:
Exemple d’objet mis à l’échelle avec une authentification de déclenchement
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple d’objet mis à l’échelle avec une authentification de déclenchement de cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez l’objet mis à l’échelle en exécutant la commande suivante:
oc apply -f <filename>
$ oc apply -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. La mise à l’échelle automatique des métriques personnalisées pour un objet mis à l’échelle Copier lienLien copié sur presse-papiers!
Au besoin, vous pouvez mettre en pause et redémarrer la mise à l’échelle automatique d’une charge de travail.
À titre d’exemple, vous voudrez peut-être mettre fin à la mise à l’échelle automatique avant d’effectuer la maintenance du cluster ou éviter la famine des ressources en supprimant les charges de travail non critiques.
3.6.1. En mettant en place un autoscaler de mesures personnalisées Copier lienLien copié sur presse-papiers!
La mise à l’échelle automatique d’un objet mis à l’échelle peut être interrompue en ajoutant l’annotation autoscaling.keda.sh/paused-replicas à l’autoscaleur de mesures personnalisées pour cet objet mis à l’échelle. Les métriques personnalisées autoscalent les répliques de cette charge de travail à la valeur spécifiée et mettent en pause l’autoscaling jusqu’à ce que l’annotation soit supprimée.
Procédure
À l’aide de la commande suivante pour modifier le ScaledObject CR pour votre charge de travail:
oc edit ScaledObject scaledobject
$ oc edit ScaledObject scaledobject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ajoutez l’annotation autoscaling.keda.sh/paused-replicas avec n’importe quelle valeur:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique que le Custom Metrics Autoscaler Operator doit mettre à l’échelle les répliques à la valeur spécifiée et arrêter l’autoscaling.
3.6.2. Le redémarrage automatique des métriques personnalisées pour un objet mis à l’échelle Copier lienLien copié sur presse-papiers!
Il est possible de redémarrer un autoscaler de mesures personnalisées en supprimant l’annotation autoscaling.keda.sh/paused-replicas pour ce ScaledObject.
Procédure
À l’aide de la commande suivante pour modifier le ScaledObject CR pour votre charge de travail:
oc edit ScaledObject scaledobject
$ oc edit ScaledObject scaledobject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enlevez l’annotation autoscaling.keda.sh/paused-replicas.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Enlevez cette annotation pour redémarrer un autoscaler de mesures personnalisées en pause.
3.7. Collecte des journaux d’audit Copier lienLien copié sur presse-papiers!
Les journaux d’audit, qui sont un ensemble chronologique d’enregistrements pertinents pour la sécurité, 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.
À titre d’exemple, les journaux d’audit peuvent vous aider à comprendre d’où provient une demande d’autoscaling. Il s’agit d’informations clés lorsque les backends sont surchargés par des requêtes d’autoscaling faites par les applications utilisateur et que vous devez déterminer quelle est l’application gênante.
3.7.1. Configuration de l’enregistrement de l’audit Copier lienLien copié sur presse-papiers!
En éditant la ressource personnalisée KedaController, vous pouvez configurer l’audit pour l’opérateur automatique de mesure personnalisée. Les journaux sont envoyés à un fichier journal d’audit sur un volume sécurisé en utilisant une revendication de volume persistante dans le CR KedaController.
Conditions préalables
- Le Custom Metrics Autoscaler Operator doit être installé.
Procédure
Éditer la ressource personnalisée KedaController pour ajouter l’auditConfig stanza:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le format de sortie du journal d’audit, qu’il s’agisse d’héritage ou de json.
- 2
- Indique une revendication existante de volume persistant pour stocker les données du journal. L’ensemble des demandes arrivant sur le serveur API sont enregistrées à cette revendication de volume persistante. Lorsque vous laissez ce champ vide, les données du journal sont envoyées à stdout.
- 3
- Indique quels événements doivent être enregistrés et quelles données ils doivent inclure:
- Aucun : Ne enregistrez pas les événements.
- Enregistrez uniquement les métadonnées pour la demande, telles que l’utilisateur, l’horodatage, et ainsi de suite. Il ne faut pas enregistrer le texte de demande et le texte de réponse. C’est la valeur par défaut.
- Demande : Logisez uniquement les métadonnées et le texte de demande, mais pas le texte de réponse. Cette option ne s’applique pas aux demandes de non-ressource.
- RequestResponse: Logiser les métadonnées d’événements, le texte de demande et le texte de réponse. Cette option ne s’applique pas aux demandes de non-ressource.
- 4
- Indique les étapes pour lesquelles aucun événement n’est créé.
- 5
- Indique s’il faut omettre les champs gérés des organismes de requête et de réponse d’être écrits dans le journal d’audit de l’API, que ce soit vrai pour omettre les champs ou faux pour inclure les champs.
- 6
- Indique la taille et la durée de vie des journaux d’audit.
- Le nombre maximum de jours pour conserver les fichiers journaux d’audit, basé sur l’horodatage encodé dans leur nom de fichier.
- sauvegarde max: Le nombre maximum de fichiers journaux d’audit à conserver. Définissez sur 0 pour conserver tous les fichiers journaux d’audit.
- La taille maximale en mégaoctets d’un fichier journal d’audit avant qu’il ne soit tourné.
La vérification
Consultez le fichier journal d’audit directement:
D’obtenir le nom de la gousse keda-metrics-apiserver-*:
oc get pod -n keda
oc get pod -n keda
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow Affichez les données du journal à l’aide d’une commande similaire à ce qui suit:
oc logs keda-metrics-apiserver-<hash>|grep -i metadata
$ oc logs keda-metrics-apiserver-<hash>|grep -i metadata
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Facultatif: Vous pouvez utiliser la commande grep pour spécifier le niveau de journal pour afficher: Metadata, Request, RequestResponse.
À titre d’exemple:
oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata
$ oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.28","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.28","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 Copied! Toggle word wrap Toggle overflow
Alternativement, vous pouvez consulter un journal spécifique:
À l’aide d’une commande similaire à ce qui suit pour vous connecter à la gousse keda-metrics-apiserver-*:
oc rsh pod/keda-metrics-apiserver-<hash> -n keda
$ oc rsh pod/keda-metrics-apiserver-<hash> -n keda
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n keda
$ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n keda
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Changement dans le répertoire /var/audit-policy/:
cd /var/audit-policy/
sh-4.4$ cd /var/audit-policy/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Liste des journaux disponibles:
ls
sh-4.4$ ls
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
log-2023.02.17-14:50 policy.yaml
log-2023.02.17-14:50 policy.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Consultez le journal, au besoin:
cat <log_name>/<pvc_name>|grep -i <log_level>
sh-4.4$ cat <log_name>/<pvc_name>|grep -i <log_level>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Facultatif: Vous pouvez utiliser la commande grep pour spécifier le niveau de journal pour afficher: Metadata, Request, RequestResponse.
À titre d’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 Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow
3.8. Collecte de données de débogage Copier lienLien copié sur presse-papiers!
Lors de l’ouverture d’un cas de support, il est utile de fournir des informations de débogage sur votre cluster à Red Hat Support.
Afin d’aider à résoudre votre problème, fournissez les informations suivantes:
- Données recueillies à l’aide de l’outil must-collectther.
- L’identifiant de cluster unique.
Il est possible d’utiliser l’outil must-collectther pour collecter des données sur l’opérateur automatique Custom Metrics et ses composants, y compris les éléments suivants:
- L’espace de noms keda et ses objets enfants.
- Les objets d’installation Custom Metric Autoscaler Operator.
- Le Custom Metric Autoscaler Operator CRD objets.
3.8.1. Collecte de données de débogage Copier lienLien copié sur presse-papiers!
La commande suivante exécute l’outil must-collectther pour l’opérateur automatique Custom Metrics:
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}')"
Le service standard Red Hat OpenShift sur la commande AWS must-collectther, oc adm must-collectther, ne collecte pas les données de Custom Metrics Autoscaler Operator.
Conditions préalables
- En tant qu’utilisateur, vous êtes connecté à Red Hat OpenShift Service sur AWS avec le rôle d’administrateur dédié.
- Le service Red Hat OpenShift sur AWS CLI (oc) installé.
Procédure
-
Accédez au répertoire dans lequel vous souhaitez stocker les données
must-gather
. Effectuer l’un des éléments suivants:
Afin d’obtenir uniquement les données requises par Custom Metrics Autoscaler Operator, 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 Copied! Toggle word wrap Toggle overflow L’image personnalisée de la commande must-collectther est tirée directement à partir du paquet Opérateur se manifeste, de sorte qu’elle fonctionne sur n’importe quel cluster où l’opérateur d’autoscale métrique personnalisé est disponible.
Afin de recueillir les données obligatoires par défaut en plus des informations personnalisées de l’opérateur d’autoscale métrique:
Faites appel à la commande suivante pour obtenir l’image Custom Metrics Autoscaler Operator et définissez-la en tant que 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 Copied! Toggle word wrap Toggle overflow Employez l’adm oc must-collectther 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 Copied! Toggle word wrap Toggle overflow
Exemple 3.1. Exemple de sortie must-collectther pour le Custom Metric Autoscaler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez un fichier compressé à partir du répertoire must-collectther qui a été créé dans votre répertoire de travail. À titre d’exemple, sur un ordinateur qui utilise 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 Copied! Toggle word wrap Toggle overflow - 1
- Le nom du répertoire est remplacé par must-collectther-local.5421342344627712289/.
- Attachez le fichier compressé à votre dossier d’assistance sur le portail client Red Hat.
3.9. Affichage des métriques de l’opérateur Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator expose les mesures prêtes à l’emploi qu’il tire du composant de surveillance on-cluster. Il est possible d’interroger les métriques en utilisant le Prometheus Query Language (PromQL) pour analyser et diagnostiquer les problèmes. L’ensemble des métriques sont réinitialisés lorsque le pod de contrôleur redémarre.
3.9.1. Accès aux métriques de performance Copier lienLien copié sur presse-papiers!
Accédez aux métriques et exécutez des requêtes à l’aide du service Red Hat OpenShift sur la console web AWS.
Procédure
- Choisissez la perspective administrateur dans Red Hat OpenShift Service sur la console web AWS.
- Choisissez Observer → Metrics.
- Afin de créer une requête personnalisée, ajoutez votre requête PromQL au champ Expression.
- Afin d’ajouter plusieurs requêtes, sélectionnez Ajouter une requête.
3.9.1.1. Fourni métriques de l’opérateur Copier lienLien copié sur presse-papiers!
Le Custom Metrics Autoscaler Operator expose les mesures suivantes, que vous pouvez afficher en utilisant le service Red Hat OpenShift sur la console web AWS.
Le nom métrique | Description |
---|---|
| La question de savoir si l’échelleur est actif ou inactif. La valeur de 1 indique que la mise à l’échelle est active; une valeur de 0 indique que l’échelle est inactive. |
| La valeur actuelle de la métrique de chaque échelleur, qui est utilisée par le Horizontal Pod Autoscaler (HPA) dans le calcul de la moyenne cible. |
| La latence de récupérer la métrique actuelle de chaque échelle. |
| Le nombre d’erreurs qui se sont produites pour chaque échelleur. |
| Le nombre total d’erreurs rencontrées pour tous les écailles. |
| Le nombre d’erreurs survenues pour chaque obejct échelonné. |
| Le nombre total de ressources personnalisées de Custom Metrics Autoscaler dans chaque espace de noms pour chaque type de ressource personnalisée. |
| Le nombre total de déclencheurs par type de déclencheur. |
Custom Metrics Autoscaler Admission webhook métriques
Le Custom Metrics Autoscaler Admission webhook expose également les métriques Prometheus suivantes.
Le nom métrique | Description |
---|---|
| Le nombre de validations d’objets mis à l’échelle. |
| Le nombre d’erreurs de validation. |
3.10. Comprendre comment ajouter des métriques personnalisées autoscalers Copier lienLien copié sur presse-papiers!
Afin d’ajouter un programmeur automatique de mesures personnalisées, créez une ressource personnalisée ScaledObject pour un déploiement, un ensemble d’état ou une ressource personnalisée. Créez une ressource personnalisée ScaledJob pour un travail.
Il est possible de créer un seul objet à l’échelle pour chaque charge de travail que vous souhaitez mettre à l’échelle. En outre, vous ne pouvez pas utiliser un objet mis à l’échelle et le pod horizontal autoscaler (HPA) sur la même charge de travail.
3.10.1. Ajout d’un autoscaler de mesures personnalisées à une charge de travail Copier lienLien copié sur presse-papiers!
Il est possible de créer un programmeur automatique de mesures personnalisées pour une charge de travail créée par un objet de déploiement, StatefulSet ou une ressource personnalisée.
Conditions préalables
- Le Custom Metrics Autoscaler Operator doit être installé.
B) Si vous utilisez un autoscaleur de mesures personnalisées pour la mise à l’échelle basée sur CPU ou mémoire:
L’administrateur de votre cluster doit avoir des métriques de cluster correctement configurées. La commande PodMetrics <pod-name> permet de déterminer si les métriques sont configurées. Lorsque les métriques sont configurées, la sortie apparaît similaire à ce qui suit, avec CPU et mémoire affichés sous Utilisation.
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 Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Les pods associés à l’objet que vous souhaitez mettre à l’échelle doivent inclure des limites de mémoire et de CPU spécifiées. À titre d’exemple:
Exemple pod spec
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procédure
Créez un fichier YAML similaire à ce qui suit. Le nom <2>, le nom de l’objet <4> et le type d’objet <5> sont seulement requis:
Exemple d’objet mis à l’échelle
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Facultatif : Spécifie que le Custom Metrics Autoscaler Operator est de mettre à l’échelle les répliques à la valeur spécifiée et d’arrêter l’autoscaling, comme décrit dans la section "Pause les métriques personnalisées autoscaler pour une charge de travail".
- 2
- Indique un nom pour cet autoscaleur de mesures personnalisées.
- 3
- Facultatif : Spécifie la version API de la ressource cible. La valeur par défaut est apps/v1.
- 4
- Indique le nom de l’objet que vous souhaitez mettre à l’échelle.
- 5
- Indique le type de déploiement, StatefulSet ou CustomResource.
- 6
- Facultatif: Spécifie le nom du conteneur dans la ressource cible, à partir de laquelle les métriques personnalisées autoscaler obtient des variables d’environnement contenant des secrets et ainsi de suite. La valeur par défaut est .spec.template.spec.containers[0].
- 7
- En option. Indique la période en secondes à attendre après que le dernier déclencheur soit signalé avant de mettre à l’échelle le déploiement à 0 si le minReplicaCount est réglé 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 mise à l’échelle.
- 10
- Facultatif : Spécifie les paramètres des journaux d’audit tels que décrits dans la section « Configuring Audit logging ».
- 11
- Facultatif: Spécifie le nombre de répliques à revenir si un échelleur ne parvient pas à obtenir des métriques de la source pour le nombre de fois défini par le paramètre failThreshold. Consultez la documentation KEDA pour plus d’informations sur le comportement de repli.
- 12
- Facultatif: Spécifie l’intervalle en quelques secondes pour vérifier chaque déclencheur. La valeur par défaut est 30.
- 13
- Facultatif : Spécifie s’il faut remonter la ressource cible au nombre de répliques d’origine après que l’objet mis à l’échelle a été supprimé. La valeur par défaut est false, ce qui maintient 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 pour mettre à l’échelle des pods vers le haut ou vers le bas, comme décrit dans la section « Politiques de mise à l’échelle ».
- 16
- Indique le déclencheur à utiliser comme base de mise à l’échelle, comme décrit dans la section « Comprendre les déclencheurs automatiques de mesures personnalisées ». Cet exemple utilise Red Hat OpenShift Service sur la surveillance AWS.
- 17
- Facultatif: Spécifie une authentification de déclencheur ou une authentification de déclenchement de cluster. En savoir plus, consultez Comprendre les métriques personnalisées autoscaler l’authentification dans la section Ressources supplémentaires.
- Entrez TriggerAuthentication pour utiliser une authentification de déclenchement. C’est la valeur par défaut.
- Entrez ClusterTriggerAuthentication pour utiliser une authentification de déclencheur de cluster.
Créez les métriques personnalisées autoscaler en exécutant la commande suivante:
oc create -f <filename>.yaml
$ oc create -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Afficher la sortie de commande pour vérifier que l’autoscaler des métriques personnalisées a été créé:
oc get scaledobject <scaled_object_name>
$ oc get scaledobject <scaled_object_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow A noter les champs suivants dans la sortie:
- TRIGGERS: Indique le déclencheur, ou l’échelle, qui est utilisé.
- AUTHENTICATION : Indique le nom de toute authentification de déclenchement utilisée.
LIRE: Indique si l’objet mis à l’échelle est prêt à commencer la mise à l’échelle:
- Dans l’affirmative, l’objet mis à l’échelle est prêt.
- En cas de faux, 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 a lieu:
- Et si c’est vrai, l’échelle est en cours.
- Dans le cas de False, la mise à l’échelle n’a pas lieu parce qu’il n’y a pas de mesures ou qu’il y a un problème dans un ou plusieurs des objets que vous avez créés.
FALLBACK: Indique si l’échelleur automatique de mesures personnalisées est capable d’obtenir des métriques à partir de la source
- Dans le cas de False, l’autoscaleur de mesures personnalisées obtient des métriques.
- Dans le cas de True, l’autoscaler des métriques personnalisées obtient des métriques 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.
3.11. La suppression de l’opérateur d’autoscale de Metrics personnalisé Copier lienLien copié sur presse-papiers!
Il est possible de supprimer l’échelle automatique de mesures personnalisées de votre Red Hat OpenShift Service sur le cluster AWS. Après avoir supprimé l’opérateur automatique de mesure personnalisée, retirez d’autres composants associés à l’opérateur pour éviter les problèmes potentiels.
Supprimez d’abord la ressource personnalisée KedaController (CR). Lorsque vous ne supprimez pas le KedaController CR, Red Hat OpenShift Service sur AWS peut accrocher lorsque vous supprimez le projet keda. En supprimant Custom Metrics Autoscaler Operator avant de supprimer le CR, vous n’êtes pas en mesure de supprimer le CR.
3.11.1. Désinstaller Custom Metrics Autoscaler Operator Copier lienLien copié sur presse-papiers!
Appliquez la procédure suivante pour supprimer les mesures personnalisées autoscaler de votre Red Hat OpenShift Service sur AWS cluster.
Conditions préalables
- Le Custom Metrics Autoscaler Operator doit être installé.
Procédure
- Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → Opérateurs installés.
- Basculez vers le projet keda.
Supprimez la ressource personnalisée KedaController.
- Cherchez l’opérateur CustomMetricsAutoscaler et cliquez sur l’onglet KedaController.
- Cherchez la ressource personnalisée, puis cliquez sur Supprimer KedaController.
- Cliquez sur Désinstaller.
Enlever le Custom Metrics Autoscaler Operator:
- Cliquez sur Opérateurs → Opérateurs installés.
- Cherchez l’opérateur CustomMetricsAutoscaler et cliquez sur le menu Options et sélectionnez Opérateur de désinstallation.
- Cliquez sur Désinstaller.
Facultatif: Utilisez le CLI OpenShift pour supprimer les composants autoscaleurs personnalisés:
Effacer les métriques personnalisées autoscaler CRDs:
-
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
$ oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La suppression des CRD supprime les rôles associés, les rôles de cluster et les liens de rôle. Cependant, il peut y avoir quelques rôles de cluster qui doivent être supprimés manuellement.
-
Liste des rôles de cluster autoscaler de mesures personnalisées:
oc get clusterrole | grep keda.sh
$ oc get clusterrole | grep keda.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Supprimez les rôles de cluster autoscaler de mesures personnalisées listés. À titre d’exemple:
oc delete clusterrole.keda.sh-v1alpha1-admin
$ oc delete clusterrole.keda.sh-v1alpha1-admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Liste de toutes les liaisons de rôle de cluster autoscaler personnalisées:
oc get clusterrolebinding | grep keda.sh
$ oc get clusterrolebinding | grep keda.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Supprimez les liaisons de rôle de cluster autoscaler personnalisées listées. À titre d’exemple:
oc delete clusterrolebinding.keda.sh-v1alpha1-admin
$ oc delete clusterrolebinding.keda.sh-v1alpha1-admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Effacer le projet d’autoscaler de mesures personnalisées:
oc delete project keda
$ oc delete project keda
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Effacer le Cluster Metric Autoscaler Operator:
oc delete operator/openshift-custom-metrics-autoscaler-operator.keda
$ oc delete operator/openshift-custom-metrics-autoscaler-operator.keda
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapitre 4. Contrôle du placement de la gousse sur les nœuds (programmation) Copier lienLien copié sur presse-papiers!
4.1. Contrôler le placement de la gousse à l’aide du planificateur Copier lienLien copié sur presse-papiers!
La planification des pod est un processus interne qui détermine le placement de nouvelles gousses sur les nœuds à l’intérieur du cluster.
Le code du programmeur a une séparation propre qui regarde les nouveaux pods au fur et à mesure qu’ils sont créés et identifie le nœud le plus approprié pour les héberger. Il crée ensuite des liaisons (pod à nœud) pour les pods à l’aide de l’API principale.
- Calendrier des pod par défaut
- Le service OpenShift Red Hat sur AWS est livré avec un programmeur 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 le meilleur ajustement pour un pod.
- Calendrier avancé des gousses
Dans les situations où vous pourriez vouloir plus de contrôle sur l’endroit où de nouveaux pods sont placés, le Red Hat OpenShift Service sur AWS fonctionnalités de planification avancées vous permettent de configurer un pod de sorte que le pod est requis ou a une préférence pour fonctionner sur un nœud particulier ou à côté d’un pod spécifique.
Il est possible de contrôler l’emplacement des pod en utilisant les fonctions de planification suivantes:
4.1.1. À propos du planificateur par défaut Copier lienLien copié sur presse-papiers!
Le Red Hat OpenShift Service par défaut sur AWS Pod scheduler est responsable de déterminer le placement de nouveaux pods sur les nœuds dans le cluster. Il lit les données du pod et trouve un nœud qui est un bon ajustement basé sur des profils configurés. Il est complètement indépendant et existe en tant que solution autonome. Il ne modifie pas la gousse; il crée une liaison pour la gousse qui lie la gousse au nœud particulier.
4.1.1.1. Comprendre la planification par défaut Copier lienLien copié sur presse-papiers!
Le planificateur générique existant est le moteur de planification fourni par la plate-forme par défaut qui sélectionne un nœud pour héberger le pod dans une opération en trois étapes:
- Filtre les nœuds
- Les nœuds disponibles sont filtrés en fonction des contraintes ou des exigences spécifiées. Cela se fait en exécutant chaque nœud à travers la liste des fonctions de filtre appelées prédicats, ou filtres.
- Priorise la liste filtrée des nœuds
- Ceci est réalisé en passant chaque nœud à travers une série de fonctions prioritaires, ou de notation, qui lui attribuent un score entre 0 - 10, avec 0 indiquant un mauvais ajustement et 10 indiquant un bon ajustement pour héberger le pod. La configuration du planning peut également prendre un poids simple (valeur numérique positive) pour chaque fonction de notation. Le score de nœud fourni par chaque fonction de notation est multiplié par le poids (poids par défaut pour la plupart des scores est 1), puis combiné en ajoutant les scores pour chaque nœud fourni par tous les scores. Cet attribut poids peut être utilisé par les administrateurs pour donner une plus grande importance à certains scores.
- Sélectionne le nœud le mieux adapté
- Les nœuds sont triés en fonction de leurs scores et le nœud avec le score le plus élevé est sélectionné pour héberger le pod. Lorsque plusieurs nœuds ont le même score élevé, l’un d’entre eux est sélectionné au hasard.
4.1.2. Cas d’utilisation du programmeur Copier lienLien copié sur presse-papiers!
L’un des cas d’utilisation importants pour la planification dans Red Hat OpenShift Service sur AWS est de prendre en charge des politiques d’affinité et de lutte contre l’affinité flexibles.
4.1.2.1. Affinité Copier lienLien copié sur presse-papiers!
Les administrateurs devraient être en mesure de configurer le programmeur pour spécifier l’affinité à n’importe quel niveau topologique, ou même à 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 gère toutes les exigences de latence des applications en permettant aux administrateurs de s’assurer que les pairs ne finissent pas par être trop séparés géographiquement. Dans le cas où aucun nœud n’est disponible au sein du même groupe d’affinité pour héberger la gousse, la gousse n’est pas programmée.
Lorsque vous avez besoin d’un plus grand contrôle sur l’endroit où les gousses sont programmées, consultez le placement de la gousse de contrôle sur les nœuds en utilisant les règles d’affinité des nœuds et les gousses de placement par rapport à d’autres gousses en utilisant des règles d’affinité et d’anti-affinité.
Ces fonctionnalités de planification avancée permettent aux administrateurs de spécifier quel nœud un pod peut être programmé et de forcer ou de rejeter la planification par rapport aux autres pods.
4.1.2.2. Anti-affinité Copier lienLien copié sur presse-papiers!
Les administrateurs devraient être en mesure de configurer le programmeur pour spécifier l’anti-affinité à n’importe quel niveau topologique, ou même à plusieurs niveaux. L’anti-affinité (ou « propagation ») à un niveau particulier indique que tous les pods appartenant au même service sont répartis entre les nœuds qui appartiennent à ce niveau. Cela garantit que l’application est bien répartie à des fins de haute disponibilité. Le planificateur essaie d’équilibrer les pods de service sur tous les nœuds applicables aussi uniformément que possible.
Lorsque vous avez besoin d’un plus grand contrôle sur l’endroit où les gousses sont programmées, consultez le placement de la gousse de contrôle sur les nœuds en utilisant les règles d’affinité des nœuds et les gousses de placement par rapport à d’autres gousses en utilisant des règles d’affinité et d’anti-affinité.
Ces fonctionnalités de planification avancée permettent aux administrateurs de spécifier quel nœud un pod peut être programmé et de forcer ou de rejeter la planification par rapport aux autres pods.
4.2. Placer des gousses par rapport à d’autres gousses en utilisant des règles d’affinité et d’anti-affinité Copier lienLien copié sur presse-papiers!
Affinité est une propriété de pods qui contrôle les nœuds sur lesquels ils préfèrent être programmés. L’anti-affinité est une propriété de gousses qui empêche une gousse d’être programmée sur un nœud.
Dans Red Hat OpenShift Service sur AWS, l’affinité de pod et la pod anti-affinité vous permettent de limiter les nœuds que votre pod est éligible pour être programmé sur la base des étiquettes de valeur clé sur d’autres gousses.
4.2.1. Comprendre l’affinité des gousses Copier lienLien copié sur presse-papiers!
L’affinité des pod et la pod anti-affinité vous permettent de limiter les nœuds sur lesquels votre pod est admissible à être programmé sur la base des étiquettes clé / valeur sur d’autres gousses.
- L’affinité des gousses peut indiquer au planificateur de localiser une nouvelle gousse sur le même nœud que les autres gousses si le sélecteur d’étiquettes sur la nouvelle gousse correspond à l’étiquette sur la gousse actuelle.
- La pod anti-affinité peut empêcher le planificateur de localiser une nouvelle gousse sur le même nœud que les gousses avec les mêmes étiquettes si le sélecteur d’étiquettes sur la nouvelle gousse correspond à l’étiquette sur la gousse actuelle.
À titre d’exemple, en utilisant des règles d’affinité, vous pouvez diffuser ou emballer des pods au sein d’un service ou par rapport à des pods dans d’autres services. Les règles anti-affinité vous permettent d’empêcher les pods d’un service particulier de planifier sur les mêmes nœuds que les pods d’un autre service qui sont connus pour interférer avec l’exécution des pods du premier service. De plus, vous pouvez répartir les pods 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.
Le sélecteur d’étiquettes peut correspondre à des pods avec plusieurs déploiements de pod. Employez des combinaisons uniques d’étiquettes lors de la configuration des règles anti-affinité pour éviter de faire correspondre les pods.
Il existe deux types de règles d’affinité de pod: requises et préférées.
Les règles requises doivent être respectées avant qu’un pod puisse être programmé sur un nœud. Les règles préférées précisent que, si la règle est respectée, le programmeur tente d’appliquer les règles, mais ne garantit pas l’exécution.
En fonction de votre priorité de pod et des paramètres de préemption, le planificateur peut ne pas être en mesure de trouver un nœud approprié pour un pod sans violer les exigences d’affinité. Dans l’affirmative, un pod pourrait ne pas être programmé.
Afin d’éviter cette situation, configurez soigneusement l’affinité des pods avec des pods de priorité égale.
Configurez l’affinité des pod/anti-affinité à travers les fichiers Pod spec. Il est possible de spécifier une règle requise, une règle préférée ou les deux. Lorsque vous spécifiez les deux, le nœud doit d’abord respecter la règle requise, puis tente de respecter la règle préférée.
L’exemple suivant montre un Pod spec configuré pour l’affinité des pod et anti-affinité.
Dans cet exemple, la règle d’affinité des pod indique que le pod ne peut programmer sur un nœud que si ce nœud a au moins un pod déjà en cours d’exécution avec une étiquette qui a la sécurité clé et la valeur S1. La règle anti-affinité de pod dit que la gousse préfère ne pas programmer sur un nœud si ce nœud est déjà en train d’exécuter un pod avec une étiquette ayant la sécurité clé et la valeur S2.
Exemple de fichier de configuration Pod avec affinité de pod
- 1
- La strophe pour configurer l’affinité des pod.
- 2
- Définit une règle requise.
- 3 5
- La clé et la valeur (étiquette) qui doivent être assorties pour appliquer la règle.
- 4
- L’opérateur représente la relation entre l’étiquette sur la gousse existante et l’ensemble de valeurs dans les paramètres de correspondanceExpression dans la spécification du nouveau pod. Il peut être dans, NotIn, existe ou n’existe pas.
Exemple de fichier de configuration Pod avec pod anti-affinité
- 1
- Configuration de la pod anti-affinité.
- 2
- Définit une règle préférée.
- 3
- Indique un poids pour une règle préférée. Le nœud avec le poids le plus élevé est préféré.
- 4
- Description de l’étiquette de pod qui détermine quand la règle anti-affinité s’applique. Indiquez une clé et une valeur pour l’étiquette.
- 5
- L’opérateur représente la relation entre l’étiquette sur la gousse existante et l’ensemble de valeurs dans les paramètres de correspondanceExpression dans la spécification du nouveau pod. Il peut être dans, NotIn, existe ou n’existe pas.
Lorsque les étiquettes sur un nœud changent au moment de l’exécution, de telle sorte que les règles d’affinité sur une gousse ne sont plus respectées, la gousse continue de fonctionner sur le nœud.
4.2.2. Configuration d’une règle d’affinité de pod Copier lienLien copié sur presse-papiers!
Les étapes suivantes démontrent une configuration simple à deux pod qui crée un pod avec une étiquette et une gousse qui utilise l’affinité pour permettre la planification avec cette gousse.
Il est impossible d’ajouter une affinité directement à un pod programmé.
Procédure
Créer un pod avec une étiquette spécifique dans le pod spec:
Créez un fichier YAML avec le contenu suivant:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod.
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lors de la création d’autres pods, configurez les paramètres suivants pour ajouter l’affinité:
Créez un fichier YAML avec le contenu suivant:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoute une affinité de gousse.
- 2
- Configure le paramètre requisDuringSchedulingIgnoredDuringExecution ou le paramètre préféréDuringSchedulingIgnoredDuringExecution.
- 3
- Indique la clé et les valeurs qui doivent être remplies. Lorsque vous souhaitez que la nouvelle gousse soit programmée avec l’autre pod, utilisez les mêmes paramètres de clé et de valeurs que l’étiquette sur le premier pod.
- 4
- Indique un opérateur. L’opérateur peut être dans, NotIn, existant ou ne pas exister. À titre d’exemple, utilisez l’opérateur In pour exiger que l’étiquette soit dans le nœud.
- 5
- Indiquez une topologyKey, qui est un label Kubernetes prépeuplé que le système utilise pour désigner un tel domaine de topologie.
Créez le pod.
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.3. Configuration d’une règle anti-affinité de pod Copier lienLien copié sur presse-papiers!
Les étapes suivantes démontrent une configuration simple à deux pod qui crée un pod avec une étiquette et un pod qui utilise une règle préférée anti-affinité pour tenter d’empêcher la planification avec ce pod.
Il est impossible d’ajouter une affinité directement à un pod programmé.
Procédure
Créer un pod avec une étiquette spécifique dans le pod spec:
Créez un fichier YAML avec le contenu suivant:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod.
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lors de la création d’autres pods, configurez les paramètres suivants:
Créez un fichier YAML avec le contenu suivant:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoute une pod anti-affinité.
- 2
- Configure le paramètre requisDuringSchedulingIgnoredDuringExecution ou le paramètre préféréDuringSchedulingIgnoredDuringExecution.
- 3
- Dans le cas d’une règle préférée, spécifie un poids pour le nœud, 1-100. Le nœud qui a le poids le plus élevé est préféré.
- 4
- Indique la clé et les valeurs qui doivent être remplies. Lorsque vous voulez que le nouveau pod ne soit pas programmé avec l’autre pod, utilisez les mêmes paramètres de clé et de valeurs que l’étiquette sur la première gousse.
- 5
- Indique un opérateur. L’opérateur peut être dans, NotIn, existant ou ne pas exister. À titre d’exemple, utilisez l’opérateur In pour exiger que l’étiquette soit dans le nœud.
- 6
- Indique une topologyKey, qui est un label Kubernetes prépeuplé que le système utilise pour désigner un tel domaine de topologie.
Créez le pod.
oc create -f <pod-spec>.yaml
$ oc create -f <pod-spec>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.4. Les règles d’affinité et d’anti-affinité des gousses d’échantillons Copier lienLien copié sur presse-papiers!
Les exemples suivants démontrent l’affinité des pod et la pod anti-affinité.
4.2.4.1. Affinité des pod Copier lienLien copié sur presse-papiers!
L’exemple suivant montre l’affinité des pod pour les gousses avec des étiquettes et des sélecteurs d’étiquettes assortis.
L’équipe de pod4 a l’équipe de label:4.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod team4a a l’équipe de sélecteur d’étiquettes:4 sous PodAffinity.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Le pod team4a est prévu sur le même nœud que le groupe Team4.
4.2.4.2. Anti-affinité de pod Copier lienLien copié sur presse-papiers!
L’exemple suivant montre la pod anti-affinité pour les gousses avec des étiquettes assorties et des sélecteurs d’étiquettes.
Le pod-s1 a la sécurité de l’étiquette:s1.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod pod-s2 a le sélecteur d’étiquette de sécurité:s1 sous PodAntiAffinity.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Le pod-s2 ne peut pas être programmé sur le même nœud que pod-s1.
4.2.4.3. Affinité de pod sans étiquettes correspondantes Copier lienLien copié sur presse-papiers!
L’exemple suivant montre l’affinité des pods pour les gousses sans assortir les étiquettes et les sélecteurs d’étiquettes.
Le pod-s1 a la sécurité de l’étiquette:s1.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod pod-s2 a la sécurité du sélecteur d’étiquettes:s2.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod-s2 n’est pas programmé à moins qu’il n’y ait un nœud avec un pod qui a l’étiquette de sécurité:s2. Lorsqu’il n’y a pas d’autre pod avec cette étiquette, la nouvelle gousse reste dans un état 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 Copied! Toggle word wrap Toggle overflow
4.3. Contrôle du placement de la gousse sur les nœuds en utilisant les règles d’affinité des nœuds Copier lienLien copié sur presse-papiers!
Affinité est une propriété de pods qui contrôle les nœuds sur lesquels ils préfèrent être programmés.
Dans Red Hat OpenShift Service sur AWS Node affinity est un ensemble de règles utilisées par le programmeur 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 les sélecteurs d’étiquettes spécifiés dans les pods.
4.3.1. Comprendre l’affinité des nœuds Copier lienLien copié sur presse-papiers!
L’affinité des nœuds permet à un pod de spécifier une affinité vers un groupe de nœuds sur lequel il peut être placé. Le nœud n’a pas de contrôle sur le placement.
À titre d’exemple, vous pouvez configurer un pod pour fonctionner uniquement sur un nœud avec un CPU spécifique ou dans une zone de disponibilité spécifique.
Il existe deux types de règles d’affinité des nœuds : requises et préférées.
Les règles requises doivent être respectées avant qu’un pod puisse être programmé sur un nœud. Les règles préférées précisent que, si la règle est respectée, le programmeur tente d’appliquer les règles, mais ne garantit pas l’exécution.
Lorsque les étiquettes sur un nœud changent au moment de l’exécution, ce qui entraîne une règle d’affinité des nœuds sur une gousse n’est plus respectée, la gousse continue de fonctionner sur le nœud.
Configurez l’affinité des nœuds via le fichier Pod spec. Il est possible de spécifier une règle requise, une règle préférée ou les deux. Lorsque vous spécifiez les deux, le nœud doit d’abord respecter la règle requise, puis tente de respecter la règle préférée.
L’exemple suivant est un Pod spec 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 e2e-az-North ou e2e-az-South:
Exemple de fichier de configuration de pod avec une règle d’affinité de nœud requise
- 1
- La strophe pour configurer l’affinité des nœuds.
- 2
- Définit une règle requise.
- 3 5 6
- La paire clé/valeur (étiquette) qui doit être assortie pour appliquer la règle.
- 4
- L’opérateur représente la relation entre l’étiquette sur le nœud et l’ensemble de valeurs dans les paramètres de correspondanceExpression dans la spécification Pod. Cette valeur peut être In, NotIn, Exist ou NeesNotExist, Lt, ou Gt.
L’exemple suivant est une spécification de nœud avec une règle préférée selon laquelle un nœud avec une étiquette dont la clé est e2e-az-East et dont la valeur est e2e-az-East ou e2e-az-West est préféré pour le pod:
Exemple de fichier de configuration de pod avec une règle d’affinité préférée des nœuds
- 1
- La strophe pour configurer l’affinité des nœuds.
- 2
- Définit une règle préférée.
- 3
- Indique un poids pour une règle préférée. Le nœud avec le poids le plus élevé est préféré.
- 4 6 7
- La paire clé/valeur (étiquette) qui doit être assortie pour appliquer la règle.
- 5
- L’opérateur représente la relation entre l’étiquette sur le nœud et l’ensemble de valeurs dans les paramètres de correspondanceExpression dans la spécification Pod. Cette valeur peut être In, NotIn, Exist ou NeesNotExist, Lt, ou Gt.
Il n’y a pas de concept explicite d’anti-affinité de nœud, mais l’utilisation de l’opérateur NotIn ou DoesNotExist reproduit ce comportement.
Lorsque vous utilisez des sélecteurs d’affinité des nœuds et de nœuds dans la même configuration, notez ce qui suit:
- Lorsque vous configurez à la fois nodeSelector et nodeAffinity, les deux conditions doivent être remplies pour que la gousse soit programmée sur un nœud candidat.
- Lorsque vous spécifiez plusieurs nodeSelectorTerms associés aux types nodeAffinity, le pod peut être programmé sur un nœud si l’un des nodeSelectorTerms est satisfait.
- Lorsque vous spécifiez plusieurs correspondancesExpressions associées à nodeSelectorTerms, le pod ne peut être programmé sur un nœud que si toutes les correspondancesExpressions sont satisfaites.
4.3.2. Configuration d’une règle d’affinité de nœud requise Copier lienLien copié sur presse-papiers!
Les règles requises doivent être respectées avant qu’un pod puisse être programmé sur un nœud.
Procédure
Les étapes suivantes démontrent une configuration simple qui crée un nœud et un pod que le programmeur est tenu de placer sur le nœud.
Créer un pod avec une étiquette spécifique dans le pod spec:
Créez un fichier YAML avec le contenu suivant:
NoteIl est impossible d’ajouter une affinité directement à un pod programmé.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoute une affinité de gousse.
- 2
- Configure le paramètre requisDuringSchedulingIgnoredDuringExecution.
- 3
- Indique la clé et les valeurs qui doivent être remplies. Lorsque vous souhaitez que le nouveau pod soit programmé sur le nœud que vous avez modifié, utilisez les mêmes paramètres de clé et de valeurs que l’étiquette dans le nœud.
- 4
- Indique un opérateur. L’opérateur peut être dans, NotIn, existant ou ne pas exister. À titre d’exemple, utilisez l’opérateur In pour exiger que l’étiquette soit dans le nœud.
Créer le pod:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.3. Configuration d’une règle d’affinité des nœuds préféré Copier lienLien copié sur presse-papiers!
Les règles préférées précisent que, si la règle est respectée, le programmeur tente d’appliquer les règles, mais ne garantit pas l’exécution.
Procédure
Les étapes suivantes démontrent une configuration simple qui crée un nœud et un pod que le planificateur essaie de placer sur le nœud.
Créer un pod avec une étiquette spécifique:
Créez un fichier YAML avec le contenu suivant:
NoteIl est impossible d’ajouter une affinité directement à un pod programmé.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoute une affinité de gousse.
- 2
- Configure le paramètre préféréDuringSchedulingIgnoredDuringExecution.
- 3
- Indique un poids pour le nœud, en tant que numéro 1-100. Le nœud avec le poids le plus élevé est préféré.
- 4
- Indique la clé et les valeurs qui doivent être remplies. Lorsque vous souhaitez que le nouveau pod soit programmé sur le nœud que vous avez modifié, utilisez les mêmes paramètres de clé et de valeurs que l’étiquette dans le nœud.
- 5
- Indique un opérateur. L’opérateur peut être dans, NotIn, existant ou ne pas exister. À titre d’exemple, utilisez l’opérateur In pour exiger que l’étiquette soit dans le nœud.
Créez le pod.
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.4. Exemple de règles d’affinité des nœuds Copier lienLien copié sur presse-papiers!
Les exemples suivants démontrent l’affinité des nœuds.
4.3.4.1. Affinité des nœuds avec les étiquettes correspondantes Copier lienLien copié sur presse-papiers!
L’exemple suivant démontre l’affinité des nœuds pour un nœud et un pod avec des étiquettes assorties:
Le nœud Node1 a la zone d’étiquette:us:
oc label node node1 zone=us
$ oc label node node1 zone=us
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour ajouter l’étiquette:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod-s1 pod a la zone et nous avons la paire clé/valeur en vertu d’une règle d’affinité de nœud requise:
cat pod-s1.yaml
$ cat pod-s1.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod-s1 peut être programmé sur Node1:
oc get pod -o wide
$ oc get pod -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow
4.3.4.2. Affinité des nœuds sans étiquettes correspondantes Copier lienLien copié sur presse-papiers!
L’exemple suivant démontre l’affinité des nœuds pour un nœud et un pod sans étiquettes correspondantes:
Le nœud Node1 a la zone d’étiquette:emea:
oc label node node1 zone=emea
$ oc label node node1 zone=emea
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour ajouter l’étiquette:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod-s1 pod a la zone et nous avons la paire clé/valeur en vertu d’une règle d’affinité de nœud requise:
cat pod-s1.yaml
$ cat pod-s1.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le pod-s1 ne peut pas être programmé sur Node1:
oc describe pod pod-s1
$ oc describe pod pod-s1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. En plaçant des gousses sur des nœuds surengagés Copier lienLien copié sur presse-papiers!
Dans un état surengagé, la somme du conteneur calcule les demandes et les limites de ressources dépasse les ressources disponibles sur le système. Des engagements excessifs pourraient être souhaitables dans les environnements de développement où un compromis de performance garantie pour la capacité est acceptable.
Les requêtes et les limites permettent aux administrateurs d’autoriser et de gérer l’engagement excessif des ressources sur un nœud. Le planificateur utilise des demandes pour planifier votre conteneur et fournir une garantie de service minimale. Les limites limitent la quantité de ressources de calcul qui peuvent être consommées sur votre nœud.
4.4.1. Comprendre le surengagement Copier lienLien copié sur presse-papiers!
Les requêtes et les limites permettent aux administrateurs d’autoriser et de gérer l’engagement excessif des ressources sur un nœud. Le planificateur utilise des demandes pour planifier votre conteneur et fournir une garantie de service minimale. Les limites limitent la quantité de ressources de calcul qui peuvent être consommées sur votre nœud.
Le service OpenShift Red Hat sur AWS peut contrôler le niveau de surengagement et gérer la densité des conteneurs sur les nœuds en configurant les maîtres pour outrepasser le rapport entre la requête et la limite définie sur les conteneurs développeurs. En conjonction avec un objet LimitRange par projet spécifiant les limites et les valeurs par défaut, cela ajuste la limite de conteneur et demande pour atteindre le niveau souhaité de surengagement.
Ces dépassements n’ont aucun effet si aucune limite n’a été fixée sur les conteneurs. Créez un objet LimitRange avec des limites par défaut, par projet individuel ou dans le modèle de projet, pour s’assurer que les dépassements s’appliquent.
Après ces dépassements, les limites de conteneur et les demandes 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 alors dépassée en dessous de la limite minimale, ce qui rend la pod interdite. Cette expérience utilisateur malheureuse devrait être traitée avec un travail futur, mais pour l’instant, configurez cette capacité et les objets LimitRange avec prudence.
4.4.2. Comprendre les nœuds surengagement Copier lienLien copié sur presse-papiers!
Dans un environnement surengagé, il est important de configurer correctement votre nœud pour fournir le meilleur comportement du système.
Lorsque le nœud démarre, il s’assure que les drapeaux tunables du noyau pour la gestion de la mémoire sont correctement définis. Le noyau ne devrait jamais échouer aux allocations de mémoire à moins qu’il ne soit épuisé de mémoire physique.
Afin d’assurer ce comportement, Red Hat OpenShift Service sur AWS configure le noyau pour toujours surengager la mémoire en définissant le paramètre vm.overcommit_memory sur 1, outrepassant le paramètre système d’exploitation par défaut.
Le service OpenShift Red Hat sur AWS configure également le noyau pour ne pas paniquer lorsqu’il n’est plus en mémoire en définissant le paramètre vm.panic_on_oom à 0. Le paramètre 0 ordonne au noyau d’appeler oom_killer dans une condition hors mémoire (OOM), qui tue les processus en fonction de la priorité.
En exécutant les commandes suivantes sur vos nœuds, vous pouvez afficher le paramètre actuel:
sysctl -a |grep commit
$ sysctl -a |grep commit
Exemple de sortie
#... vm.overcommit_memory = 0 #...
#...
vm.overcommit_memory = 0
#...
sysctl -a |grep panic
$ sysctl -a |grep panic
Exemple de sortie
#... vm.panic_on_oom = 0 #...
#...
vm.panic_on_oom = 0
#...
Les drapeaux ci-dessus doivent déjà être fixés sur les nœuds, et aucune autre action n’est requise.
Il est également possible d’effectuer les configurations suivantes pour chaque nœud:
- Désactiver ou appliquer les limites CPU en utilisant les quotas CPU CFS
- Des ressources de réserve pour les processus du système
- La mémoire de réserve à travers les niveaux de qualité de service
4.5. Placer des pods sur des nœuds spécifiques à l’aide de sélecteurs de nœuds Copier lienLien copié sur presse-papiers!
Le sélecteur de nœuds spécifie une carte des paires de clés/valeurs qui sont définies à l’aide d’étiquettes personnalisées sur les nœuds et les sélecteurs spécifiés dans les pods.
Afin que la gousse puisse fonctionner sur un nœud, la gousse doit avoir le même sélecteur de nœud clé/valeur que l’étiquette sur le nœud.
4.5.1. À propos des sélecteurs de nœuds Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser des sélecteurs de nœuds sur les gousses et les étiquettes sur les nœuds pour contrôler l’endroit où la gousse est programmée. Avec les sélecteurs de nœuds, Red Hat OpenShift Service sur AWS programme les pods sur les nœuds qui contiennent des étiquettes correspondantes.
Il est possible d’utiliser un sélecteur de nœuds 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.
En tant qu’administrateur de cluster, par exemple, vous pouvez créer une infrastructure où 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œuds 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, étiquetez les nœuds comme nous-est, nous-central, ou nous-ouest. Dans la région Asie-Pacifique (APAC), étiqueter les nœuds comme apac-est ou apac-west. Les développeurs peuvent ajouter un sélecteur de nœuds aux gousses qu’ils créent pour s’assurer que les gousses sont programmées sur ces nœuds.
La pod n’est pas programmée si l’objet Pod contient un sélecteur de nœuds, mais le nœud a une étiquette correspondante.
Lorsque vous utilisez les sélecteurs de nœuds et l’affinité des nœuds dans la même configuration, les règles suivantes contrôlent le placement des pod sur les nœuds:
- Lorsque vous configurez à la fois nodeSelector et nodeAffinity, les deux conditions doivent être remplies pour que la gousse soit programmée sur un nœud candidat.
- Lorsque vous spécifiez plusieurs nodeSelectorTerms associés aux types nodeAffinity, le pod peut être programmé sur un nœud si l’un des nodeSelectorTerms est satisfait.
- Lorsque vous spécifiez plusieurs correspondancesExpressions associées à nodeSelectorTerms, le pod ne peut être programmé sur un nœud que si toutes les correspondancesExpressions sont satisfaites.
- Les sélecteurs de nœuds sur des gousses et nœuds spécifiques
Il est possible de contrôler quel nœud est programmé en utilisant des sélecteurs de nœuds et des étiquettes.
Afin d’utiliser des sélecteurs de nœuds et des étiquettes, d’abord étiqueter le nœud pour éviter que les gousses ne soient décalées, puis ajouter le sélecteur de nœud à la gousse.
NoteIl n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant. Il faut étiqueter l’objet qui contrôle la pod, comme la configuration de déploiement.
À titre d’exemple, l’objet Node suivant a la région:
Échantillon d’objet Node avec une étiquette
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Étiquettes pour correspondre au sélecteur de nœud de pod.
A pod a le type: user-node,région: sélecteur de nœud est:
Échantillon d’objet Pod avec sélecteurs de nœuds
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Les sélecteurs de nœuds correspondent à 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 l’exemple pod spec, il peut être programmé sur le nœud d’exemple.
- Les sélecteurs par défaut de nœuds à l’échelle du cluster
Avec les sélecteurs de nœuds larges par défaut, lorsque vous créez un pod dans ce cluster, Red Hat OpenShift Service sur AWS ajoute les sélecteurs de nœuds par défaut au pod et programme le pod sur les nœuds avec des étiquettes correspondantes.
À titre d’exemple, l’objet Scheduler suivant a la région par défaut de cluster=Est et type=node-utilisateur sélecteur:
Exemple d’opérateur de programmeur de ressources personnalisées
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans ce cluster, un nœud a le type= user-node,region=East Labels:
Exemple d’objet Node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple Pod objet avec un sélecteur de nœud
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque vous créez le pod à l’aide de l’exemple pod spec dans le cluster d’exemples, le pod est créé avec le sélecteur de nœud de cluster-large et est programmé sur le nœud étiqueté:
Exemple de pod list avec la gousse 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 Copied! Toggle word wrap Toggle overflow NoteLorsque le projet où vous créez le pod a un sélecteur de nœud de projet, ce sélecteur prend la préférence sur un sélecteur de nœuds à l’échelle du cluster. Le pod n’est pas créé ou programmé si le pod n’a pas le sélecteur de nœud de projet.
- Les 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, Red Hat OpenShift Service sur AWS ajoute les sélecteurs de nœuds au pod et programme les pods sur un nœud avec des étiquettes correspondantes. Lorsqu’il existe un sélecteur de nœuds par défaut à l’échelle du cluster, un sélecteur de nœud de projet prend la préférence.
À titre d’exemple, le projet suivant a le sélecteur de nœud région=Est:
Exemple d’objet Namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le nœud suivant a le type=nœud utilisateur,région=est étiquettes:
Exemple d’objet Node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque vous créez le pod à l’aide de l’exemple pod spec dans ce projet d’exemple, le pod est créé avec les sélecteurs de nœud de projet et est programmé sur le nœud étiqueté:
Exemple d’objet Pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de pod list avec la gousse 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 Copied! Toggle word wrap Toggle overflow Dans le projet, un pod n’est pas créé ou programmé si le pod contient différents sélecteurs de nœuds. À titre d’exemple, si vous déployez la pod suivante dans le projet d’exemple, il n’est pas créé:
Exemple d’objet Pod avec un sélecteur de nœud invalide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.2. En utilisant des sélecteurs de nœuds pour contrôler le placement des pod Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser des sélecteurs de nœuds sur les gousses et les étiquettes sur les nœuds pour contrôler l’endroit où la gousse est programmée. Avec les sélecteurs de nœuds, Red Hat OpenShift Service sur AWS programme les pods sur les nœuds qui contiennent des étiquettes correspondantes.
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 la machine de calcul garantit que si le nœud ou la machine descend, les nouveaux nœuds ont l’étiquette. Les étiquettes ajoutées à un nœud ou à une configuration de machine ne persistent pas si le nœud ou la machine descend.
Ajouter des sélecteurs de nœuds à un pod existant, ajouter un sélecteur de nœud à l’objet de contrôle pour ce pod, tel qu’un objet ReplicaSet, DaemonSet objet, StatefulSet objet, Deployment object, ou DeploymentConfig objet. Les gousses existantes sous cet objet de contrôle sont recréées sur un nœud avec une étiquette correspondante. Lorsque vous créez un nouveau pod, vous pouvez ajouter le sélecteur de nœud directement au pod spec. Dans le cas où le pod n’a pas d’objet de contrôle, vous devez supprimer le pod, modifier la spécification du pod et recréer le pod.
Il n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant.
Conditions préalables
Afin d’ajouter un sélecteur de nœud à des pods existants, déterminez l’objet de contrôle de ce pod. À titre d’exemple, la gousse routeur-default-66d5cf9464-m2g75 est contrôlée par la réplique routeur-default-66d5cf9464:
oc describe pod router-default-66d5cf9464-7pwkc
$ oc describe pod router-default-66d5cf9464-7pwkc
Exemple de sortie
La console web répertorie l’objet de contrôle sous OwnerReferences dans le pod YAML:
Procédure
Ajouter le sélecteur de nœud correspondant à un pod:
Ajouter un sélecteur de nœuds aux pods existants et futurs, ajouter un sélecteur de nœud à l’objet de contrôle pour les pods:
Exemple ReplicaSet objet avec des étiquettes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoutez le sélecteur de nœud.
Ajouter un sélecteur de nœud à un nouveau pod spécifique, ajouter le sélecteur directement à l’objet Pod:
Exemple Pod objet avec un sélecteur de nœud
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIl n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant.
4.6. Contrôler le placement des gousses en utilisant des contraintes de propagation de la topologie des pods Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser des contraintes de propagation de la topologie pod pour fournir un contrôle fin sur le placement de vos gousses sur les nœuds, les zones, les régions ou d’autres domaines de topologie définis par l’utilisateur. Distribuer des pods à travers les domaines d’échec peut aider à atteindre une disponibilité élevée et une utilisation plus efficace des ressources.
4.6.1. Exemples de cas d’utilisation Copier lienLien copié sur presse-papiers!
- En tant qu’administrateur, je veux que ma charge de travail s’étende automatiquement entre deux à quinze pods. Je veux m’assurer que lorsqu’il n’y a que deux gousses, elles ne sont pas placées sur le même nœud, pour éviter un seul point d’échec.
- En tant qu’administrateur, je veux répartir mes pods uniformément sur plusieurs zones d’infrastructure afin de réduire la latence et les coûts de réseau. Je veux m’assurer que mon cluster peut s’auto-guérir si des problèmes se posent.
4.6.2. Considérations importantes Copier lienLien copié sur presse-papiers!
- Les pods d’un Red Hat OpenShift Service sur le cluster AWS sont gérés par des contrôleurs de charge de travail tels que des déploiements, des ensembles étatiques ou des ensembles de démons. Ces contrôleurs définissent l’état souhaité pour un groupe de pods, y compris la façon dont ils sont distribués et mis à l’échelle à travers les nœuds du cluster. Il faut définir les mêmes contraintes de la topologie des gousses sur toutes les gousses d’un groupe afin d’éviter toute confusion. Lors de l’utilisation d’un contrôleur de charge de travail, tel qu’un déploiement, le modèle de pod gère généralement cela pour vous.
- Le mélange de différentes contraintes de propagation de la topologie des pod peut rendre Red Hat OpenShift Service sur le comportement AWS déroutant et dépannage plus difficile. Il est possible d’éviter cela en veillant à ce que tous les nœuds d’un domaine de topologie soient systématiquement étiquetés. Le service OpenShift Red Hat sur AWS affiche automatiquement des étiquettes bien connues, telles que kubernetes.io/hostname. Cela permet d’éviter la nécessité d’un étiquetage manuel des nœuds. Ces étiquettes fournissent des informations de topologie essentielles, assurant une étiquetage uniforme des nœuds dans l’ensemble du cluster.
- En raison d’une contrainte, seuls les pods dans le même espace de noms sont appariés et regroupés ensemble lors de la propagation.
- Il est possible de spécifier plusieurs contraintes de propagation de la topologie des pods, mais vous devez vous assurer qu’elles ne sont pas en conflit les uns avec les autres. Les contraintes de propagation de la topologie des gousses doivent être satisfaites pour qu’une gousse soit placée.
4.6.3. Comprendre l’oscillation et maxSkew Copier lienLien copié sur presse-papiers!
Le skew fait référence à la différence dans le nombre de pods qui correspondent à un sélecteur d’étiquette spécifié dans différents domaines de topologie, tels que les zones ou les nœuds.
L’oscillation est calculée pour chaque domaine en prenant la différence absolue entre le nombre de pods dans ce domaine et le nombre de pods dans le domaine avec le plus faible nombre de pods programmés. La définition d’une valeur maxSkew guide le planificateur pour maintenir une répartition équilibrée des pod.
4.6.3.1. Exemple de calcul biaisé Copier lienLien copié sur presse-papiers!
Il y a trois zones (A, B et C) et vous voulez répartir vos gousses uniformément sur ces zones. Lorsque la zone A a 5 gousses, la zone B a 3 gousses, et la zone C a 2 gousses, pour trouver l’équitation, vous pouvez soustraire le nombre de gousses dans le domaine avec la plus faible quantité de gousses programmées du nombre de gousses actuellement dans chaque zone. Cela signifie que l’oscillation pour la zone A est 3, l’oscillation pour la zone B est 1, et l’oscillation pour la zone C est 0.
4.6.3.2. Le paramètre maxSkew Copier lienLien copié sur presse-papiers!
Le paramètre maxSkew définit la différence maximale admissible, ou biaisé, dans le nombre de pods entre deux domaines de topologie. Lorsque maxSkew est défini à 1, le nombre de pods dans n’importe quel domaine de topologie ne doit pas différer de plus de 1 de tout autre domaine. Lorsque l’oscillation dépasse maxSkew, le planificateur tente de placer de nouvelles gousses d’une manière qui réduit l’oscillation, en adhérant aux contraintes.
À l’aide de l’exemple précédent, les valeurs d’axe dépassent la valeur maxSkew par défaut de 1. Le planificateur place de nouvelles gousses dans les zones B et C afin de réduire l’oscillation et d’obtenir une répartition plus équilibrée, en veillant à ce qu’aucun domaine de topologie ne dépasse l’écart de 1.
4.6.4. Exemples de configurations pour les contraintes de propagation de la topologie des pod Copier lienLien copié sur presse-papiers!
Il est possible de spécifier les pods à regrouper, quels domaines de topologie ils sont répartis entre eux, et l’oscillation acceptable.
Les exemples suivants montrent les configurations de contrainte de propagation de la topologie pod.
Exemple pour distribuer des pods qui correspondent aux étiquettes spécifiées en fonction de leur zone
- 1
- La différence maximale de nombre de pods entre deux domaines de topologie. La valeur par défaut est 1, et vous ne pouvez pas spécifier une valeur de 0.
- 2
- La clé d’une étiquette de nœud. Les nœuds avec cette clé et cette valeur identique sont considérés comme étant dans la même topologie.
- 3
- Comment gérer une gousse si elle ne satisfait pas à la contrainte de propagation. La valeur par défaut est DoNotSchedule, qui indique au planificateur de ne pas programmer le pod. Définissez sur ScheduleAnyway pour toujours programmer le pod, mais le programmeur donne la priorité à honorer l’oscillation pour ne pas rendre le cluster plus déséquilibré.
- 4
- Les pods qui correspondent à ce sélecteur d’étiquettes sont comptés et reconnus comme un groupe lors de la propagation pour satisfaire la contrainte. Assurez-vous de spécifier un sélecteur d’étiquette, sinon aucun pods ne peut être assorti.
- 5
- Assurez-vous que cette spécification Pod définit également ses étiquettes pour correspondre à ce sélecteur d’étiquettes si vous voulez qu’il soit correctement compté à l’avenir.
- 6
- Liste des touches d’étiquette de pod pour sélectionner les gousses à calculer.
Exemple de démonstration d’une contrainte de propagation de la topologie unique de la gousse
L’exemple précédent définit un Pod spec avec une contrainte de propagation topologique d’une pod. Il correspond sur les gousses étiquetées région: us-est, distribue entre les zones, spécifie une biais de 1, et ne programme pas la gousse si elle ne répond pas à ces exigences.
Exemple démontrant les contraintes de propagation de la topologie des pod multiples
L’exemple précédent définit un Pod spec avec deux contraintes de propagation de la topologie de la pod. Les deux correspondent sur les gousses étiquetées région: us-est, spécifiez une biais de 1, et ne planifiez pas la gousse si elle ne répond pas à ces exigences.
La première contrainte distribue des pods en fonction d’un nœud d’étiquette défini par l’utilisateur, et la deuxième contrainte distribue des pods en fonction d’un rack d’étiquettes défini par l’utilisateur. Les deux contraintes doivent être remplies pour que la pod soit programmée.
Chapitre 5. À l’aide d’emplois et de jeux de démons Copier lienLien copié sur presse-papiers!
5.1. Exécuter des tâches d’arrière-plan sur les nœuds automatiquement avec les ensembles de démons Copier lienLien copié sur presse-papiers!
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 tous les nœuds d’un Red Hat OpenShift Service sur le cluster AWS.
Le jeu de démon garantit que tous les nœuds (ou certains) exécutent une copie d’un pod. Comme les nœuds sont ajoutés au cluster, des pods sont ajoutés au cluster. Comme les nœuds sont retirés de l’amas, ces gousses sont enlevées par collecte des ordures. La suppression d’un jeu de démons nettoiera les gousses qu’il a créées.
Il est possible d’utiliser des ensembles de démons pour créer un stockage partagé, exécuter un pod de journalisation sur tous les nœuds de votre cluster ou déployer un agent de surveillance sur chaque nœud.
Les administrateurs de cluster et les administrateurs de projet peuvent pour des raisons de sécurité créer des ensembles de démons.
Consultez la documentation Kubernetes pour plus d’informations sur les ensembles de démons.
La programmation du jeu de démon est incompatible avec le sélecteur de nœud par défaut du projet. Lorsque vous ne le désactivez pas, le jeu de démon est limité en fusionnant avec le sélecteur de nœud par défaut. Il en résulte une recréation fréquente de la gousse sur les nœuds qui n’ont pas été sélectionnés par le sélecteur de nœud fusionné, ce qui à son tour met une charge indésirable sur le cluster.
5.1.1. Programmé par défaut de planification Copier lienLien copié sur presse-papiers!
L’ensemble de démons garantit que tous les nœuds éligibles exécutent une copie d’un pod. Habituellement, le nœud sur lequel un pod fonctionne est sélectionné par le planificateur Kubernetes. Cependant, les gousses de jeu de démon sont créées et programmées par le contrôleur de jeu de démon. Cela pose les questions suivantes:
- Comportement des gousses incohérentes: Les gousses normales qui attendent d’être programmées sont créées et dans l’état en attente, mais les gousses de jeu de démons ne sont pas créées dans l’état en attente. C’est déroutant pour l’utilisateur.
- La préemption de Pod est gérée par le programmeur par défaut. Lorsque la préemption est activée, le contrôleur de jeu de démon prendra des décisions de planification sans tenir compte de la priorité et de la préemption des pod.
La fonction ScheduleDaemonSetPods, activée par défaut dans Red Hat OpenShift Service sur AWS, vous permet de programmer les jeux de démons en utilisant le programmateur par défaut au lieu du contrôleur de jeu de démon, en ajoutant le terme NodeAffinity aux pods de jeu de démons, au lieu du terme spec.nodeName. Le planificateur par défaut est ensuite utilisé pour lier le pod à l’hôte cible. Lorsque l’affinité des nœuds de la gousse de démon existe déjà, elle est remplacée. Le contrôleur de jeu de démon effectue uniquement ces opérations lors de la création ou de la modification de gousses de jeu de démons, et aucune modification n’est apportée à la spéc.template de l’ensemble de démon.
De plus, un node.kubernetes.io/unschedulable:NoSchedule tolérance est ajouté automatiquement aux pods de daemon. Le programmeur par défaut ignore les nœuds imprévus lors de la planification des gousses de jeu de démons.
5.1.2. Créer des démons Copier lienLien copié sur presse-papiers!
Lors de la création de jeux de démons, le champ nodeSelector est utilisé pour indiquer les nœuds sur lesquels le jeu de démon devrait déployer des répliques.
Conditions préalables
Avant de commencer à utiliser les jeux de démons, désactivez le sélecteur de nœuds par défaut dans votre espace de noms, en définissant l’annotation openshift.io/node-selector de l’espace de noms sur 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 Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour désactiver le sélecteur de nœud par défaut à l’échelle du projet pour un espace de noms:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procédure
Créer un jeu de démon:
Définir le fichier daemon set yaml:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le sélecteur d’étiquette qui détermine quels pods appartiennent à l’ensemble de démons.
- 2
- Le sélecteur d’étiquette du modèle de pod. Doit correspondre au sélecteur d’étiquette ci-dessus.
- 3
- Le sélecteur de nœuds qui détermine sur quels nœuds les répliques de pod doivent être déployés. L’étiquette correspondante doit être présente sur le nœud.
Créer l’objet de jeu de démon:
oc create -f daemonset.yaml
$ oc create -f daemonset.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afin de vérifier que les gousses ont été créées, et que chaque nœud a une réplique de pod:
Découvrez les gousses de daemonset:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copied! Toggle word wrap Toggle overflow Afficher les gousses pour vérifier que la gousse a été placée sur le nœud:
oc describe pod/hello-daemonset-cx6md|grep Node
$ oc describe pod/hello-daemonset-cx6md|grep Node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Node: openshift-node01.hostname.com/10.14.20.134
Node: openshift-node01.hostname.com/10.14.20.134
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe pod/hello-daemonset-e3md9|grep Node
$ oc describe pod/hello-daemonset-e3md9|grep Node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Node: openshift-node02.hostname.com/10.14.20.137
Node: openshift-node02.hostname.com/10.14.20.137
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- En cas de mise à jour d’un modèle de pod daemon, les répliques de pod existantes ne sont pas affectées.
- Lorsque vous supprimez un jeu de démons, puis créez un nouveau jeu de démons avec un modèle différent mais le même sélecteur d’étiquettes, il reconnaît que les répliques de gousses existantes ont des étiquettes correspondantes et ne les met pas à jour ou ne crée pas de nouvelles répliques malgré une inadéquation dans le modèle de pod.
- Lorsque vous changez d’étiquettes de nœuds, le jeu de démons ajoute des pods aux nœuds qui correspondent aux nouvelles étiquettes et supprime les pods des nœuds qui ne correspondent pas aux nouvelles étiquettes.
Afin de mettre à jour un jeu de démons, forcez de nouvelles répliques de gousses à être créées en supprimant les anciennes répliques ou nœuds.
5.2. Exécution de tâches dans des pods à l’aide d’emplois Copier lienLien copié sur presse-papiers!
Le travail exécute une tâche dans votre service Red Hat OpenShift sur le cluster AWS.
Le travail suit l’avancement global 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 travail nettoie toutes les répliques de gousses 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 spécification d’emploi
- 1
- Les répliques de la gousse doivent être exécutées en parallèle.
- 2
- Des achèvements réussis de la pod sont nécessaires pour marquer un travail accompli.
- 3
- La durée maximale du travail peut être exécutée.
- 4
- Le nombre de retries pour un emploi.
- 5
- Le modèle pour le pod créé par le contrôleur.
- 6
- La politique de redémarrage du pod.
Ressources supplémentaires
- Emplois dans la documentation Kubernetes
5.2.1. Comprendre les emplois et les emplois cron Copier lienLien copié sur presse-papiers!
Le travail suit l’avancement global 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 travail nettoie toutes les gousses 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.
Il existe deux types de ressources possibles qui permettent de créer des objets en cours d’exécution dans Red Hat OpenShift Service sur AWS:
- Emploi
Le travail régulier est un objet qui crée une tâche et assure la fin du travail.
Il existe trois principaux types de tâches appropriées à exécuter en tant que travail:
Emplois non parallèles:
- C’est un travail qui ne commence qu’un seul pod, à moins que la gousse échoue.
- Le travail est terminé dès que son pod se termine avec succès.
Emplois parallèles avec un nombre d’achèvements fixes:
- C’est un travail qui commence plusieurs pods.
- Le travail représente la tâche globale et est terminé lorsqu’il y a un pod réussi pour chaque valeur de la gamme 1 à la valeur d’achèvement.
Emplois parallèles avec une file d’attente de travail:
- Emploi avec plusieurs processus parallèles d’ouvrier dans une gousse donnée.
- Des pods de coordonnées Red Hat OpenShift Service sur AWS pour déterminer sur quoi chacun devrait fonctionner ou utiliser un service de file d’attente externe.
- Chaque gousse est indépendamment capable de déterminer si toutes les gousses de pairs sont complètes et que l’ensemble du travail est fait.
- Lorsque n’importe quelle gousse du travail se termine avec succès, aucune nouvelle gousse n’est créée.
- Lorsqu’au moins une gousse a pris fin avec succès et que toutes les gousses sont terminées, le travail est terminé avec succès.
Lorsqu’une gousse est sortie avec succès, aucune autre gousse ne devrait faire de travail pour cette tâche ou écrire une sortie. Les gousses devraient tous être en train de sortir.
En savoir plus sur la façon d’utiliser les différents types d’emploi, consultez Job Patterns dans la documentation Kubernetes.
- Cron job
Le travail peut être programmé pour fonctionner plusieurs fois, en utilisant un travail cron.
Le travail cron s’appuie sur un travail régulier 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 emplois Cron peuvent également planifier des tâches individuelles pour une période spécifique, par exemple si vous souhaitez planifier un emploi pour une période d’activité faible. Le travail cron crée un objet Job basé sur le fuseau horaire configuré sur le nœud de plan de contrôle qui exécute le contrôleur cronjob.
AvertissementLe travail cron crée un objet Job environ une fois par heure d’exécution de son calendrier, mais il y a des circonstances dans lesquelles il ne crée pas un emploi ou deux emplois pourraient être créés. Les emplois doivent donc être idempotents et vous devez configurer des limites d’historique.
5.2.1.1. Comprendre comment créer des emplois Copier lienLien copié sur presse-papiers!
Les deux types de ressources nécessitent une configuration de travail qui se compose des parties clés suivantes:
- Il s’agit d’un modèle de pod, qui décrit le pod que Red Hat OpenShift Service crée sur AWS.
Le paramètre parallélisme, qui spécifie combien de pods fonctionnant en parallèle à n’importe quel moment dans le temps doit exécuter une tâche.
- Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
Le paramètre d’achèvement, spécifiant le nombre d’achèvements réussis de la pod sont nécessaires pour terminer un travail.
- Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
- Dans le cas des tâches parallèles avec un nombre d’achèvements fixes, spécifiez une valeur.
- Dans le cas des tâches parallèles avec une file d’attente de travail, laissez tomber. Lorsque l’unset est par défaut à la valeur par parallélisme.
5.2.1.2. Comprendre comment fixer une durée maximale pour les emplois Copier lienLien copié sur presse-papiers!
Lors de la définition d’une tâche, vous pouvez définir sa durée maximale en définissant le champ ActiveDeadlineSeconds. Il est spécifié en secondes et n’est pas défini par défaut. Lorsqu’il n’est pas défini, il n’y a pas de durée maximale appliquée.
La durée maximale est comptée à partir du moment où un premier pod est programmé dans le système, et définit combien de temps un travail peut être actif. Il suit le temps global d’une exécution. Après avoir atteint le délai spécifié, le travail est résilié par Red Hat OpenShift Service sur AWS.
5.2.1.3. Comprendre comment mettre un emploi à l’écart de la politique pour l’échec de la pod Copier lienLien copié sur presse-papiers!
Le travail peut être considéré comme ayant échoué, après un certain nombre de retries en raison d’une erreur logique dans la configuration ou d’autres raisons similaires. Les gousses échouées associées au travail sont recréées par le contrôleur avec un retard exponentiel (10s, 20s, 40s…) plafonné à six minutes. La limite est réinitialisée si aucun nouveau pod raté n’apparaît entre les contrôles du contrôleur.
Le paramètre spec.backoffLimit permet de définir le nombre de retries pour une tâche.
5.2.1.4. Comprendre comment configurer une tâche cron pour supprimer des artefacts Copier lienLien copié sur presse-papiers!
Les emplois cron peuvent laisser derrière eux des ressources d’artefacts telles que des emplois ou des pods. En tant qu’utilisateur, il est important de configurer les limites de l’historique afin que les anciens travaux et leurs gousses soient correctement nettoyés. Il y a deux domaines dans la spécification de cron qui en est responsable:
- .spec.successfulJobsHistoryLimit. Le nombre d’emplois terminés réussis à conserver (par défaut à 3).
- .spec.failedJobsHistoryLimit. Le nombre d’emplois terminés à conserver (par défaut à 1).
5.2.1.5. Limites connues Copier lienLien copié sur presse-papiers!
La politique de redémarrage de la spécification des tâches ne s’applique qu’aux pods, et non au contrôleur d’emploi. Cependant, le contrôleur d’emploi est codé dur pour continuer à réessayer les tâches jusqu’à l’achèvement.
En tant que tel, redémarrerPolicy: Ne jamais ou --restart=N’entraîne jamais le même comportement que redémarrerPolicy: OnFailure ou --restart=OnFailure. Autrement dit, lorsqu’un travail échoue, il est redémarré automatiquement jusqu’à ce qu’il réussisse (ou qu’il soit abandonné manuellement). La stratégie définit uniquement quel sous-système effectue le redémarrage.
Avec la politique Never, le contrôleur de travail effectue le redémarrage. À chaque tentative, le contrôleur de travail augmente le nombre d’échecs dans le statut de l’emploi et crée de nouveaux pods. Cela signifie qu’à chaque tentative ratée, le nombre de gousses augmente.
Avec la politique OnFailure, kubelet effectue le redémarrage. Chaque tentative n’augmente pas le nombre d’échecs dans le statut de l’emploi. En outre, kubelet réessaiera les tâches échouées en commençant des pods sur les mêmes nœuds.
5.2.2. Créer des emplois Copier lienLien copié sur presse-papiers!
Créez un emploi dans Red Hat OpenShift Service sur AWS en créant un objet de travail.
Procédure
Créer un emploi:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Facultatif : Spécifiez le nombre de répliques de pod qu’une tâche devrait exécuter en parallèle; par défaut à 1.
- Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
- 2
- Facultatif: Spécifiez combien de réussites de la pod sont nécessaires pour marquer un travail terminé.
- Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
- Dans le cas des travaux parallèles avec un nombre d’achèvements fixes, spécifiez le nombre d’achèvements.
- Dans le cas des tâches parallèles avec une file d’attente de travail, laissez tomber. Lorsque l’unset est par défaut à la valeur par parallélisme.
- 3
- Facultatif: Spécifiez la durée maximale que le travail peut exécuter.
- 4
- Facultatif: Spécifiez le nombre de retries pour un travail. Ce champ est par défaut à six.
- 5
- Indiquez le modèle pour le pod que le contrôleur crée.
- 6
- Indiquez la politique de redémarrage du pod:
- Jamais. « ne redémarrez pas le travail.
- À l’échec. Redémarrez le travail seulement s’il échoue.
C’est toujours ça. Redémarrez toujours le travail.
En savoir plus sur la façon dont Red Hat OpenShift Service sur AWS utilise la stratégie de redémarrage avec des conteneurs défaillants, consultez l’exemple des États dans la documentation de Kubernetes.
Créer le job:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Il est également possible de créer et de lancer une tâche à partir d’une seule commande à l’aide d’oc create job. La commande suivante crée et lance une tâche similaire à celle spécifiée 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)'
5.2.3. Créer des emplois cron Copier lienLien copié sur presse-papiers!
Créez une tâche cron dans Red Hat OpenShift Service sur AWS en créant un objet de travail.
Procédure
Créer un travail cron:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Calendrier de la tâche spécifiée au format cron. Dans cet exemple, le travail fonctionnera chaque minute.
- 2
- C’est une politique facultative de concurrence qui spécifie comment traiter les emplois simultanés au sein d’un emploi cron. Il n’est possible de spécifier qu’une seule des politiques concurrentes suivantes. Dans le cas contraire, cela par défaut permet d’autoriser des exécutions simultanées.
- Autoriser les travaux cron à fonctionner simultanément.
- Interdit les courses simultanées, en sautant la prochaine course si la précédente n’est pas encore terminée.
- Le remplacement annule le travail en cours d’exécution et le remplace par un nouveau.
- 3
- Date limite facultative (en secondes) pour commencer le travail s’il manque l’heure prévue pour quelque raison que ce soit. Les exécutions d’emplois manquées seront comptabilisées comme ayant échoué. Dans le cas contraire, il n’y a pas de délai.
- 4
- Drapeau optionnel permettant la suspension d’un travail cron. En cas de définition de true, toutes les exécutions ultérieures seront suspendues.
- 5
- Le nombre d’emplois terminés réussis à conserver (par défaut à 3).
- 6
- Le nombre d’emplois terminés à conserver (par défaut à 1).
- 7
- Le modèle de travail. Ceci est similaire à l’exemple de travail.
- 8
- Définit une étiquette pour les emplois engendrés par ce travail cron.
- 9
- La politique de redémarrage du pod. Cela ne s’applique pas au contrôleur d’emploi.Note
Les champs .spec.successfulJobsHistoryLimit et .spec.failedJobsHistoryLimit sont facultatifs. Ces champs spécifient combien d’emplois terminés et échoués doivent être conservés. Ils sont définis par défaut sur 3 et 1 respectivement. Fixer une limite à 0 correspond à ne garder aucun du type de travail correspondant après avoir terminé.
Créer le travail cron:
oc create -f <file-name>.yaml
$ oc create -f <file-name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Il est également possible de créer et de lancer une tâche cron à partir d’une seule commande en utilisant oc create cronjob. La commande suivante crée et lance un travail cron similaire à celui spécifié 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)'
Avec oc créer cronjob, l’option --schedule accepte les horaires au format cron.
Chapitre 6. En travaillant avec les nœuds Copier lienLien copié sur presse-papiers!
6.1. Afficher et répertorier les nœuds dans votre Red Hat OpenShift Service sur AWS cluster Copier lienLien copié sur presse-papiers!
Liste de tous les nœuds de votre cluster pour 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 des nœuds, le CLI interagit avec les objets de nœud qui sont des représentations d’hébergeurs de nœuds réels. Le maître utilise les informations provenant d’objets de nœuds pour valider les nœuds avec des contrôles de santé.
6.1.1. À propos de la liste de tous les nœuds dans un cluster Copier lienLien copié sur presse-papiers!
Il est possible d’obtenir des informations détaillées sur les nœuds du cluster.
La commande suivante répertorie tous les nœuds:
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow L’exemple suivant est un cluster avec des nœuds sains:
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME STATUS ROLES AGE VERSION master.example.com Ready master 7h v1.31.3 node1.example.com Ready worker 7h v1.31.3 node2.example.com Ready worker 7h v1.31.3
NAME STATUS ROLES AGE VERSION master.example.com Ready master 7h v1.31.3 node1.example.com Ready worker 7h v1.31.3 node2.example.com Ready worker 7h v1.31.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow L’exemple suivant est un cluster avec un nœud malsain:
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME STATUS ROLES AGE VERSION master.example.com Ready master 7h v1.31.3 node1.example.com NotReady,SchedulingDisabled worker 7h v1.31.3 node2.example.com Ready worker 7h v1.31.3
NAME STATUS ROLES AGE VERSION master.example.com Ready master 7h v1.31.3 node1.example.com NotReady,SchedulingDisabled worker 7h v1.31.3 node2.example.com Ready worker 7h v1.31.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Les conditions qui déclenchent un statut NotReady sont affichées plus tard dans cette section.
L’option -o large fournit des informations supplémentaires sur les nœuds.
oc get nodes -o wide
$ oc get nodes -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.31.3 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.31.3-30.rhaos4.10.gitf2f339d.el8-dev node1.example.com Ready worker 72m v1.31.3 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.31.3-30.rhaos4.10.gitf2f339d.el8-dev node2.example.com Ready worker 164m v1.31.3 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.31.3-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.31.3 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.31.3-30.rhaos4.10.gitf2f339d.el8-dev node1.example.com Ready worker 72m v1.31.3 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.31.3-30.rhaos4.10.gitf2f339d.el8-dev node2.example.com Ready worker 164m v1.31.3 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.31.3-30.rhaos4.10.gitf2f339d.el8-dev
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La commande suivante répertorie des informations sur un seul nœud:
oc get node <node>
$ oc get node <node>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc get node node1.example.com
$ oc get node node1.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME STATUS ROLES AGE VERSION node1.example.com Ready worker 7h v1.31.3
NAME STATUS ROLES AGE VERSION node1.example.com Ready worker 7h v1.31.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La commande suivante fournit des informations plus détaillées sur un nœud spécifique, y compris la raison de la condition actuelle:
oc describe node <node>
$ oc describe node <node>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc describe node node1.example.com
$ oc describe node node1.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteL’exemple suivant contient certaines valeurs spécifiques au service Red Hat OpenShift sur AWS sur AWS.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le nom du nœud.
- 2
- Le rôle du nœud, que ce soit le maître ou l’ouvrier.
- 3
- Les étiquettes appliquées sur le nœud.
- 4
- Les annotations s’appliquaient au nœud.
- 5
- Les taintes s’appliquaient au nœud.
- 6
- Les conditions et le statut des nœuds. Les conditions stanza répertorient le statut Prêt, PIDPressure, MemoryPressure, DiskPressure et OutOfDisk. Cette condition est décrite plus loin dans cette section.
- 7
- L’adresse IP et le nom d’hôte du nœud.
- 8
- Les ressources pod et les ressources allocatables.
- 9
- Informations sur l’hôte du nœud.
- 10
- Les gousses sur le nœud.
- 11
- Les événements rapportés par le nœud.
Dans l’information affichée pour les nœuds, les conditions de nœud suivantes apparaissent dans la sortie des commandes affichées dans cette section:
État de l’état | Description |
---|---|
| Dans la mesure du possible, le nœud est sain et prêt à accepter les gousses. En cas de faux, le nœud n’est pas sain et n’accepte pas les gousses. En cas d’inconnu, le contrôleur du nœud n’a pas reçu de battement cardiaque du nœud pour la période node-monitor-grace-period (la valeur par défaut est de 40 secondes). |
| Lorsque c’est vrai, la capacité du disque est faible. |
| « si c’est vrai, la mémoire du nœud est faible. |
| « si c’est vrai, il y a trop de processus sur le nœud. |
| Dans l’affirmative, le nœud n’a pas suffisamment d’espace libre sur le nœud pour ajouter de nouveaux gousses. |
| Dans l’affirmative, le réseau du nœud n’est pas correctement configuré. |
| Dans l’affirmative, l’un des composants sous-jacents, tels que l’exécution du conteneur ou le réseau, connaît des problèmes ou n’est pas encore configuré. |
| Les gousses ne peuvent pas être programmées pour le placement sur le nœud. |
6.1.2. Liste des pods sur un nœud dans votre cluster Copier lienLien copié sur presse-papiers!
Il est possible de répertorier toutes les gousses sur un nœud spécifique.
Procédure
Liste de tous les pods ou des pods sélectionnés sur les nœuds sélectionnés:
oc get pod --selector=<nodeSelector>
$ oc get pod --selector=<nodeSelector>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pod --selector=kubernetes.io/os
$ oc get pod --selector=kubernetes.io/os
Copy to Clipboard Copied! Toggle word wrap Toggle overflow A) ou:
oc get pod -l=<nodeSelector>
$ oc get pod -l=<nodeSelector>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pod -l kubernetes.io/os=linux
$ oc get pod -l kubernetes.io/os=linux
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Énumérer toutes les gousses sur un nœud spécifique, y compris les gousses terminées:
oc get pod --all-namespaces --field-selector=spec.nodeName=<nodename>
$ oc get pod --all-namespaces --field-selector=spec.nodeName=<nodename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.3. Affichage des statistiques d’utilisation de la mémoire et du CPU sur vos nœuds Copier lienLien copié sur presse-papiers!
Il est possible d’afficher des statistiques d’utilisation sur les nœuds, qui fournissent les environnements d’exécution pour les conteneurs. Ces statistiques d’utilisation incluent CPU, mémoire et consommation de stockage.
Conditions préalables
- Il faut avoir l’autorisation de lire des clusters pour afficher les statistiques d’utilisation.
- Les métriques doivent être installées pour afficher les statistiques d’utilisation.
Procédure
Consulter les statistiques d’utilisation:
oc adm top nodes
$ oc adm top nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afficher les statistiques d’utilisation des nœuds avec des étiquettes:
oc adm top node --selector=''
$ oc adm top node --selector=''
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il faut choisir le sélecteur (requête d’étiquette) pour filtrer. Appuis =, ==, et !=.
6.2. En travaillant avec les nœuds Copier lienLien copié sur presse-papiers!
En tant qu’administrateur, vous pouvez effectuer plusieurs tâches pour rendre vos clusters plus efficaces. Il est possible d’utiliser la commande adm oc pour cordonner, uncordon et égoutter un nœud spécifique.
Le cordonnage et le drainage ne sont autorisés que sur les nœuds des travailleurs qui font partie des piscines de machines Red Hat OpenShift Cluster Manager.
6.2.1. Comprendre comment évacuer les pods sur les nœuds Copier lienLien copié sur presse-papiers!
Les gousses d’évacuation vous permettent de migrer toutes les gousses sélectionnées à partir d’un nœud ou d’un nœud donné.
Il est possible d’évacuer uniquement les pods 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 du(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. Il est possible d’évacuer un sous-ensemble de gousses en spécifiant un pod-selector. Les sélecteurs de pod sont basés sur des étiquettes, de sorte que toutes les gousses avec l’étiquette spécifiée seront évacuées.
Procédure
Indiquez les nœuds imprévus avant d’effectuer l’évacuation de la gousse.
Indiquez le nœud comme imprévu:
oc adm cordon <node1>
$ oc adm cordon <node1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
node/<node1> cordoned
node/<node1> cordoned
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que l’état du nœud est prêt, programmantDisabled:
oc get node <node1>
$ oc get node <node1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME STATUS ROLES AGE VERSION <node1> Ready,SchedulingDisabled worker 1d v1.31.3
NAME STATUS ROLES AGE VERSION <node1> Ready,SchedulingDisabled worker 1d v1.31.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Évacuer les gousses en utilisant l’une des méthodes suivantes:
Évacuer toutes les gousses sélectionnées sur un ou plusieurs nœuds:
oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
$ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Forcez la suppression des gousses nues en utilisant l’option --force. Lorsqu’il est défini sur true, la suppression continue même s’il y a des pods non gérés par un contrôleur de réplication, un ensemble de répliques, une tâche, un jeu de démons ou un ensemble étatique:
oc adm drain <node1> <node2> --force=true
$ oc adm drain <node1> <node2> --force=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Définissez une période de temps en secondes pour que chaque gousse se termine gracieusement, utilisez --grace-période. En cas de négatif, la valeur par défaut spécifiée dans le pod sera utilisée:
oc adm drain <node1> <node2> --grace-period=-1
$ oc adm drain <node1> <node2> --grace-period=-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignorez les gousses gérées par des ensembles de démons en utilisant le drapeau --ignore-daemonsets mis à vrai:
oc adm drain <node1> <node2> --ignore-daemonsets=true
$ oc adm drain <node1> <node2> --ignore-daemonsets=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Définissez la durée d’attente avant d’abandonner le drapeau --timeout. La valeur 0 définit une durée infinie:
oc adm drain <node1> <node2> --timeout=5s
$ oc adm drain <node1> <node2> --timeout=5s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Effacer les pods même s’il y a des pods utilisant des volumes emptyDir en définissant le drapeau --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
$ oc adm drain <node1> <node2> --delete-emptydir-data=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Liste des objets qui seront migrés sans effectuer réellement l’évacuation, en utilisant l’option --dry-run définie à true:
oc adm drain <node1> <node2> --dry-run=true
$ oc adm drain <node1> <node2> --dry-run=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 les nœuds sélectionnés.
Indiquez le nœud comme étant programmé lorsqu’il est fait.
oc adm uncordon <node1>
$ oc adm uncordon <node1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. À l’aide de l’opérateur de tuning de nœud Copier lienLien copié sur presse-papiers!
Apprenez-en plus sur l’opérateur de réglage des nœuds et comment vous pouvez l’utiliser pour gérer l’accord au niveau des nœuds en orchestreant le démon réglé.
But
L’opérateur de réglage des nœuds vous aide à gérer le réglage au niveau des nœuds en orchestreant le démon TuneD et permet d’obtenir des performances de faible latence en utilisant le contrôleur Performance Profile. La majorité des applications de haute performance nécessitent un certain niveau de réglage du noyau. Le Node Tuning Operator fournit une interface de gestion unifiée aux utilisateurs de sysctls de niveau nœud et plus de flexibilité pour ajouter un réglage personnalisé spécifié par les besoins de l’utilisateur.
L’opérateur gère le démon TuneD conteneurisé pour Red Hat OpenShift Service sur AWS en tant qu’ensemble de démon Kubernetes. Il garantit que la spécification de réglage personnalisé est transmise à tous les démons TuneD conteneurisés fonctionnant dans le cluster dans le format que les démons comprennent. Les démons s’exécutent sur tous les nœuds de l’amas, un par nœud.
Les paramètres de niveau nœud appliqués par le démon TuneD conteneurisé sont retournés sur un événement qui déclenche un changement de profil ou lorsque le démon TuneD conteneurisé est terminé gracieusement en recevant et en manipulant un signal de terminaison.
Le Node Tuning Operator utilise le contrôleur Performance Profile pour implémenter un réglage automatique afin d’obtenir des performances de latence faibles pour Red Hat OpenShift Service sur les applications AWS.
L’administrateur du cluster configure un profil de performance pour définir les paramètres de niveau des nœuds tels que les paramètres suivants:
- La mise à jour du noyau vers kernel-rt.
- Choisir des processeurs pour l’entretien ménager.
- Choisir des processeurs pour exécuter des charges de travail.
Le Node Tuning Operator fait partie d’un service standard Red Hat OpenShift sur l’installation AWS dans la version 4.1 et ultérieure.
Dans les versions antérieures de Red Hat OpenShift Service sur AWS, l’opérateur Performance Addon a été utilisé pour implémenter un réglage automatique afin d’obtenir des performances de latence faibles pour les applications OpenShift. Dans Red Hat OpenShift Service sur AWS 4.11 et plus tard, cette fonctionnalité fait partie de l’opérateur de Tuning Node.
6.3.1. Accéder à un exemple Spécification de Tuning de Node Operator Copier lienLien copié sur presse-papiers!
Ce processus permet d’accéder à un exemple de spécification de l’opérateur de tuning de nœud.
Procédure
Exécutez la commande suivante pour accéder à un exemple de spécification de l’opérateur de tuning de nœud:
oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator
oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Le CR par défaut est destiné à fournir un réglage standard au niveau des nœuds pour le service Red Hat OpenShift sur la plate-forme AWS et il ne peut être modifié que pour définir l’état de gestion de l’opérateur. Les autres modifications personnalisées apportées au CR par défaut seront annulées par l’opérateur. Créez vos propres CR Tuned pour un réglage personnalisé. Les CR nouvellement créés seront combinés avec le CR par défaut et le réglage personnalisé appliqué à Red Hat OpenShift Service sur les nœuds AWS basés sur les étiquettes de nœuds ou de pod et les priorités de profil.
Bien que dans certaines situations, le soutien pour les étiquettes de gousses puisse être un moyen pratique de fournir automatiquement l’accord requis, cette pratique est découragée et fortement conseillée, en particulier dans les clusters à grande échelle. Le CR par défaut Tuned CR est livré sans cod correspondant à l’étiquette. En cas de création d’un profil personnalisé avec la correspondance d’étiquettes de pod, la fonctionnalité sera activée à ce moment-là. La fonctionnalité de l’étiquette de pod sera dépréciée dans les futures versions de l’opérateur de tuning de nœud.
6.3.2. Caractéristiques d’accord personnalisé Copier lienLien copié sur presse-papiers!
La ressource personnalisée (CR) de l’opérateur comporte deux sections principales. La première section, profil:, est une liste de profils TuneD et de leurs noms. La seconde, recommande :, définit la logique de sélection du profil.
De multiples spécifications de réglage personnalisées peuvent coexister sous la forme de plusieurs CR 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. 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.
État de gestion
L’état de gestion de l’opérateur est défini en ajustant le CR par défaut Tuned CR. L’opérateur est par défaut dans l’état géré et le champ spec.managementState n’est pas présent dans le CR par défaut Tuned CR. Les valeurs valides pour l’état de gestion de l’opérateur sont les suivantes:
- Géré : l’opérateur mettra à jour ses opérandes à mesure que les ressources de configuration sont mises à jour
- Non géré : l’opérateur ignorera les modifications apportées aux ressources de configuration
- Supprimé : l’Opérateur supprimera ses opérandes et ses ressources que l’Opérateur a fournies
Données de profil
Le profil: section répertorie les profils TuneD et leurs noms.
Les profils recommandés
Le profil : la logique de sélection est définie par la recommandation : section du CR. La section recommandée est une liste d’éléments pour recommander les profils en fonction de critères de sélection.
recommend: <recommend-item-1> # ... <recommend-item-n>
recommend:
<recommend-item-1>
# ...
<recommend-item-n>
Les différents éléments de la liste:
- 1
- En option.
- 2
- Dictionnaire des étiquettes key/value MachineConfig. Les clés doivent être uniques.
- 3
- En cas d’omission, une correspondance de profil est supposée à moins qu’un profil ayant une priorité supérieure ne corresponde en premier ou que machineConfigLabels ne soit définie.
- 4
- Liste facultative.
- 5
- La priorité de la commande de profil. Les chiffres inférieurs signifient une priorité plus élevée (0 est la priorité la plus élevée).
- 6
- A profil TuneD à appliquer sur un match. A titre d’exemple, tuned_profile_1.
- 7
- Configuration optionnelle d’opérande.
- 8
- Activez ou éteignez le débogage pour le démon TuneD. Les options sont vraies pour on ou false for off. La valeur par défaut est fausse.
- 9
- Activez ou désactivez la fonctionnalité reapply_sysctl pour le démon TuneD. Les options sont vraies et fausses pour l’off.
<match> est une liste facultative définie de manière récursive comme suit:
- label: <label_name> value: <label_value> type: <label_type> <match>
- label: <label_name>
value: <label_value>
type: <label_type>
<match>
Lorsque <match> n’est pas omis, toutes les sections imbriquées <match> doivent également évaluer à true. Dans le cas contraire, false est supposé et le profil avec la section respective <match> ne sera pas appliqué ou recommandé. Ainsi, la nidification (sections enfant <match>) fonctionne en tant qu’opérateur logique ET. Inversement, si un élément de la liste <match> correspond, l’ensemble de la liste <match> évalue à true. La liste agit donc en tant qu’opérateur logique ou opérateur.
En cas de définition de machineConfigLabels, la correspondance basée sur le pool de configuration de machine est activée pour l’élément de liste recommandé. <mcLabels> spécifie les étiquettes d’une configuration de 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>. Cela implique de trouver tous les pools de configuration de machine avec le sélecteur de configuration de machine correspondant <mcLabels> et de définir le profil <tuned_profile_name> sur tous les nœuds qui sont assignés aux pools de configuration de machine trouvés. Afin de cibler les nœuds qui ont à la fois des rôles de maître et de travailleur, vous devez utiliser le rôle maître.
Les éléments de liste correspondent et machineConfigLabels sont connectés par l’opérateur logique OU. L’élément de match est évalué d’abord en court-circuit. Donc, s’il évalue à true, l’élément machineConfigLabels n’est pas pris en compte.
Lors de l’utilisation de la correspondance basée sur le pool de configuration de la machine, il est conseillé de regrouper les nœuds avec la même configuration matérielle dans le même pool de configuration de machine. Le fait de ne pas suivre cette pratique pourrait entraîner des opérandes TuneD calculant des paramètres contradictoires du noyau pour deux ou plusieurs nœuds partageant le même pool de configuration de machine.
Exemple: correspondance basée sur l’étiquette de nœud ou de pod
Le CR ci-dessus est traduit pour le démon TuneD conteneurisé dans son fichier recommend.conf basé sur les priorités du profil. Le profil avec la priorité la plus élevée (10) est l’avion de contrôle ouvert et, par conséquent, il est considéré en premier. Le démon TuneD conteneurisé fonctionnant sur un nœud donné semble voir s’il y a un pod fonctionnant sur le même nœud avec le set d’étiquettes tuned.openshift.io/élastique. Dans le cas contraire, l’ensemble de la section <match> évalue comme faux. En cas d’un tel pod avec l’étiquette, pour que la section <match> évalue à true, l’étiquette du nœud doit également être node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.
Lorsque les étiquettes du profil avec priorité 10 correspondent, le profil openshift-control-plane-es est appliqué et aucun autre profil n’est pris en compte. Dans le cas où la combinaison d’étiquettes node/pod ne correspondait pas, le deuxième profil de priorité (openshift-control-plan) est pris en compte. Ce profil est appliqué si le pod conteneurisé TuneD fonctionne sur un nœud avec les étiquettes node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.
Enfin, le nœud ouvert de profil a la priorité la plus basse de 30. Il manque la section <match> et, par conséquent, correspondra toujours. Il agit comme un profil catch-all pour définir le profil de nœud ouvert, s’il n’y a pas d’autre profil avec une priorité plus élevée sur un nœud donné.
Exemple: mise en correspondance basée sur le pool de configuration de machine
Afin de minimiser le redémarrage des nœuds, étiqueter les nœuds cibles avec une étiquette que le sélecteur de nœud du pool de configuration de la machine correspondra, puis créer le CR Tuned ci-dessus et enfin créer le pool de configuration de la machine personnalisée lui-même.
Les profils TuneD spécifiques aux fournisseurs de cloud
Grâce à cette fonctionnalité, tous les nœuds spécifiques aux fournisseurs de Cloud peuvent facilement se voir attribuer un profil TuneD spécifiquement adapté à un fournisseur de Cloud donné sur un service Red Hat OpenShift sur le cluster AWS. Cela peut être accompli sans ajouter d’étiquettes de nœuds supplémentaires ou regrouper des nœuds dans les pools de configuration de la machine.
Cette fonctionnalité tire parti des valeurs d’objet de nœud spec.providerID sous la forme de <cloud-provider>:///<cloud-provider-specific-id> et écrit le fichier /var/lib/ocp-tuned/provider avec la valeur <cloud-provider> dans les conteneurs d’opérande NTO. Le contenu de ce fichier est ensuite utilisé par TuneD pour charger le profil fournisseur-<cloud-provider> s’il existe un tel profil.
Le profil openshift que les profils openshift-contrôle-plan et openshift-node héritent des paramètres est maintenant mis à jour pour utiliser cette fonctionnalité grâce à l’utilisation du chargement de profil conditionnel. Actuellement, ni NTO ni TuneD n’incluent des profils spécifiques aux fournisseurs Cloud. Cependant, il est possible de créer un profil personnalisé fournisseur-<cloud-fourr> qui sera appliqué à tous les nœuds de cluster spécifiques au fournisseur Cloud.
Exemple de profil de fournisseur GCE Cloud
En raison de l’héritage du profil, tout paramètre spécifié dans le profil fournisseur-<cloud-fourr> sera écrasé par le profil openshift et ses profils enfants.
6.3.3. Des profils par défaut définis sur un cluster Copier lienLien copié sur presse-papiers!
Ce qui suit sont les profils par défaut définis sur un cluster.
À partir de Red Hat OpenShift Service sur AWS 4.9, tous les profils OpenShift TuneD sont livrés avec le package TuneD. La commande oc exec permet d’afficher 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 ^ {} \;
6.3.4. Les plugins TuneD daemon pris en charge Copier lienLien copié sur presse-papiers!
À l’exclusion de la section [principale], les plugins TuneD suivants sont pris en charge lors de l’utilisation de profils personnalisés définis dans le profil : section du CR Tuned:
- audio
- CPU
- disque de disque
- eeepc_she
- les modules
- les montures
- le net
- échéancier
- à propos de scsi_host
- à propos de SELinux
- le sysctl
- les sysfs
- USB
- la vidéo
- à propos de VM
- chargeur de démarrage
Il existe une fonctionnalité de réglage dynamique fournie par certains de ces plugins qui n’est pas pris en charge. Les plugins TuneD suivants ne sont actuellement pas pris en charge:
- le script
- d’un système
Le plugin de démarrage TuneD ne prend en charge que les nœuds de travail Red Hat Enterprise Linux CoreOS (RHCOS).
Ressources supplémentaires
Chapitre 7. En travaillant avec des conteneurs Copier lienLien copié sur presse-papiers!
7.1. Comprendre les conteneurs Copier lienLien copié sur presse-papiers!
Les unités de base de Red Hat OpenShift Service sur les applications AWS sont appelées conteneurs. Les technologies de conteneurs Linux sont des mécanismes légers pour isoler les processus en cours d’exécution, de sorte qu’ils se limitent à interagir avec seulement leurs ressources désignées.
De nombreuses instances d’application peuvent s’exécuter dans des conteneurs sur un seul hôte sans visibilité sur les processus, les fichiers, le réseau, etc. En règle générale, chaque conteneur fournit un service unique (souvent appelé « micro-service »), tel qu’un serveur Web ou une base de données, bien que les conteneurs puissent être utilisés pour des charges de travail arbitraires.
Le noyau Linux intègre des capacités pour les technologies de conteneurs depuis des années. Le service OpenShift Red Hat sur AWS et Kubernetes ajoute la possibilité d’orchestrer des conteneurs sur des installations multi-hôte.
7.1.1. À propos des conteneurs et de la mémoire du noyau RHEL Copier lienLien copié sur presse-papiers!
En raison du comportement Red Hat Enterprise Linux (RHEL), un conteneur sur un nœud avec une utilisation élevée du CPU peut sembler consommer plus de mémoire que prévu. La consommation de mémoire plus élevée pourrait être causée par le kmem_cache dans le noyau RHEL. Le noyau RHEL crée un kmem_cache pour chaque cgroup. En plus de performances, le kmem_cache contient un cache cpu_cache et un cache de nœud pour tous les nœuds NUMA. Ces caches consomment tous de la mémoire du noyau.
La quantité de mémoire stockée dans ces caches est proportionnelle au nombre de CPU que le système utilise. En conséquence, un plus grand nombre de CPU se traduit par une plus grande quantité de mémoire du noyau étant détenue dans ces caches. Des quantités plus élevées de mémoire du noyau dans ces caches peuvent entraîner Red Hat OpenShift Service sur les conteneurs AWS à dépasser les limites de mémoire configurées, ce qui entraîne la mort du conteneur.
Afin d’éviter de perdre des conteneurs en raison de problèmes de mémoire du noyau, assurez-vous que les conteneurs demandent une mémoire suffisante. La formule suivante permet d’estimer la quantité de mémoire consommée par kmem_cache, où nproc est le nombre d’unités de traitement disponibles qui sont rapportées par la commande nproc. La limite inférieure des demandes de conteneurs devrait être cette valeur plus les exigences de mémoire du conteneur:
$(nproc) X 1/2 MiB
$(nproc) X 1/2 MiB
7.1.2. À propos du moteur du conteneur et du temps d’exécution du conteneur Copier lienLien copié sur presse-papiers!
Le moteur de conteneur est un logiciel qui traite les demandes des utilisateurs, y compris les options de ligne de commande et les tirages d’image. Le moteur de conteneur utilise un runtime de conteneur, également appelé un runtime de conteneur de niveau inférieur, pour exécuter et gérer les composants nécessaires pour déployer et utiliser des conteneurs. Il est probable que vous n’aurez pas besoin d’interagir avec le moteur de conteneur ou le temps d’exécution du conteneur.
Le service OpenShift Red Hat sur la documentation AWS utilise le terme d’exécution du conteneur pour se référer à l’exécution du conteneur de niveau inférieur. D’autres documents peuvent se référer au moteur de conteneur comme le temps d’exécution du conteneur.
Le service OpenShift Red Hat sur AWS utilise CRI-O comme moteur de conteneur et cron ou runC comme temps d’exécution du conteneur. L’exécution du conteneur par défaut est crun.
7.2. En utilisant des conteneurs Init pour effectuer des tâches avant le déploiement d’un pod Copier lienLien copié sur presse-papiers!
Le service OpenShift Red Hat sur AWS fournit des conteneurs init, qui sont des conteneurs spécialisés qui s’exécutent avant les conteneurs d’application et peuvent contenir des utilitaires ou des scripts de configuration qui ne sont pas présents dans une image de l’application.
7.2.1. Comprendre les conteneurs d’entrée Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser une ressource Init Container pour effectuer des tâches avant que le reste d’un pod ne soit déployé.
La gousse peut avoir des conteneurs Init en plus des conteneurs d’application. Les conteneurs init vous permettent de réorganiser les scripts d’installation et le code de liaison.
Le conteneur Init peut:
- Contenir et exécuter des utilitaires qui ne sont pas souhaitables d’inclure dans l’image Container de l’application pour des raisons de sécurité.
- Contenir des utilitaires ou du code personnalisé pour la configuration qui n’est pas présent dans une image de l’application. À titre d’exemple, il n’est pas nécessaire de faire une image d’une autre image juste pour utiliser un outil comme sed, awk, python, ou creuser pendant la configuration.
- Utilisez les espaces de noms Linux afin qu’ils aient des vues différentes du système de fichiers des conteneurs d’applications, tels que l’accès aux secrets auxquels les conteneurs d’applications ne sont pas en mesure d’accéder.
Chaque conteneur Init doit compléter avec succès avant le début du prochain. Ainsi, les conteneurs Init fournissent un moyen facile de bloquer ou de retarder le démarrage des conteneurs d’applications jusqu’à ce que certaines conditions préalables soient remplies.
À titre d’exemple, vous pouvez utiliser les conteneurs Init suivants:
Attendez qu’un service soit créé avec une commande shell comme:
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enregistrez ce pod avec un serveur distant à partir de l’API descendante avec une commande comme:
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d ‘instance=$()&ip=$()’
$ curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d ‘instance=$()&ip=$()’
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Attendez un certain temps avant de démarrer l’application Container avec une commande comme Sleep 60.
- Cloner un dépôt git dans un volume.
- Placez les valeurs dans un fichier de configuration et exécutez un outil de modèle pour générer dynamiquement un fichier de configuration pour l’application principale Container. À titre d’exemple, placez la valeur POD_IP dans une configuration et générez le fichier de configuration de l’application principale à l’aide de Jinja.
Consultez la documentation de Kubernetes pour plus d’informations.
7.2.2. Créer des conteneurs Init Copier lienLien copié sur presse-papiers!
L’exemple suivant présente un simple pod qui a deux conteneurs Init. La première attend mon service et la seconde attend mydb. Après la fin des deux conteneurs, la gousse commence.
Procédure
Créer le pod pour le conteneur Init:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod:
oc create -f myapp.yaml
$ oc create -f myapp.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afficher l’état du pod:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 5s
NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 5s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le statut pod, Init:0/2, indique qu’il attend les deux services.
Créez le service myservice.
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod:
oc create -f myservice.yaml
$ oc create -f myservice.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afficher l’état du pod:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:1/2 0 5s
NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:1/2 0 5s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le statut pod, Init:1/2, indique qu’il attend un service, dans ce cas le service mydb.
Créer le service mydb:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod:
oc create -f mydb.yaml
$ oc create -f mydb.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afficher l’état du pod:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 2m
NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 2m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le statut de la gousse indique qu’il n’attend plus les services et qu’il est en cours d’exécution.
7.3. En utilisant des volumes pour persister les données des conteneurs Copier lienLien copié sur presse-papiers!
Les fichiers dans un conteneur sont éphémères. En tant que tel, lorsqu’un conteneur s’écrase ou s’arrête, les données sont perdues. Il est possible d’utiliser des volumes pour persister les données utilisées par les conteneurs dans un pod. Le volume est un répertoire, accessible aux Conteneurs dans un pod, où les données sont stockées pour la durée de vie de la gousse.
7.3.1. Comprendre les volumes Copier lienLien copié sur presse-papiers!
Les volumes sont des systèmes de fichiers montés disponibles pour les pods et leurs conteneurs qui peuvent être soutenus par un certain nombre de points de stockage locaux ou réseau attachés à l’hôte. Les conteneurs ne sont pas persistants par défaut; au redémarrage, leur contenu est effacé.
Afin de s’assurer que le système de fichiers sur le volume ne contient pas d’erreurs et, si des erreurs sont présentes, pour les réparer si possible, Red Hat OpenShift Service sur AWS invoque l’utilitaire fsck avant l’utilitaire de montage. Cela se produit lors de l’ajout d’un volume ou de la mise à jour d’un volume existant.
Le type de volume le plus simple est emptyDir, qui est un répertoire temporaire sur une seule machine. Les administrateurs peuvent également vous permettre de demander un volume persistant qui est automatiquement attaché à vos pods.
le stockage de volume videDir peut être limité par un quota basé sur le groupe FS du pod, si le paramètre FSGroup est activé par votre administrateur de cluster.
7.3.2. En travaillant avec les volumes à l’aide du service Red Hat OpenShift sur AWS CLI Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser le volume défini par commande CLI pour ajouter et supprimer des volumes et des montages de volume pour n’importe quel objet doté d’un modèle de pod comme des contrôleurs de réplication ou des configurations de déploiement. Il est également possible de répertorier les volumes dans les pods ou n’importe quel objet ayant un modèle de pod.
La commande oc set volume utilise la syntaxe générale suivante:
oc set volume <object_selection> <operation> <mandatory_parameters> <options>
$ oc set volume <object_selection> <operation> <mandatory_parameters> <options>
- Choix de l’objet
- Indiquez l’un des paramètres suivants pour le paramètre object_selection dans la commande oc set volume:
Syntaxe | Description | Exemple : |
---|---|---|
| Sélectionne <nom> du type <object_type>. |
|
| Sélectionne <nom> du type <object_type>. |
|
<Object_type>--selector=<object_label_selector> | Sélectionne les ressources de type <object_type> qui correspondaient au sélecteur d’étiquette donné. | déploiementConfig--selector="nom=registry" |
| Sélectionne toutes les ressources de type <object_type>. |
|
-F ou --filename=<file_name> | Le nom du fichier, le répertoire ou l’URL à utiliser pour modifier la ressource. |
|
- L’opération
- Indiquez --add ou --remove pour le paramètre d’opération dans la commande oc set volume.
- Les paramètres obligatoires
- Les paramètres obligatoires sont spécifiques à l’opération sélectionnée et sont discutés dans les sections suivantes.
- Les options
- Les options sont spécifiques à l’opération sélectionnée et sont discutées dans les sections ultérieures.
7.3.3. Liste des volumes et des montages de volume dans un pod Copier lienLien copié sur presse-papiers!
Liste des volumes et des montages de volume dans des pods ou des modèles de pod:
Procédure
Liste des volumes:
oc set volume <object_type>/<name> [options]
$ oc set volume <object_type>/<name> [options]
Liste des options prises en charge du volume:
L’option | Description | Défaut par défaut |
---|---|---|
| Le nom du volume. | |
| Choisissez les conteneurs par nom. Il peut également prendre wildcard '*' qui correspond à n’importe quel personnage. |
|
À titre d’exemple:
Liste de tous les volumes pour pod p1:
oc set volume pod/p1
$ oc set volume pod/p1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lister le volume v1 défini sur toutes les configurations de déploiement:
oc set volume dc --all --name=v1
$ oc set volume dc --all --name=v1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.4. Ajouter des volumes à un pod Copier lienLien copié sur presse-papiers!
Il est possible d’ajouter des volumes et des montures de volume à un pod.
Procédure
Ajouter un volume, une monture de volume, ou les deux aux modèles de pod:
oc set volume <object_type>/<name> --add [options]
$ oc set volume <object_type>/<name> --add [options]
L’option | Description | Défaut par défaut |
---|---|---|
| Le nom du volume. | Généré automatiquement, s’il n’est pas spécifié. |
| Le nom de la source du volume. Les valeurs prises en charge: emptyDir, hostPath, secret, configmap, persistantVolumeClaim ou projeté. |
|
| Choisissez les conteneurs par nom. Il peut également prendre wildcard '*' qui correspond à n’importe quel personnage. |
|
| Monter le chemin à l’intérieur des conteneurs sélectionnés. Il ne faut pas monter sur la racine du conteneur, /, ou tout chemin qui est le même dans l’hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme les fichiers hôte /dev/pts. Il est sûr de monter l’hôte en utilisant /host. | |
| Chemin de l’hôte. Le paramètre obligatoire pour --type=hostPath. Il ne faut pas monter sur la racine du conteneur, /, ou tout chemin qui est le même dans l’hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme les fichiers hôte /dev/pts. Il est sûr de monter l’hôte en utilisant /host. | |
| Le nom du secret. Le paramètre obligatoire pour --type=secret. | |
| Le nom de la configmap. Le paramètre obligatoire pour --type=configmap. | |
| Le nom de la revendication de volume persistant. Le paramètre obligatoire pour --type=persistentVolumeClaim. | |
| Détails de la source de volume en tant que chaîne JSON. Il est recommandé si la source de volume souhaitée n’est pas prise en charge par --type. | |
| Afficher les objets modifiés au lieu de les mettre à jour sur le serveur. Les valeurs prises en charge: json, yaml. | |
| Afficher les objets modifiés avec la version donnée. |
|
À titre d’exemple:
Ajouter un nouveau volume source videDir à l’objet DéploiementConfig du registre:
oc set volume dc/registry --add
$ oc set volume dc/registry --add
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour ajouter le volume:
Exemple 7.1. Exemple de configuration de déploiement avec un volume ajouté
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ajoutez la source de volume videDir.
Ajouter le volume v1 avec secret secret1 pour le contrôleur de réplication r1 et monter à l’intérieur des conteneurs à /data:
oc set volume rc/r1 --add --name=v1 --type=secret --secret-name='secret1' --mount-path=/data
$ oc set volume rc/r1 --add --name=v1 --type=secret --secret-name='secret1' --mount-path=/data
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAjouter le volume v1 persistant existant avec le nom de revendication pvc1 à la configuration de déploiement dc.json sur le disque, monter le volume sur le conteneur c1 à /data, et mettre à jour l’objet DeploymentConfig sur le serveur:
oc set volume -f dc.json --add --name=v1 --type=persistentVolumeClaim \ --claim-name=pvc1 --mount-path=/data --containers=c1
$ oc set volume -f dc.json --add --name=v1 --type=persistentVolumeClaim \ --claim-name=pvc1 --mount-path=/data --containers=c1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour ajouter le volume:
Ajouter un volume v1 basé sur le dépôt Git https://github.com/namespace1/project1 avec la révision 5125c45f9f563 pour tous les contrôleurs de réplication:
oc set volume rc --all --add --name=v1 \ --source='{"gitRepo": {
$ oc set volume rc --all --add --name=v1 \ --source='{"gitRepo": { "repository": "https://github.com/namespace1/project1", "revision": "5125c45f9f563" }}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.5. La mise à jour des volumes et des montages de volume dans un pod Copier lienLien copié sur presse-papiers!
Il est possible de modifier les volumes et les montages de volume dans un pod.
Procédure
La mise à jour des volumes existants en utilisant l’option --overwrite:
oc set volume <object_type>/<name> --add --overwrite [options]
$ oc set volume <object_type>/<name> --add --overwrite [options]
À titre d’exemple:
Afin de remplacer le volume v1 existant pour le contrôleur de réplication r1 par la revendication de volume persistante existante pvc1:
oc set volume rc/r1 --add --overwrite --name=v1 --type=persistentVolumeClaim --claim-name=pvc1
$ oc set volume rc/r1 --add --overwrite --name=v1 --type=persistentVolumeClaim --claim-name=pvc1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour remplacer le volume:
Exemple 7.4. Contrôleur de réplication d’échantillons avec revendication de volume persistante nommée pvc1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définir la revendication de volume persistant à pvc1.
Changer le point de montage de l’objet D1 DeploymentConfig en /opt pour le volume v1:
oc set volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt
$ oc set volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AstuceAlternativement, vous pouvez appliquer le YAML suivant pour changer le point de montage:
Exemple 7.5. Exemple de configuration de déploiement avec le point de montage défini pour opter.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définissez le point de montage sur /opt.
7.3.6. Enlever les volumes et les montages de volume d’une gousse Copier lienLien copié sur presse-papiers!
Il est possible d’enlever un support de volume ou de volume d’une gousse.
Procédure
Afin de supprimer un volume des modèles de pod:
oc set volume <object_type>/<name> --remove [options]
$ oc set volume <object_type>/<name> --remove [options]
L’option | Description | Défaut par défaut |
---|---|---|
| Le nom du volume. | |
| Choisissez les conteneurs par nom. Il peut également prendre wildcard '*' qui correspond à n’importe quel personnage. |
|
| Indiquez que vous souhaitez supprimer plusieurs volumes à la fois. | |
| Afficher les objets modifiés au lieu de les mettre à jour sur le serveur. Les valeurs prises en charge: json, yaml. | |
| Afficher les objets modifiés avec la version donnée. |
|
À titre d’exemple:
Afin de supprimer un volume v1 de l’objet DeploymentConfig d1:
oc set volume dc/d1 --remove --name=v1
$ oc set volume dc/d1 --remove --name=v1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Démonter le volume v1 du conteneur c1 pour l’objet DeploymentConfig d1 et supprimer le volume v1 s’il n’est pas référencé par des conteneurs sur d1:
oc set volume dc/d1 --remove --name=v1 --containers=c1
$ oc set volume dc/d1 --remove --name=v1 --containers=c1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow De supprimer tous les volumes pour le contrôleur de réplication r1:
oc set volume rc/r1 --remove --confirm
$ oc set volume rc/r1 --remove --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.7. Configuration des volumes pour plusieurs utilisations dans un pod Copier lienLien copié sur presse-papiers!
En utilisant la propriété VolumeMounts.subPath, vous pouvez configurer un volume pour partager un volume pour plusieurs utilisations en utilisant la propriété volumeMounts.subPath pour spécifier une valeur subPath à l’intérieur d’un volume au lieu de la racine du volume.
Il n’est pas possible d’ajouter un paramètre SubPath à une pod existante.
Procédure
Afin d’afficher la liste des fichiers dans le volume, exécutez la commande oc rsh:
oc rsh <pod>
$ oc rsh <pod>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
ls /path/to/volume/subpath/mount
sh-4.2$ ls /path/to/volume/subpath/mount example_file1 example_file2 example_file3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Indiquez le sous-Path:
Exemple Pod spec avec paramètre subPath
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. Cartographie des volumes à l’aide de volumes projetés Copier lienLien copié sur presse-papiers!
Le volume projeté cartographie plusieurs sources de volume existantes dans le même répertoire.
Les types de sources de volume suivants peuvent être projetés:
- Les secrets
- Configuration des cartes
- API descendante
Il faut que toutes les sources soient dans le même espace de noms que le pod.
7.4.1. Comprendre les volumes projetés Copier lienLien copié sur presse-papiers!
Les volumes projetés peuvent cartographier n’importe quelle combinaison de ces sources de volume en un seul répertoire, permettant à l’utilisateur de:
- installer automatiquement un seul volume avec les clés de plusieurs secrets, configurer des cartes et avec des informations API descendantes, de sorte que je puisse synthétiser un seul répertoire avec diverses sources d’information;
- remplissez un seul volume avec les clés de plusieurs secrets, configurez des cartes et avec des informations API descendantes, spécifiant explicitement les chemins pour chaque élément, afin que je puisse avoir un contrôle total sur le contenu de ce volume.
Lorsque l’autorisation RunAsUser est définie dans le contexte de sécurité d’une pod basée sur Linux, les fichiers projetés ont les autorisations correctes, y compris la propriété de l’utilisateur du conteneur. Cependant, lorsque l’autorisation RunAsUsername de Windows est définie dans un pod Windows, le kubelet est incapable de définir correctement la propriété sur les fichiers dans le volume projeté.
Donc, l’autorisation RunAsUsername définie dans le contexte de sécurité d’un pod Windows n’est pas honorée pour les volumes projetés Windows s’exécutant dans Red Hat OpenShift Service sur AWS.
Les scénarios généraux suivants montrent comment vous pouvez utiliser les volumes projetés.
- Configurez la carte, les secrets, l’API Downward.
- Les volumes projetés vous permettent de déployer des conteneurs avec des données de configuration qui incluent des mots de passe. L’application utilisant ces ressources pourrait être le déploiement de Red Hat OpenStack Platform (RHOSP) sur Kubernetes. Les données de configuration peuvent devoir être assemblées différemment selon que les services seront utilisés pour la production ou pour les tests. Lorsqu’un pod est étiqueté avec la production ou le test, le sélecteur d’API vers le bas métadonnées.labels peut être utilisé pour produire les configurations RHOSP correctes.
- Configurez la carte + secrets.
- Les volumes projetés vous permettent de déployer des conteneurs impliquant des données de configuration et des mots de passe. À titre d’exemple, vous pouvez exécuter une carte de configuration avec certaines tâches cryptées sensibles qui sont décryptées à l’aide d’un fichier de mot de passe voûte.
- ConfigMap + API vers le bas.
- Les volumes projetés vous permettent de générer une configuration incluant le nom du pod (disponible via le sélecteur métadonnées.name). Cette application peut ensuite passer le nom de la pod avec des requêtes pour déterminer facilement la source sans utiliser le suivi IP.
- Les secrets + l’API Downward.
- Les volumes projetés vous permettent d’utiliser un secret comme clé publique pour chiffrer l’espace de noms de la pod (disponible via le sélecteur métadonnées.namespace). Cet exemple permet à l’opérateur d’utiliser l’application pour fournir les informations de l’espace de noms en toute sécurité sans utiliser un transport crypté.
7.4.1.1. Exemple Pod specs Copier lienLien copié sur presse-papiers!
Ce qui suit sont des exemples de spécifications Pod pour créer des volumes projetés.
Dose avec un secret, une API Downward et une carte de configuration
- 1
- Ajoutez une section volumeMounts pour chaque conteneur qui a besoin du secret.
- 2
- Indiquez un chemin vers un répertoire inutilisé où le secret apparaîtra.
- 3
- Définir readOnly sur true.
- 4
- Ajoutez un bloc de volumes pour énumérer chaque source de volume projetée.
- 5
- Indiquez n’importe quel nom pour le volume.
- 6
- Définissez l’autorisation d’exécution sur les fichiers.
- 7
- Ajoutez un secret. Entrez le nom de l’objet secret. Chaque secret que vous souhaitez utiliser doit être répertorié.
- 8
- Indiquez le chemin vers le fichier secret sous le MountPath. Ici, le fichier secret est dans /projected-volume/my-group/my-username.
- 9
- Ajoutez une source d’API vers le bas.
- 10
- Ajoutez une source ConfigMap.
- 11
- Définir le mode de projection spécifique
Lorsqu’il y a plusieurs conteneurs dans la gousse, chaque conteneur a besoin d’une section volumeMounts, mais une seule section de volume est nécessaire.
Dose avec plusieurs secrets avec un mode d’autorisation non par défaut
Le mode par défaut ne peut être spécifié qu’au niveau prévu et non pour chaque source de volume. Cependant, comme illustré ci-dessus, vous pouvez définir explicitement le mode de chaque projection individuelle.
7.4.1.2. Considérations de cheminement Copier lienLien copié sur presse-papiers!
- Collisions entre les clés lorsque les chemins configurés sont identiques
Lorsque vous configurez des touches avec le même chemin, le pod spec ne sera pas accepté comme valide. Dans l’exemple suivant, le chemin spécifié pour mysecret et myconfigmap sont les mêmes:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Considérez les situations suivantes liées aux chemins de fichiers de volume.
- Collisions entre les clés sans parcours configurés
- La seule validation d’exécution qui peut se produire est lorsque tous les chemins sont connus à la création de pod, similaire au scénario ci-dessus. Dans le cas contraire, lorsqu’un conflit se produit, la ressource spécifiée la plus récente écrasera tout ce qui précède (cela est vrai pour les ressources qui sont mises à jour après la création de pod).
- Collisions quand un chemin est explicite et l’autre est projeté automatiquement
- Dans le cas d’une collision due à un utilisateur spécifié des données de correspondance de chemin qui est automatiquement projetée, cette dernière ressource écrasera tout ce qui précède comme avant.
7.4.2. Configuration d’un volume projeté pour un Pod Copier lienLien copié sur presse-papiers!
Lors de la création de volumes projetés, considérez les situations de chemin de fichier de volume décrites dans Comprendre les volumes projetés.
L’exemple suivant montre comment utiliser un volume projeté pour monter une source de volume secrète existante. Les étapes peuvent être utilisées pour créer un nom d’utilisateur et des secrets de mot de passe à partir de fichiers locaux. Ensuite, vous créez un pod qui exécute un conteneur, en utilisant un volume projeté pour monter les secrets dans le même répertoire partagé.
Le nom d’utilisateur et les valeurs de mot de passe peuvent être n’importe quelle chaîne valide qui est encodée base64.
L’exemple suivant montre admin en base64:
echo -n "admin" | base64
$ echo -n "admin" | base64
Exemple de sortie
YWRtaW4=
YWRtaW4=
L’exemple suivant montre le mot de passe 1f2d1e2e67df en base64:
echo -n "1f2d1e2e67df" | base64
$ echo -n "1f2d1e2e67df" | base64
Exemple de sortie
MWYyZDFlMmU2N2Rm
MWYyZDFlMmU2N2Rm
Procédure
D’utiliser un volume projeté pour monter une source de volume secrète existante.
Créer le secret:
Créez un fichier YAML similaire à ce qui suit, en remplaçant le mot de passe et les informations d’utilisateur selon le cas:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Faites appel à la commande suivante pour créer le secret:
oc create -f <secrets-filename>
$ oc create -f <secrets-filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc create -f secret.yaml
$ oc create -f secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
secret "mysecret" created
secret "mysecret" created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il est possible de vérifier que le secret a été créé à l’aide des commandes suivantes:
oc get secret <secret-name>
$ oc get secret <secret-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc get secret mysecret
$ oc get secret mysecret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME TYPE DATA AGE mysecret Opaque 2 17h
NAME TYPE DATA AGE mysecret Opaque 2 17h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get secret <secret-name> -o yaml
$ oc get secret <secret-name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc get secret mysecret -o yaml
$ oc get secret mysecret -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créez un pod avec un volume projeté.
Créez un fichier YAML similaire à ce qui suit, y compris une section des volumes:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le nom du secret que vous avez créé.
Créer le pod à partir du fichier de configuration:
oc create -f <your_yaml_file>.yaml
$ oc create -f <your_yaml_file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc create -f secret-pod.yaml
$ oc create -f secret-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
pod "test-projected-volume" created
pod "test-projected-volume" created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Assurez-vous que le conteneur de la gousse est en cours d’exécution, puis surveillez les modifications apportées à la gousse:
oc get pod <name>
$ oc get pod <name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc get pod test-projected-volume
$ oc get pod test-projected-volume
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le produit devrait apparaître comme suit:
Exemple de sortie
NAME READY STATUS RESTARTS AGE test-projected-volume 1/1 Running 0 14s
NAME READY STATUS RESTARTS AGE test-projected-volume 1/1 Running 0 14s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans un autre terminal, utilisez la commande oc exec pour ouvrir un shell au conteneur en cours d’exécution:
oc exec -it <pod> <command>
$ oc exec -it <pod> <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc exec -it test-projected-volume -- /bin/sh
$ oc exec -it test-projected-volume -- /bin/sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans votre shell, vérifiez que le répertoire des volumes projetés contient vos sources projetées:
/ # ls
/ # ls
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
bin home root tmp dev proc run usr etc projected-volume sys var
bin home root tmp dev proc run usr etc projected-volume sys var
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5. Autoriser les conteneurs à consommer des objets API Copier lienLien copié sur presse-papiers!
L’API Downward est un mécanisme qui permet aux conteneurs de consommer des informations sur les objets API sans couplage à Red Hat OpenShift Service sur AWS. Ces informations incluent le nom, l’espace de noms et les valeurs de ressource du pod. Les conteneurs peuvent consommer des informations à partir de l’API descendante à l’aide de variables d’environnement ou d’un plugin de volume.
7.5.1. Exposer les informations de pod aux conteneurs utilisant l’API Downward Copier lienLien copié sur presse-papiers!
L’API Downward contient des informations telles que le nom, le projet et les valeurs de ressources du pod. Les conteneurs peuvent consommer des informations à partir de l’API descendante à l’aide de variables d’environnement ou d’un plugin de volume.
Les champs dans le pod sont sélectionnés à l’aide du type d’API FieldRef. FieldRef a deux champs:
Le champ | Description |
---|---|
| Le chemin du champ à sélectionner, par rapport au pod. |
| La version API pour interpréter le sélecteur fieldPath à l’intérieur. |
Actuellement, les sélecteurs valides dans l’API v1 incluent:
Le sélecteur | Description |
---|---|
| Le nom de la gousse. Ceci est pris en charge tant dans les variables d’environnement que dans les volumes. |
| L’espace de nom du pod.This est pris en charge dans les variables d’environnement et les volumes. |
| Les étiquettes de la gousse. Cela n’est pris en charge que dans les volumes et non dans les variables d’environnement. |
| Les annotations de la gousse. Cela n’est pris en charge que dans les volumes et non dans les variables d’environnement. |
| L’IP de la gousse. Ceci n’est pris en charge que dans les variables d’environnement et non dans les volumes. |
Le champ apiVersion, s’il n’est pas spécifié, par défaut, par défaut, par défaut à la version API du modèle de pod enclosing.
7.5.2. Comprendre comment consommer des valeurs de conteneur à l’aide de l’API descendante Copier lienLien copié sur presse-papiers!
Les conteneurs peuvent consommer des valeurs API à l’aide de variables d’environnement ou d’un plugin de volume. En fonction de la méthode que vous choisissez, les conteneurs peuvent consommer:
- Le nom du pod
- Le projet Pod/namespace
- Annotations de pod
- Étiquettes de pod
Les annotations et les étiquettes sont disponibles en utilisant uniquement un plugin de volume.
7.5.2.1. Consommer des valeurs de conteneur à l’aide de variables d’environnement Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez les variables d’environnement d’un conteneur, utilisez la valeur du type EnvVar du champ (de type EnvVarSource) pour spécifier que la valeur de la variable devrait provenir d’une source FieldRef au lieu de la valeur littérale spécifiée par le champ de valeur.
Les attributs constants de la gousse peuvent être consommés de cette façon, car les variables d’environnement ne peuvent pas être mises à jour une fois qu’un processus est lancé d’une manière qui permet au processus d’être informé que la valeur d’une variable a changé. Les champs pris en charge à l’aide de variables d’environnement sont:
- Le nom du pod
- Le projet Pod/namespace
Procédure
Créez une nouvelle spécification de pod qui contient les variables d’environnement que vous souhaitez que le conteneur consomme:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod à partir du fichier pod.yaml:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux du conteneur pour les valeurs MY_POD_NAME et MY_POD_NAMESPACE:
oc logs -p dapi-env-test-pod
$ oc logs -p dapi-env-test-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.2.2. Consommer des valeurs de conteneur à l’aide d’un plugin de volume Copier lienLien copié sur presse-papiers!
Les conteneurs peuvent consommer des valeurs API à l’aide d’un plugin de volume.
Les conteneurs peuvent consommer:
- Le nom du pod
- Le projet Pod/namespace
- Annotations de pod
- Étiquettes de pod
Procédure
D’utiliser le plugin de volume:
Créez une nouvelle spécification de pod qui contient les variables d’environnement que vous souhaitez que le conteneur consomme:
Créez un fichier volume-pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod à partir du fichier volume-pod.yaml:
oc create -f volume-pod.yaml
$ oc create -f volume-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux du conteneur et vérifiez la présence des champs configurés:
oc logs -p dapi-volume-test-pod
$ oc logs -p dapi-volume-test-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.3. Comprendre comment consommer des ressources de conteneurs à l’aide de l’API Downward Copier lienLien copié sur presse-papiers!
Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des informations sur les demandes de ressources informatiques et les limites afin que les auteurs d’images et d’applications puissent créer correctement une image pour des environnements spécifiques.
Il est possible de le faire à l’aide d’une variable d’environnement ou d’un plugin de volume.
7.5.3.1. Consommer des ressources de conteneurs à l’aide de variables d’environnement Copier lienLien copié sur presse-papiers!
Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des informations sur les demandes de ressources informatiques et les limites à l’aide de variables d’environnement.
Lors de la création de la configuration de pod, spécifiez les variables d’environnement qui correspondent au contenu du champ ressources dans le champ spec.container.
Dans le cas où les limites de ressources ne sont pas incluses dans la configuration du conteneur, l’API descendante par défaut vers le CPU du nœud et les valeurs allocatables de mémoire.
Procédure
Créez une nouvelle spécification de pod qui contient les ressources que vous souhaitez injecter:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod à partir du fichier pod.yaml:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.3.2. Consommer des ressources de conteneurs à l’aide d’un plugin de volume Copier lienLien copié sur presse-papiers!
Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des informations sur les demandes de ressources informatiques et les limites à l’aide d’un plugin de volume.
Lors de la création de la configuration de pod, utilisez le champ spec.volumes.downwardAPI.items pour décrire les ressources souhaitées qui correspondent au champ spec.resources.
Dans le cas où les limites de ressources ne sont pas incluses dans la configuration du conteneur, l’API Downward par défaut sur le CPU du nœud et les valeurs allocatables de mémoire.
Procédure
Créez une nouvelle spécification de pod qui contient les ressources que vous souhaitez injecter:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod à partir du fichier volume-pod.yaml:
oc create -f volume-pod.yaml
$ oc create -f volume-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.4. Consommer des secrets à l’aide de l’API Downward Copier lienLien copié sur presse-papiers!
Lors de la création de pods, vous pouvez utiliser l’API descendante pour injecter des secrets afin que les auteurs d’images et d’applications puissent créer une image pour des environnements spécifiques.
Procédure
Créer un secret à injecter:
Créez un fichier secret.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez l’objet secret à partir du fichier secret.yaml:
oc create -f secret.yaml
$ oc create -f secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créez un pod qui fait référence au champ nom d’utilisateur à partir de l’objet secret ci-dessus:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod à partir du fichier pod.yaml:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux du conteneur pour la valeur MY_SECRET_USERNAME:
oc logs -p dapi-env-test-pod
$ oc logs -p dapi-env-test-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.5. Consommer des cartes de configuration à l’aide de l’API Downward Copier lienLien copié sur presse-papiers!
Lors de la création de pods, vous pouvez utiliser l’API Downward pour injecter des valeurs de carte de configuration afin que les auteurs d’images et d’applications puissent créer une image pour des environnements spécifiques.
Procédure
Créer une carte de configuration avec les valeurs à injecter:
Créez un fichier configmap.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer la carte de configuration à partir du fichier configmap.yaml:
oc create -f configmap.yaml
$ oc create -f configmap.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créez un pod qui fait référence à la carte de configuration ci-dessus:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod à partir du fichier pod.yaml:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux du conteneur pour la valeur MY_CONFIGMAP_VALUE:
oc logs -p dapi-env-test-pod
$ oc logs -p dapi-env-test-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.6. Les variables d’environnement de référencement Copier lienLien copié sur presse-papiers!
Lors de la création de pods, vous pouvez référencer la valeur d’une variable d’environnement définie précédemment en utilisant la syntaxe $(). Lorsque la référence de la variable d’environnement ne peut pas être résolue, la valeur sera laissée en tant que chaîne fournie.
Procédure
Créer un pod qui fait référence à une variable d’environnement existante:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod à partir du fichier pod.yaml:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux du conteneur pour la valeur MY_ENV_VAR_REF_ENV:
oc logs -p dapi-env-test-pod
$ oc logs -p dapi-env-test-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.7. Évasion des références des variables d’environnement Copier lienLien copié sur presse-papiers!
Lors de la création d’une gousse, vous pouvez échapper à une référence variable d’environnement en utilisant un signe double dollar. La valeur sera ensuite définie sur une version de signe d’un seul dollar de la valeur fournie.
Procédure
Créer un pod qui fait référence à une variable d’environnement existante:
Créez un fichier pod.yaml similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le pod à partir du fichier pod.yaml:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux du conteneur pour la valeur MY_NEW_ENV:
oc logs -p dapi-env-test-pod
$ oc logs -p dapi-env-test-pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.6. Copier des fichiers vers ou à partir d’un service Red Hat OpenShift sur le conteneur AWS Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser le CLI pour copier des fichiers locaux vers ou à partir d’un répertoire distant dans un conteneur à l’aide de la commande rsync.
7.6.1. Comprendre comment copier des fichiers Copier lienLien copié sur presse-papiers!
La commande oc rsync, ou synchronisation à distance, est un outil utile pour copier les archives de base de données vers et à partir de vos pods à des fins de sauvegarde et de restauration. Il est également possible d’utiliser oc rsync pour copier les modifications de code source dans un pod en cours d’exécution pour le débogage de développement, lorsque le pod en cours d’exécution prend en charge le rechargement à chaud des fichiers source.
oc rsync <source> <destination> [-c <container>]
$ oc rsync <source> <destination> [-c <container>]
7.6.1.1. A) Exigences Copier lienLien copié sur presse-papiers!
- Définir la source de copie
L’argument source de la commande oc rsync doit pointer vers un répertoire local ou un répertoire pod. Les fichiers individuels ne sont pas pris en charge.
Lors de la spécification d’un répertoire pod, le nom du répertoire doit être préfixé avec le nom de pod:
<pod name>:<dir>
<pod name>:<dir>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque le nom du répertoire se termine dans un séparateur de chemin (/), seul le contenu du répertoire est copié vers la destination. Dans le cas contraire, le répertoire et son contenu sont copiés vers la destination.
- En spécifiant la destination Copier
- L’argument de destination de la commande oc rsync doit pointer vers un répertoire. Dans le cas où le répertoire n’existe pas, mais que rsync est utilisé pour la copie, le répertoire est créé pour vous.
- La suppression de fichiers à la destination
- L’indicateur --delete peut être utilisé pour supprimer tous les fichiers dans le répertoire distant qui ne sont pas dans le répertoire local.
- Synchronisation continue sur la modification de fichier
En utilisant l’option --watch, la commande surveille le chemin source pour toutes les modifications du système de fichiers et synchronise les modifications lorsqu’elles se produisent. Avec cet argument, la commande s’exécute pour toujours.
La synchronisation se produit après de courtes périodes de silence pour s’assurer qu’un système de fichiers en évolution rapide n’entraîne pas d’appels de synchronisation continus.
Lors de l’utilisation de l’option --watch, le comportement est effectivement le même que d’invoquer manuellement oc rsync à plusieurs reprises, y compris tous les arguments normalement passés à oc rsync. Ainsi, vous pouvez contrôler le comportement via les mêmes drapeaux utilisés avec des invocations manuelles d’oc rsync, comme --delete.
7.6.2. Copier des fichiers vers et depuis des conteneurs Copier lienLien copié sur presse-papiers!
La prise en charge de la copie de fichiers locaux à destination ou à partir d’un conteneur est intégrée dans le CLI.
Conditions préalables
Lorsque vous travaillez avec oc rsync, notez ce qui suit:
le rsync doit être installé. La commande oc rsync utilise l’outil rsync local, s’il est présent sur la machine cliente et sur le conteneur distant.
Lorsque rsync n’est pas trouvé localement ou dans le conteneur distant, une archive tar est créée localement et envoyée au conteneur où l’utilitaire de goudron est utilisé pour extraire les fichiers. Lorsque le goudron n’est pas disponible dans le conteneur distant, la copie échoue.
La méthode de copie de goudron ne fournit pas la même fonctionnalité que oc rsync. À titre d’exemple, oc rsync crée le répertoire de destination s’il n’existe pas et envoie uniquement des fichiers qui sont différents entre la source et la destination.
NoteDans Windows, le client cwRsync doit être installé et ajouté au PATH pour une utilisation avec la commande oc rsync.
Procédure
Copier un répertoire local dans un répertoire pod:
oc rsync <local-dir> <pod-name>:/<remote-dir> -c <container-name>
$ oc rsync <local-dir> <pod-name>:/<remote-dir> -c <container-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc rsync /home/user/source devpod1234:/src -c user-container
$ oc rsync /home/user/source devpod1234:/src -c user-container
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copier un répertoire pod dans un répertoire local:
oc rsync devpod1234:/src /home/user/source
$ oc rsync devpod1234:/src /home/user/source
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
oc rsync devpod1234:/src/status.txt /home/user/
$ oc rsync devpod1234:/src/status.txt /home/user/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.6.3. En utilisant des fonctionnalités avancées de Rsync Copier lienLien copié sur presse-papiers!
La commande oc rsync expose moins d’options de ligne de commande que rsync standard. Dans le cas où vous souhaitez utiliser une option de ligne de commande rsync standard qui n’est pas disponible dans oc rsync, par exemple l’option --exclude-from=FILE, il pourrait être possible d’utiliser l’option standard rsync --rsh (-e) ou RSYNC_RSH comme solution de contournement:
rsync --rsh='oc rsh' --exclude-from=<file_name> <local-dir> <pod-name>:/<remote-dir>
$ rsync --rsh='oc rsh' --exclude-from=<file_name> <local-dir> <pod-name>:/<remote-dir>
a) ou:
Exporter la variable RSYNC_RSH:
export RSYNC_RSH='oc rsh'
$ export RSYNC_RSH='oc rsh'
Ensuite, exécutez la commande rsync:
rsync --exclude-from=<file_name> <local-dir> <pod-name>:/<remote-dir>
$ rsync --exclude-from=<file_name> <local-dir> <pod-name>:/<remote-dir>
Les deux exemples ci-dessus configurent rsync standard pour utiliser oc rsh comme programme shell distant pour lui permettre de se connecter à la pod distante, et sont une alternative à l’exécution oc rsync.
7.7. Exécuter des commandes à distance dans un service Red Hat OpenShift sur le conteneur AWS Copier lienLien copié sur presse-papiers!
Le CLI permet d’exécuter des commandes à distance dans un service OpenShift Red Hat sur le conteneur AWS.
7.7.1. Exécution de commandes distantes dans des conteneurs Copier lienLien copié sur presse-papiers!
La prise en charge de l’exécution de la commande de conteneur à distance est intégrée dans le CLI.
Procédure
Exécuter une commande dans un conteneur:
oc exec <pod> [-c <container>] -- <command> [<arg_1> ... <arg_n>]
$ oc exec <pod> [-c <container>] -- <command> [<arg_1> ... <arg_n>]
À titre d’exemple:
oc exec mypod date
$ oc exec mypod date
Exemple de sortie
Thu Apr 9 02:21:53 UTC 2015
Thu Apr 9 02:21:53 UTC 2015
À des fins de sécurité, la commande oc exec ne fonctionne pas lors de l’accès aux conteneurs privilégiés, sauf lorsque la commande est exécutée par un utilisateur cluster-admin.
7.7.2. Lancement d’une commande distante à partir d’un client Copier lienLien copié sur presse-papiers!
Les clients initient l’exécution d’une commande distante dans un conteneur en envoyant une demande au serveur API Kubernetes:
/proxy/nodes/<node_name>/exec/<namespace>/<pod>/<container>?command=<command>
/proxy/nodes/<node_name>/exec/<namespace>/<pod>/<container>?command=<command>
Dans l’URL ci-dessus:
- <node_name> est le FQDN du nœud.
- <namespace> est le projet du pod cible.
- <pod> est le nom du pod cible.
- <container> est le nom du conteneur cible.
- <command> est la commande souhaitée à exécuter.
À titre d’exemple:
/proxy/nodes/node123.openshift.com/exec/myns/mypod/mycontainer?command=date
/proxy/nodes/node123.openshift.com/exec/myns/mypod/mycontainer?command=date
En outre, le client peut ajouter des paramètres à la demande pour indiquer si:
- le client doit envoyer une entrée à la commande du conteneur distant (stdin).
- le terminal du client est un TTY.
- la commande du conteneur distant doit envoyer la sortie de stdout au client.
- la commande du conteneur distant doit envoyer la sortie de stderr au client.
Après avoir envoyé une requête exec au serveur API, le client met à niveau la connexion vers celui qui prend en charge les flux multiplexés; l’implémentation actuelle utilise HTTP/2.
Le client crée un flux chacun pour stdin, stdout et stderr. Afin de distinguer entre les flux, le client définit l’en-tête streamType sur le flux sur l’un de stdin, stdout ou stderr.
Le client ferme tous les flux, la connexion mise à niveau et la connexion sous-jacente lorsqu’elle est terminée avec la demande d’exécution de commande à distance.
7.8. En utilisant le transfert de port pour accéder aux applications dans un conteneur Copier lienLien copié sur presse-papiers!
Le service Red Hat OpenShift sur AWS prend en charge le transfert de port vers les pods.
7.8.1. Comprendre l’expédition portuaire Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser le CLI pour transférer un ou plusieurs ports locaux vers un pod. Cela vous permet d’écouter sur un port donné ou aléatoire localement, et d’avoir des données transmises vers et à partir de ports donnés dans le pod.
Le support pour le transfert de ports est intégré dans le CLI:
oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]
$ oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]
Le CLI écoute sur chaque port local spécifié par l’utilisateur, en transmettant en utilisant le protocole décrit ci-dessous.
Les ports peuvent être spécifiés en utilisant les formats suivants:
| Le client écoute sur le port 5000 localement et transmet à 5000 dans le pod. |
| Le client écoute sur le port 6000 localement et transmet à 5000 dans le pod. |
:5000 ou 0:5000 | Le client sélectionne un port local gratuit et transmet à 5000 dans le pod. |
Le service OpenShift Red Hat sur AWS gère les demandes de port-avant des clients. Lors de la réception d’une demande, Red Hat OpenShift Service sur AWS met à niveau la réponse et attend que le client crée des flux d’avance de port. Lorsque Red Hat OpenShift Service sur AWS reçoit un nouveau flux, il copie les données entre le flux et le port du pod.
Architecturalement, il existe des options pour l’expédition vers le port d’un pod. Le Red Hat OpenShift Service supporté sur l’implémentation AWS invoque nsenter directement sur l’hôte du nœud pour entrer dans l’espace de noms réseau du pod, puis invoque socat pour copier des données entre le flux et le port du pod. Cependant, une implémentation personnalisée pourrait inclure l’exécution d’un module d’aide qui exécute ensuite nsenter et socat, de sorte que ces binaires ne sont pas tenus d’être installés sur l’hôte.
7.8.2. En utilisant le transfert de port Copier lienLien copié sur presse-papiers!
Le CLI permet d’utiliser un ou plusieurs ports locaux vers un pod.
Procédure
Consultez la commande suivante pour écouter le port spécifié dans un pod:
oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]
$ oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]
À titre d’exemple:
À l’aide de la commande suivante, écoutez les ports 5000 et 6000 localement et transmettez des données vers et depuis les ports 5000 et 6000 dans la pod:
oc port-forward <pod> 5000 6000
$ oc port-forward <pod> 5000 6000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Forwarding from 127.0.0.1:5000 -> 5000 Forwarding from [::1]:5000 -> 5000 Forwarding from 127.0.0.1:6000 -> 6000 Forwarding from [::1]:6000 -> 6000
Forwarding from 127.0.0.1:5000 -> 5000 Forwarding from [::1]:5000 -> 5000 Forwarding from 127.0.0.1:6000 -> 6000 Forwarding from [::1]:6000 -> 6000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À l’aide de la commande suivante pour écouter le port 8888 localement et passer à 5000 dans le pod:
oc port-forward <pod> 8888:5000
$ oc port-forward <pod> 8888:5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Forwarding from 127.0.0.1:8888 -> 5000 Forwarding from [::1]:8888 -> 5000
Forwarding from 127.0.0.1:8888 -> 5000 Forwarding from [::1]:8888 -> 5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Faites appel à la commande suivante pour écouter sur un port gratuit localement et passer à 5000 dans le pod:
oc port-forward <pod> :5000
$ oc port-forward <pod> :5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Forwarding from 127.0.0.1:42390 -> 5000 Forwarding from [::1]:42390 -> 5000
Forwarding from 127.0.0.1:42390 -> 5000 Forwarding from [::1]:42390 -> 5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow A) ou:
oc port-forward <pod> 0:5000
$ oc port-forward <pod> 0:5000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.8.3. Le protocole pour lancer le transfert de port à partir d’un client Copier lienLien copié sur presse-papiers!
Les clients initient le transfert de port vers un pod en envoyant une demande au serveur API Kubernetes:
/proxy/nodes/<node_name>/portForward/<namespace>/<pod>
/proxy/nodes/<node_name>/portForward/<namespace>/<pod>
Dans l’URL ci-dessus:
- <node_name> est le FQDN du nœud.
- <namespace> est l’espace de noms du pod cible.
- <pod> est le nom du pod cible.
À titre d’exemple:
/proxy/nodes/node123.openshift.com/portForward/myns/mypod
/proxy/nodes/node123.openshift.com/portForward/myns/mypod
Après l’envoi d’une demande de port vers le serveur API, le client met à niveau la connexion vers celui qui prend en charge les flux multiplexés; l’implémentation actuelle utilise Hyptertext Transfer Protocol Version 2 (HTTP/2).
Le client crée un flux avec l’en-tête de port contenant le port cible dans le pod. L’ensemble des données écrites au flux est livrée via le kubelet au pod cible et au port. De même, toutes les données envoyées à partir du pod pour cette connexion transmise sont remises au même flux dans le client.
Le client ferme tous les flux, la connexion mise à niveau et la connexion sous-jacente lorsqu’elle est terminée avec la demande de transfert de port.
Chapitre 8. En travaillant avec des clusters Copier lienLien copié sur presse-papiers!
8.1. Affichage des informations sur les événements système dans un Red Hat OpenShift Service sur AWS cluster Copier lienLien copié sur presse-papiers!
Les événements dans Red Hat OpenShift Service sur AWS sont modélisés sur la base d’événements qui se produisent aux objets API dans un Red Hat OpenShift Service sur le cluster AWS.
8.1.1. Comprendre les événements Copier lienLien copié sur presse-papiers!
Les événements permettent à Red Hat OpenShift Service sur AWS d’enregistrer des informations sur les événements du monde réel d’une manière agnostique des ressources. Ils permettent également aux développeurs et aux administrateurs de consommer des informations sur les composants système de manière unifiée.
8.1.2. Affichage des événements à l’aide du CLI Copier lienLien copié sur presse-papiers!
Il est possible d’obtenir une liste d’événements dans un projet donné à l’aide du CLI.
Procédure
Afin de visualiser les événements dans un projet, utilisez la commande suivante:
oc get events [-n <project>]
$ oc get events [-n <project>]
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le nom du projet.
À titre d’exemple:
oc get events -n openshift-config
$ oc get events -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Afficher les événements de votre projet à partir du service Red Hat OpenShift sur la console AWS.
- Lancez le Red Hat OpenShift Service sur la console AWS.
- Cliquez sur Accueil → Événements et sélectionnez votre projet.
Déplacez-vous vers la ressource que vous souhaitez voir les événements. À titre d’exemple: Home → Projets → <project-name> → <resource-name>.
De nombreux objets, tels que les pods et les déploiements, ont également leur propre onglet Événements, qui affiche les événements liés à cet objet.
8.1.3. Liste des événements Copier lienLien copié sur presse-papiers!
Cette section décrit les événements de Red Hat OpenShift Service sur AWS.
Le nom | Description |
---|---|
| Échec de la validation de la configuration de la pod. |
Le nom | Description |
---|---|
| Le redémarrage a échoué dans le conteneur. |
| Conteneur créé. |
| Tirer/Créer/Démarrer a échoué. |
| Je tue le conteneur. |
| Le conteneur a commencé. |
| En préemptant d’autres gousses. |
| Le temps d’exécution du conteneur n’a pas arrêté la gousse dans le délai de grâce spécifié. |
Le nom | Description |
---|---|
| Le conteneur est malsain. |
Le nom | Description |
---|---|
| Démarrez le Ctr, tirez sur l’image. |
| La politique NeverPull de l’image est violée. |
| Impossible de tirer l’image. |
| Impossible d’inspecter l’image. |
| L’image a été tirée avec succès ou l’image du conteneur est déjà présente sur la machine. |
| En tirant l’image. |
Le nom | Description |
---|---|
| L’espace disque libre a échoué. |
| Capacité du disque invalide. |
Le nom | Description |
---|---|
| Le montage en volume a échoué. |
| Le réseau hôte n’est pas pris en charge. |
| Conflit hôte/port. |
| La configuration du kubelet a échoué. |
| Formeur indéfini. |
| Le nœud n’est pas prêt. |
| Le nœud n’est pas programmé. |
| Le nœud est prêt. |
| Le nœud est programmé. |
| Inadéquation du sélecteur de nœuds. |
| Hors disque. |
| Le nœud a redémarré. |
| Démarrage du kubelet. |
| Impossible d’attacher le volume. |
| Je n’ai pas réussi à détacher le volume. |
| Impossible d’étendre/réduire le volume. |
| Augmentation/réduction du volume avec succès. |
| Impossible d’étendre/réduire le système de fichiers. |
| Développé / réduit avec succès système de fichiers. |
| Impossible de démonter le volume. |
| Impossible de cartographier un volume. |
| Échec de l’appareil non mappé. |
| Le volume est déjà monté. |
| Le volume est détaché avec succès. |
| Le volume est monté avec succès. |
| Le volume est démonté avec succès. |
| La collecte des ordures de conteneur a échoué. |
| La collecte des ordures d’image a échoué. |
| Impossible d’appliquer la limite de groupe réservé du système. |
| Limite de groupe réservé au système appliqué. |
| L’option de montage non prise en charge. |
| Le bac à sable de pod a changé. |
| Impossible de créer un bac à sable pod. |
| Échec de l’état du bac à sable. |
Le nom | Description |
---|---|
| La synchronisation des pod a échoué. |
Le nom | Description |
---|---|
| Il y a une situation OOM (hors mémoire) sur le cluster. |
Le nom | Description |
---|---|
| Je n’ai pas réussi à arrêter un pod. |
| Impossible de créer un conteneur de pod. |
| Impossible de créer des répertoires de données de pod. |
| Le réseau n’est pas prêt. |
| Erreur de création: <error-msg>. |
| Créé pod: <pod-name>. |
| Erreur de suppression: <error-msg>. |
| Dose supprimée: <pod-id>. |
Le nom | Description |
---|---|
Le sélecteur requis | Le sélecteur est requis. |
| Impossible de convertir le sélecteur en un objet sélecteur interne correspondant. |
| HPA n’a pas pu calculer le nombre de répliques. |
| Inconnu type de source métrique. |
| HPA a réussi à calculer un nombre de répliques. |
| Impossible de convertir le HPA donné. |
| Le contrôleur HPA n’a pas pu obtenir l’échelle actuelle de la cible. |
| Le contrôleur HPA a pu obtenir l’échelle actuelle de la cible. |
| Impossible de calculer le nombre désiré de répliques en fonction des métriques répertoriées. |
| La nouvelle taille: <size>; raison: <msg>; erreur: <error-msg>. |
| La nouvelle taille: <size>; raison: <msg>. |
| Impossible de mettre à jour l’état. |
Le nom | Description |
---|---|
| Il n’y a pas de volumes persistants disponibles et aucune classe de stockage n’est définie. |
| La taille ou la classe de volume est différente de ce qui est demandé dans la revendication. |
| Erreur de création de la gousse de recycleur. |
| Il se produit lorsque le volume est recyclé. |
| Il se produit lorsque la gousse est recyclée. |
| Il se produit lorsque le volume est supprimé. |
| Erreur lors de la suppression du volume. |
| Il se produit lorsque le volume de la réclamation est fourni manuellement ou via un logiciel externe. |
| Échec du volume de provision. |
| Erreur de nettoyage du volume provisionné. |
| Il se produit lorsque le volume est fourni avec succès. |
| Retarder la fixation jusqu’à la planification de la pod. |
Le nom | Description |
---|---|
| Le gestionnaire a échoué pour le démarrage du pod. |
| Le gestionnaire a échoué pour le pré-stop. |
| Crochet préarrêt inachevé. |
Le nom | Description |
---|---|
| Impossible d’annuler le déploiement. |
| Déploiement annulé. |
| Création d’un nouveau contrôleur de réplication. |
| Aucun IP Ingress disponible à allouer au service. |
Le nom | Description |
---|---|
| Impossible de programmer le pod: <pod-namespace>/<pod-name>. Cet événement est soulevé pour plusieurs raisons, par exemple: AssumePodVolumes a échoué, Binding rejeté etc. |
| Avec <preemptor-namespace>/<preemptor-name> sur le nœud <node-name>. |
| Attribué avec succès <pod-name> à <node-name>. |
Le nom | Description |
---|---|
| Cet ensemble de démons sélectionne tous les pods. Il faut un sélecteur non vide. |
| Impossible de placer le pod sur <node-name>. |
| Trouvé la pod de démon échouée <pod-name> sur le nœud <node-name>, va essayer de le tuer. |
Le nom | Description |
---|---|
| Erreur de création d’équilibreur de charge. |
| La suppression de l’équilibreur de charge. |
| Assurer l’équilibreur de charge. |
| Équilibreur de charge assuré. |
| Il n’y a pas de nœuds disponibles pour le service LoadBalancer. |
| Liste les nouveaux LoadBalancerSourceRanges. À titre d’exemple, <old-source-range> → <new-source-range>. |
| Liste la nouvelle adresse IP. À titre d’exemple, <old-ip> → <new-ip>. |
| Liste les adresses IP externes. À titre d’exemple, Ajouté : <external-ip>. |
| Liste le nouvel UID. À titre d’exemple, <old-service-uid> → <new-service-uid>. |
| Liste la nouvelle politique de trafic externe. A titre d’exemple, <old-policy> → <new-policy>. |
| Liste le nouveau HealthCheckNodePort. A titre d’exemple, <old-node-port> → new-node-port>. |
| Équilibreur de charge mis à jour avec de nouveaux hôtes. |
| Erreur de mise à jour de l’équilibreur de charge avec de nouveaux hôtes. |
| La suppression de l’équilibreur de charge. |
| Erreur supprimant l’équilibreur de charge. |
| Équilibreur de charge supprimé. |
8.2. Estimer le nombre de pods de votre Red Hat OpenShift Service sur les nœuds AWS peut contenir Copier lienLien copié sur presse-papiers!
En tant qu’administrateur de cluster, vous pouvez utiliser l’outil OpenShift Cluster Capacity Tool pour afficher le nombre de pods qui peuvent être programmés pour augmenter les ressources actuelles avant qu’elles ne soient épuisées, et pour s’assurer que tous les futurs pods peuvent être programmés. Cette capacité provient d’un hôte de nœuds individuel dans un cluster, et comprend le CPU, la mémoire, l’espace disque et d’autres.
8.2.1. Comprendre l’outil de capacité de cluster OpenShift Copier lienLien copié sur presse-papiers!
L’outil OpenShift Cluster Capacity Tool simule une séquence de décisions de planification pour déterminer combien d’instances d’un pod d’entrée peuvent être programmées sur le cluster avant qu’il ne soit épuisé des ressources pour fournir une estimation plus précise.
La capacité allocatable restante est une estimation approximative, car elle ne compte pas toutes les ressources distribuées entre les nœuds. Il analyse uniquement les ressources restantes et estime la capacité disponible qui est encore consommable en fonction d’un certain nombre de cas d’une pod avec des exigences données qui peuvent être programmées dans un cluster.
En outre, les gousses peuvent seulement avoir un support de planification sur des ensembles particuliers de nœuds en fonction de ses critères de sélection et d’affinité. En conséquence, il peut être difficile d’estimer les pods restants d’un cluster.
Il est possible d’exécuter l’outil OpenShift Cluster Capacity Tool en tant qu’utilitaire autonome à partir de la ligne de commande, ou en tant que travail dans un pod à l’intérieur d’un service Red Hat OpenShift sur le cluster AWS. L’exécution de l’outil en tant que travail à l’intérieur d’un pod vous permet de l’exécuter plusieurs fois sans intervention.
8.2.2. Exécution de l’outil OpenShift Cluster Capacity Tool sur la ligne de commande Copier lienLien copié sur presse-papiers!
À partir de la ligne de commande, vous pouvez exécuter l’outil OpenShift Cluster Capacity Tool pour estimer le nombre de pods pouvant être programmés sur votre cluster.
Créez un exemple de fichier spec de pod, que l’outil utilise pour estimer l’utilisation des ressources. Le pod spec spécifie ses besoins en ressources comme limites ou demandes. L’outil de capacité des clusters tient compte des besoins en ressources de la pod pour son analyse d’estimation.
Conditions préalables
- Exécutez l’outil OpenShift Cluster Capacity Tool, qui est disponible sous forme d’image conteneur à partir du catalogue de l’écosystème Red Hat.
Créer un fichier spec de pod d’échantillon:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer le rôle du cluster:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc create -f pod-spec.yaml
$ oc create -f pod-spec.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procédure
D’utiliser l’outil de capacité de cluster sur la ligne de commande:
À partir du terminal, connectez-vous au Registre Red Hat:
podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Tirez l’image de l’outil de capacité de cluster:
podman pull registry.redhat.io/openshift4/ose-cluster-capacity
$ podman pull registry.redhat.io/openshift4/ose-cluster-capacity
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez l’outil de capacité de cluster:
podman run -v $HOME/.kube:/kube:Z -v $(pwd):/cc:Z ose-cluster-capacity \ /bin/cluster-capacity --kubeconfig /kube/config --<pod_spec>.yaml /cc/<pod_spec>.yaml \ --verbose
$ podman run -v $HOME/.kube:/kube:Z -v $(pwd):/cc:Z ose-cluster-capacity \ /bin/cluster-capacity --kubeconfig /kube/config --<pod_spec>.yaml /cc/<pod_spec>.yaml \ --verbose
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
- <pod_spec>.yaml
- Spécifie le pod spec à utiliser.
- le verbose
- Affiche une description détaillée du nombre de gousses pouvant être programmées sur chaque nœud du cluster.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans l’exemple ci-dessus, le nombre de gousses estimées pouvant être programmées sur le cluster est de 88.
8.2.3. Exécuter l’outil OpenShift Cluster Capacité en tant que travail à l’intérieur d’un pod Copier lienLien copié sur presse-papiers!
L’exécution de l’outil OpenShift Cluster Capacity Tool en tant que travail à l’intérieur d’un pod vous permet d’exécuter l’outil plusieurs fois sans avoir besoin d’intervention de l’utilisateur. Exécutez l’outil OpenShift Cluster Capacity Tool en tant que travail à l’aide d’un objet ConfigMap.
Conditions préalables
Installez et téléchargez l’outil OpenShift Cluster Capacity Tool.
Procédure
Exécuter l’outil de capacité de cluster:
Créer le rôle du cluster:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le rôle de cluster en exécutant la commande suivante:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc create sa cluster-capacity-sa
$ oc create sa cluster-capacity-sa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créer le compte de service:
oc create sa cluster-capacity-sa -n default
$ oc create sa cluster-capacity-sa -n default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ajouter le rôle au compte de service:
oc adm policy add-cluster-role-to-user cluster-capacity-role \ system:serviceaccount:<namespace>:cluster-capacity-sa
$ oc adm policy add-cluster-role-to-user cluster-capacity-role \ system:serviceaccount:<namespace>:cluster-capacity-sa
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
- <namespace>
- Indique l’espace de noms où se trouve le pod.
Définir et créer le pod spec:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod en exécutant la commande suivante:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
oc create -f pod.yaml
$ oc create -f pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créé un objet map config en exécutant la commande suivante:
oc create configmap cluster-capacity-configmap \ --from-file=pod.yaml=pod.yaml
$ oc create configmap cluster-capacity-configmap \ --from-file=pod.yaml=pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow L’analyse de la capacité du cluster est montée dans un volume à l’aide d’un objet mappage nommé cluster-capacity-configmap pour monter le fichier pod.yaml dans un volume de test de volume sur le chemin /test-pod.
Créez le travail à l’aide de l’exemple ci-dessous d’un fichier de spécification d’emploi:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La variable d’environnement requise permet à l’outil de capacité de cluster de savoir qu’il s’exécute à l’intérieur d’un cluster en tant que pod.
La clé pod.yaml de l’objet ConfigMap est identique au nom du fichier Pod spec, bien qu’il ne soit pas requis. Ce faisant, le fichier d’entrée de pod spec peut être accédé à l’intérieur du pod comme /test-pod/pod.yaml.
Exécutez l’image de capacité de cluster en tant que travail dans un pod en exécutant la commande suivante:
oc create -f cluster-capacity-job.yaml
$ oc create -f cluster-capacity-job.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Consultez les journaux des tâches pour trouver le nombre de pods pouvant être programmés dans le cluster:
oc logs jobs/cluster-capacity-job
$ oc logs jobs/cluster-capacity-job
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3. Limiter la consommation de ressources avec des fourchettes limites Copier lienLien copié sur presse-papiers!
Les conteneurs s’exécutent par défaut avec des ressources de calcul non liées sur un service Red Hat OpenShift sur le cluster AWS. Avec des plages limites, vous pouvez limiter la consommation de ressources pour des objets spécifiques dans un projet:
- gousses et conteneurs: Vous pouvez définir des exigences minimales et maximales pour le CPU et la mémoire pour les pods et leurs conteneurs.
- Flux d’images: Vous pouvez définir des limites sur le nombre d’images et de balises dans un objet ImageStream.
- Images: Vous pouvez limiter la taille des images qui peuvent être poussées à un registre interne.
- Allégations de volume persistants (PVC): Vous pouvez restreindre la taille des PVC qui peuvent être demandés.
Lorsqu’un pod ne répond pas aux contraintes imposées par la plage limite, le pod ne peut pas être créé dans l’espace de noms.
8.3.1. À propos des limites Copier lienLien copié sur presse-papiers!
La plage limite, définie par un objet LimitRange, limite la consommation de ressources dans un projet. Dans le projet, vous pouvez définir des limites de ressources spécifiques pour un pod, un conteneur, une image, un flux d’images ou une revendication de volume persistant (PVC).
Les demandes de création et de modification de ressources sont évaluées par rapport à chaque objet LimitRange du projet. En cas de violation de l’une des contraintes énumérées, la ressource est rejetée.
Ce qui suit montre un objet de plage limite pour tous les composants: pod, conteneur, image, flux d’images ou PVC. Il est possible de configurer des limites pour l’un ou l’autre de ces composants dans le même objet. Créez un objet de plage limite différent pour chaque projet où vous souhaitez contrôler les ressources.
Échantillon limite objet de portée pour un conteneur
8.3.1.1. À propos des limites des composants Copier lienLien copié sur presse-papiers!
Les exemples suivants montrent les paramètres de plage limite pour chaque composant. Les exemples sont révélés pour plus de clarté. Il est possible de créer un seul objet LimitRange pour n’importe quel ou tous les composants si nécessaire.
8.3.1.1.1. Limites du conteneur Copier lienLien copié sur presse-papiers!
La plage limite vous permet de spécifier le CPU et la mémoire minimum et maximum que chaque conteneur d’un pod peut demander pour un projet spécifique. Lorsqu’un conteneur est créé dans le projet, les requêtes CPU et mémoire du conteneur dans la spécification Pod doivent respecter les valeurs définies dans l’objet LimitRange. Dans le cas contraire, la gousse n’est pas créée.
- La requête et la limite de CPU de conteneur ou de mémoire doivent être supérieures ou égales à la contrainte de ressource min pour les conteneurs qui sont spécifiés dans l’objet LimitRange.
La requête et la limite de CPU de conteneur ou de mémoire doivent être inférieures ou égales à la contrainte de ressource maximale pour les conteneurs qui sont spécifiés dans l’objet LimitRange.
Lorsque l’objet LimitRange définit un CPU max, vous n’avez pas besoin de définir une valeur de requête CPU dans la spécification Pod. Cependant, vous devez spécifier une valeur limite CPU qui satisfait à la contrainte maximale du CPU spécifiée dans la plage de limites.
Le rapport entre les limites du conteneur et les demandes doit être inférieur ou égal à la valeur maxLimitRequestRatio pour les conteneurs spécifiés dans l’objet LimitRange.
Lorsque l’objet LimitRange définit une contrainte maxLimitRequestRatio, tout nouveau conteneur doit avoir à la fois une requête et une valeur limite. Le service OpenShift Red Hat sur AWS calcule le ratio limite/demande en divisant la limite par la demande. Cette valeur devrait être un entier non négatif supérieur à 1.
À titre d’exemple, si un conteneur a cpu: 500 dans la valeur limite, et cpu: 100 dans la valeur de requête, le rapport limite-demande pour cpu est 5. Ce ratio doit être inférieur ou égal au rapport maxLimitRequestRatio.
Dans le cas où la spécification Pod ne spécifie pas de mémoire ou de limite de ressource de conteneur, les valeurs CPU et mémoire par défautRequest CPU et mémoire pour les conteneurs spécifiés dans l’objet de la plage limite sont assignées au conteneur.
Définition de l’objet LimitRange de conteneur
- 1
- Le nom de l’objet LimitRange.
- 2
- La quantité maximale de CPU qu’un seul conteneur dans un pod peut demander.
- 3
- La quantité maximale de mémoire qu’un seul conteneur dans un pod peut demander.
- 4
- La quantité minimale de CPU qu’un seul conteneur dans un pod peut demander.
- 5
- La quantité minimale de mémoire qu’un seul conteneur dans un pod peut demander.
- 6
- La quantité par défaut de CPU qu’un conteneur peut utiliser s’il n’est pas spécifié dans la spécification Pod.
- 7
- La quantité de mémoire par défaut qu’un conteneur peut utiliser s’il n’est pas spécifié dans la spécification Pod.
- 8
- La quantité par défaut de CPU qu’un conteneur peut demander s’il n’est pas spécifié dans la spécification Pod.
- 9
- La quantité de mémoire par défaut qu’un conteneur peut demander s’il n’est pas spécifié dans la spécification Pod.
- 10
- Le rapport limite/demande maximum pour un conteneur.
8.3.1.1.2. Limites de pod Copier lienLien copié sur presse-papiers!
La plage limite vous permet de spécifier les limites minimales et maximales de CPU et de mémoire pour tous les conteneurs d’un pod dans un projet donné. Afin de créer un conteneur dans le projet, les requêtes CPU et mémoire du conteneur dans la spécification Pod doivent respecter les valeurs définies dans l’objet LimitRange. Dans le cas contraire, la gousse n’est pas créée.
Dans le cas où la spécification Pod ne spécifie pas de mémoire ou de limite de ressource de conteneur, les valeurs CPU et mémoire par défautRequest CPU et mémoire pour les conteneurs spécifiés dans l’objet de la plage limite sont assignées au conteneur.
Dans tous les conteneurs d’une gousse, les éléments suivants doivent être vrais:
- La requête et la limite de CPU de conteneur ou de mémoire doivent être supérieures ou égales aux contraintes de ressources min pour les pods qui sont spécifiés dans l’objet LimitRange.
- Le CPU de conteneur ou la requête et la limite de mémoire doivent être inférieures ou égales aux contraintes de ressources maximales pour les pods qui sont spécifiés dans l’objet LimitRange.
- Le rapport entre les limites du conteneur et les requêtes doit être inférieur ou égal à la contrainte maxLimitRequestRatio spécifiée dans l’objet LimitRange.
Définition de l’objet Pod LimitRange
- 1
- Le nom de l’objet de plage limite.
- 2
- La quantité maximale de CPU qu’un pod peut demander sur tous les conteneurs.
- 3
- La quantité maximale de mémoire qu’un pod peut demander sur tous les conteneurs.
- 4
- La quantité minimale de CPU qu’un pod peut demander sur tous les conteneurs.
- 5
- La quantité minimale de mémoire qu’un pod peut demander sur tous les conteneurs.
- 6
- Le rapport limite/demande maximum pour un conteneur.
8.3.1.1.3. Limites d’image Copier lienLien copié sur presse-papiers!
L’objet LimitRange vous permet de spécifier la taille maximale d’une image qui peut être poussée vers un registre d’images OpenShift.
Lorsque vous poussez des images vers un registre d’images OpenShift, les éléments suivants doivent être vrais:
- La taille de l’image doit être inférieure ou égale à la taille maximale pour les images spécifiées dans l’objet LimitRange.
Définition de l’objet LimitRange d’image
La taille de l’image n’est pas toujours disponible dans le manifeste d’une image téléchargée. C’est particulièrement le cas pour les images construites avec Docker 1.10 ou supérieure et poussées vers un registre v2. Lorsqu’une telle image est tirée avec un démon Docker plus ancien, le manifeste de l’image est converti par le registre en schema v1 dépourvu de toutes les informations de taille. Aucune limite de stockage définie sur les images ne l’empêche d’être téléchargée.
La question est en cours d’examen.
8.3.1.1.4. Limites de flux d’images Copier lienLien copié sur presse-papiers!
L’objet LimitRange vous permet de spécifier des limites pour les flux d’images.
Dans chaque flux d’images, les éléments suivants doivent être vrais:
- Le nombre de balises d’image dans une spécification ImageStream doit être inférieur ou égal à la contrainte openshift.io/image-tags dans l’objet LimitRange.
- Le nombre de références uniques aux images dans une spécification ImageStream doit être inférieur ou égal à la contrainte openshift.io/images dans l’objet de plage limite.
Définition d’objet ImageStream LimitRange
La ressource openshift.io/image-tags représente des références d’image uniques. Les références possibles sont un ImageStreamTag, une ImageStreamImage et un DockerImage. Les balises peuvent être créées à l’aide des commandes oc tag et oc import-image. Aucune distinction n’est faite entre les références internes et externes. Cependant, chaque référence unique marquée dans une spécification ImageStream est comptée une seule fois. Il ne limite pas les poussées à un registre d’images de conteneur interne de quelque manière que ce soit, mais est utile pour la restriction des balises.
La ressource openshift.io/images représente des noms d’images uniques enregistrés dans l’état du flux d’images. Il permet de restreindre un certain nombre d’images qui peuvent être poussées au registre d’images OpenShift. Les références internes et externes ne sont pas distinguées.
8.3.1.1.5. Limites persistantes des revendications de volume Copier lienLien copié sur presse-papiers!
L’objet LimitRange vous permet de restreindre le stockage demandé dans une revendication de volume persistant (PVC).
Dans toutes les revendications de volume persistantes dans un projet, les éléments suivants doivent être vrais:
- La demande de ressource dans une revendication de volume persistant (PVC) doit être supérieure ou égale à la contrainte minimale pour les PVC spécifiée dans l’objet LimitRange.
- La demande de ressource dans une revendication de volume persistant (PVC) doit être inférieure ou égale à la contrainte maximale pour les PVC spécifiée dans l’objet LimitRange.
Définition d’objet en PVC LimitRange
8.3.2. Création d’une gamme de limites Copier lienLien copié sur presse-papiers!
Appliquer une plage limite à un projet:
Créez un objet LimitRange avec vos spécifications requises:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez un nom pour l’objet LimitRange.
- 2
- Afin de fixer des limites pour un pod, spécifiez les demandes minimales et maximales de CPU et de mémoire au besoin.
- 3
- Afin de fixer des limites pour un conteneur, spécifiez les demandes minimales et maximales de CPU et de mémoire au besoin.
- 4
- En option. Dans le cas d’un conteneur, spécifiez la quantité par défaut de CPU ou de mémoire qu’un conteneur peut utiliser, s’il n’est pas spécifié dans la spécification Pod.
- 5
- En option. Dans le cas d’un conteneur, spécifiez la quantité par défaut de CPU ou de mémoire qu’un conteneur peut demander, s’il n’est pas spécifié dans la spécification Pod.
- 6
- En option. Dans le cas d’un conteneur, spécifiez le rapport limite/demande maximum qui peut être spécifié dans la spécification Pod.
- 7
- Afin de définir des limites pour un objet Image, définissez la taille maximale d’une image qui peut être poussée à un registre d’images OpenShift.
- 8
- Afin de définir des limites pour un flux d’images, définissez le nombre maximal de balises d’image et de références qui peuvent être dans le fichier objet ImageStream, au besoin.
- 9
- Afin de fixer des limites pour une revendication de volume persistant, fixez la quantité minimale et maximale de stockage qui peut être demandée.
Créer l’objet:
oc create -f <limit_range_file> -n <project>
$ oc create -f <limit_range_file> -n <project>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le nom du fichier YAML que vous avez créé et le projet où vous souhaitez que les limites s’appliquent.
8.3.3. Afficher une limite Copier lienLien copié sur presse-papiers!
Il est possible d’afficher les limites définies dans un projet en naviguant dans la console Web vers la page Quota du projet.
Il est également possible d’utiliser le CLI pour afficher les détails de la plage limite:
Accédez à la liste de l’objet LimitRange défini dans le projet. À titre d’exemple, pour un projet appelé démoproject:
oc get limits -n demoproject
$ oc get limits -n demoproject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME CREATED AT resource-limits 2020-07-15T17:14:23Z
NAME CREATED AT resource-limits 2020-07-15T17:14:23Z
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Décrivez l’objet LimitRange qui vous intéresse, par exemple la plage de limites ressources-limites:
oc describe limits resource-limits -n demoproject
$ oc describe limits resource-limits -n demoproject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.4. La suppression d’une plage de limites Copier lienLien copié sur presse-papiers!
De supprimer tout objet LimitRange actif pour ne plus appliquer les limites d’un projet:
Exécutez la commande suivante:
oc delete limits <limit_name>
$ oc delete limits <limit_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Configuration de la mémoire cluster pour répondre aux exigences de mémoire de conteneur et de risque Copier lienLien copié sur presse-papiers!
En tant qu’administrateur de clusters, vous pouvez aider vos clusters à fonctionner efficacement grâce à la gestion de la mémoire d’application en:
- Déterminer les exigences en matière de mémoire et de risque d’un composant d’application conteneurisé et configurer les paramètres de mémoire du conteneur pour répondre à ces exigences.
- Configuration d’exécutions d’applications conteneurisées (par exemple, OpenJDK) pour adhérer de manière optimale aux paramètres de mémoire de conteneur configurés.
- Diagnostiquer et résoudre les conditions d’erreur liées à la mémoire associées à l’exécution dans un conteneur.
8.4.1. Comprendre la gestion de la mémoire applicative Copier lienLien copié sur presse-papiers!
Il est recommandé de lire pleinement l’aperçu de la façon dont Red Hat OpenShift Service sur AWS gère les ressources de calcul avant de procéder.
Dans chaque type de ressource (mémoire, CPU, stockage), Red Hat OpenShift Service sur AWS permet de placer des valeurs de requête et limites optionnelles sur chaque conteneur dans un pod.
À noter ce qui suit au sujet des requêtes de mémoire et des limites de mémoire:
Demande de mémoire
- La valeur de la demande de mémoire, si elle est spécifiée, influence le service Red Hat OpenShift sur AWS. Le planificateur prend en compte la demande de mémoire lors de la planification d’un conteneur à un nœud, puis clôture la mémoire demandée sur le nœud choisi pour l’utilisation du conteneur.
- En cas d’épuisement de la mémoire d’un nœud, Red Hat OpenShift Service sur AWS donne la priorité à l’expulsion de ses conteneurs dont l’utilisation de la mémoire dépasse le plus leur demande de mémoire. Dans les cas graves d’épuisement de la mémoire, le tueur OOM peut sélectionner et tuer un processus dans un conteneur en fonction d’une métrique similaire.
- L’administrateur du cluster peut attribuer un quota ou attribuer des valeurs par défaut pour la valeur de demande de mémoire.
- L’administrateur de cluster peut outrepasser les valeurs de requête de mémoire qu’un développeur spécifie, pour gérer le cluster overcommit.
Limite de mémoire
- La valeur limite de mémoire, si spécifiée, fournit une limite dure sur la mémoire qui peut être allouée sur tous les processus d’un conteneur.
- Lorsque la mémoire allouée par tous les processus d’un conteneur dépasse la limite de mémoire, le tueur hors mémoire (OOM) sélectionne et tue immédiatement un processus dans le conteneur.
- Lorsque la requête mémoire et la limite sont spécifiées, la valeur limite de mémoire doit être supérieure ou égale à la requête mémoire.
- L’administrateur du cluster peut attribuer un quota ou attribuer des valeurs par défaut pour la valeur limite de mémoire.
- La limite minimale de mémoire est de 12 Mo. En cas de démarrage d’un conteneur en raison d’un événement de Pod de mémoire impossible, la limite de mémoire est trop faible. Augmentez ou supprimez la limite de mémoire. La suppression de la limite permet aux gousses de consommer des ressources de nœuds non limitées.
8.4.1.1. Gestion de la stratégie de mémoire des applications Copier lienLien copié sur presse-papiers!
Les étapes de dimensionnement de la mémoire de l’application sur Red Hat OpenShift Service sur AWS sont les suivantes:
Déterminer l’utilisation prévue de la mémoire de conteneur
Déterminer l’utilisation prévue de la mémoire moyenne et maximale du conteneur, empiriquement si nécessaire (par exemple, par des tests de charge séparés). Considérez tous les processus qui peuvent potentiellement s’exécuter en parallèle dans le conteneur: par exemple, l’application principale génère-t-elle des scripts auxiliaires?
Déterminer l’appétit du risque
Déterminer l’appétit de risque pour l’expulsion. Lorsque l’appétit de risque est faible, le conteneur doit demander de la mémoire en fonction de l’utilisation maximale prévue plus un pourcentage de marge de sécurité. Lorsque l’appétit de risque est plus élevé, il peut être plus approprié de demander de la mémoire en fonction de l’utilisation moyenne prévue.
Définir la demande de mémoire de conteneur
Définissez la demande de mémoire de conteneur en fonction de ce qui précède. Le plus précisément la demande représente l’utilisation de la mémoire de l’application, mieux c’est. Lorsque la demande est trop élevée, l’utilisation des grappes et des quotas sera inefficace. Lorsque la demande est trop faible, les chances d’expulsion de l’application augmentent.
Définir la limite de mémoire du conteneur, si nécessaire
Définissez la limite de mémoire du conteneur, si nécessaire. Fixer une limite a pour effet de tuer immédiatement un processus de conteneur si l’utilisation combinée de la mémoire de tous les processus dans le conteneur dépasse la limite, et est donc une bénédiction mixte. D’une part, il peut rendre l’utilisation excessive de mémoire imprévue évidente tôt ("échec rapide"); d’autre part, il met également fin aux processus brusquement.
Il est à noter que certains Red Hat OpenShift Service sur les clusters AWS peuvent nécessiter une valeur limite à définir; certains peuvent outrepasser la demande en fonction de la limite; et certaines images de l’application dépendent d’une valeur limite définie car cela est plus facile à détecter qu’une valeur de requête.
Lorsque la limite de mémoire est définie, elle ne doit pas être inférieure à l’utilisation prévue de la mémoire du conteneur de pointe plus une marge de sécurité en pourcentage.
Assurez-vous que l’application est réglée
Assurez-vous que l’application est réglée en ce qui concerne les valeurs de requête configurées et les valeurs limites, le cas échéant. Cette étape est particulièrement pertinente pour les applications qui mettent en commun la mémoire, comme le JVM. Le reste de cette page en traite.
8.4.2. Comprendre les paramètres OpenJDK pour Red Hat OpenShift Service sur AWS Copier lienLien copié sur presse-papiers!
Les paramètres OpenJDK par défaut ne fonctionnent pas bien avec les environnements conteneurisés. En conséquence, certains paramètres de mémoire Java supplémentaires doivent toujours être fournis chaque fois qu’on exécute l’OpenJDK dans un conteneur.
La mise en page de la mémoire JVM est complexe, dépendante de la version, et la décrire en détail dépasse le champ d’application de cette documentation. Cependant, comme point de départ pour l’exécution d’OpenJDK dans un conteneur, au moins les trois tâches suivantes liées à la mémoire sont essentielles:
- Dépassement de la taille maximale du tas JVM.
- Encourager le JVM à libérer la mémoire inutilisée au système d’exploitation, le cas échéant.
- Assurer la configuration appropriée de tous les processus JVM dans un conteneur.
Le réglage optimal des charges de travail JVM pour l’exécution dans un conteneur est au-delà de la portée de cette documentation, et peut impliquer la définition de plusieurs options JVM supplémentaires.
8.4.2.1. Comprendre comment remplacer la taille maximale du tas JVM Copier lienLien copié sur presse-papiers!
« pour de nombreuses charges de travail Java, le tas JVM est le plus grand consommateur de mémoire. Actuellement, l’OpenJDK permet par défaut de permettre jusqu’à 1/4 (1/-XX:MaxRAMFraction) de la mémoire du nœud de calcul à utiliser pour le tas, que l’OpenJDK fonctionne ou non dans un conteneur. Il est donc essentiel de remplacer ce comportement, surtout si une limite de mémoire de conteneur est également définie.
Il y a au moins deux façons d’atteindre ce qui précède:
Lorsque la limite de mémoire du conteneur est définie et que les options expérimentales sont prises en charge par le JVM, set -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap.
NoteL’option UseCGroupMemoryLimitForHeap a été supprimée dans JDK 11. À la place, utilisez -XX:+UseContainerSupport.
Ceci définit -XX:MaxRAM à la limite de mémoire du conteneur, et la taille maximale du tas (-XX:MaxHeapSize / -Xmx) à 1/-XX:MaxRAMFraction (1/4 par défaut).
Remplacez directement l’un des -XX:MaxRAM, -XX:MaxHeapSize ou -Xmx.
Cette option implique un codage dur d’une valeur, mais a l’avantage de permettre le calcul d’une marge de sécurité.
8.4.2.2. Comprendre comment encourager le JVM à libérer de la mémoire inutilisée au système d’exploitation Copier lienLien copié sur presse-papiers!
L’OpenJDK ne renvoie pas de manière agressive la mémoire inutilisée au système d’exploitation. Cela peut être approprié pour de nombreuses charges de travail Java conteneurisées, mais des exceptions notables incluent des charges de travail où des processus actifs supplémentaires coexistent avec un JVM dans un conteneur, que ces processus supplémentaires soient natifs, JVM supplémentaires ou une combinaison des deux.
Les agents basés sur Java peuvent utiliser les arguments JVM suivants pour encourager le JVM à libérer de la mémoire inutilisée au système d’exploitation:
-XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90.
-XX:+UseParallelGC
-XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90.
Ces arguments sont destinés à renvoyer la mémoire tas au système d’exploitation chaque fois que la mémoire allouée dépasse 110% de la mémoire en usage (-XX:MaxHeapFreeRatio), passant jusqu’à 20% du temps CPU dans le collecteur d’ordures (-XX:GCTimeRatio). À aucun moment, l’allocation du tas d’application ne sera inférieure à l’allocation initiale du tas (surpassée par -XX:InitialHeapSize / -Xms). L’empreinte de Java dans OpenShift (Partie 1), l’empreinte de Java dans OpenShift (Partie 2) et OpenJDK et Containers.
8.4.2.3. Comprendre comment s’assurer que tous les processus JVM dans un conteneur sont correctement configurés Copier lienLien copié sur presse-papiers!
Dans le cas où plusieurs JVM s’exécutent dans le même conteneur, il est essentiel de s’assurer qu’ils sont tous configurés de manière appropriée. Dans de nombreuses charges de travail, il sera nécessaire d’accorder à chaque JVM un budget de mémoire en pourcentage, laissant une marge de sécurité supplémentaire peut-être substantielle.
De nombreux outils Java utilisent différentes variables d’environnement (JAVA_OPTS, GRADLE_OPTS, etc.) pour configurer leurs JVM et il peut être difficile de s’assurer que les bons paramètres sont passés au bon JVM.
La variable d’environnement JAVA_TOOL_OPTIONS est toujours respectée par OpenJDK, et les valeurs spécifiées dans JAVA_TOOL_OPTIONS seront remplacées par d’autres options spécifiées sur la ligne de commande JVM. Afin de s’assurer que ces options sont utilisées par défaut pour toutes les charges de travail JVM exécutées dans l’image de l’agent basé sur Java, le Red Hat OpenShift Service sur AWS Jenkins Maven jeu d’image d’agent:
JAVA_TOOL_OPTIONS="-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"
JAVA_TOOL_OPTIONS="-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"
L’option UseCGroupMemoryLimitForHeap a été supprimée dans JDK 11. À la place, utilisez -XX:+UseContainerSupport.
Cela ne garantit pas que d’autres options ne sont pas nécessaires, mais est destinée à être un point de départ utile.
8.4.3. La recherche de la requête et de la limite de mémoire à l’intérieur d’un pod Copier lienLien copié sur presse-papiers!
L’application qui souhaite découvrir dynamiquement sa demande de mémoire et sa limite à partir d’un pod doit utiliser l’API Downward.
Procédure
Configurez le pod pour ajouter les sanzas MEMORY_REQUEST et MEMORY_LIMIT:
Créez un fichier YAML similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le pod en exécutant la commande suivante:
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Accédez au pod à l’aide d’un shell distant:
oc rsh test
$ oc rsh test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que les valeurs demandées ont été appliquées:
env | grep MEMORY | sort
$ env | grep MEMORY | sort
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
MEMORY_LIMIT=536870912 MEMORY_REQUEST=402653184
MEMORY_LIMIT=536870912 MEMORY_REQUEST=402653184
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La valeur limite de mémoire peut également être lue à l’intérieur du conteneur par le fichier /sys/fs/cgroup/memory.limit_in_bytes.
8.4.4. Comprendre la politique de l’OOM Copier lienLien copié sur presse-papiers!
Le service OpenShift de Red Hat sur AWS peut tuer un processus dans un conteneur si l’utilisation totale de la mémoire de tous les processus dans le conteneur dépasse la limite de mémoire, ou dans les cas graves d’épuisement de la mémoire des nœuds.
Lorsqu’un processus est hors mémoire (OOM) tué, cela peut entraîner la sortie immédiate du conteneur. Lorsque le procédé PID 1 du conteneur reçoit le SIGKILL, le conteneur sortira immédiatement. Dans le cas contraire, le comportement du conteneur dépend du comportement des autres processus.
À titre d’exemple, un processus de conteneur est sorti avec le code 137, indiquant qu’il a reçu un signal SIGKILL.
Dans le cas où le conteneur ne sort pas immédiatement, une mise à mort d’OOM est détectable comme suit:
Accédez au pod à l’aide d’un shell distant:
oc rsh test
# oc rsh test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour voir le compte de destruction OOM actuel dans /sys/fs/cgroup/memory/memory.oom_control:
grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
$ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
oom_kill 0
oom_kill 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour provoquer un meurtre d’OOM:
sed -e '' </dev/zero
$ sed -e '' </dev/zero
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Killed
Killed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour afficher l’état de sortie de la commande sed:
echo $?
$ echo $?
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
137
137
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le code 137 indique le processus de conteneur sorti avec le code 137, indiquant qu’il a reçu un signal SIGKILL.
Exécutez la commande suivante pour voir que le compteur OOM kill dans /sys/fs/cgroup/memory/memory.oom_control incrémented:
grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
$ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
oom_kill 1
oom_kill 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsqu’un ou plusieurs processus dans une gousse sont tués, lorsque la gousse quitte par la suite, que ce soit immédiatement ou non, elle aura échoué et raisonne OOMKilled. Il est possible qu’une gousse tuée par OOM soit redémarrée en fonction de la valeur de redémarragePolicy. En cas de redémarrage, les contrôleurs tels que le contrôleur de réplication remarqueront l’état raté du pod et créeront un nouveau pod pour remplacer l’ancien.
Faites appel à la commande follwing pour obtenir le statut du pod:
oc get pod test
$ oc get pod test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME READY STATUS RESTARTS AGE test 0/1 OOMKilled 0 1m
NAME READY STATUS RESTARTS AGE test 0/1 OOMKilled 0 1m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque le pod n’a pas redémarré, exécutez la commande suivante pour afficher le pod:
oc get pod test -o yaml
$ oc get pod test -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow En cas de redémarrage, exécutez la commande suivante pour afficher le pod:
oc get pod test -o yaml
$ oc get pod test -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.5. Comprendre l’expulsion des pod Copier lienLien copié sur presse-papiers!
Le service OpenShift Red Hat sur AWS peut expulser un pod de son nœud lorsque la mémoire du nœud est épuisée. En fonction de l’ampleur de l’épuisement de la mémoire, l’expulsion peut ou peut ne pas être gracieuse. L’expulsion gracieuse implique le processus principal (PID 1) de chaque conteneur recevant un signal SIGTERM, puis quelque temps plus tard un signal SIGKILL si le processus n’est pas déjà sorti. L’expulsion non gracieuse implique le processus principal de chaque conteneur recevant immédiatement un signal SIGKILL.
La phase d’expulsion d’une gousse a échoué et la raison de l’expulsion. Il ne sera pas redémarré, quelle que soit la valeur de redémarragePolicy. Cependant, les contrôleurs tels que le contrôleur de réplication remarqueront l’état défaillant du pod et créeront un nouveau pod pour remplacer l’ancien.
oc get pod test
$ oc get pod test
Exemple de sortie
NAME READY STATUS RESTARTS AGE test 0/1 Evicted 0 1m
NAME READY STATUS RESTARTS AGE
test 0/1 Evicted 0 1m
oc get pod test -o yaml
$ oc get pod test -o yaml
Exemple de sortie
... status: message: 'Pod The node was low on resource: [MemoryPressure].' phase: Failed reason: Evicted
...
status:
message: 'Pod The node was low on resource: [MemoryPressure].'
phase: Failed
reason: Evicted
8.5. Configuration de votre cluster pour placer des pods sur des nœuds surengagés Copier lienLien copié sur presse-papiers!
Dans un état surengagé, la somme du conteneur calcule les demandes de ressources et les limites dépasse les ressources disponibles sur le système. À titre d’exemple, vous voudrez peut-être utiliser un surengagement dans des environnements de développement où un compromis de performance garantie pour la capacité est acceptable.
Les conteneurs peuvent spécifier les demandes de ressources et les limites de calcul. Les demandes sont utilisées pour planifier votre conteneur et fournir une garantie de service minimale. Les limites limitent la quantité de ressources de calcul qui peuvent être consommées sur votre nœud.
Le planificateur tente d’optimiser l’utilisation des ressources de calcul sur tous les nœuds de votre cluster. Il place les pods sur des nœuds spécifiques, en tenant compte des demandes de ressources de calcul des pods et de la capacité disponible des nœuds.
Les administrateurs AWS peuvent gérer la densité des conteneurs sur les nœuds en configurant le comportement de placement de pod et les limites de ressources par projet qui ne peuvent pas dépasser.
Alternativement, les administrateurs peuvent désactiver le surengagement de ressources au niveau du projet sur des espaces de noms créés par le client qui ne sont pas gérés par Red Hat.
En savoir plus sur la gestion des ressources de conteneurs, voir Ressources supplémentaires.
8.5.1. Limites au niveau du projet Copier lienLien copié sur presse-papiers!
Dans Red Hat OpenShift Service sur AWS, le surengagement des ressources au niveau du projet est activé par défaut. En cas de besoin dans votre cas d’utilisation, vous pouvez désactiver le surengagement sur des projets qui ne sont pas gérés par Red Hat.
En ce qui concerne la liste des projets gérés par Red Hat et qui ne peuvent pas être modifiés, voir « Ressources gérées par Red Hat » dans Support.
8.5.1.1. Désactivation de l’engagement excessif pour un projet Copier lienLien copié sur presse-papiers!
En cas de besoin dans votre cas d’utilisation, vous pouvez désactiver le surengagement sur tout projet qui n’est pas géré par Red Hat. Dans la liste des projets qui ne peuvent pas être modifiés, voir "Ressources gérées par Red Hat" dans Support.
Conditions préalables
- Il est connecté au cluster à l’aide d’un compte avec des autorisations d’administrateur de cluster ou d’éditeur de clusters.
Procédure
Éditer le fichier objet namespace:
Lorsque vous utilisez la console web:
- Cliquez sur Administration → Namespaces et cliquez sur l’espace de noms du projet.
- Dans la section Annotations, cliquez sur le bouton Modifier.
- Cliquez sur Ajouter plus et entrez une nouvelle annotation qui utilise une clé de quota.openshift.io/cluster-resource-override-enabled et une valeur de faux.
- Cliquez sur Save.
En cas d’utilisation du ROSA CLI (rosa):
Éditer l’espace de noms:
rosa edit namespace/<project_name>
$ rosa edit namespace/<project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ajouter l’annotation suivante:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ≪.> paramétrer cette annotation à de faux désactives overcommit pour cet espace de noms.
Legal Notice
Copier lienLien copié sur presse-papiers!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.