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

Copia de seguridad y restauración

No se puede editar el plan de restauración de copias de seguridad de clústeres

Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6 y 1.14.7

Síntomas:

El recurso personalizado RestorePlan no se puede editar con la consola de GDC.

Solución alternativa:

Crea un plan de restauración y elimina el antiguo, o edita el plan de restauración con la CLI de kubectl.

Tamaño de disco de origen no válido

Versiones: 1.14.4 y 1.14.5

Síntomas: la interfaz de usuario muestra incorrectamente el tamaño de un disco como 0 MB y su hora de creación como "Desconocido" debido a un cambio en el modelo de datos backend después de la migración a la arquitectura de organización de la versión 2.

Solución: No hay ningún método alternativo para ver esta información a través de la interfaz de usuario.

Los pods del agente y del plano de control se reinician por falta de memoria

Versiones: 1.14.3 y 1.14.4

Síntomas: es posible que los pods del agente y del plano de control se reinicien si se quedan sin memoria.

Solución alternativa: aumenta la memoria de los pods del plano de control y del agente siguiendo las instrucciones del runbook BACK-R0005. Aumenta la memoria de los pods a 2 GiB.

No se aplican los SLOs de copia de seguridad y restauración

Versiones: 1.14.3 y 1.14.4

Síntomas: las métricas y las alertas de los objetivos de nivel de servicio (SLOs) de GDC no están configuradas de forma predeterminada, ya que no se ha instalado la definición de recurso personalizado necesaria. Estas alertas se usan en Grafana.

Soluciones alternativas: Para habilitar los SLOs de copia de seguridad y restauración en GDC, sigue el runbook BACK-T0001.

Las políticas de conservación no se aplican a las copias de seguridad importadas

Versiones: todas las versiones de Google Distributed Cloud (GDC) con air gap pueden verse afectadas.

Síntomas: al adjuntar un repositorio de copias de seguridad al clúster, se sincronizan todos los metadatos de las copias de seguridad y de las restauraciones, y los repositorios se tratan como copias de seguridad importadas. Estas copias de seguridad importadas se omiten incorrectamente durante la conciliación, lo que significa que las políticas de conservación se ignoran y las copias de seguridad se conservan indefinidamente.

Solución: Las copias de seguridad importadas se etiquetan con backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME. Para permitir la conciliación normal y la aplicación de las políticas de conservación, quita la etiqueta de las copias de seguridad con los siguientes comandos de kubectl:

1. Define las variables de entorno necesarias:

   export KUBECONFIG=KUBECONFIG
   export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
   export NAMESPACE=BACKUP_PLAN_NAMESPACE
   

   Haz los cambios siguientes:

   • KUBECONFIG: la ruta al archivo kubeconfig.
   • BACKUP_REPOSITORY_NAME: el nombre del repositorio de la copia de seguridad.
   • NAMESPACE: el espacio de nombres que contiene el plan de copia de seguridad.

2. Lista todas las copias de seguridad importadas:

   kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME
   

3. Quita las etiquetas según sea necesario:

   • Quita las etiquetas de todas las copias de seguridad:

     kubectl get backups.backup.gdc.goog -l
     backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
     -o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
     $NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-
     

   • Quitar las etiquetas de una sola copia de seguridad:

     export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
     $NAMESPACE backup.gdc.goog/imported-repository-
     

Fallo de copia de seguridad parcial de una VM

Versiones: 1.14.3 y 1.14.4

Síntomas: Si no se puede crear una copia de seguridad de una de las muchas VMs, se marca como fallida toda la copia de seguridad de la VM.

Solución alternativa: limita el número de VMs por plan de copias de seguridad.

Limpiar los recursos de copia de seguridad huérfanos después de eliminar un clúster de usuarios o de servicios

Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6 y 1.14.7

Síntomas: Cuando se elimina un clúster de usuario o de servicio, los recursos del agente de copia de seguridad asociados (como StatefulSet, pods, secretos, etc.) creados en la infraestructura de la organización y en el clúster de gestión no se limpian automáticamente. Esto puede dejar recursos huérfanos y, si el clúster se crea de nuevo con el mismo nombre, el pod del agente de copia de seguridad no funcionará.

Solución alternativa: Los recursos huérfanos se encuentran en un espacio de nombres específico del clúster de infraestructura de la organización. Para limpiarlos, debes eliminar este espacio de nombres.

1. Define los archivos kubeconfig de los clústeres de infraestructura y de gestión de la organización.

   export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifica el espacio de nombres de los recursos huérfanos. El espacio de nombres sigue el patrón gpc-backup-<cluster-name>-system. Por ejemplo:

   • gpc-backup-user-vm-1-cluster-system
   • gpc-backup-user-vm-2-cluster-system
   • gpc-backup-g-org-1-shared-service-cluster-system

3. Elimina el espacio de nombres. Se eliminarán todos los recursos que contenga, incluido el StatefulSet y el pod del agente de copia de seguridad en la infraestructura, así como el secreto en el clúster de gestión.

   # Replace <namespace-name> with the actual namespace
   kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
   kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
   

4. Para confirmar que la limpieza se ha realizado correctamente, vuelve a ejecutar el comando get all.

   # Replace <namespace-name> with the actual namespace
   kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
   kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
   

   El comando debería fallar porque el espacio de nombres ya no existe. Deberías ver un error como Error from server (NotFound): namespaces "<namespace-name>" not found.

No se admite la eliminación de VirtualMachineRestore a través de la CLI o la interfaz de usuario

Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6 y 1.14.7

Síntomas: el controlador VirtualMachineRestore no limpia automáticamente los recursos subyacentes (VolumeRestore y Restore) al eliminar un recurso VirtualMachineRestore. Esto requiere que se realice una limpieza manual. Esto se aplica tanto si se elimina con kubectl delete como con la interfaz de usuario.

Solución: Elimine manualmente los recursos dependientes en el orden correcto y, a continuación, quite el finalizador del recurso VirtualMachineRestore.

1. Define el archivo kubeconfig para que apunte al clúster de gestión.

   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifica el VirtualMachineRestore que quieres eliminar y su espacio de nombres.

   export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
   export NAMESPACE=<namespace-of-vm-restore>
   

3. Busca y elimina los recursos VolumeRestore asociados. Se crean con una etiqueta que los vincula a VirtualMachineRestore.

   # Find and delete all associated VolumeRestores.
   kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

4. Busca y elimina los recursos Restore asociados. Se crean con una etiqueta que los vincula a VirtualMachineRestore.

   # Find and delete all associated Restores.
   kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

5. Ahora, realiza el paso kubectl delete si aún no lo has hecho y quita el finalizador del recurso VirtualMachineRestore. Este es el paso final que permite que el recolector de elementos no utilizados de Kubernetes elimine el recurso.

   kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
   

6. Verifica la eliminación.

   kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"
   

   El comando debería devolver un error NotFound, lo que confirma que el recurso se ha eliminado.

El pod del plano de control de la copia de seguridad falla porque no tiene suficiente memoria

Versiones: 1.14.4 y posteriores

Síntomas: el pod gpcbackup-controlplane-controller del espacio de nombres del sistema gpc-backup del clúster de infraestructura de la organización muestra el estado CrashLoopBackOff. Cuando se produce este error, las operaciones de copia de seguridad y restauración fallarán, dejarán de responder o no funcionarán como se espera.

Solución: aumenta los límites de memoria de la implementación de gpcbackup-controlplane-controller siguiendo las instrucciones de BACK-R0005. Este método aplica un SubcomponentOverride para ajustar las solicitudes y los límites de CPU y memoria.

La eliminación de un clúster de usuarios se ha bloqueado

Versiones: 1.14.7 y posteriores

Síntomas: los clústeres se quedan atascados en el estado de eliminación debido a problemas con el finalizador.

Solución: Comprueba si los volúmenes de almacenamiento tienen relaciones SnapMirror antes de eliminar el clúster. Para obtener más información, consulta BACK-R0109.

La restauración se ha bloqueado debido a una reclamación de volumen persistente pendiente

Versiones: 1.14.3 y posteriores

Síntomas: A veces, los controladores de reclamación de volumen persistente (PVC) no pueden comunicarse con los agentes de copia de seguridad en el clúster de infraestructura de la organización. Aunque este problema no afecta a la función de copia de seguridad, puede provocar que una operación de restauración de volumen se quede atascada en el estado Pending y, finalmente, se agote el tiempo de espera. Este problema afecta a las operaciones de restauración que implican una restauración de volumen, como la función de restauración del servicio de bases de datos para la clonación y la restauración de cargas de trabajo de usuarios.

Si se produce este problema, las operaciones de restauración posteriores en el clúster afectado fallarán hasta que reinicies manualmente el agente de copia de seguridad correspondiente.

Para confirmar que el problema de restauración está relacionado con este problema específico, debes investigar los registros del agente de copia de seguridad:

1. Sigue las instrucciones de IAM-R0005 para obtener el rol de depurador BACK (back-cluster-debugger) necesario aplicando el recurso ExpirationClusterRoleBinding.

2. Sigue las instrucciones de IAM-R0004 para generar el archivo kubeconfig del clúster de infraestructura de la organización. Todos los agentes de copia de seguridad se ejecutan en el clúster de infraestructura de la organización.

3. Identifica el agente de copia de seguridad que facilita la restauración:

   kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
       --all-namespaces | grep gpcbackup-agent
   

   Sustituye ORG_INFRA_KUBECONFIG por la ruta al archivo kubeconfig del clúster de infraestructura de la organización.

   El resultado debería ser similar al siguiente:

   NAMESPACE                                          NAME                                     READY   AGE
   gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
   gpc-backup-system                                  gpcbackup-agent                          1/1     22d
   gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
   gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
   gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d
   

   Lee el resultado y determina el agente de copia de seguridad que corresponde a tu restauración. Por ejemplo, si el espacio de nombres del conjunto con estado afectado de la salida es gpc-backup-user-vm-1-cluster-system, el agente de copia de seguridad es gpcbackup-agent-user-vm-1.

4. Busca el mensaje de error en los registros del conjunto con estado para confirmar el problema:

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
       -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
   

   Haz los cambios siguientes:

   • ORG_INFRA_KUBECONFIG: la ruta al archivo kubeconfig del clúster de infraestructura de la organización.

   • BACKUP_AGENT: el agente de copia de seguridad que has identificado en el paso anterior.

   • NAMESPACE: el espacio de nombres que has identificado en el paso anterior.

   Si hay registros coincidentes, significa que tienes este problema conocido.

Solución alternativa: para solucionar el problema, sigue estos pasos:

1. Reinicia el agente de copia de seguridad:

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
      statefulsets/BACKUP_AGENT -n NAMESPACE
   

   Haz los cambios siguientes:

   • ORG_INFRA_KUBECONFIG: la ruta al archivo kubeconfig del clúster de infraestructura de la organización.

   • BACKUP_AGENT: el agente de copia de seguridad que ha identificado al confirmar el problema.

   • NAMESPACE: el espacio de nombres que has identificado al confirmar el problema.

   El resultado debería ser similar al siguiente:

   statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
   

2. Espera hasta 20 minutos para que las operaciones pendientes se reanuden automáticamente.

Puedes realizar otra restauración en el mismo clúster de destino una vez que se haya completado el reinicio del agente de copia de seguridad. Una vez que hayas completado esta solución alternativa, no habrá ningún efecto secundario. Solo es necesario completar esta solución alternativa una vez por cada clúster afectado.

Gestión de clústeres

El subcomponente kub-gpu-controller no se reconcilia

Versiones: 1.14.3

Síntomas: El subcomponente g-gdchservices-shared-service-cluster/kub-gpu-controller de la organización gdchservices no se reconcilia. Se devuelve la siguiente salida:

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

Este error impide que las máquinas con GPU se inicien en la organización gdchservices.

Solución alternativa: actualiza a la versión 1.14.4 o posterior para mitigar el problema.

No se puede eliminar un grupo de nodos de un clúster estándar

Versiones: 1.14.3, 1.14.4 y 1.14.5

Corregido: 1.14.6

Síntomas: no se pueden eliminar grupos de nodos obsoletos de clústeres estándar y los grupos de nodos no se eliminan en el plazo previsto. Los clústeres estándar están en versión preliminar privada y puede que no estén disponibles para todos los clientes.

Solución alternativa: elimina manualmente los grupos de nodos obsoletos.

El clúster se ha quedado bloqueado en el estado de eliminación

Versiones: 1.14.6 y posteriores

Síntomas: al eliminar un clúster de Kubernetes, puede que se quede en el estado Deleting. Para comprobar el estado de tu clúster, ejecuta el siguiente comando:

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

El resultado debería ser similar al siguiente:

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

También puedes verificar el problema comprobando el estado del espacio de nombres del clúster:

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

El resultado debería ser similar al siguiente:

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

El espacio de nombres del clúster está en estado Terminating y las condiciones NamespaceContentRemaining y NamespaceFinalizersRemaining se han definido como True.

Solución alternativa: para solucionar el problema, sigue estos pasos:

1. Aplica un parche a la API de reglas de reenvío:

   kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
       cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'
   

2. Aplica un parche a la API de servicios de backend:

   kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
       cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'
   

Servicio de base de datos

En esta sección se describen los problemas conocidos del servicio de bases de datos.

Clonación de base de datos de AlloyDB Omni bloqueada

Versiones: 1.14.6 y anteriores

Corregido: 1.14.7

Síntomas: Cuando un usuario clona un clúster de AlloyDB Omni desde un momento dado, el clúster de base de datos clonado se bloquea con el error DBSE0005 y no puede estar listo. El recurso restore.alloydb correspondiente está bloqueado en la fase "ProvisionInProgress".

Solución alternativa: Para solucionar este problema, elige cuidadosamente el momento a partir del COMPLETETIME de las copias de seguridad correctas.

Lista de copias de seguridad de AlloyDB Omni disponibles para clonar en el servidor de la API de gestión.

kubectl get backups.alloydb -n source-dbcluster-namespace

Ejemplos de resultados:

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

Elige un valor de COMPLETETIME como momento de la clonación. Ten en cuenta que la hora está en UTC.

DNS

GlobalCustomerRootDNSServerNotReachable activa una alerta falsa

Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7 y 1.14.8

Síntomas: se activa la alerta de DNS DNS-A0021, que sugiere GlobalCustomerRootDNSServerNotReachable. La CR de la sonda de global-customer-root-dns en org-mp no tiene egress: true en las especificaciones.

Solución alternativa:

1. Define la ruta de KUBECONFIG para org-mgmt:

   export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG
   

2. Pausa el subcomponente core-mz que gestiona la sonda CR:

   kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true
   

3. Edita el CR de la sonda actual de org-mp:

   kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns
   

4. Actualiza la especificación para incluir egress: True y aplica el cambio. Ten en cuenta que CLUSTER_NAME y GLOBAL_CUSTOMER_ROOT_IP no han cambiado.

   apiVersion: prober.private.gdc.goog/v1alpha1
   kind: Probe
   metadata:
     name: global-customer-root-dns
   spec:
     egress: True
     matchClusters:
     - CLUSTER_NAME
     probeJobs:
     - moduleName: dns_udp_global_customer_root
       name: healthy-dns-global-customer-root
       targets:
       - GLOBAL_CUSTOMER_ROOT_IP
   

Esta solución alternativa corrige el prober y las falsas alertas desaparecerán en 15 minutos.

Almacenamiento de archivos o en bloques

No se puede montar el volumen de un recurso compartido de archivos en una máquina virtual

Versiones: 1.14.6 y 1.14.7

Síntomas: no se actualizan los permisos de almacenamiento de red cuando se añade un nodo nuevo a un clúster, lo que puede provocar que se denieguen las solicitudes de montaje de NFS. Es posible que aparezca un error access denied by server al montar un recurso compartido de archivos NFS.

Solución alternativa: reinicia los reconciliadores file-share o proxy-group, o modifica el recurso FileShare para activar una actualización.

Cortafuegos

Falta la regla de política de seguridad para la dirección de la CR de subred

Versiones: 1.14.3

Síntomas: no se puede acceder a una organización porque falta el grupo de direcciones del cortafuegos en el recurso personalizado de subred global creado por el cliente en el servidor de la API global de la organización.

Solución: Sigue los pasos que se indican en el manual de servicio FW-G0002 para añadir manualmente una regla de política de seguridad que permita el tráfico.

Los firewalls de GDC deniegan el tráfico hacia OIR tanto para el plano de gestión como para el de datos

Versiones: 1.14.3 y 1.14.4

Síntomas: después de implementar el recurso personalizado OCITTopology, se interrumpe la conectividad entre el plano de gestión y el plano de datos de OIR y GDC.

Solución alternativa: Sigue los pasos que se indican en el manual de servicio FW-G0002 para añadir manualmente reglas de política de seguridad en el clúster de administrador raíz y permitir el tráfico.

Se requieren las siguientes reglas de la política de seguridad:

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

Haz los cambios siguientes:

• OCIT_CIDR: los intervalos de direcciones IP del campo ocitCIDR del cuestionario de información del cliente (CIQ).
• MGMT_CIDR: los intervalos de direcciones IP del campo oobManagementCIDRs del cuestionario de información del cliente (CIQ).
• ZONE_INFRA_CIDR: los intervalos de direcciones IP del campo zoneInfraCIDRs del cuestionario de información del cliente (CIQ).

El cortafuegos de GDC deniega el tráfico entre zonas y organizaciones

Versiones: 1.14.3, 1.14.4 y 1.14.5

Síntomas: los firewalls bloquean de forma predeterminada el tráfico entre zonas y organizaciones.

Solución alternativa: sigue los pasos que se indican en el runbook para añadir manualmente reglas de política de seguridad que permitan el tráfico.

Firewall no admite AttachmentGroup cuyo identificador sea el mismo que el nombre de la organización

Versiones: 1.14.3 y posteriores

Síntomas: Después de implementar un AttachmentGroup, si el campo identifier de ese objeto AttachmentGroup es el mismo que orgName, el cortafuegos no puede analizar este objeto y las actualizaciones de la configuración del cortafuegos se bloquean. A continuación, se muestra un ejemplo de un objeto AttachmentGroup problemático:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

Solución: No utilices el nombre de la organización como identificador. Hay varias opciones para corregir el AttachmentGroup incorrecto.

Elige una de las siguientes opciones para solucionar el problema con AttachmentGroup.

• Añade una cadena al final del identificador original con un guion:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg-orgdx
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

• Añade una cadena al principio del identificador original con un guion:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: orgdx-myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

• Sustituye el identificador original por otra cadena:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: dxidentifier
    entities:
      - orgName: myorg
        domainType: OrgMixed
  

Puerto

El secreto de la CLI de Harbor deja de ser válido después de crear una copia de seguridad y restaurarla

Versiones: 1.14.3

Síntomas: Después de hacer una copia de seguridad y restaurar Harbor, los secretos de la CLI dejan de ser válidos y deben crearse de nuevo.

Solución alternativa: para mitigar este problema, sigue estos pasos:

1. Inicia sesión en Harbor con una cuenta de usuario de IAP.
2. Haz clic en tu nombre de usuario y selecciona Perfil de usuario.
3. Haz clic en Más.
4. Crea otro secreto de CLI de forma automática o manual.

Para obtener más información sobre Harbor en GDC, consulta el resumen de Harbor.

El trabajo de copia de seguridad y restauración de Harbor compite por el permiso

Versiones: 1.14.3 y 1.14.4

Síntomas: Cuando hay varias instancias de Harbor en diferentes proyectos de usuario, las operaciones de copia de seguridad y restauración compiten por los controles de acceso basados en roles y experimentan un alto porcentaje de fallos.

Solución alternativa: Para mitigar este problema, sigue estos pasos para crear manualmente un enlace de rol para cada espacio de nombres en el que se creen instancias de Harbor:

1. Define las variables de entorno necesarias:

   INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
   INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
   

   Haz los cambios siguientes:

   • INFRA_CLUSTER_KUBECONFIG: la ruta al archivo kubeconfig del clúster de infraestructura.
   • INSTANCE_NAMESPACE: espacio de nombres en el que se crean las instancias de Harbor de Managed Harbor Service (MHS).

2. Crea el enlace de rol para la solución alternativa:

   kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
   rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
   --role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
   --namespace=haas-system
   

El tamaño de la copia de seguridad de Harbor muestra valores 0

Versiones: 1.14.3 y 1.14.4

Síntomas: Por el momento, no se ha implementado la medición del tamaño de las copias de seguridad de Harbor. En la consola de GDC, los campos SizeBytes muestran el valor 0 y la columna Size muestra el valor 0 MB. Por ahora, este es el comportamiento esperado de esta configuración.

Error de permisos en los recursos de copia de seguridad en la página de la consola de Harbor Registry

Versiones: 1.14.3 y 1.14.4

Síntomas: Si no tienes el rol de administrador de instancias de Harbor, verás un error de permiso en el recurso de copia de seguridad al consultar la página Harbor Container Registry en la consola de GDC. Este error se muestra porque la información de la copia de seguridad se ha añadido recientemente a la página Harbor Container Registry, pero no se ha concedido el permiso de lectura del recurso de copia de seguridad a los roles de gestión de identidades y accesos que no sean el administrador de instancias de Harbor.

Los demás elementos de la consola de GDC de la página Harbor Container Registry siguen funcionando correctamente. Para obtener más información sobre los roles en GDC, consulta Definiciones de roles.

La página de rotación de contraseñas de la base de datos no se carga

Versiones: 1.14.3, 1.14.4, 1.14.5 y 1.14.6

Síntomas: se producen errores relacionados con la autenticación de solicitudes a la base de datos, como failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), y se presentan muchas solicitudes de rotación generadas automáticamente para un único secreto rotatorio.

Solución alternativa: elimina las solicitudes de rotación adicionales que no estén listas de un secreto que se pueda rotar.

1. Define KUBECONFIG en el servidor de la API de mp.

2. Exporta el espacio de nombres:

   NAMESPACE=haas-system
   

3. Comprueba si hay secretos rotables en haas-system que no estén listos:

   kubectl get rotatablesecrets -n ${NAMESPACE?}
   

   La salida podría tener este aspecto:

   NAME                        CREDENTIALID   READY     AGE
   haasdb-pw-ar-test           HAAS-0002      True      109d
   haasdb-pw-gardener-harbor   HAAS-0002      True      178d
   haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
   haasdb-pw-myinstance        HAAS-0002      True      80d
   haasdb-pw-osd               HAAS-0002      True      158d
   haasdb-pw-saptest           HAAS-0002      True      91d
   

4. Exporta el nombre del secreto rotatorio. Por ejemplo:

   ROTATABLE_SECRET=haasdb-pw-haas-alice
   

5. Elimina las solicitudes de rotación adicionales que no estén listas:

   CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')
   
   kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}
   

Módulo de seguridad de hardware

Las licencias de prueba desactivadas de HSM siguen siendo detectables

Versiones: 1.14.3, 1.14.4 y 1.14.5

Síntomas: debido a un problema conocido de CipherTrust Manager, las licencias de prueba desactivadas siguen siendo detectables y pueden activar advertencias de vencimiento falsas.

Solución alternativa: consulta el error HSM-R0003 para verificar las licencias normales activas y eliminar las licencias de prueba desactivadas.

Fuga de descriptores de archivo del host-daemon de HSM

Versiones: 1.14.x

Síntomas: si los HSMs se ejecutan durante más de 30 días, se puede producir una fuga de descriptores de archivos que provoque que el servicio host-daemon deje de responder, lo que dará lugar a un error ServicesNotStarted.

Solución alternativa: reinicia el servicio host-daemon. Para ello, pide a tu operador de infraestructura que se conecte al HSM a través de SSH como usuario ksadmin y ejecute el siguiente comando:

sudo systemctl restart host-daemon

Si no funciona, tu IO puede reiniciar el HSM en mal estado.

Los HSMs fallan con el error ValidateNetworkConfig después del arranque

Versiones: 1.14.x

Síntomas: los recursos personalizados de HSM no entran en el estado Ready y fallan debido a un error ValidateNetworkConfig. Este error muestra el siguiente mensaje: data0 interface MAC address {} is not active. Este error se produce si se reinicia el sistema y se establece una interfaz de datos principal diferente.

Solución alternativa: sigue el manual de operaciones HSM-R0059 y vuelve a aplicar la configuración de red del HSM a la red de datos. Este runbook se puede seguir aunque más de un HSM tenga este error.

PROBABILIDADES DE RENOVACIÓN

Alertas de objetivos de nivel de servicio falsas

Versiones: 1.14.3

Síntomas: un SLO de successRange se activa de forma errónea.

Solución alternativa: pide al operador de infraestructura que verifique si la alerta es un problema real o una falsa alarma.

Para ello, cuando se active una alerta, sigue el runbook correspondiente para solucionar la causa subyacente de la alerta del objetivo de nivel de servicio.

1. Caso 1: Si el runbook resuelve el problema correctamente y la alerta deja de activarse, el operador puede cerrar la incidencia asociada.

2. Caso 2: Si se completa el runbook, pero la alerta sigue activándose, significa que puede tratarse de una falsa alarma. Comprueba si el SLO no se cumple:

   kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'
   

3. Según el resultado, si se confirma que la alerta es una falsa alarma, el IO debe silenciar la alerta en la instancia aislada de GDC. De lo contrario, debe derivar el problema al equipo de Asistencia de Google Cloud.

4. En cualquier caso, es adecuado que el IO derive el problema al equipo de Asistencia de Cloud para verificar que el componente operativo funciona correctamente.

Configuraciones de SLO basadas en métricas de tipo Gauge no válidas

Versiones: 1.14.3 y 1.14.4

Síntomas: un subconjunto de objetivos de nivel de servicio (SLOs) no se rellena con eventos buenos, malos o totales debido a un error de configuración. Los SLOs en cuestión se basan en los gauges de Prometheus y deben configurarse en consecuencia.

Solución:

Versión 1.14.3: no hay ninguna solución alternativa. Por lo tanto, las alertas de objetivo de nivel de servicio no se activarán para los objetivos de nivel de servicio afectados.

Versión 1.14.4: hay una solución alternativa para corregir el SLO. Para solucionar este problema, el ajuste isGauge: true debe aplicarse a la especificación del SLO.

Ejemplo de configuración de un indicador de un SLO:

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

La lista de SLOs conocidos que se corrigen con este ajuste es la siguiente:

• SLOs de cortafuegos:
  • fw-packet-discard-errors-slo
  • fw-packet-discard-no-error-slo
  • fw-packet-discard-unknown-protocol-slo
  • fw-uptime-slo
• Objetivos de nivel de servicio de archivos:
  • file-ontap-appliance-availability-slo
  • file-ipsec-networking-availability-slo
  • file-ontap-networking-availability-slo
  • file-iscsi-client-availability-slo
  • file-multipath-client-availability-slo
  • file-trident-client-availability-slo

Gestión de identidades y accesos

No se ha podido crear la vinculación de roles de gestión de identidades y accesos

Versiones: 1.14.3

Síntomas: el sistema genera los nombres de las vinculaciones de roles de gestión de identidades y accesos. Estos nombres tienen una longitud máxima de 63 caracteres y el formato user-idp-prefix-rolename. En los casos en los que el nombre generado supera el límite de 63 caracteres, no se pueden crear las vinculaciones de roles. Por lo tanto, los permisos definidos mediante roles predefinidos o personalizados no se asignarán a los usuarios.

Solución alternativa: la creación de la vinculación de roles puede completarse correctamente si el nombre del rol predefinido o personalizado es muy corto (por ejemplo, de 4 a 5 caracteres).

No se ha podido crear el enlace de rol de gestión de identidades y accesos para las cuentas de servicio del proyecto

Versiones: 1.14.3, 1.14.4, 1.14.5 y 1.14.6

Síntomas: Una cuenta de servicio de proyecto (PSA) con el rol organization-iam-admin no puede usar el comando gdcloud projects add-iam-policy-binding para asignarse otro rol, como el rol project-iam-admin. Esta deficiencia impide que un PSA gestione sus propios permisos.

Solución alternativa: Comprueba que tienes el rol organization-iam-admin. A continuación, asígnate el rol project-iam-admin en el espacio de nombres del proyecto del PSA de destino y asigna el rol project-iam-admin al PSA. Esta configuración de permisos permite que el PSA se asigne permisos adicionales a sí mismo o a otros PSAs.

Los proyectos nuevos experimentan retrasos en la creación de roles predefinidos

Versiones: 1.14.3

Síntomas: Cuando se crea un proyecto, faltan los roles predeterminados, como project-bucket-object-admin.

Solución alternativa: espera entre 15 y 60 minutos o reinicia manualmente el controlador iam-org-admin-cm-backend-controller en el espacio de nombres iam-system del clúster de infraestructura de la organización.

La consola de GDC no puede crear la primera vinculación de roles

Versiones: 1.14.4

Síntomas: al crear la primera vinculación de rol para una nueva identidad de servicio con la consola de GDC, se indica que la creación de la vinculación de rol se ha completado correctamente, pero no funciona. Cualquier otra acción que se realice en la identidad de servicio fallará y no tendrá ningún efecto, como añadir o eliminar enlaces de roles.

Solución alternativa: usa la CLI de gdcloud para crear la primera vinculación de rol de una identidad de servicio. Todas las acciones futuras que se realicen con la identidad de servicio mediante la consola de GDC funcionarán correctamente después de que se adjunte la primera vinculación de roles. Para obtener más información, consulta Asignar un enlace de rol a la identidad de servicio.

Los AOs no pueden concederse acceso a roles en el clúster de infraestructura

Versiones: 1.14.3. 1.14.4

Corregido: 1.14.3 hotfix 21

Síntomas: los AOs no pueden concederse a sí mismos ni a ningún otro usuario acceso a ningún rol del clúster de infraestructura.

Solución: Los usuarios de la cuenta de administrador deben ponerse en contacto con los IOs para obtener el acceso necesario. Los IOs pueden usar IAC para proporcionar a los usuarios de AO el acceso necesario.

El token de la cuenta de servicio deja de ser válido

Versiones: 1.14.3

Corregido: 1.14.3 hotfix 21

Síntomas: el token de cuenta de servicio emitido por el clúster de usuario deja de ser válido porque se cambia el argumento service-account-issuer apiserver después de que el clúster esté en estado de ejecución tras el arranque. Este problema provoca que el pod (por ejemplo, el pod con un contenedor sidecar istio-proxy) del clúster de usuario no pueda autenticarse con el token de la cuenta de servicio y que el token de la cuenta de servicio tarde horas en actualizarse con las nuevas configuraciones.

Solución: Reinicia manualmente el pod en el clúster de usuario para que el token de la cuenta de servicio se renueve con las nuevas configuraciones.

Infraestructura como código (IaC)

Error de conciliación de subcomponentes debido a que falta un espacio de nombres

Versiones: 1.14.3

Síntomas: no se puede conciliar un subcomponente. Esto ocurre porque el espacio de nombres config-management-monitoring necesario no se crea automáticamente en el clúster gdchservices-mp.

Solución alternativa: Crea el espacio de nombres config-management-monitoring en el clúster gdchservices-mp con el siguiente manifiesto:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

Falla la recogida de métricas de IAC ConfigSync

Versiones: 1.14.3 y 1.14.4

Síntomas: un problema en el subsistema de monitorización de Config Sync de IAC impide que se inicie el despliegue de otel-collector. Las métricas de Config Sync no se recogen para la monitorización y las alertas.

Solución alternativa: completa los siguientes pasos en el clúster root-admin:

1. Pausa el iac-configsync-monsubcomponente.
2. Edita el objeto MetricsProxySidecar/iac-configsync-metrics en el espacio de nombres config-management-monitoring.

3. En el archivo MetricsProxySidecar/iac-configsync-metrics YAML, busca lo siguiente:

   spec:
     [...]
     destinations:
     - certificate:
         secretName: iac-configsync-mon-target-cert
   

   Cambia esta sección por la siguiente:

   spec:
     [...]
     destinations:
     - certificate:
         secretName: iac-configsync-mon-mon-target-cert
   

4. Reinicia la implementación de otel-collector en el espacio de nombres config-management-monitoring.

Falla de RootSync de IAC

Versiones: 1.14.3

Síntomas: hay un problema en los recursos de sincronización de Config Sync de Gitlab a los clústeres debido a que falta un secreto de iac-creds . Los iac-creds no se rotan debido a un problema de iacmanager.

Solución alternativa: completa los siguientes pasos en el clúster:

1. Sigue el manual de procedimientos IAC-R0015 para resolver el problema de la falta de la credencial secreta iac. Rota las credenciales del gestor de IaC y de Config Sync.

Inventario

No se puede conciliar la auditoría de inventario

Versiones: 1.14.3

Síntomas: El subcomponente inv-audit no se puede conciliar, ya que HarborRobotAccount solo está disponible en el plano de gestión.

Solución alternativa: crea un silencio en AlertManager para silenciar la alerta component_reconciliation_errors durante component: inv.

Sistema de gestión de claves

KMS configurado para usar una clave raíz de CTM no conmuta por error cuando un HSM no está disponible

Versiones: 1.14.x

Síntomas: se produce un error en algunas solicitudes al KMS cuando un HSM no está disponible y hay otros HSMs disponibles que se podrían haber utilizado. Este problema solo se produce cuando el KMS está configurado para usar una clave raíz de CTM.

Solución: Elimina el HSM no disponible del HSMCluster siguiendo el runbook HSM-P0006. A continuación, reinicia la implementación de kms-backend:

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

Este comando reinicia los pods kms-backend y restablece la conexión con los HSMs del HSMCluster.

Balanceadores de carga

No se puede crear un balanceador de carga global debido a que se ha agotado el CIDR de subred

Versiones: 1.14.3

Síntomas: no se puede crear un balanceador de carga externo o interno global debido a que no hay suficientes direcciones IP en las subredes globales. El sistema no puede asignar direcciones IP de forma dinámica a los balanceadores de carga globales debido a un controlador que usa una ruta de código incorrecta. El balanceador de carga solo hace referencia a una subred y, si esa subred no tiene más direcciones IP disponibles, no hay forma de cambiar a otra subred. Esta limitación provoca que se muestre el error.

Solución: Debes crear tu propia subred y direcciones IP estáticas para tus recursos de ForwardingRule. Para obtener más información sobre cómo crear subredes, consulta Configurar subredes para redes de cargas de trabajo. Cuando creas un recurso ForwardingRule, puedes especificar la subred en el campo cidrRef.

Versiones: 1.14.3

Síntoma: los objetos del balanceador de carga no entran en el estado Ready.

Solución alternativa: debe crear recursos Backend en los que el campo spec tenga un valor. Los recursos Backend identifican los endpoints del balanceador de carga. Si no se proporciona un valor para el campo spec, se pueden producir errores.

La modificación de los recursos del balanceador de carga no reconcilia los servicios

Versiones: 1.14.3

Síntomas: al modificar los recursos personalizados del balanceador de carga, no se reconcilian los servicios del balanceador de carga.

Solución alternativa: Para mitigar este problema, elimine y vuelva a crear el balanceador de carga eliminando los recursos BackendService y ForwardingRule de ese balanceador de carga.

No se rechazan los nombres de zonas incorrectos

Versiones: 1.14.3

Síntomas: El recurso global BackendService no rechaza los nombres de zona incorrectos. Si el nombre de la zona es incorrecto, el balanceador de carga fallará en lugar de validar y rechazar la configuración.

Solución alternativa: debe proporcionar los nombres correctos de las zonas que se estén usando. Si el balanceador de carga está configurado incorrectamente, los recursos personalizados del balanceador de carga deben eliminarse y volver a crearse.

Error de webhook de balanceador de carga global y de zona

Versiones: 1.14.3

Síntomas: se devuelve el siguiente error:

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

Solución alternativa: para mitigar este problema, reinicia y elimina el pod unet-global-cm:

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

Almacenamiento de registros

Loki pod falla o se cierra por falta de memoria durante la reproducción de WAL

Versiones: 1.14.3, 1.14.4 y 1.14.5

Síntomas:

Los pods audit-logs-loki-io del espacio de nombres obs-system pasan al estado CrashLoopBackOff. Esto se debe a errores prematuros de la comprobación de actividad o a la finalización por falta de memoria durante la reproducción del registro Write-Ahead Log (WAL), debido a un valor de wal_replay_ceiling que supera el límite de memoria del pod.

Solución:

Sigue estos pasos para ajustar la configuración de Loki y permitir que se reproduzca el WAL correctamente. Los cambios se deben aplicar al clúster afectado (por ejemplo, root-admin o org-infra).

1. Define KUBECONFIG=/path/to/affected-cluster.kubeconfig como variable de entorno.

2. Pausa LoggingPipelineReconciler para evitar que el mando deshaga los cambios manuales. Aplica este archivo de manifiesto:

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: log-logging-pipeline-pause
     namespace: root
   spec:
     subComponentRef: "log-admin"
     backend:
       operableParameters:
         controller:
           disableReconcilers: "LoggingPipelineReconciler"
   

   Confirma que la anulación está activa. El resultado debe incluir "disable-reconcilers=LoggingPipelineReconciler".

   kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq
   

3. Reduce el replay_memory_ceiling del ConfigMap audit-logs-loki-io-cm a 8GB.

   kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}
   

   Modifica la sección wal:

   [...]
     wal:
       replay_memory_ceiling: 8GB ## <-- Change to 8GB
   [...]
   

4. Opcional: Escala el proxy del objeto. Si los pods de obj-proxy están cerca de alcanzar sus límites de recursos, escala la implementación para gestionar el aumento de carga durante la recuperación.

   a. Comprobar el uso de recursos:

   kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
   

   b. Si el uso es alto, escala la implementación:

   kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
   

   c. También puedes aumentar el límite de memoria del pod (por ejemplo, de 12000Mi a 16000Mi) si es necesario.

5. Aumenta el tamaño del PVC del pod afectado (por ejemplo, loki-storage-audit-logs-loki-io-0 de 70Gi a 75Gi) para evitar la presión del disco. Sigue el procedimiento interno SUPP-R001 para cambiar el tamaño del PVC. El reinicio del paso siguiente aplica el nuevo tamaño.

6. Añade un startupProbe al audit-logs-loki-io StatefulSet para que haya tiempo para la reproducción de WAL antes de que empiecen las comprobaciones de actividad. Al guardar el cambio, se reiniciarán los pods de forma gradual (entre 5 y 10 minutos).

   kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
   

   Añade este startupProbe a la especificación del contenedor audit-logs-loki-io:

   startupProbe:
     failureThreshold: 1000
     httpGet:
       path: /ready
       port: loki
       scheme: HTTP
     periodSeconds: 10
     successThreshold: 1
     timeoutSeconds: 10
   

Verificar la solución alternativa

1. Comprueba el estado de los pods y los StatefulSets: verifica que todos los pods audit-logs-loki-io estén Running y que el StatefulSet muestre todas las réplicas como listas.

   kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
   kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}
   

2. Confirma que se ha cambiado el tamaño del PVC. El resultado esperado es 75Gi.

   kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo
   

3. Confirma que la recuperación de WAL se ha completado correctamente comprobando los registros del pod en busca de mensajes errors=false.

   kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
   

4. Comprueba que el uso del directorio /wal dentro del pod sea bajo.

   kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal
   

5. Comprobar el estado del Loki Ring:

   a. Redirige los puertos del servicio de Loki:

   DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
   kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}
   

   b. Comprueba que todas las instancias estén en buen estado en http://<DATA_IP>:43100/ring.

Limpiar la anulación y el proxy de objeto

Una vez que se haya completado la verificación, sigue estos pasos para limpiar los datos.

1. Elimina la anulación del subcomponente:

   kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}
   

2. Si has aumentado la escala de la implementación de obj-proxy, vuelve a su tamaño original.

Supervisión

Los webhooks de AlertManager no envían alertas de algunos clústeres

Versión: 1.14.3

Síntomas: los webhooks de AlertManager no envían solicitudes ni notificaciones de alertas a ServiceNow desde ningún clúster que no sea el clúster de administrador raíz o el clúster en el que se encuentra la instancia de ServiceNow. Por lo tanto, no se crean alertas en ServiceNow para la organización.

Puedes identificar que el webhook no envía alertas si recibes mensajes de registro de errores repetidamente. Sigue estos pasos para buscar errores repetidos:

1. Exporta las variables de entorno:

   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   

   Sustituye MGMT_API_KUBECONFIG por la ruta al archivo kubeconfig del servidor de la API Management.

2. Busca el pódcast:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
     -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-
   

3. Obtén los registros:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system
   

   Sustituye POD_NAME por el nombre del pod.

4. Busca errores repetidos que tengan un aspecto similar al siguiente:

   Errorsendingtherequest ... read: connection reset by peer
   

Nota: Los errores que incluyen CHANGE_ME indican que no se ha configurado este webhook. Este problema solo se produce en los clústeres que no tienen una instancia de ServiceNow.

Solución alternativa: la solución alternativa recomendada para este problema es pausar dos subcomponentes: uno para las alertas de metamonitorización y otro para las alertas normales. A continuación, sustituya la etiqueta egress.networking.gke.io/enabled: "true" por networking.private.gdc.goog/infra-access: enabled en la implementación de mon-alertmanager-servicenow-webhook-backend del clúster afectado. Esta etiqueta permite que el pod se comunique con otros clústeres de infraestructura sin depender de una pasarela de salida.

Sigue estos pasos para aplicar la solución alternativa recomendada:

1. Exporta las variables de entorno:

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   export ORG=ORG
   

   Haz los cambios siguientes:

   • ROOT_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador raíz.
   • MGMT_API_KUBECONFIG: la ruta al archivo kubeconfig del servidor de la API Management.
   • ORG: el espacio de nombres de la organización.

2. Pausar subcomponentes:

   • Pausa el subcomponente mon-alertmanager-servicenow-webhook:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
     -n "${ORG}" lcm.private.gdc.goog/paused=true
   

   • Pausa el subcomponente mon-meta-monitoring:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
     -n "${ORG}" lcm.private.gdc.goog/paused=true
   

3. Actualiza la implementación de mon-alertmanager-servicenow-webhook-backend que abarca la mayoría de las alertas:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
     -n mon-system mon-alertmanager-servicenow-webhook-backend
   

4. Sustituye la etiqueta de spec.template.metadata.labels por networking.private.gdc.goog/infra-access: "enabled" en lugar de egress.networking.gke.io/enabled: "true".

5. Actualiza la meta-alertmanager-servicenow-webhook implementación que cubre las alertas relacionadas con la pila de monitorización:

   kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
     -n mon-system meta-alertmanager-servicenow-webhook
   

6. Sustituye la etiqueta de spec.template.metadata.labels por networking.private.gdc.goog/infra-access: "enabled" en lugar de egress.networking.gke.io/enabled: "true".

También puedes usar Grafana para ver las mismas alertas.

Los incidentes de ServiceNow se duplican ocasionalmente

Versión: 1.14.3

Síntomas: es posible que veas incidentes duplicados de ServiceNow para el mismo pod.

Solución alternativa: puedes identificar las incidencias duplicadas comparando las huellas digitales de la descripción de la incidencia.

Las métricas de infraestructura pueden ser demasiado sensibles

Versión: 1.14.3

Síntomas: es posible que veas alarmas de la alerta oclcm-reconciler-success-rate.

Solución: Puedes silenciar la alerta sin problema. Se trata de una alerta demasiado ruidosa y estamos trabajando para mejorar la señal.

Las métricas de conciliación pueden ser demasiado sensibles

Versión: 1.14.3, 1.14.4 y 1.14.5

Síntomas: es posible que veas alarmas de la alerta component_reconciliation_errors.

Solución alternativa: Puedes silenciar la alerta de forma segura siguiendo el runbook MON-R2009. Esta alerta es demasiado ruidosa.

Hay dos alertas falsas abiertas en el clúster de administrador raíz

Versión: 1.14.3

Síntomas: las alertas MON-A0001_slow y MON-A0001_fast están activadas en el clúster de administrador raíz.

El incidente de ServiceNow tiene un aspecto similar al siguiente ejemplo:

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

El incidente tiene la siguiente descripción:

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

Nota: El campo u_organization_id muestra el valor root, pero el clúster de la descripción es ORG_NAME-admin. Puedes encontrar la alerta en la instancia de Grafana del clúster de administrador raíz.

Solución alternativa: sigue estos pasos para resolver el problema solo en el clúster de administrador raíz:

1. Elimina la etiqueta monitoring.gdc.goog/metamonitoring-project=mon-system de la mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

2. Elimina todas las reglas de grabación con el nombre mon_metrics_pipeline_absent y el valor de la etiqueta de clúster ORG_NAME-admin de mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

   En el siguiente ejemplo se muestra una regla de registro mon_metrics_pipeline_absent que se va a eliminar:

   Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
       Labels:
         _source_project:  blackbox-monitoring-obs-system
         Cluster:          gdchservices-admin
         Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
       Record:             mon_metrics_pipeline_absent
   

Las alertas MON_A0001_slow y MON_A0001_fast vuelven al estado Normal al cabo de unos minutos (unos 40 minutos).

El gestor de controladores de administrador raíz muestra una tasa de errores alta

Versión: 1.14.3

Síntomas: es posible que veas alarmas de la alerta ControllerReconciliationErrorRateHigh. El gestor de controladores mostrará registros que dicen: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Solución: Puedes inhabilitar el controlador que da error sin problema.

1. Exporta las variables de entorno:

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   

2. Edita el despliegue del gestor de controladores de administrador raíz:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
     -n gpc-system root-admin-controller
   

   En el contenedor manager, si aún no hay ningún argumento --disable-reconcilers, añade uno con el valor --disable-reconcilers=ApplianceStorageTunnelReconciler. Si es así, añade el ApplianceStorageTunnelReconciler reconciliador con una coma. Por ejemplo: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler

Los registros de errores deberían borrarse.

Los paneles de control de KUB no muestran datos en todos los paneles de PA

Versiones: 1.14.3

Síntomas: los paneles de control de KUB no muestran datos en todos los paneles de Grafana para los administradores de la plataforma.

Solución alternativa: pausa el subcomponente KSM y actualiza monitoringtarget y metricsproxysidecar:

1. Pausa el subcomponente:

   export SUBCOMPONENT_NAME=mon-kube-state-metrics
   export SUBCOMPONENT_NAMESPACE=ORG_NAME
   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true
   

   Haz los cambios siguientes:

   • ORG_NAME: el nombre de la organización
   • ROOT_ADMIN_KUBECONFIG: la ruta al archivo root-admin kubeconfig

2. Añada lo siguiente a mon-kube-state-metrics-metrics-proxy metricsproxysidecar en la sección .spec.destinations:

     - certificate:
     secretName: mon-pa-kube-state-metrics-cert
   port: 8091
   

   La métrica actualizada proxysidecar podría tener el siguiente aspecto:

   ...
   spec:
     containerName: otel-collector
     destinations:
     - certificate:
         secretName: mon-io-kube-state-metrics-cert
       port: 8090
     - certificate:
         secretName: mon-pa-kube-state-metrics-cert
       port: 8091
     resources:
       limits:
   ...
   

3. Elimina la sección matchClusters: del mon-pa-kube-state-metrics monitoringtarget spec. El mon-pa-kube-state-metrics monitoringtarget spec actualizado podría tener este aspecto:

   ...
   spec:
     podMetricsEndpoints:
       metricsRelabelings:
       - action: replace
         replacement: platform-obs
         targetLabel: _gdch_project
       path:
         value: /metrics
       port:
         value: 8091
       scheme:
         value: http
       scrapeInterval: 60s
       scrapeTimeout: 45s
     selector:
       matchLabels:
         monitoringtarget: mon-kube-state-metrics
   

Permisos mal configurados para el rol observability-admin-debugger

Versiones: 1.14.3 y 1.14.4

Síntomas: los IOs no pueden reiniciar los pods de Cortex o Prometheus en el espacio de nombres mon-system.

Solución:

Para organizaciones:

1. Pausa el iam-commonsubcomponente.

2. Actualiza el observability-admin-debugger/iam-system roleTemplate de la siguiente manera:

   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: RoleTemplate
   metadata:
     name: observability-admin-debugger
     namespace: iam-system
   spec:
     metadata:
       roleType: predefined
       hierarchyLevel: org
       persona: infra-operator
       displayName: "Observability Admin"
       bindingType: rolebinding
       roleNamespace: "mon-system"
       operableComponent: IAM
     rules:
     - apiGroups:
       - "apps"
       resources:
       - "deployments"
       resourceNames:
       - "logmon-operator"
       - "cortex-tenant"
       - "meta-blackbox-exporter"
       - "blackbox-exporter"
       verbs:
       - "*"
     - apiGroups:
       - "apps"
       resources:
       - "statefulsets"
       resourceNames:
       - "anthos-prometheus-k8s"
       - "meta-prometheus"
       - "mon-prober-backend-prometheus"
       - "primary-prometheus-shard0-replica0"
       - "primary-prometheus-shard0-replica1"
       - "primary-prometheus-shard1-replica0"
       - "primary-prometheus-shard1-replica1"
       verbs:
       - "*"
     - apiGroups:
       - ""
       resources:
       - "secrets"
       resourceNames:
       - "anthos-prometheus-scrape-cert"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       - "anthos-prometheus-etcd-scrape"
       verbs:
       - "*"
     - apiGroups:
       - "cert-manager.io"
       resources:
       - "certificates"
       resourceNames:
       - "anthos-prometheus-scrape"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       verbs:
       - "get"
       - "list"
       - "watch"
   

Para el administrador raíz:

1. Pausa el iam-commonsubcomponente.

2. Actualiza el observability-admin-debugger-root/iam-system roleTemplate de la siguiente manera:

   apiVersion: iam.private.gdc.goog/v1alpha1
   kind: RoleTemplate
   metadata:
     name: observability-admin-debugger
     namespace: iam-system
   spec:
     metadata:
       roleType: predefined
       hierarchyLevel: org
       persona: infra-operator
       displayName: "Observability Admin"
       bindingType: rolebinding
       roleNamespace: "mon-system"
       operableComponent: IAM
     rules:
     - apiGroups:
       - "apps"
       resources:
       - "deployments"
       resourceNames:
       - "logmon-operator"
       - "cortex-tenant"
       - "meta-blackbox-exporter"
       - "blackbox-exporter"
       verbs:
       - "*"
     - apiGroups:
       - "apps"
       resources:
       - "statefulsets"
       resourceNames:
       - "anthos-prometheus-k8s"
       - "meta-prometheus"
       - "mon-prober-backend-prometheus"
       - "primary-prometheus-shard0-replica0"
       - "primary-prometheus-shard0-replica1"
       - "primary-prometheus-shard1-replica0"
       - "primary-prometheus-shard1-replica1"
       verbs:
       - "*"
     - apiGroups:
       - ""
       resources:
       - "secrets"
       resourceNames:
       - "anthos-prometheus-scrape-cert"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       - "anthos-prometheus-etcd-scrape"
       verbs:
       - "*"
     - apiGroups:
       - "cert-manager.io"
       resources:
       - "certificates"
       resourceNames:
       - "anthos-prometheus-scrape"
       - "kube-control-plane-metrics-proxy-cert"
       - "metrics-consumers-ca"
       - "metrics-providers-ca"
       verbs:
       - "get"
       - "list"
       - "watch"
   

Falta el rol de depurador de Grafana

Versiones: 1.14.3 y 1.14.4

Síntomas: El rol grafana-debugger-cp no está presente en los espacios de nombres del proyecto de sombra de observabilidad (*-obs-system). No se puede conceder a los usuarios el conjunto correcto de permisos necesarios para depurar problemas relacionados con Grafana.

Solución alternativa: crea el siguiente recurso personalizado ClusterRoleTemplate en infra-cp y usa el ClusterRole correspondiente que se crea para obtener los permisos de grafana-debugger.

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

Las métricas y los registros entre zonas no se ven después de añadir una zona

Versiones: 1.14.*

Síntomas: el panel de control de Grafana no muestra los registros ni las métricas de la zona recién añadida.

Solución alternativa 1: reinicia la implementación de datasource-proxy:

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

De esta forma, se reiniciarán los pods de datasource-proxy y se actualizará la configuración de los endpoints entre zonas de la zona recién añadida.

El finalizador MonitoringTarget impide que se elimine el espacio de nombres

Versiones: 1.14.3 y 1.14.4

Síntomas: El espacio de nombres no se elimina y hay clústeres incorrectos en la organización correspondiente.

Solución alternativa: elimina manualmente los finalizadores de los recursos personalizados MonitoringTarget que han bloqueado la eliminación del espacio de nombres.

La eliminación de un proyecto se bloquea porque hay finalizadores pendientes en el panel de control y en la fuente de datos

Versiones: 1.14.3 y 1.14.4

Corregido: 1.14.3 hotfix 22

Síntomas: los proyectos no se eliminan y el espacio de nombres de finalización tiene errores, como en el siguiente ejemplo:

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

Solución: Elimina manualmente los finalizadores del panel de control y de la fuente de datos.

No se ven las métricas de KSM

Versiones: 1.14.3

Corregido: 1.14.3 hotfix 22

Síntomas: los paneles de control de KUB muestran No Data en todos los paneles.

Solución: Pausa el subcomponente KSM y actualiza monitoringtarget y metricsproxysidecar.

1. Subcomponente de pausa:

   export SUBCOMPONENT_NAME=mon-kube-state-metrics
   export SUBCOMPONENT_NAMESPACE=ORG_NAME
   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true
   

   Haz los cambios siguientes:

   • ORG_NAME: el nombre de la organización.
   • ROOT_ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del administrador raíz.

2. Añade lo siguiente a mon-kube-state-metrics-metrics-proxy metricsproxysidecar en .spec.destinations:

   - certificate:
     secretName: mon-pa-kube-state-metrics-cert
   port: 8091
   

   La métrica mon-kube-state-metrics-metrics-proxymetricsproxysidecar actualizada tiene el siguiente aspecto:

   ...
   spec:
     containerName: otel-collector
     destinations:
     - certificate:
         secretName: mon-io-kube-state-metrics-cert
       port: 8090
     - certificate:
         secretName: mon-pa-kube-state-metrics-cert
       port: 8091
     resources:
       limits:
   ...
   

3. Elimina la sección matchClusters: de la especificación mon-pa-kube-state-metrics monitoringtarget. La especificación mon-pa-kube-state-metrics monitoringtarget actualizada tiene este aspecto:

   ...
   spec:
     podMetricsEndpoints:
       metricsRelabelings:
       - action: replace
         replacement: platform-obs
         targetLabel: _gdch_project
       path:
         value: /metrics
       port:
         value: 8091
       scheme:
         value: http
       scrapeInterval: 60s
       scrapeTimeout: 45s
     selector:
       matchLabels:
         monitoringtarget: mon-kube-state-metrics`
   

La canalización de métricas del sistema no funciona

Versión: 1.14.3

Síntomas: La alerta MON-A0001 está activa incluso después de seguir el manual de instrucciones MON-R0001.

Solución alternativa:

1. Si el problema se produce en el clúster de administrador, crea el siguiente SubcomponentOverride en root-admin con el runbook IAC-R0004. Para otros clústeres, como el de usuario, perímetro o compartido, crea el SubcomponentOverride en ${ORG}-mp.

   kind: SubcomponentOverride
   metadata:
     name: mon-cortex-tenant
     namespace: <NAMESPACE>
   spec:
     backend:
       operableParameters:
         concurrency: 1024
         resourcesLimit:
           cpu: "8"
           memory: 16Gi
     subComponentRef: mon-cortex-tenant
   

2. Busca el NAMESPACE correcto:

   kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"
   

   El resultado es el siguiente:

   org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
   org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
   root                 mon-cortex-tenant                      47h   ReconciliationCompleted
   

   El espacio de nombres es la raíz si la canalización está inactiva para root-admin, o bien org-1 si la canalización está inactiva para org-1 admin:

   kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"
   

   El resultado es el siguiente:

   g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
   g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
   user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
   user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
   

   En este caso, el espacio de nombres correcto podría ser g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster o user-vm-2-cluster, en función del clúster para el que esté inactivo el flujo de procesamiento de métricas del sistema.

3. Después de aplicar el SubcomponentOverride, reinicia la implementación de cortex-tenant en los clústeres correspondientes. Comprueba si los valores se han actualizado en el clúster correspondiente:

   kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
   

4. Actualiza el campo de simultaneidad.

5. Reinicia las implementaciones de cortex-tenant:

   kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system
   

Arquitectura multicliente

La consola no indica los fallos de creación de grupos de nodos

Versión: 1.14.4, 1.14.5 y 1.14.6

Corregido: 1.14.7

Síntomas: en la consola de GDC, cuando no se puede crear un grupo de nodos, la interfaz de usuario muestra incorrectamente un mensaje creation in progress que indica que el grupo de nodos se ha creado correctamente.

Solución alternativa: usa la CLI gdcloud para validar la creación del grupo de nodos.

Multizona

La zona inaccesible redirige a la página de autenticación

Versión: 1.14.x

Síntomas: cuando no se puede acceder a una zona, la consola de GDC redirige a una página que muestra un error de autenticación. Sin embargo, es posible que la inaccesibilidad de la zona no se deba a un problema de autenticación, sino a una interrupción zonal.

Solución: utilice la URL zonal para solucionar el problema. Si la URL zonal tampoco funciona, pide a tu operador de infraestructura que determine si la zona en la que tienes problemas de autenticación está inactiva.

No se aplica el rol para ver zonas con la CLI de gdcloud

Versión: 1.14.x

Síntomas: El rol de gestión de identidades y accesos necesario para usar el comando gdcloud zones list no se aplica al universo de GDC de forma predeterminada. El rol que falta, que no está disponible como rol predefinido, impide usar la CLI de gdcloud para enumerar las zonas.

Solución alternativa: aplica el rol de gestión de identidades y accesos global-zone-viewer y los recursos de enlace de roles al servidor de la API global:

1. Crea un archivo YAML de rol, como global-zone-viewer.yaml, con el siguiente contenido:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: global-zone-viewer
     namespace: mz-system
   rules:
   - apiGroups:
     - location.mz.global.private.gdc.goog
     resources:
     - zones
     verbs:
     - get
     - list
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: global-zone-viewer-binding
     namespace: mz-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: global-zone-viewer
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

2. Aplica el archivo YAML al servidor de la API global de la organización:

   kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml
   

Esta vinculación de rol autentica a todos los usuarios del sistema para ver las zonas mediante gdcloud zones list.

Errores intermitentes de inicio de sesión en la URL de la consola global

Versiones: 1.14.x

Síntomas: al iniciar sesión en la consola de GDC con la URL global, es posible que recibas errores que indiquen que tu sesión ya no es válida. Este error puede deberse a un error de red subyacente y no a una representación precisa del estado de tu sesión.

Solución: inicia sesión en la consola de GDC con las URLs zonales para gestionar los recursos globales de cada zona. Para obtener más información sobre cómo cambiar de contexto de zona desde la consola de GDC, consulta Gestionar recursos en varias zonas.

Redes

Ajustar el orden de las zonas de MultiZoneNetworkConfig provoca un error de sustitución de la configuración

Versiones: todas las versiones 1.14.x pueden verse afectadas.

Síntomas:

1. El estado READY de los conmutadores Top of Rack (ToR) es False. Para confirmarlo, ejecuta el siguiente comando:

   kubectl get torswitches -A
   

2. La sustitución de la configuración del interruptor falla y se muestra un error que indica que la entrada ya existe. Esto se puede ver en los registros de sustitución de la configuración del conmutador. El mensaje de error es similar al siguiente:

   % Insertion failed - entry already exists
   

Este problema se debe a que se ha modificado el orden de las zonas en MultiZoneNetworkConfig. El sistema genera números de secuencia para las reglas de listas de acceso de BGP en función de la posición de cada zona en la lista de configuración. Si se cambia el orden de las zonas, el sistema genera nuevas reglas con números de secuencia diferentes que entran en conflicto con las reglas que ya están presentes en el interruptor.

Soluciones:

Para resolver este problema, elimine manualmente la configuración de la lista de acceso de la ruta de AS de BGP en conflicto de cada switch ToR afectado. De esta forma, el sistema puede conciliar y aplicar la configuración correcta.

1. Establece una conexión SSH con cada switch ToR que no esté en estado Ready.

2. Entra en el modo de configuración global:

   config t
   

3. Elimina la configuración de la lista de acceso en conflicto:

   no ip as-path access-list other-zones
   

4. Salir del modo de configuración.

Una vez que se haya ejecutado este comando en todos los conmutadores afectados, el reconciliador aplicará la configuración correcta y los conmutadores pasarán al estado READY.

Config-replace commit expiry

Versiones: todas las versiones 1.14.x pueden verse afectadas.

Síntomas:

Un gran número de listas de control de acceso (LCA) provoca un tiempo de espera al configurar los conmutadores de red. El recurso personalizado BorderLeafSwitch no está en estado Ready y, al establecer una conexión SSH con el interruptor no preparado, se muestra el estado Commit expiry.

Por ejemplo, el siguiente comando muestra el estado:

sh config-replace log verify

El resultado debería ser similar al siguiente:

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

Solución:

En las versiones 1.14.3 o 1.14.7+, edita el recurso personalizado SubcomponentOverride llamado pnet-core-override en el espacio de nombres root y añade un campo httpTimeout a .spec.operableParameters.netDevGW.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

Espera 15 minutos para que la infraestructura de automatización envíe las nuevas configuraciones a los interruptores. Configura la httpTimeout según sea necesario hasta que desaparezcan los mensajes de Commit expiry.

En las versiones 1.14.4, 1.14.5 y 1.14.6, realiza manualmente la sustitución de la configuración y confirma los cambios.

1. Pausar el cambio:

   export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
   export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch
   
   kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"
   

2. Sigue el manual de instrucciones PNET-P0001 para obtener acceso con interruptores.

3. Busca la configuración que quieras sustituir:

   switch-cli# dir | grep new_config
   

4. Completa la sustitución de la configuración:

   switch-cli# configure replace <new_config_file>
   

   Este proceso puede tardar más de cinco minutos.

5. Una vez que config-replace se haya completado correctamente, confirma el cambio:

   switch-cli# configure replace commit
   

6. Reanuda el interruptor:

   kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-
   

Fallo en la implementación con ASN de BGP de 4 bytes

Versiones: 1.14.3 y 1.14.4

Síntomas: al configurar el protocolo de pasarela fronteriza (BGP) con un número de sistema autónomo (ASN) de 4 bytes en los conmutadores de red, se producen errores de configuración. Si no se aplica correctamente la configuración de BGP, es posible que la red de esa zona de GDC no pueda establecer un enrutamiento adecuado, lo que provocaría problemas de conectividad, la imposibilidad de anunciar rutas o una inestabilidad general de la red. Por el momento, no hay ninguna solución alternativa.

Tráfico anycast global bloqueado

Versiones: 1.14.3

Síntomas: las listas de control de acceso (LCA) bloquean el tráfico dirigido a los endpoints anycast globales.

Solución alternativa:

Para solucionar el problema por el que las listas de control de acceso (LCAs) bloquean el tráfico de difusión simultánea global, debes crear un recurso personalizado SubcomponentOverride en el clúster de administrador raíz para permitir explícitamente el tráfico a los bloques CIDR de difusión simultánea del servidor DNS global. Sigue estos pasos:

1. Encuentra todos los bloques CIDR de anycast globales. Para encontrar los bloques CIDR de anycast global que debes actualizar, sigue estos pasos:

   1. Conéctate al servidor de la API global raíz.

   2. Lista todos los recursos personalizados de subredes de todos los espacios de nombres con el siguiente comando:

      kubectl get subnet -A
      

   3. Filtra la salida para encontrar recursos de subred en los que el filtro metadata.name contenga la palabra clave anycast.

   4. Por cada recurso de subred que encuentre con anycast en su nombre, anote el valor de spec.subnet. Este valor representa un bloque CIDR de difusión general global.

2. En el clúster de administrador raíz, crea un SubcomponentOverride recurso personalizado llamado pnet-trafficpolicy-dc-override en el espacio de nombres raíz. Por cada subred de difusión general que haya identificado en el paso anterior, añada las reglas tal como se muestra en el archivo YAML:

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: pnet-trafficpolicy-dc-override
     namespace: root
   spec:
     backend:
       operableParameters:
         breakglassRules:
           default-traffic-policy-data:
           - IPVersions:
             - IPv4
             L4Protocol: IP
             action: Accept
             description: INTERCONNECT_RULE_DESCRIPTION
             destinationEndPoint:
               host:
                 hostPrefix: GLOBAL_ANYCAST_CIDR
               port:
                 portType: ANY
             direction: Ingress
             enforcePoints:
             - enableLogging: false
               enforcePointType: DataInterconnect
             sourceEndPoint:
               host:
                 hostType: ANY
               port:
                 portType: ANY
           - IPVersions:
             - IPv4
             L4Protocol: IP
             action: Accept
             description: HAIRPIN_RULE_DESCRIPTION
             destinationEndPoint:
               host:
                 hostType: ANY
               port:
                 portType: ANY
             direction: Ingress
             enforcePoints:
             - enableLogging: false
               enforcePointType: DataHairpin
             sourceEndPoint:
               host:
                 hostPrefix: GLOBAL_ANYCAST_CIDR
               port:
                 portType: ANY
     subComponentRef: pnet-trafficpolicy-dc
   

   Haz los cambios siguientes:

   • INTERCONNECT_RULE_DESCRIPTION: texto descriptivo de la regla de red de interconexión.
   • GLOBAL_ANYCAST_CIDR: el bloque CIDR de difusión general global, como 136.125.38.128/28. Por cada anycast que encuentres en el paso anterior, crea la regla con este archivo YAML.
   • HAIRPIN_RULE_DESCRIPTION: texto descriptivo de la regla de red de bucle.

Un error parcial de DCI provoca una pérdida de tráfico

Versiones: 1.14.3

Síntomas: cuando los dos enlaces de interconexión de centros de datos (DCI) que conectan el switch de hoja de borde de una zona al switch del operador, o cuando el switch de hoja de borde de una zona sufre un fallo de hardware, se pierde aproximadamente el 50% del tráfico de red entre zonas.

El nombre de la VRF es demasiado largo

Versiones: 1.14.2

Síntomas: es posible que veas un mensaje como este ejemplo, que indica que los interruptores no están en buen estado al ejecutar este comando:

sh config-replace log verify

La salida podría tener este aspecto:

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

Solución alternativa: El nombre del CR de la organización puede tener un máximo de 19 caracteres.

Fallo en la comunicación del pod de StatefulSet

Versiones: 1.14.3 y 1.14.4

Corregido: 1.14.3 hotfix 23, 1.14.5

Síntomas: problemas o interrupciones de conectividad debido a que la eliminación de objetos de endpoint de Cilium (CEP) no se gestiona correctamente después de reiniciar el pod StatefulSet. Esto podría provocar que la identidad del endpoint no gestionado haga que las políticas de red rechacen erróneamente el tráfico legítimo. Los pods afectados se pueden verificar comprobando que no tengan el objeto CEP correspondiente:

kubectl get cep -A | grep [*POD_IP*]

Solución alternativa: reinicia los pods StatefulSet afectados para actualizar su UID y actualizar los metadatos asociados:

kubectl rollout restart statefulset [*STATEFULSET_NAME*] -n [*NAMESPACE*]

No se puede acceder al nodo en la red de datos

Se trata de un problema poco habitual que puede producirse si el pod anetd se queda en un bucle de fallos.

Un recurso del kernel esencial para la conectividad de los nodos puede quedarse bloqueado en un estado dañado.

En esta guía se describen los síntomas de este problema y los pasos que se pueden seguir para solucionarlo.

Versiones:

Todas las versiones de Google Distributed Cloud (GDC) con air gap pueden verse afectadas.

Síntomas:

Si se produce este problema, es posible que observes los siguientes síntomas:

• Los nodos se quedan en el estado NotReady
• Al describir el nodo, se muestra el mensaje kubelet:kubelet was found unhealthy; repair flag : true
• No se puede acceder al nodo mediante SSH en la red de datos

Solución alternativa:

Sigue estas instrucciones para reparar cada nodo en mal estado:

1. Obtén la dirección IP de gestión del nodo afectado:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'
   

2. Obtén acceso SSH al nodo afectado.

3. Conéctate al nodo mediante SSH con la dirección IP de gestión del nodo.

4. En el nodo, ejecuta el siguiente comando y, a continuación, cierra la conexión SSH:

   tc filter del dev bond0 egress
   

5. Reinicia el conjunto de demonios anetd del clúster con el nodo afectado:

   kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system
   

Crear un PNP de salida que permita todo el tráfico rechaza el tráfico inesperado

Versiones:

Todas las versiones de Google Distributed Cloud (GDC) con air gap pueden verse afectadas.

Síntomas: La política de red del proyecto (PNP) allow-all-egress permite el tráfico a los endpoints del proyecto y a los endpoints externos fuera del clúster, pero no permite el tráfico a los endpoints del sistema. Este problema puede provocar que se bloquee el acceso al sistema y a los servicios propios, como la resolución de DNS y el almacenamiento de objetos.

El allow-all-egress PNP podría ser similar al siguiente:

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

Solución: elimina el allow-all-egress PNP. De forma predeterminada, una vez que se inhabilita la protección contra la filtración externa de datos, se permite el tráfico a los endpoints externos y del proyecto que no sean del clúster ni del sistema.

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

Problema con el panel de control de Grafana de SLO de disponibilidad entre zonas de varias zonas

Versiones: 1.14.3

Síntomas: en Grafana, el panel de control pnet-cross-zone-availability SLO no muestra ninguna métrica.

Solución: sigue el runbook PNET-P0001 para obtener acceso al conmutador y comprueba manualmente la sesión de BGP multizona y el estado de la conectividad.

No se pueden reconciliar las pasarelas de entrada del plano de datos y de gestión

Versiones: 1.14.3

Síntomas: los subcomponentes asm-dataplane-ingress o asm-management-ingress no se pueden conciliar y se muestra el siguiente error:

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

Otros valores posibles en la cadena de error en lugar de BackendService son ForwardingRuleInternal y ForwardingRuleExternal. Del mismo modo, el nombre del recurso puede ser dataplane-ingress-gateway, dataplane-ingress-gateway-global o management-ingress-gateway-global en lugar de management-ingress-gateway.

Solución alternativa: identifica si el recurso está presente en el servidor de la API de gestión o en el servidor de la API global. Esto se puede deducir de la versión de la API del tipo de recurso en la cadena de error. Por ejemplo, un recurso con el sufijo networking.gdc.goog está presente en el servidor de la API de gestión, mientras que un recurso con el sufijo networking.global.gdc.goog está presente en el servidor de la API global.

Una vez que hayas identificado el servidor de la API, elimina el recurso con el archivo kubeconfig correspondiente. Por ejemplo:

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

La página de la política de red del proyecto no admite el campo de selector de proyectos en la API ProjectNetworkPolicy

Versiones: 1.14.3 y 1.14.4

Síntomas: Cuando creas una política de red de proyecto que incluye el campo projectSelector y la ves en la consola de GDC, la interfaz de usuario muestra todos los proyectos seleccionados para la política en lugar de los proyectos del campo projectSelector.

Solución alternativa: usa la API para crear y leer una política de red de un proyecto que incluya el campo projectSelector.

Sistema operativo

Fallo en el aprovisionamiento del servidor

Versiones: 1.14.3

Síntomas: Durante el aprovisionamiento del servidor, pueden aparecer los siguientes errores 401 en el recurso personalizado BaremetalHost correspondiente al descargar la imagen del SO del registro de Harbor, y el servidor se queda bloqueado en un bucle de desaprovisionamiento y reaprovisionamiento.

Para comprobar si se han producido estos errores, describe el BaremetalHost recurso personalizado:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

La salida podría tener este aspecto:

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

Solución:

1. Obtén el nombre y el espacio de nombres del nodePoolClaim al que pertenece el servidor:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'
   

   La salida podría tener este aspecto:

   {
   "name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
   "namespace": "gpu-org-lancer"
   }
   

2. Obtén el nombre de la imagen del SO de NodePoolClaim:

   kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'
   

3. Obtén la URL de la imagen del SO desde OSImageMetadata:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'
   

4. Actualiza el recurso personalizado Server con la URL de la imagen del SO más reciente:

   kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'
   

OS NodeUpgrade puede quedarse bloqueado en el paso NodeOSInPlaceUpgradePostProcessingCompleted

Versiones: 1.14.3 y 1.14.4

Síntomas:

Durante una actualización de un nodo, NodeUpgradeTask se queda atascado en el paso NodeOSInPlaceUpgradePostProcessingCompleted con un error de reconciliación con el mensaje failed verifying delta after upgrade y no se puede completar. Este error indica que el proceso de verificación de la actualización ha detectado discrepancias inesperadas en el paquete del nodo. En concreto, identifica los paquetes que aún están en el estado "need-upgrade" o que aparecen como paquetes "only-in-new" después del intento de actualización.

En el mensaje de error se indican los paquetes específicos que no han superado la verificación. Fragmento de ejemplo:

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

Este síntoma puede deberse a dos problemas. Primero, detecta cuál es el problema:

1. Cause-A: no se puede acceder a la máquina, por lo que OSArtifactSnapShot no está actualizado.

   Comprueba si el nodo que se está actualizando sigue funcionando correctamente o no, y si el trabajo OSArtifactSnapShot correspondiente está fallando.

   Si OSArtifactSnapShot está obsoleto y no se puede acceder a la máquina durante más de 20 minutos, ve al paso Mitigation-A. De lo contrario, sigue comprobando si hay Cause-B.

2. Cause-B: error de actualización silenciosa de RPM

   En casos excepcionales, la actualización de RPM en una máquina podría fallar de forma silenciosa después de una actualización parcial. Debería haber dos ConfigMaps que contengan la diferencia del paquete antes y después de la actualización:

   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
   

   Si la configuración "after-upgrade" contiene menos paquetes que la configuración "before-upgrade", significa que la actualización se ha cancelado de forma silenciosa y no se han actualizado todos los paquetes. Ve a Mitigation-B.

Solución:

Mitigation-A: reparar una máquina a la que no se puede acceder

Intenta reparar la máquina reiniciándola. Si la máquina sigue sin estar disponible después de intentar reiniciarla, ponte en contacto con el equipo de SERV para obtener más ayuda. Cuando la máquina vuelva a estar accesible, elimina el OSArtifactSnapShot para forzar la conciliación. Una vez que se haya conciliado OSArtifactSnapShot, NodeUpgradeTask debe pasar al siguiente paso.

Mitigation-B: vuelve a intentar la NodeUpgradeTask.

1. Conéctate por SSH a la máquina que se va a actualizar y recoge los siguientes registros para solucionar problemas en el futuro. Debes recoger los siguientes archivos:

   • /var/log/dnf.log
   • /var/log/dnf.rpm.log
   • dnf history > dnf_history.log
   • rpm -qa --last > rpm_last.log

2. Elimina el NodeUpgradeTask que no funciona. Esto activará un nuevo intento de NodeUpgradeTask en el nodo concreto. El nuevo NodeUpgradeTask debería completar la actualización de RPM y pasar al siguiente paso.

OS NodeUpgrade puede quedarse bloqueado en el paso de creación del servidor de paquetes

Versiones: 1.14.3 y 1.14.4

Síntomas:

Cuando se crea una NodeUpgrade CR, se activa y permanece en in-progress durante más de 30 minutos, es posible que falle de forma silenciosa en la fase de creación del servidor de paquetes. El síntoma es que NodeUpgrade se queda en .status.upgradeStatus=in-progress, pero no se carga .status.tasks:

status:
  duration: 0s
  upgradeStatus: in-progress

Para confirmar que se produce un error al crear el servidor de paquetes, lee el registro del controlador de actualización del SO:

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Si el registro del controlador muestra failed to create package server y failed to create package repo server DNS registration con un motivo detallado (cualquiera de los siguientes)

• spec.fqdnPrefix already used in an existing DNS registration
• name already used in an existing DNS.

A continuación, sugiere que algunos recursos de servidor de paquetes que usan otros NodeUpgrade siguen activos y entran en conflicto con el recurso que se va a crear para el NodeUpgrade colgado actual.

Solución:

Para confirmarlo, puedes consultar el recurso del servidor de paquetes real (de una API concreta, como dnsregistration.network.private.gdc.goog en el servidor de la API de gestión del clúster que gestiona el CR NodeUpgrade) y buscar el NodeUpgrade propietario de esos recursos. Si el NodeUpgrade propietario del DNSRegistration ya ha terminado, pero el recurso DNSRegistration aún no se ha eliminado, puedes eliminar el objeto DNSRegistration si todos sus objetos NodeUpgrade de referencia han terminado.

1. Lista todos los DNSRegistration CRs del servidor de paquetes NodeUpgrade:

   kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm
   

2. Consulta la NodeUpgrade CR del propietario de un DNSRegistration concreto:

   kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'
   

Las actualizaciones del SO de los nodos pueden dar problemas y detenerse en cualquier fase del proceso.

Versiones: 1.14.4, 1.14.5 y 1.14.6

Síntomas:

NodeUpgradeTask CR sigue por debajo de in-progress durante más de 2 horas, aunque es posible que se complete automáticamente si se le da suficiente tiempo.

La solicitud de cambio NodeUpgradeTask lleva más de dos horas en curso. Aunque puede que se complete automáticamente, el problema subyacente es que el reconciliador de políticas del SO no puede gestionar de forma eficiente un gran volumen de CRs de OSPolicy. Este problema se produce durante el paso NodeOSInPlaceUpgradeCompleted.

Para confirmar este error durante la creación del servidor de paquetes, consulta el registro del controlador de actualización del SO.

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Si el registro del controlador no tiene una entrada OSPolicy de NodeUpgradeTask, significa que el controlador está sobrecargado.

Solución:

Pausa todos los OSPolicy CRs no esenciales durante el proceso de actualización.

"storage cp" de un archivo grande provoca un error en org-mgmt kube-api

Versiones: 1.14.3 y posteriores

Síntomas: Durante una operación de gdcloud storage cp o de gdcloud system container-registry load-oci desde una estación de trabajo de OIC, existe una pequeña probabilidad de que se pierda el acceso a org-infra y, a continuación, se produzca un fallo en org-mgmt's kube-api. Se trata de un problema poco habitual, por lo que es útil recoger datos para el equipo de ingeniería.

Solución alternativa: cuando se produzca este problema, prueba a seguir estos pasos:

1. En cada nodo del plano de control, ejecuta uptime para ver si los nodos se han reiniciado en las últimas 24 horas.
2. Anota la hora del reinicio.
3. Comprueba si se ha producido un pánico del kernel en cada nodo de CP justo antes del reinicio ejecutando dmesg | grep -i 'kernel panic'.
4. En cada nodo de CP, comprueba si hay instaladas tarjetas NIC Mellanox con el comando lspci | grep -i eth | grep -i mellanox. Si no hay NICs Mellanox, deja de leer este problema conocido.

5. En cada nodo de CP, comprueba estos ajustes de red en data0:

   [root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
   rx-checksumming: off
   generic-receive-offload: on
   large-receive-offload: off
   rx-gro-hw: on  # <--- Check this value
   

   Si rx-gro-hw (consulta la información anterior) está configurado como "off" en todos los nodos, deja de leer este problema conocido.

6. Recoge información para que Google pueda diagnosticar el problema:

   k8s.org get po -n anthos-identity-service -l k8s-app=ais
   
   k8s.org get po -n management-kube-system
   
   k8s.org get po -n kube-system -l component=kube-apiserver
   
   k8s.org get nodes -l node-role.kubernetes.io/control-plane
   

7. En cada nodo de CP, ejecuta los siguientes comandos:

   dmesg | grep -i 'kernel panic'
   
   journalctl -u disable-rx-gro-hw.service
   
   systemctl status disable-rx-gro-hw
   
   modinfo mlx5_core | grep ^version:
   

8. Para mitigar el problema de configuración de red, rx-gro-hw debe estar off. Para ello, ejecuta los siguientes comandos en todos los nodos de CP:

   ethtool -K data0 rx off gro off lro off
   ethtool -K data1 rx off gro off lro off
   ethtool -K bond00 rx off gro off lro off
   

9. Vuelve a comprobar los ajustes:

   [root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
   rx-checksumming: off
   generic-receive-offload: on
   large-receive-offload: off
   rx-gro-hw: off # <--- Check this, should be "off"
   

10. Vuelve a intentar la operación original, como gdcloud storage cp o gdcloud system container-registry load-oci. Si sigue fallando, ponte en contacto con el equipo de Ingeniería.

Servicios principales de infraestructura de Operations Suite (OIC)

Rendimiento deficiente de Jumphost

Versiones: todas las versiones de Google Distributed Cloud (GDC) con air gap pueden verse afectadas.

Síntomas: las operaciones del navegador o del sistema tardan demasiado en completarse.

Solución:

Aumenta el número de vCPUs en los jumphosts a través del administrador de Hyper-V en BM03 y BM04:

1. Selecciona una VM de Jumphost y, a continuación, haz clic en Configuración en el panel de acciones.
2. Selecciona Procesador y, a continuación, aumenta el número de Número de procesadores virtuales a 4 o más, en función de la carga de trabajo.
3. Repite el proceso con el resto de los Jumphosts.

Administrador de recursos

No se pueden eliminar proyectos en la consola de GDC

Versiones: 1.14.3 y 1.14.4

Síntomas: La consola de GDC proporciona el botón Eliminar Eliminar para los proyectos que ya existen en la página Detalles del proyecto, pero el botón no funciona.

Solución: Para eliminar un proyecto, debes usar la CLI de gdcloud. Para obtener más información, consulta Eliminar un proyecto.

Faltan guías de Ansible de la organización

Versiones: 1.14.3

Síntomas: al crear una organización, el trabajo create-ansible-playbooks que crea los libros de jugadas de Ansible obligatorios falla de forma silenciosa. La falta de libros de jugadas de Ansible provoca problemas como la ausencia de máquinas virtuales perimetrales y problemas al crear una organización global.

Solución alternativa: Sigue el manual de procedimientos OS-R0009 para crear manualmente los playbooks de Ansible de la organización que faltan.

Una organización global asimétrica muestra configuraciones zonales que no existen

Versiones: 1.14.4

Síntomas: Al crear una organización global de la versión 1 con solo un subconjunto de configuraciones de organización zonales, todas las zonas siguen mostrando un estado de réplica de la organización. Por ejemplo, si tienes un universo de GDC con tres zonas, pero solo creas una configuración de organización zonal para dos zonas, la tercera zona seguirá mostrando un estado de réplica erróneo para la tercera organización zonal inexistente.

Para confirmar el estado erróneo, imprime el estado de la organización global:

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

La salida de YAML tiene un aspecto similar al siguiente:

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

Ten en cuenta que esto solo ocurre en las organizaciones de la versión 1, ya que las configuraciones zonales asimétricas no se admiten en las organizaciones de la versión 2.

Solución: Puedes ignorar el estado de réplica erróneo, ya que la organización zonal no existe a menos que la hayas creado específicamente.

Clúster

No se elimina el grupo de nodos de trabajador del clúster de infraestructura

Versiones: 1.14.3 y 1.14.4

Síntomas: al eliminar un grupo de nodos de trabajo de la especificación de CR de Organization, el grupo de nodos no se elimina automáticamente, es decir, el comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} sigue mostrando el grupo de nodos que se va a eliminar.

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

Solución alternativa: Después de quitar el grupo de nodos de trabajo de la especificación de Organization CR, elimina manualmente el NodePoolClaim CR de este grupo de nodos del clúster de administrador raíz ejecutando el siguiente comando: sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

Espera hasta que se elimine por completo el NodePoolClaim y sus NodePool CRs asociados, es decir, hasta que el comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} deje de mostrar el grupo de nodos de trabajador.

Almacenamiento

No se pueden eliminar los contenedores creados con el comando gdcloud config set zone

Versiones: 1.14.7 y posteriores

Síntomas: Los segmentos creados con el comando gdcloud config set zone no se pueden eliminar debido a problemas con los permisos, ya que el comando intenta operar en la zona incorrecta.

Solución: Usa la consola para definir la zona específica de un segmento o sustituye la marca --zone por --location en el comando gcloud.

Alertas de objetivos de nivel de servicio activadas

Versiones: 1.14.3 y 1.14.4

Síntomas: Se activan alertas de objetivo de nivel de servicio de OBJ debido a un error ErrFailedStreamingDecryptRequest en el proxy de OBJ: obj-list-object-ops-availability-slo y obj-rw-object-ops-error-rate-slo.

Solución: silencia la alerta. El error se identifica incorrectamente como un error del sistema cuando lo provoca el usuario al finalizar la conexión, lo que no se tiene en cuenta en el SLO.

S3 UploadPart Empty ETag

Versiones: 1.14.3

Síntomas: después de enviar una solicitud UploadPart, obtienes un código de estado 200 Success en el mensaje de respuesta, pero el campo ETag está vacío. Este error se produce porque se produce un InternalServerError debido a una interrupción de la red y el código de estado no se actualiza a 500 InternalServerError.

Solución alternativa: vuelve a enviar la solicitud como si hubiera fallado anteriormente.

Los pods no se montan debido a un error de Trident mkfs.ext4

Versiones: 1.14.3

Síntomas: Después de intentar montar pods, observa que todos los pods que están pasando a un nodo concreto o que vienen de él fallan. Aparece un mensaje de error de RPC: DeadlineExceeded desc = context deadline exceeded, que indica que el nodo está bloqueado. Cuando se produce este mensaje, no puedes realizar operaciones adicionales de Trident en el nodo en cuestión. Los volúmenes que sirven datos no se verán afectados, pero los volúmenes que se muevan hacia y desde el nodo podrían sufrir una interrupción.

Solución:

1. Inspecciona los registros de Trident en el nodo que el pod está intentando montar y comprueba que la cola aumenta. Los registros pueden tener un aspecto similar al siguiente:

   2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"
   

2. Inicia sesión en el nodo y consulta el resultado de dmesg. Los registros pueden tener un aspecto similar al siguiente:

   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
   Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
   

3. Después de confirmar que se produce un error de Trident mkfs.ext4, reinicia el nodo.

Trident no puede crear un volumen debido a un error que ya existe

Versiones: 1.14.3

Síntomas:

No se aprovisiona un PVC y se muestra un evento como el siguiente:

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

Cuando se produce este evento, el PVC no se aprovisiona hasta que realizas la solución alternativa.

Solución:

Para solucionar el problema, sigue estos pasos:

1. Anota el nombre del volumen interno del evento. Por ejemplo, el evento de muestra que se muestra en la sección Síntomas muestra el nombre del volumen interno trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
2. Sigue el manual de operaciones FILE-R0105 para acceder a ONTAP.

3. Eliminar el volumen:

   volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a
   

file_block_iscsi_sessions_unhealthy alert informa de un falso positivo

Versiones: 1.14.3

Síntomas: en algunos entornos, se activa la alerta file_block_iscsi_sessions_unhealthy, que indica que uno o varios nodos están experimentando errores de iSCSI. El controlador file-observability usa un recopilador de métricas personalizadas para monitorizar el estado de las sesiones iSCSI en cada nodo de Kubernetes, pero, en algunos casos, el recopilador de métricas no puede analizar la salida del comando iscsiadm e informa de que no hay sesiones iSCSI en ejecución aunque iSCSI tenga sesiones correctas.

Solución:

Sigue estos pasos para verificar que iSCSI no tiene problemas y silenciar la alerta si se trata de un falso positivo:

1. En la página de exploración de Grafana, ejecuta la consulta fb_sessions_running_count{job="file-observability-backend-target.file-system"}. La consulta devuelve una métrica por cada nodo del clúster. Si algún nodo informa de una métrica fb_sessions_running_count de 0, anota el nombre del nodo.

2. En cada nodo con métricas fb_sessions_running_count que devuelvan 0, ejecuta los siguientes comandos:

   1. Establece una conexión SSH con el nodo afectado.

   2. Ejecuta el comando iscsiadm -m session. Debes ver varias líneas devueltas. Cada línea es una sesión iSCSI en ejecución. Si el comando no devuelve nada o hay errores en el resultado, deriva el problema al equipo de ingeniería de bloqueo de archivos.

   3. Si el comando anterior ha devuelto sesiones iSCSI correctamente, significa que has confirmado que la alerta de este nodo es un falso positivo.

3. Cuando confirmes que todos los nodos afectados tienen sesiones iSCSI correctas y que están provocando que la alerta se active por error, crea un silencio en AlertManager para silenciar la alerta file_block_iscsi_sessions_unhealthy.

Se activa una alerta file_block_storage_disk_failure para los discos de repuesto

Versiones: 1.14.3

Síntomas: En algunos entornos, se activa la alerta file_block_storage_disk_failure, que indica que uno o varios discos de ONTAP no están en buen estado. El controlador file-observability usa un recopilador de métricas personalizadas para monitorizar el estado de cada disco de ONTAP, pero en versiones anteriores de GDC, el recopilador no considera que un disco de repuesto esté en buen estado y activará una alerta para el disco de repuesto.

Solución:

Sigue estos pasos para verificar que los discos son de repuesto y silenciar la alerta del disco:

1. En la página de exploración de Grafana, ejecuta la consulta disks_labels_healthy{job="file-observability-backend-target.file-system"}. La consulta devolverá una métrica por cada disco de ONTAP. Si algún disco indica una métrica de 0 (no está en buen estado), anota el nombre del disco.

2. En cada disco con métricas disks_labels_healthy que devuelvan 0, ejecuta los siguientes comandos:

   1. Conéctate al clúster de ONTAP mediante SSH y ejecuta el comando disk show -disk <disk-name> -fields state con el nombre del disco recogido de la consulta de métricas.

   2. Verifica que la salida del comando indica que el estado del disco es present o spare. Si el disco está en cualquier otro estado que no sea present o spare, deriva el problema al equipo de ingeniería de bloqueo de archivos.

   3. Si el disco en cuestión indica present o spare, podemos confirmar que la alerta no debería activarse para este disco. Crea un silencio en AlertManager para silenciar la alerta file_block_storage_disk_failure con la etiqueta disk_name definida con el nombre del disco.

3. Una vez que se hayan creado los silencios para todos los discos de repuesto, ve a Grafana para verificar que las alertas han dejado de activarse.

La alerta file_block_storage_node_peer_connection_unhealthy se activa después de que se restaure la conexión

Versiones: 1.14.3

Síntomas: en algunos entornos, se activa la alerta file_block_storage_node_peer_connection_unhealthy, que indica que se produce un error en una o varias conexiones entre los nodos de ONTAP. El controlador file-observability usa un recopilador de métricas personalizadas para monitorizar el estado de estas conexiones. Hay un problema conocido por el que esta alerta seguirá activándose incluso después de que se haya restablecido la conexión fallida.

Solución:

Sigue estos pasos para verificar que las conexiones entre los nodos son correctas y silenciar la alerta de los nodos:

1. En la página de exploración de Grafana, ejecuta la consulta storage_node_peer_connections{job="file-observability-backend-target.file-system"}. La consulta devuelve una métrica por cada conexión entre los nodos de almacenamiento del clúster. Si alguna conexión registra una métrica storage_node_peer_connections de 0, anota las etiquetas source_node, destination_ip y storage_cluster_name de la métrica.

2. En cada métrica storage_node_peer_connections que devuelva 0, ejecuta los siguientes comandos:

   1. Establece una conexión SSH con el clúster de almacenamiento de ONTAP desde la etiqueta storage_cluster_name.

   2. Ejecuta el siguiente comando en el clúster de ONTAP con los valores de las etiquetas source_node y destination_ip:

   ping -node <node-name> -destination <destination-ip> -verbose -show-detail
   

   Si el comando ping falla, deriva el problema al equipo de Ingeniería de bloqueo de archivos. Si el comando ping se ejecuta correctamente, significa que las conexiones de los nodos funcionan correctamente y que la alerta se activa por error.

   1. Crea un silencio en AlertManager para silenciar la alerta file_block_storage_node_peer_connection_unhealthy con las etiquetas source_node y destination_ip definidas en el nodo de origen y la IP de destino de la métrica.

3. Una vez que se hayan creado los silencios para todos los nodos correctos, ve a Grafana para verificar que las alertas han dejado de activarse.

La alerta file_block_nodes_not_reachable se activa después de que se restaure la conexión

Versiones: 1.14.3

Síntomas: en algunos entornos, se activa la alerta file_block_nodes_not_reachable, que indica que se están produciendo errores en una o varias conexiones de los servicios IPsec en los nodos de Kubernetes a ONTAP. El controlador file-observability usa un recopilador de métricas personalizadas para monitorizar el estado de estas conexiones. Hay un problema conocido por el que esta alerta seguirá activándose incluso después de que se haya restablecido la conexión fallida.

Solución:

Sigue estos pasos para verificar que las conexiones de los nodos funcionan correctamente y silenciar la alerta de los nodos:

1. En la página de exploración de Grafana, ejecuta la consulta fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}. La consulta devuelve una métrica por cada nodo del clúster. Si algún nodo informa de una métrica fb_all_nodes_reachable de 0, anota el nombre del nodo.

2. En cada nodo con métricas fb_all_nodes_reachable que devuelvan 0, ejecuta los siguientes comandos:

   1. Establece una conexión SSH con el nodo afectado.

   2. Ejecuta el siguiente comando:

      journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
      

      El comando intentará hacer ping a ONTAP mediante todas las conexiones IPsec. Si falla algún ping del comando, deriva el problema al equipo de ingeniería de bloqueo de archivos. Si los comandos ping se ejecutan correctamente, se confirma que las conexiones de los nodos funcionan correctamente y que la alerta se activa por error.

   3. Si todos los pings del comando se realizan correctamente, significa que las conexiones del nodo están en buen estado y que la alerta se activa de forma errónea. Crea un silencio en AlertManager para silenciar la alerta file_block_nodes_not_reachable con la etiqueta node_name definida con el nombre del nodo.

3. Una vez que se hayan creado los silencios para todos los nodos correctos, ve a Grafana para verificar que las alertas han dejado de activarse.

file_block_storage_high_node_total_latency se activa una alerta durante cargas de trabajo pesadas

Versiones: 1.14.3

Síntomas: La alerta file_block_storage_high_node_total_latency puede activarse en determinados entornos debido a cargas de trabajo pesadas en los nodos de almacenamiento. Esta alerta se mantiene hasta que se procesen por completo estas cargas de trabajo. Aunque el rendimiento de lectura y escritura en los volúmenes sea rápido, los nodos de almacenamiento pueden seguir notificando una latencia alta en operaciones de bloques específicas.

Solución:

Para verificar las latencias de volumen correctas y silenciar la alerta de latencia del nodo de almacenamiento, sigue estos pasos:

1. Comprueba las alertas de latencia de volumen:

   1. En Grafana, comprueba que las alertas file_block_storage_high_volume_write_latency y file_block_storage_high_volume_read_latency no se activen y que indiquen tiempos de latencia óptimos para los volúmenes.

2. Deriva el caso si la latencia del volumen es alta:

   1. Si se activan las alertas de escritura o lectura de volumen, significa que hay una latencia alta en todo el sistema de almacenamiento. Deriva este problema al equipo de ingeniería de bloqueo de archivos.

3. Silenciar la alerta de latencia de nodos (si los volúmenes están en buen estado):

   1. Si las alertas de escritura y lectura de volumen están en buen estado, es probable que la alerta de latencia de nodo sea un falso positivo.

   2. Crea un silencio en AlertManager para la alerta file_block_storage_high_node_total_latency.

   3. Después de crear el silencio, ve a Grafana para confirmar que la alerta ha dejado de activarse.

Actualización de nodo bloqueada

Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6 y 1.14.7

Síntomas: este bloqueo se produce cuando un LUN (número de unidad lógica) pasa a ser de solo lectura, a menudo debido a problemas con las copias de seguridad. Cuando esto ocurre, el nodo se acordonará para mover el pod afectado a otro nodo. Como el proceso de actualización de nodos incluye una comprobación previa para asegurarse de que los nodos no estén aislados, este estado impide que se lleve a cabo la actualización.

Solución: Inhabilita manualmente el subcomponente file-read-only-lun-cleanup antes de iniciar el proceso de actualización:

1. Identifica cada organización afectada.

2. Aplica un SubcomponentOverride a cada organización del entorno.

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: file-read-only-lun-cleanup
     namespace: ORG_NAMESPACE
   spec:
     subComponentRef: "file-read-only-lun-cleanup"
     disable: true
   

3. Comprueba que ninguno de los nodos de las organizaciones afectadas esté acordonado:

   1. Lista los nodos de la organización:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      El resultado debería ser similar al siguiente:

      NAME                STATUS                     ROLES           AGE   VERSION
      admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
      admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      

      Anota los nombres de los nodos que tengan el estado SchedulingDisabled. En este ejemplo, el nodo acordonado es admin-node0-zone1.

   2. Desactiva el aislamiento de los nodos que hayan devuelto el estado SchedulingDisabled en el paso anterior:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
      

   3. Comprueba que todos los nodos estén listos:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      El resultado debería ser similar al siguiente:

      NAME                STATUS                     ROLES           AGE   VERSION
      admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
      

La alerta file_block_zombie_luns_present se activa después de que se resuelvan los errores de multipath

Versiones: 1.14.3 y posteriores

Síntomas: La alerta file_block_zombie_luns_present puede activarse en determinados entornos porque el controlador file-observability no puede analizar la salida del comando multipath -ll. Esta situación provoca que se active constantemente la alerta de LUNs zombi, aunque el servicio de multiruta funcione correctamente en todos los nodos.

Solución:

Para verificar que los servicios de multipath funcionan correctamente en los nodos en cuestión, sigue estos pasos:

1. En la página de exploración de Grafana, ejecuta la consulta zombie_lun_exists{job="file-observability-backend-target.file-system"}. La consulta devuelve una métrica por cada nodo del clúster. Si algún nodo informa de una métrica zombie_lun_exists de 1, anota el nombre del nodo.

2. En cada nodo con métricas zombie_lun_exists que devuelvan 1, ejecuta los siguientes comandos:

   1. Establece una conexión SSH con el nodo afectado.

   2. Ejecuta el siguiente comando:

      multipath -ll
      

      El comando devuelve información sobre todos los dispositivos de bloque gestionados por el servicio multipath. Comprueba que ninguno de los dispositivos de bloque contenga la cadena failed undef unknown o la cadena failed faulty running en sus estados.

   3. Si algún dispositivo tiene el estado failed faulty running, sigue el runbook FILE-R0020 para resolver los LUNs zombi.

   4. Si algún dispositivo tiene el estado failed undef unknown, sigue el runbook FILE-R0021 para resolver los LUNs superzombies.

3. Silencia las alertas de LUN zombi si los nodos están en buen estado:

   1. Si no se encuentran dispositivos de bloque no válidos en ninguno de los nodos, la alerta de LUN zombi es un falso positivo.

   2. Crea un silencio en AlertManager para la alerta file_block_zombie_luns_present.

   3. Después de crear el silencio, ve a ServiceNow para confirmar que la alerta ha dejado de activarse.

No se puede eliminar un segmento vacío desde la consola

Versiones: 1.14.4 y posteriores

Síntomas: en la consola de GDC, no puedes eliminar un contenedor vacío. El segmento puede tener marcadores de eliminación y otras versiones de objetos cuando la gestión de versiones de objetos está habilitada con políticas de retención. Puede que veas un error como este:

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

Solución alternativa: Usa el comando gdcloud storage rm -a para eliminar objetos, incluidos los marcadores de eliminación, para que se pueda eliminar el segmento.

Artifact Registry del sistema

Las tareas de replicación de Harbor se bloquean

Versiones: 1.14.3

Síntomas: los trabajos de replicación de artefactos de Harbor se bloquean. Este problema impide la distribución de artefactos a la organización y detiene la creación de organizaciones.

Solución alternativa: para mitigar este problema, siga los pasos que se indican en el runbook SAR-R1010.

El estado de error transitorio no se borra al reconciliar el recurso personalizado de la cuenta de robot de Harbor

Versiones: 1.14.3

Síntomas: se activa erróneamente una alerta CustomResourceErrorStatusAlert con las etiquetas kind=HarborRobotAccount y code=SAR2002. Por ejemplo, la alerta falsa tiene el campo message definido como "Error getting robot: failed to list robots: 503 Service Unavailable".

Solución alternativa: pide al operador de infraestructura que verifique si la alerta es un problema real o una falsa alarma y que la silencie si es una falsa alarma, siguiendo las instrucciones que se indican a continuación.

Cuando se active una alerta, sigue el manual de operaciones SAR-E2002 para identificar y solucionar la causa subyacente de la alerta.

Debido a este problema conocido, aunque el runbook resuelva correctamente la causa subyacente, la alerta podría seguir activándose erróneamente. Sigue comprobando el estado de error del objeto de recurso personalizado (CR) HarborRobotAccount (HRD) de destino del que se está enviando la alerta:

1. Define las variables de entorno necesarias:

   export KUBECONFIG=KUBECONFIG
   export HRD_NAME=HRD_NAME
   export HRD_NAMESPACE=HRD_NAMESPACE
   

   Haz los cambios siguientes:

   • KUBECONFIG: la ruta al archivo kubeconfig.
   • HRD_NAME: el nombre de la CR de destino HarborRobotAccount.
   • HRD_NAMESPACE: el espacio de nombres que contiene el CR HarborRobotAccount de destino.

2. Comprueba el estado del error del HarborRobotAccount CR de destino:

   kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'
   

Si el valor de lastUpdateTime indica que el campo errorStatus se actualizó por última vez hace más de 30 minutos, la alerta es falsa. Para mitigar la falsa alarma, silencia la alerta en la instancia con air gap de GDC siguiendo el runbook MON-R2009.

Falsa alarma de alerta SAR-R0003

Versiones: 1.14.3 y posteriores

Síntomas: se activa una alerta con el código SAR-R0003, OC SAR y gravedad critical de forma errónea.

Solución: sigue el runbook MON-R2009 para silenciar la alerta.

Sistema de incidencias

El servidor MID de ServiceNow no se inicia correctamente

Versiones: 1.14.3

Corregido: 1.14.4

Síntomas: El MID Server de ServiceNow, que se integra con Splunk, no se registra en ServiceNow al iniciarse debido a una incompatibilidad de versiones.

Solución:

1. Pausa el ts-mid-serversubcomponente.

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

1. Anula la cadena de versión del servidor MID.

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

Actualizar

La anotación del clúster de servicios compartidos no se actualiza después de una actualización correcta del clúster

Versiones: 1.14.4

Síntomas: los CRs de los clústeres de perímetro y de servicios compartidos de clusters.baremetal.cluster.gke.io reflejan la versión correcta de GKE después de la actualización. Los CRs de clusters.cluster.gdc.goog siguen mostrando la versión anterior de GKE.

Solución alternativa: Actualiza la anotación upgrade.gdc.goog/version en clusters.baremetal.cluster.gke.io al nuevo nombre UserClusterMetadata correspondiente a la versión de GKE actualizada.

La actualización de nodos del administrador de la organización se queda atascada

Versiones: 1.14.6

Corregido: 1.14.7

Síntomas: el proceso de actualización de nodos del plano de control de administrador de la organización gdchservices se ha bloqueado. La actualización del nodo falla porque no se puede establecer una conexión SSH con el nodo, lo que provoca un error Connection timed out.

La actualización del complemento se queda atascada

Versiones: 1.14.6

Corregido: 1.14.7

Síntomas: La actualización del complemento del clúster de administrador raíz se bloquea durante la actualización de cualquier versión anterior a la 1.14.6. Un mensaje de estado puede indicar que la actualización ha superado el límite de tiempo previsto:

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

Solución: Actualiza manualmente el spec.addOnSetTemplateRef del recurso addonset root-admin para que apunte a la plantilla correcta de la nueva versión.

Fallo al generar un informe de asistencia

Versiones: 1.14.3, 1.14.4, 1.14.5 y 1.14.6

Corregido: 1.14.7

Síntomas: el comando gdcloud resource-support get-report falla cuando se ejecuta en un clúster de usuarios debido a un problema de permisos.

El arranque de la VM puede quedarse bloqueado después de completar la actualización del nodo del SO

Versiones: 1.14.6

Síntomas: durante la actualización de la versión 1.14.3 a la 1.14.6, las máquinas virtuales de los clústeres de perímetro o de servicio compartido no se inician y no se puede acceder a ellas después de actualizar el SO.

Por ejemplo, el siguiente comando puede confirmar el problema:

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

El resultado del registro de la consola de la VM muestra un mensaje de pánico del kernel similar al siguiente:

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

Solución alternativa: sigue estos pasos para solucionar el problema:

1. Define las siguientes variables de entorno:

   export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
   export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
   export VM_NAMESPACE=VM_NAMESPACE
   export VM_NAME=FAILED_VM_NAME
   

2. Detén la VM que ha fallado:

   kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
       $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'
   

3. Abre el editor para desvincular el disco de arranque de la VM que ha fallado:

   kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
   

4. Sustituye el disco de arranque por un nombre de marcador de posición en la especificación de la VM:

   # Several lines of code are omitted here.
   spec:
     disks:
     - boot: true
       virtualMachineDiskRef:
         # This is a random placeholder name you put here. Doesn't need to exist
         name: VM_DISK_PLACEHOLDER_NAME
   

5. Crea un secreto de secuencia de comandos de inicio:

   cat <<'EOF' > script
   #!/bin/bash
   username="newuser"
   password="Lime+blaze8legend"
   sudo useradd -m -s /bin/bash "$username"
   echo "$username:$password" | sudo chpasswd
   sudo usermod -aG sudo "$username"
   EOF
   
   kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script
   

6. Crea una VM auxiliar:

   1. Obtén la imagen de VM para el disco de arranque de la VM. La imagen no debe tener la misma familia de SO que el disco de arranque del nodo de la VM con problemas. Por lo tanto, usa grep para buscar la imagen de Ubuntu:

      # find the latest ubuntu-20.04 OS version
      UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')
      

   2. Crea el disco de arranque y la VM. Crea un disco de arranque y una VM con un disco secundario conectado y un script de inicio para acceder a la consola:

      kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
      apiVersion: virtualmachine.gdc.goog/v1
      kind: VirtualMachineDisk
      metadata:
        name: HELPER_VM_BOOT_DISK_NAME
      spec:
        source:
          image:
            name: UBUNTU_OS_VERSION
            namespace: vm-system
        size: 20Gi
      ---
      apiVersion: virtualmachine.gdc.goog/v1
      kind: VirtualMachine
      metadata:
        name: HELPER_VM_NAME
      spec:
        compute:
          virtualMachineType: n3-standard-2-gdc
        disks:
        - virtualMachineDiskRef:
            name: HELPER_VM_NAME-disk
          boot: true
          autoDelete: true
        - virtualMachineDiskRef:
            name: PROBLEM_VM_BOOT_DISK
          autoDelete: false
        startupScripts:
        - scriptSecretRef:
            name: configure-password
          name: configure-password
      EOF
      

   3. Verifica que la VM auxiliar se esté ejecutando:

      kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME
      

7. Consola de la VM auxiliar y vuelve a generar el initramfs:

   1. De la consola a la VM auxiliar:

      kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG
      

   2. Usa las siguientes credenciales:

      username="newuser"

      password="Lime+blaze8legend"

   3. Monta las particiones del disco conectado:

      sudo mkdir /mnt/kernelpanic/
      sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
      sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
      sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
      sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
      sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
      sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
      sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
      sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
      sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
      sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/
      
      sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
      sudo mount -t proc procfs /mnt/kernelpanic/proc/
      sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
      sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
      sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/
      

   4. Establece una conexión chroot con el punto de montaje y vuelve a generar el archivo initramfs:

      sudo chroot /mnt/kernelpanic/
      dracut --regenerate-all --force
      

   5. Verifica que se haya generado el nuevo initramfs para la nueva versión del kernel: 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64

      ls /boot/initramfs-* -l
      

      El resultado es similar al siguiente:

      -rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
      -rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
      -rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img
      

8. Detén la VM auxiliar:

   kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'
   

9. Desconecta el disco de la máquina virtual auxiliar:

   1. Abre la especificación de la VM auxiliar en un editor:

      kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME
      

   2. Elimina el siguiente código del archivo YAML:

      - virtualMachineDiskRef:
          name: PROBLEM_VM_BOOT_DISK
        autoDelete: false
      

10. Vuelve a conectar el disco de arranque a la VM que ha fallado:

    1. Abre la especificación de la VM que ha fallado en un editor:

       kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
       

    2. Actualiza la especificación de la siguiente manera:

       # Several lines of code are omitted here.
       spec:
         disks:
         - boot: true
           virtualMachineDiskRef:
             name: PROBLEM_VM_BOOT_DISK
       

11. Inicia la VM que falla:

    kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'
    

12. Verifica que la actualización se haya solucionado:

    1. Comprueba que el recurso personalizado Node de esta VM muestra Ready y usa la versión más reciente del kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64:

       kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide
       

       El resultado debería ser similar al siguiente:

       NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
       vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0
       

    2. Comprueba la versión del kernel después de establecer una conexión SSH con la VM:

       uname -a
       

       En el resultado debe aparecer la nueva versión del kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.

El ingester sigue sin estar en buen estado y no se olvida automáticamente después de la actualización

Versiones: 1.14.x

Síntomas: el subcomponente log-infra no está en buen estado después de la actualización. Para comprobarlo, ejecuta el siguiente comando: none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Para comprobar el estado de un subcomponente, debes usar el archivo kubeconfig del clúster principal para KUBECONFIG y el espacio de nombres del clúster actual para CLUSTER_NAMESPACE. El comando devolverá el valor de STATUS del subcomponente. Si el estado no es ReconciliationCompleted, significa que el subcomponente no está en buen estado en ese clúster.

Algunos pods de Loki del clúster no están en buen estado. Para enumerar todos los pods de Loki, ejecuta el siguiente comando: none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Este comando muestra todos los pods de Loki, incluidas las columnas STATUS y READY. Se considera que un pod no está en buen estado si su estado no es Running o si algunos de sus contenedores no están listos. La columna READY, con el formato a/b, indica el número de contenedores listos a del total b. Un pod está en buen estado cuando a y b son iguales.

Comprueba los registros de los pods de Loki que no estén en buen estado: none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

Los registros de salida de los pods incorrectos son similares a los siguientes:

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

Solución alternativa: Para eliminar un ingester incorrecto del anillo de Loki, consulta el runbook AL-R0031.

Vertex AI

Las solicitudes de traducción pueden generar el código de error RESOURCE_EXHAUSTED

Versiones: 1.14.3

Síntomas: después de enviar una solicitud de traducción, se obtiene el código de error RESOURCE_EXHAUSTED en el mensaje de respuesta. Este error se produce cuando superas un límite de frecuencia del sistema. Se ha agotado un recurso, como una cuota por usuario, el número máximo de consultas por segundo o el espacio de todo el sistema de archivos.

Solución alternativa: pide a tu operador de infraestructura que reinicie los fragmentos del backend del servicio de traducción. Después, vuelve a enviar las solicitudes de traducción con intervalos más largos entre ellas o enviando solicitudes más cortas.

batchTranslateDocument solicita que se devuelva un error 503

Versiones: 1.14.3

Síntomas: después de enviar una solicitud batchTranslateDocument, obtienes el código de error 503 "Batch Document translation is not implemented" en el mensaje de respuesta. Este error se produce porque el método BatchTranslateDocument requiere el servicio Aspose, que solo se implementa cuando el parámetro operable enableRAG se define como true en el clúster.

Solución alternativa: pide a tu operador de infraestructura que defina el parámetro enableRAG operable como true en el clúster de administrador de la organización siguiendo estos pasos:

1. Crea un recurso personalizado SubcomponentOverride en un archivo YAML llamado vai-translation.yaml con el parámetro operable enableRAG definido como true:

   apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
     name: "vai-translation"
     namespace: SHARED_SERVICE_CLUSTER_NAMESPACE
   spec:
     subComponentRef: "vai-translation"
     backend:
       operableParameters:
         enableRAG: true
   

   Sustituye SHARED_SERVICE_CLUSTER_NAMESPACE por el espacio de nombres del clúster de servicios compartidos.

2. Aplica el recurso personalizado SubcomponentOverride al clúster de administrador de la organización:

   kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
   

   Sustituye ORG_MGMT_KUBECONFIG por la ruta al archivo kubeconfig de gestión del clúster de administrador de la organización.

No se pueden inicializar el pod y el servicio frontend de traducción u OCR.

Versiones: 1.11.x, 1.12.x, 1.13.x y 1.14.x

Síntomas: durante las actualizaciones, se vuelve a crear el clúster de la base de datos, lo que provoca que el secreto secret-store de ODS en el clúster de servicios compartidos esté obsoleto y no esté sincronizado. Por este motivo, el pod y el servicio de frontend de traducción u OCR no se inicializan.

Solución:

Elimina el secreto del clúster de servicios compartidos:

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

Sustituye SHARED_SERVICE_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de servicios compartidos.

Si el servicio que da problemas es Traducción, sustituye VAI_API_NAMESPACE por "g-vai-translation-sie". Si el servicio que da problemas es OCR, sustituye VAI_API_NAMESPACE por "g-vai-ocr-sie".

Un controlador vuelve a crear el secreto automáticamente y lo vuelve a sincronizar con el clúster de la base de datos.

Vertex AI Search

Componentes de búsqueda atascados en el estado de conciliación

Versiones: 1.14.6

Síntomas: Los subcomponentes vaisearch-conversation y vaisearch-frontend se quedan en el estado Reconciling si no se crea ningún recurso personalizado SearchConfig en la organización.

Solución alternativa: se puede ignorar el problema. Una vez creado el recurso personalizado SearchConfig, los subcomponentes deben completar su conciliación.

Servidor

La rotación de credenciales de la BIOS se queda bloqueada en la fase de solicitud de restablecimiento

Versiones: 1.14.4

Síntomas: la rotación de las credenciales de la BIOS se queda bloqueada en el estado de solicitud de restablecimiento. Para comprobarlo, consulta la anotación gdch.cluster.gke.io/rotation-status del secreto bios-credentials del servidor:

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

Sustituye SERVER_NAME por el nombre del servidor. El resultado del comando es "reset-requested" si la rotación se bloquea.

Solución alternativa: Para completar la rotación de credenciales de la BIOS, sigue el runbook SERV-R0018.

No se pueden aprovisionar los servidores instalados anteriormente

Versiones: 1.14.6

Síntomas: los servidores no se aprovisionan después de desaprovisionarse y volver a aprovisionarse, concretamente en relación con problemas con la gestión de claves de iLO (Integrated Lights-Out) y HSM (módulo de seguridad de hardware). Los servidores, que antes formaban parte de una organización desactivada, tienen errores durante el aprovisionamiento de imágenes, lo que indica que no se puede encontrar un dispositivo adecuado, a menudo debido a discos bloqueados por claves antiguas o eliminadas. Es posible que veas un error como este:

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

Solución alternativa: elimina y vuelve a instalar los servidores afectados para que se aprovisionen. Para obtener más información, consulta los runbooks SERV-R0020 y SERV-R0021.

Máquinas virtuales

No se pueden importar imágenes

Versiones: 1.14.4. 1.14.5

Corregido: 1.14.6

Síntomas: la importación de una imagen mediante el comando gdcloud compute images import falla y se muestra un error Unauthorized debido a que se ha agotado el tiempo de espera de la sesión.

Solución: Usa la API de KRM para importar tu propia imagen en lugar de la CLI de gdcloud.

La importación de imágenes KRM tarda mucho

Versiones: 1.14.6 y posteriores

Síntomas: la importación de una imagen mediante la API KRM tarda mucho en completarse. El recurso VirtualMachineImageImport permanece en el estado TranslationJobInProgress durante un periodo prolongado, lo que indica que la fase de traducción no se completa como se esperaba. El pod image-translation pasa al estado CrashLoopBackOff.

Solución:

1. Vuelve a intentar la importación creando un recurso VirtualMachineImageImport con otro nombre.
2. Monitoriza el estado VirtualMachineImageImport comprobando periódicamente el recurso hasta que cambie a WaitingForTranslationJob. Para obtener más información, consulta el manual de operaciones de VMM R0007.