Cette rubrique décrit les problèmes courants et leurs solutions lors de la création, de l'utilisation et de la gestion des clusters.
Migration de clusters auto-gérés vers ACK
ACK propose une solution de migration permettant de transférer en toute transparence un cluster Kubernetes auto-géré vers un cluster ACK, avec un impact minimal sur vos activités professionnelles. Pour plus d'informations, consultez Présentation des solutions de migration Kubernetes.
Compatibilité des images Alibaba Cloud Linux et CentOS
Oui, elles sont compatibles. Pour plus d'informations, consultez Alibaba Cloud Linux 3.
Modification du runtime de conteneur après la création du cluster
Non, vous ne pouvez pas modifier le runtime de conteneur après la création du cluster. Toutefois, vous pouvez créer des pools de nœuds utilisant différents runtimes. Pour plus d'informations, consultez Créer et gérer un pool de nœuds.
Pour migrer le runtime de conteneur d'un nœud de Docker vers containerd, consultez Migrer le runtime de conteneur d'un nœud de Docker vers containerd.
Docker n'est pas pris en charge en tant que runtime de conteneur intégré dans les clusters exécutant Kubernetes 1.24 ou une version ultérieure. Vous devez utiliser containerd comme runtime pour les pools de nœuds de ces clusters.
Comparaison des runtimes de conteneur
Container Service for Kubernetes prend en charge trois runtimes : containerd, Docker et Sandboxed-Container. Nous vous recommandons d'utiliser le runtime containerd. Le runtime Docker est uniquement pris en charge dans les clusters exécutant Kubernetes 1.22 ou une version antérieure. Le runtime Sandboxed-Container est uniquement pris en charge dans les clusters exécutant Kubernetes 1.24 ou une version antérieure. Pour comparer ces runtimes, consultez Comparaison des runtimes containerd, Sandboxed-Container et Docker. Lors de la mise à niveau d'un cluster ACK vers Kubernetes 1.24 ou une version ultérieure, vous devez migrer le runtime de conteneur des nœuds de Docker vers containerd. Pour plus d'informations, consultez Migrer le runtime de conteneur d'un nœud de Docker vers containerd.
Certification ACK et MLPS 2.0 Niveau 3
Vous pouvez activer le durcissement basé sur MLPS pour votre cluster et configurer des politiques de vérification de référence. Sur la base d'Alibaba Cloud Linux, vous pouvez implémenter MLPS 2.0 Niveau 3 et configurer des vérifications de référence pour la conformité MLPS afin de répondre aux exigences suivantes :
Authentification d'identité
Contrôle d'accès
Audit de sécurité
Prévention des intrusions
Prévention des codes malveillants
Pour plus d'informations, consultez Activer le durcissement basé sur MLPS pour les clusters ACK.
Prise en charge d'ACK et d'Istio
Oui. Vous pouvez utiliser Alibaba Cloud Service Mesh(ASM). ASM est un produit de maillage de services entièrement compatible avec Istio communautaire. Son plan de contrôle entièrement géré vous permet de vous concentrer sur le développement et le déploiement de vos applications métier. ASM est compatible avec divers systèmes d'exploitation de nœuds et plug-ins réseau dans les clusters ACK. Vous pouvez ajouter un cluster ACK existant à une instance ASM et utiliser des fonctionnalités telles que la gestion du trafic, la gestion des pannes, la surveillance unifiée et la gestion des journaux. Pour plus d'informations, consultez Ajouter un cluster à une instance ASM. Pour obtenir des informations sur la facturation d'ASM, consultez Facturation d'ASM.
Collecter les informations de diagnostic
Si un cluster Kubernetes rencontre un problème ou si un nœud est anormal, vous pouvez utiliser la fonction de diagnostic en un clic fournie par ACK pour identifier le problème. Pour plus d'informations, consultez Utiliser les diagnostics de cluster.
Si la fonction de diagnostic de cluster ne répond pas à vos besoins et que vous devez collecter des informations de diagnostic à partir des nœuds master et des nœuds worker anormaux, suivez les étapes des sections suivantes pour collecter les informations depuis des nœuds Linux ou Windows.
Nœud Linux
Les nœuds worker peuvent exécuter Linux ou Windows, mais les nœuds master ne peuvent exécuter que Linux. La méthode suivante s'applique aux nœuds master et worker exécutant Linux. Cet exemple utilise un nœud master.
-
Connectez-vous à un nœud master du cluster Kubernetes et exécutez la commande suivante pour télécharger le script de diagnostic.
curl -o /usr/local/bin/diagnose_k8s.sh http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/diagnose/diagnose_k8s.shRemarqueLe script de diagnostic pour les nœuds Linux ne peut être téléchargé que depuis la région Chine (Hangzhou).
-
Exécutez la commande suivante pour accorder les permissions d'exécution au script de diagnostic :
chmod u+x /usr/local/bin/diagnose_k8s.sh -
Exécutez la commande suivante pour accéder au répertoire spécifié :
cd /usr/local/bin -
Exécutez la commande suivante pour lancer le script de diagnostic :
diagnose_k8s.shLa sortie est similaire à la suivante. Le nom du fichier journal généré varie à chaque exécution du script. Cet exemple utilise diagnose_1514939155.tar.gz.
...... + echo 'please get diagnose_1514939155.tar.gz for diagnostics' please get diagnose_1514939155.tar.gz for diagnostics + echo 'Please upload diagnose_1514939155.tar.gz' Please upload diagnose_1514939155.tar.gz -
Exécutez la commande suivante pour afficher le fichier contenant les informations de diagnostic du cluster :
ls -ltr | grep diagnose_1514939155.tar.gzRemarqueRemplacez diagnose_1514939155.tar.gz par le nom réel du fichier journal dans votre environnement.
Nœud Windows
Pour collecter les informations de diagnostic du cluster à partir d'un nœud worker Windows, téléchargez et exécutez le script de diagnostic.
Windows est pris en charge uniquement pour les nœuds worker.
Connectez-vous au nœud worker anormal et ouvrez un outil de ligne de commande.
-
Exécutez la commande suivante pour passer en mode PowerShell :
powershell -
Exécutez la commande suivante pour télécharger et exécuter le script de diagnostic.
Vous pouvez télécharger le script de diagnostic pour les nœuds Windows depuis la région de votre cluster. Remplacez
[$Region_ID]dans la commande par l'ID de la région de votre cluster.Invoke-WebRequest -UseBasicParsing -Uri http://aliacs-k8s-[$Region_ID].oss-[$Region_ID].aliyuncs.com/public/pkg/windows/diagnose/diagnose.ps1 | Invoke-ExpressionLa sortie suivante indique que les informations de diagnostic ont été collectées avec succès.
INFO: Compressing diagnosis clues ... INFO: ...done INFO: Please get diagnoses_1514939155.zip for diagnosticsRemarqueLe fichier diagnoses_1514939155.zip est enregistré dans le répertoire où le script est exécuté.
Résoudre les problèmes des clusters ACK
Étape 1 : Vérifier les nœuds du cluster
-
Exécutez la commande suivante pour afficher l'état des nœuds du cluster. Vérifiez que tous les nœuds existent et sont dans l'état Ready.
kubectl get nodesLa sortie attendue est similaire à la suivante.
NAME STATUS ROLES AGE VERSION cn-hxxx.20 Ready master 86m v1.18.8-aliyun.1 cn-hxxx.21 Ready master 84m v1.18.8-aliyun.1 cn-hxxx.22 Ready master 81m v1.18.8-aliyun.1 cn-hxxx.23 Ready <none> 78m v1.18.8-aliyun.1 cn-hxxx.24 Ready <none> 78m v1.18.8-aliyun.1 cn-hxxx.25 Ready <none> 78m v1.18.8-aliyun.1 -
Exécutez la commande suivante pour afficher les informations détaillées et les événements d'un nœud.
Remplacez
[$NODE_NAME]par le nom de votre nœud.kubectl describe node [$NODE_NAME]RemarquePour plus d'informations sur la sortie de kubectl, consultez État du nœud.
Étape 2 : Vérifier les composants du cluster
Si vous ne parvenez pas à identifier le problème après avoir vérifié les nœuds du cluster, examinez les journaux des composants du cluster sur le plan de contrôle.
-
Exécutez la commande suivante pour afficher tous les composants dans le namespace kube-system.
kubectl get pods -n kube-systemLa sortie attendue est la suivante.
NAME READY STATUS RESTARTS AGE alicloud-monitor-controller-6fbd5454f9-tvsls 1/1 Running 0 91m aliyun-acr-credential-helper-587bf4b6f8-bq2bg 1/1 Running 0 91m cloud-controller-manager-74q86 1/1 Running 0 91m cloud-controller-manager-sktzk 1/1 Running 0 91m cloud-controller-manager-tkvtz 1/1 Running 0 91m coredns-64d57b9c4b-222pj 1/1 Running 0 91m coredns-64d57b9c4b-fcr8t 1/1 Running 0 91m csi-plugin-5hnn8 4/4 Running 0 91m csi-plugin-6wxtm 4/4 Running 0 91m csi-plugin-jdvg4 4/4 Running 0 91m csi-plugin-njd28 4/4 Running 0 91m csi-plugin-tvf2h 4/4 Running 0 91m csi-plugin-zt76m 4/4 Running 0 91m csi-provisioner-84c4866d86-874wm 7/7 Running 0 91m csi-provisioner-84c4866d86-wvj86 7/7 Running 0 91m ingress-nginx-admission-create-9gnv8 0/1 Completed 0 91m ingress-nginx-admission-patch-wjskw 0/1 Completed 2 91m kube-apiserver-cn-huhehaote.1xxx 0 1/1 Running 0 95m kube-apiserver-cn-huhehaote.1xxx 1 1/1 Running 0 95m kube-apiserver-cn-huhehaote.1xxx 2 1/1 Running 0 95m kube-controller-manager-cn-huhehaote.1xxx 20 1/1 Running 1 100m kube-controller-manager-cn-huhehaote.1xxx 21 1/1 Running 1 97m kube-controller-manager-cn-huhehaote.1xxx 22 1/1 Running 1 91m kube-flannel-ds-b5zt4 1/1 Running 0 91m kube-flannel-ds-blj25 1/1 Running 0 91m kube-flannel-ds-d8v7j 1/1 Running 0 91m kube-flannel-ds-dq6nz 1/1 Running 0 91m kube-flannel-ds-vx97g 1/1 Running 0 91m kube-flannel-ds-wp8cj 1/1 Running 0 91m kube-proxy-master-8kl67 1/1 Running 0 91m kube-proxy-master-mnqmt 1/1 Running 0 91m kube-proxy-master-zfns9 1/1 Running 0 91m kube-proxy-worker-j2gr2 1/1 Running 0 91m kube-proxy-worker-n69x8 1/1 Running 0 91m kube-proxy-worker-qrft5 1/1 Running 0 100m kube-scheduler-cn-huhehaote.1xxx l20 1/1 Running 0 97m kube-scheduler-cn-huhehaote.1xxx l21 1/1 Running 0 97m kube-scheduler-cn-huhehaote.1xxx l22 1/1 Running 0 95m metrics-server-84f55db549-h9n4k 1/1 Running 0 91m nginx-ingress-controller-7474b6cc84-7pk7v 1/1 Running 0 91m nginx-ingress-controller-7474b6cc84-hg8l9 1/1 Running 0 91mLes pods dont le nom commence par
kube-sont des composants système du cluster Kubernetes. Les pods dont le nom commence parcoredns-sont des modules complémentaires DNS. Cette sortie indique que les composants sont dans un état normal. Si un composant est dans un état anormal, passez à l'étape suivante. -
Exécutez la commande suivante pour afficher les journaux du composant anormal afin d'identifier et de résoudre le problème.
Remplacez
[$Component_Name]par le nom du composant anormal.kubectl logs -f [$Component_Name] -n kube-system
Étape 3 : Vérifier le composant kubelet
-
Exécutez la commande suivante pour vérifier l'état de kubelet.
systemctl status kubelet -
Si l'état de kubelet n'est pas
active (running), exécutez la commande suivante pour afficher les journaux de kubelet afin d'identifier et de résoudre le problème.journalctl -u kubelet
Problèmes courants des clusters
Le tableau suivant répertorie certaines causes courantes d'échecs des clusters ACK et leurs solutions.
Problème | Solution |
Le composant API Server ou un composant master s'arrête :
| Les composants ACK intègrent la haute disponibilité. Nous vous recommandons de vérifier si le composant lui-même est anormal. Par exemple, l'API Server d'un cluster ACK utilise par défaut une instance CLB. Vous pouvez résoudre le statut anormal de l'instance CLB. |
Les données backend de l'API Server sont perdues :
| Si vous avez créé un snapshot, vous pouvez restaurer les données à partir du snapshot lorsqu'un problème survient. Si vous n'avez pas créé de snapshot, soumettez un ticket. Une fois le problème résolu, prenez les mesures suivantes pour éviter qu'il ne se reproduise :
|
Un nœud individuel s'arrête et tous les pods sur ce nœud cessent de s'exécuter. | Utilisez une charge de travail telle qu'un Deployment, un StatefulSet ou un DaemonSet pour créer des pods au lieu de créer directement des pods. Cela garantit que des pods de remplacement sont planifiés sur des nœuds sains en cas de défaillance d'un nœud. |
Le composant kubelet échoue :
|
|
Des problèmes sont causés par des configurations manuelles ou d'autres raisons. | Si vous avez créé un snapshot, vous pouvez l'utiliser pour restaurer les données lorsqu'un problème survient. Si vous n'avez pas créé de snapshot, soumettez un ticket pour signaler le problème. Une fois le problème résolu, créez périodiquement des snapshots pour le volume de données utilisé par kubelet. Pour plus d'informations, consultez Créer un snapshot pour un seul volume de disque. |
Configurer une autorisation fine
Par défaut, un utilisateur RAM ou un rôle RAM ne dispose pas des permissions nécessaires pour appeler l'OpenAPI d'un service cloud. Pour utiliser et gérer les clusters ACK, vous devez attribuer la politique système AliyunCSFullAccess ou une politique personnalisée pour Container Service for Kubernetes à l'utilisateur RAM ou au rôle RAM. Pour plus d'informations, consultez Accorder des permissions d'accès aux clusters et aux ressources cloud à l'aide de RAM.
-
Sur la base du mécanisme RBAC de Kubernetes, vous devez utiliser RBAC pour autoriser un utilisateur RAM à gérer les ressources internes du cluster, telles que la création de Deployments et de Services.
Dans les scénarios nécessitant un contrôle fin des permissions de lecture et d'écriture sur les ressources, consultez Utiliser des politiques RBAC personnalisées pour restreindre les opérations sur les ressources d'un cluster afin de configurer des permissions RBAC plus fines à l'aide d'un ClusterRole et d'un Role personnalisés.
Lorsqu'un utilisateur RAM accède à la console, vous devez également configurer les permissions correspondantes du service cloud pour utiliser des fonctionnalités telles que l'affichage des activités de mise à l'échelle des pools de nœuds et des tableaux de bord de surveillance des clusters. Pour plus d'informations, consultez Permissions requises pour la console Container Service for Kubernetes.
Quelles plages d'adresses IP doivent être autorisées pour la politique de contrôle d'accès SLB de l'API Server d'un cluster ?
Les règles de liste de contrôle d'accès (ACL) pour l'instance SLB de l'API Server doivent autoriser les blocs CIDR suivants.
Le bloc CIDR 100.104.0.0/16, réservé au plan de contrôle de Container Service for Kubernetes.
Les blocs CIDR principaux et tout bloc CIDR supplémentaire du Virtual Private Cloud (VPC) du cluster, ou les blocs CIDR des vSwitches où résident les nœuds du cluster.
Les blocs CIDR de sortie des clients qui doivent accéder à l'API server.
Pour les clusters ACK Edge, vous devez également ajouter les blocs CIDR de sortie des nœuds edge.
Pour les clusters ACK Lingjun, vous devez également ajouter les blocs CIDR du Virtual Private Datacenter (VPD) Lingjun.
Pour plus d'informations, consultez Configurer la politique de contrôle d'accès pour l'API Server.
Accéder à un nœud master
Cluster dédié : Pour plus d'informations, consultez Se connecter au nœud master d'un cluster ACK Dedicated via SSH.
Cluster géré : Les nœuds du plan de contrôle d'un cluster géré ACK sont entièrement gérés. Vous ne pouvez pas vous connecter aux terminaux des nœuds du plan de contrôle. Si vous devez vous connecter aux nœuds du plan de contrôle, envisagez d'utiliser un cluster dédié.
Si un nœud master d'un cluster ACK Dedicated est accidentellement supprimé, le cluster peut-il être mis à niveau ?
Non. Après avoir supprimé un nœud master d'un cluster dédié, vous ne pouvez pas ajouter de nœuds master ni mettre à niveau le cluster. Vous pouvez créer un cluster ACK Dedicated (obsolète).
Cluster ACK Dedicated : Peut-on supprimer ou ajouter des nœuds master, et quelles sont les opérations à haut risque ?
Non. L'ajout ou la suppression de nœuds master d'un cluster dédié peut rendre le cluster inutilisable et irrécupérable.
Pour les nœuds master d'un cluster dédié, des opérations incorrectes peuvent rendre les nœuds master, voire l'ensemble du cluster, inutilisables. Les opérations à haut risque incluent le remplacement des certificats master ou etcd, la modification des composants centraux, la suppression ou le formatage des données dans les répertoires centraux tels que /etc/kubernetes sur un nœud, et la réinstallation du système d'exploitation. Pour plus d'informations, consultez Opérations à haut risque liées aux clusters.
Cluster ACK DedicatedAPI Servererreur :api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after xxx. Que faire ?
Symptômes
Lorsque vous créez un pod dans un cluster dédié, l'API Server renvoie une erreur d'expiration de certificat, ou les journaux ou événements du kube-controller-manager affichent une erreur d'expiration de certificat. Le message d'erreur est le suivant.
"https://localhost:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX"https://[::1]:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXXCause
Dans Kubernetes, l'API Server possède un certificat intégré pour son LoopbackClient interne. Dans la version communautaire, ce certificat a une durée de validité de 1 an et ne peut pas être renouvelé automatiquement. Il n'est renouvelé et mis à jour que lorsque le pod API Server redémarre. Si le cluster n'a pas été mis à niveau depuis plus d'un an, le certificat interne expire, ce qui entraîne l'échec des requêtes API. Pour plus d'informations, consultez #86552.
Afin de réduire les risques de stabilité liés à la courte durée de validité des certificats dans la version communautaire, ACK étend la durée de validité par défaut de ce certificat intégré à 10 ans pour les clusters exécutant Kubernetes 1.24 ou une version ultérieure. Pour plus d'informations sur les modifications et leur champ d'impact, consultez Modification du produit : Durée de validité des certificats internes de l'API Server des clusters ACK.
Solution
Vous pouvez vous connecter à un nœud master et exécuter la commande suivante pour interroger l'heure d'expiration du certificat LoopbackClient.
Dans la commande, XX.XX.XX.XX représente l'adresse IP locale du nœud master.
curl --resolve apiserver-loopback-client:6443:XX.XX.XX.XX -k -v https://apiserver-loopback-client:6443/healthz 2>&1 |grep expirePour les clusters dotés de certificats d'un an qui ont expiré ou sont sur le point d'expirer, consultez Mettre à niveau manuellement un cluster ACK pour mettre à niveau le cluster vers la version 1.24 ou ultérieure. Nous vous recommandons de migrer vers une instance ACK Managed Cluster Pro (Migrer à chaud un cluster ACK Dedicated vers une instance ACK Managed Cluster Pro).
-
Pour un cluster dédié qui ne peut pas être mis à niveau à court terme, connectez-vous à chaque nœud master et redémarrez manuellement l'API Server pour générer un nouveau certificat valide.
-
Nœud containerd
crictl pods | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' crictl stopp {} -
Nœud Docker
docker ps | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' docker restart {}
-