| Mise en réseau |
1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0+, 1.15.0 et plus |
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 arrêtée 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 le fluent-bit exécuté sur la VM Seesaw n'est pas configuré avec une rotation correcte des journaux.
Solution :
Localisez les fichiers journaux qui consomment la majeure partie de l'espace disque à l'aide de du -sh -- /var/lib/docker/containers/* | sort -rh. Nettoyez le fichier journal en exécutant la plus grande taille et redémarrez la VM.
Remarque:Si la VM est complètement inaccessible, associez le disque à une VM opérationnelle (par exemple, un poste de travail administrateur), supprimez le fichier du disque installé, puis réassociez le disque à la VM Seesaw d'origine.
|
| 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 et renvoyer les erreurs 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 à effectuer la mise à niveau vers une version corrective des Clusters Anthos sur VMware avec ce 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 inscrit dans l'API Anthos On-Prem peut échouer
Lorsqu'un cluster d'administrateur est enregistré dans l'API Anthos 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. Dans ce cas, l'erreur suivante s'affiche lorsque vous essayez 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 inscrit à l'API lorsque vous enregistrez explicitement le cluster ou lorsque vous mettez à niveau un cluster d'utilisateur à l'aide d'un client API Anthos On-Prem.
Solution :
Désenregistrez le cluster d'administrateur:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
et renouvelez la mise à niveau du cluster d'administrateur. Il est possible que l'erreur d'échec d'enregistrement du cluster soit temporairement obsolète. Elle devrait être mise à jour automatiquement au bout d'un certain temps.
|
| Mises à niveau et 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 inscrit n'est pas conservée
Lorsqu'un cluster d'administrateur est enregistré dans l'API Anthos On-Prem, son annotation de lien de ressources 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 d'une clé d'annotation incorrecte utilisée. Cela peut entraîner une nouvelle inscription du cluster d'administrateur à l'API Anthos On-Prem.
Un cluster d'administrateur est inscrit à l'API lorsque vous enregistrez explicitement le cluster ou lorsque vous mettez à niveau un cluster d'utilisateur à l'aide d'un client API Anthos On-Prem.
Solution :
Désenregistrez 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 (DNS) non reconnu
OrderPolicy n'est pas reconnu en tant que paramètre et n'est pas utilisé. À la place, les clusters Anthos sur VMware utilisent toujours Random.
Ce problème est dû au fait que le modèle CoreDNS n'a pas été mis à jour, ce qui explique que orderPolicy soit ignoré.
Solution :
Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif persiste jusqu'à une mise à niveau.
- Modifiez le modèle existant:
kubectl edit cm -n kube-system coredns-template
Remplacez le contenu du modèle par ce qui suit:
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 et 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 RS réelle
Certaines conditions de concurrence peuvent entraîner des incohérences d'état OnPremAdminCluster entre le point de contrôle et la RS réelle. Lorsque le problème se produit, l'erreur suivante peut s'afficher lorsque vous mettez à jour le cluster d'administrateur après la mise à 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 résoudre ce problème, vous devrez soit modifier le point de contrôle, soit désactiver le point de contrôle pour la mise à niveau ou la mise à jour. Veuillez contacter notre équipe d'assistance pour procéder au remplacement.
|
| Opération |
1,13, 1,14, 1,15 |
Le processus de rapprochement modifie les certificats d'administrateur sur les clusters d'administrateur
Clusters Anthos sur VMware modifie les certificats d'administrateur sur les plans de contrôle de cluster d'administrateur à chaque processus de rapprochement, par exemple lors de la mise à niveau du cluster. Ce comportement augmente le risque d'obtenir des certificats non valides pour votre cluster d'administrateur, en particulier pour les clusters version 1.15.
Si vous êtes concerné, vous pouvez rencontrer les problèmes suivants:
Solution :
Effectuez la mise à niveau vers une version d'Clusters Anthos sur VMware avec le correctif.
Si cela n'est pas possible, contactez le Cloud Customer Care pour résoudre ce problème.
|
| Mise en réseau, fonctionnement |
1.10, 1.11, 1.12, 1.13 et 1.14 |
Composants de la passerelle réseau Anthos évincés ou en attente, car la classe de priorité est manquante
Les pods de passerelle réseau dans kube-system peuvent afficher l'état Pending ou Evicted, comme illustré dans l'exemple de résultat condensé 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 une incapacité à planifier les pods en raison de ressources de nœuds. Comme les pods de passerelle réseau Anthos n'ont pas de PriorityClass, ils ont la même priorité par défaut que les autres charges de travail.
Lorsque les nœuds sont limités en 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 être migrés.
Solution :
Passez à la version 1.15 ou ultérieure.
Pour résoudre ce problème à court terme, vous pouvez attribuer manuellement une classe PriorityClass aux composants de la passerelle réseau Anthos. Le contrôleur Clusters Anthos sur VMware écrase ces modifications manuelles lors d'un processus de rapprochement, par exemple lors d'une mise à niveau de cluster.
- Attribuez la classe de priorité
system-cluster-critical aux déploiements du contrôleur de cluster ang-controller-manager et autoscaler.
- Attribuez la classe Class de classe
system-node-critical au DaemonSet du nœud ang-daemon.
|
| Mises à niveau et 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 relancez le 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 pour les commandes journalctl exécutées sur les nœuds du cluster.
Cela n'affecte pas le fonctionnement de la prise d'un instantané du cluster, car celui-ci 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 manquante.
|
| Installation, mises à niveau et mises à jour |
1.9+, 1.10+, 1.11+, 1.12 et plus |
Échec de gkectl prepare windows
gkectl prepare windows ne peut pas installer Docker sur les Clusters Anthos sur VMware antérieurs à la version 1.13, car MicrosoftDockerProvider est obsolète.
Solution :
L'idée générale pour contourner ce problème consiste à passer à Clusters Anthos sur VMware 1.13 et à utiliser la version 1.13 gkectl pour créer un modèle de VM Windows, puis des pools de nœuds Windows. Deux options permettent d'accéder aux clusters Anthos sur VMware 1.13 à partir de votre version actuelle, comme indiqué ci-dessous.
Remarque:Il existe des options pour résoudre ce problème dans votre version actuelle sans avoir à passer à la version 1.13. Toutefois, si des étapes manuelles sont nécessaires, 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 Clusters Anthos sur VMware 1.13 ou version ultérieure avec des pools de nœuds Windows, migrer vos charges de travail vers le nouveau cluster, puis supprimer le cluster actuel. Nous vous recommandons d'utiliser la dernière version mineure d'Anthos.
Remarque:Cette opération nécessite des ressources supplémentaires pour provisionner le nouveau cluster, mais moins de temps d'arrêt et d'interruption pour les charges de travail existantes.
Option 2:supprimez les pools de nœuds Windows et rajoutez-les lors de la mise à niveau vers Clusters Anthos sur 1.13 VMware.
Remarque:Pour cette option, les charges de travail Windows ne pourront pas s'exécuter tant que le cluster ne sera pas mis à niveau vers la version 1.13 et que les pools de nœuds Windows ne seront pas rajoutés.
- 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'utilisateur et d'administrateur Linux uniquement vers la version 1.12 en suivant le
guide de l'utilisateur de mise à niveau pour la version mineure cible correspondante.
- (Assurez-vous d'effectuer cette étape avant de passer à la version 1.13.) Vérifiez que
enableWindowsDataplaneV2: true est configuré dans la RS OnPremUserCluster. Sinon, le cluster continuera à utiliser Docker pour les pools de nœuds Windows, qui ne seront pas compatibles avec le modèle de VM Windows 1.13 nouvellement créé sur lequel Docker n'est pas installé. Si vous ne la configurez pas ou si vous la définissez sur "false", mettez à jour votre cluster pour le définir sur "true" dans le 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 uniquement vers la version 1.13 en suivant le
guide de mise à niveau utilisateur.
- Préparez le modèle de VM Windows à l'aide de 1.13 gkectl:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
- Ajoutez de nouveau la configuration du pool de nœuds Windows à user-cluster.yaml, en définissant le champ
OSImage sur le modèle de VM Windows que vous venez de créer.
- 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 et mises à jour |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
La configuration RootDistanceMaxSec ne prend pas effet pour ubuntu nœuds
La valeur par défaut de 5 secondes pour RootDistanceMaxSec sera utilisée sur les nœuds au lieu de 20 secondes, ce qui devrait être la configuration attendue. Si vous consultez le journal de démarrage du nœud en vous connectant en SSH à la VM, située 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'une RootDistanceMaxSec de cinq secondes peut entraîner une désynchronisation de l'horloge système avec le serveur NTP lorsque l'écart de l'horloge est supérieur à 5 secondes.
Solution :
Connectez-vous en SSH aux nœuds et configurez RootDistanceMaxSec:
mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
|
| Mises à niveau et 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 gkectl pour mettre à jour un cluster d'administrateur version 1.12, vous pouvez rencontrer l'erreur suivante:
Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"
Si vous utilisez gkectl update admin pour des clusters version 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 plusieurs modifications incluent la définition de osImageType, qui passe d'une chaîne vide à ubuntu_containerd.
Ces erreurs de mise à jour sont dues à un remplissage incorrect du champ osImageType dans la configuration du cluster d'administrateur depuis son lancement dans la version 1.9.
Solution :
Effectuez la mise à niveau vers une version d'Clusters Anthos sur VMware avec le correctif. Si cela n'est pas possible, contactez le Cloud Customer Care pour résoudre ce problème.
|
| Installation, sécurité |
1,13, 1,14, 1,15 |
L'extension SNI ne fonctionne pas sur les clusters d'utilisateur avec Controlplane V2
La possibilité de fournir un certificat de diffusion supplémentaire pour le serveur d'API Kubernetes d'un cluster d'utilisateur avec
authentication.sni ne fonctionne pas lorsque le plan de contrôle V2 est activé (
enableControlplaneV2: true).
Solution :
Tant que ce correctif ne sera pas disponible, si vous devez utiliser l'extension 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é provoque un échec de démarrage de la machine du plan de contrôle administrateur
La machine de plan de contrôle d'administrateur 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'administrateur, 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 d'Clusters Anthos sur VMware avec le correctif.
|
| Mises à niveau et mises à jour |
1.12.0 à 1.12.4 |
Avertissements de faux positifs concernant des 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, que vous pouvez ignorer.
console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
...
- CARotation: &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
+ CARotation: nil,
...
}
|
| Mises à niveau et 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 des clés de signature KSA
Une fois que vous avez rotté les clés de signature KSA, puis
mis à jour un cluster d'utilisateur, 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 :
Remplacez la version de votre clé de signature KSA par la version 1, 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 et récupérez 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 ksa-signing-key précédent:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
- Mettez à jour le champ
data.data dans le ConfigMaps 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'utilisateur cible soit prêt. Vous pouvez vérifier l'état:
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 toute autre rotation des clés de signature KSA jusqu'à ce que le cluster soit mis à niveau vers la version contenant le correctif.
|
| Opération |
1.13.1+, 1.14, 1.15 |
Lorsque vous utilisez Terraform pour supprimer un cluster d'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 permettant de nettoyer une partition F5 de cluster d'utilisateur.
|
| Installation, mises à niveau et mises à jour |
1.13.8 et 1.14.4 |
Le cluster de genre extrait les images de conteneurs 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 genre extrait les images de conteneur suivantes 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 échoue pour afficher le cluster.
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 semblables à celles-ci:
...
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 conteneurs doivent être préchargées dans l'image de conteneur du cluster de genre. Cependant, le genre v0.18.0 présente un problème avec les images de conteneurs préchargées : elles sont donc extraites d'Internet par erreur.
Solution :
Exécutez les commandes suivantes sur le poste de travail administrateur, pendant que votre cluster d'administrateur est en attente de création ou de mise à niveau:
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 d'utilisateur et le cluster d'administrateur HA ControlPlane V2 lorsque le réseau exclut les requêtes GARP en double
Si les VM de votre cluster sont connectées à un commutateur qui filtre les requêtes ARP en double, l'élection du responsable de keepalife peut rencontrer une condition de concurrence, ce qui peut donner lieu à 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 expire.
Solution :
Exécutez la commande suivante sur chaque nœud de plan de contrôle du cluster concerné:
iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
|
| Mises à niveau et 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 provoque le plantage de vsphere-csi-controller après la rotation.
Solution :
Pour les clusters créés à partir de la version 1.13, 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 échoue en cas d'erreur d'enregistrement du cluster.
Même en cas d'échec de l'enregistrement du cluster lors de la création du cluster d'administrateur, la commande gkectl create admin n'échoue pas sur l'erreur et peut réussir. En d'autres termes, la création du cluster d'administrateur peut "aboutir" 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" et
Failed to register admin cluster
Vous pouvez également vérifier si vous pouvez trouver le cluster parmi les clusters enregistrés dans Cloud Console.
Solution :
Pour les clusters créés à partir de la version 1.12, suivez les instructions pour relancer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters créés dans des versions antérieures,
-
Ajouter une paire clé-valeur fictive comme "foo: bar" au fichier de clé SA connect-register
-
Exécutez
gkectl update admin pour réenregistrer le cluster d'administrateur.
|
| Mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13.0 à 1.13.1 |
La réinscription du cluster d'administrateur peut être ignorée lors de la mise à niveau du cluster d'administrateur.
Lors de la mise à niveau du cluster d'administrateur, si le délai de mise à niveau des nœuds du plan de contrôle utilisateur expire, il ne sera pas réenregistré avec la version mise à jour de l'agent Connect.
Solution :
Vérifiez si le cluster figure parmi les clusters enregistrés.
Vous pouvez également vous connecter au cluster après avoir configuré l'authentification. Si le cluster est toujours enregistré, vous pouvez ignorer les instructions suivantes pour réessayer.
Pour les clusters mis à niveau vers la version 1.12 ou une version ultérieure, suivez les instructions permettant de relancer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters mis à niveau vers des versions antérieures, procédez comme suit :
-
Ajouter une paire clé-valeur fictive comme "foo: bar" au fichier de clé SA connect-register
-
Exécutez
gkectl update admin pour réenregistrer le cluster d'administrateur.
|
| Configuration |
1.15.0 |
Faux message d'erreur concernant vCenter.dataDisk
Pour un cluster d'administrateur à haute disponibilité, gkectl prepare affiche le faux message d'erreur suivant:
vCenter.dataDisk must be present in the AdminCluster spec
Solution :
Vous pouvez ignorer ce message d'erreur.
|
| VMware |
1.15.0 |
Échec de la création du pool de nœuds en raison de règles d'affinité redondantes pour les VM et les hôtes
Lors de la création d'un pool de nœuds utilisant l'affinité VM-hôte, une condition de concurrence 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 permettre la création du pool de nœuds.
Ces règles sont nommées [USER_CLUSTER_NAME]-[HASH].
|
| Opération |
1.15.0 |
gkectl repair admin-master peut échouer pour la raison suivante : 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. Elle peut être réexécutée de manière sécurisée jusqu'à ce que la commande aboutisse.
|
| Mises à niveau et mises à jour |
1.15.0 |
Les pods restent en état "Échec de la recréation ou la mise à jour d'un nœud de plan de contrôle"
Après avoir recréé ou mis à jour un nœud de plan de contrôle, certains pods peuvent rester à l'état Failed en raison de l'échec du prédicat NodeAffinity. Ces pods ayant échoué n'ont aucune incidence sur le fonctionnement normal du cluster ni sur son état.
Solution :
Vous pouvez ignorer les pods défaillants ou les supprimer manuellement.
|
| Sécurité, configuration |
1.15 |
OnPremUserCluster n'est pas prêt en raison des identifiants de registre privés
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é, onPremUserCluster peut ne pas être prêt. Le message d'erreur suivant peut s'afficher:
failed to check secret reference for private registry …
Solution :
Préparez les identifiants de registre privés du cluster d'utilisateur en suivant les instructions de la section Configurer les identifiants préparés.
|
| Mises à niveau et mises à jour |
1.15.0 |
Pendant gkectl upgrade admin, la vérification préliminaire du stockage pour la migration CSI vérifie que les StorageClasses ne comportent aucun paramètre ignoré après la migration CSI.
Par exemple, s'il existe une StorageClass avec le paramètre diskformat, gkectl upgrade admin la signale et signale un échec lors de la validation préliminaire.
Les clusters d'administrateur créés dans Anthos 1.10 et versions antérieures disposent d'une StorageClass avec diskformat: thin, qui échouera à cette validation. Toutefois, cette StorageClass fonctionne toujours correctement après la migration CSI. Ces échecs doivent être interprétés comme des avertissements.
Pour en savoir plus, consultez la section "Paramètre StorageClass" de la page Migrer des volumes vSphere In-Tree vers le plug-in de stockage de conteneurs vSphere.
Solution :
Après avoir vérifié que votre cluster dispose d'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 |
Les volumes vSphere migrés dans les arbres à 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, la mise à niveau d'un cluster ou la mise à jour d'un pool de nœuds). Les charges de travail avec état qui fonctionnaient correctement auparavant peuvent ne pas pouvoir écrire dans leurs volumes sur le nouvel ensemble de nœuds.
Solution :
-
Obtenez l'UID du pod qui ne peut pas écrire dans son volume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
POD_NAME --namespace POD_NAMESPACE \
-o=jsonpath='{.metadata.uid}{"\n"}'
-
Utilisez la PersistentVolumeClaim pour obtenir le nom du PersistentVolume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
PVC_NAME --namespace POD_NAMESPACE \
-o jsonpath='{.spec.volumeName}{"\n"}'
-
Déterminez 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 shell au nœud via SSH ou 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 du 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 à l'état
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 afin qu'il soit redémarré:
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 et mises à jour |
1.12, 1.13.0 à 1.13.7, 1.14.0 à 1.14.4 |
vsphere-csi-secret n'est pas mise à jour après gkectl update credentials vsphere --admin-cluster
Si vous mettez à jour les identifiants vSphere pour un cluster d'administrateur après avoir mis à jour les identifiants de cluster, vous pourriez trouver vsphere-csi-secret sous l'espace de noms kube-system dans le cluster d'administrateur.
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 obtenu à l'étape ci-dessus:
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 de plusieurs façons:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
Une fois le déploiement déployé, le vsphere-csi-secret mis à jour doit être utilisé par le contrôleur.
|
| Mises à niveau et mises à jour |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
audit-proxy boucle de plantage lors de l'activation de Cloud Audit Logs avec gkectl update cluster
audit-proxy pourrait planter en raison du --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 conteneur / pod d'audit-proxy.
Solution :
Pour un cluster d'utilisateur de plan de contrôle v2 avec enableControlplaneV2: true, connectez-vous à la machine du plan de contrôle utilisateur à l'aide de SSH, puis mettez à jour /etc/kubernetes/manifests/audit-proxy.yaml avec --cluster_name=USER_CLUSTER_NAME.
Pour un cluster d'utilisateur de 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 et mises à jour |
1.11, 1.12, 1.13.0 – 1.13.5, 1.14.0 - 1.14.1 |
Un redéploiement du plan de contrôle supplémentaire juste après gkectl upgrade cluster
Juste après gkectl upgrade cluster, les pods du plan de contrôle peuvent être redéployés.
L'état du cluster gkectl list clusters passe de RUNNING à RECONCILING.
Les requêtes envoyées au cluster d'utilisateur peuvent expirer.
En effet, la rotation des certificats du plan de contrôle s'effectue automatiquement après gkectl upgrade cluster.
Ce problème ne concerne que les clusters d'utilisateurs qui n'utilisent PAS le plan de contrôle v2.
Solution :
Attendez que l'état du cluster redevienne RUNNING dans gkectl list clusters ou passez aux versions corrigées: 1.13.6+, 1.14.2+ ou 1.15+.
|
| Mises à niveau et mises à jour |
1.12.7 |
La version 1.12.7-gke.19 a été supprimée
Les clusters Anthos sur VMware 1.12.7-gke.19 sont une mauvaise version. Vous ne devez donc 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 et mises à jour |
1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3 |
gke-connect-agent continue à 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 le registre privé n'est pas utiliségkectl update credentials privateregistry si vous utilisez un registre privé
gke-connect-agent peut continuer à utiliser l'ancienne image, ou les pods gke-connect-agent ne peuvent pas être récupérés en raison de ImagePullBackOff.
Ce problème sera résolu dans les versions 1.13.8 et 1.14.4 des clusters Anthos sur VMware, ainsi que dans les versions suivantes.
Solution :
Option 1: redéployez gke-connect-agent manuellement:
- Supprimez l'espace de noms
gke-connect :
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- Redéployez
gke-connect-agent avec la clé de compte de service d'enregistrement d'origine (il n'est pas nécessaire de la mettre à jour):
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 d'extraction d'image regcred, qui est 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 d'extraction d'image par défaut pour votre cluster dans le déploiement gke-connect-agent:
- 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 et 1,14 |
Échec manuel de la vérification de la configuration de l'équilibreur de charge
Lorsque vous validez la configuration avant de créer un cluster avec l'équilibreur de charge manuel en exécutant gkectl check-config, la commande échoue avec les messages d'erreur suivants.
- 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 1.13.7 et 1.14.4 du correctif qui comprendront 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 |
etcd
Les clusters exécutant la version 3.4.13 ou antérieure d' etcd peuvent rencontrer des problèmes de surveillance des ressources et de surveillance des ressources non opérationnelles, ce qui peut entraîner les problèmes suivants:
- La planification des pods est interrompue
- Impossible d'enregistrer les nœuds
- Kubelet n'observe pas les modifications du pod
Ces problèmes peuvent rendre le cluster non fonctionnel.
Ce problème est résolu dans les versions 1.12.7, 1.13.6 et 1.14.3 des clusters Anthos sur VMware, ainsi que dans les versions ultérieures. Ces versions plus récentes utilisent la version 3.4.21 d'Etd. Toutes les versions précédentes des clusters Anthos sur VMware sont affectées par ce problème.
Solution
Si vous ne pouvez pas procéder à une mise à niveau immédiate, vous pouvez réduire le risque de défaillance du cluster en réduisant le nombre de nœuds qu'il contient. Supprimez les nœuds jusqu'à ce que la métrique etcd_network_client_grpc_sent_bytes_total soit inférieure à 300 Mbit/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 et mises à jour |
1.10, 1.11, 1.12, 1.13 et 1.14 |
Anthos Identity Service peut entraîner des latences du plan de contrôle
Lors des redémarrages ou des mises à niveau du cluster, Anthos Identity Service peut être submergé par le trafic constitué de jetons JWT expirés et transférés de kube-apiserver à Anthos Identity Service via le webhook d'authentification. Bien qu'Anthos Identity Service ne plante pas, il ne répond plus et cesse de diffuser d'autres requêtes.
Au final, ce problème entraîne une latence plus élevée du plan de contrôle.
Ce problème est résolu dans les versions suivantes de Clusters Anthos sur VMware:
- 1.12.6 et supérieures
- 1.13.6 et supérieures
- 1.14.2 et supérieures
Pour déterminer si vous êtes concerné, procédez comme suit:
- Vérifiez si le point de terminaison Anthos 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 du plan de contrôle et par le port de l'équilibreur de charge du plan de contrôle pour votre cluster (par exemple, 172.16.20.50:443).
Si vous êtes affecté par ce problème, la commande renvoie un code d'état 400. Si la requête expire, redémarrez le pod ais et réexécutez la commande curl pour voir si cela résout le problème. Si le code d'état 000 s'affiche, le problème a été résolu et vous avez terminé. Si vous obtenez toujours un code d'état 400, le serveur HTTP Anthos Identity Service ne démarre pas. Dans ce cas, continuez.
- Vérifiez les journaux Anthos Identity Service et kube-apiserver :
- Consultez le journal Anthos Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
Si le journal contient une entrée semblable à la suivante, cela signifie que vous êtes concerné par le 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 pour vos clusters:
Dans les commandes suivantes, KUBE_APISERVER_POD est le nom du pod kube-apiserver sur le 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 semblables aux suivantes, 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 la correction, vous pouvez identifier et redémarrer les pods en question en guise de solution:
- Augmentez le niveau de verbosité d'Anthos 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
- Consultez le journal d'Anthos Identity Service pour identifier le contexte de jeton non valide:
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 voir le nom et l'espace de noms du pod source, copiez le jeton dans le débogueur à l'adresse 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 pour les pods de maintenance etcd
Les pods de maintenance etcd qui utilisent l'image etcddefrag:gke_master_etcddefrag_20210211.00_p0 sont affectés. Le conteneur "etcddefrag" ouvre une nouvelle connexion au serveur etcd à chaque cycle de décodage, et les anciennes connexions ne sont pas nettoyées.
Solution :
Option 1: Effectuez la mise à niveau vers la dernière version du correctif 1.8 vers la version 1.11 qui contient le correctif.
Option 2: Si vous utilisez une version de correctif antérieure aux versions 1.9.6 et 1.10.3, vous devez effectuer un scaling à la baisse du pod de maintenance etcd pour le cluster d'administrateur et 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 et 1.13 |
Manque de vérification des états des pods du plan de contrôle du cluster d'utilisateur
Le contrôleur d'é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, ils commencent à ignorer les pods du plan de contrôle utilisateur par erreur. L'utilisation du mode Plan de contrôle v2 n'affecte pas votre cluster.
Solution :
Cela n'affectera aucune gestion des charges de travail ni des clusters. Si vous souhaitez vérifier le bon fonctionnement 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 et mises à jour |
1.6 et versions supérieures, 1.7 et plus |
Les mises à niveau de cluster d'administrateur 1.6 et 1.7 peuvent être affectées par la redirection k8s.gcr.io -> registry.k8s.io
Kubernetes a redirigé le trafic de k8s.gcr.io vers registry.k8s.io le 20/03/2023. Dans Clusters Anthos sur VMware 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'administrateur é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
Échec de gkectl create loadbalancer 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 fichier de groupe Seesaw existant. La vérification préliminaire tente de valider un équilibreur de charge Seesaw 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 du délai de l'application dues à des échecs d'insertion de table conntrack
Les clusters Anthos sur VMware version 1.14 sont susceptibles d'échouer lors de l'insertion d'une table de suivi netfilter lors de l'utilisation d'images de système d'exploitation Ubuntu ou COS. Les échecs d'insertion entraînent des délais d'expiration d'application aléatoires et peuvent se produire même lorsque la table conntrack peut accueillir de nouvelles entrées. Les échecs sont dus à des modifications apportées à partir de la version 5.15 du noyau, qui restreignent l'insertion de la table en fonction de la longueur de la chaîne.
Pour savoir si vous êtes concerné par ce problème, vous pouvez consulter les statistiques du système de suivi des connexions du 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
L'atténuation à court terme consiste à augmenter la taille de la table de hachage netfiler (nf_conntrack_buckets) et de la table de suivi de connexion netfilter (nf_conntrack_max). Utilisez les commandes suivantes sur chaque nœud du cluster pour augmenter la taille des tables:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Remplacez TABLE_SIZE par une nouvelle taille en octets. La valeur de la taille de la table par défaut est 262144. Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs sur le 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 anetd-operator sur les nœuds Windows avec Controlplane v2
Avec Controlplane v2 ou un nouveau modèle d'installation, calico-typha ou anetd-operator peuvent être programmés sur les nœuds Windows et être placés en boucle.
La raison est que les deux déploiements tolèrent tous les rejets, y compris les rejets de nœuds Windows.
Solution :
Passez à la version 1.13.3+ ou exécutez les commandes suivantes pour modifier le déploiement "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 suivantes:
- 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 du registre privé du cluster d'utilisateur
Vous ne pourrez peut-être pas créer de cluster d'utilisateur si vous spécifiez la section privateRegistry avec les identifiants fileRef.
La requête préliminaire peut échouer avec le message suivant:
[FAILURE] Docker registry access: Failed to login.
Solution :
- Si vous n'avez pas l'intention de spécifier le champ ou que vous souhaitez utiliser les mêmes identifiants de registre privés que ceux du cluster d'administrateur, il vous suffit de supprimer ou de commenter la section
privateRegistry dans le fichier de configuration de votre cluster d'utilisateur.
- Si vous souhaitez utiliser des identifiants de registre privés spécifiques pour votre cluster d'utilisateur, 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'un correctif temporaire. Ces champs sont déjà obsolètes. Pensez à utiliser le fichier d'identifiants lorsque vous passez à la version 1.14.3 ou ultérieure.)
|
| Opérations |
1.10+ |
Anthos Service Mesh et autres maillages de services non compatibles avec Dataplane v2
Dataplane V2 prend en charge l'équilibrage de charge et crée un socket de noyau au lieu d'un DNAT basé sur un paquet. Cela signifie qu'Anthos Service Mesh ne peut pas effectuer d'inspection de paquets, car le pod est contourné et n'utilise jamais de tables IPTables.
Cela se manifeste en mode sans frais de kube-proxy en raison d'une perte de connectivité ou d'un routage du trafic incorrect pour les services avec Anthos Service Mesh, car le side-car ne peut pas inspecter les paquets.
Ce problème est présent sur toutes les versions d'clusters Anthos sur bare metal 1.10, mais certaines versions plus récentes de 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 utilisez la version 1.10.2 ou une version 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 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 manière forcée les volumes persistants au bout de six minutes
kube-controller-manager peut dépasser le délai lors de la dissociation de PV/PVC, puis dissocier de manière forcée les PV/PVC. Des 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
Les erreurs suivantes s'affichent dans le journal de kubelet:
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 et mises à jour |
1.12+, 1.13+, 1.14 et plus |
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 et plus |
gkectl repair admin-master crée la VM maître administrateur sans mettre à niveau la version matérielle de sa VM.
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 survient, une 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 nœud.
|
| Système d'exploitation |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15 et plus |
La VM libère le bail DHCP lors de l'arrêt ou du redémarrage de manière inattendue, ce qui peut entraîner des modifications d'adresses IP
Dans systemv v244, systemd-networkd présente un changement de comportement par défaut dans la configuration KeepConfiguration. Avant cette modification, les VM n'envoyaient pas de message de version du bail DHCP au serveur DHCP à l'arrêt ou au redémarrage. Après cette modification, les VM envoient un message de ce type et renvoient les adresses IP au serveur DHCP. Par conséquent, l'adresse IP libérée peut être réaffectée à une VM différente et/ou une autre adresse IP peut être attribuée à la VM, ce qui peut entraîner un conflit d'adresses IP (au niveau de Kubernetes et non au niveau de vSphere) et/ou des modifications d'adresses IP sur les VM, ce qui peut endommager les clusters de différentes manières.
Par exemple, vous pouvez constater les symptômes suivants.
- L'UI de vCenter indique qu'aucune VM n'utilise la même adresse IP, mais
kubectl get
nodes -o wide renvoie les 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 de l'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 annuler le changement de comportement par défaut systemd-networkd. Les VM qui exécutent ce DaemonSet ne libèrent pas les adresses IP du serveur DHCP lors de leur arrêt/redémarrage. Les adresses IP sont automatiquement libérées par le serveur DHCP lorsque les baux expirent.
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
|
| Fonctionnement, mises à niveau et mises à jour |
1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Clé de compte de service d'accès aux composants effacée après la mise à niveau du cluster d'administrateur 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. Il ne concerne pas les clusters d'administrateur qui sont créés après la version 1.12.
Après la mise à niveau d'un cluster 1.11.x vers la version 1.12.x, le champ component-access-sa-key du secret admin-cluster-creds est effacé.
Pour ce faire, 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 le résultat est vide, la clé est effacée.
Une fois la clé du compte de service d'accès aux composants supprimée, l'installation de nouveaux clusters d'utilisateur ou la mise à niveau de clusters d'utilisateur existants échouent. Voici quelques messages d'erreur que vous pouvez rencontrer:
- Échec de la validation préliminaire lente avec le message d'erreur:
"Failed
to create the test VMs: failed to get service account key: service
account is not configured."
- Échec de la préparation de
gkectl prepare avec le message d'erreur : "Failed to prepare OS images: dialing: unexpected end of JSON
input"
- Si vous mettez à niveau un cluster d'utilisateur 1.13 à l'aide de Google Cloud Console ou de gcloud CLI, 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 et le message suivant s'affiche: "failed to download bundle to disk: dialing:
unexpected end of JSON input" (vous pouvez voir ce message dans le champ status dans le résultat de kubectl --kubeconfig
ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).
Solution :
Ajoutez manuellement la clé du compte de service d'accès au 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 et versions supérieures, 1.14.0 et supérieures |
L'autoscaler de cluster ne fonctionne pas lorsque Controlplane V2 est activé
Pour les clusters d'utilisateur créés avec Controlplane V2 ou un nouveau modèle d'installation, les pools de nœuds sur lesquels l'autoscaling est activé utilisent toujours leurs autoscaling.minReplicas dans le fichier user-cluster.yaml. Le journal du pod cluster-autoscaler indique également qu'ils ne sont pas opérationnels.
> 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ésactiver l'autoscaling dans tous les pools de nœuds avec "gkectl update cluster" jusqu'à la mise à niveau vers une version corrigée
|
| Installation |
1.12.0 à 1.12.4, 1.13.0 à 1.13.3, 1.14.0 |
CIDR n'est pas autorisé dans le fichier de bloc d'adresses IP
Lorsque les utilisateurs utilisent le CIDR dans le fichier de blocs d'adresses IP, la validation de la configuration échoue avec 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 bloc d'adresses IP jusqu'à la version 1.12.5, 1.13.4 ou 1.14.1 (ou version ultérieure).
|
| Mises à niveau et 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
Lors de la mise à jour du type d'image d'OS du plan de contrôle dans admin-cluster.yaml, et si le cluster d'utilisateur correspondant a été créé via Controlplane V2, les machines de plan de contrôle d'utilisateur peuvent ne pas terminer leur recréation une fois la commande gkectl terminée.
Solution :
Une fois la mise à jour terminée, attendez que les machines du plan de contrôle de l'utilisateur terminent leur recréation en surveillant les types d'images de leur système d'exploitation à 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 d'Ubuntu à COS, même après l'exécution de la commande de mise à jour.
|
| Opération |
1.14.0 |
Erreurs de création ou de suppression de pod dues à un problème de jeton d'authentification du compte de service Calico
Un problème lié à Calico dans Clusters Anthos sur VMware 1.14.0 entraîne l'échec de la création et de la suppression des pods avec le message d'erreur suivant dans le résultat de kubectl describe pods:
error getting ClusterInformation: connection is unauthorized: Unauthorized
Ce problème n'est observé que 24 heures après la création ou la mise à niveau du cluster vers la version 1.14 à l'aide de Calico.
Les clusters d'administrateur utilisent toujours Calico. 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 fichier kubeconfig avec un jeton valide 24 heures. Ce jeton doit être renouvelé régulièrement 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 :
Pour atténuer le problème, appliquez le correctif suivant sur le DaemonSet calico-node de votre cluster d'administrateur et d'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 de votre 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 lors de l'utilisation de CIDR
La création du cluster échoue, alors que l'utilisateur dispose de la configuration appropriée. La création échoue, car le cluster ne dispose pas de suffisamment d'adresses IP.
Solution :
Divisez les CIDR en plusieurs blocs CIDR plus petits, tels que 10.0.0.0/30 devient 10.0.0.0/31, 10.0.0.2/31. Tant que les CIDR N+1 sont associés, où N est le nombre de nœuds du cluster, cela devrait suffire.
|
| Opération, mises à niveau et 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 la clé et la configuration de chiffrement des secrets toujours activés
Lorsque la fonctionnalité de chiffrement des secrets "Toujours activé" est activée en même temps que la sauvegarde du cluster, celle-ci ne comprend pas les clés de chiffrement ni la configuration requises par la fonctionnalité de chiffrement des secrets "Toujours activé". Par conséquent, la réparation du maître d'administration avec cette sauvegarde à l'aide de gkectl repair admin-master --restore-from-backup génère 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 afin d'effectuer la sauvegarde du cluster d'administrateur après les opérations critiques du cluster. Par exemple, si le cluster exécute une version 1.10.2, utilisez le binaire 1.10.5 gkectl pour effectuer une sauvegarde manuelle du cluster d'administrateur comme décrit dans Sauvegarder et restaurer un cluster d'administrateur avec gkectl.
|
| Opération, mises à niveau et mises à jour |
1.10+ |
Recréer la VM maîtresse avec un nouveau disque de démarrage (ex. : gkectl repair admin-master) échoueront si la fonctionnalité de chiffrement des secrets toujours activée est activée à l'aide de la commande "gkectl update".
Si la fonctionnalité de chiffrement des secrets toujours activée n'est pas activée lors de la création du cluster, mais activée ultérieurement à 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. Il est recommandé d'activer la fonctionnalité de chiffrement des secrets toujours activée lors de la création du cluster. Il n'existe actuellement aucune mesure d'atténuation.
|
| Mises à niveau et mises à jour |
1.10 |
La mise à niveau du premier cluster d'utilisateur de la version 1.9 vers la version 1.10 recrée les nœuds d'autres clusters d'utilisateur
La mise à niveau du premier cluster d'utilisateur de la version 1.9 vers la version 1.10 peut recréer les nœuds d'autres clusters d'utilisateur sous le même cluster d'administrateur. La recréation s'effectue 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 sur tous les MachineDeployment.
Solution :
Afficher la procédure de contournement
|
| Mises à niveau et mises à jour |
1.10.0 |
Docker redémarre fréquemment après la mise à niveau du cluster
Mettre à niveau le cluster d'utilisateur vers la version 1.10.0 peut entraîner fréquemment le redémarrage 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 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 comprendre la cause première, vous devez vous connecter en SSH au nœud contenant le symptôme et exécuter des commandes telles que sudo journalctl --utc -u docker ou sudo journalctl -x.
Solution :
|
| Mises à niveau et mises à jour |
1,11 et 1,12 |
Les composants GMP autodéployés ne sont pas conservés après la mise à niveau vers la version 1.12.
Si vous utilisez une version de Clusters Anthos sur VMware antérieure à la version 1.12 et que vous avez configuré manuellement les composants Prometheus de Google (GMP) gérés dans l'espace de noms gmp-system de votre cluster, ces composants ne sont pas conservés lorsque vous passez à la version 1.12.x.
À partir de la version 1.12, les composants GMP dans l'espace de noms gmp-system et les objets CRD sont gérés par l'objet stackdriver, l'indicateur enableGMPForApplications étant défini sur false par défaut. Si vous déployez manuellement les 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 d'instantané de cluster system
Dans le scénario system, l'instantané du cluster n'inclut aucune ressource sous l'espace de noms default.
Cependant, certaines ressources Kubernetes, telles que les objets API Cluster qui se trouvent sous cet espace de noms, contiennent des informations de débogage utiles. Ils doivent être inclus dans l'instantané du cluster.
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 et 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 lors du drainage du nœud pour la configuration de vSAN
Lors de la suppression, de la mise à jour ou de la mise à niveau d'un cluster d'utilisateur, le drainage de nœud peut être bloqué dans les cas suivants:
- Le cluster d'administrateur utilise le pilote CSI vSphere sur vSAN depuis la version 1.12.x.
- Aucun objet PVC/PV n'est créé par les plug-ins vSphere arborescence dans le cluster d'administrateur et d'utilisateur.
Pour identifier le symptôme, exécutez la commande suivante:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Voici un exemple de message d'erreur provenant 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 pour le pilote in-tree vSphere. Si aucun objet PVC/PV n'est créé, vous risquez de rencontrer un bug qui empêchera le drainage 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 champ 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 et 1.14 |
Cluster Autoscaler clusterrolebinding et clusterrole sont supprimés après la suppression d'un cluster d'utilisateur.
Lors de la suppression du cluster d'utilisateur, les valeurs clusterrole et clusterrolebinding correspondantes pour l'autoscaler de cluster sont également supprimées. Cela affecte tous les autres clusters d'utilisateur du même cluster d'administrateur pour lequel l'autoscaler de cluster est activé. En effet, les mêmes cluster et cluster de liaison sont utilisés pour tous les pods d'autoscaler de cluster du même cluster d'administrateur.
Les symptômes sont les suivants:
- 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 des exemples de messages d'erreur susceptibles de s'afficher:
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 contournement
Vérifier si le cluster et la liaison de cluster 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 la liaison de cluster suivants au cluster d'administrateur s'ils sont manquants. Ajoutez les objets de compte de service au clusterrolebinding pour chaque cluster d'utilisateur.
-
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 et 1.13 |
Le cluster d'administrateur cluster-health-controller et vsphere-metrics-exporter ne fonctionnent pas après la suppression du cluster d'utilisateur
Lors de la suppression du cluster d'utilisateur, le clusterrole correspondant est également supprimé, ce qui empêche l'exportateur de métriques de réparation automatique et vSphere.
Les symptômes sont les suivants:
- 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 des exemples de messages d'erreur susceptibles de s'afficher:
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 des exemples de messages d'erreur susceptibles de s'afficher:
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 contournement
Appliquez le fichier 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 gkectl check-config lors de la validation de l'image de l'OS
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 suggérons d'exécuter la commande avant d'exécuter gkectl prepare.
Le symptôme à l'échec de la commande gkectl check-config est le 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 d'OS.
|
| Mises à niveau et mises à jour |
1,11, 1,12, 1,13 |
gkectl update admin/cluster ne réussit pas à mettre à jour les groupes d'anti-affinité.
Problème connu pouvant entraîner l'échec de gkectl update admin/cluster lors de la mise à jour de anti affinity groups.
Le symptôme à l'échec de la commande gkectl update est le 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 la procédure de contournement
Pour que la mise à jour soit prise en compte, les machines doivent être recréées after.
Pour mettre à jour le cluster d'administrateur, les nœuds maîtres et les nœuds complémentaires d'administrateur doivent être recréés
Pour mettre à jour le cluster d'utilisateur, les nœuds de calcul des utilisateurs doivent être recréés
Pour recréer des nœuds de calcul d'utilisateurs
Option 1
Suivez la procédure de mise à jour d'un pool de nœuds et modifiez le processeur ou la mémoire pour déclencher la recréation progressive des nœuds.
Option 2
Utilisez 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
Suivez le redimensionnement du plan de contrôle, puis modifiez le processeur ou la mémoire pour déclencher la recréation progressive des nœuds.
Option 2
Utilisez kubectl delete pour recréer les machines une par une.
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
Pour recréer des nœuds de module complémentaire administrateur
Utiliser kubectl delete pour recréer les machines une par une
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
| Installation, mises à niveau et mises à jour |
1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0 |
L'enregistrement du nœud échoue lors de la création, de la mise à niveau, de la mise à jour et de la réparation automatique du nœud, lorsque ipMode.type est défini sur static et que le nom d'hôte configuré dans le fichier de bloc d'adresses IP contient une ou plusieurs périodes. Dans ce cas, les requêtes de signature de certificat (CSR) d'un nœud ne sont pas automatiquement approuvées.
Pour afficher les requêtes de signature de certificat en attente pour un nœud, exécutez la commande suivante:
kubectl get csr -A -o wide
Recherchez les messages d'erreur dans les journaux suivants:
- Affichez les journaux du cluster d'administrateur 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 un exemple de messages d'erreur susceptibles de s'afficher: "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 messages d'erreur susceptibles de s'afficher: "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 bloc d'adresses IP, les caractères qui suivent le premier point seront ignorés. Par exemple, si vous spécifiez le nom d'hôte en tant que bob-vm-1.bank.plc, le nom d'hôte et le nom du nœud de la VM seront définis sur bob-vm-1.
Lorsque la validation de l'ID du nœud est activée, l'approbateur du service de comparateur de prix compare le nom du nœud au nom d'hôte indiqué dans la spécification de la machine, puis il ne parvient pas à rapprocher le nom. L'approbateur refuse la requête de signature de certificat, et le nœud ne parvient pas à amorcer la procédure.
Solution :
Cluster d'utilisateur
Pour désactiver la validation de l'ID de nœud:
- Ajoutez les champs suivants à votre fichier de configuration de cluster d'utilisateur:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- Enregistrez le fichier et 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 de votre cluster d'utilisateur.
Cluster d'administration
- 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 de
controllers:
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Modifiez cette section comme indiqué ci-dessous:
--controllers=*,bootstrapsigner,tokencleaner
- Ouvrez le contrôleur d'API Deployment Cluster 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 et mises à jour |
1.11.0 à 1.11.4 |
Échec du démarrage de la machine du plan de contrôle administrateur causé par un bundle de certificats du registre privé
La création/mise à niveau du cluster d'administrateur est bloquée indéfiniment dans le journal suivant:
Waiting for Machine gke-admin-master-xxxx to become ready...
Le journal du contrôleur d'API du cluster dans l'
instantané de cluster externe contient le journal suivant:
Invalid value 'XXXX' specified for property startup-data
Voici un exemple de chemin d'accès au fichier journal du contrôleur d'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.
|
| Mise en réseau |
1.10, 1.11.0 à 1.11.3, 1.12.0 à 1.12.2, 1.13.0 |
NetworkGatewayNodes marqué comme non opérationnel suite à un conflit d'actualisation d'état simultané
Dans networkgatewaygroups.status.nodes, certains nœuds passent de NotHealthy à Up.
Les journaux du pod ang-daemon exécuté sur ce nœud révèlent des erreurs répétées:
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 les autres nœuds ou un manque de redondance pour la haute disponibilité.
Cela n'a aucune incidence sur l'activité du plan de données.
Les conflits au niveau de l'objet networkgatewaygroup entraînent l'échec de certaines mises à jour de l'état en raison d'une erreur de traitement des nouvelles tentatives. Si un trop grand nombre de mises à jour de l'état échoue, ang-controller-manager considère que le nœud a dépassé sa limite de temps de pulsation et le marque NotHealthy.
Correction de l'erreur dans le traitement des nouvelles tentatives dans les versions ultérieures
Solution :
Passez à une version corrigée, si disponible.
|
| Mises à niveau et mises à jour |
1.12.0 à 1.12.2, 1.13.0 |
La condition de concurrence bloque la suppression des objets machine pendant et lors des mises à jour ou des mises à niveau
Un problème connu pourrait entraîner le blocage de la mise à niveau ou de la mise à jour du cluster en attendant la suppression de l'ancien objet machine. En effet, le finaliseur ne peut pas être supprimé de l'objet machine. Cela a une incidence sur les opérations de mise à jour progressive des pools de nœuds.
Le problème se produit lorsque 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 sont les suivantes:
$ 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 afin d'obtenir des exécutions réussies, même sans ce bug. La plupart du temps, elle peut s'effectuer rapidement, mais dans de rares cas, elle peut rester bloquée pendant plusieurs heures au niveau de cette condition de concurrence.
Le problème est que la VM sous-jacente est déjà supprimée dans vCenter, mais l'objet machine correspondant ne peut pas être supprimé, ce qui est bloqué lors de 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 à rapprocher le cluster pour 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 elle-même.
En fonction de l'analyse et de la reproduction dans votre environnement, la mise à niveau peut se terminer par elle-même sans intervention manuelle. Le problème de cette option est qu'il n'est pas certain que la suppression prendra fin pour chaque objet machine. Elle peut fonctionner immédiatement si la chance est suffisante, ou elle peut durer plusieurs heures si le rapprochement de la manette de l'ensemble de machines est trop rapide et qu'elle n'a jamais la possibilité de supprimer le finaliseur entre les rapprochements.
Bonne nouvelle : cette option ne nécessite aucune action de votre part et les charges de travail ne seront pas perturbées. La mise à niveau prend plus de temps.
- Option 2: Appliquez une annotation de réparation automatique à tous les anciens objets de la machine.
Le contrôleur de machineset filtre les machines dont l'annotation de réparation automatique et l'horodatage de suppression sont différents de zéro, et n'envoie pas d'appels de suppression sur ces machines pour éviter la condition de concurrence.
Inconvénient est que les pods sur les machines sont supprimés directement au lieu d'être évincés, ce qui signifie qu'ils ne respectent pas la configuration PDB. Cela peut entraîner un temps d'arrêt pour vos charges de travail.
La commande permettant d'obtenir tous les noms de machine:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
La commande permettant d'appliquer l'annotation de réparation automatique pour 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 se termine toujours pas au bout d'un certain temps, contactez notre équipe d'assistance pour résoudre le problème.
|
| Installation, mises à niveau et mises à jour |
1.10.2, 1.11, 1.12 et 1.13 |
gkectl prépare l'échec de la requête préliminaire de validation de l'image de l'OS
É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 incluent une validation incorrecte.
Solution :
Exécutez la même commande avec une option supplémentaire --skip-validation-os-images.
|
| Installation |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12 et 1.13 |
L'URL vCenter avec le préfixe https:// ou http:// peut entraîner un échec de démarrage du cluster
Échec de la création du cluster d'administrateur:
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 le cadre d'une clé secrète, qui n'est pas compatible avec "/" ni ":".
Solution :
Supprimez le préfixe https:// ou http:// du champ vCenter.Address dans le fichier YAML de configuration du cluster d'administrateur ou de l'utilisateur.
|
| Installation, mises à niveau et mises à jour |
1.10, 1.11, 1.12 et 1.13 |
Panique : gkectl prepare sur util.CheckFileExists
gkectl prepare peut paniquer à l'aide de la trace de 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 la mauvaise autorisation.
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 et mises à jour |
1.10, 1.11, 1.12 et 1.13 |
gkectl repair admin-master et la mise à niveau administrateur avec reprise ne fonctionnent pas ensemble
Après une tentative infructueuse de mise à niveau du cluster d'administrateur, n'exécutez pas gkectl
repair admin-master. Cela peut entraîner l'échec des tentatives de mise à niveau administrateur ultérieures, par exemple en cas d'échec du maître de l'administrateur ou si la VM est inaccessible.
Solution :
Si vous avez déjà rencontré ce problème, contactez l'assistance.
|
| Mises à niveau et mises à jour |
1,10 et 1,11 |
La reprise de la mise à niveau du cluster d'administrateur peut entraîner l'absence du modèle de VM du plan de contrôle d'administrateur
Si la machine du plan de contrôle d'administrateur n'est pas recréée après une nouvelle tentative de mise à niveau du cluster d'administrateur, le modèle de VM du plan de contrôle d'administrateur est supprimé. Le modèle de VM du plan de contrôle d'administrateur est le modèle du maître d'administration qui permet de récupérer la machine du plan de contrôle à l'aide de gkectl
repair admin-master.
Solution :
Le modèle de VM du plan de contrôle d'administrateur sera généré à nouveau lors de la mise à niveau suivante du cluster d'administrateur.
|
| Système d'exploitation |
1,12 et 1,13 |
cgroup v2 pourrait 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 sa publication.
|
| Identité |
1.10, 1.11, 1.12 et 1.13 |
Ressource personnalisée ClientConfig
gkectl update annule toutes 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 et 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 d'utilisateur en raison du problème d'élection du responsable de cert-manager/ca-injector
Il est possible que vous constatiez un échec de l'installation en raison de cert-manager-cainjector dans plantageloop lorsque le serveur d'API/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 contournement
Exécutez les commandes suivantes pour atténuer le problème.
Commencez par effectuer un scaling à la baisse de monitoring-operator afin d'annuler 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 nous n'avons qu'une seule instance dupliquée en cours d'exécution. Elle n'est pas requise pour une seule instance dupliquée:
# 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 YAML pertinent pour le déploiement 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
...
Limitez la valeur des instances dupliquées monitoring-operator à 0 jusqu'à la fin de l'installation. Sinon, la modification sera annulée.
Une fois l'installation terminée et le cluster opérationnel, activez le monitoring-operator pour les opérations du jour 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 limiter le problème jusqu'à ce que le problème soit résolu dans une prochaine version.
|
| Sécurité, mises à niveau et mises à jour |
1.10, 1.11, 1.12 et 1.13 |
Le renouvellement des certificats peut être requis avant la mise à niveau du cluster d'administrateur
Avant de commencer le processus de mise à niveau du cluster d'administrateur, assurez-vous que les certificats de votre cluster d'administrateur sont actuellement valides. Si ce n'est pas le cas, renouvelez-les.
Si vous avez commencé le processus de mise à niveau et que vous avez découvert une erreur liée à l'expiration du certificat, contactez l'assistance Google pour obtenir de l'aide.
Remarque: Ces conseils sont uniquement destinés au renouvellement des certificats de cluster d'administrateur.
Solution :
Afficher la procédure de contournement
Assurez-vous qu'OpenSSL est installé sur le poste de travail administrateur avant de commencer.
- Définissez la variable
KUBECONFIG :
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Remplacez ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès absolu au fichier kubeconfig du cluster d'administrateur.
- Obtenez l'adresse IP et les clés SSH du nœud maître administrateur :
kubectl --kubeconfig "${KUBECONFIG}" get secrets \
-n kube-system sshkeys \
-o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" \
get nodes -o \
jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
--selector='node-role.kubernetes.io/master')
- Vérifiez si les certificats ont expiré :
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
Si les certificats ont expiré, vous devez les renouveler avant de mettre à niveau le cluster d'administrateur.
- Étant donné que le fichier kubeconfig du cluster d'administrateur expire également si les certificats d'administrateur expirent, vous devez sauvegarder ce fichier avant l'expiration.
- Sauvegardez le fichier kubeconfig du cluster d'administrateur :
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
- Remplacez
client-certificate-data et client-key-data dans kubeconfig par client-certificate-data et client-key-data dans le fichier new_admin.conf que vous avez créé.
- Sauvegardez les anciens certificats. Cette étape est facultative, mais recommandée:
# ssh into admin master if you didn't in the previous step
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout
# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
- Renouvelez les certificats avec kubeadm :
# ssh into admin master
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo kubeadm alpha certs renew all
- Redémarrez les pods statiques exécutés sur le nœud maître administrateur:
# on admin master
cd /etc/kubernetes
sudo mkdir tempdir
sudo mv manifests/*.yaml tempdir/
sleep 5
echo "remove pods"
# ensure kubelet detect those change remove those pods
# wait until the result of this command is empty
sudo docker ps | grep kube-apiserver
# ensure kubelet start those pods again
echo "start pods again"
sudo mv tempdir/*.yaml manifests/
sleep 30
# ensure kubelet start those pods again
# should show some results
sudo docker ps | grep -e kube-apiserver -e kube-controller-manager \
-e kube-scheduler -e etcd
# clean up
sudo rm -rf tempdir
logout
- Vous devez valider les certificats renouvelés et le certificat de kube-apiserver. Vérifiez la date d'expiration des certificats :
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
- Vérifiez le certificat de kube-apiserver :
# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server
# Get the current kube-apiserver certificate
openssl s_client -showcerts -connect : \
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
> current-kube-apiserver.crt
# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate
|
| VMware |
1.10, 1.11, 1.12 et 1.13 |
Redémarrer ou mettre à niveau vCenter pour les versions antérieures à la version 7.0U2
Pour les versions antérieures à vCenter 7.0U2, vCenter est redémarré après une mise à niveau ou autrement. Le nom du réseau dans les informations de VM de vCenter est incorrect et l'état de la machine est Unavailable. À terme, cela entraîne la réparation automatique des nœuds pour en créer d'autres.
Bug Govmomi associé :
Solution :
Cette solution est fournie par l'assistance VMware :
- Le problème a été résolu dans vCenter 7.0U2 et les versions ultérieures.
- Pour les versions antérieures, effectuez un clic droit sur l'hôte, puis sélectionnez Connexion > Déconnecter. Ensuite, reconnectez-vous, ce qui force la mise à jour du groupe de ports de la VM.
|
| Système d'exploitation |
1.10, 1.11, 1.12 et 1.13 |
Connexion SSH fermée par l'hôte distant
Pour les clusters Anthos sur VMware version 1.7.2 ou ultérieure, les images d'OS Ubuntu sont renforcées avec le
Benchmark des serveurs CIS L1.
Pour respecter la règle CIS "5.2.16 Vérifier que l'intervalle d'inactivité en veille de SSH est configuré", /etc/ssh/sshd_config a les paramètres suivants:
ClientAliveInterval 300
ClientAliveCountMax 0
Ces paramètres visent à mettre fin à une session cliente 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 lorsque vous exécutez une commande chronophage, et que votre commande peut être arrêtée avec le message suivant:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Solution :
Vous disposez des options suivantes :
- Utilisez
nohup pour éviter que votre commande ne soit arrêtée à la déconnexion SSH.
nohup gkectl upgrade admin --config admin-cluster.yaml \
--kubeconfig kubeconfig
- Mettez à jour
sshd_config pour utiliser une valeur ClientAliveCountMax non nulle. 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
Assurez-vous de reconnecter votre session SSH.
|
| Installation |
1.10, 1.11, 1.12 et 1.13 |
cert-manager installation en conflit
Dans les versions 1.13, monitoring-operator installe cert-manager dans l'espace de noms cert-manager. Si, pour certaines raisons, vous devez installer votre propre cert-manager, procédez comme suit pour éviter les conflits:
Vous n'avez besoin d'appliquer ce travail qu'une seule fois pour chaque cluster. Les modifications seront conservées lors de la mise à niveau du cluster.
Remarque: Lors de l'installation de votre propre cert-manager, vous pouvez constater que la version ou l'image cert-manager (par exemple, v1.7.2) peut revenir à son ancienne version. Cela est dû au fait que monitoring-operator tente de rapprocher cert-manager et d'annuler la version au cours du processus.
Solution :
Éviter les conflits pendant 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
- Mettez le déploiement
monitoring-operator à zéro:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Faites passer les 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 votre cert-manager est installé dans l'espace de noms
cert-manager.
Sinon, copiez le certificat cert-manager.io/v1 metrics-ca et les ressources de l'émetteur metrics-pki.cluster.local de cert-manager dans 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 d'installer de nouveau 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 Clusters Anthos sur VMware. 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 les conflits. Notez que si vous êtes un client Apigee et que vous avez seulement besoin de cert-manager pour Apigee, vous n'avez pas besoin d'exécuter de commandes de 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
- Faites passer les 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 votre cert-manager est installé dans l'espace de noms
cert-manager.
Sinon, copiez le certificat cert-manager.io/v1 metrics-ca et les ressources de l'émetteur metrics-pki.cluster.local de cert-manager dans 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
|
| Système d'exploitation |
1.10, 1.11, 1.12 et 1.13 |
Faux positifs lors de l'analyse des failles docker, containerd et runc
Les images Docker, containerd et runc dans les images d'OS Ubuntu fournies avec Clusters Anthos sur VMware sont épinglées sur des versions spéciales à l'aide du contrat d'intérêt public Ubuntu. Ainsi, toutes les modifications apportées à l'environnement d'exécution du conteneur seront qualifiées par les clusters Anthos sur VMware avant chaque version.
Cependant, les versions spéciales sont inconnues de l'outil de suivi CVE Ubuntu, qui est utilisé comme flux de failles par divers outils d'analyse CVE. Par conséquent, vous verrez des résultats positifs dans Docker, containerd et runc.
Par exemple, les faux positifs suivants peuvent apparaître dans les résultats de l'analyse CVE. Ces failles CVE sont déjà corrigées dans les dernières versions de correctif des clusters Anthos sur VMware.
Consultez les notes de version] pour connaître 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 et mises à jour |
1.10, 1.11, 1.12 et 1.13 |
Il est possible que la connexion réseau entre le cluster d'administrateur et le cluster d'utilisateur soit temporairement indisponible pendant la mise à niveau du cluster non haute disponibilité.
Si vous mettez à niveau des clusters non haute disponibilité vers la version 1.9 vers la version 1.10, vous remarquerez peut-être que kubectl exec, kubectl log et le webhook ne seront peut-être pas disponibles pendant une courte période. Ce temps d'arrêt peut prendre jusqu'à une minute. Cela est dû au fait que la requête entrante (kubectl exec, kubectl log and webhook) est gérée par le kube-apiserver pour le cluster d'utilisateur. Le kube-apiserver de l'utilisateur est un
objet StatefulSet. Dans un cluster non haute disponibilité, il n'y a qu'une seule instance dupliquée pour le StatefulSet. Lors de la mise à niveau, il est donc possible que l'ancien kube-apiserver ne soit pas disponible et que le nouveau kube-apiserver ne soit pas encore prêt.
Solution :
Ce temps d'arrêt ne se produit que pendant le processus de mise à niveau. Si vous souhaitez bénéficier d'un temps d'arrêt plus court lors de la mise à niveau, nous vous recommandons de passer aux clusters à haute disponibilité.
|
| Installation, mises à niveau et mises à jour |
1.10, 1.11, 1.12 et 1.13 |
Échec du contrôle de préparation Konnectivity lors du diagnostic du cluster à haute disponibilité après sa création ou sa mise à niveau
Si vous créez ou mettez à niveau un cluster à haute disponibilité et que vous remarquez que la vérification de préparation de la connectivité échoue dans le diagnostic du cluster, cela n'affectera généralement pas le fonctionnement des clusters Anthos sur VMware (kubectl exec, kubectl log and webhook). Cela se produit parfois parce qu'une ou deux des instances dupliquées de la règle de connaissance peuvent être indisponibles 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 réexécutez 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 des clusters Anthos sur VMware, les images d'OS Ubuntu sont renforcées avec le benchmark de serveur CIS L1.
Par conséquent, le script Cron /etc/cron.daily/aide a été installé de sorte qu'une vérification aide soit planifiée, afin de s'assurer que la règle de serveur CIS L1 "1.4.2 assure la vérification régulière de l'intégrité du système de fichiers".
La job Cron'exécute tous les jours à 6h25 UTC. En fonction du nombre de fichiers sur le système de fichiers, vous risquez de constater des pics d'utilisation du processeur et de la mémoire à cette période à cause de ce processus aide.
Solution :
Si les pics affectent votre charge de travail, vous pouvez désactiver la job Cron quotidienne:
sudo chmod -x /etc/cron.daily/aide
|
| Mise en réseau |
1.10, 1.11, 1.12 et 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 clusters Anthos sur VMware version 1.9 ou ultérieure, lorsque le déploiement dispose de 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 échouer à créer un ConfigMap gke-metrics-agent-conf et entraîner une interruption des pods gke-connect-agent.
Le problème sous-jacent est que les règles de pare-feu distribuées avec état NSX-T arrêtent la connexion d'un client au serveur d'API du cluster d'utilisateur via l'équilibreur de charge Seesaw, car celui-ci utilise des flux de connexion asymétriques. Les problèmes d'intégration liés aux règles de pare-feu distribués NSX-T affectent tous les Clusters Anthos sur VMware qui utilisent Seesaw. Des problèmes de connexion similaires peuvent survenir sur vos propres applications lorsqu'elles créent des objets Kubernetes volumineux dont la taille est supérieure à 32 Ko.
Solution :
Suivez
ces instructions pour désactiver les règles de pare-feu distribué 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 backend. Sans cette configuration, les clients du serveur d'API Kubernetes peuvent cesser de répondre pendant plusieurs minutes en cas de panne d'une instance de serveur.
|
| Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15 |
Surveillance inattendue de la facturation
Pour les clusters Anthos sur VMware versions 1.10 et récentes, certains clients ont constaté une facturation élevée inattendue pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que lorsque toutes les circonstances suivantes s'appliquent:
- La surveillance des applications est activée (
enableStackdriverForApplications=true)
- Managed Service pour Prometheus n'est pas activé (
enableGMPForApplications)
- Les pods d'application comportent l'annotation
prometheus.io/scrap=true. (L'installation d'Anthos Service Mesh peut également ajouter cette annotation.)
Pour savoir si vous êtes concerné par ce problème, répertoriez-les. Si la facturation de métriques indésirables s'affiche, 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 et de passer à la nouvelle solution de surveillance des applications managed-service-for-prometheus.
Indicateurs distincts pour contrôler la collecte des journaux d'application par rapport aux métriques d'application
Service Google Cloud Managed Service pour Prometheus inclus
Si vous ne pouvez pas passer à la version 1.12, procédez comme suit:
- Recherchez les pods et services sources qui ont le facturé indésirable
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 Anthos Service Mesh, vous pouvez configurer Anthos Service Mesh sans l'option Prometheus ou désactiver la fonctionnalité de fusion des métriques d'Istio.
|
| Installation |
1,11, 1,12, 1,13 |
Le programme d'installation échoue lors de la création du disque de données vSphere
Le programme d'installation des clusters Anthos sur VMware peut échouer si les rôles personnalisés sont associés au niveau d'autorisation incorrect.
Lorsque la liaison de rôle est incorrecte, la création d'un disque de données vSphere se bloque avec govc et la taille du disque est é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 centre de données (ou inférieur à la racine), vous devez également lier le rôle en lecture seule à l'utilisateur au niveau de vCenter racine.
Pour en savoir plus sur la création de rôles, consultez la page
Droits d'utilisateur de compte 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 constaterez peut-être un trafic réseau élevé vers monitoring.googleapis.com, même dans un nouveau cluster sans 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 la procédure de contournement
Passez à 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 :
- Effectuez un scaling à la baisse 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 du 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 et 1,11 |
gke-metrics-agent présente des erreurs CrashLoopBackOff récurrentes
Pour les Clusters Anthos sur VMware version 1.10 et ultérieures, le DaemonSet "gke-metrics-agent" présente fréquemment des erreurs "CrashLoopBackOff" lorsque "enableStackdriverForApplications" est défini sur "true" dans l'objet "stackdriver".
Solution :
Pour atténuer 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 éviter que les modifications suivantes ne soient annulées, 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 toute 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 OOTB, des graphiques vides s'affichent. Pour rechercher des métriques obsolètes dans les tableaux de bord Monitoring, 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 valeurs de remplacement.
| 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 :
Remplacer les métriques obsolètes
- Supprimez l'état du nœud GKE On-Prem dans le tableau de bord Google Cloud Monitoring. Réinstallez l'état du nœud GKE On-Prem en suivant
ces instructions.
- Supprimez "Utilisation des nœuds GKE On-Prem" dans le tableau de bord Google Cloud Monitoring. Réinstallez l'option "Utilisation des nœuds GKE On-Prem" en suivant
ces instructions.
- Supprimez "GKE On-Prem vSphere vm Health" dans le tableau de bord Google Cloud Monitoring. Réinstallez "GKE On-Prem vSphere vm health" en suivant
ces instructions.
Cet abandon est dû à la mise à niveau de l'agent
kube-state-metrics de la version 1.9 vers la version 2.4, qui est nécessaire pour Kubernetes 1.22. Vous pouvez remplacer toutes les métriques kube-state-metrics obsolètes, avec 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 et 1.13 |
Données de métriques inconnues dans Cloud Monitoring
Pour les clusters Anthos sur VMware version 1.10 ou ultérieure, les données des clusters 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 peuvent présenter des métriques récapitulatives non pertinentes : :
apiserver_admission_step_admission_duration_seconds_summarygo_gc_duration_secondsscheduler_scheduling_duration_secondsgkeconnect_http_request_duration_seconds_summaryalertmanager_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 et 1.13 |
Métriques manquantes sur certains nœuds
Vous constaterez peut-être qu'il manque les métriques suivantes sur certains nœuds, mais pas sur tous:
kubernetes.io/anthos/container_memory_working_set_byteskubernetes.io/anthos/container_cpu_usage_seconds_totalkubernetes.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 de
gke-metrics-agent de 10m à 50m, la limite de processeur de 100m à 200m ajoute 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 ressembler à ce qui 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 planification et de contrôleur-gestionnaire manquantes dans le cluster d'administrateur
Si votre cluster d'administrateur est concerné par ce problème, il manque les métriques du programmeur et du contrôleur-gestionnaire. 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, ou à la version 1.12.1 ou ultérieure.
|
|
1.11.0 à 1.11.2, 1.12.0 |
Métriques de planification et de contrôleur-gestionnaire manquantes dans le cluster d'utilisateur
Si votre cluster d'utilisateur est affecté par ce problème, il manque les métriques du programmeur et du contrôleur-gestionnaire. Par exemple, ces deux métriques 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 les versions 1.13.0 et ultérieures des clusters Anthos sur VMware.
Mettez à niveau votre cluster vers une version contenant le correctif.
|
| Installation, mises à niveau et mises à jour |
1.10, 1.11, 1.12 et 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 avec la spécification gkeConnect fournie lors de sa création, l'erreur suivante s'affiche.
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 continuer à utiliser ce cluster d'administrateur, mais vous obtiendrez l'erreur suivante si vous tentez ultérieurement de mettre à niveau le cluster d'administrateur vers la version 1.10.y.
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 la procédure 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 résolu, vous pourrez mettre à niveau votre cluster d'administrateur.
- Exécutez
gkectl update admin pour enregistrer le cluster d'administrateur avec la bonne clé de compte de service.
- 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
- Réessayez de mettre à niveau le cluster d'administrateur avec l'indicateur
--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 au fichier de configuration de votre cluster d'administrateur.
|
| Identité |
1.10, 1.11, 1.12 et 1.13 |
L'utilisation d'Anthos Identity Service peut entraîner le redémarrage imprévisible de l'agent Connect
Si vous utilisez la fonctionnalité Anthos Identity Service pour gérer
Anthos Identity Service ClientConfig, l'
agent Connect peut redémarrer de manière inattendue.
Solution :
Si vous rencontrez ce problème avec un cluster existant, vous pouvez effectuer l'une des opérations suivantes:
- Désactivez Anthos Identity Service (AIS). La désactivation d'AIS n'entraîne pas la suppression du binaire AIS déployé ni la suppression du ClientConfig AIS. Pour désactiver AIS, exécutez la commande suivante:
gcloud beta container hub identity-service disable \
--project PROJECT_NAME
Remplacez PROJECT_NAME par le nom du
projet hôte du parc.
- Mettez à jour le cluster vers la version 1.9.3 ou une version ultérieure, ou la version 1.10.1 ou une version ultérieure, afin de mettre à niveau la version de l'agent Connect.
|
| Mise en réseau |
1.10, 1.11, 1.12 et 1.13 |
Cisco ACI ne fonctionne pas avec Direct Server Return (DSR)
Seesaw s'exécute en mode DSR. Par défaut, elle 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.
Vous pouvez configurer l'option d'adresse IP virtuelle L4-L7 en accédant à Locataires > Profils d'application > EPG d'application ou EPG uSeg. Si le ML n'est pas désactivé, le point de terminaison de l'adresse IP basculera entre les différents emplacements de la structure Cisco API.
|
| VMware |
1.10, 1.11, 1.12 et 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 Update 3:
- vSphere ESXi 7.0 Update 3 (build 18644231)
- vSphere ESXi 7.0 Update 3a (build 18825058)
- vSphere ESXi 7.0 Update 3b (build 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 vCenter vers une version plus récente.
|
| Système d'exploitation |
1.10, 1.11, 1.12 et 1.13 |
Échec de l'installation du volume emptyDir en tant que exec dans le pod s'exécutant 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 installer le volume emptyDir en tant que exec. Il s'installe 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
Et dans le pod de test, si vous exécutez mount | grep test-volume, l'option noexec s'affiche:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Solution :
Afficher la procédure 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 et mises à jour |
1.10, 1.11, 1.12 et 1.13 |
La mise à jour 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 que l'autoscaling a été 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 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, les tableaux de bord de surveillance prêts à l'emploi incluent le tableau de bord d'état des pods Windows et des nœuds Windows. En effet, les métriques de nœud Windows et de pod sont également exposées sur les clusters Linux.
|
| Journalisation et surveillance |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder dans CrashLoopBackOff en continu
Pour les clusters Anthos sur VMware versions 1.10, 1.11 et 1.12, stackdriver-log-forwarderLe DaemonSet peut rencontrer des erreurs CrashLoopBackOff en cas de défaillance des journaux mis en mémoire tampon sur le disque.
Solution :
Pour résoudre ce problème, nous devons nettoyer les journaux mis en mémoire tampon sur le nœud.
- Pour éviter ce comportement inattendu, réduisez la taille
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 fragments endommagé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 fragments, vous pouvez exécuter les commandes suivantes. Le résultat des deux commandes doit être égal à votre numéro de nœud dans le 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
- Reprenez la
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 et 1.15 |
stackdriver-log-forwarder n'envoie pas de journaux à Cloud Logging
Si vous ne voyez pas de journaux dans vos clusters 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
Le taux d'entrée des journaux dépasse probablement la limite de l'agent Logging, ce qui empêche stackdriver-log-forwarder d'envoyer les journaux.
Ce problème se produit dans toutes les versions d'Clusters Anthos sur VMware.
Solution :
Pour résoudre ce problème, vous devez augmenter la limite de ressources sur l'agent Logging.
- Ouvrez votre ressource
stackdriver pour la modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Pour augmenter la requête 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 ressembler à ce qui 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 le certificat du serveur kubelet n'est pas prêt. kubectl exec et kubectl logs sont indisponibles pendant ces dizaines de secondes.
En effet, un nouvel outil d'approbation de certificats de serveur peut mettre du temps à afficher les adresses IP valides mises à jour du nœud.
Ce problème n'affecte que le certificat du serveur kubelet et n'a aucune incidence sur la planification des pods.
|
| Mises à niveau et 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:
.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.
La mise à niveau du cluster d'administrateur n'est pas terminée et la version d'état est toujours 1.10. La mise à niveau du cluster d'utilisateur vers la version 1.12 ne sera bloquée par aucune vérification préliminaire, et échouera en raison d'un problème de décalage de version.
Solution :
Terminez la mise à niveau du cluster d'administrateur vers la version 1.11, puis mettez à niveau 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 à tort un espace 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 libre du datastore ne doit pas être utilisée pour les pools de nœuds de cluster existants. Elle a été ajoutée par erreur à 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 |
Vous ne pourrez peut-être pas ajouter de cluster d'utilisateur si celui-ci est configuré avec une configuration d'équilibreur de charge MetalLB.
Le processus de suppression du cluster d'utilisateur peut être bloqué pour une raison quelconque, ce qui entraîne l'invalidation du ConfigMap de MatalLB. Il ne sera pas possible d'ajouter un cluster d'utilisateur 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 et 1.13 |
Échec de l'utilisation de Container-Optimized OS (COS) pour le cluster d'utilisateur
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, il échoue:
Failed to create the test VMs: VM failed to get IP addresses on the network.
La VM de test créée pour le cluster d'utilisateur check-config utilise par défaut la même valeur osImageType du cluster d'administrateur. La VM de test n'est pas encore compatible avec COS pour le moment.
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 peut pas accéder aux clusters d'utilisateur
Ce problème concerne les clients qui utilisent Grafana dans le cluster d'administrateur pour surveiller les clusters d'utilisateur dans Clusters Anthos sur VMware versions 1.12.0 et 1.12.1. Elle provient d'une incohérence entre les certificats pushprox-client dans les clusters utilisateur et la liste d'autorisation du serveur pushprox dans le cluster d'administrateur.
Le symptôme se produit pushprox-client dans les journaux d'erreurs d'impression des clusters d'utilisateur:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Solution :
Afficher la procédure de contournement
procédez comme suit:
- Réduire la capacité du déploiement de l'opérateur de surveillance dans l'espace de noms kube-system du cluster d'administrateur.
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'utilisateur 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'utilisateur 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, une fois le problème résolu, effectuez un scaling à la hausse du kube-system monitoring-operator du cluster d'administrateur pour pouvoir gérer à nouveau 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 d'administrateur si le nom de la VM 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 et 1.15 |
Échec de Cloud Audit Logging en raison d'une autorisation refusée
Anthos Cloud Audit Logging requiert une configuration d'autorisation spéciale qui n'est actuellement effectuée automatiquement que pour les clusters d'utilisateur via GKE Hub.
Il est recommandé de disposer d'au moins un cluster d'utilisateur qui utilise le même ID de projet et le même compte de service avec le cluster d'administrateur pour Cloud Audit Logging, afin que le cluster d'administrateur dispose de l'autorisation nécessaire pour Cloud Audit Logging.
Toutefois, dans les cas où le cluster d'administrateur utilise un ID de projet ou un compte de service différent avec un cluster d'utilisateur, les journaux d'audit du cluster d'administrateur ne parviennent pas à être injectés dans le cloud. Le symptôme est une série d'erreurs Permission Denied dans le pod audit-proxy du cluster d'administrateur.
Solution :
Afficher la procédure de contournement
Pour résoudre ce problème, vous pouvez configurer l'autorisation en interagissant avec la fonctionnalité cloudauditlogging Hub:
- Commencez par vérifier les comptes de service existants ajoutés à la liste d'autorisation pour Anthos Cloud Audit Logging pour votre projet:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- En fonction de 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 ne figure sur la liste d'autorisation pour cet ID de projet. Vous pouvez ajouter un compte de service à la liste d'autorisation en activant la fonctionnalité cloudauditlogging Hub:
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 caractéristiques 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 soit utiliser un compte de service de cette liste dans votre cluster, soit ajouter un 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 caractéristiques contenant
"lifecycleState": "ENABLED" avec "code":
"FAILED", cela signifie que la configuration des autorisations 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 d'audit cloud, puis réactivez-la après l'étape 1 de cette section. Vous pouvez supprimer la fonctionnalité cloudauditlogging Hub 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 |
gkectl diagnose vérifie l'échec des certificats
Si votre station de travail n'a pas accès aux nœuds de calcul du cluster d'utilisateur, les échecs suivants se produiront 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 station de travail n'a pas accès aux nœuds de calcul du cluster d'administrateur ou aux nœuds de calcul du cluster d'administrateur, les échecs suivants se produiront 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 et 1.13 |
/var/log/audit/ remplit l'espace disque des VM
/var/log/audit/ contient de nombreux 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 Anthos v1.8, l'image Ubuntu est renforcée avec le benchmark CIS de niveau 2. Et l'une des règles de conformité, "4.1.2.2 Assurez-vous que les journaux d'audit ne sont pas supprimés automatiquement", garantit le paramètre audité max_log_file_action = keep_logs. Toutes les règles d'audit sont ainsi conservées sur le disque.
Solution :
Afficher la procédure de contournement
Poste de travail administrateur
Pour le poste de travail administrateur, vous pouvez modifier manuellement les paramètres d'audit pour alterner automatiquement les journaux, puis redémarrer le service audité:
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
Avec le paramètre ci-dessus, l'audit effectuerait la rotation automatique de ses journaux dès qu'ils auraient généré plus de 250 fichiers (chacun d'une taille de 8 millions).
Nœuds de cluster
Pour les nœuds de cluster, passez à la version 1.11.5+, 1.12.4+, 1.13.2+ ou 1.14+. Si vous ne pouvez pas encore effectuer la mise à niveau vers 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 la configuration auditée enfreint la règle CIS de niveau 2 "4.1.2.2. Assurez-vous que les journaux d'audit ne sont pas automatiquement supprimés".
|
| Mise en réseau |
1.10, 1.11.0 à 1.11.3, 1.12.0 à 1.12.2, 1.13.0 |
NetworkGatewayGroup Conflit d'adresses IP flottantes avec l'adresse du nœud
Les utilisateurs ne peuvent pas créer ou mettre à jour des objets NetworkGatewayGroup en raison de l'erreur de validation de 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 affectées, le kubelet peut être associé par erreur à une adresse IP flottante attribuée au nœud et le signaler en tant qu'adresse de nœud dans node.status.addresses. Le webhook de validation vérifie les adresses IP flottantes NetworkGatewayGroup pour toutes les ressources node.status.addresses du cluster et les considère comme un conflit.
Solution :
Dans le cluster dans lequel 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 de pouvoir la restaurer à 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 et fermez l'élément pour appliquer les modifications.
- Créez ou modifiez votre objet
NetworkGatewayGroup.
- Réappliquez la configuration du webhook d'origine:
kubectl -n kube-system apply -f webhook-config.yaml
|
| Installation, mises à niveau et mises à jour |
1.10.0 à 1.10.2 |
Création ou mise à niveau du délai avant expiration du cluster d'administrateur
Lors d'une tentative de mise à niveau du cluster d'administrateur, la VM du plan de contrôle d'administrateur peut être bloquée lors de la création. La VM du plan de contrôle d'administrateur entre en boucle d'attente infinie lors du démarrage. 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 Clusters Anthos sur VMware 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 d'interface réseau. Cependant, la commande ignore également les adresses IP ayant le préfixe de 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 du plan de contrôle du cluster d'administrateur comporte le même préfixe, par exemple 192.168.1.254, la VM du plan de contrôle est bloquée lors de la création. Ce problème peut également être déclenché si l'adresse de diffusion possède 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 d'expiration de la création du cluster d'administrateur est dû à l'adresse IP de diffusion, exécutez la commande suivante sur la VM du plan de contrôle du cluster d'administrateur:
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
Cette opération 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é, exécutez la commande suivante pour supprimer cette ligne:
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
- Toutefois, si le délai d'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 ou mettez à niveau vers la version 1.10.3 ou une version ultérieure.
|
| Système d'exploitation, mises à niveau et 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 du maître d'administrateur
Impossible d'installer correctement DataDisk 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 est perdu lors de la mise à niveau du cluster d'administrateur ou de la réparation du maître d'administrateur. (le cluster d'administrateur utilisant l'image COS est une fonctionnalité bêta)
Solution :
Recréer le cluster d'administrateur avec osImageType défini sur ubuntu_containerd
Après avoir créé le cluster d'administrateur avec osImageType défini sur cos, récupérez la clé SSH du cluster d'administrateur et SSH dans le nœud maître administrateur.
df -h résultat 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 Clusters Anthos sur VMware version 1.10.0, les résolutions de noms sur Ubuntu sont acheminées par défaut vers 127.0.0.53 en local une fois l'écoute résolue par le système. En effet, sur l'image Ubuntu 20.04 utilisé dans la version 1.10.0, /etc/resolv.conf est lié à /run/systemd/resolve/stub-resolv.conf, ce qui pointe vers le bouchon DNS localhost 127.0.0.53.
Par conséquent, la résolution de noms DNS localhost refuse de rechercher les serveurs DNS en amont (spécifié dans /run/systemd/resolve/resolv.conf) pour les noms avec un suffixe .local, sauf si les noms sont spécifiés en tant que domaines de recherche.
Cela entraîne l'échec des recherches de noms .local. Par exemple, au démarrage du nœud, kubelet ne parvient pas à extraire d'images de registre privé avec le suffixe .local. La spécification d'une adresse vCenter avec le suffixe .local ne fonctionne pas sur un poste de travail administrateur.
Solution :
Vous pouvez éviter ce problème pour les nœuds de cluster en spécifiant le champ searchDomainsForDNS dans votre fichier de configuration de cluster d'administrateur et le fichier de configuration du cluster d'utilisateur de façon à inclure les domaines.
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 le bouchon résolu par le système local en remplaçant le symlink /etc/resolv.conf de /run/systemd/resolve/stub-resolv.conf (qui contient le bouchon local 127.0.0.53) par /run/systemd/resolve/resolv.conf (qui pointe vers le DNS en amont):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
En ce qui concerne le poste de travail administrateur, gkeadm ne permet pas de spécifier des domaines de recherche. Vous devez donc contourner cette erreur manuellement.
Cette solution n'est pas conservée pour les recréations de VM. Vous devez appliquer de nouveau cette solution chaque fois que des VM sont recréées.
|
| 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
Clusters Anthos sur VMware spécifie un sous-réseau dédié à l'adresse IP du pont 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 a été bugisée et a ignoré la configuration Docker personnalisée.
Par conséquent, Docker choisit le sous-réseau 172.17.0.1/16 par défaut comme sous-réseau d'adresses IP de pont. Cela peut entraîner un conflit d'adresses IP si une charge de travail est déjà 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 n'est pas conservée pour les recréations de VM. Vous devez appliquer de nouveau cette solution chaque fois que des VM sont recréées.
|
| Mises à niveau et mises à jour |
1.11 |
Mise à niveau vers la version 1.11 bloquée par Stackdriver Ready
Dans la version 1.11.0 des clusters Anthos sur VMware, des modifications ont été apportées à la définition des ressources personnalisées concernant la journalisation et la surveillance:
- Le nom du 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 comparées à leur schéma. En particulier, les spécifications resourceAttrOverride et storageSizeOverride de la ressource personnalisée
stackdriver doivent avoir un type de chaîne dans les valeurs des requêtes et des limites de taille de processeur, de mémoire et de stockage.
Les modifications apportées au nom du groupe sont conformes aux mises à jour de CustomResourceDefinition dans Kubernetes 1.22.
Aucune action n'est requise si vous n'avez pas de logique supplémentaire qui applique ou modifie les ressources personnalisées concernées. Le processus de mise à niveau des clusters Anthos sur VMware se charge de la migration des ressources concernées et conserve 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 de groupe dans le fichier manifeste. Exemple :
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
Ensuite, assurez-vous que les valeurs des spécifications 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
Dans le cas contraire, les modifications appliquées ne seront pas appliquées et pourront entraîner un état inattendu dans les composants de journalisation et de surveillance. Les symptômes potentiels peuvent être les suivants:
- Les journaux d'erreurs 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. 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 conforme aux spécifications de la RS Stackdriver était déjà présent avant la mise à niveau. Pour contourner ce problème, vous pouvez modifier manuellement la RS Stackdriver sous l'ancien nom de groupe kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver et procéder comme suit:
- Modifier le type de chaîne pour les demandes et limites de ressources
- Supprimez toutes les annotations
addons.gke.io/migrated-and-deprecated: true, le cas échéant.
Reprenez ensuite ou recommencez le processus de mise à niveau.
|
| Système d'exploitation |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14 et 1.15 |
Les VM COS n'affichent aucune adresse IP lorsque les VM sont déplacées via un arrêt non progressif de l'hôte
En cas de défaillance d'un serveur ESXi et lorsque la fonction haute disponibilité vCenter 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 perdent leur adresse IP.
Solution :
Redémarrer la VM
|
| Mise en réseau |
toutes les versions antérieures à 1.14.7, 1.15.0-1.15.3, 1.16.0 |
La réponse GARP envoyée par Seesaw ne définit pas l'adresse IP cible
Le GARP périodique (ARP gratuit) 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 ces paquets (comme Cisco ACI). Le service peut être plus long après la récupération d'un cerveau fractionné (en raison de la perte de paquets VRRP).
Solution :
Déclenchez un basculement Seeaw en exécutant sudo seesaw -c failover sur l'une des VM Seesaw. Cela devrait restaurer le trafic.
|
