0Pricing
Azure Fundamentals · Leçon

Déploiement de charges de travail sur AKS

Créez un cluster AKS, déployez une application mult Conteneur avec kubectl et des graphiques Helm, puis exposez-la à l’extérieur avec un service Azure Load Balancer.

Déploiement de charges de travail sur AKS est une leçon Azure Fundamentals gratuite sur CoddyKit. Ceci est la leçon 4 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 qu’Azure Kubernetes Service ?

Azure Kubernetes Service (AKS) est une offre Kubernetes managée dans laquelle Microsoft exploite et maintient le plan de contrôle (serveur d’API, etcd, ordonnanceur) gratuitement. Vous ne payez que les nœuds worker (VM). AKS gère les mises à niveau de la version de Kubernetes, l’application des correctifs du système d’exploitation des nœuds, la mise à l’échelle du plan de contrôle et l’intégration avec le réseau, le stockage et la gestion des identités Azure. Cela réduit considérablement la charge opérationnelle liée à l’exécution de Kubernetes en production.

Créer un cluster AKS

Créez un cluster AKS avec az aks create, en spécifiant le nombre de nœuds, la taille des VM et les options réseau. AKS crée automatiquement un groupe de ressources de nœuds contenant les VM, les disques managés, les cartes réseau et les équilibreurs de charge. Le mode réseau recommandé est Azure CNI : chaque pod reçoit une véritable adresse IP de réseau virtuel, ce qui permet une connectivité directe avec les autres services Azure sans NAT.

# Create an AKS cluster with 3 nodes
az aks create \
  --name myAKSCluster \
  --resource-group MyRG \
  --location eastus \
  --node-count 3 \
  --node-vm-size Standard_D2s_v3 \
  --enable-managed-identity \
  --attach-acr mycontainerregistry \
  --network-plugin azure \
  --generate-ssh-keys

# Get kubectl credentials
az aks get-credentials --name myAKSCluster --resource-group MyRG

Pools de nœuds

Les clusters AKS peuvent comporter plusieurs pools de nœuds : des groupes de VM ayant la même configuration. Le pool de nœuds système exécute les composants système Kubernetes essentiels (pods kube-system). Les pools de nœuds utilisateur exécutent vos charges de travail applicatives. Des pools distincts vous permettent de combiner plusieurs références de VM : un pool polyvalent pour les applications web et un pool GPU pour les charges de travail de ML, par exemple, et de les mettre à l’échelle indépendamment.

# Add a GPU node pool for ML workloads
az aks nodepool add \
  --cluster-name myAKSCluster \
  --resource-group MyRG \
  --name gpupool \
  --node-count 2 \
  --node-vm-size Standard_NC6s_v3 \
  --node-taints sku=gpu:NoSchedule

# List node pools
az aks nodepool list \
  --cluster-name myAKSCluster \
  --resource-group MyRG \
  -o table

Déployer une application multi-conteneurs

Déployez une application à plusieurs niveaux sur AKS en écrivant des fichiers manifeste Kubernetes distincts pour chaque niveau, puis en les appliquant avec kubectl apply. Un déploiement classique comprend un déploiement pour le niveau web, un déploiement pour le niveau API, des services pour les relier, un ConfigMap pour la configuration de l’environnement et une ressource Ingress pour exposer l’application à l’extérieur via un seul nom d’hôte.

# Apply all manifests in a directory
kubectl apply -f k8s/

# Or apply individual files
kubectl apply -f frontend-deployment.yaml
kubectl apply -f frontend-service.yaml
kubectl apply -f api-deployment.yaml
kubectl apply -f api-service.yaml
kubectl apply -f ingress.yaml

# Watch rollout status
kubectl rollout status deployment/frontend
kubectl rollout status deployment/api

Ingress et Application Gateway

Une ressource Ingress définit des règles de routage HTTP qui associent les noms d’hôte et les chemins URL aux services principaux. Contrairement à un service LoadBalancer (une adresse IP externe par service), un seul contrôleur Ingress gère l’ensemble du trafic HTTP externe et l’achemine en fonction de règles. Dans AKS, utilisez le contrôleur NGINX Ingress ou le contrôleur Application Gateway Ingress (AGIC) pour terminer TLS et acheminer le trafic vers plusieurs services.

# Ingress routing traffic to two services by path
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts: [myapp.contoso.com]
    secretName: myapp-tls
  rules:
  - host: myapp.contoso.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service: {name: api-svc, port: {number: 80}}
      - path: /
        pathType: Prefix
        backend:
          service: {name: frontend-svc, port: {number: 80}}

Charts Helm pour empaqueter les applications

Helm est le gestionnaire de paquets de Kubernetes. Un chart regroupe tous les manifestes Kubernetes d’une application (déploiements, services, Ingress, ConfigMaps) dans un paquet unique, versionné et paramétrable. helm install déploie un chart avec des valeurs propres à l’environnement. Le dépôt Helm d’Artifact Hub héberge des milliers de charts préconfigurés pour les infrastructures courantes (NGINX, cert-manager, Prometheus, Redis).

# Add the NGINX Ingress Controller chart repo
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Install NGINX Ingress Controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=2

# Install your own app chart with custom values
helm install myapp ./charts/myapp -f values-prod.yaml

Mises à jour progressives et retours arrière

Mettez à jour un déploiement en modifiant la balise de l’image du conteneur : Kubernetes effectue une mise à jour progressive, crée de nouveaux pods avec l’image mise à jour et arrête progressivement les anciens, tout en maintenant l’application disponible. Si la nouvelle version ne fonctionne pas, revenez instantanément à la révision précédente avec kubectl rollout undo. Kubernetes conserve un historique configurable des révisions pour chaque déploiement.

# Update the image to a new version
kubectl set image deployment/myapp \
  myapp=mycontainerregistry.azurecr.io/myapp:v2.0

# Watch the rollout progress
kubectl rollout status deployment/myapp

# View rollout history
kubectl rollout history deployment/myapp

# Rollback to the previous version
kubectl rollout undo deployment/myapp

# Rollback to a specific revision
kubectl rollout undo deployment/myapp --to-revision=2

Autoscaler de cluster

L’Autoscaler de cluster ajoute ou supprime automatiquement des nœuds worker d’un pool de nœuds AKS en fonction des pods en attente de planification et de l’utilisation des nœuds. Lorsque les pods ne peuvent pas être planifiés parce que tous les nœuds sont complets, l’Autoscaler de cluster provisionne de nouveaux nœuds. Lorsque les nœuds sont sous-utilisés et que les pods peuvent être regroupés, il les vide puis les supprime. Cela complète l’Autoscaler horizontal de pods : HPA met les pods à l’échelle, tandis que l’Autoscaler de cluster met les nœuds à l’échelle.

# Enable Cluster Autoscaler on the default node pool
az aks update \
  --name myAKSCluster \
  --resource-group MyRG \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 10

# Update autoscaler bounds on a specific node pool
az aks nodepool update \
  --cluster-name myAKSCluster \
  --resource-group MyRG \
  --name nodepool1 \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 20

Surveiller AKS avec Azure Monitor

Activez Azure Monitor Container Insights pour collecter les journaux et les métriques de votre cluster AKS sans déployer d’outils de surveillance tiers. Container Insights fournit des tableaux de bord prédéfinis sur l’état du cluster, le processeur et la mémoire des nœuds et des pods, les journaux des conteneurs et la diffusion en continu des pods en temps réel. Il s’intègre à Prometheus pour extraire des métriques personnalisées et permet d’interroger toutes les données à l’aide de KQL dans Log Analytics.

# Enable Azure Monitor Container Insights on AKS
az aks enable-addons \
  --addons monitoring \
  --name myAKSCluster \
  --resource-group MyRG \
  --workspace-resource-id /subscriptions/.../workspaces/MyLogAnalytics

# Stream live logs from a running pod
kubectl logs -f deployment/myapp -c myapp

# Query pod resource usage
kubectl top pods --namespace default

RBAC AKS et Azure Active Directory

Intégrez AKS à Microsoft Entra ID pour utiliser les utilisateurs et les groupes Azure AD avec le RBAC Kubernetes. Au lieu de gérer des comptes utilisateur Kubernetes distincts, vous attribuez des liaisons de ClusterRole ou de rôle aux ID d’objet Entra ID. Lorsqu’un développeur exécute kubectl, AKS valide son jeton Entra ID. Cette approche fournit une gestion centralisée des identités et s’intègre aux stratégies d’accès conditionnel et de MFA.

# Enable Entra ID RBAC on an AKS cluster
az aks update \
  --name myAKSCluster \
  --resource-group MyRG \
  --enable-azure-rbac

# Assign a built-in AKS role to an Entra group
az role assignment create \
  --role 'Azure Kubernetes Service RBAC Reader' \
  --assignee '<Entra-Group-Object-ID>' \
  --scope /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.ContainerService/managedClusters/myAKSCluster

Stratégies réseau pour la sécurité au niveau des pods

Les stratégies réseau sont des ressources Kubernetes qui contrôlent les pods pouvant communiquer entre eux. Par défaut, tous les pods d’un cluster peuvent atteindre tous les autres pods : les stratégies réseau fournissent un pare-feu au niveau des pods. Dans AKS, activez la stratégie réseau Azure ou Calico pour appliquer ces stratégies. Un modèle courant consiste à utiliser une stratégie de refus par défaut qui bloque tout le trafic entre les pods, puis à définir explicitement les autorisations pour les chemins précis nécessaires à votre application.

# Default deny all ingress to pods in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}  # Matches all pods
  policyTypes:
  - Ingress

# Allow API pods to receive from frontend pods only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
spec:
  podSelector: {matchLabels: {app: api}}
  ingress:
  - from:
    - podSelector: {matchLabels: {app: frontend}}

Vérification rapide

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

Récapitulatif de la leçon

Dans cette leçon, vous avez appris qu’AKS est un service Kubernetes managé dans lequel Microsoft exploite le plan de contrôle, que les charts Helm empaquettent les applications Kubernetes à ressources multiples pour permettre des déploiements reproductibles, et que l’Autoscaler de cluster ajoute et supprime dynamiquement des nœuds en fonction de la demande de planification des pods. Nous allons maintenant découvrir les déclencheurs et les liaisons d’Azure Functions.

Questions Fréquemment Posées

La leçon « Déploiement de charges de travail sur AKS » est-elle gratuite ?

Oui — le texte complet de « Déploiement de charges de travail sur AKS » 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 « Déploiement de charges de travail sur AKS » ?

Créez un cluster AKS, déployez une application mult Conteneur avec kubectl et des graphiques Helm, puis exposez-la à l’extérieur avec un service Azure Load Balancer. 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 4 sur 4.

Combien de temps prend la leçon « Déploiement de charges de travail sur AKS » ?

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

  1. Azure Container Registry
  2. Azure Container Instances
  3. Concepts Kubernetes pour Azure
  4. Déploiement de charges de travail sur AKS
← Retour à Azure Fundamentals