Présentation du contrôle de version des composants AKS

Azure Kubernetes Service (AKS) gère plusieurs composants qui suivent différentes stratégies de contrôle de version et de mise à jour corrective. Comprendre comment ces composants sont versionnés vous aide à planifier les mises à niveau, à suivre les correctifs de sécurité et à gérer efficacement le cycle de vie de votre cluster.

Cet article explique l’approche de contrôle de version pour différentes catégories de composants AKS et la façon dont ils sont conservés au fil du temps.

Vue d’ensemble des composants AKS

Diagramme de différents composants AKS : plan de contrôle, images de nœud et fonctionnalités AKS, extensions, modules complémentaires déployés en tant que charges de travail sur les nœuds

AKS se compose de plusieurs composants, chacun avec des modèles de contrôle de version distincts :

  • Plan de contrôle de cluster Kubernetes hébergé par AKS : serveur d’API Kubernetes managé, etcd, et d’autres composants du plan de contrôle de cluster.

  • Images de nœuds : système d’exploitation, environnement d'exécution de conteneur et composants de nœud Kubernetes principaux. Pour plus d’informations sur les composants empaquetés dans les images de nœud, consultez le dossier de notes Disque dur virtuel (VHD) sous le référentiel AKS GitHub.

  • Charges de travail : les fonctionnalités gérées par AKS/les modules complémentaires/extensions peuvent avoir des composants dans l’un des deux compartiments suivants :

    • Pods de module complémentaire/fonctionnalités/extension autonomes : fonctionnalités/modules complémentaires/extensions AKS exécutant des pods autonomes (à partir de Déploiements ou DaemonSets) sur les nœuds hébergés par le client (à gauche). istiod, azure-cns et coredns en sont des exemples.
    • Composants AKS à l’intérieur des pods de charge de travail client : certaines fonctionnalités/modules complémentaires/extensions AKS peuvent avoir des sidecars s’exécutant à l’intérieur des pods de l’utilisateur (à droite). Par exemple, Istio injecte des proxies sidecar aux pods de charge de travail des utilisateurs.

    Le tableau suivant résume la façon dont le contrôle de version et les mises à jour sont gérés pour chaque catégorie de composant AKS :

Plan de contrôle Images de noeuds Modules complémentaires/fonctionnalités/pods d’extension autonomes Composants AKS à l’intérieur des pods de charge de travail client
Qu’est-ce qui est versionné ? Serveur d’API Kubernetes, etcd, contrôleurs Système d’exploitation, runtime de conteneur et composants de nœud Kubernetes principaux Fonctionnalités/modules complémentaires/extensions AKS exécutant des pods autonomes (par exemple : istiod) Sidecars ou conteneurs auxiliaires injectés par des modules complémentaires/extensions
Modèle de contrôle de version Suit la version sémantique Kubernetes d'origine (MAJOR.MINOR.PATCH). AKS offre des modèles de support à long terme (LTS) et de communauté. Pour plus d’informations, consultez la documentation relative à la stratégie de prise en charge des versions AKS Les versions d'image de nœud ainsi que les notes VHD publiées avec les versions AKS. Version mineure de module complémentaire/fonctionnalité/extension liée à une version mineure d'AKS selon un ratio de 1:1 La version sidecar doit être compatible avec le plan de contrôle du module complémentaire
Méthode de mise à jour Le client a le contrôle sur la version de MAJOR.MINOR.PATCH à mettre à niveau. Manuel (az aks upgrade) ou automatique à l’aide de canaux de mise à niveau automatique Le client peut effectuer une mise à niveau vers la dernière version d’image de nœud prise en charge. Manuel (az aks nodepool upgrade) ou automatique à l’aide de canaux de mise à niveau automatique - Version mineure mise à niveau lorsque la version mineure du plan de contrôle est mise à niveau (à l’exception d’Istio ; consultez la documentation sur la mise à niveau d’Istio)
- Version de correctif mise à niveau automatiquement par les mises à jour AKS		 Le client doit manuellement mettre à jour (relancer les charges de travail ayant des sidecars) vers des versions sidecar compatibles, comme documenté par le module complémentaire/fonctionnalité/extension.

Meilleures pratiques de gestion des versions

Considérations de sécurité : activez les mises à jour automatiques des correctifs pour vous assurer que les correctifs de sécurité sont appliqués dès que possible. Choisissez le canal de mise à niveau automatique qui correspond le mieux aux exigences et à la tolérance de risque de votre cluster. Manuel ou automatique : choisissez la stratégie de mise à jour qui répond le mieux à vos besoins opérationnels. Les mises à jour automatiques fournissent des correctifs de sécurité en temps opportun et réduisent la surcharge opérationnelle, tandis que les mises à jour manuelles offrent un contrôle précis sur le minutage et la gestion des changements. Utilisez des fenêtres de maintenance planifiée pour contrôler le moment où les mises à niveau automatiques sont appliquées, ce qui garantit que les mises à jour se produisent pendant les périodes approuvées pour votre cluster. Surveillez et préparez les modifications : restez informé des mises à jour et de la disponibilité à venir des nouvelles versions à l’aide des notes de publication AKS et du suivi des versions AKS. Validez les mises à niveau dans les environnements hors production avant de mettre à niveau les environnements de production.

  • Pour les clusters de production :
    • Envisagez les mises à jour automatiques pour des correctifs de sécurité rapides
    • Choisir entre les mises à niveau automatiques ou manuelles de versions mineures en fonction de vos besoins opérationnels
    • Tester toutes les modifications dans les environnements intermédiaires en premier
  • Pour les clusters de développement :
    • Activer les mises à jour automatiques pour les pools de plans de contrôle et de nœuds afin de rester à jour avec les dernières fonctionnalités
    • Choisissez les canaux appropriés en fonction de vos besoins de développement et de test (consultez mises à niveau automatiques des clusters et mise à niveau automatique de l’image de nœud pour les options de canal)
    • Utiliser comme terrain de test pour les stratégies de mise à jour de production
  • Changements cassants : surveillez l'outil de suivi des versions AKS et passez en revue les stratégies de dépréciation de Kubernetes pour rester informé des dépréciations des API et des modifications majeures dans AKS et Kubernetes en amont.
  • Validation de la pré-mise à niveau : avant de mettre à niveau vos clusters de production, testez vos applications, vos ressources personnalisées et vos intégrations tierces sur des clusters de préproduction pour garantir la compatibilité avec la nouvelle version de Kubernetes et les composants AKS mis à jour.

Afficher les versions des composants AKS à l’aide d’AKS Component Insights (préversion)

AKS Component Insights (Preview) fournit une visibilité détaillée des versions exactes de tous les composants s’exécutant dans votre cluster Azure Kubernetes Service. Cette fonctionnalité vous permet de comprendre l’état actuel de votre cluster, de planifier les mises à niveau et d’identifier les problèmes de compatibilité potentiels.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Conditions préalables

  • Un compte Azure avec un abonnement actif. Si vous n’en avez pas, vous pouvez créer un compte gratuitement.
  • Un cluster AKS configuré dans votre environnement de Azure
Prérequis Remarques
Azure CLI 2.74.0 ou version ultérieure installée. Pour connaître la version, exécutez az --version. Si vous devez installer ou mettre à niveau, consultez Installer Azure CLI.
Azure CLI aks-preview extension 18.0.0b19 ou une version ultérieure. Pour connaître la version, exécutez az --version. Si vous devez installer ou mettre à niveau, consultez Manage Azure CLI extensions.

Vous pouvez installer ou mettre à jour vers la dernière extension aks-preview Azure CLI disponible à l’aide des commandes suivantes :

# Install the aks-preview extension
az extension add --name aks-preview

# Update to the latest version if already installed
az extension update --name aks-preview

Afficher les versions des composants à l’aide de Azure CLI

Utilisez la az aks get-upgrades commande pour afficher les versions des composants :

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

Les informations de composant sont retournées dans la componentsByReleases section. La sortie attendue serait similaire à ce qui suit (seule une partie de componentByReleases est indiquée ici pour la concision) :

{
  "componentsByReleases": [
      {
        "components": [
          {
            "hasBreakingChanges": false,
            "name": "cloud-provider-node-manager-linux",
            "version": "v1.32.5"
          },
          {
            "hasBreakingChanges": false,
            "name": "cloud-provider-node-manager-windows",
            "version": "v1.32.5"
          },
          {
            "hasBreakingChanges": false,
            "name": "health-probe-proxy",
            "version": "v1.29.1"
          },
          {
            "hasBreakingChanges": false,
            "name": "kubelet-serving-csr-approver",
            "version": "v0.0.7"
          },
          {
            "hasBreakingChanges": false,
            "name": "coredns",
            "version": "v1.11.3-8"
          },
          {
            "hasBreakingChanges": false,
            "name": "metrics-server",
            "version": "v0.7.2-7"
          }
        ],
        "kubernetesVersion": "1.32"
      }
  ]
}

Les composants réels affichés peuvent varier en fonction de la configuration de votre cluster, des modules complémentaires activés et de la version de Kubernetes. Utilisez la az aks get-upgrades commande pour afficher la liste complète des composants de votre cluster spécifique.

Chaque entrée de composant inclut :

  • nom : identificateur du composant
  • version : version exacte du composant installé sur le cluster
  • hasBreakingChanges : indique si cette version du composant introduit des changements cassants

Conseil / Astuce

Outre l’utilisation de l’Azure CLI pour interroger les informations de version du composant, vous pouvez également utiliser le GET upgradeProfiles API avec les API AKS en préversion (2025-05-04-preview ou version ultérieure) pour récupérer des données détaillées de version de composant par programme.

Étapes suivantes

  • Dernière mise à jour :