Introduction  

Avec plus de 40 000 étoiles sur Github, plus de 70 000 commits et des contributeurs majeurs tels que Google et Redhat, Kubernetes a rapidement pris en main l'écosystème des conteneurs pour devenir le véritable leader des plates-formes d'orchestration de conteneurs.  

Comprendre Kubernetes et ses abstractions  

Au niveau de l'infrastructure, un cluster Kubernetes est un ensemble de machines physiques ou virtuelles jouant un rôle spécifique. Les machines jouant le rôle de maître agissent comme le cerveau de toutes les opérations et sont chargées d'orchestrer les conteneurs qui fonctionnent sur tous les nœuds.  Les composants maîtres gèrent le cycle de vie d'un pod, l'unité de base du déploiement dans un cluster Kubernetes. Si un pod meurt, le contrôleur en crée un nouveau. Si vous augmentez ou réduisez le nombre de réplicas de pods, le contrôleur crée ou détruit des pods pour répondre à votre demande.

Le rôle principal inclut les composants suivants:  

  • kube-apiserver - expose les API pour les autres composants maîtres.
  • etcd - un magasin de clés / valeurs cohérent et hautement disponible utilisé pour stocker toutes les données internes du cluster.
  • kube-scheduler - utilise les informations de la spécification du pod pour décider du nœud sur lequel exécuter un pod.
  • kube-controller-manager - responsable de la gestion des noeuds (détection en cas de défaillance d'un noeud), de la réplication du pod et de la création de noeuds finaux.
  • cloud-controller-manager - exécute des contrôleurs qui interagissent avec les fournisseurs de cloud sous-jacents.

Les composants de nœud sont des ordinateurs de travail dans Kubernetes et sont gérés par le maître. Un nœud peut être une machine virtuelle (machine virtuelle) ou une machine physique. Kubernetes fonctionne aussi bien sur les deux types de systèmes. Chaque nœud contient les composants nécessaires à l'exécution des pods:

  • kubelet: gère toutes les communications entre le maître et le nœud sur lequel il s'exécute. Il s'interface avec le moteur d'exécution du conteneur pour déployer et surveiller les conteneurs.
  • kube-proxy: maintient les règles du réseau sur l'hôte et gère la transmission des paquets entre les pods, l'hôte et le monde extérieur.
  • conteneur d'exécution: responsable de l'exécution des conteneurs sur l'hôte. Le moteur le plus populaire est Docker, bien que Kubernetes prenne en charge les exécutions de conteneur de rkt, runc et autres.
illustration en image

D'un point de vue logique, un déploiement Kubernetes est composé de divers composants, chacun servant un objectif spécifique au sein du cluster.  

  • Les pods constituent l'unité de base du déploiement au sein de Kubernetes. Un module consiste en un ou plusieurs conteneurs qui partagent le même espace de nom de réseau et la même adresse IP. Les meilleures pratiques recommandent de créer un module par composant d'application afin de pouvoir les mettre à l'échelle et les contrôler séparément.
  • Les services fournissent une adresse IP cohérente devant un ensemble de pods et une stratégie qui en contrôle l'accès. L'ensemble de pods ciblés par un service est souvent déterminé par un sélecteur d'étiquettes. Cela facilite le fait de diriger le service vers un autre ensemble de pods lors de mises à niveau ou de déploiements blue/green.
  • Les ReplicaSets sont contrôlés par les déploiements et garantissent que le nombre souhaité de pods pour ce déploiement est en cours d'exécution.
  • Les namespaces définissent un espace de noms logique pour des ressources telles que des pods et des services. Ils permettent aux ressources d'utiliser les mêmes noms, alors que les ressources d'un seul espace de noms doivent avoir des noms uniques. Rancher utilise des espaces de noms avec son contrôle d'accès basé sur les rôles pour fournir une séparation sécurisée entre les espaces de noms et les ressources qui y sont exécutées.
  • Les métadata marks sont des conteneurs basés sur des caractéristiques de déploiement.

Monitoring de Kubernetes  

Plusieurs services et namespaces peuvent être répartis sur l’infrastructure. Comme on le voit ci-dessus, chacun des services est constitué de pods pouvant contenir un ou plusieurs conteneurs. Avec autant de pièces mobiles, surveiller même un petit cluster Kubernetes peut présenter un défi. Cela nécessite une compréhension approfondie de l'architecture et des fonctionnalités de l'application afin de la surveiller efficacement.  Kubernetes est livré avec des outils de surveillance du cluster:

  • Les probes surveillent activement la santé d'un conteneur. Si le probe détermine qu'un conteneur n'est plus en bon état, elle le redémarrera.
  • cAdvisor est un agent open source qui surveille l'utilisation des ressources et analyse les performances des conteneurs. Créé à l'origine par Google, cAdvisor est maintenant intégré à Kubelet. Il collecte, regroupe, traite et exporte des métriques telles que l'utilisation du processeur, de la mémoire, des fichiers et du réseau pour tous les conteneurs exécutés sur un nœud donné.
  • Le dashboard kubernetes est un complément qui donne une vue d'ensemble des ressources en cours d'exécution sur votre cluster. Il fournit également un moyen très simple de déployer et d’interagir avec ces ressources.

Kubernetes a une capacité extraordinaire de récupération automatique après une panne. Il peut redémarrer les pods si un processus se bloque et redistribuer les pods si un nœud échoue. Cependant, malgré toute sa puissance, il est parfois impossible de résoudre un problème. Afin de détecter ces situations, nous avons besoin d’une surveillance supplémentaire.  

Couches de surveillance  

Infrastructure

Tous les clusters doivent avoir une surveillance des composants du serveur sous-jacents, car des problèmes au niveau du serveur apparaîtront dans les charges de travail.

Que surveiller?  

  • Utilisation du processeur. Surveiller le processeur révélera la consommation du système et de l'utilisateur, ainsi que iowait. Lorsque vous exécutez des clusters dans le cloud ou avec un stockage réseau, iowait indique les goulots d'étranglement en attente de lectures et d'écritures de stockage (processus d'E/S). Une infrastructure de stockage surabondée peut avoir un impact sur les performances.
  • Utilisation de la mémoire. La surveillance de la mémoire indique la quantité de mémoire utilisée et disponible, sous forme de mémoire libre ou de cache. Les systèmes qui se heurtent à des limites de mémoire commenceront à échanger (si l'échange est disponible sur le système) et cet échange dégradera rapidement les performances.
  • Pression du disque. Si un système exécute des services d'écriture intensive tels qu'etcd ou un magasin de données, le manque d'espace disque peut être catastrophique. L'incapacité d'écrire des données entraînera la corruption, et cette corruption peut se traduire par des pertes réelles. Les technologies telles que LVM rendent l’accroissement de l’espace disque nécessaire, mais il est impératif de le surveiller.
  • Bande passante du réseau. À l’ère des interfaces gigabits, il peut sembler qu’on ne peut jamais manquer de bande passante. Toutefois, il suffit de quelques services aberrants, d’une violation de données, d’une compromission du système ou d’une attaque du DOS pour absorber toute la bande passante et provoquer une panne. Garder conscience de votre consommation de données normale et des modèles de votre application vous aidera à réduire vos coûts et vous aidera également à la planification de la capacité.
  • Ressources pod. Le planificateur Kubernetes fonctionne mieux lorsqu'il sait de quelles ressources un pod a besoin. Il peut ensuite s'assurer qu'il place des pods sur les nœuds où les ressources sont disponibles. Lors de la conception de votre réseau, prenez en compte le nombre de nœuds pouvant échouer avant que les nœuds restants ne puissent plus exécuter toutes les ressources souhaitées. L'utilisation d'un service tel qu'un groupe de mise à l'échelle automatique sur le cloud accélère la récupération, mais assurez-vous que les nœuds restants peuvent gérer la charge accrue pendant le temps nécessaire à la remise en ligne du nœud défaillant.