Termes - Container Service for Kubernetes - Centre de documentation Alibaba Cloud

Cluster

Un cluster est un ensemble de ressources cloud qui exécutent des applications conteneurisées, y compris des instances ECS, la mise en réseau VPC et l'équilibrage de charge SLB.

ACK propose différents types de clusters adaptés à vos besoins opérationnels et infrastructurels :

Type de cluster	Description	Idéal pour
ACK managed Pro cluster	Étend les clusters ACK managed Basic avec une fiabilité accrue, une sécurité renforcée et un accord de niveau de service (SLA) incluant des clauses de compensation.	Les charges de travail d'entreprise et les environnements de production à grande échelle nécessitant une disponibilité garantie
ACK managed Basic cluster	ACK crée et gère le plan de contrôle. Créez et maintenez uniquement les nœuds de calcul.	Les équipes souhaitant bénéficier d'un Kubernetes managé à moindre coût en ressources
ACK dedicated cluster	Nécessite trois plans de contrôle et des nœuds de calcul. Offre un contrôle granulaire de l'infrastructure, mais vous devez planifier, gérer et mettre à jour les nœuds vous-même.	Les équipes ayant besoin d'un contrôle direct sur le plan de contrôle
ACK cluster that supports sandboxed containers	Exécute des conteneurs isolés (sandboxed) sur des instances ECS Bare Metal pour offrir des performances élevées sous forte charge et une bande passante importante.	Les charges de travail exigeant une isolation stricte ou présentant des besoins élevés en E/S
ACK cluster for confidential computing	Utilise Intel Software Guard Extensions (Intel SGX) pour protéger le code et les données lors de l'exécution.	La protection des données, la blockchain, la gestion des clés, la protection de la propriété intellectuelle et le calcul génomique
ACK Edge cluster	Étend Kubernetes vers la périphérie (edge) avec l'autonomie des nœuds, la gestion basée sur des cellules et la gestion du trafic réseau. Prend en charge les API Kubernetes natives sans nécessiter de réécriture du code.	Les applications s'étendant aux environnements cloud et edge
ACK Serverless cluster	Aucun plan de contrôle ni nœud de calcul à provisionner. Configurez les ressources, spécifiez les images de conteneur et démarrez les applications directement depuis la console ACK ou la CLI.	Les équipes souhaitant exécuter des conteneurs sans gérer aucune infrastructure
ACK One registered cluster	Connecte des clusters Kubernetes externes à ACK pour une gestion centralisée, y compris les clusters sur site et ceux hébergés sur des clouds tiers.	Les environnements multi-clusters ou hybrides

Node

Un nœud est une machine virtuelle ou un serveur physique sur lequel Docker Engine est installé. Lorsqu'il est ajouté à un cluster ACK, ce dernier installe un agent et enregistre le nœud. Ajustez le nombre de nœuds à la hausse ou à la baisse en fonction de la demande de la charge de travail.

Node pool

Un node pool regroupe des nœuds partageant la même configuration afin de faciliter les mises à jour et la mise à l'échelle centralisées.

Les node pools ACK prennent en charge des fonctionnalités d'O&M automatisées qui réduisent la charge opérationnelle :

Application automatique des correctifs pour les vulnérabilités et expositions courantes (CVE) du système d'exploitation
Autorécupération des nœuds défaillants
Mises à jour automatiques des versions de kubelet et containerd

Consultez la section Node pools.

VPC

Un VPC est un réseau logiquement isolé sur Alibaba Cloud. Personnalisez le bloc CIDR, les tables de routage et les passerelles. Déployez des instances ECS, des instances SLB et des instances RDS au sein d'un VPC.

Security group

Un security group est un pare-feu virtuel doté de fonctions d'inspection stateful des paquets (SPI) et de filtrage pour les instances situées dans la même région. Les instances appartenant à un security group partagent les mêmes règles de sécurité.

App catalog

L'App catalog est une fonctionnalité d'ACK qui simplifie le déploiement grâce à l'intégration de Helm et à une interface graphique permettant de parcourir et d'installer des charts Helm.

Orchestration template

Un orchestration template stocke les configurations des ressources Kubernetes au format YAML pour permettre le versioning, la réutilisation et le partage.

Knative

Knative est un framework serverless basé sur Kubernetes conçu pour construire et exécuter des applications cloud-native sur diverses plateformes.

Kubernetes

Kubernetes est une plateforme open source dédiée aux charges de travail et services conteneurisés, offrant une configuration déclarative, des déploiements et rollbacks automatisés, une autoréparation et une mise à l'échelle horizontale.

Container

Un conteneur empaquete une application et ses dépendances d'exécution dans une unité portable et isolée. Un seul nœud peut exécuter plusieurs conteneurs.

Container image

Une image de conteneur empaquete une application et ses dépendances. Téléchargez les images depuis Docker Hub, Container Registry ou un registre privé.

Chaque image est identifiée par une combinaison de l'URI de son registre et d'un tag. Le tag par défaut est latest.

Image registry

Un image registry stocke les images fournies par Kubernetes ainsi que les images construites à partir de conteneurs.

Control plane

Le plan de contrôle gère les nœuds de calcul et les composants du cluster. Il expose l'API Kubernetes, planifie les charges de travail, maintient l'état du cluster et gère le réseau des conteneurs.

Le plan de contrôle comprend les composants suivants :

Composant	Rôle
`kube-apiserver`	Expose l'API Kubernetes. Toutes les opérations du cluster transitent par ce composant.
`kube-scheduler`	Assigne les nouveaux pods aux nœuds en fonction de la disponibilité des ressources et des contraintes de planification.
`kube-controller-manager`	Exécute les boucles de contrôle qui reconcilient l'état réel du cluster avec l'état souhaité (par exemple, le redémarrage des pods défaillants).
`etcd`	Magasin clé-valeur distribué qui conserve toutes les données de configuration et d'état du cluster.
Plug-ins de réseau de conteneur	Implémente la mise en réseau des pods et les politiques réseau pour le cluster.

Worker node

Un nœud de calcul est une machine virtuelle ou physique qui exécute les charges de travail, héberge les pods planifiés et communique avec le plan de contrôle. Les nœuds de calcul exécutent ces composants :

Environnement d'exécution Docker
kubelet — l'agent principal du nœud qui garantit que les conteneurs fonctionnent comme spécifié
kube-proxy — maintient les règles réseau pour la communication pod-à-pod et pod-à-service
Composants optionnels spécifiques à la configuration de votre cluster

Namespace

Les namespaces divisent les ressources du cluster en espaces virtuels isolés. Ils permettent de séparer les environnements, les équipes ou les applications au sein d'un même cluster. Les administrateurs de cluster peuvent créer des namespaces supplémentaires.

Chaque cluster ACK inclut les namespaces par défaut suivants :

Namespace	Objectif
`default`	Namespace par défaut pour les ressources créées sans namespace explicite.
`kube-system`	Réservé aux composants système de Kubernetes. Ne déployez pas vos applications ici.
`kube-public`	Lisible par tous les utilisateurs, y compris ceux non authentifiés. Réservé aux ressources publiques à l'échelle du cluster.

Pod

Un pod est la plus petite unité déployable dans Kubernetes. Il encapsule un ou plusieurs conteneurs, des volumes de stockage, une adresse IP de cluster unique et une configuration d'exécution.

ReplicationController

Un ReplicationController maintient un nombre spécifié de réplicas de pods. Il remplace les pods défaillants et termine les réplicas excédentaires. Le nombre minimal est de un.

ReplicationController est une ressource héritée. Utilisez ReplicaSet (géré par un Deployment) pour les nouvelles charges de travail.

ReplicaSet

ReplicaSet succède à ReplicationController en offrant des sélecteurs d'étiquettes plus flexibles. Les Deployments créent et gèrent les ReplicaSets pour maintenir le nombre souhaité de pods.

Workload

Une charge de travail est une application s'exécutant sur Kubernetes. Choisissez le type de charge de travail en fonction du comportement et des exigences de l'application :

Type de charge de travail	Description	À utiliser lorsque
Deployment	Les Deployments gèrent les applications répliquées sur un cluster Kubernetes. Utilisez-les pour des applications indépendantes partageant les mêmes fonctionnalités.	Exécution de plusieurs réplicas d'une application sans état
StatefulSet	Garantit un déploiement ordonné, une mise à l'échelle et des mises à jour progressives ; prend en charge le stockage persistant.	Applications nécessitant des identités stables ou des données persistantes (bases de données, files d'attente)
DaemonSet	Exécute un pod sur chaque nœud (ou sur un sous-ensemble sélectionné).	Opérations à l'échelle du cluster telles que la collecte de journaux, les agents de surveillance ou les plug-ins réseau au niveau du nœud
Job	Exécute une tâche jusqu'à son achèvement, avec parallélisme optionnel.	Traitement par lots et tâches ponctuelles
CronJob	Exécute une Job selon un planning défini.	Tâches périodiques telles que les sauvegardes ou les notifications par e-mail
CustomResourceDefinition (CRD)	Étend l'API Kubernetes avec des types de ressources personnalisés.	Intégration de contrôleurs tiers ou définition de ressources spécifiques à un domaine

Label

Les labels sont des paires clé-valeur associées aux ressources Kubernetes. Ils n'ont aucune sémantique système intrinsèque. Utilisez les labels pour organiser et sélectionner des ressources, par exemple pour les sélecteurs de Service ou la planification nodeAffinity. Ajoutez des labels lors de la création ou modifiez-les ultérieurement. Chaque ressource peut avoir plusieurs labels, mais chaque clé doit être unique.

Service

Un Service expose les pods via un endpoint réseau stable. kube-proxy sélectionne un pod backend et achemine le trafic vers le port du Service.

Ingress

Un Ingress achemine le trafic HTTP et HTTPS externe vers les Services internes au cluster. Configurez des URL accessibles, distribuez le trafic, terminez les connexions SSL et activez l'hébergement virtuel basé sur le nom.

Créez un Ingress via une requête HTTP POST vers le serveur API du cluster. Un contrôleur Ingress (généralement un équilibreur de charge) applique les règles. Pour une haute disponibilité, ajoutez des routeurs de bordure ou des proxys frontend.

ConfigMap

Une ConfigMap stocke la configuration non sensible sous forme de paires clé-valeur. Séparez la configuration des images de conteneur pour porter les applications d'un environnement à l'autre. Les ConfigMaps contiennent des valeurs individuelles, des fichiers de configuration ou des objets JSON.

Secret

Un Secret stocke des données sensibles telles que les mots de passe et les certificats, séparément de la configuration générale, afin de réduire les risques d'exposition accidentelle.

Volume

Un volume Kubernetes est un espace de stockage dont la durée de vie est liée à celle du pod. Contrairement aux volumes Docker (limités à un seul conteneur), un volume Kubernetes est partagé entre tous les conteneurs d'un même pod.

Persistent volume (PV)

Un persistent volume (PV) est un stockage au niveau du cluster, indépendant de tout pod. Provisionnez des types de PV tels que des disques cloud ou NAS via des StorageClasses.

Persistent volume claim (PVC)

Une persistent volume claim (PVC) demande du stockage. Les pods consomment les PVC de la même manière qu'ils consomment les ressources des nœuds.

StorageClass

Une StorageClass définit un type de stockage et permet le provisioning dynamique de PV. Lorsqu'une PVC référence une StorageClass, Kubernetes crée automatiquement un PV correspondant.

Auto scaling

L'Auto Scaling ajuste les ressources de calcul en fonction de la demande de la charge de travail. ACK effectue la mise à l'échelle à deux niveaux :

La mise à l'échelle au niveau des pods ajuste le nombre ou la taille des pods au sein d'un cluster :

Composant	Description
Horizontal Pod Autoscaler (HPA)	Met à l'échelle le nombre de pods en fonction de l'utilisation du CPU pour les Deployments et les StatefulSets.
CronHPA	Met à l'échelle les charges de travail selon un planning prédéfini à l'aide du composant `kubernetes-cronhpa-controller add-on`. Compatible avec HPA, utilisez-les conjointement lorsque vous avez besoin d'une mise à l'échelle basée à la fois sur le temps et sur les métriques.
Vertical Pod Autoscaler (VPA)	Ajuste les valeurs `request` et `limit` de CPU et de mémoire pour les pods en fonction de l'utilisation observée. Utilisez VPA pour les applications qui ne peuvent pas être mises à l'échelle horizontalement, ou pour dimensionner correctement les pods après la récupération d'une anomalie.

La mise à l'échelle au niveau des nœuds ajuste le nombre de nœuds du cluster :

Composant	Description
Cluster Autoscaler	Ajoute ou supprime des nœuds lorsque les pods ne peuvent pas être planifiés en raison de ressources insuffisantes. Prend en charge les instances classiques, accélérées par GPU et préemptibles, sur plusieurs zones et types d'instances.

Utilisez l'Auto Scaling pour les charges de travail en ligne, le calcul et l'entraînement à grande échelle, le deep learning accéléré par GPU, l'inférence et l'entraînement de modèles avec des GPU partagés, ainsi que pour les modèles de charge périodiques.

Observability

L'observabilité Kubernetes couvre la surveillance et la journalisation :

Surveillance — suit les métriques de santé et de performance pour la détection d'incidents en temps réel.
Journalisation — capture les événements applicatifs et système pour le diagnostic et le dépannage.

Helm

Helm est le gestionnaire de paquets pour Kubernetes. Un chart Helm regroupe les configurations de ressources pour déployer, mettre à jour et partager des applications.

nodeAffinity

nodeAffinity restreint les nœuds sur lesquels un pod peut s'exécuter, en se basant sur les labels des nœuds. Utilisez nodeAffinity pour diriger les charges de travail vers des nœuds disposant de matériel spécifique, situés dans certaines régions ou possédant des attributs personnalisés.

Taint

Un taint marque un nœud pour repousser les pods qui n'ont pas de tolération correspondante. Les taints fonctionnent à l'opposé de nodeAffinity : ils repoussent les pods au lieu de les attirer.

Toleration

Une toleration permet à un pod d'être planifié sur un nœud portant un taint correspondant. Les tolerations autorisent, mais n'imposent pas, le placement sur des nœuds tainted.

podAffinity

podAffinity place un pod dans le même domaine topologique (comme le même nœud ou la même zone) que les pods correspondant à un sélecteur. Utilisez podAffinity pour co-localiser les services qui communiquent fréquemment et réduire la latence réseau.

podAntiAffinity

podAntiAffinity empêche un pod de partager un domaine topologique avec les pods correspondant à un sélecteur. Utilisez podAntiAffinity pour répartir les réplicas sur différents nœuds ou zones afin d'améliorer la disponibilité.

Service mesh (Istio)

Istio est un service mesh open source qui connecte, sécurise, contrôle et observe les microservices.

Service Mesh (ASM) est le service mesh entièrement managé d'Alibaba Cloud, compatible avec Istio open source. Acheminez et divisez le trafic interservices, sécurisez la communication par authentification et observez le comportement des services sans modifier le code de l'application.