Azure Fundamentals · Leçon

Concepts Kubernetes pour Azure

Passez en revue les principales constructions Kubernetes — pods, déploiements, services et espaces de noms — et comprenez comment AKS gère le plan de contrôle pour vous.

Leçon 3 sur 413 étapes

Concepts Kubernetes pour Azure est une leçon Azure Fundamentals gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Azure Fundamentals, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Azure Fundamentals comprend 4 leçons au total.

Qu’est-ce que Kubernetes ?

Kubernetes (K8s) est une plateforme open source d’orchestration de conteneurs développée à l’origine par Google. Elle automatise le déploiement, la mise à l’échelle et la gestion des applications conteneurisées. Au lieu d’exécuter les conteneurs manuellement, vous déclarez l’état souhaité de votre application dans des manifestes YAML, puis Kubernetes s’efforce en permanence de faire correspondre l’état réel à l’état souhaité : il redémarre les conteneurs défaillants, planifie les charges de travail sur les nœuds sains et ajuste le nombre de réplicas.

Architecture du cluster : plan de contrôle et nœuds

Un cluster Kubernetes se compose d’un plan de contrôle et de nœuds Worker. Le plan de contrôle contient le serveur d’API (point d’entrée de toutes les commandes kubectl), etcd (magasin d’état distribué), le planificateur (qui affecte les Pods aux nœuds) et le gestionnaire de contrôleurs (qui maintient l’état souhaité). Les nœuds Worker exécutent le kubelet (agent du nœud), kube-proxy (règles réseau) et un moteur d’exécution de conteneurs (containerd). Dans AKS, Microsoft gère le plan de contrôle ; vous ne gérez que les nœuds Worker.

# Kubernetes control plane components
# kube-apiserver    - REST API for all cluster operations
# etcd              - Distributed key-value store (cluster state)
# kube-scheduler    - Assigns pending pods to nodes
# kube-controller-manager  - Runs reconciliation controllers

# Worker node components
# kubelet           - Node agent, ensures containers run
# kube-proxy        - Network routing for services
# containerd        - Container runtime (runs containers)

Pods : l’unité déployable la plus petite

Un Pod est l’unité déployable la plus petite de Kubernetes. Un Pod regroupe un ou plusieurs conteneurs qui partagent un espace de noms réseau (la même adresse IP), des volumes de stockage et un cycle de vie. Les conteneurs d’un Pod communiquent via localhost. Les Pods sont éphémères : lorsqu’ils échouent, ils sont remplacés par de nouveaux Pods dotés d’adresses IP différentes. Vous créez rarement des Pods directement ; vous créez plutôt des ressources de niveau supérieur qui les gèrent.

# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: mycontainerregistry.azurecr.io/myapp:v1.0
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: '100m'
        memory: '128Mi'
      limits:
        cpu: '500m'
        memory: '512Mi'

Déploiements : gérer les ReplicaSet

Un Deployment est la méthode standard pour exécuter des applications sans état dans Kubernetes. Il crée et gère un ReplicaSet qui maintient le nombre souhaité de réplicas de Pods identiques. Les Deployments prennent en charge les mises à jour progressives, qui remplacent graduellement les anciens Pods par de nouveaux, ainsi que les retours à une version précédente. Vous décrivez le modèle de Pod souhaité et le nombre de réplicas ; Kubernetes s’occupe du reste.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Create 1 extra pod during update
      maxUnavailable: 0 # Never reduce below desired count
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: mycontainerregistry.azurecr.io/myapp:v1.0
        ports:
        - containerPort: 80

Services : points de terminaison réseau stables

Comme les Pods sont éphémères et que leurs adresses IP changent, les Services fournissent un point de terminaison réseau stable qui répartit le trafic entre les Pods correspondants. Le Service utilise un sélecteur d’étiquettes pour trouver les Pods. Types de Service : ClusterIP (interne uniquement, valeur par défaut), NodePort (expose un port sur chaque nœud), LoadBalancer (provisionne un Azure Load Balancer avec une adresse IP publique) et ExternalName (alias DNS vers un service externe).

# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: LoadBalancer  # Creates Azure Load Balancer
  selector:
    app: myapp        # Routes traffic to pods with this label
  ports:
  - port: 80          # Service port
    targetPort: 80    # Pod/container port

# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svc

Espaces de noms pour la multilocation

Les espaces de noms partitionnent un cluster Kubernetes unique en plusieurs clusters virtuels. Les ressources de différents espaces de noms sont isolées par leur nom : vous pouvez avoir simultanément un myapp Deployment dans les espaces de noms development et production. Les espaces de noms constituent l’unité principale pour appliquer le RBAC, les quotas de ressources et les stratégies réseau à une équipe ou à un environnement. Les espaces de noms par défaut comprennent default, kube-system et kube-public.

# Create a namespace for the dev team
kubectl create namespace dev-team

# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team

# List all resources in a namespace
kubectl get all --namespace dev-team

# Set default namespace for current context
kubectl config set-context --current --namespace dev-team

ConfigMaps et secrets

Les ConfigMaps stockent des données de configuration non sensibles sous forme de paires clé-valeur ou de fichiers, injectées dans les Pods en tant que variables d’environnement ou montages de volumes. Les secrets stockent des données sensibles (mots de passe, jetons) encodées en base64 (elles ne sont pas chiffrées par défaut ; utilisez Azure Key Vault Provider for Secrets Store CSI Driver pour un véritable chiffrement au repos). Les deux sont associés à un espace de noms et sont référencés par leur nom dans les spécifications des Pods.

# Create a ConfigMap from literal values
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info

# Create a Secret
kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD='super-secret'

# Reference in a pod spec
# env:
# - name: APP_ENV
#   valueFrom:
#     configMapKeyRef:
#       name: app-config
#       key: APP_ENV
# - name: DB_PASSWORD
#   valueFrom:
#     secretKeyRef:
#       name: db-secret
#       key: DB_PASSWORD

Volumes persistants sur Azure

Les applications avec état ont besoin d’un stockage qui dure plus longtemps que les Pods individuels. Kubernetes utilise les PersistentVolumes (PV) et les PersistentVolumeClaims (PVC) pour découpler le stockage du cycle de vie des Pods. Sur AKS, les classes de stockage intégrées Azure Disk et Azure Files provisionnent automatiquement des disques managés et des partages de fichiers lorsqu’un PVC est créé. Azure Disk est destiné à l’accès d’un seul Pod ; Azure Files permet à plusieurs Pods de lire et d’écrire simultanément.

# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce   # Single-node read/write (Azure Disk)
  storageClassName: managed-csi
  resources:
    requests:
      storage: 10Gi

# Mount in a pod
# volumes:
# - name: data
#   persistentVolumeClaim:
#     claimName: my-disk-pvc
# volumeMounts:
# - name: data
#   mountPath: /data

Horizontal Pod Autoscaler

Le Horizontal Pod Autoscaler (HPA) ajuste automatiquement le nombre de réplicas de Pods dans un Deployment en fonction de l’utilisation observée du processeur et de la mémoire ou de métriques personnalisées. Le contrôleur HPA interroge le serveur de métriques toutes les 15 secondes et augmente ou réduit le nombre de réplicas pour maintenir l’utilisation à proximité de la cible. Vous définissez un nombre minimal et maximal de réplicas afin d’éviter une mise à l’échelle incontrôlée.

# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Contrôles d’intégrité : sondes de vivacité et de disponibilité

Kubernetes utilise des sondes pour surveiller l’état des conteneurs. Une sonde de vivacité vérifie qu’un conteneur fonctionne toujours ; en cas d’échec, Kubernetes redémarre le conteneur. Une sonde de disponibilité vérifie qu’un conteneur est prêt à recevoir du trafic ; en cas d’échec, le Pod est retiré de la répartition de charge du Service sans être redémarré. Une sonde de démarrage retarde les autres sondes jusqu’à l’initialisation de l’application, afin d’éviter les redémarrages prématurés lors d’un démarrage lent.

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /startup
    port: 80
  failureThreshold: 30
  periodSeconds: 10  # Allow 300s for slow startup

Demandes et limites de ressources

Chaque conteneur Kubernetes doit déclarer des demandes de ressources (l’allocation minimale garantie utilisée par le planificateur) et des limites (le maximum autorisé, au-delà duquel le conteneur est limité ou arrêté). Les demandes de processeur sont exprimées en milli-cœurs (m) : 1000m = 1 cœur de processeur. Définir précisément les demandes et les limites évite les problèmes de concurrence entre charges de travail et permet au planificateur de répartir efficacement les Pods sur les nœuds sans surallouer les ressources.

resources:
  requests:
    cpu: '250m'      # 0.25 CPU core guaranteed
    memory: '256Mi'  # 256 MiB guaranteed
  limits:
    cpu: '1'         # Max 1 CPU core
    memory: '512Mi'  # Max 512 MiB (OOMKilled if exceeded)

Vérification rapide

Évaluez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Réponds-y dans la leçon interactive

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que les pods sont les plus petites unités déployables partageant le réseau et le stockage, que les déploiements gèrent des ensembles de réplicas sans état avec prise en charge des mises à jour progressives, et que les services fournissent des points de terminaison stables qui répartissent le trafic entre des pods éphémères. Nous allons maintenant découvrir le déploiement de charges de travail sur AKS.

Gratuit pour commencer

Apprends Azure Fundamentals avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours: 30
Leçons: 120

Commencer gratuitement Voir le cours complet

Questions Fréquemment Posées

La leçon « Concepts Kubernetes pour Azure » est-elle gratuite ?

Oui — le texte complet de « Concepts Kubernetes pour Azure » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Azure Fundamentals, passe à CoddyKit PRO. Le cours Azure Fundamentals comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Concepts Kubernetes pour Azure » ?

Passez en revue les principales constructions Kubernetes — pods, déploiements, services et espaces de noms — et comprenez comment AKS gère le plan de contrôle pour vous. Tu pratiques Azure Fundamentals avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Azure Fundamentals ?

Aucune expérience préalable n'est requise. Azure Fundamentals sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Concepts Kubernetes pour Azure » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Azure Fundamentals ?

Oui. Chaque leçon Azure Fundamentals inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Azure Container Registry
Azure Container Instances
Concepts Kubernetes pour Azure
Déploiement de charges de travail sur AKS

← Retour à Azure Fundamentals