Mise en réseau |
1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100 |
L'entrée groupée n'est pas compatible avec les ressources gateway.networking.k8s.io
Les pods Istiod de l'entrée groupée ne peuvent pas être prêts si des ressources gateway.networking.k8s.io sont installées dans le cluster d'utilisateur. L'exemple de message d'erreur suivant peut s'afficher dans les journaux du pod:
failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"
Solution :
Appliquez les ClusterRole et ClusterRoleBinding suivants à votre cluster d'utilisateurs:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: istiod-gateway
rules:
- apiGroups:
- 'gateway.networking.k8s.io'
resources:
- '*'
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: istiod-gateway-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: istiod-gateway
subjects:
- kind: ServiceAccount
name: istiod-service-account
namespace: gke-system
|
Installation |
1.29.0-1.29.1000 1.30.0-1.30.500, 1.31.0-1.31.100 |
Les nœuds du plan de contrôle du cluster d'administrateur continuent de redémarrer après l'exécution de gkectl create admin
Si les noms d'hôte du champ ipblocks contiennent des lettres majuscules, les nœuds du plan de contrôle du cluster d'administrateur peuvent redémarrer de manière répétée.
Solution :
N'utilisez que des noms d'hôte en minuscules.
|
Installation, mises à niveau |
1.30.0-1.30.500, 1.31.0-1.31.100 |
"Erreur" Runtime: out of memory après l'exécution de gkeadm create ou upgrade
Lorsque vous créez ou mettez à niveau des postes de travail administrateur avec les commandes gkeadm , une erreur OOM peut s'afficher lors de la vérification de l'image de l'OS téléchargée.
Par exemple,
Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...
[==================================================>] 10.7GB/10.7GB
Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova
Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|
runtime: out of memory
Solution :
Augmentez la taille de la mémoire de l'OS où vous exécutez la commande gkeadm .
|
Mises à niveau |
1.30.0-1.30.400 |
Mise à niveau du cluster d'administrateur non HD bloquée à Creating or updating cluster control plane workloads
Lors de la mise à niveau d'un cluster d'administrateur non haute disponibilité, la mise à niveau peut rester bloquée à l'étape Creating or updating cluster control plane workloads .
Ce problème se produit si, dans la VM maître administrateur, ip a | grep cali renvoie un résultat non vide.
Par exemple,
ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3: mtu 1500 qdisc noqueue state UP group default
Solution :
- Réparez le maître administrateur:
gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
--config=ADMIN_CONFIG_FILE \
--skip-validation
- Sélectionnez le modèle de VM 1.30 si une invite semblable à l'exemple suivant s'affiche:
Please select the control plane VM template to be used for re-creating the
admin cluster's control plane VM.
- Reprendre la mise à niveau:
gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
--config ADMIN_CONFIG_FILE
|
Configuration |
1.31.0 |
Champ isControlPlane redondant dans le fichier de configuration du cluster sous network.controlPlaneIPBlock
Les fichiers de configuration de cluster générés par gkectl create-config dans la version 1.31.0 contiennent un champ isControlPlane redondant sous network.controlPlaneIPBlock :
controlPlaneIPBlock:
netmask: ""
gateway: ""
ips:
- ip: ""
hostname: ""
isControlPlane: false
- ip: ""
hostname: ""
isControlPlane: false
- ip: ""
hostname: ""
isControlPlane: false
Ce champ n'est pas nécessaire et peut être supprimé en toute sécurité du fichier de configuration.
|
Migration |
1.29.0-1.29.800, 1.30.0-1.30.400, 1.31.0 |
Nœuds de modules complémentaires d'administrateur bloqués sur "NotReady" lors de la migration d'un cluster d'administrateur standard vers un cluster d'administrateur haute disponibilité
Lorsque vous migrez un cluster d'administrateur non HD qui utilise MetalLB vers un cluster HD, les nœuds de modules complémentaires d'administrateur peuvent rester bloqués à l'état NotReady , ce qui empêche la migration de se terminer.
Ce problème ne concerne que les clusters d'administrateur configurés avec MetalLB, où la réparation automatique n'est pas activée.
Ce problème est causé par une condition de course lors de la migration, où les diffuseurs MetalLB utilisent toujours l'ancien secret metallb-memberlist . En raison de la condition de course, l'ancienne adresse IP virtuelle du plan de contrôle devient inaccessible, ce qui entraîne l'arrêt de la migration.
Solution :
- Supprimez le secret
metallb-memberlist existant:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
delete secret metallb-memberlist
- Redémarrez le déploiement
metallb-controller pour qu'il puisse générer le nouveau metallb-memberlist :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
rollout restart deployment metallb-controller
- Assurez-vous que le nouveau
metallb-memberlist est généré:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
get secret metallb-memberlist
- Remplacez
updateStrategy.rollingUpdate.maxUnavailable dans le DaemonSet metallb-speaker de 1 par 100% .
Cette étape est obligatoire, car certains pods DaemonSet s'exécutent sur les nœuds NotReady .
kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
edit daemonset metallb-speaker
- Redémarrez le DaemonSet
metallb-speaker pour qu'il récupère la nouvelle liste de membres:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
rollout restart daemonset metallb-speaker
Au bout de quelques minutes, les nœuds de modules complémentaires d'administration redeviennent Ready et la migration peut continuer.
- Si la commande
gkectl initiale a expiré au bout de plus de trois heures, exécutez à nouveau gkectl update pour reprendre la migration ayant échoué.
|
Configuration, fonctionnement |
1.12+, 1.13+, 1.14+, 1.15+, 1.16+, 1.28+, 1.29+, 1.30+ |
Échec de la sauvegarde de cluster pour un cluster d'administrateur non haute disponibilité en raison de noms de datastore et de disque de données longs
Lorsque vous tentez de sauvegarder un cluster d'administrateur non haute disponibilité, la sauvegarde échoue, car la longueur combinée des noms du datastore et du disque de données dépasse la longueur maximale de caractères.
La longueur maximale d'un nom de datastore est de 80 caractères. Le chemin d'accès à la sauvegarde d'un cluster d'administrateur non haute disponibilité suit la syntaxe __. Par conséquent, si le nom concaténé dépasse la longueur maximale, la création du dossier de sauvegarde échouera.
Solution :
Renommez le datastore ou le disque de données avec un nom plus court. Vérifiez que la longueur combinée des noms du datastore et du disque de données ne dépasse pas la longueur maximale de caractères.
|
Mises à niveau |
1.28, 1.29, 1.30 |
Le nœud du plan de contrôle d'administrateur HA affiche une ancienne version après l'exécution de gkectl repair admin-master
Après l'exécution de la commande gkectl repair admin-master , un nœud de plan de contrôle d'administrateur peut afficher une version antérieure à celle attendue.
Ce problème se produit, car le modèle de VM sauvegardé utilisé pour la réparation du nœud du plan de contrôle administrateur de l'HA n'est pas actualisé dans vCenter après une mise à niveau, car le modèle de VM de sauvegarde n'a pas été cloné lors de la création de la machine si le nom de la machine reste inchangé.
Solution :
- Identifiez le nom de la machine qui utilise l'ancienne version de Kubernetes:
kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
- Supprimez l'annotation
onprem.cluster.gke.io/prevented-deletion :
kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
Enregistrez la modification.
- Exécutez la commande suivante pour supprimer la machine:
kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
Une nouvelle machine sera créée avec la version correcte.
|
Configuration |
1.30.0 |
Lors de la mise à jour d'un cluster d'utilisateur ou d'un pool de nœuds à l'aide de Terraform, Terraform peut tenter de définir des valeurs vides pour les champs vCenter .
Ce problème peut se produire si le cluster n'a pas été créé à l'origine à l'aide de Terraform.
Solution :
Pour éviter la mise à jour inattendue, assurez-vous qu'elle est sécurisée avant d'exécuter terraform apply , comme décrit ci-dessous:
- Exécuter
terraform plan
- Dans la sortie, vérifiez si les champs
vCenter sont définis sur nil .
- Si un champ
vCenter est défini sur une valeur vide, dans la configuration Terraform, ajoutez vcenter à la liste ignore_changes en suivant la
documentation Terraform. Cela empêche la mise à jour de ces champs.
- Exécutez à nouveau
terraform plan et vérifiez la sortie pour vous assurer que la mise à jour est conforme à vos attentes.
|
Mises à jour |
1.13, 1.14, 1.15, 1.16 |
Les nœuds du plan de contrôle du cluster utilisateur sont toujours redémarrés lors de la première opération de mise à jour du cluster d'administrateur.
Une fois que les nœuds du plan de contrôle des clusters d'utilisateurs kubeception ont été créés, mis à jour ou mis à niveau, ils sont redémarrés un par un lors de la première opération du cluster d'administrateur, lorsque le cluster d'administrateur est créé ou mis à niveau vers l'une des versions concernées. Pour les clusters kubeception avec trois nœuds de plan de contrôle, cela ne devrait pas entraîner de temps d'arrêt du plan de contrôle. Le seul impact est que l'opération du cluster d'administrateur prend plus de temps.
|
Installation, mises à niveau et mises à jour |
1.31 |
Erreurs lors de la création de ressources personnalisées
Dans la version 1.31 de Google Distributed Cloud, vous pouvez rencontrer des erreurs lorsque vous essayez de créer des ressources personnalisées, telles que des clusters (tous types) et des charges de travail. Ce problème est dû à un changement majeur introduit dans Kubernetes 1.31 qui empêche le champ caBundle d'une définition de ressource personnalisée de passer d'un état valide à un état non valide.
Pour en savoir plus sur ce changement, consultez le changelog de Kubernetes 1.31.
Avant Kubernetes 1.31, le champ caBundle était souvent défini sur une valeur provisoire de \n , car dans les versions antérieures de Kubernetes, le serveur d'API n'autorisait pas le contenu du bundle d'autorité de certification vide. L'utilisation de \n était une solution raisonnable pour éviter toute confusion, car cert-manager met généralement à jour caBundle plus tard.
Si caBundle a été corrigé une fois d'un état non valide à un état valide, aucun problème ne devrait se produire. Toutefois, si la définition de la ressource personnalisée est réconciliée avec \n (ou une autre valeur non valide), l'erreur suivante peut s'afficher:
...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]
Solution
Si vous disposez d'une définition de ressource personnalisée dans laquelle caBundle est défini sur une valeur non valide, vous pouvez supprimer complètement le champ caBundle . Le problème devrait être résolu.
|
OS |
1.31 |
cloud-init status renvoie toujours une erreur
Lorsque vous mettez à niveau un cluster qui utilise l'image d'OS Container-Optimized OS (COS) vers la version 1.31, la commande cloud-init status échoue, même si cloud-init a terminé sans erreur.
Solution :
Exécutez la commande suivante pour vérifier l'état de cloud-init:
systemctl show -p Result cloud-final.service
Si le résultat est semblable à celui-ci, cloud-init a bien terminé:
Result=success
|
Mises à niveau |
1.28 |
La vérification préliminaire de la station de travail administrateur échoue lors de la mise à niveau vers la version 1.28 avec une taille de disque inférieure à 100 Go
Lors de la mise à niveau d'un cluster vers la version 1.28, la commande gkectl prepare échoue lors de l'exécution des vérifications préliminaires du poste de travail administrateur si la taille de disque du poste de travail administrateur est inférieure à 100 Go. Dans ce cas, la commande affiche un message d'erreur semblable à celui-ci:
Workstation Hardware: Workstation hardware requirements are not satisfied
Dans la version 1.28, la taille de disque requise pour la station de travail administrateur est passée de 50 Go à 100 Go.
Solution :
- Effectuez un rollback sur le poste de travail administrateur.
- Mettez à jour le fichier de configuration du poste de travail administrateur pour augmenter la taille du disque à au moins 100 Go.
- Mettez à niveau le poste de travail administrateur.
|
Mises à niveau |
1,30 |
gkectl renvoie une erreur fausse sur la classe de stockage NetApp
La commande gkectl upgrade renvoie une erreur incorrecte concernant la classe de stockage netapp. Le message d'erreur ressemble à ceci :
detected unsupported drivers:
csi.trident.netapp.io
Solution :
Exécutez gkectl upgrade avec l'indicateur `--skip-pre-upgrade-checks`.
|
Identité |
toutes les versions |
Un certificat CA non valide après la rotation de l'autorité de certification de cluster dans ClientConfig empêche l'authentification du cluster
Après avoir effectué une rotation des certificats d'autorité de certification (AC) sur un cluster d'utilisateur, le champ spec.certificateAuthorityData de ClientConfig contient un certificat AC non valide, ce qui empêche l'authentification au cluster.
Solution :
Avant la prochaine authentification gcloud CLI, mettez à jour manuellement le champ spec.certificateAuthorityData dans ClientConfig avec le certificat d'autorité de certification approprié.
- Copiez le certificat de l'autorité de certification du cluster à partir du champ
certificate-authority-data du fichier kubeconfig du cluster d'administrateur.
-
Modifiez
ClientConfig et collez le certificat CA dans le champ spec.certificateAuthorityData .
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
|
Mises à jour |
1.28+ |
La vérification préliminaire échoue lors de la désactivation de l'entrée groupée
Lorsque vous désactivez l'entrée groupée en supprimant le champ loadBalancer.vips.ingressVIP dans le fichier de configuration du cluster, un bug dans la vérification préliminaire MetalLB entraîne l'échec de la mise à jour du cluster avec le message d'erreur "invalid user ingress vip: invalid IP" (VIP d'entrée utilisateur non valide : adresse IP non valide).
Solution :
Ignorez le message d'erreur. Ignorez la vérification préalable à l'aide de l'une des méthodes suivantes:
- Ajoutez l'indicateur
--skip-validation-load-balancer à la commande gkectl update cluster .
- Annotez l'objet
onpremusercluster avec onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer . .
|
VMware, Mises à niveau |
1.16 |
Échec de la mise à niveau du cluster en raison de l'absence de règle de groupe d'anti-affinité dans vCenter
Lors d'une mise à niveau de cluster, les objets machine peuvent rester bloqués à la phase de création et ne pas être associés aux objets de nœud en raison d'une règle de groupe anti-affinité (AAG) manquante dans vCenter.
Si vous décrivez les objets de machine problématiques, vous pouvez voir des messages récurrents tels que "Reconfigure DRS rule task "task-xxxx" complete" (Reconfiguration de la tâche de règle DRS "task-xxxx" terminée).
kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME
Solution :
Désactivez le paramètre de groupe d'anti-affinité dans la configuration du cluster d'administrateur et la configuration du cluster d'utilisateur, puis déclenchez la commande de force de mise à jour pour débloquer la mise à niveau du cluster:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
|
Migration |
1.29, 1.30 |
La migration d'un cluster d'utilisateurs vers Controlplane V2 échoue si le chiffrement des secrets a déjà été activé
Lors de la migration d'un cluster utilisateur vers Controlplane V2, si le
chiffrement permanent des secrets a déjà été activé, le processus de migration ne parvient pas à gérer correctement la clé de chiffrement des secrets. En raison de ce problème, le nouveau cluster Controlplane V2 ne peut pas déchiffrer les secrets. Si le résultat de la commande suivante n'est pas vide, cela signifie que le chiffrement permanent des secrets a été activé à un moment donné et que le cluster est affecté par ce problème:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get onpremusercluster USER_CLUSTER_NAME \
-n USER_CLUSTER_NAME-gke-onprem-mgmt \
-o jsonpath={.spec.secretsEncryption}
Si vous avez déjà commencé la migration et qu'elle échoue, contactez Google pour obtenir de l'aide. Dans le cas contraire, avant la migration,
désactivez le chiffrement permanent des secrets et déchiffrez les secrets.
|
Migration |
1.29.0-1.29.600, 1.30.0-1.30.100 |
La migration d'un cluster d'administrateur non haute disponibilité vers un cluster haute disponibilité échoue si le chiffrement des secrets est activé
Si le cluster d'administrateur a activé le chiffrement permanent des secrets à la version 1.14 ou antérieure, et qu'il a effectué la mise à niveau complète des anciennes versions vers les versions 1.29 et 1.30 concernées, le processus de migration ne parvient pas à gérer correctement la clé de chiffrement des secrets. En raison de ce problème, le nouveau cluster d'administrateur HA ne peut pas déchiffrer les secrets.
Pour vérifier si le cluster utilise l'ancienne clé formatée:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'
Si la sortie affiche une clé vide comme celle-ci, cela signifie que le cluster sera affecté par ce problème:
"GeneratedKeys":[{"KeyVersion":"1","Key":""}]
Si vous avez déjà commencé la migration et qu'elle échoue, contactez Google pour obtenir de l'aide.
Sinon, avant de commencer la migration, faites pivoter la clé de chiffrement.
|
Mises à niveau |
1.16, 1.28, 1.29, 1.30 |
credential.yaml régénéré de manière incorrecte lors de la mise à niveau du poste de travail administrateur
Lors de la mise à niveau du poste de travail administrateur à l'aide de la commande gkeadm upgrade
admin-workstation , le fichier credential.yaml est régénéré de manière incorrecte. Les champs "Nom d'utilisateur" et "Mot de passe" sont vides.
De plus, la clé privateRegistry contient une faute de frappe.
La même faute d'orthographe de la clé privateRegistry se trouve également dans le fichier admin-cluster.yaml . Étant donné que le fichier credential.yaml est régénéré lors du processus de mise à niveau du cluster d'administrateur, la faute de frappe est présente même si vous l'avez corrigée précédemment.
Solution :
- Mettez à jour le nom de la clé de registre privée dans
credential.yaml pour qu'il corresponde à privateRegistry.credentials.fileRef.entry dans admin-cluster.yaml .
- Mettez à jour le nom d'utilisateur et le mot de passe du registre privé dans
credential.yaml .
|
Mises à niveau |
1.16+ |
Échec de la migration du cluster d'utilisateur en raison d'un délai avant la mise à niveau
Lors de la mise à niveau d'un cluster d'utilisateurs, l'opération de réconciliation préalable à la mise à niveau peut prendre plus de temps que le délai avant expiration défini, ce qui entraîne un échec de la mise à niveau.
Le message d'erreur ressemble à ceci:
Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.
Le délai avant expiration de l'opération de réconciliation avant la mise à niveau est de cinq minutes plus une minute par pool de nœuds du cluster d'utilisateur.
Solution :
Assurez-vous que la commande gkectl diagnose cluster est exécutée sans erreur. Ignorez l'opération de réconciliation avant la mise à niveau en ajoutant l'indicateur --skip-reconcile-before-preflight à la commande gkectl upgrade cluster . Exemple :
gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
|
Mises à jour |
1.16, 1.28.0-1.28.800, 1.29.0-1.29.400, 1.30.0 |
La mise à jour de DataplaneV2 ForwardMode ne déclenche pas automatiquement le redémarrage du DaemonSet anetd
Lorsque vous modifiez le champ dataplaneV2.forwardMode du cluster utilisateur à l'aide de gkectl update cluster , le changement n'est mis à jour que dans le ConfigMap. Le DaemonSet anetd ne détectera pas le changement de configuration tant qu'il n'aura pas redémarré, et vos modifications ne seront pas appliquées.
Solution :
Une fois la commande gkectl update cluster terminée, le résultat Done updating the user cluster s'affiche. Une fois ce message affiché, exécutez la commande suivante pour redémarrer le DaemonSet anetd afin de récupérer la modification de configuration:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd
Vérifiez que le DaemonSet est prêt après le redémarrage:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd
Dans la sortie de la commande précédente, vérifiez que le nombre de la colonne DESIRED correspond à celui de la colonne READY .
|
Mises à niveau |
1.16 |
Commande etcdctl introuvable lors de la mise à niveau du cluster à l'étape de sauvegarde du cluster d'administrateur
Lors de la mise à niveau d'un cluster d'utilisateur de la version 1.16 vers la version 1.28, le cluster d'administrateur est sauvegardé. Le processus de sauvegarde du cluster d'administration affiche le message d'erreur "etcdctl: commande introuvable". La mise à niveau du cluster utilisateur aboutit et le cluster d'administrateur reste opérationnel. Le seul problème est que le fichier de métadonnées du cluster d'administration n'est pas sauvegardé.
Le problème est que le binaire etcdctl a été ajouté dans la version 1.28 et n'est pas disponible sur les nœuds 1.16.
La sauvegarde du cluster d'administrateur implique plusieurs étapes, y compris la création d'un instantané etcd, puis l'écriture du fichier de métadonnées du cluster d'administrateur.
La sauvegarde etcd aboutit toujours, car etcdctl peut toujours être déclenché après une exécution dans le pod etcd. Toutefois, l'écriture du fichier de métadonnées échoue, car le binaire etcdctl doit toujours être installé sur le nœud. Toutefois, la sauvegarde du fichier de métadonnées n'est pas un obstacle à la création d'une sauvegarde. Le processus de sauvegarde aboutit donc, tout comme la mise à niveau du cluster d'utilisateurs.
Solution :
Si vous souhaitez effectuer une sauvegarde du fichier de métadonnées, suivez la procédure Sauvegarder et restaurer un cluster d'administrateur avec gkectl pour déclencher une sauvegarde distincte du cluster d'administrateur à l'aide de la version de gkectl correspondant à celle de votre cluster d'administrateur.
|
Installation |
1.16-1.29 |
Échec de la création du cluster d'utilisateur avec équilibrage de charge manuel
Lorsque vous créez un cluster utilisateur configuré pour l'équilibrage de charge manuel, une erreur gkectl check-config se produit, indiquant que la valeur ingressHTTPNodePort doit être d'au moins 30 000, même lorsque l'entrée groupée est désactivée.
Ce problème se produit que les champs ingressHTTPNodePort et ingressHTTPSNodePort soient définis ou laissés vides.
Solution :
Pour contourner ce problème, ignorez le résultat renvoyé par gkectl check-config . Pour désactiver l'entrée groupée, consultez la section Désactiver l'entrée groupée.
|
Mises à jour |
1.29.0 |
Le problème avec PodDisruptionBudget (PDB) se produit lorsque vous utilisez des clusters d'administrateur haute disponibilité (HA) et qu'il n'y a pas de rôle attribué à un ou à zéro nœud de cluster d'administrateur après la migration. Pour vérifier si des objets de nœud sont associés à un rôle, exécutez la commande suivante:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide
Si deux objets de nœud ou plus ne sont pas associés à un rôle après la migration, la PDB n'est pas mal configurée.
Symptômes :
La sortie de admin cluster diagnose inclut les informations suivantes :
Checking all poddisruptionbudgets...FAILURE
Reason: 1 pod disruption budget error(s).
Unhealthy Resources:
PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).
Solution :
Exécutez la commande suivante pour supprimer le fichier PDB:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
|
Installation, mises à niveau et mises à jour |
1.28.0-1.28.600,1.29.0-1.29.100 |
Le webook d'autorisation binaire bloque le démarrage du plug-in CNI, ce qui entraîne l'échec de l'un des pools de nœuds.
Dans de rares cas, une séquence d'installation incorrecte du webhook d'autorisation binaire et du pod gke-connect peut entraîner l'arrêt de la création du cluster d'utilisateurs, car un nœud ne parvient pas à atteindre l'état prêt. Dans les scénarios concernés, la création du cluster d'utilisateurs peut s'arrêter en raison de l'échec de la mise en état de disponibilité d'un nœud. Dans ce cas, le message suivant s'affiche:
Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready
Solution :
- Supprimez la configuration de l'autorisation binaire de votre fichier de configuration. Pour obtenir des instructions de configuration, consultez le guide d'installation de l'autorisation binaire pour GKE sur VMware (jour 2).
- Pour débloquer un nœud défaillant pendant le processus de création de cluster en cours, supprimez temporairement la configuration du webhook d'autorisation binaire dans le cluster d'utilisateur à l'aide de la commande suivante.
kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
Une fois le processus de démarrage terminé, vous pouvez ajouter à nouveau la configuration de webhook suivante.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
namespaceSelector:
matchExpressions:
- key: control-plane
operator: DoesNotExist
objectSelector:
matchExpressions:
- key: "image-policy.k8s.io/break-glass"
operator: NotIn
values: ["true"]
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- pods
- pods/ephemeralcontainers
admissionReviewVersions:
- "v1beta1"
clientConfig:
service:
name: binauthz
namespace: binauthz-system
path: /binauthz
# CA Bundle will be updated by the cert rotator.
caBundle: Cg==
timeoutSeconds: 10
# Fail Open
failurePolicy: "Ignore"
sideEffects: None
|
Mises à niveau |
1.16, 1.28, 1.29 |
Mise à niveau du cluster d'utilisateurs CPV2 bloquée en raison d'une machine miroir avec deletionTimestamp
Lors d'une mise à niveau de cluster d'utilisateur, l'opération de mise à niveau peut se bloquer si l'objet de machine miroir du cluster d'utilisateur contient un deletionTimestamp . Le message d'erreur suivant s'affiche si la mise à niveau est bloquée:
machine is still in the process of being drained and subsequently removed
Ce problème peut se produire si vous avez déjà tenté de réparer le nœud du plan de contrôle de l'utilisateur en exécutant gkectl delete machine sur la machine miroir du cluster d'utilisateur.
Solution :
- Obtenez l'objet de machine miroir et enregistrez-le dans un fichier local à des fins de sauvegarde.
- Exécutez la commande suivante pour supprimer le finaliseur de la machine miroir et attendez qu'il soit supprimé du cluster d'utilisateur.
kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
- Suivez la procédure décrite dans la section
Nœud du plan de contrôle du cluster d'utilisateurs Controlplane V2 pour déclencher la réparation des nœuds sur les nœuds du plan de contrôle, afin que la spécification de machine source correcte soit résynchronisée dans le cluster d'utilisateurs.
- Exécuter à nouveau
gkectl upgrade cluster pour reprendre la mise à niveau
|
Configuration, installation |
1.15, 1.16, 1.28, 1.29 |
Échec de la création du cluster en raison d'une adresse IP virtuelle du plan de contrôle dans un sous-réseau différent
Pour un cluster d'administrateur HA ou un cluster d'utilisateur Controlplane V2, l'adresse IP virtuelle du plan de contrôle doit se trouver dans le même sous-réseau que les autres nœuds du cluster. Sinon, la création du cluster échoue, car kubelet ne peut pas communiquer avec le serveur d'API à l'aide de l'adresse IP virtuelle du plan de contrôle.
Solution :
Avant de créer le cluster, assurez-vous que l'adresse IP virtuelle du plan de contrôle est configurée dans le même sous-réseau que les autres nœuds du cluster.
|
Installation, mises à niveau, mises à jour |
1.29.0 à 1.29.100 |
Échec de la création/mise à niveau du cluster en raison d'un nom d'utilisateur vCenter non FQDN
La création/mise à niveau du cluster échoue et renvoie une erreur dans les pods CSI vSphere indiquant que le nom d'utilisateur vCenter n'est pas valide. Cela se produit parce que le nom d'utilisateur utilisé n'est pas un nom de domaine complet. Message d'erreur dans le pod vsphere-csi-controller comme suit:
GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username
Ce problème ne se produit que dans la version 1.29 et les versions ultérieures, car une validation a été ajoutée au pilote CSI vSphere pour imposer l'utilisation de noms d'utilisateur de domaine complets.
Solution :
Utilisez un nom de domaine complet pour le nom d'utilisateur vCenter dans le fichier de configuration des identifiants. Par exemple, au lieu d'utiliser "nomutilisateur1", utilisez "nomutilisateur1@exemple.com".
|
Mises à niveau, mises à jour |
1.28.0 à 1.28.500 |
Échec de la mise à niveau du cluster administrateur pour les clusters créés dans les versions 1.10 ou antérieures
Lors de la mise à niveau d'un cluster d'administrateur de la version 1.16 vers la version 1.28, le démarrage de la nouvelle machine maître d'administration peut ne pas générer le certificat du plan de contrôle. Ce problème est dû à des modifications apportées à la manière dont les certificats sont générés pour le serveur d'API Kubernetes dans la version 1.28 et les versions ultérieures. Le problème se reproduit pour les clusters créés sur les versions 1.10 et antérieures qui ont été mis à niveau vers la version 1.16 et pour lesquels le certificat de feuille n'a pas été remplacé avant la mise à niveau.
Pour déterminer si l'échec de la mise à niveau du cluster d'administrateur est causé par ce problème, procédez comme suit:
- Connectez-vous à la machine maître administrateur défaillante à l'aide de SSH.
- Ouvrez
/var/log/startup.log et recherchez une erreur semblable à celle-ci:
Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>
Solution :
- Connectez-vous à la machine maître administrateur à l'aide de SSH. Pour en savoir plus, consultez la section Se connecter à un nœud de cluster d'administrateur via SSH.
- Créer une copie de
/etc/startup/pki-yaml.sh et l'appeler /etc/startup/pki-yaml-copy.sh
- Modifier
/etc/startup/pki-yaml-copy.sh . Recherchez authorityKeyIdentifier=keyidset et remplacez-le par authorityKeyIdentifier=keyid,issuer dans les sections des extensions suivantes : apiserver_ext , client_ext , etcd_server_ext et kubelet_server_ext . Exemple :
[ apiserver_ext ]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth
basicConstraints = critical,CA:false
authorityKeyIdentifier = keyid,issuer
subjectAltName = @apiserver_alt_names
- Enregistrez les modifications apportées à
/etc/startup/pki-yaml-copy.sh .
- À l'aide d'un éditeur de texte, ouvrez
/opt/bin/master.sh , recherchez et remplacez toutes les occurrences de /etc/startup/pki-yaml.sh par /etc/startup/pki-yaml-copy.sh , puis enregistrez les modifications.
- Exécutez
/opt/bin/master.sh pour générer le certificat et terminer le démarrage de la machine.
- Exécutez à nouveau
gkectl upgrade admin pour mettre à niveau le cluster d'administrateur.
- Une fois la migration terminée, effectuez la rotation du certificat de feuille pour les clusters d'administrateur et d'utilisateur, comme décrit dans la section Démarrer la rotation.
- Une fois la rotation des certificats terminée, apportez les mêmes modifications à
/etc/startup/pki-yaml-copy.sh que vous l'avez fait précédemment, puis exécutez /opt/bin/master.sh .
|
Configuration |
1.29.0 |
Message d'avertissement incorrect pour les clusters avec Dataplane V2 activé
Le message d'avertissement incorrect suivant s'affiche lorsque vous exécutez gkectl pour créer, mettre à jour ou mettre à niveau un cluster pour lequel Dataplane V2 est déjà activé:
WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.
Un bug dans gkectl entraîne l'affichage constant de cet avertissement tant que dataplaneV2.forwardMode n'est pas utilisé, même si vous avez déjà défini enableDataplaneV2: true dans le fichier de configuration de votre cluster.
Solution :
Vous pouvez ignorer cet avertissement.
|
Configuration |
1.28.0-1.28.400, 1.29.0 |
La vérification préliminaire de l'installation du cluster d'administrateur à haute disponibilité indique un nombre incorrect d'adresses IP statiques requises
Lorsque vous créez un cluster d'administrateur HA, la vérification préliminaire affiche le message d'erreur incorrect suivant:
- Validation Category: Network Configuration
- [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
at least X+1 IP addresses for admin cluster with X nodes
Cette exigence est incorrecte pour les clusters d'administrateur HA version 1.28 et ultérieures, car ils ne comportent plus de nœuds complémentaires. De plus, comme les trois adresses IP des nœuds de plan de contrôle du cluster d'administrateur sont spécifiées dans la section network.controlPlaneIPBlock du fichier de configuration du cluster d'administrateur, les adresses IP du fichier de bloc d'adresses IP ne sont nécessaires que pour les nœuds de plan de contrôle du cluster utilisateur kubeception.
Solution :
Pour ignorer la vérification préliminaire incorrecte dans une version non corrigée, ajoutez --skip-validation-net-config à la commande gkectl .
|
Opération |
1.29.0-1.29.100 |
L'agent Connect perd la connexion à Google Cloud après la migration d'un cluster d'administrateur standard vers un cluster d'administrateur haute disponibilité
Si vous avez
fait passer un cluster d'administrateur non HD à un cluster d'administrateur HD, l'agent Connect du cluster d'administrateur perd la connexion à gkeconnect.googleapis.com avec l'erreur "Échec de la validation de la signature JWT". En effet, lors de la migration, la clé de signature KSA est modifiée. Un nouvel enregistrement est donc nécessaire pour actualiser les JWK OIDC.
Solution :
Pour reconnecter le cluster d'administrateur à Google Cloud, procédez comme suit pour déclencher un nouvel enregistrement:
Commencez par obtenir le nom du déploiement gke-connect :
kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect
Supprimez le déploiement gke-connect :
kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect
Déclenchez une mise en correspondance forcée pour le onprem-admin-cluster-controller en ajoutant une annotation "force-reconcile" à votre CR onpremadmincluster :
kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
annotations:
onprem.cluster.gke.io/force-reconcile: "true"
'
L'idée est que onprem-admin-cluster-controller redéployera toujours le déploiement gke-connect et réenregistrera le cluster s'il ne trouve aucun déploiement gke-connect existant disponible.
Après le correctif (il peut s'écouler quelques minutes avant que le contrôleur termine le rapprochement), vous pouvez vérifier que l'erreur 400 "Échec de la validation de la signature JWT" a disparu des journaux gke-connect-agent :
kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
|
Installation, système d'exploitation |
1.28.0-1.28.500, 1.29.0 |
L'adresse IP de la liaison Docker utilise 172.17.0.1/16 pour les nœuds du plan de contrôle du cluster COS
Google Distributed Cloud spécifie un sous-réseau dédié, --bip=169.254.123.1/24 , pour l'adresse IP de la liaison Docker dans la configuration Docker afin d'éviter de réserver le sous-réseau 172.17.0.1/16 par défaut. Toutefois, dans les versions 1.28.0-1.28.500 et 1.29.0, le service Docker n'a pas été redémarré après que Google Distributed Cloud a personnalisé la configuration Docker en raison d'une régression dans l'image de l'OS COS. En conséquence, Docker sélectionne le paramètre 172.17.0.1/16 par défaut comme sous-réseau d'adresse IP de liaison. Cela peut entraîner un conflit d'adresses IP si vous avez déjà une charge de travail en cours d'exécution dans cette plage d'adresses IP.
Solution :
Pour contourner ce problème, vous devez redémarrer le service Docker:
sudo systemctl restart docker
Vérifiez que Docker sélectionne l'adresse IP de liaison correcte :
ip a | grep docker0
Cette solution ne persiste pas lors de la recréation des VM. Vous devez appliquer cette solution de contournement à chaque recréation de VM.
|
update |
1.28.0-1.28.400, 1.29.0-1.29.100 |
L'utilisation de plusieurs interfaces réseau avec CNI standard ne fonctionne pas
Les binaires CNI standards bridge, ipvlan, vlan, macvlan, dhcp, tuning,
host-local, ptp, portmap ne sont pas inclus dans les images de l'OS dans les versions concernées. Ces binaires CNI ne sont pas utilisés par le dataplane V2, mais peuvent être utilisés pour des interfaces réseau supplémentaires dans la fonctionnalité d'interface réseau multiple.
Les interfaces réseau multiples avec ces plug-ins CNI ne fonctionneront pas.
Solution :
Passez à la version contenant le correctif si vous utilisez cette fonctionnalité.
|
update |
1.15, 1.16, 1.28 |
Les dépendances Netapp Trident interfèrent avec le pilote CSI vSphere
L'installation de multipathd sur les nœuds de cluster interfère avec le pilote CSI vSphere, ce qui empêche le démarrage des charges de travail utilisateur.
Solution :
|
Mises à jour |
1.15, 1.16 |
Le webhook du cluster d'administrateur peut bloquer les mises à jour lorsque vous ajoutez les configurations requises.
Si certaines configurations requises sont vides dans le cluster d'administration, car des validations ont été ignorées, leur ajout peut être bloqué par le webhook du cluster d'administration. Par exemple, si le champ gkeConnect n'a pas été défini dans un cluster d'administrateur existant, l'ajout avec la commande gkectl update admin peut générer le message d'erreur suivant:
admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters
Solution :
-
Pour les clusters d'administrateur 1.15, exécutez la commande
gkectl update admin avec l'option --disable-admin-cluster-webhook . Exemple :
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
-
Pour les clusters d'administrateur 1.16, exécutez les commandes
gkectl update admin avec l'option --force . Exemple :
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
|
Configuration |
1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200 |
La valeur par défaut du champ controlPlaneNodePort est 30968 lorsque la spécification manualLB est vide.
Si vous utilisez un équilibreur de charge manuel (loadBalancer.kind est défini sur "ManualLB" ), vous n'avez pas besoin de configurer la section loadBalancer.manualLB dans le fichier de configuration pour un cluster d'administrateur haute disponibilité (HA) dans les versions 1.16 et ultérieures. Toutefois, lorsque cette section est vide, Google Distributed Cloud attribue des valeurs par défaut à tous les NodePorts, y compris manualLB.controlPlaneNodePort , ce qui entraîne l'échec de la création du cluster avec le message d'erreur suivant:
- Validation Category: Manual LB
- [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
not be set when using HA admin cluster, got: 30968
Solution :
Spécifiez manualLB.controlPlaneNodePort: 0 dans la configuration du cluster d'administrateur pour le cluster d'administrateur haute disponibilité:
loadBalancer:
...
kind: ManualLB
manualLB:
controlPlaneNodePort: 0
...
|
Stockage |
1.28.0-1.28.100 |
nfs-common est manquant dans l'image de l'OS Ubuntu
nfs-common est manquant dans l'image de l'OS Ubuntu, ce qui peut entraîner des problèmes pour les clients qui utilisent des pilotes dépendants de NFS tels que NetApp.
Si le journal contient une entrée semblable à celle-ci après la mise à niveau vers la version 1.28, vous êtes concerné par ce problème:
Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".
Solution :
Assurez-vous que vos nœuds peuvent télécharger des paquets depuis Canonical.
Appliquez ensuite le DaemonSet suivant à votre cluster pour installer nfs-common :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: install-nfs-common
labels:
name: install-nfs-common
namespace: kube-system
spec:
selector:
matchLabels:
name: install-nfs-common
minReadySeconds: 0
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 100%
template:
metadata:
labels:
name: install-nfs-common
spec:
hostPID: true
hostIPC: true
hostNetwork: true
initContainers:
- name: install-nfs-common
image: ubuntu
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
command:
- chroot
- /host
- bash
- -c
args:
- |
apt install -y nfs-common
volumeMounts:
- name: host
mountPath: /host
containers:
- name: pause
image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
imagePullPolicy: IfNotPresent
volumes:
- name: host
hostPath:
path: /
|
Stockage |
1.28.0-1.28.100 |
Le champ "Storage policy" (Règle de stockage) est manquant dans le modèle de configuration du cluster d'administrateur
SPBM dans les clusters administrateur est compatible avec la version 1.28.0 et les versions ultérieures. Cependant, le champ vCenter.storagePolicyName est manquant dans le modèle de fichier de configuration.
Solution :
Ajoutez le champ "vCenter.storagePolicyName" dans le fichier de configuration du cluster d'administrateur si vous souhaitez configurer la stratégie de stockage pour le cluster d'administrateur. Veuillez consulter les instructions.
|
Journalisation et surveillance |
1.28.0-1.28.100 |
L'API kubernetesmetadata.googleapis.com récemment ajoutée n'est pas compatible avec VPC-SC. L'agent de collecte des métadonnées ne pourra donc pas atteindre cette API sous VPC-SC. Par conséquent, les libellés de métadonnées de métriques seront manquants.
Solution :
Dans l'espace de noms "kube-system", définissez le champ "featureGates.disableExperimentalMetadataAgent" sur "true" en exécutant la commande
`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`
puis exécutez
`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`
|
Mises à niveau, mises à jour |
1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0 |
Le clusterapi-controller peut planter lorsque le cluster d'administrateur et tout cluster d'utilisateur avec ControlPlane V2 activé utilisent des identifiants vSphere différents.
Lorsqu'un cluster d'administrateur et un cluster d'utilisateur avec ControlPlane V2 activé utilisent des identifiants vSphere différents (par exemple, après avoir mis à jour les identifiants vSphere du cluster d'administrateur), le clusterapi-controller peut ne pas réussir à se connecter à vCenter après le redémarrage. Affichez le journal du clusterapi-controller exécuté dans l'espace de noms "kube-system" du cluster d'administrateur.
kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
-n kube-system --kubeconfig KUBECONFIG
Si le journal contient une entrée semblable à celle-ci, vous êtes concerné par ce problème:
E1214 00:02:54.095668 1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found
Solution :
Mettez à jour les identifiants vSphere afin que le cluster d'administrateur et tous les clusters d'utilisateur avec Controlplane V2 activé utilisent les mêmes identifiants vSphere.
|
Journalisation et surveillance |
1,14 |
Nombre élevé de requêtes GRPC infructueuses dans etcd dans le gestionnaire d'alertes Prometheus
Prometheus peut générer des alertes semblables à l'exemple suivant:
Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.
Pour vérifier si cette alerte est un faux positif pouvant être ignoré, procédez comme suit:
- Comparez la métrique
grpc_server_handled_total brute à l'grpc_method indiquée dans le message d'alerte. Dans cet exemple, vérifiez le libellé grpc_code pour Watch .
Vous pouvez vérifier cette métrique à l'aide de Cloud Monitoring avec la requête MQL suivante:
fetch
k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
- Vous pouvez ignorer en toute sécurité une alerte pour tous les codes autres que
OK s'ils ne correspondent pas à l'un des codes suivants:
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded
Solution :
Pour configurer Prometheus pour ignorer ces alertes faussement positives, examinez les options suivantes:
- Mettez l'alerte sous silence dans l'interface utilisateur du Gestionnaire d'alertes.
- Si vous ne pouvez pas couper le son de l'alerte, suivez les étapes ci-dessous pour supprimer les faux positifs :
- Réduisez la capacité de l'opérateur de surveillance à des réplicas
0 afin que les modifications puissent persister.
- Modifiez le ConfigMap
prometheus-config et ajoutez grpc_method!="Watch" à la configuration d'alerte etcdHighNumberOfFailedGRPCRequests , comme indiqué dans l'exemple suivant :
- Version originale:
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
- Modifié:
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
Remplacez le CLUSTER_NAME suivant par le nom de votre cluster.
- Redémarrez le Statefulset Prometheus et Alertmanager pour récupérer la nouvelle configuration.
- Si le code fait partie de l'un des cas problématiques, vérifiez le journal etcd et le journal
kube-apiserver pour effectuer un débogage plus approfondi.
|
Mise en réseau |
1.16.0-1.16.2, 1.28.0 |
Les connexions NAT de sortie de longue durée sont abandonnées
Les connexions NAT de sortie peuvent être interrompues au bout de cinq à dix minutes après l'établissement d'une connexion si aucun trafic n'est généré.
Comme le conntrack n'a d'importance que dans le sens entrant (connexions externes au cluster), ce problème ne se produit que si la connexion ne transmet aucune information pendant un certain temps, puis que le côté de destination transmet quelque chose. Si le pod NAT de sortie instancie toujours la messagerie, ce problème ne se produira pas.
Ce problème se produit, car la collecte des déchets d'anetd supprime par inadvertance les entrées conntrack que le daemon pense être inutilisées.
Un correctif en amont a récemment été intégré à anetd pour corriger ce comportement.
Solution :
Il n'existe pas de solution de contournement simple, et nous n'avons pas constaté de problèmes dans la version 1.16 en raison de ce comportement. Si vous constatez que des connexions de longue durée sont interrompues en raison de ce problème, vous pouvez utiliser une charge de travail sur le même nœud que l'adresse IP de sortie ou envoyer des messages de manière cohérente sur la connexion TCP.
|
Opération |
1.14, 1.15, 1.16 |
Le signataire de la CSR ignore spec.expirationSeconds lors de la signature des certificats
Si vous créez une requête de signature de certificat (CSR) avec expirationSeconds défini, expirationSeconds est ignoré.
Solution :
Si vous êtes concerné par ce problème, vous pouvez mettre à jour votre cluster d'utilisateur en ajoutant disableNodeIDVerificationCSRSigning: true dans le fichier de configuration du cluster d'utilisateur, puis en exécutant la commande gkectl update cluster pour mettre à jour le cluster avec cette configuration.
|
Mise en réseau, mises à niveau, mises à jour |
1.16.0-1.16.3 |
Échec de la validation de l'équilibreur de charge du cluster utilisateur pour disable_bundled_ingress
Si vous essayez de désactiver l'entrée groupée pour un cluster existant, la commande gkectl update cluster échoue et affiche une erreur semblable à l'exemple suivant:
[FAILURE] Config: ingress IP is required in user cluster spec
Cette erreur se produit, car gkectl recherche une adresse IP d'entrée d'un équilibreur de charge lors des vérifications préalables. Bien que cette vérification ne soit pas requise lorsque vous désactivez l'entrée groupée, la vérification préliminaire gkectl échoue lorsque disableBundledIngress est défini sur true .
Solution :
Utilisez le paramètre --skip-validation-load-balancer lorsque vous mettez à jour le cluster, comme illustré dans l'exemple suivant:
gkectl update cluster \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
--skip-validation-load-balancer
Pour en savoir plus, découvrez comment désactiver l'ingress groupé pour un cluster existant.
|
Mises à niveau, mises à jour |
1.13, 1.14, 1.15.0 à 1.15.6 |
Les mises à jour du cluster d'administrateur échouent après la rotation de l'autorité de certification
Si vous effectuez une rotation des certificats de l'autorité de certification (CA) du cluster d'administrateur, les tentatives ultérieures d'exécution de la commande gkectl update admin échouent.
L'erreur renvoyée ressemble à ceci:
failed to get last CARotationStage: configmaps "ca-rotation-stage" not found
Solution :
Si vous êtes concerné par ce problème, vous pouvez mettre à jour votre cluster d'administrateur à l'aide de l'indicateur --disable-update-from-checkpoint avec la commande gkectl update admin :
gkectl update admin --config ADMIN_CONFIG_file \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-update-from-checkpoint
Lorsque vous utilisez l'option --disable-update-from-checkpoint , la commande de mise à jour n'utilise pas le fichier de point de contrôle comme source de vérité lors de la mise à jour du cluster. Le fichier de point de contrôle est toujours mis à jour pour une utilisation ultérieure.
|
Stockage |
1.15.0-1.15.6, 1.16.0-1.16.2 |
Échec de la vérification préliminaire de la charge de travail CSI en raison d'un échec de démarrage du pod
Lors des vérifications préalables, la validation de la charge de travail CSI installe un pod dans l'espace de noms default . Le pod de charge de travail CSI vérifie que le pilote CSI vSphere est installé et peut effectuer un provisionnement de volume dynamique. Si ce pod ne démarre pas, la vérification de la validation de la charge de travail CSI échoue.
Plusieurs problèmes connus peuvent empêcher le démarrage de ce pod:
- Si aucune limite de ressources n'est spécifiée pour le pod, ce qui est le cas pour certains clusters avec des webhooks d'admission installés, le pod ne démarre pas.
- Si Cloud Service Mesh est installé dans le cluster avec l'injection side-car Istio automatique activée dans l'espace de noms
default , le pod de charge de travail CSI ne démarre pas.
Si le pod de charge de travail CSI ne démarre pas, une erreur de délai avant expiration semblable à celle-ci s'affiche lors des validations préalables:
- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition
Pour voir si l'échec est dû à un manque de ressources de pod définies, exécutez la commande suivante pour vérifier l'état de la tâche anthos-csi-workload-writer-<run-id> :
kubectl describe job anthos-csi-workload-writer-<run-id>
Si les limites de ressources ne sont pas définies correctement pour le pod de charge de travail CSI, l'état de la tâche contient un message d'erreur semblable à celui-ci:
CPU and memory resource limits is invalid, as it are not defined for container: volume-tester
Si le pod de charge de travail CSI ne démarre pas en raison de l'injection de side-car Istio, vous pouvez désactiver temporairement l'injection automatique de side-car Istio dans l'espace de noms default . Vérifiez les libellés de l'espace de noms et utilisez la commande suivante pour supprimer le libellé commençant par istio.io/rev :
kubectl label namespace default istio.io/rev-
Si le pod est mal configuré, vérifiez manuellement que le provisionnement de volume dynamique avec le pilote CSI vSphere fonctionne:
- Créez un PVC qui utilise la StorageClass
standard-rwo .
- Créez un pod qui utilise le PVC.
- Vérifiez que le pod peut lire/écrire des données sur le volume.
- Supprimez le pod et le PVC une fois que vous avez vérifié le bon fonctionnement.
Si le provisionnement de volume dynamique avec le pilote CSI vSphere fonctionne, exécutez gkectl diagnose ou gkectl upgrade avec l'indicateur --skip-validation-csi-workload pour ignorer la vérification de la charge de travail CSI.
|
Opération |
1.16.0-1.16.2 |
Dépassement du délai d'expiration de la mise à jour du cluster d'utilisateur lorsque la version du cluster d'administrateur est 1.15
Lorsque vous êtes connecté à un
poste de travail administrateur géré par l'utilisateur, la commande gkectl update cluster peut expirer et ne pas réussir à mettre à jour le cluster d'utilisateurs. Cela se produit si la version du cluster d'administrateur est 1.15 et que vous exécutez gkectl update admin avant d'exécuter gkectl update cluster .
Lorsque cette erreur se produit, le message suivant s'affiche lorsque vous tentez de mettre à jour le cluster:
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Lors de la mise à jour d'un cluster d'administrateur 1.15, le validation-controller qui déclenche les vérifications préliminaires est supprimé du cluster. Si vous essayez ensuite de mettre à jour le cluster d'utilisateur, la vérification préliminaire se bloque jusqu'à l'expiration du délai.
Solution :
- Exécutez la commande suivante pour redéployer le
validation-controller :
gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
-
Une fois la préparation terminée, exécutez à nouveau
gkectl update cluster pour mettre à jour le cluster d'utilisateur.
|
Opération |
1.16.0-1.16.2 |
Dépassement du délai de création du cluster d'utilisateur lorsque la version du cluster d'administrateur est 1.15
Lorsque vous êtes connecté à un
poste de travail administrateur géré par l'utilisateur, la commande gkectl create cluster peut expirer et ne pas créer le cluster d'utilisateur. Cela se produit si la version du cluster d'administration est 1.15.
Dans ce cas, l'erreur suivante s'affiche lorsque vous tentez de créer le cluster:
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Étant donné que validation-controller a été ajouté dans la version 1.16, lorsque vous utilisez le cluster d'administration 1.15, le validation-controller chargé de déclencher les vérifications préliminaires est manquant. Par conséquent, lorsque vous essayez de créer un cluster d'utilisateur, les vérifications préliminaires sont suspendues jusqu'à l'expiration du délai.
Solution :
- Exécutez la commande suivante pour déployer le
validation-controller :
gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
-
Une fois la préparation terminée, exécutez à nouveau
gkectl create cluster pour créer le cluster d'utilisateur.
|
Mises à niveau, mises à jour |
1.16.0-1.16.2 |
La mise à jour ou la mise à niveau du cluster d'administrateur échoue si les projets ou les emplacements des services complémentaires ne correspondent pas.
Lorsque vous mettez à niveau un cluster d'administrateur de la version 1.15.x à la version 1.16.x, ou que vous ajoutez une configuration connect , stackdriver , cloudAuditLogging ou gkeOnPremAPI lorsque vous mettez à jour un cluster d'administrateur, l'opération peut être refusée par le webhook du cluster d'administrateur. L'un des messages d'erreur suivants peut s'afficher:
"projects for connect, stackdriver and cloudAuditLogging must be the
same when specified during cluster creation."
"locations for connect, gkeOnPremAPI, stackdriver and
cloudAuditLogging must be in the same region when specified during
cluster creation."
"locations for stackdriver and cloudAuditLogging must be the same
when specified during cluster creation."
Une mise à jour ou une mise à niveau d'un cluster d'administrateur nécessite que onprem-admin-cluster-controller réconcilie le cluster d'administrateur dans un cluster de type. Lorsque l'état du cluster d'administrateur est restauré dans le cluster de type, le webhook du cluster d'administrateur ne peut pas distinguer si l'objet OnPremAdminCluster est destiné à créer un cluster d'administrateur ou à reprendre les opérations pour une mise à jour ou une mise à niveau. Certaines validations de création uniquement sont appelées lors de la mise à jour et de la mise à niveau de manière inattendue.
Solution :
Ajoutez l'annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true à l'objet OnPremAdminCluster :
- Modifiez la ressource de cluster
onpremadminclusters :
kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
Remplacez les éléments suivants :
ADMIN_CLUSTER_NAME : nom du cluster d'administrateur.
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- Ajoutez l'annotation
onprem.cluster.gke.io/skip-project-location-sameness-validation: true et enregistrez la ressource personnalisée.
- En fonction du type de clusters d'administrateur, effectuez l'une des opérations suivantes :
- Pour les clusters d'administrateur non haute disponibilité avec un fichier de point de contrôle:ajoutez le paramètre
disable-update-from-checkpoint dans la commande de mise à jour ou le paramètre "disable-upgrade-from-checkpoint" dans la commande de mise à niveau. Ces paramètres ne sont nécessaires que la prochaine fois que vous exécuterez la commande update ou upgrade :
-
gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-update-from-checkpoint
-
gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
- Pour les clusters d'administrateur HA ou si le fichier de point de contrôle est désactivé:mettez à jour ou mettez à niveau le cluster d'administrateur comme d'habitude. Aucun paramètre supplémentaire n'est requis pour les commandes de mise à jour ou de mise à niveau.
|
Opération |
1.16.0-1.16.2 |
La suppression du cluster d'utilisateur échoue lorsque vous utilisez une station de travail d'administration gérée par l'utilisateur.
Lorsque vous êtes connecté à une
station de travail d'administration gérée par l'utilisateur, la commande gkectl delete cluster peut expirer et ne pas réussir à supprimer le cluster d'utilisateurs. Cela se produit si vous avez d'abord exécuté gkectl sur le poste de travail géré par l'utilisateur pour créer, mettre à jour ou mettre à niveau le cluster d'utilisateur. Lorsque cet échec se produit, le message d'erreur suivant s'affiche lorsque vous essayez de supprimer le cluster:
failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
to be deleted: timed out waiting for the condition
Lors de la suppression d'un cluster, tous ses objets sont d'abord supprimés. La suppression des objets de validation (créés lors de la création, de la mise à jour ou de la mise à niveau) est bloquée à la phase de suppression. Cela se produit parce qu'un finaliseur bloque la suppression de l'objet, ce qui entraîne l'échec de la suppression du cluster.
Solution :
- Obtenez le nom de tous les objets de validation:
kubectl --kubeconfig ADMIN_KUBECONFIG get validations \
-n USER_CLUSTER_NAME-gke-onprem-mgmt
-
Pour chaque objet Validation, exécutez la commande suivante pour supprimer le finaliseur de l'objet Validation:
kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
-n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
Une fois le finaliseur supprimé de tous les objets de validation, les objets sont supprimés et l'opération de suppression du cluster utilisateur se termine automatiquement. Aucune action supplémentaire n'est requise de votre part.
|
Mise en réseau |
1.15, 1.16 |
Échec du trafic de la passerelle NAT de sortie vers le serveur externe
Si le pod source et le pod de passerelle NAT de sortie se trouvent sur deux nœuds de travail différents, le trafic du pod source ne peut atteindre aucun service externe. Si les pods se trouvent sur le même hôte, la connexion au service ou à l'application externe aboutit.
Ce problème est dû au fait que vSphere supprime les paquets VXLAN lorsque l'agrégation de tunnels est activée. Il existe un problème connu avec NSX et VMware qui n'envoie que du trafic agrégé sur les ports VXLAN connus (4789).
Solution :
Définissez le port VXLAN utilisé par Cilium sur 4789 :
- Modifiez le fichier ConfigMap
cilium-config :
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
- Ajoutez ce qui suit au ConfigMap
cilium-config :
tunnel-port: 4789
- Redémarrez le DaemonSet anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
Cette solution de contournement est annulée chaque fois que le cluster est mis à niveau. Vous devez reconfigurer après chaque mise à niveau. VMware doit résoudre son problème dans vSphere pour une solution permanente.
|
Mises à niveau |
1.15.0-1.15.4 |
Échec de la mise à niveau d'un cluster d'administrateur avec le chiffrement des secrets toujours activé
La mise à niveau du cluster d'administration de la version 1.14.x vers la version 1.15.x avec le chiffrement des secrets activé en permanence échoue en raison d'une incompatibilité entre la clé de chiffrement générée par le contrôleur et la clé qui persiste sur le disque de données maître de l'administrateur. Le résultat de gkectl upgrade
admin contient le message d'erreur suivant:
E0926 14:42:21.796444 40110 console.go:93] Exit with error:
E0926 14:42:21.796491 40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane
L'exécution de kubectl get secrets -A --kubeconfig KUBECONFIG` échoue avec l'erreur suivante:
Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk
Solution
Si vous disposez d'une sauvegarde du cluster d'administrateur, procédez comme suit pour contourner l'échec de la mise à niveau:
-
Désactivez
secretsEncryption dans le fichier de configuration du cluster d'administrateur, puis mettez à jour le cluster à l'aide de la commande suivante:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
-
Une fois la nouvelle VM maître administrateur créée, connectez-vous à la VM maître administrateur via SSH, puis remplacez la nouvelle clé sur le disque de données par l'ancienne de la sauvegarde. La clé se trouve à
/opt/data/gke-k8s-kms-plugin/generatedkeys sur le maître administrateur.
-
Mettez à jour le fichier manifeste de pod statique kms-plugin.yaml dans
/etc/kubernetes/manifests pour que --kek-id corresponde au champ kid de la clé de chiffrement d'origine.
-
Redémarrez le pod statique kms-plugin en déplaçant
/etc/kubernetes/manifests/kms-plugin.yaml vers un autre répertoire, puis en le replaçant.
-
Reprenez la mise à niveau pour les administrateurs en exécutant à nouveau
gkectl upgrade admin .
Empêcher l'échec de la mise à niveau
Si vous ne l'avez pas déjà fait, nous vous recommandons de ne pas passer à la version 1.15.0-1.15.4. Si vous devez passer à une version affectée, procédez comme suit avant de mettre à niveau le cluster d'administrateur:
-
Sauvegardez le cluster d'administrateur.
-
Désactivez
secretsEncryption dans le fichier de configuration du cluster d'administrateur, puis mettez à jour le cluster à l'aide de la commande suivante:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
- Mettez à niveau le cluster d'administrateur.
-
Réactivez le chiffrement des secrets toujours activé.
|
Stockage |
1.11-1.16 |
Erreurs de disque et échecs d'association lors de l'utilisation du suivi des blocs modifiés (CBT)
Google Distributed Cloud n'est pas compatible avec le suivi des blocs modifiés (CBT) sur les disques. Certains logiciels de sauvegarde utilisent la fonctionnalité CBT pour suivre l'état du disque et effectuer des sauvegardes, ce qui empêche le disque de se connecter à une VM exécutant Google Distributed Cloud. Pour en savoir plus, consultez l'article de la base de connaissances VMware.
Solution :
Ne sauvegardez pas les VM Google Distributed Cloud, car un logiciel de sauvegarde tiers peut entraîner l'activation de CBT sur leurs disques. Il n'est pas nécessaire de sauvegarder ces VM.
N'activez pas la CBT sur le nœud, car cette modification ne persistera pas lors des mises à jour ou des mises à niveau.
Si vous disposez déjà de disques avec CBT activé, suivez les étapes de la résolution dans l'article de la base de connaissances VMware pour désactiver CBT sur le disque de première classe.
|
Stockage |
1.14, 1.15, 1.16 |
Corruption de données sur NFSv3 lorsque des ajouts parallèles à un fichier partagé sont effectués à partir de plusieurs hôtes
Si vous utilisez des arrays de stockage Nutanix pour fournir des partages NFSv3 à vos hôtes, vous risquez de corrompre des données ou de ne pas pouvoir exécuter les pods. Ce problème est causé par un problème de compatibilité connu entre certaines versions de VMware et de Nutanix. Pour en savoir plus, consultez l'article de la base de connaissances VMware associé.
Solution :
L'article de la base de connaissances VMware est obsolète, car il indique qu'il n'existe actuellement aucune solution. Pour résoudre ce problème, passez à la dernière version d'ESXi sur vos hôtes et à la dernière version de Nutanix sur vos arrays de stockage.
|
Système d'exploitation |
1.13.10, 1.14.6, 1.15.3 |
Incompatibilité de version entre le kubelet et le plan de contrôle Kubernetes
Pour certaines versions de Google Distributed Cloud, le kubelet exécuté sur les nœuds utilise une version différente de celle du plan de contrôle Kubernetes. Il existe une non-concordance, car le binaire kubelet préchargé sur l'image de l'OS utilise une version différente.
Le tableau suivant liste les incompatibilités de version identifiées:
Version de Google Distributed Cloud |
Version du kubelet |
Version de Kubernetes |
1.13.10 |
v1.24.11-gke.1200 |
v1.24.14-gke.2100 |
1.14.6 |
v1.25.8-gke.1500 |
v1.25.10-gke.1200 |
1.15.3 |
v1.26.2-gke.1001 |
v1.26.5-gke.2100 |
Solution :
Aucune action n'est requise de votre part. L'incohérence ne concerne que les versions de correctifs Kubernetes, et aucun problème n'a été causé par ce décalage de version.
|
Mises à niveau, mises à jour |
1.15.0-1.15.4 |
La mise à niveau ou la mise à jour d'un cluster d'administrateur avec une version de l'autorité de certification supérieure à 1 échoue
Lorsqu'un cluster d'administrateur dispose d'une version d'autorité de certification (CA) supérieure à 1, une mise à jour ou une mise à niveau échoue en raison de la validation de la version de l'autorité de certification dans le webhook. La sortie de la mise à niveau/mise à jour de gkectl contient le message d'erreur suivant:
CAVersion must start from 1
Solution :
-
Réduisez le déploiement
auto-resize-controller dans le cluster d'administrateur pour désactiver le redimensionnement automatique des nœuds. Cela est nécessaire, car un nouveau champ introduit dans la ressource personnalisée du cluster d'administration dans la version 1.15 peut entraîner une erreur de pointeur nul dans auto-resize-controller .
kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
-
Exécutez les commandes
gkectl avec l'option --disable-admin-cluster-webhook .Par exemple: gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
|
Opération |
1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1 |
La suppression du cluster Controlplane V2 sans HA est bloquée jusqu'à l'expiration du délai
Lorsqu'un cluster Controlplane V2 sans HA est supprimé, la suppression des nœuds est bloquée jusqu'à l'expiration du délai.
Solution :
Si le cluster contient un StatefulSet contenant des données critiques, contactez Cloud Customer Care pour résoudre ce problème.
Sinon, procédez comme suit:
- Supprimez toutes les VM du cluster de vSphere. Vous pouvez supprimer les VM via l'interface utilisateur vSphere ou exécuter la commande suivante:
govc vm.destroy .
- Forcez à nouveau la suppression du cluster:
gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
|
Stockage |
1.15.0+, 1.16.0+ |
Des tâches d'attachement de volume CNS constantes apparaissent toutes les minutes pour les PVC/PV dans l'arborescence après la mise à niveau vers la version 1.15 ou ultérieure
Lorsqu'un cluster contient des volumes persistants vSphere "in-tree" (par exemple, des PVC créés avec la StorageClass standard ), vous observerez des tâches com.vmware.cns.tasks.attachvolume déclenchées toutes les minutes à partir de vCenter.
Solution :
Modifiez le ConfigMap de la fonctionnalité CSI vSphere et définissez list-volumes sur "false" :
kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG
Redémarrez les pods du contrôleur CSI vSphere:
kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
|
Stockage |
1.16.0 |
Fausses alertes concernant les PVC
Lorsqu'un cluster contient des volumes persistants vSphere dans l'arborescence, les commandes gkectl diagnose et gkectl upgrade peuvent générer de fausses avertissements concernant leurs demandes de volume persistant (PVC) lors de la validation des paramètres de stockage du cluster. Le message d'avertissement se présente comme suit :
CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled
Solution :
Exécutez la commande suivante pour vérifier les annotations d'un PVC avec l'avertissement ci-dessus:
kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG
Si le champ annotations du résultat contient les éléments suivants, vous pouvez ignorer l'avertissement en toute sécurité:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
|
Mises à niveau, mises à jour |
1.15.0+, 1.16.0+ |
La rotation des clés de compte de service échoue lorsque plusieurs clés sont arrivées à expiration
Si votre cluster n'utilise pas de registre privé, et que la clé de compte de service d'accès au composant et les clés de compte de service de surveillance de journalisation (ou de registre Connect) ont expiré, lorsque vous faites pivoter les clés de compte de service, gkectl update credentials échoue avec une erreur semblable à la suivante:
Error: reconciliation failed: failed to update platform: ...
Solution :
Commencez par alterner la clé du compte de service d'accès aux composants. Bien que le même message d'erreur s'affiche, vous devriez pouvoir faire pivoter les autres clés après la rotation de la clé du compte de service d'accès au composant.
Si la mise à jour ne fonctionne toujours pas, contactez l'assistance Cloud Customer Care pour résoudre ce problème.
|
Mises à niveau |
1.16.0-1.16.5 |
1.15 La machine maître utilisateur rencontre une recréation inattendue lorsque le contrôleur de cluster utilisateur est mis à niveau vers la version 1.16
Lors d'une mise à niveau de cluster d'utilisateur, une fois le contrôleur de cluster d'utilisateur mis à niveau vers la version 1.16, si d'autres clusters d'utilisateurs de la version 1.15 sont gérés par le même cluster d'administrateur, leur machine maître utilisateur peut être recréée de manière inattendue.
Un bug est présent dans le contrôleur de cluster d'utilisateurs 1.16, ce qui peut déclencher la recréation de la machine maître utilisateur 1.15.
La solution de contournement que vous allez appliquer dépend de la façon dont vous rencontrez ce problème.
Solution de contournement lors de la mise à niveau du cluster d'utilisateurs à l'aide de la console Google Cloud:
Option 1: Utilisez une version 1.16.6 ou ultérieure de GKE sur VMware avec le correctif.
Option 2: Procédez comme suit:
- Ajoutez manuellement l'annotation de nouvelle exécution à l'aide de la commande suivante:
kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG
L'annotation de la nouvelle diffusion est la suivante:
onprem.cluster.gke.io/server-side-preflight-rerun: true
- Surveillez la progression de la mise à niveau en vérifiant le champ
status de OnPremUserCluster.
Solution de contournement lorsque vous mettez à niveau le cluster d'utilisateurs à l'aide de votre propre poste de travail administrateur:
Option 1: Utilisez une version 1.16.6 ou ultérieure de GKE sur VMware avec le correctif.
Option 2: Procédez comme suit:
- Ajoutez le fichier d'informations de compilation
/etc/cloud/build.info avec le contenu suivant. Les vérifications préliminaires sont alors exécutées localement sur votre poste de travail administrateur plutôt que sur le serveur.
gke_on_prem_version: GKE_ON_PREM_VERSION Par exemple :gke_on_prem_version: 1.16.0-gke.669
- Réexécutez la commande de mise à niveau.
- Une fois la mise à niveau terminée, supprimez le fichier build.info.
|
Créer |
1.16.0-1.16.5, 1.28.0-1.28.100 |
La vérification préliminaire échoue lorsque le nom d'hôte ne figure pas dans le fichier de bloc d'adresses IP.
Lors de la création du cluster, si vous ne spécifiez pas de nom d'hôte pour chaque adresse IP du fichier de bloc d'adresses IP, la vérification préliminaire échoue avec le message d'erreur suivant:
multiple VMs found by DNS name in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`
Un bug dans la vérification préalable considère un nom d'hôte vide comme un doublon.
Solution :
Option 1: Utiliser une version avec le correctif.
Option 2: Contournez cette vérification préliminaire en ajoutant l'indicateur --skip-validation-net-config .
Option 3: Spécifiez un nom d'hôte unique pour chaque adresse IP dans le fichier de bloc d'adresses IP.
|
Mises à niveau, mises à jour |
1.16 |
Échec de l'installation de volume lors de la mise à niveau/mise à jour du cluster d'administrateur si vous utilisez un cluster d'administrateur non haute disponibilité et un cluster d'utilisateur du plan de contrôle V1
Pour un cluster d'administrateur non haute disponibilité et un cluster d'utilisateur de plan de contrôle v1, lorsque vous mettez à niveau ou mettez à jour le cluster d'administrateur, la recréation de la machine maître du cluster d'administrateur peut se produire en même temps que le redémarrage de la machine maître du cluster d'utilisateur, ce qui peut entraîner une condition de course.
Les pods du plan de contrôle du cluster utilisateur ne peuvent donc pas communiquer avec le plan de contrôle du cluster d'administrateur, ce qui entraîne des problèmes d'association de volumes pour kube-etcd et kube-apiserver sur le plan de contrôle du cluster d'utilisateur.
Pour vérifier le problème, exécutez les commandes suivantes pour le pod concerné:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
Vous verrez les événements suivants:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 101s kubelet Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
Warning FailedMount 86s (x2 over 3m28s) kubelet MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"
Solution :
-
Se connecter en SSH au nœud du plan de contrôle de l'utilisateur : comme il s'agit d'un cluster d'utilisateurs du plan de contrôle v1, le nœud du plan de contrôle de l'utilisateur se trouve dans le cluster d'administrateur.
-
Redémarrez le kubelet à l'aide de la commande suivante:
sudo systemctl restart kubelet
Après le redémarrage, le kubelet peut reconstruire correctement le montage global de l'étape.
|
Mises à niveau, mises à jour |
1.16.0 |
Échec de la création du nœud du plan de contrôle
Lors d'une mise à niveau ou d'une mise à jour d'un cluster d'administrateur, une condition de course peut entraîner la suppression inattendue d'un nouveau nœud de plan de contrôle par le gestionnaire de contrôleur cloud vSphere. Le clusterapi-controller reste bloqué en attendant la création du nœud, et la mise à niveau/mise à jour expire à terme. Dans ce cas, la sortie de la commande upgrade/update gkectl ressemble à ceci:
controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...
Pour identifier le symptôme, exécutez la commande ci-dessous pour obtenir la connexion au gestionnaire de contrôleur cloud vSphere dans le cluster d'administrateur:
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
Voici un exemple de message d'erreur de la commande ci-dessus:
node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.
Solution :
-
Redémarrez la machine défaillante pour recréer l'objet de nœud supprimé.
-
Connectez-vous en SSH à chaque nœud du plan de contrôle et redémarrez le pod statique du gestionnaire de contrôleur cloud vSphere:
sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
sudo crictl stop PREVIOUS_COMMAND_OUTPUT
-
Réexécutez la commande de mise à niveau/mise à jour.
|
Opération |
1.16 |
Un nom d'hôte en double dans le même centre de données entraîne des échecs de création ou de mise à niveau de cluster
La mise à niveau d'un cluster 1.15 ou la création d'un cluster 1.16 avec des adresses IP statiques échoue si des noms d'hôtes sont en double dans le même centre de données. Cet échec se produit, car le gestionnaire de contrôleur cloud vSphere ne parvient pas à ajouter une adresse IP externe et un ID de fournisseur dans l'objet du nœud. La création/mise à niveau du cluster expire alors.
Pour identifier le problème, obtenez les journaux du pod du gestionnaire de contrôleur cloud vSphere pour le cluster. La commande que vous utilisez dépend du type de cluster, comme suit:
- Cluster d'administrateur :
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
- Cluster d'utilisateur (kubeception):
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
- Cluster d'utilisateur: (Controlplane V2):
kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system
Voici un exemple de message d'erreur:
I1003 17:17:46.769676 1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
E1003 17:17:46.771717 1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2
Vérifiez si le nom d'hôte est en double dans le centre de données:
Vous pouvez utiliser l'approche suivante pour vérifier si le nom d'hôte est dupliqué et trouver une solution de contournement si nécessaire.
export GOVC_DATACENTER=GOVC_DATACENTER
export GOVC_URL=GOVC_URL
export GOVC_USERNAME=GOVC_USERNAME
export GOVC_PASSWORD=GOVC_PASSWORD
export GOVC_INSECURE=true
govc find . -type m -guest.hostName HOSTNAME
Exemples de commandes et de résultats:
export GOVC_DATACENTER=mtv-lifecycle-vc01
export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
export GOVC_USERNAME=xxx
export GOVC_PASSWORD=yyy
export GOVC_INSECURE=true
govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
./vm/gke-admin-node-6b7788cd76-wkt8g
./vm/gke-admin-node-6b7788cd76-99sg2
./vm/gke-admin-master-5m2jb
La solution de contournement que vous allez mettre en œuvre dépend de l'opération ayant échoué.
Solution de contournement pour les mises à niveau:
Appliquez la solution de contournement pour le type de cluster applicable.
- Cluster d'utilisateur :
-
Remplacez le nom d'hôte de la machine concernée dans user-ip-block.yaml par un nom unique et déclenchez une mise à jour forcée:
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
-
Réexécuter
gkectl upgrade cluster
- Cluster d'administrateur :
- Remplacez le nom d'hôte de la machine concernée dans admin-ip-block.yaml par un nom unique et déclenchez une mise à jour forcée:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
- S'il s'agit d'un cluster d'administrateur non haute disponibilité et que vous constatez que la VM maître d'administration utilise un nom d'hôte en double, vous devez également:
Obtenir le nom de la machine maître d'administration
kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
Mettre à jour l'objet de machine maître administrateur
Remarque:NEW_ADMIN_MASTER_HOSTNAME doit être identique à celui que vous avez défini dans admin-ip-block.yaml à l'étape 1.
kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
Vérifiez que le nom d'hôte est mis à jour dans l'objet de machine maître administrateur:
kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
- Réexécutez la mise à niveau du cluster d'administrateur avec le point de contrôle désactivé:
gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint
Solution de contournement pour les installations:
Appliquez la solution de contournement pour le type de cluster applicable.
|
Opération |
1.16.0, 1.16.1, 1.16.2, 1.16.3 |
$ et ` ne sont pas acceptés dans le nom d'utilisateur ou le mot de passe vSphere
Les opérations suivantes échouent lorsque le nom d'utilisateur ou le mot de passe vSphere contient $ ou ` :
- Mettre à niveau un cluster d'utilisateurs 1.15 avec Controlplane V2 activé vers la version 1.16
- Mettre à niveau un cluster d'administrateur haute disponibilité (HD) de la version 1.15 vers la version 1.16
- Créer un cluster d'utilisateurs 1.16 avec Controlplane V2 activé
- Créer un cluster d'administrateur haute disponibilité 1.16
Utilisez une version 1.16.4 ou ultérieure de Google Distributed Cloud avec le correctif ou effectuez le correctif ci-dessous. La solution de contournement que vous allez mettre en œuvre dépend de l'opération ayant échoué.
Solution de contournement pour les mises à niveau:
- Modifiez le nom d'utilisateur ou le mot de passe vCenter côté vCenter pour supprimer les
$ et ` .
- Mettez à jour le nom d'utilisateur ou le mot de passe vCenter dans votre fichier de configuration des identifiants.
- Déclencher une mise à jour forcée du cluster.
- Cluster d'utilisateur :
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
- Cluster d'administrateur :
gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
Solution de contournement pour les installations:
- Modifiez le nom d'utilisateur ou le mot de passe vCenter côté vCenter pour supprimer les
$ et ` .
- Mettez à jour le nom d'utilisateur ou le mot de passe vCenter dans votre fichier de configuration des identifiants.
- Appliquez la solution de contournement pour le type de cluster applicable.
|
Stockage |
1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16 |
Échec de la création de PVC après la recréation du nœud avec le même nom
Une fois qu'un nœud a été supprimé, puis recréé avec le même nom, il est possible qu'une création ultérieure de PersistentVolumeClaim (PVC) échoue avec une erreur semblable à la suivante:
The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created
Ce problème est dû à une condition de course où le contrôleur CSI vSphere ne supprime pas une machine supprimée de son cache.
Solution :
Redémarrez les pods du contrôleur CSI vSphere:
kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
|
Opération |
1.16.0 |
La commande gkectl repair admin-master renvoie une erreur de désérialisation kubeconfig
Lorsque vous exécutez la commande gkectl repair admin-master sur un cluster d'administrateur HA, gkectl renvoie le message d'erreur suivant:
Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
line 3: cannot unmarshal !!seq into map[string]*api.Cluster
line 8: cannot unmarshal !!seq into map[string]*api.Context
Solution :
Ajoutez l'indicateur --admin-master-vm-template= à la commande et fournissez le modèle de VM de la machine à réparer:
gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--config ADMIN_CLUSTER_CONFIG_FILE \
--admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME
Pour trouver le modèle de VM de la machine:
- Accédez à la page Hosts and Clusters (Hôtes et clusters) dans le client vSphere.
- Cliquez sur Modèles de VM, puis filtrez par nom du cluster d'administrateur.
Les trois modèles de VM du cluster administrateur s'affichent.
- Copiez le nom du modèle de VM qui correspond au nom de la machine que vous réparez, puis utilisez le nom du modèle dans la commande de réparation.
gkectl repair admin-master \
--config=/home/ubuntu/admin-cluster.yaml \
--kubeconfig=/home/ubuntu/kubeconfig \
--admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
|
Mise en réseau |
1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0 |
VM Seesaw défectueuse en raison d'un espace disque insuffisant
Si vous utilisez Seesaw comme type d'équilibreur de charge pour votre cluster et que vous constatez qu'une VM Seesaw est en panne ou ne parvient pas à démarrer, le message d'erreur suivant peut s'afficher dans la console vSphere:
GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
Cette erreur indique que l'espace disque est faible sur la VM, car fluent-bit exécuté sur la VM Seesaw n'est pas configuré avec une rotation de journaux correcte.
Solution :
Recherchez les fichiers journaux qui occupent la majeure partie de l'espace disque à l'aide de du -sh -- /var/lib/docker/containers/* | sort -rh . Nettoyez le fichier journal le plus volumineux, puis redémarrez la VM.
Remarque:Si la VM est complètement inaccessible, associez le disque à une VM fonctionnelle (par exemple, une station de travail d'administration), supprimez le fichier du disque associé, puis réassociez le disque à la VM Seesaw d'origine.
Pour éviter que le problème ne se reproduise, connectez-vous à la VM et modifiez le fichier /etc/systemd/system/docker.fluent-bit.service . Ajoutez --log-opt max-size=10m --log-opt max-file=5 dans la commande Docker, puis exécutez systemctl restart docker.fluent-bit.service .
|
Opération |
1.13, 1.14.0-1.14.6, 1.15 |
Erreur de clé publique SSH d'administrateur après la mise à niveau ou la mise à jour du cluster d'administrateur
Lorsque vous essayez de mettre à niveau (gkectl upgrade admin ) ou de mettre à jour (gkectl update admin ) un cluster d'administrateur non haute disponibilité avec le point de contrôle activé, la mise à niveau ou la mise à jour peut échouer avec des erreurs telles que les suivantes:
Checking admin cluster certificates...FAILURE
Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
ubuntu@AdminMasterIP: Permission denied (publickey).
failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
ubuntu@AdminMasterIP: Permission denied (publickey)
error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...
Solution :
Si vous ne parvenez pas à passer à une version de correctif de Google Distributed Cloud avec le correctif, contactez l'assistance Google pour obtenir de l'aide.
|
Mises à niveau |
1.13.0 à 1.13.9, 1.14.0 à 1.14.6, 1.15.1 à 1.15.2 |
La mise à niveau d'un cluster d'administrateur enregistré dans l'API GKE On-Prem peut échouer
Lorsqu'un cluster d'administrateur est inscrit dans l'API GKE On-Prem, la mise à niveau du cluster d'administrateur vers les versions concernées peut échouer, car l'appartenance au parc n'a pas pu être mise à jour. Lorsque cette erreur se produit, le message d'erreur suivant s'affiche lorsque vous tentez de mettre à niveau le cluster:
failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated
Un cluster d'administrateur est enregistré dans l'API lorsque vous enregistrez explicitement le cluster ou lorsque vous mettez à niveau un cluster d'utilisateur à l'aide d'un client d'API GKE On-Prem.
Solution :
Désinscrivez le cluster d'administrateur:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
et reprendez la mise à niveau du cluster d'administrateur. L'erreur obsolète "Échec de l'enregistrement du cluster" peut s'afficher temporairement. Au bout d'un certain temps, il devrait être mis à jour automatiquement.
|
Mises à niveau, mises à jour |
1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0 |
L'annotation du lien vers les ressources du cluster d'administrateur enregistré n'est pas conservée
Lorsqu'un cluster d'administrateur est enregistré dans l'API GKE On-Prem, son annotation de lien de ressource est appliquée à la ressource personnalisée OnPremAdminCluster , qui n'est pas conservée lors des mises à jour ultérieures du cluster d'administrateur en raison de la mauvaise clé d'annotation utilisée. Cela peut entraîner l'enregistrement du cluster d'administrateur dans l'API GKE On-Prem par erreur.
Un cluster d'administrateur est enregistré dans l'API lorsque vous enregistrez explicitement le cluster ou lorsque vous mettez à niveau un cluster d'utilisateur à l'aide d'un client d'API GKE On-Prem.
Solution :
Désinscrivez le cluster d'administrateur:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
et réenregistrez le cluster d'administrateur.
|
Mise en réseau |
1.15.0-1.15.2 |
orderPolicy CoreDNS non reconnu
OrderPolicy n'est pas reconnu comme paramètre et n'est pas utilisé. Google Distributed Cloud utilise toujours Random .
Ce problème se produit car le modèle CoreDNS n'a pas été mis à jour, ce qui entraîne l'ignorance de orderPolicy .
Solution :
Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif est conservé jusqu'à une mise à niveau.
- Modifiez le modèle existant:
kubectl edit cm -n kube-system coredns-template
Remplacez le contenu du modèle par le code suivant:
coredns-template: |-
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
{{- if .PrivateGoogleAccess }}
import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
import zones/restricted.Corefile
{{- end }}
prometheus :9153
forward . {{ .UpstreamNameservers }} {
max_concurrent 1000
{{- if ne .OrderPolicy "" }}
policy {{ .OrderPolicy }}
{{- end }}
}
cache 30
{{- if .DefaultDomainQueryLogging }}
log
{{- end }}
loop
reload
loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
errors
{{- if $stubdomain.QueryLogging }}
log
{{- end }}
cache 30
forward . {{ $stubdomain.Nameservers }} {
max_concurrent 1000
{{- if ne $.OrderPolicy "" }}
policy {{ $.OrderPolicy }}
{{- end }}
}
}
{{- end }}
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3 |
État OnPremAdminCluster incohérent entre le point de contrôle et la CR réelle
Certaines conditions de course peuvent entraîner une incohérence entre l'état OnPremAdminCluster du point de contrôle et le CR réel. Lorsque ce problème se produit, l'erreur suivante peut s'afficher lorsque vous mettez à jour le cluster d'administrateur après l'avoir mis à niveau:
Exit with error:
E0321 10:20:53.515562 961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Pour contourner ce problème, vous devez modifier le point de contrôle ou le désactiver pour la mise à niveau/la mise à jour. Veuillez contacter notre équipe d'assistance pour suivre cette procédure de contournement.
|
Opération |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Le processus de réconciliation modifie les certificats d'administrateur sur les clusters d'administrateur
Google Distributed Cloud modifie les certificats d'administrateur sur les plans de contrôle du cluster d'administrateur à chaque processus de rapprochement, par exemple lors d'une mise à niveau de cluster. Ce comportement augmente la probabilité d'obtenir des certificats non valides pour votre cluster d'administrateur, en particulier pour les clusters de la version 1.15.
Si vous êtes concerné par ce problème, vous pouvez rencontrer les problèmes suivants:
Solution :
Passez à une version de Google Distributed Cloud avec le correctif : 1.13.10 ou version ultérieure, 1.14.6 ou version ultérieure, 1.15.2 ou version ultérieure. Si la mise à niveau n'est pas possible pour vous, contactez l'assistance client Cloud pour résoudre ce problème.
|
Mise en réseau, exploitation |
1.10, 1.11, 1.12, 1.13, 1.14 |
Composants Anthos Network Gateway évincés ou en attente en raison de l'absence de classe de priorité
Les pods de passerelle réseau dans kube-system peuvent afficher un état Pending ou Evicted , comme illustré dans l'exemple de sortie condensée suivant:
$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc 2/2 Running 0 5d2h
ang-node-mw8cq 0/2 Evicted 0 6m5s
ang-node-zsmq7 0/2 Pending 0 7h
Ces erreurs indiquent des événements d'éviction ou l'impossibilité de planifier des pods en raison des ressources de nœud. Étant donné qu'ils n'ont pas de PriorityClass, les pods de passerelle réseau Anthos ont la même priorité par défaut que les autres charges de travail.
Lorsque les nœuds sont soumis à des contraintes de ressources, les pods de passerelle réseau peuvent être évincés. Ce comportement est particulièrement mauvais pour le DaemonSet ang-node , car ces pods doivent être planifiés sur un nœud spécifique et ne peuvent pas migrer.
Solution :
Effectuez une mise à niveau vers la version 1.15 ou une version ultérieure.
Pour résoudre le problème à court terme, vous pouvez attribuer manuellement un PriorityClass aux composants Anthos Network Gateway. Le contrôleur Google Distributed Cloud écrase ces modifications manuelles lors d'un processus de rapprochement, par exemple lors d'une mise à niveau de cluster.
- Attribuez la PriorityClass
system-cluster-critical aux déploiements des contrôleurs de cluster ang-controller-manager et autoscaler .
- Attribuez la PriorityClass
system-node-critical au DaemonSet du nœud ang-daemon .
|
Mises à niveau, mises à jour |
1.12, 1.13, 1.14, 1.15.0-1.15.2 |
Échec de la mise à niveau du cluster d'administrateur après l'enregistrement du cluster avec gcloud
Après avoir utilisé gcloud pour enregistrer un cluster d'administrateur avec une section gkeConnect non vide, l'erreur suivante peut s'afficher lorsque vous essayez de mettre à niveau le cluster:
failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated
Supprimez l'espace de noms gke-connect :
kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Obtenez le nom du cluster d'administrateur:
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Supprimez l'appartenance au parc:
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME et reprendez la mise à niveau du cluster d'administrateur.
|
Opération |
1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1 |
gkectl diagnose snapshot --log-since ne parvient pas à limiter la période d'exécution des commandes journalctl sur les nœuds du cluster
Cela n'affecte pas la fonctionnalité de création d'un instantané du cluster, car l'instantané inclut toujours tous les journaux collectés par défaut en exécutant journalctl sur les nœuds du cluster. Par conséquent, aucune information de débogage n'est manquée.
|
Installation, mises à niveau, mises à jour |
1.9+, 1.10+, 1.11+, 1.12+ |
Échec de gkectl prepare windows
gkectl prepare windows ne parvient pas à installer Docker sur les versions de Google Distributed Cloud antérieures à la version 1.13, car MicrosoftDockerProvider est obsolète.
Solution :
L'idée générale pour contourner ce problème consiste à passer à Google Distributed Cloud 1.13 et à utiliser gkectl 1.13 pour créer un modèle de VM Windows, puis à créer des pools de nœuds Windows. Vous avez le choix entre deux options pour passer à Google Distributed Cloud 1.13 à partir de votre version actuelle, comme illustré ci-dessous.
Remarque:Nous disposons d'options pour contourner ce problème dans votre version actuelle sans avoir à passer à la version 1.13. Toutefois, cela nécessitera davantage d'étapes manuelles. Veuillez contacter notre équipe d'assistance si vous souhaitez envisager cette option.
Option 1:Mise à niveau bleu-vert
Vous pouvez créer un cluster à l'aide de Google Distributed Cloud 1.13 ou version ultérieure avec des pools de nœuds Windows, puis migrer vos charges de travail vers le nouveau cluster, puis détruire le cluster actuel. Nous vous recommandons d'utiliser la dernière version mineure de Google Distributed Cloud.
Remarque:Cette approche nécessite des ressources supplémentaires pour provisionner le nouveau cluster, mais réduit les temps d'arrêt et les perturbations pour les charges de travail existantes.
Option 2:Supprimez les pools de nœuds Windows, puis ajoutez-les à nouveau lors de la mise à niveau vers Google Distributed Cloud 1.13.
Remarque:Pour cette option, les charges de travail Windows ne pourront pas s'exécuter tant que le cluster n'aura pas été mis à niveau vers la version 1.13 et que les pools de nœuds Windows n'auront pas été ajoutés à nouveau.
- Supprimez les pools de nœuds Windows existants en supprimant la configuration des pools de nœuds Windows du fichier user-cluster.yaml, puis exécutez la commande suivante:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Mettez à niveau les clusters d'administrateur et d'utilisateur Linux vers la version 1.12 en suivant le
guide de l'utilisateur de la mise à niveau pour la version mineure cible correspondante.
- (Assurez-vous d'effectuer cette étape avant de passer à la version 1.13) Assurez-vous que
enableWindowsDataplaneV2: true est configuré dans la CR OnPremUserCluster . Sinon, le cluster continuera d'utiliser Docker pour les pools de nœuds Windows, ce qui ne sera pas compatible avec le nouveau modèle de VM Windows 1.13 créé sans Docker installé. Si ce n'est pas le cas ou si la valeur est définie sur "false", mettez à jour votre cluster pour définir la valeur sur "true" dans user-cluster.yaml, puis exécutez:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Mettez à niveau les clusters administrateur et utilisateur Linux vers la version 1.13 en suivant le
guide de l'utilisateur de la mise à niveau.
- Préparez le modèle de VM Windows à l'aide de gkectl 1.13:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
- Réajoutez la configuration du pool de nœuds Windows à user-cluster.yaml, en définissant le champ
OSImage sur le nouveau modèle de VM Windows.
- Mettre à jour le cluster pour ajouter des pools de nœuds Windows
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
|
Installation, mises à niveau, mises à jour |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
La configuration RootDistanceMaxSec n'est pas appliquée aux nœuds ubuntu
La valeur par défaut de 5 secondes pour RootDistanceMaxSec sera utilisée sur les nœuds, au lieu de 20 secondes, qui devrait être la configuration attendue. Si vous vérifiez le journal de démarrage du nœud en vous connectant à la VM via SSH, qui se trouve dans/var/log/startup.log, vous pouvez trouver l'erreur suivante:
+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found
L'utilisation d'un RootDistanceMaxSec de 5 secondes peut entraîner la désynchronisation de l'horloge système avec le serveur NTP lorsque la dérive de l'horloge est supérieure à 5 secondes.
Solution :
Appliquez le DaemonSet suivant à votre cluster pour configurer RootDistanceMaxSec :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-root-distance
namespace: kube-system
spec:
selector:
matchLabels:
app: change-root-distance
template:
metadata:
labels:
app: change-root-distance
spec:
hostIPC: true
hostPID: true
tolerations:
# Make sure pods gets scheduled on all nodes.
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
containers:
- name: change-root-distance
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
echo "timesyncd has the expected RootDistanceMaxSec, skip update"
else
echo "updating timesyncd config to RootDistanceMaxSec=20"
mkdir -p /etc/systemd/timesyncd.conf.d
cat > $conf_file << EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Mises à niveau, mises à jour |
1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Échec de gkectl update admin en raison d'un champ osImageType vide
Lorsque vous utilisez la version 1.13 de gkectl pour mettre à jour un cluster d'administrateur de la version 1.12, l'erreur suivante peut s'afficher:
Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"
Lorsque vous utilisez gkectl update admin pour les clusters des versions 1.13 ou 1.14, le message suivant peut s'afficher dans la réponse:
Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time
Si vous consultez le journal gkectl , vous constaterez peut-être que les modifications multiples incluent le passage de la chaîne vide osImageType à ubuntu_containerd .
Ces erreurs de mise à jour sont dues à un remplissage incorrect du champ osImageType dans la configuration du cluster d'administrateur depuis son introduction dans la version 1.9.
Solution :
Passez à une version de Google Distributed Cloud contenant le correctif. Si la mise à niveau n'est pas possible pour vous, contactez l'assistance Cloud Customer Care pour résoudre ce problème.
|
Installation, sécurité |
1.13, 1.14, 1.15, 1.16 |
Le SNI ne fonctionne pas sur les clusters d'utilisateurs avec Controlplane V2
La possibilité de fournir un certificat de diffusion supplémentaire pour le serveur d'API Kubernetes d'un cluster d'utilisateurs avec
authentication.sni ne fonctionne pas lorsque le plan de contrôle V2 est activé (
enableControlplaneV2: true ).
Solution :
Tant qu'un correctif Google Distributed Cloud n'est pas disponible, si vous devez utiliser le SNI, désactivez Controlplane V2 (enableControlplaneV2: false ).
|
Installation |
1.0 à 1.11, 1.12, 1.13.0 à 1.13.9, 1.14.0 à 1.14.5, 1.15.0 à 1.15.1 |
$ dans le nom d'utilisateur du registre privé entraîne un échec du démarrage de la machine du plan de contrôle administrateur
La machine du plan de contrôle d'administration ne démarre pas lorsque le nom d'utilisateur du registre privé contient $ .
Lorsque vous vérifiez /var/log/startup.log sur la machine du plan de contrôle d'administration, l'erreur suivante s'affiche:
++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable
Solution :
Utilisez un nom d'utilisateur de registre privé sans $ ou une version de Google Distributed Cloud avec le correctif.
|
Mises à niveau, mises à jour |
1.12.0-1.12.4 |
Avertissements de faux positifs concernant les modifications non prises en charge lors de la mise à jour du cluster d'administrateur
Lorsque vous
mettez à jour des clusters d'administrateur, les avertissements de faux positifs suivants s'affichent dans le journal. Vous pouvez les ignorer.
console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
...
- CARotation: &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
+ CARotation: nil,
...
}
|
Mises à niveau, mises à jour |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Échec de la mise à jour du cluster d'utilisateur après la rotation de la clé de signature KSA
Après avoir roté les clés de signature KSA, puis
mis à jour un cluster d'utilisateurs, gkectl update peut échouer avec le message d'erreur suivant:
Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"
Solution :
Rétablissez la version 1 de votre clé de signature KSA, mais conservez les dernières données de clé :
- Vérifiez le secret dans le cluster d'administrateur sous l'espace de noms
USER_CLUSTER_NAME , puis obtenez le nom du secret ksa-signing-key:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
- Copiez le secret ksa-signing-key et nommez-le "service-account-cert" :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
- Supprimez le secret de clé de signature ksa précédent:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
- Modifiez le champ
data.data dans le ConfigMap ksa-signing-key-rotation-stage sur '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
- Désactivez le webhook de validation pour modifier les informations de version dans la ressource personnalisée OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremuserclusters
'
- Remplacez le champ
spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation par 1 dans votre ressource personnalisée OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
- Attendez que le cluster d'utilisateurs cible soit prêt. Pour vérifier son état, procédez comme suit:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
- Restaurez le webhook de validation pour le cluster d'utilisateur:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremuserclusters
'
- Évitez une autre rotation de clé de signature KSA tant que le cluster n'est pas mis à niveau vers la version contenant le correctif.
|
Opération |
1.13.1+, 1.14, 1., 1.16 |
Lorsque vous utilisez Terraform pour supprimer un cluster utilisateur avec un équilibreur de charge F5 BIG-IP, les serveurs virtuels F5 BIG-IP ne sont pas supprimés après la suppression du cluster.
Solution :
Pour supprimer les ressources F5, suivez la procédure de nettoyage de la partition F5 d'un cluster d'utilisateur
. |
Installation, mises à niveau, mises à jour |
1.13.8, 1.14.4 |
Le cluster kind extrait les images de conteneur de docker.io .
Si vous créez un cluster d'administrateur version 1.13.8 ou 1.14.4, ou si vous mettez à niveau un cluster d'administrateur vers la version 1.13.8 ou 1.14.4, le cluster de type extrait les images de conteneur suivantes à partir de docker.io :
docker.io/kindest/kindnetd
docker.io/kindest/local-path-provisioner
docker.io/kindest/local-path-helper
Si docker.io n'est pas accessible depuis votre poste de travail administrateur, la création ou la mise à niveau du cluster d'administrateur ne permet pas d'afficher le cluster de type.
L'exécution de la commande suivante sur le poste de travail administrateur affiche les conteneurs correspondants en attente avec ErrImagePull :
docker exec gkectl-control-plane kubectl get pods -A
La réponse contient des entrées comme suit:
...
kube-system kindnet-xlhmr 0/1
ErrImagePull 0 3m12s
...
local-path-storage local-path-provisioner-86666ffff6-zzqtp 0/1
Pending 0 3m12s
...
Ces images de conteneur doivent être préchargées dans l'image de conteneur de cluster de type. Toutefois, kind v0.18.0 présente un problème avec les images de conteneur préchargées, ce qui entraîne leur extraction d'Internet par erreur.
Solution :
Exécutez les commandes suivantes sur le poste de travail administrateur, pendant que la création ou la mise à niveau de votre cluster d'administrateur est en attente:
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
|
Opération |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
Échec du basculement sur le cluster utilisateur et le cluster d'administrateur Controlplane V2 HA lorsque le réseau filtre les requêtes GARP en double
Si les VM de votre cluster sont connectées à un commutateur qui filtre les requêtes GARP (ARP gratuit) en double, l'élection du leader keepalived peut rencontrer une condition de course, ce qui entraîne des entrées de table ARP incorrectes pour certains nœuds.
Les nœuds concernés peuvent ping l'adresse IP virtuelle du plan de contrôle, mais une connexion TCP à l'adresse IP virtuelle du plan de contrôle expirera.
Solution :
Exécutez la commande suivante sur chaque nœud du plan de contrôle du cluster concerné:
iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
|
Mises à niveau, mises à jour |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
vsphere-csi-controller doit être redémarré après la rotation du certificat vCenter
vsphere-csi-controller doit actualiser son secret vCenter après la rotation du certificat vCenter. Toutefois, le système actuel ne redémarre pas correctement les pods de vsphere-csi-controller , ce qui entraîne le plantage de vsphere-csi-controller après la rotation.
Solution :
Pour les clusters créés avec la version 1.13 ou ultérieure, suivez les instructions ci-dessous pour redémarrer vsphere-csi-controller .
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
|
Installation |
1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1 |
La création du cluster d'administrateur ne provoque pas d'erreurs d'enregistrement du cluster.
Même si l'enregistrement du cluster échoue lors de la création du cluster d'administrateur, la commande gkectl create admin n'échoue pas en raison de l'erreur et peut réussir. En d'autres termes, la création du cluster d'administrateur peut "réussir" sans être enregistrée dans un parc.
Pour identifier le symptôme, vous pouvez rechercher les messages d'erreur suivants dans le journal de "gkectl create admin" :
Failed to register admin cluster
Vous pouvez également vérifier si le cluster figure parmi les clusters enregistrés dans la console Cloud.
Solution :
Pour les clusters créés avec la version 1.12 ou ultérieure, suivez les instructions pour réessayer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters créés avec des versions antérieures :
-
Ajoutez une fausse paire clé-valeur telle que "foo: bar" à votre fichier de clé SA connect-register.
-
Exécutez
gkectl update admin pour réenregistrer le cluster d'administrateur.
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13.0-1.13.1 |
Le réenregistrement du cluster d'administrateur peut être ignoré lors de la mise à niveau du cluster d'administrateur
Lors de la mise à niveau du cluster d'administrateur, si la mise à niveau des nœuds du plan de contrôle de l'utilisateur expire, le cluster d'administrateur n'est pas réenregistré avec la version mise à jour de l'agent de connexion.
Solution :
Vérifiez si le cluster apparaît parmi les clusters enregistrés.
(Étape facultative) Connectez-vous au cluster après avoir configuré l'authentification. Si le cluster est toujours enregistré, vous pouvez ignorer les instructions suivantes pour réessayer l'enregistrement.
Pour les clusters mis à niveau vers la version 1.12 ou ultérieure, suivez les instructions pour réessayer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters mis à niveau vers des versions antérieures,
-
Ajoutez une fausse paire clé-valeur telle que "foo: bar" à votre fichier de clé SA connect-register.
-
Exécutez
gkectl update admin pour réenregistrer le cluster d'administrateur.
|
Configuration |
1.15.0 |
Message d'erreur incorrect concernant vCenter.dataDisk
Pour un cluster d'administrateur haute disponibilité, gkectl prepare affiche ce faux message d'erreur:
vCenter.dataDisk must be present in the AdminCluster spec
Solution :
Vous pouvez ignorer ce message d'erreur en toute sécurité.
|
VMware |
1.15.0 |
Échec de la création du pool de nœuds en raison de règles d'affinité VM-hôte redondantes
Lors de la création d'un pool de nœuds qui utilise l'affinité VM-hôte, une condition de course peut entraîner la création de plusieurs règles d'affinité VM-hôte portant le même nom. Cela peut entraîner l'échec de la création du pool de nœuds.
Solution :
Supprimez les anciennes règles redondantes pour que la création du pool de nœuds puisse se poursuivre.
Ces règles sont nommées [USER_CLUSTER_NAME]-[HASH].
|
Opération |
1.15.0 |
gkectl repair admin-master peut échouer en raison de failed
to delete the admin master node object and reboot the admin master VM
La commande gkectl repair admin-master peut échouer en raison d'une condition de concurrence avec l'erreur suivante.
Failed to repair: failed to delete the admin master node object and reboot the admin master VM
Solution :
Cette commande est idempotente. Il peut être réexécuté en toute sécurité jusqu'à ce que la commande aboutisse.
|
Mises à niveau, mises à jour |
1.15.0 |
Les pods restent en état "Failed" (Échec) après la recréation ou la mise à jour d'un nœud de plan de contrôle
Après avoir recréer ou mis à jour un nœud de plan de contrôle, certains pods peuvent rester à l'état Failed en raison d'une défaillance du prédicat NodeAffinity. Ces pods défaillants n'affectent pas le fonctionnement normal du cluster ni son état.
Solution :
Vous pouvez ignorer les pods ayant échoué ou les supprimer manuellement.
|
Sécurité, configuration |
1.15.0-1.15.1 |
OnPremUserCluster n'est pas prêt en raison d'identifiants de registre privé
Si vous utilisez des identifiants préparés et un registre privé, mais que vous n'avez pas configuré d'identifiants préparés pour votre registre privé, le cluster d'utilisateurs OnPremUserCluster risque de ne pas être prêt, et le message d'erreur suivant peut s'afficher:
failed to check secret reference for private registry …
Solution :
Préparez les identifiants du registre privé pour le cluster d'utilisateur en suivant les instructions de la section Configurer des identifiants préparés.
|
Mises à niveau, mises à jour |
1.15.0 |
Lors de gkectl upgrade admin , la vérification préalable du stockage pour la migration CSI vérifie que les StorageClasses ne comportent pas de paramètres ignorés après la migration CSI.
Par exemple, si une StorageClass est associée au paramètre diskformat , gkectl upgrade admin signale la StorageClass et signale une erreur lors de la validation préalable.
Les clusters d'administrateur créés dans Google Distributed Cloud 1.10 et versions antérieures disposent d'une classe StorageClass avec diskformat: thin , ce qui entraîne l'échec de cette validation. Toutefois, cette classe StorageClass fonctionne toujours correctement après la migration CSI. Ces échecs doivent plutôt être interprétés comme des avertissements.
Pour en savoir plus, consultez la section sur le paramètre StorageClass dans Migrer des volumes vSphere dans l'arborescence vers le plug-in de stockage de conteneurs vSphere.
Solution :
Après avoir vérifié que votre cluster comporte une StorageClass avec des paramètres ignorés après la migration CSI, exécutez gkectl upgrade admin avec l'indicateur --skip-validation-cluster-health .
|
Stockage |
1.15, 1.16 |
Les volumes vSphere "in-tree" migrés à l'aide du système de fichiers Windows ne peuvent pas être utilisés avec le pilote CSI vSphere.
Dans certaines conditions, les disques peuvent être associés en lecture seule aux nœuds Windows. Le volume correspondant est alors en lecture seule dans un pod.
Ce problème est plus susceptible de se produire lorsqu'un nouvel ensemble de nœuds remplace un ancien ensemble de nœuds (par exemple, lors de la mise à niveau d'un cluster ou de la mise à jour d'un pool de nœuds). Les charges de travail avec état qui fonctionnaient auparavant correctement peuvent ne pas pouvoir écrire dans leurs volumes sur le nouvel ensemble de nœuds.
Solution :
-
Obtenez l'UID du pod qui ne parvient pas à écrire sur son volume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
POD_NAME --namespace POD_NAMESPACE \
-o=jsonpath='{.metadata.uid}{"\n"}'
-
Utilisez l'objet PersistentVolumeClaim pour obtenir le nom du PersistentVolume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
PVC_NAME --namespace POD_NAMESPACE \
-o jsonpath='{.spec.volumeName}{"\n"}'
-
Identifiez le nom du nœud sur lequel le pod s'exécute:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
--namespace POD_NAMESPACE \
-o jsonpath='{.spec.nodeName}{"\n"}'
-
Obtenez un accès powershell au nœud, soit via SSH, soit via l'interface Web vSphere.
-
Définissez les variables d'environnement :
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- Identifiez le numéro de disque associé au PersistentVolume:
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
-
Vérifiez que le disque est
readonly :
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
Le résultat doit être True .
- Définissez
readonly sur false .
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
-
Supprimez le pod pour qu'il redémarre:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
--namespace POD_NAMESPACE
-
Le pod doit être planifié sur le même nœud. Toutefois, si le pod est planifié sur un nouveau nœud, vous devrez peut-être répéter les étapes précédentes sur le nouveau nœud.
|
Mises à niveau, mises à jour |
1.12, 1.13.0-1.13.7, 1.14.0-1.14.4 |
vsphere-csi-secret n'est pas mis à jour après gkectl update credentials vsphere --admin-cluster
Si vous mettez à jour les identifiants vSphere d'un cluster d'administrateur après avoir mis à jour les identifiants du cluster, il est possible que vsphere-csi-secret sous l'espace de noms kube-system du cluster d'administrateur utilise toujours les anciens identifiants.
Solution :
- Obtenez le nom du secret
vsphere-csi-secret :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
- Mettez à jour les données du secret
vsphere-csi-secret que vous avez obtenu à l'étape précédente:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
"{\"data\":{\"config\":\"$( \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
| base64 -d \
| sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
| sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
| base64 -w 0 \
)\"}}"
- Redémarrez
vsphere-csi-controller :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
- Vous pouvez suivre l'état du déploiement à l'aide des éléments suivants:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
Une fois le déploiement terminé, le contrôleur doit utiliser la vsphere-csi-secret mise à jour.
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Boucle de plantage audit-proxy lors de l'activation des journaux d'audit Cloud avec gkectl update cluster
audit-proxy peut entrer dans une boucle de plantage en raison d'un --cluster-name vide.
Ce comportement est dû à un bug dans la logique de mise à jour, où le nom du cluster n'est pas propagé dans le fichier manifeste du pod / conteneur audit-proxy.
Solution :
Pour un cluster d'utilisateurs ControlPlane V2 avec enableControlplaneV2: true , connectez-vous à la machine du plan de contrôle de l'utilisateur à l'aide de SSH, puis mettez à jour /etc/kubernetes/manifests/audit-proxy.yaml avec --cluster_name=USER_CLUSTER_NAME .
Pour un cluster d'utilisateurs du plan de contrôle v1, modifiez le conteneur audit-proxy dans le statefulset kube-apiserver pour ajouter --cluster_name=USER_CLUSTER_NAME :
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
|
Mises à niveau, mises à jour |
1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Redéploiement supplémentaire du plan de contrôle juste après gkectl upgrade cluster
Immédiatement après gkectl upgrade cluster , les pods du plan de contrôle peuvent être redéployés.
L'état du cluster gkectl list clusters est passé de RUNNING à RECONCILING .
Les requêtes envoyées au cluster d'utilisateurs peuvent expirer.
Ce comportement est dû au fait que la rotation des certificats du plan de contrôle se produit automatiquement après gkectl upgrade cluster .
Ce problème ne se produit que pour les clusters d'utilisateurs qui n'utilisent PAS le plan de contrôle V2.
Solution :
Attendez que l'état du cluster revienne à RUNNING dans gkectl list clusters ou passez à une version avec le correctif: 1.13.6 ou version ultérieure, 1.14.2 ou version ultérieure ou 1.15 ou version ultérieure.
|
Mises à niveau, mises à jour |
1.12.7 |
La version incorrecte 1.12.7-gke.19 a été supprimée
Google Distributed Cloud 1.12.7-gke.19 est une version défectueuse et vous ne devez pas l'utiliser. Les artefacts ont été supprimés du bucket Cloud Storage.
Solution :
Utilisez plutôt la version 1.12.7-gke.20.
|
Mises à niveau, mises à jour |
1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3 |
gke-connect-agent
continue d'utiliser l'ancienne image après la mise à jour des identifiants du registre
Si vous mettez à jour les identifiants du Registre à l'aide de l'une des méthodes suivantes:
gkectl update credentials componentaccess si vous n'utilisez pas de registre privé
gkectl update credentials privateregistry si vous utilisez un registre privé
Il est possible que gke-connect-agent continue d'utiliser l'ancienne image ou que les pods gke-connect-agent ne puissent pas être récupérés en raison de ImagePullBackOff .
Ce problème sera résolu dans les versions Google Distributed Cloud 1.13.8, 1.14.4 et ultérieures.
Solution :
Option 1: Redéployer gke-connect-agent manuellement:
- Supprimez l'espace de noms
gke-connect :
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- Redéployer
gke-connect-agent avec la clé de compte de service du registre d'origine (pas besoin de mettre à jour la clé):
Pour le cluster d'administrateur:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
Pour le cluster d'utilisateur:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Option 2: Vous pouvez modifier manuellement les données du secret de récupération d'image regcred utilisé par le déploiement gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"
Option 3: vous pouvez ajouter le secret de récupération d'image par défaut de votre cluster dans le déploiement gke-connect-agent en procédant comme suit:
- Copiez le secret par défaut dans l'espace de noms
gke-connect :
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
- Obtenez le nom du déploiement
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
- Ajoutez le secret par défaut au déploiement
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
|
Installation |
1.13, 1.14 |
Échec de la vérification manuelle de la configuration du LB
Lorsque vous validez la configuration avant de créer un cluster avec un équilibreur de charge manuel en exécutant gkectl check-config , la commande échoue et les messages d'erreur suivants s'affichent.
- Validation Category: Manual LB Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference
Solution :
Option 1: Vous pouvez utiliser les versions de correctif 1.13.7 et 1.14.4, qui incluent le correctif.
Option 2: Vous pouvez également exécuter la même commande pour valider la configuration, mais ignorer la validation de l'équilibreur de charge.
gkectl check-config --skip-validation-load-balancer
|
Opération |
1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 et 1.14 |
Déséquilibre de la surveillance etcd
Les clusters exécutant la version 3.4.13 d'etcd ou une version antérieure peuvent rencontrer des problèmes de manque de surveillance et de surveillance des ressources non opérationnelles, ce qui peut entraîner les problèmes suivants:
- La planification des pods est perturbée
- Les nœuds ne peuvent pas s'enregistrer
- kubelet n'observe pas les modifications de pod
Ces problèmes peuvent rendre le cluster inutilisable.
Ce problème est résolu dans les versions Google Distributed Cloud 1.12.7, 1.13.6, 1.14.3 et versions ultérieures. Ces versions plus récentes utilisent la version 3.4.21 d'etcd. Toutes les versions précédentes de Google Distributed Cloud sont concernées par ce problème.
Solution
Si vous ne pouvez pas effectuer la mise à niveau immédiatement, vous pouvez réduire le risque de défaillance du cluster en réduisant le nombre de nœuds de votre cluster. Supprimez des nœuds jusqu'à ce que la métrique etcd_network_client_grpc_sent_bytes_total soit inférieure à 300 Mo/s.
Pour afficher cette métrique dans l'explorateur de métriques:
- Accédez à l'explorateur de métriques dans la console Google Cloud:
Accéder à l'explorateur de métriques
- Accédez à l'onglet Configuration.
- Développez Sélectionner une métrique, saisissez
Kubernetes Container dans la barre de filtre, puis utilisez les sous-menus pour sélectionner la métrique :
- Dans le menu Ressources actives, sélectionnez Conteneur Kubernetes.
- Dans le menu Catégories de métriques actives, sélectionnez Anthos.
- Dans le menu Métriques actives, sélectionnez
etcd_network_client_grpc_sent_bytes_total .
- Cliquez sur Appliquer.
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 et 1.14 |
GKE Identity Service peut entraîner des latences du plan de contrôle
Lors des redémarrages ou des mises à niveau du cluster, GKE Identity Service peut être submergé par le trafic constitué de jetons JWT expirés transférés de kube-apiserver vers GKE Identity Service via le webhook d'authentification. Bien que GKE Identity Service ne soit pas en boucle de plantage, il ne répond plus et cesse de répondre aux requêtes ultérieures.
Ce problème entraîne finalement des latences plus élevées du plan de contrôle.
Ce problème est résolu dans les versions suivantes de Google Distributed Cloud:
- 1.12.6 et versions ultérieures
- 1.13.6 et versions ultérieures
- 1.14.2 et versions ultérieures
Pour savoir si vous êtes concerné par ce problème, procédez comme suit:
- Vérifiez si le point de terminaison GKE Identity Service est accessible en externe:
curl -s -o /dev/null -w "%{http_code}" \
-X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
Remplacez CLUSTER_ENDPOINT par l'adresse IP virtuelle et le port de l'équilibreur de charge du plan de contrôle de votre cluster (par exemple, 172.16.20.50:443 ).
Si vous êtes concerné par ce problème, la commande renvoie un code d'état 400 . Si la requête expire, redémarrez le pod ais et exécutez à nouveau la commande curl pour voir si le problème est résolu. Si vous obtenez un code d'état 000 , le problème est résolu et vous pouvez passer à l'étape suivante. Si vous recevez toujours un code d'état 400 , le serveur HTTP de GKE Identity Service ne démarre pas. Dans ce cas, continuez.
- Vérifiez les journaux de GKE Identity Service et de kube-apiserver :
- Consultez le journal de GKE Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
Si le journal contient une entrée semblable à celle-ci, vous êtes concerné par ce problème:
I0811 22:32:03.583448 32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
- Vérifiez les journaux
kube-apiserver de vos clusters:
Dans les commandes suivantes, KUBE_APISERVER_POD est le nom du pod kube-apiserver du cluster donné.
Cluster d'administrateur :
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n kube-system KUBE_APISERVER_POD kube-apiserver
Cluster d'utilisateur :
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver
Si les journaux kube-apiserver contiennent des entrées comme celles-ci, vous êtes concerné par ce problème:
E0811 22:30:22.656085 1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"
Solution
Si vous ne pouvez pas mettre à niveau vos clusters immédiatement pour obtenir le correctif, vous pouvez identifier et redémarrer les pods concernés en guise de solution de contournement:
- Augmentez le niveau de verbosité de GKE Identity Service à 9:
kubectl patch deployment ais -n anthos-identity-service --type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
"value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
--kubeconfig KUBECONFIG
- Recherchez le contexte de jeton non valide dans le journal de GKE Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
- Pour obtenir la charge utile du jeton associée à chaque contexte de jeton non valide, analysez chaque secret de compte de service associé à l'aide de la commande suivante:
kubectl -n kube-system get secret SA_SECRET \
--kubeconfig KUBECONFIG \
-o jsonpath='{.data.token}' | base64 --decode
- Pour décoder le jeton et afficher le nom et l'espace de noms du pod source, copiez le jeton dans le débogueur sur jwt.io.
- Redémarrez les pods identifiés à partir des jetons.
|
Opération |
1.8, 1.9, 1.10 |
Problème d'augmentation de l'utilisation de la mémoire des pods etcd-maintenance
Les pods de maintenance etcd qui utilisent l'image etcddefrag:gke_master_etcddefrag_20210211.00_p0 sont concernés. Le conteneur "etcddefrag" ouvre une nouvelle connexion au serveur etcd à chaque cycle de défragmentation, et les anciennes connexions ne sont pas nettoyées.
Solution :
Option 1: Mettez à niveau la version de correctif de la version 1.8 vers la version 1.11, qui contient le correctif.
Option 2: Si vous utilisez une version de correctif antérieure à 1.9.6 et 1.10.3, vous devez réduire la taille du pod etcd-maintenance pour le cluster d'administrateur et le cluster d'utilisateur:
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Opération |
1.9, 1.10, 1.11, 1.12, 1.13 |
Ignorer les vérifications d'état des pods du plan de contrôle du cluster utilisateur
Le contrôleur de l'état du cluster et la commande gkectl diagnose cluster effectuent un ensemble de vérifications de l'état, y compris des vérifications de l'état des pods dans les espaces de noms. Cependant, il commence à ignorer les pods du plan de contrôle utilisateur par erreur. Si vous utilisez le mode v2 du plan de contrôle, cela n'affectera pas votre cluster.
Solution :
Cela n'aura aucune incidence sur la gestion des charges de travail ni des clusters. Si vous souhaitez vérifier l'état des pods du plan de contrôle, vous pouvez exécuter les commandes suivantes:
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Mises à niveau, mises à jour |
1.6+, 1.7+ |
La redirection k8s.gcr.io -> registry.k8s.io peut affecter les mises à niveau des clusters d'administrateur 1.6 et 1.7
Kubernetes a redirigé le trafic de k8s.gcr.io vers registry.k8s.io le 20/03/2023. Dans Google Distributed Cloud 1.6.x et 1.7.x, les mises à niveau du cluster d'administrateur utilisent l'image de conteneur k8s.gcr.io/pause:3.2 . Si vous utilisez un proxy pour votre poste de travail administrateur et que le proxy n'autorise pas registry.k8s.io et que l'image de conteneur k8s.gcr.io/pause:3.2 n'est pas mise en cache localement, les mises à niveau du cluster d'administration échoueront lors de l'extraction de l'image de conteneur.
Solution :
Ajoutez registry.k8s.io à la liste d'autorisation du proxy pour votre poste de travail administrateur.
|
Mise en réseau |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Échec de la validation Seesaw lors de la création de l'équilibreur de charge
gkectl create loadbalancer échoue avec le message d'erreur suivant:
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host
Cela est dû au fait que le fichier de groupe Seesaw existe déjà. La vérification préliminaire tente de valider un équilibreur de charge à bascule inexistant.
Solution :
Supprimez le fichier de groupe Seesaw existant pour ce cluster. Le nom du fichier est seesaw-for-gke-admin.yaml pour le cluster d'administrateur et seesaw-for-{CLUSTER_NAME}.yaml pour un cluster d'utilisateur.
|
Mise en réseau |
1,14 |
Expirations de délai de l'application causées par les échecs d'insertion de la table conntrack
La version 1.14 de Google Distributed Cloud est susceptible d'échecs d'insertion de tables Netfilter Connection Tracking (conntrack) lors de l'utilisation d'images de système d'exploitation Ubuntu ou COS. Les échecs d'insertion entraînent des expirations de délai d'application aléatoires et peuvent se produire même lorsque la table conntrack dispose de place pour de nouvelles entrées. Les échecs sont dus à des modifications apportées au noyau 5.15 et aux versions ultérieures qui limitent les insertions de table en fonction de la longueur de chaîne.
Pour savoir si vous êtes concerné par ce problème, vous pouvez vérifier les statistiques du système de suivi de la connexion au noyau sur chaque nœud à l'aide de la commande suivante:
sudo conntrack -S
La réponse est semblable à ce qui suit :
cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...
Si une valeur chaintoolong dans la réponse est un nombre différent de zéro, vous êtes concerné par ce problème.
Solution
À court terme, vous pouvez augmenter la taille de la table de hachage Netfilter (nf_conntrack_buckets ) et de la table de suivi des connexions Netfilter (nf_conntrack_max ). Pour ce faire, exécutez les commandes suivantes sur chaque nœud de cluster:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Remplacez TABLE_SIZE par la nouvelle taille en octets. La valeur par défaut de la taille de table est 262144 . Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs du nœud. Par exemple, si votre nœud comporte huit cœurs, définissez la taille de la table sur 524288 .
|
Mise en réseau |
1.13.0-1.13.2 |
Boucle de plantage de calico-typha ou de l'opérateur anetd sur les nœuds Windows avec Controlplane V2
Lorsque
Controlplane V2 est activé, calico-typha ou anetd-operator peuvent être planifiés sur des nœuds Windows et entrer dans une boucle de plantage.
En effet, les deux déploiements tolèrent tous les taints, y compris le taint de nœud Windows.
Solution :
Passez à la version 1.13.3 ou exécutez les commandes suivantes pour modifier le déploiement de "calico-typha" ou "anetd-operator" :
# If dataplane v2 is not used.
kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
# If dataplane v2 is used.
kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
Supprimez les spec.template.spec.tolerations suivants:
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
Ajoutez la tolérance suivante:
- key: node-role.kubernetes.io/master
operator: Exists
|
Configuration |
1.14.0-1.14.2 |
Impossible de charger le fichier d'identifiants de registre privé du cluster d'utilisateur
Vous ne pourrez peut-être pas créer de cluster d'utilisateurs si vous spécifiez la section privateRegistry avec les identifiants fileRef .
La vérification préliminaire peut échouer avec le message suivant:
[FAILURE] Docker registry access: Failed to login.
Solution :
- Si vous n'aviez pas l'intention de spécifier le champ ou si vous souhaitez utiliser les mêmes identifiants de registre privé que le cluster d'administrateur, vous pouvez simplement supprimer ou commenter la section
privateRegistry dans le fichier de configuration de votre cluster d'utilisateur.
- Si vous souhaitez utiliser des identifiants de registre privé spécifiques pour votre cluster d'utilisateurs, vous pouvez spécifier temporairement la section
privateRegistry comme suit:
privateRegistry:
address: PRIVATE_REGISTRY_ADDRESS
credentials:
username: PRIVATE_REGISTRY_USERNAME
password: PRIVATE_REGISTRY_PASSWORD
caCertPath: PRIVATE_REGISTRY_CACERT_PATH
(REMARQUE: Il ne s'agit que d'une solution temporaire. Ces champs sont déjà obsolètes. Envisagez d'utiliser le fichier d'identifiants lors de la mise à niveau vers la version 1.14.3 ou ultérieure.)
|
Opérations |
1.10+ |
Cloud Service Mesh et d'autres services de mesh non compatibles avec Dataplane V2
Dataplane V2 prend en charge l'équilibrage de charge et crée un socket de kernel au lieu d'un DNAT basé sur les paquets. Cela signifie que Cloud Service Mesh ne peut pas effectuer d'inspection des paquets, car le pod est contourné et n'utilise jamais IPTables.
En mode kube-proxy libre, cela se traduit par une perte de connectivité ou un routage incorrect du trafic pour les services avec Cloud Service Mesh, car le sidecar ne peut pas effectuer d'inspection des paquets.
Ce problème est présent dans toutes les versions de Google Distributed Cloud 1.10. Toutefois, certaines versions plus récentes de la version 1.10 (1.10.2 et versions ultérieures) proposent une solution de contournement.
Solution :
Passez à la version 1.11 pour une compatibilité totale ou, si vous exécutez la version 1.10.2 ou ultérieure, exécutez la commande suivante:
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
Ajoutez bpf-lb-sock-hostns-only: true au fichier ConfigMap, puis redémarrez le DaemonSet anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
|
Stockage |
1.12+, 1.13.3 |
kube-controller-manager peut dissocier de force les volumes persistants au bout de six minutes
kube-controller-manager peut expirer lors de la dissociation des PV/PVC après six minutes et les dissocier de force. Les journaux détaillés de kube-controller-manager affichent des événements semblables à ceux-ci:
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
Pour vérifier le problème, connectez-vous au nœud et exécutez les commandes suivantes:
# See all the mounting points with disks
lsblk -f
# See some ext4 errors
sudo dmesg -T
Dans le journal kubelet, des erreurs telles que les suivantes s'affichent:
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
Solution :
Connectez-vous au nœud concerné à l'aide de SSH, puis redémarrez-le.
|
Mises à niveau, mises à jour |
1.12+, 1.13+, 1.14+ |
La mise à niveau du cluster est bloquée si un pilote CSI tiers est utilisé
Vous ne pourrez peut-être pas mettre à niveau un cluster si vous utilisez un pilote CSI tiers. La commande gkectl cluster diagnose peut renvoyer l'erreur suivante:
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
Solution :
Effectuez la mise à niveau à l'aide de l'option --skip-validation-all .
|
Opération |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+ |
gkectl repair admin-master crée la VM principale administrateur sans mettre à niveau sa version matérielle
Le nœud maître administrateur créé via gkectl repair admin-master peut utiliser une version matérielle de VM inférieure à celle attendue. Lorsque le problème se produit, l'erreur s'affiche dans le rapport gkectl diagnose cluster .
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.
Solution :
Arrêtez le nœud maître administrateur, suivez https://kb.vmware.com/s/article/1003746 pour mettre à niveau le nœud vers la version attendue décrite dans le message d'erreur, puis démarrez-le.
|
Système d'exploitation |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+ |
La VM libère le bail DHCP lors de l'arrêt/du redémarrage de manière inattendue, ce qui peut entraîner des modifications d'adresse IP
Dans systemd v244, systemd-networkd subit un changement de comportement par défaut sur la configuration KeepConfiguration . Avant cette modification, les VM n'envoyaient pas de message de libération de bail DHCP au serveur DHCP lors de l'arrêt ou du redémarrage. Après ce changement, les VM envoient un tel message et renvoient les adresses IP au serveur DHCP. Par conséquent, l'adresse IP libérée peut être réallouée à une autre VM et/ou une autre adresse IP peut être attribuée à la VM, ce qui entraîne un conflit d'adresse IP (au niveau de Kubernetes, et non de vSphere) et/ou un changement d'adresse IP sur les VM, ce qui peut endommager les clusters de différentes manières.
Vous pouvez par exemple constater les symptômes suivants.
- L'interface utilisateur de vCenter indique qu'aucune VM n'utilise la même adresse IP, mais
kubectl get
nodes -o wide renvoie des nœuds avec des adresses IP en double.
NAME STATUS AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node1 Ready 28h v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
node2 NotReady 71d v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
- Échec du démarrage des nouveaux nœuds en raison d'une erreur
calico-node
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
Solution :
Déployez le DaemonSet suivant sur le cluster pour revenir à l'ancien comportement par défaut de systemd-networkd . Les VM qui exécutent ce DaemonSet ne libèrent pas les adresses IP au serveur DHCP lors de l'arrêt/du redémarrage. Les adresses IP seront libérées automatiquement par le serveur DHCP à l'expiration des baux.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-dhcp-on-stop
spec:
selector:
matchLabels:
name: set-dhcp-on-stop
template:
metadata:
labels:
name: set-dhcp-on-stop
spec:
hostIPC: true
hostPID: true
hostNetwork: true
containers:
- name: set-dhcp-on-stop
image: ubuntu
tty: true
command:
- /bin/bash
- -c
- |
set -x
date
while true; do
export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
if (( $? != 0 )) ; then
echo "Setting KeepConfiguration=dhcp-on-stop"
sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
cat "${CONFIG}"
chroot /host systemctl restart systemd-networkd
else
echo "KeepConfiguration=dhcp-on-stop has already been set"
fi;
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "5m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
tolerations:
- operator: Exists
effect: NoExecute
- operator: Exists
effect: NoSchedule
|
Opération, Mises à niveau, Mises à jour |
1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Clé du compte de service d'accès au composant effacée après la mise à niveau du cluster d'administration depuis la version 1.11.x
Ce problème ne concerne que les clusters d'administrateur mis à niveau à partir de la version 1.11.x et n'affecte pas les clusters d'administrateur créés après la version 1.12.
Après avoir mis à niveau un cluster 1.11.x vers la version 1.12.x, le champ component-access-sa-key du secret admin-cluster-creds sera effacé.
Pour vérifier cela, exécutez la commande suivante:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
Si la sortie est vide, cela signifie que la clé a été effacée.
Une fois la clé du compte de service d'accès au composant supprimée, l'installation de nouveaux clusters d'utilisateurs ou la mise à niveau de clusters d'utilisateurs existants échouera. Voici quelques messages d'erreur que vous pouvez rencontrer:
- Échec de la validation lente avec le message d'erreur suivant:
"Failed
to create the test VMs: failed to get service account key: service
account is not configured."
- Échec de la préparation par
gkectl prepare avec le message d'erreur suivant :
"Failed to prepare OS images: dialing: unexpected end of JSON
input"
- Si vous mettez à niveau un cluster d'utilisateurs 1.13 à l'aide de la console Google Cloud ou de la CLI gcloud, lorsque vous exécutez
gkectl update admin --enable-preview-user-cluster-central-upgrade pour déployer le contrôleur de plate-forme de mise à niveau, la commande échoue avec le message suivant: "failed to download bundle to disk: dialing:
unexpected end of JSON input" (vous pouvez voir ce message dans le champ status dans la sortie de kubectl --kubeconfig
ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml ).
Solution :
Ajoutez manuellement la clé du compte de service d'accès du composant dans le secret en exécutant la commande suivante:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
|
Opération |
1.13.0+, 1.14.0+ |
L'autoscaler de cluster ne fonctionne pas lorsque Controlplane V2 est activé
Pour les clusters d'utilisateurs créés avec Controlplane V2 activé, les pools de nœuds avec autoscaling activé utilisent toujours leur autoscaling.minReplicas dans le user-cluster.yaml . Le journal du pod cluster-autoscaler affiche une erreur semblable à la suivante:
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
TIMESTAMP 1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
Pour trouver le pod de l'autoscaler de cluster, exécutez les commandes suivantes.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c 4648017n 48076Ki 30s
Solution :
Désactivez l'autoscaling dans tous les pools de nœuds avec "gkectl update cluster" jusqu'à ce que vous passiez à une version contenant le correctif.
|
Installation |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
Le routage CIDR n'est pas autorisé dans le fichier de bloc d'adresses IP.
Lorsque les utilisateurs utilisent le routage CIDR dans le fichier de bloc IP, la validation de la configuration échoue et renvoie l'erreur suivante:
- Validation Category: Config Check
- [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
Solution :
Incluez des adresses IP individuelles dans le fichier de blocage des adresses IP jusqu'à ce que vous passiez à une version avec le correctif: 1.12.5, 1.13.4, 1.14.1 ou version ultérieure.
|
Mises à niveau, mises à jour |
1.14.0-1.14.1 |
La mise à jour du type d'image de l'OS dans le fichier admin-cluster.yaml n'attend pas la recréation des machines du plan de contrôle de l'utilisateur
Lorsque vous modifiez le type d'image de l'OS du plan de contrôle dans le fichier admin-cluster.yaml et si le cluster d'utilisateur correspondant a été créé via Controlplane V2, la recréation des machines du plan de contrôle de l'utilisateur peut ne pas être terminée lorsque la commande gkectl se termine.
Solution :
Une fois la mise à jour terminée, attendez que les machines du plan de contrôle de l'utilisateur aient également terminé leur recréation en surveillant les types d'images d'OS de leurs nœuds à l'aide de kubectl --kubeconfig USER_KUBECONFIG get nodes -owide . Par exemple, si vous passez d'Ubuntu à COS, vous devez attendre que toutes les machines du plan de contrôle passent complètement d'Ubuntu à COS, même après la fin de la commande de mise à jour.
|
Opération |
1.10, 1.11, 1.12, 1.13, 1.14.0 |
Erreurs de création ou de suppression de pod en raison d'un problème de jeton d'authentification du compte de service CNI Calico
Un problème avec Calico dans Google Distributed Cloud 1.14.0 entraîne l'échec de la création et de la suppression de pod avec le message d'erreur suivant dans la sortie de kubectl describe pods :
error getting ClusterInformation: connection is unauthorized: Unauthorized
Ce problème ne se produit que 24 heures après la création du cluster ou la mise à niveau vers la version 1.14 à l'aide de Calico.
Les clusters d'administrateur utilisent toujours Calico, tandis que pour le cluster d'utilisateur, il existe un champ de configuration "enableDataPlaneV2" dans user-cluster.yaml. Si ce champ est défini sur "false" ou n'est pas spécifié, cela signifie que vous utilisez Calico dans le cluster d'utilisateur.
Le conteneur install-cni des nœuds crée un kubeconfig avec un jeton valide pendant 24 heures. Ce jeton doit être régulièrement renouvelé par le pod calico-node . Le pod calico-node ne peut pas renouveler le jeton, car il n'a pas accès au répertoire contenant le fichier kubeconfig sur le nœud.
Solution :
Ce problème a été résolu dans la version 1.14.1 de Google Distributed Cloud. Mettez à niveau vers cette version ou une version ultérieure.
Si vous ne pouvez pas effectuer la mise à niveau immédiatement, appliquez le correctif suivant au DaemonSet calico-node dans votre cluster administrateur et votre cluster utilisateur:
kubectl -n kube-system get daemonset calico-node \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -
kubectl -n kube-system get daemonset calico-node \
--kubeconfig USER_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
USER_CLUSTER_CONFIG_FILE : chemin d'accès au fichier de configuration du cluster d'utilisateur
|
Installation |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
Échec de la validation du bloc d'adresses IP lorsque vous utilisez le routage CIDR
La création du cluster échoue, même si l'utilisateur dispose de la configuration appropriée. L'utilisateur constate que la création échoue, car le cluster ne dispose pas d'adresses IP suffisantes.
Solution :
Divisez les CIDR en plusieurs blocs CIDR plus petits, par exemple 10.0.0.0/30 devient 10.0.0.0/31, 10.0.0.2/31 . Tant qu'il y a N + 1 CIDR, où N correspond au nombre de nœuds du cluster, cela devrait suffire.
|
Opération, Mises à niveau, Mises à jour |
1.11.0 à 1.11.1, 1.10.0 à 1.10.4, 1.9.0 à 1.9.6 |
La sauvegarde du cluster d'administrateur n'inclut pas les clés de chiffrement des secrets toujours activés ni leur configuration
Lorsque la fonctionnalité de chiffrement des secrets toujours activés est activée avec la sauvegarde du cluster, la sauvegarde du cluster d'administrateur n'inclut pas les clés de chiffrement et la configuration requises par la fonctionnalité de chiffrement des secrets toujours activés. Par conséquent, la réparation du maître administrateur avec cette sauvegarde à l'aide de gkectl repair admin-master --restore-from-backup entraîne l'erreur suivante:
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Solution :
- Utilisez le binaire gkectl de la dernière version de correctif disponible pour la version mineure correspondante pour effectuer la sauvegarde du cluster d'administrateur après des opérations de cluster critiques. Par exemple, si le cluster exécute la version 1.10.2, utilisez le binaire gkectl 1.10.5 pour effectuer une sauvegarde manuelle du cluster d'administrateur, comme décrit dans la section Sauvegarder et restaurer un cluster d'administrateur avec gkectl.
|
Opération, Mises à niveau, Mises à jour |
1.10+ |
Recréer la VM maître administrateur avec un nouveau disque de démarrage (par exemple, gkectl repair admin-master ) échouera si la fonctionnalité de chiffrement des secrets toujours activés est activée à l'aide de la commande gkectl update.
Si la fonctionnalité de chiffrement permanent des secrets n'est pas activée lors de la création du cluster, mais qu'elle l'est par la suite à l'aide de l'opération gkectl update , gkectl repair admin-master ne parvient pas à réparer le nœud du plan de contrôle du cluster d'administrateur. Nous vous recommandons d'activer la fonctionnalité de chiffrement des secrets toujours activés lors de la création du cluster. Il n'existe actuellement aucune mesure d'atténuation.
|
Mises à niveau, mises à jour |
1.10 |
La mise à niveau du premier cluster d'utilisateur de la version 1.9 vers la version 1.10 recrée des nœuds dans d'autres clusters d'utilisateurs
La mise à niveau du premier cluster d'utilisateurs de la version 1.9 vers la version 1.10 peut recréer des nœuds dans d'autres clusters d'utilisateurs du même cluster d'administrateur. La recréation est effectuée de manière progressive.
Le disk_label a été supprimé de MachineTemplate.spec.template.spec.providerSpec.machineVariables , ce qui a déclenché une mise à jour inattendue de tous les MachineDeployment .
Solution :
Afficher les étapes de la solution de contournement
|
Mises à niveau, mises à jour |
1.10.0 |
Docker redémarre fréquemment après la mise à niveau du cluster
La mise à niveau du cluster d'utilisateur vers la version 1.10.0 peut entraîner des redémarrages fréquents de Docker.
Vous pouvez détecter ce problème en exécutant kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG .
Une condition de nœud indique si le docker redémarre fréquemment. Voici un exemple de résultat:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Pour identifier l'origine du problème, vous devez vous connecter en SSH au nœud présentant le symptôme et exécuter des commandes telles que sudo journalctl --utc -u docker ou sudo journalctl -x .
Solution :
|
Mises à niveau, mises à jour |
1.11, 1.12 |
Les composants GMP auto-déployés ne sont pas conservés après la mise à niveau vers la version 1.12
Si vous utilisez une version de Google Distributed Cloud antérieure à la version 1.12 et que vous avez configuré manuellement des composants Prometheus gérés par Google (GMP) dans l'espace de noms gmp-system pour votre cluster, ils ne sont pas conservés lorsque vous passez à la version 1.12.x.
À partir de la version 1.12, les composants GMP de l'espace de noms gmp-system et des CRD sont gérés par l'objet stackdriver , avec l'indicateur enableGMPForApplications défini sur false par défaut. Si vous déployez manuellement des composants GMP dans l'espace de noms avant la mise à niveau vers la version 1.12, les ressources seront supprimées par stackdriver .
Solution :
|
Opération |
1.11, 1.12, 1.13.0 à 1.13.1 |
Objets ClusterAPI manquants dans le scénario system d'instantané de cluster
Dans le scénario system , l'instantané du cluster n'inclut aucune ressource dans l'espace de noms default .
Toutefois, certaines ressources Kubernetes, comme les objets Cluster API situés dans cet espace de noms, contiennent des informations de débogage utiles. L'instantané du cluster doit les inclure.
Solution :
Vous pouvez exécuter manuellement les commandes suivantes pour collecter les informations de débogage.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
où:
USER_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'utilisateur.
|
Mises à niveau, mises à jour |
1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1 |
La suppression du cluster d'utilisateur est bloquée à l'étape de vidage des nœuds pour la configuration vSAN
Lorsque vous supprimez, mettez à jour ou mettez à niveau un cluster d'utilisateur, l'épuisement des nœuds peut se bloquer dans les scénarios suivants:
- Le cluster administrateur utilise le pilote CSI vSphere sur vSAN depuis la version 1.12.x, et
- Aucun objet PVC/PV n'est créé par les plug-ins vSphere dans l'arborescence dans le cluster d'administrateur et d'utilisateur.
Pour identifier le symptôme, exécutez la commande ci-dessous:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Voici un exemple de message d'erreur de la commande ci-dessus:
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols est le répertoire par défaut du pilote vSphere "in-tree". Si aucun objet PVC/PV n'est créé, vous pouvez rencontrer un bug qui empêche le vidage du nœud de trouver kubevols , car l'implémentation actuelle suppose que kubevols existe toujours.
Solution :
Créez le répertoire kubevols dans le datastore dans lequel le nœud est créé. Ce paramètre est défini dans le champ vCenter.datastore des fichiers user-cluster.yaml ou admin-cluster.yaml .
|
Configuration |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14 |
Les éléments clusterrolebinding et clusterrole Cluster Autoscaler sont supprimés après la suppression d'un cluster d'utilisateur.
Lors de la suppression d'un cluster d'utilisateur, les clusterrole et clusterrolebinding correspondants pour cluster-autoscaler sont également supprimés. Cela affecte tous les autres clusters d'utilisateurs du même cluster d'administrateur sur lequel l'autoscaler de cluster est activé. En effet, le même clusterrole et le même clusterrolebinding sont utilisés pour tous les pods de l'autoscaler de cluster du même cluster d'administrateur.
Voici les symptômes:
- Journaux
cluster-autoscaler
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler , où ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur.
Voici quelques exemples de messages d'erreur que vous pouvez rencontrer:
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463 1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494 1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
Solution :
Afficher la procédure de dépannage
Vérifier si le clusterrole et le clusterrolebinding sont manquants sur le cluster d'administrateur
-
kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
-
kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
Appliquez le clusterrole et le clusterrolebinding suivants au cluster d'administrateur s'ils sont manquants. Ajoutez les sujets du compte de service au clusterrolebinding pour chaque cluster d'utilisateurs.
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
resources: ["clusters"]
verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
resources: ["onpremuserclusters"]
verbs: ["get", "list", "watch"]
- apiGroups:
- coordination.k8s.io
resources:
- leases
resourceNames: ["cluster-autoscaler"]
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
- ""
resources:
- pods
verbs: ["get", "list", "watch"]
- apiGroups:
- ""
resources:
- pods/eviction
verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["daemonsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
resources: ["poddisruptionbudgets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cluster-autoscaler-status"]
verbs: ["get", "update", "patch", "delete"]
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: cluster-autoscaler
name: cluster-autoscaler
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-autoscaler
subjects:
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_1
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_2
...
|
Configuration |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
Les commandes cluster-health-controller et vsphere-metrics-exporter du cluster d'administration ne fonctionnent pas après la suppression du cluster d'utilisateur
Lors de la suppression d'un cluster d'utilisateur, le clusterrole correspondant est également supprimé, ce qui entraîne l'arrêt de la réparation automatique et de l'exportateur de métriques vSphere.
Voici les symptômes:
- Journaux
cluster-health-controller
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller , où ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur.
Voici quelques exemples de messages d'erreur que vous pouvez rencontrer:
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
- Journaux
vsphere-metrics-exporter
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter , où ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur.
Voici quelques exemples de messages d'erreur que vous pouvez rencontrer:
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
Solution :
Afficher la procédure de dépannage
Appliquez le code YAML suivant au cluster d'administrateur.
- Pour vsphere-metrics-exporter
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: vsphere-metrics-exporter
rules:
- apiGroups:
- cluster.k8s.io
resources:
- clusters
verbs: [get, list, watch]
- apiGroups:
- ""
resources:
- nodes
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: vsphere-metrics-exporter
name: vsphere-metrics-exporter
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vsphere-metrics-exporter
subjects:
- kind: ServiceAccount
name: vsphere-metrics-exporter
namespace: kube-system
- Pour cluster-health-controller
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-health-controller-role
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
|
Configuration |
1.12.1 à 1.12.3, 1.13.0 à 1.13.2 |
Échec de la validation de l'image de l'OS par gkectl check-config
Problème connu pouvant entraîner l'échec de gkectl check-config sans exécuter gkectl prepare . Cela peut prêter à confusion, car nous vous recommandons d'exécuter la commande avant d'exécuter gkectl prepare .
Le problème est que la commande gkectl check-config échoue et affiche le message d'erreur suivant:
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}
Solution :
Option 1: exécutez gkectl prepare pour importer les images d'OS manquantes.
Option 2: Utilisez gkectl check-config --skip-validation-os-images pour ignorer la validation des images du système d'exploitation.
|
Mises à niveau, mises à jour |
1.11, 1.12, 1.13 |
Échec de la mise à jour des groupes d'anti-affinité avec gkectl update admin/cluster
Correction d'un problème connu pouvant entraîner l'échec de gkectl update admin/cluster lors de la mise à jour de anti affinity groups .
Le problème est que la commande gkectl update échoue et affiche le message d'erreur suivant:
Waiting for machines to be re-deployed... ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition
Solution :
Afficher les étapes de la solution de contournement
Pour que la mise à jour prenne effet, les machines doivent être recréées after la mise à jour ayant échoué.
Pour mettre à jour le cluster d'administrateur, les nœuds maître d'utilisateur et de modules complémentaires d'administrateur doivent être recréés.
Pour mettre à jour un cluster d'utilisateur, les nœuds de calcul de l'utilisateur doivent être recréés.
Pour recréer des nœuds de calcul utilisateur
Option 1 Dans la version 1.11 de la documentation, suivez la procédure Mettre à jour un pool de nœuds et modifiez le processeur ou la mémoire pour déclencher une recréation progressive des nœuds.
Option 2 Utiliser la commande kubectl delete pour recréer les machines une par une
kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG
Pour recréer des nœuds maîtres utilisateur
Option 1 Dans la version 1.11 de la documentation, suivez la procédure Redimensionner le plan de contrôle et modifiez le processeur ou la mémoire pour déclencher une recréation progressive des nœuds.
Option 2 Utiliser la commande kubectl delete pour recréer les machines une à une
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
Pour recréer des nœuds de module complémentaire d'administrateur
Utiliser kubectl delete pour recréer les machines une à une
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
Installation, mises à niveau, mises à jour |
1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0 |
L'enregistrement des nœuds échoue lors de la création, de la mise à niveau et de la mise à jour du cluster, ainsi que lors de la réparation automatique des nœuds, lorsque ipMode.type est static et que le nom d'hôte configuré dans le fichier de blocs d'adresses IP contient une ou plusieurs périodes. Dans ce cas, les requêtes de signature de certificat (CSR) pour un nœud ne sont pas automatiquement approuvées.
Pour afficher les CSR en attente pour un nœud, exécutez la commande suivante:
kubectl get csr -A -o wide
Recherchez des messages d'erreur dans les journaux suivants:
- Affichez les journaux du cluster d'administration pour le conteneur
clusterapi-controller-manager dans le pod clusterapi-controllers :
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n kube-system \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
- Pour afficher les mêmes journaux dans le cluster d'utilisateur, exécutez la commande suivante:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
où :
- ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur.
- USER_CLUSTER_NAME est le nom du cluster d'utilisateur.
Voici quelques exemples de messages d'erreur que vous pouvez rencontrer: "msg"="failed
to validate token id" "error"="failed to find machine for node
node-worker-vm-1" "validate"="csr-5jpx9"
- Affichez les journaux
kubelet sur le nœud problématique:
journalctl --u kubelet
Voici un exemple de message d'erreur que vous pouvez rencontrer: "Error getting
node" err="node \"node-worker-vm-1\" not found"
Si vous spécifiez un nom de domaine dans le champ "nom d'hôte" d'un fichier de blocage d'adresses IP, tous les caractères qui suivent le premier point seront ignorés. Par exemple, si vous spécifiez le nom d'hôte comme bob-vm-1.bank.plc , le nom d'hôte et le nom de nœud de la VM seront définis sur bob-vm-1 .
Lorsque la validation de l'ID de nœud est activée, l'approbateur de la demande de certification s'assure que le nom du nœud correspond au nom d'hôte dans les spécifications de la machine, mais ne parvient pas à concilier le nom. L'approbateur rejette la CSR, et le nœud ne parvient pas à démarrer.
Solution :
Cluster d'utilisateur
Pour désactiver la validation de l'ID de nœud, procédez comme suit:
- Ajoutez les champs suivants dans votre fichier de configuration du cluster d'utilisateur:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- Enregistrez le fichier, puis mettez à jour le cluster d'utilisateur en exécutant la commande suivante:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
USER_CLUSTER_CONFIG_FILE : chemin d'accès au fichier de configuration du cluster d'utilisateur
Cluster d'administrateur
- Ouvrez la ressource personnalisée
OnPremAdminCluster pour la modifier:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit onpremadmincluster -n kube-system
- Ajoutez l'annotation suivante à la ressource personnalisée:
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
- Modifiez le fichier manifeste
kube-controller-manager dans le plan de contrôle du cluster d'administrateur :
- Connectez-vous en SSH au nœud du plan de contrôle du cluster d'administrateur.
- Ouvrez le fichier manifeste
kube-controller-manager pour le modifier:
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
- Recherchez la liste des
controllers :
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Mettez à jour cette section comme indiqué ci-dessous:
--controllers=*,bootstrapsigner,tokencleaner
- Ouvrez le contrôleur d'API Cluster de déploiement pour le modifier:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit deployment clusterapi-controllers -n kube-system
- Remplacez les valeurs de
node-id-verification-enabled et node-id-verification-csr-signing-enabled par false :
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
|
Installation, mises à niveau, mises à jour |
1.11.0-1.11.4 |
Échec du démarrage de la machine du plan de contrôle administrateur causé par le bundle de certificats du registre privé
La création/mise à niveau du cluster d'administrateur est bloquée sur le journal suivant pour toujours et finit par expirer:
Waiting for Machine gke-admin-master-xxxx to become ready...
Dans la version 1.11 de la documentation, le journal du contrôleur de l'API Cluster dans l'
instantané de cluster externe inclut le journal suivant:
Invalid value 'XXXX' specified for property startup-data
Voici un exemple de chemin d'accès au journal du contrôleur de l'API Cluster:
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
VMware has a 64k vApp property size limit. In the identified versions,
the data passed via vApp property is close to the limit. When the private
registry certificate contains a certificate bundle, it may cause the final
data to exceed the 64k limit.
Workaround:
Only include the required certificates in the private registry
certificate file configured in privateRegistry.caCertPath in
the admin cluster config file.
Or upgrade to a version with the fix when available.
|
Networking |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayNodes marked unhealthy from concurrent
status update conflict
In networkgatewaygroups.status.nodes , some nodes switch
between NotHealthy and Up .
Logs for the ang-daemon Pod running on that node reveal
repeated errors:
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}
L'état NotHealthy empêche le contrôleur d'attribuer des adresses IP flottantes supplémentaires au nœud. Cela peut entraîner une charge plus élevée sur d'autres nœuds ou un manque de redondance pour une haute disponibilité.
L'activité du plan de données n'est pas affectée.
La contention sur l'objet networkgatewaygroup entraîne l'échec de certaines mises à jour d'état en raison d'un défaut de gestion des nouvelles tentatives. Si trop de mises à jour d'état échouent, ang-controller-manager considère que le nœud a dépassé la limite de temps de battement et le marque comme NotHealthy .
Le problème de gestion des nouvelles tentatives a été corrigé dans les versions ultérieures.
Solution :
Passez à une version corrigée, le cas échéant.
|
Mises à niveau, mises à jour |
1.12.0-1.12.2, 1.13.0 |
Une condition de concurrence bloque la suppression d'objets machine lors de la mise à jour ou de la mise à niveau
Problème connu pouvant entraîner la mise à niveau ou la mise à jour du cluster en attente de la suppression de l'ancien objet machine. En effet, le finaliseur ne peut pas être supprimé de l'objet machine. Cela affecte toute opération de mise à jour progressive pour les pools de nœuds.
Le problème est que la commande gkectl expire avec le message d'erreur suivant:
E0821 18:28:02.546121 61942 console.go:87] Exit with error:
E0821 18:28:02.546184 61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Dans les journaux du pod clusterapi-controller , les erreurs se présentent comme suit:
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
-c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
| grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993 1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
L'erreur se répète pour la même machine pendant plusieurs minutes pour les exécutions réussies, même sans ce problème. Dans la plupart des cas, elle peut être traitée rapidement, mais dans de rares cas, elle peut rester bloquée sur cette condition de course pendant plusieurs heures.
Le problème est que la VM sous-jacente est déjà supprimée dans vCenter, mais que l'objet machine correspondant ne peut pas être supprimé, ce qui est bloqué à la suppression du finaliseur en raison de mises à jour très fréquentes d'autres contrôleurs.
Cela peut entraîner l'expiration de la commande gkectl , mais le contrôleur continue de réconcilier le cluster afin que le processus de mise à niveau ou de mise à jour se termine.
Solution :
Nous avons préparé plusieurs options d'atténuation pour ce problème, en fonction de votre environnement et de vos exigences.
- Option 1: Attendez que la mise à niveau se termine d'elle-même.
En fonction de l'analyse et de la reproduction dans votre environnement, la mise à niveau peut éventuellement se terminer d'elle-même, sans intervention manuelle. L'inconvénient de cette option est qu'il est difficile de savoir combien de temps la suppression du finaliseur prendra pour chaque objet machine. Il peut être traité immédiatement si vous avez de la chance, ou durer plusieurs heures si la réconciliation du contrôleur de machineset est trop rapide et que le contrôleur de machineset n'a jamais la possibilité de supprimer le finaliseur entre les réconciliations.
L'avantage de cette option est qu'aucune action de votre part n'est requise, et que les charges de travail ne sont pas perturbées. La migration prend juste plus de temps.
- Option 2: Appliquez l'annotation de réparation automatique à tous les anciens objets de machine.
Le contrôleur de machineset filtre les machines dont l'annotation de réparation automatique et le code temporel de suppression ne sont pas nuls, et n'émet pas d'appels de suppression sur ces machines. Cela peut aider à éviter les conditions de concurrence.
L'inconvénient est que les pods sur les machines seront supprimés directement au lieu d'être évincés, ce qui signifie qu'ils ne respecteront pas la configuration du PDB, ce qui peut entraîner des temps d'arrêt pour vos charges de travail.
Commande permettant d'obtenir tous les noms de machine:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
Commande permettant d'appliquer l'annotation de réparation automatique à chaque machine:
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
machine MACHINE_NAME \
onprem.cluster.gke.io/repair-machine=true
Si vous rencontrez ce problème et que la mise à niveau ou la mise à jour ne peut toujours pas être effectuée au bout d'un certain temps, contactez notre équipe d'assistance pour obtenir des solutions.
|
Installation, mises à niveau, mises à jour |
1.10.2, 1.11, 1.12, 1.13 |
Échec de la validation préalable de l'image système gkectl
Échec de la commande gkectl prepare avec:
- Validation Category: OS Images
- [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
Les vérifications préliminaires de gkectl prepare incluaient une validation incorrecte.
Solution :
Exécutez la même commande avec un indicateur supplémentaire --skip-validation-os-images .
|
Installation |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
L'URL vCenter avec un préfixe https:// ou http:// peut entraîner un échec du démarrage du cluster
Échec de la création du cluster d'administrateur avec:
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
L'URL est utilisée dans une clé secrète, qui n'est pas compatible avec "/" ou ":".
Solution :
Supprimez le préfixe https:// ou http:// du champ vCenter.Address dans le fichier YAML de configuration du cluster d'administrateur ou du cluster d'utilisateur.
|
Installation, mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 |
Erreur de gkectl prepare sur util.CheckFileExists
gkectl prepare peut subir une panique avec la trace de la pile suivante:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]
goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...
Le problème est que gkectl prepare a créé le répertoire de certificats de registre privé avec une autorisation incorrecte.
Solution :
Pour résoudre ce problème, exécutez les commandes suivantes sur le poste de travail administrateur:
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 |
gkectl repair admin-master et la mise à niveau de l'administrateur avec reprise ne fonctionnent pas ensemble
Après une tentative de mise à niveau du cluster d'administrateur ayant échoué, n'exécutez pas gkectl
repair admin-master . Cela peut entraîner l'échec des tentatives de mise à niveau ultérieures de l'administrateur en raison de problèmes tels que l'échec de la mise sous tension de l'administrateur maître ou l'inaccessibilité de la VM.
Solution :
Si vous avez déjà rencontré ce scénario d'échec, contactez l'assistance.
|
Mises à niveau, mises à jour |
1.10, 1.11 |
La reprise de la mise à niveau du cluster administrateur peut entraîner l'absence du modèle de VM du plan de contrôle administrateur
Si la machine du plan de contrôle administrateur n'est pas recréée après une tentative de mise à niveau du cluster administrateur reprise, le modèle de VM du plan de contrôle administrateur est supprimé. Le modèle de VM de plan de contrôle administrateur est le modèle du maître administrateur utilisé pour récupérer la machine de plan de contrôle avec gkectl
repair admin-master .
Solution :
Le modèle de VM de plan de contrôle administrateur sera régénéré lors de la prochaine mise à niveau du cluster administrateur.
|
Système d'exploitation |
1.12, 1.13 |
cgroup v2 peut affecter les charges de travail
Dans la version 1.12.0, cgroup v2 (unifié) est activé par défaut pour les nœuds COS (Container-Optimized OS). Cela peut entraîner une instabilité de vos charges de travail dans un cluster COS.
Solution :
Nous sommes revenus à cgroup v1 (hybride) dans la version 1.12.1. Si vous utilisez des nœuds COS, nous vous recommandons de passer à la version 1.12.1 dès qu'elle sera disponible.
|
Identité |
1.10, 1.11, 1.12, 1.13 |
Ressource personnalisée ClientConfig
gkectl update rétablit les modifications manuelles que vous avez apportées à la ressource personnalisée ClientConfig.
Solution :
Nous vous recommandons vivement de sauvegarder la ressource ClientConfig après chaque modification manuelle.
|
Installation |
1.10, 1.11, 1.12, 1.13 |
Échec de la validation de gkectl check-config : impossible de trouver les partitions F5 BIG-IP
La validation échoue, car les partitions F5 BIG-IP sont introuvables, même si elles existent.
Un problème avec l'API F5 BIG-IP peut entraîner l'échec de la validation.
Solution :
Essayez d'exécuter gkectl check-config à nouveau.
|
Installation |
1.12 |
Échec de l'installation du cluster utilisateur en raison du problème d'élection du responsable cert-manager/ca-injector
Une erreur d'installation peut survenir en raison de la boucle de plantage cert-manager-cainjector lorsque l'apiserver/etcd est lent:
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
cert-manager-cainjector-xxx`
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
Solution :
Afficher la procédure de dépannage
Exécutez les commandes suivantes pour atténuer le problème.
Effectuez d'abord un scaling à la baisse de monitoring-operator afin qu'il n'annule pas les modifications apportées au déploiement cert-manager :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Modifiez le déploiement cert-manager-cainjector pour désactiver l'élection du responsable, car une seule instance dupliquée est en cours d'exécution. L'élection n'est pas nécessaire pour une instance dupliquée unique:
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
-n kube-system deployment cert-manager-cainjector
L'extrait de code YAML pertinent pour le déploiement de cert-manager-cainjector doit se présenter comme suit:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --leader-elect=false
...
Conservez les instances dupliquées monitoring-operator à 0 comme solution d'atténuation jusqu'à la fin de l'installation. Sinon, la modification sera annulée.
Une fois l'installation terminée et le cluster opérationnel, activez monitoring-operator pour les opérations à J+2:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Après chaque mise à niveau, les modifications sont annulées. Effectuez à nouveau les mêmes étapes pour atténuer le problème jusqu'à ce qu'il soit résolu dans une version ultérieure.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Redémarrer ou mettre à niveau vCenter pour les versions antérieures à la version 7.0U2
Si vCenter, pour les versions antérieures à 7.0U2, est redémarré, après une mise à niveau ou autre, le nom de réseau dans les informations de VM de vCenter est incorrect et la machine présente un état Unavailable . Cela entraîne la réparation automatique des nœuds pour en créer de nouveaux.
Bug govmomi associé
Solution :
Cette solution est fournie par l'assistance VMware :
- Ce problème est résolu dans les versions 7.0U2 et ultérieures de vCenter.
- Pour les versions antérieures, effectuez un clic droit sur l'hôte, puis sélectionnez Connection > Disconnect (Connexion > Déconnecter). Ensuite, reconnectez-vous, ce qui force une mise à jour du portgroup de la VM.
|
Système d'exploitation |
1.10, 1.11, 1.12, 1.13 |
Connexion SSH fermée par l'hôte distant
Pour Google Distributed Cloud version 1.7.2 et ultérieure, les images de l'OS Ubuntu sont renforcées avec le
benchmark CIS L1 Server.
Pour respecter la règle CIS "5.2.16 Vérifier que le délai d'inactivité de la connexion SSH est configuré", /etc/ssh/sshd_config a les paramètres suivants:
ClientAliveInterval 300
ClientAliveCountMax 0
Le but de ces paramètres est de mettre fin à une session client après cinq minutes d'inactivité. Cependant, la valeur ClientAliveCountMax 0 entraîne un comportement inattendu. Lorsque vous utilisez la session SSH sur le poste de travail administrateur ou un nœud de cluster, la connexion SSH peut être déconnectée même si votre client SSH n'est pas inactif, par exemple lors de l'exécution d'une commande chronophage, et votre commande peut être interrompue avec le message suivant:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Solution :
Vous pouvez utiliser l'une de ces deux méthodes :
- Utilisez
nohup pour éviter que votre commande soit interrompue lors d'une déconnexion SSH.
nohup gkectl upgrade admin --config admin-cluster.yaml \
--kubeconfig kubeconfig
- Mettez à jour
sshd_config pour utiliser une valeur ClientAliveCountMax différente de zéro. La règle CIS recommande d'utiliser une valeur inférieure à 3:
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
/etc/ssh/sshd_config
sudo systemctl restart sshd
Veillez à reconnecter votre session SSH.
|
Installation |
1.10, 1.11, 1.12, 1.13 |
Installation cert-manager en conflit
Dans les versions 1.13, monitoring-operator installera cert-manager dans l'espace de noms cert-manager . Si, pour certaines raisons, vous devez installer votre propre cert-manager, suivez les instructions ci-dessous pour éviter tout conflit:
Vous n'avez besoin d'effectuer cette opération qu'une seule fois pour chaque cluster, et les modifications seront conservées lors de la mise à niveau du cluster.
Remarque: L'un des symptômes courants de l'installation de votre propre cert-manager est que la version ou l'image de cert-manager (par exemple, v1.7.2) peut revenir à son ancienne version. Cela est dû au fait que monitoring-operator tente de rapprocher le cert-manager et d'annuler la version au cours du processus.
Solution :
<pÉviter les conflits lors de la mise à niveau
- Désinstallez votre version de
cert-manager . Si vous avez défini vos propres ressources, vous pouvez les sauvegarder
.
- Procédez à la mise à niveau.
- Suivez les instructions ci-dessous pour restaurer votre propre
cert-manager .
Restaurer votre propre cert-manager dans les clusters d'utilisateur
- Effectuez le scaling du déploiement
monitoring-operator à 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Effectuez le scaling des déploiements
cert-manager gérés par monitoring-operator à 0:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector\
--replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook --replicas=0
- Réinstallez votre version de
cert-manager .
Restaurez vos ressources personnalisées, le cas échéant.
- Vous pouvez ignorer cette étape si vous utilisez l'
installation de cert-manager par défaut en amont, ou si vous êtes sûr que cert-manager est installé dans l'espace de noms
cert-manager .
Sinon, copiez le certificat metrics-ca cert-manager.io/v1 et les ressources émettrices metrics-pki.cluster.local depuis cert-manager vers l'espace de noms des ressources de cluster de votre cert-manager installé.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
Restaurer votre propre cert-manager dans les clusters d'administrateur
En général, vous n'avez pas besoin de réinstaller cert-manager dans les clusters d'administrateur, car les clusters d'administrateur n'exécutent que des charges de travail de plan de contrôle Google Distributed Cloud. Dans les rares cas où vous devez également installer votre propre cert-manager dans des clusters d'administrateur, suivez les instructions ci-dessous pour éviter tout conflit. Veuillez noter que si vous êtes un client Apigee et que vous avez besoin de cert-manager uniquement pour Apigee, vous n'avez pas besoin d'exécuter les commandes du cluster d'administrateur.
- Effectuez le scaling du déploiement
monitoring-operator à 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n kube-system scale deployment monitoring-operator --replicas=0
- Effectuez le scaling des déploiements
cert-manager gérés par monitoring-operator à 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook \
--replicas=0
- Réinstallez votre version de
cert-manager .
Restaurez vos ressources personnalisées, le cas échéant.
- Vous pouvez ignorer cette étape si vous utilisez l'
installation de cert-manager par défaut en amont, ou si vous êtes sûr que cert-manager est installé dans l'espace de noms
cert-manager .
Sinon, copiez le certificat metrics-ca cert-manager.io/v1 et les ressources émettrices metrics-pki.cluster.local depuis cert-manager vers l'espace de noms des ressources de cluster de votre cert-manager installé.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
</p |
Système d'exploitation |
1.10, 1.11, 1.12, 1.13 |
Faux positifs lors de l'analyse des failles docker, containerd et runc
Les conteneurs Docker, containerd et runc des images d'OS Ubuntu fournies avec Google Distributed Cloud sont rattachés aux versions spéciales à l'aide de Ubuntu PPA. Cela garantit que tout changement d'environnement d'exécution des conteneurs sera qualifié par Google Distributed Cloud avant chaque publication de version.
Cependant, les versions spéciales ne sont pas connues de l'outil de suivi CVE d'Ubuntu, qui est utilisé comme flux concernant les failles par divers outils d'analyse CVE. Par conséquent, vous observerez des faux positifs dans les résultats d'analyse des failles Docker, containerd et runc.
Par exemple, il est possible que les faux positifs ci-dessous apparaissent dans les résultats de l'analyse CVE. Ces failles CVE sont déjà corrigées dans les dernières versions corrigées de Google Distributed Cloud.
Reportez-vous aux notes de version pour obtenir les correctifs CVE.
Solution :
Canonical est informé de ce problème et le correctif est disponible à l'adresse
https://github.com/canonical/sec-cvescan/issues/73.
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 |
La connexion réseau entre le cluster d'administrateur et le cluster d'utilisateur peut être indisponible pendant une courte période lors de la mise à niveau d'un cluster standard.
Si vous mettez à niveau des clusters standards de la version 1.9 à la version 1.10, vous remarquerez peut-être que les commandes kubectl exec , kubectl log et webhook sur les clusters d'utilisateur peuvent être indisponibles pendant une courte période. Ce temps d'arrêt peut durer jusqu'à une minute. Cela se produit parce que la requête entrante (kubectl exec, kubectl log et webhook) est gérée par kube-apiserver pour le cluster d'utilisateur. L'utilisateur kube-apiserver est un
ensemble avec état. Dans un cluster standard, il n'existe qu'une seule instance dupliquée pour l'ensemble avec état. Lors de la mise à niveau, il est possible que l'ancien kube-apiserver soit indisponible alors que le nouveau kube-apiserver n'est pas encore prêt.
Solution :
Ce temps d'arrêt ne se produit que pendant le processus de mise à niveau. Si vous souhaitez obtenir un temps d'arrêt plus court pendant la mise à niveau, nous vous recommandons de passer à des clusters à haute disponibilité.
|
Installation, mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 |
Échec de la vérification de préparation de Konnectivity lors du diagnostic d'un cluster à haute disponibilité après la création ou la mise à niveau du cluster
Si vous créez ou mettez à niveau un cluster à haute disponibilité et que la vérification de la préparation des nœuds a échoué lors du diagnostic du cluster, dans la plupart des cas, cela n'affectera pas les fonctionnalités de Google Distributed Cloud (kubectl exec, kubectl log et webhook). Cela se produit parce qu'une ou deux des instances konnectivity dupliquées peuvent parfois ne pas être prêtes pendant un certain temps en raison d'une mise en réseau instable ou d'autres problèmes.
Solution :
L'instance konnectivity se rétablira seule. Patientez 30 minutes à 1 heure, puis relancez le diagnostic du cluster.
|
Système d'exploitation |
1.7, 1.8, 1.9, 1.10, 1.11 |
/etc/cron.daily/aide Problème de pic de mémoire et de processeur
À partir de la version 1.7.2 de Google Distributed Cloud, les images d'OS Ubuntu sont renforcées avec le benchmark CIS L1 Server.
Le script Cron /etc/cron.daily/aide a donc été installé. Il permet de programmer une vérification aide pour garantir que la règle CIS L1 Server "1.4.2 Ensure filesystem integrity is regularly checked" (S'assurer que l'intégrité du système de fichiers est régulièrement contrôlée) est appliquée.
La tâche Cron s'exécute tous les jours à 6h25 UTC. Selon le nombre de fichiers sur le système de fichiers, vous pouvez rencontrer des pics d'utilisation du processeur et de la mémoire autour de cette période, en raison du processus aide .
Solution :
Si les pics affectent votre charge de travail, vous pouvez désactiver la tâche Cron quotidienne:
sudo chmod -x /etc/cron.daily/aide
|
Mise en réseau |
1.10, 1.11, 1.12, 1.13 |
Les équilibreurs de charge et les règles de pare-feu distribuées avec état NSX-T interagissent de manière imprévisible.
Lors du déploiement de la version 1.9 ou ultérieure de Google Distributed Cloud, lorsque le déploiement comporte l'équilibreur de charge groupé Seesaw dans un environnement qui utilise des règles de pare-feu distribuées avec état NSX-T, stackdriver-operator peut ne pas réussir à créer gke-metrics-agent-conf ConfigMap et entraîner gke-connect-agent à se retrouver bloqué dans une boucle de plantage.
Le problème sous-jacent est que les règles de pare-feu distribuées avec état NSX-T mettent fin à la connexion d'un client au serveur d'API du cluster d'utilisateur via l'équilibreur de charge Seesaw, car Seesaw utilise des flux de connexion asymétriques. Les problèmes d'intégration avec les règles de pare-feu distribuées NSX-T affectent toutes les versions de Google Distributed Cloud qui utilisent Seesaw. Vous pouvez rencontrer des problèmes de connexion similaires sur vos propres applications lorsqu'elles créent des objets Kubernetes de grande taille, supérieure à 32 Ko.
Solution :
Dans la version 1.13 de la documentation, suivez
ces instructions pour désactiver les règles de pare-feu distribuées NSX-T ou pour utiliser des règles de pare-feu distribuées sans état pour les VM Seesaw.
Si vos clusters utilisent un équilibreur de charge manuel, suivez
ces instructions pour le configurer afin de réinitialiser les connexions client lorsqu'il détecte une défaillance du nœud de backend. Sans cette configuration, les clients du serveur d'API Kubernetes peuvent cesser de répondre pendant plusieurs minutes lorsqu'une instance de serveur est en panne.
|
Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
Facturation de surveillance inattendue
Pour les versions Google Distributed Cloud 1.10 à 1.15, certains clients ont constaté une facturation inattendue pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que dans les cas suivants:
- La journalisation et la surveillance des applications sont activées (
enableStackdriverForApplications=true ).
- Les pods d'application comportent l'annotation
prometheus.io/scrap=true . (L'installation de Cloud Service Mesh peut également ajouter cette annotation.)
Pour vérifier si vous êtes concerné par ce problème, répertoriez vos métriques définies par l'utilisateur. Si vous constatez une facturation pour des métriques indésirables avec le préfixe de nom external.googleapis.com/prometheus et que enableStackdriverForApplications est défini sur "true" dans la réponse de kubectl -n kube-system get stackdriver stackdriver -o yaml , ce problème vous concerne.
Solution
Si vous êtes concerné par ce problème, nous vous recommandons de mettre à niveau vos clusters vers la version 1.12 ou ultérieure, d'arrêter d'utiliser l'indicateur enableStackdriverForApplications et de passer à la nouvelle solution de surveillance des applications managed-service-for-prometheus, qui ne repose plus sur l'annotation prometheus.io/scrap=true . Avec la nouvelle solution, vous pouvez également contrôler la collecte des journaux et des métriques séparément pour vos applications, à l'aide des indicateurs enableCloudLoggingForApplications et enableGMPForApplications , respectivement.
Pour arrêter d'utiliser l'indicateur enableStackdriverForApplications , ouvrez l'objet "stackdriver" pour le modifier:
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver
Supprimez la ligne enableStackdriverForApplications: true , enregistrez et fermez l'éditeur.
Si vous ne parvenez pas à désactiver la collecte de métriques basée sur les annotations, procédez comme suit:
- Recherchez les pods et services sources contenant les métriques indésirables facturées.
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
- Supprimez l'annotation
prometheus.io/scrap=true du pod ou du service. Si l'annotation est ajoutée par Cloud Service Mesh, envisagez de configurer Cloud Service Mesh sans l'option Prometheus ou de désactiver la fonctionnalité de fusion des métriques Istio.
|
Installation |
1.11, 1.12, 1.13 |
Échec de l'installation lors de la création d'un disque de données vSphere
L'installation de Google Distributed Cloud peut échouer si les rôles personnalisés sont associés à un niveau d'autorisation incorrect.
Lorsque la liaison de rôle n'est pas correcte, la création d'un disque de données vSphere avec govc est bloquée et le disque créé avec une taille égale à 0. Pour résoudre le problème, vous devez lier le rôle personnalisé au niveau de vSphere vCenter (racine).
Solution :
Si vous souhaitez lier le rôle personnalisé au niveau du DC (ou inférieur à la racine), vous devez également lier le rôle en lecture seule à l'utilisateur au niveau racine de vCenter.
Pour en savoir plus sur la création de rôle, consultez la page
Droits des utilisateurs sur les comptes vCenter.
|
Journalisation et surveillance |
1.9.0-1.9.4, 1.10.0-1.10.1 |
Trafic réseau élevé vers monitoring.googleapis.com
Vous risquez de rencontrer un trafic réseau important vers monitoring.googleapis.com , même dans un nouveau cluster qui ne comporte aucune charge de travail d'utilisateur.
Ce problème affecte la version 1.10.0-1.10.1 et la version 1.9.0-1.9.4. Ce problème est résolu dans les versions 1.10.2 et 1.9.5.
Solution :
Afficher les étapes de la solution de contournement
Effectuez une mise à niveau vers la version 1.10.2/1.9.5 ou ultérieure.
Pour résoudre ce problème dans une version antérieure, procédez comme suit :
- Réduisez la capacité de "stackdriver-operator" :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
scale deployment stackdriver-operator --replicas=0
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
- Ouvrez le fichier ConfigMap
gke-metrics-agent-conf pour le modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
edit configmap gke-metrics-agent-conf
- Augmentez l'intervalle de vérification de 0,1 seconde à 13 secondes :
processors:
disk_buffer/metrics:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-metrics
probe_interval: 13s
retention_size_mib: 6144
disk_buffer/self:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-self
probe_interval: 13s
retention_size_mib: 200
disk_buffer/uptime:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-uptime
probe_interval: 13s
retention_size_mib: 200
- Fermez la session de modification.
- Remplacez la version de DaemonSet
gke-metrics-agent par la version 1.1.0-anthos.8:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
Journalisation et surveillance |
1.10, 1.11 |
gke-metrics-agent présente des erreurs CrashLoopBackOff récurrentes
Pour Google Distributed Cloud version 1.10 et ultérieure, le DaemonSet gke-metrics-agent présente des erreurs CrashLoopBackOff récurrentes lorsque enableStackdriverForApplications est défini sur "true" dans l'objet "stackdriver".
Solution :
Pour résoudre ce problème, désactivez la collecte de métriques d'application en exécutant les commandes suivantes. Ces commandes ne désactivent pas la collecte des journaux d'application.
- Pour empêcher l'annulation des modifications suivantes, effectuez un scaling à la baisse de
stackdriver-operator :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy stackdriver-operator \
--replicas=0
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
- Ouvrez le fichier ConfigMap
gke-metrics-agent-conf pour le modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- Sous
services.pipelines , mettez en commentaire l'intégralité de la section metrics/app-metrics :
services:
pipelines:
#metrics/app-metrics:
# exporters:
# - googlecloud/app-metrics
# processors:
# - resource
# - metric_to_resource
# - infer_resource
# - disk_buffer/app-metrics
# receivers:
# - prometheus/app-metrics
metrics/metrics:
exporters:
- googlecloud/metrics
processors:
- resource
- metric_to_resource
- infer_resource
- disk_buffer/metrics
receivers:
- prometheus/metrics
- Fermez la session de modification.
- Redémarrez le DaemonSet
gke-metrics-agent :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system rollout restart daemonset gke-metrics-agent
|
Journalisation et surveillance |
1.11, 1.12, 1.13 |
Remplacer les métriques obsolètes dans le tableau de bord
Si des métriques obsolètes sont utilisées dans vos tableaux de bord prêts à l'emploi, certains graphiques seront vides. Pour rechercher des métriques obsolètes dans les tableaux de bord de surveillance, exécutez les commandes suivantes:
gcloud monitoring dashboards list > all-dashboard.json
# find deprecated metrics
cat all-dashboard.json | grep -E \
'kube_daemonset_updated_number_scheduled\
|kube_node_status_allocatable_cpu_cores\
|kube_node_status_allocatable_pods\
|kube_node_status_capacity_cpu_cores'
Les métriques obsolètes suivantes doivent être migrées vers leurs remplacements.
Obsolète | Remplacement |
kube_daemonset_updated_number_scheduled |
kube_daemonset_status_updated_number_scheduled |
kube_node_status_allocatable_cpu_cores
kube_node_status_allocatable_memory_bytes
kube_node_status_allocatable_pods |
kube_node_status_allocatable |
kube_node_status_capacity_cpu_cores
kube_node_status_capacity_memory_bytes
kube_node_status_capacity_pods |
kube_node_status_capacity |
kube_hpa_status_current_replicas |
kube_horizontalpodautoscaler_status_current_replicas |
Solution :
Pour remplacer les métriques obsolètes :
- Supprimez l'état du nœud GKE On-Prem dans le tableau de bord de Google Cloud Monitoring. Réinstallez l'état du nœud GKE On-Prem en suivant
ces instructions.
- Supprimez l'utilisation du nœud GKE On-Prem dans le tableau de bord Google Cloud Monitoring. Réinstallez l'utilisation du nœud GKE On-Prem en suivant
ces instructions.
- Supprimez "État de la VM vSphere GKE On-Prem" dans le tableau de bord Google Cloud Monitoring. Réinstallez "État de la VM vSphere GKE On-Prem" en suivant
ces instructions.
Cette suppression est due à la mise à niveau de l'agent
kube-state-metrics de la version 1.9 à la version 2.4, qui est requise pour Kubernetes 1.22. Vous pouvez remplacer toutes les métriques kube-state-metrics obsolètes, qui portent le préfixe kube_ , dans vos tableaux de bord personnalisés ou vos règles d'alerte.
|
Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13 |
Données de métriques inconnues dans Cloud Monitoring
Pour Google Distributed Cloud version 1.10 et ultérieures, les données des clusters dans Cloud Monitoring peuvent contenir des entrées de métriques récapitulatives non pertinentes, telles que les suivantes:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Les autres types de métriques pouvant présenter des métriques récapitulatives non pertinentes sont les suivants : :
apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary
Bien que ces métriques de type récapitulatif figurent dans la liste des métriques, elles ne sont pas compatibles avec gke-metrics-agent pour le moment.
|
Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13 |
Métriques manquantes sur certains nœuds
Il se peut que les métriques suivantes soient manquantes sur certains nœuds, mais pas tous:
kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total
Solution :
Pour résoudre ce problème, procédez comme suit : Pour [version 1.9.5+, 1.10.2+, 1.11.0]: augmentez le processeur pour gke-metrics-agent en suivant les étapes 1 à 4.
- Ouvrez votre ressource
stackdriver pour la modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Pour augmenter la demande de processeur pour
gke-metrics-agent de 10m à 50m , la limite de processeur de 100m à 200m , ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver :
spec:
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 100m
memory: 4608Mi
requests:
cpu: 10m
memory: 200Mi
Votre ressource modifiée doit se présenter comme suit:
spec:
anthosDistribution: on-prem
clusterLocation: us-west1-a
clusterName: my-cluster
enableStackdriverForApplications: true
gcpServiceAccountSecretName: ...
optimizedMetrics: true
portable: true
projectID: my-project-191923
proxyConfigSecretName: ...
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 200m
memory: 4608Mi
requests:
cpu: 50m
memory: 200Mi
- Enregistrez les modifications et fermez l'éditeur de texte.
- Pour vérifier que vos modifications ont pris effet, exécutez la commande suivante :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset gke-metrics-agent -o yaml \
| grep "cpu: 50m"
La commande détecte cpu: 50m si vos modifications ont été appliquées.
|
Journalisation et surveillance |
1.11.0-1.11.2, 1.12.0 |
Métriques de l'ordonnanceur et du gestionnaire de contrôleur manquantes dans le cluster d'administrateur
Si votre cluster d'administrateur est affecté par ce problème, les métriques du planificateur et du gestionnaire de contrôleur sont manquantes. Par exemple, ces deux métriques sont manquantes :
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solution :
Passez à la version 1.11.3 ou ultérieure, à la version 1.12.1 ou ultérieure ou à la version 1.13 ou ultérieure.
|
|
1.11.0-1.11.2, 1.12.0 |
Métriques de planificateur et de contrôleur-gestionnaire manquantes dans le cluster d'utilisateur
Si votre cluster d'utilisateurs est concerné par ce problème, les métriques du planificateur et du gestionnaire de contrôleur sont manquantes. Par exemple, les deux métriques suivantes sont manquantes:
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solution :
Ce problème est résolu dans Google Distributed Cloud version 1.13.0 et ultérieures.
Mettez à niveau votre cluster vers une version avec le correctif.
|
Installation, mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 |
Échec de l'enregistrement du cluster d'administrateur lors de la création
Si vous créez un cluster d'administrateur pour la version 1.9.x ou 1.10.0 et que le cluster d'administrateur ne parvient pas à s'enregistrer auprès de la spécification gkeConnect fournie lors de sa création, vous obtenez l'erreur suivante.
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH
Vous pourrez toujours utiliser ce cluster d'administrateur, mais vous obtiendrez l'erreur suivante si vous tenterez de mettre à niveau le cluster d'administrateur vers la version 1.10.y par la suite.
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""
Solution :
Afficher les étapes de la solution de contournement
Si cette erreur se produit, procédez comme suit pour résoudre le problème d'enregistrement du cluster. Une fois ce correctif effectué, vous pouvez mettre à niveau votre cluster d'administrateur.
- Exécutez
gkectl update admin pour enregistrer le cluster d'administrateur avec la clé de compte de service appropriée.
- Créez un compte de service dédié pour corriger la ressource personnalisée
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.
- Exécutez ces commandes pour mettre à jour la ressource personnalisée
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
--no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
-n kube-system $ADMIN_CLUSTER_NAME \
-o=jsonpath='{.spec.gkeOnPremVersion}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Essayez à nouveau de mettre à niveau le cluster d'administrateur avec l'option
--disable-upgrade-from-checkpoint .
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès de votre fichier de configuration de cluster d'administrateur.
|
Identité |
1.10, 1.11, 1.12, 1.13 |
L'utilisation de GKE Identity Service peut entraîner un redémarrage imprévisible de l'agent Connect
Si vous utilisez la fonctionnalité GKE Identity Service pour gérer la
ClientConfig de GKE Identity Service, l'
agent Connect peut redémarrer de manière inattendue.
Solution :
Si vous avez rencontré ce problème avec un cluster existant, vous pouvez effectuer l'une des opérations suivantes:
- Désactivez GKE Identity Service. Si vous désactivez GKE Identity Service, cela ne supprimera pas le binaire GKE Identity Service déployé ni ne supprimera la ClientConfig GKE Identity Service. Pour désactiver GKE Identity Service, exécutez cette commande:
gcloud container fleet identity-service disable \
--project PROJECT_ID
Remplacez PROJECT_ID par l'ID du
projet hôte de parc du cluster.
- Mettez à jour le cluster vers la version 1.9.3 ou ultérieure, ou la version 1.10.1 ou ultérieure, afin de mettre à jour la version de l'agent Connect.
|
Mise en réseau |
1.10, 1.11, 1.12, 1.13 |
Cisco ACI ne fonctionne pas avec Direct Server Return (DSR)
Seesaw s'exécute en mode DSR et, par défaut, il ne fonctionne pas dans Cisco ACI en raison de l'apprentissage IP du plan de données.
Solution :
Une solution de contournement possible consiste à désactiver l'apprentissage IP en ajoutant l'adresse IP Seesaw en tant qu'adresse IP virtuelle L4-L7 dans le contrôleur d'infrastructure Cisco Application Policy Infrastructure (APIC).
Vous pouvez configurer l'option d'adresse IP virtuelle L4-L7 en accédant à Locataire > Profils d'application > EPG d'application ou EPG uSeg. Si vous ne désactivez pas l'apprentissage IP, les points de terminaison IP basculeront entre différents emplacements de la structure d'API Cisco.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Problèmes liés à la mise à niveau 3 de vSphere 7.0
VMWare a récemment identifié des problèmes critiques avec les versions suivantes de vSphere 7.0, mise à niveau 3:
- vSphere ESXi 7.0, mise à niveau 3 (version 18644231)
- vSphere ESXi 7.0, mise à niveau 3a (version 18825058)
- vSphere ESXi 7.0, mise à niveau 3b (version 18905247)
- vSphere vCenter 7.0, mise à niveau 3b (version 18901211)
Solution :
VMWare a depuis supprimé ces versions. Vous devez mettre à niveau les serveurs ESXi et les serveurs vCenter vers une version plus récente.
|
Système d'exploitation |
1.10, 1.11, 1.12, 1.13 |
Échec de l'installation du volume emptyDir en tant que exec dans le pod exécuté sur des nœuds COS
Pour les pods exécutés sur des nœuds qui utilisent des images Container-Optimized OS (COS), vous ne pouvez pas monter le volume emptyDir en tant que exec . Il est installé en tant que noexec et vous obtenez l'erreur suivante: exec user
process caused: permission denied . Par exemple, ce message d'erreur s'affiche si vous déployez le pod de test suivant:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: test
name: test
spec:
containers:
- args:
- sleep
- "5000"
image: gcr.io/google-containers/busybox:latest
name: test
volumeMounts:
- name: test-volume
mountPath: /test-volume
resources:
limits:
cpu: 200m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
volumes:
- emptyDir: {}
name: test-volume
Dans le pod de test, si vous exécutez mount | grep test-volume , l'option noexec est affichée:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Solution :
Afficher les étapes de la solution de contournement
Appliquez une ressource DaemonSet, par exemple :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fix-cos-noexec
namespace: kube-system
spec:
selector:
matchLabels:
app: fix-cos-noexec
template:
metadata:
labels:
app: fix-cos-noexec
spec:
hostIPC: true
hostPID: true
containers:
- name: fix-cos-noexec
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
set -ex
while true; do
if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
echo "remounting /var/lib/kubelet with exec"
nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
fi
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Mises à niveau, mises à jour |
1.10, 1.11, 1.12, 1.13 |
La mise à niveau de l'instance dupliquée du pool de nœuds du cluster ne fonctionne pas une fois l'autoscaling désactivé sur le pool de nœuds
Les instances dupliquées du pool de nœuds ne sont pas mises à jour une fois l'autoscaling activé et désactivé sur un pool de nœuds.
Solution :
Suppression des annotations cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size et cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size du déploiement de la machine du pool de nœuds correspondant.
|
Journalisation et surveillance |
1.11, 1.12, 1.13 |
Les tableaux de bord de surveillance Windows affichent les données des clusters Linux
À partir de la version 1.11, dans les tableaux de bord de surveillance prêts à l'emploi, le tableau de bord "État du pod Windows" et le tableau de bord "État du nœud Windows" affichent également des données provenant de clusters Linux. En effet, les métriques de nœud et de pod Windows sont également exposées sur les clusters Linux.
|
Journalisation et surveillance |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder en CrashLoopBackOff constant
Pour les versions Google Distributed Cloud 1.10, 1.11 et 1.12, le DaemonSet stackdriver-log-forwarder peut présenter des erreurs CrashLoopBackOff en cas de journaux tamponnés défectueux sur le disque.
Solution :
Pour résoudre ce problème, nous devons nettoyer les journaux tamponnés sur le nœud.
- Pour éviter tout comportement inattendu, effectuez un scaling à la baisse de
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
- Déployez le DaemonSet de nettoyage pour nettoyer les segments cassés:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit-cleanup
namespace: kube-system
spec:
selector:
matchLabels:
app: fluent-bit-cleanup
template:
metadata:
labels:
app: fluent-bit-cleanup
spec:
containers:
- name: fluent-bit-cleanup
image: debian:10-slim
command: ["bash", "-c"]
args:
- |
rm -rf /var/log/fluent-bit-buffers/
echo "Fluent Bit local buffer is cleaned up."
sleep 3600
volumeMounts:
- name: varlog
mountPath: /var/log
securityContext:
privileged: true
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
- key: node-role.kubernetes.io/master
effect: NoSchedule
- key: node-role.gke.io/observability
effect: NoSchedule
volumes:
- name: varlog
hostPath:
path: /var/log
EOF
- Pour vous assurer que le DaemonSet de nettoyage a nettoyé tous les segments, vous pouvez exécuter les commandes suivantes. Le résultat des deux commandes doit être égal au numéro de nœud du cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
- Supprimez le DaemonSet de nettoyage:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
- Réactiver
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
|
Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16 |
stackdriver-log-forwarder n'envoie pas de journaux à Cloud Logging
Si les journaux de vos clusters ne s'affichent pas dans Cloud Logging et que l'erreur suivante s'affiche dans vos journaux:
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
Il est probable que le taux d'entrée des journaux dépasse la limite de l'agent de journalisation, ce qui empêche stackdriver-log-forwarder d'envoyer des journaux.
Ce problème se produit dans toutes les versions de Google Distributed Cloud.
Solution :
Pour atténuer ce problème, vous devez augmenter la limite de ressources sur l'agent de journalisation.
- Ouvrez votre ressource
stackdriver pour la modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Pour augmenter la demande de processeur pour
stackdriver-log-forwarder , ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver :
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
Votre ressource modifiée doit se présenter comme suit:
spec:
anthosDistribution: on-prem
clusterLocation: us-west1-a
clusterName: my-cluster
enableStackdriverForApplications: true
gcpServiceAccountSecretName: ...
optimizedMetrics: true
portable: true
projectID: my-project-191923
proxyConfigSecretName: ...
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
- Enregistrez les modifications et fermez l'éditeur de texte.
- Pour vérifier que vos modifications ont pris effet, exécutez la commande suivante :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
| grep "cpu: 1200m"
La commande détecte cpu: 1200m si vos modifications ont été appliquées.
|
Sécurité |
1.13 |
Le service Kubelet sera temporairement indisponible après NodeReady.
Il existe une courte période où le nœud est prêt, mais que le certificat du serveur kubelet n'est pas prêt. kubectl exec et kubectl logs ne sont pas disponibles pendant ces dizaines de secondes.
En effet, il faut un certain temps pour que l'approbateur du nouveau certificat de serveur voit les adresses IP valides mises à jour du nœud.
Ce problème ne concerne que le certificat du serveur kubelet. Il n'affecte pas la planification des pods.
|
Mises à niveau, mises à jour |
1.12 |
La mise à niveau partielle du cluster d'administrateur ne bloque pas la mise à niveau ultérieure du cluster d'utilisateur
Échec de la mise à niveau du cluster d'utilisateur avec:
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Le cluster administrateur n'est pas entièrement mis à niveau, et la version d'état est toujours 1.10. La mise à niveau du cluster d'utilisateur vers la version 1.12 ne sera pas bloquée par une vérification préliminaire et échouera en raison d'un problème de décalage de version.
Solution :
Effectuez cette opération pour mettre d'abord à niveau le cluster d'administrateur vers la version 1.11, puis le cluster d'utilisateur vers la version 1.12.
|
Stockage |
1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0 |
Datastore signale de manière incorrecte un espace de stockage insuffisant
Échec de la commande gkectl diagnose cluster avec:
Checking VSphere Datastore FreeSpace...FAILURE
Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB
La validation de l'espace de stockage disponible ne doit pas être utilisée pour les pools de nœuds de cluster existants et a été ajoutée par erreur dans gkectl diagnose cluster .
Solution :
Vous pouvez ignorer le message d'erreur ou ignorer la validation à l'aide de --skip-validation-infra .
|
Opération, mise en réseau |
1.11, 1.12.0-1.12.1 |
Il est possible que vous ne puissiez pas ajouter de cluster d'utilisateur si votre cluster d'administrateur est configuré avec une configuration d'équilibreur de charge MetalLB.
Pour une raison quelconque, le processus de suppression du cluster d'utilisateurs peut se bloquer, ce qui entraîne l'invalidation du ConfigMap MatalLB. Il n'est pas possible d'ajouter un cluster d'utilisateurs dans cet état.
Solution :
Vous pouvez
forcer la suppression de votre cluster d'utilisateur.
|
Installation, système d'exploitation |
1.10, 1.11, 1.12, 1.13 |
Échec lors de l'utilisation de Container-Optimized OS (COS) pour le cluster d'utilisateurs
Si osImageType utilise cos pour le cluster d'administrateur et que gkectl check-config est exécuté après la création du cluster d'administrateur et avant la création du cluster d'utilisateur, l'opération échouera sur:
Failed to create the test VMs: VM failed to get IP addresses on the network.
La VM de test créée pour le cluster utilisateur check-config utilise par défaut le même osImageType que le cluster administrateur. À l'heure actuelle, la VM de test n'est pas encore compatible avec COS.
Solution :
Pour éviter la vérification préliminaire lente qui crée la VM de test, utilisez gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config
USER_CLUSTER_CONFIG --fast .
|
Journalisation et surveillance |
1.12.0-1.12.1 |
Grafana dans le cluster d'administrateur ne parvient pas à atteindre les clusters d'utilisateur
Ce problème affecte les clients qui utilisent Grafana dans le cluster d'administration pour surveiller les clusters d'utilisateurs dans les versions 1.12.0 et 1.12.1 de Google Distributed Cloud. Il provient d'une incohérence entre les certificats pushprox-client dans les clusters d'utilisateurs et la liste d'autorisation dans le serveur pushprox du cluster d'administration.
Le symptôme est que pushprox-client dans les clusters d'utilisateurs imprime des journaux d'erreur comme suit:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Solution :
Afficher les étapes de la solution de contournement
Procédez comme suit:
- Réduction du déploiement de l'opérateur de surveillance dans l'espace de noms kube-system du cluster d'administration.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Modifiez le ConfigMap
pushprox-server-rbac-proxy-config dans l'espace de noms kube-system du cluster d'administrateur.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Recherchez la ligne principals pour l'écouteur external-pushprox-server-auth-proxy et corrigez le principal_name pour tous les clusters d'utilisateurs en supprimant la sous-chaîne kube-system de pushprox-client.metrics-consumers.kube-system.cluster. .
La nouvelle configuration doit se présenter comme suit:
permissions:
- or_rules:
rules:
- header: { name: ":path", exact_match: "/poll" }
- header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
- Redémarrez le déploiement
pushprox-server dans le cluster d'administrateur et le déploiement pushprox-client dans les clusters d'utilisateurs concernés:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
- Les étapes précédentes devraient résoudre le problème. Une fois le cluster mis à niveau vers la version 1.12.2 ou ultérieure, où le problème est résolu, faites évoluer l'opérateur de surveillance kube-system du cluster d'administrateur afin qu'il puisse à nouveau gérer le pipeline.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
Autre |
1.11.3 |
gkectl repair admin-master ne fournit pas le modèle de VM à utiliser pour la récupération
Échec de la commande gkectl repair admin-master avec:
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support
gkectl repair admin-master ne peut pas récupérer le modèle de VM à utiliser pour réparer la VM du plan de contrôle administrateur si le nom de la VM du plan de contrôle administrateur se termine par les caractères t , m , p ou l .
Solution :
Exécutez à nouveau la commande avec --skip-validation .
|
Journalisation et surveillance |
1.11, 1.12, 1.13, 1.14, 1.15, 1.16 |
Échec de Cloud Audit Logging en raison d'une autorisation refusée
Cloud Audit Logs nécessite une configuration d'autorisation spéciale qui n'est actuellement effectuée automatiquement pour les clusters d'utilisateur que dans GKE Hub.
Il est recommandé de disposer d'au moins un cluster d'utilisateur utilisant le même ID de projet et le même compte de service avec le cluster d'administrateur Cloud Audit Logs, afin que le cluster d'administrateur dispose des autorisations requises.
Toutefois, dans le cas où le cluster d'administrateur utilise un ID de projet ou un compte de service différent de celui d'un cluster d'utilisateur, les journaux d'audit du cluster d'administrateur ne pourront pas être injectés dans Google Cloud. Le symptôme est une série d'erreurs Permission Denied dans le pod audit-proxy du cluster d'administrateur.
Solution :
Afficher les étapes de la solution de contournement
Pour résoudre ce problème, vous pouvez configurer l'autorisation en interagissant avec la fonctionnalité de hub cloudauditlogging :
- Commencez par vérifier les comptes de service existants autorisés pour Cloud Audit Logs dans votre projet:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- Selon la réponse, effectuez l'une des opérations suivantes :
- Si vous avez reçu une erreur
404 Not_found , cela signifie qu'aucun compte de service n'a été autorisé pour cet ID de projet. Vous pouvez ajouter un compte de service à la liste d'autorisation en activant la fonctionnalité de hub cloudauditlogging :
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Si vous avez reçu une spécification de fonctionnalité contenant
"lifecycleState": "ENABLED" avec "code":
"OK" et une liste de comptes de service dans allowlistedServiceAccounts , cela signifie que des comptes de service existants sont autorisés pour ce projet. Vous pouvez utiliser un compte de service de cette liste dans votre cluster ou ajouter un nouveau compte de service à la liste d'autorisation:
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Si vous avez reçu une spécification de fonctionnalité contenant
"lifecycleState": "ENABLED" avec "code":
"FAILED" , cela signifie que la configuration de l'autorisation a échoué.
Essayez de résoudre les problèmes dans le champ description de la réponse, ou sauvegardez la liste d'autorisation actuelle, supprimez la fonctionnalité de hub cloudauditlogging, puis réactivez-la en suivant à nouveau l'étape 1 de la présente section. Vous pouvez supprimer la fonctionnalité de hub cloudauditlogging en:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
Dans les commandes ci-dessus :
|
Opération, sécurité |
1.11 |
Échec de la vérification des certificats gkectl diagnose
Si votre poste de travail n'a pas accès aux nœuds de calcul du cluster d'utilisateur, il obtiendra les échecs suivants lors de l'exécution de gkectl diagnose :
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Si votre poste de travail n'a pas accès aux nœuds de calcul du cluster d'administrateur ou aux nœuds de calcul du cluster, il recevra les échecs suivants lors de l'exécution de gkectl diagnose :
Checking admin cluster certificates...FAILURE
Reason: 3 admin cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Solution :
Vous pouvez ignorer ces messages.
|
Système d'exploitation |
1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
/var/log/audit/ occupe de l'espace disque sur les VM
/var/log/audit/ est rempli de journaux d'audit. Vous pouvez vérifier l'utilisation du disque en exécutant sudo du -h -d 1 /var/log/audit .
Certaines commandes gkectl sur le poste de travail administrateur, par exemple gkectl diagnose snapshot , contribuent à l'utilisation de l'espace disque.
Depuis la version 1.8 de Google Distributed Cloud, l'image Ubuntu est renforcée avec le benchmark CIS de niveau 2. L'une des règles de conformité, "4.1.2.2 Assurez-vous que les journaux d'audit ne sont pas automatiquement supprimés", garantit le paramètre auditd max_log_file_action = keep_logs . Toutes les règles d'audit sont ainsi conservées sur le disque.
Solution :
Afficher les étapes de la solution de contournement
Poste de travail administrateur
Pour la station de travail administrateur, vous pouvez modifier manuellement les paramètres auditd pour alterner automatiquement les journaux, puis redémarrer le service auditd:
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
Le paramètre ci-dessus permet d'auditer automatiquement les journaux une fois qu'il a généré plus de 250 fichiers (tous de 8 Mo).
Nœuds de cluster
Pour les nœuds de cluster, passez à la version 1.11.5 ou ultérieure, 1.12.4 ou ultérieure, 1.13.2 ou ultérieure ou 1.14 ou ultérieure. Si vous ne pouvez pas encore passer à ces versions, appliquez le DaemonSet suivant à votre cluster:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
Notez que cette modification de configuration auditée ne respecte pas la règle de niveau 2 CIS 4.1.2.2 "S'assurer que les journaux d'audit ne sont pas supprimés automatiquement".
|
Mise en réseau |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
L'adresse IP flottante NetworkGatewayGroup est en conflit avec l'adresse du nœud.
Les utilisateurs ne peuvent pas créer ni modifier d'objets NetworkGatewayGroup en raison de l'erreur de validation du webhook suivante:
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"
Dans les versions concernées, le kubelet peut se lier par erreur à une adresse IP flottante attribuée au nœud et la signaler comme adresse de nœud dans node.status.addresses . Le webhook de validation vérifie les adresses IP flottantes NetworkGatewayGroup par rapport à toutes les node.status.addresses du cluster et considère cela comme un conflit.
Solution :
Dans le même cluster où la création ou la mise à jour d'objets NetworkGatewayGroup échoue, désactivez temporairement le webhook de validation ANG et envoyez votre modification:
- Enregistrez la configuration du webhook afin qu'elle puisse être restaurée à la fin:
kubectl -n kube-system get validatingwebhookconfiguration \
ang-validating-webhook-configuration -o yaml > webhook-config.yaml
- Modifiez la configuration du webhook:
kubectl -n kube-system edit validatingwebhookconfiguration \
ang-validating-webhook-configuration
- Supprimez l'élément
vnetworkgatewaygroup.kb.io de la liste de configuration du webhook, puis fermez la fenêtre pour appliquer les modifications.
- Créez ou modifiez votre objet
NetworkGatewayGroup .
- Appliquez à nouveau la configuration d'origine du webhook:
kubectl -n kube-system apply -f webhook-config.yaml
|
Installation, mises à niveau, mises à jour |
1.10.0-1.10.2 |
Délai avant expiration de la création ou de la mise à niveau du cluster d'administrateur
Lors d'une tentative de mise à niveau d'un cluster d'administrateur, la VM du plan de contrôle administrateur peut rester bloquée lors de la création. La VM du plan de contrôle administrateur entre dans une boucle d'attente infinie au démarrage, et l'erreur de boucle infinie suivante s'affiche dans le fichier /var/log/cloud-init-output.log :
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1
En effet, lorsque Google Distributed Cloud tente d'obtenir l'adresse IP du nœud dans le script de démarrage, il utilise grep -v
ADMIN_CONTROL_PLANE_VIP pour ignorer l'adresse IP virtuelle du plan de contrôle du cluster d'administrateur, qui peut également être attribuée à la carte réseau. Toutefois, la commande ignore également toute adresse IP dont le préfixe correspond à l'adresse IP virtuelle du plan de contrôle, ce qui entraîne le blocage du script de démarrage.
Par exemple, supposons que l'adresse IP virtuelle du plan de contrôle du cluster d'administrateur soit 192.168.1.25. Si l'adresse IP de la VM de plan de contrôle du cluster d'administrateur a le même préfixe, par exemple 192.168.1.254, la VM de plan de contrôle se bloquera lors de la création. Ce problème peut également se produire si l'adresse de diffusion a le même préfixe que l'adresse IP virtuelle du plan de contrôle, par exemple 192.168.1.255 .
Solution :
- Si le délai avant expiration de la création du cluster d'administrateur est dû à l'adresse IP de diffusion, exécutez la commande suivante sur la VM de plan de contrôle du cluster d'administrateur:
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
Cela crée une ligne sans adresse de diffusion et débloque le processus de démarrage. Une fois le script de démarrage débloqué, supprimez cette ligne ajoutée en exécutant la commande suivante:
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
- Toutefois, si le délai avant expiration de la création du cluster d'administrateur est dû à l'adresse IP de la VM du plan de contrôle, vous ne pouvez pas débloquer le script de démarrage. Passez à une autre adresse IP, puis recréez le cluster ou passez à la version 1.10.3 ou ultérieure.
|
Système d'exploitation, Mises à niveau, Mises à jour |
1.10.0-1.10.2 |
L'état du cluster d'administrateur utilisant l'image COS sera perdu lors de la mise à niveau du cluster d'administrateur ou de la réparation de son maître
DataDisk ne peut pas être correctement installé sur le nœud maître du cluster d'administrateur lorsque vous utilisez l'image COS. L'état du cluster d'administrateur utilisant l'image COS sera perdu lors de la mise à niveau du cluster d'administrateur ou de la réparation de son maître. (le cluster d'administrateur utilisant l'image COS est une fonctionnalité en preview)
Solution :
Recréer le cluster d'administrateur avec osImageType défini sur ubuntu_containerd
Une fois le cluster d'administration créé avec osImageType défini sur cos, récupérez la clé SSH du cluster d'administration et connectez-vous en SSH au nœud maître d'administration.
Le résultat df -h contient /dev/sdb1 98G 209M 93G
1% /opt/data . Et le résultat lsblk contient -sdb1
8:17 0 100G 0 part /opt/data
|
Système d'exploitation |
1.10 |
La résolution DNS par systemd-resolved a échoué sur les domaines .local
Dans Google Distributed Cloud version 1.10.0, les résolutions de noms sur Ubuntu sont acheminées par défaut vers l'écoute locale résolue par systemd sur 127.0.0.53 . En effet, sur l'image Ubuntu 20.04 utilisée dans la version 1.10.0, /etc/resolv.conf est un lien symbolique vers /run/systemd/resolve/stub-resolv.conf , qui pointe vers la simulation de DNS sur l'hôte local (127.0.0.53 ).
Par conséquent, la résolution de noms DNS localhost refuse de vérifier les serveurs DNS en amont (spécifiés dans /run/systemd/resolve/resolv.conf ) pour les noms avec un suffixe .local , à moins que les noms ne soient spécifiés en tant que domaines de recherche.
Cela entraîne l'échec des recherches de noms .local . Par exemple, lors du démarrage du nœud, kubelet ne parvient pas à extraire les images d'un registre privé portant un suffixe .local . La spécification d'une adresse vCenter avec un suffixe .local ne fonctionne pas sur un poste de travail d'administrateur.
Solution :
Pour les nœuds de cluster, vous pouvez éviter ce problème en incluant les domaines avec le champ searchDomainsForDNS dans le fichier de configuration de votre cluster d'administrateur et dans le fichier de configuration de cluster d'utilisateur.
Actuellement, gkectl update ne permet pas encore de mettre à jour le champ searchDomainsForDNS .
Par conséquent, si vous n'avez pas configuré ce champ avant la création du cluster, vous devez vous connecter en SSH aux nœuds et contourner la simulation locale résolue par systemd en modifiant le lien symbolique /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (qui contient la simulation locale 127.0.0.53 ) à /run/systemd/resolve/resolv.conf (qui pointe vers le DNS en amont réel):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Comme pour le poste de travail administrateur, gkeadm ne permet pas de spécifier des domaines de recherche. Vous devez donc contourner ce problème avec cette étape manuelle.
Cette solution ne persiste pas lors de la recréation des VM. Vous devez appliquer cette solution de contournement à chaque recréation de VM.
|
Installation, système d'exploitation |
1.10 |
L'adresse IP du pont Docker utilise 172.17.0.1/16 au lieu de 169.254.123.1/24
Google Distributed Cloud spécifie un sous-réseau dédié pour l'adresse IP de la liaison Docker qui utilise --bip=169.254.123.1/24 afin de ne pas réserver le sous-réseau 172.17.0.1/16 par défaut. Toutefois, dans la version 1.10.0, l'image d'OS Ubuntu souffre d'un bug qui empêche la prise en compte de la configuration Docker personnalisée.
En conséquence, Docker sélectionne le paramètre 172.17.0.1/16 par défaut comme sous-réseau d'adresse IP de liaison. Cela peut entraîner un conflit d'adresses IP si vous avez déjà une charge de travail en cours d'exécution dans cette plage d'adresses IP.
Solution :
Pour contourner ce problème, vous devez renommer le fichier de configuration systemd suivant pour dockerd, puis redémarrer le service:
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
/etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
sudo systemctl daemon-reload
sudo systemctl restart docker
Vérifiez que Docker sélectionne l'adresse IP de liaison correcte :
ip a | grep docker0
Cette solution ne persiste pas lors de la recréation des VM. Vous devez appliquer cette solution de contournement à chaque recréation de VM.
|
Mises à niveau, mises à jour |
1.11 |
La mise à niveau vers la version 1.11 est bloquée par la préparation de Stackdriver
Dans la version 1.11.0 de Google Distributed Cloud, la définition des ressources personnalisées liées à la journalisation et à la surveillance a été modifiée:
- Le nom de groupe de la ressource personnalisée
stackdriver est passé de addons.sigs.k8s.io à addons.gke.io .
- Le nom de groupe des ressources personnalisées
monitoring et metricsserver est passé de addons.k8s.io à addons.gke.io .
- Les spécifications des ressources ci-dessus commencent à être validées par rapport à son schéma. Plus précisément, les spécifications resourceAttrOverride et storageSizeOverride de la ressource personnalisée
stackdriver doivent avoir un type de chaîne dans les valeurs des demandes et limites de processeur, de mémoire et de taille de stockage.
Les modifications de nom de groupe sont apportées pour se conformer aux mises à jour de CustomResourceDefinition dans Kubernetes 1.22.
Aucune action n'est requise de votre part si vous ne disposez d'aucune logique supplémentaire qui applique ou modifie les ressources personnalisées concernées. Le processus de migration de Google Distributed Cloud s'occupera de la migration des ressources concernées et conservera leurs spécifications existantes après le changement de nom du groupe.
Toutefois, si vous exécutez une logique qui applique ou modifie les ressources concernées, une attention particulière est requise. Tout d'abord, ils doivent être référencés avec le nouveau nom du groupe dans votre fichier manifeste. Exemple :
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
Ensuite, assurez-vous que les valeurs de spécification resourceAttrOverride et storageSizeOverride sont de type chaîne. Exemple :
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder
limits:
cpu: 1000m # or "1"
# cpu: 1 # integer value like this would not work
memory: 3000Mi
Sinon, les applications et les modifications ne prendront pas effet et peuvent entraîner un état inattendu dans les composants de journalisation et de surveillance. Voici quelques symptômes possibles:
- Journaux d'erreur de rapprochement dans
onprem-user-cluster-controller , par exemple: potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
- Échec dans
kubectl edit stackdriver stackdriver , par exemple: Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found
Si vous rencontrez les erreurs ci-dessus, cela signifie qu'un type non compatible dans la spécification de la CR stackdriver était déjà présent avant la mise à niveau. Pour contourner ce problème, vous pouvez modifier manuellement la demande de correction Stackdriver sous l'ancien nom de groupe kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver et procéder comme suit:
- Modifiez les demandes et les limites de ressources en type de chaîne.
- Supprimez toute annotation
addons.gke.io/migrated-and-deprecated: true , le cas échéant.
Ensuite, reprenez ou redémarrez le processus de mise à niveau.
|
Système d'exploitation |
1.7 et versions ultérieures |
Les VM COS n'affichent aucune adresse IP lorsque les VM sont déplacées via un arrêt non correct de l'hôte
En cas de panne sur un serveur ESXi et si la fonction vCenter HA a été activée pour le serveur, toutes les VM du serveur ESXi défectueux déclenchent le mécanisme vMotion et sont déplacées vers un autre serveur ESXi normal. Les VM COS migrées perdraient leurs adresses IP.
Solution :
Redémarrer la VM
|
Mise en réseau |
toutes les versions antérieures à 1.14.7, 1.15.0-1.15.3 et 1.16.0 |
La réponse GARP envoyée par Seesaw ne définit pas l'adresse IP cible
Le GARP (ARP gratuit) périodique envoyé par Seesaw toutes les 20 secondes ne définit pas l'adresse IP cible dans l'en-tête ARP. Certains réseaux peuvent ne pas accepter de tels paquets (comme Cisco ACI). Cela peut entraîner un temps d'indisponibilité du service plus long après la récupération d'une erreur de double cerveau (due à la perte de paquets VRRP).
Solution :
Déclenchez un basculement Seesaw en exécutant sudo seesaw -c failover sur l'une des VM Seesaw. Le trafic devrait alors être rétabli.
|
Système d'exploitation |
1.16, 1.28.0-1.28.200 |
Kubelet est inondé de journaux indiquant que "/etc/kubernetes/manifests" n'existe pas sur les nœuds de calcul
"staticPodPath" a été défini par erreur pour les nœuds de calcul
Solution :
Créez manuellement le dossier "/etc/kubernetes/manifests".
|