| Installation |
1.9.0
1.9.1
1.9.2 |
iLO est parfois incapable de récupérer la clé depuis le HSM.
Symptômes :
`server.status.conditions` comporte une entrée de type "KeyManagerConfigured" et d'état "True", mais aucune de type "DiskEncryptionEnabled". Des pods nommés `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` ont échoué avec l'erreur "ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0". Échec de la connexion SSH au pod en raison d'une clé non valide.
Solution :
Pour résoudre le problème, procédez comme suit :
Accédez à l'interface utilisateur iLO > Informations > Diagnostics > Réinitialiser pour réinitialiser iLO. Si, pendant la réinitialisation, iLO indique que le serveur est en cours d'autotest à la mise sous tension (POST), redémarrez le processus de provisionnement :
Si l'installation du cluster d'administrateur a réussi :
export KUBECONFIG=<root-admin-kubeconfig path>
Mettez à jour la clé SSH :
Récupérez la clé SSH publique actuelle (notez qu'elle peut avoir été renouvelée et donc être différente de /root/.ssh/id_rsa.pub).
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
Placez la clé publique dans le fichier ConfigMap ironic-vars :
kubectl -n gpc-system edit cm/ironic-vars
Ajoutez IRONIC_RAMDISK_SSH_KEY : \ Redémarrez ironic :
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Reprovisionnez la machine pour réinstaller IPA :
Sauvegardez bmc-credential-$SERVER, car la suppression de bmh entraînera également la suppression du secret.
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Supprimez du fichier les attributs non applicables tels que last-applied, creationtimestamp, finalizer, ownerreference, resourceversion et uid.
Supprimez le BareMetalHost :
kubectl -n gpc-system delete bmh/$SERVER
Récupérez le secret bmc-credentials-$SERVER ou la sauvegarde précédente à partir de cellcfg et appliquez-le.
Indiquez au serveur de faire autre chose.
Pour supprimer l'état BMH mis en cache :
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Attendez que le serveur soit provisionné. Découvrez comment les objets BMH sont créés. Vous devrez peut-être supprimer les tâches de chiffrement pour les redéclencher.
|
| Opérations |
1.9.0
1.9.1
1.9.2 |
Symptômes :
L'état de la VM est conservé avec STATUS de Provisioning ou Starting lorsque storageClassName est standard-block.
Solution :
Pour résoudre le problème, procédez comme suit :
Vérifiez que la VM STATUS affiche Provisioning ou Starting :
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG est le chemin d'accès au fichier kubeconfig du cluster système.
PROJECT est le projet GDC dans lequel réside la VM.
Facultatif : Obtenez des informations supplémentaires sur l'état :
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME est le nom de la VM qui ne répond pas.
Supprimez la VM :
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME correspond au nom de votre espace de noms.
Vérifiez que la suppression a bien été effectuée :
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Si l'opération réussit, vous obtiendrez un résultat semblable à ceci :
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Supprimez tous les disques de cette VM :
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME Remplacez DISK_NAME_1, DISK_NAME_2 et DISK_NAME_N par le nom de chacun de vos disques et assurez-vous que tous les disques sont listés. Vérifiez que la suppression a bien été effectuée :
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
Si l'opération réussit, vous obtiendrez un résultat semblable à ceci :
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
Recréez la VM et les disques.
Redémarrez la VM.
|
| Opérations |
1.9.2 |
Symptômes :
gdcloud system container-registry load-oci échoue avec des erreurs. Si vous réexécutez la commande, elle s'exécute pendant différentes périodes et échoue à différents moments du processus (par exemple, lors de l'envoi ou du re-taggage), mais avec des erreurs similaires.
Solution :
Pour résoudre le problème, procédez comme suit :
Exportez KUBECONFIG vers le fichier kubeconfig de l'administrateur racine :
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Exécutez cette commande pour réduire
deployment/root-admin-tftp-manager-controller à zéro instance dupliquée :
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- Effectuez les opérations qui échouaient.
- Effectuez un scaling à la hausse de
deployment/root-admin-tftp-manager-controller à une instance dupliquée :
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| Opérations |
1.9.1
1.9.2
1.9.3 |
Symptômes :
gdcloud system container-registry load-oci échoue avec des erreurs. Si vous réexécutez la commande, elle s'exécute pendant différentes périodes et échoue à différents moments du processus (par exemple, lors de l'envoi ou du re-taggage), mais avec des erreurs similaires.
Solution :
Vous pouvez ignorer ce message sans risque. Il disparaît au bout d'un certain temps.
|
| Opérations |
1.9.2 |
Solution :
Pour résoudre le problème, redémarrez le pod concerné.
|
| Opérations |
1.9.0
1.9.1
1.9.2 |
Symptômes :
L'état de la condition "Server's Ready" (Serveur prêt) est défini sur "False" (Faux), et le message contient "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ..." (Échec de la tâche server-encrypt-and-create-logical-drive-... avec le motif ... et le message ...). Les journaux de la tâche ayant échoué contiennent "Failed to connect to the host via ssh ... Permission denied (publickey)." (Échec de la connexion à l'hôte via SSH ... Autorisation refusée (clé publique)).
Solution :
Pour résoudre le problème, procédez comme suit :
Récupérez la clé SSH publique actuelle du cluster d'administrateur racine :
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dPlacez la clé dans le fichier ConfigMap ironic-vars :
kubectl -n gpc-system edit cm/ironic-vars Ajoutez ou remplacez la clé IRONIC_RAMDISK_SSH_KEY existante :
<SSH public key>
Redémarrez le déploiement d'Ironic :
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Pour chaque serveur concerné :
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| Opérations |
1.9.2 |
Solution :
Pour éviter de manquer d'adresses IP, définissez la taille du CIDR de pod sur /21 ou plus lorsque vous créez un cluster d'utilisateur à haute disponibilité.
|
| Installation |
1.9.2 |
Solution :
Pour résoudre le problème, redémarrez les pods.
Pour en savoir plus, consultez le runbook MON-R0001.
|
| Authentification de la plate-forme |
1.9.13 |
Symptômes :
Tous les jobs cplb-init et storage-ipsec-config-bm-XXXXX affichent le message suivant : Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out.
Solution :
1. Vérifiez si le VRF BGP est hors service sur aggswitch.
2. Vérifiez si des modifications non validées ont été apportées à la nouvelle configuration de préproduction du pare-feu.
3. Nettoyez tous les securitypolicyrules dont le nom contenait l'organisation supprimée, puis redémarrez le contrôleur d'administrateur racine.
|
| Mettre à niveau |
1.9.1
1.9.2
1.9.11 |
Symptômes :
Server est bloqué à deprovisioning depuis plus de 20 minutes..status.bareMetalHostStatus.provisionState
L'adresse IP de gestion du serveur en cours de mise à niveau est incluse dans le résultat de l'une de ces commandes :
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
Solution :
Pour résoudre le problème, exécutez la commande suivante :
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| Mettre à niveau |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
Symptômes :
Une tâche de mise à niveau dans NodeUpgrade n'est pas terminée depuis plus de deux heures.
Un NodeUpgradeTask correspondant est bloqué à la condition NodeResumeCompleted et reste inachevé pendant plus d'une heure.
Les tâches bm-system-x.x.x.x-machine-init restent inachevées pendant une longue période. x.x.x.x est l'adresse du nœud.
Solution :
Pour trouver l'adresse d'un nœud non opérationnel, consultez le x.x.x.x du job bm-system-x.x.x.x-machine-init en attente.
Pour trouver un nœud de plan de contrôle opérationnel pour le nœud non opérationnel, procédez comme suit :
- Recherchez le pool de nœuds du nœud non opérationnel.
Vérifiez le pool de nœuds du plan de contrôle dans le même cluster que le nœud défaillant, puis sélectionnez une adresse dans le .spec.address de ce pool de nœuds du plan de contrôle.
Sur le programme d'amorçage ou OC IT, exécutez :
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
Dans le nœud de plan de contrôle opérationnel, exécutez la commande suivante :
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| Mettre à niveau |
1.9.1
1.9.2 |
Symptômes :
Le pod ODS Fleet Operator est en boucle de plantage.
Pour vérifier l'état du pod, exécutez la commande suivante :
ko get pods -n ods-fleet-operator
Une erreur d'élection du leader semblable à la suivante s'affiche dans les journaux de l'opérateur de parc ODS :
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
Pour vérifier les journaux de l'opérateur de flotte ODS, exécutez la commande suivante :
ko logs deployment/fleet-controller-manager -n ods-fleet-system
Le message suivant s'affiche :
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition.
Solution :
Pour modifier le déploiement, exécutez la commande suivante :
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
Veillez à modifier le champ resources du conteneur manager comme suit :
Avant :
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
Après :
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| Mettre à niveau |
1.9.2
1.9.3 |
Symptômes :
Le message d'erreur suivant s'affiche :
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
Solution :
Pour résoudre le problème, suivez les étapes ci-dessous :
Connectez-vous à tous les nœuds GPU provisionnés :
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
Supprimez les anciens packages :
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
Supprimez le pod kubevm-gpu-driver-daemonset bloqué. Cela redémarre l'installation :
# kug get pods -A | grep gpu | grep Init
(Facultatif) Si l'installation du module complémentaire a expiré, redémarrez-la :
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| Mettre à niveau |
1.9.10
1.9.11 |
Symptômes :
gpcbackup-agent-0 affiche failed to stage volume: iSCSI login failed et ne parvient pas à définir le volume.
Vérifiez si le pod ne parvient pas à associer le volume. Les exemples suivants utilisent le fichier kubeconfig du cluster système :
-
Décrivez le pod :
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Si le pod échoue, un résultat semblable à l'exemple suivant s'affiche :
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
Vérifiez le nœud pour lequel le pod échoue :
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Vous obtenez un résultat semblable à l'exemple suivant :
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
Obtenez le pod netapp-trident sur le même nœud pour lequel le pod gpcbackup-agent-0 a échoué :
kos get pod -o wide -n netapp-trident
Vous obtenez un résultat semblable à l'exemple suivant :
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Consultez les journaux du pod netapp-trident sur le même nœud pour lequel le pod gpcbackup-agent-0 a échoué :
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Vous obtenez un résultat semblable à l'exemple suivant :
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
Solution :
Pour résoudre le problème, procédez comme suit :
-
Obtenez le nom de InventoryMachine :
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Vérifiez que le job précédent existe :
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
Vous obtenez un résultat semblable à celui-ci :
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
Supprimez le job :
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Vous obtenez un résultat semblable à celui-ci :
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Vérifiez que StorageEncryptionConnection existe :
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Vous obtenez un résultat semblable à celui-ci :
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
Supprimez le sous-réseau StorageEncryptionConnection :
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Vous obtenez un résultat semblable à celui-ci :
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Redémarrez le pod root-admin-controller :
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
Vérifiez que le nouveau job a bien été recréé et exécuté :
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
Vous obtenez un résultat semblable à celui-ci :
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| Mettre à niveau |
1.9.10
1.9.11 |
Symptômes :
Un pod de registre Harbor affiche un message d'erreur semblable à celui-ci :
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
Solution :
Pour résoudre ce problème, procédez comme suit :
-
Vérifiez la demande de volume persistant (PVC) du registre Harbor et notez le nom du volume PVC :
kubectl get pvc harbor-registry -n harbor-system
-
Pour vérifier si le volume est associé au même nœud que le pod du registre Harbor, listez les volumeattachment et recherchez celui associé au nom du volume :
kubectl get volumeattachment | grep [volume-name]
-
Si le rattachement de volume se trouve dans un nœud différent de celui du pod de registre Harbor, supprimez volumeattachment :
kubectl delete volumeattachment [volumeattachment-name]
-
Redémarrez le pod du registre Harbor.
Le registre Harbor du cluster d'administrateur racine doit maintenant être opérationnel et la mise à niveau des nœuds doit se terminer correctement.
|
| Installation |
1.9.2
1.9.3
1.9.4
1.9.5
|
Symptômes :
Le message d'erreur suivant s'affiche :
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Un journal de pod contient les éléments suivants :
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
La version de CoreDNS est 1.8.6.
Solution :
Pour résoudre le problème, redémarrez le déploiement coredns.
Une fois KUBECONFIG défini pour le bon cluster, exécutez la commande suivante :
kubectl rollout restart deployment coredns -n kube-system
Le nom du cluster d'utilisateur figure dans le message d'erreur.
Pour trouver le fichier kubeconfig dans /root/release/user/, recherchez les fichiers kubeconfig : org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig.
Si des fichiers kubeconfig sont manquants, générez-les comme suit :
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| Mettre à niveau |
1.9.2
1.9.3 |
Symptômes :
Le message d'erreur suivant s'affiche :
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
Ce problème est généralement temporaire et devrait disparaître.
|
| Installation |
1.9.3 |
L'installation d'un module complémentaire échoue avec l'erreur suivante :
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition.
Solution :
L'installation du module complémentaire peut échouer si les nœuds sont à l'état NotReady. Vérifiez si les nœuds sont à l'état NotReady à l'aide de la commande suivante :
kubectl get nodes
Obtenez des informations sur le nœud à l'état NotReady :
$ kubectl describe node | grep PodCIDRs
Pour un cluster présentant ce problème, aucun PodCIDR n'est attribué à un nœud. Par exemple :
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
Pour résoudre le problème, redémarrez le déploiement ipam-controller dans le cluster concerné :
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| Mettre à niveau |
1.9.3 |
Une mise à niveau échoue avec l'erreur suivante :
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded.
Solution :
Mettez à jour manuellement le champ <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> de l'AddOnSet abm-overrides en indiquant le nom de l'AddOnSetTemplate de la version souhaitée dans le même espace de noms que le cluster mis à niveau.</code.spec.addonsettemplateref<>
|
| Installation |
1.9.3 |
Symptômes :
Un contrôleur d'administrateur de parc ne parvient pas à devenir prêt et échoue au test TestCreateFleetAdminCluster ou TestSimOverlayCreateFleetAdminCluster. Le contrôleur d'administrateur de flotte est bloqué dans une boucle de plantage. L'erreur suivante figure dans les journaux du contrôleur d'administration de parc : Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Solution :
Déployez le CRD Logmon dans le cluster d'administrateur de l'organisation. Redémarrez le contrôleur d'administrateur de parc.
|
| Installation |
1.9.3 |
Symptômes :
Le message d'erreur suivant s'affiche :
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
Solution :
Pour résoudre le problème, redémarrez le déploiement et le DaemonSet dans le cluster :
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
Remarque : Exécutez la commande suivante avant de redémarrer le déploiement et le DaemonSet pour pointer vers le bon cluster :
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| Mettre à niveau |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
Symptômes :
Un pod ne peut pas être planifié en raison d'un processeur insuffisant.
Solution :
Pour un cluster d'utilisateur existant créé avec des nœuds de calcul n2-standard-4, ajoutez un pool de nœuds n2-standard-8 avec trois nœuds à ce cluster avant la mise à niveau. Pour les nouveaux clusters d'utilisateur, créez un n2-standard-8 NodePool avec au moins trois nœuds. Pour en savoir plus, consultez Créer un cluster d'utilisateur pour les charges de travail de conteneurs.
|
| Opérations |
1.9.0
1.9.2
1.9.3
1.9.4 |
Symptômes :
L'instance de VM PHASE affiche Scheduling et READY, et reste à l'état False sans jamais atteindre l'état True. Cela affecte deux types de machines, comme indiqué dans la solution de contournement. Les autres types de machines ne sont pas concernés et n'ont pas besoin de solution de contournement.
Solution :
- Lorsque vous créez des clusters d'utilisateur qui utilisent des GPU A100 40G, sélectionnez toujours le type de machine a2-highgpu-1g-gdc dans l'UI.
- Lorsque vous créez des clusters d'utilisateur qui utilisent des GPU A100 80G, sélectionnez toujours le type de machine a2-ultragpu-1g-gdc dans l'UI.
|
| Opérations |
1.9.0
1.9.2
1.9.3
1.9.4 |
Symptômes :
Pour les pools de nœuds avec des instances de VM dont la taille de mémoire est supérieure à 32 Go, l'instance de VM peut sembler s'exécuter, puis s'arrêter et s'exécuter à nouveau, et cette séquence peut se répéter. Finalement, une erreur OOMKilled de mémoire insuffisante est générée et l'instance échoue.
Voici les trois types de VM concernés :
- n2-highmem-8-gdc : 64 Go de mémoire
- a2-highgpu-1g-gdc : 85 Go de mémoire
- a2-ultragpu-1g-gdc : 170 Go de mémoire
Solution :
- Vérifiez le type de votre machine :
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- Recherchez le type de VM dans
spec.compute.virtualMachineTypeName dans votre résultat.
- Si le type de VM correspond à l'un des trois types listés, modifiez
configmap pour inclure un remplacement de la mémoire :
.
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- Ajoutez une section
memory.guest et resources.overcommitGuestOverhead, comme dans l'exemple suivant :
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- Dans
memory, remplacez guest par les valeurs suivantes :
- Pour n2-highmem-8-gdc, définissez MEMORY_SIZE sur
63.6G.
- Pour a2-highgpu-1g-gdc, définissez MEMORY_SIZE sur
84G.
- Pour a2-ultragpu-1g-gdc, définissez MEMORY_SIZE sur
168G.
- Répétez cette opération pour toutes les VM concernées.
|
| Mettre à niveau |
1.9.4 |
Symptômes :
Une tâche bm-system-* est bloquée à l'étape Gathering Facts. Lorsque vous essayez d'établir manuellement une connexion SSH au serveur, PTY allocation request failed on channel 0 s'affiche.
Solution :
Redémarrez le serveur à l'aide de l'une des méthodes suivantes :
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
Interface utilisateur iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Mettre à niveau |
1.9.4
1.9.10 |
Symptômes :
Une mise à niveau échoue en raison de l'échec du job backup-ipsec-*.
Solution :
Procédez comme suit :
Recherchez les clés prépartagées dans l'espace de noms gpc-system du cluster d'administrateur de l'organisation. Les clés sont nommées <node-name>-pre-shared-key.
Pour obtenir le hachage de clé à partir du fichier YAML de clé prépartagée d'un nœud fonctionnel, utilisez kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }'.
Notez que vous devez obtenir le hachage de clé à partir d'un nœud autre que celui où la mise à niveau ipsec a échoué. Appliquez le hachage de cette clé pré-partagée au secret de clé pré-partagée du nœud défaillant dans gpc-system du cluster d'administrateur de l'organisation. Supprimez l'objet storageencryptionconnection qui porte le même nom que le nœud défaillant dans le cluster d'administrateur racine. Supprimez le job storage-ipsec-config-<node-name> associé dans le cluster d'administrateur de l'organisation. Supprimez le job de mise à niveau backup-ipsec-for-upgrade-<node-name> associé.
|
| Mettre à niveau |
1.9.4 |
Symptômes :
La mise à niveau des clusters d'organisation prend beaucoup de temps.
Solution :
Attendez que clamav s'arrête naturellement.
|
| Mettre à niveau |
1.9.5 |
Symptômes :
Différents certificats s'affichent :
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
Solution :
Remarque : Faites pivoter le certificat harbor-harbor-https avant de passer aux étapes suivantes.
Procédez comme suit :
Des copies des données du certificat sont stockées dans des secrets au sein du cluster. Après avoir fait tourner le certificat harbor-harbor-https, vous devez également mettre à jour les copies secrètes.
- Récupérez l'URL Artifact Registry.
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- Mettez à jour les copies secrètes du certificat Artifact Registry dans chaque espace de noms.
Obtenez tous les espaces de noms qui stockent une copie secrète du certificat Artifact Registry.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Mettez à jour la copie secrète du certificat Artifact Registry dans chaque espace de noms.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- Pour le cluster root-admin, vous devez également mettre à jour un correctif nommé copie du secret du certificat, appelé
ca-cert-in-cluster-registry dans l'espace de noms anthos-creds.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
- Mettez à jour le
registry-cert stocké dans l'espace de noms kube-system.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- Si vous appliquez une rotation des certificats pour le cluster org-admin, vous devez également mettre à jour les copies secrètes des certificats qui existent dans le cluster root-admin.
Obtenez tous les espaces de noms qui stockent une copie secrète du certificat Artifact Registry.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Mettez à jour la copie secrète du certificat Artifact Registry dans chaque espace de noms.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done .
|
| Mettre à niveau |
1.10.0
1.10.1 |
Symptômes :
Après avoir démarré un OrganizationUpgrade, le pod kube-apiserver ne s'exécute pas sur un ou plusieurs nœuds.
- Identifiez le nœud sur lequel la mise à niveau est bloquée :
kubectl get po -n kube-system -l component=kube-apiserver
Le résultat ressemble à ceci :
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- Établissez une connexion SSH avec le nœud qui vient d'être mis à jour :
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
L'état du conteneur est Exited :
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- Vérifiez les journaux du pod
Exited :
crictl logs f1771b8aad929
Le résultat ressemble à ceci :
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
L'indicateur est configuré dans le fichier /etc/kubernetes/manifests/kube-apiserver.yaml :
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
Solution :
Supprimez l'indicateur du fichier /etc/kubernetes/manifests/kube-apiserver.yaml.
- Sauvegardez le fichier :
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- Supprimez la ligne :
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- Vérifiez que la ligne a été supprimée :
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Répertoriez le conteneur
kube-apiserver :
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet détecte automatiquement la modification et démarre le pod kube-apiserver :
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Répétez ces étapes pour tous les nœuds concernés.
|
| Mettre à niveau |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Symptômes :
Les boucles de plantage du déploiement kube-state-metrics dans une organisation après la rotation des certificats. Ce problème peut entraîner une perte de données de surveillance.
|
| Mettre à niveau |
1.9.6 |
Symptômes :
Après la mise à niveau, le nœud de calcul est déséquilibré.
Solution :
Équilibrez manuellement le nœud de calcul :
- Pour une charge de travail de pod, supprimez les pods du déploiement.
- Pour une charge de travail de VM, supprimez virt-launcher sans modifier l'objet GVM du plan de contrôle.
|
| Mettre à niveau |
1.9.6 |
Lors de la mise à niveau de la version 1.9.5 vers la version 1.9.6, il est possible que le plug-in de périphérique GPU ne puisse pas démarrer.
Symptômes :
L'erreur suivante peut s'afficher, ce qui bloque la préparation de l'exécution de la VM et le processus de mise à niveau :
Failed to initialize NVML: could not load NVML library
Solution :
- Vérifiez si
nvidia-container-runtime est correctement configuré sur le nœud :
- Établissez une connexion SSH avec le nœud qui, selon vous, présente un problème.
- Obtenez la liste des pods :
crictl pods
- Inspectez les pods :
crictl inspectp $pod_hash | grep runtimeOption -A1
Si le résultat ressemble à ceci, le nœud est correctement configuré. Si le résultat ne ressemble pas à celui-ci, cela signifie que nvidia-container-runtime n'est pas configuré sur le nœud :
binary_name": "/usr/bin/nvidia-container-runtime"
- Si
nvidia-container-runtime n'est pas configuré correctement, redémarrez containerd pour résoudre le problème :
systemctl restart containerd
|
| Mettre à niveau |
1.9.7 |
Lors de la mise à niveau vers la version 1.9.7, le micrologiciel du pool de nœuds du cluster administrateur racine reste à l'état in process.
Symptômes :
- Pour le côté
NodeUpgrade, consultez la solution de contournement Délai d'inactivité du serveur d'artefacts :
NodeUpgrade est bloqué à l'état in process et la condition pour NodeROMFirmwareUpgradeCompleted à l'état Nodeupgradetask n'est jamais remplie.- L'URL dans
spec.firmware.firmwarePackages.url de l'objet NodeUpgrade peut se bloquer lors de la connexion, par exemple :
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- Pour le côté
Harbor, consultez la solution de contournement Serveur d'artefacts non autorisé :
- Dans le journal du serveur d'artefacts, une erreur liée à un accès non autorisé à un dépôt peut s'afficher :
gdch-hpe-firmware/ilo, par exemple :
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- Dans le projet Harbor,
gdch-hpe-firmware doit avoir Spec.harborProjectConfig.accessLevel comme private :
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
Solution :
|
| Mise en réseau de niveau inférieur |
1.9.0 - 1.9.6 |
Symptômes :
Les sessions BGP sont arrêtées dans le réseau interne d'une organisation. Un seul des points de terminaison d'appairage BGP interne de l'organisation est ajouté aux objets TORSwitchInternal.
Solution :
Modifiez explicitement le sous-réseau utilisé dans {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim pour qu'il ne chevauche pas les ressources AddressPoolClaim analogues d'une autre organisation.
- Étudiez les symptômes :
- Pour chaque cluster de système d'organisation, exécutez la commande suivante :
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- Vérifiez le champ
State de chaque objet BGPSession pour State de NotEstablished. Notez le LocalIP de chaque NotEstablished BGPSession associé pour une utilisation ultérieure.
- Déterminez si
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" est la cause première :
- Pour chaque organisation active, exécutez la commande suivante :
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- Recherchez le
LocalIPs noté à l'étape 1.b dans le champ ClusterIP (3e colonne) du résultat. Notez les LocalIP qui correspondent aux entrées de la troisième colonne du résultat pour plus tard. S'il existe plusieurs clusters d'administration d'organisation distincts, où la sortie de l'étape 2.a contient les LocalIP indiqués à l'étape 1.b, passez à l'étape 3.
- Résolvez les adresses IP qui se chevauchent et qui sont utilisées pour les clusters de systèmes de l'organisation.
- Exécutez la commande suivante :
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- Notez le nombre d'objets
SubnetClaim renvoyés par la requête 3.a. Elle doit être égale au nombre d'organisations actives.
- Pour chaque ligne, notez l'espace de noms (colonne 1) et le bloc CIDR (colonne 3). Le bloc CIDR de chaque ligne doit être identique à celui de toutes les autres lignes.
- Pour chaque organisation, procédez comme suit :
- Accédez à l'objet
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim dans le cluster d'administration de l'organisation.
- Calculez le
Start IP de la revendication du pool d'adresses de nœuds de calcul de cette organisation. Pour ce faire, prenez le bloc CIDR de 3.c et le champ Size de AddressPoolClaim dans 3.d.i. En commençant par l'avant-dernière adresse IP du bloc CIDR, décomptez Size IP. Il s'agit du nouveau Start IP pour la première organisation (utilisé à l'étape 3.d.iii). Pour chaque organisation supplémentaire, décomptez Size IP, en commençant par le nouveau Start IP de l'organisation précédente.
Exemple :
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- Dans le
AddressPoolClaim de l'étape 3.c.i, ajoutez le champ suivant dans le champ Spec :
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
Exécutez la commande suivante :
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
Le résultat doit ressembler à ce qui suit si vous utilisez org-1 à partir de 3.d.ii, par exemple :
apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- Nettoyez pour éviter les sessions BGP inutiles sur le matériel TORSwitch.
- Pour lister toutes les ressources
TORSwitchInternal à mettre à jour, exécutez la commande suivante :
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Pour chaque
TORSwitchInternals listé dans le résultat de la commande précédente, exécutez la commande suivante :
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- Pour tous les objets
TORSwitchInternal, supprimez toutes les entrées de la liste .spec.ebgpNeighbors dont les NeighborIP sont égaux à l'un des LocalIP de l'étape 2.b. Par exemple, LocalIP de 2.2.2.2 a été noté à l'étape 2.b. Vous trouverez ci-dessous un exemple de fichier TORSwitchInternal avant et après l'étape de nettoyage.
Avant le nettoyage :
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
Après le nettoyage. Notez l'entrée ebgpNeighbor supprimée :
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- Validez en effectuant l'étape 1 et en vérifiant que tous les objets
States BGPSession sont revenus à l'état Established. La propagation de toutes les modifications aux configurations physiques des TORSwitch GDC peut prendre environ 10 minutes.
|
| Mettre à niveau |
1.9.7 - 1.9.21 |
Lors d'une mise à niveau, il est possible que la mise à niveau du nœud et du système d'exploitation ne progresse pas.
Symptômes :
Il est possible qu'un nœud affiche l'état Ready, SchedulingDisabled pendant quelques heures.
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
Solution :
- Suivez le runbook PLATAUTH-SSH 0001 pour obtenir la clé SSH du nœud en question. Après vous être connecté au nœud avec SSH, exécutez la commande suivante :
multipath -ll | grep fail
- Ne passez à l'étape suivante que si le résultat ressemble à ce qui suit :
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- Exécutez la commande suivante pour résoudre le problème :
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| Mettre à niveau |
1.9.8-1.9.21 |
Symptômes :
Si la mise à niveau d'un cluster ABM est bloquée pendant plus de deux heures, le drainage des nœuds peut être bloqué.
Solution :
Les opérations suivantes utilisent le cluster d'administrateur racine comme exemple. ${TARGET_KUBECONFIG} fait référence au fichier kubeconfig du cluster ABM cible dont la vidange des nœuds est bloquée, et ${KUBECONFIG} fait référence au fichier kubeconfig du cluster gérant le cluster ABM cible. Pour le cluster d'administrateur racine, ils font tous les deux référence au fichier kubeconfig de l'administrateur racine.
Pour savoir si la mise à niveau du cluster ABM est bloquée, procédez comme suit :
- Vérifiez les nœuds bloqués au niveau du drainage :
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
Le résultat ressemble à ce qui suit :
{"10.200.0.2": 2}
Cela signifie que deux pods sont en cours de drainage pour le nœud "10.200.0.2".
- Vérifiez si les pods sont toujours en cours de vidange du nœud (appelé
${NODE_BEING_DRAINED}) :
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
Le nombre de pods de sortie doit être identique au nombre de pods en cours de vidange indiqué à l'étape précédente.
Pour chaque pod yetToDrain listé à l'étape 1, vérifiez l'état du pod :
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Si le pod est à l'état Running, ou s'il est audit-logs-loki-0 ou loki-0 dans l'espace de noms obs-system et qu'il n'y a aucun événement unable to unmount volume, supprimez explicitement le pod avec un grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- Pour tous les autres cas où un pod est bloqué en cours de vidange, escaladez le problème aux services d'astreinte.
- Vérifiez que le drainage du nœud est terminé.
- Répétez l'étape 1 si d'autres nœuds sont bloqués lors de la vidange.
|
| Mettre à niveau |
1.9.6
1.9.7
1.9.8
|
Les versions 1.9 avec des artefacts signés ne peuvent pas être distribuées, car le flag Override dans DistributionPolicy est défini sur "false". Cela empêche la distribution lorsqu'un artefact portant le même nom se trouve dans le registre de destination.
Symptômes :
Vous pouvez rencontrer les problèmes suivants :
- L'artefact avec signature est transféré. Le journal peut se présenter comme suit :
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Échec de l'envoi de l'artefact. Le journal peut se présenter comme suit :
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 404 : l'artefact est introuvable. Le journal peut se présenter comme suit :
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- Échec de la distribution des artefacts.
Solution :
Pour résoudre le problème, procédez comme suit :
- Mettez à jour la ressource personnalisée (CR)
DistributionPolicy pour définir Spec.Override sur true.
- Déclenchez à nouveau une réplication en suivant le runbook SAR-1005.
- Une fois la nouvelle exécution de la réplication réussie, mettez à jour le CR
execution-ids ManualDistribution dans Annotation avec l'ID d'exécution réussi.
|
| Module de sécurité matériel (HSM) |
1.9.9 |
Les HSM peuvent signaler par intermittence ServicesNotStarted, ce qui peut empêcher les serveurs bare metal de passer à l'état sain et entraîner l'affichage du message suivant :
"message": "failed to get master key name"
Symptômes :
Vous pouvez rencontrer les problèmes suivants :
Solution :
Pour résoudre le problème, suivez les étapes ci-dessous pour redémarrer les HSM bloqués :
- Installez l'outil
kstl à partir du premier HSM en exécutant les commandes suivantes :
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- Vérifiez si un HSM rencontre des difficultés pour redémarrer. Pour chaque HSM bloqué à l'état
ServicesNotStarted, obtenez le $HSM_MGMT_IP et vérifiez que le service est hors service :
ksctl services status --url=https://$HSM_MGMT_IP
- Mettez en veille tous les HSM, clusters HSM et locataires HSM :
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- Établissez une connexion SSH avec le HSM lorsque le service est arrêté :
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Assurez-vous d'être dans le bon HSM. Vérifiez si vous avez établi une connexion SSH avec le
$HSM_MGMT_IP approprié.
- Redémarrez le premier HSM depuis l'intérieur du HSM :
ksadmin@ciphertrust:~ sudo reboot
- Attendez que le premier HSM devienne opérationnel depuis l'extérieur du HSM :
watch -c ksctl services status --url=https://$HSM_MGMT_IP
Le redémarrage des HSM peut prendre environ cinq minutes.
- Répétez ces étapes pour les autres HSM dont les services sont hors service.
- Réactivez les HSM, les clusters HSM et les locataires HSM :
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- Vérifiez que tout est bien réconcilié. La réconciliation des HSM peut prendre entre cinq et dix minutes.
|
| Surveillance |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
Symptômes :
Les alertes alertmanager-servicenow-webhook n'atteignent pas ServiceNow dans le cluster système de l'organisation pour les versions GDC antérieures à 1.11.3. Les journaux contiennent le message d'erreur read: connection reset by peer. Ce problème est dû à un libellé manquant pour activer le trafic de sortie. Si le webhook doit communiquer entre les organisations, il doit utiliser la NAT de sortie.
Solution :
Vous devez activer le trafic sortant pour alertmanager-servicenow-webhook dans les clusters système de l'organisation. Pour résoudre le problème, procédez comme suit :
- Définissez les prérequis requis :
- Installez l'interface de ligne de commande (CLI) gdcloud.
- Obtenez les chemins d'accès aux fichiers kubeconfig des clusters administrateur racine et administrateur de l'organisation. Enregistrez les chemins d'accès dans les variables d'environnement
ROOT_KUBECONFIG et ORG_SYSTEM_KUBECONFIG, respectivement.
- Demandez à votre administrateur de sécurité de vous attribuer le rôle Administrateur Observability (
observability-admin) dans l'espace de noms obs-system pour les clusters d'administrateur racine et d'administrateur de l'organisation.
- Vérifiez que le problème existe dans votre environnement :
- Obtenez le déploiement
alertmanager-servicenow-webhook :
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- Affichez les journaux du déploiement
alertmanager-servicenow-webhook :
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
Si les journaux contiennent le message d'erreur read: connection reset by peer, le problème existe et vous devez suivre les étapes de cette solution de contournement.
- Ajoutez le libellé de sortie :
- Obtenez le fichier YAML de déploiement
alertmanager-servicenow-webhook actuel :
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Ajoutez le libellé de sortie au fichier YAML de déploiement
alertmanager-servicenow-webhook :
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Remplacez le fichier YAML de déploiement
alertmanager-servicenow-webhook par les mises à jour :
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
Le déploiement doit redémarrer automatiquement.
- Vérifiez que le problème est résolu en exécutant à nouveau les étapes de la section Confirmer que le problème existe dans votre environnement. Le message d'erreur des journaux ne doit pas s'afficher. Sinon, escaladez le problème à l'équipe d'ingénierie.
Stratégie de rollback :
Si la procédure de contournement échoue ou si vous constatez une perte de métriques, rétablissez l'état d'origine du fichier YAML de déploiement alertmanager-servicenow-webhook :
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| Mettre à niveau |
1.9.10 |
Symptômes :
La mise à niveau est bloquée à l'étape NodeMaintain.
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
Le nodeupgradetask du pool de nœuds en cours d'exécution affiche :
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
Solution :
Procédez comme suit :
- Obtenez le nom du déploiement cap-controller-manager.
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- Spécifiez le nom de cap-controller-manager (par exemple, cap-controller-manager-1.28.0-gke.435) :
export CAP_DEPLOYMENT_NAME=
- Redémarrez le cap-controller-manager.
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| Mettre à niveau |
1.9.10 |
Symptômes :
La mise à niveau est bloquée à l'étape de vérification post-mise à niveau AdminClusterHealth.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
L'objet "organization" affiche les informations suivantes :
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
Solution :
Procédez comme suit :
Utilisez la commande suivante pour ignorer les vérifications préalables :
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| Mettre à niveau |
1.9.9 |
Symptômes :
Le NodeUpgradeTask peut avoir la condition failed to monitor failover registry recreation: failed to monitor job: job not complete qui empêche l'exécution d'une tâche.
Solution :
Pour résoudre le problème, redémarrez le job :
- Supprime le job nommé
create-failover-registry-*** dont l'état est "0/1".
- Supprimez l'annotation
failover-registry-creation-job-name de l'objet Server en cours de mise à niveau.
Le contrôleur recrée automatiquement le job.
|
| Mettre à niveau |
1.9.20 |
Symptômes :
Le nœud échoue au niveau du job backup-ipsec-for-upgrade-bm.
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
Solution :
Supprimez le job `backup-ipsec-for-upgrade-bm` et attendez qu'il soit recréé.
|
| Google Distributed Cloud |
1.9.9 |
Symptômes :
Un pool de nœuds du plan de contrôle n'est pas prêt en raison de l'échec du démarrage du cluster etcd. Vous pouvez rencontrer le problème suivant :
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
Solution :
Pour résoudre le problème, procédez comme suit :
- Vérifiez si la création du cluster est bloquée sur le job d'initialisation de la machine.
La tâche kubeadm join a échoué pour les raisons suivantes :
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
La tâche kubeadm reset a échoué pour les raisons suivantes :
panic: runtime error: invalid memory address or nil pointer dereference
- Utilisez SSH pour vous connecter à un nœud de panneau de configuration fonctionnel.
- Exécutez la commande
etcdctl pour nettoyer les données obsolètes.
- Vérifiez l'abonnement
etcd :
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- Supprimez l'abonnement obsolète :
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| Sauvegarde et restauration de VM |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
Symptômes :
Les utilisateurs ne peuvent pas démarrer le processus de sauvegarde et de restauration des VM en raison de paramètres de contrôle des accès basé sur les rôles (RBAC) et de schéma incorrects dans le gestionnaire de VM.
Les noms des plans de sauvegarde de VM ne peuvent pas comporter plus de 63 caractères.
Par exemple, le message d'erreur suivant peut s'afficher :
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog":
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s":
context deadline exceeded
Solution :
Les noms des plans de sauvegarde de VM sont une concaténation du nom VirtualMachineBackupPlanTemplate, du type de ressource (vm ou vm-disk) et du nom de cette ressource. Cette chaîne concaténée ne doit pas dépasser 63 caractères.
Pour ce faire, veillez à ce que les noms de ces ressources soient courts lorsque vous les créez. Pour en savoir plus sur la création de ces ressources, consultez Créer et démarrer une instance de VM et Créer un plan de sauvegarde pour les VM.
|
| Mettre à niveau |
1.9.9 |
Symptômes :
Une mise à niveau échoue à la tâche de sauvegarde ipsec avec l'erreur de modèle suivante :
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
Solution :
Procédez comme suit :
Connectez-vous au nœud sur lequel la tâche de mise à niveau échoue. Enregistrez le swanctl.conf en tant que sauvegarde. Supprimez la ligne avec des accolades dans le fichier /etc/swanctl/swanctl.conf. Supprimez le job backup-ipsec-for-upgrade en échec et attendez qu'il soit recréé. Le job suivant sera alors exécuté correctement. Ajoutez à nouveau la ligne supprimée à l'étape 3 dans /etc/swanctl/swanctl.conf.
|
| Plate-forme de nœud |
1.9.6
1.9.7
1.9.8
1.9.9 |
Lorsqu'une mise à niveau du micrologiciel démarre sur le cluster administrateur racine, une fois que l'un des nœuds a terminé la mise à niveau, il semble bloqué.
Symptômes :
- Le
nodeupgradetask est bloqué à l'étape NodeResumeCompleted.
- La tâche
machine-init échoue et le journal indique que kubeadm join a échoué.
- Vous ne pouvez pas établir de connexion SSH au nœud à l'aide de l'adresse IP du plan de données.
Le problème est dû au fait que le nœud mis à niveau n'accepte plus le trafic réseau entrant.
Solution :
- Examinez les journaux
job/nodeupgradetask en échec pour noter les adresses IP et identifier le nœud qui pose problème.
- Redémarrez le pod
anetd-client du nœud concerné.
- Vérifiez la connexion SSH sur l'adresse IP du plan de données au nœud concerné.
Étapes facultatives pour approfondir l'enquête :
- Accédez à un conteneur d'agent Cilium de l'un des pods anetd fonctionnels.
- Exécutez cilium-bugtool et attendez environ 10 secondes. L'outil enregistre les journaux dans le répertoire
/var/log/network/policy_action.log.
- Recherchez
deny pour voir si le trafic est refusé :
grep -r "deny" /var/log/network/ to
Notez les serveurs auxquels l'accès est refusé, peut-être les nœuds Bare Metal de l'administrateur racine.
|
| Mettre à niveau |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Symptômes :
- La mise à niveau du module complémentaire
atat-webhooks échoue.
- Les libellés de module complémentaire ATAT expirés peuvent entraîner l'échec des mises à niveau de l'organisation.
Exemple :
Invalid value: "TO1234": The current date 2024-05-06 is not within the valid range of this TaskOrder: 2023-12-16 - 2024-04-16.
Solution :
Les utilisateurs doivent mettre à jour les libellés de complément ATAT de leur portefeuille. Suivez le runbook ATAT-R0003 pour résoudre le problème.
|
| Mettre à niveau |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Symptômes :
- La mise à niveau de l'OS du nœud sur le locataire Bare Metal échoue lors de la mise à niveau de la version 1.9.12 vers la version 1.9.13. Le message suivant s'affiche :
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
Solution :
- Supprimez l'annotation
cluster.private.gdc.goog/ssh-trusted-ca-versions dans le CR du serveur de l'administrateur racine et de l'administrateur de l'organisation.
- Supprimez les tâches Ansible ayant échoué. De nouveaux jobs sont créés automatiquement, car l'annotation
cluster.private.gdc.goog/host-key-rotation-in-progress est définie sur "true" dans le CR du serveur.
- Une fois la rotation effectuée, les annotations
cluster.private.gdc.goog/ssh-trusted-ca-versions sont ajoutées à la réponse standardisée du serveur.
|
| Nœud, Mise à niveau |
1.9.* |
Symptômes :
Après la mise à niveau, les pods de certains nœuds Bare Metal sont bloqués à l'état CrashLoopBackOff et iptables -L -v -n | grep CILIUM sur le nœud renvoie un résultat vide.
Solution :
Pour résoudre ce problème, procédez comme suit :
- Exécutez la commande suivante :
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force.
- Exécutez à nouveau
iptables -L -v -n | grep CILIUM et vérifiez qu'il y a une sortie.
|
| Journalisation |
1.9.14
1.9.15 |
Symptômes :
Le pod audit-logs-loki-0 est à l'état CrashLoopBackOff.
Vérifiez l'état du pod :
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
où SYSTEM_KUBECONFIG est le chemin d'accès au fichier kubeconfig.
L'erreur Loki s'affiche dans le résultat suivant, où CrashLoopBackOff correspond à l'état :
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Solution :
Pour résoudre ce problème, procédez comme suit :
- Exportez le chemin d'accès au fichier kubeconfig vers une variable d'environnement appelée
SYSTEM_KUBECONFIG.
- Effectuez un scaling à la baisse de l'opérateur Logmon :
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Réduisez les ressources Loki :
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Supprimez les revendications de volume persistant (PVC)
audit-logs-loki-storage-audit-logs-loki-0 et loki-storage-loki-0.
- Supprimez les volumes persistants (PV)
obs-system/loki-storage-loki-0 et obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Effectuez un scaling à la hausse de l'opérateur Logmon :
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- Suivez les étapes pour mettre à jour la configuration de journalisation à partir de la version 1.9.
- Vérifiez que le pod
audit-logs-loki-0 est en cours d'exécution :
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
L'état Running doit s'afficher dans le résultat, comme dans l'exemple suivant :
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infrastructure as Code |
1.9.16 |
Symptômes :
L'installation du module complémentaire GitLab échoue lors de la mise à niveau vers la version 1.9.16. Vous pouvez rencontrer une erreur semblable à celle-ci :
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
Le pod postgres, tel que gpc-system/gitlab-postgresql-0, est en état d'arrêt.
Solution :
- Forcez la suppression du pod postgres bloqué dans un état d'arrêt :
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- Assurez-vous que le pod postgres est recréé après la suppression.
|
| Gestion de l'authentification et des accès |
1.9.19
1.9.20 |
Symptômes :
Lorsque vous effectuez une mise à niveau depuis la version 1.9.18 et que vous essayez d'accéder à la console GDC, le message suivant peut s'afficher :
Authentication failed, please contact your system administrator
Solution :
- Obtenez l'autorité de certification requise :
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- Ouvrez le fichier de configuration du client pour le modifier :
kubectl edit clientconfig -n kube-public default
- Localisez
certificateAuthorityData dans la configuration du client et mettez à jour l'autorité de certification requise en utilisant le chemin d'accès suivant : spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData.
|
