Copia de seguridad y restablecimiento
No se puede editar el plan de restablecimiento de la copia de seguridad del clúster
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 restablecimiento nuevo y borra el anterior, o bien edita el plan de restablecimiento con la CLI de kubectl.
El tamaño del disco de origen no es válido
Versiones: 1.14.4 y 1.14.5
Síntomas: La IU muestra de forma incorrecta el tamaño de un disco como 0 MB y su hora de creación como "Desconocida" debido a un cambio en el modelo de datos de backend después de la migración a la arquitectura de organización v2.
Solución: No hay ningún método alternativo para ver esta información a través de la IU.
Los pods del agente y del plano de control se reinician debido a la falta de memoria
Versiones: 1.14.3 y 1.14.4
Síntomas: Es posible que se reinicien los Pods del agente y del plano de control 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 manual de ejecución BACK-R0005. Aumenta la memoria de los Pods a 2 GiB.
No se aplican los SLO de copia de seguridad y restablecimiento
Versiones: 1.14.3 y 1.14.4
Síntomas: Las métricas y las alertas del objetivo de nivel de servicio (SLO) de GDC no se configuran de forma predeterminada, ya que no se instala la definición de recurso personalizado necesaria. Estas alertas se usan en Grafana.
Soluciones alternativas: Para habilitar los SLO para copias de seguridad y restablecimiento en GDC, sigue el manual de ejecución BACK-T0001.
Las políticas de retención no se aplican a las copias de seguridad importadas
Versiones: Todas las versiones de Google Distributed Cloud (GDC) aislado pueden verse afectadas.
Síntomas: Cuando se adjunta un repositorio de copias de seguridad al clúster, se sincronizan todos los metadatos de copias de seguridad y restablecimiento, y los repositorios se tratan como copias de seguridad importadas. Estas copias de seguridad importadas se omiten de forma incorrecta durante la conciliación, lo que significa que se ignoran las políticas de retención y las copias de seguridad se conservan de forma indefinida.
Solución alternativa: 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 políticas de retención, quita la etiqueta de las copias de seguridad con los siguientes comandos de kubectl:
Configura las variables de entorno necesarias:
export KUBECONFIG=KUBECONFIG export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME export NAMESPACE=BACKUP_PLAN_NAMESPACEReemplaza lo siguiente:
KUBECONFIG: Es la ruta de acceso al archivo kubeconfig.BACKUP_REPOSITORY_NAME: Es el nombre del repositorio de copias de seguridad.NAMESPACE: Es el espacio de nombres que contiene el plan de copia de seguridad.
Enumera todas las copias de seguridad importadas:
kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAMEQuita 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-Para quitar las etiquetas de una sola copia de seguridad, haz lo siguiente:
export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n $NAMESPACE backup.gdc.goog/imported-repository-
Falla la copia de seguridad parcial de la VM
Versiones: 1.14.3 y 1.14.4
Síntomas: Si no se puede crear una copia de seguridad de una VM entre muchas, se marca como fallida la copia de seguridad de toda la VM.
Solución alternativa: Limita la cantidad de VMs por plan de copia de seguridad.
Limpia los recursos de copias de seguridad huérfanos después de la eliminación de un clúster de usuario o de servicio
Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6 y 1.14.7
Síntomas: Cuando se borra un clúster de usuario o de servicio, los recursos del agente de copias de seguridad asociados (como StatefulSet, Pods, secretos, etcétera) creados en la infraestructura de la organización y el clúster de administración no se limpian automáticamente. Esto puede dejar recursos huérfanos y, si el clúster se vuelve a crear con el mismo nombre, el Pod del agente de copias de seguridad no funcionará.
Solución alternativa: Los recursos huérfanos existen en un espacio de nombres dedicado en el clúster de infraestructura de la organización. Para limpiarlos, debes borrar este espacio de nombres.
Configura los archivos kubeconfig para la infraestructura de la organización y los clústeres de administración.
export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig> export MGMT_KUBECONFIG=<path_to_management_kubeconfig>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-systemgpc-backup-user-vm-2-cluster-systemgpc-backup-g-org-1-shared-service-cluster-system
Borra el espacio de nombres. Se borrarán todos los recursos que contiene, incluidos el StatefulSet y el Pod del agente de copias de seguridad en el clúster de administración y el secreto en el clúster de infraestructura.
# Replace <namespace-name> with the actual namespace kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}" kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"Para confirmar que la limpieza se realizó 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:?}"Ahora, 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 el borrado de VirtualMachineRestore a través de la CLI o la IU
Versiones: 1.14.3, 1.14.4, 1.14.5, 1.14.6 y 1.14.7
Síntomas: El controlador de VirtualMachineRestore no limpia automáticamente los recursos subyacentes (VolumeRestore, Restore) cuando se borra un recurso de VirtualMachineRestore. Esto requiere que se realice una limpieza manual.
Esto se aplica tanto si borras con kubectl delete como con la IU.
Solución alternativa: La solución alternativa implica borrar manualmente los recursos dependientes en el orden correcto y, luego, quitar el finalizador del recurso VirtualMachineRestore.
Configura el archivo kubeconfig para que apunte al clúster de administración.
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>Identifica el
VirtualMachineRestoreque se borrará y su espacio de nombres.export VM_RESTORE_NAME=<vm-restore-to_be_deleted> export NAMESPACE=<namespace-of-vm-restore>Busca y borra los recursos de
VolumeRestoreasociados. Se crean con una etiqueta que los vincula alVirtualMachineRestore.# 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:?}"Busca y borra los recursos de
Restoreasociados. Se crean con una etiqueta que los vincula alVirtualMachineRestore.# 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:?}"Ahora, realiza
kubectl deletesi aún no lo hiciste y quita el finalizador del recursoVirtualMachineRestore. Este es el paso final que permite que el recolector de basura de Kubernetes borre el recurso.kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"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 borró.
El Pod del plano de control de la copia de seguridad falla debido a que no hay memoria suficiente
Versiones: 1.14.4 y posteriores
Síntomas: El pod gpcbackup-controlplane-controller en el espacio de nombres del sistema gpc-backup del clúster de infraestructura de la organización muestra un estado de CrashLoopBackOff. Cuando se produce este error, las operaciones de copia de seguridad y restablecimiento fallarán, dejarán de responder o no funcionarán como se espera.
Solución alternativa: Aumenta los límites de memoria para la implementación de gpcbackup-controlplane-controller siguiendo BACK-R0005. Este método aplica un SubcomponentOverride para ajustar la CPU, las solicitudes de memoria y los límites.
La eliminación del clúster de usuarios está atascada
Versiones: 1.14.7 y posteriores
Síntomas: Los clústeres se atascan en el estado de eliminación debido a problemas con el finalizador.
Solución alternativa: Verifica si los volúmenes de almacenamiento tienen relaciones SnapMirror antes de borrar el clúster. Para obtener más información, consulta BACK-R0109.
La restauración se detiene debido a que hay una reclamación de volumen persistente pendiente
Versiones: 1.14.3 y posteriores
Síntomas: A veces, los controladores de reclamos de volúmenes persistentes (PVC) no pueden comunicarse con los agentes de copias de seguridad en el clúster de infraestructura de la organización. Si bien este problema no afecta la funcionalidad de copia de seguridad, puede hacer que una operación de restablecimiento de volumen se quede atascada en un estado Pending y, finalmente, se agote el tiempo de espera. Este problema afecta las operaciones de restablecimiento que involucran un restablecimiento de volumen, como la función de restablecimiento del servicio de bases de datos para la clonación y el restablecimiento de una carga de trabajo del usuario.
Si surge este problema, las operaciones de restablecimiento posteriores en el clúster afectado fallarán hasta que reinicies manualmente el agente de copias 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 copias de seguridad:
Sigue IAM-R0005 para obtener el rol de depurador de BACK necesario (
back-cluster-debugger) aplicando el recursoExpirationClusterRoleBinding.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.
Identifica el agente de copia de seguridad que facilita el restablecimiento:
kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \ --all-namespaces | grep gpcbackup-agentReemplaza
ORG_INFRA_KUBECONFIGpor la ruta de acceso al archivo kubeconfig del clúster de infraestructura de la organización.El resultado es similar a este:
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 22dLee 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 del resultado es
gpc-backup-user-vm-1-cluster-system, el agente de copia de seguridad esgpcbackup-agent-user-vm-1.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"Reemplaza lo siguiente:
ORG_INFRA_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de infraestructura de la organización.BACKUP_AGENT: Es el agente de copias de seguridad que identificaste en el paso anterior.NAMESPACE: Es el espacio de nombres que identificaste en el paso anterior.
Si hay registros coincidentes, significa que tienes este problema conocido.
Solución alternativa: Para solucionar el problema, completa los siguientes pasos:
Reinicia el agente de copias de seguridad:
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \ statefulsets/BACKUP_AGENT -n NAMESPACEReemplaza lo siguiente:
ORG_INFRA_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de infraestructura de la organización.BACKUP_AGENT: Es el agente de copias de seguridad que identificaste cuando confirmaste el problema.NAMESPACE: Es el espacio de nombres que identificaste cuando confirmaste el problema.
El resultado es similar a este:
statefulset.apps/gpcbackup-agent-g-org-1-shared-service restartedEspera hasta 20 minutos para que se reanuden automáticamente las operaciones pendientes.
Puedes realizar otro restablecimiento para el mismo clúster de destino después de que finalice el reinicio del agente de copias de seguridad. Después de completar esta solución alternativa, no habrá efectos secundarios. Solo es necesario completar esta solución alternativa una vez por clúster afectado.
Administración de clústeres
El subcomponente kub-gpu-controller no se concilia
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 mostrará el siguiente resultado:
│ 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
│ >
Esta falla impide que las máquinas con GPU se inicien en la organización gdchservices.
Solución: Actualiza a la versión 1.14.4 o posterior para mitigar el problema.
El clúster estándar no puede quitar un grupo de nodos
Versiones: 1.14.3, 1.14.4 y 1.14.5
Corregido: 1.14.6
Síntomas: No se pueden quitar los grupos de nodos obsoletos de los clústeres estándar, y los grupos de nodos no se borran dentro del plazo esperado. Los clústeres estándar se encuentran en versión preliminar privada y es posible que no estén disponibles para todos los clientes.
Solución: Quita manualmente los grupos de nodos obsoletos.
El clúster está atascado en el estado de eliminación
Versiones: 1.14.6 y posteriores
Síntomas: Cuando se borra un clúster de Kubernetes, es posible que se quede atascado en un estado Deleting. Ejecuta el siguiente comando para verificar el estado de tu clúster:
kubectl get cluster CLUSTER_NAME -n platform \
--kubeconfig MANAGEMENT_API_SERVER
El resultado es similar a este:
NAMESPACE NAME STATE K8S VERSION
platform test-cluster Deleting 1.28.15-gke.100
También puedes verificar el problema revisando el estado del espacio de nombres de tu clúster:
kubectl describe ns/CLUSTER_NAME-cluster \
--kubeconfig MANAGEMENT_API_SERVER
El resultado es similar a este:
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á atascado en el estado Terminating, y las condiciones NamespaceContentRemaining y NamespaceFinalizersRemaining se establecen como True.
Solución alternativa: Para solucionar el problema, completa los siguientes pasos:
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'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 bases de datos
En esta sección, se describen los problemas conocidos del servicio de bases de datos.
El clon de la base de datos de AlloyDB Omni se bloqueó
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 determinado, 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á atascado en la fase "ProvisionInProgress".
Solución alternativa: Para evitar este problema, elige con cuidado el momento a partir del COMPLETETIME de las copias de seguridad correctas.
Enumera las copias de seguridad disponibles de AlloyDB Omni desde las que se puede clonar en el servidor de la API de administració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 el 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, 1.14.8
Síntomas: Se activa la alerta de DNS DNS-A0021, que sugiere GlobalCustomerRootDNSServerNotReachable.
El CR de Probe para global-customer-root-dns en org-mp no tiene egress: true en la especificación.
Solución alternativa:
Establece la ruta de acceso de KUBECONFIG para
org-mgmt:export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIGPausa el CR del sondeo de administración del subcomponente
core-mz:kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=trueEdita el CR de sondeo actual de
org-mp:kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dnsActualiza la especificación para incluir
egress: Truey aplica el cambio. Ten en cuenta queCLUSTER_NAMEyGLOBAL_CUSTOMER_ROOT_IPno cambian.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 verificador, y las alertas falsas desaparecerán en 15 minutos.
Almacenamiento de archivos o en bloque
No se puede activar el volumen del recurso compartido de archivos en la VM
Versiones: 1.14.6 y 1.14.7
Síntomas: No se pueden actualizar los permisos de almacenamiento de red cuando se agrega un nodo nuevo a un clúster, lo que puede provocar que se rechacen las solicitudes de montaje de NFS.
Es posible que veas un error access denied by server cuando actives un recurso compartido de archivos NFS.
Solución alternativa: Reinicia los reconciliadores file-share o proxy-group, o bien modifica el recurso FileShare para activar una actualización.
Firewall
Falta la regla de política de seguridad para la dirección en el CR de Subnet
Versiones: 1.14.3
Síntomas: No se puede acceder a una organización porque falta el grupo de direcciones del firewall en el recurso personalizado de subred global que creó el cliente en el servidor de la API global de la organización.
Solución alternativa: Sigue los pasos que se indican en el manual de servicio FW-G0002 para agregar manualmente una regla de política de seguridad que permita el tráfico.
Los firewalls de GDC rechazan el tráfico hacia el OIR para el plano de administración y el plano 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 administració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 agregar 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 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
Reemplaza lo siguiente:
OCIT_CIDR: Son los rangos de direcciones IP en el campoocitCIDRdel Cuestionario de entrada del cliente (CIQ).MGMT_CIDR: Son los rangos de direcciones IP en el campooobManagementCIDRsdel Cuestionario de entrada del cliente (CIQ).ZONE_INFRA_CIDR: Son los rangos de direcciones IP en el campozoneInfraCIDRsdel Cuestionario de entrada del cliente (CIQ).
El firewall de GDC rechaza 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 del manual de operaciones para agregar de forma manual reglas de política de seguridad que permitan el tráfico.
El 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 firewall no puede analizar este objeto y las actualizaciones de la configuración del firewall se bloquean. El siguiente es un ejemplo de un 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 alternativa: Evita usar el nombre de la organización como identificador. Hay algunas opciones para corregir el AttachmentGroup incorrecto.
Elige una de las siguientes opciones para corregir el AttachmentGroup problemático.
Agrega una cadena al final del identificador original con un símbolo de 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: OrgMixedAgrega un guion y una cadena al principio del identificador original:
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: OrgMixedReemplaza el identificador original por una cadena diferente:
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 la copia de seguridad y el restablecimiento
Versiones: 1.14.3
Síntomas: Después de una copia de seguridad y un restablecimiento de Harbor, los secretos de la CLI dejan de ser válidos y deben volver a crearse.
Solución alternativa: Para mitigar este problema, sigue estos pasos:
- Accede a Harbor con una cuenta de usuario de IAP.
- Haz clic en tu nombre de usuario y selecciona Perfil de usuario.
- Haz clic en Más.
- Crea otro secreto de la CLI de forma automática o manual.
Para obtener más información sobre Harbor en GDC, consulta la descripción general de Harbor.
El trabajo de copia de seguridad y restablecimiento de Harbor compite por el permiso
Versiones: 1.14.3 y 1.14.4
Síntomas: Cuando existen varias instancias de Harbor en diferentes proyectos de usuarios, las operaciones de copia de seguridad y restablecimiento compiten por los controles de acceso basados en roles y experimentan una alta tasa de errores.
Solución alternativa: Para mitigar este problema, sigue estos pasos para crear manualmente una vinculación de rol para cada espacio de nombres en el que se creen instancias de Harbor:
Configura las variables de entorno necesarias:
INSTANCE_NAMESPACE=INSTANCE_NAMESPACE INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIGReemplaza lo siguiente:
INFRA_CLUSTER_KUBECONFIG: Es la ruta al archivo kubeconfig del clúster de infraestructura.INSTANCE_NAMESPACE: Es el espacio de nombres en el que se crean las instancias de Harbor del servicio de Harbor administrado (MHS).
Crea la vinculación 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 de 0
Versiones: 1.14.3 y 1.14.4
Síntomas: Por el momento, no se implementó la medición del tamaño de las copias de seguridad de Harbor. En la consola de GDC, los campos SizeBytes muestran un valor de 0, y la columna Size muestra un valor de 0 MB. Por el momento, se espera que esta configuración se comporte de esta manera.
Se produjo un error de permiso 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 cuando veas 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 agregó recientemente a la página Harbor Container Registry, pero no se otorgó permiso de lectura para el recurso de copia de seguridad a los roles de IAM que no sean el administrador de instancias de Harbor.
Los demás elementos de la consola de GDC en la página Harbor Container Registry siguen funcionando según lo previsto. Para obtener más información sobre los roles en GDC, consulta Definiciones de roles.
Página de rotación de contraseñas de la base de datos atascada
Versiones: 1.14.3, 1.14.4, 1.14.5 y 1.14.6
Síntomas: Se producen errores relacionados con la autenticación para las solicitudes a la base de datos, como failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), y hay muchas solicitudes de rotación generadas automáticamente para un solo secreto rotativo.
Solución alternativa: Borra las solicitudes de rotación adicionales que no estén listas para un secreto rotativo.
Establece KUBECONFIG en el servidor de la API de mp.
Exporta el espacio de nombres:
NAMESPACE=haas-systemBusca si hay secretos rotativos en
haas-systemque no estén listos:kubectl get rotatablesecrets -n ${NAMESPACE?}El resultado podría verse como este ejemplo:
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 91dExporta el nombre del secreto rotativo, por ejemplo:
ROTATABLE_SECRET=haasdb-pw-haas-aliceBorra 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
Aún se pueden detectar las licencias de prueba desactivadas del HSM
Versiones: 1.14.3, 1.14.4 y 1.14.5
Síntomas: Debido a un problema conocido existente en CipherTrust Manager, las licencias de prueba desactivadas aún se pueden detectar y podrían activar advertencias de vencimiento falsas.
Solución alternativa: Consulta HSM-R0003 para verificar las licencias normales activas y borrar las licencias de prueba desactivadas.
Pérdida del descriptor de archivos del daemon del host del HSM
Versiones: 1.14.x
Síntomas: Si los HSM se ejecutan durante más de 30 días, una pérdida de descriptores de archivos puede hacer que el servicio host-daemon deje de responder, lo que genera un error ServicesNotStarted.
Solución: Reinicia el servicio host-daemon. Para ello, pídele a tu operador de infraestructura (IO) que se conecte al HSM a través de SSH como usuario ksadmin y ejecute el siguiente comando:
sudo systemctl restart host-daemon
Si eso no funciona, tu IO puede reiniciar el HSM en mal estado.
Los HSM fallan con el error ValidateNetworkConfig después del inicio
Versiones: 1.14.x
Síntomas: Los recursos personalizados del HSM no ingresan en un estado Ready y fallan debido a un error ValidateNetworkConfig. Este error muestra el siguiente mensaje: data0 interface MAC address {} is not active. Este error ocurre 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 para la red de datos. Es seguro seguir este manual incluso si más de un HSM tiene este error.
RENDIMIENTO
Alertas de SLO de falsa alarma
Versiones: 1.14.3
Síntomas: Un SLO de successRange se activa de forma errónea.
Solución alternativa: Solicita al operador de infraestructura (IO) que verifique si la alerta es un problema real o una falsa alarma.
Para ello, cuando se active una alerta, sigue el manual de ejecución correspondiente para abordar la causa subyacente de la alerta del objetivo de nivel de servicio (SLO).
Caso uno: Si el runbook resuelve el problema correctamente y la alerta deja de activarse, el IO puede cerrar el incidente asociado.
Caso dos: Si se completa el manual de operaciones, pero la alerta sigue activándose, esto indica una posible falsa alarma. Verifica si el SLO está roto:
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" }'Según el resultado, si se confirma que la alerta es falsa, el IO debe silenciar la alerta en la instancia aislada de GDC. De lo contrario, debe derivar el caso a la asistencia de Cloud.
En cualquier caso, es adecuado que IO derive el problema a la asistencia de Cloud para verificar que el componente operativo esté en buen estado.
Configuraciones de SLO basadas en indicadores no válidas
Versiones: 1.14.3 y 1.14.4
Síntomas: Un subconjunto de objetivos de nivel de servicio (SLO) no completará los eventos buenos, malos o totales debido a una configuración incorrecta. Los SLO en cuestión se basan en los indicadores de Prometheus y deben configurarse en consecuencia.
Solución alternativa:
Versión 1.14.3: No hay solución alternativa. Por lo tanto, no se activarán las alertas de SLO para los SLO afectados.
Versión 1.14.4: Hay una solución alternativa disponible para corregir el SLO. Para resolver este problema, se debe aplicar el parámetro de configuración isGauge: true a la especificación del SLO.
Ejemplo de una configuración de medidor para 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 conocida de SLO que se fijan con este parámetro de configuración es la siguiente:
- SLOs de firewall:
- fw-packet-discard-errors-slo
- fw-packet-discard-no-error-slo
- fw-packet-discard-unknown-protocol-slo
- fw-uptime-slo
- SLOs 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
Administración de identidades y accesos
Error en la creación de la vinculación de rol de IAM
Versiones: 1.14.3
Síntomas: El sistema genera los nombres de las vinculaciones de roles de IAM. Estos nombres tienen una longitud máxima de 63 caracteres y el formato user-idp-prefix-rolename. En los casos en 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 con roles predefinidos o personalizados no se asignarán a los usuarios.
Solución alternativa: Es posible que la creación de la vinculación de roles se realice correctamente si el nombre del rol predefinido o personalizado es muy corto, por ejemplo, de 4 a 5 caracteres.
No se pudo crear la vinculación del rol de IAM 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 del 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 una PSA administre sus propios permisos.
Solución alternativa: Confirma que tienes el rol organization-iam-admin. Luego, asígnate el rol de project-iam-admin en el espacio de nombres del proyecto del PSA objetivo y asígnale al PSA el rol de project-iam-admin. Esta configuración de permisos permite que el PSA se asigne permisos adicionales a sí mismo o a otros PSA.
Los proyectos nuevos experimentan demoras en la creación de roles predefinidos
Versiones: 1.14.3
Síntomas: Cuando se crea un proyecto nuevo, faltan roles predeterminados, como project-bucket-object-admin.
Solución: 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 rol
Versiones: 1.14.4
Síntomas: Cuando se crea la primera vinculación de rol para una nueva identidad de servicio con la consola de GDC, se informa que la creación de la vinculación de rol se realizó correctamente, pero en realidad no funciona. Cualquier otra acción en la identidad del servicio fallará y no tendrá efecto, incluida la adición o eliminación de vinculaciones de roles.
Solución alternativa: Usa la CLI de gdcloud para crear la primera vinculación de rol para una identidad de servicio. Todas las acciones futuras con la identidad del servicio que se realicen con la consola de GDC funcionarán correctamente después de que se adjunte la primera vinculación de rol. Para obtener más información, consulta Cómo asignar una vinculación de rol a la identidad del servicio.
Los AO no pueden otorgarse acceso a roles en el clúster de infraestructura
Versiones: 1.14.3 1.14.4
Se corrigió: Parche rápido 21 de la versión 1.14.3
Síntomas: Los AO no tienen forma de otorgarse a sí mismos ni a otros usuarios acceso a ningún rol en el clúster de infraestructura.
Solución alternativa: Los usuarios de AO deben comunicarse con los IO para obtener el acceso necesario. Los IO pueden usar la IAC para proporcionar a los usuarios de AO el acceso requerido.
El token de la cuenta de servicio existente deja de ser válido
Versiones: 1.14.3
Se corrigió: Parche rápido 21 de la versión 1.14.3
Síntomas: El token de la cuenta de servicio existente que emitió el clúster de usuario deja de ser válido porque se cambia el argumento service-account-issuer del servidor de la API después de que el clúster se encuentra en estado de ejecución tras el arranque. Este problema hace que el Pod, por ejemplo, el Pod con un contenedor secundario istio-proxy, en el clúster del usuario no pueda autenticarse con el token de la cuenta de servicio, y se necesitarían horas para que el token de la cuenta de servicio se actualice con las nuevas configuraciones.
Solución alternativa: 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)
Falla en la reconciliación del subcomponente debido a la falta de 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 requerido 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 recopilación de métricas de ConfigSync de IaC
Versiones: 1.14.3 y 1.14.4
Síntomas: Un problema en el subsistema de supervisión de ConfigSync de IaC impide que se inicie la implementación de otel-collector. No se recopilan métricas de ConfigSync para la supervisión y las alertas.
Solución alternativa: Completa los siguientes pasos en el clúster root-admin:
- Pausa el subcomponente
iac-configsync-mon. - Edita el objeto
MetricsProxySidecar/iac-configsync-metricsen el espacio de nombresconfig-management-monitoring. En el archivo YAML de
MetricsProxySidecar/iac-configsync-metrics, busca lo siguiente:spec: [...] destinations: - certificate: secretName: iac-configsync-mon-target-certCambia esta sección por la siguiente:
spec: [...] destinations: - certificate: secretName: iac-configsync-mon-mon-target-certReinicia la implementación de
otel-collectoren el espacio de nombresconfig-management-monitoring.
Falla de RootSync de IaC
Versiones: 1.14.3
Síntomas: Hay un problema en los recursos de sincronización de ConfigSync desde GitLab a los clústeres debido a la falta de un secreto 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:
- Sigue el manual de IAC-R0015 para resolver el problema de la falta del secreto iac-creds. Rota las credenciales del administrador de IaC y de ConfigSync.
Inventario
No se puede conciliar la auditoría del 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 administración.
Solución: Crea un silencio en AlertManager para silenciar la alerta component_reconciliation_errors para component: inv.
Sistema de administración de claves
El KMS configurado para usar una clave raíz de CTM no realiza una conmutación por error cuando un HSM no está disponible
Versiones: 1.14.x
Síntomas: Algunas solicitudes al KMS fallan cuando no hay un HSM disponible y hay otros HSM disponibles que se podrían haber usado. Este problema solo se aplica cuando el KMS está configurado para usar una clave raíz de CTM.
Solución alternativa: Quita el HSM no disponible del HSMCluster siguiendo el manual de ejecución HSM-P0006. Luego, 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 de kms-backend y restablece la conexión a los HSM en HSMCluster.
Balanceadores de cargas
No se pudo crear el balanceador de cargas global debido al agotamiento del CIDR de la subred
Versiones: 1.14.3
Síntomas: Falla la creación del balanceador de cargas interno o externo global debido a que no hay suficientes direcciones IP en las subredes globales. El sistema no puede asignar direcciones IP de forma dinámica para los balanceadores de cargas globales debido a un controlador que usa una ruta de código incorrecta. El balanceador de cargas hace referencia a una sola subred y, si esa subred no tiene más direcciones IP disponibles, no hay forma de cambiar a otra subred. Esta limitación hace que se muestre el error.
Solución alternativa: 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 Configura subredes para las 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 cargas no ingresan en un estado Ready.
Solución alternativa: Debes crear recursos Backend en los que el campo spec tenga un valor. Los recursos Backend identifican los extremos del balanceador de cargas. Si no se proporciona un valor para el campo spec, es posible que se produzcan estados de error.
La modificación de los recursos del balanceador de cargas no reconcilia los servicios
Versiones: 1.14.3
Síntomas: La modificación de los recursos personalizados del balanceador de cargas no reconcilia los servicios del balanceador de cargas.
Solución alternativa: Para mitigar este problema, borra y vuelve a crear el balanceador de cargas. Para ello, borra los recursos BackendService y ForwardingRule de ese balanceador de cargas.
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 cargas falla en lugar de validar y rechazar la configuración.
Solución: Debes proporcionar los nombres correctos de las zonas que se utilizan. Si el balanceador de cargas está configurado de forma incorrecta, se deben borrar y volver a crear los recursos personalizados del balanceador de cargas.
Error de webhook del balanceador de cargas global y zonal
Versiones: 1.14.3
Síntomas: Se muestra 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 borra 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
Logging
El Pod de Loki falla o se produce un error de OOMKilled durante la reproducción del WAL
Versiones: 1.14.3, 1.14.4 y 1.14.5
Síntomas:
Los Pods audit-logs-loki-io en el espacio de nombres obs-system ingresan en un estado CrashLoopBackOff. Esto se debe a fallas prematuras en la sonda de actividad o a un cierre por falta de memoria (OOM) durante la reproducción del registro de escritura anticipada (WAL), debido a un valor de wal_replay_ceiling que supera el límite de memoria del pod.
Solución alternativa:
Sigue estos pasos para ajustar la configuración de Loki y permitir una reproducción correcta del WAL. Los cambios se aplicarán al clúster afectado (p. ej., root-admin o org-infra).
Establece
KUBECONFIG=/path/to/affected-cluster.kubeconfigcomo una variable de entorno.Pausa el
LoggingPipelineReconcilerpara evitar que el controlador revierta los cambios manuales. Aplica este 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} | jqReduce el valor de
replay_memory_ceilingen el ConfigMapaudit-logs-loki-io-cma8GB.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 [...]Opcional: Ajusta la escala del proxy del objeto. Si los Pods de
obj-proxyestán cerca de sus límites de recursos, ajusta la escala de la implementación para controlar el aumento de carga durante la recuperación.a. Verifica el uso de recursos:
kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}b. Si el uso es alto, ajusta la escala de 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 (p.ej., de
12000Mia16000Mi) si es necesario.Aumenta el tamaño del PVC para el pod afectado (p.ej.,
loki-storage-audit-logs-loki-io-0de70Gia75Gi) para evitar la presión del disco. Sigue el procedimiento internoSUPP-R001para cambiar el tamaño de la PVC. El reinicio del siguiente paso aplica el nuevo tamaño.Agrega un
startupProbeal StatefulSetaudit-logs-loki-iopara permitir que se reproduzca el WAL antes de que comiencen las verificaciones de estado en funcionamiento. Cuando guardes el cambio, se activará un reinicio progresivo de los pods (de 5 a 10 minutos).kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}Agrega este
startupProbea la especificación del contenedoraudit-logs-loki-io:startupProbe: failureThreshold: 1000 httpGet: path: /ready port: loki scheme: HTTP periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10
Verifica la solución alternativa
Verifica el estado del Pod y del StatefulSet: Comprueba que todos los Pods
audit-logs-loki-ioesténRunningy 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}Confirma que se haya 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} ; echoConfirma que la recuperación del WAL se realizó correctamente verificando 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"Verifica que el uso del directorio
/waldentro del pod sea bajo.kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /walVerifica el estado del anillo de Loki:
a. Redirecciona el puerto 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. Verifica que todas las instancias estén en buen estado en
http://<DATA_IP>:43100/ring.
Limpia la anulación y el proxy de objeto
Después de la verificación correcta, realiza los siguientes pasos de limpieza.
Cómo quitar la anulación del subcomponente:
kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}Si aumentaste 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 para algunos clústeres
Versión: 1.14.3
Síntomas: Los webhooks de AlertManager no pueden enviar 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 reside 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 de forma repetida. Sigue estos pasos para buscar errores repetidos:
Exporta las variables de entorno:
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIGReemplaza
MGMT_API_KUBECONFIGpor la ruta de acceso al archivo kubeconfig del servidor de la API de administración.Busca el pod:
kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \ -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-Obtén los registros:
kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-systemReemplaza
POD_NAMEpor el nombre del pod.Busca errores repetidos similares a los siguientes:
Errorsendingtherequest ... read: connection reset by peer
Solución alternativa: La solución alternativa recomendada para este problema es pausar dos subcomponentes, uno para las alertas de supervisión de metadatos y otro para las alertas normales. Luego, reemplaza la etiqueta egress.networking.gke.io/enabled: "true" por networking.private.gdc.goog/infra-access: enabled en la implementación 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 puerta de enlace de salida.
Sigue estos pasos para aplicar la solución alternativa recomendada:
Exporta las variables de entorno:
export ROOT_KUBECONFIG=ROOT_KUBECONFIG export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG export ORG=ORGReemplaza lo siguiente:
ROOT_KUBECONFIG: Es la ruta al archivo kubeconfig del clúster de administrador raíz.MGMT_API_KUBECONFIG: Es la ruta al archivo kubeconfig del servidor de la API de administración.ORG: Es el espacio de nombres de la organización.
Pausa los 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- Pausa el subcomponente
Actualiza la implementación de
mon-alertmanager-servicenow-webhook-backendque abarca la mayoría de las alertas:kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \ -n mon-system mon-alertmanager-servicenow-webhook-backendReemplaza la etiqueta en
spec.template.metadata.labelsdeegress.networking.gke.io/enabled: "true"anetworking.private.gdc.goog/infra-access: "enabled".Actualiza la implementación de
meta-alertmanager-servicenow-webhookque abarca las alertas relacionadas con la pila de supervisión:kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \ -n mon-system meta-alertmanager-servicenow-webhookReemplaza la etiqueta en
spec.template.metadata.labelsdeegress.networking.gke.io/enabled: "true"anetworking.private.gdc.goog/infra-access: "enabled".
Como alternativa, puedes usar Grafana para ver las mismas alertas.
En ocasiones, se duplican los incidentes de ServiceNow
Versión: 1.14.3
Síntomas: Es posible que veas incidentes duplicados de ServiceNow para el mismo pod.
Solución alternativa: Puedes identificar los tickets duplicados comparando las huellas digitales en la descripción del incidente.
Es posible que las métricas de infraestructura sean demasiado sensibles
Versión: 1.14.3
Síntomas: Es posible que veas alarmas para la alerta oclcm-reconciler-success-rate.
Solución alternativa: Puedes silenciar la alerta de forma segura. Esta es una alerta demasiado ruidosa, y estamos trabajando para mejorar la señal.
Es posible que las métricas de conciliación sean demasiado sensibles
Versión: 1.14.3, 1.14.4 y 1.14.5
Síntomas: Es posible que veas alarmas para la alerta component_reconciliation_errors.
Solución: Puedes silenciar la alerta de forma segura siguiendo el runbook MON-R2009. Esta es una alerta 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 en estado de activación en el clúster de administrador raíz.
El incidente en ServiceNow se ve como en el 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
Solución alternativa: Sigue estos pasos para resolver el problema solo en el clúster de administrador raíz:
Borra la etiqueta
monitoring.gdc.goog/metamonitoring-project=mon-systemenmon-a0001-blackbox-monitoring-obs-systemMonitoringRule.Borra todas las reglas de grabación con el nombre
mon_metrics_pipeline_absenty el valor de la etiqueta del clústerORG_NAME-admindemon-a0001-blackbox-monitoring-obs-systemMonitoringRule.En el siguiente ejemplo, se muestra una regla de grabación
mon_metrics_pipeline_absentque se borrará: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 de MON_A0001_slow y MON_A0001_fast vuelven al estado Normal después de unos minutos (alrededor de 40 minutos).
El administrador de controlador del administrador raíz muestra una tasa de errores alta
Versión: 1.14.3
Síntomas: Es posible que veas alarmas para la alerta ControllerReconciliationErrorRateHigh. El administrador del controlador mostrará registros que indican lo siguiente: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\"
not found
Solución alternativa: Puedes inhabilitar de forma segura el controlador que genera el error.
Exporta las variables de entorno:
export ROOT_KUBECONFIG=ROOT_KUBECONFIGEdita la implementación del administrador del controlador raíz:
kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \ -n gpc-system root-admin-controllerEn el contenedor
manager, si aún no hay un argumento--disable-reconcilers, agrega uno con el valor--disable-reconcilers=ApplianceStorageTunnelReconciler. Si hay uno, agrega el reconciliadorApplianceStorageTunnelReconcilercon una coma. Por ejemplo:--disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler
Los registros de errores deberían borrarse.
Los paneles de KUB no muestran datos en ninguno de los paneles de PA
Versiones: 1.14.3
Síntomas: Los paneles de KUB no muestran datos en todos los paneles de Grafana para los administradores de la plataforma.
Solución alternativa: Pausa el subcomponente del KSM y actualiza monitoringtarget y metricsproxysidecar:
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=trueReemplaza lo siguiente:
- ORG_NAME: Es el nombre de la organización.
- ROOT_ADMIN_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig de
root-admin.
Agrega lo siguiente a
mon-kube-state-metrics-metrics-proxymetricsproxysidecar en la sección.spec.destinations:- certificate: secretName: mon-pa-kube-state-metrics-cert port: 8091El objeto metricsproxysidecar actualizado podría verse de la siguiente manera:
... 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: ...Quita la sección
matchClusters:delmon-pa-kube-state-metricsde monitoringtargetspec. Elmon-pa-kube-state-metricsmonitoringtargetspecactualizado podría verse de la siguiente manera:... 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 de observability-admin-debugger
Versiones: 1.14.3 y 1.14.4
Síntomas: Los IO no pueden reiniciar los Pods de Cortex o Prometheus en el espacio de nombres mon-system.
Solución alternativa:
Para organizaciones:
- Pausa el subcomponente
iam-common. Actualiza el roleTemplate
observability-admin-debugger/iam-systemde 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:
- Pausa el subcomponente
iam-common. Actualiza el roleTemplate
observability-admin-debugger-root/iam-systemde 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 otorgar 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"
No se ven las métricas ni los registros entre zonas después de agregar una zona nueva
Versiones: 1.14.*
Síntomas: En el panel de Grafana, no se muestran los registros ni las métricas de la zona agregada recientemente.
Solución 1: Reinicia la implementación de datasource-proxy:
kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system
Esto reiniciará los Pods de datasource-proxy y actualizará la configuración del extremo entre zonas para la zona agregada recientemente.
El finalizador MonitoringTarget bloquea la eliminación del espacio de nombres
Versiones: 1.14.3 y 1.14.4
Síntomas: No se borra el espacio de nombres y hay clústeres en mal estado en la organización respectiva.
Solución alternativa: Quita los finalizadores de forma manual de los recursos personalizados MonitoringTarget que bloquearon la eliminación del espacio de nombres.
La eliminación del proyecto se detuvo debido a finalizadores pendientes del panel y la fuente de datos
Versiones: 1.14.3 y 1.14.4
Se corrigió: Parche rápido 22 de la versión 1.14.3
Síntomas: Los proyectos no se borran y el espacio de nombres de finalización tiene errores como 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 alternativa: Borra los finalizadores del panel y de la fuente de datos de forma manual.
No se ven las métricas de KSM
Versiones: 1.14.3
Se corrigió: Parche rápido 22 de la versión 1.14.3
Síntomas: Los paneles de KUB muestran No Data en todos los paneles.
Solución alternativa: Pausa el subcomponente del KSM y actualiza monitoringtarget y metricsproxysidecar.
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=trueReemplaza lo siguiente:
- ORG_NAME: Es el nombre de la organización.
- ROOT_ADMIN_KUBECONFIG: Es la ruta de acceso a kubeconfig del administrador raíz.
Agrega lo siguiente a
mon-kube-state-metrics-metrics-proxymetricsproxysidecar en.spec.destinations:- certificate: secretName: mon-pa-kube-state-metrics-cert port: 8091El objeto
mon-kube-state-metrics-metrics-proxyactualizado de MetricsProxySidecar se ve como en este ejemplo:... 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: ...Quita la sección
matchClusters:de la especificación demon-pa-kube-state-metricsmonitoringtarget. La especificación demon-pa-kube-state-metricsmonitoringtarget actualizada se ve de la siguiente manera:... 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 MON-R0001.
Solución alternativa:
Si el problema se observa en el clúster de administrador, crea el siguiente
SubcomponentOverrideenroot-admincon el manual IAC-R0004. Para otros clústeres, como el de usuario, el de perímetro o el compartido, crea elSubcomponentOverrideen${ORG}-mp.kind: SubcomponentOverride metadata: name: mon-cortex-tenant namespace: <NAMESPACE> spec: backend: operableParameters: concurrency: 1024 resourcesLimit: cpu: "8" memory: 16Gi subComponentRef: mon-cortex-tenantEncuentra el
NAMESPACEcorrecto: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 ReconciliationCompletedEl espacio de nombres es la raíz si la canalización no funciona para
root-admin, o bien org-1 si la canalización no funciona paraorg-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 ReconciliationCompletedAquí, el espacio de nombres correcto podría ser
g-org-1-perimeter-cluster,g-org-1-shared-service-cluster,user-vm-1-clusterouser-vm-2-cluster, según el clúster para el que no funcione la canalización de métricas del sistema.Después de aplicar
SubcomponentOverride, reinicia la implementación de cortex-tenant en los clústeres respectivos. Verifica si los valores se actualizaron en el clúster respectivo:kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yamlActualiza el campo de simultaneidad.
Reinicia las implementaciones de cortex-tenant:
kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system
Multiusuario
Console no indica errores de creación del grupo 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 falla la creación de un grupo de nodos, la IU muestra de forma incorrecta un mensaje de creation in progress, lo que indica que el grupo de nodos se creó correctamente.
Solución alternativa: Usa la CLI de gdcloud para validar la creación del grupo de nodos.
Multizona
La zona inaccesible redirecciona 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 redirecciona 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 alternativa: Usa la URL zonal para solucionar el problema. Si la URL zonal tampoco funciona, pídele a tu operador de infraestructura (IO) que diagnostique si la zona para la que recibes 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 IAM requerido para usar el comando gdcloud zones list no se aplica al universo de GDC de forma predeterminada. El rol faltante, que no está disponible como rol predefinido, impide usar la CLI de gdcloud para enumerar zonas.
Solución alternativa: Aplica el rol de IAM global-zone-viewer y los recursos de vinculación de roles al servidor de la API global:
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:authenticatedAplica 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 que vean zonas con gdcloud zones list.
Errores intermitentes de acceso a la URL de la consola global
Versiones: 1.14.x
Síntomas: Cuando accedes a 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 podría deberse a un error de red subyacente y no a una representación precisa del estado de tu sesión.
Solución alternativa: Accede a la consola de GDC con las URLs zonales para administrar los recursos globales desde cada zona. Para obtener más información sobre cómo cambiar los contextos zonales desde la consola de GDC, consulta Administra recursos en diferentes zonas.
Redes
El ajuste del orden de las zonas MultiZoneNetworkConfig provoca una falla en el reemplazo de la configuración
Versiones: Todas las versiones de 1.14.x pueden verse afectadas.
Síntomas:
El estado
READYde los conmutadores de la parte superior del bastidor (ToR) es False. Para confirmar esto, ejecuta el siguiente comando:kubectl get torswitches -ALa configuración de reemplazo del conmutador falla con un error que indica que la entrada ya existe. Esto se puede ver en los registros de reemplazo de la configuración del conmutador. El mensaje de error es similar al siguiente:
% Insertion failed - entry already exists
Este problema se debe al ajuste del orden de las zonas dentro de MultiZoneNetworkConfig. El sistema genera números de secuencia para las reglas de la lista de acceso de BGP según la posición de cada zona en la lista de configuración. Si se cambia el orden de las zonas, el sistema genera reglas nuevas con números de secuencia diferentes que entran en conflicto con las reglas que ya están presentes en el conmutador.
Soluciones alternativas:
Para resolver este problema, quita manualmente la configuración de la lista de acceso de la ruta AS de BGP en conflicto de cada conmutador ToR afectado. Esto permite que el sistema concilie y aplique la configuración correcta.
- Establece una conexión SSH a cada conmutador ToR que no esté en estado
Ready. Ingresa al modo de configuración global:
config tQuita la configuración de la lista de acceso en conflicto:
no ip as-path access-list other-zonesSalir del modo de configuración
Después de que se ejecute este comando en todos los conmutadores afectados, el reconciliador aplicará la configuración correcta y los conmutadores pasarán a un estado READY.
Vencimiento de la confirmación de config-replace
Versiones: Todas las versiones de 1.14.x pueden verse afectadas.
Síntomas:
Una gran cantidad de listas de control de acceso (LCA) provocan un tiempo de espera agotado cuando se configuran los conmutadores de red. El recurso personalizado BorderLeafSwitch no está en estado Ready y, cuando se establece una conexión SSH con el interruptor no listo, se ve el estado Commit expiry.
Por ejemplo, el siguiente comando muestra el estado:
sh config-replace log verify
El resultado es similar a este:
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 alternativa:
En las versiones 1.14.3 o 1.14.7 y posteriores, edita el recurso personalizado SubcomponentOverride llamado pnet-core-override en el espacio de nombres root y agrega 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 conmutadores. Configura 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 el reemplazo de la configuración y confirma los cambios.
Pausa el interruptor:
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"Sigue el manual de PNET-P0001 para obtener acceso al conmutador.
Busca la configuración que deseas reemplazar:
switch-cli# dir | grep new_configCompleta la acción config-replace:
switch-cli# configure replace <new_config_file>Este proceso puede tardar más de cinco minutos.
Después de que config-replace se ejecute correctamente, confirma el cambio:
switch-cli# configure replace commitPara reanudar el interruptor, haz lo siguiente:
kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-
Falla la Deployment con el ASN de BGP de 4 bytes
Versiones: 1.14.3 y 1.14.4
Síntomas: La configuración del Protocolo de puerta de enlace fronteriza (BGP) con un número de sistema autónomo (ASN) de 4 bytes en los conmutadores de red genera errores de configuración. Sin una configuración de BGP aplicada correctamente, es posible que la red dentro de esa zona de GDC no pueda establecer un enrutamiento adecuado, lo que generaría problemas de conectividad, incapacidad para anunciar rutas o inestabilidad general de la red. Por el momento, no hay una solución alternativa.
Se bloqueó el tráfico de Anycast global
Versiones: 1.14.3
Síntomas: Las listas de control de acceso (LCA) bloquean el tráfico que se dirige a los extremos de difusión global por IP única.
Solución alternativa:
Para resolver el problema por el que las Listas de Control de Acceso (LCA) bloquean el tráfico de difusión global a cualquier destino, debes crear un recurso personalizado SubcomponentOverride en el clúster de administrador raíz para permitir de forma explícita el tráfico a los bloques CIDR de difusión a cualquier destino del servidor DNS global. Lleva a cabo los pasos siguientes:
Encuentra todos los bloques CIDR de difusión global a cualquier dirección. Para encontrar los bloques de CIDR de difusión global a cualquier dirección que debes actualizar, sigue estos pasos:
Conéctate al servidor de la API global raíz.
Enumera todos los recursos personalizados de subred en todos los espacios de nombres con el siguiente comando:
kubectl get subnet -AFiltra el resultado para encontrar recursos de subred en los que el filtro
metadata.namecontenga la palabra claveanycast.Para cada recurso de subred que se encuentre con
anycasten su nombre, anota el valor despec.subnet. Este valor representa un bloque CIDR de difusión global a cualquier destino.
En el clúster de administrador raíz, crea un recurso personalizado
SubcomponentOverridellamadopnet-trafficpolicy-dc-overrideen el espacio de nombres raíz. Para cada subred de difusión por IP múltiple que identificaste en el paso anterior, agrega las reglas 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-dcReemplaza lo siguiente:
INTERCONNECT_RULE_DESCRIPTION: Es el texto descriptivo de la regla de red de interconexión.GLOBAL_ANYCAST_CIDR: Es el bloque CIDR de difusión global, como 136.125.38.128/28. Para cada anycast que encuentres en el paso anterior, crea la regla con este archivo YAML.HAIRPIN_RULE_DESCRIPTION: Es el texto descriptivo de la regla de red de hairpin.
La falla parcial del DCI provoca la pérdida de tráfico
Versiones: 1.14.3
Síntomas: Cuando ambos vínculos de interconexión del centro de datos (DCI) que conectan el conmutador de hoja de borde de una zona al conmutador de operador, o cuando el conmutador de hoja de borde de una zona sufre una falla de hardware, se pierde alrededor del 50% del tráfico de red entre zonas.
El nombre del VRF es demasiado largo
Versiones: 1.14.2
Síntomas: Es posible que veas un mensaje como este ejemplo, que indica que los conmutadores no están en buen estado cuando ejecutas este comando:
sh config-replace log verify
El resultado podría verse como este ejemplo:
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 de la CR de la organización puede tener un máximo de 19 caracteres.
Falla la comunicación del Pod de StatefulSet
Versiones: 1.14.3 y 1.14.4
Corregido: Parche rápido 23 de la versión 1.14.3, versión 1.14.5
Síntomas: Problemas o interrupciones de conectividad debido a que no se controlan correctamente los objetos de Cilium Endpoint (CEP) después de que se reinicia el pod de StatefulSet.
Esto podría provocar que la identidad del extremo no administrado haga que las políticas de red descarten erróneamente el tráfico legítimo. Para verificar los pods afectados, comprueba que no esté presente el objeto CEP correspondiente:
kubectl get cep -A | grep [*POD_IP*]
Solución alternativa: Reinicia los Pods de 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
Este es un problema poco frecuente que puede ocurrir si el pod anetd queda atrapado en un bucle de fallas.
Un recurso del kernel que es esencial para la conectividad del nodo puede quedar atascado 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 resolverlo.
Versiones:
Todas las versiones de Google Distributed Cloud (GDC) aislado pueden verse afectadas.
Síntomas:
Si ocurre este problema, es posible que observes los siguientes síntomas:
- Los nodos están atascados en el estado
NotReady - La descripción del nodo muestra el mensaje
kubelet:kubelet was found unhealthy; repair flag : true. - No es posible acceder al nodo a través de SSH en la red de datos
Solución alternativa:
Sigue estas instrucciones para reparar cada nodo no saludable:
Obtén la dirección IP de administración del nodo afectado:
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'Obtén acceso SSH al nodo afectado.
Conéctate al nodo con SSH usando la dirección IP de administración del nodo.
En el nodo, ejecuta el siguiente comando y, luego, cierra la conexión SSH:
tc filter del dev bond0 egressReinicia el daemonset
anetdpara el clúster con el nodo afectado:kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system
Crear un PNP de permiso de salida para todo rechaza el tráfico inesperado
Versiones:
Todas las versiones de Google Distributed Cloud (GDC) aislado pueden verse afectadas.
Síntomas: La política de red del proyecto (PNP) allow-all-egress permite el tráfico a los extremos dentro del proyecto y a los extremos externos fuera del clúster, pero no permite el tráfico a los extremos 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 PNP de allow-all-egress podría verse de la siguiente manera:
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
namespace: PROJECT_1
name: allow-all-egress
spec:
policyType: Egress
subject:
subjectType: UserWorkload
egress:
- {}
Solución alternativa: Borra el PNP allow-all-egress. De forma predeterminada, una vez que se inhabilita la Protección contra robo de datos, se permite el tráfico a los extremos externos y del proyecto fuera de los extremos del clúster y del sistema.
kubectl delete pnp [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]
Problema del panel de Grafana del SLO de disponibilidad entre zonas multizona
Versiones: 1.14.3
Síntomas: En Grafana, el panel del SLO de pnet-cross-zone-availability no muestra ninguna métrica.
Solución: Sigue el manual de ejecución PNET-P0001 para obtener acceso al conmutador y verificar manualmente el estado de la sesión de BGP y la conectividad de varias zonas.
Las puertas de enlace de entrada de administración y del plano de datos no se pueden conciliar
Versiones: 1.14.3
Síntomas: Los subcomponentes asm-dataplane-ingress o asm-management-ingress no se pueden reconciliar con 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 podría 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 administración o en el servidor de la API global. Esto se puede inferir 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 administración, mientras que un recurso con el sufijo networking.global.gdc.goog está presente en el servidor de la API global.
Después de identificar el servidor de la API, borra 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 del selector de proyectos en la API de ProjectNetworkPolicy
Versiones: 1.14.3 y 1.14.4
Síntomas: Cuando creas una política de red del proyecto que incluye el campo projectSelector y la ves en la consola de GDC, la IU muestra todos los proyectos seleccionados para la política en lugar de los proyectos en el campo projectSelector.
Solución alternativa: Usa la API para crear y leer una política de red del proyecto que incluya el campo projectSelector.
Sistema operativo
Falla el aprovisionamiento del servidor
Versiones: 1.14.3
Síntomas: Durante el aprovisionamiento del servidor, es posible que se muestren los siguientes errores 401 en el recurso personalizado BaremetalHost correspondiente cuando se descarga la imagen de SO desde el registro de Harbor, y el servidor se queda atascado en un bucle de desaprovisionamiento y reaprovisionamiento.
Para verificar si se producen estos errores, describe el recurso personalizado BaremetalHost:
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system
El resultado podría verse como este ejemplo:
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 alternativa:
Obtén el nombre y el espacio de nombres del
nodePoolClaimal que pertenece el servidor:kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'El resultado podría verse como este ejemplo:
{ "name": "control-plane-extension-pool-o2-standard1-96-gdc-metal", "namespace": "gpu-org-lancer" }Obtén el nombre de la imagen de SO de
NodePoolClaim:kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'Obtén la URL de la imagen de SO desde
OSImageMetadata:kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'Actualiza el recurso personalizado
Servercon la URL de la imagen de 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'"}]'
Es posible que OS NodeUpgrade se detenga en el paso NodeOSInPlaceUpgradePostProcessingCompleted
Versiones: 1.14.3 y 1.14.4
Síntomas:
Durante la actualización de un nodo, NodeUpgradeTask se bloquea en el paso NodeOSInPlaceUpgradePostProcessingCompleted con un error de reconciliador 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 encontró discrepancias inesperadas en el paquete del nodo. Específicamente, 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.
El mensaje de error enumera los paquetes específicos que no pasaron la verificación. Ejemplo de fragmento:
{"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 qué problema es la causa:
Cause-A: La máquina no está disponible, lo que provoca queOSArtifactSnapShotesté desactualizado.Verifica si el nodo que se está actualizando sigue en buen estado o no, y si el trabajo de
OSArtifactSnapShotcorrespondiente está fallando.Si
OSArtifactSnapShotestá desactualizado y no se puede acceder a la máquina durante más de 20 minutos, continúa conMitigation-A. De lo contrario, sigue buscandoCause-B.Cause-B: Falla silenciosa en la actualización de RPMEn 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 objetos
ConfigMapque 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-upgradeSi el mapa de configuración "after-upgrade" contiene menos paquetes que el mapa de configuración "before-upgrade", significa que la actualización se anuló de forma silenciosa y no se actualizaron todos los paquetes. Continúa hacia
Mitigation-B.
Solución alternativa:
Mitigation-A: Reparar máquina inaccesible
Intenta reparar la máquina reiniciándola. Si la máquina sigue sin estar disponible después de los intentos de reinicio, comunícate con el equipo de SERV para obtener más ayuda.
Una vez que se pueda volver a acceder a la máquina, borra el elemento OSArtifactSnapShot para forzar la reconciliación. Una vez que se concilia OSArtifactSnapShot, NodeUpgradeTask debe continuar con el siguiente paso.
Mitigation-B: Vuelve a intentar la operación NodeUpgradeTask
Establece una conexión SSH a la máquina que se está actualizando y recopila los siguientes registros para solucionar problemas en el futuro. Se deben recopilar los siguientes archivos:
- /var/log/dnf.log
- /var/log/dnf.rpm.log
- dnf history > dnf_history.log
- rpm -qa --last > rpm_last.log
Borra el
NodeUpgradeTaskque falla. Esto activará un reintento deNodeUpgradeTasken el nodo en particular. El nuevoNodeUpgradeTaskdebería completar la actualización del RPM y continuar con el siguiente paso.
Es posible que OS NodeUpgrade se detenga en el paso de creación del servidor de paquetes
Versiones: 1.14.3 y 1.14.4
Síntomas:
Cuando se crea un CR de NodeUpgrade, se reanuda y permanece en in-progress durante más de 30 minutos, es posible que falle de forma silenciosa en la etapa de creación del servidor de paquetes. El síntoma es que un NodeUpgrade permanece con .status.upgradeStatus=in-progress, pero no se carga ningún .status.tasks:
status:
duration: 0s
upgradeStatus: in-progress
Para confirmar aún más que esto falla en la creación del 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 registrationname already used in an existing DNS
Luego, sugiere que algunos otros recursos del servidor de paquetes que usan otros NodeUpgrade siguen activos y entran en conflicto con el recurso que se creará para el NodeUpgrade actual que está en espera.
Solución alternativa:
Para confirmar aún más, puedes verificar el recurso real del servidor de paquetes (de cierta API, como dnsregistration.network.private.gdc.goog en el servidor de la API de administración del clúster que administra el CR de NodeUpgrade) y encontrar el NodeUpgrade que posee esos recursos. Si el NodeUpgrade propietario del DNSRegistration ya finalizó, pero el recurso DNSRegistration aún no se borró, puedes borrar el objeto DNSRegistration si todos sus objetos NodeUpgrade referenciados finalizaron.
Enumera todos los CR de
DNSRegistrationpara el servidor de paquetesNodeUpgrade:kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bmConsulta el CR del propietario
NodeUpgradepara unDNSRegistrationen particular: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 tener problemas y detenerse en cualquier etapa del proceso.
Versiones: 1.14.4, 1.14.5 y 1.14.6
Síntomas:
NodeUpgradeTask El CR sigue siendo inferior a in-progress durante más de 2 horas, aunque es posible que se pueda completar automáticamente si se le da suficiente tiempo.
La CR de NodeUpgradeTask está en curso desde hace más de dos horas. Si bien es posible que, con el tiempo, se complete automáticamente, el problema subyacente es la incapacidad del reconciliador de políticas del SO para administrar de manera eficiente un gran volumen de CR de OSPolicy. Este problema ocurre durante el paso NodeOSInPlaceUpgradeCompleted.
Para confirmar aún más 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 contiene una entrada OSPolicy del NodeUpgradeTask, significa que el controlador está sobrecargado.
Solución alternativa:
Detén todas las CR de OSPolicy no esenciales durante el proceso de actualización.
El comando "storage cp" de un archivo grande interrumpe la kube-api de org-mgmt
Versiones: 1.14.3 y posteriores
Síntomas: Durante una operación de gdcloud storage cp o una operación de gdcloud system container-registry load-oci desde una estación de trabajo de OIC, existe una pequeña posibilidad de que se pierda el acceso a org-infra y, luego, se interrumpa el kube-api de org-mgmt. Este es un problema poco frecuente, por lo que es útil recopilar datos para el equipo de ingeniería.
Solución alternativa: Cuando se produzca este problema, sigue estos pasos:
- Para cada nodo del plano de control (CP), ejecuta
uptimepara ver si los nodos se reiniciaron en las últimas 24 horas. - Toma nota de la hora del reinicio.
- Ejecuta
dmesg | grep -i 'kernel panic'para verificar si se produjeron errores de kernel en cada nodo de CP justo antes del reinicio. - En cada nodo de CP, verifica si las tarjetas NIC de Mellanox están instaladas con el siguiente comando:
lspci | grep -i eth | grep -i mellanox. Si no hay NIC de Mellanox, deja de leer este problema conocido. En cada nodo de CP, verifica la siguiente configuración 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 valueSi
rx-gro-hw(ver arriba) está configurado como "off" en todos los nodos, deja de leer este problema conocido.Recopila 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-planeEn 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:Para mitigar el problema de configuración de la red,
rx-gro-hwdebe estaroff. 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 offVuelve a revisar la configuración:
[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"Vuelve a intentar la operación original, como
gdcloud storage cpogdcloud system container-registry load-oci. Si el problema persiste, comunícate con el equipo de ingeniería.
Infrastructure: Core Services de Operations Suite (OIC)
Bajo rendimiento del host de salto
Versiones: Todas las versiones de Google Distributed Cloud (GDC) aislado pueden verse afectadas.
Síntomas: Las operaciones del navegador o del sistema tardan demasiado en completarse.
Solución alternativa:
Aumenta el recuento de CPU virtuales en los Jumphosts a través del administrador de Hyper-V en BM03 y BM04:
- Selecciona una VM de Jumphost y, luego, haz clic en settings en el panel de acciones.
- Selecciona Procesador y, luego, aumenta el recuento en Cantidad de procesadores virtuales a 4 o más, según la carga de trabajo.
- Repite el proceso para los demás hosts de salto.
Resource Manager
No se pueden borrar proyectos en la consola de GDC
Versiones: 1.14.3 y 1.14.4
Síntomas: La consola de GDC proporciona el botón Borrar borrar para los proyectos existentes en la página Detalles del proyecto, pero el botón no funciona.
Solución alternativa: Para borrar un proyecto existente, debes usar la CLI de gcloud. Para obtener más información, consulta Borra un proyecto.
Faltan guías de Ansible de la organización
Versiones: 1.14.3
Síntomas: Cuando se crea una organización, el trabajo create-ansible-playbooks que crea los playbooks de Ansible necesarios falla de forma silenciosa. La falta de playbooks de Ansible causa problemas, como la ausencia de máquinas virtuales perimetrales y problemas para crear una organización global.
Solución alternativa: Sigue el manual de ejecución OS-R0009 para crear manualmente las guías de Ansible de la organización que faltan.
La organización global asimétrica muestra configuraciones zonales inexistentes
Versiones: 1.14.4
Síntomas: Cuando se crea 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
El resultado de YAML es 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 para las organizaciones de la versión 1, ya que las configuraciones zonales asimétricas no se admiten para las organizaciones de la versión 2.
Solución alternativa: 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 borró el grupo de nodo trabajador del clúster de infraestructura
Versiones: 1.14.3 y 1.14.4
Síntomas: Cuando se quita un grupo de nodo trabajador de la especificación del CR de Organization, el grupo de nodos no se borra 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 borrará.
# 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 nodo trabajador de la especificación del CR de Organization, borra manualmente el CR de NodePoolClaim para 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 borren por completo el NodePoolClaim y sus CR de NodePool asociados, es decir, el comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} ya no genera el grupo de nodo trabajador.
Almacenamiento
No se pueden borrar los buckets creados con el comando gdcloud config set zone
Versiones: 1.14.7 y posteriores
Síntomas: Los buckets creados con el comando gdcloud config set zone no se pueden borrar debido a problemas de permisos, ya que el comando intenta operar en la zona incorrecta.
Solución alternativa: Usa la consola para establecer la zona específica de un bucket o reemplaza la marca --zone por --location en el comando de gcloud.
Se activan alertas de SLO de OBJ
Versiones: 1.14.3 y 1.14.4
Síntomas: Se activan alertas de SLO para OBJ debido a un error de ErrFailedStreamingDecryptRequest en el proxy de OBJ: obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo.
Solución: Silencia la alerta. El error se identifica de forma incorrecta como un error del sistema cuando se debe a que el usuario finalizó la conexión, lo que no se contabiliza en el SLO.
ETag vacío de S3 UploadPart
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 genera un InternalServerError a partir de una interrupción de la red y el código de estado no se actualiza a 500 InternalServerError.
Solución: Vuelve a intentar la solicitud como si hubiera fallado anteriormente.
Los Pods no se pueden activar debido a un error mkfs.ext4 de Trident
Versiones: 1.14.3
Síntomas: Después de intentar activar los pods, observas que fallan todos los pods que están en transición hacia un nodo en particular o desde él. Aparece un mensaje de error de RPC: DeadlineExceeded desc = context deadline exceeded, que indica que el nodo está atascado. Cuando aparece este mensaje, pierdes la capacidad de realizar operaciones adicionales de Trident en el nodo en cuestión. Los volúmenes que publican datos no se ven afectados, pero los volúmenes que se mueven hacia el nodo y desde él podrían sufrir una interrupción.
Solución alternativa:
Inspecciona los registros de Trident en el nodo en el que el Pod intenta realizar el montaje y verifica que la cola aumente. Los registros podrían ser similares a los siguientes:
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"Accede al nodo y observa el resultado de
dmesg. Los registros podrían ser similares a los siguientes: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)Después de confirmar que tienes un error de Trident
mkfs.ext4, reinicia el nodo.
Trident no puede crear un volumen debido a un error existente
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 alternativa:
Sigue estos pasos para resolver el problema:
- Toma nota del nombre interno del volumen del evento. Por ejemplo, el evento de muestra que se muestra en la sección Síntomas muestra el nombre interno del volumen
trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a. - Sigue el manual de ejecución FILE-R0105 para acceder a ONTAP.
Borra el volumen:
volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a
file_block_iscsi_sessions_unhealthy alert informa 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 más nodos experimentan fallas de iSCSI. El controlador file-observability usa un recopilador de métricas personalizado para hacer un seguimiento del estado de las sesiones de iSCSI en cada nodo de Kubernetes, pero, en algunos casos, el recopilador de métricas no puede analizar el resultado del comando iscsiadm y registra cero sesiones de iSCSI en ejecución, aunque iSCSI tenga sesiones en buen estado.
Solución alternativa:
Sigue estos pasos para verificar que iSCSI no tenga problemas y silencia la alerta si, de hecho, se trata de un falso positivo:
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 para cada nodo del clúster. Si algún nodo informa una métricafb_sessions_running_countde0, anota el nombre del nodo.Para cada nodo con métricas de
fb_sessions_running_countque devuelven0, ejecuta los siguientes comandos:Establece una conexión SSH con el nodo afectado.
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.Si el comando anterior devolvió sesiones de iSCSI correctamente, confirmaste que la alerta para este nodo es un falso positivo.
Cuando confirmes que todos los nodos afectados tienen sesiones iSCSI en buen estado y que la alerta se activa de forma errónea, crea un silencio en AlertManager para silenciar la alerta
file_block_iscsi_sessions_unhealthy.
Se activa la 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 más discos de ONTAP no están en buen estado. El controlador file-observability usa un recopilador de métricas personalizado para hacer un seguimiento del estado de cada disco en 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 alternativa:
Sigue estos pasos para verificar que los discos sean de repuesto y silenciar la alerta del disco:
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 para cada disco de ONTAP. Si algún disco informa una métrica de 0 (no saludable), anota el nombre del disco.Para cada disco con métricas de
disks_labels_healthyque devuelvan0, ejecuta los siguientes comandos:Conéctate al clúster de ONTAP a través de SSH y ejecuta el comando
disk show -disk <disk-name> -fields statecon el nombre del disco recopilado de la consulta de métricas.Verifica que el resultado del comando indique que el estado del disco es
presentospare. Si el disco se encuentra en cualquier otro estado que no seapresentospare, deriva el problema al equipo de ingeniería de bloqueo de archivos.Si el disco en cuestión informa
presentospare, podemos confirmar que la alerta no debería activarse para este disco. Crea un silencio en AlertManager para silenciar la alertafile_block_storage_disk_failurecon la etiquetadisk_nameestablecida en el nombre del disco.
Una vez que se hayan creado los silencios para todos los discos de repuesto, navega a Grafana para verificar que las alertas hayan dejado de activarse.
Se activa la alerta file_block_storage_node_peer_connection_unhealthy después de que se restablece 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 falla una o más conexiones entre los nodos de ONTAP. El controlador file-observability usa un recopilador de métricas personalizado para hacer un seguimiento del estado de estas conexiones. Se conoce un problema por el que esta alerta seguirá activándose incluso después de que se restablezca la conexión fallida.
Solución alternativa:
Sigue estos pasos para verificar que las conexiones entre los nodos estén en buen estado y silencia la alerta para los nodos:
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 para cada conexión entre los nodos de almacenamiento del clúster. Si alguna conexión informa una métrica destorage_node_peer_connectionsde0, anota las etiquetassource_node,destination_ipystorage_cluster_namede la métrica.Para cada métrica
storage_node_peer_connectionsque devuelva0, ejecuta los siguientes comandos:Establece una conexión SSH con el clúster de almacenamiento de ONTAP desde la etiqueta
storage_cluster_name.Ejecuta el siguiente comando en el clúster de ONTAP con los valores de las etiquetas
source_nodeydestination_ip:
ping -node <node-name> -destination <destination-ip> -verbose -show-detailSi el comando ping falla, deriva el problema al equipo de ingeniería de bloqueo de archivos. Si el comando ping se ejecuta correctamente, se confirma que las conexiones de los nodos 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_storage_node_peer_connection_unhealthycon las etiquetassource_nodeydestination_ipestablecidas en el nodo de origen y la IP de destino de la métrica.
Una vez que se hayan creado los silencios para todos los nodos en buen estado, navega a Grafana para verificar que las alertas hayan dejado de activarse.
Se activa la alerta file_block_nodes_not_reachable después de que se restablece la conexión
Versiones: 1.14.3
Síntomas: En algunos entornos, se activa la alerta file_block_nodes_not_reachable, que indica que fallan una o más conexiones de los servicios de IPsec en los nodos de Kubernetes a ONTAP. El controlador file-observability usa un recopilador de métricas personalizado para hacer un seguimiento del estado de estas conexiones. Se conoce un problema por el que esta alerta seguirá activándose incluso después de que se restablezca la conexión fallida.
Solución alternativa:
Sigue estos pasos para verificar que las conexiones en los nodos estén en buen estado y silenciar la alerta para los nodos:
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 para cada nodo del clúster. Si algún nodo informa una métricafb_all_nodes_reachablede0, anota el nombre del nodo.Para cada nodo con métricas de
fb_all_nodes_reachableque devuelven0, ejecuta los siguientes comandos:Establece una conexión SSH con el nodo afectado.
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}' | shEl comando intentará hacer ping a ontap con todas las conexiones IPsec. Si falla algún ping en el 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 están en buen estado y que la alerta se activa de forma errónea.
Si todas las pruebas de ping del comando se realizan correctamente, confirmamos 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_reachablecon la etiquetanode_nameestablecida en el nombre del nodo.
Una vez que se hayan creado los silencios para todos los nodos en buen estado, navega a Grafana para verificar que las alertas hayan dejado de activarse.
Se activa la alerta de file_block_storage_high_node_total_latency durante cargas de trabajo pesadas
Versiones: 1.14.3
Síntomas: Es posible que se active la alerta file_block_storage_high_node_total_latency en ciertos entornos debido a cargas de trabajo pesadas en los nodos de almacenamiento. Esta alerta persiste hasta que se procesan por completo esas cargas de trabajo. Incluso cuando el rendimiento de lectura y escritura en los volúmenes es rápido, los nodos de almacenamiento pueden seguir informando una latencia alta para operaciones de bloques específicas.
Solución alternativa:
Para verificar que las latencias del volumen sean correctas y silenciar la alerta de latencia del nodo de almacenamiento, sigue estos pasos:
Verifica las alertas de latencia de volumen:
- En Grafana, confirma que las alertas de
file_block_storage_high_volume_write_latencyyfile_block_storage_high_volume_read_latencyno se activen y que informen tiempos de latencia óptimos para los volúmenes.
- En Grafana, confirma que las alertas de
Deriva el caso si la latencia del volumen es alta:
- Si se activan las alertas de escritura o lectura de volumen, esto indica una latencia alta en todo el sistema de almacenamiento. Deriva este problema al equipo de ingeniería de bloqueo de archivos.
Silenciar la alerta de latencia del nodo (si los volúmenes están en buen estado):
Si las alertas de escritura y lectura de volumen están en buen estado, es probable que la alerta de latencia del nodo sea un falso positivo.
Crea un silencio en AlertManager para la alerta
file_block_storage_high_node_total_latency.Después de crear el silencio, navega a Grafana para confirmar que la alerta dejó 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 ocurre cuando un LUN (número de unidad lógica) se vuelve de solo lectura, a menudo debido a problemas con las instantáneas. Cuando esto sucede, el nodo se aísla para trasladar el pod afectado a otro nodo. Dado que el proceso de actualización de nodos tiene una verificación previa para garantizar que los nodos no estén aislados, este estado impide que se lleve a cabo la actualización.
Solución alternativa: Inhabilita manualmente el subcomponente file-read-only-lun-cleanup antes de iniciar el proceso de actualización:
Identifica cada organización afectada.
Aplica un
SubcomponentOverridepara 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: trueVerifica que ninguno de los nodos de las organizaciones afectadas esté aislado:
Enumera los nodos de la organización:
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodesEl resultado es similar a este:
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.200Anota los nombres de los nodos que tienen el estado
SchedulingDisabled. En este resultado de ejemplo, el nodo acordonado esadmin-node0-zone1.Quita el aislamiento de los nodos que devolvieron el estado
SchedulingDisableden el paso anterior:kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAMEVerifica que todos los nodos estén listos:
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodesEl resultado es similar a este:
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 resuelven los errores de rutas múltiples
Versiones: 1.14.3 y posteriores
Síntomas: Es posible que se active la alerta file_block_zombie_luns_present en ciertos entornos debido a que el controlador file-observability no puede analizar el resultado del comando multipath -ll. Esta situación genera un envío constante de la alerta de LUN zombis, incluso cuando el servicio de rutas múltiples está en buen estado en todos los nodos.
Solución alternativa:
Para verificar que los servicios de rutas múltiples funcionen correctamente en los nodos en cuestión, sigue estos pasos:
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 para cada nodo del clúster. Si algún nodo informa una métrica dezombie_lun_existsde1, anota el nombre del nodo.Para cada nodo con métricas de
zombie_lun_existsque devuelven1, ejecuta los siguientes comandos:Establece una conexión SSH con el nodo afectado.
Ejecuta el siguiente comando:
multipath -llEl comando devuelve información sobre todos los dispositivos de bloque administrados por el servicio de rutas múltiples. Verifica que ninguno de los dispositivos de almacenamiento en bloque contenga la cadena
failed undef unknowno la cadenafailed faulty runningen sus estados.Si algún dispositivo contiene el estado
failed faulty running, sigue el manual de ejecución FILE-R0020 para resolver los LUN zombis.Si algún dispositivo tiene el estado
failed undef unknown, sigue el manual de ejecución FILE-R0021 para resolver los LUN de superzombi.
Silencia las alertas de LUN zombie si los nodos están en buen estado:
Si no se encuentran dispositivos de bloqueo no válidos en ninguno de los nodos, la alerta de LUN zombie es un falso positivo.
Crea un silencio en AlertManager para la alerta
file_block_zombie_luns_present.Después de crear el silencio, navega a ServiceNow para confirmar que la alerta dejó de activarse.
No se puede borrar un bucket vacío desde la consola
Versiones: 1.14.4 y posteriores
Síntomas: En la consola de GDC, no puedes borrar un bucket vacío. El bucket puede tener marcadores de eliminación y, posiblemente, otras versiones de objetos cuando el control de versiones de objetos está habilitado con políticas de retención. Es posible que veas un error como el siguiente:
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 borrar objetos, incluidos los marcadores de eliminación, para que se pueda borrar el bucket.
System Artifact Registry
Los trabajos de replicación de Harbor se atascan
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: Para mitigar este problema, sigue los pasos del manual de ejecución SAR-R1010.
No se borra el estado de error transitorio cuando se reconcilia el recurso personalizado de la cuenta de robot de Harbor
Versiones: 1.14.3
Síntomas: Se activa erróneamente una alerta de CustomResourceErrorStatusAlert etiquetada con kind=HarborRobotAccount y code=SAR2002. Por ejemplo, la alerta falsa tiene el campo message establecido en "Error getting robot: failed to list robots: 503 Service Unavailable".
Solución alternativa: Solicita al operador de infraestructura (IO) que verifique si la alerta es un problema real o una falsa alarma, y que silencie la alerta si es una falsa alarma, según las siguientes instrucciones.
Cuando se active una alerta, sigue el manual SAR-E2002 para identificar y abordar la causa subyacente de la alerta.
Debido a este problema conocido, incluso si el runbook resuelve correctamente la causa subyacente, es posible que la alerta siga activándose de forma errónea. Sigue verificando el estado de error del objeto de recurso personalizado (CR) HarborRobotAccount (HRD) de destino sobre el que se muestra la alerta:
Configura las variables de entorno necesarias:
export KUBECONFIG=KUBECONFIG export HRD_NAME=HRD_NAME export HRD_NAMESPACE=HRD_NAMESPACEReemplaza lo siguiente:
KUBECONFIG: Es la ruta de acceso al archivo kubeconfig.HRD_NAME: Es el nombre de la CR deHarborRobotAccountde destino.HRD_NAMESPACE: Es el espacio de nombres que contiene el CR deHarborRobotAccountde destino.
Verifica el estado de error del CR de
HarborRobotAccountde 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 aislada de GDC siguiendo el manual de ejecución MON-R2009.
Falsa alarma para la alerta SAR-R0003
Versiones: 1.14.3 y posteriores
Síntomas: Se activa erróneamente una alerta con el código SAR-R0003, OC SAR y gravedad critical.
Solución: Sigue el manual de ejecución MON-R2009 para silenciar la alerta.
Sistema de tickets
El servidor MID de ServiceNow no se inicia correctamente
Versiones: 1.14.3
Corregido: 1.14.4
Síntomas: El servidor MID de ServiceNow, que se integra con Splunk, no se registra en ServiceNow al inicio debido a una discrepancia de versión.
Solución alternativa:
- Pausa el subcomponente
ts-mid-server.
KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true
- Anula la cadena de versión del servidor de 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 servicio compartido no se actualiza después de una actualización correcta del clúster
Versiones: 1.14.4
Síntomas: Los CR de los clústeres de perímetro y de servicio compartido para clusters.baremetal.cluster.gke.io reflejan la versión correcta de GKE después de la actualización. Los CR de clusters.cluster.gdc.goog aún muestran la versión anterior de GKE.
Solución: Actualiza la anotación upgrade.gdc.goog/version en clusters.baremetal.cluster.gke.io al nuevo nombre UserClusterMetadata que corresponde a la versión de GKE actualizada.
La actualización del nodo del administrador de la organización está atascada
Versiones: 1.14.6
Corregido: 1.14.7
Síntomas: El proceso de actualización de nodos para el plano de control de administrador de la organización gdchservices está detenido. La actualización del nodo falla porque no se puede establecer una conexión SSH con el nodo, lo que genera un error Connection timed out.
La actualización del complemento se atasca
Versiones: 1.14.6
Corregido: 1.14.7
Síntomas: La actualización del complemento para el clúster de administrador raíz se detiene durante la actualización de cualquier versión anterior 1.14.x a la versión 1.14.6. Un mensaje de estado puede indicar que la actualización superó el límite de tiempo esperado:
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 alternativa: Actualiza manualmente el campo spec.addOnSetTemplateRef del recurso addonset de administrador raíz para que apunte a la plantilla correcta de la versión nueva.
Falla el 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 para un clúster de usuario debido a un problema de permisos.
Es posible que el inicio de la VM se detenga 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 perimetrales o de servicios compartidos no se inician y se vuelven inaccesibles después de una actualización del 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 error 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: Para solucionar el problema, completa los siguientes pasos:
Configura 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_NAMEDetén la VM con errores:
kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \ $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'Abre el editor para desconectar el disco de arranque de la VM con errores:
kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAMEReemplaza 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_NAMECrea 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=scriptCrea una VM auxiliar:
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 problemática, por lo que debes usar
greppara encontrar 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}')Crea el disco de arranque y la VM. Crea un disco de arranque y una VM nuevos con un disco secundario conectado y una secuencia de comandos 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 EOFVerifica que la VM auxiliar se esté ejecutando:
kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME
Conéctate a la consola de la VM de ayuda y vuelve a generar initramfs:
Consola para la VM de ayuda:
kubectl virt console HELPER_VM_NAME -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIGUsa las siguientes credenciales:
username="newuser"
password="Lime+blaze8legend"
Activa las particiones del disco adjunto:
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/Establece una conexión chroot al punto de activación y vuelve a generar el initramfs:
sudo chroot /mnt/kernelpanic/ dracut --regenerate-all --forceVerifica 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-* -lEl 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
Detén la VM auxiliar:
kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'Desconecta el disco de la VM auxiliar:
Abre la especificación de la VM auxiliar en un editor:
kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAMEQuita el siguiente código del archivo YAML:
- virtualMachineDiskRef: name: PROBLEM_VM_BOOT_DISK autoDelete: false
Vuelve a conectar el disco de arranque a la VM con errores:
Abre la especificación de la VM con errores en un editor:
kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAMEActualiza la especificación de la siguiente manera:
# Several lines of code are omitted here. spec: disks: - boot: true virtualMachineDiskRef: name: PROBLEM_VM_BOOT_DISK
Inicia la VM con errores:
kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'Verifica que la actualización se haya corregido:
Verifica que el recurso personalizado
Nodepara esta VM muestreReadyy use la versión de kernel más reciente4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64:kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owideEl resultado es similar a este:
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.0Verifica la versión del kernel después de establecer una conexión SSH a la VM:
uname -aEl resultado debe mostrar la nueva versión del kernel
4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.
El procesador de datos permanece en mal 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 verificarlo, ejecuta lo siguiente:
none
kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra
Para verificar el estado de un subcomponente, debes usar el kubeconfig del clúster principal para KUBECONFIG y el espacio de nombres del clúster actual para CLUSTER_NAMESPACE. El comando devolverá el ESTADO del subcomponente. Si el estado no es ReconciliationCompleted, indica 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 sus columnas STATUS y READY. Un Pod se considera en mal estado si su STATUS no es Running o si algunos de sus contenedores no están listos. La columna READY, con el formato a/b, indica la cantidad de contenedores listos a del total b. Un pod está en buen estado cuando a y b son iguales.
Verifica los registros de los Pods de Loki en mal estado:
none
kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system
Los registros de salida de muestra de los Pods en mal estado 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 borrar un ingester en mal estado del anillo de Loki, consulta el runbook AL-R0031.
Vertex AI
Es posible que las solicitudes de traducción generen el código de error RESOURCE_EXHAUSTED
Versiones: 1.14.3
Síntomas: Después de enviar una solicitud de traducción, obtienes 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 agotó un recurso, como una cuota por usuario, la cantidad máxima de consultas por segundo o se agotó el espacio de todo el sistema de archivos.
Solución: Pídele a tu operador de infraestructura (IO) que reinicie las particiones del backend del servicio de traducción. Luego, vuelve a enviar solicitudes de traducción con retrasos más largos entre ellas o con solicitudes más cortas.
batchTranslateDocument Las solicitudes de batchTranslateDocument devuelven un error 503
Versiones: 1.14.3
Síntomas: Después de enviar una solicitud de 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 de Aspose, que solo se implementa cuando el parámetro operable enableRAG se establece en true en el clúster.
Solución alternativa: Pídele a tu operador de infraestructura (IO) que establezca el parámetro operable enableRAG en true en el clúster de administrador de la organización siguiendo estos pasos:
Crea un recurso personalizado
SubcomponentOverrideen un archivo YAML llamadovai-translation.yamlcon el parámetro operableenableRAGestablecido entrue:apiVersion: lcm.private.gdc.goog/v1 kind: SubcomponentOverride metadata: name: "vai-translation" namespace: SHARED_SERVICE_CLUSTER_NAMESPACE spec: subComponentRef: "vai-translation" backend: operableParameters: enableRAG: trueReemplaza
SHARED_SERVICE_CLUSTER_NAMESPACEpor el espacio de nombres del clúster de servicio compartido.Aplica el recurso personalizado
SubcomponentOverrideal clúster de administrador de la organización:kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yamlReemplaza
ORG_MGMT_KUBECONFIGpor la ruta de acceso al archivo kubeconfig de administración en el clúster de administrador de la organización.
No se pueden inicializar el pod y el servicio de frontend de OCR o traducción.
Versiones: 1.11.x, 1.12.x, 1.13.x, 1.14.x
Síntomas: Durante las actualizaciones, se vuelve a crear el clúster de BD, lo que provoca que el secreto de ODS secreto-store en el clúster de servicio compartido esté desactualizado y no sincronizado. Por este motivo, fallan la inicialización del pod y el servicio de frontend de OCR o Traducción.
Solución alternativa:
Borra el secreto en el clúster de servicio compartido:
kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE
Reemplaza SHARED_SERVICE_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig en el clúster de servicio compartido.
Si el servicio problemático es Traducción, reemplaza VAI_API_NAMESPACE por "g-vai-translation-sie"; si el servicio problemático es OCR, reemplaza 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 BD.
Vertex AI Search
Los componentes de búsqueda están atascados en el estado de conciliación
Versiones: 1.14.6
Síntomas: Los subcomponentes vaisearch-conversation y vaisearch-frontend se bloquean en un estado Reconciling si no se crea ningún recurso personalizado SearchConfig en la organización.
Solución: Se puede ignorar el problema. Una vez creado el recurso personalizado SearchConfig, los subcomponentes deben completar su reconciliación.
Servidor
La rotación de credenciales del BIOS se detiene en la etapa de restablecimiento solicitado
Versiones: 1.14.4
Síntomas: La rotación de credenciales del BIOS se atasca en el estado de restablecimiento solicitado. Para verificarlo, revisa la anotación gdch.cluster.gke.io/rotation-status del secreto de credenciales de BIOS del servidor:
kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'
Reemplaza SERVER_NAME por el nombre del servidor. El resultado del comando es reset-requested si la rotación está atascada.
Solución: Para completar la rotación de credenciales del BIOS, sigue el manual de ejecución SERV-R0018.
No se pueden aprovisionar los servidores instalados anteriormente
Versiones: 1.14.6
Síntomas: Los servidores no se aprovisionan después de que se desaprovisionan y se vuelven a aprovisionar, específicamente en relación con problemas con la administració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, encuentran errores durante el aprovisionamiento de imágenes, lo que indica una incapacidad para encontrar un dispositivo adecuado, a menudo debido a discos bloqueados por claves antiguas o borradas. 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: Borra y reinstala los servidores afectados para que se aprovisionen. Para obtener más información, consulta los manuales SERV-R0020 y SERV-R0021.
Máquinas virtuales
Falla la importación de imágenes
Versiones: 1.14.4 1.14.5
Corregido: 1.14.6
Síntomas: La importación de una imagen con el comando gdcloud compute images import falla con un error Unauthorized debido a tiempos de espera de sesión.
Solución alternativa: Usa la API de KRM para la importación de tu propia imagen en lugar de la CLI de gdcloud.
La importación de imágenes de KRM tarda mucho tiempo
Versiones: 1.14.6 y posteriores
Síntomas: La importación de una imagen con la API de KRM tarda mucho en completarse.
El recurso VirtualMachineImageImport permanece en estado TranslationJobInProgress durante un período prolongado, lo que indica que la fase de traducción no se completa según lo previsto. El Pod image-translation ingresa en un estado CrashLoopBackOff.
Solución alternativa:
- Intenta realizar la importación nuevamente creando un recurso
VirtualMachineImageImportnuevo con otro nombre. - Supervisa el estado de
VirtualMachineImageImportverificando periódicamente el recurso hasta que su estado cambie aWaitingForTranslationJob. Para obtener más información, consulta el manual de ejecución de VMM R0007.