| Installazione |
1.9.0
1.9.1
1.9.2 |
A volte iLO non riesce a recuperare la chiave da HSM
Sintomi:
`server.status.conditions` ha una voce con tipo `KeyManagerConfigured` e stato `True`, ma nessuna con tipo `DiskEncryptionEnabled`. Esistono pod non riusciti denominati `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` con l'errore `"ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0`. Impossibile eseguire SSH nel pod a causa di una chiave non valida.
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
Vai a iLO UI > Information > Diagnostics > Reset per ripristinare iLO. Se durante il ripristino iLO mostra che il server è in fase di autotest all'accensione (POST), riavvia il flusso di provisioning:
Se l'installazione del cluster di amministrazione è stata completata:
export KUBECONFIG=<root-admin-kubeconfig path>
Aggiorna la chiave SSH:
Recupera la chiave SSH pubblica attuale (tieni presente che potrebbe essere stata ruotata e quindi diversa da /root/.ssh/id_rsa.pub
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
Inserisci la chiave pubblica nel ConfigMap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars
Aggiungi IRONIC_RAMDISK_SSH_KEY: \ Riavvia ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Esegui il provisioning della macchina per reinstallare IPA:
Esegui il backup di bmc-credential-$SERVER, poiché l'eliminazione di bmh comporta anche l'eliminazione del secret
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Rimuovi dal file gli attributi non applicabili, ad esempio: last-applied, creationtimestamp, finalizer, ownerreference, resourceversion, uid.
Elimina BareMetalHost:
kubectl -n gpc-system delete bmh/$SERVER
Prendi il file Secret bmc-credentials-$SERVER o il backup precedente da cellcfg e applicalo.
Chiedere al server di fare qualcosa di diverso.
Per rimuovere lo stato BMH memorizzato nella cache:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Attendi il provisioning del server. Guarda come vengono creati gli oggetti BMH. Potresti dover eliminare i job di crittografia per riattivarli.
|
| Operazioni |
1.9.0
1.9.1
1.9.2 |
Sintomi:
Lo stato della VM persiste con STATUS di Provisioning o Starting quando storageClassName è standard-block.
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
Verifica che la VM STATUS mostri Provisioning o Starting:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG è il percorso del file del cluster di sistema kubeconfig.
PROJECT è il progetto GDC in cui si trova la VM.
(Facoltativo) Ottieni ulteriori dettagli sullo stato:
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME è il nome della VM che non risponde.
Elimina la VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME è il nome del tuo spazio dei nomi.
Verifica che l'eliminazione sia andata a buon fine:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Un risultato simile al seguente conferma l'operazione:
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Elimina tutti i dischi della VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME Sostituisci il nome di ciascuno dei tuoi dischi con DISK_NAME_1 e DISK_NAME_2 fino a DISK_NAME_N e assicurati che tutti i dischi siano elencati. Verifica che l'eliminazione sia andata a buon fine:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
Un risultato simile al seguente conferma l'operazione:
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
Ricrea la VM e i dischi.
Riavvia la VM.
|
| Operazioni |
1.9.2 |
Sintomi:
gdcloud system container-registry load-oci non riesce a essere eseguito a causa di errori. Se esegui nuovamente il comando, viene eseguito per periodi di tempo diversi e non riesce in punti diversi del processo, ad esempio push o retag, ma con errori simili.
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
Esporta KUBECONFIG nel file kubeconfig dell'amministratore root:
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Esegui questo comando per ridurre lo scale down di
deployment/root-admin-tftp-manager-controller a 0 repliche:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- Esegui le operazioni non riuscite.
- Aumenta la scalabilità di
deployment/root-admin-tftp-manager-controller a 1 replica:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| Operazioni |
1.9.1
1.9.2
1.9.3 |
Sintomi:
gdcloud system container-registry load-oci non riesce a essere eseguito a causa di errori. Se esegui nuovamente il comando, viene eseguito per periodi di tempo diversi e non riesce in punti diversi del processo, ad esempio push o retag, ma con errori simili.
Soluzione temporanea:
Ignora pure il messaggio. Scompare dopo un po'.
|
| Operazioni |
1.9.2 |
Soluzione temporanea:
Per risolvere il problema, riavvia il pod interessato.
|
| Operazioni |
1.9.0
1.9.1
1.9.2 |
Sintomi:
Lo stato della condizione Server's Ready è "False" e il messaggio contiene "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...". I log del job non riuscito contengono "Failed to connect to the host via ssh ... Permission denied (publickey)."
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
Recupera la chiave SSH pubblica corrente dal cluster di amministrazione principale:
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dInserisci la chiave in configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars e aggiungi o sostituisci la chiave IRONIC_RAMDISK_SSH_KEY esistente:
<SSH public key>
Riavvia il deployment di Ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Per ogni server interessato:
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| Operazioni |
1.9.2 |
Soluzione temporanea:
Per evitare il problema di una carenza di indirizzi IP, imposta le dimensioni del CIDR dei pod su /21 o superiore quando crei un cluster utente ad alta disponibilità.
|
| Installazione |
1.9.2 |
Soluzione temporanea:
Per risolvere il problema, riavvia i pod.
Per maggiori dettagli, consulta il runbook MON-R0001.
|
| Autenticazione della piattaforma |
1.9.13 |
Sintomi:
Tutti i job cplb-init e storage-ipsec-config-bm-XXXXX mostrano il seguente messaggio: Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out.
Soluzione temporanea:
1. Controlla se bgp vrf non è disponibile su aggswitch.
2. Controlla se sono presenti modifiche non commit per la nuova configurazione di staging sul firewall.
3. Pulisci tutti i securitypolicyrules che avevano l'organizzazione eliminata nel nome e riavvia root-admin-controller.
|
| Esegui l'upgrade |
1.9.1
1.9.2
1.9.11 |
Sintomi:
Server ha .status.bareMetalHostStatus.provisionState bloccato a deprovisioning da più di 20 minuti.
L'indirizzo IP di gestione del server in fase di upgrade è incluso nell'output di uno qualsiasi di questi comandi:
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
Soluzione temporanea:
Per risolvere il problema, esegui:
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| Esegui l'upgrade |
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 |
Sintomi:
Un'attività di upgrade in NodeUpgrade rimane incompiuta per oltre 2 ore.
Un NodeUpgradeTask corrispondente rimane in attesa della condizione NodeResumeCompleted per più di un'ora.
bm-system-x.x.x.x-machine-init i job rimangono incompiuti per un lungo periodo di tempo. x.x.x.x è l'indirizzo del nodo.
Soluzione temporanea:
Per trovare l'indirizzo di un nodo non integro, consulta x.x.x.x del job bm-system-x.x.x.x-machine-init in attesa.
Per trovare un nodo del control plane integro per il nodo non integro, segui questi passaggi:
- Trova il nodepool del nodo non integro.
Controlla il pool di nodi del control plane nello stesso cluster del nodo non integro e seleziona un indirizzo da .spec.address di quel pool di nodi del control plane.
Su bootstrapper o OC IT, esegui:
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
All'interno del nodo del control plane integro, esegui:
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
|
| Esegui l'upgrade |
1.9.1
1.9.2 |
Sintomi:
Il pod ODS Fleet Operator è in crash loop.
Per controllare lo stato del pod, esegui:
ko get pods -n ods-fleet-operator
Nei log dell'operatore della flotta ODS viene visualizzato un errore di selezione del leader simile al seguente:
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"
Per controllare i log dell'operatore della flotta ODS, esegui:
ko logs deployment/fleet-controller-manager -n ods-fleet-system
Viene visualizzato il seguente messaggio:
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.
Soluzione temporanea:
Per modificare il deployment, esegui:
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
Assicurati di modificare il campo resources del container manager come segue:
Prima:
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
Dopo:
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| Esegui l'upgrade |
1.9.2
1.9.3 |
Sintomi:
Viene visualizzato il seguente messaggio di errore:
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
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
Accedi a tutti i nodi GPU di cui è stato eseguito il provisioning:
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
Rimuovi i vecchi pacchetti:
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) ...
Elimina il pod kubevm-gpu-driver-daemonset bloccato. L'installazione viene riavviata:
# kug get pods -A | grep gpu | grep Init
(Facoltativo) Se l'installazione del componente aggiuntivo è scaduta, riavviala:
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| Esegui l'upgrade |
1.9.10
1.9.11 |
Sintomi:
gpcbackup-agent-0 mostra failed to stage volume: iSCSI login failed e non esegue lo staging del volume.
Controlla se il pod non riesce ad associare il volume. Gli esempi seguenti utilizzano il file kubeconfig del cluster di sistema:
-
Descrivi il pod:
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Se il pod non funziona, viene visualizzato un output simile al seguente esempio:
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
-
Controlla il nodo per cui il pod non funziona:
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Ottieni un output simile al seguente esempio:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
Recupera il pod netapp-trident sullo stesso nodo per cui il pod gpcbackup-agent-0 non è riuscito:
kos get pod -o wide -n netapp-trident
Ottieni un output simile al seguente esempio:
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Controlla i log del pod netapp-trident sullo stesso nodo per cui il pod gpcbackup-agent-0 non è riuscito:
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Ottieni un output simile al seguente esempio:
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
Soluzione temporanea:
Per risolvere il problema, procedi nel seguente modo:
-
Recupera il nome di InventoryMachine:
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Conferma che il job precedente esista:
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}"
Ottieni un output simile al seguente:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
Elimina il job:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Ottieni un output simile al seguente:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Verifica che StorageEncryptionConnection esista:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Ottieni un output simile al seguente:
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
-
Elimina StorageEncryptionConnection:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Ottieni un output simile al seguente:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Riavvia il 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
-
Verifica che il nuovo job sia stato ricreato ed eseguito correttamente:
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
Ottieni un output simile al seguente:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| Esegui l'upgrade |
1.9.10
1.9.11 |
Sintomi:
Un pod del registro Harbor mostra un messaggio di errore simile al seguente:
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
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
-
Controlla la richiesta di volume permanente (PVC) del registro Harbor e annota il nome del volume PVC:
kubectl get pvc harbor-registry -n harbor-system
-
Per verificare se l'allegato del volume si trova nello stesso nodo del pod del registro Harbor, elenca i volumeattachment e trova quello associato al nome del volume:
kubectl get volumeattachment | grep [volume-name]
-
Se l'allegato del volume si trova in un nodo diverso dal pod del registro Harbor, rimuovi volumeattachment:
kubectl delete volumeattachment [volumeattachment-name]
-
Riavvia il pod del registro Harbor.
Ora, il registro Harbor nel cluster di amministrazione principale deve essere integro e l'upgrade dei nodi viene completato correttamente.
|
| Installazione |
1.9.2
1.9.3
1.9.4
1.9.5
|
Sintomi:
Viene visualizzato il seguente messaggio di errore:
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Un log dei pod contiene quanto segue:
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
La versione di CoreDNS è 1.8.6.
Soluzione temporanea:
Per risolvere il problema, riavvia il deployment di coredns.
Una volta impostato KUBECONFIG per il cluster corretto, esegui:
kubectl rollout restart deployment coredns -n kube-system
Il nome del cluster di utenti fa parte del messaggio di errore.
Per trovare il file kubeconfig in /root/release/user/, individua i kubeconfig: org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
Se mancano i file kubeconfig, generali come segue:
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
|
| Esegui l'upgrade |
1.9.2
1.9.3 |
Sintomi:
Viene visualizzato il seguente messaggio di errore:
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]]
Questo problema è in genere temporaneo e dovrebbe risolversi.
|
| Installazione |
1.9.3 |
L'installazione di un componente aggiuntivo non riesce e viene visualizzato il seguente errore:
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.
Soluzione temporanea:
L'installazione del componente aggiuntivo potrebbe non riuscire perché i nodi si trovano nello stato NotReady. Controlla se i nodi sono nello stato NotReady utilizzando:
kubectl get nodes
Visualizza i dettagli del nodo nello stato NotReady:
$ kubectl describe node | grep PodCIDRs
Per un cluster con questo problema, a un nodo non sono assegnati PodCIDR, ad esempio:
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
Per risolvere il problema, riavvia il deployment di ipam-controller nel cluster interessato:
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| Esegui l'upgrade |
1.9.3 |
Un upgrade non riesce e viene visualizzato il seguente errore:
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.
Soluzione temporanea:
Aggiorna manualmente il campo <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> di AddOnSet abm-overrides con il nome di AddOnSetTemplate della versione desiderata nello stesso spazio dei nomi del cluster in fase di upgrade.</code.spec.addonsettemplateref<>
|
| Installazione |
1.9.3 |
Sintomi:
Un controller di amministrazione della flotta non diventa pronto perché il test TestCreateFleetAdminCluster o TestSimOverlayCreateFleetAdminCluster non va a buon fine. Il controller dell'amministratore del parco risorse è bloccato in un loop di arresto anomalo. Il seguente errore si trova nei log del controller di amministrazione del parco dispositivi: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Soluzione temporanea:
Esegui il deployment della CRD Logmon nel cluster di amministrazione dell'organizzazione. Riavvia il controller di amministrazione della flotta.
|
| Installazione |
1.9.3 |
Sintomi:
Viene visualizzato il seguente messaggio di errore:
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] [...]
Soluzione temporanea:
Per risolvere il problema, riavvia sia il deployment che il daemonset nel cluster:
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
Nota:esegui il seguente comando prima di riavviare il deployment e il daemonset per indirizzare il cluster corretto:
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| Esegui l'upgrade |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
Sintomi:
Un pod non può essere pianificato a causa di una CPU insufficiente.
Soluzione temporanea:
Per un cluster utente esistente creato con nodi worker n2-standard-4, aggiungi un nuovo NodePool n2-standard-8 con tre nodi a questo cluster prima di eseguire l'upgrade. Per i nuovi cluster utente, crea un n2-standard-8 NodePool con un minimo di tre nodi. Per maggiori dettagli, vedi Creare un cluster utente per i carichi di lavoro dei container.
|
| Operazioni |
1.9.0
1.9.2
1.9.3
1.9.4 |
Sintomi:
L'istanza VM PHASE mostra Scheduling e READY
rimane False, senza mai raggiungere lo stato True. Questo
interessa due tipi di macchine, come elencato per la soluzione alternativa. Gli altri tipi di macchina
non sono interessati e non richiedono l'applicazione di una soluzione alternativa.
Soluzione temporanea:
- Quando crei cluster utente che utilizzano GPU A100 40G, seleziona sempre il tipo di macchina a2-highgpu-1g-gdc dalla UI.
- Quando crei cluster utente che utilizzano GPU A100 80G, seleziona sempre il tipo di macchina a2-ultragpu-1g-gdc dalla UI.
|
| Operazioni |
1.9.0
1.9.2
1.9.3
1.9.4 |
Sintomi:
Per i pool di nodi con istanze VM con dimensioni della memoria superiori a 32 GB,
l'istanza VM può sembrare in esecuzione, poi arrestarsi e riavviarsi, ripetendo
possibilmente questa sequenza. Alla fine, viene generato un errore di esaurimento della memoria OOMKilled e l'istanza non funziona.
Questi sono i tre tipi di VM interessati:
- n2-highmem-8-gdc: 64 GB di memoria
- a2-highgpu-1g-gdc: 85 GB di memoria
- a2-ultragpu-1g-gdc: 170 GB di memoria
Soluzione temporanea:
- Verifica il tipo di macchina:
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- Cerca il tipo di VM in
spec.compute.virtualMachineTypeName nell'output.
- Se il tipo di VM è uno dei tre tipi elencati
modifica
configmap per includere un override della memoria:
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- Aggiungi una sezione
memory.guest e resources.overcommitGuestOverhead
come mostrato nell'esempio seguente:
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- In
memory modifica guest in modo che abbia i seguenti valori:
- Per n2-highmem-8-gdc, imposta MEMORY_SIZE
63.6G.
- Per a2-highgpu-1g-gdc, imposta MEMORY_SIZE
84G.
- Per a2-ultragpu-1g-gdc, crea MEMORY_SIZE
168G.
- Ripeti questa operazione per tutte le VM interessate.
|
| Esegui l'upgrade |
1.9.4 |
Sintomi:
Un job bm-system-* si blocca al passaggio Gathering Facts. Quando tenti di accedere manualmente al server tramite SSH, viene visualizzato PTY allocation request failed on channel 0.
Soluzione temporanea:
Riavvia il server utilizzando uno dei seguenti metodi:
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
Interfaccia utente iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Esegui l'upgrade |
1.9.4
1.9.10 |
Sintomi:
Un upgrade non riesce a causa dell'errore del job backup-ipsec-*.
Soluzione temporanea:
Segui questi passaggi:
Trova le chiavi precondivise nello spazio dei nomi gpc-system nel cluster di amministrazione dell'organizzazione. Le chiavi sono denominate <node-name>-pre-shared-key.
Per ottenere l'hash della chiave dal file YAML pre-shared-key di un nodo funzionante, utilizza 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 }'.
Tieni presente che devi ottenere l'hash della chiave da un nodo diverso da quello in cui l'upgrade di IPsec non è riuscito. Applica l'hash di questa chiave precondivisa al secret della chiave precondivisa del nodo non funzionante in gpc-system nel cluster di amministrazione dell'organizzazione. Elimina l'oggetto storageencryptionconnection che ha lo stesso nome del nodo non riuscito nel cluster di amministrazione principale. Elimina il job storage-ipsec-config-<node-name> associato nel cluster di amministrazione dell'organizzazione. Elimina il job di upgrade backup-ipsec-for-upgrade-<node-name> associato.
|
| Esegui l'upgrade |
1.9.4 |
Sintomi:
L'upgrade dei cluster dell'organizzazione richiede molto tempo.
Soluzione temporanea:
Attendi l'arresto naturale di clamav.
|
| Esegui l'upgrade |
1.9.5 |
Sintomi:
Vengono visualizzati diversi certificati:
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-----
Soluzione temporanea:
Nota: ruota il certificato harbor-harbor-https prima di eseguire i passaggi successivi.
Segui questi passaggi:
Nel cluster sono memorizzate copie dei dati del certificato nei secret. Dopo aver ruotato il certificato harbor-harbor-https, devi aggiornare anche le copie del secret.
- Recupera l'URL di Artifact Registry.
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- Aggiorna le copie del secret del certificato Artifact Registry in ogni spazio dei nomi.
Recupera tutti gli spazi dei nomi che archiviano una copia del secret del certificato 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,\" \"")
Aggiorna la copia del secret del certificato Artifact Registry in ogni spazio dei nomi.
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
- Per il cluster root-admin, devi anche aggiornare una correzione denominata copia segreta del certificato chiamata
ca-cert-in-cluster-registry nello spazio dei nomi 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}\"}}"
- Aggiorna
registry-cert memorizzato nello spazio dei nomi 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}\"}}"
- Se ruoti i certificati per il cluster org-admin, devi anche aggiornare le copie segrete dei certificati esistenti nel cluster root-admin.
Recupera tutti gli spazi dei nomi che archiviano una copia del secret del certificato 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,\" \"")
Aggiorna la copia del secret del certificato Artifact Registry in ogni spazio dei nomi.
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 .
|
| Esegui l'upgrade |
1.10.0
1.10.1 |
Sintomi:
Dopo aver avviato un OrganizationUpgrade, il
pod kube-apiserver non è in esecuzione su uno o più nodi.
- Identifica il nodo in cui l'upgrade è bloccato:
kubectl get po -n kube-system -l component=kube-apiserver
L'output ha il seguente aspetto:
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
- Stabilisci una connessione SSH al nodo appena aggiornato:
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
Viene visualizzato lo stato del container come Exited:
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- Controlla i log del pod
Exited:
crictl logs f1771b8aad929
L'output ha il seguente aspetto:
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
Il flag è configurato nel file /etc/kubernetes/manifests/kube-apiserver.yaml:
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
Soluzione temporanea:
Rimuovi il flag dal file /etc/kubernetes/manifests/kube-apiserver.yaml.
- Esegui il backup del file:
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- Rimuovi la linea:
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- Conferma che la linea è stata rimossa:
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Elenca il container
kube-apiserver:
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet rileva automaticamente la modifica e avvia il
pod kube-apiserver:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Ripeti questi passaggi per tutti i nodi interessati.
|
| Esegui l'upgrade |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Sintomi:
Il ciclo di arresti anomali del deployment di kube-state-metrics in un'organizzazione dopo la rotazione dei certificati. Questo problema potrebbe causare una perdita di
dati di monitoraggio.
|
| Esegui l'upgrade |
1.9.6 |
Sintomi:
Dopo l'upgrade, il nodo di lavoro non è bilanciato.
Soluzione temporanea:
Bilancia manualmente il nodo worker:
- Per un workload pod, elimina i pod nel deployment.
- Per un carico di lavoro VM, elimina virt-launcher senza modificare l'oggetto GVM del piano di controllo.
|
| Esegui l'upgrade |
1.9.6 |
Quando esegui l'upgrade dalla versione 1.9.5 alla 1.9.6, è possibile che il plug-in
del dispositivo GPU non possa essere avviato.
Sintomi:
Potresti visualizzare il seguente errore che blocca la preparazione del runtime della VM
e il processo di upgrade:
Failed to initialize NVML: could not load NVML library
Soluzione temporanea:
- Controlla se
nvidia-container-runtime è configurato correttamente sul nodo:
- Stabilisci una connessione SSH al nodo che sospetti abbia un problema.
- Recupera l'elenco dei pod:
crictl pods
- Esamina i pod:
crictl inspectp $pod_hash | grep runtimeOption -A1
Se l'output è simile a questo, il nodo è configurato correttamente. Se l'output non è simile a questo, nvidia-container-runtime non è configurato sul nodo:
binary_name": "/usr/bin/nvidia-container-runtime"
- Se
nvidia-container-runtime non è configurato
correttamente, riavvia containerd per risolvere il problema:
systemctl restart containerd
|
| Esegui l'upgrade |
1.9.7 |
Quando esegui l'upgrade alla versione 1.9.7, il firmware pool di nodi del cluster di amministrazione principale rimane nello stato in process.
Sintomi:
- Per la parte
NodeUpgrade, consulta la soluzione alternativa Timeout del server degli artefatti:
NodeUpgrade è bloccato nello stato in process e la condizione per NodeROMFirmwareUpgradeCompleted nello stato Nodeupgradetask non viene mai completata.- L'URL in
spec.firmware.firmwarePackages.url nell'oggetto NodeUpgrade potrebbe bloccarsi quando viene connesso, ad esempio:
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- Per la parte
Harbor, consulta la soluzione alternativa Server artefatti non autorizzato:
- Nel log del server degli artefatti potrebbe essere visualizzato un errore relativo all'accesso non autorizzato a un repository:
gdch-hpe-firmware/ilo, ad esempio:
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
- Nel progetto Harbor,
gdch-hpe-firmware deve avere Spec.harborProjectConfig.accessLevel come private:
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
Soluzione temporanea:
|
| Networking inferiore |
1.9.0 - 1.9.6 |
Sintomi:
Le sessioni BGP non sono attive nella rete interna di un'organizzazione. Solo uno degli endpoint di peering BGP interni dell'organizzazione viene aggiunto a TORSwitchInternal Objects.
Soluzione temporanea:
Modifica in modo esplicito la subnet utilizzata in {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim in modo che non si sovrapponga a nessuna altra risorsa AddressPoolClaim analoga dell'organizzazione.
- Esamina i sintomi:
- Per ogni cluster di sistemi dell'organizzazione, esegui:
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- Controlla il campo
State di ogni oggetto BGPSession per State di NotEstablished. Prendi nota del LocalIP di ogni NotEstablished BGPSession associato per utilizzarlo in un secondo momento.
- Determina se
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" è la causa principale:
- Per ogni organizzazione attiva, esegui:
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- Cerca nel campo
ClusterIP (terza colonna) dell'output il valore LocalIPs annotato nel passaggio 1.b. Annota gli LocalIP che corrispondono alle voci della terza colonna dell'output per un utilizzo successivo. Se sono presenti più cluster di amministratori dell'organizzazione distinti, in cui l'output del passaggio 2.a contiene i LocalIP indicati nel passaggio 1.b, procedi al passaggio 3.
- Risolvi gli IP sovrapposti utilizzati per i cluster di sistema dell'organizzazione.
- Esegui:
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- Annota il numero di oggetti
SubnetClaim restituiti dalla query nel passaggio 3.a. Deve essere uguale al numero di organizzazioni attive.
- Per ogni riga, annota lo spazio dei nomi (colonna 1) e il blocco CIDR (colonna 3). Il blocco CIDR di ogni riga deve essere uguale a quello di tutte le altre righe.
- Per ogni organizzazione, esegui i seguenti passaggi:
- Vai all'oggetto
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim nel cluster di amministrazione dell'organizzazione.
- Calcola il
Start IP della richiesta del pool di indirizzi dei nodi worker dell'organizzazione. Per farlo, prendi il blocco CIDR dal punto 3.c e il campo Size in AddressPoolClaim dal punto 3.d.i. A partire dal penultimo IP nel blocco CIDR, esegui il conto alla rovescia di Size IP. Questo è il nuovo Start IP per la prima organizzazione (utilizzato nel passaggio 3.d.iii). Per ogni organizzazione aggiuntiva, esegui il conto alla rovescia di Size IP secondi, a partire dal nuovo Start IP dell'organizzazione precedente.
Ad esempio:
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
- Nel campo
AddressPoolClaim del passaggio 3.c.i, aggiungi il seguente campo nel campo Spec:
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
Utilizza questo comando:
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
Il risultato deve essere simile al seguente se utilizzi org-1 del punto 3.d.ii, ad esempio:
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: ...
...
- Esegui la pulizia per evitare sessioni BGP non necessarie sull'hardware TORSwitch.
- Per elencare tutte le risorse
TORSwitchInternal che devono essere aggiornate, esegui:
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Per ciascuno dei
TORSwitchInternals elencati nell'output del comando precedente, esegui questo comando:
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- Per tutti gli oggetti
TORSwitchInternal, rimuovi tutte le voci dall'elenco .spec.ebgpNeighbors che hanno NeighborIP uguali a uno qualsiasi dei LocalIP del passaggio 2.b. Ad esempio, LocalIP di 2.2.2.2 è stato annotato nel passaggio 2.b. Di seguito è riportato un esempio di TORSwitchInternal prima e dopo il passaggio di pulizia.
Prima della pulizia:
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:
...
Dopo la pulizia. Prendi nota della voce ebgpNeighbor rimossa:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- Esegui la convalida eseguendo il passaggio 1 e verificando che tutti gli
BGPSession oggetti States siano tornati a Established. Potrebbero essere necessari circa 10 minuti prima che tutte le modifiche vengano propagate alle configurazioni TORSwitch GDC fisiche.
|
| Esegui l'upgrade |
1.9.7 - 1.9.21 |
Durante un upgrade, è possibile che l'upgrade del nodo e del sistema operativo non progredisca.
Sintomi:
Potresti vedere un nodo con lo stato Ready, SchedulingDisabled per alcune ore.
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
Soluzione temporanea:
- Segui il runbook PLATAUTH-SSH 0001 per ottenere la chiave SSH per il nodo in questione. Dopo aver eseguito la connessione al nodo con SSH, esegui il seguente comando:
multipath -ll | grep fail
- Procedi al passaggio successivo solo se l'output è simile al seguente:
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
- Esegui il comando seguente per risolvere il problema:
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| Esegui l'upgrade |
1.9.8-1.9.21 |
Sintomi:
Se l'upgrade di un cluster ABM è bloccato per più di 2 ore, lo svuotamento dei nodi potrebbe essere bloccato.
Soluzione temporanea:
Le seguenti operazioni utilizzano il cluster di amministrazione principale come esempio. ${TARGET_KUBECONFIG} si riferisce al file kubeconfig per il cluster ABM di destinazione il cui svuotamento dei nodi è bloccato, ${KUBECONFIG} si riferisce al file kubeconfig per il cluster che gestisce il cluster ABM di destinazione. Per il cluster di amministrazione principale, entrambi fanno riferimento al file kubeconfig dell'amministratore principale.
Completa i seguenti passaggi per verificare se l'upgrade del cluster ABM è bloccato:
- Controlla i nodi bloccati durante lo svuotamento:
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
Il risultato è simile al seguente:
{"10.200.0.2": 2}
Ciò significa che per il nodo "10.200.0.2" vengono svuotati due pod.
- Controlla se i pod vengono ancora scaricati dal nodo (indicato come
${NODE_BEING_DRAINED}):
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
Il numero di pod di output deve essere uguale al numero di pod in fase di svuotamento segnalato nel passaggio precedente.
Per ogni pod yetToDrain elencato nel passaggio 1, controlla lo stato del pod:
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Se il pod è nello stato Running o se è audit-logs-loki-0 o loki-0 nello spazio dei nomi obs-system e non ha alcun evento che segnala unable to unmount volume, elimina esplicitamente il pod con un grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- Per tutti gli altri casi in cui un pod è bloccato in fase di scaricamento, esegui il riassegnamento ai servizi di reperibilità.
- Verifica che lo svuotamento del nodo sia completato.
- Ripeti il passaggio 1 se altri nodi sono bloccati nello svuotamento.
|
| Esegui l'upgrade |
1.9.6
1.9.7
1.9.8
|
Le release 1.9 con artefatti firmati non possono essere distribuite perché
il flag Override in DistributionPolicy è impostato
su false, il che impedisce la distribuzione quando è presente un
artefatto con lo stesso nome nel registro di destinazione.
Sintomi:
Potresti riscontrare i seguenti problemi:
- L'artefatto con la firma viene eseguito il push. Il log potrebbe avere il seguente aspetto:
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Impossibile eseguire il push dell'artefatto. Il log potrebbe avere il seguente aspetto:
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- L'artefatto 404 non è stato trovato. Il log potrebbe avere il seguente aspetto:
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- La distribuzione degli artefatti non riesce.
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
- Aggiorna la risorsa personalizzata (CR)
DistributionPolicy per
impostare Spec.Override su true.
- Attiva di nuovo una replica seguendo il runbook SAR-1005.
- Dopo che la nuova esecuzione della replica è andata a buon fine, aggiorna il
ManualDistribution CR execution-ids in
Annotation con l'ID di esecuzione riuscita.
|
| Modulo di sicurezza hardware (HSM) |
1.9.9 |
Gli HSM potrebbero segnalare in modo intermittente ServicesNotStarted, il che
può impedire ai server bare metal di diventare integri e segnalare il seguente
messaggio:
"message": "failed to get master key name"
Sintomi:
Potresti riscontrare i seguenti problemi:
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi per riavviare gli HSM bloccati:
- Installa lo strumento
kstl dal primo HSM eseguendo i seguenti comandi:
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
- Verifica che l'HSM abbia problemi di riavvio. Per ogni HSM bloccato
su
ServicesNotStarted, recupera
$HSM_MGMT_IP e verifica che il servizio non sia disponibile:
ksctl services status --url=https://$HSM_MGMT_IP
- Metti in pausa tutti gli HSM, i cluster HSM e i tenant 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
- Stabilisci una connessione SSH all'HSM con il servizio inattivo:
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Assicurati di trovarti nell'HSM corretto. Verifica di aver stabilito una connessione SSH con il
$HSM_MGMT_IP corretto.
- Riavvia il primo HSM dall'interno dell'HSM:
ksadmin@ciphertrust:~ sudo reboot
- Attendi che il primo HSM diventi integro dall'esterno dell'HSM:
watch -c ksctl services status --url=https://$HSM_MGMT_IP
Il riavvio degli HSM potrebbe richiedere circa cinque minuti.
- Ripeti questi passaggi per gli altri HSM i cui servizi non funzionano.
- Riattiva le pause per gli HSM, i cluster HSM e i tenant 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-
- Verifica che tutto sia riconciliato. Potrebbero essere necessari da 5 a 10 minuti
per la riconciliazione degli HSM.
|
| Monitoraggio |
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 |
Sintomi:
Gli avvisi alertmanager-servicenow-webhook non raggiungono ServiceNow nel cluster di sistema dell'organizzazione per le versioni di GDC precedenti alla 1.11.3. I log contengono il messaggio di errore read: connection reset by peer. Questo problema è dovuto a un'etichetta mancante per attivare il traffico in uscita. Se il webhook deve comunicare tra organizzazioni, deve utilizzare NAT in uscita.
Soluzione temporanea:
Devi abilitare il traffico in uscita per alertmanager-servicenow-webhook nei cluster di sistema dell'organizzazione. Per risolvere il problema, segui questi passaggi:
- Imposta i prerequisiti richiesti:
- Installa l'interfaccia a riga di comando (CLI) gcloud.
- Ottieni i percorsi dei file kubeconfig dei cluster di amministrazione principale e di amministrazione dell'organizzazione. Salva i percorsi rispettivamente nelle variabili di ambiente
ROOT_KUBECONFIG e ORG_SYSTEM_KUBECONFIG.
- Chiedi all'Amministratore sicurezza di concederti il ruolo Amministratore dell'osservabilità (
observability-admin) nello spazio dei nomi obs-system per i cluster di amministrazione radice e di amministrazione dell'organizzazione.
- Verifica che il problema esista nel tuo ambiente:
- Ottieni il deployment di
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- Visualizza i log del deployment di
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
Se i log contengono il messaggio di errore read: connection reset by peer, il problema esiste e devi continuare con i passaggi di questa soluzione alternativa.
- Aggiungi l'etichetta di uscita:
- Recupera il file YAML di deployment
alertmanager-servicenow-webhook corrente:
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
- Aggiungi l'etichetta di uscita al file YAML di deployment
alertmanager-servicenow-webhook:
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Sostituisci il file YAML di deployment
alertmanager-servicenow-webhook con gli aggiornamenti:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
Il deployment deve riavviarsi automaticamente.
- Verifica che il problema sia stato risolto eseguendo di nuovo i passaggi descritti in Conferma che il problema esiste nel tuo ambiente. Il messaggio di errore dei log non deve essere visualizzato. In caso contrario, esegui l'escalation ai tecnici.
Strategia di rollback:
Se i passaggi della soluzione alternativa non vanno a buon fine o se noti una perdita di metriche, ripristina lo stato originale del file YAML di deployment alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| Esegui l'upgrade |
1.9.10 |
Sintomi:
L'upgrade è bloccato al passaggio 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
nodeupgradetask per il pool di nodi in corso mostra:
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
Soluzione temporanea:
Segui questi passaggi:
- Recupera il nome del deployment di 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
- Specifica il nome di cap-controller-manager (ad esempio: cap-controller-manager-1.28.0-gke.435):
export CAP_DEPLOYMENT_NAME=
- Riavvia 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
|
| Esegui l'upgrade |
1.9.10 |
Sintomi:
L'upgrade è bloccato al passaggio di controllo post-volo AdminClusterHealth.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
L'oggetto organizzazione mostra:
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
Soluzione temporanea:
Segui questi passaggi:
Utilizza il seguente comando per ignorare i controlli preliminari:
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| Esegui l'upgrade |
1.9.9 |
Sintomi:
Il NodeUpgradeTask potrebbe avere la condizione failed to monitor failover registry recreation: failed to monitor job: job not complete che blocca il completamento di un'attività.
Soluzione temporanea:
Per risolvere il problema, riavvia il job:
- Elimina il job denominato
create-failover-registry-*** con completamento "0/1".
- Elimina l'annotazione
failover-registry-creation-job-name dall'oggetto Server di cui viene eseguito l'upgrade.
Il controller crea di nuovo automaticamente il job.
|
| Esegui l'upgrade |
1.9.20 |
Sintomi:
Il nodo non riesce a eseguire il 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
"
Soluzione temporanea:
Elimina il job `backup-ipsec-for-upgrade-bm` e attendi che venga ricreato.
|
| Google Distributed Cloud |
1.9.9 |
Sintomi:
Un pool di nodi del control plane non è pronto a causa dell'impossibilità di avviare il cluster etcd. Potresti riscontrare il seguente problema:
--- 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
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
- Controlla se la creazione del cluster è bloccata nel job di inizializzazione della macchina.
L'attività kubeadm join non è riuscita a causa di:
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
L'attività kubeadm reset non è riuscita a causa di:
panic: runtime error: invalid memory address or nil pointer dereference
- Utilizza SSH per connetterti a un nodo del pannello di controllo funzionante.
- Esegui il comando
etcdctl per pulire i dati obsoleti.
- Controlla l'abbonamento a
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
- Rimuovi l'abbonamento obsoleto:
# 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
|
| Backup e ripristino delle 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 |
Sintomi:
Il processo di backup e ripristino della VM non può essere avviato dagli utenti a causa di impostazioni di controllo dell'accesso basato sui ruoli (RBAC) e dello schema improprie nel gestore VM.
I nomi dei piani di backup delle VM non possono contenere più di 63 caratteri.
Ad esempio, potresti visualizzare questo messaggio di errore:
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
Soluzione temporanea:
I nomi dei piani di backup delle VM sono una concatenazione del nome VirtualMachineBackupPlanTemplate, del tipo di risorsa (vm o vm-disk) e del nome della risorsa. Questa stringa concatenata deve contenere meno di 63 caratteri.
Per farlo, mantieni brevi i nomi di queste risorse quando le crei. Per informazioni dettagliate sulla creazione di queste risorse, consulta Crea e avvia un'istanza VM e Crea un piano di backup per le VM.
|
| Esegui l'upgrade |
1.9.9 |
Sintomi:
Un upgrade non riesce a eseguire il job di backup ipsec con il seguente errore di modello:
"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
Soluzione temporanea:
Segui questi passaggi:
Accedi al nodo in cui l'attività di upgrade non è riuscita. Salva swanctl.conf come backup. Rimuovi la riga con le parentesi graffe nel file /etc/swanctl/swanctl.conf. Elimina il job backup-ipsec-for-upgrade non riuscito, attendi che venga ricreato e poi il job successivo viene completato correttamente. Aggiungi di nuovo la riga rimossa nel passaggio 3 a /etc/swanctl/swanctl.conf.
|
| Piattaforma del nodo |
1.9.6
1.9.7
1.9.8
1.9.9 |
Quando viene avviato un upgrade del firmware sul cluster di amministrazione principale, dopo che uno dei nodi ha completato l'upgrade, sembra bloccato.
Sintomi:
nodeupgradetask è bloccato alla fase
NodeResumeCompleted.- Il job
machine-init non viene completato e il log mostra che
kubeadm join non è riuscito.
- Non puoi stabilire una connessione SSH al nodo utilizzando l'indirizzo IP del piano dati.
Il problema è causato dal nodo aggiornato che non accetta più il traffico
di rete in entrata.
Soluzione temporanea:
- Controlla i log
job/nodeupgradetask non riusciti per annotare gli
indirizzi IP e scoprire quale nodo presenta il problema.
- Riavvia il pod
anetd-client del nodo interessato.
- Verifica la connessione SSH sull'IP del piano dati al nodo interessato.
Passaggi facoltativi per ulteriori indagini:
- Accedi a un container dell'agente Cilium di uno qualsiasi dei pod anetd funzionanti.
- Esegui il comando cilium-bugtool e attendi circa 10 secondi. Lo strumento salva
i log nella directory
/var/log/network/policy_action.log.
- Cerca
deny per vedere se il traffico viene negato:
grep -r "deny" /var/log/network/ to
Prendi nota dei server a cui viene negato l'accesso, possibilmente i nodi bare metal dell'amministratore root.
|
| Esegui l'upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Sintomi:
- Un upgrade non riesce sul componente aggiuntivo
atat-webhooks.
- Le etichette dei componenti aggiuntivi ATAT scaduti potrebbero causare errori negli upgrade dell'organizzazione.
Ad esempio:
Invalid value: "TO1234": The current date 2024-05-06 is not within the valid range of this TaskOrder: 2023-12-16 - 2024-04-16.
Soluzione temporanea:
Gli utenti devono aggiornare le etichette dei componenti aggiuntivi ATAT del proprio portfolio. Segui il runbook ATAT-R0003 per risolvere il problema.
|
| Esegui l'upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Sintomi:
- L'upgrade del sistema operativo del nodo su Bare Metal dell'organizzazione tenant non riesce durante l'upgrade dalla versione 1.9.12 alla 1.9.13. Viene visualizzato il seguente messaggio:
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"
}
} ]
Soluzione temporanea:
- Rimuovi l'annotazione
cluster.private.gdc.goog/ssh-trusted-ca-versions nel CR del server dell'amministratore root e dell'amministratore dell'organizzazione.
- Elimina i job Ansible non riusciti. I nuovi job vengono creati automaticamente perché l'annotazione
cluster.private.gdc.goog/host-key-rotation-in-progress
è contrassegnata come true nel CR del server.
- Dopo la rotazione, l'annotazione
cluster.private.gdc.goog/ssh-trusted-ca-versions viene nuovamente aggiunta al CR del server.
|
| Nodo, Esegui l'upgrade |
1.9.* |
Sintomi:
Dopo l'upgrade, i pod su alcuni nodi bare metal sono bloccati nello stato CrashLoopBackOff e
iptables -L -v -n | grep CILIUM sul nodo restituisce un risultato vuoto.
Soluzione temporanea:
Per risolvere il problema, completa i seguenti passaggi:
- Esegui questo comando:
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force.
- Esegui di nuovo
iptables -L -v -n | grep CILIUM e verifica che sia presente un output.
|
| Logging |
1.9.14
1.9.15 |
Sintomi:
Il pod audit-logs-loki-0 è nello stato CrashLoopBackOff.
Verifica lo stato del pod:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
dove SYSTEM_KUBECONFIG è il percorso del file kubeconfig.
L'errore Loki viene visualizzato nell'output seguente, dove CrashLoopBackOff è lo stato:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Soluzione temporanea:
Per risolvere il problema, completa i seguenti passaggi:
- Esporta il percorso del file kubeconfig in una variabile di ambiente denominata
SYSTEM_KUBECONFIG.
- Riduci le dimensioni dell'operatore Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Ridimensiona le risorse Loki:
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Elimina le richieste di volumi permanenti (PVC)
audit-logs-loki-storage-audit-logs-loki-0 e loki-storage-loki-0.
- Elimina i volumi permanenti (PV)
obs-system/loki-storage-loki-0 e obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Fai lo scale up dell'operatore Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- Segui i passaggi per aggiornare la configurazione di logging dalla versione 1.9.
- Verifica che il pod
audit-logs-loki-0 sia in esecuzione:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Lo stato Running deve essere visualizzato nell'output come nell'esempio seguente:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infrastructure as Code (IaC) |
1.9.16 |
Sintomi:
L'installazione del componente aggiuntivo Gitlab non riesce durante l'upgrade alla versione 1.9.16. Potresti
visualizzare un errore simile a questo:
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
Il pod postgres, ad esempio gpc-system/gitlab-postgresql-0,
è in stato di terminazione.
Soluzione temporanea:
- Elimina forzatamente il pod postgres bloccato nello stato di terminazione:
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- Assicurati che il pod postgres venga ricreato dopo l'eliminazione.
|
| Gestione di identità e accessi |
1.9.19
1.9.20 |
Sintomi:
Quando esegui l'upgrade dalla versione 1.9.18 e provi ad accedere alla
console GDC, potresti visualizzare il seguente messaggio:
Authentication failed, please contact your system administrator
Soluzione temporanea:
- Ottieni la CA richiesta:
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- Apri il file di configurazione del client per modificarlo:
kubectl edit clientconfig -n kube-public default
- Individua
certificateAuthorityData nella configurazione del client e aggiorna la CA richiesta utilizzando il seguente percorso: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
