Operation |
1,8, 1,9, 1,10 |
Problème d'augmentation de l'utilisation de la mémoire des 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égel, et les anciennes connexions ne sont pas nettoyées.
Solution :
Option 1: Passez à la version 1.8 à la version 1.11 contenant le correctif.
Option 2: Si vous utilisez une version de correctif antérieure à 1.9.6 et 1.10.3, vous devez réduire la capacité du pod de maintenance etcd pour l'administrateur et le cluster d'utilisateur:
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Operation |
1,9, 1,10, 1,11, 1,12, 1,13 |
Ne pas vérifier les vérifications d'état 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 tous deux un ensemble de vérifications de l'état, y compris les vérifications de l'état des pods sur les espaces de noms. Cependant, ils commencent à ignorer les pods du plan de contrôle utilisateur par erreur. Si vous utilisez le mode plan de contrôle v2, cela n'affectera 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+, 1.7+ |
Les mises à niveau des clusters 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 mars 2023. Dans les 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 fait que le fichier du groupe Seesaw existe déjà. 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 de délai d'application dues à des échecs d'insertion de table conntrack
Les clusters Anthos sur VMware version 1.14 sont susceptibles de faire l'objet d'échecs d'insertion de table connfilter (conntrack) 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 si la table conntrack a de la place pour de nouvelles entrées. Les échecs sont dus à des modifications apportées aux versions 5.15 et ultérieures du noyau, qui limitent les insertions de tables 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 in-kernel 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 par défaut de la taille de la table est 262144 . Nous vous recommandons 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 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 pour les nœuds Windows et entrer en boucle.
En effet, les deux déploiements tolèrent tous les rejets, y compris le rejet de nœud Windows.
Solution :
Effectuez une mise à niveau vers 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 l'identifiant fileRef .
La requête préliminaire peut échouer avec le message suivant:
[FAILURE] Docker registry access: Failed to login.
Solution :
|
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 inspecter les paquets, car le pod est contourné et n'utilise jamais d'IPTables.
En mode sans kube-proxy, cela se manifeste par une perte de connectivité ou 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 des clusters Anthos sur solution Bare Metal 1.10, mais certaines versions plus récentes de la version 1.10 (1.10.2 et ultérieures) offrent une solution de contournement.
Solution :
Pour une compatibilité totale, passez à la version 1.11. 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 fichier ConfigMap, puis redémarrez le daemonset Anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
|
Stockage |
1.12+, 1.13.3 |
kube-controller-manager peut dissocier de manière forcée les volumes persistants au bout de six minutes
kube-controller-manager peut expirer lors de la dissociation de PV/PVC au bout de six minutes, et dissocier de manière forcée les PV/PVC. Les journaux détaillés de kube-controller-manager affichent des événements semblables à ceux-ci:
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
Pour vérifier le problème, connectez-vous au nœud et exécutez les commandes suivantes:
# See all the mounting points with disks
lsblk -f
# See some ext4 errors
sudo dmesg -T
Dans le journal du kubelet, des erreurs de ce type s'affichent:
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
Solution :
Connectez-vous en SSH au nœud concerné et redémarrez-le.
|
Mises à niveau et mises à jour |
1.12+, 1.13+, 1.14+ |
La mise à niveau du cluster est bloquée si un pilote CSI tiers est utilisé
Vous ne pourrez peut-être pas mettre à niveau un cluster si vous utilisez un pilote CSI tiers. La commande gkectl cluster diagnose peut renvoyer l'erreur suivante:
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
Solution :
Effectuez la mise à niveau à l'aide de l'option --skip-validation-all .
|
Operation |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+ |
gkectl repair admin-master crée la VM maîtresse 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, l'erreur s'affiche dans le rapport gkectl diagnose cluster .
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.
Solution :
Arrêtez le nœud maître administrateur, suivez https://kb.vmware.com/s/article/1003746 pour mettre à niveau le nœud vers la version attendue décrite dans le message d'erreur, puis démarrez le nœud.
|
Système d'exploitation |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+ |
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'adresse IP
Dans systemd 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 ce changement, les VM envoient un tel message et renvoient les adresses IP au serveur DHCP. Par conséquent, l'adresse IP libérée peut être réaffectée à une autre VM et/ou une autre adresse IP peut être attribuée à la VM. Cela entraîne un conflit d'adresses IP (au niveau de Kubernetes, et non au niveau de vSphere) et/ou une modification de l'adresse 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'interface utilisateur de vCenter montre qu'aucune VM n'utilise la même adresse IP, mais
kubectl get
nodes -o wide renvoie des nœuds avec des adresses IP en double.
NAME STATUS AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node1 Ready 28h v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
node2 NotReady 71d v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
- Échec du démarrage des nouveaux nœuds en raison d'une erreur
calico-node
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
Solution :
Déployez le DaemonSet suivant sur le cluster pour annuler le changement de comportement par défaut de systemd-networkd . Les VM qui exécutent ce DaemonSet ne libèrent pas les adresses IP du serveur DHCP lors de l'arrêt ou du redémarrage. Les adresses IP seront libérées automatiquement par le serveur DHCP lorsque les baux expireront.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-dhcp-on-stop
spec:
selector:
matchLabels:
name: set-dhcp-on-stop
template:
metadata:
labels:
name: set-dhcp-on-stop
spec:
hostIPC: true
hostPID: true
hostNetwork: true
containers:
- name: set-dhcp-on-stop
image: ubuntu
tty: true
command:
- /bin/bash
- -c
- |
set -x
date
while true; do
export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
if (( $? != 0 )) ; then
echo "Setting KeepConfiguration=dhcp-on-stop"
sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
cat "${CONFIG}"
chroot /host systemctl restart systemd-networkd
else
echo "KeepConfiguration=dhcp-on-stop has already been set"
fi;
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "5m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
tolerations:
- operator: Exists
effect: NoExecute
- operator: Exists
effect: NoSchedule
|
Opération, mises à niveau et mises à jour |
1.12.0+, 1.13.0+, 1.14.0+ |
Clé de compte de service de l'accès aux composants effacée après la mise à niveau du cluster d'administrateur depuis la version 1.11.x
Ce problème n'affectera que les clusters d'administrateur mis à niveau depuis la version 1.11.x. Il n'affectera pas les clusters d'administrateur nouvellement créés après la version 1.12.
Après avoir mis à niveau un cluster 1.11.x vers la version 1.12.x, le champ component-access-sa-key du secret admin-cluster-creds sera effacé.
Vous pouvez le vérifier en exécutant 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, cela signifie que la clé est effacée.
Une fois la clé de 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 échoue. Voici quelques messages d'erreur susceptibles de s'afficher:
- Échec lent de la validation préliminaire 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 d'ici le
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 -
|
Operation |
1.13.0+, 1.14.0+ |
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 pour lesquels l'autoscaling est activé utilisent toujours leur 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 ayant le correctif
|
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 et renvoie l'erreur suivante:
- Validation Category: Config Check
- [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
Solution :
Incluez des adresses IP individuelles dans le fichier "bloc d'adresses IP" jusqu'à ce que vous procédiez à une mise à niveau avec la correction suivante: 1.12.5, 1.13.4, 1.14.1+.
|
Mises à niveau et mises à jour |
1.14.0 à 1.14.1 |
La mise à jour du type d'image de l'OS dans admin-cluster.yaml n'attend pas que les machines du plan de contrôle d'utilisateur soient recréées
Lors de la mise à jour du type d'image de l'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 du 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 d'utilisateur terminent leur recréation en surveillant leur type d'image de nœud os à 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 une fois la commande de mise à jour terminée.
|
Operation |
1.14.0 |
Erreurs de création ou de suppression de pod en raison d'un problème de jeton d'authentification du compte de service CNI Calico
Un problème lié à Calico dans les 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 la sortie 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 pendant 24 heures. Ce jeton doit être régulièrement renouvelé par le pod calico-node . Le pod calico-node ne peut pas renouveler le jeton, car il n'a pas accès au répertoire contenant le fichier kubeconfig sur le nœud.
Solution :
Pour atténuer le problème, appliquez le correctif suivant sur le DaemonSet calico-node dans 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 à votre fichier de configuration de cluster d'utilisateur.
|
Installation |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
La validation du bloc d'adresses IP échoue lors de l'utilisation du CIDR
La création du cluster échoue, malgré la configuration de l'utilisateur. La création échoue, car le cluster ne dispose pas d'un nombre suffisant d'adresses IP.
Solution :
Diviser 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 qu'il existe N+1 CIDR, N étant 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 les clés de chiffrement et la configuration des secrets permanents
Lorsque la fonctionnalité de chiffrement des secrets permanents est activée avec la sauvegarde du cluster, la sauvegarde du cluster d'administrateur n'inclut pas les clés de chiffrement ni la configuration requise par la fonctionnalité de chiffrement des secrets permanents. Par conséquent, la réparation de l'instance maître administrateur à l'aide de 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 une 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 gkectl 1.10.5 pour effectuer une sauvegarde manuelle du cluster d'administrateur, comme décrit dans la section Sauvegarder et restaurer un cluster d'administrateur avec gkectl.
|
Opération, mises à niveau et mises à jour |
1.10+ |
Recréer la VM maîtresse avec un nouveau disque de démarrage (par exemple, gkectl repair admin-master ) échouera 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 permanents n'est pas activée lors de la création du cluster, mais activée ultérieurement via 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 permanents 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 dans d'autres clusters d'utilisateur.
En mettant à niveau le premier cluster d'utilisateur de la version 1.9 vers la version 1.10, vous pourriez recréer des nœuds dans d'autres clusters d'utilisateur du même cluster d'administrateur. La reconstitution se déroule progressivement.
Le disk_label a été supprimé de MachineTemplate.spec.template.spec.providerSpec.machineVariables , ce qui a déclenché une mise à jour inattendue de tous les MachineDeployment .
Solution :
Afficher la procédure de contournement
- Faites évoluer l'instance dupliquée de
clusterapi-controllers à 0 pour tous les clusters d'utilisateur.
kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Mettez à niveau chaque cluster d'utilisateur un par un.
|
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 indiquera si le docker redémarre fréquemment. Voici un exemple de résultat:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Pour comprendre la cause première, vous devez vous connecter en SSH au nœud qui présente le problè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, 1,12 |
Composants GMP autodéployés non conservés après la mise à niveau vers la version 1.12
Si vous utilisez un Clusters Anthos sur VMware en version antérieure à 1.12 et que vous avez configuré manuellement les composants Prometheus géré par Google (GMP) dans l'espace de noms gmp-system de votre cluster, les composants ne sont pas conservés lorsque vous passez à la version 1.12.x.
À partir de la version 1.12, les composants GMP de l'espace de noms gmp-system et les objets CRD sont gérés par l'objet stackdriver , l'option enableGMPForApplications étant définie sur false par défaut. Si vous déployez manuellement des composants GMP dans l'espace de noms avant la mise à niveau vers la version 1.12, les ressources seront supprimées par stackdriver .
Solution :
|
Operation |
1.11, 1.12, 1.13.0 – 1.13.1 |
Objets ClusterAPI manquants dans le scénario system de l'instantané de cluster
Dans le scénario system , l'instantané du cluster n'inclut aucune ressource sous l'espace de noms default .
Toutefois, certaines ressources Kubernetes, telles que les objets d'API Cluster, qui se trouvent sous cet espace de noms, contiennent des informations de débogage utiles. L'instantané du cluster doit les inclure.
Solution :
Vous pouvez exécuter manuellement les commandes suivantes pour collecter les informations de débogage.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
où :
USER_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'utilisateur.
|
Mises à niveau et mises à jour |
1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1 |
Suppression du cluster d'utilisateur bloquée sur le drainage de 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 "in-tree" dans le cluster d'administrateur et d'utilisateur.
Pour identifier le symptôme, exécutez la commande ci-dessous:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Voici un exemple de message d'erreur de la commande ci-dessus:
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols est le répertoire par défaut du pilote vSphere In-tree. Si aucun objet PVC/PV n'est créé, vous risquez de rencontrer un bug qui bloquera le drainage de nœud à la recherche de kubevols , car l'implémentation actuelle suppose que kubevols existe toujours.
Solution :
Créez le répertoire kubevols dans le datastore où le nœud est créé. Ce paramètre est défini dans le champ vCenter.datastore des fichiers user-cluster.yaml ou admin-cluster.yaml .
|
Configuration |
1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 |
Les clusters d'administrateur cluster-health-controller et vsphere-metrics-exporter ne fonctionnent plus 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 la réparation automatique et l'exportateur de métriques vSphere de ne pas fonctionner
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 un exemple 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 un exemple 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 est le suivant : la commande gkectl check-config échoue et le message d'erreur suivant s'affiche :
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 de l'OS.
|
Mises à niveau et mises à jour |
1,11, 1,12, 1,13 |
Échec de la mise à jour des groupes anti-affinité par gkectl update admin/cluster
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 est le suivant : la commande gkectl update échoue et le message d'erreur suivant s'affiche :
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 avec la mise à jour ayant échoué.
Pour la mise à jour du cluster d'administrateur, les nœuds maîtres et les nœuds des modules complémentaires administrateur doivent être recréés
Pour mettre à jour le cluster d'utilisateur, les nœuds de calcul doivent être recréés
Pour recréer des nœuds de calcul utilisateur
Option 1 Suivez la procédure Mettre à jour un pool de nœuds et modifiez le processeur ou la mémoire pour déclencher une recréation progressive des nœuds.
Option 2 Utiliser 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 la procédure de redimensionnement du plan de contrôle et modifiez le processeur ou la mémoire pour déclencher une recréation progressive des nœuds.
Option 2 Utiliser 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 modules complémentaires 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 |
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 cluster, lorsque ipMode.type est défini sur static et que le nom d'hôte configuré dans le fichier de blocs d'adresses IP contient un ou plusieurs points. 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 du nom d'hôte d'un fichier de bloc d'adresses IP, tous les caractères qui suivent le premier point seront ignorés. Par exemple, si vous spécifiez le nom d'hôte 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 de nœud est activée, l'approbateur RSE compare le nom du nœud au nom d'hôte indiqué dans les spécifications de la machine, puis ne parvient pas à rapprocher le nom. L'approbateur rejette la requête de signature de certificat, et le nœud ne parvient pas à démarrer.
Solution :
Cluster d'utilisateur
Pour désactiver la validation de l'ID de nœud, procédez comme suit:
- Ajoutez les champs suivants à 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 à votre fichier de configuration de 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 de 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
- Mettez à jour cette section comme indiqué ci-dessous:
--controllers=*,bootstrapsigner,tokencleaner
- Ouvrez le contrôleur de l'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 le groupe de certificats du registre privé
La création ou la mise à niveau du cluster d'administrateur est bloquée sur le journal suivant indéfiniment et finit par expirer:
Waiting for Machine gke-admin-master-xxxx to become ready...
Le journal du contrôleur de l'API Cluster dans l'
instantané de cluster externe comprend le journal suivant:
Invalid value 'XXXX' specified for property startup-data
Voici un exemple de chemin d'accès au 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 de mise à jour d'état simultané
Dans networkgatewaygroups.status.nodes , certains nœuds basculent entre NotHealthy et Up .
Les journaux du pod ang-daemon exécuté sur ce nœud indiquent 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é.
Sinon, l'activité du plan de données n'est pas affectée.
Les conflits sur l'objet networkgatewaygroup entraînent l'échec de certaines mises à jour d'état en raison d'une erreur dans le traitement des nouvelles tentatives. Si un trop grand nombre de mises à jour d'état échouent, ang-controller-manager considère le nœud comme au-delà de sa limite de temps de pulsation et le marque comme NotHealthy .
L'erreur dans le traitement des nouvelles tentatives a été corrigée dans les versions ultérieures.
Solution :
Passer à 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 de la mise à jour ou de la mise à niveau
Problème connu pouvant 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 affecte toute opération de mise à jour progressive pour les pools de nœuds.
Le symptôme est le suivant : la commande gkectl expire et le message d'erreur suivant s'affiche :
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 de pod clusterapi-controller , les erreurs se présentent comme suit:
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
-c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
| grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993 1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
L'erreur se répète plusieurs fois pour la même machine pour 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 dans 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é à la suppression du finaliseur en raison des mises à jour très fréquentes d'autres contrôleurs.
Cela peut entraîner l'expiration du délai de la commande gkectl , mais le contrôleur effectue un rapprochement continu du cluster afin que le processus de mise à niveau ou de mise à jour se termine.
Solution :
Nous avons préparé différentes options d'atténuation pour ce problème, qui dépendent de votre environnement et de vos exigences.
Si vous rencontrez ce problème et que la mise à niveau ou la mise à jour ne peuvent toujours pas s'effectuer au bout d'un certain temps, contactez notre équipe d'assistance pour limiter les risques.
|
Installation, mises à niveau et mises à jour |
1.10.2, 1.11, 1.12, 1.13 |
gkectl prépare l'échec de la vérification préliminaire de l'image de l'OS
Échec de la commande gkectl prepare :
- Validation Category: OS Images
- [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
Les vérifications préliminaires de gkectl prepare incluaient une validation incorrecte.
Solution :
Exécutez la même commande avec une option supplémentaire --skip-validation-os-images .
|
Installation |
1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 |
L'URL vCenter avec le préfixe https:// ou http:// peut entraîner l'échec du 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 une clé secrète, qui n'est pas compatible avec "/" ni ":".
Solution :
Supprimez le préfixe https:// ou http:// du champ vCenter.Address du cluster d'administrateur ou du fichier de configuration YAML du cluster d'utilisateur.
|
Installation, mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13 |
Panique : gkectl prepare sur util.CheckFileExists
gkectl prepare peut paniquer à l'aide de la trace Stackdriver 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 certificat de registre privé avec une autorisation incorrecte.
Solution :
Pour résoudre ce problème, exécutez les commandes suivantes sur le poste de travail administrateur:
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
|
Mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13 |
gkectl repair admin-master et la mise à niveau administrateur avec reprise ne fonctionnent pas ensemble
Après une tentative de mise à niveau du cluster d'administrateur ayant échoué, n'exécutez pas gkectl
repair admin-master . Cela pourrait entraîner l'échec des tentatives de mise à niveau administrateur suivantes en raison de problèmes tels que l'échec de l'alimentation du maître administrateur ou l'inaccessibilité de la VM.
Solution :
Si vous avez déjà rencontré ce problème, contactez l'assistance.
|
Mises à niveau et mises à jour |
1,10, 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 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 administrateur est supprimé. Le modèle de VM du plan de contrôle d'administrateur est le modèle du maître d'administration utilisé pour 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 administrateur sera régénéré lors de la prochaine mise à niveau du cluster d'administrateur.
|
Système d'exploitation |
1,12, 1,13 |
cgroup v2 pourrait affecter les charges de travail
Dans la version 1.12.0, cgroup v2 (unified) est activé par défaut pour les nœuds Container-Optimized OS (COS). Cela peut entraîner une instabilité pour 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, 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, 1.13 |
Échec de la validation de gkectl check-config : partitions F5 BIG-IP introuvables
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 d'un problème d'élection du responsable de cert-manager/ca-injector
Vous pouvez constater un échec de l'installation en raison de cert-manager-cainjector dans la boucle de plantage, 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 de ne pas 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 il n'y a 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 de code YAML pertinent pour le déploiement cert-manager-cainjector doit ressembler à l'exemple suivant:
...
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
...
Pour réduire les risques liés à l'installation, conservez monitoring-operator instances dupliquées à 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 monitoring-operator pour les opérations à J+2:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Après chaque mise à niveau, les modifications sont annulées. Répétez ces étapes pour atténuer le problème jusqu'à ce que ce problème soit résolu dans une prochaine version.
|
Sécurité, mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13 |
Le renouvellement des certificats peut être requis avant la mise à niveau d'un cluster d'administrateur
Avant de commencer le processus de mise à niveau du cluster d'administrateur, vous devez vous assurer que les certificats de votre cluster d'administrateur sont valides et les renouveler s'ils ne le sont pas.
Si vous avez commencé le processus de mise à niveau et découvert une erreur concernant l'expiration du certificat, contactez l'assistance Google pour obtenir de l'aide.
Remarque: Ces conseils concernent uniquement le 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 absolu du 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 sont arrivés à expiration, vous devez les renouveler avant de mettre à niveau le cluster d'administrateur.
- Comme 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éé.
- Sauvegarder les anciens certificats Il s'agit d'une étape 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, ainsi que 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, 1.13 |
Redémarrer ou mettre à niveau vCenter pour les versions antérieures à la version 7.0U2
Si vCenter est redémarré, pour les versions antérieures à 7.0U2, après une mise à niveau ou autre, le nom du réseau figurant dans les informations de VM de vCenter est incorrect et la machine présente l'état Unavailable . Cela entraîne la réparation automatique des nœuds pour en créer de nouveaux.
Bug BugGovmomi associé.
Solution :
Cette solution est fournie par l'assistance VMware :
- Ce problème a été résolu dans les versions 7.0U2 et ultérieures de vCenter.
- Pour les versions antérieures, faites un clic droit sur l'hôte, puis sélectionnez Connexion > Déconnecter. Ensuite, reconnectez-vous pour forcer la mise à jour du groupe de ports de la VM.
|
Système d'exploitation |
1.10, 1.11, 1.12, 1.13 |
Connexion SSH fermée par l'hôte distant
Pour les clusters Anthos sur VMware version 1.7.2 ou ultérieure, les images d'OS Ubuntu sont renforcées avec le
CIS L1 Server Benchmark.
Pour répondre à la règle CIS "5.2.16 Assurez-vous que l'intervalle d'expiration de délai d'inactivité SSH est configuré", /etc/ssh/sshd_config a les paramètres suivants:
ClientAliveInterval 300
ClientAliveCountMax 0
Ces paramètres visent à mettre fin à une session client après cinq minutes d'inactivité. Cependant, la valeur ClientAliveCountMax 0 entraîne un comportement inattendu. Lorsque vous utilisez la session SSH sur le poste de travail administrateur ou un nœud de cluster, la connexion SSH peut être déconnectée, même si votre client ssh n'est pas inactif, par exemple lors de l'exécution d'une commande fastidieuse 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 pouvez utiliser l'une de ces deux méthodes :
Assurez-vous de reconnecter votre session SSH.
|
Installation |
1.10, 1.11, 1.12, 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, suivez les instructions ci-dessous pour éviter les conflits:
Il vous suffit d'appliquer ce travail une fois pour chaque cluster, et les modifications seront conservées lors de la mise à niveau du cluster.
Remarque: L'un des symptômes courants affectant l'installation de votre propre cert-manager est que la version ou l'image cert-manager (par exemple, v1.7.2) peut revenir à son ancienne version. En effet, monitoring-operator tente de rapprocher cert-manager , puis rétablit la version.
Solution :
Éviter les conflits lors du passage à une édition supérieure
- 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
- Scaling du déploiement
monitoring-operator sur 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Faites évoluer les déploiements
cert-manager gérés par monitoring-operator à zéro:
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 .
Le cas échéant, restaurez vos ressources personnalisées.
- Vous pouvez ignorer cette étape si vous utilisez l'
installation en amont du cert-manager ou si vous êtes certain 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 à partir de cert-manager dans l'espace de noms des ressources de cluster du gestionnaire de certificats 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, il n'est pas nécessaire de réinstaller cert-manager dans les clusters d'administrateur, car les clusters d'administrateur n'exécutent que les clusters Anthos sur le plan de contrôle VMware. Dans les rares cas où vous devrez également installer votre propre cert-manager dans des clusters d'administrateur, suivez les instructions suivantes pour éviter les conflits. Veuillez noter que si vous êtes un client Apigee et que vous n'avez besoin que de cert-manager pour Apigee, vous n'avez pas besoin d'exécuter les commandes du cluster d'administrateur.
- Effectuez le scaling du déploiement
monitoring-operator à 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n kube-system scale deployment monitoring-operator --replicas=0
- Faites évoluer les déploiements
cert-manager gérés par monitoring-operator à zéro.
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 .
Le cas échéant, restaurez vos ressources personnalisées.
- Vous pouvez ignorer cette étape si vous utilisez l'
installation en amont du cert-manager ou si vous êtes certain 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 à partir de cert-manager dans l'espace de noms des ressources de cluster du gestionnaire de certificats 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, 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 envoyées avec des clusters Anthos sur VMware sont épinglées à des versions spéciales à l'aide du PPA Ubuntu. Cela garantit que toutes les modifications 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 faux positifs dans les résultats de l'analyse des failles de Docker, containerd et runc.
Par exemple, vous pouvez voir les faux positifs suivants dans vos résultats d'analyse CVE. Ces failles CVE sont déjà corrigées dans les dernières versions correctives des clusters Anthos sur VMware.
Reportez-vous aux notes de version pour obtenir les correctifs CVE.
Solution :
Canonical a connaissance de ce problème et le correctif est suivi à l'adresse
https://github.com/canonical/sec-cvescan/issues/73.
|
Mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13 |
La connexion réseau entre le cluster d'administrateur et le cluster d'utilisateur peut être indisponible pendant une courte période lors de la mise à niveau d'un cluster à haute disponibilité
Si vous mettez à niveau des clusters non haute disponibilité de la version 1.9 à la version 1.10, vous remarquerez peut-être que kubectl exec , kubectl log et le webhook ne sont pas disponibles pendant une courte période. Ce temps d'arrêt peut prendre jusqu'à une minute. En effet, la requête entrante (kubectl exec, kubectl log and webhook) est gérée par kube-apiserver pour le cluster d'utilisateur. L'utilisateur kube-apiserver est un
Statefulset. Dans un cluster à haute disponibilité, il n'existe qu'une seule instance dupliquée pour le Statefulset. Ainsi, lors de la mise à niveau, il est possible que l'ancien kube-apiserver ne soit pas disponible alors que le nouveau kube-apiserver n'est pas encore prêt.
Solution :
Ce temps d'arrêt ne se produit que pendant le processus de mise à niveau. Si vous souhaitez obtenir un temps d'arrêt plus court lors de la mise à niveau, nous vous recommandons de passer à des clusters à haute disponibilité.
|
Installation, mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13 |
Échec du contrôle de préparation de la Konnectivity lors du diagnostic des clusters à haute disponibilité après la création ou la mise à niveau du cluster
Si vous créez ou mettez à niveau un cluster à haute disponibilité, et que vous remarquez que la vérification de la préparation de la connectivité a échoué lors du 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 parce qu'une ou deux des instances dupliquées de la Konctivity peuvent ne pas être prêtes pour une certaine période en raison de la mise en réseau instable ou d'autres problèmes.
Solution :
L'instance konnectivity se rétablira seule. Attendez entre 30 minutes et une heure avant d'effectuer un nouveau 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 de l'OS Ubuntu sont renforcées avec le benchmark CIS L1 Server.
Par conséquent, le script Cron /etc/cron.daily/aide a été installé de sorte qu'une vérification aide est programmée afin de s'assurer que la règle de serveur CIS L1 "1.4.2 garantit que l'intégrité du système de fichiers est régulièrement vérifiée" est suivie.
La tâche Cron s'exécute tous les jours à 6h25 UTC. Selon le nombre de fichiers sur le système de fichiers, vous pouvez rencontrer des pics d'utilisation du processeur et de la mémoire à cette période qui sont dus à ce processus aide .
Solution :
Si les pics affectent votre charge de travail, vous pouvez désactiver la tâche Cron quotidienne:
sudo chmod -x /etc/cron.daily/aide
|
Mise en réseau |
1.10, 1.11, 1.12, 1.13 |
Les équilibreurs de charge et les règles de pare-feu distribuées avec état NSX-T interagissent de manière imprévisible
Lorsque vous déployez des clusters Anthos sur VMware version 1.9 ou ultérieure, lorsque l'équilibreur de charge groupé Seesaw est déployé dans un environnement utilisant des règles de pare-feu distribuées NSX-T, il est possible que stackdriver-operator ne crée pas de ConfigMap gke-metrics-agent-conf et provoque la plantage des pods gke-connect-agent dans une boucle de plantage.
Le problème sous-jacent réside dans le fait que les règles de pare-feu distribuées NSX-T avec état mettent fin à la connexion d'un client au serveur d'API du cluster d'utilisateur via l'équilibreur de charge Seesaw, car Seesaw utilise des flux de connexion asymétriques. Les problèmes d'intégration liés aux règles de pare-feu distribué NSX-T affectent tous les clusters Anthos sur VMware utilisant Seesaw. Vous pouvez rencontrer des problèmes de connexion similaires 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 configurer votre équilibreur de charge 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 |
Facturation de surveillance inattendue
Pour les clusters Anthos sur VMware version 1.10 vers la dernière version, certains clients ont constaté une facturation élevée et 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 )
- Le service géré pour Prometheus n'est pas activé (
enableGMPForApplications )
- Les pods de l'application comportent l'annotation
prometheus.io/scrap=true
Pour vérifier si vous êtes concerné par ce problème, répertoriez vos métriques définies par l'utilisateur. Si la facturation de métriques indésirables s'affiche, ce problème s'applique à vous.
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 gestion d'applications managed-service-for-prometheus permettant de résoudre le problème:
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 associés à l' 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.
|
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 approprié.
Lorsque la liaison de rôle est incorrecte, la création d'un disque de données vSphere avec govc se bloque et le disque est créé avec une taille égale à 0. Pour résoudre le problème, vous devez lier le rôle personnalisé au niveau de vSphere vCenter (racine).
Solution :
Si vous souhaitez lier le rôle personnalisé au niveau DC (ou inférieur à la racine), vous devez également lier le rôle en lecture seule à l'utilisateur au niveau racine de vCenter.
Pour en savoir plus sur la création de rôles, consultez la page
Droits liés au compte utilisateur 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 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 :
- 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 de DaemonSet
gke-metrics-agent par 1.1.0-anthos.8:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
Journalisation et surveillance |
1,10, 1,11 |
gke-metrics-agent présente des erreurs CrashLoopBackOff récurrentes
Pour les clusters Anthos sur VMware version 1.10 et ultérieure, le DaemonSet gke-metrics-agent présente fréquemment des erreurs CrashLoopBackOff lorsque la valeur de "enableStackdriverForApplications" est définie sur "true" dans l'objet "stackdriver".
Solution :
Pour résoudre ce problème, désactivez la collecte de métriques d'application en exécutant les commandes suivantes. Ces commandes ne désactivent pas la collecte des journaux d'application.
- Pour empêcher le rétablissement des modifications suivantes, procédez au scaling à la baisse de
stackdriver-operator :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy stackdriver-operator \
--replicas=0
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
- Ouvrez le fichier ConfigMap
gke-metrics-agent-conf pour le modifier :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- Sous
services.pipelines , mettez en commentaire l'intégralité de la section metrics/app-metrics :
services:
pipelines:
#metrics/app-metrics:
# exporters:
# - googlecloud/app-metrics
# processors:
# - resource
# - metric_to_resource
# - infer_resource
# - disk_buffer/app-metrics
# receivers:
# - prometheus/app-metrics
metrics/metrics:
exporters:
- googlecloud/metrics
processors:
- resource
- metric_to_resource
- infer_resource
- disk_buffer/metrics
receivers:
- prometheus/metrics
- Fermez la session de modification.
- Redémarrez le DaemonSet
gke-metrics-agent :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system rollout restart daemonset gke-metrics-agent
|
Journalisation et surveillance |
1,11, 1,12, 1,13 |
Remplacer les métriques obsolètes dans le tableau de bord
Si vous utilisez des métriques obsolètes dans vos tableaux de bord OOTB, des graphiques vides s'affichent. Pour rechercher les 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 remplacements.
Obsolète | Remplacement |
kube_daemonset_updated_number_scheduled |
kube_daemonset_status_updated_number_scheduled |
kube_node_status_allocatable_cpu_cores
kube_node_status_allocatable_memory_bytes
kube_node_status_allocatable_pods |
kube_node_status_allocatable |
kube_node_status_capacity_cpu_cores
kube_node_status_capacity_memory_bytes
kube_node_status_capacity_pods |
kube_node_status_capacity |
kube_hpa_status_current_replicas |
kube_horizontalpodautoscaler_status_current_replicas |
Solution :
Pour remplacer les métriques obsolètes
- Supprimez l'état du nœud GKE On-Prem dans le tableau de bord Google Cloud Monitoring. Réinstallez l'état "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 "GKE On-Prem Node Usage" 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 requise pour Kubernetes 1.22. Vous pouvez remplacer toutes les métriques kube-state-metrics obsolètes, qui portent le préfixe kube_ , dans vos tableaux de bord personnalisés ou vos règles d'alerte.
|
Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13 |
Données de métriques inconnues dans Cloud Monitoring
Pour les clusters Anthos sur VMware version 1.10 ou ultérieure, les données des clusters dans Cloud Monitoring peuvent contenir des entrées récapitulatives non pertinentes pour les métriques:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Voici d'autres types de métriques dont le résumé peut ne pas être pertinent : :
apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary
Bien que ces métriques de type résumé figurent dans la liste des métriques, elles ne sont pas compatibles avec gke-metrics-agent pour le moment.
|
Journalisation et surveillance |
1.10, 1.11, 1.12, 1.13 |
Métriques manquantes sur certains nœuds
Vous constaterez peut-être que les métriques suivantes sont manquantes pour certains nœuds, mais pas pour tous:
kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total
Solution :
Pour résoudre ce problème, procédez comme suit : Pour [version 1.9.5+, 1.10.2+, 1.11.0]: augmentez le processeur de 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 faire passer la demande de CPU 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 programmeur et contrôleur-gestionnaire manquantes dans le cluster d'administrateur
Si votre cluster d'administrateur est concerné par ce problème, les métriques du programmeur et du contrôleur-manquant sont manquantes. Par exemple, ces deux métriques sont manquantes
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solution :
Passez à la version 1.11.3+, v1.12.1+ ou v1.13+.
|
|
1.11.0-1.11.2, 1.12.0 |
Métriques de programmeur et contrôleur-gestionnaire manquantes dans le cluster d'utilisateur
Si votre cluster d'utilisateur est affecté par ce problème, les métriques "planificateur" et "contrôleur-gestionnaire" sont manquantes. Par exemple, ces deux métriques sont manquantes:
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solution :
|
Installation, mises à niveau et mises à jour |
1.10, 1.11, 1.12, 1.13 |
Échec de l'enregistrement du cluster d'administrateur lors de la création
Si vous créez un cluster d'administrateur pour la version 1.9.x ou 1.10.0 et que le cluster d'administrateur ne parvient pas à s'enregistrer 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 toujours 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 pouvez 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 appliquer un correctif à la ressource personnalisée
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.
- Exécutez ces commandes pour mettre à jour la ressource personnalisée
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
--no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
-n kube-system $ADMIN_CLUSTER_NAME \
-o=jsonpath='{.spec.gkeOnPremVersion}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Essayez à nouveau de mettre à niveau le cluster d'administrateur avec l'option
--disable-upgrade-from-checkpoint .
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès au fichier de configuration de votre cluster d'administrateur.
|
Identité |
1.10, 1.11, 1.12, 1.13 |
L'utilisation d'Anthos Identity Service peut entraîner le redémarrage imprévisible de l'agent Connect
Si vous gérez le service
Anthos Identity Service ClientConfig à l'aide de la fonctionnalité Anthos Identity Service, l'
agent Connect peut redémarrer de manière inattendue.
Solution :
Si vous avez rencontré ce problème avec un cluster existant, vous pouvez effectuer l'une des opérations suivantes:
|
Mise en réseau |
1.10, 1.11, 1.12, 1.13 |
Cisco ACI ne fonctionne pas avec Direct Server Return (DSR)
Seesaw s'exécute en mode DSR. Par défaut, elle ne fonctionne pas dans Cisco ACI en raison de l'apprentissage d'adresses IP de 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 (APIC).
Vous pouvez configurer l'option d'adresse IP virtuelle L4-L7 en accédant à Locataires > Profils d'application > EPG de l'application ou EPG uSeg. Si l'apprentissage IP n'est pas désactivé, les points de terminaison IP basculent entre différents emplacements de l'infrastructure Cisco.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Problèmes liés à la mise à niveau 3 de vSphere 7.0
VMWare a récemment identifié des problèmes critiques avec les versions suivantes de vSphere 7.0 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, 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 s'exécutant sur des nœuds qui utilisent des images Container-Optimized OS (COS), vous ne pouvez pas installer un 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
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, 1.13 |
La mise à jour de l'instance dupliquée de pool de nœuds ne fonctionne pas après la désactivation de l'autoscaling sur le pool de nœuds
Les instances dupliquées de pools 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 :
Supprimez les 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
Depuis la version 1.11, sur les tableaux de bord de surveillance prêts à l'emploi, le tableau de bord d'état des pods Windows et celui des nœuds Windows affichent également les données des clusters Linux. En effet, les métriques de nœud et de pod Windows sont également exposées sur des clusters Linux.
|
Journalisation et surveillance |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder en constante CrashLoopBackOff
Pour les clusters Anthos sur VMware versions 1.10, 1.11 et 1.12, stackdriver-log-forwarder Le DaemonSet peut rencontrer des erreurs CrashLoopBackOff lorsqu'il y a des journaux mis en mémoire tampon cassés 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, procédez au scaling à la baisse de
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
- Déployez le DaemonSet de nettoyage pour nettoyer les fragments cassés:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit-cleanup
namespace: kube-system
spec:
selector:
matchLabels:
app: fluent-bit-cleanup
template:
metadata:
labels:
app: fluent-bit-cleanup
spec:
containers:
- name: fluent-bit-cleanup
image: debian:10-slim
command: ["bash", "-c"]
args:
- |
rm -rf /var/log/fluent-bit-buffers/
echo "Fluent Bit local buffer is cleaned up."
sleep 3600
volumeMounts:
- name: varlog
mountPath: /var/log
securityContext:
privileged: true
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
- key: node-role.kubernetes.io/master
effect: NoSchedule
- key: node-role.gke.io/observability
effect: NoSchedule
volumes:
- name: varlog
hostPath:
path: /var/log
EOF
- Pour vous assurer que le DaemonSet de nettoyage a nettoyé tous les fragments, vous pouvez exécuter les commandes suivantes. Le résultat des deux commandes doit être égal au numéro de nœud du cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
- Supprimez le DaemonSet de nettoyage:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
- Réactiver
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
|
Sécurité |
1.13 |
Le service Kubelet sera temporairement indisponible après NodeReady
Il existe une courte période pendant laquelle le nœud est prêt, mais le certificat du serveur kubelet n'est pas prêt. kubectl exec et kubectl logs ne sont pas disponibles pendant ces dizaines de secondes.
En effet, le nouvel approbateur du certificat du serveur a besoin de temps pour voir les adresses IP valides mises à jour du nœud.
Ce problème n'affecte que le certificat du serveur kubelet. Il n'affecte pas 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 avec:
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Le cluster d'administrateur n'a pas été entièrement mis à niveau et la version d'état est toujours 1.10. La mise à niveau du cluster d'utilisateur vers la version 1.12 ne sera bloquée par aucune vérification préliminaire et échouera en cas de problème de décalage de version.
Solution :
Terminez pour mettre à niveau le cluster d'administrateur vers la version 1.11, puis pour le mettre à niveau vers la version 1.12.
|
Stockage |
1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0 |
Datastore signale à tort que l'espace disponible est insuffisant
Échec de la commande gkectl diagnose cluster :
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 dans gkectl diagnose cluster .
Solution :
Vous pouvez ignorer le message d'erreur ou ignorer la validation à l'aide de --skip-validation-infra .
|
Opération, mise en réseau |
1.11, 1.12.0-1.12.1 |
Vous ne pourrez peut-être pas ajouter de cluster d'utilisateur si votre cluster d'administrateur est doté d'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, 1.13 |
Échec lors de l'utilisation de Container-Optimized OS (COS) pour un 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 ressource osImageType que pour le cluster d'administrateur, et la VM de test n'est pas encore compatible avec COS.
Solution :
Pour éviter la vérification préliminaire lente qui crée la VM de test, utilisez gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config
USER_CLUSTER_CONFIG --fast .
|
Journalisation et surveillance |
1.12.0 à 1.12.1 |
Grafana dans le cluster d'administrateur ne parvient pas à atteindre les clusters d'utilisateur
Ce problème concerne les clients qui utilisent Grafana dans le cluster d'administrateur pour surveiller les clusters d'utilisateur dans Clusters Anthos sur VMware 1.12.0 et 1.12.1. Elle provient d'une non-concordance entre les certificats pushprox-client des clusters d'utilisateur et la liste d'autorisation du pushprox-server du cluster d'administrateur.
Le symptôme est pushprox-client dans les journaux d'erreurs d'impression des clusters d'utilisateur, comme suit:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Solution :
Afficher la procédure de contournement
procédez comme suit:
- Scaling à la baisse du déploiement de l'opérateur monitoring 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 de 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 que le cluster est mis à niveau vers la version 1.12.2, puis à résoudre le problème, faites évoluer le kube-system monitoring-operator du cluster d'administrateur afin qu'il puisse à nouveau gérer le pipeline.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
Autre |
1.11.3 |
gkectl repair admin-master ne fournit pas le modèle de VM à utiliser pour la récupération.
Échec de la commande gkectl repair admin-master :
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 du plan de contrôle d'administrateur se termine par les caractères t , m , p ou l .
Solution :
Exécutez à nouveau la commande avec --skip-validation .
|
Journalisation et surveillance |
1.11 |
Échec de Cloud Audit Logging en raison d'une autorisation refusée
Anthos Cloud Audit Logging nécessite 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 que le cluster d'administrateur pour la journalisation d'audit cloud. Ainsi, le cluster d'administrateur disposera de l'autorisation nécessaire pour Cloud Audit Logging.
Toutefois, dans le 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 autorisés 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 n'a été ajouté à 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 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 de l'autorisation a échoué.
Essayez de résoudre les problèmes dans le champ description de la réponse, ou sauvegardez la liste d'autorisation actuelle, supprimez la fonctionnalité de hub cloudauditlogging, puis réactivez-la à l'étape 1 de cette section. Pour supprimer la fonctionnalité cloudauditlogging Hub, procédez comme suit:
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 échec de vérification des certificats
Si votre poste de travail n'a pas accès aux nœuds de calcul du cluster d'utilisateur, les erreurs suivantes s'afficheront lors de l'exécution de gkectl diagnose :
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Si votre poste de travail n'a pas accès aux nœuds de calcul du cluster d'administrateur ni aux nœuds de calcul du cluster d'administrateur, il rencontrera les erreurs suivantes lors de l'exécution de gkectl diagnose :
Checking admin cluster certificates...FAILURE
Reason: 3 admin cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Solution :
Vous pouvez ignorer ces messages.
|
Système d'exploitation |
1,8, 1,9, 1,10, 1,11, 1,12, 1,13 |
/var/log/audit/ remplissant l'espace disque sur le poste de travail administrateur
/var/log/audit/ est rempli de journaux d'audit. Vous pouvez vérifier l'utilisation du disque en exécutant sudo du -h -d 1 /var/log/audit .
Certaines commandes gkectl sur le poste de travail administrateur, par exemple, gkectl diagnose snapshot contribuent à l'utilisation de l'espace disque.
Depuis 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 automatiquement supprimés", garantit le paramètre audit max_log_file_action = keep_logs . Toutes les règles d'audit sont alors conservées sur le disque.
Solution :
Afficher la procédure de contournement
Poste de travail d'administrateur
Pour le poste de travail administrateur, vous pouvez modifier manuellement les paramètres auditd 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 procède à la rotation automatique de ses journaux dès lors qu'il a généré plus de 250 fichiers (de 8 Mo chacun).
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 ne respecte pas 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 L'adresse IP flottante est en conflit avec l'adresse du nœud
Les utilisateurs ne peuvent pas créer ni mettre à jour d'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 par rapport à tous les node.status.addresses du cluster et considère cela comme un conflit.
Solution :
Dans le même cluster que celui où la création ou la mise à jour d'objets NetworkGatewayGroup échoue, désactivez temporairement le webhook de validation ANG et envoyez votre modification:
- Enregistrez la configuration du webhook pour 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, puis fermez l'application afin d'appliquer les modifications.
- Créez ou modifiez votre objet
NetworkGatewayGroup .
- Réappliquez la configuration 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 administrateur entre dans une boucle d'attente infinie lors du démarrage. Vous verrez l'erreur de boucle infinie suivante 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 toute adresse IP ayant un préfixe d'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 sera bloquée lors de la création. Ce problème peut également être résolu si l'adresse de diffusion a le même préfixe que l'adresse IP virtuelle du plan de contrôle, par exemple 192.168.1.255 .
Solution :
|
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 sera perdu lors de la mise à niveau du cluster d'administrateur ou de la réparation du maître d'administration. (le cluster d'administrateur utilisant l'image COS est une fonctionnalité d'aperçu)
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 les versions 1.10.0 d'Clusters Anthos sur VMware, les résolutions de noms sur Ubuntu sont acheminées par défaut vers l'écoute résolue par le système sur 127.0.0.53 . En effet, sur l'image Ubuntu 20.04 utilisée dans la version 1.10.0, /etc/resolv.conf est lié de manière symbolique à /run/systemd/resolve/stub-resolv.conf , qui pointe vers la simulation DNS de l'hôte local 127.0.0.53 .
Par conséquent, la résolution de noms DNS localhost refuse de vérifier les serveurs DNS en amont (spécifiés dans /run/systemd/resolve/resolv.conf ) pour rechercher 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, lors du démarrage du nœud, kubelet ne parvient pas à extraire des images d'un registre privé avec un suffixe .local . La spécification d'une adresse vCenter avec un suffixe .local ne fonctionne pas sur un poste de travail administrateur.
Solution :
Vous pouvez éviter ce problème pour les nœuds de cluster si vous spécifiez le champ searchDomainsForDNS dans votre fichier de configuration de cluster d'administrateur et le fichier de configuration du cluster d'utilisateur pour 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 modifiant le lien symbolique de /etc/resolv.conf /run/systemd/resolve/stub-resolv.conf (qui contient 127.0.0.53 local stub) en /run/systemd/resolve/resolv.conf le:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Comme pour le poste de travail administrateur, gkeadm ne prend pas en charge la spécification des domaines de recherche. Vous devez donc contourner ce problème avec cette étape manuelle.
Cette solution pour ne persiste pas lors de la recréation des VM. Vous devez l'appliquer 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 de système d'exploitation Ubuntu présente un bug qui 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 liaison. Cela peut entraîner un conflit d'adresses IP si une charge de travail s'exécute déjà dans cette plage d'adresses IP.
Solution :
Pour contourner ce problème, vous devez renommer le fichier de configuration systemd suivant pour Docker, puis redémarrer le service:
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
/etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
sudo systemctl daemon-reload
sudo systemctl restart docker
Vérifiez que Docker sélectionne l'adresse IP de liaison correcte :
ip a | grep docker0
Cette solution ne persiste pas lors de la recréation des VM. Vous devez appliquer de nouveau cette solution chaque fois que des VM sont recréées.
|
Mises à niveau et mises à jour |
1.11 |
Passer à la version 1.11 bloquée par Stackdriver
Dans la version 1.11.0 des clusters Anthos sur VMware, la définition des ressources personnalisées liées à la journalisation et à la surveillance a changé:
- Le nom du groupe de la ressource personnalisée
stackdriver (addons.sigs.k8s.io ) a été remplacé par 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 valiisées par rapport à leur schéma. Plus précisément, les spécifications resourceAttrOverride et storageSizeOverride de la ressource personnalisée
stackdriver doivent comporter un type de chaîne dans les valeurs et les limites de processeur, de mémoire et de taille de stockage.
Les modifications apportées au nom du groupe sont conformes aux mises à jour des définitions de ressources personnalisées dans Kubernetes 1.22.
Aucune action n'est requise si vous n'avez pas de logique supplémentaire pour appliquer ou modifier les ressources personnalisées concernées. Le processus de mise à niveau des clusters Anthos sur VMware se chargera de la migration des ressources concernées et conservera leurs spécifications existantes après le changement de nom du groupe.
Toutefois, si vous exécutez une logique qui applique ou modifie les ressources concernées, une attention particulière est requise. Tout d'abord, ils doivent être référencés avec le nouveau nom de groupe dans votre fichier manifeste. Exemple :
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
Ensuite, assurez-vous que les valeurs 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 ne s'appliqueront pas et peuvent entraîner un état inattendu des composants de journalisation et de surveillance. Symptômes possibles:
- 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 , par exemple:
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found
Si vous rencontrez les erreurs ci-dessus, cela signifie qu'un type non compatible selon la spécification Stackdriver CR é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 effectuer les opérations suivantes:
- Modifier les demandes et les limites de ressources en type de chaîne
- Supprimez toute annotation
addons.gke.io/migrated-and-deprecated: true si elle est présente.
Ensuite, reprenez ou redémarrez le processus de mise à niveau.
|