Compte non VRF ou compte VRF avec un noeud final de service cloud public uniquement

L'image suivante présente les composants de votre cluster et montre leur interaction dans un compte non VRF ou VRF lorsque seul le noeud final de service cloud public activé.

Compte VRF avec des noeuds finaux de service de cloud privé et public

L'image suivante présente les composants de votre cluster et montre leur interaction dans un compte avec la fonction VRF activée lorsque les noeuds finaux de service cloud publics et privés sont activés.

Composants du maître Kubernetes

Le maître Kubernetes est chargé de gérer toutes les ressources de calcul, de réseau et de stockage dans le cluster, ce qui garantit que vos applications et services conteneurisés sont déployés de manière égale sur les noeuds worker du cluster. En fonction de la configuration de vos applications et de vos services, le maître détermine le noeud worker qui dispose des ressources suffisantes pour répondre aux besoins de l'application.

Le maître Kubernetes et tous les composants du maître vous sont exclusivement dédiés et ne sont pas partagés avec d'autres clients IBM.

Le tableau suivant présente les composants d'un maître Kubernetes :

kube-apiserver

Le serveur d'API Kubernetes constitue le point d'entrée principal pour toutes les demandes de gestion de cluster du noeud worker au maître Kubernetes. Il valide et traite les demandes qui modifient l'état des ressources Kubernetes, tels que les pods ou les services, et enregistre cet état dans le magasin de données etcd.

konnectivity-server

Le serveur Konnectivity fonctionne avec l’agent Konnectivity pour connecter en toute sécurité le nœud maître au nœud de travail. Cette connexion prend en charge les appels apiserver proxy vers vos pods et services, ainsi que les appels kubectl exec, attach et logs vers le kubelet.

etcd

etcd est une base de données clé-valeur à haute disponibilité qui contient l'état de toutes les ressources Kubernetes d'un cluster, comme par exemple les services, les déploiements et les pods. Les données dans etcd sont sauvegardées sur une instance de stockage chiffrée gérée par IBM.

kube-scheduler

Le planificateur de Kubernetes examine les pods qui viennent d'être créés et décide de l'emplacement de leur déploiement en fonction de la capacité, des besoins en matière de performances, des contraintes en matière de réglementation, des spécification en matière d'anti-affinité et des exigences liées aux charges de travail. Si aucun noeud worker ne répond à ces exigences, le pod n'est pas déployé dans le cluster.

kube-controller-manager

Le gestionnaire de contrôleurs Kubernetes est un démon qui examine l'état des ressources de cluster, telles que les jeux de répliques. Lorsque l'état d'une ressource change, par exemple si un pod d'un ensemble de répliques tombe en panne, le gestionnaire de contrôleurs initie les actions correctives pour atteindre l'état requis.

Composants de nœud worker

Chaque noeud worker correspond à une machine physique (bare metal) ou à une machine virtuelle qui s'exécute sur du matériel physique dans l'environnement de cloud. Lorsque vous mettez à disposition un noeud worker, vous déterminez les ressources disponibles dans les conteneurs qui sont hébergés sur ce noeud worker. Les nœuds de travail sont configurés avec un environnement d'exécution de conteneurs géré par l' IBM, des ressources de calcul distinctes, une infrastructure réseau et un service de volumes. Les fonctions de sécurité intégrées assurent l'isolement, offrent des capacités de gestion des ressources et garantissent la conformité des noeuds worker en matière de sécurité.

Les noeuds worker et tous les composants des noeuds worker vous sont exclusivement dédiés et ne sont pas partagés avec d'autres clients IBM. Cependant, si vous utilisez une machine virtuelle de noeud worker, le matériel sous-jacent peut être partagé avec d'autres clients en fonction du niveau d'isolement du matériel que vous choisissez.

La modification des composants de noeud worker par défaut, tels que kubelet, n'est pas prise en charge et peut entraîner des résultats imprévisibles.

Les tableaux suivants décrivent les composants d'un nœud worker.

Espace de nom kube-system

ibm-master-proxy

ibm-master-proxy transfère les demandes du noeud worker aux adresses IP des répliques du maître à haute disponibilité. Dans les clusters à zone unique, le maître comporte trois répliques sur des hôtes distincts avec une adresse IP du maître et un nom de domaine. Pour les clusters qui se trouvent dans une zone compatible avec plusieurs zones, le maître comporte trois répliques réparties sur les différentes zones. Par conséquent, chaque maître dispose de sa propre adresse IP enregistrée avec DNS, avec un nom de domaine pour le maître cluster complet.

konnectivity-agent

L'agent Konnectivity fonctionne avec le serveur Konnectivity pour connecter en toute sécurité le nœud maître au nœud de travail. Cette connexion prend en charge les appels apiserver proxy vers vos pods et services, ainsi que les appels kubectl exec, attach et logs vers le kubelet.

kubelet

Le kubelet est un pod qui s'exécute sur tous les noeuds worker et qui est chargé de surveiller l'intégrité des pods qui s'exécutent sur le noeud worker et de contrôler les événements envoyés par le serveur d'API Kubernetes. En fonction des événements, le kubelet crée ou supprime des pods, assure la mise en place des sondes Liveness probe et Readiness probe et renvoie le statut des pods au serveur d'API Kubernetes.

coredns

Par défaut, Kubernetes planifie un service et un pod CoreDNS (ou un pod KubeDNS dans la version 1.12 ou antérieure) sur le cluster. Les conteneurs utilisent automatiquement l'adresse IP du service DNS pour résoudre les noms DNS dans leur recherche d'autres pods et services.

calico

Calico gère les règles réseau de votre cluster et comprend les composants suivants :

calico-cni : l'interface réseau de conteneur Calico (CNI) gère la connectivité réseau des conteneurs et supprime les ressources allouées lorsqu'un conteneur est supprimé.

calico-ipam: Calico IPAM gère l'affectation d'adresse IP des conteneurs.

calico-node : le nœud Calico est un conteneur qui regroupe les différents composants requis pour les conteneurs réseau avec Calico.

calico-policy-controller : le contrôleur de politiques Calico surveille le trafic entrant et sortant du réseau pour se conformer aux politiques de réseau définies. Si le trafic n'est pas autorisé dans le cluster, l'accès au cluster est bloqué. Calico Policy Controller est également utilisé pour créer et définir des règles réseau pour un cluster.

kube-proxy

Le proxy réseau de Kubernetes est un démon qui s'exécute sur tous les noeuds worker et transfère ou équilibre le trafic réseau TCP et UDP pour les services qui s'exécutent dans le cluster.

kube-dashboard

Le tableau de bord Kubernetes est une interface graphique Web qui permet aux utilisateurs d'assurer la gestion et le traitement des incidents du cluster et des applications qui s'exécutent dans le cluster.

heapster

Heapster est un outil d'agrégation de données d'événement et de surveillance à l'échelle du cluster. Le pod Heapster reconnaît tous les noeuds dans un cluster et interroge les informations d'utilisation à partir du kubelet de chaque noeud. Vous pouvez obtenir des graphiques d'utilisation dans le tableau de bord Kubernetes.

ALB Ingress

Ingress est un service Kubernetes que vous pouvez utiliser pour l'équilibrage de vos charges de travail réseau dans votre cluster en transférant des demandes publiques ou privées à plusieurs applications dans votre cluster. Pour exposer vos applications sur le réseau public ou privé, vous devez créer une ressource Ingress pour enregistrer vos applications auprès de l'équilibreur de charge d'application (ALB) Ingress. L'accès à plusieurs applications peut alors s'effectuer en utilisant une seule adresse URL ou une seule adresse IP.

Fournisseur de stockage

Tous les clusters sont configurés avec un plug-in pour mettre à disposition du stockage de fichiers. Vous pouvez opter pour l'installation d'autres modules complémentaires, comme par exemple du stockage par blocs.

Espace de nom ibm-system

Logging and Metrics

Vous pouvez utiliser les services IBM Cloud Logs et IBM Cloud® Monitoring pour étendre vos fonctions de collecte et de conservation lorsque vous gérez des journaux et des métriques. Équilibreur de charge

Un équilibreur de charge est un service Kubernetes que vous pouvez utiliser pour l'équilibrage de vos charges de travail réseau dans votre cluster en transférant des demandes publiques ou privées à une application.

Espace de nom default

Pods et services d'application

Dans l'espace de nom ou dans les espaces de nom default que vous créez, vous pouvez déployer des applications dans des pods et des services pour communiquer avec ces pods.