Problemas conocidos de Google Distributed Cloud con air gap 1.9.x

Categoría	Versión(es) identificada(s)	Problema y solución alternativa
Instalación	1.9.0 1.9.1 1.9.2	En ocasiones, iLO no puede obtener la clave del HSM Síntomas: `server.status.conditions` tiene una entrada con el tipo `KeyManagerConfigured` y el estado `True`, pero ninguna con el tipo `DiskEncryptionEnabled`. Hay pods fallidos llamados `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` con el error `"ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0"`. No se puede acceder al pod mediante SSH debido a una clave no válida. Solución alternativa: Para solucionar el problema, sigue estos pasos: Ve a la interfaz de usuario de iLO > Información > Diagnóstico > Restablecer para restablecer iLO. Si, durante el restablecimiento, iLO muestra que el servidor está en la autoprueba al encenderse (POST), reinicia el flujo de aprovisionamiento: Si la instalación del clúster de administrador se ha completado correctamente: export KUBECONFIG=<root-admin-kubeconfig path> Actualiza la clave SSH: Obtén la clave SSH pública actual (ten en cuenta que puede haber cambiado y, por lo tanto, ser diferente de /root/.ssh/id_rsa.pub). kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d Coloca la clave pública en el mapa de configuración de ironic-vars: kubectl -n gpc-system edit cm/ironic-vars Añade IRONIC_RAMDISK_SSH_KEY: \ Reinicia ironic: kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Vuelve a aprovisionar el equipo para reinstalar IPA: Crea una copia de seguridad de bmc-credential-$SERVER, ya que al eliminar bmh también se eliminará el secreto. kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER Elimina del archivo los atributos no aplicables, como last-applied, creationtimestamp, finalizer, ownerreference, resourceversion y uid. Elimina el BareMetalHost: kubectl -n gpc-system delete bmh/$SERVER Obtén el secreto bmc-credentials-$SERVER o la copia de seguridad anterior de cellcfg y aplícalo. Pídele al servidor que haga otra cosa. Para quitar el estado de BMH almacenado en caché, sigue estos pasos: kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status- Espera a que se aprovisione el servidor. Descubre cómo se crean los objetos de BMH. Es posible que tengas que eliminar los trabajos de cifrado para volver a activarlos.
Operaciones	1.9.0 1.9.1 1.9.2	Usar la clase de almacenamiento standard-block puede impedir que las máquinas virtuales se inicien o se reinicien Síntomas: El estado de la VM se mantiene con STATUS de Provisioning o Starting cuando storageClassName es standard-block. Solución alternativa: Para solucionar el problema, sigue estos pasos: Comprueba que la máquina virtual STATUS muestre Provisioning o Starting: kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT SYSTEM_KUBECONFIG es la ruta del archivo del clúster del sistema kubeconfig. PROJECT es el proyecto de GDC en el que reside la VM. Opcional: Obtén más detalles sobre el estado: kubectl get gvm VM_NAME -n PROJECT -o \ jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}' VM_NAME es el nombre de la VM que no responde. Elimina la VM: kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME NAMESPACE_NAME es el nombre de tu espacio de nombres. Comprueba que la eliminación se ha realizado correctamente: kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT Si obtienes un resultado similar al siguiente, significa que se ha completado correctamente: Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found Elimina todos los discos de esa VM: kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME Sustituye el nombre de cada uno de tus discos por DISK_NAME_1 y DISK_NAME_2 hasta DISK_NAME_N y asegúrate de que todos los discos estén en la lista. Comprueba que la eliminación se ha realizado correctamente: kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT Si obtienes un resultado similar al siguiente, significa que se ha completado correctamente: 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 Vuelve a crear la VM y los discos. Reinicia la VM.
Operaciones	1.9.2	Durante una actualización de la versión 1.9.1 a la 1.9.2, es posible que las operaciones en Artifact Registry fallen y se produzcan errores de autorización Síntomas: gdcloud system container-registry load-oci falla y se producen errores. Si vuelves a ejecutar el comando, se ejecutará durante periodos diferentes y fallará en distintos puntos del proceso, como la inserción o el retiquetado, pero con errores similares. Solución alternativa: Para solucionar el problema, sigue estos pasos: Exporta KUBECONFIG al archivo kubeconfig del administrador raíz: export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig Ejecuta este comando para reducir deployment/root-admin-tftp-manager-controller a 0 réplicas: kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system Realiza las operaciones que no se han podido completar. Aumenta la escala de deployment/root-admin-tftp-manager-controller a 1 réplica: kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
Operaciones	1.9.1 1.9.2 1.9.3	No se pueden definir etiquetas de selector de complementos para el clúster de administrador raíz Síntomas: gdcloud system container-registry load-oci falla y se producen errores. Si vuelves a ejecutar el comando, se ejecutará durante periodos diferentes y fallará en distintos puntos del proceso, como la inserción o el retiquetado, pero con errores similares. Solución alternativa: Ignora el mensaje sin problema. Desaparece al cabo de un rato.
Operaciones	1.9.2	No se pueden recuperar los registros de un pod porque falta una imagen Solución alternativa: Para resolver el problema, reinicia el pod que lo tenga.
Operaciones	1.9.0 1.9.1 1.9.2	Un servidor está en el estado available y su tarea de configuración del cifrado sigue fallando debido a un error de clave SSH Síntomas: El estado de la condición "Server's Ready " (Servidor listo) es"False " (Falso) y el mensaje contiene "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ..." (El trabajo server-encrypt-and-create-logical-drive-... ha fallado por el motivo ... y el mensaje ...). Los registros del trabajo fallido contienen "Failed to connect to the host via ssh ... Permission denied (publickey)." (No se ha podido conectar al host mediante SSH. Permiso denegado [clave pública]). Solución alternativa: Para solucionar el problema, sigue estos pasos: Obtén la clave pública SSH actual del clúster de administrador raíz: kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d Coloca la clave en el configmap ironic-vars: kubectl -n gpc-system edit cm/ironic-vars Añade o sustituye la clave IRONIC_RAMDISK_SSH_KEY: <SSH public key> Reinicia la implementación de Ironic: kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Para cada servidor afectado: kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
Operaciones	1.9.2	El aprovisionamiento de un clúster de usuarios a través de la interfaz gráfica de usuario se bloquea Solución alternativa: Para evitar el problema de quedarse sin direcciones IP, define el tamaño de CIDR de pod en /21 o superior al crear un clúster de usuarios de alta disponibilidad.
Instalación	1.9.2	En el arranque, Google Distributed Cloud con air gap 1.14.2 no devuelve métricas de Cortex Solución alternativa: Para resolver el problema, reinicia los pods. Consulta el runbook MON-R0001 para obtener más información.
Autenticación de la plataforma	1.9.13	Las organizaciones recién creadas no pueden acceder a las IPs de datos del servidor Síntomas: En todos los trabajos de cplb-init y storage-ipsec-config-bm-XXXXX se muestra el siguiente mensaje: Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out. Solución alternativa: 1. Comprueba si bgp vrf está inactivo en aggswitch. 2. Comprueba si hay cambios sin confirmar en la nueva configuración de puesta en producción del cortafuegos. 3. Limpia todos los securitypolicyrules que tengan la organización eliminada en el nombre y reinicia el controlador de administrador raíz.
Actualizar	1.9.1 1.9.2 1.9.11	Durante la actualización del SO del nodo, el servidor se queda bloqueado en el proceso de desaprovisionamiento porque la URL boot.ipxe no es válida Síntomas: Server lleva más de 20 minutos atascado en deprovisioning..status.bareMetalHostStatus.provisionState La dirección IP de gestión del servidor que se está actualizando se incluye en el resultado de cualquiera de estos comandos: 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 Solución alternativa: Para resolver el problema, ejecuta el siguiente comando: kubectl -n gpc-system rollout restart deploy/root-admin-controller
Actualizar	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	Durante la actualización del SO del nodo, un nodo falla en el trabajo machine-init Síntomas: Una tarea de actualización de NodeUpgrade lleva más de 2 horas sin completarse. Un NodeUpgradeTask correspondiente se queda colgado en la condición NodeResumeCompleted durante más de una hora. bm-system-x.x.x.x-machine-init tareas siguen sin completarse durante mucho tiempo. x.x.x.x es la dirección del nodo. Solución alternativa: Para encontrar la dirección de un nodo incorrecto, consulta el x.x.x.x del trabajo bm-system-x.x.x.x-machine-init colgado. Para encontrar un nodo de plano de control en buen estado para el nodo en mal estado, sigue estos pasos: Busca el nodepool del nodo incorrecto. Comprueba el grupo de nodos del plano de control del mismo clúster que el nodo en mal estado y selecciona una dirección del .spec.address de ese grupo de nodos del plano de control. En el bootstrapper o OC IT, ejecuta lo siguiente: 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 En el nodo del plano de control en buen estado, ejecuta lo siguiente: 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
Actualizar	1.9.1 1.9.2	La actualización de la versión 1.9.0 a la 1.9.1 está bloqueada porque no se ha podido instalar el complemento ods-fleet Síntomas: El pod de operador de flota de ODS está en un bucle de fallos. Para comprobar el estado del pod, ejecuta el siguiente comando: ko get pods -n ods-fleet-operator En los registros del operador de flota de ODS aparece un error de elección de líder similar al siguiente: 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" Para consultar los registros de ODS Fleet Operator, ejecuta el siguiente comando: ko logs deployment/fleet-controller-manager -n ods-fleet-system Se muestra el siguiente mensaje: 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. Solución alternativa: Para editar la implementación, ejecuta el siguiente comando: 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 Asegúrate de editar el campo resources del contenedor manager de la siguiente manera: Antes: resources: limits: cpu: 100m memory: 512Mi requests: cpu: 100m memory: 512Mi Después: resources: limits: cpu: 1000m memory: 1024Mi requests: cpu: 1000m memory: 1024Mi
Actualizar	1.9.2 1.9.3	El complemento vm-runtime se queda atascado durante la actualización de gpu-org-system-cluster de la versión 1.9.1 a la 1.9.2 porque los pods de kubevm-gpu-driver-daemonset están en el estado CrashLoopBackOff Síntomas: Aparece el siguiente mensaje de error: 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 Solución alternativa: Para solucionar el problema, sigue estos pasos: Inicia sesión en todos los nodos de GPU aprovisionados: # ka get servers -A | grep o1-highgpu1-48-gdc-metal Elimina los paquetes antiguos: 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 el pod de kubevm-gpu-driver-daemonset que no responde. De esta forma, se reiniciará la instalación: # kug get pods -A | grep gpu | grep Init (Opcional) Si se ha agotado el tiempo de espera de la instalación del complemento, reiníciala: ku delete job vm-runtime-readiness -n gpu-org-system-cluster
Actualizar	1.9.10 1.9.11	El pod gpcbackup-agent-0 falla y muestra el mensaje de error failed to stage volume: iSCSI login failed. Síntomas: El gpcbackup-agent-0 muestra failed to stage volume: iSCSI login failed y no puede ajustar el volumen. Comprueba si el pod no puede adjuntar el volumen. En los siguientes ejemplos se usa el archivo kubeconfig del clúster del sistema: Describe el pod: kos describe pod -n gpc-backup-system gpcbackup-agent-0 Si el pod falla, se muestra un resultado similar al siguiente ejemplo: 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 Comprueba el nodo en el que falla el pod: kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide Obtendrá un resultado similar al siguiente ejemplo: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none] Obtén el pod netapp-trident en el mismo nodo en el que ha fallado el pod gpcbackup-agent-0: kos get pod -o wide -n netapp-trident Obtendrá un resultado similar al siguiente ejemplo: netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none] Comprueba los registros del pod netapp-trident en el mismo nodo en el que ha fallado el pod gpcbackup-agent-0: kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main Obtendrá un resultado similar al siguiente ejemplo: 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 Solución alternativa: Para solucionar el problema, sigue estos pasos: Obtener el nombre de InventoryMachine: export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig] export INV_MACH=vm-e2b9792a Confirma que la tarea anterior 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}" Obtendrás un resultado similar al siguiente: NAME COMPLETIONS DURATION AGE storage-ipsec-config-vm-e2b9792a 1/1 17s 19d Elimina el trabajo: kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH} Obtendrás un resultado similar al siguiente: warning: deleting cluster-scoped resources, not scoped to the provided namespace storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted Confirma que StorageEncryptionConnection existe: kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH} Obtendrás un resultado similar al siguiente: 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 el StorageEncryptionConnection: kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH} Obtendrás un resultado similar al siguiente: warning: deleting cluster-scoped resources, not scoped to the provided namespace storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted Reinicia el 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 Confirma que el nuevo trabajo se ha vuelto a crear y se ha ejecutado correctamente: kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH} Obtendrás un resultado similar al siguiente: NAME COMPLETIONS DURATION AGE storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
Actualizar	1.9.10 1.9.11	El nodo zp-aa-bm08 del clúster de administrador raíz muestra un error de aprovisionamiento y no se puede completar porque el registro no está en buen estado. Síntomas: Un pod de registro de Harbor muestra un mensaje de error similar al siguiente: 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 Solución alternativa: Para solucionar el problema, sigue estos pasos: Comprueba la reclamación de volumen persistente (PVC) del registro de Harbor y anota el nombre del volumen de la PVC: kubectl get pvc harbor-registry -n harbor-system Para comprobar si el archivo adjunto de volumen está en el mismo nodo que el pod del registro de Harbor, enumera los volumeattachment y busca el que esté asociado al nombre del volumen: kubectl get volumeattachment | grep [volume-name] Si el archivo adjunto de volumen está en un nodo diferente del pod del registro de Harbor, elimina volumeattachment: kubectl delete volumeattachment [volumeattachment-name] Reinicia el pod del registro de Harbor. Ahora, el registro de Harbor del clúster de administrador raíz debe estar en buen estado y la actualización de nodos debe completarse correctamente.
Instalación	1.9.2 1.9.3 1.9.4 1.9.5	Un clúster de usuarios no se prepara a tiempo Síntomas: Aparece el siguiente mensaje de error: pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet. Un registro de pod contiene lo siguiente: [INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes" La versión de CoreDNS es la 1.8.6. Solución alternativa: Para resolver el problema, reinicia la implementación de coredns. Una vez que KUBECONFIG se haya definido para el clúster correcto, ejecuta el siguiente comando: kubectl rollout restart deployment coredns -n kube-system El nombre del clúster de usuarios forma parte del mensaje de error. Para encontrar el archivo kubeconfig en /root/release/user/, busca los kubeconfigs: org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig Si faltan archivos kubeconfig, genéralos de la siguiente manera: 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
Actualizar	1.9.2 1.9.3	No se puede actualizar el estado de OrganizationUpgrade Síntomas: Aparece el siguiente mensaje de error: 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]] Este problema suele ser temporal y debería desaparecer.
Instalación	1.9.3	No se puede instalar un complemento No se puede instalar un complemento y se muestra el siguiente error: 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. Solución alternativa: Es posible que no se pueda instalar el complemento porque los nodos estén en el estado NotReady. Comprueba si los nodos están en el estado NotReady con el siguiente comando: kubectl get nodes Obtén detalles del nodo que se encuentra en el estado NotReady: $ kubectl describe node | grep PodCIDRs En un clúster con este problema, un nodo no tiene asignado ningún PodCIDR. Por ejemplo: 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 Para solucionar el problema, reinicia la implementación de ipam-controller en el clúster afectado: kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
Actualizar	1.9.3	No se pueden llamar webhooks al actualizar un clúster de usuarios Una actualización falla y se muestra el siguiente error: 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. Solución alternativa: Actualiza manualmente el campo abm-overrides's <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> al nombre del AddOnSetTemplate de la versión que quieras en el mismo espacio de nombres que el clúster que se va a actualizar.</code.spec.addonsettemplateref<>
Instalación	1.9.3	Un controlador de administrador de flota se queda en un bucle de fallos con el error Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced en los registros Síntomas: Un controlador de administrador de flota no se prepara y falla la prueba TestCreateFleetAdminCluster o TestSimOverlayCreateFleetAdminCluster. El mando del administrador de la flota se queda bloqueado en un bucle de fallos. En los registros del controlador de administrador de la flota aparece el siguiente error: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced. Solución alternativa: Despliega el Logmon CRD en el clúster de administrador de la organización. Reinicia el controlador de administrador de la flota.
Instalación	1.9.3	Un clúster del sistema no se prepara a tiempo Síntomas: Aparece el siguiente mensaje de error: 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] [...] Solución alternativa: Para solucionar el problema, reinicia tanto la implementación como el daemonset en el clúster: kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident Nota: Ejecuta el siguiente comando antes de reiniciar la implementación y el daemonset para que apunten al clúster correcto: export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
Actualizar	1.9.4 1.9.5 1.9.6 1.9.7 1.9.8	Un clúster de usuario con tres nodos de trabajador n2-standard-4 no tiene suficientes recursos de CPU para la actualización Síntomas: No se puede programar un pod porque no hay suficiente CPU. Solución alternativa: En el caso de un clúster de usuarios creado con n2-standard-4 nodos de trabajo, añade un nuevo NodePool con tres nodos a este clúster antes de actualizarlo.n2-standard-8 En el caso de los clústeres de usuarios nuevos, crea un n2-standard-8 NodePool con un mínimo de tres nodos. Consulta más información en el artículo Crear un clúster de usuarios para cargas de trabajo de contenedores.
Operaciones	1.9.0 1.9.2 1.9.3 1.9.4	La interfaz de usuario te permite seleccionar configuraciones de GPU y tipo de VM incompatibles Síntomas: La instancia de VM PHASE muestra Scheduling y READY permanece en el estado False y nunca llega al estado True. Esto afecta a dos tipos de máquinas, tal como se indica en la solución alternativa. Otros tipos de máquinas no se ven afectados y no necesitan ninguna solución alternativa. Solución alternativa: Cuando crees clústeres de usuario que usen GPUs A100 de 40 GB, selecciona siempre el tipo de máquina a2-highgpu-1g-gdc en la interfaz de usuario. Cuando crees clústeres de usuarios que usen GPUs A100 de 80 GB, selecciona siempre el tipo de máquina a2-ultragpu-1g-gdc en la interfaz de usuario. Importante: Estos tipos de máquinas con GPU son susceptibles al problema del tamaño de la memoria. Implementa la solución alternativa para tamaños de memoria de VM grandes para evitar este problema.
Operaciones	1.9.0 1.9.2 1.9.3 1.9.4	Los tamaños de memoria de las máquinas virtuales superiores a 32 GB pueden provocar que se calcule incorrectamente la sobrecarga de QEMU, por lo que requieren anulaciones del tamaño de la memoria Síntomas: En los grupos de nodos con instancias de VM que tengan tamaños de memoria superiores a 32 GB, es posible que la instancia de VM parezca ejecutarse, se detenga y vuelva a ejecutarse, y que esta secuencia se repita. Finalmente, se produce un error OOMKilled de falta de memoria y la instancia falla. Estos son los tres tipos de máquinas virtuales afectados: n2-highmem-8-gdc: 64 GB de memoria a2-highgpu-1g-gdc: 85 GB de memoria a2-ultragpu-1g-gdc: 170 GB de memoria Solución alternativa: Verifica el tipo de máquina: kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra Busca el tipo de VM en spec.compute.virtualMachineTypeName en el resultado. Si el tipo de VM es uno de los tres tipos que se indican, edita configmap para incluir una anulación de memoria: kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \ edit configmap NAME -n NAMESPACE Añade una sección memory.guest y resources.overcommitGuestOverhead como se muestra en el siguiente ejemplo: apiVersion: v1 kind: ConfigMap metadata: name: vm-8c440bc4 namespace: gdch-vm-infra data: virtSpec: | template: spec: domain: ... ... memory: guest: "MEMORY_SIZE" resources: overcommitGuestOverhead: true ... ... En memory, cambia guest para que tenga los siguientes valores: En el caso de n2-highmem-8-gdc, haz MEMORY_SIZE 63.6G. En el caso de a2-highgpu-1g-gdc, haz MEMORY_SIZE 84G. En el caso de a2-ultragpu-1g-gdc, usa MEMORY_SIZE 168G. Repite este proceso con todas las máquinas virtuales afectadas.
Actualizar	1.9.4	Un cliente SSH no puede asignar un pseudoterminal Síntomas: Una tarea de bm-system-* se bloquea en el paso Gathering Facts. Cuando se intenta acceder al servidor manualmente mediante SSH, se muestra PTY allocation request failed on channel 0. Solución alternativa: Reinicia el servidor de una de las siguientes formas: curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset Interfaz de usuario de iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
Actualizar	1.9.4 1.9.10	No se puede crear una copia de seguridad de la configuración de ipsec al actualizar el nodo Síntomas: Una actualización falla porque no se puede completar el trabajo backup-ipsec-*. Solución alternativa: Sigue estos pasos: Busca las claves precompartidas en el espacio de nombres gpc-system del clúster de administrador de la organización. Las claves se llaman <node-name>-pre-shared-key. Para obtener el hash de la clave del archivo yaml pre-shared-key de un nodo que funcione, usa 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 }'. Ten en cuenta que debes obtener el hash de la clave de un nodo distinto de aquel en el que se produjo un error al actualizar ipsec. Aplica el hash de esta clave precompartida al secreto de clave precompartida del nodo que falla en el gpc-system del clúster de administrador de la organización. Elimina el objeto storageencryptionconnection que tenga el mismo nombre que el nodo que falla en el clúster de administrador raíz. Elimina el trabajo de storage-ipsec-config-<node-name> asociado en el clúster de administrador de la organización. Elimina la tarea de actualización backup-ipsec-for-upgrade-<node-name> asociada.
Actualizar	1.9.4	El ejecutor de Clamav se niega a cerrarse al gestionar la señal SIGTERM Síntomas: La actualización de los clústeres de organizaciones lleva mucho tiempo. Solución alternativa: Espera a que clamav se cierre de forma natural.
Actualizar	1.9.5	El harbor-cert-secret tiene una CA diferente de la CA del lado del cliente Síntomas: Se muestran diferentes certificados: 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----- Solución alternativa: Nota: Rota el certificado harbor-harbor-https antes de seguir los pasos que se indican a continuación. Sigue estos pasos: Hay copias de los datos del certificado almacenadas en secretos del clúster. Después de rotar el certificado harbor-harbor-https, también debes actualizar las copias secretas. Recupera la URL de Artifact Registry. export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL') Actualice las copias del secreto del certificado de Artifact Registry en cada espacio de nombres. Obtener todos los espacios de nombres que almacenan una copia secreta del certificado de 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,\" \"") Actualiza la copia del secreto del certificado de Artifact Registry en cada espacio de nombres. 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 En el caso del clúster root-admin, también debes actualizar una corrección denominada copia secreta del certificado llamada ca-cert-in-cluster-registry en el espacio de nombres 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}\"}}" Actualiza el registry-cert almacenado en el espacio de nombres 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 vas a rotar los certificados de un clúster de administrador de organización, también debes actualizar las copias secretas de los certificados que haya en el clúster de administrador raíz. Obtiene todos los espacios de nombres que almacenan una copia secreta del certificado de 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,\" \"") Actualiza la copia del secreto del certificado de Artifact Registry en cada espacio de nombres. 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 .
Actualizar	1.10.0 1.10.1	Si actualizas una organización a la versión 1.10.x desde la 1.9.1 o una versión anterior, es posible que los pods de kube-apiserver no se activen durante la actualización. Síntomas: Después de iniciar un OrganizationUpgrade, el pod kube-apiserver no se ejecuta en uno o varios nodos. Identifica el nodo en el que se ha bloqueado la actualización: kubectl get po -n kube-system -l component=kube-apiserver La salida tiene este aspecto: 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 Establece una conexión SSH con el nodo que acabas de actualizar: root@ah-ac-bm01:~# crictl ps -a | grep kube-api Verá el estado del contenedor como Exited: f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01 bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited Consulta los registros del pod Exited: crictl logs f1771b8aad929 La salida tiene este aspecto: Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true La marca se configura en el archivo /etc/kubernetes/manifests/kube-apiserver.yaml: root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml - --feature-gates=JobTrackingWithFinalizers=false Solución alternativa: Elimina la marca del archivo /etc/kubernetes/manifests/kube-apiserver.yaml. Crea una copia de seguridad del archivo: root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak Quita la línea: root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml Confirma que la línea se ha eliminado: root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak 35a36 > - --feature-gates=JobTrackingWithFinalizers=false Lista el contenedor kube-apiserver: root@ah-ac-bm01:~# crictl ps --name kube-apiserver kubelet detecta automáticamente el cambio e inicia el pod kube-apiserver: CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD e1344008dfed9 bd6ed897ecfe2 12 hours ago Running Repite estos pasos con todos los nodos afectados.
Actualizar	1.9.2 1.9.3 1.9.3 1.9.4 1.9.5 1.9.6	kube-state-metrics bucles de fallos de implementación Síntomas: Los bucles de fallos de implementación de kube-state-metrics en una organización después de la rotación de certificados. Este problema puede provocar la pérdida de datos de monitorización.
Actualizar	1.9.6	Nodo de trabajo desequilibrado tras la actualización Síntomas: Después de la actualización, el nodo de trabajo está desequilibrado. Solución alternativa: Equilibra manualmente el nodo de trabajador: En el caso de una carga de trabajo de pods, elimina los pods de la implementación. En el caso de una carga de trabajo de VM, elimina virt-launcher sin modificar el objeto GVM del plano de control.
Actualizar	1.9.6	El complemento de dispositivo de GPU no se inicia Al actualizar de la versión 1.9.5 a la 1.9.6, es posible que el complemento del dispositivo GPU no se pueda iniciar. Síntomas: Es posible que veas el siguiente error, que bloquea la preparación del tiempo de ejecución de la VM y el proceso de actualización: Failed to initialize NVML: could not load NVML library Solución alternativa: Comprueba si el nvidia-container-runtime está configurado correctamente en el nodo: Establece una conexión SSH con el nodo que creas que tiene un problema. Obtén la lista de pods: crictl pods Inspecciona los pods: crictl inspectp $pod_hash | grep runtimeOption -A1 Si el resultado es similar a este, el nodo está configurado correctamente. Si el resultado no es como este, significa que nvidia-container-runtime no está configurado en el nodo: binary_name": "/usr/bin/nvidia-container-runtime" Si el nvidia-container-runtime no está bien configurado, reinicia containerd para solucionar el problema: systemctl restart containerd
Actualizar	1.9.7	NodeUpgrade para actualizar el firmware del servidor se queda atascado en el estado in process Al actualizar a la versión 1.9.7, el firmware del grupo de nodos del clúster de administrador raíz permanece en el estado in process. Síntomas: En el lado de NodeUpgrade, consulta la solución alternativa Tiempo de espera del servidor de artefactos: NodeUpgrade se queda en el estado in process y la condición de NodeROMFirmwareUpgradeCompleted en el estado Nodeupgradetask nunca se completa. La URL de spec.firmware.firmwarePackages.url del objeto NodeUpgrade puede colgarse al conectarse, por ejemplo: curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2 En el lado de Harbor, consulta la solución alternativa Servidor de artefactos no autorizado: En el registro del servidor de artefactos, puede aparecer un error relacionado con el acceso no autorizado a un repositorio: gdch-hpe-firmware/ilo. Por ejemplo: 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 En el proyecto de Harbor, gdch-hpe-firmware debe tener Spec.harborProjectConfig.accessLevel como private: kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml Solución alternativa: El tiempo de espera del servidor de artefactos se debe a que se usa el proxy istiogateway en el nodo que se está actualizando, que no está disponible. La solicitud enviada a esta URL no puede reenviar la solicitud al servidor de artefactos. Sigue estos pasos para solucionar el problema: Obtén otros hosts de servidores de artefactos disponibles: kubectl --kubeconfig ${KUBECONFIG:?} get servers -n gpc-system -o json | jq '[.items[] | select(.spec.nodePoolClaimRef.name=="root-admin-control-plane")] | .[].spec.managementNetwork.ips[0]' -r Elige uno que no esté en el objeto Nodeupgrade y repite la investigación descrita en NodeUpgrade. El comando curl no debe colgarse hasta que se agote el tiempo de espera. Actualiza el objeto NodeUpgrade para usar una nueva URL. El error Servidor de artefactos no autorizado se produce porque gdch-hpe-firmware está marcado como private en release-1.9, mientras que no se admite la autenticación básica a través del servidor de artefactos. Sigue estos pasos para solucionar el problema: Actualiza el proyecto de Harbor gdch-hpe-firmware para que sea público: kubectl patch harborproject/gdch-hpe-firmware \ --kubeconfig ${KUBECONFIG} \ -n gpc-system \ --type=merge \ -p ' spec: harborProjectConfig: accessLevel: public ' El comando curl devuelve una respuesta no vacía y el servidor de artefactos no debe mostrar un nuevo registro de errores. Nota: Puedes aplicar este paso antes de iniciar NodeUpgrade.
Redes inferiores	1.9.0 - 1.9.6	No se pueden establecer sesiones de BGP del clúster del sistema debido a que las IPs de clúster se solapan Síntomas: Las sesiones de BGP no funcionan en la red interna de una organización. Solo se añade uno de los endpoints de emparejamiento BGP internos de la organización a los objetos TORSwitchInternal. Solución alternativa: Cambia explícitamente la subred utilizada en {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim para que no se solape con los recursos AddressPoolClaim análogos de ninguna otra organización. Investiga los síntomas: En cada clúster del sistema de organización, ejecuta lo siguiente: kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG Comprueba el campo State de cada objeto BGPSession para ver el State de NotEstablished. Anota el LocalIP de cada NotEstablished BGPSession asociado para usarlo más adelante. Determina si "System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" es la causa principal: En cada organización activa, ejecuta el siguiente comando: kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip Busca el campo ClusterIP de la salida (tercera columna) correspondiente al LocalIPs que has anotado en el paso 1b. Apunta los LocalIP que coincidan con las entradas de la tercera columna del resultado para más adelante. Si hay varios clústeres de administrador de organización distintos, donde el resultado de 2.a contiene los LocalIPs indicados en el paso 1.b, vaya al paso 3. Resuelve las IPs superpuestas que se usan en los clústeres del sistema de la organización. Ejecuta lo siguiente: kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node Anota el número de objetos SubnetClaim devueltos por la consulta del paso 3a. Debe ser igual al número de organizaciones activas. En cada fila, anote el espacio de nombres (columna 1) y el bloque CIDR (columna 3). El bloque CIDR de cada fila debe ser el mismo que el de las demás filas. Sigue estos pasos con cada organización: Ve al objeto {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim en el clúster de administrador de la organización de esa organización. Calcula el Start IP de la reclamación del grupo de direcciones de nodos de trabajador de esa organización. Para ello, toma el bloque CIDR de 3.c y el campo Size del AddressPoolClaim de 3.d.i. Empezando por la penúltima IP del bloque CIDR, cuenta hacia atrás Size IP. Este es el nuevo Start IP de la primera organización (que se usa en el paso 3.d.iii). Por cada organización adicional, cuenta Size IP segundos, empezando por el nuevo Start IP de la organización anterior. Por ejemplo: 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 En el AddressPoolClaim del paso 3.c.i, añade el siguiente campo en el campo Spec: staticIPRanges: - startIPAddress: {Start IP from step 3.d.ii} size: {Size from step 3.d.ii} Usa el siguiente comando: `kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG El resultado debe ser similar al siguiente si usas org-1 del paso 3.d.ii, por ejemplo: 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: ... ... Limpia para evitar sesiones de BGP innecesarias en el hardware de TORSwitch. Para enumerar todos los recursos de TORSwitchInternal que necesitan actualizarse, ejecuta el siguiente comando: kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A En cada uno de los TORSwitchInternals que se muestran en el resultado del comando anterior, ejecuta el siguiente comando: kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system En todos los objetos TORSwitchInternal, elimina todas las entradas de la lista .spec.ebgpNeighbors que tengan NeighborIPs iguales a cualquiera de los LocalIPs del paso 2b. Por ejemplo, LocalIP de 2.2.2.2 se ha observado en el paso 2b. A continuación, se muestra un ejemplo de TORSwitchInternal antes y después del paso de limpieza. Antes de la limpieza: 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: ... Después de la limpieza. Fíjate en la entrada ebgpNeighbor que se ha eliminado: apiVersion: network.private.gdc.goog/v1alpha1 kind: TORSwitchInternal metadata: ... spec: ... ebgpNeighbors: - md5SecretReference: {} neighborIP: 1.1.1.1 peerASN: 11111 updateSource: loopbackID: ... vrf: ... l2Networks: ... Para validar la acción, realiza el paso 1 y confirma que todos los objetos BGPSession States han vuelto a Established. Puede que las modificaciones tarden unos 10 minutos en propagarse a las configuraciones físicas de TORSwitch de los centros de datos de Google.
Actualizar	1.9.7 - 1.9.21	La actualización del nodo y del sistema operativo no avanza Durante una actualización, es posible que no se complete la actualización del nodo y del sistema operativo. Síntomas: Puede que veas un nodo con el estado Ready, SchedulingDisabled durante unas horas. 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 Solución alternativa: Sigue el runbook PLATAUTH-SSH 0001 para obtener la clave SSH del nodo en cuestión. Después de conectarte al nodo mediante SSH, ejecuta el siguiente comando: multipath -ll | grep fail Ve al paso siguiente solo si la salida es similar a la siguiente: 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 Ejecuta lo siguiente para solucionar el problema: systemctl stop multipathd iscsiadm -m session -R systemctl start multipathd
Actualizar	1.9.8-1.9.21	Se ha bloqueado el drenaje de nodos porque el pod está en estado de finalización Síntomas: Si una actualización de un clúster de ABM se bloquea durante más de 2 horas, es posible que el drenaje de nodos se bloquee. Solución alternativa: En las siguientes operaciones se usa el clúster de administrador raíz como ejemplo. ${TARGET_KUBECONFIG} hace referencia al archivo `kubeconfig` del clúster de ABM de destino cuyo drenaje de nodos está bloqueado. ${KUBECONFIG} hace referencia al archivo kubeconfig del clúster que gestiona el clúster de ABM de destino. En el caso del clúster de administrador raíz, ambos hacen referencia al archivo kubeconfig del administrador raíz. Sigue estos pasos para comprobar si la actualización del clúster de ABM se ha quedado bloqueada: Comprueba los nodos que se han quedado atascados en el proceso de drenaje: kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo El resultado es el siguiente: {"10.200.0.2": 2} Esto significa que se están drenando dos pods del nodo "10.200.0.2". Comprueba si los pods siguen consumiendo recursos del nodo (${NODE_BEING_DRAINED}): kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}' El número de pods de salida debe ser el mismo que el número de pods que se están drenando, tal como se indica en el paso anterior. Para cada pod yetToDrain que se haya indicado en el paso 1, comprueba su estado: kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide Si el pod está en el estado Running o si el pod es audit-logs-loki-0 o loki-0 en el espacio de nombres obs-system y no tiene ningún evento que indique unable to unmount volume, elimina el pod explícitamente con un grace-period. kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME} En el resto de los casos en los que un pod se quede bloqueado en el proceso de drenaje, deriva el problema a los servicios de guardia. Monitoriza que se haya completado el drenaje del nodo. Repite el paso 1 si otros nodos se quedan bloqueados en el proceso de drenaje.
Actualizar	1.9.6 1.9.7 1.9.8	La distribución de artefactos falla después de adjuntar firmas Las versiones 1.9 con artefactos firmados no se pueden distribuir porque la marca Override de DistributionPolicy está definida como falsa, lo que impide que se distribuyan cuando hay un artefacto con el mismo nombre en el registro de destino. Síntomas: Puede que te encuentres con los siguientes problemas: Se envía el artefacto con la firma. El registro podría tener este aspecto: pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig No se ha podido enviar el artefacto. El registro podría tener este aspecto: failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig No se ha encontrado el artefacto 404. El registro podría tener este aspecto: http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]} No se puede distribuir el artefacto. Solución alternativa: Para solucionar el problema, sigue estos pasos: Actualiza el recurso personalizado (CR) DistributionPolicy para asignar el valor true a Spec.Override. Vuelve a activar una replicación siguiendo el manual de procedimientos SAR-1005. Una vez que se haya completado la nueva réplica, actualiza la ManualDistribution respuesta predefinida execution-ids en Annotation con el ID de ejecución correcto.
Módulo de seguridad de hardware (HSM)	1.9.9	El servidor informa de que el arrendatario de HSM no está en buen estado Es posible que los HSMs informen de forma intermitente de ServicesNotStarted, lo que puede provocar que los servidores físicos no se activen y muestren el siguiente mensaje: "message": "failed to get master key name" Síntomas: Puede que te encuentres con los siguientes problemas: Ejecuta el comando kubectl get server: kubectl get server zp-aa-bm08 -n gpc-system -o jsonpath='{.status.conditions}' | jq . La salida podría tener este aspecto: "message": "failed to get master key name: HSMTenant gpc-system/root does not have condition \"Ready\"=true" Ejecuta el comando kubectl get HSM: kubectl get hsm -A Es posible que los servicios se queden en ServicesNotStarted. Solución alternativa: Para solucionar el problema, siga estos pasos para reiniciar los HSMs que se hayan quedado bloqueados: Instala la herramienta kstl desde el primer HSM ejecutando los siguientes comandos: 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 Confirma que algún HSM tiene problemas para reiniciarse. Por cada HSM bloqueado en ServicesNotStarted, obtén el $HSM_MGMT_IP y comprueba que el servicio no funciona: ksctl services status --url=https://$HSM_MGMT_IP Pausa todos los HSMs, clústeres de HSMs y tenants de HSMs: 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 Establece una conexión SSH con el HSM cuando el servicio esté inactivo: ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP Asegúrate de que estás en el HSM correcto. Comprueba si has establecido una conexión SSH con el $HSM_MGMT_IP correcto. Reinicia el primer HSM desde dentro del HSM: ksadmin@ciphertrust:~ sudo reboot Espera a que el primer HSM pase a estar en buen estado desde fuera del HSM: watch -c ksctl services status --url=https://$HSM_MGMT_IP Este paso puede tardar unos cinco minutos en completarse. Repite estos pasos con los demás HSMs que tengan servicios inactivos. Reanuda los HSMs, los clústeres de HSMs y los tenants de HSMs: 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 que todo coincida. Los HSMs pueden tardar entre cinco y diez minutos en reconciliarse.
Supervisión	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	Las alertas de alertmanager-servicenow-webhook en clústeres del sistema de la organización no llegan a ServiceNow Síntomas: Las alertas de alertmanager-servicenow-webhook no llegan a ServiceNow en el clúster del sistema de la organización para las versiones de GDC anteriores a la 1.11.3. Los registros contienen el mensaje de error read: connection reset by peer. Este problema se debe a que falta una etiqueta para habilitar el tráfico de salida. Si el webhook necesita comunicarse entre organizaciones, debe usar NAT de salida. Solución alternativa: Debes habilitar el tráfico de salida para alertmanager-servicenow-webhook en los clústeres del sistema de la organización. Para solucionar el problema, sigue estos pasos: Define los requisitos previos necesarios: Instala la interfaz de línea de comandos (CLI) de gdcloud. Obtén las rutas a los archivos kubeconfig de los clústeres de administrador raíz y de administrador de organización. Guarda las rutas en las variables de entorno ROOT_KUBECONFIG y ORG_SYSTEM_KUBECONFIG, respectivamente. Pide a tu administrador de seguridad que te conceda el rol de administrador de observabilidad (observability-admin) en el espacio de nombres obs-system para los clústeres de administrador raíz y de administrador de organización. Confirma que el problema se produce en tu entorno: Obtén el despliegue de alertmanager-servicenow-webhook: kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system Para ver los registros de la implementación de alertmanager-servicenow-webhook, haz lo siguiente: kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system Si los registros contienen el mensaje de error read: connection reset by peer, significa que el problema existe y debes seguir los pasos de esta solución alternativa. Añade la etiqueta de salida: Obtén el archivo YAML de la implementación alertmanager-servicenow-webhook actual: 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 Añade la etiqueta de salida al archivo YAML de implementación de alertmanager-servicenow-webhook: yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml Sustituye el archivo YAML de implementación alertmanager-servicenow-webhook por las actualizaciones: kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \ $HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system El despliegue debe reiniciarse automáticamente. Para comprobar que el problema se ha solucionado, vuelve a ejecutar los pasos de la sección Confirmar que el problema existe en tu entorno. No se debe mostrar el mensaje de error de los registros. De lo contrario, deriva el caso al equipo de Ingeniería. Estrategia de restauración: Si los pasos de la solución alternativa no funcionan o detectas una pérdida de métricas, restaura el archivo YAML de la implementación alertmanager-servicenow-webhook a su estado original: kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \ $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
Actualizar	1.9.10	El NodeUpgradeTask del nodo se ha quedado bloqueado en el paso NodeMaintainCompleted durante un periodo más largo (más de 30 minutos). Síntomas: La actualización se queda atascada en el paso 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 El nodeupgradetask del grupo de nodos en curso muestra lo siguiente: 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 Solución alternativa: Sigue estos pasos: Obtén el nombre del despliegue de 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 Especifica el nombre de cap-controller-manager (por ejemplo, cap-controller-manager-1.28.0-gke.435): export CAP_DEPLOYMENT_NAME= Reinicia el 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
Actualizar	1.9.10	La actualización se queda atascada en el paso de comprobación posterior al vuelo AdminClusterHealth. Síntomas: La actualización se queda atascada en el paso de comprobación posterior al vuelo AdminClusterHealth. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root El objeto de organización muestra lo siguiente: NAMESPACE NAME READY gpc-system org-1 True gpc-system root False Solución alternativa: Sigue estos pasos: Usa el siguiente comando para omitir las comprobaciones previas: kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
Actualizar	1.9.9	El NodeUpgradeTask puede tener la condición failed to monitor failover registry recreation: failed to monitor job: job not complete Síntomas: El NodeUpgradeTask puede tener la condición failed to monitor failover registry recreation: failed to monitor job: job not complete que impide que se complete una tarea. Solución alternativa: Para resolver el problema, reinicia el trabajo: Elimina el trabajo llamado create-failover-registry-*** que tiene el estado "0/1". Elimina la anotación failover-registry-creation-job-name del objeto Server que se va a actualizar. El controlador vuelve a crear el trabajo automáticamente.
Actualizar	1.9.20	El nodo falla en el trabajo backup-ipsec-for-upgrade-bm. Síntomas: El nodo falla en el trabajo 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 " Solución alternativa: Elimina la tarea `backup-ipsec-for-upgrade-bm` y espera a que se vuelva a crear.
Google Distributed Cloud	1.9.9	La creación de la organización puede quedarse bloqueada porque el pool de nodos del plano de control no se prepara a tiempo. Síntomas: Un grupo de nodos del plano de control no se prepara porque el clúster etcd no se inicia. Puede que te encuentres con el siguiente 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 Solución alternativa: Para solucionar el problema, sigue estos pasos: Comprueba si la creación del clúster se ha quedado bloqueada en el trabajo de inicialización de la máquina. La tarea kubeadm join no se ha podido completar por el siguiente motivo: 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 tarea kubeadm reset no se ha podido completar debido a lo siguiente: panic: runtime error: invalid memory address or nil pointer dereference Usa SSH para conectarte a un nodo del panel de control que funcione. Ejecuta el comando etcdctl para limpiar los datos obsoletos. Comprueba la suscripción 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 Quita la suscripción obsoleta: # 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
Copia de seguridad y restauración de VMs	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	Los ajustes de webhook de la máquina virtual impiden que los usuarios inicien procedimientos de copia de seguridad y restauración de máquinas virtuales Síntomas: Los usuarios no pueden iniciar el proceso de copia de seguridad y restauración de VMs debido a que el control de acceso basado en roles (RBAC) y la configuración del esquema del gestor de VMs no son correctos. Los nombres de los planes de copia de seguridad de VMs no pueden tener más de 63 caracteres. Por ejemplo, puede que veas este mensaje de error: 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 Solución alternativa: Los nombres de los planes de copia de seguridad de VMs son una concatenación del nombre VirtualMachineBackupPlanTemplate, el tipo de recurso (que es vm o vm-disk) y el nombre de ese recurso. Esta cadena concatenada debe tener menos de 63 caracteres. Para ello, pon nombres cortos a estos recursos al crearlos. Para obtener información sobre cómo crear estos recursos, consulta los artículos Crear e iniciar una instancia de VM y Crear un plan de copias de seguridad para VMs.
Actualizar	1.9.9	No se puede actualizar el SO del nodo debido a un error en la plantilla Síntomas: Si se produce un error en la actualización de la tarea de copia de seguridad ipsec con el siguiente error de plantilla: "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 Solución alternativa: Sigue estos pasos: Inicia sesión en el nodo en el que falla la tarea de actualización. Guarda el swanctl.conf como copia de seguridad. Elimina la línea con llaves del archivo /etc/swanctl/swanctl.conf. Elimina el trabajo backup-ipsec-for-upgrade que ha fallado y espera a que se vuelva a crear. Después, el trabajo posterior se completará correctamente. Vuelve a añadir a /etc/swanctl/swanctl.conf la línea que has quitado en el paso 3.
Plataforma de nodo	1.9.6 1.9.7 1.9.8 1.9.9	El nodo de metal desnudo del administrador raíz rechaza el tráfico de red entrante después de una actualización de firmware Cuando se inicia una actualización de firmware en el clúster de administrador raíz, después de que uno de los nodos complete la actualización, parece que se bloquea. Síntomas: El nodeupgradetask se queda atascado en la fase NodeResumeCompleted. El trabajo machine-init falla y el registro muestra que kubeadm join ha fallado. No puedes establecer una conexión SSH con el nodo mediante la dirección IP del plano de datos. El problema se debe a que el nodo actualizado ya no acepta tráfico de red entrante. Solución alternativa: Inspecciona los registros de job/nodeupgradetask que fallen para anotar las direcciones IP y averiguar qué nodo tiene el problema. Reinicia el pod anetd-client del nodo afectado. Verifica la conexión SSH en la IP del plano de datos al nodo afectado. Pasos opcionales para investigar más a fondo: Accede a un contenedor de agente de cilium de cualquiera de los pods de anetd que funcionen. Ejecuta cilium-bugtool y espera unos 10 segundos. La herramienta guarda los registros en el directorio /var/log/network/policy_action.log. Busca deny para ver si se está denegando el tráfico: grep -r "deny" /var/log/network/ to Anota qué servidores se deniegan, posiblemente los nodos de hardware sin sistema operativo del administrador raíz.
Actualizar	1.9.13 1.9.14 1.9.15 1.9.16 1.9.17 1.9.18 1.9.19	La actualización falla en el complemento atat-webhooks Síntomas: No se puede actualizar el complemento atat-webhooks. Las etiquetas de complementos de ATAT caducadas pueden provocar que las actualizaciones de la organización fallen. Por ejemplo: Invalid value: "TO1234": The current date 2024-05-06 is not within the valid range of this TaskOrder: 2023-12-16 - 2024-04-16. Solución alternativa: Los usuarios deben actualizar las etiquetas de complementos de ATAT de su cartera. Sigue el runbook ATAT-R0003 para resolver el problema.
Actualizar	1.9.13 1.9.14 1.9.15 1.9.16 1.9.17 1.9.18 1.9.19	Falla la actualización del SO del nodo en el hardware desnudo de la organización de inquilinos Síntomas: La actualización del SO del nodo en Bare Metal de la organización de arrendatario falla al actualizar de la versión 1.9.12 a la 1.9.13. Aparece el siguiente mensaje: 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" } } ] Solución alternativa: Quita la anotación cluster.private.gdc.goog/ssh-trusted-ca-versions en el CR del servidor de administrador raíz y de administrador de organización. Elimina los trabajos de Ansible fallidos. Las tareas nuevas se crean automáticamente porque la anotación cluster.private.gdc.goog/host-key-rotation-in-progress se marca como verdadera en el CR del servidor. Después de la rotación, las anotaciones cluster.private.gdc.goog/ssh-trusted-ca-versions se vuelven a añadir al CR del servidor.
Nodo, actualización	1.9.*	Es posible que los pods de las máquinas Bare Metal muestren el estado CrashLoopBackOff debido a que se han eliminado reglas de cilium Síntomas: Después de la actualización, los pods de algunos nodos de Bare Metal se quedan en el estado CrashLoopBackOff y iptables -L -v -n | grep CILIUM en el nodo devuelve un resultado vacío. Solución alternativa: Para solucionar el problema, sigue estos pasos: Ejecuta el siguiente comando: crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force. Vuelve a ejecutar iptables -L -v -n | grep CILIUM y comprueba que haya resultados.
Almacenamiento de registros	1.9.14 1.9.15	El pod audit-logs-loki-0 puede mostrar el estado CrashLoopBackOff debido a un error de Loki Síntomas: El pod audit-logs-loki-0 está en el estado CrashLoopBackOff. Verifica el estado del pod: kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0 donde SYSTEM_KUBECONFIG es la ruta al archivo kubeconfig. El error de Loki se muestra en el siguiente resultado, donde CrashLoopBackOff es el estado: NAME READY STATUS RESTARTS AGE audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m Solución alternativa: Para solucionar el problema, sigue estos pasos: Exporta la ruta al archivo kubeconfig a una variable de entorno llamada SYSTEM_KUBECONFIG. Reduce la escala del operador Logmon: kubectl scale deployment -n obs-system logmon-operator --replicas 0 Reduce los recursos de Loki: kubectl scale loki -n obs-system --replicas 0 kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0 Elimina las reclamaciones de volumen persistente (PVC) audit-logs-loki-storage-audit-logs-loki-0 y loki-storage-loki-0. Elimina los volúmenes persistentes (PV) obs-system/loki-storage-loki-0 y obs-system/audit-logs-loki-storage-audit-logs-loki-0. Escala verticalmente el operador Logmon: kubectl scale deployment -n obs-system logmon-operator --replicas 1 Sigue los pasos para actualizar la configuración de registro desde la versión 1.9. Comprueba que el pod audit-logs-loki-0 se está ejecutando: kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0 El estado Running debe mostrarse en la salida, como en el siguiente ejemplo: NAME READY STATUS RESTARTS AGE audit-logs-loki-0 2/2 Running 0 15h
Infraestructura como código	1.9.16	No se puede instalar GitLab Síntomas: Al actualizar a la versión 1.9.16, falla la instalación del complemento Gitlab. Es posible que veas un error como este: 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 El pod de PostgreSQL, como gpc-system/gitlab-postgresql-0, está en estado de finalización. Solución alternativa: Elimina por la fuerza el pod de Postgres que está bloqueado en un estado de finalización: kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE Asegúrate de que el pod de Postgres se vuelva a crear después de eliminarlo.
Gestión de identidades y accesos	1.9.19 1.9.20	Falla la autenticación al acceder a la consola Síntomas: Al actualizar de la versión 1.9.18 e intentar acceder a la consola de GDC, es posible que veas el siguiente mensaje: Authentication failed, please contact your system administrator Solución alternativa: Obtén la CA necesaria: export KUBECONFIG=ORG_ADMIN_KUBECONFIG kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}' Abre el archivo de configuración del cliente para editarlo: kubectl edit clientconfig -n kube-public default Busca certificateAuthorityData en la configuración del cliente y actualiza la CA necesaria con la siguiente ruta: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData.