Meilleures pratiques concernant les grands clusters

Meilleure pratique : Limiter la mise à l'échelle de l'éclatement à environ 10 % des pods et des noeuds d'un cluster

Nous recommandons d'ajouter ou de supprimer des noeuds et des pods dans un cluster volumineux par lots d'environ 10 % de leur nombre total.

Les actions de redimensionnement de cluster (telles que la modification du nombre de noeuds dans un pool de noeuds, la configuration du nombre de répliques dans un déploiement et la génération dynamique de travaux dans le cluster) peuvent générer une grande quantité de trafic d'API pour la coordination distribuée et la planification des ressources. La recommandation de 10 % est généralement suffisamment prudente pour éviter de rencontrer des limites de débit dans le serveur d'API Kubernetes et d'autres adresses cloud en aval, et ainsi éviter des tentatives coûteuses pendant une période de trafic élevé qui pourrait entraîner des retards dus aux retards.

La recommandation de 10 % est un point de départ et dépend de la taille du cluster et des types de charge globale qu'il contient. Les charges de travail avec de nombreux opérateurs qui communiquent tous avec l'adaptateur kube peuvent nécessiter un lissage des rafales plus important, tandis que les noeuds vides avec une charge de travail minimale peuvent éclater plus rapidement.

Reportez-vous à Remarques concernant les clusters volumineux dans la documentation Kubernetes.

Meilleure pratique : configurer FlowSchemas pour optimiser les décisions de limitation de débit en cas de charge

Nous vous recommandons de supprimer la priorité des demandes qui ne sont pas urgentes sur les clusters volumineux.

La fonctionnalité API Priority and Fairness (APF) du kube-apiserver expose certains contrôles aux demandes de limite de débit. Vous pouvez configurer la fonction APF à l'aide de niveaux de priorité, qui définissent des configurations flexibles pour la taille de la main et la taille de la file d'attente allouées à une priorité particulière. L'utilisation de niveaux de priorité permet aux charges de travail avancées d'optimiser le traitement des demandes et de garantir que les demandes hautement prioritaires sont traitées.

Un élément FlowSchema définit le niveau de priorité auquel une demande appartient. Une configuration commune, en particulier dans les clusters avec des charges globales d'éclatement qui nécessitent l'ajout ou la suppression d'un grand nombre de pods ou de noeuds, consiste à utiliser un élément FlowSchema qui réduit la priorité des demandes LIST /events au niveau de priorité catch-all. Dans Kubernetes, les appels LIST sont généralement les plus chers pour le service de kube-apiserver, et en période d'attrition élevée, le nombre d'événements peut devenir important. En installant un FlowSchema qui réduit le niveau de priorité de ces appels, vous pouvez traiter davantage de demandes critiques. Les demandes de priorité inférieure reçoivent des erreurs HTTP 429 Too Many Requests et seront retentées ultérieurement par les clients pour devenir cohérentes à terme.

Reportez-vous à Isolation des demandes non essentielles provenant d'autres flux affamés dans la documentation Kubernetes.

Vous pouvez utiliser les mesures publiées par kube-apiserver à l'adresse /metrics pour identifier le moment où la limitation se produit et quels flux peuvent être de bons candidats pour un schéma personnalisé :

• Utilisez la mesure apiserver_flowcontrol_rejected_requests_total pour voir à quel moment les demandes ne sont pas traitées et doivent faire l'objet d'une nouvelle tentative. Si la valeur est différente de zéro, la limitation s'est produite et vous pouvez prendre des mesures.
• Utilisez la mesure apiserver_flowcontrol_request_wait_duration_seconds pour voir les niveaux de priorité qui constituent un goulet d'étranglement.

Reportez-vous à Bonnes pratiques d'utilisation de la priorité et de l'équité des API dans la documentation Kubernetes.

Meilleure pratique : régler les extensions de cluster pour les adapter à la taille du cluster

Nous vous recommandons de configurer les modules complémentaires CoreDNS et flannel dans des clusters volumineux.

Les clusters améliorés dans Kubernetes Engine vous permettent de configurer les modules complémentaires installés dans un cluster (reportez-vous à Mise à jour d'une extension de cluster). Les valeurs par défaut raisonnables pour les petits clusters ne sont pas nécessairement optimales pour les grands clusters.

La configuration par défaut de CoreDNS alloue 1 réplique par noeud. Toutefois, dans les clusters volumineux, moins de répliques peuvent être plus appropriées. Par exemple, une configuration telle que {minReplica: 3, nodesPerReplica: 8} peut être plus appropriée dans un cluster de grande taille. Une configuration avec moins de répliques consomme non seulement moins de ressources de calcul au sein du cluster, mais augmente également la probabilité d'accès efficaces au cache en consolidant les demandes DNS vers moins de répliques.

Pour éviter qu'un seul noeud indisponible arrête le déploiement d'une modification apportée au flannel DaemonSet, vous pouvez configurer la stratégie de déploiement de sorte qu'elle ait une valeur maxUnavailable telle que 25%. Une telle stratégie permet le déploiement d'un changement de flanelle DaemonSet vers un cluster volumineux comportant des milliers de noeuds, même si un certain nombre de ces noeuds ne sont pas disponibles.

Pour les modules complémentaires CoreDNS et flannel, dans les clusters volumineux, il peut s'avérer nécessaire d'augmenter les demandes/limites de CPU et de mémoire allouées pour prendre en charge la charge.

Reportez-vous à la section Configuring Cluster Add-ons.

Meilleure pratique : configurer les clients Kubernetes pour qu'ils utilisent le type de contenu protobuf au lieu de JSON

Nous vous recommandons d'utiliser le type de contenu protobuf avec de grands clusters, le cas échéant.

Par défaut, les clients Kubernetes utilisent JSON comme type de contenu pour toutes les demandes. L'utilisation de JSON comme type de contenu est une option conviviale et suffisante pour la majorité des cas d'utilisation. Cependant, avec des clusters volumineux, l'utilisation de protobuf plutôt que de JSON comme type de contenu peut améliorer les performances.

Pour spécifier l'utilisation du type de contenu protobuf :

• Pour les demandes, utilisez l'en-tête Content-Type: application/vnd.kubernetes.protobuf.
• Pour les réponses, utilisez l'en-tête Accept: application/vnd.kubernetes.protobuf, application/json. En indiquant protobuf et json dans l'en-tête Accept, le serveur d'API Kubernetes peut revenir au format JSON si aucune représentation protobuf n'existe pour un objet.

Reportez-vous à Autres représentations des ressources dans la documentation Kubernetes.

Meilleure pratique : Activer la journalisation du service pour une visibilité sur les journaux de plan de contrôle Kubernetes

Nous recommandons d'activer les journaux de service pour les clusters volumineux.

Le serveur d'API Kubernetes signale de nombreux problèmes aux clients via des avertissements dans les réponses du serveur, ainsi que via des événements. Toutefois, les journaux des conteneurs de plan de contrôle Kubernetes suivants capturent également des informations supplémentaires qui peuvent vous aider à comprendre le comportement des clusters volumineux :

• kube-planificateur
• kube-contrôleur-gestionnaire
• gestionnaire de contrôleur cloud
• kube-apiserver

Pour activer et visualiser ces journaux de plan de contrôle Kubernetes en tant que journaux de service dans Oracle Cloud Infrastructure Logging, suivez les instructions fournies dans Visualisation des journaux de service Kubernetes Engine (OKE).

Meilleure pratique : Allouer des blocs CIDR réseau avec des adresses IP suffisantes pour le nombre attendu de pods

Nous vous recommandons d'examiner à l'avance la taille du bloc CIDR de réseau à spécifier pour un cluster volumineux et le module d'extension CNI à sélectionner.

Les modifications de sous-réseau dans un cluster en cours d'exécution peuvent entraîner des interruptions. Dans le cas des blocs CIDR de pod, vous ne pouvez pas modifier le bloc CIDR de pod que vous indiquez initialement pour un cluster après la création du cluster. Par conséquent, avant de créer un cluster volumineux, afin d'éviter les complications réseau au fur et à mesure de l'évolution d'un cluster, tenez compte du plug-in CNI le plus approprié à sélectionner et de la taille de bloc CIDR la plus appropriée à spécifier.

Le module d'extension CNI flannel permet d'allouer de grands sous-réseaux privés pour une utilisation. Nous recommandons un bloc CIDR /12 pour le bloc CIDR de pod. En raison de la nature des VXLAN, le plugin flannel CNI peut allouer / désallouer des pods rapidement, avec le compromis que le trafic de pod est maintenant dans l'encapsulation VXLAN. Lorsque vous choisissez la taille d'un bloc CIDR de pod, tenez compte du fait que le moteur Kubernetes alloue un bloc CIDR /25 à chaque noeud. La taille du bloc CIDR de pod que vous indiquez peut limiter le nombre de noeuds disponibles pour un cluster (par exemple, si vous indiquez un bloc CIDR /24 en tant que bloc CIDR de pod, le cluster ne peut avoir que 8 noeuds). Selon le ratio pod-noeud attendu, un nombre important d'adresses IP peut être alloué à chaque noeud qui sera inutilisé et non disponible pour les autres noeuds. Dans ce cas, indiquez un bloc CIDR de pod plus volumineux (reportez-vous à Blocs IPv4 CIDR et moteur Kubernetes (OKE)).

Le plug-in CNI Native Pod Networking s'intègre directement au réseau VCN à l'aide d'attachements VNIC dédiés. Cette approche supprime les limites liées aux allocations IP par noeud et élimine la nécessité d'une couche réseau superposée VXLAN supplémentaire dans le cluster. Cependant, les sous-réseaux VCN sont limités à un bloc CIDR /16, qui est un espace d'adressage plus petit que celui pouvant être pris en charge avec flannel (reportez-vous à Taille et plages d'adresses VCN autorisées). Notez que le nombre de cartes d'interface réseau virtuelles pouvant être attachées à un noeud est limité par la taille du noeud. Tenez compte de la sélection de forme pour chaque noeud lors de l'évaluation du nombre d'adresses IP de pod nécessaires (reportez-vous à Formes de calcul).

Le sous-réseau de l'adresse d'API Kubernetes n'a généralement besoin que d'un petit bloc CIDR car une seule adresse IP d'adresse est requise pour chaque cluster qui partage le sous-réseau. Par exemple, la spécification d'un bloc CIDR /29 pour le sous-réseau d'adresse d'API Kubernetes permet à 6 clusters de partager le sous-réseau, tandis qu'un bloc CIDR /28 permet à 14 clusters de partager le sous-réseau.

Meilleure pratique : Demander de manière préventive des augmentations de limite de service

Nous vous recommandons de passer en revue les limites de service configurées pour votre location et de soumettre des demandes à l'avance pour augmenter les limites de service que les clusters volumineux devraient atteindre. Reportez-vous à Limites par service.

Les clusters volumineux atteignent généralement les limites suivantes :

• Nombre et taille des référentiels d'images de conteneur.
• Nombre de noeuds autorisés pour un seul cluster.
• Nombre de gigaoctets de volumes de blocs pouvant être alloués.

Afin d'éviter toute interruption, nous vous recommandons donc de soumettre des demandes pour augmenter les limites de service à l'avance, en particulier pour les limites sur les volumes de blocs utilisés en tant que volumes d'initialisation pour les noeuds.

Reportez-vous à Demande d'augmentation de limite de service

Meilleure pratique : Tirer parti du redimensionnement automatique pour gérer les ressources de calcul proportionnellement aux charges de travail

Nous recommandons d'utiliser des redimensionneurs automatiques (tels que l'outil de redimensionnement automatique de cluster Kubernetes (CA), l'outil de redimensionnement automatique de pod horizontal (HPA) et l'outil de redimensionnement automatique de pod vertical (VPA)) avec des clusters volumineux afin d'optimiser l'utilisation des ressources.

L'utilisation d'un redimensionneur automatique vous permet de configurer des règles qui définissent le moment où provisionner plus de noeuds, créer plus de répliques ou réduire un cluster pendant une période calme.

La mise à l'échelle automatique basée sur des règles est un moyen efficace de gérer des clusters volumineux avec des milliers de noeuds et de pods.

Reportez-vous à la section Autoscaler Best Practices.

Meilleure pratique : Utiliser des règles sans conservation de statut pour les listes de sécurité et les groupes de sécurité réseau afin de réduire la surcharge liée au suivi des connexions

Nous vous recommandons d'utiliser des règles sans conservation de statut lors de la configuration des listes de sécurité et des groupes de sécurité réseau pour les clusters de grande taille.

Les tutoriels et la documentation précisent souvent que vous devez créer des listes de sécurité et des groupes de sécurité réseau avec des règles avec conservation de statut. Les règles avec conservation de statut exploitent le suivi de connexion pour garantir que le chemin de retour d'une demande est automatiquement autorisé, quelle que soit la présence d'une règle sortante (reportez-vous à Suivi de connexion). Bien que l'autorisation automatique des chemins de retour soit destinée à simplifier la configuration des règles, ces chemins de retour autorisés automatiquement constituent une surcharge potentielle qui peut devenir un problème pour les clusters de grande taille. Le nombre de connexions pouvant faire l'objet d'un suivi est proportionnel à la forme de l'instance utilisée, mais la simple sélection d'une forme plus grande ne résout pas nécessairement le problème.

Pour éliminer la surcharge du suivi des connexions et éviter les limites de mise à l'échelle potentielles, nous recommandons donc que pour chaque chemin réseau :

1. vous définissez une règle entrante et une règle sortante correspondante en tant que paire.
2. vous indiquez les règles entrantes et sortantes comme "sans conservation de statut".

Reportez-vous à Règles avec conservation de statut et sans conservation de statut.