Resolve failed cluster checks - Container Service for Kubernetes

ACK propose des vérifications pour les mises à niveau de cluster, les migrations de cluster, les composants et les pools de nœuds. Exécutez une vérification avant ces opérations afin de vous assurer que votre cluster répond aux exigences requises et d'obtenir des recommandations de correction pour les éléments ayant échoué.

Instructions

Vérifications du cluster

Vérifications de mise à niveau du cluster

En raison de la complexité de Kubernetes, la mise à niveau d'un cluster comporte des risques importants. Pour garantir une mise à niveau fluide, ACK exécute une série de vérifications préalables. Vous ne pouvez procéder à la mise à niveau que si votre cluster réussit toutes les vérifications. Les éléments vérifiés varient selon le type de cluster, la version de Kubernetes et le moteur d'exécution de conteneurs. Pour obtenir la liste définitive des vérifications applicables à votre cluster, consultez la console ACK.

Les vérifications de mise à niveau du cluster se répartissent en trois catégories :

Ressources du cluster : vérifie les ressources cloud associées au cluster ACK, telles que SLB, ECS et VPC.
Composants du cluster : vérifie les configurations du cluster ACK, de ses composants et des applications, par exemple si les versions des composants sont conformes aux exigences et si les applications utilisent des API obsolètes.
Configuration du cluster : vérifie les configurations des nœuds du cluster ACK. Cette vérification crée un Pod sur les nœuds pour collecter les informations.

Catégorie	Élément de vérification	Description
Ressources du cluster	API Server SLB	Vérifie que l'instance SLB existe.
		Vérifie que l'instance SLB est saine.
		Vérifie que l'écouteur SLB est correctement configuré.
		Vérifie que le groupe de serveurs backend de l'instance SLB est correctement configuré.
		Vérifie que les paramètres de contrôle d'accès SLB sont corrects. Si aucun contrôle d'accès n'est configuré, cette vérification est réussie.
	VPC	Vérifie que l'instance VPC existe.
	VPC	Vérifie que l'instance VPC est saine.
	vSwitch	Vérifie que le vSwitch existe.
		Vérifie que le vSwitch est sain.
		Vérifie que le vSwitch dispose d'au moins deux adresses IP disponibles.
	ECS	Vérifie que l'instance ECS existe.
		Vérifie que l'instance ECS est saine.
		Vérifie que le groupe de sécurité ECS est sain.
		Vérifie que la période de service ECS est valide.
		Vérifie que le type d'instance ECS répond aux exigences.
		Vérifie que le client Cloud Assistant est sain.
Composants du cluster	Kube Proxy master	Vérifie que le composant existe.
	Kube Proxy worker	Vérifie que le composant existe.
	Service API	Recherche les services API indisponibles.
	Instance de cluster	Vérifie que le cluster compte 3 ou 5 nœuds master.
	Composants du cluster	Vérifie que la version du composant Terway répond aux exigences.
		Vérifie que la version du composant CoreDNS répond aux exigences.
		Vérifie que la version du composant cloud-controller-manager répond aux exigences.
		Vérifie que la version du composant Nginx Ingress Controller répond aux exigences.
		Vérifie que la version du composant ACK Virtual Node répond aux exigences.
		Vérifie que la version du composant Metrics Server répond aux exigences.
	Nœud	Vérifie que le nœud possède une adresse IP.
		Vérifie que le nœud est planifiable.
		Vérifie que le nœud est dans l'état Ready.
		Vérifie que le système d'exploitation du nœud prend en charge la mise à niveau.
		Vérifie que le nœud dispose de plus de deux Pods disponibles.
	API obsolète	Recherche l'utilisation d'API obsolètes dans le cluster.
Configuration du cluster	Configuration iptables	Vérifie que la configuration iptables est correcte.
	Système d'exploitation	Vérifie que le système d'exploitation prend en charge la mise à niveau.
	yum	Vérifie que yum fonctionne correctement.
	Disque	Vérifie que le système de fichiers du nœud est sain.
	Disque	Vérifie que le nœud dispose de plus de 5 % d'espace disque libre.
	Swap	Vérifie si Swap est activé sur le nœud.
	NTP	Vérifie que NTP fonctionne correctement sur le nœud.
	Systemd	Vérifie que la version de Systemd est supérieure à systemd-219-67.
	kubelet	Vérifie que la configuration kubelet correspond aux paramètres attendus.
	Moteur d'exécution de conteneurs	Vérifie que le moteur d'exécution Docker ou containerd est sain.
	Configuration du noyau	Vérifie que la configuration du noyau du nœud est correcte.
	Configuration Manifest	Vérifie que le fichier Manifest correspond aux paramètres attendus.

### Vérifications de migration de cluster Avant une migration de cluster, ACK exécute des vérifications préalables à la migration. La migration ne peut avoir lieu qu'après la réussite de toutes les vérifications. Cela s'applique aux scénarios suivants :

Migration d'un cluster ACK dédié vers un cluster ACK Pro managé.

Migration d'un cluster ACK managé basique vers un cluster ACK Pro managé.

Les vérifications de migration de cluster se répartissent en quatre catégories :

Ressources du cluster : vérifie les ressources cloud associées au cluster ACK, telles que SLB, ECS et VPC.

Composants du cluster : vérifie les configurations des composants dans le cluster ACK, par exemple l'existence éventuelle de services API indisponibles.

Configuration du cluster : vérifie les configurations des nœuds du cluster ACK. Cette vérification crée un Pod sur les nœuds pour collecter les informations.

Utilisation des composants : lors de la migration d'un cluster ACK dédié, certains de ses composants passent sous la gestion d'ACK. Cette vérification confirme que ces composants sont sains avant la migration.

Catégorie	Élément de vérification	Description
Ressources du cluster	API Server SLB	Vérifie que l'instance SLB existe.
		Vérifie que l'instance SLB est saine.
		Vérifie que l'écouteur SLB est correctement configuré.
		Vérifie que le groupe de serveurs backend de l'instance SLB est correctement configuré.
		Vérifie que les paramètres de contrôle d'accès SLB sont corrects. Si aucun contrôle d'accès n'est configuré, cette vérification est réussie.
	VPC	Vérifie que l'instance VPC existe.
	VPC	Vérifie que l'instance VPC est saine.
	vSwitch	Vérifie que le vSwitch existe.
		Vérifie que le vSwitch est sain.
		Vérifie que le vSwitch dispose d'au moins deux adresses IP disponibles.
	ECS	Vérifie que l'instance ECS existe.
		Vérifie que l'instance ECS est saine.
		Vérifie que le groupe de sécurité ECS est sain.
		Vérifie que le client Cloud Assistant est sain.
Composants du cluster	Kube Proxy master	Vérifie que le composant existe.
	Kube Proxy worker	Vérifie que le composant existe.
	Service API	Recherche les services API indisponibles.
	Instance de cluster	Vérifie que le cluster compte 3 ou 5 nœuds master.
	Nœud	Vérifie que le nœud possède une adresse IP.
		Vérifie que le nœud est planifiable.
		Vérifie que le nœud est dans l'état Ready.
		Vérifie que le système d'exploitation du nœud prend en charge la mise à niveau.
		Vérifie que le nœud dispose de plus de deux Pods disponibles.
Configuration du cluster	Système d'exploitation	Vérifie que le système d'exploitation prend en charge la mise à niveau.
Configuration du cluster	yum	Vérifie que yum fonctionne correctement.
Utilisation des composants	cloud-controller-manager	Vérifie que le composant cloud-controller-manager est sain.

Vérifications des composants

Les vérifications des composants s'appliquent aux scénarios de mise à niveau des composants. Avant la mise à niveau d'un composant, ACK exécute des vérifications préalables. La mise à niveau ne peut avoir lieu qu'après la réussite de toutes les vérifications par le composant.

Catégorie	Élément de vérification	Description
cloud-controller-manager	Addon_CCM	Vérifie si la mise à niveau de ce composant affecte SLB.
cloud-controller-manager	Component_Block_Version	Vérifie que la version CCM peut être mise à niveau.
csi-plugin	DaemonSet_Annotation	Vérifie que les annotations DaemonSet correspondent aux paramètres attendus.
	Csi_Driver_Attributes	Vérifie que les attributs du pilote CSI répondent aux exigences.
	Node_Status_Ready	Vérifie que les nœuds du cluster sont dans l'état Ready.
csi-provisioner	Stateful_Set_Exist	Vérifie que le composant est déployé en tant que StatefulSet.
	Deployment_Annotation	Vérifie que les annotations Deployment correspondent aux paramètres attendus.
	Storage_Class_Attributes	Vérifie que les attributs StorageClass répondent aux exigences.
	Csi_Provisioner_Node_Count	Vérifie qu'il existe au moins deux nœuds Ready.
terway-eniip	Systemd	Vérifie que la version de Systemd sur le nœud est supérieure à systemd-219-67.
nginx-ingress-controller	Deployment_Healthy	Vérifie que le Deployment Nginx Ingress Controller est sain.
	Deployment_Not_Under_HPA	Vérifie si un HorizontalPodAutoscaler (HPA) est configuré pour le Deployment.
	Deployment_Not_Modified	Vérifie si le Deployment a été modifié.
	Nginx_Ingress_Pod_Error_Log	Recherche les journaux d'erreurs dans Nginx.
	LoadBalancer_Service_Healthy	Vérifie que le service Nginx est sain.
	Nginx_Ingress_Configuration	Recherche les configurations Ingress incompatibles.
aliyun-acr-credential-helper	RamRole_Exist	Vérifie que le composant dispose du rôle AliyunCSManagedAcrRole.
ack-cost-exporter	RamRole_Exist	Vérifie que le composant dispose du rôle AliyunCSManagedCostRole.

Vérifications du pool de nœuds

Les vérifications du pool de nœuds s'appliquent aux scénarios de mise à niveau des pools de nœuds. Lors de la mise à niveau d'un pool de nœuds, ACK exécute des vérifications préalables. Vous ne pouvez mettre à niveau le pool de nœuds qu'après la réussite de toutes les vérifications.

Les vérifications du pool de nœuds se répartissent en trois catégories :

Ressources du cluster : vérifie les ressources cloud associées au cluster ACK, telles que SLB et VPC.
Composants du cluster : vérifie les configurations du cluster ACK, des nœuds et des applications.
Configuration du cluster : vérifie les configurations des nœuds du cluster ACK. Cette vérification crée un Pod sur les nœuds pour collecter les informations.

Catégorie	Élément de vérification	Description
Ressources du cluster	API Server SLB	Vérifie que l'instance SLB existe.
		Vérifie que l'instance SLB est saine.
		Vérifie que l'écouteur SLB est correctement configuré.
		Vérifie que le groupe de serveurs backend de l'instance SLB est correctement configuré.
		Vérifie que les paramètres de contrôle d'accès SLB sont corrects. Si aucun contrôle d'accès n'est configuré, cette vérification est réussie.
	VPC	Vérifie que l'instance VPC existe.
	VPC	Vérifie que l'instance VPC est saine.
	vSwitch	Vérifie que le vSwitch existe.
		Vérifie que le vSwitch est sain.
		Vérifie que le vSwitch dispose d'au moins deux adresses IP disponibles.
Composants du cluster	Service API	Recherche les services API indisponibles.
	Instance de cluster	Vérifie que le cluster compte 3 ou 5 nœuds master.
	Nœud	Vérifie que le nœud est dans l'état Ready.
	Nœud	Vérifie que le nœud dispose de plus de deux Pods disponibles.
	HostPath	Vérifie si des Pods sur le nœud utilisent des volumes HostPath.
Configuration du cluster	Configuration iptables	Vérifie que la configuration iptables est correcte.
	Système d'exploitation	Vérifie que le système d'exploitation prend en charge la mise à niveau.
	yum	Vérifie que yum fonctionne correctement.
	Disque	Vérifie que le système de fichiers du nœud est sain.
	Espace disque restant sur le nœud	Vérifie que le nœud dispose de plus de 5 % d'espace disque libre.
	Swap	Vérifie si Swap est activé sur le nœud.
	NTP	Vérifie que NTP fonctionne correctement sur le nœud.
	Systemd	Vérifie que la version de Systemd est supérieure à systemd-219-67.
	kubelet	Vérifie que la configuration kubelet correspond aux paramètres attendus.
	Moteur d'exécution de conteneurs	Vérifie que le moteur d'exécution Docker ou containerd est sain.
	Configuration du noyau	Vérifie que la configuration du noyau du nœud est correcte.
	Configuration Manifest	Vérifie que le fichier Manifest correspond aux paramètres attendus.

Solutions pour les vérifications ayant échoué

Vérification ayant échoué	Solution
La version de systemd est trop ancienne	Mettez à niveau la version de systemd.
La version du composant est trop ancienne	Mettez à niveau la version du composant. Pour plus d'informations, consultez la rubrique Gérer les composants.
Délai dépassé lors de la vérification yum	Exécutez la commande suivante pour vérifier les délais d'expiration de yum. Le délai par défaut est de 10 secondes. `time if type yum&>/dev/null; then yum list yum; fi`
Le service API n'est pas disponible	Exécutez la commande suivante pour identifier les services API indisponibles. `kubectl -n kube-system get apiservices \|grep -i false` Confirmez l'utilité du service API indisponible. Si le service n'est pas requis, exécutez la commande suivante pour le supprimer. Important La suppression d'un service API requis peut entraîner un dysfonctionnement du cluster. Si vous n'êtes pas certain de l'utilité du service API indisponible, contactez le support technique. `kubectl -n kube-system delete apiservices ${your-abnormal-apiservice-name}`
Un nœud contient des pods qui utilisent HostPath	La mise à niveau d'un nœud par remplacement de son disque système peut entraîner une perte de données pour les pods qui montent un répertoire hôte via HostPath. Vérifiez le répertoire monté de chaque pod concerné. S'il n'y a aucun impact, vous pouvez procéder à la mise à niveau. Cette vérification est purement informative et ne bloque pas la mise à niveau.
Le cluster utilise des API obsolètes	Identifiez les sources des API obsolètes et prenez les mesures appropriées. Pour plus d'informations, consultez la section API obsolètes.

API obsolètes

Lorsque vous exécutez une vérification préalable à la mise à niveau sur un cluster exécutant Kubernetes 1.20 ou une version ultérieure, le système détecte toute utilisation d'API obsolète. Les résultats de la vérification répertorient ces API.

Par exemple, lors de la mise à niveau d'un cluster de Kubernetes 1.20 vers Kubernetes 1.22, le système analyse les journaux d'audit de la veille pour identifier toute utilisation d'API obsolète.

Si le cluster utilise une API obsolète, le résultat de la vérification constitue une simple notification et ne bloque pas la mise à niveau.
Le maintien de l'utilisation d'une API obsolète dans Kubernetes 1.22 peut introduire des risques de sécurité. Vous devez évaluer l'impact sur votre activité.

Les API obsolètes sont classées en quatre catégories selon la source de la requête (agent utilisateur). Avant de mettre à niveau le cluster, identifiez la source de chaque API obsolète en vous basant sur sa Category dans le tableau suivant et appliquez l'action recommandée.

Type	Action recommandée	Exemple
core	Composants principaux de Kubernetes : ACK met automatiquement à niveau ces composants lors de la mise à niveau du cluster. Ils n'apparaissent pas sur la page de vérification et aucune action n'est requise.	kube-apiserver, kube-scheduler, kube-controller-manager
ack	Composants ACK : ces composants sont fournis par ACK et n'apparaissent pas sur la page des API obsolètes. ACK vous guide plutôt pour mettre à niveau ces composants via la page Add-ons. Remarque Dans la console ACK, accédez à Operations > Add-ons pour mettre à niveau les composants. Les informations relatives aux API obsolètes disparaissent le lendemain de la mise à niveau des composants. Dans certains cas, le composant CoreDNS peut utiliser une API obsolète dans un cluster Kubernetes de version 1.24 ou ultérieure. Si le résultat de la vérification inclut coredns, consultez Pourquoi CoreDNS utilise-t-il une API obsolète ? pour obtenir des instructions. La notification d'API obsolète est purement informative et n'affecte pas la mise à niveau. Après celle-ci, le système remplace les ressources utilisant des API obsolètes par de nouvelles versions. Nous vous recommandons d'éviter de créer des ressources avec des API obsolètes afin de prévenir les risques de sécurité.	metrics-server, nginx-ingress-controller, CoreDNS
opensource	Composants open source : cette catégorie inclut les composants issus de la communauté open source. Décidez de leur mise à niveau en fonction de vos besoins. Remarque La notification d'API obsolète est purement informative et n'affecte pas la mise à niveau. Mettez à niveau les composants selon vos besoins pour éviter d'altérer leurs fonctionnalités.	rancher, elasticsearch-operator, etc.
unknown	Source inconnue : les sources qui ne correspondent pas aux types précédents sont marquées comme inconnues. Vous devez décider vous-même de la mise à niveau du composant et l'effectuer. Remarque La notification d'API obsolète est purement informative et n'affecte pas la mise à niveau. Mettez à niveau les composants selon vos besoins pour éviter d'altérer leurs fonctionnalités.	kubectl, agent, Go-http-client, okhttp

Pour consulter les informations sur les API obsolètes :

Sur la page Upgrade Cluster, cliquez sur Precheck, puis sur View Details.
Sur la page Report, cliquez sur View Details.
La page de détails affiche l'API obsolète, l'agent utilisateur, le type, la version Kubernetes obsolète, la dernière heure d'accès et l'adresse IP source.

La page Report contient trois onglets : Cluster Resources, Cluster Components et Node Configuration. L'onglet Node Configuration inclut un avertissement indiquant : « The cluster is still using a deprecated Kubernetes API. »