Compréhension théorique de l'entrée Kubernetes

Avant-propos :

En tant qu'ingénieur d'exploitation et de maintenance, si vous ne connaissez pas encore k8s, alors vous êtes vraiment out.Ce chapitre présente principalement la partie théorique d'entrée de gamme de k8s (Kubernetes).

1. Présentation de Kubernetes

1. Qu'est-ce que Kubernetes ?

Kubernetes est une plate-forme open source portable et extensible pour la gestion des charges de travail et des services conteneurisés qui facilite la configuration et l'automatisation déclaratives. Il possède un écosystème vaste et en croissance rapide. Les services, l'assistance et les outils Kubernetes sont partout.

Kubernetes tire son nom du mot grec signifiant timonier ou pilote. Le résultat de K8s en tant qu'abréviation provient du calcul des huit lettres entre "K" et "s". Google a ouvert le projet Kubernetes en 2014. Kubernetes associe les plus de 15 ans d'expérience de Google dans l'exécution de charges de travail de production à grande échelle aux meilleures idées et pratiques de la communauté.

Site officiel de référence : https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/, qui présente principalement les concepts de base et les scénarios d'application de kubernetes, le concept de conception des K8 et ce que les K8 peuvent faire et ne pas faire faire.

2. Pourquoi avez-vous besoin de K8S ?

Imaginez simplement la méthode de déploiement back-end traditionnelle : placez le package (y compris les fichiers binaires exécutables, les fichiers de configuration, etc.) sur le serveur, puis exécutez le script de démarrage pour exécuter le programme et démarrez le script démon pour vérifier régulièrement l'état d'exécution. du programme et redémarrez-le si nécessaire. Remontez le programme.

Imaginez, que se passe-t-il si le volume de demande de service augmente et que le service déployé ne répond pas ? L'approche traditionnelle est souvent que si le volume de demande, la mémoire et le processeur dépassent le seuil et qu'une alarme est émise, le personnel d'exploitation et de maintenance ajoutera immédiatement un peu de serveurs et déploiement Après un bon service, accédez à la répartition de charge pour partager la pression des services existants. Ce problème se pose : de la surveillance des alarmes au déploiement des services, une intervention humaine est nécessaire au milieu ! Alors, existe-t-il un moyen de terminer automatiquement le déploiement, la mise à jour, la désinstallation, l'expansion et la contraction des services ? Et c'est ce que fait K8S : automatisé opération Gère de manière dimensionnelle les programmes conteneurisés (Docker).

L'objectif de K8S est de rendre le déploiement d'applications conteneurisées simple et efficace.

K8s résout plusieurs problèmes liés à l'exécution de Docker nu :

1.单机使用，无法有效集群
2.随着容器数量的上升，管理成本攀升
3.没有有效的容灾、自愈机制
4.没有预设编排模板，无法实现快速、大规模容器调度
5.没有统一的配置管理中心工具
6.没有容器生命周期的管理工具
7.没有图形化运维管理工具

K8S fournit une série de fonctions telles que l' orchestration des conteneurs, la planification des ressources, la mise à l'échelle élastique, la gestion du déploiement et la découverte de services .

Deuxièmement, les caractéristiques de K8S

(1) Mise à l' échelle élastique : utilisez des commandes, une interface utilisateur ou augmentez et réduisez automatiquement et rapidement les instances d'application en fonction de l'utilisation du processeur pour garantir une haute disponibilité lorsque les applications sont simultanées pendant les pics d'activité ; recyclez les ressources pendant les pics d'activité faibles pour exécuter des services à un coût minimal .

(2) Autoréparation : Redémarrez les conteneurs défaillants, remplacez et redéployez lorsque les nœuds échouent, garantissez le nombre de répliques attendu ; tuez les conteneurs qui échouent aux vérifications de l'état et ne traiteront pas les demandes des clients tant qu'ils ne seront pas prêts à garantir que le service en ligne ne sera pas interrompu .

(3) Découverte de service et équilibrage de charge : K8S fournit une entrée d'accès unifiée (adresse IP interne et un nom DNS) pour plusieurs conteneurs, et équilibre la charge de tous les conteneurs associés, afin que les utilisateurs n'aient pas à se soucier des problèmes d'IP des conteneurs.

(4) Lancement automatique (mode de lancement progressif par défaut) et restauration : K8S utilise une stratégie progressive pour mettre à jour les applications, en mettant à jour un pod à la fois au lieu de supprimer tous les pods en même temps. En cas de problème lors du processus de mise à jour, les modifications seront annulées pour s'assurer que la mise à niveau n'affecte pas les activités.

(5) Gestion centralisée de la configuration et gestion des clés : gérez les données confidentielles et la configuration des applications sans exposer les données sensibles dans l'image, améliorez la sécurité des données sensibles et stockez certaines configurations couramment utilisées dans K8S, ce qui est une utilisation pratique des applications.

(6) Orchestration du stockage : prendre en charge le stockage externe et orchestrer les ressources de stockage externes, monter des systèmes de stockage externes, que ce soit à partir d'un stockage local, d'un cloud public (par exemple : AWS) ou d'un stockage de village réseau (par exemple : NFS, Glusterfs, Ceph) Tous sont utilisés comme partie des ressources du cluster, ce qui améliore considérablement la flexibilité d'utilisation du stockage.

(7) Traitement par lots et exécution de tâches : fournissez des tâches ponctuelles et des tâches planifiées pour répondre aux scénarios de traitement et d'analyse de données par lots.

3. Architecture et composants du cluster K8S

K8S appartient au modèle d'appareil maître-esclave (architecture maître-esclave) , c'est-à-dire que le nœud maître reproduit la planification, la gestion et le fonctionnement du cluster, et le nœud esclave est le nœud de charge de travail informatique du cluster. Dans K8S, le nœud maître est généralement appelé le nœud maître et le nœud esclave est appelé le nœud de nœud de travail.Chaque nœud se verra attribuer une charge de travail par le maître.

Le composant maître peut s'exécuter sur n'importe quel ordinateur du cluster, mais il est recommandé que le nœud maître occupe un serveur indépendant, car le maître est le cerveau de l'ensemble du cluster. Si le nœud où se trouve le maître est en panne ou indisponible, tous les commandes de contrôle échoueront. . En plus du maître, d'autres machines du cluster K8S sont appelées nœuds de travail.Lorsqu'un nœud tombe en panne, la charge de travail sur celui-ci sera automatiquement transférée par le maître vers d'autres nœuds.

Quatrièmement, les composants de base de K8S

1.Composant principal

1.1 Être apiserver

Utilisé pour exposer l'API Kubernetes , toute demande de ressource ou opération d'appel est effectuée via l'interface fournie par kube-apiserver. L'API HTTP Restful est utilisée pour fournir des services d'interface, et tous les ajouts, suppressions, modifications et opérations de surveillance des ressources d'objets sont transmis à API Server pour traitement, puis soumis à Etcd pour stockage .

On peut comprendre que API Server est le service d'entrée de requête de K8S . Le serveur API est chargé d'accepter toutes les demandes de K8S (depuis l'interface utilisateur ou l'outil de ligne de commande CLI), puis de notifier aux autres composants de fonctionner en fonction de la demande spécifique de l'utilisateur. On peut dire que API Server est le cerveau de l'architecture du cluster K8S.

1.2 kube-controller-manager

Le contrôleur de gestion des opérations est le thread d'arrière-plan qui traite les tâches de routine dans le cluster K8S et est le centre de contrôle automatique pour tous les objets de ressource dans le cluster K8S. Dans un cluster K8S, une ressource correspond à un contrôleur, et le gestionnaire de contrôleur réplique et gère ces contrôleurs.

Il se compose d'une série de contrôleurs. Il surveille l'état de l'ensemble du cluster via le serveur d'API et s'assure que le cluster est dans l'état de fonctionnement attendu. Par exemple, lorsqu'un nœud tombe en panne de manière inattendue, le gestionnaire de contrôleur détecte et exécute un processus de réparation automatisé à temps pour s'assurer que le cluster est toujours dans l'état de fonctionnement prévu.

Ces contrôleurs comprennent principalement :

① Node Controller : responsable de la découverte et de la réponse aux pannes de nœud.

② Replication Controller : chargé de s'assurer que la réplique de pod associée à un RC (Resource Object Replication Controller) dans le cluster conserve toujours la valeur prédéfinie. Cela peut être compris comme garantissant qu'il y a N instances de pod dans le cluster, où N est le nombre de réplicas de pod définis dans RC.

③ Endpoints Controller : renseignez l'objet endpoint (c'est-à-dire connecter le Service et les Pods), chargé de surveiller les modifications du Service et de la copie du Pod correspondant. On peut comprendre que le endpoint est un point d'accès exposé par un service. Si vous avez besoin d'accéder à un service, son point de terminaison doit être connu.

④ Contrôleurs de compte de service et de jeton : créez un compte par défaut et un jeton d'accès à l'API pour le nouvel espace de noms.

⑤ ResourceQuota Controller (contrôleur d'espace de noms) : gérez le cycle de vie de l'espace de noms.

⑥ Service Controller : Il appartient à un contrôleur d'interface entre le cluster K8S et la plateforme cloud externe.

1.3 Soyez un planificateur

Il s'agit du processus responsable de la planification des ressources et sélectionne un nœud de nœud approprié pour le pod nouvellement créé en fonction de l'algorithme de planification.

Il peut être compris comme le planificateur de tous les nœuds Node de K8S. Lorsque l'utilisateur souhaite déployer le service, le planificateur sélectionne le nœud de nœud le plus approprié pour déployer le pod en fonction de l'algorithme de planification.

Il existe généralement deux stratégies pour l'algorithme d'ordonnancement :

Stratégie budgétaire (prédicat)

Priorités

1.4 Configuration du Storage Center - etcd

Service de stockage K8S. etcd est un système de stockage clé-valeur distribué, qui stocke la configuration clé et la configuration utilisateur de K8S. Dans K8S, seul le serveur API dispose d'autorisations de lecture et d'écriture, et les autres composants ne peuvent lire et écrire des données que via l'interface du serveur API.

2. Composants du nœud

2.1Kubelet

Le moniteur du nœud Node, ainsi que le communicateur avec le nœud Master, Kubelet est la "eyeline" que le nœud Master place sur le nœud Node, il rapportera régulièrement à l'API Server l'état du service en cours d'exécution sur son nœud nœud principal et accepter les informations du nœud maître. Ordonne de prendre des mesures correctives.

Obtenez l'état souhaité du pod sur son propre nœud à partir du nœud maître (tel que le conteneur en cours d'exécution, le nombre de répliques en cours d'exécution, la configuration du réseau ou du stockage, etc.) et interagissez directement avec le moteur de conteneur pour réaliser la gestion du cycle de vie du conteneur. Si l'état attendu est incohérent, appelez l'interface de plate-forme de conteneur correspondante (c'est-à-dire l'interface de Docker) pour atteindre cet état.

Gérer le nettoyage des images et des conteneurs pour s'assurer que les images sur les nœuds ne remplissent pas l'espace disque et que les conteneurs abandonnés n'occupent pas trop de ressources

2.2 Être mandataire

Le proxy réseau Pod est implémenté sur chaque nœud Node, qui est le support des ressources du service Kubernetes, responsable de la maintenance des règles réseau et de l'équilibrage de charge à quatre couches, et responsable de l'écriture des règles sur Iptables et ipvs pour obtenir l'accès au mappage de service.

Kube-Proxy lui-même ne fournit pas directement de réseau au Pod.Le réseau de Pod est fourni par Kubelet, et ce que Kube-Proxy gère réellement est un réseau de cluster de Pod virtuel. Kube-apiserver met à jour le service Kubernetes et maintient les points de terminaison en surveillant Kube-Proxy.

L'équilibrage de charge des microservices dans le cluster K8S est implémenté par kube-Proxy. kube-proxy est un équilibreur de charge à l'intérieur du cluster K8s, c'est un serveur proxy distribué et un composant Kube-Proxy s'exécute sur chaque nœud de K8s.

2.3 docker ou fusée

Le moteur de conteneur, qui exécute les conteneurs, est responsable de la création et de la gestion des conteneurs natifs. Maintenant, utilisez essentiellement docker

Cinq concepts de base de Kubernetes

Kubernetes contient différents types d'objets ressources : Pod, Label, Service, Replication Controller, etc.

Tous les objets de ressource peuvent être ajoutés, supprimés, modifiés et recherchés via l'outil Kubectl fourni par Kubernetes, et enregistrés dans etcd pour un stockage persistant.

Kubernetes est en fait un système de contrôle des ressources hautement automatisé. Il implémente des fonctions avancées telles que le contrôle automatique et la correction automatique des erreurs en suivant et en comparant la différence entre l'état attendu des ressources enregistrées dans le stockage etcd et l'état réel des ressources dans l'environnement actuel.

1.Cosse

Un pod est l' unité de base la plus petite/la plus simple créée ou déployée par Kubernetes . Un pod représente un processus s'exécutant sur un cluster. Les gousses peuvent être comprises comme des cosses de pois, et chaque récipient dans le même Pod est un pois.

Un pod se compose d'un ou plusieurs conteneurs. Les conteneurs du pod partagent des ressources réseau, de stockage et de calcul et s'exécutent sur le même hôte Docker.

Un pod peut exécuter plusieurs conteneurs, également appelés mode SideCare.Dans un environnement de production, un seul conteneur ou plusieurs conteneurs avec une forte corrélation et complémentarité sont généralement utilisés pour former un pod.

Le même pod et conteneur peuvent accéder les uns aux autres via localhost et peuvent monter tous les volumes de données dans le pod ; mais les conteneurs entre différents pods ne sont pas accessibles par localhost, et ils ne peuvent pas non plus monter les volumes de données d'autres pods.

La communication réseau des pods dans Kubernetes est la suivante :

2. Contrôleur de pod

Le contrôleur de pod est un modèle pour le démarrage du pod, qui est utilisé pour garantir que les pods démarrés dans K8S doivent toujours fonctionner comme prévu par les utilisateurs (nombre de copies, cycle de vie, vérification de l'état de santé, etc.).

Il existe de nombreux contrôleurs Pod fournis dans K8S, et ceux couramment utilisés sont les suivants :

① Déploiement : déploiement d'applications sans état. Le rôle du déploiement est de gérer et de contrôler les pods et les ReplicaSets, et de les contrôler pour qu'ils s'exécutent dans l'état souhaité par l'utilisateur.

② Replicaset : Assurez-vous du nombre attendu de répliques de pod. Le rôle de ReplicaSet est de gérer et de contrôler les pods, et de contrôler leur bon fonctionnement. Cependant, le ReplicaSet est contrôlé par le déploiement.

On peut comprendre que le déploiement est l'entrepreneur général. Il est principalement responsable de la supervision du travail des pods de travail qui en dépendent, en s'assurant que le nombre de pods requis par l'utilisateur fonctionne à tout moment. Si vous constatez qu'un pod de travail est ne fonctionne pas, vous en retirerez rapidement un nouveau. Pod vient le remplacer. Et ReplicaSet est un petit entrepreneur sous la direction de l'entrepreneur.

Du point de vue des utilisateurs de K8S, les utilisateurs doivent uniquement être liés au déploiement et ne pas se soucier du prédécesseur de ReplicaSet. Il est officiellement recommandé d'utiliser le déploiement au lieu du contrôleur de réplication pour déployer les services.

③ Daemonset : assurez-vous que tous les nœuds exécutent le même type de pod et qu'il existe un tel pod en cours d'exécution sur chaque nœud, qui est généralement utilisé pour implémenter des tâches d'arrière-plan au niveau du système.

④ Statefulset : Déploiement d'application avec état.

⑤ Job : une tâche ponctuelle. Selon les paramètres de l'utilisateur, le pod géré par le Job se ferme automatiquement une fois la tâche terminée avec succès.

⑥ Cronjob : Tâches planifiées périodiquement.

3.Étiquette

Label est une méthode de gestion caractéristique de K8S, qui est pratique pour classer et gérer les objets de ressource.

Des étiquettes peuvent être attachées à divers objets de ressource, tels que : nœud, pod, service, RC, etc., pour associer des objets, interroger et filtrer.

Une étiquette est une paire clé-valeur, où la clé et la valeur sont spécifiées par l'utilisateur.

Un objet de ressource peut définir n'importe quel nombre d'étiquettes, et la même étiquette peut également être ajoutée à n'importe quel nombre d'objets de ressource, et peut également être dynamiquement ajoutée ou supprimée après la création de l'objet.

La fonction de gestion de groupement de ressources multidimensionnelles peut être réalisée en regroupant une ou plusieurs étiquettes différentes à l'objet de ressource spécifié.

Semblable à Label, il y a Annotation.

La différence est qu'une valeur de balise valide doit être de 63 caractères ou moins, et doit être vide ou alphanumérique ([a-z0-9A-Z]) au début et à la fin, et peut contenir des tirets (-), des traits de soulignement (), Un point (.) et une lettre ou un chiffre. Les valeurs de commentaire n'ont pas de limite de longueur de caractères.

4 .Sélecteur d'étiquette (sélecteur d'étiquette)

Définir une étiquette pour un objet de ressource équivaut à lui ajouter une étiquette, puis vous pouvez interroger et filtrer des objets de ressource avec certaines étiquettes via le sélecteur d'étiquette.

Il existe actuellement deux types de sélecteurs de balises : basés sur l'équivalence (égal, différent) et basés sur l'ensemble (appartient, n'appartient pas, existe).

5.Service

Dans un cluster K8S, bien que chaque pod se verra attribuer une adresse IP distincte, puisque les pods ont un cycle de vie (ils peuvent être créés et ne seront pas redémarrés après avoir été détruits), ils peuvent changer à tout moment en raison de changements commerciaux. résultat, cette adresse IP disparaîtra également avec la destruction du Pod.

Et le service est le concept de base utilisé pour résoudre ce problème.

Le service dans K8S n'est pas le sens de "service" que nous disons souvent, mais plutôt une couche de passerelle, qui peut être considérée comme un ensemble d'interfaces d'accès externes et d'équilibreurs de trafic pour les pods qui fournissent le même service.

Les pods sur lesquels un service agit sont définis par un sélecteur d'étiquettes.

Dans un cluster K8S, un Service peut être considéré comme une interface d'accès externe pour un groupe de Pods qui fournissent le même service. Le service auquel le client doit accéder est l'objet Service. chaque Prestation

Il existe une IP virtuelle fixe (cette IP est également appelée Cluster IP), qui est automatiquement et dynamiquement liée au Pod du backend. Toutes les requêtes réseau accèdent directement à l'IP virtuelle du Service, et le Service la transmettra automatiquement au arrière-plan.

En plus de fournir un accès externe stable, le service peut également fonctionner comme équilibreur de charge, distribuant automatiquement le trafic des demandes à tous les services sur le backend. Le service peut évoluer horizontalement de manière transparente pour les clients. ).

La clé pour réaliser la fonction de service est kube-proxy. kube-proxy s'exécute sur chaque nœud, surveillant les modifications des objets de service dans API Server,

Les trois modes de planification du trafic suivants sont disponibles :

**espace utilisateur (abandonné), iptables (sur le point d'être abandonné), ipvs (recommandé, meilleures performances)** pour réaliser le transfert réseau.

Le service est au cœur des services K8S, qui protège les détails du service et expose les interfaces de service de manière unifiée, réalisant véritablement des « microservices ». Par exemple, un de nos services A déploie 3 réplicas, soit 3 Pods ; pour les utilisateurs, ils n'ont qu'à faire attention à la saisie d'un Service, et n'ont pas à se soucier du Pod à demander.

Les avantages sont très évidents : d'une part, les utilisateurs externes n'ont pas besoin de percevoir les changements d'adresse IP causés par des plantages de service inattendus sur le pod et le redémarrage des pods par K8S, et les utilisateurs externes n'ont pas non plus besoin de percevoir les remplacements de pod causés par les mises à niveau et les changements de service. .IP change.

6. Entrée

Le service est principalement responsable de la topologie du réseau à l'intérieur du cluster K8S, alors comment l'extérieur du cluster peut-il accéder à l'intérieur du cluster ? Ingress est la couche d'accès de l'ensemble du cluster K8S et est responsable de la communication à l'intérieur et à l'extérieur du cluster.

Ingress est une application de couche 7 qui fonctionne sous le modèle de référence de réseau OSI dans le cluster K8S et expose l'interface au monde extérieur. La méthode d'accès typique est http/https. Le service ne peut effectuer la planification du trafic qu'au niveau de la quatrième couche, sous la forme d'ip + port. Ingress peut planifier le trafic commercial de différents domaines commerciaux et différents chemins d'accès URL.

7. Nom

Étant donné que K8S utilise des "ressources" pour définir chaque concept logique (fonction), chaque "ressource" doit avoir son propre "nom".

Les "ressources" contiennent des informations de configuration telles que la version de l'API (apiversion), la catégorie (kind), les métadonnées (metadata), la liste de définitions (spec) et le statut (status).

Le "nom" est généralement défini dans les informations "métadonnées" de la "ressource". Doit être unique dans le même espace de noms.

8. Espace de noms

Avec l'augmentation des projets, l'augmentation du personnel et l'expansion de l'échelle du cluster, une méthode qui peut logiquement isoler diverses "ressources" dans K8S s'impose, qui est Namespace. L'espace de noms est né pour diviser un cluster K8S en milliers de groupes de clusters virtuels dont les ressources ne peuvent pas être partagées. Les "ressources" dans différents espaces de noms peuvent avoir le même nom, et les mêmes "ressources" dans le même espace de noms ne peuvent pas avoir le même "nom".

L'utilisation raisonnable de l'espace de noms de K8S permet aux administrateurs de cluster de mieux gérer et parcourir les services fournis à K8S. Les espaces de noms par défaut dans K8S sont : default, kube-system, kube-public, etc.

Pour interroger une "ressource" spécifique dans K8S, vous devez apporter le Namespace correspondant.

6. Flux de travail de K8S pour créer un POd

1.首先API Server接受请求创建一批 POd，API Server 会把相关信息写入到etcd当中 。然后API Server会让Controller-manager 按照预设的模板（就是按照etcd里的信息）去创建Pod
2.Controller-manager会通过API Server 去找 Scheduler 为新创建的POD，Scheduler会通过预选策略或择优策略选择一个为新创建的Pod 最合适nod节点（Schduler是通过etcd里的pod信息来进行筛选node的）
3.scheduler找到node后，会通过API Server去找到 对应node上面的 Kubelet，然后通过kubelet去创建（创建的话要通过docker引擎去创建），维护pod并且管理pod的生命周期
4.创建完pod群集之后 ，kube-proxy 讲这些pod 关联起来，使用一个service资源（pod群集统一使用一个ip地址，并且暴露出去）
5.外部用户通过 这个暴露的ip 访问到pod 里面运行的业务
6.运维人员通过 node节点中的Kubelet 监控 pod 中跑了哪些业务 ，使用了哪些资源和一些相关状态，然后kubelet通过 kube_apiserver 将这些信息写入到 etcd中 保存起来