| Instalación |
1.9.0
1.9.1
1.9.2 |
En ocasiones, iLO no puede recuperar 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 con errores 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 pudo acceder al pod por SSH debido a una clave no válida.
Solución alternativa:
Para resolver el problema, sigue estos pasos:
Ve a la IU de iLO > Information > Diagnostics > Reset para restablecer iLO. Si, durante el restablecimiento, iLO muestra que el servidor está en la prueba automática de encendido (POST), reinicia el flujo de aprovisionamiento:
Si la instalación del clúster de administrador se realizó correctamente, haz lo siguiente:
export KUBECONFIG=<root-admin-kubeconfig path>
Actualiza la clave SSH:
Toma la clave SSH pública actual (ten en cuenta que es posible que se haya rotado y, por lo tanto, sea 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 configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars
Agrega IRONIC_RAMDISK_SSH_KEY: \ Reinicia ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Vuelve a aprovisionar la máquina para reinstalar la IPA:
Crea una copia de seguridad de bmc-credential-$SERVER, ya que borrar bmh también borrará el secreto.
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Quita del archivo los atributos no aplicables, como last-applied, creationtimestamp, finalizer, ownerreference, resourceversion y uid.
Borra el BareMetalHost:
kubectl -n gpc-system delete bmh/$SERVER
Toma el secreto bmc-credentials-$SERVER o la copia de seguridad anterior de cellcfg y aplícalo.
Indicarle al servidor que haga algo diferente
Para quitar el estado de BMH almacenado en caché, haz lo siguiente:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Espera a que se aprovisione el servidor. Mira cómo se crean los objetos de BMH. Es posible que debas borrar los trabajos de encriptación para volver a activarlos.
|
| Operaciones |
1.9.0
1.9.1
1.9.2 |
Síntomas:
El estado de la VM persiste con STATUS de Provisioning o Starting cuando storageClassName es standard-block.
Solución alternativa:
Para resolver el problema, sigue estos pasos:
Verifica que la VM STATUS muestre Provisioning o Starting:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG es la ruta de acceso al archivo kubeconfig del clúster del sistema.
PROJECT es el proyecto de GDC en el que reside la VM.
Opcional: Obtén detalles adicionales del 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.
Borra la VM:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME es el nombre de tu espacio de nombres.
Verifica que la eliminación se haya realizado correctamente:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Un resultado similar al siguiente confirma que la operación se realizó correctamente:
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Borra 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 a través de DISK_NAME_N, y asegúrate de que se incluyan todos los discos. Verifica que la eliminación se haya realizado correctamente:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
Un resultado similar al siguiente confirma que la operación se realizó 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 |
Síntomas:
gdcloud system container-registry load-oci falla con errores. Si vuelves a ejecutar el comando, se ejecuta durante diferentes períodos y falla en diferentes puntos del proceso, como la inserción o el cambio de etiquetas, pero con errores similares.
Solución alternativa:
Para resolver el problema, sigue estos pasos:
Exporta KUBECONFIG al kubeconfig del administrador raíz:
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Ejecuta este comando para reducir la escala de
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 fallaron.
- Escala verticalmente
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 |
Síntomas:
gdcloud system container-registry load-oci falla con errores. Si vuelves a ejecutar el comando, se ejecuta durante diferentes períodos y falla en diferentes puntos del proceso, como la inserción o el cambio de etiquetas, pero con errores similares.
Solución alternativa:
Ignora el mensaje de forma segura. Desaparece después de un tiempo.
|
| Operaciones |
1.9.2 |
Solución alternativa:
Para resolver el problema, reinicia el pod que lo tiene.
|
| Operaciones |
1.9.0
1.9.1
1.9.2 |
Síntomas:
El estado de la condición Server's Ready es "False" y el mensaje contiene "job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...". Los registros del trabajo fallido contienen "Failed to connect to the host via ssh ... Permission denied (publickey).".
Solución alternativa:
Para resolver el problema, sigue estos pasos:
Obtén la clave SSH pública actual del clúster de administrador raíz:
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dColoca la clave en el configmap ironic-vars:
kubectl -n gpc-system edit cm/ironic-vars Agrega o reemplaza la clave IRONIC_RAMDISK_SSH_KEY existente:
<SSH public key>
Reinicia la implementación de Ironic:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Para cada servidor afectado, haz lo siguiente:
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| Operaciones |
1.9.2 |
Solución alternativa:
Para evitar el problema de escasez de direcciones IP, establece el tamaño del CIDR de Pod en /21 o superior cuando crees un clúster de usuario con alta disponibilidad.
|
| Instalación |
1.9.2 |
Solución alternativa:
Para resolver el problema, reinicia los Pods.
Consulta el manual MON-R0001 para obtener más detalles.
|
| Autenticación de la plataforma |
1.9.13 |
Síntomas:
Todos los trabajos de cplb-init y storage-ipsec-config-bm-XXXXX muestran 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. Verifica si la VRF de BGP está inactiva en aggswitch.
2. Verifica si hay cambios sin confirmar en la nueva configuración de etapa de pruebas del firewall.
3. Limpia todos los securitypolicyrules que tenían la organización borrada en el nombre y reinicia el root-admin-controller.
|
| Actualizar |
1.9.1
1.9.2
1.9.11 |
Síntomas:
Server tiene .status.bareMetalHostStatus.provisionState atascado en deprovisioning durante más de 20 minutos.
La dirección IP de administración del servidor que se actualiza 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 |
Síntomas:
Una tarea de actualización en NodeUpgrade permanece sin finalizar durante más de 2 horas.
Un NodeUpgradeTask correspondiente se bloquea en la condición NodeResumeCompleted y permanece sin finalizar durante más de 1 hora.
Los trabajos de bm-system-x.x.x.x-machine-init permanecen sin finalizar durante un período prolongado. x.x.x.x es la dirección del nodo.
Solución alternativa:
Para encontrar la dirección de un nodo en mal estado, consulta el x.x.x.x del trabajo bm-system-x.x.x.x-machine-init que se detuvo.
Para encontrar un nodo del plano de control en buen estado para el nodo en mal estado, sigue estos pasos:
- Busca el grupo de nodos del nodo en mal estado.
Verifica el grupo de nodos del plano de control en el mismo clúster de ese nodo en mal estado y selecciona una dirección de .spec.address de ese grupo de nodos del plano de control.
En el equipo de asistencia técnica de OC o de Bootstrapper, ejecuta el siguiente comando:
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
Dentro del 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 |
Síntomas:
El pod del operador de la flota de ODS se reinicia en bucle.
Para verificar el estado del pod, ejecuta el siguiente comando:
ko get pods -n ods-fleet-operator
En los registros del operador de la 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 verificar los registros del operador de la flota de ODS, 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 |
Síntomas:
Se muestra 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:
Accede a todos los nodos de GPU aprovisionados:
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
Quita los paquetes anteriores:
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) ...
Borra el Pod atascado kubevm-gpu-driver-daemonset. Esto reinicia la instalación:
# kug get pods -A | grep gpu | grep Init
(Opcional) Si se agotó 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 |
Síntomas:
El gpcbackup-agent-0 muestra failed to stage volume: iSCSI login failed y no puede organizar 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
-
Verifica el nodo para el que falla el Pod:
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Obtendrás 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 para el que falló el pod gpcbackup-agent-0:
kos get pod -o wide -n netapp-trident
Obtendrás un resultado similar al siguiente ejemplo:
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Verifica los registros del pod netapp-trident en el mismo nodo en el que falló el pod gpcbackup-agent-0:
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Obtendrás 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 resolver el problema, realiza los siguientes pasos:
-
Obtén el nombre de InventoryMachine:
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Confirma que existe el trabajo anterior:
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
-
Borra 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 existe StorageEncryptionConnection:
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
-
Borra 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 trabajo nuevo se haya recreado y 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 |
Síntomas:
Un pod del 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 resolver el problema, sigue estos pasos:
-
Verifica 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 verificar si la conexión del volumen se encuentra en el mismo nodo desde el pod del registro de Harbor, enumera los volumeattachment y busca el asociado con el nombre del volumen:
kubectl get volumeattachment | grep [volume-name]
-
Si la conexión del volumen se encuentra en un nodo diferente del pod del registro de Harbor, quita volumeattachment:
kubectl delete volumeattachment [volumeattachment-name]
-
Reinicia el pod del registro de Harbor.
Ahora, el registro de Harbor en el clúster de administrador raíz debe estar en buen estado y la actualización del nodo debe completarse correctamente.
|
| Instalación |
1.9.2
1.9.3
1.9.4
1.9.5
|
Síntomas:
Se muestra 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 1.8.6.
Solución alternativa:
Para resolver el problema, reinicia la implementación de coredns.
Una vez que KUBECONFIG esté configurado para el clúster correcto, ejecuta el siguiente comando:
kubectl rollout restart deployment coredns -n kube-system
El nombre del clúster de usuario 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 los 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 |
Síntomas:
Se muestra 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]]
Por lo general, este problema es transitorio y debería solucionarse.
|
| Instalación |
1.9.3 |
La instalación de un complemento falla con 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 falle la instalación del complemento porque los nodos están en 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 |
Una actualización falla con 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 de AddOnSet <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> al nombre de AddOnSetTemplate de la versión deseada en el mismo espacio de nombres que el clúster que se actualiza.</code.spec.addonsettemplateref<>
|
| Instalación |
1.9.3 |
Síntomas:
Un controlador de administrador de la flota no se prepara, lo que provoca que falle la prueba TestCreateFleetAdminCluster o TestSimOverlayCreateFleetAdminCluster. El controlador de administrador de flota está atascado en un bucle de fallas. El siguiente error se encuentra en los registros del controlador de administrador de la flota: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Solución alternativa:
Implementa el CRD Logmon en el clúster de administrador de la organización. Reinicia el controlador de administrador de la flota.
|
| Instalación |
1.9.3 |
Síntomas:
Se muestra 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 resolver el problema, reinicia la implementación y 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 |
Síntomas:
No se puede programar un pod debido a que no hay suficiente CPU.
Solución alternativa:
En el caso de un clúster de usuario existente creado con nodos trabajadores n2-standard-4, agrega un nuevo NodePool n2-standard-8 con tres nodos a este clúster antes de actualizarlo. Para los clústeres de usuarios nuevos, crea un n2-standard-8 NodePool con un mínimo de tres nodos. Consulta Crea un clúster de usuario para cargas de trabajo de contenedores para obtener más detalles.
|
| Operaciones |
1.9.0
1.9.2
1.9.3
1.9.4 |
Síntomas:
La instancia de VM PHASE muestra Scheduling y READY permanece en False, sin alcanzar nunca el estado True. Esto afecta a dos tipos de máquinas, como se indica en la solución alternativa. Otros tipos de máquinas no se ven afectados y no necesitan una solución alternativa.
Solución alternativa:
- Cuando crees clústeres de usuario que usen GPU A100 40G, siempre selecciona el tipo de máquina a2-highgpu-1g-gdc en la IU.
- Cuando crees clústeres de usuario que usen GPUs A100 80G, siempre selecciona el tipo de máquina a2-ultragpu-1g-gdc en la IU.
|
| Operaciones |
1.9.0
1.9.2
1.9.3
1.9.4 |
Síntomas:
En el caso de los grupos de nodos con instancias de VM con tamaños de memoria superiores a 32 GB, es posible que la instancia de VM parezca ejecutarse, luego detenerse y volver a ejecutarse, y que repita esta secuencia. Finalmente, se arroja un error OOMKilled de memoria insuficiente y la instancia falla.
Estos son los tres tipos de VM 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 cualquiera 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
- Agrega 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:
- Para n2-highmem-8-gdc, haz MEMORY_SIZE
63.6G.
- Para a2-highgpu-1g-gdc, haz que MEMORY_SIZE
84G.
- Para a2-ultragpu-1g-gdc, haz MEMORY_SIZE
168G.
- Repite este paso para todas las VMs afectadas.
|
| Actualizar |
1.9.4 |
Síntomas:
Un trabajo bm-system-* se detiene en el paso Gathering Facts. Cuando se intenta acceder al servidor de forma manual a través de SSH, se muestra PTY allocation request failed on channel 0.
Solución alternativa:
Reinicia el servidor con una de las siguientes opciones:
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
IU de iLO kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Actualizar |
1.9.4
1.9.10 |
Síntomas:
La actualización falla porque el trabajo backup-ipsec-* falla.
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 de clave precompartida de un nodo en funcionamiento, 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 que no sea el nodo en el que falló la actualización de IPsec. Aplica el hash de esta clave precompartida al secreto precompartido del nodo con errores en gpc-system en el clúster de administrador de la organización. Borra el objeto storageencryptionconnection que tiene el mismo nombre que el nodo con errores en el clúster de administrador raíz. Borra el trabajo de storage-ipsec-config-<node-name> asociado en el clúster de administrador de la organización. Borra el trabajo de actualización de backup-ipsec-for-upgrade-<node-name> asociado.
|
| Actualizar |
1.9.4 |
Síntomas:
La actualización de los clústeres de la organización lleva mucho tiempo.
Solución alternativa:
Espera a que clamav se cierre de forma natural.
|
| Actualizar |
1.9.5 |
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 dentro 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')
- Actualiza las copias secretas del certificado de Artifact Registry en cada espacio de nombres.
Obtén 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 secreta 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 clúster de administrador raíz, también debes actualizar una copia secreta del certificado de corrección 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 rotas los certificados del clúster de administrador de la organización, también debes actualizar las copias de los secretos de los certificados que existen en el clúster de administrador raíz.
Obtén 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 secreta 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 |
Síntomas:
Después de iniciar un OrganizationUpgrade, el pod kube-apiserver no se ejecuta en uno o más nodos.
- Identifica el nodo en el que se bloqueó la actualización:
kubectl get po -n kube-system -l component=kube-apiserver
La salida obtenida se verá así:
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 se acaba de actualizar:
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
Verás 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
- Verifica los registros del pod
Exited:
crictl logs f1771b8aad929
La salida obtenida se verá así:
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:
Quita 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 se haya quitado la línea:
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Enumera el contenedor
kube-apiserver:
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet detecta automáticamente el cambio y comienza el pod de
kube-apiserver:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Repite estos pasos para todos los nodos afectados.
|
| Actualizar |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Síntomas:
Los bucles de fallas 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 supervisión.
|
| Actualizar |
1.9.6 |
Síntomas:
Después de la actualización, el nodo trabajador está desequilibrado.
Solución alternativa:
Balancea manualmente el nodo trabajador:
- En el caso de una carga de trabajo de Pod, borra los Pods de la implementación.
- Para una carga de trabajo de VM, borra virt-launcher sin modificar el objeto GVM del plano de control.
|
| Actualizar |
1.9.6 |
Cuando se actualiza de la versión 1.9.5 a la 1.9.6, es posible que no se pueda iniciar el complemento del dispositivo de GPU.
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:
- Verifica si
nvidia-container-runtime está configurado correctamente en el nodo:
- Establece una conexión SSH al nodo que sospechas 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 se ve así, significa que nvidia-container-runtime
no está configurado en el nodo:
binary_name": "/usr/bin/nvidia-container-runtime"
- Si
nvidia-container-runtime no está configurado correctamente, reinicia containerd para resolver el problema:
systemctl restart containerd
|
| Actualizar |
1.9.7 |
Cuando se actualiza 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 está atascado en el estado in process y la condición para NodeROMFirmwareUpgradeCompleted en el estado Nodeupgradetask siempre está incompleta.- La URL en
spec.firmware.firmwarePackages.url del objeto NodeUpgrade podría dejar de responder cuando se conecta, por ejemplo, en los siguientes casos:
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- Para el lado de
Harbor, consulta la solución alternativa Servidor de artefactos no autorizado:
- En el registro del servidor de artefactos, es posible que se muestre 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:
|
| Redes de menor nivel |
1.9.0 - 1.9.6 |
Síntomas:
Las sesiones de BGP están inactivas en la red interna de una organización. Solo se agrega uno de los extremos de peering de BGP internos de la organización a los objetos TORSwitchInternal.
Solución alternativa:
Cambia de forma explícita la subred que se usa en {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim para que no se superponga con ningún otro recurso AddressPoolClaim análogo de la organización.
- Investiga los síntomas:
- Para cada clúster del sistema de organización, ejecuta lo siguiente:
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- Verifica 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 raíz:
- Para 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
LocalIPs que se indicó en el paso 1b en el campo ClusterIP del resultado (3ª columna). Anota los LocalIP que coincidan con las entradas de la 3ª columna del resultado para más adelante. Si hay varios clústeres de administración de la organización distintos, en los que el resultado del paso 2a contiene los LocalIP que se indican en el paso 1b, continúa con el paso 3.
- Resuelve las IPs superpuestas que se usan para los clústeres del sistema de la organización.
- Ejecución:
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 la cantidad de objetos
SubnetClaim devueltos por la búsqueda en el paso 3a. Este valor debe ser igual a la cantidad de organizaciones activas.
- Para cada fila, anota 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 todas las demás filas.
- Para cada organización, realiza los siguientes pasos:
- Navega al objeto
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim en el clúster de administrador de la organización.
- Calcula el
Start IP del reclamo del grupo de direcciones de nodo trabajador de esa organización. Para ello, toma el bloque CIDR de 3c y el campo Size en el AddressPoolClaim de 3d.i. Comenzando por la penúltima IP del bloque CIDR, cuenta hacia atrás Size IPs. Este es el nuevo Start IP para la primera organización (se usa en el paso 3.d.iii). Para cada organización adicional, cuenta hacia atrás Size IP, comenzando 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, agrega 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 verse de la siguiente manera si usas org-1 del punto 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: ...
...
- Realiza una limpieza para evitar sesiones de BGP innecesarias en el hardware de TORSwitch.
- Para enumerar todos los recursos de
TORSwitchInternal que necesitan actualización, ejecuta el siguiente comando:
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Para cada uno de los
TORSwitchInternals que se enumeran en el resultado del comando anterior, ejecuta el siguiente comando:
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- Para todos los objetos
TORSwitchInternal, quita todas las entradas de la lista .spec.ebgpNeighbors que tengan NeighborIPs iguales a cualquiera de los LocalIPs del paso 2b. Por ejemplo, se observó LocalIP de 2.2.2.2 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. Observa la entrada ebgpNeighbor que se quitó:
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, realiza el paso 1 y confirma que todos los objetos
BGPSession States hayan vuelto a Established. Es posible que todas las modificaciones tarden alrededor de 10 minutos en propagarse a las configuraciones físicas de los TORSwitch de GDC.
|
| Actualizar |
1.9.7 - 1.9.21 |
Durante una actualización, es posible que no se avance con la actualización del nodo y del sistema operativo.
Síntomas:
Es posible que veas un nodo con el estado Ready, SchedulingDisabled durante algunas 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 manual de operaciones PLATAUTH-SSH 0001 para obtener la clave SSH del nodo en cuestión. Después de conectarte al nodo con SSH, ejecuta el siguiente comando:
multipath -ll | grep fail
- Continúa con el siguiente paso solo si el resultado es similar al 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 el siguiente comando para solucionar el problema:
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| Actualizar |
1.9.8-1.9.21 |
Síntomas:
Si una actualización del clúster de ABM se detiene durante más de 2 horas, es posible que se bloquee el vaciado de nodos.
Solución alternativa:
Las siguientes operaciones usan el clúster de administrador raíz como ejemplo. ${TARGET_KUBECONFIG} hace referencia a `kubeconfig` para el clúster de ABM de destino cuyo vaciado de nodos está bloqueado, y ${KUBECONFIG} hace referencia a kubeconfig para el clúster que administra el clúster de ABM de destino. En el caso del clúster de administrador raíz, ambos se refieren al kubeconfig del administrador raíz.
Completa los siguientes pasos para ver si la actualización del clúster de ABM está atascada:
- Verifica los nodos que se quedaron atascados en el proceso de vaciado:
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, para el nodo "10.200.0.2", se están vaciando dos Pods.
- Verifica si los Pods aún se están vaciando del nodo (denominado
${NODE_BEING_DRAINED}):
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
La cantidad de Pods de salida debe ser la misma que la cantidad de Pods que se están vaciando, según se informó en el paso anterior.
Para cada Pod yetToDrain que se indica en el paso 1, verifica el estado del Pod:
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Si el pod está en estado Running, o si el pod está en estado audit-logs-loki-0 o loki-0 en el espacio de nombres obs-system y no tiene ningún evento que se queje de unable to unmount volume, borra explícitamente el pod con un grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- En todos los demás casos en los que un pod se quede atascado en el proceso de vaciado, deriva el problema a los servicios de guardia.
- Supervisa que se complete el desvío del nodo.
- Repite el paso uno si otros nodos están atascados en el proceso de vaciado.
|
| Actualizar |
1.9.6
1.9.7
1.9.8
|
Las versiones 1.9 con artefactos firmados no se pueden distribuir porque la marca Override en DistributionPolicy está establecida como falsa, lo que impide que se distribuya cuando hay un artefacto con el mismo nombre en el registro de destino.
Síntomas:
Es posible que encuentres los siguientes problemas:
- Se envía el artefacto con la firma. El registro podría verse de la siguiente manera:
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- No se pudo enviar el artefacto. El registro podría verse de la siguiente manera:
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- No se encontró el artefacto 404. El registro podría verse de la siguiente manera:
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- Falla la distribución del artefacto.
Solución alternativa:
Para resolver el problema, sigue estos pasos:
- Actualiza el recurso personalizado (CR)
DistributionPolicy para establecer Spec.Override en true.
- Vuelve a activar una replicación siguiendo el runbook SAR-1005.
- Después de que la nueva ejecución de replicación se realice correctamente, actualiza el CR de
ManualDistribution execution-ids en Annotation con el ID de ejecución exitosa.
|
| Módulo de seguridad de hardware (HSM) |
1.9.9 |
Es posible que los HSM informen de forma intermitente ServicesNotStarted, lo que puede provocar que los servidores de metal desnudo no se vuelvan saludables y muestren el siguiente mensaje:
"message": "failed to get master key name"
Síntomas:
Es posible que encuentres los siguientes problemas:
Solución alternativa:
Para resolver el problema, sigue estos pasos para reiniciar los HSM que están 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 tenga problemas para reiniciarse. Para cada HSM atascado en
ServicesNotStarted, obtén el $HSM_MGMT_IP y verifica que el servicio esté inactivo:
ksctl services status --url=https://$HSM_MGMT_IP
- Pausa todos los HSM, los clústeres de HSM y los inquilinos de 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
- Establece una conexión SSH con el HSM con el servicio inactivo:
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Asegúrate de estar en el HSM correcto. Verifica si estableciste una conexión SSH con el
$HSM_MGMT_IP correcto.
- Reinicia el primer HSM desde el interior del HSM:
ksadmin@ciphertrust:~ sudo reboot
- Espera a que el primer HSM se ponga 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 que se reinicien los HSM.
- Repite estos pasos para los demás HSM que tengan servicios inactivos.
- Reanuda los HSM, los clústeres de HSM y los inquilinos de 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 que todo coincida. Es posible que los HSM tarden de cinco a diez minutos en conciliarse.
|
| 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 |
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 la falta de una etiqueta para habilitar el tráfico de salida. Si el webhook necesita comunicarse entre organizaciones, debe usar la 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 resolver el problema, sigue estos pasos:
- Establece los requisitos previos necesarios:
- Instala la interfaz de línea de comandos (CLI) de gdcloud.
- Obtén las rutas de acceso a los archivos kubeconfig de los clústeres de administrador raíz y de administrador de la organización. Guarda las rutas de acceso en las variables de entorno
ROOT_KUBECONFIG y ORG_SYSTEM_KUBECONFIG, respectivamente.
- Pídele a tu administrador de seguridad que te otorgue el rol de administrador de Observabilidad (
observability-admin) en el espacio de nombres obs-system para los clústeres de administrador raíz y administrador de la organización.
- Confirma que el problema existe en tu entorno:
- Obtén la implementación
alertmanager-servicenow-webhook:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- Visualiza los registros de la implementación de
alertmanager-servicenow-webhook:
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, el problema existe y debes continuar con los pasos de esta solución alternativa.
- Agrega la etiqueta de salida:
- Obtén el archivo YAML de 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
- Agrega la etiqueta de salida al archivo YAML de implementación
alertmanager-servicenow-webhook:
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Reemplaza 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
La implementación debe reiniciarse automáticamente.
- Para verificar que se haya corregido el problema, vuelve a ejecutar los pasos de Confirma 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 reversión:
Si los pasos de la solución alternativa fallan o ves alguna pérdida en las métricas, vuelve el archivo YAML de 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 |
Síntomas:
La actualización se detuvo 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 de la implementación 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 |
Síntomas:
La actualización se detuvo en el paso de verificació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 verificaciones previas al vuelo:
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 |
Síntomas:
El NodeUpgradeTask podría tener la condición failed to monitor failover registry recreation: failed to monitor job: job not complete que bloquea la finalización de una tarea.
Solución alternativa:
Para resolver el problema, reinicia el trabajo:
- Borra el trabajo llamado
create-failover-registry-*** que tiene una finalización de "0/1".
- Borra la anotación
failover-registry-creation-job-name del objeto Server que se está actualizando.
El controlador vuelve a crear el trabajo automáticamente.
|
| Actualizar |
1.9.20 |
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:
Borra el trabajo `backup-ipsec-for-upgrade-bm` y espera a que se vuelva a crear.
|
| Google Distributed Cloud |
1.9.9 |
Síntomas:
Un grupo de nodos del plano de control no se prepara debido a que no se inicia el clúster etcd. Es posible que encuentres 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 resolver el problema, sigue estos pasos:
- Verifica si la creación del clúster se detuvo en el trabajo de inicialización de la máquina.
La tarea kubeadm join falló debido a lo siguiente:
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 falló 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 en funcionamiento.
- Ejecuta el comando
etcdctl para limpiar los datos obsoletos.
- Verifica la membresía de
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
- Sigue estos pasos para quitar la membresía 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 restablecimiento de VM |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
Síntomas:
Los usuarios no pueden iniciar el proceso de copia de seguridad y restablecimiento de la VM debido a una configuración incorrecta del control de acceso basado en roles (RBAC) y del esquema en el administrador de la VM.
Los nombres de los planes de copias de seguridad de VM no pueden contener más de 63 caracteres.
Por ejemplo, es posible que veas el siguiente 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 copias de seguridad de VM son una concatenación del nombre VirtualMachineBackupPlanTemplate, el tipo de recurso (que puede ser vm o vm-disk) y el nombre de ese recurso. Esta cadena concatenada debe tener menos de 63 caracteres.
Para lograr esto, mantén los nombres de estos recursos cortos cuando los crees. Para obtener detalles sobre la creación de estos recursos, consulta Crea y, luego, inicia una instancia de VM y Crea un plan de copias de seguridad para las VMs.
|
| Actualizar |
1.9.9 |
Síntomas:
Una actualización falla en el trabajo 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:
Accede al nodo en el que falla la tarea de actualización. Guarda el archivo swanctl.conf como copia de seguridad. Quita la línea con corchetes en el archivo /etc/swanctl/swanctl.conf. Borra el trabajo backup-ipsec-for-upgrade que falló y espera a que se vuelva a crear. Luego, el trabajo posterior se completará correctamente. Vuelve a agregar la línea que quitaste en el paso 3 a /etc/swanctl/swanctl.conf.
|
| Plataforma del nodo |
1.9.6
1.9.7
1.9.8
1.9.9 |
Cuando se inicia una actualización de firmware en el clúster de administrador raíz, después de que uno de los nodos completa la actualización, parece que se detiene.
Síntomas:
- El
nodeupgradetask está atascado en la etapa NodeResumeCompleted.
- El trabajo
machine-init falla y el registro muestra que kubeadm join falló.
- No puedes establecer una conexión SSH al nodo con 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 fallan 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 realizar una investigación adicional:
- Conéctate a la shell de un contenedor de agentes de Cilium de cualquiera de los pods de anetd en funcionamiento.
- Ejecuta cilium-bugtool y espera unos 10 segundos. La herramienta guarda registros en el directorio
/var/log/network/policy_action.log.
- Busca
deny para ver si se rechaza el tráfico:
grep -r "deny" /var/log/network/ to
Ten en cuenta qué servidores se rechazan, posiblemente los nodos raíz de administrador de Bare Metal.
|
| Actualizar |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Síntomas:
- Falla una actualización en el complemento de
atat-webhooks.
- Las etiquetas de complementos de ATAT vencidas pueden hacer que fallen las actualizaciones de la organización.
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 los complementos de ATAT de su cartera. Sigue el manual 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 |
Síntomas:
- La actualización del SO del nodo en la organización de inquilinos de Bare Metal falla durante la actualización 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 administrador de la organización.
- Borra los trabajos de Ansible que fallaron. Los trabajos nuevos se crean automáticamente porque la anotación
cluster.private.gdc.goog/host-key-rotation-in-progress está marcada 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 agregar al CR del servidor.
|
| Nodo, actualización |
1.9.* |
Síntomas:
Después de la actualización, los Pods de algunos nodos de metal desnudo quedan en el estado CrashLoopBackOff y iptables -L -v -n | grep CILIUM en el nodo devuelve un resultado vacío.
Solución alternativa:
Para resolver el problema, completa los siguientes 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 verifica que haya un resultado.
|
| Logging |
1.9.14
1.9.15 |
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
Aquí, SYSTEM_KUBECONFIG es la ruta de acceso al archivo kubeconfig.
El error de Loki se muestra en el siguiente resultado, en el que CrashLoopBackOff es el estado:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Solución alternativa:
Para resolver el problema, completa los siguientes pasos:
- Exporta la ruta de acceso al archivo kubeconfig a una variable de entorno llamada
SYSTEM_KUBECONFIG.
- Reduce la escala vertical del operador de Logmon:
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Reduce la escala vertical de los recursos de Loki:
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Borra las reclamaciones de volúmenes persistentes (PVC)
audit-logs-loki-storage-audit-logs-loki-0 y loki-storage-loki-0.
- Borra los volúmenes persistentes (PV)
obs-system/loki-storage-loki-0 y obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Aumenta la escala vertical del operador de 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.
- Verifica 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 el resultado 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 |
Síntomas:
Cuando se actualiza a la versión 1.9.16, falla la instalación del complemento de 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 postgres, como gpc-system/gitlab-postgresql-0, se encuentra en estado de finalización.
Solución alternativa:
- Borra a la fuerza el pod de Postgres que está atascado 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 la eliminación.
|
| Administración de identidades y accesos |
1.9.19
1.9.20 |
Síntomas:
Cuando actualices de la versión 1.9.18 y trates de 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 requerida:
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 requerida con la siguiente ruta: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
