Principes fondamentaux de l'ordonnancement des pods Kubernetes
Kubernetes est une plateforme puissante d'orchestration de conteneurs qui offre des fonctionnalités d'ordonnancement avancées pour gérer le déploiement et la mise à l'échelle d'applications emballées dans des conteneurs. Au cœur de l'ordonnancement Kubernetes se trouve le concept de pods, qui sont les plus petites unités déployables pouvant être ordonnées et gérées par le cluster Kubernetes.
Dans cette section, nous explorerons les aspects fondamentaux de l'ordonnancement des pods Kubernetes, y compris le processus d'ordonnancement de base, les exigences de ressources des pods et les stratégies d'ordonnancement courantes.
Comprendre les pods Kubernetes
Les pods Kubernetes sont les briques fondamentales d'un cluster Kubernetes. Un pod est un groupe d'un ou plusieurs conteneurs, avec des ressources de stockage et de réseau partagées, et une spécification sur la manière d'exécuter les conteneurs. Les pods sont les plus petites unités déployables pouvant être créées, ordonnées et gérées par Kubernetes.
graph LR
Pod --> Container1
Pod --> Container2
Pod --> SharedVolume
Pod --> SharedNetwork
Processus d'ordonnancement Kubernetes
Le planificateur Kubernetes est responsable d'attribuer les pods à des nœuds appropriés dans le cluster. Le processus d'ordonnancement implique les étapes suivantes :
- Création d'un pod : Un nouveau pod est créé et ajouté au serveur API Kubernetes.
- Filtrage : Le planificateur filtre les nœuds disponibles sur la base des exigences de ressources du pod et d'autres contraintes.
- Classement : Le planificateur classe les nœuds filtrés sur la base de divers facteurs, tels que la disponibilité des ressources, l'affinité et d'autres politiques d'ordonnancement.
- Sélection : Le planificateur sélectionne le nœud ayant le score le plus élevé et lie le pod à ce nœud.
sequenceDiagram
participant API Server
participant Scheduler
participant Node1
participant Node2
API Server->>Scheduler: Nouveau pod créé
Scheduler->>Node1: Filtrer et classer
Scheduler->>Node2: Filtrer et classer
Scheduler->>API Server: Lier le pod au nœud Node1
Exigences de ressources des pods
Les pods dans Kubernetes peuvent avoir des exigences de ressources spécifiques, telles que le CPU et la mémoire. Ces exigences de ressources sont définies dans la spécification du pod et sont utilisées par le planificateur pour trouver le nœud le plus approprié pour le pod.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: nginx
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
Dans l'exemple ci-dessus, le pod a une demande de CPU de 100 millicores et une demande de mémoire de 128 MiB. Le pod a également une limite de CPU de 500 millicores et une limite de mémoire de 256 MiB.
Stratégies d'ordonnancement
Kubernetes propose diverses stratégies d'ordonnancement pour répondre à différents besoins de placement de pods. Certaines stratégies d'ordonnancement courantes sont les suivantes :
- Ordonnancement par défaut : Le planificateur Kubernetes par défaut attribue les pods à des nœuds sur la base de la disponibilité des ressources et d'autres contraintes.
- Affinité de nœud : Les pods peuvent être ordonnés sur des nœuds spécifiques sur la base d'étiquettes et de sélecteurs de nœuds.
- Affinité et anti-affinité de pods : Les pods peuvent être ordonnés pour s'exécuter sur le même ou des nœuds différents sur la base de la relation entre les pods.
- Taints et tolérances : Les nœuds peuvent être marqués comme indisponibles pour certains pods, et les pods peuvent être configurés pour tolérer des taints spécifiques.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: environment
operator: In
values:
- production
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
containers:
- name: example-container
image: nginx
Dans l'exemple ci-dessus, le pod est configuré pour être ordonné sur un nœud avec l'étiquette environment=production
, et il est également configuré pour tolérer la taint node-role.kubernetes.io/master
.