Se usó la API de Cloud Translation para traducir esta página.

Problemas conocidos de Google Distributed Cloud aislado 1.13.x

Artifact Registry

Error de conciliación del subcomponente `sar-failoverregistry`

Versiones: 1.13.1, 1.13.3 y 1.13.4

Síntomas: Cuando se crea el clúster de administrador raíz con el comando gdcloud system admin-cluster install, la operación puede fallar si hay una lista larga de servidores durante el proceso de arranque. El mensaje de error de salida es el siguiente:

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

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

En el mismo clúster de Kubernetes que el subcomponente, enumera los servidores y confirma que cada recurso personalizado del servidor tenga una etiqueta con la clave como cluster.private.gdc.goog/inventory-machine:
```
kubectl get servers -n gpc-system
```

Busca el recurso personalizado del componente que se parece al siguiente:

  apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

En el recurso personalizado del componente de System Artifact Registry (SAR), agrega el selector de etiquetas en los servidores runtimeParameterSources para sar-failover-registry:

Visualiza el recurso server existente:

servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

Actualiza el campo servers en el recurso personalizado del componente:

servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

Verifica que los cambios en el componente SAR del paso anterior se propaguen al subcomponente sar-failverregistry:
1. Obtén los detalles del componente SAR:
```
kubectl get component | grep sar
```
2. Obtén los detalles del componente sar-failoverregistry:
```
kubectl get subcomponent sar-failoverregistry -n root
```
  Usa la marca -n para especificar el espacio de nombres.

Copia de seguridad y restablecimiento

Las instantáneas fallan debido a la falta de espacio en el volumen

Versiones: Todas las versiones de 1.13.x

Síntomas: Hay un problema intermitente con la copia de seguridad del volumen persistente que puede afectar los flujos de trabajo de los trabajos de copia de seguridad periódicos. En algunos volúmenes con una alta tasa de cambio, las instantáneas de volumen que se toman para las copias de seguridad en curso pueden hacer que el volumen se quede sin espacio, lo que luego lo pone en modo de solo lectura.

Solución alternativa: Para evitar un posible impacto en las cargas de trabajo de producción, sigue los pasos del manual de ejecución BACK-R0104. De manera opcional, también puedes quitar las instantáneas acumuladas siguiendo el manual de ejecución BACK-R0106.

Los pods del agente y del plano de control se reinician debido a la falta de memoria

Versiones: Todas las versiones de 1.13.x

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

Solución: 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.

Falla la copia de seguridad de la instantánea de PVC

Versiones: Todas las versiones de 1.13.x

Síntomas: Se produjeron errores de copia de seguridad debido a que se superó el límite de instantáneas de ONTAP de 1,023 por recurso de PersistentVolumeClaim (PVC).

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

Actualiza el plan de copia de seguridad para que nunca se alcancen los límites. Configura un plan de copias de seguridad para que se realice una copia de seguridad cada hora o reduce el valor de deleteLockDays a tres para que la cantidad de instantáneas no supere las 1,023:
```
apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS
```
Reemplaza lo siguiente:
- LOCK_DAYS: Bloquea el borrado de la copia de seguridad durante la cantidad de días especificada después de la creación de la copia de seguridad. Usa los siguientes valores:
  - Si el campo volumeStrategy se establece en un valor de LocalSnapshotOnly, usa un valor de 2.
  - Si el campo volumeStrategy se establece en un valor de ProvisionerSpecific, usa un valor de 7.
- RETENTION_DAYS: Borra las copias de seguridad después de la cantidad de días especificada tras la creación de la copia de seguridad. Si el campo volumeStrategy se establece en un valor de LocalSnapshotOnly, usa un valor menor que 3.

Para borrar manualmente las instantáneas excesivas de tu entorno con los comandos de borrado de instantáneas de volúmenes, sigue estos pasos:

Inicializa variables:

export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

Reemplaza lo siguiente:

ORG_NAME: Es el nombre de tu organización.
PVC_NAME: Es el nombre del recurso PVC relacionado con el plan de copia de seguridad.

NetApp ONTAP es un sistema operativo que se usa para administrar el almacenamiento de GDC. Obtén acceso a ONTAP:

export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD

Enumera todas las Instant Snapshots del recurso PVC seleccionado:
```
ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list
```
Usa la contraseña del paso anterior para acceder a la máquina en la dirección IP definida por la variable MGMT_IP.

Busca el PVC con el recuento de instantáneas más alto:

grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c

Establece el nombre del recurso PVC en el que tiene una gran cantidad de instantáneas:
```
export PV_NAME=
```

Borra la instantánea del recurso PVC que contiene una gran cantidad de instantáneas. El límite para la cantidad de instantáneas de un recurso PVC es de 1,023:

for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done

Accede a ONTAP y ejecuta estos comandos para borrar la instantánea:

echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}

Ejecuta los comandos que se indican en el paso anterior para borrar la instantánea. Una vez que se complete, sal de la sesión de SSH.

Repite los pasos de eliminación hasta que se borren todas las instantáneas PVC infractoras.

Restablecimiento desde una copia de seguridad que no es compatible con la cuota de SVM

Versiones: 1.13.1

Síntomas: El problema es una incompatibilidad entre las funciones de NetApp. Esta incompatibilidad impide la entrega de la cuota del arrendatario y la implementación correcta de las restauraciones. El problema solo se produce cuando se restablece una copia de seguridad en un clúster de usuario con restricciones de cuota.

Solución: Si se produce este problema, la restauración falla con el mensaje de error DP volumes are not supported on storage-limit enabled Vserver y el operador de infraestructura (IO) debe inhabilitar la cuota para ese clúster de usuario y reiniciar el proceso de restauración. Una vez que se complete el restablecimiento, el IO debe volver a habilitar las cuotas de inquilino y el sistema debería seguir funcionando según lo previsto. Consulta el runbook FILE A0030 para obtener más detalles.

Facturación

Las métricas de facturación no se muestran correctamente en el panel de facturación

Versiones: 1.13.1

Síntomas: Las métricas de facturación no se emiten correctamente al Cortex debido a la falta de MetricsProxySidecar.

Solución alternativa: Crea un recurso billing-monetizer MetricsProxySidecar. Luego, ejecuta una secuencia de comandos para actualizar el metricExpression.

Exporta la siguiente variable de kubeconfig:
```
export KUBECONFIG=KUBECONFIG_PATH
```
Reemplaza la variable KUBECONFIG_PATH por la ruta de acceso al archivo kubeconfig del clúster de administrador de la organización. Sigue los pasos que se indican en Manual de servicio IAM-R0101 para generar el archivo kubeconfig necesario para esta solución alternativa.

Crea un recurso de billing-monetizer MetricsProxySidecar para los espacios de nombres billing-system y partner-billing-system:

Para billing-system:

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

Para partner-billing-system:

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

Ejecuta la siguiente secuencia de comandos para actualizar metricExpression. Esta acción quita el container_name="monetizer" del skuconfig, lo que incluye billing_total_cost{container_name="monetizer":

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

El usuario no puede crear `BillingAccountBinding` debido a errores en el webhook de validación

Versiones: 1.13.0, 1.13.1 y 1.13.3

Síntomas: El error se encuentra en la lógica del webhook de validación de BillingAccountBinding. Si un usuario intenta crear un recurso BillingAccountBinding, el webhook devuelve el error permission denied.

Solución: Para crear recursos de BillingAccountBinding, notifica al operador de infraestructura y crea los recursos correspondientes a través de la IaC.

Almacenamiento en bloque

Los Pods de Grafana están bloqueados en el estado `Init` debido a errores de montaje de volumen.

Versiones: 1.13.3

Síntomas:

Los Pods de Grafana en los espacios de nombres anthos-identity-service-obs-system y platform-obs-obs-system están atascados en el estado Init debido a errores de montaje de volumen. El mensaje de error en los registros de kubelet indica un problema de conexión múltiple. El problema se debe a un error en Trident, en el que no se puede identificar y verificar correctamente el dispositivo subyacente para las asignaciones de LUKS, lo que genera un error de conexión múltiple.

Solución alternativa:

Verifica si el PVC tiene un deletionTimestamp. Si no hay ningún deletionTimestamp (migración de Pod), sigue estos pasos:

Verifica el VolumeAttachment del PVC para identificar dónde está conectado actualmente el volumen.
Aísla el Nodes en el clúster que no coincida con este valor.
Borra el Pod que falla. Esto debería hacer que migre de nuevo al Node original.

Después de verificar, si hay un deletionTimestamp (eliminación de volumen), sigue estos pasos:

Verifica el VolumeAttachment del PVC para identificar dónde está conectado actualmente el volumen.
En Node, genera el contenido de su archivo de seguimiento:
```
cat /var/lib/trident/tracking/PVC_NAME.json
```
Valida que el dispositivo LUKS que se encuentra en el campo devicePath del resultado del archivo de seguimiento esté realmente cerrado. Esta ruta no debería existir en este punto:
```
stat DEVICE_PATH
```
Valida si el número de serie está asignado actualmente a algún dispositivo de rutas múltiples.
1. Copia el valor del campo iscsiLunSerial del archivo de seguimiento.
2. Convierte este valor en el valor hexadecimal esperado:
```
echo 'iISCSILUNSERIAL' | xxd -l 12 -ps
```
3. Con este valor nuevo, verifica si la entrada de rutas múltiples aún existe:
```
multipath -ll | grep SERIAL_HEX
```
4. Si no existe, borra el archivo de seguimiento.
5. Si existe, verás un valor hexadecimal serial un poco más largo que el que buscaste, que se llamará multipathSerial. Ejecuta lo siguiente y busca los dispositivos de bloqueo:
```
multipath -ll MULTIPATH_SERIAL
```
6. Luego, ejecuta los siguientes comandos, y el último solo para cada dispositivo de almacenamiento en bloques:
```
systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
```

Los pods del launcher de la máquina virtual no pueden asignar volúmenes

Versiones: 1.13.1

Síntomas:

Es posible que veas una advertencia similar a la siguiente:

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

Para diagnosticar el problema, sigue estos pasos:

Asegúrate de que los volúmenes y los pods estén en el mismo nodo.
Busca el nodo en el que se encuentran los Pods y verifica su estado.
Verifica la conectividad de los nodos.
Verifica IPSEC.
Verifica la ruta múltiple para ver si hay un zombie.
Verifica los registros de Trident para averiguar qué paso del flujo de CSI podría haber introducido este zombie:
```
kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main
```

Solución: Para solucionar este problema, sigue los pasos que se indican en los siguientes manuales de ejecución:

Para problemas relacionados con los nodos, consulta el runbook FILE-R0010.
Para problemas con IPSEC, consulta el runbook FILE-R0007.
Si tienes problemas con LUNs zombis, consulta el runbook FILE-R0020.
Para problemas con LUNs de superzombies, consulta el runbook FILE-R0021.

Fallas relacionadas con el almacenamiento

Versiones: 1.13.1

Síntomas: Las fallas relacionadas con el almacenamiento se pueden identificar con la activación de la alerta file_block_zombie_luns_present o con la imposibilidad de iniciar el pod debido a un problema en la llamada MountVolume que persiste durante más de un bucle de reconciliación. El tiempo de espera puede ser de unos dos minutos. Una repetición del mismo error indica que algo falló en la ruta de CSI de NodeStage o NodePublish y requiere una solución alternativa. La única excepción es la indicación de una falla por tiempo de espera agotado. Es posible que veas algunos errores como los siguientes:

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

Solución alternativa:

Para ver si el Node que tiene el Pod se puede corregir para el PVC con errores, aísla el nodo actual en el que se programó el Pod y borra el Pod:
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE
```
El Pod debe programarse para un Node completamente diferente, lo que obliga a Trident a ejecutar por completo NodeStage, NodePublish, NodeUnpublish y NodeUnstage. Es posible que esto no solucione el problema de inmediato, ya que es posible que aún haya sesiones abiertas para este volumen en el Node original.
Después de completar el paso anterior, quita el aislamiento del nodo en cuestión:
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE
```
Si los errores persisten, aísla todos los demás Nodes, excepto aquel en el que se programó originalmente el Pod, y borra el Pod. Esto debería hacer que Pod comience en el Node original en el que podrían permanecer los dispositivos existentes.
Una vez que se complete el paso anterior, quita el aislamiento de los nodos en cuestión.
Como último recurso para guardar el PV y sus datos, se puede reiniciar el Node para borrar las fallas de rutas múltiples, udev y devmapper en el Node. Si bien este paso es bastante arduo, es el que tiene más probabilidades de éxito.
Si las mitigaciones anteriores no resuelven el problema con el volumen, esto indica que los datos se dañaron y son inutilizables. La única opción que queda para continuar con el comportamiento previsto del contenedor es borrar los elementos PV, PVC y Pod con errores, seguido de un reinicio del nodo en el que se alojó el PV. Esta acción provoca la pérdida completa de los datos que ya se habían escrito en el volumen.

Volúmenes persistentes creados con un tamaño incorrecto

Versiones: 1.13.1

Síntomas: Las cargas de trabajo con un volumen persistente se crean con un tamaño de aproximadamente 16 MiB menos de lo esperado. Si las cargas de trabajo dependen exactamente del tamaño que anuncia un volumen persistente, la pequeña discrepancia hace que la carga de trabajo falle cuando se expande o aprovisiona. Es más probable que este problema se produzca en los volúmenes persistentes aprovisionados con una clase de almacenamiento standard-block que en los aprovisionados con una clase de almacenamiento standard-rwo. Este problema puede ocurrir en volúmenes persistentes con una clase de almacenamiento standard-rwo que usa el modo volumemode:block.

Solución: Asigna un volumen persistente que sea al menos 16 MiB más grande de lo que realmente se requiere.

No se puede borrar la máquina virtual de almacenamiento

Versiones: 1.13.1

Síntomas: Es posible que el StorageVirtualMachine muestre un error como el siguiente:

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

Solución alternativa: Borra el finalizador de StorageVirtualMachines en el espacio de nombres de la organización.

La desactivación de la organización no limpia los recursos

Versiones: 1.13.1

Síntomas: Cuando se desactiva una organización, quedan algunos recursos de StorageVirtualMachines, por ejemplo:

Secreto de gpc-system/org-2-admin-backup-agent-cert-secret
Secreto de gpc-system/org-2-admin-client-cert-secret
Secreto de gpc-system/org-2-admin-server-cert-secret
Secreto de gpc-system/org-2-admin-svm-credential
Secreto de gpc-system/org-2-admin-backup-agent-cert-secret
Secreto de gpc-system/org-2-admin-client-cert-secret
Secreto de gpc-system/org-2-admin-server-cert-secret
Secreto de gpc-system/org-2-admin-svm-credential

Solución alternativa: Borra estos recursos.

Error de conciliación de eliminación

Versiones: 1.13.1

Síntomas: Cuando se borra un StorageVirtualMachine antes de la limpieza de los clústeres que dependen de ese StorageVirtualMachine, es posible que se produzca un problema al limpiar algunos de los volúmenes persistentes (PV) de los clústeres. Específicamente, cuando no se limpian los PV encriptados con LUKS, su secreto impide que se borre el espacio de nombres en el que se encuentran. Es posible que veas una advertencia en los registros como la siguiente:

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

Solución alternativa: Borra el finalizador de los secretos g-luks-gdc-vm-disk-* en el espacio de nombres del clúster de servicio.

La actualización de Bare Metal se detuvo

Versiones: 1.13.1, 1.13.5 y 1.13.6

Síntomas: Los trabajos de Ansible se bloquean en la recopilación de hechos cuando hay LUN zombie. Si ejecutas el comando multipath -ll, es posible que se muestre el siguiente problema:

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

Es posible que también veas el siguiente mensaje de error:

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

Solución alternativa: Verifica la conectividad SSH con el nodo de destino y, luego, usa el siguiente runbook: FILE-R0020.

Error de conexión múltiple de Trident

Versiones: 1.13.3

Síntomas: Es posible que los Pods y los PVC queden varados en diferentes nodos con el Pod atascado en la inicialización a la espera del PVC.

Solución alternativa:

Verifica el PVC para ver si hay un deletionTimestamp:

kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

Si no hay deletionTimestamp (migración de Pod), haz lo siguiente:
1. Verifica el VolumeAttachment del PVC para identificar dónde está conectado el volumen.
2. Aísla los nodos del clúster que no coinciden con este valor.
3. Borra el Pod con fallas. Esta acción migra el POD de nuevo al nodo original.
Nota: Esta acción no creará un zombie porque el valor hexadecimal serial que usa Trident para la entrada de varias rutas proviene del recurso de LUN real en ONTAP. Si el dispositivo ya está presente, se recuperará el valor original. Si el dispositivo no está presente, se creará el valor correctamente.
Si hay un deletionTimestamp (borrado de volumen), haz lo siguiente:
1. Verifica el VolumeAttachment del PVC para identificar dónde está conectado el volumen.
2. En el nodo, genera el contenido de su archivo de seguimiento, /var/lib/trident/tracking/PVC_NAME.json.
3. Valida que el dispositivo LUKS que se encuentra en el campo devicePath del archivo de seguimiento de salida esté realmente cerrado. Esta ruta no debería existir en este punto: stat DEVICE_PATH. Si la ruta aún existe, se está produciendo otro problema.
4. Valida si el número de serie está asignado a algún dispositivo de varias rutas.
5. Copia el valor del campo iscsiLunSerial del archivo de seguimiento.
6. Convierte este valor en el valor hexadecimal esperado: echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
7. Con este valor nuevo, busca si la entrada de varias rutas aún existe: multipath -ll | grep SERIAL_HEX.
8. Si no existe, borra el archivo de seguimiento.
9. Si existe, verás un valor hexadecimal-serial un poco más largo que el que buscaste. Registra este valor como MULTIPATH_SERIAL. Ejecuta multipath -ll MULTIPATH_SERIAL y verás un mensaje como este:
```
3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running
```
10. Ejecuta los siguientes comandos:
  1. systemctl restart iscsid
  2. systemctl restart multipathd
  3. multipath -f MULTIPATH_SERIAL
  4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
11. Ejecuta el último comando de forma única para cada dispositivo de almacenamiento en bloques.

Error en la configuración de IPsec

Versiones: 1.13.4

Síntomas: La configuración de IPsec de ONTAP encuentra un error debido a una clave precompartida (PSK) no válida que contiene 0X, que se interpreta como una cadena hexadecimal.

Es posible que veas una advertencia como esta:

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

Solución alternativa:

Obtén las conexiones de encriptación de almacenamiento:

kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

Busca la entrada con Ready=False y anota el nombre de PRESHAREKEY. El resultado podría verse como este ejemplo:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

Esta máquina ejecuta una organización de GPU, por lo que debes borrar secrets gpc-system/vm-5a77b2a2-pre-shared-key en gpu-org-admin.
Espera a que el sistema vuelva a crear secret/vm-5a77b2a2-pre-shared-key.
Busca un trabajo con un patrón como gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Ten en cuenta que los últimos 8 caracteres se generan de forma aleatoria. Una vez que la clave esté disponible de nuevo, borra el trabajo, como jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl en gpu-org-admin.

No se creó la máquina virtual de almacenamiento

Versiones: 1.13.5

Síntomas: El servicio de Harbor en gpu-org no se inicia debido a un problema con el aprovisionamiento de volúmenes. Este problema se debe a que el pod file-storage-backend-controller hace referencia a una máquina de inventario inexistente.

Es posible que veas un error del controlador de almacenamiento como el siguiente, que indica que no se encontró InventoryMachine:

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

Solución alternativa:

Borra el Pod file-storage-backend-controller.
Permite que el controlador de almacenamiento vuelva a recuperar las máquinas de inventario presentes.

No se pueden conciliar las redes de interclúster de almacenamiento

Versiones: 1.13.5 y 1.13.6

Síntomas: Después de una actualización, el recurso personalizado StorageCluster en el clúster de administrador raíz no se prepara debido a un error de configuración en las subredes entre clústeres de la especificación. El clúster de almacenamiento informa Not Ready y, además, incluye un evento con este error:

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

Si se produce este error, el reclamo de subred entre clústeres que usa el clúster de almacenamiento no incluye el campo kind en la referencia. Cuando inspecciones el recurso personalizado StorageCluster, encontrarás una referencia de reclamo de subred entre clústeres con solo un nombre y un espacio de nombres, como el siguiente:

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Solución alternativa: Actualiza la especificación de StorageCluster para incluir el campo kind: SubnetClaim en la referencia de la reclamación de subred:

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Después de actualizar la especificación de StorageCluster, reinicia la Deployment file-storage-backend-controller y verifica que el clúster de almacenamiento esté listo.

Administración de clústeres

El trabajo de `machine-init` falla durante el aprovisionamiento del clúster

Versiones: 1.13.1

Síntomas:

Durante el aprovisionamiento del clúster, el trabajo machine-init del segundo nodo del plano de control falla con el siguiente mensaje:
```
FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".
```

Consulta los registros:

kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

El resultado muestra un resultado no vacío.

Solución alternativa:

Activa o desactiva el permiso de /etc/kubernetes/pki/etcd/ca.crt. Esta es una operación muy sensible al tiempo. El cambio de permiso debe ocurrir después de la ejecución anterior del trabajo machine-init, pero antes de la siguiente ejecución del trabajo machine-init, ya que machine-init sobrescribe el permiso y lo restablece como raíz.
Reinicia etcd en el segundo nodo para recuperar etcd en el primer nodo de los bucles de fallas.

Después de completar estos dos pasos, el kube-apiserver del primer nodo comienza a ejecutarse y el siguiente trabajo de machine-init se completa correctamente.

No hay conectividad del clúster de servicio al bucket de almacenamiento de objetos

Versiones: 1.13.1

Síntomas: Falla la conexión de un Pod de base de datos que se ejecuta en el clúster de servicio a un bucket de almacenamiento de objetos en el clúster de administrador de la organización.

Solución alternativa: Sigue las instrucciones del manual de ejecución KUB-R0305.

Falla la comprobación previa

Versiones: 1.13.1

Síntomas: Es posible que veas el siguiente mensaje en el estado del objeto del clúster:

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

También deberías ver un objeto PreflightCheck correspondiente con el mismo nombre y espacio de nombres que el objeto del clúster que ha estado allí durante varias horas mientras se sabe que el error o la falla indicados en el objeto PreflightCheck ya no son un problema.

Solución alternativa: Borra el objeto PreflightCheck.

Falla la creación del grupo de nodo trabajador del clúster de usuario

Versiones: 1.13.5

Síntomas: Es posible que la creación del grupo de nodo trabajador del clúster de usuario deje de responder para uno de estos tipos de máquinas:

n2-standard-16-gdc
n2-standard-32-gdc
n2-highmem-16-gdc
n2-highmem-32-gdc

Solución alternativa: Borra ese grupo de nodos y vuelve a crearlo seleccionando otros tipos de máquinas disponibles en el menú desplegable de la IU de creación del clúster de usuario.

Es posible que los clústeres de usuarios, cuando se vuelvan a crear, queden atascados en el proceso de conciliación debido a una limpieza inadecuada.

Versiones: 1.13.x

Síntomas: Cuando se crean clústeres de usuarios con el mismo nombre que un clúster que se borró anteriormente, es posible que se queden atascados en Reconciling de forma indefinida con un estado que menciona la etapa de instalación del complemento ONE.

Solución alternativa: Desinstala el complemento de Helm CLUSTER_NAME-abm-overrides y reinicia la implementación de managed-adm-controller. Sigue MKS-R0004 para obtener instrucciones detalladas.

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: Todas las versiones de 1.13.x

Problemas: 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.

La aplicación de IOPS afecta el rendimiento del almacenamiento

Versiones: 1.13.1

Solución alternativa: Para solucionar este problema, sigue una de estas opciones:

Aumenta el tamaño de almacenamiento.
Anula la cuota de IOPS.

Error de conciliación al actualizar el subcomponente `dbs-fleet`

Versiones: 1.13.3

Síntomas: Cuando actualices la organización raíz de la versión 1.13.1 a la 1.13.3, es posible que veas un error de reconciliación. Comprueba si hay errores de conciliación:

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

El error podría verse de la siguiente manera:

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

Solución alternativa: Sigue los pasos del manual de ejecución OCLCM-R0122.

Falla en la creación del DBCluster

Versiones: 1.13.3

Síntomas: Después de actualizar a 1.13.3, los clústeres de bases de datos nuevos no se reconcilian y se muestra el siguiente error en el estado:

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

Solución alternativa

Verifica que haya CR de localrollout que terminen en cpa-v0.12.46 y cpa-v0.12.51 en el clúster de administrador de la organización. Por ejemplo:

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

Encuentra y borra los CR de localrollout que terminan en cpa-v0.12.46, y asegúrate de que los demás CR de localrollout no se vean afectados.

kubectl get localrollouts -A | grep cpa-v0.12.46

Debería mostrar una lista como esta:

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

Borra cada uno de ellos:

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

Verifica que las CR de localrollout que terminan en cpa-v0.12.51 aún estén presentes:

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

Las DNSSEC deben desactivarse de forma explícita en resolved.conf

Versiones: 1.13.1, 1.13.3 y 1.13.4

Síntomas: La resolución de DNS falla en nodos de metal desnudo o de VM. Para confirmar que la resolución de DNS está fallando, establece una conexión SSH con el nodo afectado y ejecuta systemctl status systemd-resolved. El resultado contiene líneas como DNSSEC validation failed for question . IN SOA: no-signature.

Solución alternativa:

Agrega la siguiente línea a /etc/systemd/resolved.conf en el nodo afectado.
```
DNSSEC=false
```

Reinicia el servicio systemd-resolved:

systemctl restart systemd-resolved.service

Servicio de puerto

No se pudo crear el servicio de Harbor

Versiones: 1.13.6

Síntomas: No se puede crear una instancia de Harbor debido a una discrepancia en el espacio de nombres causada por una limitación de longitud en el nombre de ServiceIsolationEnvironment. Es posible que veas un mensaje como este:

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

Solución alternativa: Acorta el nombre de la instancia de Harbor para resolver el problema actual. Asegúrate de que la longitud combinada de PROJECT_NAME y HARBOR_INSTANCE_NAME sea inferior a 27 caracteres.

Borrar instancias de Harbor no borra los duplicados de registro asociados

Versiones: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8

Síntomas: Cuando se borran instancias de Harbor, no se borran los duplicados de registro asociados. Es posible que el grupo de nodos esté atascado en un estado de Provisioning. Esto se debe a que los duplicados del registro creados por el controlador de MHS no se borran cuando se borran las instancias de Harbor.

Solución alternativa: Debes quitar los duplicados del registro de forma manual. Para mitigar este problema, sigue estos pasos:

Conéctate al clúster de administrador de la organización. Para obtener más información, consulta Arquitectura del clúster de GDC.

Ejecuta este script para quitar los espejos del registro que coincidan con el valor de la variable de entorno HARBOR_INSTANCE_URL de todos los clústeres de Kubernetes que tengan la etiqueta lcm.private.gdc.goog/cluster-type=user:

LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

Reemplaza HARBOR_INSTANCE_URL por la URL de tu instancia de Harbor.

Módulo de seguridad de hardware

Aún se pueden detectar las licencias de prueba desactivadas del HSM

Versiones: 1.13.1, 1.13.3 a 1.13.11

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.13.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 alternativa: 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.

Vencieron los certificados del HSM

Versiones: 1.13.11

Síntomas: Cuando actualices una organización, es posible que veas una advertencia como esta:

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

El org-1-system-cluster está atascado en una actualización de versión de ABM debido a que caducaron los certificados del HSM (módulo de seguridad de hardware).

También es posible que veas un error como el de este ejemplo en iLO del servidor HPE, StorageGRID o ONTAP:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Solución alternativa:

Rota manualmente el certificado de la CA raíz y de la interfaz web con ksctl:

Pausa todas las CR de HSM, HSMCluster y HSMTenant.

Crea una nueva CA raíz con los atributos copiados de la anterior. Busca el ID de la CA anterior con ksctl ca locals list. Un ejemplo podría verse así:

ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

Autofirma la nueva CA con una duración de un año. Un ejemplo podría verse así:

ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

Actualiza la interfaz web para que use esta nueva CA para la generación automática de certificados. Un ejemplo podría verse así:

ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

Genera un nuevo certificado de interfaz web, firmado por la nueva CA. La marca --url es la IP de administración del HSM (de kubectl get hsm -n gpc-system). Un ejemplo podría verse así::

ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

En este punto, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text aún muestra el certificado anterior. Debes reiniciar el HSM para que se aplique el certificado nuevo.
```
ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot
```
Ahora openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text muestra el certificado nuevo.

Borra la AC anterior del CR del HSM:

kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

Sigue estos pasos para salir del modo de pausa del HSM:
```
kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-
```
Asegúrate de que el HSM esté en buen estado.
Repite estos pasos para los otros dos HSM. Ya tienen la nueva CA raíz autofirmada porque la CA se comparte entre los HSM de un clúster. Omite los pasos 2 y 3, pero repite los pasos del 4 al 8.
Sigue la tarea de rotación HSM T0008 de la CA para automatizar la rotación de todos los certificados, pero omite el paso Finaliza la rotación agregando una nueva anotación de rotación a hsmcluster en el que se agrega ca-rotation-finalizing annotation.

Sube el nuevo nombre de la CA a iLO:

En la interfaz de iLO, abre la página Administración - Administrador de claves y haz clic en la pestaña Administrador de claves.
Rota el nombre del certificado.
Realiza un reinicio en frío.
Verifica que el protocolo de enlace SSL vuelva a funcionar.

Administración de identidades y accesos

Los Pods `gatekeeper-audit` en el espacio de nombres `opa-system` se reinician con frecuencia.

Versiones: 1.13.3

Síntomas: Verifica el estado de los Pods gatekeeper-audit-*** en el espacio de nombres opa-system:

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

El resultado podría verse como este ejemplo:

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

Este problema se debe a límites de recursos bajos.

Infraestructura como código (IaC)

El riesgo de creación excesiva de tokens de GitLab llena las bases de datos de GitLab

Versiones: 1.13.1

Síntomas: El subcomponente iac-manager crea un token nuevo para el usuario de configsync-ro de forma repetida, incluso cuando no es necesario. Esto puede hacer que la base de datos de GitLab se llene y que no se pueda acceder a la IAC. Es posible que el pod pg-gitlab-database-0 en el espacio de nombres gitlab-system no pueda iniciarse y muestre eventos como los siguientes:

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

Solución alternativa:

Trabaja con tu contacto de Google para obtener hotfix_3 para la versión 1.13.1 y aplicarla.

Sistema de administración de claves (KMS)

Si cambias el tipo de clave raíz, se invalidarán todas las claves existentes.

Versiones: 1.13.x

Síntomas: Una vez que se crea una organización, el KMS se aprovisiona automáticamente con una clave raíz de software. Para migrar de una clave raíz de software a una clave de CTM, los usuarios deben anular un subcomponente. Esto cambia el tipo de clave raíz, lo que invalida todas las claves de software existentes en el KMS.

Solución: Si es posible, evita actualizar el tipo de clave raíz. Si actualizas el tipo de clave raíz, se invalidarán todas las claves existentes.

`kms-rootkey-controller` `CrashLoopBackOff` debido a `OOMKILL`

Versiones: 1.13.1

Síntomas: Cuando el uso de memoria de kms-rootkey-controller supera el límite de 600Mi, el controlador entra en un estado de CrashLoopBackOff debido a un estado de OOMKilled.

Solución alternativa: Crea un SubcomponentOverride para actualizar el límite de memoria a 1500Mi. Para obtener instrucciones, consulta el Runbook 0007 de KMS. Después de completar los pasos de requisitos previos del manual de ejecución, ejecuta los siguientes comandos:

Crea un recurso personalizado SubcomponentOverride:

cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

En el siguiente ejemplo, se muestra un recurso personalizado SubcomponentOverride completo:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

Aplica el recurso SubcomponentOverride:

kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

Logging

El registrador de auditoría del almacenamiento de objetos no puede resolver el host de DNS

Versiones: 1.13.x

Síntomas:

En el clúster de administrador raíz, la implementación de obs-system/log-remote-logger contiene varios errores como los siguientes:

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

Solución alternativa: Aplica un parche al Deployment de obs-system/log-remote-logger con el siguiente comando:

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

El registrador de HaaS muestra errores en el clúster de administrador raíz

Versiones: 1.13.x

Síntomas:

En el clúster de administrador raíz, la implementación de obs-system/log-remote-logger contiene varios errores como los siguientes:

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

Solución alternativa: Actualiza a la versión 1.13.8 para corregir el error. También puedes modificar la implementación de obs-system/log-remote-logger de la siguiente manera:

En los argumentos del contenedor remote-logger, actualiza la marca --disabled-loggers para incluir la santricidad y el HaaS:

YAML

args:
  - --disabled-loggers=santricity,haas

Falla el registrador de Santricity

Versiones: 1.13.x

Síntomas:

En el clúster de administrador raíz, la implementación de obs-system/log-remote-logger contiene varios errores como los siguientes:

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

Solución alternativa: Actualiza a la versión 1.13.8 para corregir el error.

Los registros de Logging Target se envían al proyecto incorrecto

Versiones: 1.13.x

Síntomas: El DaemonSet obs-system/oplogs-forwarder registra advertencias similares a las siguientes:

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

Estas advertencias hacen que los registros se enruten al proyecto incorrecto (ID de inquilino). Este problema se debe a un error conocido en Fluent Bit. Para obtener más información, consulta el problema de Fluent Bit en GitHub.

Solución alternativa: Actualiza a la versión 1.13.8 para corregir el error.

El PA no puede ver los registros de auditoría del espacio de nombres de la plataforma.

Versiones: 1.13.x

Síntomas: Los registros de auditoría del espacio de nombres de la plataforma son visibles para el operador de infraestructura (IO) en lugar del administrador de la plataforma (PA).

Solución alternativa: Agrega manualmente la etiqueta observability.gdc.goog/auditlog-destination=pa al espacio de nombres platform en todos los clústeres de la organización. Sigue estos pasos para implementar esta solución manual:

Establece KUBECONFIG en el clúster de destino.

Agrega la etiqueta obligatoria al espacio de nombres:

KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

Confirma que la etiqueta se haya agregado correctamente:

KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Los Pods no pueden inicializar contenedores

Versiones: 1.13.x

Síntomas: No se pueden crear los Pods y se muestra un error similar al siguiente:

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

Estos errores impiden que los pods se inicien en un nodo específico. El comportamiento observado surge de un caso límite conocido en el que el archivo de estado logrotate-daemon se bloquea, lo que impide que el daemon realice la rotación de archivos esperada. Para confirmar este error, sigue estos pasos:

Establece KUBECONFIG en el clúster de destino.

Identifica la instancia anthos-audit-logs-forwarder-xxxx programada en el nodo.

KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

Recupera los registros de la instancia de anthos-audit-logs-forwarder-xxxx programada en el nodo para verificar.

KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

Solución alternativa:

Sigue estos pasos para resolver el problema:

Realiza la recuperación manual de espacio en disco en el directorio /var/log del nodo.
Establece KUBECONFIG en el clúster de destino.

Identifica el nodo de destino en el clúster.

KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide

Conéctate al nodo con SSH y libera espacio de forma manual en el directorio /var/log del nodo. logrotate administra los archivos en estos directorios.

/var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

Verifica si hay archivos de registro inusualmente grandes (más de 100 MB) o archivos con más de un par de días de antigüedad. Cuando tengas el archivo de destino, puedes truncar los registros de la siguiente manera:
```
truncate -s 1G <target_file>
```

Identifica la instancia anthos-audit-logs-forwarder-xxxx programada en el nodo.

KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

Reinicia la instancia anthos-audit-logs-forwarder-xxxx programada en el nodo.

KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx

Marketplace

Falla la extracción de imágenes de Prisma Cloud

Versiones: 1.13.7

Síntomas: Falla la creación de una instancia de servicio de Prisma Cloud desde Marketplace. El problema se debe a una etiqueta de imagen incorrecta.

Solución alternativa:

Edita la implementación de twistlock-console para modificar la etiqueta de imagen:

KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

Busca la siguiente línea:

image: HARBOR_IP/library/twistlock/console:console_33_01_137

Reemplaza console_33_01_137 por console_33.01.137:

image: HARBOR_IP/library/twistlock/console:console_33.01.137

Verifica que el pod se ejecute correctamente:

KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

El resultado podría verse como este ejemplo:

NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

Supervisión

Se creó una gran cantidad de alertas en ServiceNow

Versiones: 1.13.x

Síntomas:

Después de configurar Monitoring para que envíe alertas a ServiceNow con las tareas de esfuerzo MON-T0016 y MON-T1016, se crean automáticamente una gran cantidad de incidentes en ServiceNow.

El problema tiene las siguientes características:

Todos los incidentes están vacíos.
Solo el clúster de administrador raíz y la organización gdchservices pueden enviar alertas a ServiceNow.

Solución: Sigue la tarea de toil MON-T0018 inmediatamente después de ejecutar las tareas de toil MON-T0016 y MON-T1016.

Se crearon varias alertas duplicadas en ServiceNow

Versiones: 1.13.x

Síntomas:

Después de configurar Monitoring para que envíe alertas a ServiceNow con las tareas de toil MON-T0016, MON-T1016 y MON-T0018, se crean varias alertas duplicadas en ServiceNow.

El problema tiene las siguientes características:

Se crean varios incidentes duplicados para algunas alertas, incluso después de aplicar la tarea de toil MON-T0018.

Solución: Sigue la tarea de toil MON-T0019 inmediatamente después de ejecutar las tareas de toil MON-T0016, MON-T1016 y MON-T0018.

No se pueden ver las métricas de Vertex AI

Versiones: 1.13.1

Síntomas: El pod dvs-frontend-server no emite métricas.

Solución alternativa: La versión 1.13.1 no admite métricas encriptadas para los servicios de Vertex AI. Si el servicio de Vertex AI no se habilita durante más de una hora, reinicia el pod del controlador mon-admin.

Error de conciliación en `mon-cortex`

Versiones: 1.13.1 y 1.13.9

Síntomas: El pod mon-cortex tiene un error de conciliación. Obtén el estado del pod mon-cortex:

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

El resultado podría verse de la siguiente manera:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Es posible que se registre un mensaje como el siguiente:

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

Solución alternativa:

Verifica qué Pod de Cortex muestra un mensaje como este:

Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

Borra el PVC asociado a ese Pod y reinícialo.

El pod `metrics-server-exporter` del clúster del sistema está en un bucle de fallas

Versiones: 1.13.1

Síntomas: El pod metrics-server-exporter del clúster del sistema se reinicia en bucle con OOMKilled, pero no parece alcanzar su límite. Diagnostica el error:

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

El resultado podría verse de la siguiente manera:

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

Solución alternativa: Borra el pod y permite que se reinicie para reducir la cantidad de datos que se entregan en el extremo de métricas. Cuando se hace esto, se borra el objeto time-series anterior que se mantiene en la memoria, lo que reduce la memoria requerida.

Ignora los mensajes de error de conciliación de `ObservabilityPipeline`

Versiones: 1.13

Síntomas:

El objeto ObservabilityPipeline muestra registros de Reconciler error como los siguientes en el pod root-admin-controller:

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

Solución alternativa:

Ignora los registros que satisfagan todas las siguientes condiciones:

"controller":"observabilitypipeline"
"namespace":"infra-obs"
"name":"default"
"err" contiene failed to get system cluster client to install per project overrides: root admin cluster has no system cluster

Si estás depurando una alerta debido a errores de conciliación altos, ignora estos registros, ya que son falsos negativos.

Se restablece el ConfigMap `mon-prober-backend-prometheus-config`

Versiones: 1.13.0 y 1.13.1

Síntomas:

Se activa la alerta MON-A0001.

El ConfigMap mon-prober-backend-prometheus-config se restablece para no incluir trabajos de sondeo, por ejemplo:

apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

Solución alternativa:

Sigue estos pasos para resolver el problema:

Configura las siguientes variables de entorno:
- KUBECONFIG: Es la ruta de acceso al archivo kubeconfig en el clúster.
- TARGET_CLUSTER: Es el nombre del clúster en el que resolverás el problema.

Pausa el subcomponente mon-prober en todos los clústeres:

kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

Por ejemplo:

kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

Reinicia el controlador del administrador de MON en cada clúster de administrador:
```
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller
```
El ConfigMap de Prober se completa a medida que se registra cada sondeo.
Sigue el manual de ejecución MON-R2009 para silenciar la alerta MON-A0001, Blackbox monitoring metrics pipeline down, ya que esta alerta seguirá activándose.

Bucle de fallas de OOMKilled del componente de puerta de enlace de la tienda de Cortex

Versiones: 1.13.3

Síntomas: Si ves errores en Grafana cuando cargas métricas o si las métricas no se cargan, es posible que el pod cortex-store-gateway esté en un bucle de fallas.

Para diagnosticar el Pod cortex-store-gateway y verificar si se encuentra en un bucle de fallas, revisa su estado:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

Reemplaza SYSTEM_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster del sistema.

Si el Pod está en un bucle de fallas, el resultado se verá como en el siguiente ejemplo:

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

Solución alternativa: Aumenta temporalmente el límite de memoria de cortex-store-gateway con un SubcomponentOverride. Para obtener detalles sobre la implementación de un SubComponentOverride, consulta el runbook MON-R2008.

A continuación, se muestra un ejemplo de un SubcomponentOverride con un límite de memoria especificado:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

Deja la anulación hasta que todos los Pods de cortex-store-gateway tengan el estado Ready y asegúrate de que el subcomponente mon-cortex no esté pausado:

Verifica que los Pods cortex-store-gateway tengan el estado Ready:
```
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway
```
El resultado se ve como en el siguiente ejemplo si todos los Pods tienen el estado Ready:
```
NAME                   READY   AGE
cortex-store-gateway   3/3     70d
```
La columna READY debe mostrar un valor N/N para que todos los Pods estén listos. De lo contrario, muestra valores como 1/3 o 2/3.
Asegúrate de que el subcomponente mon-cortex no esté en pausa en una organización determinada:
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused
```
Reemplaza lo siguiente:
- ORG_ADMIN_KUBECONFIG: Es la ruta al archivo kubeconfig del clúster de administrador de la organización.
- SYSTEM_CLUSTER: Es el nombre del clúster del sistema.
Si el subcomponente está en pausa, el resultado muestra la siguiente línea:
```
lcm.private.gdc.goog/paused: true
```
De lo contrario, el resultado estará vacío.

Tiempo de espera para la extracción de la imagen del proxy de métricas del plano de control de Kube en el clúster de usuario

Versiones: 1.13.3

Síntomas: Cuando las métricas relacionadas con kube-scheduler o kube-controller-manager (por ejemplo, las métricas scheduler_pending_pods y workqueue_depth) no están visibles en Grafana, es posible que haya un problema de retirada de imágenes con el pod kube-control-plane-metrics-proxy.

Para diagnosticar el pod kube-control-plane-metrics-proxy y verificar si tiene un problema de retirada de la imagen, revisa su estado:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

Si el Pod tiene un problema de retirada de extracción de imágenes, el resultado se verá como el siguiente ejemplo:

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

Solución alternativa: Sigue estos pasos para resolver el problema:

Extrae la imagen gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 del proyecto gpc-system-container-images de Harbor. Para obtener instrucciones y los permisos necesarios para extraer una imagen, consulta Cómo extraer una imagen con Docker.
Envía la imagen gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 al proyecto library de Harbor. Para obtener instrucciones y conocer los permisos necesarios para enviar una imagen, consulta Envía una imagen.

El proyecto library se usa para que los artefactos se implementen en el clúster de usuario.

Un aumento en el WAL hace que Prometheus use mucha memoria

Versiones: 1.13.3

Síntomas: El nodo de VM del plano de control del sistema informa eventos NodeHasInsufficientMemory y EvictionThresholdMet:

kubectl describe node NODE_NAME | grep Events -A100

El resultado podría parecerse al siguiente ejemplo:

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

Prometheus usa mucha memoria debido al crecimiento del WAL (registro de escritura por adelantado), lo que afecta la memoria del nodo. El crecimiento del WAL puede deberse a que no se implementó Cortex, por lo que este problema podría ser una consecuencia de la inactividad de Cortex. La instancia de Prometheus pierde la conectividad con Cortex durante un período prolongado, durante el cual almacena datos en búfer en la memoria y en el volumen persistente (PV). Cuando se cierra Prometheus, carga todos los datos de su WAL en la memoria durante el inicio.

Otra causa raíz podrían ser los problemas de conectividad de red (malla de servicios, redes físicas y superiores).

Solución alternativa: Para recuperarse de este estado, la acción recomendada es resolver la causa raíz y lograr que Cortex esté en buen estado o resolver los problemas de conectividad de red. Luego, espera a que se vacíe el WAL de Prometheus. No perderás datos, pero, si Cortex no funcionaba, el nodo no estará disponible durante el tiempo que tarde en recuperarse.

Como alternativa, puedes reducir la escala de Prometheus STS a cero y borrar el PV. Esta acción reduce el tiempo total durante el que el nodo no está disponible, pero provoca la pérdida de datos. Además, mientras Cortex siga inactivo o tengas problemas de conectividad de red, debes repetir esta acción periódicamente. Mientras haya un problema de conexión entre Prometheus y Cortex, el PV se volverá a llenar.

Sigue estos pasos para reducir la escala de Prometheus STS a cero y borrar el PV:

Reduce la escala vertical del componente logmon-operator:
```
kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0
```
Reemplaza ORG_SYSTEM_KUBECONFIG por la ruta de acceso al archivo kubeconfig en el clúster del sistema de la organización.

Reduce verticalmente la escala del componente anthos-prometheus-k8s:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

Borra la reclamación de volúmenes persistentes:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

Vuelve a escalar verticalmente logmon-operator:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

Espera a que anthos-prometheus-k8s esté listo.

Arranque multizona

Faltan roles de clúster

Versiones: 1.13.1

Síntomas: No hay roles específicos para el bootstrapping de varias zonas que se puedan usar en Add required roles.

Solución alternativa: Usa el rol de clúster cluster-admin como se especifica en las instrucciones vinculadas. Esto le otorga al usuario más del acceso mínimo requerido para realizar las tareas posteriores.

Recurso `Bootstrap` incompatible

Versiones: 1.13.1

Síntomas: El recurso Bootstrap creado en el paso 3 de Crea el archivo de arranque es incompatible con la lógica que lo procesa.

Solución alternativa: Edita el archivo YAML generado como se especifica en el paso 4.

No se crea el recurso `GlobalAPIZone` en la API global.

Versiones: 1.13.1

Síntomas: El plano de control no crea un recurso GlobalAPIZone para la zona en la API global, lo que provoca que los componentes que dependen de este recurso no funcionen correctamente.

Solución: Crea el recurso como se indica en Crea el recurso GlobalAPIZone.

Redes

La red de nodos de almacenamiento de objetos no funciona

Versiones: 1.13.1, 1.13.3 y 1.13.4

Síntomas:

Durante la fase de inicio del almacenamiento de objetos, la red de la cuadrícula se muestra como inactiva en la IU del instalador del nodo de administración de OBJ.
cables.csv y Cell CR muestran que el valor de MPN en cables.csv es QSFP-100G-CU2.5M para las conexiones entre los nodos objsadmin de almacenamiento de objetos y el conmutador TOR.

Explicación En la versión 1.13, el campo MPN de cables.csv se usa para determinar qué velocidad se establece en el conmutador de Tor. Si no se establece la velocidad en estos puertos, fallará la conectividad del conmutador Tor con el nodo objsadmin. La lista que se usó para asignar el MPN a la velocidad no tuvo en cuenta un valor que proporcionó el integrador del sistema, lo que provocó que fallara el inicio del almacenamiento de objetos. En la mayoría de las configuraciones de la versión 1.13, se usa el proveedor QSFP-100G-CU2.5M.

Solución alternativa:

Usa kubectl get -A cell -oyaml en el clúster de administrador raíz para encontrar la conexión relacionada con el dispositivo de almacenamiento de objetos y el conmutador TOR.
Cambia todas las ocurrencias de mpn a "QSFP-100G-CU3M" para la conexión de objsadm -> torsw.

Este es un ejemplo:

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

No se puede acceder al nodo

Versiones: 1.13.1, 1.13.3 y 1.13.4

Síntomas:

Durante la fase de arranque de la red, no se puede acceder a algunos conmutadores.
Durante la fase de instalación de DHCP, no se puede acceder a algunos servidores a través de su dirección IP de iLO.

Solución alternativa:

Vuelve a cargar los interruptores de administración afectados. Consulta el manual de ejecución PNET-R0018 para obtener más detalles.

`PodCIDR` no se asigna a los nodos, aunque se cree `ClusterCIDRConfig`

Versiones: 1.13.1

Síntomas: Un ClusterCIDRConfig es un objeto obligatorio para asignar PodCIDRs. A pesar de que se creó el ClusterCIDRConfig, no se asignó el PodCIDRs. Este problema se produce si se crea un objeto ClusterCIDRConfig al mismo tiempo que se inician los Pods de ipam-controller. La creación del clúster está atascada en el estado de conciliación.

Verifica si se creó el objeto ClusterCIDRConfig en el clúster:

kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

El resultado podría verse de la siguiente manera:

apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

Ejecuta la descripción de uno de los objetos de nodo del clúster que está atascado en la reconciliación y verifica si hay un evento CIDRNotAvailable en el objeto de nodo:

kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

Los eventos de salida podrían verse de la siguiente manera:

  Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

Solución alternativa:

Reinicia los Pods ipam-controller-manager:

kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

Una vez que los Pods de ipam-controller-manager estén en estado de ejecución, verifica si podCIDR está asignado a los nodos:

kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR

El resultado podría verse de la siguiente manera:

podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:

Desvío de NTP

Versiones: 1.13.1

Síntomas: Un nodo de VM tiene una hora imprecisa o desfasada después de estar inactivo o en ejecución durante un tiempo.

Solución alternativa:

Establece una conexión SSH con el nodo de la VM y edita el archivo /etc/chrony.conf.
Reemplaza la línea makestep 1.0 3 por makestep 1.0 -1.
Reinicia el servicio de chronyd:
```
systemctl restart chronyd
```

Solo debes realizar este cambio una vez en cada VM. El cambio no se reemplazará.

Para solucionar el problema de inmediato y de forma más rápida, establece una conexión SSH al nodo de la VM y ejecuta chronyc -a makestep.

No se analizaron los registros de auditoría de SyncServer

Versiones: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Síntomas: El log-remote-logger no analiza correctamente los registros de auditoría de SyncServer. Algunos registros de auditoría no estarán disponibles en Grafana, y es posible que veas mensajes de error en el pod log-remote-logger de administrador raíz, como los siguientes:

Failed to fetch syncserver audit logs for syncserver-...

Solución alternativa: Los registros de auditoría aún están disponibles en SyncServer. Sigue NTP-P0002 para acceder a la IU de SyncServer y ver los registros en Logs > Events.

No se pudo extraer la imagen del interruptor

Versiones: 1.13.3

Síntomas: Es posible que veas un mensaje como este en el objeto SwitchImageHostRequest cuando realices un reemplazo por RMA o cuando inicialices el clúster de administrador raíz:

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

Si tienes acceso a kubectl, úsalo para verificar si tienes este problema:

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

El resultado podría parecerse al siguiente ejemplo:

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

Solución alternativa:

Crea manualmente un SwitchImageHostRequest con la etiqueta de imagen correcta:

Accede al servidor de arranque.
Usa gdcloud para identificar la versión correcta de la imagen del interruptor:
```
release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch
```
El resultado podría parecerse al siguiente ejemplo:
```
│   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385
```
En este resultado, la versión correcta de la imagen del interruptor es 1.13.3-gdch.5385.

Edita el objeto SwitchImageHostRequest que informa el error:

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

Edita o reemplaza los campos name, fromVersion y toVersion para que coincidan con la versión de la imagen de cambio esperada. En este caso, es 1.13.3-gdch.5385. Consulta el siguiente resultado de diff, que ilustra los cambios que se deben realizar en el objeto SwitchImageHostRequest.

kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385

Falla la comunicación del Pod de StatefulSet

Versiones: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9, 1.13.10

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*]

Problemas de conectividad con las instancias de DBS

Versiones: 1.13.0 y 1.13.1

Síntomas: No se puede acceder a las instancias de Database Services (DBS) y los clientes de bases de datos muestran tiempos de espera de conexión.

Este problema podría surgir a través de otro componente del sistema que dependa de DBS. Por ejemplo, es posible que Billing informe mensajes de error como los siguientes:

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

Solución alternativa: La falla se debe a que un componente del sistema de redes no puede programarse en el clúster de servicio de la organización.

Configura las siguientes variables de entorno:
```
export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME
```
Reemplaza lo siguiente:
- KUBECONFIG_PATH: Es la ruta al archivo kubeconfig del clúster de administrador de la organización.
- ORG_NAME: El nombre de tu organización, como org-1.

Actualiza la configuración del componente de redes para permitir que se programe:

kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

La conectividad de red se restablece después de unos minutos.

La malla de clústeres no está configurada con información de zonas

Versiones: 1.13.5

Síntomas: Una VM no se puede conectar a un clúster de base de datos en el mismo proyecto. Se ve afectada la conectividad con el balanceador de cargas interno. Este problema se debe a que un Clustermesh no puede intercambiar objetos de servicio entre clústeres porque falta información de la zona en la configuración del nombre del clúster.

Solución alternativa: En los entornos que se inicializaron como multizona, realiza los siguientes pasos manuales de solución alternativa para que funcione el balanceador de cargas interno:

En el clúster de administrador de la organización, obtén el nombre de la zona:
```
ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME
```
El resultado podría verse como este ejemplo:
```
zone1
```
En el clúster de administrador de la organización, obtén el ID del sitio de la zona:
```
SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID
```
El resultado podría verse como este ejemplo:
```
1
```

Enumera todos los clústeres:

kubectl get clusters -A

El resultado podría verse como este ejemplo:

NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

Para cada clúster, construye el CILIUM_CLUSTERNAME:

CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

El resultado podría verse como este ejemplo:

org-1-system-zone1

Para cada clúster, establece los demás parámetros de la siguiente manera. El siguiente ejemplo para org-1-system:
```
CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592
```

Para cada clúster, crea un objeto AddOnConfiguration y almacénalo en un archivo addonconfig.yaml. Crea este archivo para todos los clústeres existentes y los clústeres nuevos que crees en el futuro:

En esta página, configura las siguientes variables para actualizar el siguiente muestra de código:

CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

Aplica addonconfig.yaml en el clúster de administrador de la organización:
```
kubectl apply -f addonconfig.yaml
```
En los clústeres del sistema, de servicio y de usuario, asegúrate de que cluster-name se actualice en cilium-config del clúster. La actualización puede tardar un poco, pero este paso es necesario antes de reiniciar la implementación de clustermesh-apiserver.
```
kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo
```
En los clústeres del sistema, de servicio y de usuario, reinicia la implementación de clustermesh-apiserver:
```
kubectl rollout restart deployment -n kube-system clustermesh-apiserver
```

Se generan direcciones IP de EVPN incorrectas

Versiones: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Síntomas: Las direcciones IP de intercambio de tráfico de la sesión de interconexión de EVPN multizona (MZ) que genera el sistema de administración de activos de hardware (HAMS) no terminan en .65 o .66, lo que es incorrecto y evita que se establezcan las sesiones de BGP de EVPN MZ.

Solución alternativa:

Para resolver este problema de forma manual, sigue estos pasos:

Enumera todos los recursos InterconnectSession:

kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

Revisa los recursos InterconnectSession de varias zonas de EVPN generados que tienen un valor interconnectType de ZonePeering y un addressFamily de EVPN:

apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

Para cada uno de los recursos InterconnectSession que coincidan con estos parámetros, aplica la siguiente corrección:
1. Verifica el nombre del recurso personalizado de la sesión de interconexión.
2. Si el nombre termina en un número impar, actualiza la última parte de la dirección IP del par a 65 con el comando del siguiente paso.
3. Si el nombre termina en un número par, actualiza la última parte de la dirección IP del par a 66 con el comando del siguiente paso.

Modifica el recurso InterconnectSession con la dirección IP del par incorrecta:

kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

Aplica esta corrección a todos los recursos InterconnectSession que causan el error.

El panel de control de la parte superior del plano de control de redes no muestra datos

Versiones: 1.13.7

Síntomas: Las consultas de Prometheus en TestUpperNetworkingMetrics fallan debido a la falta de métricas en el clúster org-1-system. Los paneles de clustermesh en el panel de Upper Networking del plano de control para los administradores de la organización de IO no muestran datos. El problema se debe a una falta de coincidencia en la etiqueta source_cluster entre Cilium y el sistema de supervisión.

Solución alternativa: Quita el filtro source_cluster del panel de control de UNET para mostrar los datos.

Errores de pista falsa que se muestran en la instalación de la red

Versiones: 1.13.1

Síntomas: Durante la instalación de la red, se muestran algunos mensajes de advertencia sobre el cableado. Por ejemplo:

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

Estos mensajes de error se pueden ignorar sin problemas.

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*]

Almacenamiento de objetos

No se puede borrar la organización de almacenamiento

Versiones: 1.13.1

Síntomas: Es posible que no se pueda borrar una organización debido a un problema que impide que se complete el borrado del SVM. Es posible que veas una advertencia como esta:

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

Se pueden ignorar algunas advertencias de actualización del almacenamiento de objetos

Versiones: 1.13.3

Síntomas: Cuando actualices el almacenamiento de objetos, es posible que veas una advertencia como esta:

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

Solución alternativa:

Verifica que cada nodo tenga las credenciales de SSH correspondientes almacenadas en un secreto.

Verifica los nodos de administrador:

kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

Verifica los nodos de almacenamiento:

kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

El resultado correcto se ve como este ejemplo para los nodos de almacenamiento:

NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

Si no se encuentra un secreto, el error se verá de la siguiente manera:

Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

Si el comando no muestra ningún error, puedes ignorar de forma segura los errores que informan los reconciliadores.

`ObjectStorageStorageNodeReconciler` informes `maintenance.gdu.gdu_server_locked`

Versiones: 1.13.3

Síntomas: Muestra los detalles del objectstoragestoragenode:

kubectl describe objectstoragestoragenode zv-aa-objs02

El resultado podría parecerse al siguiente ejemplo:

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

Solución: Este problema se puede ignorar. Es posible que el servicio de GDU se bloquee temporalmente cuando recibe demasiadas solicitudes, pero se desbloqueará después de unos minutos.

Falla la verificación de Object Storage posterior a la actualización de 1.12.x a 1.13.x

Versiones: 1.13.x

Síntoma: El CR de ObjectStorageUpgrade falla con el error

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Los Pods gpc-system/upgrade-managed-check-objectstorageupgrade fallan con un error

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

Causa raíz: La actualización del componente operativo de Object Storage de la versión 1.12.x a la 1.13.x falla si no se desactivó o borró el clúster KIND de inicio. Incluso si la actualización se realiza correctamente, es posible que los servicios comunes de almacenamiento de objetos, como la creación de buckets nuevos o credenciales de S3 a través del RBAC de Kubernetes, fallen debido a errores de validación del certificado TLS. Esto se debe a que un pod de almacenamiento de objetos específico dentro del clúster de KIND intenta instalar continuamente el certificado del servidor TLS del extremo de administración de StorageGRID, que era válido en la versión 1.12.x, pero que podría no reconocerse en la versión 1.13.x. Durante la actualización, StorageGRID instala un certificado de servidor TLS nuevo y verificable, pero el pod del clúster de KIND lo reemplaza por el certificado anterior no válido, lo que provoca el error del certificado TLS.

Solución alternativa: Se deben cumplir los siguientes requisitos:

Actualización del almacenamiento de objetos de la versión 1.12.x a la 1.13.x
El clúster de arranque (el clúster de KIND) aún existe.

Sigue estos pasos:

Adquiere un kubeconfig que tenga permiso de visualización y modificación para el recurso ObjectStorageSite en el clúster de bootstrapping (el clúster de KIND).

Establece un alias para kubectl que se conecte al clúster de bootstrapping (el clúster de KIND):

alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>

Obtén la instancia del recurso personalizado ObjectStorageSite del clúster de arranque. Debe haber una instancia del recurso ObjectStorageSite:
```
SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')
```

Agrega una anotación de pausa de almacenamiento de objetos a la instancia de recurso ObjectStorageSite:

kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true

Verifica que se haya agregado la anotación de pausa del almacenamiento de objetos a la instancia de ObjectStorageSite:
```
kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq
```
Adquiere un kubeconfig que tenga acceso de visualización y permiso de parche de estado para los recursos ObjectStorageCluster en el clúster de administrador raíz.

Establece un alias para el kubectl que se conecta al clúster de administrador raíz:

alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

Verifica si existe alguna instancia de recurso ObjectStorageCluster en el clúster de administrador raíz:
```
kubectlrootadmin get ObjectStorageCluster
```
Si no hay una instancia de recurso ObjectStorageCluster, la solución alternativa se completó. Es posible que debas volver a realizar el procedimiento de actualización de Object Storage.

Obtén la URL del extremo de administración del estado del recurso ObjectStorageSite en el clúster de arranque:

MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')

Valida si se configuró la variable de entorno $MGMT_ENDPOINT. El extremo debe comenzar con https://:
```
echo ${MGMT_ENDPOINT:?}
```
Realiza los pasos restantes solo cuando haya exactamente una instancia de recurso ObjectStorageCluster en el clúster de administrador raíz. De lo contrario, vuelve a realizar el procedimiento de actualización del almacenamiento de objetos:
```
kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"
```

Reinicia el pod gpc-system/obj-infra-cluster-cm:

kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

Verifica si se agregó el extremo de administración al estado del recurso ObjectStorageCluster:
```
kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq
```
Para reiniciar la verificación posterior al vuelo, borra el trabajo de Kubernetes de la verificación posterior al vuelo gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. El trabajo se volverá a crear pronto.

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 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 egress
```

Reinicia el daemonset anetd para el clúster con el nodo afectado:

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

Sistema operativo

Pods atascados en el estado `init`

Versiones: 1.13.1

Síntomas: El nodo informa que está listo, pero el acceso SSH al nodo es lento y top -n 1 muestra más de 100 procesos zombis.

Solución alternativa:

Sigue OS-P0001 para vaciar el servidor. El drenaje puede tardar más de 20 minutos. Si el drenaje no se completa después de una hora, continúa con el siguiente paso.
Para reiniciar el servidor, establece una conexión SSH con él y ejecuta el siguiente comando:
```
systemctl reboot
```
Es posible que se necesite un segundo reinicio para recuperar por completo el servidor.
Verifica que el acceso SSH ya no sea lento y que la cantidad de procesos zombis sea mucho menor, preferentemente menos de 30.
Para anular el drenaje del servidor, configura maintenance como false en el servidor.

`bm-system-machine-preflight-check` Falla el trabajo de Ansible para un nodo de VM o de metal desnudo

Versiones: 1.13.1

Síntomas: El módulo del kernel nf_tables no se carga después del reinicio, lo que provoca que los trabajos de Ansible del clúster fallen con un error Either ip_tables or nf_tables kernel module must be loaded. Este problema ocurre cuando se reinicia el nodo de VM o de metal desnudo antes de que se aprovisione por completo. Es posible que el trabajo de Ansible arroje un error como el siguiente:

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

Solución alternativa:

Establece una conexión SSH con el nodo y ejecuta el siguiente comando:

modprobe nf_tables

VM sin espacio disponible en el dispositivo

Versiones: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Síntomas: Cuando el directorio de registro /var/log está lleno, es posible que Node se bloquee en el estado NotReady y que los Pods no se puedan iniciar debido al error no space left on device. Para verificar esto, ejecuta el siguiente comando en el nodo y comprueba si el uso es de alrededor del 100%.

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

Solución alternativa:

Accede al nodo que presenta el problema y limpia los archivos de registro antiguos de /var/log/messages.
```
find /var/log -name "messages*" -mtime +4 -delete
```
También se recomienda seguir aplicando la siguiente solución alternativa para evitar que esto suceda. La solución alternativa es crear un AnsiblePlaybook y aplicar el cambio a través de un CR OSPolicy personalizado responsable de configurar de forma segura el SO de destino (máquinas BM y VM). Consulta el proceso OS-P0005 para obtener más detalles.

Configura las siguientes variables de entorno:

export KUBECONFIG=<the path to the kubeconfig file>

Crea un playbook de Ansible para la solución alternativa:

kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

Identifica los inventarios objetivo a los que se debe aplicar el cambio. El objetivo puede ser un InventoryMachine individual o un NodePool. Consulta el proceso OS-P0005 (2. Identifica el inventario objetivo para las configuraciones del tiempo de ejecución) para obtener más detalles.

En el siguiente ejemplo de OSPolicy, se incluyen dos inventarios objetivo en spec.inventory. Puedes agregar más inventarios según sea necesario.

kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

Validación

Consulta el proceso OS-P0005 (validación) para hacer un seguimiento del estado de ejecución de la política.

Los Pods están atascados en el estado `ContainerCreating`.

Versiones: 1.13.3, 1.13.5 y 1.13.6

Síntomas: Un nodo se muestra como en buen estado, pero tiene muchos Pods atascados en un estado ContainerCreating y no puedes establecer una conexión SSH con el servidor.

Solución alternativa: Apaga y enciende el servidor, y confirma que puedes establecer una conexión SSH con el nodo cuando se reinicie.

No se puede establecer una conexión SSH al nodo aprovisionado

Versiones: 1.13.5

Síntomas: Se aprovisiona un nodo, pero se agota el tiempo de espera de SSH en las IPs de administración y de datos.

Solución: Reinicia el nodo a través de iLO. Después de que se inicie, establece una conexión SSH y deshabilita clamonacc con systemctl stop clamonacc; systemctl disable clamonacc.

Infraestructura de Operations Suite (OI)

No se necesita la SSA para el hardware 3.0

La configuración del adaptador RAID es diferente para el Hardware 3.0. Los servidores de OIC de hardware 3.0 usan una unidad de disco autoencriptada, por lo que ya no es necesario iniciar la Administración de almacenamiento inteligente (SSA). Se necesitan pasos adicionales para determinar los identificadores de disco por servidor. Consulta Arranque del servidor de OI.

Seguridad perimetral

El clúster del sistema de la organización se bloquea durante el inicio de la organización

Versiones: 1.13.1

Síntomas: Durante el inicio de la organización, es posible que el clúster del sistema de la organización se bloquee. Los pods edr-sidecar-injector están en estado pendiente. Cuando intentes borrar estos Pods, es posible que veas un mensaje de error como el siguiente:

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

Al mismo tiempo, es posible que otros Pods pendientes tengan mensajes de error como este:

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

El sistema necesita intervención manual para desbloquearse.

Solución alternativa:

Duplica la CR de MutatingWebhookConfiguration edr-sidecar-injector-webhook-cfg en el clúster del sistema.
Duplica la CR de ValidatingWebhookConfiguration gatekeeper-validating-webhook-configuration en el clúster del sistema.
Borra la CR de edr-sidecar-injector-webhook-cfg y la CR de gatekeeper-validating-webhook-configuration del clúster del sistema.
Espera a que los Pods de edr-sidecar-injector y gatekeeper-controller-manager vuelvan a estar activos.
Restablece el CR de webhook con el comando kubectl apply.

Los grupos de direcciones de firewall de PANW no se actualizan con los cambios en los reclamos de CIDR

Versiones: 1.13.1

Síntomas: Durante el inicio, el OCIT cidr-claim se actualiza con el valor correcto, pero el firewall AddressGroups no lo hace. Un par de AddressGroups, específicamente vsys1-root-ocit-network-cidr-group y ocvsys1-root-ocit-network-cidr-group, usan bloques de red que no se superponen con lo que se usa realmente en la OIR. OIR no puede resolver los registros de zona de GDC y las consultas agotan el tiempo de espera sin una respuesta.

Solución: Después de los cambios en cidr-claim, asegúrate de que AddressGroup se actualice con el cidr-claim más reciente. Para ello, reinicia la implementación de fw-core-backend-controller en el espacio de nombres fw-system del clúster de administrador raíz.

Servidores físicos

El inicio del servidor falla debido a problemas de POST en el servidor HPE

Versiones: 1.13.1

Síntomas: El arranque del servidor falla cuando este no puede superar el proceso de inicio POST. Acceder a la ILO y verificar la consola del servidor muestra el siguiente error:

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

Solución alternativa:

En iLO, haz clic en el botón de encendido y selecciona Cold Boot.

Servidores atascados en el estado de aprovisionamiento

Versiones: 1.13.1, 1.13.3 y 1.13.5

Síntomas: Los servidores se atascan en un estado de aprovisionamiento durante el inicio del servidor. Comprueba el estado de los servidores:

k get servers -A | grep -v availabl

El resultado podría verse de la siguiente manera:

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

Solución alternativa:

Inicia dhcp de forma manual con una configuración descargada del clúster de KIND. En este ejemplo, /tmp/dhcp.conf es la configuración de DHCP del clúster de KIND:
```
docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION
```
Reemplaza VERSION por la versión de lanzamiento, como se describe en las instrucciones de actualización en Actualización manual del componente de archivos para clústeres raíz y de administrador de la organización, por ejemplo, 1.13.1-gdch.525.
Verifica la configuración del BIOS en el servidor y comprueba que NetworkBoot no esté habilitado para las NIC de plano de datos (cuyo nombre sigue el patrón Slot{i}Nic{i}).
Verifica el BIOS con la llamada a la API:
```
curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword
```
Aquí, $bmcUser y $bmcPassword son las contraseñas de los ILO, que se pueden encontrar en el archivo o directorio cellcfg en un secreto llamado bmc-credentials-<server-name>, por ejemplo, bmc-credentials-ai-aa-bm01. Verifica que el resultado de este comando muestre Slot1Nic1: Disabled.

Si alguno de esos Slot{i}Nic{i} tiene NetworkBoot, inhabilítalo con la API de configuración del BIOS.

curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'

Reemplaza Slot{i}Nic{i} por el nombre de la ranura que tiene el problema en la carga útil.

Reinicia el servidor.

No se puede aprovisionar el servidor DL380a

Versiones: 1.13.3, 1.13.4 y 1.13.5

Síntomas: El aprovisionamiento del servidor falla en el trabajo de encriptación para el modelo HPE DL380a. El estado del CR del servidor se atasca en available durante el arranque del servidor:

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

Solución alternativa:

Sigue IAM-R0004 para generar el KUBECONFIG para el root-admin-cluster.
Sigue PLATAUTH-G0001 para generar la clave SSH root-id_rsa para CLUSTER_NS=root.

Agrega la anotación server.system.private.gdc.goog/paused al recurso personalizado del servidor para pausarlo:

kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

Accede al servidor desde la IP de administración:

export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

Habilita la encriptación de forma manual:

/opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

El resultado de los comandos debería ser similar al siguiente:

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

Si ves que el último comando no se ejecutó correctamente o ves errores como "Invalid BIOS EKM status", reinicia el servidor y el iLO, y vuelve a ejecutar este paso.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

Si el último comando se ejecutó correctamente, reinicia el servidor según las instrucciones.

Crea la unidad lógica de forma manual:

Después de que el servidor termine de reiniciarse, vuelve a acceder a él desde la IP de administración y enumera todas las unidades disponibles:

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

El resultado del último comando podría verse como este ejemplo:

{
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

Debes guardar los 2 IDs de EID:Slt con Size igual a 1.60 TB, en este caso:

252:1,252:2

Luego, crea una unidad lógica con IDs de EID:Slt:

/opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

El resultado del último comando se ve como el siguiente ejemplo:

/opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

Simula el estado de encriptación del disco en el CR del servidor.

Edita el estado del CR del servidor:

kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

Agrega o modifica el estado de DiskEncryptionEnabled como verdadero:

  - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

Borra el trabajo de encriptación del servidor, si existe:

kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

Reactiva el servidor para que se reanude el aprovisionamiento:

kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

El borrado seguro falla sin una licencia

Versiones: 1.13.5

Síntomas: Cuando un servidor se bloquea durante la instalación, es posible que veas un estado en el CR del servidor como el siguiente:

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

Solución alternativa: Sigue las instrucciones del manual de ejecución SERV-R0014.

Seguridad de la plataforma

El reconciliador de la SubCA BYO no verifica si los certificados tienen una clave pública coincidente

Versiones: 1.13.1

Síntomas: Cuando el modo de SubCA de BYO de PKI genera una nueva solicitud de firma de certificado (CSR) mientras se sube un certificado firmado previamente a la SubCA, el reconciliador no verifica si la nueva CSR coincide con el certificado firmado anterior y marca el recurso personalizado (CR) cert-manager CertificateRequest como Ready. Esto ocurre durante la renovación del certificado de la SubCA o la rotación manual. El controlador de cert-manager intenta actualizar el estado del CR de Certificate, lo que activa el siguiente mensaje de error:

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

Solución alternativa:

Sigue las instrucciones para subir un nuevo certificado de SubCA BYO firmado para la nueva CSR.

El problema de cert-manager genera una emisión fallida de PKI BYO con ACME

Versiones: 1.13.1

Síntomas: El error se produce en la primera emisión o renovación de certificados BYO con el entorno de administración de certificados automático (ACME). Cuando ejecutas el comando para verificar el estado del certificado, ves que el certificado está not ready:

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

El resultado es similar al siguiente:

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

Solución alternativa:

Reinicia la implementación de cert-manager en el clúster de administrador de la organización:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

Resource Manager

El estado del proyecto no está disponible en la consola de GDC

Versiones: 1.13.1 y versiones posteriores

Síntomas: La consola de GDC no muestra el estado de un proyecto. Los proyectos que no se encuentran en el estado Ready no pueden admitir recursos nuevos ni procesar modificaciones nuevas en los recursos existentes. Debido a la imposibilidad de confirmar el estado del proyecto, no está claro cuándo se pueden administrar los recursos de un proyecto, lo que genera errores cuando se intentan realizar acciones nuevas en el proyecto.

Solución alternativa: Consulta el manual de ejecución RM-R0100 para imprimir el estado del proyecto con la CLI de kubectl.

Actualizar

`bm-system` y otros trabajos atascados

Versiones: 1.13.1

Síntomas: El trabajo bm-system y otros trabajos que ejecutan el playbook de Ansible se atascan en gathering facts.

Solución alternativa: Ingresa el nombre del nodo que está atascado y ejecuta multipath -ll | grep failed y multipath -ll | grep #. Si hay un resultado no vacío,sigue los manuales FILE R0020 y FILE R0021.

IP de administración inaccesible

Versiones: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Síntomas: Durante una actualización, no se puede acceder a la IP de administración de un servidor, en especial después de un cambio.

Con Rocky Linux, cuando se agregan rutas estáticas, se debe poder acceder a la IP de destino que se usa para llegar a las rutas estáticas antes de agregarlas. Si el conmutador se reinicia después de una actualización del SO, es posible que no se pueda acceder a esa IP de administración de forma temporal.

Solución alternativa: Establece una conexión SSH con el servidor a través de la dirección IP de datos y reinicia el servicio de redes para volver a crear las rutas estáticas faltantes:

systemctl restart NetworkManager.service

No se muestra el número de versión de `storagecluster`.

Versiones: 1.13.3

Síntomas: Después de una actualización, la CR de StorageCluster no muestra ningún valor para el campo de estado StorageVersion.

Verifica la versión:

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

Si el campo de versión está vacío, sigue los pasos de la solución alternativa.

Solución: Reinicia la implementación de file-storage-backend-controller:

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

El servidor de equipo físico se atascó en el estado de aprovisionamiento

Versiones: 1.13.1

Síntomas:

El servidor de Bare Metal está atascado en el estado "provisioning" durante mucho tiempo cuando se crea una organización.

Solución alternativa:

Es posible que la configuración del BIOS del servidor haya cambiado para que el servidor use la tarjeta de red incorrecta para el inicio de PXE.

Sigue estos pasos para inhabilitar el arranque de red de la NIC del plano de datos.

Acceso requerido:
- Necesitarás acceso a las credenciales de administrador de la BMC de los servidores que están bloqueados.
- Sigue IAM-R0005 para obtener el rol de hardware-admin de ClusterRole en el clúster de root-admin durante 1 hora.
- Sigue IAM-R0004 para generar el archivo KUBECONFIG del clúster root-admin.

Establece el nombre del servidor atascado.
```
export SERVER_NAME=
```

Configura la IP y las credenciales de la BMC del servidor.

export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

Identifica la ranura PCIe de la tarjeta de red del plano de datos en el servidor.
```
kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}
```
Por ejemplo, el siguiente resultado indica que la tarjeta de red está instalada en la ranura 3.
```
["s3p1","s3p2"]
```
Establece la variable PCIEslot:
```
export DATA_NIC_SLOT=3
```

Confirma que el inicio de red no esté inhabilitado.

curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"

Si el resultado es "NetworkBoot", debes inhabilitarlo de forma explícita.

Usa la BMC para inhabilitar la función de arranque de red en la tarjeta de red del plano de datos.

Reemplaza "Slot3" en el siguiente comando por el número de ranura real.

curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq

y, luego, reinicia la máquina.

curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq

El servidor tarda entre 10 y 15 minutos en volver a estar disponible y reanuda automáticamente el proceso de aprovisionamiento.

La actualización del almacenamiento de objetos muestra un error durante la verificación previa o posterior al vuelo

Versiones: 1.13.1

Síntomas: Las comprobaciones previas o posteriores a la ejecución fallan con un error. Verifica los registros:

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

El error podría verse de la siguiente manera:

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

Solución alternativa:

Si el error se produce durante las verificaciones posteriores al vuelo y todas las demás verificaciones se completan sin errores, omite las verificaciones posteriores al vuelo. Cuando se reinicie la actualización, también debes omitir las verificaciones previas con el kubeconfig de administrador raíz:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Por ejemplo, si el error se produce en org-1, el comando se verá de la siguiente manera:

kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

Si el error se produce durante las comprobaciones previas y todas las demás comprobaciones previas se completan sin errores, omite las comprobaciones previas:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Por ejemplo, si el error se produce en org-1, el comando se verá de la siguiente manera:

kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

Es posible que debas aplicar esta solución alternativa más de una vez si no se aplica.

Reversiones de actualizaciones de Helm

Versiones: 1.13.3

Síntomas: Un problema de actualización de Helm genera una serie de reversiones y no se encuentra un Certificate ni un ServiceEntry. Es posible que veas un mensaje como este:

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

Solución alternativa: Sigue los pasos del manual de ejecución OCLCM-R0122.

La actualización del nodo o ABM se detuvo porque no se vació el pod dhcp-tftp-core-server

Versiones: 1.13.3, 1.14.4 y 1.14.5

Síntomas: Es posible que la actualización del nodo se detenga. En el estado de la máquina de Metal desnudo, no se vacía el pod dhcp-tftp-core-server. Es posible que veas un mensaje como este:

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

Solución alternativa: Fuerza el borrado del pod dhcp-tftp-core-server-* para continuar. El comando se ve de la siguiente manera:

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

`OrganizationUpgrade` se detuvo en la etapa de actualización del nodo

Versiones: 1.13.3

Síntomas: OrganizationUpgrade se detiene en la etapa de actualización del nodo. Es posible que veas un mensaje como este:

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

Solución alternativa:

Verifica si hay CR de upgradetaskrequest en el clúster raíz ka get upgradetaskrequest -n gpc-system. Verifica que el nodo siga en estado de ejecución. Asegúrate de que se haya atascado en la tarea de servicio.

spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

Crea manualmente objetos CR de nodeupgrade para cada reclamo del grupo de nodos:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

Crea un CR nodeupgrade para cada reclamo de grupo de nodos. Los detalles de la anotación upgrade.private.gdc.goog/target-release-version se deben obtener del nombre de CRMD del SO del objetivo:

kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h

Usa la versión de aquí en las anotaciones upgrade.private.gdc.goog/target-release-version:

kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

Aplica el siguiente yaml para cada uno de los nodepoolclaim:

    apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

Una vez que se completen las actualizaciones de los nodos del clúster de servicio, actualiza el estado del CR de UpgradeTaskRequest a True para que la actualización de la organización avance a la siguiente etapa:

    kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

La actualización de la organización ahora debería pasar a la siguiente etapa, y el estado del servicio o el nodo se completará:

Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

El kernel no puede crear un contenedor

Versiones: 1.13.3

Síntomas: El kernel no puede asignar objetos cgroup de memoria, lo que provoca errores en la creación de contenedores nuevos.

Es posible que veas un mensaje como este:

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

y el nodo usa una gran cantidad de cgroups:

# cat /proc/cgroups | grep memory
memory  12      380360  1

Solución alternativa:

Realiza una de las siguientes acciones:

Ejecuta echo 3 > /proc/sys/vm/drop_caches en el nodo y reinicia kubelet.
Si el método anterior no funciona, intenta reiniciar el nodo.

Falla de conectividad intermitente a la VIP del clúster externo

Versiones: 1.13.3

Síntomas: Las fallas de conexión intermitentes a la IP virtual (VIP) del clúster externo, como la VIP del plano de control, la VIP de istio-gateway o la VIP de Harbor, generan un error dial tcp :: connect: no route to host.

Para diagnosticar este problema, sigue estos pasos:

Conéctate al clúster de administrador raíz. Esta solución alternativa supone que estás depurando direcciones IP en un clúster de administrador raíz. Si estás depurando problemas de conectividad con otros clústeres de Kubernetes, como los clústeres de administrador de la organización o del sistema de la organización, cambia el valor de KUBECONFIG a la ruta de acceso correcta de kubeconfig del clúster.
Existen dos categorías conocidas de IPs que pueden verse afectadas. Verifica si el Protocolo de Puerta de Enlace Fronteriza (BGP) anuncia las direcciones IP a los conmutadores de la parte superior del rack (ToR):
- Si la IP es una dirección IP del plano de control de Kubernetes, como 192.0.2.100, usa este comando para obtener la información de configuración:
```
KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`
```
  Reemplaza KUBECONFIG por la ruta de acceso a tu archivo kubeconfig en el clúster de administrador raíz.
- Para algunas configuraciones, el recurso personalizado BGPAdvertisedRoute define qué rutas de la dirección IP se anuncian a otras redes o sistemas a través de BGP. Si el recurso personalizado BGPAdvertisedRoute anuncia la dirección IP, usa este comando para obtener la información de configuración:
```
TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP
```
  Reemplaza TARGET_IP_ADDRESS por la dirección IP que experimenta problemas de conectividad intermitentes.

Verifica el estado de los recursos personalizados de BGPSession. Un objeto BGPSessionrepresenta una sesión de peering de BGP individual establecida entre tu clúster de Kubernetes y un par de BGP externo. Inspecciona los registros de los Pods BGPAdvertiser y verifica que todos los recursos BGPSession estén en el estado Established:

KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`

El resultado de un Pod BGPAdvertiser en buen estado contiene el siguiente fragmento:

I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\

Verifica la estabilidad de la conexión. Crea y ejecuta una secuencia de comandos para verificar si la conectividad es intermitente o inestable:

Crea la secuencia de comandos:

#!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

Ejecuta la secuencia de comandos:

./script.sh TARGET_IP_ADDRESS:PORT

Reemplaza PORT por el número de puerto que presenta problemas.

Si tu conexión tiene problemas, verás un resultado como el siguiente:

Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

El resultado anterior confirma el problema. Verifica las rutas en los conmutadores TOR para ver si la configuración del conmutador TOR es la causa del problema.

Si se descarta el tráfico para una dirección IP de ejemplo de 192.0.2.201 y el recurso BGPAdvertisedRoute la anuncia, examina los saltos en el recurso BGPAdvertisedRoute para identificar posibles puntos de falla:

apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

Observa las direcciones IP en el campo nextHops. Para cada dirección IP, busca el nombre del servidor. Por ejemplo:
```
- 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01
```
Este resultado muestra que los próximos saltos se dirigen hacia los servidores de los racks aa y ab. Accede a los switches TOR en los racks aa y ab, y compara las rutas en ambos racks:
```
show ip route 192.0.2.201 vrf root-external-vrf
```

Si las rutas son diferentes entre los conmutadores TOR de los dos racks, tienes el problema que mitiga la solución alternativa. El resultado de este problema se ve de la siguiente manera:

zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

En este resultado, las rutas del rack aa se encuentran en el estado esperado, con tres próximos saltos enumerados junto al prefijo. Sin embargo, en el rack ab, el prefijo solo tiene dos próximos saltos. Cuando el tráfico destinado al prefijo se codifica con hash en el rack ab, el nodo correspondiente al próximo salto faltante nunca recibe el tráfico y la red experimenta el problema de conectividad.

Sigue la solución alternativa para mitigar este problema.

Solución alternativa:

Esta solución alternativa ayuda a resolver problemas de conectividad intermitentes con ciertas direcciones IP dentro de los clústeres de Kubernetes.

Para mitigar este problema, debes aplicar varios cambios de configuración a la sesión de BGP entre los conmutadores agregados. Los conmutadores de agregación (AGG) agregan tráfico de varios conmutadores TOR. Sigue estos pasos para actualizar todos los parámetros de configuración necesarios:

Un archivo de configuración llamado switchstaticconfig representa las configuraciones estáticas en un solo conmutador. Descarga el archivo switchstaticconfig para ambos interruptores de AGG:

export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

Obtén el número de sistema autónomo (ASN) del entorno:
```
root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030
```
En este resultado, se muestra un valor de ASN de 65030. Debes usar el valor de ASN que se muestra aquí en los pasos siguientes.
Una dirección IP de bucle invertido en un conmutador AGG actúa como una dirección estable y siempre activa para la administración, el enrutamiento y la solución de problemas, incluso si otras conexiones de red no funcionan. Obtén las direcciones IP de bucle invertido de cada uno de los conmutadores AGG:
```
root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'
```
El resultado es similar al siguiente:
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
Actualiza el staticswitchconfig para el interruptor de AGG za-ab-aggsw01. Agrega este fragmento a la sección config:
```
spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1
```
Reemplaza lo siguiente:
- ASN: Es el valor del ASN del paso anterior. En este ejemplo, el valor es 65030.
- LOOPBACK_ADDRESS: Es la dirección IP de bucle invertido del conmutador AGG za-ac-aggsw01. En este ejemplo, el valor es 192.0.2.2.
Aplica la misma actualización al otro conmutador de AGG, za-ac-aggsw01. Debes proporcionar la dirección de bucle invertido correcta. La dirección IP de bucle invertido es diferente para cada conmutador:
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
Crea y ejecuta la misma secuencia de comandos que se usó para diagnosticar el problema en este paso para verificar que la corrección se haya realizado correctamente. El resultado no muestra ningún mensaje de error.

Aparece el error `Incorrect version of Trident` durante la actualización

Versiones: 1.13.3, 1.13.4 y 1.13.5

Síntomas: Cuando se actualiza desde versiones anteriores a la 1.13.3, ontap muestra el error Incorrect version of Trident. Es posible que veas un mensaje como este:

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

Solución alternativa:

Actualiza el releasemetadata de la versión a la que deseas actualizar:

export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

El resultado podría verse así:

NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

Elige la versión a la que deseas actualizar, como se menciona en el siguiente ejemplo:
```
kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml
```
Actualiza tridentVersion en la sección fileBlockStorage de .yaml a la versión que se menciona en el error. Si el mensaje de error se veía así:
```
Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5
```
Cambia tridentVersion a v23.10.0-gke.5 en releasemetadata.yaml.

Por ejemplo, si el valor original era infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6,

Cámbialo por el siguiente valor:

infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5
Aplica los cambios:
```
kubectl apply -f releasemetadata.yaml
```
Vuelve a aplicar la actualización de almacenamiento de ontap.

No se pueden programar los Pods

Versiones: 1.13.3 1.13.4, 1.13.5

Síntomas: Durante el aprovisionamiento del clúster de usuario, no se pueden programar algunos Pods. Es posible que veas un mensaje como este:

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

Solución alternativa:

Aumenta la escala del grupo de nodos del plano de control del clúster de usuario:

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

La actualización falla en el subcomponente `iac-zoneselection-global`

Versiones: 1.13.1

Síntomas: Durante una actualización a la versión 1.13.3, se produce un error en el subcomponente iac-zoneselection-global. Es posible que veas un mensaje como este:

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Solución alternativa:

La actualización a la versión 1.13.3 corrige el error.

Se excedió la fecha límite de los trabajos de verificación de actualización

Versiones: 1.12.x y 1.13.x

Síntomas: Durante la actualización de la organización, la verificación de actualización muestra el estado False con el motivo DeadlineExceeded. Es posible que veas un mensaje como este:

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

Solución alternativa:

Borra los trabajos de verificación de actualización fallidos correspondientes a las verificaciones de actualización fallidas.
Espera hasta que se vuelvan a crear los trabajos de verificación de actualización.
Analiza los registros de los trabajos recreados y clasifica los problemas.

El complemento `meta-monitoring` falla porque la ubicación de strongswan se encuentra en un directorio de tiempo de ejecución diferente.

Versiones: 1.12.x y 1.13.x

Síntomas: Durante la actualización a la versión 1.13.4 o 1.13.5, falla el complemento meta-monitoring:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

Verifica el complemento:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

El mensaje de condición podría verse de la siguiente manera:

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

Solución alternativa:

Asegúrate de que las sesiones de BGP en el clúster del sistema de la organización estén fallando, por ejemplo:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

Asegúrate de que los Pods ang-node estén atascados en ContainerCreating, por ejemplo:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

Se muestra el siguiente error:

Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

Aplica el siguiente cambio a la AddonConfiguration de ang-overrides en el clúster de administrador de la organización:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

Cambia lo siguiente:

            volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

a lo siguiente:

            volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

Después de aproximadamente un minuto, confirma que los Pods ang-node ahora estén en el estado Running:

NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

Asegúrate de que las sesiones de BGP en el clúster del sistema de la organización ahora se estén ejecutando.
El complemento meta-monitoring pasará a la siguiente etapa.

La actualización de la organización raíz se detuvo debido a una falla en el trabajo de firma

Versiones: 1.13.3 y 1.13.4

Síntomas: Cuando actualices de la versión 1.13.3 a la 1.13.4, es posible que veas un mensaje como el siguiente:

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

Solución alternativa:

Sigue estos pasos para inhabilitar la comprobación previa:

kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

Borra el trabajo artifact-signature-verification-*** que falló.
Espera hasta que se complete la actualización de la raíz.
Opcional: Habilita la verificación previa al vuelo si el entorno se actualizó a la versión 1.13.4 o posterior.

Una vez que el controlador esté en la versión 1.13.4, las actualizaciones no deberían tener este problema.

La actualización de la organización del arrendatario falla en la etapa de comprobación previa con `ErrImagePull`

Versiones: 1.13.3

Síntomas: La actualización de la organización del arrendatario falla en la etapa de verificación previa con ErrImagePull para el pod de validación de paquetes. Es posible que veas un mensaje como este:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Los Pods muestran un error de ImagePullBackOff:

kubectl describe po -n package-validation-system POD_NAME

Se muestra un error de extracción de imágenes, como el siguiente ejemplo:

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

Solución alternativa:

Omitir las comprobaciones previas:

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

No se pudo encontrar `serviceaccount` durante la actualización de la organización raíz

Versiones: 1.13.8 y 1.13.9

Síntomas: Durante la actualización a la versión 1.13.8, falla la implementación de addon para los RBAC si se realizaron actualizaciones anteriores y ya existen complementos. Los síntomas pueden estar en una de las siguientes etapas:

Verificaciones previas o posteriores al vuelo
Cualquier etapa que involucre una tarea de actualización y el mensaje indique que el trabajo se está ejecutando, aunque la tarea esté atascada. El mensaje status.conditions indica que el trabajo se está ejecutando durante mucho tiempo, lo que indica que hay un problema.

Para verificar si hay un error en la verificación previa a la actualización, consulta el estado del objeto OrganizationUpgrade correspondiente a la organización que se está actualizando:

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

Si el trabajo falla en PreflightCheck, es posible que muestre un error como este o un mensaje de UpgradeCheckRBACDeploymentInProgress:

  - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

Si el trabajo falla en la etapa de Anthos Bare Metal (ABM) en la que se ejecuta el trabajo de la tarea, se mostrará el siguiente resultado:

- Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

Si la falla se produce en las verificaciones, falla el CR de upgradecheckrequest:

kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

El resultado podría verse como este ejemplo:

NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

Si el error se produce en las tareas, falla la CR de upgradetaskrequests:

kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

El resultado podría verse como este ejemplo:

NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

Si el error indica un problema de RBAC en la búsqueda de una cuenta de servicio, verifica si se implementó un complemento anterior:

Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

Solución alternativa:

Comprueba si se implementó un complemento de versión anterior:

  Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

Obtén los complementos a priori que existen para el mismo componente, upgrade-task-mz para la tarea:

kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

Borra este complemento:

kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

Después de borrar el complemento, también borra el objeto upgradetaskrequest o upgradecheckrequest correspondiente. Se volverá a crear.
```
kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc
```
Sigue supervisando el upgradetaskrequest, el upgradecheckrequest o el trabajo correspondiente que se crearon recientemente.

La actualización falla en `shared-service-cluster upgrade`

Versiones: 1.13.3

Síntomas: La actualización de Anthos Bare Metal se detiene en una o más máquinas de metal desnudo. Todas las demás máquinas físicas se actualizaron correctamente o aún no se inició la actualización. Una máquina física está en modo de mantenimiento, pero sigue mostrando la versión anterior en los campos VERSIÓN DE ABM ACTUAL y VERSIÓN DE ABM DESEADA.

Sigue Anthos Bare Metal para obtener el estado baremetalmachine y los detalles del clúster:

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

Resultado esperado:

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

Resultado esperado:

true

Solución alternativa:

Quita la máquina del inventario del modo de mantenimiento:

export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

Espera a que la máquina de inventario salga del modo de mantenimiento. Este proceso puede tardar hasta 10 minutos.

kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

Supervisa las baremetalmachines para asegurarte de que la máquina vea la actualización de la versión de ABM seleccionada.
```
kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}
```

No se pudo instalar el complemento `system-dashboards`

Versiones: 1.13.5

Síntomas: La actualización de 1.12.4 a 1.13.5 falla en la actualización del complemento system-dashboards:

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

Solución alternativa: Sigue los pasos del manual de ejecución OCLCM-R0122.

`NodeUpgradeTask` CR is stuck at the `NodeOSInPlaceUpgradePostProcessingCompleted` condition

Versiones: 1.13.5

Síntomas: Durante la actualización a la versión 1.13.5, la CR de NodeUpgradeTask se detiene en la condición NodeOSInPlaceUpgradePostProcessingCompleted.

Comprueba si se completó el trabajo de os-artifact-collector correspondiente. Si el trabajo se detiene durante muchas horas, se muestra el siguiente mensaje:

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Solución alternativa:

Borra el trabajo o el pod para forzar el reintento.

La distribución de imágenes falla durante una actualización

Versiones: 1.13.5

Síntomas: La distribución de imágenes falla durante una actualización de 1.12.4 a 1.13.x:

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

Verifica los Pods de obj-proxy en gpc-system de la organización para ver que falla la verificación del certificado:

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

Solución alternativa:

Reinicia el pod de obj-proxy con KUBECONFIG de la organización en la que falla:

export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

Verifica los registros de obj-proxy:

kubectl get pods -n gpc-system | grep obj-proxy

El resultado esperado es el siguiente:

obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

Verifica los registros de los Pods disponibles, por ejemplo:
```
kubectl logs obj-proxy-gdgzp -n gpc-system
```
Los trabajos de distribución de imágenes deberían completarse después de aplicar la solución alternativa.

El nodo falla durante la actualización del clúster de usuario

Versiones: 1.13.3

Síntomas: Un trabajo que se ejecuta en un nodo falla durante la actualización del clúster de usuario y muestra un mensaje de error como el siguiente:

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

Accede al nodo y verifica si la partición está llena:

df -h /

El resultado podría verse como este ejemplo:

Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

Comprueba si /etc/kubernetes/tmp usa una gran cantidad de espacio: du -s /etc/kubernetes/tmp. Este problema se produce cuando Kubernetes crea más copias de seguridad de lo habitual.

Solución alternativa:

Borra todas las copias de seguridad en rm -f /etc/kubernetes/tmp/*:
```
df -h /
```
El resultado podría verse como este ejemplo:
```
Filesystem                  Size  Used Avail Use% Mounted on
/dev/m
```

Se está recreando la actualización del administrador raíz y falla en las verificaciones previas

Versiones: 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9

Síntoma: La actualización de la organización raíz falla en la verificación previa, por ejemplo:

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

El clúster de administrador raíz y el kubeapiserver para el administrador raíz se actualizaron a la versión de ABM elegida.

Ejemplo:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

Ejemplo de salida para kubectl describe kubeapiserver root-admin -n root:

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

Ejemplo de salida para kubectl get cluster root-admin -n root:

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

Solución alternativa

Aplica la omisión de la verificación previa para continuar con la actualización:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

Los espacios de nombres `platform-obs-obs-system` o `platform-obs` se atascan en el estado de finalización

Versiones: 1.13.5

Síntomas: Los complementos no se implementan durante la actualización o el inicio, y muestran un mensaje de error como el siguiente:

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

Se muestra el siguiente resultado:

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

Si los estados DEPLOYED o READY muestran false o están en blanco, verifica los complementos respectivos para ver si hay errores, por ejemplo:

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

Se muestra el siguiente resultado:

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

El complemento se bloqueó porque intentó crear contenido en los espacios de nombres que se están borrando. Este bloqueo persiste, ya que también se bloquea la eliminación del espacio de nombres.

Solución alternativa:

Antes de comenzar una actualización, anota los proyectos para evitar que se borren:

export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

Se muestra el siguiente resultado:

project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

Si el entorno ya presenta los síntomas descritos anteriormente, sigue esta solución alternativa:

La eliminación del espacio de nombres está bloqueada debido a recursos con finalizadores. Para continuar con el borrado, quita los finalizadores con la secuencia de comandos proporcionada:

  export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

Espera a que se borre el recurso. Después de ejecutar la secuencia de comandos, borra los recursos y los espacios de nombres de finalización. Es posible que debas volver a ejecutar la secuencia de comandos si el espacio de nombres sigue atascado en el estado de finalización. Una vez que se termine, el espacio de nombres se volverá a crear automáticamente. Verifica que los espacios de nombres se hayan recreado y estén en estado ACTIVE:
```
  export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system
```
Se muestra el siguiente resultado:
```
  NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s
```
Con los espacios de nombres activos, los complementos que estaban atascados deberían implementarse en unos minutos. Verifica que sus estados DEPLOYED y READY ahora sean verdaderos:
```
  export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards
```
Se muestra el siguiente resultado:
```
  NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998
```

El UPORC se bloquea en bucle en el clúster de KIND durante el arranque

Versiones: 1.13.x

Síntomas: El bucle de fallas de la Deployment uporc-root-backend-controller en el espacio de nombres uporc-system en el clúster de KIND.

Solución alternativa:

Comprueba si coinciden los objetos ComponentGroupReleaseMetadata y ReleaseMetadata:
```
export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata
```
Si los objetos coinciden, no se necesita ninguna solución alternativa.
Si los objetos no coinciden, comunícate con el equipo de UPORC para obtener ayuda, ya que esto puede indicar otros problemas subyacentes.

No se pudieron actualizar los nodos

Versiones: 1.13.6

Síntomas: No se pudo actualizar el nodo en NodeOSInPlaceUpgradeCompleted.

Verifica los registros de los trabajos de os-upgrade ospolicy.
Si el registro incluye un error que sugiere que el archivo de configuración está dañado, ingresa a la máquina del nodo y verifica el contenido del archivo de forma manual para ver si está dañado. Es posible que el error de registro mencione el código de error configparser.DuplicateOptionError y el archivo /etc/yum.repos.d/gdch.repo.

Solución: Solo si confirmaste que el archivo está dañado, borra manualmente el archivo /etc/yum.repos.d/gdch.repo dañado en el nodo que no funciona.

El trabajo de Ansible para la actualización vuelve a generar el archivo automáticamente como parte del playbook de Ansible.

### NodeUpgradeTask La CR está atascada en la condición NodeOSInPlaceUpgradePostProcessingCompleted

Versiones: 1.13.5

Síntomas: Durante la actualización a la versión 1.13.5, la CR de NodeUpgradeTask se detiene en la condición NodeOSInPlaceUpgradePostProcessingCompleted.

Comprueba si se completó el trabajo de os-artifact-collector correspondiente. Si el trabajo se detiene durante muchas horas, se muestra el siguiente mensaje:

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Solución alternativa:

Borra el trabajo o el pod para forzar el reintento.

`NodeUpgradeTask` CR is stuck at the `NodeBIOSFirmwareUpgradeCompleted` condition

Versiones: 1.13.5

Síntomas: Durante la actualización a la versión 1.13.5, la CR de NodeUpgradeTask se detiene en la condición NodeBIOSFirmwareUpgradeCompleted.

Verifica si la condición NodeBIOSFirmwareUpgradeCompleted correspondiente está atascada con la siguiente condición que se muestra:

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

Solución alternativa:

En la CR NodeUpgrade, edita manualmente "U30 v3.20 (05/29/2024)" y cámbialo a "U30 v3.20 (05/27/2024)".

La actualización del clúster está bloqueada porque un nodo no pudo ingresar en el modo de mantenimiento.

Versiones: 1.13.5, 1.13.6 y 1.13.7

Síntomas: La actualización del clúster (clúster de administrador de la organización, del sistema o de usuario) se bloquea porque un nodo no puede ingresar en el modo de mantenimiento.

El clúster muestra MaintenanceMode establecido en true, pero Status se bloquea en false cuando se ejecuta lo siguiente:

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

Se muestra el siguiente resultado:

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

Solución alternativa:

Establece KUBECONFIG en el archivo kubeconfig del clúster que contiene el nodo que no se está drenando. El clúster puede ser el clúster de usuario o un clúster de servicios compartidos.

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

Tiempo de espera persistente durante el `organizationupgrade` raíz inicial

Versiones: 1.13.3

Síntomas: Si la anotación de ignorar el período de mantenimiento está presente durante una actualización de la organización, el CR de organizationupgrade se parchea de forma repetida, lo que restablece el progreso.

Solución alternativa:

Pausa el subcomponente rm-org y reduce la escala vertical de las réplicas de rm-org-backend-controller.

Si no se declara el alias, ejecuta el siguiente comando:

alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

Pausa el subcomponente y reduce la implementación de rm-org:

kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

Una vez que se complete la actualización del clúster, reduce la implementación:

kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

El subcomponente `obj-syslog-server` no supera la conciliación en la organización raíz

Versiones: 1.13.3, 1.13.4, 1.13.5, 1.13.6

Síntomas: Durante la actualización a la versión 1.13.x, se detecta que el subcomponente obj-syslog-server se encuentra en un estado ReconciliationError:

root        obj-syslog-server     ReconciliationError

con una condición similar a la siguiente:

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

Es posible que veas que el Pod, syslog-server-abcdefg-wxyz, está en estado CrashLoopBackOff con el siguiente error:

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

Solución alternativa:

Para que el subcomponente vuelva a un estado en buen estado, quita el volumeMounts innecesario.

Edita la implementación actual:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

kubectl edit deployments syslog-server -n istio-system

Quita los volumeMounts que no sean necesarios en el spec.containers.volumeMounts. Quita las siguientes rutas de acceso de la unidad de montaje:

    - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

Aplica los cambios y el subcomponente volverá a ReconciliationCompleted después de que se apliquen los cambios.

La actualización de ABM o del nodo se detuvo en `maintenanceMode false`

Versiones: 1.13.4

Síntomas: El nodo se detiene en la actualización del clúster de AnthosBaremetal y no ingresa en el modo de mantenimiento.

Verifica el objeto baremetalmachine en un nodo del clúster de servicio, por ejemplo:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

Solución alternativa:

Reinicia anthos-cluster-operator para propagar BMM.MaintenanceMode:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

Falla la actualización del complemento atat-webhooks para la organización del arrendatario

Versiones: 1.13.5

Síntomas: La actualización del complemento atat-webhooks no se recupera:

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Es posible que veas un mensaje como este:

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

Verifica los Pods de atat-webhooks-parameters-*****:

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Es posible que veas un error como este:

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

Solución alternativa:

Crea una copia de la cartera actual:

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

Actualiza portfolio-org-1 Pop End Date a una fecha futura:
```
kubectl delete portfolios -n atat-system portfolio-org-1
```
Si este comando deja de responder, borra la condición .Metadata.Finalizers de la cartera activa antes de borrar la cartera. La condición podría verse de la siguiente manera:
```
│     portfolio.finalizers.atat.config.google.com 
```
Vuelve a aplicar el archivo YAML copiado:
```
kubectl apply -f portfolio-org-1
```
Verifica las fechas para asegurarte de que tanto las carteras como el mapa de configuración estén actualizados.
Si el trabajo no se recupera, borra el trabajo atat-webhooks-parameters que falló y se recuperará. Espera a que se complete:
```
kubectl delete jobs -n org-1 atat-webhooks-parameters
```

La verificación previa al vuelo o de actualización falla debido a errores de `DeadlineExceeded` o `BackoffLimitExceeded`.

Versiones: 1.13.8

Síntomas:

Durante la actualización de la versión 1.13.7 a la 1.13.8, las verificaciones posteriores al vuelo siguen en estado pendiente y muestran errores de DeadlineExceeded o BackoffLimitExceeded.

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

Solución alternativa:

Identifica dónde fallan los trabajos:

Verifica si los trabajos fallan durante las verificaciones previas o posteriores al vuelo:

kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

Comprueba si los trabajos fallan durante la actualización:

kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

Borra los trabajos:

kubectl delete jobs -n gpc-system CHECK_NAME

Las verificaciones de actualización incluyen resultados irrelevantes para el nivel de verificación

Versiones: 1.13.x

Síntomas:

Es posible que las verificaciones de actualización de la organización fallen debido a que se incluyeron incorrectamente resultados de otros niveles. Por ejemplo, las verificaciones de la organización raíz pueden mostrar resultados de la organización del arrendatario, o las verificaciones de la organización del arrendatario pueden mostrar resultados del clúster de usuarios.

Ejemplo de registros de errores para las verificaciones de la organización raíz:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

Solución alternativa:

Omite por completo las comprobaciones previas o posteriores al vuelo con el siguiente comando:

Verificación previa:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Después del vuelo:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

Las APIs entrenadas previamente muestran un estado `Enabling` en la interfaz de usuario.

Versiones: 1.13.1

Síntomas: MonitoringTarget muestra un estado Not Ready cuando se crean clústeres de usuarios, lo que hace que las APIs previamente entrenadas muestren continuamente un estado Enabling en la interfaz de usuario.

Solución alternativa:

Abre el menú en tu navegador Chrome (ícono de tres puntos).
Haz clic en Más herramientas > Herramientas para desarrolladores para abrir la consola.
Haz clic en la pestaña Red de la consola.
Busca las solicitudes de ai-service-status.
Haz clic en la pestaña Response en una solicitud ai-service-status para mostrar el contenido de esa solicitud.
Verifica que todo se vea listo, excepto los componentes MonitoringTarget y LoggingTarget.

Falla la función de la API `streaming_recognize` previamente entrenada de Speech-to-Text

Versiones: 1.13.3

Síntomas: Cuando se llama a la función de la API preentrenada streaming_recognize de Speech-to-Text, un problema con la biblioteca cliente genera un mensaje de error 400 similar al siguiente:

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

Solución alternativa: Usa la siguiente secuencia de comandos de Python para permitir que funcione la función streaming_recognize:

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

Reemplaza lo siguiente:

ENDPOINT: Es el extremo de Speech-to-Text. Para obtener más información, consulta los estados y los extremos de los servicios.
APPLICATION_DEFAULT_CREDENTIALS_FILENAME: Es el nombre del archivo JSON que contiene las claves de la cuenta de servicio que creaste en el proyecto, como my-service-key.json.
CERT_NAME: el nombre del archivo del certificado de la autoridad certificadora (CA), como org-1-trust-bundle-ca.cert. Para obtener más información, consulta Cómo generar el archivo de certificado de CA del paquete de confianza en un entorno de desarrollo.

La secuencia de comandos de Python introduce las siguientes diferencias entre las funciones streaming_recognize y recognize para que funcione la solución alternativa para streaming_recognize:

Línea 4: Una instrucción import adicional en comparación con la secuencia de comandos recognize (from google.cloud.speech_v1p1beta1.services.speech import client).
Línea 18: El cliente se devuelve con client.SpeechClient() en lugar de speech_v1p1beta1.SpeechClient().

No se pueden inicializar el pod y el servicio de frontend de Translation

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

Síntomas: Durante las actualizaciones, se vuelve a crear el clúster de la base de datos de Translation, lo que provoca que el secreto del clúster del sistema de ODS secret-store esté desactualizado y no sincronizado. Por este motivo, el pod y el servicio de frontend de Translation no se inicializan.

Solución alternativa:

Borra el secreto en el clúster del sistema:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

Reemplaza SYSTEM_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig en el clúster del sistema.

Un controlador recrea el secreto automáticamente y lo vuelve a sincronizar con el clúster de la BD.

No se admite el sondeo del estado del trabajo para la API de `batchTranslateDocument`

Versiones: 1.13.3

Síntomas: Vertex AI no admite las operaciones GET y LIST en las APIs del servicio de Translation. Si llamas a la API de Translation BatchTranslateDocument, se muestra una operación de larga duración similar al siguiente ejemplo:

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Este problema se debe a una limitación de la APIP (autorización) que te impide llamar al extremo directamente. Los extremos no admiten el sondeo del estado del trabajo, y no puedes realizar operaciones de GET en la operación de larga duración debido a la limitación de la APIP.

Solución alternativa: Como operador de aplicaciones (AO), revisa el estado del trabajo consultando tu carpeta s3_destination con regularidad y busca un archivo de salida del trabajo creado recientemente. Si la carpeta contiene el archivo de salida, el trabajo finalizó correctamente.

Las solicitudes de `batchTranslateDocument` pueden causar problemas de rendimiento

Versiones: 1.13.3

Síntomas: El servicio de traducción de documentos por lotes lee uno o varios archivos de entrada del usuario y escribe los archivos de salida traducidos y de procesamiento temporales en StorageGRID. Se crea un nuevo cliente de curl para cada acción de lectura y escritura, ya que no se puede reutilizar el cliente.

Los clientes de curl de S3 en el archivo binario son de uso único, lo que significa que cada cliente solo puede realizar una sola acción de lectura y escritura en los buckets de StorageGRID. Por lo tanto, se crea un nuevo cliente curl cada vez que se establece la comunicación con el cliente de StorageGRID desde el servidor batchTranslateDocument para leer y escribir archivos en buckets.

Sin embargo, esto no es óptimo para los clientes de curl. Esto podría provocar los siguientes problemas:

Disminución del rendimiento: Aumento de la latencia y disminución de la capacidad de procesamiento
Agotamiento de recursos: Sobrecarga de memoria y CPU, y agotamiento de sockets
Sobrecarga del servidor: Límite de frecuencia o regulación

La consola de GDC muestra un estado incoherente después de habilitar las APIs previamente entrenadas

Versiones: 1.13.3

Síntomas: Cuando habilitas por primera vez las APIs previamente entrenadas, es posible que la consola de GDC muestre un estado incoherente después de unos minutos para el servicio habilitado. La consola de GDC vuelve a cambiar el estado de Enabling a Disabled y vuelve a mostrar el botón Habilitar en la interfaz de usuario, incluso si el servicio se está habilitando.

Solución: El estado se vuelve coherente después de unos minutos y el servicio refleja su estado correcto.

Para verificar el estado del servicio, abre la pestaña Red en la consola del navegador y verifica el estado de la solicitud ai-service-status. La carga útil debe mostrar que el operador de L2 está habilitado.

Las solicitudes de traducción con más de 250 caracteres fallan en los pods de `translation-prediction-server`

Versiones: 1.13.3

Síntomas: Cuando envías solicitudes de traducción con aproximadamente 250 caracteres o más (incluidas las solicitudes de traducción de documentos), es posible que los Pods de translation-prediction-0 o translation-prediction-1 fallen, lo que requiere que se vuelva a cargar el modelo. La recarga del modelo se realiza automáticamente y este proceso puede tardar alrededor de 30 minutos en resolverse.

Este problema se debe a una limitación de los contenedores de Translation.

Solución alternativa: Divide las solicitudes de traducción para que tengan menos de 250 caracteres. Un rango de entre 200 y 250 caracteres es seguro para todos los idiomas. No es necesario realizar ninguna otra acción para mitigar el problema si una solicitud larga falla en los Pods.

`GPUAllocation` para el clúster de servicio compartido no está configurado correctamente

Versiones: 1.13.3

Síntomas: No se pueden programar las cargas de trabajo de Vertex AI debido a la falta de recursos de GPU suficientes. Por ejemplo, si no puedes ver ni habilitar los extremos de servicio de Vertex AI, es posible que se deba a la falta de recursos de GPU suficientes.

Este problema de recursos puede deberse a que algunos de los recursos GPUAllocation ubicados dentro del clúster de servicio compartido no tienen la siguiente anotación:

processed: "true"

Solución alternativa:

Sigue IAM-R0004 para generar el archivo kubeconfig para g-ORG_NAME-shared-service-cluster.

Enumera todas las asignaciones de GPU en el clúster de servicio que no tienen la anotación processed: "true":

kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

El resultado es similar a este:

zi-ad-bm08

Para el recurso GPUAllocation que no está asignado, ábrelo en un editor:
```
kubectl edit gpuallocation -n vm-system NODE_NAME
```

Edita la asignación de GPU según la cantidad total de asignaciones de GPU presentes en el clúster de servicio:

Si solo hay un recurso personalizado de asignación de GPU, agrégale la anotación processed: "true" y modifica su especificación para que sea como la siguiente:

annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

Si hay dos recursos personalizados de asignación de GPU, busca el que no tenga la anotación processed: "true", agrégale la anotación processed: "true" y modifica su especificación para que sea como la siguiente:

annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

Si hay cuatro recursos personalizados de asignación de GPU, busca el que no tenga la anotación processed: "true", agrégale la anotación processed: "true" y modifica su especificación para que sea como la siguiente:
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0
```

Guarda los cambios en el recurso personalizado GPUAllocation y confirma que su estado de asignación se actualizó a true:

kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

El resultado es similar a este:

NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

Cuando se actualiza de la versión 1.9.x a la 1.13.3, el controlador de OCLCM muestra errores

Versiones: 1.13.3

Síntomas: Cuando se actualiza de la versión 1.9.x a la 1.13.3, es posible que el controlador de Operable Component Lifecycle Management (OCLCM) para los subcomponentes de Vertex AI muestre errores. Este problema se debe a un error con el trabajo del complemento ai_platform. Los errores que recibes durante la actualización indican que OCLCM no puede transferir la propiedad de estos componentes de Vertex AI.

Los siguientes son los componentes de Vertex AI afectados en el clúster de administrador de la organización:

Nombre	Espacio de nombres
`aip-l1operator-deployment`	`ai-system`
`aip-l2operator-deployment`	`ai-system`
`aip-web-plugin-frontend`	`ai-system`
`aip-web-plugin-backend`	`ai-system`
`aip-l1operator-sa`	`ai-system`
`aip-l2operator-sa`	`ai-system`
`aip-web-plugin-sa`	`ai-system`
`aip-l1operator-role`	N/A
`aip-l2operator-role`	N/A
`aip-web-plugin-role`	N/A
`aip-l1operator-rolebinding`	N/A
`aip-l2operator-rolebinding`	N/A
`aip-web-plugin-rolebinding`	N/A
`aip-l1operator-log`	`ai-system`
`aip-l2operator-log`	`ai-system`
`aip-web-plugin-frontend-log`	`ai-system`
`aip-web-plugin-backend-log`	`ai-system`
`log-rule-aipl-a004`	`platform-obs`
`mon-rule-aipl-a0001`	`platform-obs`
`mon-rule-aipl-a0003`	`platform-obs`
`aip-l1operator-mon`	`ai-system`
`aip-l1operator-mon-cm`	`ai-system`
`aip-l2operator-mon`	`ai-system`
`aip-l2operator-mon-cm`	`ai-system`
`aip-l1operator-webhook-svc`	`ai-system`
`aip-web-plugin-frontend-svc`	`ai-system`
`aip-web-plugin-backend-svc`	`ai-system`
`aip-web-plugin-frontend-virtualsvc`	`ai-system`
`aip-web-plugin-backend-virtualsvc`	`ai-system`
`aip-l1operator-selfsigned-issuer`	`ai-system`
`aip-l1operator-serving-cert`	`ai-system`
`aip-l1operator-validating-webhook`	`ai-system`
`aip-l1operator-mutating-webhook`	`ai-system`

Solución alternativa: Para resolver este problema, debes quitar manualmente los componentes afectados de Vertex AI del clúster de administrador de la organización. Luego, la nueva versión de Vertex AI basada en OCLCM los reinstala.

Quita manualmente los componentes afectados de Vertex AI en el clúster de administrador de la organización:

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

Reemplaza lo siguiente:

ORG_ADMIN_CLUSTER_KUBECONFIG: Es la ruta al archivo kubeconfig en el clúster de administrador de la organización.
NAMESPACE: Es el espacio de nombres del componente de Vertex AI que deseas quitar. Si el componente no tiene un espacio de nombres, quita -n NAMESPACE del comando.
COMPONENT_NAME: Es el nombre del componente de Vertex AI que deseas quitar.

En el siguiente ejemplo, se muestra cómo quitar el componente aip-l1operator-deployment que existe en el espacio de nombres ai-system en el clúster de administrador de la organización:

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

Es posible que las solicitudes de traducción generen el código de error `RESOURCE_EXHAUSTED`

Versiones: 1.13.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.13.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 SubcomponentOverride en un archivo YAML llamado vai-translation.yaml con el parámetro operable enableRAG establecido en true:

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

Reemplaza ORG_ADMIN_NAMESPACE por el espacio de nombres del clúster del administrador de la organización.

Aplica el recurso personalizado SubcomponentOverride al clúster de administrador de la organización:
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f vai-translation.yaml
```
Reemplaza ORG_ADMIN_KUBECONFIG por la ruta de acceso al archivo kubeconfig en el clúster de administrador de la organización.

Los servicios previamente entrenados de Vertex AI no están disponibles

Versiones: 1.13.7 y 1.13.9

Síntomas: Los servicios de OCR y Traducción de Vertex AI no se inician debido a problemas de programación de Kubernetes. Es posible que veas una advertencia como esta en los registros:

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

Solución alternativa: Agrega más nodos trabajadores al grupo predeterminado y expulsa los pods en los nodos de GPU para que se puedan programar las cargas de trabajo de IA.

Máquinas virtuales

Falla la importación de imágenes BYO para imágenes qcow2 y sin procesar

Versiones: 1.13.1 y 1.13.3

Síntomas: Cuando se importan imágenes de VM locales con la CLI de gdcloud compute images import, el estado de importación se queda atascado en WaitingForTranslationVM o ImportJobNotCreated. Esto se debe a que el disco temporal creado para la traducción o la importación usa el tamaño exacto de la imagen qcow2/sin procesar, pero LUKS agrega una sobrecarga de unos pocos MiB que hace que falle el aprovisionamiento del disco.

Solución alternativa:

Crea un nuevo VirtualMachineImageImport de forma manual con el mismo nombre de imagen, pero con un spec.minimumDiskSize más grande.

Por ejemplo, si este fue el comando que se usó para importar la imagen:

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

Si el VirtualMachineImageImport original creado automáticamente por la CLI tiene minimumDiskSize como X Gi, crea uno nuevo con X + 1 Gi. El valor se basa en el tamaño de la imagen que se importa. En el caso de qcow2, sería el tamaño virtual. Por ejemplo, 20 Gi debería reemplazarse por 21 Gi.

Reemplaza los valores de marcador de posición según la forma en que se llamó a la CLI.

Busca el VirtualMachineImageImport:
```
kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml
```
Si el objeto no está presente, vuelve a activar el comando gdcloud compute images import .... Una vez que el resultado de la consola cambie de Uploading image to .. a Image import has started for ..., presiona Ctrl + C para que la imagen local se suba al almacenamiento de objetos y se conserve el VirtualMachineImageImport como referencia para crear uno nuevo.

Crea un nuevo VirtualMachineImageImport con un minimumDiskSize más grande:

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

Falla el aprovisionamiento de un disco a partir de una imagen

Versiones: 1.13.1 y 1.13.3

Síntomas: Cuando se aprovisiona un disco a partir de una imagen personalizada, es posible que el minimumDiskSize esté demasiado cerca del tamaño virtual, lo que provoca que falle el aprovisionamiento del disco. El disco de la VM está en estado pendiente, pero nunca se aprovisiona.

Solución alternativa: Crea un disco nuevo de forma manual con un spec.minimumDiskSize más grande.

El complemento de dispositivo NVIDIA `DaemonSet` falla cuando un clúster tiene GPUs

Versiones: 1.13.3

Síntomas: El complemento de dispositivo NVIDIA DaemonSet falla con el mensaje driver rpc error en los nodos del clúster con GPUs:

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig en el clúster.

Obtendrás un resultado similar al siguiente ejemplo:

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

Este problema hace que las GPUs no estén disponibles para las máquinas virtuales (VM) y los Pods. Las implicaciones se basan en los siguientes tipos de clústeres:

Clúster del sistema: No se crea el recurso personalizado GPUAllocation para ese nodo de metal desnudo, y las GPUs de ese nodo no se configuran en el modo de VM para que las consuman el servicio y el clúster de usuario. Consulta la solución alternativa para el clúster del sistema para resolver este problema.
Clúster de servicio o de usuario: No se crea el recurso personalizado GPUAllocation para ese nodo de VM, y los Pods del clúster no pueden consumir las GPUs de ese nodo. Consulta la solución alternativa para el clúster de servicio o de usuario para resolver este problema.

Solución alternativa para el clúster del sistema:

Sigue estos pasos para resolver el problema en el clúster del sistema:

Configura la variable de entorno KUBECONFIG con la ruta de acceso al archivo kubeconfig en el clúster del sistema. Para obtener más detalles, consulta el manual IAM-R0004.
Identifica el nodo que tiene el problema:
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
El resultado debe imprimir el nombre del nodo y la dirección IP del nodo de Kubernetes.

Si hay varios nodos, ejecuta los pasos en todos ellos. En este caso, el resultado se ve como en el siguiente ejemplo:
```
Node:                 yy-ab-bm04/172.20.128.26
```
Establece la variable de entorno NODE_NAME con el nombre del nodo, por ejemplo:
```
export NODE_NAME=yy-ab-bm04
```
Establece una conexión SSH con el nodo. Para obtener más información, consulta el manual PLATAUTH-G0001.

Nota: La dirección IP del nodo de administración es diferente de la dirección IP del comando anterior. Usa la dirección IP del nodo de administración como se menciona en el manual.

Verifica que el nodo tenga GPUs:

nvidia-smi -L

El resultado debe imprimir las GPUs del nodo, como en el siguiente ejemplo:

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

Habilita el modo de persistencia en las GPUs:
```
nvidia-smi -pm 1
```
Esta acción garantiza que los controladores de NVIDIA siempre se carguen para que el complemento del dispositivo no se agote.

El resultado debe verse como el siguiente ejemplo:
```
Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.
```
Nota: El modo de persistencia está habilitado para el inicio actual. Esta acción se revierte durante el próximo reinicio. Si el problema persiste después de reiniciar el dispositivo, vuelve a realizar estos pasos.
Sal de la sesión de SSH:
```
exit
```

Verifica que el complemento del dispositivo se esté ejecutando consultando DaemonSet:

kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Verifica que el recurso personalizado GPUAllocation se haya creado y configurado en el modo de VM:

kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

El resultado debe verse como el siguiente ejemplo:

apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

Solución alternativa para el clúster de servicios o usuarios:

Sigue estos pasos para resolver el problema en el servicio o clúster:

Configura la variable de entorno KUBECONFIG con la ruta de acceso al archivo kubeconfig en el clúster de servicio o de usuario. Para obtener más detalles, consulta el manual IAM-R0004.
Identifica el nodo que tiene el problema:
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
El resultado debe imprimir el nombre del nodo y la dirección IP del nodo de Kubernetes.

Si hay varios nodos, ejecuta los pasos en todos ellos. En este caso, el resultado se ve como en el siguiente ejemplo:
```
Node:                 vm-948fa7f4/172.20.128.21
```
Establece la variable de entorno NODE_NAME con el nombre del nodo, por ejemplo:
```
export NODE_NAME=vm-948fa7f4
```
Establece una conexión SSH con el nodo. Para obtener más información, consulta el manual PLATAUTH-G0001.

Nota: La dirección IP del nodo de administración es diferente de la dirección IP del comando anterior. Usa la dirección IP del nodo de administración como se menciona en el manual.

Verifica que el nodo tenga GPUs:

nvidia-smi -L

El resultado debe imprimir las GPUs del nodo, como en el siguiente ejemplo:

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

Habilita el modo de persistencia en las GPUs:
```
nvidia-smi -pm 1
```
Esta acción garantiza que los controladores de NVIDIA siempre se carguen para que el complemento del dispositivo no se agote.

El resultado debe verse como el siguiente ejemplo:
```
Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.
```
Nota: El modo de persistencia está habilitado para el inicio actual. Esta acción se revierte durante el próximo reinicio. Si el problema persiste después de reiniciar el dispositivo, vuelve a realizar estos pasos.
Sal de la sesión de SSH:
```
exit
```

Verifica que el complemento del dispositivo se esté ejecutando consultando DaemonSet:

kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Verifica que el recurso personalizado GPUAllocation se haya creado y configurado en el modo de VM:

kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

El resultado debe verse como el siguiente ejemplo:

apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

La VM del clúster del sistema no está lista

Versiones: 1.13.3

Síntomas: La VM del clúster del sistema no está lista. Es posible que veas un mensaje como este:

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

Solución alternativa:

Busca el VirtualMachineInstance y bórralo.
Reinicia una VM nueva.

No se encontró el espacio de trabajo de los informes de volumen de datos

Versiones: 1.13.3 y 1.13.4

Síntomas: Cuando se crea un disco de VM, el volumen de datos se informa como correcto:

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

Sin embargo, un pod de importador, como importer-gdc-vm-disk-vm-ce34b8ea-disk, puede entrar en un bucle de fallas con un mensaje como el siguiente:

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

Solución alternativa: Borra el pod del importador después de confirmar que el estado del volumen de datos es Succeeded.

Las VMs en proyectos con nombres que superan los 45 caracteres permanecen en estado detenido.

Versiones: 1.13.5

Síntomas: Cuando se crea una VM, esta permanece en el estado Stopped si el nombre del proyecto tiene más de 45 caracteres.

Solución alternativa: Crea un proyecto con un nombre de no más de 45 caracteres.

Falta la asignación de GPU en el clúster de servicio

Versiones: 1.13.5

Síntomas: Falta GPUAllocation en el clúster de servicios compartidos de gpu-org. Es posible que veas un mensaje cuando obtengas las asignaciones de GPU:

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

La salida obtenida se verá así:

No resources found

Solución alternativa:

Agrega un taint al nodo de GPU:

taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

Quita el taint para permitir la programación del pod virt-launcher de la VM.

No se pudo programar la VM de trabajador del clúster de servicio compartido

Versiones: 1.13.6

Síntomas: No se pudo programar una VM de trabajador de Kubernetes debido a que no había suficientes recursos de CPU en el nodo designado, a pesar de que había GPUs disponibles. Es posible que veas un evento como este:

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

Solución alternativa:

Detén manualmente las VMs que no tengan GPU para liberar recursos de CPU.
Después de programar la VM pendiente, inicia las VMs que no son de GPU.

Problemas conocidos de Google Distributed Cloud aislado 1.13.x Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Artifact Registry

Error de conciliación del subcomponente sar-failoverregistry

Copia de seguridad y restablecimiento

Las instantáneas fallan debido a la falta de espacio en el volumen

Los pods del agente y del plano de control se reinician debido a la falta de memoria

Falla la copia de seguridad de la instantánea de PVC

Restablecimiento desde una copia de seguridad que no es compatible con la cuota de SVM

Facturación

Las métricas de facturación no se muestran correctamente en el panel de facturación

El usuario no puede crear BillingAccountBinding debido a errores en el webhook de validación

Almacenamiento en bloque

Los Pods de Grafana están bloqueados en el estado Init debido a errores de montaje de volumen.

Los pods del launcher de la máquina virtual no pueden asignar volúmenes

Fallas relacionadas con el almacenamiento

Volúmenes persistentes creados con un tamaño incorrecto

No se puede borrar la máquina virtual de almacenamiento

La desactivación de la organización no limpia los recursos

Error de conciliación de eliminación

La actualización de Bare Metal se detuvo

Error de conexión múltiple de Trident

Error en la configuración de IPsec

No se creó la máquina virtual de almacenamiento

No se pueden conciliar las redes de interclúster de almacenamiento

Administración de clústeres

El trabajo de machine-init falla durante el aprovisionamiento del clúster

No hay conectividad del clúster de servicio al bucket de almacenamiento de objetos

Falla la comprobación previa

Falla la creación del grupo de nodo trabajador del clúster de usuario

Es posible que los clústeres de usuarios, cuando se vuelvan a crear, queden atascados en el proceso de conciliación debido a una limpieza inadecuada.

Servicio de bases de datos

El clon de la base de datos de AlloyDB Omni se bloqueó

La aplicación de IOPS afecta el rendimiento del almacenamiento

Error de conciliación al actualizar el subcomponente dbs-fleet

Falla en la creación del DBCluster

DNS

Las DNSSEC deben desactivarse de forma explícita en resolved.conf

Servicio de puerto

No se pudo crear el servicio de Harbor

Borrar instancias de Harbor no borra los duplicados de registro asociados

Módulo de seguridad de hardware

Aún se pueden detectar las licencias de prueba desactivadas del HSM

Pérdida del descriptor de archivos del daemon del host del HSM

Vencieron los certificados del HSM

Administración de identidades y accesos

Los Pods gatekeeper-audit en el espacio de nombres opa-system se reinician con frecuencia.

Infraestructura como código (IaC)

El riesgo de creación excesiva de tokens de GitLab llena las bases de datos de GitLab

Sistema de administración de claves (KMS)

Si cambias el tipo de clave raíz, se invalidarán todas las claves existentes.

kms-rootkey-controller CrashLoopBackOff debido a OOMKILL

Logging

El registrador de auditoría del almacenamiento de objetos no puede resolver el host de DNS

El registrador de HaaS muestra errores en el clúster de administrador raíz

Falla el registrador de Santricity

Los registros de Logging Target se envían al proyecto incorrecto

El PA no puede ver los registros de auditoría del espacio de nombres de la plataforma.

Los Pods no pueden inicializar contenedores

Marketplace

Falla la extracción de imágenes de Prisma Cloud

Supervisión

Se creó una gran cantidad de alertas en ServiceNow

Se crearon varias alertas duplicadas en ServiceNow

No se pueden ver las métricas de Vertex AI

Error de conciliación en mon-cortex

El pod metrics-server-exporter del clúster del sistema está en un bucle de fallas

Ignora los mensajes de error de conciliación de ObservabilityPipeline

Se restablece el ConfigMap mon-prober-backend-prometheus-config

Bucle de fallas de OOMKilled del componente de puerta de enlace de la tienda de Cortex

Tiempo de espera para la extracción de la imagen del proxy de métricas del plano de control de Kube en el clúster de usuario

Un aumento en el WAL hace que Prometheus use mucha memoria

Arranque multizona

Faltan roles de clúster

Recurso Bootstrap incompatible

No se crea el recurso GlobalAPIZone en la API global.

Redes

La red de nodos de almacenamiento de objetos no funciona

No se puede acceder al nodo

PodCIDR no se asigna a los nodos, aunque se cree ClusterCIDRConfig

Desvío de NTP

Problemas conocidos de Google Distributed Cloud aislado 1.13.x

Error de conciliación del subcomponente `sar-failoverregistry`

El usuario no puede crear `BillingAccountBinding` debido a errores en el webhook de validación

Los Pods de Grafana están bloqueados en el estado `Init` debido a errores de montaje de volumen.

El trabajo de `machine-init` falla durante el aprovisionamiento del clúster

Error de conciliación al actualizar el subcomponente `dbs-fleet`

Los Pods `gatekeeper-audit` en el espacio de nombres `opa-system` se reinician con frecuencia.

`kms-rootkey-controller` `CrashLoopBackOff` debido a `OOMKILL`

Error de conciliación en `mon-cortex`

El pod `metrics-server-exporter` del clúster del sistema está en un bucle de fallas

Ignora los mensajes de error de conciliación de `ObservabilityPipeline`

Se restablece el ConfigMap `mon-prober-backend-prometheus-config`

Recurso `Bootstrap` incompatible

No se crea el recurso `GlobalAPIZone` en la API global.

`PodCIDR` no se asigna a los nodos, aunque se cree `ClusterCIDRConfig`

`ObjectStorageStorageNodeReconciler` informes `maintenance.gdu.gdu_server_locked`

Pods atascados en el estado `init`

`bm-system-machine-preflight-check` Falla el trabajo de Ansible para un nodo de VM o de metal desnudo

Los Pods están atascados en el estado `ContainerCreating`.

`bm-system` y otros trabajos atascados

No se muestra el número de versión de `storagecluster`.

`OrganizationUpgrade` se detuvo en la etapa de actualización del nodo

Aparece el error `Incorrect version of Trident` durante la actualización

La actualización falla en el subcomponente `iac-zoneselection-global`

El complemento `meta-monitoring` falla porque la ubicación de strongswan se encuentra en un directorio de tiempo de ejecución diferente.

La actualización de la organización del arrendatario falla en la etapa de comprobación previa con `ErrImagePull`

No se pudo encontrar `serviceaccount` durante la actualización de la organización raíz

La actualización falla en `shared-service-cluster upgrade`

No se pudo instalar el complemento `system-dashboards`

`NodeUpgradeTask` CR is stuck at the `NodeOSInPlaceUpgradePostProcessingCompleted` condition

Los espacios de nombres `platform-obs-obs-system` o `platform-obs` se atascan en el estado de finalización

`NodeUpgradeTask` CR is stuck at the `NodeBIOSFirmwareUpgradeCompleted` condition

Tiempo de espera persistente durante el `organizationupgrade` raíz inicial

El subcomponente `obj-syslog-server` no supera la conciliación en la organización raíz

La actualización de ABM o del nodo se detuvo en `maintenanceMode false`