Meilleures pratiques concernant la gestion de cluster

Meilleure pratique : utiliser les libellés Kubernetes

Nous vous recommandons d'utiliser des libellés Kubernetes pour organiser les nombreuses ressources Kubernetes (telles que les services, les pods, les conteneurs et les réseaux) qui constituent un cluster.

Les libellés Kubernetes sont des paires clé-valeur qui vous aident à gérer ces ressources et à suivre leur interaction dans un cluster.

Par exemple, vous pouvez utiliser oci.oraclecloud.com/oke-is-preemptible=true label (que Kubernetes Engine applique aux noeuds de processus actif hébergés sur des instances préemptives) avec des sélecteurs de noeud Kubernetes et une affinité/anti-affinité de noeud pour contrôler les pods programmés sur ces noeuds de processus actif.

Reportez-vous à Libellés, annotations et peintures bien connus dans la documentation Kubernetes.

Meilleure pratique : utiliser le balisage des ressources OCI

Nous vous recommandons d'utiliser le balisage de ressources OCI pour organiser les nombreuses ressources (telles que les noeuds de processus actif, les réseaux cloud virtuels, les équilibreurs de charge et les volumes de blocs) utilisées par les clusters Kubernetes que vous créez avec Kubernetes Engine. Lorsqu'un grand nombre de ressources est réparti dans plusieurs compartiments d'une location, il est difficile de suivre les ressources utilisées à des fins spécifiques. De même, il est difficile d'agréger les ressources, de générer des rapports sur celles-ci et de prendre des mesures globales à leur égard.

Le balisage permet de définir des clés et des valeurs, et de les associer à des ressources. Vous pouvez ensuite utiliser les balises pour organiser et répertorier les ressources en fonction de vos besoins métier.

Reportez-vous à Balisage des ressources liées à un cluster Kubernetes.

Meilleure pratique : Définir les demandes et les limites des ressources

Il est recommandé de définir les éléments suivants :

• demandes de ressources, pour spécifier la quantité minimale de ressources qu'un conteneur peut utiliser
• limites de ressources, pour spécifier la quantité maximale de ressources qu'un conteneur peut utiliser

Lors de l'utilisation d'un cluster Kubernetes, un défi courant est l'échec occasionnel du déploiement d'une application sur un cluster en raison de la disponibilité limitée des ressources sur ce cluster. L'échec est dû à des demandes de ressources et à des limites de ressources qui n'ont pas été définies.

Si vous ne définissez ni demandes ni limites de ressources, les pods d'un cluster peuvent commencer à utiliser plus de ressources que nécessaire. Si un pod commence à consommer plus de CPU ou de mémoire sur un noeud, le kube-scheduler peut ne pas être en mesure de placer de nouveaux pods sur le noeud, et le noeud lui-même peut même planter.

Reportez-vous à Demandes et limites dans la documentation Kubernetes.

Meilleure pratique : réserver des ressources pour les démons système Kubernetes et OS

kubectl get node <NODE_NAME> -o=yaml | grep -A 6 -B 7 capacity

  allocatable:
    cpu: 15743m
    ephemeral-storage: "34262890849"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 234972476Ki
    pods: "110"
  capacity:
    cpu: "16"
    ephemeral-storage: 37177616Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 257197372Ki
    pods: "110"

Recommandations supplémentaires :

• Avant d'appliquer des modifications de réservation aux clusters de production, testez et comparez toujours l'impact des modifications de réservation dans un environnement autre que de production.
• Utilisez les indicateurs de kubelet --eviction-hard ou --eviction-soft pour définir les seuils appropriés pour la mémoire et la pression sur le disque. Lorsque vous définissez ces seuils, le système Kubernetes peut protéger la stabilité du système en évitant les pods moins importants si nécessaire. Pour plus d'informations, reportez-vous à Emission sous pression de noeud dans la documentation Kubernetes.
• Sachez que la réservation d'un trop grand nombre de ressources peut entraîner une sous-utilisation des noeuds. Votre objectif est de trouver un équilibre approprié entre la garantie de la disponibilité des ressources pour les composants critiques et l'optimisation de la disponibilité des ressources pour les charges de travail. Nous vous recommandons de commencer par des réservations de ressources plus importantes et de réduire progressivement la taille des réservations en fonction de l'observation, plutôt que de commencer par des réservations de ressources plus petites qui sont trop faibles et risquent d'être instables. Utilisez les mesures des outils de surveillance et d'alerte pour observer l'utilisation des ressources par Kubernetes et les composants système au fil du temps.
• Lors de la réservation de ressources, tenez compte des différences de forme de noeud et de type de charge globale. Les noeuds volumineux peuvent nécessiter des réservations absolues plus importantes que les noeuds plus petits. Les charges globales avec des besoins spécifiques en ressources ou des modèles d'éclatement connus peuvent nécessiter des réservations de ressources plus ou moins importantes.

Pour plus d'informations sur la réservation de ressources, reportez-vous à Réservation de ressources de calcul pour les démons système dans la documentation Kubernetes.

Meilleure pratique : fournir des noeuds dédiés à l'aide de peintures et de tolérances

Nous vous recommandons d'utiliser des taches et des tolérances Kubernetes pour limiter les applications gourmandes en ressources à des noeuds de processus actif spécifiques.

L'utilisation de peintures et de tolérances vous permet de maintenir les ressources de noeud disponibles pour les charges globales qui en ont besoin et empêche la planification d'autres charges globales sur les noeuds.

Par exemple, lorsque vous créez un cluster à l'aide de Kubernetes Engine, vous pouvez définir des noeuds de processus actif avec une forme de GPU ou une forme avec un grand nombre d'UC puissantes. Ces noeuds de processus actif bien spécifiés sont idéaux pour les charges globales de traitement de données volumineuses. Toutefois, ce matériel spécialisé est généralement coûteux à déployer. Par conséquent, vous souhaiterez généralement limiter les charges globales pouvant être planifiées sur ces noeuds. Pour limiter les charges globales pouvant être programmées sur les noeuds de processus actif bien spécifiés, ajoutez une tache aux noeuds. Par exemple, exécutez l'une des commandes suivantes :

• kubectl taint nodes <node-name> special=true:NoSchedule
• kubectl taint nodes <node-name> special=true:PreferNoSchedule

Une fois que vous avez ajouté une tâche aux noeuds de processus actif spécifiés, ajoutez une tolérance correspondante aux pods que vous voulez autoriser à utiliser les noeuds.

De même, vous pouvez utiliser oci.oraclecloud.com/oke-is-preemptible=true label (qui Kubernetes Engine s'applique aux noeuds de processus actif hébergés sur des instances préemptives) avec des tolérances Kubernetes pour contrôler les pods programmés sur ces noeuds de processus actif.

Reportez-vous à Taints and Tolerations dans la documentation Kubernetes.

Meilleure pratique : Contrôler la planification des pods à l'aide de sélecteurs de noeud et d'affinités

Il existe plusieurs façons de contraindre un pod à s'exécuter sur des noeuds particuliers ou de spécifier une préférence pour qu'un pod s'exécute sur des noeuds particuliers. Les approches recommandées utilisent toutes des sélecteurs d'étiquette pour faciliter la sélection. Souvent, le kube-scheduler effectuera automatiquement un placement raisonnable sans ces contraintes ou préférences. Toutefois, dans certains cas, vous pouvez vouloir contrôler le noeud sur lequel un pod est exécuté.

Dans ces cas, nous vous recommandons de contrôler la programmation des pods sur les noeuds à l'aide des sélecteurs de noeud Kubernetes, de l'affinité de noeud et de l'affinité inter-pod.

L'utilisation de sélecteurs de noeud, d'affinité de noeud et d'affinité inter-pod permet au planificateur de kube d'isoler logiquement les charges de travail, par exemple par le matériel du noeud.

Par exemple, vous pouvez attribuer une étiquette aux noeuds pour indiquer qu'ils disposent d'un stockage SSD connecté localement. Pour indiquer qu'un pod doit être exécuté uniquement sur des noeuds disposant d'un stockage SSD connecté localement, vous devez inclure ce libellé en tant que sélecteur de noeud dans la spécification du pod. Kubernetes planifie uniquement les pods sur les noeuds avec des libellés correspondants.

Reportez-vous à Affectation de pods aux noeuds dans la documentation Kubernetes.

Meilleure pratique : Utiliser le service OCI Full Stack Disaster Recovery pour la sauvegarde et la récupération après sinistre

Nous vous recommandons d'utiliser le service de récupération après sinistre OCI Full Stack avec Kubernetes Engine pour la sauvegarde et la récupération après sinistre. Full Stack Disaster Recovery est un service cloud natif d'orchestration et de gestion de la récupération après sinistre qui fournit des fonctionnalités complètes pour toutes les couches d'une pile d'applications, y compris l'infrastructure, le middleware, la base de données et les applications.

Lorsque vous utilisez Full Stack Disaster Recovery, vous pouvez ajouter des clusters Kubernetes que vous avez créés avec Kubernetes Engine aux groupes de protection de récupération après sinistre, ce qui vous permet d'automatiser l'orchestration de récupération de bout en bout de votre système Kubernetes entre les régions OCI.

Pour plus d'informations, reportez-vous à la documentation Full Stack Disaster Recovery, et aux sections suivantes en particulier :

• Préparation du moteur Kubernetes (OKE) pour la récupération après sinistre
• Ajout d'un cluster OKE à un groupe de protection de récupération après sinistre
• le tutoriel Automatiser les plans de permutation et de basculement pour OCI Kubernetes Engine (avec conservation de statut) avec OCI Full Stack Disaster Recovery

Avant la publication de Full Stack Disaster Recovery, nous avions précédemment recommandé l'utilisation d'outils tiers (tels que Kasten, Rancher, Trilio ou Velero) avec Kubernetes Engine pour la sauvegarde et la récupération après sinistre. Si un outil tiers de récupération après sinistre est déjà en place, vous pouvez continuer à l'utiliser. Cependant, nous vous recommandons de considérer les avantages d'OCI Full Stack Disaster Recovery comme une alternative aux outils tiers.