Services de cluster

Les services de cluster s'exécutent au sein d'un cluster EKS, mais ils ne constituent pas des charges de travail utilisateur. Si vous avez un serveur Linux, vous devez souvent exécuter des services tels que NTP, Syslog et un environnement d'exécution de conteneur pour prendre en charge vos charges de travail. Les services de cluster sont similaires et prennent en charge des services qui vous aident à automatiser et à exploiter votre cluster. Dans Kubernetes, ils sont généralement exécutés dans l'espace de noms du système kube et certains sont exécutés en tant que. DaemonSets

Les services de cluster sont censés avoir un temps de disponibilité élevé et sont souvent essentiels en cas de panne et pour le dépannage. Si un service de cluster principal n'est pas disponible, vous risquez de perdre l'accès aux données qui peuvent aider à récupérer ou à prévenir une panne (par exemple, utilisation élevée du disque). Ils doivent s'exécuter sur des instances de calcul dédiées, telles qu'un groupe de nœuds distinct ou AWS Fargate. Cela garantira que les services du cluster ne sont pas affectés sur les instances partagées par des charges de travail susceptibles d'augmenter ou d'utiliser davantage de ressources.

CoreDNS à l'échelle

La mise à l'échelle de CoreDNS repose sur deux mécanismes principaux. Réduction du nombre d'appels au service CoreDNS et augmentation du nombre de répliques.

Réduisez les requêtes externes en diminuant le nombre de points

Le paramètre ndots indique le nombre de points (également appelés « points ») d'un nom de domaine considérés comme suffisants pour éviter d'interroger le DNS. Si votre application possède un paramètre ndots de 5 (par défaut) et que vous demandez des ressources à un domaine externe tel que api.example.com (2 points), CoreDNS sera interrogé pour chaque domaine de recherche défini dans /etc/resolv.conf pour un domaine plus spécifique. Par défaut, les domaines suivants seront recherchés avant de faire une demande externe.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

Les region valeurs namespace et seront remplacées par l'espace de noms de vos charges de travail et votre région de calcul. Il se peut que vous disposiez de domaines de recherche supplémentaires en fonction des paramètres de votre cluster.

Vous pouvez réduire le nombre de requêtes adressées à CoreDNS en diminuant l'option ndots de votre charge de travail ou en qualifiant complètement vos demandes de domaine en incluant un suivi. (par exempleapi.example.com.). Si votre charge de travail se connecte à des services externes via le DNS, nous vous recommandons de définir ndots sur 2 afin que les charges de travail ne rendent pas inutiles les requêtes DNS du cluster au sein du cluster. Vous pouvez définir un serveur DNS et un domaine de recherche différents si la charge de travail ne nécessite pas l'accès aux services du cluster.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

Si vous réduisez ndots à une valeur trop faible ou si les domaines auxquels vous vous connectez ne sont pas suffisamment spécifiques (y compris les derniers points), il est possible que les recherches DNS échouent. Assurez-vous de tester l'impact de ce paramètre sur vos charges de travail.

Mettre à l'échelle CoreDNS horizontalement

Les instances CoreDNS peuvent évoluer en ajoutant des répliques supplémentaires au déploiement. Il est recommandé d'utiliser le NodeLocal DNS ou l'autoscaler proportionnel au cluster pour dimensionner CoreDNS.

NodeLocal Le DNS nécessitera l'exécution d'une instance par nœud, en tant que nœud, DaemonSet ce qui nécessite davantage de ressources de calcul dans le cluster, mais cela évitera l'échec des requêtes DNS et réduira le temps de réponse des requêtes DNS dans le cluster. L'autoscaler proportionnel du cluster adaptera CoreDNS en fonction du nombre de nœuds ou de cœurs du cluster. Il ne s'agit pas d'une corrélation directe avec les requêtes, mais cela peut être utile en fonction de vos charges de travail et de la taille de votre cluster. L'échelle proportionnelle par défaut consiste à ajouter une réplique supplémentaire pour 256 cœurs ou 16 nœuds du cluster, selon la première éventualité.

Faites dimensionner le serveur de métriques Kubernetes à la verticale

Le serveur Kubernetes Metrics prend en charge la mise à l'échelle horizontale et verticale. En dimensionnant horizontalement le serveur de métriques, il sera hautement disponible, mais il ne sera pas redimensionné horizontalement pour gérer un plus grand nombre de métriques de clusters. Vous devrez dimensionner verticalement le serveur de métriques en fonction de ses recommandations au fur et à mesure que les nœuds et les métriques collectées sont ajoutés au cluster.

Le serveur de métriques conserve en mémoire les données qu'il collecte, agrège et sert. À mesure qu'un cluster s'agrandit, la quantité de données que le serveur de métriques stocke augmente. Dans les grands clusters, le serveur Metrics aura besoin de plus de ressources de calcul que la quantité de mémoire et de CPU réservée dans l'installation par défaut. Vous pouvez utiliser le Vertical Pod Autoscaler (VPA) ou Addon Resizer pour redimensionner le serveur de métriques. L'Addon Resizer évolue verticalement proportionnellement aux nœuds de travail et le VPA évolue en fonction de l'utilisation du processeur et de la mémoire.

Durée du lameduck CoreDNS

Les pods utilisent le kube-dns service pour la résolution des noms. Kubernetes utilise le NAT de destination (DNAT) pour rediriger le kube-dns trafic des nœuds vers les pods principaux CoreDNS. Au fur et à mesure que vous adaptez le déploiement CoreDNSkube-proxy, les règles iptables et les chaînes sont mises à jour sur les nœuds afin de rediriger le trafic DNS vers les pods CoreDNS. La propagation de nouveaux points de terminaison lorsque vous augmentez et la suppression de règles lorsque vous réduisez CoreDNS peuvent prendre entre 1 et 10 secondes selon la taille du cluster.

Ce délai de propagation peut entraîner des échecs de recherche DNS lorsqu'un pod CoreDNS est arrêté alors que les règles iptables du nœud n'ont pas été mises à jour. Dans ce scénario, le nœud peut continuer à envoyer des requêtes DNS à un pod CoreDNS arrêté.

Vous pouvez réduire les échecs de recherche DNS en définissant une durée de lameduck dans vos pods CoreDNS. En mode lameduck, CoreDNS continuera de répondre aux demandes en vol. La définition d'une durée de lameduck retardera le processus d'arrêt de CoreDNS, laissant aux nœuds le temps dont ils ont besoin pour mettre à jour leurs règles et chaînes iptables.

Nous vous recommandons de définir la durée de CoreDNS lameduck sur 30 secondes.

Sonde de préparation CoreDNS

Nous vous recommandons d'utiliser /ready plutôt que /health pour la sonde de préparation de CoreDNS.

Conformément à la recommandation précédente de fixer la durée du lameduck à 30 secondes, afin de laisser suffisamment de temps pour que les règles iptables du nœud soient mises à jour avant la fin du pod, l'utilisation /ready plutôt que de /health la sonde de préparation CoreDNS garantit que le pod CoreDNS est parfaitement préparé au démarrage pour répondre rapidement aux requêtes DNS.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

Pour plus d'informations sur le plugin CoreDNS Ready, veuillez consulter https://coredns. io/plugins/ready/

Agents de journalisation et de surveillance

Les agents de journalisation et de surveillance peuvent alourdir considérablement le plan de contrôle de votre cluster, car ils interrogent le serveur d'API pour enrichir les journaux et les métriques avec des métadonnées de charge de travail. L'agent d'un nœud n'a accès qu'aux ressources du nœud local pour voir des informations telles que le conteneur et le nom du processus. En interrogeant le serveur d'API, il peut ajouter des détails supplémentaires tels que le nom et les étiquettes du déploiement de Kubernetes. Cela peut être extrêmement utile pour le dépannage, mais cela nuit à la mise à l'échelle.

Comme il existe de nombreuses options différentes pour la journalisation et la surveillance, nous ne pouvons pas donner d'exemples pour chaque fournisseur. Avec fluentbit, nous recommandons d'activer Use_Kubelet pour récupérer les métadonnées du kubelet local plutôt que du serveur d'API Kubernetes et de définir un nombre qui réduit les appels répétés lorsque les données peuvent Kube_Meta_Cache_TTL être mises en cache (par exemple 60).

Le dimensionnement de la surveillance et de la journalisation comporte deux options générales :

• Désactiver les intégrations

• Échantillonnage et filtrage

La désactivation des intégrations n'est souvent pas une option car vous perdez les métadonnées des journaux. Cela élimine le problème de dimensionnement de l'API, mais cela introduira d'autres problèmes en ne disposant pas des métadonnées requises en cas de besoin.

L'échantillonnage et le filtrage réduisent le nombre de mesures et de journaux collectés. Cela réduira le nombre de requêtes adressées à l'API Kubernetes, ainsi que la quantité de stockage nécessaire pour les métriques et les journaux collectés. La réduction des coûts de stockage réduira le coût de l'ensemble du système.

La possibilité de configurer l'échantillonnage dépend du logiciel de l'agent et peut être mise en œuvre à différents points d'ingestion. Il est important d'ajouter un échantillonnage le plus près possible de l'agent, car c'est probablement là que les appels du serveur d'API ont lieu. Contactez votre fournisseur pour en savoir plus sur l'assistance en matière d'échantillonnage.

Si vous utilisez CloudWatch and CloudWatch Logs, vous pouvez ajouter un filtrage par agent à l'aide des modèles décrits dans la documentation.

Pour éviter de perdre des journaux et des métriques, vous devez envoyer vos données vers un système capable de les mettre en mémoire tampon en cas de panne du terminal récepteur. Avec Fluentbit, vous pouvez utiliser Amazon Kinesis Data Firehose pour conserver temporairement des données, ce qui peut réduire le risque de surcharge de votre emplacement de stockage final.