Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : ✔️ AKS Automatic ✔️ AKS Standard
Cet article montre comment Azure Kubernetes Service (AKS) pouvez bloquer automatiquement les mises à niveau de cluster lorsqu’elle détecte l’utilisation déconseillée de l’API Kubernetes.
Pour la plupart des charges de travail de production, AKS Automatic est l’option par défaut recommandée et prête pour la production pour AKS. La détection des changements avec rupture de compatibilité de l’API Kubernetes est préconfigurée sur les clusters AKS Automatic et AKS Standard.
Comportement dans AKS Automatic et AKS Standard
Les deux modes de cluster incluent cette protection :
- AKS Automatic: inclus par défaut dans le cadre des mécanismes de protection de la plateforme AKS Automatic prête pour la production.
- AKS Standard : inclus par défaut sur les clusters AKS Standard.
Dans les deux modes, AKS peut bloquer les opérations de mise à niveau de version mineure lorsqu’il détecte l’utilisation récente des API déconseillées ou supprimées dans la version de Kubernetes cible.
Vue d’ensemble
Pour rester dans une version de Kubernetes prise en charge, vous devez mettre à niveau votre cluster au moins une fois par an et préparer les interruptions possibles. Ces perturbations peuvent inclure des modifications avec rupture de compatibilité de l’API, des dépréciations et des dépendances telles que Helm et Container Storage Interface (CSI). Il peut être difficile d’anticiper ces interruptions et de migrer des charges de travail critiques sans temps d’arrêt.
Quand AKS détecte l’utilisation déconseillée de l’API pour la version cible, elle peut bloquer automatiquement les opérations de mise à niveau des versions mineures et vous avertir du problème. Ce comportement vous permet d’éviter des interruptions inattendues et vous donne le temps de corriger l’utilisation déconseillée de l’API avant de poursuivre la mise à niveau.
Prerequisites
Vérifiez que vous remplissez les conditions préalables suivantes :
- L’opération de mise à niveau correspond à un changement vers une version mineure de Kubernetes du plan de contrôle du cluster.
- La version cible Kubernetes est 1.26 ou ultérieure.
- La dernière utilisation des API déconseillées pour la version cible s’est produite dans les 12 heures avant l’opération de mise à niveau. AKS enregistre l’utilisation chaque heure. Par conséquent, l’utilisation au cours de la dernière heure n’est pas garantie de figurer dans la détection.
Remarque
Vous n’avez pas besoin d’activer manuellement cette fonctionnalité de détection. Les clusters AKS Automatic et AKS Standard le préconfigurent.
Réduire les effets des opérations de mise à niveau interrompues
Si vous remplissez les conditions préalables, essayez une mise à niveau et recevez une erreur similaire au message d’erreur suivant :
Bad Request({
"code": "ValidationError",
"message": "Control Plane upgrade is blocked due to recent usage of a Kubernetes API deprecated in the specified version. Please refer to https://kubernetes.io/docs/reference/using-api/deprecation-guide to migrate the usage. To bypass this error, set enable-force-upgrade in upgradeSettings.overrideSettings. Bypassing this error without migrating usage will result in the deprecated Kubernetes API calls failing. Usage details: 1 error occurred:\n\t* usage has been detected on API flowcontrol.apiserver.k8s.io.prioritylevelconfigurations.v1beta1, and was recently seen at: 2023-03-23 20:57:18 +0000 UTC, which will be removed in 1.26\n\n",
"subcode": "UpgradeBlockedOnDeprecatedAPIUsage"
})
Utilisez l’une des options suivantes :
- Supprimer l’utilisation des API déconseillées (recommandé)
- Ignorez la validation pour ignorer les modifications de l’API.
Supprimer l’utilisation des API dépréciées (recommandé)
Dans le portail Azure, accédez à votre ressource de cluster et sélectionnez Diagnostiquer et résoudre les problèmes.
Sélectionnez Créer, mettre à niveau, supprimer et redimensionner>Dépréciations de l’API Kubernetes.
Attendez 12 heures à compter du moment où la dernière utilisation d’une API obsolète a été constatée. Les verbes en lecture seule sont exclus de l’utilisation déconseillée de l’API, à savoir Get/List/Watch. Vous pouvez également vérifier l’utilisation de l’API passée en activant Container Insights et en explorant les journaux d’audit kube.
Réessayez la mise à niveau de votre cluster.
Contourner une validation pour ignorer les modifications de l’API
Remarque
Cette méthode nécessite Azure CLI version 2.57 ou ultérieure. Si l’extension CLI en préversion est installée, mettez à jour vers la version 3.0.0b10 ou ultérieure. Cette méthode n’est pas recommandée pour les opérations de production normales, car les API déconseillées dans la version de Kubernetes cible peuvent échouer à long terme. Supprimez l’utilisation déconseillée de l’API dès que possible après la mise à niveau.
Effectuez la mise à niveau en contournant la validation à l’aide de la commande az aks upgrade avec --enable-force-upgrade et définissez --upgrade-override-until pour définir la fin de la fenêtre de contournement. Si vous ne définissez pas de valeur, la fenêtre est définie par défaut sur trois jours à partir de l’heure actuelle. La date et l’heure fournies doivent être ultérieures à la date et à l’heure actuelles.
# Set environment variables
RESOURCE_GROUP_NAME=<your-resource-group-name>
CLUSTER_NAME=<your-cluster-name>
KUBERNETES_VERSION=<target-kubernetes-version>
# Run the upgrade command with validation bypass
az aks upgrade --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP_NAME --kubernetes-version $KUBERNETES_VERSION --enable-force-upgrade --upgrade-override-until 2023-10-01T13:00:00Z
Remarque
Z est l’indicateur de zone pour le décalage UTC/GMT zéro, également appelé heure « Zulu ». Cet exemple montre comment définir la fin de la fenêtre sur 13:00:00 GMT. Pour plus d’informations, consultez Représentations de date et d’heure combinées.
Considérations relatives à la production
Pour les charges de travail de production, suivez ces pratiques :
- Traitez le blocage de mise à niveau comme un mécanisme de sécurité, et non comme un état d’échec.
- Préférer la migration d’API par rapport au contournement forcé.
- Utilisez les fenêtres de maintenance planifiée et les vérifications de pré-mise à niveau.
- Surveillez en permanence l’utilisation de l’API déconseillée pour éviter les blocs de mise à niveau de dernière minute.
Contenu connexe
Cet article vous a montré comment interrompre automatiquement les mises à niveau du cluster AKS en cas de modifications incompatibles de l’API. Si vous souhaitez obtenir plus d’informations sur les options de mise à niveau des clusters AKS, voir Options de mise à niveau des clusters Azure Kubernetes Service (AKS).
Pour en savoir plus sur AKS Automatic, consultez les articles suivants :