Problemas conocidos de Google Distributed Cloud con air gap 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: Al crear 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 al iniciar el proceso. El mensaje de error 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:

  1. En el mismo clúster de Kubernetes que el subcomponente, enumera los servidores y confirma que cada recurso personalizado de servidor tiene una etiqueta con la clave cluster.private.gdc.goog/inventory-machine:

    kubectl get servers -n gpc-system

  2. Busca el recurso personalizado del componente que tenga un aspecto similar 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

  3. En el recurso personalizado del componente System Artifact Registry (SAR), añada el selector de etiquetas en los runtimeParameterSources servidores de sar-failover-registry:

    1. Consulta el recurso server:

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

    2. 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"

  4. Verifica que los cambios en el componente SAR del paso anterior se propagan 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 restauración

Las copias de seguridad fallan por 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 de volúmenes persistentes que puede afectar a los flujos de trabajo de las tareas de copia de seguridad periódicas. En algunos volúmenes con una alta tasa de cambios, las capturas de volumen que se toman para las copias de seguridad en curso pueden provocar que el volumen se quede sin espacio, lo que hace que pase al modo de solo lectura.

Solución alternativa: Para evitar posibles problemas en las cargas de trabajo de producción, sigue los pasos del runbook BACK-R0104. También puedes eliminar las copias de seguridad acumuladas siguiendo el manual de instrucciones BACK-R0106.

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

Versiones: todas las versiones de 1.13.x

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

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

Falla la copia de seguridad de la captura de PVC

Versiones: todas las versiones de 1.13.x

Síntomas: se han producido errores en las copias de seguridad porque se ha superado el límite de 1023 copias de ONTAP por recurso PersistentVolumeClaim (PVC).

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

  1. Actualiza el plan de copias de seguridad para que nunca se alcancen los límites. Configura un plan de copias de seguridad para que se haga una copia cada hora o reduce el deleteLockDays a tres para que el número de instantáneas no supere las 1023:

    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

    Haz los cambios siguientes:

    • LOCK_DAYS: bloquea la eliminación de la copia de seguridad durante el número de días especificado después de la creación de la copia de seguridad. Usa los siguientes valores:

      • Si el campo volumeStrategy tiene el valor LocalSnapshotOnly, usa el valor 2.
      • Si el campo volumeStrategy tiene el valor ProvisionerSpecific, usa el valor 7.

    • RETENTION_DAYS: elimina las copias de seguridad después del número de días especificado tras la creación de la copia de seguridad. Si el campo volumeStrategy tiene el valor LocalSnapshotOnly, utilice un valor inferior a 3.

  2. Para eliminar manualmente las instantáneas excesivas de tu entorno mediante comandos de eliminación de instantáneas de volumen, sigue estos pasos:

    1. Inicializa las 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

      Haz los cambios siguientes:

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

    2. NetApp ONTAP es un sistema operativo que se usa para administrar el almacenamiento de GDC. Obtener 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

    3. Lista todas las copias de seguridad 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 iniciar sesión en la máquina con la dirección IP definida por la variable MGMT_IP.

    4. Busca el PVC con el mayor número de copias de seguridad:

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

    5. Asigna al PVC el nombre de recurso que tenga un número elevado de copias de seguridad:

      export PV_NAME=

    6. Elimina la captura del recurso PVC que contenga un número elevado de capturas. El límite del número de copias de un recurso PVC es de 1023:

      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

    7. Inicia sesión en ONTAP y ejecuta estos comandos para eliminar la instantánea:

      echo $PASSWORD

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

    8. Ejecuta los comandos que se indican en el paso anterior para eliminar la instantánea. Cuando termines, cierra la sesión SSH.

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

Restaurar a partir de 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 que se proporcione la cuota de inquilino y que se implementen correctamente las restauraciones. El problema solo se produce al restaurar una copia de seguridad en un clúster de usuarios con restricciones de cuota.

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

Facturación

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

Versiones: 1.13.1

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

Solución: crea un recurso billing-monetizer MetricsProxySidecar. A continuación, ejecuta una secuencia de comandos para actualizar el metricExpression.

  1. Exporta la siguiente variable kubeconfig:

    export KUBECONFIG=KUBECONFIG_PATH

    Sustituye la variable KUBECONFIG_PATH por la ruta al archivo kubeconfig del clúster de administrador de la organización. Sigue los pasos que se indican en el manual de servicio IAM-R0101 para generar el archivo kubeconfig necesario para esta solución alternativa.

  2. Crea un recurso billing-monetizer MetricsProxySidecarpara 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

  3. Ejecuta la siguiente secuencia de comandos para actualizar el metricExpression. De esta forma, se elimina el container_name="monetizer" del skuconfig, lo que incluye lo siguiente: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 alternativa: para crear recursos de BillingAccountBinding, notifica al operador de la infraestructura y crea los recursos correspondientes mediante IaC.

Almacenamiento en bloques

Los pods de Grafana se quedan en el estado Init debido a errores de montaje de volumen.

Versiones: 1.13.3

Síntomas:

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

Solución:

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

  1. Consulta el VolumeAttachment de PVC para identificar dónde está conectado el volumen.
  2. Cordonar los Nodes del clúster que no coincidan con este valor.
  3. Elimina el Pod que falla. De esta forma, debería migrar de nuevo al Node original.

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

  1. Consulta el VolumeAttachment de PVC para identificar dónde está conectado el volumen.

  2. En Node, muestra el contenido de su archivo de seguimiento:

    cat /var/lib/trident/tracking/PVC_NAME.json

  3. Valida que el dispositivo LUKS que se encuentra en el campo devicePath de la salida del archivo de seguimiento esté cerrado. Esta ruta no debería existir en este punto:

    stat DEVICE_PATH

  4. Valida si el número de serie está asignado a algún dispositivo de multipath.

    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 nuevo valor, comprueba si la entrada multipath sigue existiendo:

      multipath -ll | grep SERIAL_HEX

    4. Si no existe, elimina el archivo de seguimiento.

    5. Si existe, verás un valor hexadecimal de serie ligeramente más largo que el que has buscado, que se llamará multipathSerial. Ejecuta lo siguiente y busca los dispositivos de bloque:

      multipath -ll MULTIPATH_SERIAL

    6. A continuación, ejecuta los siguientes comandos. El último se ejecuta de forma única para cada dispositivo de bloque:

      systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

Los pods de inicio de máquinas virtuales no pueden asignar volúmenes

Versiones: 1.13.1

Síntomas:

Puede que veas una advertencia como esta:

 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:

  1. Asegúrate de que los volúmenes y los pods estén en el mismo nodo.
  2. Busca el nodo en el que se encuentran los pods y comprueba su estado.
  3. Comprueba la conectividad de los nodos.
  4. Comprueba IPSEC.
  5. Comprueba la multipista para ver si hay un zombi.

  6. Consulta los registros de Trident para averiguar qué paso del flujo de CSI puede haber introducido este elemento zombie:

    kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main

Solución alternativa: para evitar este problema, sigue los pasos que se indican en los siguientes runbooks:

  1. Si tienes problemas con los nodos, consulta el runbook FILE-R0010.
  2. Si tienes problemas con IPSEC, consulta el runbook FILE-R0007.
  3. Si tienes problemas con LUNs zombi, consulta el runbook FILE-R0020.
  4. Si tienes problemas con los LUNs superzombies, consulta el runbook FILE-R0021.

Errores relacionados con el almacenamiento

Versiones: 1.13.1

Síntomas: los fallos relacionados con el almacenamiento se pueden identificar mediante la activación de la alerta file_block_zombie_luns_present o porque no se puede iniciar el pod debido a un problema en la llamada MountVolume que persiste durante más de un bucle de conciliación. El tiempo de espera puede ser de unos dos minutos. Si se repite el mismo error, significa que ha habido un fallo en la ruta NodeStage o NodePublish de CSI y que se necesita una solución alternativa. La única excepción es la indicación de un fallo por tiempo de espera agotado. Es posible que veas algunos errores como este:

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:

  1. Para ver si el Node que tiene el Pod se puede corregir para el error PVC, acordonar el nodo actual en el que se ha programado el pod y eliminar el Pod:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    El Pod debe programarse en un Node completamente diferente, lo que obliga a Trident a ejecutar por completo NodeStage, NodePublish, NodeUnpublish y NodeUnstage. Es posible que el volumen no se corrija de inmediato, ya que puede que aún haya sesiones abiertas para este volumen en el Node original.

  2. Una vez completado el paso anterior, quita el acordonamiento del nodo en cuestión:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. Si sigue habiendo errores, aísla todos los demás Nodes excepto aquel en el que se programó originalmente el Pod y elimina el Pod. Debería dar como resultado que Pod se inicie en el Node original, donde es posible que aún queden dispositivos.

  4. Una vez completado el paso anterior, retira el cordón de los nodos en cuestión.

  5. Como último recurso para guardar el PV y sus datos, se puede reiniciar el Node para borrar los errores de multipath, udev y devmapper en el Node. Aunque este paso es bastante arduo, es el que tiene más probabilidades de dar buenos resultados.

  6. Si las mitigaciones anteriores no resuelven el problema con el volumen, significa que los datos se han dañado y no se pueden usar. La única opción que queda para continuar con el comportamiento previsto del contenedor es eliminar los elementos PV, PVC y Pod que fallan y, a continuación, reiniciar el nodo en el que se alojaba el PV. Esta acción provoca la pérdida total de los datos que ya se hayan 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 16 MiB demasiado pequeño. Si las cargas de trabajo dependen exactamente del tamaño anunciado por un volumen persistente, la pequeña discrepancia hace que la carga de trabajo falle al ampliar o aprovisionar. Este problema es más probable que se produzca en volúmenes persistentes aprovisionados con una clase de almacenamiento standard-block que en aquellos aprovisionados con una clase de almacenamiento standard-rwo. Este problema puede producirse en volúmenes persistentes con una clase de almacenamiento standard-rwo que use el modo volumemode:block.

Solución alternativa: asigna un volumen persistente que sea al menos 16 MiB mayor de lo que se necesita.

No se puede eliminar la máquina virtual de almacenamiento

Versiones: 1.13.1

Síntomas: es posible que la StorageVirtualMachine muestre un error como este:

 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: elimina el finalizador de StorageVirtualMachines en el espacio de nombres de la organización.

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

Versiones: 1.13.1

Síntomas: al desactivar una organización, quedan algunos StorageVirtualMachines recursos, como los siguientes:

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

Solución: elimina estos recursos.

Error de conciliación de eliminación

Versiones: 1.13.1

Síntomas: Cuando se elimina un StorageVirtualMachine antes de limpiar los clústeres que dependen de ese StorageVirtualMachine, es posible que haya un problema al limpiar algunos de los volúmenes persistentes (PV) de los clústeres. En concreto, cuando no se limpian los PVs cifrados con LUKS, su secreto impide que se elimine el espacio de nombres en el que se encuentran. Es posible que veas una advertencia en los registros como esta:

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: Elimina 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 queda atascada

Versiones: 1.13.1, 1.13.5 y 1.13.6

Síntomas: los trabajos de Ansible se quedan bloqueados al recopilar datos cuando hay LUNs zombi. Al ejecutar el comando multipath -ll, puede aparecer 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

También es posible que 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: comprueba la conectividad SSH con el nodo de destino y, a continuación, usa el siguiente runbook: FILE-R0020.

Error de adjuntos múltiples de Trident

Versiones: 1.13.3

Síntomas: Es posible que los pods y los PVCs se queden en nodos diferentes y que el pod se quede atascado inicializándose y esperando el PVC.

Solución alternativa:

  1. Comprueba si el PVC tiene un deletionTimestamp:

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

  2. Si no hay deletionTimestamp (migración de pódcast):

    1. Comprueba el campo VolumeAttachment del PVC para identificar dónde está conectado el volumen.
    2. Aísla los nodos del clúster que no coincidan con este valor.
    3. Elimina el pod que falla. Esta acción migra el POD de nuevo al nodo original.

  3. Si hay un deletionTimestamp (eliminación de volumen):

    1. Comprueba el campo VolumeAttachment del PVC para identificar dónde está conectado el volumen.
    2. En el nodo, muestra el contenido de su archivo de seguimiento, /var/lib/trident/tracking/PVC_NAME.json.
    3. Valida que el dispositivo LUKS encontrado en el campo devicePath de la salida del archivo de seguimiento esté cerrado. Esta ruta no debería existir en este punto: stat DEVICE_PATH. Si la ruta sigue existiendo, se produce otro problema.
    4. Valida si el número de serie está asignado a algún dispositivo de multipath.
    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 nuevo valor, comprueba si la entrada de multipath sigue existiendo: multipath -ll | grep SERIAL_HEX.
    8. Si no existe, elimina el archivo de seguimiento.

    9. Si existe, verás un valor hexadecimal de serie ligeramente más largo que el que has buscado. Registre 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 estos 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 bloque.

Error en la configuración de IPsec

Versiones: 1.13.4

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

Puede 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:

  1. Obtén las conexiones de cifrado del almacenamiento:

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    Busca la entrada con Ready=False y anota el nombre de PRESHAREKEY. La salida podría tener este aspecto:

    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

  2. Esta máquina está ejecutando una organización de GPU, así que elimina secrets gpc-system/vm-5a77b2a2-pre-shared-key en gpu-org-admin.

  3. Espera a que el sistema vuelva a crear secret/vm-5a77b2a2-pre-shared-key.

  4. 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. Cuando la clave vuelva a estar disponible, elimina el trabajo, como jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl en gpu-org-admin.

No se ha creado la máquina virtual de almacenamiento

Versiones: 1.13.5

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

Es posible que veas un error del controlador de almacenamiento como este, que indica que no se ha encontrado el 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:

  1. Elimina el pod file-storage-backend-controller.
  2. Deje que el controlador de almacenamiento vuelva a obtener las máquinas de inventario presentes.

No se pueden conciliar las redes entre clústeres de almacenamiento

Versiones: 1.13.5 y 1.13.6

Síntomas: Después de una actualización, el recurso personalizado StorageCluster del clúster de administrador raíz no se puede preparar debido a un error de configuración en las subredes entre clústeres de la especificación. El clúster de almacenamiento informa de Not Ready e 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, significa que la reclamación de subred entre clústeres que usa el clúster de almacenamiento no incluye el campo kind en la referencia. Al inspeccionar el recurso personalizado StorageCluster, encontrarás una referencia de reclamación de subred entre clústeres con solo un nombre y un espacio de nombres, como este:

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 StorageCluster para incluir el campo kind: SubnetClaim en la referencia de la reclamación de la 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 StorageCluster, reinicia la implementación file-storage-backend-controller y comprueba que el clúster de almacenamiento esté listo.

Gestión de clústeres

La tarea machine-init falla durante el aprovisionamiento del clúster

Versiones: 1.13.1

Síntomas:

  1. Durante el aprovisionamiento del clúster, el trabajo machine-init del segundo nodo del plano de control falla y muestra el siguiente mensaje:

    FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".

  2. Revisa 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 no está vacío.

Solución alternativa:

  1. Cambia el permiso de /etc/kubernetes/pki/etcd/ca.crt. Esta es una operación que requiere mucho tiempo. El cambio de permiso debe producirse después de la ejecución anterior de la tarea machine-init, pero antes de la siguiente, ya que machine-init vuelve a asignar el permiso a la raíz.machine-init

  2. Reinicia etcd en el segundo nodo para recuperar etcd en el primer nodo de un bucle de fallos.

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

No hay conectividad del clúster de servicio al segmento 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 segmento de almacenamiento de objetos del clúster de administrador de la organización.

Solución: Sigue las instrucciones del runbook KUB-R0305.

Fallo en la comprobación preparatoria

Versiones: 1.13.1

Síntomas: es posible que veas el siguiente mensaje en el estado del objeto de 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 de clúster que ha estado ahí durante varias horas, mientras que se sabe que el error o el fallo indicado en el objeto PreflightCheck ya no es un problema.

Solución alternativa: elimina el objeto PreflightCheck.

No se puede crear el grupo de nodos de trabajo del clúster de usuarios

Versiones: 1.13.5

Síntomas: La creación del grupo de nodos de trabajo del clúster de usuarios puede dejar de responder en 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: Elimina ese grupo de nodos y vuelve a crearlo seleccionando otros tipos de máquina disponibles en el menú desplegable de la interfaz de creación de clústeres de usuario.

Es posible que los clústeres de usuarios, cuando se vuelven a crear, se queden en el estado de conciliación debido a una limpieza incorrecta

Versiones: 1.13.x

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

Solución: Desinstala el complemento de Helm CLUSTER_NAME-abm-overrides y reinicia la implementación de managed-adm-controller. Sigue los pasos detallados de MKS-R0004.

Servicio de base de datos

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

Clonación de base de datos de AlloyDB Omni bloqueada

Versiones: todas las versiones de 1.13.x

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

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

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

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

Ejemplos de resultados:

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

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

El cumplimiento de las IOPS afecta al rendimiento del almacenamiento

Versiones: 1.13.1

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

  • Aumenta el tamaño del almacenamiento.
  • Anular la cuota de IOPS.

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

Versiones: 1.13.3

Síntomas: Al actualizar la organización raíz de la versión 1.13.1 a la 1.13.3, es posible que se produzca un error de conciliació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 puede ser similar al siguiente:

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 runbook OCLCM-R0122.

No se puede crear DBCluster

Versiones: 1.13.3

Síntomas: Después de actualizar a 1.13.3, los nuevos clústeres de bases de datos no se reconcilian y muestran 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

Verifica que haya localrollout CRs 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

Busca y elimina localrollout CRs que terminen en cpa-v0.12.46, asegurándote de que el resto de las localrollout CRs no se vean afectadas.

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

Debería devolver 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

Elimina cada uno de ellos:

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

Verifica que las CRs de localrollout que terminan en cpa-v0.12.51 sigan 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 explícitamente 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 hardware desnudo o de máquina virtual. Para confirmar que la resolución de DNS falla, 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:

  1. Añada la siguiente línea a /etc/systemd/resolved.conf en el nodo afectado.

    DNSSEC=false

  2. Reinicia el servicio systemd-resolved:

    systemctl restart systemd-resolved.service

Servicio portuario

No se ha podido crear el servicio 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 solucionar el problema actual. Asegúrate de que la longitud combinada de PROJECT_NAME y HARBOR_INSTANCE_NAME sea inferior a 27 caracteres.

Al eliminar instancias de Harbor, no se eliminan los espejos de registro asociados

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

Síntomas: al eliminar instancias de Harbor, no se eliminan los espejos de registro asociados. Es posible que el nodepool esté bloqueado en el estado Provisioning. Esto se debe a que los espejos del registro creados por el controlador de MHS no se eliminan cuando se eliminan las instancias de Harbor.

Solución: Debes quitar los espejos del registro manualmente. Para mitigar este problema, sigue estos pasos:

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

  2. Ejecuta esta secuencia de comandos para quitar todos 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)

    Sustituye HARBOR_INSTANCE_URL por la URL de tu instancia de Harbor.

Módulo de seguridad de hardware

Las licencias de prueba desactivadas de HSM siguen siendo detectables

Versiones: 1.13.1, 1.13.3-1.13.11

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

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

Fuga de descriptores de archivo del host-daemon de HSM

Versiones: 1.13.x

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

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

sudo systemctl restart host-daemon

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

Los certificados de HSM han caducado

Versiones: 1.13.11

Síntomas: al actualizar una organización, puede 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 se ha quedado bloqueado en una actualización de la versión de ABM debido a que los certificados HSM (módulo de seguridad de hardware) han caducado.

También puede que veas un error como este ejemplo en el servidor iLO de HPE, StorageGRID u ONTAP:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Solución:

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

  1. Pausa todas las respuestas predefinidas de HSM, HSMCluster y HSMTenant.

  2. Crea una nueva CA raíz con los atributos copiados de la antigua. Busca el ID de la antigua CA con ksctl ca locals list. Por ejemplo, podría tener este aspecto:

    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": {}
}

  3. Autofirma la nueva CA con una duración de un año. Por ejemplo, podría tener este aspecto:

    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"
    }
}

  4. Actualiza la interfaz web para que use esta nueva AC en la generación automática de certificados. Por ejemplo, podría tener este aspecto:

    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"                                                                                                                 
            ],      
...

  5. Genera un nuevo certificado de interfaz web firmado por la nueva AC. La marca --url es la IP de gestión del HSM (de kubectl get hsm -n gpc-system). Por ejemplo, podría ser 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"
}

  6. En este punto, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text sigue mostrando el certificado antiguo. Debes reiniciar el HSM para obtener el nuevo certificado.

    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 nuevo certificado.

  7. Elimina la AC antigua del CR del HSM:

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

  8. Reanuda el 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.

  9. Repite estos pasos con los otros dos HSMs. Ya tienen la nueva CA raíz autofirmada, ya que la CA se comparte entre los HSMs de un clúster. Sáltate los pasos 2 y 3, pero repite los pasos del 4 al 8.

  10. Sigue la tarea HSM T0008 para automatizar la rotación de todos los certificados, pero omite el paso Finaliza la rotación añadiendo una nueva anotación de rotación a hsmcluster en el que se añade ca-rotation-finalizing annotation.

Sube el nuevo nombre de la AC a iLO:

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

Gestión de identidades y accesos

Los pods gatekeeper-audit del espacio de nombres opa-system se reinician con frecuencia

Versiones: 1.13.3

Síntomas: comprueba 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

La salida podría tener este aspecto:

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

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

Infraestructura como código (IaC)

Si se crean demasiados tokens de GitLab, se corre el riesgo de llenar las bases de datos de GitLab

Versiones: 1.13.1

Síntomas: el subcomponente iac-manager crea un token para el usuario configsync-ro repetidamente, incluso cuando no es necesario. Esto puede provocar que la base de datos de GitLab se llene y que no se pueda acceder a IAC. Es posible que el pod pg-gitlab-database-0 del 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:

Ponte en contacto con tu representante de Google para obtener hotfix_3 para la versión 1.13.1 y aplícalo.

Sistema de gestión de claves (KMS)

Si cambia el tipo de clave raíz, todas las claves dejarán de ser válidas

Versiones: 1.13.x

Síntomas: una vez que se crea una organización, 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. De esta forma, se cambia el tipo de clave raíz, lo que invalida todas las claves de software del KMS.

Solución alternativa: Evita actualizar el tipo de clave raíz si es posible. Si actualiza el tipo de clave raíz, todas las claves que ya tenga dejarán de ser válidas.

kms-rootkey-controller CrashLoopBackOff debido a OOMKILL

Versiones: 1.13.1

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

Solución: 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 los requisitos previos del runbook, ejecuta los siguientes comandos:

  1. Crea un SubcomponentOverride recurso personalizado:

    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

  2. Aplica el recurso SubcomponentOverride:

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

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

Almacenamiento de registros

El registrador de auditoría de almacenamiento de objetos no puede resolver el host 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: parchea la implementación 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"}}}}'

HaaS Logger 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: actualiza a la versión 1.13.8 para solucionar el error. También puedes modificar la implementación de obs-system/log-remote-logger de la siguiente forma:

En los argumentos del contenedor remote-logger, actualice la marca --disabled-loggers para incluir santricity y HaaS:

YAML

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

Fallo de Santricity Logger

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: actualiza a la versión 1.13.8 para solucionar el error.

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

Versiones: 1.13.x

Síntomas: los registros de obs-system/oplogs-forwarder DaemonSet muestran 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 provocan que los registros se dirijan al proyecto incorrecto (ID de arrendatario). Este problema se debe a un error conocido de Fluent Bit. Para obtener más información, consulta el problema de Fluent Bit en GitHub.

Solución: actualiza a la versión 1.13.8 para solucionar 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 de para el administrador de la plataforma (PA).

Solución alternativa: añade 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 alternativa manual:

  1. Define KUBECONFIG como clúster de destino.

  2. Añade la etiqueta necesaria al espacio de nombres:

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

  3. Confirma que la etiqueta se ha añadido correctamente:

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

Los pods no pueden inicializar los contenedores

Versiones: 1.13.x

Síntomas: no se pueden crear los pods y se produce 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 se debe a un caso extremo conocido en el que el archivo de estado logrotate-daemon se bloquea, lo que impide que el daemon realice la rotación de archivos prevista. Para confirmar este error, sigue estos pasos:

  1. Define KUBECONFIG como clúster de destino.

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

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

  3. Obtén los registros de la instancia de anthos-audit-logs-forwarder-xxxx programada en el nodo para verificarlo.

    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:

Sigue estos pasos para solucionar el problema:

  1. Realiza una recuperación manual del espacio en disco en el directorio /var/log del nodo.

  2. Define KUBECONFIG como clúster de destino.

  3. Identifica el nodo de destino del clúster.

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

  4. Conéctate al nodo mediante SSH y libera espacio manualmente en el directorio /var/log del nodo. logrotate gestiona los archivos de 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

  5. Busca archivos de registro inusualmente grandes (más de 100 MB) o archivos de hace más de un par de días. Cuando tengas el archivo de destino, puedes truncar los registros de la siguiente manera:

    truncate -s 1G <target_file>

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

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

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

Fallo al extraer la imagen de Prisma Cloud

Versiones: 1.13.7

Síntomas: no se puede crear una instancia de servicio de Prisma Cloud desde Marketplace. El problema se debe a una etiqueta de imagen incorrecta.

Solución:

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

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

  2. Busca la siguiente línea:

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. Reemplaza console_33_01_137 por console_33.01.137:

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

  4. Comprueba que el pod se ejecuta correctamente:

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

    La salida podría tener este aspecto:

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

Supervisión

Se ha creado un gran número de alertas en ServiceNow

Versiones: 1.13.x

Síntomas:

Después de configurar la monitorización para enviar alertas a ServiceNow mediante las tareas de rutina MON-T0016 y MON-T1016, se crea automáticamente un gran número de incidencias 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 alternativa: sigue la tarea de esfuerzo MON-T0018 inmediatamente después de ejecutar las tareas de esfuerzo MON-T0016 y MON-T1016.

Se han creado varias alertas duplicadas en ServiceNow

Versiones: 1.13.x

Síntomas:

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

El problema tiene las siguientes características:

  • Se están creando varios incidentes duplicados para algunas alertas incluso después de aplicar la tarea rutinaria MON-T0018.

Solución alternativa: sigue la tarea MON-T0019 inmediatamente después de ejecutar las tareas 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 cifradas para los servicios de Vertex AI. Si el servicio de Vertex AI no se habilita en 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. Consulta el estado del pod mon-cortex:

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

La salida podría tener este aspecto:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Se puede registrar un mensaje como este:

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:

  1. Comprueba 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

  2. Elimina el PVC asociado a ese pod y reinícialo.

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

Versiones: 1.13.1

Síntomas: el pod metrics-server-exporter del clúster del sistema está en un bucle de fallos con OOMKilled, pero parece que no alcanza su límite. Diagnosticar el error:

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

La salida podría tener este aspecto:

[...]
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: reduce la cantidad de datos que se sirven en el endpoint de métricas eliminando el pod y dejando que se reinicie. La antigua time-series que se ha guardado en la memoria se borra al hacerlo, lo que reduce la memoria necesaria.

Ignorar 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:

Ignorar los registros que cumplan todas las condiciones siguientes:

  • "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 un gran número de errores de conciliación, 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 ha activado la alerta MON-A0001.

  • El ConfigMap mon-prober-backend-prometheus-config se restablece para que no incluya ningún trabajo de comprobación. 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:

Para solucionar el problema, sigue estos pasos:

  1. Define las siguientes variables de entorno:

    • KUBECONFIG: la ruta al archivo kubeconfig del clúster.
    • TARGET_CLUSTER: el nombre del clúster en el que estás resolviendo el problema.

  2. 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

  3. Reinicia el controlador de 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 rellena a medida que se registra cada sonda.

  4. Sigue el runbook MON-R2009 para silenciar la alerta MON-A0001, Blackbox monitoring metrics pipeline down, ya que esta alerta se activará continuamente.

Cortex store gateway component OOMKilled crashloop

Versiones: 1.13.3

Síntomas: Si ve errores en Grafana al cargar métricas o las métricas no se cargan, es posible que el pod cortex-store-gateway esté en un bucle de fallos.

Para diagnosticar el pod cortex-store-gateway y comprobar si está en un bucle de fallos, revisa su estado:

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

Sustituye SYSTEM_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster del sistema.

Si el pod está en un bucle de fallos, el resultado será similar al siguiente ejemplo:

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

Solución alternativa: aumenta temporalmente el límite de memoria cortex-store-gateway usando un SubcomponentOverride. Para obtener información sobre cómo implementar 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 cortex-store-gateway tengan el estado Ready y asegúrate de que el subcomponente mon-cortex no esté en pausa:

  • Comprueba que los pods cortex-store-gateway tienen el estado Ready:

    kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway

    La salida es similar al siguiente ejemplo si todos los pods tienen el estado Ready:

    NAME                   READY   AGE
cortex-store-gateway   3/3     70d

    La columna READY debe mostrar el 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

    Haz los cambios siguientes:

    • ORG_ADMIN_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador de la organización.
    • SYSTEM_CLUSTER: 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 de 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 se ven en Grafana, puede haber un problema de retirada de imagen con el pod kube-control-plane-metrics-proxy.

Para diagnosticar el pod kube-control-plane-metrics-proxy y comprobar si tiene un problema de retirada de extracción de imágenes, revisa su estado:

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

Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

Si el pod tiene un problema de retirada de extracción de imágenes, el resultado será similar al siguiente ejemplo:

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

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

  1. Extrae la imagen gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 del proyecto gpc-system-container-images Puerto. Para obtener instrucciones y los permisos necesarios para extraer una imagen, consulta Extraer una imagen con Docker.

  2. Envía la imagen gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 al proyecto library Harbor. Para obtener instrucciones y saber qué permisos necesitas para enviar una imagen, consulta Enviar una imagen.

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

El aumento de WAL provoca que Prometheus use mucha memoria

Versiones: 1.13.3

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

kubectl describe node NODE_NAME | grep Events -A100

La salida podría ser similar a la del 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 de WAL (registro anticipado de escritura), lo que afecta a la memoria del nodo. El crecimiento de WAL puede deberse a que no se ha implementado Cortex, por lo que este problema puede ser una consecuencia de que Cortex esté inactivo. La instancia de Prometheus pierde la conectividad con Cortex durante un periodo prolongado, durante el cual almacena datos en la memoria y en el volumen persistente (PV). Cuando se termina Prometheus, carga todos los datos de su WAL en la memoria al iniciarse.

Otra causa principal pueden ser los problemas de conectividad de red (malla de servicios, redes físicas y superiores).

Solución alternativa: para recuperarse de este estado, se recomienda solucionar la causa raíz y conseguir que Cortex vuelva a funcionar correctamente o resolver los problemas de conectividad de red. A continuación, espera a que se vacíe el WAL de Prometheus. No se pierden datos, pero si Cortex no funcionaba, el nodo no estará disponible durante el tiempo que tarde Cortex en recuperarse.

También puedes reducir la escala de Prometheus STS a cero y eliminar el PV. De este modo, se reduce el tiempo total durante el que el nodo no está disponible, pero se pierden datos. Además, mientras Cortex siga sin funcionar 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 eliminar el PV:

  1. Reduce el escalado del componente logmon-operator:

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

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

  2. Reduce el tamaño del componente anthos-prometheus-k8s:

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

  3. Elimina la reclamación de volumen persistente:

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

  4. Vuelve a aumentar el tamaño del logmon-operator:

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

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

Bootstrap multizona

Faltan roles de clúster

Versiones: 1.13.1

Síntomas: no hay roles específicos para el arranque de varias zonas que se puedan usar en Añadir roles obligatorios.

Solución: Usa el rol de clúster cluster-admin, tal como se especifica en las instrucciones vinculadas. De esta forma, el usuario tiene más del acceso mínimo necesario para realizar las tareas posteriores.

Recurso Bootstrap incompatible

Versiones: 1.13.1

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

Solución alternativa: Edita el archivo YAML generado tal 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 tal como se indica en Crear un recurso GlobalAPIZone.

Redes

La red de la cuadrícula de nodos de almacenamiento de objetos no funciona

Versiones: 1.13.1, 1.13.3 y 1.13.4

Síntomas:

  1. Durante la fase de arranque del almacenamiento de objetos, la interfaz de usuario del instalador del nodo de administrador de objetos muestra que la red de la cuadrícula está inactiva.
  2. cables.csv y Cell CR muestran que el valor MPN de 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 la velocidad que se establece en el interruptor Tor. Si no se define la velocidad en estos puertos, el cambio de Tor a la conectividad del nodo objsadmin fallará. La lista usada para asignar el MPN a la velocidad no tenía en cuenta un valor que proporcionó el integrador del sistema, lo que provocó que fallara el arranque del almacenamiento de objetos. En la mayoría de las configuraciones de la versión 1.13, el proveedor usaba QSFP-100G-CU2.5M.

Solución:

  1. 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.
  2. Cambia todas las instancias de mpn a "QSFP-100G-CU3M" para objsadm -> torsw connect.

Por 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:

  1. Durante la fase de arranque de la red, algunos interruptores no se pueden alcanzar.
  2. 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:

  1. Vuelve a cargar los interruptores de gestión afectados. Consulta el runbook PNET-R0018 para obtener más información.

PodCIDR no se ha asignado a ningún nodo aunque se haya creado ClusterCIDRConfig

Versiones: 1.13.1

Síntomas: ClusterCIDRConfig es un objeto obligatorio para asignar PodCIDRs. A pesar de que se ha creado el ClusterCIDRConfig, no se ha asignado el PodCIDRs. Este problema se produce si se crea un ClusterCIDRConfig al mismo tiempo que se inicializan los pods de ipam-controller. La creación del clúster se ha quedado bloqueada en el estado de conciliación.

  1. Comprueba si el objeto ClusterCIDRConfig se ha creado en el clúster:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    La salida podría tener este aspecto:

    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: ""

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

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    Los eventos de salida podrían tener este aspecto:

      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:

  1. Reinicia los pods del ipam-controller-manager:

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

  2. Una vez que los ipam-controller-manager pods estén en estado de ejecución, comprueba si el podCIDR se ha asignado a los nodos:

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

    La salida podría tener este aspecto:

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

Deriva de NTP

Versiones: 1.13.1

Síntomas: un nodo de VM se ha desviado o tiene una hora incorrecta después de estar en suspensión o de ejecutarse durante un tiempo.

Solución:

  1. Establece una conexión SSH con el nodo de la VM y edita el archivo /etc/chrony.conf.
  2. Sustituye la línea makestep 1.0 3 por makestep 1.0 -1.

  3. Reinicia el servicio chronyd:

    systemctl restart chronyd

Solo tienes que hacer este cambio una vez en cada VM. El cambio no se sobrescribirá.

Para solucionar el problema de forma rápida e inmediata, establece una conexión SSH con el nodo de la VM y ejecuta chronyc -a makestep.

No se han analizado los registros de auditoría de SyncServer

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

Síntomas: el log-remote-loggerno 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 siguen estando disponibles en SyncServer. Sigue las instrucciones de NTP-P0002 para acceder a la interfaz de usuario de SyncServer y ver los registros en Logs > Events.

No se ha podido extraer la imagen de cambio

Versiones: 1.13.3

Síntomas: es posible que veas un mensaje como este en el objeto SwitchImageHostRequest cuando realices un cambio de 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

La salida podría ser similar a la del 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:

Crea manualmente un SwitchImageHostRequest con la etiqueta de imagen correcta:

  1. Inicia sesión en el servidor de arranque.

  2. Usa gdcloud para identificar la versión correcta de la imagen del interruptor:

    release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch

    La salida podría ser similar a la del siguiente ejemplo:

    │   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385

    En esta salida, la versión correcta de la imagen del interruptor es 1.13.3-gdch.5385.

  3. Edita el objeto SwitchImageHostRequest que informa del error:

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

  4. Edita o sustituye los campos name, fromVersion y toVersion para que coincidan con la versión de la imagen del interruptor que esperas. En este caso, es 1.13.3-gdch.5385. Consulta el siguiente resultado de diff, que muestra los cambios que debes hacer 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

Fallo en 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 y 1.13.10

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

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

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

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

Problemas de conectividad con instancias de DBS

Versiones: 1.13.0 y 1.13.1

Síntomas: no se puede acceder a las instancias de Servicios de Bases de Datos (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, Facturación puede informar de 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: El error se debe a que un componente del sistema de redes no puede programar en el clúster de servicios de la organización.

  1. Define las siguientes variables de entorno:

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    Haz los cambios siguientes:

    • KUBECONFIG_PATH: 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.

  2. Actualiza la configuración del componente de red 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 restaura al cabo 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 puede conectarse a un clúster de base de datos del mismo proyecto. La conectividad con el balanceador de carga interno se ve afectada. Este problema se debe a que un Clustermesh no puede intercambiar objetos de servicio entre clústeres porque falta información de zona en la configuración del nombre del clúster.

Solución alternativa: en los entornos inicializados como multizona, sigue estos pasos para que funcione el balanceador de carga interno:

  1. 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

    La salida podría tener este aspecto:

    zone1

  2. 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

    La salida podría tener este aspecto:

    1

  3. Lista de todos los clústeres:

    ​​kubectl get clusters -A

    La salida podría tener este aspecto:

    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

  4. Para cada clúster, construye el CILIUM_CLUSTERNAME:

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

    La salida podría tener este aspecto:

    org-1-system-zone1

  5. En cada clúster, define 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

  6. Crea un objeto AddOnConfiguration para cada clúster y guárdalo en un archivo addonconfig.yaml. Crea este archivo para todos los clústeres que ya tengas y para los que crees en el futuro:

    En esta página, define las siguientes variables para actualizar el código de ejemplo:

    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

  7. Aplica el addonconfig.yaml en el clúster de administrador de la organización:

    kubectl apply -f addonconfig.yaml

  8. En los clústeres del sistema, de servicios y de usuarios, asegúrate de que cluster-name se haya actualizado en cilium-config del clúster. Este proceso puede tardar un poco, pero 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

  9. En los clústeres de sistema, de servicio y de usuario, reinicia la clustermesh-apiserver implementación:

    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 y 1.13.7

Síntomas: las direcciones IP de emparejamiento de la sesión de interconexión EVPN multizona (MZ) generadas por el sistema de gestión de activos de hardware (HAMS) no terminan en .65 ni en .66, lo que es incorrecto e impide que se establezcan las sesiones BGP de EVPN MZ.

Solución:

Para solucionar este problema manualmente, sigue estos pasos:

  1. Lista todos los recursos de InterconnectSession:

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

  2. Revisa los recursos de EVPN multizona InterconnectSession generados que tengan 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: {}

  3. En cada uno de los InterconnectSession recursos que coincidan con estos parámetros, aplica la siguiente corrección:

    1. Comprueba el nombre de 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 peer a 65 con el comando del paso siguiente.
    3. Si el nombre termina en un número par, actualiza la última parte de la dirección IP del peer a 66 con el comando del siguiente paso.

  4. Modifica el recurso InterconnectSession con la dirección IP del peer incorrecta:

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

  5. Aplica esta corrección a todos los recursos de InterconnectSession que provoquen el error.

El panel de control de la capa de control de redes superior no muestra datos

Versiones: 1.13.7

Síntomas: las consultas de Prometheus en TestUpperNetworkingMetrics fallan porque faltan métricas en el clúster org-1-system. Los paneles de clustermesh del panel de control de la capa de red superior de los administradores de organizaciones de IO no muestran datos. El problema se debe a una discrepancia en la etiqueta source_cluster entre Cilium y el sistema de monitorizació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 problema.

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

Versiones:

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

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

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

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

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

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

Almacenamiento de objetos

No se puede eliminar la organización de almacenamiento

Versiones: 1.13.1

Síntomas: Es posible que no se pueda eliminar una organización debido a un problema que impide que se complete la eliminación de la SVM. Puede 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 de almacenamiento de objetos

Versiones: 1.13.3

Síntomas: al actualizar el almacenamiento de objetos, puede que vea 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:

  1. Comprueba que cada nodo tenga las credenciales SSH correspondientes almacenadas en un secreto.

    1. Comprueba 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

    2. Comprueba 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 tiene el siguiente aspecto en el caso de 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 ningún secreto, el error tendrá este aspecto:

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

  2. Si el comando no devuelve ningún error, puedes ignorar los errores que informen los reconciliadores.

ObjectStorageStorageNodeReconciler informes maintenance.gdu.gdu_server_locked

Versiones: 1.13.3

Síntomas: muestra los detalles de la objectstoragestoragenode:

kubectl describe objectstoragestoragenode zv-aa-objs02

La salida podría ser similar a la del 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 alternativa: puede ignorar este problema. El servicio GDU puede bloquearse temporalmente si recibe demasiadas solicitudes, pero se desbloqueará al cabo de unos minutos.

Fallo en la comprobación del almacenamiento de objetos tras la actualización de 1.12.x a 1.13.x

Versiones: 1.13.x

Síntoma: el CR ObjectStorageUpgrade falla y se produce 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 principal: La actualización del componente operativo de Object Storage de la versión 1.12.x a la 1.13.x falla si el clúster KIND de arranque no se ha desactivado ni eliminado. Aunque la actualización se realice correctamente, es posible que se produzcan errores en los servicios de almacenamiento de objetos comunes, como la creación de nuevos contenedores o credenciales de S3 a través de RBAC de Kubernetes, debido a errores de validación de certificados TLS. Esto se debe a que un pod de almacenamiento de objetos específico del clúster de KIND intenta continuamente instalar el certificado de servidor TLS del endpoint de gestión de StorageGRID, que era válido en la versión 1.12.x, pero que puede que no se reconozca en la versión 1.13.x. Durante la actualización, StorageGRID instala un nuevo certificado de servidor TLS verificable, pero el pod del clúster de KIND lo sustituye por el certificado antiguo no válido, lo que provoca el error del certificado TLS.

Solución alternativa: Debes cumplir los siguientes requisitos:

  • Actualización de Object Storage de la versión 1.12.x a la 1.13.x
  • El clúster de arranque (el clúster de KIND) sigue existiendo

Sigue estos pasos:

  1. Obtén un kubeconfig que tenga permiso de lectura y modificación para el recurso ObjectStorageSite en el clúster de arranque (el clúster KIND).

  2. Define un alias para kubectl que se conecte al clúster de arranque (el clúster de KIND):

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

  3. Obtén la instancia de recurso personalizado ObjectStorageSite del clúster de bootstrapping. Debería haber una instancia de recurso ObjectStorageSite:

    SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')

  4. Añade 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

  5. Verifica que se haya añadido la anotación de pausa del almacenamiento de objetos a la instancia ObjectStorageSite:

    kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq

  6. Obtén un kubeconfig que tenga acceso de lectura y permiso para aplicar parches de estado a los recursos ObjectStorageCluster del clúster de administrador raíz.

  7. Define un alias para kubectl que se conecte al clúster de administrador raíz:

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

  8. Comprueba si existe alguna instancia de recurso ObjectStorageCluster en el clúster de administrador raíz:

    kubectlrootadmin get ObjectStorageCluster

    Si no hay ninguna instancia de recurso ObjectStorageCluster, la solución alternativa habrá finalizado. Es posible que tengas que volver a realizar el procedimiento de actualización de Object Storage.

  9. Obtén la URL del endpoint de gestión del estado del recurso ObjectStorageSite en el clúster de bootstrapping:

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

  10. Valida si se ha definido la variable de entorno $MGMT_ENDPOINT. El endpoint debe empezar por https://:

    echo ${MGMT_ENDPOINT:?}

  11. Sigue los pasos restantes solo si hay exactamente una instancia de recurso ObjectStorageCluster en el clúster de administrador raíz. De lo contrario, vuelva a realizar el procedimiento de actualización de Object Storage:

    kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"

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

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

  13. Comprueba si el endpoint de gestión se ha añadido al estado del recurso ObjectStorageCluster:

    kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq

  14. Reinicia la comprobación posterior al vuelo eliminando el trabajo de Kubernetes de comprobación posterior al vuelo gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. La tarea se volverá a crear en breve.

No se puede acceder al nodo en la red de datos

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

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

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

Versiones:

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

Síntomas:

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

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

Solución alternativa:

Sigue estas instrucciones para reparar cada nodo en mal estado:

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

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

  2. Obtén acceso SSH al nodo afectado.

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

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

    tc filter del dev bond0 egress

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

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

Sistema operativo

Pods atascados en el estado init

Versiones: 1.13.1

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

Solución:

  1. Sigue las instrucciones de OS-P0001 para drenar el servidor. El proceso puede tardar más de 20 minutos. Si el drenaje no se completa después de una hora, ve al paso siguiente.

  2. Reinicia el servidor estableciendo una conexión SSH con él y ejecutando el siguiente comando:

    systemctl reboot

  3. Es posible que sea necesario reiniciar el servidor una segunda vez para que se recupere por completo.

  4. Comprueba que el acceso SSH ya no es lento y que el número de procesos zombi es mucho menor (preferiblemente, inferior a 30).

  5. Para que el servidor vuelva a funcionar, cambia el valor de maintenance a false en el servidor.

bm-system-machine-preflight-check Falla un trabajo de Ansible para un nodo de metal desnudo o de máquina virtual

Versiones: 1.13.1

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

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 en el dispositivo

Versiones: 1.13.1, 1.13.3, 1.13.4 y 1.13.5

Síntomas: cuando el directorio de registro /var/log está lleno, Node puede quedarse atascado en el estado NotReady y es posible que los pods no se inicien debido al error no space left on device. Para comprobarlo, ejecuta el siguiente comando en el nodo y comprueba si el uso es de aproximadamente el 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:

  1. Inicia sesión en el nodo que tiene el problema y elimina los archivos de registro antiguos de /var/log/messages.

    find /var/log -name "messages*" -mtime +4 -delete

    También te recomendamos que sigas aplicando la siguiente solución alternativa para evitar que vuelva a ocurrir. La solución alternativa consiste en crear un AnsiblePlaybook y aplicar el cambio mediante un OSPolicy CR 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 información.

  2. Define las siguientes variables de entorno:

    export KUBECONFIG=<the path to the kubeconfig file>

  3. 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

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

    En el siguiente ejemplo de OSPolicy se han incluido dos inventarios de destino en spec.inventory, pero puede añadir 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

  5. Validación

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

Pods atascados en el estado ContainerCreating

Versiones: 1.13.3, 1.13.5 y 1.13.6

Síntomas: Un nodo aparece como correcto, pero tiene muchos pods atascados en el estado ContainerCreating y no puedes establecer una conexión SSH con el servidor.

Solución: Reinicia el servidor y confirma que puedes establecer una conexión SSH con el nodo cuando vuelva a estar operativo.

No se puede conectar por 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 gestión y de datos.

Solución alternativa: reinicia el nodo a través de iLO. Una vez que se haya iniciado, conéctate por SSH e inhabilita clamonacc con systemctl stop clamonacc; systemctl disable clamonacc.

Infraestructura de la suite de operaciones (OI)

No se necesita SSA para el hardware 3.0

La configuración del adaptador RAID es diferente en Hardware 3.0. Los servidores OIC de hardware 3.0 usan una unidad autocifrada, por lo que ya no es necesario iniciar Smart Storage Administration (SSA). Se necesitan pasos adicionales para determinar los identificadores de disco en cada servidor. Consulta OI server bootstrap.

Seguridad perimetral

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

Versiones: 1.13.1

Síntomas: Durante el arranque de la organización, el clúster del sistema de la organización puede quedarse bloqueado. Los pods edr-sidecar-injector están en estado pendiente. Cuando intentes eliminar estos pods, es posible que veas un mensaje de error como este:

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 una intervención manual para desbloquearse.

Solución:

  1. Duplica el MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg en el clúster del sistema.
  2. Duplica el ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration en el clúster del sistema.
  3. Elimina tanto el edr-sidecar-injector-webhook-cfg CR como el gatekeeper-validating-webhook-configuration CR del clúster del sistema.
  4. Espera a que los pods edr-sidecar-injector y gatekeeper-controller-manager vuelvan a estar activos.
  5. Restaura el CR de webhook con el comando kubectl apply.

Los grupos de direcciones de cortafuegos de PANW no se actualizan con los cambios de reclamación de CIDR

Versiones: 1.13.1

Síntomas: durante el arranque, el OCIT cidr-claim se actualiza con el valor correcto, pero el firewall AddressGroups no. Un par de AddressGroups, concretamente vsys1-root-ocit-network-cidr-group y ocvsys1-root-ocit-network-cidr-group, usa bloques de red que no se solapan con lo que se está usando en OIR. OIR no puede resolver los registros de zona de GDC y las consultas agotan el tiempo de espera sin recibir respuesta.

Solución: Después de los cambios en cidr-claim, asegúrate de que AddressGroup se actualice con la versión más reciente de cidr-claim reiniciando la implementación de fw-core-backend-controller en el espacio de nombres fw-system del clúster root-admin.

Servidores físicos

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

Versiones: 1.13.1

Síntomas: el arranque del servidor falla cuando no se supera el proceso de arranque POST. Al iniciar sesión en ILO y consultar la consola del servidor, se 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 bloqueados en el estado de aprovisionamiento

Versiones: 1.13.1, 1.13.3 y 1.13.5

Síntomas: los servidores se quedan bloqueados en un estado de aprovisionamiento durante el arranque del servidor. Comprueba el estado de los servidores:

k get servers -A | grep -v availabl

La salida podría tener este aspecto:

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:

  1. Inicia dhcp manualmente 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

    Sustituye VERSION por la versión de lanzamiento, tal como se describe en las instrucciones de actualización de Actualización manual de componentes de archivos para clústeres de administrador raíz y de organización. Por ejemplo, 1.13.1-gdch.525.

  2. Comprueba la configuración de la BIOS en el servidor y verifica que NetworkBoot no esté habilitado para las NICs del plano de datos (cuyo nombre sigue el patrón Slot{i}Nic{i}).

  3. Comprueba la BIOS mediante la llamada a la API:

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword

    Donde $bmcUser y $bmcPassword son las contraseñas de los ILOs, 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 la salida de este comando muestre Slot1Nic1: Disabled.

  4. Si alguna de esas Slot{i}Nic{i} tiene NetworkBoot, inhabilítala con la API de configuración de la 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'

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

  5. 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 la tarea de cifrado del modelo HPE DL380a. El estado del CR del servidor se queda bloqueado 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:

  1. Sigue las instrucciones de IAM-R0004 para generar el KUBECONFIG de root-admin-cluster.

  2. Sigue las instrucciones de PLATAUTH-G0001 para generar la clave SSH root-id_rsa de CLUSTER_NS=root.

  3. Para pausar el servidor, añade la anotación server.system.private.gdc.goog/paused al recurso personalizado del servidor:

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

  4. Inicia sesión en el servidor desde la IP de gestió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

  5. Habilita el cifrado manualmente:

    /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

    La salida de los comandos debería ser similar a la 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 el último comando no se ejecuta correctamente o ves errores como "Invalid BIOS EKM status" (Estado de EKM de BIOS no válido), prueba a reiniciar el servidor y la iLO y, a continuación, 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 ha ejecutado correctamente, reinicia el servidor siguiendo las instrucciones.

  6. Crea una unidad lógica manualmente:

    Una vez que el servidor haya terminado de reiniciarse, vuelve a iniciar sesión en el servidor desde la IP de gestión y muestra todas las unidades disponibles:

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

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

    La salida del último comando podría ser similar a 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"
        }
      ]
    }
  }
  ]
}

    Deberías guardar los 2 IDs de EID:Slt con Size igual a 1.60 TB. En este caso:

    252:1,252:2

    A continuación, crea una unidad lógica con los IDs de EID:Slt:

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

    El resultado del último comando es similar al 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.

  7. Estado de cifrado de disco simulado en el CR del servidor.

    Edita el estado de la respuesta predefinida del servidor:

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

    Añade o modifica el estado DiskEncryptionEnabled a true:

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

  8. Elimina el trabajo de cifrado del servidor, si lo hay:

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

  9. Reanuda 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 si no hay 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 este:

- 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 runbook SERV-R0014.

Seguridad de la plataforma

El reconciliador de subautoridades de certificación propias no verifica si los certificados tienen una clave pública coincidente

Versiones: 1.13.1

Síntomas: cuando el modo de subautoridad de certificación (SubCA) de PKI BYO genera una nueva solicitud de firma de certificado (CSR) mientras se sube un certificado firmado anteriormente a la SubCA, el reconciliador no comprueba si la nueva CSR coincide con el certificado firmado antiguo y marca el recurso personalizado (CR) cert-manager CertificateRequest como Ready. Esto ocurre durante la renovación o la rotación manual del certificado de la subautoridad de certificación. El controlador de cert-manager intenta actualizar el estado del CR 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 subautoridad de certificación BYO firmado para el nuevo CSR.

Un problema de cert-manager provoca que no se pueda emitir una 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 gestión de certificados automatizado (ACME). Cuando ejecutas el comando para comprobar 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

Administrador de recursos

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

Versiones: 1.13.1 o posteriores

Síntomas: la consola de GDC no muestra el estado de un proyecto. Los proyectos que no estén en el estado Ready no podrán admitir recursos nuevos ni procesar modificaciones nuevas en los recursos que ya tengan. Como no se puede confirmar el estado del proyecto, no está claro cuándo se pueden gestionar los recursos de un proyecto, lo que provoca errores al intentar realizar nuevas acciones en el proyecto.

Solución alternativa: consulta el runbook RM-R0100 para imprimir el estado del proyecto mediante la CLI de kubectl.

Actualizar

bm-system y otros trabajos atascados

Versiones: 1.13.1

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

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

IP de gestión no accesible

Versiones: 1.13.1, 1.13.3, 1.13.4 y 1.13.5

Síntomas: durante una actualización, no se puede acceder a la IP de gestión de un servidor, sobre todo después de un cambio.

En Rocky Linux, cuando se añaden rutas estáticas, la IP de destino utilizada para acceder a las rutas estáticas debe ser accesible antes de añadir las rutas estáticas. Si el switch se reinicia después de una actualización del SO, es posible que no se pueda acceder a esa IP de gestión temporalmente.

Solución alternativa: establece una conexión SSH con el servidor mediante la dirección IP de los datos y reinicia el servicio de red para volver a crear las rutas estáticas que faltan:

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, el CR StorageCluster no muestra ningún valor en el campo de estado StorageVersion.

Comprueba la versión:

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

Sigue los pasos de la solución alternativa si el campo de versión está vacío.

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 Bare Metal se queda bloqueado en el estado de aprovisionamiento

Versiones: 1.13.1

Síntomas:

El servidor de hardware desnudo se queda en el estado "provisioning" (aprovisionando) durante mucho tiempo cuando se crea una organización.

Solución:

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

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

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

  1. Define el nombre del servidor bloqueado.

    export SERVER_NAME=

  2. Define 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)

  3. 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"]

    Define la variable PCIEslot:

    export DATA_NIC_SLOT=3

  4. Comprueba 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 explícitamente.

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

    Sustituya "Slot3" en el siguiente comando por el número de espacio 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, a continuación, reinicia el equipo.

    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 operativo y reanuda automáticamente el proceso de aprovisionamiento.

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

Versiones: 1.13.1

Síntomas: las comprobaciones previas o posteriores a la publicación fallan y se produce un error. Consulta los registros:

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

El error puede ser similar al siguiente:

 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:

  1. Si el error se produce durante las comprobaciones posteriores al vuelo y todas las demás comprobaciones se completan sin errores, omite las comprobaciones posteriores al vuelo. Cuando se reinicie la actualización, también debes omitir las comprobaciones previas mediante el archivo kubeconfig del administrador root:

    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 tiene este aspecto:

    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

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

    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 tiene este aspecto:

    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 tengas que aplicar esta solución alternativa más de una vez si no se aplica.

Restauraciones de versiones anteriores de Helm

Versiones: 1.13.3

Síntomas: un problema con la actualización de Helm provoca una serie de restauraciones y no se encuentra Certificate ni 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 runbook OCLCM-R0122.

Actualización de nodos o ABM bloqueado porque no se ha vaciado el pod dhcp-tftp-core-server

Versiones: 1.13.3, 1.14.4 y 1.14.5

Síntomas: la actualización del nodo puede quedarse bloqueada. En el estado de la máquina Bare Metal, el pod dhcp-tftp-core-server no se ha drenado. 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 la eliminación del pod dhcp-tftp-core-server-* para continuar. El comando tiene este aspecto:

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

OrganizationUpgrade se ha quedado atascado en la fase de actualización del nodo

Versiones: 1.13.3

Síntomas: OrganizationUpgrade se queda atascado en la fase de actualización de nodos. 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:

  1. Comprueba si hay upgradetaskrequest CRs en el clúster raíz ka get upgradetaskrequest -n gpc-system. Comprueba si el nodo sigue en estado de ejecución. Asegúrate de que se haya quedado atascado en la tarea del 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

  2. Crea manualmente nodeupgrade CRs para cada reclamación de 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

  3. Crea un nodeupgrade CR para cada reclamación de grupo de nodos. Los detalles de la anotación upgrade.private.gdc.goog/target-release-version deben obtenerse del nombre CRMD del SO de destino:

    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

  4. 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

  5. Aplica los siguientes yaml a 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

  6. Una vez que se hayan completado las actualizaciones de los nodos del clúster de servicio, actualiza el estado del UpgradeTaskRequest CR a True para que la actualización de la organización pase a la siguiente fase:

        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

  7. La actualización de la organización debería pasar a la siguiente fase y el estado del servicio o del nodo debería ser "Completado":

    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 asigna memoria cgroup, lo que provoca errores al crear contenedores.

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 está usando un número muy elevado de cgroups:

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

Solución:

Sigue uno de estos procedimientos:

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

Fallo de conectividad intermitente a la IP virtual del clúster externo

Versiones: 1.13.3

Síntomas: los fallos 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, provocan un error dial tcp :: connect: no route to host.

Para diagnosticar este problema, sigue estos pasos:

  1. Conéctate al clúster de administrador raíz. Esta solución alternativa presupone 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 del administrador o del sistema de la organización, cambia el valor de KUBECONFIG a la ruta kubeconfig del clúster correcto.

  2. Hay dos categorías conocidas de IPs que pueden verse afectadas. Comprueba si el protocolo de puerta de enlace de frontera (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`

      Sustituye KUBECONFIG por la ruta a tu archivo kubeconfig en el clúster de administrador raíz.

    • En algunas configuraciones, el recurso personalizado BGPAdvertisedRoute define qué rutas de la dirección IP se anuncian a otras redes o sistemas mediante BGP. Si la dirección IP se anuncia mediante el recurso personalizado BGPAdvertisedRoute, 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

      Sustituye TARGET_IP_ADDRESS por la dirección IP que tenga problemas de conectividad intermitentes.

  3. Comprueba el estado de los BGPSession recursos personalizados. Un BGPSession representa una sesión de emparejamiento de BGP individual establecida entre tu clúster de Kubernetes y un peer de BGP externo. Inspecciona los registros de los pods de BGPAdvertiser y comprueba que todos los recursos de BGPSession tengan 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`

    La salida de un pod BGPAdvertiser correcto 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\

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

    1. 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"

    2. Ejecuta la secuencia de comandos:

      ./script.sh TARGET_IP_ADDRESS:PORT

      Sustituye PORT por el número de puerto que tiene 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`

  5. El resultado anterior confirma el problema. Comprueba las rutas de los conmutadores TOR para ver si la configuración de los conmutadores TOR es la causa del problema.

    Supongamos que el tráfico se ha descartado para una dirección IP de ejemplo 192.0.2.201 y que la anuncia el recurso BGPAdvertisedRoute. Examina los saltos del recurso BGPAdvertisedRoute para identificar posibles puntos de fallo:

    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

  6. Consulta las direcciones IP en el campo nextHops. Busca el nombre del servidor de cada dirección IP. Por ejemplo:

    - 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01

  7. Esta salida muestra que los siguientes saltos se dirigen a servidores de los racks aa y ab. Inicia sesión en los conmutadores TOR de los racks aa y ab y compara las rutas de ambos racks:

    show ip route 192.0.2.201 vrf root-external-vrf

  8. Si las rutas son diferentes entre los conmutadores TOR de los dos racks, significa que tienes el problema que mitiga la solución alternativa. La salida de este problema es similar a la siguiente:

    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 tienen el estado esperado y muestran tres saltos siguientes en el prefijo. Sin embargo, en el rack ab, el prefijo solo tiene dos saltos siguientes. Cuando el tráfico destinado al prefijo se cifra con hash en el rack ab, el nodo correspondiente al siguiente salto que falta nunca recibe el tráfico y la red tiene problemas de conectividad.

Sigue la solución alternativa para mitigar este problema.

Solución:

Esta solución alternativa ayuda a resolver problemas de conectividad intermitente con determinadas direcciones IP en clústeres de Kubernetes.

Para mitigar este problema, debe aplicar varios cambios de configuración a la sesión BGP entre los conmutadores agregados. Los conmutadores de agregación (AGG) agregan el tráfico de varios conmutadores TOR. Sigue estos pasos para actualizar todas las configuraciones necesarias:

  1. Un archivo de configuración llamado switchstaticconfig representa las configuraciones estáticas de un solo interruptor. 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

  2. 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 el valor de ASN 65030. En los pasos siguientes, debes usar el valor de ASN que se devuelva aquí.

  3. Una dirección IP de bucle de retorno en un switch AGG actúa como una dirección estable y siempre activa para la gestión, el enrutamiento y la resolución de problemas, incluso si otras conexiones de red no funcionan. Obtén las direcciones IP de bucle invertido de cada uno de los switches 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"]

  4. Actualiza el valor de staticswitchconfig en el interruptor za-ab-aggsw01 AGG. Añade 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

    Haz los cambios siguientes:

    • ASN: el valor de ASN del paso anterior. En este ejemplo, el valor es 65030.
    • LOOPBACK_ADDRESS: es la dirección IP de bucle invertido del switch AGG za-ac-aggsw01. En este ejemplo, el valor es 192.0.2.2.

  5. Aplica la misma actualización al otro interruptor AGG. za-ac-aggsw01. Debe proporcionar la dirección de bucle invertido correcta. La dirección IP de bucle de retorno es diferente para cada switch:

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  6. Crea y ejecuta la misma secuencia de comandos que has usado para diagnosticar el problema en este paso para verificar que la corrección se ha aplicado correctamente. En el resultado no se muestra ningún mensaje de error.

Aparece un error Incorrect version of Trident durante la actualización

Versiones: 1.13.3, 1.13.4 y 1.13.5

Síntomas: al actualizar 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:

  1. Actualiza la releasemetadata de la versión a la que vas a cambiar:

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

    La salida podría ser la siguiente:

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

  2. Elige la versión a la que vas a actualizar, como se indica en el siguiente ejemplo:

    kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml

  3. Actualiza la versión de trident en la sección fileBlockStorage del archivo .yaml a la versión que se menciona en el error. Si el mensaje de error era similar a este:

    Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5

    Cambia tridentVersion por 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.

  4. Aplica los cambios:

    kubectl apply -f releasemetadata.yaml

  5. Vuelve a aplicar la ampliación del almacenamiento de ontap.

No se pueden programar pods

Versiones: 1.13.3. 1.13.4 y 1.13.5

Síntomas: durante el aprovisionamiento del clúster de usuarios, 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:

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

  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}]"

Fallo al actualizar 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:

Si actualizas a la versión 1.13.3, se solucionará el error.

Se ha superado el plazo de las tareas de comprobación de la actualización

Versiones: 1.12.x y 1.13.x

Síntomas: durante la actualización de la organización, la comprobación de la 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:

  1. Elimina las tareas de comprobación de actualización fallidas correspondientes a las comprobaciones de actualización fallidas.
  2. Espera hasta que se vuelvan a crear los trabajos de comprobación de la actualización.
  3. Consulta los registros de los trabajos recreados y clasifica los problemas.

El complemento meta-monitoring falla porque la ubicación de strongswan está 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, el complemento meta-monitoring falla:

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

Comprueba el complemento:

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

El mensaje de la condición podría ser similar al siguiente:

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:

  1. Asegúrate de que las sesiones de BGP del 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

  2. Comprueba que los ang-node pods 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

  3. Aplica el siguiente cambio a ang-overridesAddonConfiguration 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

  4. Después de un minuto, confirma que los pods de ang-node 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

  5. Asegúrate de que las sesiones de BGP del clúster del sistema de la organización se estén ejecutando.

  6. El complemento meta-monitoring pasará a la siguiente fase.

La actualización de la organización raíz se bloquea debido a un error en la tarea de firma

Versiones: 1.13.3 y 1.13.4

Síntomas: al actualizar de la versión 1.13.3 a la 1.13.4, es posible que veas un mensaje como este:

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:

  1. Inhabilita la comprobación preparatoria:

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

  2. Elimina el trabajo artifact-signature-verification-*** fallido.

  3. Espera a que se complete la actualización de root.

  4. Opcional: Habilita la comprobación previa al lanzamiento si el entorno se ha actualizado a la versión 1.13.4 o posterior.

Una vez que el mando tenga 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 fase de comprobación previa con ErrImagePull

Versiones: 1.13.3

Síntomas: la actualización de la organización del arrendatario falla en la fase de comprobación previa con ErrImagePull para el pod de validación del paquete. 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 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:

Para saltarte las comprobaciones preparatorias, haz lo siguiente:

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

No se encuentra 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, se produce un error en la implementación de addon para los RBACs si se han realizado actualizaciones anteriores y ya existen complementos. Los síntomas pueden estar en una de las siguientes fases:

  1. comprobaciones preparatorias o posteriores
  2. Cualquier fase que implique una tarea de actualización y el mensaje indique que la tarea se está ejecutando aunque esté bloqueada. El mensaje status.conditions indica que el trabajo se está ejecutando durante mucho tiempo, lo que significa que hay un problema.

Para comprobar si se ha producido un error en la comprobación previa a la actualización, consulta el estado del objeto OrganizationUpgrade correspondiente a la organización que se va a actualizar:

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

  1. Si el trabajo falla en PreflightCheck, puede mostrar un error como este o un mensaje UpgradeCheckRBACDeploymentInProgress:

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

  2. Si el trabajo falla en la fase de Anthos Bare Metal (ABM) en la que se está ejecutando 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

  3. Si el fallo se produce en las comprobaciones, la upgradecheckrequest CR falla:

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

    La salida podría tener este aspecto:

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

  4. Si el fallo se produce en las tareas, upgradetaskrequests CR falla:

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

    La salida podría tener este aspecto:

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

  5. Si el error indica que hay un error de RBAC al buscar una cuenta de servicio, comprueba si se ha desplegado 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:

  1. Comprueba si se ha implementado un complemento 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

  2. Obtén los complementos anteriores 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

  3. Eliminar 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

  4. Después de eliminar el complemento, también debe eliminar el upgradetaskrequest o el upgradecheckrequest correspondiente. Se volverá a crear.

    kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc

  5. Sigue monitorizando el upgradetaskrequest o el upgradecheckrequest que acabas de crear, o la tarea correspondiente, directamente.

No se puede cambiar a un plan superior en shared-service-cluster upgrade

Versiones: 1.13.3

Síntomas: la actualización de Anthos en Bare Metal se bloquea en una o varias máquinas Bare Metal. Todas las demás máquinas físicas se han actualizado correctamente o aún no han empezado 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 ABM actual y VERSIÓN ABM DESEADA.

Sigue los pasos de Anthos Bare Metal para obtener el baremetalmachine estado 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:

  1. Saca la máquina de 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}}'

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

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

  3. Monitoriza las máquinas Bare Metal para comprobar que la máquina ve la actualización de la versión de ABM seleccionada.

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

No se ha podido instalar el complemento system-dashboards

Versiones: 1.13.5

Síntomas: la actualización de la versión 1.12.4 a la 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 que se indican en el runbook OCLCM-R0122.

NodeUpgradeTask CR se queda bloqueado en la condición NodeOSInPlaceUpgradePostProcessingCompleted

Versiones: 1.13.5

Síntomas: durante la actualización a la versión 1.13.5, el NodeUpgradeTask CR se queda bloqueado en la condición NodeOSInPlaceUpgradePostProcessingCompleted.

Comprueba si el os-artifact-collectortrabajo correspondiente se ha completado. Si el trabajo se queda bloqueado 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:

  1. Elimina el trabajo o el pod para forzar un nuevo intento.

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 la versión 1.12.4 a la 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]:

Comprueba los pods de obj-proxy en gpc-system de la organización para ver si se produce un error en 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:

  1. Reinicia el pod obj-proxy con KUBECONFIG de la organización en la que se produce el error:

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

  2. Consulta 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

  3. Consulta los registros de los pods disponibles. Por ejemplo: 

    kubectl logs obj-proxy-gdgzp -n gpc-system

  4. Las tareas 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 usuarios

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 este:

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

  1. Inicia sesión en el nodo y comprueba si la partición está llena:

    df -h /

    La salida podría tener este aspecto:

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

  2. Comprueba si /etc/kubernetes/tmp está usando 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:

  1. Borra todas las copias de seguridad de rm -f /etc/kubernetes/tmp/*:

    df -h /

    La salida podría tener este aspecto:

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/m

Se está volviendo a crear la actualización del administrador raíz y se produce un error en las comprobaciones preparatorias

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

Síntoma: la actualización de la organización raíz falla en la comprobació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 root-admin y el kubeapiserver de root-admin se han actualizado 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 de 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 de 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

Aplica el salto de comprobació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 quedan en el estado de finalización

Versiones: 1.13.5

Síntomas: los complementos no se pueden implementar durante la actualización o el arranque y muestran un mensaje de error como este: 

 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, comprueba si hay errores en los complementos correspondientes. 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 ha bloqueado porque ha intentado crear contenido en los espacios de nombres que se están eliminando. Este bloqueo persiste, ya que la eliminación del espacio de nombres también está bloqueada.

Solución alternativa:

  1. Antes de iniciar una actualización, anota los proyectos para evitar que se eliminen:

    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:

  2. La eliminación del espacio de nombres se ha bloqueado debido a recursos con finalizadores. Para continuar con la eliminación, 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.

  3. Espera a que se elimine el recurso. Después de ejecutar la secuencia de comandos, elimina los recursos y los espacios de nombres que terminan. Es posible que tengas que volver a ejecutar la secuencia de comandos si el espacio de nombres sigue en el estado de finalización. Una vez finalizado, 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 se habían quedado bloqueados deberían implementarse en unos minutos. Verifica que los estados DEPLOYED y READY ahora sean true:

      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

UPORC entra en bucles de fallos en el clúster de KIND durante el arranque

Versiones: 1.13.x

Síntomas: la implementación uporc-root-backend-controller en el espacio de nombres uporc-system se bloquea en bucle en el clúster de KIND.

Solución alternativa:

  1. Comprueba si los objetos ComponentGroupReleaseMetadata y ReleaseMetadata coinciden:

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    Si los objetos coinciden, no es necesario aplicar ninguna solución alternativa.

  2. Si los objetos no coinciden, ponte en contacto con el equipo de UPORC para obtener ayuda, ya que esto puede indicar otros problemas subyacentes.

No se ha podido actualizar el nodo

Versiones: 1.13.6

Síntomas: no se ha podido actualizar el nodo en NodeOSInPlaceUpgradeCompleted.

  1. Consulta los registros de los trabajos de os-upgrade ospolicy.
  2. Si el registro incluye un error que sugiere que el archivo de configuración está dañado, accede al nodo y comprueba el contenido del archivo manualmente para ver si está dañado. En el error del registro puede aparecer el código de error configparser.DuplicateOptionError y el archivo /etc/yum.repos.d/gdch.repo.

Solución: Solo si has confirmado que el archivo está dañado, elimina 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 respuesta predefinida se queda atascada en la condición NodeOSInPlaceUpgradePostProcessingCompleted

Versiones: 1.13.5

Síntomas: durante la actualización a la versión 1.13.5, el NodeUpgradeTask CR se queda bloqueado en la condición NodeOSInPlaceUpgradePostProcessingCompleted.

Comprueba si el os-artifact-collectortrabajo correspondiente se ha completado. Si el trabajo se queda bloqueado 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:

  1. Elimina el trabajo o el pod para forzar un nuevo intento.

NodeUpgradeTask CR se queda bloqueado en la condición NodeBIOSFirmwareUpgradeCompleted

Versiones: 1.13.5

Síntomas: durante la actualización a la versión 1.13.5, el NodeUpgradeTask CR se queda bloqueado en la condición NodeBIOSFirmwareUpgradeCompleted.

Comprueba si la condición NodeBIOSFirmwareUpgradeCompleted correspondiente está atascada y se muestra la siguiente condición:

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

Solución alternativa:

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

La actualización del clúster está bloqueada porque un nodo no ha podido entrar en el modo de mantenimiento

Versiones: 1.13.5, 1.13.6 y 1.13.7

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

El clúster muestra que MaintenanceMode tiene el valor true, pero Status se queda en false al ejecutar 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:

Asigna el valor KUBECONFIG al archivo kubeconfig del clúster que contiene el nodo que no se va a drenar. 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 la raíz inicial organizationupgrade

Versiones: 1.13.3

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

Solución:

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

  1. Si el alias no se ha declarado, ejecuta lo siguiente:

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

  2. Pausa el subcomponente y reduce la escala de 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

  3. Una vez que se haya completado la actualización del clúster, reduce la escala de la implementación:

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

El subcomponente obj-syslog-server no se reconcilia en la organización raíz

Versiones: 1.13.3, 1.13.4, 1.13.5 y 1.13.6

Síntomas: durante la actualización a la versión 1.13.x, se detecta que el subcomponente obj-syslog-server está en 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 estar en buen estado, elimina el volumeMounts innecesario.

  1. Edita el despliegue actual:

    export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

    kubectl edit deployments syslog-server -n istio-system

  2. Elimina los volumeMounts que no sean necesarios en el spec.containers.volumeMounts. Elimina las siguientes rutas 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

  3. Aplica los cambios y el subcomponente volverá a ReconciliationCompleted cuando se hayan aplicado.

La actualización de ABM o de nodos se queda atascada en maintenanceMode false

Versiones: 1.13.4

Síntomas: El nodo se queda bloqueado en la actualización del clúster de Anthos Bare Metal y no entra en modo de mantenimiento.

Comprueba el elemento BareMetalMachine en un nodo de 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:

Reinicia el anthos-cluster-operator para propagar el BMM.MaintenanceMode:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

Error al actualizar el complemento atat-webhooks de una organización de cliente

Versiones: 1.13.5

Síntomas: la actualización del complemento atat-webhooks no se puede recuperar:

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

Comprobar 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:

  1. Hacer una copia de la cartera actual:

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. Cambiar la fecha de 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, elimina la condición .Metadata.Finalizers de la cartera activa antes de eliminar la cartera. La condición podría tener este aspecto:

    │     portfolio.finalizers.atat.config.google.com

  3. Vuelve a aplicar el archivo YAML copiado:

    kubectl apply -f portfolio-org-1

  4. Vuelve a comprobar las fechas para asegurarte de que tanto las carteras como el mapa de configuración se hayan actualizado.

  5. Si el trabajo no se recupera, elimina el trabajo atat-webhooks-parameters que ha fallado y se recuperará. Espera a que se complete:

    kubectl delete jobs -n org-1 atat-webhooks-parameters

Se produce un error en la comprobación posterior al vuelo o en la comprobación de actualización debido a errores de DeadlineExceeded o BackoffLimitExceeded.

Versiones: 1.13.8

Síntomas:

Al actualizar de la versión 1.13.7 a la 1.13.8, las comprobaciones posteriores al vuelo siguen pendientes y muestran errores 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:

Identifica dónde fallan los trabajos:

  1. Comprueba si los trabajos fallan durante las comprobaciones preparatorias o posteriores:

    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}'

  2. 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}'

  3. Elimina los trabajos:

    kubectl delete jobs -n gpc-system CHECK_NAME

Las comprobaciones de actualización incluyen resultados irrelevantes para el nivel de comprobación

Versiones: 1.13.x

Síntomas:

Las comprobaciones de actualización de la organización pueden fallar debido a que se han incluido resultados incorrectos de otros niveles. Por ejemplo, las comprobaciones de la organización raíz pueden mostrar resultados de la organización de inquilino, o las comprobaciones de la organización de inquilino pueden mostrar resultados del clúster de usuarios.

Ejemplo de registros de errores de comprobaciones 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:

Para omitir por completo las comprobaciones preparatorias o posteriores, usa lo siguiente:

Solicitud preparatoria:

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 tramo:

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 preentrenadas muestran el estado Enabling en la interfaz de usuario

Versiones: 1.13.1

Síntomas: el MonitoringTarget muestra el estado Not Ready cuando se están creando clústeres de usuarios, lo que provoca que las APIs preentrenadas muestren continuamente el estado Enabling en la interfaz de usuario.

Solución:

  1. Abre el menú de tu navegador Chrome (icono de tres puntos).
  2. Haz clic en Más herramientas > Herramientas para desarrolladores para abrir la consola.
  3. Haz clic en la pestaña Red de la consola.
  4. Busca las solicitudes de ai-service-status.
  5. Haz clic en la pestaña Respuesta de una solicitud ai-service-status para ver el contenido de esa solicitud.
  6. Comprueba que todo esté listo, excepto los componentes MonitoringTarget y LoggingTarget.

La función de API preentrenada streaming_recognize de Speech-to-Text falla

Versiones: 1.13.3

Síntomas: Al llamar a la función de la API preentrenada streaming_recognize de Speech-to-Text, un problema con la biblioteca de cliente provoca 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 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)

Haz los cambios siguientes:

La secuencia de comandos de Python introduce las siguientes diferencias entre las funciones streaming_recognize y recognize para que funcione la solución alternativa de 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: client.SpeechClient() devuelve el cliente en lugar de speech_v1p1beta1.SpeechClient().

No se pueden inicializar el pod y el servicio del frontend de traducción

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

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

Solución:

Elimina el secreto del clúster del sistema:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

Sustituye SYSTEM_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster del sistema.

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

No se admite el sondeo del estado de los trabajos en la API batchTranslateDocument

Versiones: 1.13.3

Síntomas: Vertex AI no admite las operaciones GET y LIST en las APIs del servicio Translation. Al llamar a la API Translation BatchTranslateDocument, se devuelve una operación de larga duración similar a la del 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 APIP (autorización) que te impide llamar al endpoint directamente. Los endpoints no admiten la comprobación del estado de los trabajos y no puedes realizar operaciones GET en la operación de larga duración debido a la limitación de la APIP.

Solución alternativa: Como operador de aplicaciones, revisa el estado del trabajo consultando tu carpeta s3_destination con regularidad y busca un archivo de salida de trabajo recién creado. Si la carpeta contiene el archivo de salida, significa que el trabajo se ha completado correctamente.

Las solicitudes de batchTranslateDocument pueden provocar problemas de rendimiento

Versiones: 1.13.3

Síntomas: El servicio de traducción de documentos por lotes lee uno o varios archivos introducidos por el usuario y escribe los archivos de salida temporales de procesamiento y traducción en StorageGRID. Se crea un nuevo cliente curl para cada acción de lectura y escritura porque no se puede reutilizar el cliente.

Los clientes de S3 curl del archivo binario son de un solo uso, lo que significa que cada cliente solo puede realizar una acción de lectura y escritura en los contenedores 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 los contenedores.

Sin embargo, no es la opción más adecuada para los clientes de curl. Esto podría provocar los siguientes problemas:

  • Rendimiento degradado: aumento de la latencia y disminución del rendimiento
  • Agotamiento de recursos: sobrecarga de memoria y CPU, y agotamiento de sockets
  • Sobrecarga del servidor: limitación de frecuencia o restricción

La consola de GDC muestra un estado incoherente después de habilitar las APIs preentrenadas

Versiones: 1.13.3

Síntomas: Cuando habilitas por primera vez las APIs preentrenadas, la consola de GDC puede mostrar un estado incoherente al cabo de unos minutos en el servicio que has habilitado. La consola de GDC cambia el estado Enabling a Disabled y vuelve a mostrar el botón Habilitar en la interfaz de usuario, aunque el servicio se esté habilitando.

Solución alternativa: el estado se vuelve coherente al cabo 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 comprueba el estado de la solicitud ai-service-status. La carga útil debe mostrar que el operador de nivel 2 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 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 unos 30 minutos en completarse.

Este problema se debe a una limitación de los contenedores de traducción.

Solución alternativa: divide las solicitudes de traducción para que tengan menos de 250 caracteres. Un intervalo de entre 200 y 250 caracteres es adecuado para todos los idiomas. No es necesario hacer nada más para mitigar el problema si una solicitud larga falla en los pods.

GPUAllocation para el clúster de servicios compartidos no está configurado correctamente

Versiones: 1.13.3

Síntomas: No se pueden programar cargas de trabajo de Vertex AI debido a la falta de recursos de GPU suficientes. Por ejemplo, si no puedes ver o habilitar los endpoints de servicio de Vertex AI, puede deberse a que no tienes suficientes recursos de GPU.

Este problema de recursos puede deberse a que algunos de los recursos de GPUAllocation situados en el clúster de servicios compartidos no tienen la siguiente anotación:

processed: "true"

Solución:

  1. Sigue las instrucciones de IAM-R0004 para generar el archivo kubeconfig de g-ORG_NAME-shared-service-cluster.

  2. Lista todas las asignaciones de GPU del clúster de servicios que no tengan 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 debería ser similar al siguiente:

    zi-ad-bm08

  3. En el recurso GPUAllocation que no se ha asignado, ábrelo en un editor:

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. Edita la asignación de GPU en función del número total de asignaciones de GPU presentes en el clúster de servicio:

    • Si solo hay un recurso personalizado de asignación de GPU, añádele 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", añádele 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", añádele 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

  5. Guarda los cambios en el recurso personalizado GPUAllocation y confirma que su estado de asignación se ha actualizado a true:

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

    El resultado debería ser similar al siguiente:

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

Al actualizar de la versión 1.9.x a la 1.13.3, el controlador OCLCM muestra errores

Versiones: 1.13.3

Síntomas: Al actualizar de la versión 1.9.x a la 1.13.3, es posible que el controlador de gestión del ciclo de vida de los componentes operativos (OCLCM) de los subcomponentes de Vertex AI muestre errores. Este problema se debe a un error en 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.

Estos 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 solucionar este problema, debe quitar manualmente los componentes de Vertex AI afectados del clúster de administrador de la organización. A continuación, la nueva versión de Vertex AI basada en OCLCM los vuelve a instalar.

Elimina manualmente los componentes de Vertex AI afectados en el clúster de administrador de la organización:

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

Haz los cambios siguientes:

  • ORG_ADMIN_CLUSTER_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador de la organización.
  • NAMESPACE: el espacio de nombres del componente de Vertex AI que quieras quitar. Si el componente no tiene un espacio de nombres, quita -n NAMESPACE del comando.
  • COMPONENT_NAME: el nombre del componente de Vertex AI que quieres quitar.

En el siguiente ejemplo se muestra cómo quitar el componente aip-l1operator-deployment que se encuentra en el espacio de nombres ai-system del clúster de administrador de la organización:

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

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

Versiones: 1.13.3

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

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

batchTranslateDocument solicita que se devuelva un error 503

Versiones: 1.13.3

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

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

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

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

    Sustituye ORG_ADMIN_NAMESPACE por el espacio de nombres del clúster de administrador de la organización.

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

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

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

Servicios preentrenados de Vertex AI no 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: Añade más nodos de trabajador al grupo predeterminado y expulsa los pods de 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 formato

Versiones: 1.13.1 y 1.13.3

Síntomas: Cuando se importan imágenes de máquinas virtuales locales mediante la CLI de gdcloud compute images import, el estado de la importación se queda en WaitingForTranslationVM o ImportJobNotCreated. Esto se debe a que el disco temporal creado para traducir o importar usa el mismo tamaño que la imagen qcow2 o sin formato, pero LUKS añade una sobrecarga de unos pocos MiBs que provoca que falle el aprovisionamiento del disco.

Solución alternativa:

Crea un nuevo VirtualMachineImageImport manualmente con el mismo nombre de imagen, pero con un spec.minimumDiskSize más grande.

Por ejemplo, si este fuera el comando usado para importar la imagen:

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

Si el VirtualMachineImageImport 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 se debe sustituir por 21 Gi.

Sustituye los valores de marcador de posición en función de cómo se haya llamado a la CLI.

  1. 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 la salida de la consola pase de Uploading image to .. a Image import has started for ..., pulsa Ctrl+C para que la imagen local se suba al almacenamiento de objetos y se conserve el VirtualMachineImageImport para poder crear una nueva.

  2. 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: al aprovisionar un disco a partir de una imagen personalizada, el minimumDiskSize podría estar demasiado cerca del tamaño virtual, lo que provocaría que el aprovisionamiento del disco fallara. El disco de la VM está en estado pendiente, pero nunca se aprovisiona.

Solución: crea un disco manualmente 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 y muestra 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

Sustituye KUBECONFIG por la ruta al archivo kubeconfig del clúster.

Obtendrá 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 provoca 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 hardware desnudo y las GPUs de ese nodo no se configuran en el modo de máquina virtual para que las consuman el clúster de 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 servicio o el clúster de usuarios para resolver este problema.

Solución alternativa para el clúster del sistema:

Sigue estos pasos para solucionar el problema en el clúster del sistema:

  1. Define la variable de entorno KUBECONFIG con la ruta al archivo kubeconfig del clúster del sistema. Para obtener más información, consulta el runbook IAM-R0004.

  2. Identifica el nodo que tiene el problema:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    La salida debe mostrar el nombre del nodo y la dirección IP del nodo de Kubernetes.

    Si hay varios nodos, sigue los pasos en todos ellos. En este caso, el resultado es similar al siguiente ejemplo:

    Node:                 yy-ab-bm04/172.20.128.26

  3. Define la variable de entorno NODE_NAME con el nombre del nodo. Por ejemplo:

    export NODE_NAME=yy-ab-bm04

  4. Establece una conexión SSH con el nodo. Para obtener más información, consulta el runbook PLATAUTH-G0001.

  5. Verifica que el nodo tenga GPUs:

    nvidia-smi -L

    La salida debe mostrar 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)

  6. Habilita el modo de persistencia en las GPUs:

    nvidia-smi -pm 1

    De esta forma, los controladores de NVIDIA siempre se cargan para que el complemento del dispositivo no se agote.

    La salida debe tener el siguiente aspecto:

    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.

  7. Cierra la sesión SSH:

    exit

  8. Comprueba que el complemento del dispositivo se esté ejecutando consultando el DaemonSet:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. 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

    La salida debe tener el siguiente aspecto:

    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 servicio o el clúster de usuarios:

Sigue estos pasos para solucionar el problema en el servicio o el clúster:

  1. Define la variable de entorno KUBECONFIG con la ruta al archivo kubeconfig en el clúster de servicio o de usuario. Para obtener más información, consulta el runbook IAM-R0004.

  2. Identifica el nodo que tiene el problema:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    La salida debe mostrar el nombre del nodo y la dirección IP del nodo de Kubernetes.

    Si hay varios nodos, sigue los pasos en todos ellos. En este caso, el resultado es similar al siguiente ejemplo:

    Node:                 vm-948fa7f4/172.20.128.21

  3. Define la variable de entorno NODE_NAME con el nombre del nodo. Por ejemplo:

    export NODE_NAME=vm-948fa7f4

  4. Establece una conexión SSH con el nodo. Para obtener más información, consulta el runbook PLATAUTH-G0001.

  5. Verifica que el nodo tenga GPUs:

    nvidia-smi -L

    La salida debe mostrar 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)

  6. Habilita el modo de persistencia en las GPUs:

    nvidia-smi -pm 1

    De esta forma, los controladores de NVIDIA siempre se cargan para que el complemento del dispositivo no se agote.

    La salida debe tener el siguiente aspecto:

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. Cierra la sesión SSH:

    exit

  8. Comprueba que el complemento del dispositivo se esté ejecutando consultando el DaemonSet:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. 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

    La salida debe tener el siguiente aspecto:

    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:

  1. Busca el VirtualMachineInstance y elimínalo.
  2. Reinicia una VM.

No se ha encontrado el espacio de trabajo de los informes de volumen de datos

Versiones: 1.13.3 y 1.13.4

Síntomas: al crear un disco de VM, el volumen de datos se indica como creado correctamente:

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

Sin embargo, un pod de importación, como importer-gdc-vm-disk-vm-ce34b8ea-disk, puede fallar en bucle con un mensaje como este:

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: Elimina el pod de importación después de confirmar que el estado del volumen de datos es Succeeded.

Las VMs de los proyectos con nombres de más de 45 caracteres permanecen en estado detenido

Versiones: 1.13.5

Síntomas: al crear 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 45 caracteres como máximo.

Falta la asignación de GPU en el clúster de servicio

Versiones: 1.13.5

Síntomas: falta el GPUAllocation en el clúster de servicios compartidos de gpu-org. Es posible que veas un mensaje al obtener las asignaciones de GPU:

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

La salida tiene este aspecto:

No resources found

Solución:

  1. Añade un taint al nodo de GPU:

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. Quita el taint para permitir la programación del pod virt-launcher de la VM.

No se puede programar una VM de trabajador de clúster de servicio compartido

Versiones: 1.13.6

Síntomas: una VM de trabajador de Kubernetes no ha podido programarse debido a que no tiene suficientes recursos de CPU en el nodo designado, a pesar de que hay GPUs disponibles. Puede 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:

  1. Detén manualmente las VMs que no sean de GPU para liberar recursos de CPU.
  2. Una vez que se haya programado la VM pendiente, inicia las VMs sin GPU.