Meilleures pratiques pour la gestion des grappes

Meilleures pratiques : Utiliser des étiquettes Kubernetes

Nous vous recommandons d'utiliser des étiquettes Kubernetes pour organiser les nombreuses ressources Kubernetes (telles que les services, les pods, les conteneurs, les réseaux) qui composent une grappe.

Les étiquettes Kubernetes sont des paires clé-valeur qui vous aident à tenir à jour ces ressources et à suivre la façon dont elles interagissent les unes avec les autres dans une grappe.

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

Voir Étiquettes, annotations et teintes bien connues dans la documentation sur Kubernetes.

Meilleures pratiques : Utiliser le marquage des ressources OCI

Nous vous recommandons d'utiliser le marquage des ressources OCI pour organiser les nombreuses ressources (telles que les noeuds de travail, les réseaux en nuage virtuels, les équilibreurs de charge et les volumes par blocs) utilisées par les grappes Kubernetes que vous créez avec le moteur Kubernetes. Lorsqu'un grand nombre de ressources sont réparties entre plusieurs compartiments dans une location, il peut s'avérer difficile d'effectuer le suivi des ressources utilisées à des fins spécifiques. De même, il peut être difficile d'agréger les ressources, d'en produire des rapports et d'effectuer des actions en masse.

Le marquage vous permet de définir des clés et des valeurs, et de les associer aux ressources. Vous pouvez ensuite utiliser les marqueurs pour organiser et répertorier les ressources en fonction des besoins de votre entreprise.

Voir Marquage des ressources de grappe de Kubernetes.

Meilleures pratiques : Définir des demandes et des limites de ressources

Nous vous recommandons de définir :

• 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'une grappe Kubernetes, un défi commun est la défaillance occasionnelle d'une application à déployer sur une grappe en raison de la disponibilité limitée des ressources sur cette grappe. L'échec est causé par des demandes de ressources et des limites de ressources qui n'ont pas été définies.

Si vous ne définissez pas de demandes et de limites de ressources, les pods d'une grappe peuvent commencer à utiliser plus de ressources que nécessaire. Si un pod commence à consommer plus d'UC ou de mémoire sur un noeud, il se peut que le kube-scheduler ne puisse pas placer de nouveaux pods sur le noeud et que le noeud lui-même tombe en panne.

Voir Demandes et limites dans la documentation sur Kubernetes.

Meilleures pratiques : 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 les modifications de réservation aux grappes de production, testez et testez toujours l'incidence des modifications de réservation dans un environnement hors production.
• Utilisez les indicateurs de kubelet --eviction-hard ou --eviction-soft pour définir des seuils appropriés pour la pression sur la mémoire et 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, voir Éviction de pression de noeud dans la documentation de 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 qui présentent un risque d'instabilité du système. Utilisez les mesures des outils de surveillance et d'alerte pour observer l'utilisation des ressources par Kubernetes et les composants du système au fil du temps.
• Lors de la réservation des ressources, tenez compte des différences de forme de noeud et de type de charge de travail. Les noeuds volumineux peuvent nécessiter des réservations absolues plus importantes que les noeuds plus petits. Les charges de travail ayant des besoins spécifiques en ressources ou des modèles de séparation connus peuvent nécessiter des réservations de ressources plus ou moins importantes.

Pour plus d'informations sur la réservation de ressources, voir Réserver des ressources de calcul pour les démons de système dans la documentation sur Kubernetes.

Meilleures pratiques : Fournir des noeuds dédiés à l'aide de peintures et de tolérances

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

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

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

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

Après avoir ajouté une teinte aux noeuds de travail bien spécifiés, ajoutez une tolérance correspondante aux pods que vous souhaitez autoriser à utiliser.

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

Voir Taintes et tolérance dans la documentation sur Kubernetes.

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

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 tous des sélecteurs d'étiquettes 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 contrôler le noeud sur lequel un pod s'exécute.

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

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

Par exemple, vous pouvez donner aux noeuds une étiquette indiquant qu'ils ont un stockage SSD attaché localement. Pour spécifier qu'un pod doit s'exécuter uniquement sur les noeuds avec un stockage SSD attaché localement, vous incluez ensuite cette étiquette en tant que sélecteur de noeud dans la spécification du pod. Kubernetes programme uniquement les pods sur les noeuds avec des étiquettes correspondantes.

Voir Affectation de pods à des noeuds dans la documentation sur Kubernetes.

Meilleures pratiques : Utiliser le service de récupération après sinistre de pile complète OCI 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 de pile complète pour OCI avec Kubernetes Engine pour la sauvegarde et la récupération après sinistre. Full Stack Disaster Recovery est un service en nuage natif d'orchestration et de gestion de la récupération après sinistre qui fournit des fonctions complètes de récupération après sinistre pour toutes les couches d'une pile d'applications, notamment l'infrastructure, l'intergiciel, la base de données et les applications.

Lorsque vous utilisez la récupération après sinistre de pile complète, vous pouvez ajouter des grappes Kubernetes que vous avez créées avec le moteur Kubernetes aux groupes de protection pour la récupération après sinistre, ce qui vous permet d'automatiser l'orchestration de la récupération de bout en bout de votre système Kubernetes entre les régions OCI.

Pour plus d'informations, consultez la documentation complète sur le service de récupération après sinistre de pile, et les sections suivantes en particulier :

• Préparation du moteur Kubernetes pour la récupération après sinistre
• Ajouter une grappe OKE à un groupe de protection pour récupération après sinistre
• le tutoriel Automatiser les plans de permutation et de basculement pour le moteur Kubernetes OCI (état) avec la récupération après sinistre de pile complète OCI

Notez qu'avant le lancement de la récupération après sinistre de pile complète, nous avons 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 de récupération après sinistre tiers est déjà en place, vous pouvez continuer à l'utiliser. Toutefois, nous vous recommandons de considérer les avantages de la récupération après sinistre de pile complète pour OCI comme une alternative aux outils de tierce partie.