Resolve failed cluster checks - Container Service for Kubernetes

ACK propose des vérifications pour les mises à niveau de clusters, les migrations de clusters, 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 obtenez des recommandations de correction pour les éléments ayant échoué.

Vérifications du cluster

Vérifications préalables à la 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 avant le processus. Vous ne pouvez procéder à la mise à niveau que si votre cluster réussit toutes les vérifications. Les éléments contrôlés varient selon le type de cluster, la version de Kubernetes et l'environnement d'exécution des conteneurs. Pour obtenir la liste exhaustive des vérifications applicables à votre cluster, consultez la console ACK.

Les vérifications préalables à la 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 : examine les configurations du cluster ACK, de ses composants et des applications, par exemple si les versions des composants sont conformes aux exigences ou si les applications utilisent des API obsolètes.
Configuration du cluster : contrôle les configurations des nœuds du cluster ACK. Cette vérification crée un Pod sur les nœuds pour collecter les informations nécessaires.

Catégorie	Élément vérifié	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 validée.
	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 comporte 3 ou 5 nœuds maîtres.
	Composants du cluster	Vérifie que la version du composant Terway est conforme aux exigences.
		Vérifie que la version du composant CoreDNS est conforme aux exigences.
		Vérifie que la version du composant cloud-controller-manager est conforme aux exigences.
		Vérifie que la version du composant Nginx Ingress Controller est conforme aux exigences.
		Vérifie que la version du composant ACK Virtual Node est conforme aux exigences.
		Vérifie que la version du composant Metrics Server est conforme aux exigences.
	Nœud	Vérifie que le nœud possède une adresse IP.
		Vérifie que le nœud peut être planifié (schedulable).
		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.
	Environnement d'exécution des conteneurs	Vérifie que l'environnement 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 avant la migration d'un cluster

Avant de procéder à la migration d'un cluster, ACK effectue des vérifications préalables. La migration ne peut être lancée que si l'ensemble des tests est concluant. Cette procédure s'applique aux scénarios suivants :

Migration depuis un ACK dedicated cluster vers un ACK Pro managed cluster.
Migration depuis un ACK managed cluster standard vers un ACK Pro managed cluster.

Les vérifications de migration de cluster sont réparties en quatre catégories :

Ressources du cluster : vérification des ressources cloud associées au cluster ACK, telles que SLB, ECS et VPC.
Composants du cluster : analyse des configurations des composants au sein du cluster ACK, notamment la détection d'éventuels services API indisponibles.
Configuration du cluster : examen de la configuration des nœuds du cluster ACK. Ce test implique le déploiement d'un Pod sur les nœuds afin de collecter les informations nécessaires.
Utilisation des composants : lors de la migration d'un ACK dedicated cluster, certains composants passent sous la gestion d'ACK. Cette étape valide l'état de santé de ces composants avant le basculement.

Catégorie	Élément de vérification	Description
Ressources du cluster	API Server SLB	Vérifie l'existence de l'instance SLB.
		Confirme que l'instance SLB est opérationnelle.
		Valide la configuration correcte de l'écouteur SLB.
		S'assure que le groupe de serveurs principaux (backend) de l'instance SLB est correctement configuré.
		Contrôle la conformité des paramètres de contrôle d'accès SLB. En l'absence de configuration spécifique, le test est considéré comme réussi.
	VPC	Vérifie l'existence de l'instance VPC.
	VPC	Confirme que l'instance VPC est opérationnelle.
	vSwitch	Vérifie l'existence du vSwitch.
		Confirme que le vSwitch est opérationnel.
		S'assure que le vSwitch dispose d'au moins deux adresses IP disponibles.
	ECS	Vérifie l'existence de l'instance ECS.
		Confirme que l'instance ECS est opérationnelle.
		Valide l'état de santé du groupe de sécurité ECS.
		S'assure que le client Cloud Assistant fonctionne correctement.
Composants du cluster	Kube Proxy master	Vérifie l'existence du composant.
	Kube Proxy worker	Vérifie l'existence du composant.
	Service API	Recherche d'éventuels services API indisponibles.
	Instance de cluster	Confirme que le cluster comporte 3 ou 5 nœuds maîtres.
	Nœud	Vérifie que le nœud possède une adresse IP.
		Confirme que le nœud est éligible à la planification (schedulable).
		S'assure que le nœud est dans l'état Ready.
		Valide la compatibilité du système d'exploitation du nœud avec la mise à niveau.
		Vérifie que le nœud dispose de capacité pour plus de deux Pods supplémentaires.
Configuration du cluster	Système d'exploitation	Valide la prise en charge de la mise à niveau par le système d'exploitation.
Configuration du cluster	yum	Vérifie le bon fonctionnement de yum.
Utilisation des composants	cloud-controller-manager	Vérifie que le composant cloud-controller-manager est opérationnel.

Vérifications des composants

Les vérifications des composants s'appliquent aux scénarios de mise à niveau. Avant la mise à niveau d'un composant, ACK exécute des vérifications préalables. La mise à niveau ne peut se poursuivre que si le composant passe toutes les vérifications avec succès.

Catégorie	Élément de vérification	Description
cloud-controller-manager	Addon_CCM	Vérifie si la mise à niveau de ce composant affecte le SLB.
cloud-controller-manager	Component_Block_Version	Vérifie que la version du CCM peut être mise à niveau.
csi-plugin	DaemonSet_Annotation	Vérifie que les annotations du 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 du Deployment correspondent aux paramètres attendus.
	Storage_Class_Attributes	Vérifie que les attributs de 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'erreur 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 des pools de nœuds

Les vérifications des pools de nœuds s'appliquent aux scénarios de mise à niveau d'un pool de nœuds. Lorsque vous mettez à niveau un pool de nœuds, ACK exécute des vérifications préalables. Vous ne pouvez procéder à la mise à niveau du pool de nœuds qu'une fois toutes les vérifications passées avec succès.

Les vérifications des pools 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 l'existence de l'instance SLB.
		Vérifie que l'instance SLB est opérationnelle.
		Vérifie que l'écouteur SLB est configuré correctement.
		Vérifie que le groupe de serveurs backend de l'instance SLB est configuré correctement.
		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 réussit.
	VPC	Vérifie l'existence de l'instance VPC.
	VPC	Vérifie que l'instance VPC est opérationnelle.
	vSwitch	Vérifie l'existence du vSwitch.
		Vérifie que le vSwitch est opérationnel.
		Vérifie que le vSwitch dispose d'au moins deux adresses IP disponibles.
Composants du cluster	Service API	Recherche les services API indisponibles.
	Instance du cluster	Vérifie que le cluster comporte 3 ou 5 nœuds maîtres.
	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 le 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.
	Environnement d'exécution de conteneurs	Vérifie que l'environnement 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 en cas d'échec des vérifications

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.
Le délai d'attente de yum a expiré	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 ce service n'est pas nécessaire, 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 utilisant HostPath	La mise à niveau d'un nœud par remplacement de son disque système peut provoquer 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é-mise à niveau sur un cluster exécutant Kubernetes 1.20 ou une version ultérieure, la vérification 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 détecter toute utilisation d'API obsolète.

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

Les API obsolètes sont classées en quatre types selon la source de la requête (agent utilisateur). Avant de mettre à niveau le cluster, identifiez la source de chaque API obsolète en fonction de 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 ne s'affichent 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 ne s'affichent pas sur la page des API obsolètes. ACK vous guide plutôt pour mettre à niveau ces composants sur la page Modules complémentaires. 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 la rubrique Pourquoi CoreDNS utilise-t-il une API obsolète ? pour obtenir des instructions. La notification d'API obsolète est uniquement informative et n'affecte pas la mise à niveau. Après la mise à niveau, le système remplace les ressources d'API obsolètes par de nouvelles. 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 : Ce type inclut des composants issus de la communauté open source. Décidez de les mettre à niveau en fonction de vos besoins. Remarque La notification d'API obsolète est uniquement informative et n'affecte pas la mise à niveau. Mettez à niveau les composants selon vos besoins pour éviter d'altérer leur fonctionnalité.	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 de mettre à niveau le composant et effectuer la mise à niveau vous-même. Remarque La notification d'API obsolète est uniquement informative et n'affecte pas la mise à niveau. Mettez à niveau les composants selon vos besoins pour éviter d'altérer leur fonctionnalité.	kubectl, agent, Go-http-client, okhttp

Pour afficher les informations sur les API obsolètes :

Sur la page Upgrade Cluster, cliquez sur Precheck, puis cliquez 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. »