Problemas conhecidos do Google Distributed Cloud air-gapped 1.13.x

Artifact Registry

Erro de conciliação do subcomponente sar-failoverregistry

Versões: 1.13.1, 1.13.3 e 1.13.4

Sintomas: quando cria o cluster de administrador raiz com o comando gdcloud system admin-cluster install, a operação pode falhar se houver uma longa lista de servidores durante o arranque. A mensagem de saída de erro é a seguinte:

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

Solução alternativa: para mitigar este problema, siga estes passos:

  1. No mesmo cluster do Kubernetes que o subcomponente, liste os servidores e confirme que cada recurso personalizado do servidor tem uma etiqueta com a chave cluster.private.gdc.goog/inventory-machine:

    kubectl get servers -n gpc-system

  2. Encontre o recurso personalizado do componente semelhante ao seguinte:

      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. No recurso personalizado do componente System Artifact Registry (SAR), adicione o seletor de etiquetas nos runtimeParameterSources servidores para sar-failover-registry:

    1. Veja o recurso server existente:

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

    2. Atualize o campo de servidores no recurso personalizado do 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. Verifique se as alterações no componente SAR no passo anterior são propagadas para o subcomponente sar-failverregistry:

    1. Obtenha os detalhes do componente SAR:

      kubectl get component | grep sar

    2. Obtenha os detalhes do componente sar-failoverregistry:

      kubectl get subcomponent sar-failoverregistry -n root

      Use a flag -n para especificar o espaço de nomes.

Cópia de segurança e restauro

As capturas instantâneas falham devido à falta de espaço no volume

Versões: todas as versões de 1.13.x

Sintomas: existe um problema intermitente com a cópia de segurança do volume persistente que pode afetar os fluxos de trabalho das tarefas de cópia de segurança periódicas. Para alguns volumes com uma taxa de alteração elevada, as capturas instantâneas de volume tiradas para cópias de segurança em curso podem fazer com que o volume fique sem espaço, o que, por sua vez, coloca o volume no modo só de leitura.

Solução alternativa: para evitar um potencial impacto nas cargas de trabalho de produção, siga os passos no manual de procedimentos BACK-R0104. Em alternativa, também pode remover as capturas de ecrã acumuladas seguindo o manual de procedimentos BACK-R0106.

Os pods do agente e do plano de controlo são reiniciados devido à falta de memória

Versões: todas as versões de 1.13.x

Sintomas: os pods do agente e do plano de controlo podem ser reiniciados se ficarem sem memória.

Solução alternativa: aumente a memória para os pods do painel de controlo e do agente seguindo as instruções no manual de procedimentos BACK-R0005. Aumente a memória dos pods para 2 GiB.

A cópia de segurança falha para o instantâneo de PVC

Versões: todas as versões de 1.13.x

Sintomas: ocorreram falhas de cópia de segurança devido à ultrapassagem do limite de instantâneos do ONTAP de 1023 por recurso de PersistentVolumeClaim (PVC).

Solução alternativa: para mitigar este problema, siga estes passos:

  1. Atualize o plano de cópia de segurança para que os limites nunca sejam atingidos. Configure um plano de cópia de segurança para fazer uma cópia de segurança a cada hora ou reduza o valor de deleteLockDays para três, de modo que o número de resumos não aumente para além de 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

    Substitua o seguinte:

    • LOCK_DAYS: bloqueia a eliminação da cópia de segurança durante o número de dias especificado após a criação da cópia de segurança. Use os seguintes valores:

      • Se o campo volumeStrategy estiver definido com um valor de LocalSnapshotOnly, use um valor de 2.
      • Se o campo volumeStrategy estiver definido com um valor de ProvisionerSpecific, use um valor de 7.

    • RETENTION_DAYS: elimina as cópias de segurança após o número de dias especificado após a criação da cópia de segurança. Se o campo volumeStrategy estiver definido com um valor de LocalSnapshotOnly, use um valor inferior a 3.

  2. Para eliminar manualmente instantâneos excessivos do seu ambiente através de comandos de eliminação de instantâneos de volumes, siga estes passos:

    1. Inicialize as variáveis:

      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

      Substitua o seguinte:

      • ORG_NAME: o nome da sua organização.
      • PVC_NAME: o nome do recurso PVC relacionado com o plano de cópia de segurança.

    2. O NetApp ONTAP é um sistema operativo usado para administrar o armazenamento do GDC. Obtenha acesso ao 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. Apresente todas as imagens instantâneas do recurso PVC selecionado:

      ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list

      Use a palavra-passe do passo anterior para iniciar sessão na máquina no endereço IP definido pela variável MGMT_IP.

    4. Encontre o PVC com o número mais elevado de capturas instantâneas:

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

    5. Defina o nome do recurso PVC para o que tem uma contagem elevada de resumos:

      export PV_NAME=

    6. Elimine o instantâneo do recurso PVC que contém uma quantidade elevada de instantâneos. O limite para o número de instantâneos de um recurso PVC é 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. Inicie sessão no ONTAP e execute estes comandos para eliminar a captura instantânea:

      echo $PASSWORD

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

    8. Execute os comandos indicados no passo anterior para eliminar o instantâneo. Quando terminar, saia da sessão de SSH

  3. Repita os passos de eliminação até que todas as capturas de ecrã PVC ofensivas sejam limpas.

Restaurar a partir de uma cópia de segurança incompatível com a quota de SVM

Versões: 1.13.1

Sintomas: o problema é uma incompatibilidade entre as funcionalidades do NetApp. Esta incompatibilidade impede a entrega da quota do inquilino e a implementação bem-sucedida das restaurations. O problema só ocorre quando restaura uma cópia de segurança para um cluster de utilizadores com restrições de quota.

Solução alternativa: se este problema ocorrer, a restauração falha com a mensagem de erro DP volumes are not supported on storage-limit enabled Vserver e o operador de infraestrutura (IO) tem de desativar a quota para esse cluster de utilizadores e reiniciar o processo de restauração. Assim que o restauro estiver concluído, o IO tem de reativar as quotas de inquilinos e o sistema deve continuar a funcionar conforme previsto. Consulte o runbook FILE A0030 para mais detalhes.

Faturação

As métricas de faturação não são apresentadas corretamente no painel de controlo de faturação

Versões: 1.13.1

Sintomas: as métricas de faturação não são emitidas corretamente para o Cortex devido à falta de MetricsProxySidecar.

Solução alternativa: crie um recurso billing-monetizer MetricsProxySidecar. Em seguida, execute um script para atualizar o metricExpression.

  1. Exporte a seguinte variável kubeconfig:

    export KUBECONFIG=KUBECONFIG_PATH

    Substitua a variável KUBECONFIG_PATH pelo caminho para o ficheiro kubeconfig do cluster de administrador da organização. Siga os passos no manual de serviço IAM-R0101 para gerar o ficheiro kubeconfig necessário para esta solução alternativa.

  2. Crie um recurso billing-monetizer MetricsProxySidecarpara os espaços de nomes billing-system e 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. Execute o seguinte script para atualizar o metricExpression. Esta ação remove o container_name="monetizer" do skuconfig, que inclui 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

O utilizador não consegue criar BillingAccountBinding devido a erros no webhook de validação

Versões: 1.13.0, 1.13.1, 1.13.3

Sintomas: o erro está na lógica do webhook de validação BillingAccountBinding. Se um utilizador tentar criar um recurso BillingAccountBinding, o webhook devolve o erro permission denied.

Solução alternativa: para criar recursos BillingAccountBinding, notifique o operador da infraestrutura e crie os recursos correspondentes através da IAC.

Armazenamento em bloco

Pods do Grafana bloqueados no estado Init devido a erros de montagem de volume.

Versões: 1.13.3

Sintomas:

Os pods do Grafana nos espaços de nomes anthos-identity-service-obs-system e platform-obs-obs-system estão bloqueados no estado Init devido a erros de montagem de volume. A mensagem de erro nos registos do kubelet indica um problema de multi-attach. O problema tem origem num erro no Trident, em que não identifica nem valida corretamente o dispositivo subjacente para mapeamentos LUKS, o que leva a um erro de ligação múltipla.

Solução alternativa:

Verifique se o PVC tem um deletionTimestamp. Se não existir deletionTimestamp (migração de pods), siga estes passos:

  1. Verifique o VolumeAttachment do PVC para identificar onde o volume está atualmente associado.
  2. Isolar o Nodes no cluster que não corresponda a este valor.
  3. Elimine o Pod com falhas. Isto deve fazer com que seja migrado novamente para o Node original.

Após a verificação, se existir um deletionTimestamp (eliminação de volume), siga estes passos:

  1. Verifique o VolumeAttachment do PVC para identificar onde o volume está atualmente associado.

  2. No Node, apresente o conteúdo do respetivo ficheiro de acompanhamento:

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

  3. Valide se o dispositivo LUKS encontrado no campo devicePath do resultado do ficheiro de acompanhamento está efetivamente fechado. Este caminho não deve existir neste ponto:

    stat DEVICE_PATH

  4. Valide se o número de série está atualmente mapeado para algum dispositivo de vários caminhos.

    1. Copie o valor no campo iscsiLunSerial do ficheiro de acompanhamento.

    2. Converta este valor no valor hexadecimal esperado:

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. Com este novo valor, verifique se a entrada de vários caminhos ainda existe:

      multipath -ll | grep SERIAL_HEX

    4. Se não existir, elimine o ficheiro de acompanhamento.

    5. Se existir, é apresentado um valor hexadecimal ligeiramente mais longo do que o pesquisado, denominado multipathSerial. Execute o seguinte e encontre os dispositivos de bloqueio:

      multipath -ll MULTIPATH_SERIAL

    6. Em seguida, execute os seguintes comandos, sendo que o último é executado exclusivamente para cada dispositivo de blocos:

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

Os pods do iniciador de máquinas virtuais não conseguem mapear volumes

Versões: 1.13.1

Sintomas:

Pode ver um aviso com o seguinte aspeto:

 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 o problema, siga estes passos:

  1. Certifique-se de que os volumes e os pods estão no mesmo nó.
  2. Encontre o nó em que os pods estão e verifique o respetivo estado.
  3. Verifique a conetividade do nó.
  4. Verifique o IPSEC.
  5. Verifique o multipath para ver se existe um zombie.

  6. Verifique os registos do trident para saber que passo no fluxo de CSI pode ter introduzido este zombie:

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

Solução alternativa: para contornar este problema, siga os passos nos seguintes runbooks:

  1. Para problemas relacionados com nós, consulte o manual de procedimentos FILE-R0010.
  2. Para problemas com o IPSEC, consulte o manual de instruções FILE-R0007.
  3. Para problemas com LUNs inativos, consulte o manual de procedimentos FILE-R0020.
  4. Para problemas com LUNs de zombies super, consulte o manual de procedimentos FILE-R0021.

Falhas relacionadas com o armazenamento

Versões: 1.13.1

Sintomas: as falhas relacionadas com o armazenamento podem ser identificadas através do acionamento do alerta file_block_zombie_luns_present ou da falha na apresentação do pod devido a um problema na chamada MountVolume que persiste durante mais de um ciclo de conciliação. O tempo limite pode ser de cerca de dois minutos. A repetição da mesma falha indica que algo falhou no caminho NodeStage ou NodePublish CSI e requer uma solução alternativa. A única exceção é a indicação de uma falha de limite de tempo. Pode ver algumas falhas como esta:

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

Solução alternativa:

  1. Para ver se o Node que tem o Pod pode ser corrigido para o PVC com falhas, isole o nó atual onde o pod está agendado e elimine o Pod:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    O Pod deve ser agendado para um Node completamente diferente, o que faz com que o Trident seja forçado a executar completamente o NodeStage, o NodePublish, o NodeUnpublish e o NodeUnstage. Isto pode não corrigir o volume imediatamente, porque podem existir sessões ainda abertas para este volume no Node original.

  2. Depois de concluir o passo anterior, remova a restrição do nó em questão:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. Se continuarem a existir falhas, isole todos os outros Nodes, exceto aquele em que o Pod foi originalmente agendado, e elimine o Pod. Isto deve fazer com que o Pod seja iniciado no Node original, onde os dispositivos existentes podem permanecer.

  4. Depois de concluir o passo anterior, remova a restrição dos nós em questão.

  5. Como último recurso para guardar o PV e os respetivos dados, o Node pode ser reiniciado para limpar as falhas de vários caminhos, udev e devmapper no Node. Embora este passo seja bastante difícil, é o que tem maior probabilidade de sucesso.

  6. Se as mitigações anteriores não resolverem o problema com o volume, isto indica que os dados foram danificados e são efetivamente inutilizáveis. A única opção restante para continuar com o comportamento pretendido do contentor é eliminar os PV, PVC e Pod com falhas, seguido de um reinício do nó onde o PV estava alojado. Esta ação resulta na perda total de dados do que já foi escrito no volume.

Volumes persistentes criados com tamanho incorreto

Versões: 1.13.1

Sintomas: as cargas de trabalho com um volume persistente são criadas com cerca de 16 MiB a menos. Se as cargas de trabalho dependerem exatamente do tamanho anunciado por um volume persistente, a pequena discrepância faz com que a carga de trabalho falhe ao expandir ou aprovisionar. Este problema é mais provável para volumes persistentes aprovisionados com uma classe de armazenamento standard-block, em oposição aos aprovisionados com uma classe de armazenamento standard-rwo. Este problema pode ocorrer em volumes persistentes com uma classe de armazenamento standard-rwo que usa o modo volumemode:block.

Solução alternativa: atribua um volume persistente que seja, pelo menos, 16 MiB maior do que o que é realmente necessário.

Não é possível eliminar a máquina virtual de armazenamento

Versões: 1.13.1

Sintomas: o StorageVirtualMachine pode apresentar um erro 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"

Solução alternativa: elimine o finalizador de StorageVirtualMachines no espaço de nomes da organização.

A desativação da organização não limpa os recursos

Versões: 1.13.1

Sintomas: quando desativa uma organização, ficam alguns StorageVirtualMachines recursos, por exemplo:

  • 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

Solução alternativa: elimine estes recursos.

Falha na conciliação da eliminação

Versões: 1.13.1

Sintomas: quando um StorageVirtualMachine é eliminado antes da limpeza dos clusters que dependem desse StorageVirtualMachine, existe a possibilidade de ocorrer um problema na limpeza dos volumes persistentes (PV) de alguns clusters. Especificamente, quando os PVs encriptados com LUKS não são limpos, o respetivo segredo impede a eliminação do espaço de nomes em que se encontram. Pode ver um aviso nos registos semelhante ao seguinte:

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

Solução alternativa: elimine o finalizador dos segredos g-luks-gdc-vm-disk-* no espaço de nomes do cluster de serviço.

Atualização do Bare Metal bloqueada

Versões: 1.13.1, 1.13.5, 1.13.6

Sintomas: as tarefas do Ansible ficam bloqueadas na recolha de factos quando existem LUNS inativos. A execução do comando multipath -ll pode apresentar o seguinte 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

Também pode ver a seguinte mensagem de erro:

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

Solução alternativa: verifique a conetividade SSH com o nó de destino e, em seguida, use o seguinte runbook: FILE-R0020.

Erro de anexos múltiplos do Trident

Versões: 1.13.3

Sintomas: os pods e os PVCs podem ficar presos em nós diferentes com o pod preso na inicialização à espera do PVC.

Solução alternativa:

  1. Verifique se o PVC tem um deletionTimestamp:

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

  2. Se não existir deletionTimestamp (migração de pods):

    1. Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado.
    2. Isolar os nós no cluster que não correspondem a este valor.
    3. Elimine o pod com falhas. Esta ação migra o POD de volta para o nó original.

  3. Se houver um deletionTimestamp (Volume deletion):

    1. Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado.
    2. No nó, produza o conteúdo do respetivo ficheiro de acompanhamento, /var/lib/trident/tracking/PVC_NAME.json.
    3. Valide se o dispositivo LUKS encontrado no campo devicePath do resultado do ficheiro de acompanhamento está efetivamente fechado. Este caminho não deve existir neste ponto: stat DEVICE_PATH. Se o caminho ainda existir, está a ocorrer um problema diferente.
    4. Valide se o número de série está mapeado para algum dispositivo de vários caminhos.
    5. Copie o valor no campo iscsiLunSerial do ficheiro de acompanhamento.
    6. Converta este valor no valor hexadecimal esperado: echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. Com este novo valor, verifique se a entrada de vários caminhos ainda existe: multipath -ll | grep SERIAL_HEX.
    8. Se não existir, elimine o ficheiro de acompanhamento.

    9. Se existir, é apresentado um valor hexadecimal serial ligeiramente mais longo do que o que pesquisou. Registe este valor como MULTIPATH_SERIAL. Execute multipath -ll MULTIPATH_SERIAL e veja uma mensagem como esta:

      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. Execute os seguintes 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. Execute o último comando de forma exclusiva para cada dispositivo de bloco.

Erro na configuração do IPsec

Versões: 1.13.4

Sintomas: a configuração IPsec do ONTAP encontra um erro devido a uma chave pré-partilhada (PSK) inválida que contém 0X, que é interpretada como uma string hexadecimal.

Pode ver um aviso como este:

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

Solução alternativa:

  1. Obtenha as associações de encriptação de armazenamento:

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    Procure a entrada com Ready=False e anote o nome do PRESHAREKEY. O resultado pode ter o seguinte aspeto:

    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á a executar uma organização de GPU, por isso, elimine-a secrets gpc-system/vm-5a77b2a2-pre-shared-key em gpu-org-admin.

  3. Aguarde que o sistema recrie secret/vm-5a77b2a2-pre-shared-key.

  4. Procure um trabalho com um padrão como gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Tenha em atenção que os últimos 8 carateres são gerados aleatoriamente. Depois de a chave estar novamente disponível, elimine a tarefa, como jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl em gpu-org-admin.

A máquina virtual de armazenamento não foi criada

Versões: 1.13.5

Sintomas: o serviço Harbor em gpu-org não é iniciado devido a um problema com o aprovisionamento de volumes. Este problema é causado pelo file-storage-backend-controllerpod que faz referência a uma máquina de inventário inexistente.

Pode ver um erro do controlador de armazenamento como este, que indica que o InventoryMachine não foi encontrado:

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

Solução alternativa:

  1. Elimine o pod file-storage-backend-controller.
  2. Permitir que o controlador de armazenamento obtenha novamente as máquinas de inventário presentes.

As redes intercluster de armazenamento não são reconciliadas

Versões: 1.13.5, 1.13.6

Sintomas: após uma atualização, o recurso personalizado StorageCluster no cluster de administrador raiz não fica pronto devido a uma configuração incorreta nas sub-redes entre clusters na especificação. O cluster de armazenamento comunica Not Ready e inclui um evento com este erro:

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

Se este erro ocorrer, a reivindicação de sub-rede entre clusters usada pelo cluster de armazenamento não inclui o campo kind na referência. Ao inspecionar o recurso personalizado StorageCluster, encontra uma referência de reivindicação de sub-rede entre clusters com apenas um nome e um espaço de nomes, 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

Solução alternativa: atualize a especificação StorageCluster para incluir o campo kind: SubnetClaim na referência da reivindicação de sub-rede:

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

Depois de atualizar a especificação StorageCluster, reinicie a implementação file-storage-backend-controller e verifique se o cluster de armazenamento está pronto.

Gestão de clusters

A tarefa machine-init falha durante o aprovisionamento do cluster

Versões: 1.13.1

Sintomas:

  1. Durante o aprovisionamento do cluster, a tarefa machine-init do segundo nó do plano de controlo falha com a seguinte mensagem:

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

  2. Ver os registos:

    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"

    A saída mostra um resultado não vazio.

Solução alternativa:

  1. Ative ou desative a autorização de /etc/kubernetes/pki/etcd/ca.crt. Esta é uma operação muito sensível ao tempo. A mudança de autorização tem de ocorrer após a execução anterior da tarefa machine-init, mas antes da execução seguinte da tarefa machine-init, uma vez que machine-init substitui a autorização de volta para a raiz.

  2. Reinicie o etcd no segundo nó para recuperar o etcd no primeiro nó de um ciclo de falhas.

Depois de concluir estes dois passos, o kube-apiserver no primeiro nó começa a ser executado e a tarefa machine-init seguinte é bem-sucedida.

Sem conetividade do cluster de serviços ao contentor de armazenamento de objetos

Versões: 1.13.1

Sintomas: a ligação de um pod de base de dados em execução no cluster de serviço a um contentor de armazenamento de objetos no cluster de administração da organização falha.

Solução alternativa: siga as instruções no manual de procedimentos KUB-R0305.

A verificação prévia falha

Versões: 1.13.1

Sintomas: pode ver a seguinte mensagem no estado do objeto de cluster:

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

Também deve ver um objeto PreflightCheck correspondente com o mesmo nome e espaço de nomes que o objeto de cluster que está presente há várias horas, enquanto o erro ou a falha indicados no objeto PreflightCheck já não são um problema conhecido.

Solução alternativa: elimine o objeto PreflightCheck.

A criação do node pool de worker do cluster de utilizadores falha

Versões: 1.13.5

Sintomas: a criação do node pool do worker do cluster de utilizadores pode deixar de responder para um destes tipos de máquinas:

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

Solução alternativa: elimine esse conjunto de nós e volte a criá-lo selecionando outros tipos de máquinas disponíveis na lista pendente da IU de criação do cluster de utilizadores.

Os clusters de utilizadores, quando recriados, podem ficar presos na reconciliação devido a uma limpeza inadequada

Versões: 1.13.x

Sintomas: quando são criados grupos de utilizadores com o mesmo nome de um grupo que foi eliminado anteriormente, podem ficar presos em Reconciling indefinidamente com o estado a mencionar a fase de instalação do suplemento ONE.

Solução alternativa: desinstale o suplemento helm CLUSTER_NAME-abm-overrides e reinicie a implementação managed-adm-controller. Siga os passos detalhados em MKS-R0004.

Serviço de base de dados

Esta secção contém problemas conhecidos do serviço de base de dados.

Clonagem da base de dados do AlloyDB Omni bloqueada

Versões: todas as versões de 1.13.x

Sintomas: quando um utilizador clona um cluster do AlloyDB Omni a partir de um determinado momento, o cluster da base de dados clonado fica bloqueado com o erro DBSE0005 e não fica pronto. O recurso restore.alloydb correspondente está bloqueado na fase "ProvisionInProgress".

Solução alternativa: para contornar este problema, escolha cuidadosamente o momento a partir do COMPLETETIME das cópias de segurança bem-sucedidas.

Liste as cópias de segurança do AlloyDB Omni disponíveis para clonagem no servidor da API de gestão.

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

Exemplos 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

Escolha um valor COMPLETETIME como o momento específico para o clone. Tenha em atenção que a hora está no formato UTC.

A aplicação de IOPS afeta o desempenho do armazenamento

Versões: 1.13.1

Solução alternativa: para contornar este problema, siga uma destas opções:

  • Aumente o tamanho do armazenamento.
  • Substitua a quota de IOPS.

Erro de conciliação ao atualizar o subcomponente dbs-fleet

Versões: 1.13.3

Sintomas: quando atualiza a organização raiz de 1.13.1 para 1.13.3, pode ver um erro de conciliação. Verifique se existem erros de conciliação:

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

O erro pode ter o seguinte aspeto:

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

Solução alternativa: siga os passos no manual de procedimentos OCLCM-R0122.

A criação do DBCluster falha

Versões: 1.13.3

Sintomas: após a atualização para o 1.13.3, os novos DBclusters não são reconciliados, com o seguinte erro no 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>'

Solução alternativa

Verifique se existem localrollout CRs que terminam em cpa-v0.12.46 e cpa-v0.12.51 no cluster de administração da organização. Por exemplo:

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

Encontre e elimine localrollout CRs que terminem em cpa-v0.12.46, garantindo que outras localrollout CRs permanecem inalteradas.

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

Deve ser devolvida uma lista semelhante à seguinte:

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

Elimine cada um deles:

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

Verifique se os localrollout CRs que terminam em cpa-v0.12.51 ainda estão 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

As DNSSEC têm de ser explicitamente desativadas em resolved.conf

Versões: 1.13.1, 1.13.3 e 1.13.4

Sintomas: a resolução de DNS falha em nós bare metal ou de VM. Para confirmar que a resolução de DNS está a falhar, estabeleça uma ligação SSH ao nó afetado e execute systemctl status systemd-resolved. O resultado contém linhas como DNSSEC validation failed for question . IN SOA: no-signature.

Solução alternativa:

  1. Adicione a seguinte linha a /etc/systemd/resolved.conf no nó afetado.

    DNSSEC=false

  2. Reinicie o serviço systemd-resolved:

    systemctl restart systemd-resolved.service

Serviço portuário

Falha na criação do serviço Harbor

Versões: 1.13.6

Sintomas: a criação de uma instância do Harbor falha devido a uma incompatibilidade do espaço de nomes causada por uma limitação de comprimento no nome do ServiceIsolationEnvironment. Pode ver uma mensagem como esta:

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

Solução alternativa: encurte o nome da instância do Harbor para resolver o problema atual. Certifique-se de que o comprimento combinado de PROJECT_NAME e HARBOR_INSTANCE_NAME é inferior a 27 carateres.

A eliminação de instâncias do Harbor não elimina os espelhos do registo associados

Versões: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8

Sintomas: a eliminação de instâncias do Harbor não elimina os espelhos do registo associados. O conjunto de nós pode estar bloqueado num estado de Provisioning. Isto deve-se ao facto de os espelhos do registo criados pelo controlador do MHS não serem eliminados quando as instâncias do Harbor são eliminadas.

Solução alternativa: tem de remover manualmente os espelhos do registo. Para mitigar este problema, siga estes passos:

  1. Estabeleça ligação ao cluster de administração da organização. Para mais informações, consulte a arquitetura de cluster do GDC.

  2. Execute este script para remover todos os espelhos de registo que correspondam ao valor da variável de ambiente HARBOR_INSTANCE_URL de todos os clusters do Kubernetes que tenham a 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)

    Substitua HARBOR_INSTANCE_URL pelo URL da sua instância do Harbor.

Módulo de segurança de hardware

As licenças de avaliação desativadas do HSM ainda são detetáveis

Versões: 1.13.1, 1.13.3-1.13.11

Sintomas: devido a um problema conhecido existente no CipherTrust Manager, as licenças de avaliação desativadas continuam detetáveis e podem acionar avisos de expiração falsos.

Solução alternativa: consulte o artigo HSM-R0003 para validar as licenças normais ativas e eliminar as licenças de avaliação desativadas.

Fuga de descritores de ficheiros do anfitrião do HSM

Versões: 1.13.x

Sintomas: se os HSMs forem executados durante mais de 30 dias, uma fuga de descritores de ficheiros pode fazer com que o serviço host-daemon deixe de responder, o que resulta num erro ServicesNotStarted.

Solução alternativa: reinicie o serviço host-daemon. Para o fazer, peça ao seu operador de infraestrutura (IO) para estabelecer ligação ao HSM através do SSH como utilizador ksadmin e executar o seguinte comando:

sudo systemctl restart host-daemon

Se isso não funcionar, a sua IO pode reiniciar o HSM não saudável.

Os certificados de HSM expiraram

Versões: 1.13.11

Sintomas: quando atualiza uma organização, pode ver um aviso como este:

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

O org-1-system-cluster está bloqueado numa atualização da versão do ABM devido a certificados HSM (módulo de segurança de hardware) expirados.

Também pode ver um erro como o deste exemplo no servidor iLO, StorageGRID ou ONTAP do HPE:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Solução alternativa:

Alterne manualmente o certificado da CA de raiz e da interface Web com ksctl:

  1. Pausar todas as CRs HSM, HSMCluster e HSMTenant.

  2. Crie uma nova AC raiz com atributos copiados da antiga. Encontre o ID de CA antigo com o ksctl ca locals list. Um exemplo pode ter o seguinte aspeto:

    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. Assine automaticamente a nova AC com uma duração de um ano. Um exemplo pode ter o seguinte aspeto:

    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. Atualize a interface Web para usar esta nova CA para a geração automática de certificados. Um exemplo pode ter o seguinte aspeto:

    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. Gere um novo certificado de interface Web, assinado pela nova AC. A flag --url é o IP de gestão do HSM (de kubectl get hsm -n gpc-system). Um exemplo pode ter o seguinte aspeto:

    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. Neste momento, o openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text continua a apresentar o certificado antigo. Tem de reiniciar o HSM para obter o novo certificado.

    ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot

    Agora, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text mostra o novo certificado.

  7. Elimine a CA antiga do CR do HSM:

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

  8. Retome o HSM: 

    kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

    Certifique-se de que o HSM fica em bom estado.

  9. Repita estes passos para os outros dois HSMs. Já têm a nova AC raiz autocertificada porque a AC é partilhada entre HSMs num cluster. Ignore os passos 2 e 3, mas repita os passos 4 a 8.

  10. Siga a tarefa de esforço HSM T0008 de rotação de CA para automatizar a rotação de todos os certificados, mas ignore o passo Finalize a rotação adicionando uma nova anotação de rotação a hsmcluster, onde o ca-rotation-finalizing annotation é adicionado.

Carregue o novo nome da AC para o iLO:

  1. Na interface iLO, abra a página Administration - Key Manager e clique no separador Key Manager.
  2. Mude o nome do certificado.
  3. Faça um reinício a frio.
  4. Verifique se a negociação de SSL volta a funcionar.

Gestão de identidade e de acesso

Os pods gatekeeper-audit no espaço de nomes opa-system são reiniciados com frequência

Versões: 1.13.3

Sintomas: verifique o estado dos pods gatekeeper-audit-*** no espaço de nomes opa-system:

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

O resultado pode ter o seguinte aspeto:

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

Este problema é causado por limites de recursos baixos.

Infraestrutura como código (IAC)

A criação excessiva de tokens do Gitlab corre o risco de preencher as bases de dados do Gitlab

Versões: 1.13.1

Sintomas: o subcomponente iac-manager cria repetidamente um novo token para o utilizador configsync-ro, mesmo quando não é necessário. Isto pode levar ao preenchimento da base de dados do Gitlab e tornar o IAC inacessível. O pod pg-gitlab-database-0 no espaço de nomes gitlab-system pode não conseguir iniciar e apresentar eventos como:

  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

Solução alternativa:

Trabalhe em articulação com o seu contacto da Google para obter hotfix_3 para a versão 1.13.1 e aplique-a.

Sistema de gestão de chaves (KMS)

A alteração do tipo de chave principal torna todas as chaves existentes inválidas

Versões: 1.13.x

Sintomas: assim que uma organização é criada, o KMS é aprovisionado automaticamente com uma chave raiz de software. Para migrar de uma chave de raiz de software para uma chave VMT, os utilizadores substituem um subcomponente. Isto altera o tipo de chave raiz, o que torna todas as chaves de software existentes no KMS inválidas.

Solução alternativa: se possível, evite atualizar o tipo de chave raiz. Se atualizar o tipo de chave principal, todas as chaves existentes são invalidadas.

kms-rootkey-controller CrashLoopBackOff devido a OOMKILL

Versões: 1.13.1

Sintomas: quando a utilização de memória kms-rootkey-controller excede o limite de 600Mi, o controlador entra num estado CrashLoopBackOff devido a um estado OOMKilled.

Solução alternativa: crie um SubcomponentOverride para atualizar o limite de memória para 1500Mi. Para ver instruções, consulte o KMS Runbook 0007. Depois de concluir os passos de pré-requisito do manual de procedimentos, execute os seguintes comandos:

  1. Crie um recurso personalizado SubcomponentOverride:

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

    No exemplo seguinte, vê um SubcomponentOverride recurso personalizado 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. Aplique o recurso SubcomponentOverride:

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

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

Registo

O registador de auditoria do armazenamento de objetos não consegue resolver o anfitrião de DNS

Versões: 1.13.x

Sintomas:

No cluster de administrador raiz, a implementação obs-system/log-remote-logger contém vários erros, como os seguintes:

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

Solução alternativa: corrija a implementação do obs-system/log-remote-logger com o seguinte comando:

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

O HaaS Logger mostra erros no cluster de administrador raiz

Versões: 1.13.x

Sintomas:

No cluster de administrador raiz, a implementação obs-system/log-remote-logger contém vários erros, como os seguintes:

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

Solução alternativa: atualize para a versão 1.13.8 para corrigir o erro. Em alternativa, modifique a implementação do obs-system/log-remote-logger da seguinte forma:

Nos argumentos do contentor remote-logger, atualize a flag --disabled-loggers para incluir a santricity e o HaaS:

YAML

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

Falha no registador Santricity

Versões: 1.13.x

Sintomas:

No cluster de administrador raiz, a implementação obs-system/log-remote-logger contém vários erros, como os seguintes:

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"

Solução alternativa: atualize para a versão 1.13.8 para corrigir o erro.

Os registos do destino de registo estão a ser enviados para o projeto incorreto

Versões: 1.13.x

Sintomas: os registos do obs-system/oplogs-forwarder DaemonSet mostram avisos semelhantes aos seguintes:

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

Estes avisos fazem com que os registos sejam encaminhados para o projeto errado (ID do inquilino). Este problema tem origem num erro conhecido no Fluent Bit. Para mais informações, consulte o problema do Fluent Bit no GitHub.

Solução alternativa: atualize para a versão 1.13.8 para corrigir o erro.

Os registos de auditoria do espaço de nomes da plataforma não são visíveis para o PA

Versões: 1.13.x

Sintomas: os registos de auditoria do espaço de nomes da plataforma são visíveis para o operador de infraestrutura (IO) em vez do administrador da plataforma (PA).

Solução alternativa: adicione manualmente a etiqueta observability.gdc.goog/auditlog-destination=pa ao espaço de nomes platform em todos os clusters da organização. Siga estes passos para implementar esta solução alternativa manual:

  1. Defina KUBECONFIG para o cluster de destino.

  2. Adicione a etiqueta necessária ao espaço de nomes:

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

  3. Confirme que a etiqueta foi adicionada com êxito:

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

Os pods não conseguem inicializar os contentores

Versões: 1.13.x

Sintomas: não é possível criar os pods, e é apresentado um erro semelhante ao seguinte:

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 │

Estes erros impedem que os pods sejam iniciados num nó específico. O comportamento observado surge de um caso limite conhecido em que o ficheiro de estado logrotate-daemon fica bloqueado, o que impede que o daemon execute a rotação de ficheiros esperada. Para confirmar este erro, siga estes passos:

  1. Defina KUBECONFIG para o cluster de destino.

  2. Identifique a instância anthos-audit-logs-forwarder-xxxx agendada no nó.

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

  3. Obtenha registos da instância anthos-audit-logs-forwarder-xxxx agendada no nó para validação.

    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"

Solução alternativa:

Siga estes passos para resolver este problema:

  1. Faça a recuperação manual do espaço em disco no diretório /var/log do nó.

  2. Defina KUBECONFIG para o cluster de destino.

  3. Identifique o nó de destino no cluster.

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

  4. Ligue-se ao nó através de SSH e liberte manualmente espaço no diretório /var/log no nó. O logrotate faz a gestão dos ficheiros nestes diretórios.

    /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. Verifique se existem ficheiros de registo invulgarmente grandes (com mais de 100 MB) ou ficheiros com mais de alguns dias. Quando tiver o ficheiro de destino, pode truncar os registos da seguinte forma:

    truncate -s 1G <target_file>

  6. Identifique a instância anthos-audit-logs-forwarder-xxxx agendada no nó.

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

  7. Reinicie a instância anthos-audit-logs-forwarder-xxxx agendada no nó.

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

Marketplace

A obtenção de imagens do Prisma Cloud falha

Versões: 1.13.7

Sintomas: a criação de uma instância do serviço Prisma Cloud a partir do Marketplace falha. O problema é causado por uma etiqueta de imagem incorreta.

Solução alternativa:

  1. Edite a implementação twistlock-console para modificar a etiqueta de imagem:

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

  2. Encontre a seguinte linha:

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. Substituir console_33_01_137 por console_33.01.137:

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

  4. Verifique se o pod é executado corretamente:

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

    O resultado pode ter o seguinte aspeto:

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

Monitorização

Número elevado de alertas criados no ServiceNow

Versões: 1.13.x

Sintomas:

Depois de configurar a monitorização para enviar alertas para o ServiceNow através das tarefas de esforço MON-T0016 e MON-T1016, é criado automaticamente um número elevado de incidentes no ServiceNow.

O problema tem as seguintes características:

  • Todos os incidentes estão vazios.
  • Apenas o cluster de administrador raiz e a organização gdchservices podem enviar alertas para o ServiceNow.

Solução alternativa: siga a tarefa de esforço MON-T0018 imediatamente após executar as tarefas de esforço MON-T0016 e MON-T1016.

Vários alertas duplicados criados no ServiceNow

Versões: 1.13.x

Sintomas:

Depois de configurar a monitorização para enviar alertas para o ServiceNow através das tarefas de esforço MON-T0016, MON-T1016 e MON-T0018, são criados vários alertas duplicados no ServiceNow.

O problema tem as seguintes características:

  • Estão a ser criados vários incidentes duplicados para alguns alertas, mesmo após a aplicação da tarefa de esforço MON-T0018.

Solução alternativa: siga a tarefa de esforço MON-T0019 imediatamente após executar as tarefas de esforço MON-T0016, MON-T1016 e MON-T0018.

Não é possível ver as métricas da Vertex AI

Versões: 1.13.1

Sintomas: as métricas não são emitidas pelo pod dvs-frontend-server.

Solução alternativa: a versão 1.13.1 não suporta métricas encriptadas para os serviços da Vertex AI. Se o serviço Vertex AI não for ativado durante mais de uma hora, reinicie o pod do controlador mon-admin.

Erro de conciliação em mon-cortex

Versões: 1.13.1, 1.13.9

Sintomas: o pod mon-cortex tem um erro de conciliação. Obtenha o estado do agrupamento mon-cortex:

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

O resultado pode ter o seguinte aspeto:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Pode ser registada uma mensagem como esta:

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

Solução alternativa:

  1. Verifique que cápsula do Cortex está a apresentar uma mensagem como esta:

    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. Elimine o PVC associado a esse pod e reinicie-o.

O agrupamento metrics-server-exporter no cluster do sistema está em ciclo de falhas de sistema

Versões: 1.13.1

Sintomas: o pod metrics-server-exporter no cluster do sistema está em ciclo infinito com OOMKilled, mas não parece estar a atingir o respetivo limite. Diagnosticar o erro:

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

O resultado pode ter o seguinte aspeto:

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

Solução alternativa: reduza a quantidade de dados publicados no ponto final de métricas eliminando o pod e permitindo que seja reiniciado. A time-series antiga mantida na memória é limpa quando o faz, o que reduz a memória necessária.

Ignore as mensagens de erro de conciliação ObservabilityPipeline

Versões: 1.13

Sintomas:

O objeto ObservabilityPipeline mostra registos Reconciler error semelhantes aos seguintes no 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"}

Solução alternativa:

Ignore os registos que satisfazem todas as seguintes condições:

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

Se estiver a depurar um alerta devido a erros de conciliação elevados, ignore estes registos, uma vez que são falsos negativos.

O mon-prober-backend-prometheus-config ConfigMap é reposto

Versões: 1.13.0 e 1.13.1

Sintomas:

  • O alerta MON-A0001 é acionado.

  • O ConfigMap mon-prober-backend-prometheus-config é reposto para não incluir tarefas de sondagem, por exemplo:

    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

Solução alternativa:

Siga estes passos para resolver o problema:

  1. Defina as seguintes variáveis de ambiente:

    • KUBECONFIG: o caminho para o ficheiro kubeconfig no cluster.
    • TARGET_CLUSTER: o nome do cluster onde está a resolver o problema.

  2. Pause o subcomponente mon-prober em todos os clusters:

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

    Por exemplo:

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

  3. Reinicie o controlador do administrador do MON em cada cluster de administrador:

    kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller

    O Prober ConfigMap é preenchido à medida que cada teste é registado.

  4. Siga o manual de procedimentos MON-R2009 para silenciar o alerta MON-A0001, Blackbox monitoring metrics pipeline down, porque este alerta vai continuar a ser acionado.

Cortex store gateway component OOMKilled crashloop

Versões: 1.13.3

Sintomas: se vir erros no Grafana ao carregar métricas ou se as métricas não forem carregadas, o pod cortex-store-gateway pode estar em ciclo de falhas.

Para diagnosticar o pod cortex-store-gateway e verificar se está em ciclo de falhas, reveja o respetivo estado:

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

Substitua SYSTEM_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster do sistema.

Se o pod estiver num ciclo de falhas, o resultado tem o seguinte aspeto:

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

Solução alternativa: aumente temporariamente o limite de memória de cortex-store-gateway usando um SubcomponentOverride. Para obter detalhes sobre a implementação de um SubComponentOverride, consulte o manual de procedimentos MON-R2008.

Segue-se um exemplo de um SubcomponentOverride com um limite de memória 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

Deixe a substituição no lugar até que todos oscortex-store-gateway pods tenham um Ready estado e certifique-se de que o subcomponente mon-cortex não está pausado:

  • Verifique se os auriculares cortex-store-gateway têm o estado Ready:

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

    O resultado tem o seguinte aspeto se todos os agrupamentos tiverem o estado Ready:

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

    A coluna READY tem de apresentar um valor N/N para que todos os pods estejam prontos. Caso contrário, mostra valores como 1/3 ou 2/3.

  • Certifique-se de que o subcomponente mon-cortex não está pausado numa determinada organização:

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused

    Substitua o seguinte:

    • ORG_ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador da organização.
    • SYSTEM_CLUSTER: o nome do cluster do sistema.

    Se o subcomponente estiver pausado, o resultado mostra a seguinte linha:

    lcm.private.gdc.goog/paused: true

    Caso contrário, a saída está vazia.

Kube control-plane metrics proxy image pull backoff in user cluster

Versões: 1.13.3

Sintomas: quando as métricas relacionadas com o kube-scheduler ou o kube-controller-manager (por exemplo, as métricas scheduler_pending_pods e workqueue_depth) não estão visíveis no Grafana, pode haver um problema de recuo de obtenção de imagens com o pod kube-control-plane-metrics-proxy.

Para diagnosticar o pod kube-control-plane-metrics-proxy e verificar se tem um problema de recuo de obtenção de imagens, reveja o respetivo estado:

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

Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizador.

Se o pod tiver um problema de recuo de obtenção de imagens, o resultado é semelhante ao seguinte exemplo:

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

Solução alternativa: siga estes passos para resolver o problema:

  1. Extrair a imagem gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 do projeto gpc-system-container-images Harbor. Para ver instruções e as autorizações necessárias para extrair uma imagem, consulte o artigo Extraia uma imagem com o Docker.

  2. Envie a imagem gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 para o projeto library Harbor. Para ver instruções e autorizações necessárias para enviar uma imagem, consulte o artigo Envie uma imagem.

    O projeto library é usado para artefactos a implementar no cluster de utilizadores.

Um aumento no WAL faz com que o Prometheus use muita memória

Versões: 1.13.3

Sintomas: o nó da VM do plano de controlo do sistema comunica eventos NodeHasInsufficientMemory e EvictionThresholdMet:

kubectl describe node NODE_NAME | grep Events -A100

O resultado pode ter o seguinte aspeto:

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

O Prometheus usa muita memória devido ao crescimento do WAL (write-ahead log), o que afeta a memória do nó. O crescimento do WAL pode ocorrer porque o Cortex não foi implementado, pelo que este problema pode ser uma consequência da indisponibilidade do Cortex. A instância do Prometheus perde a conetividade com o Cortex durante um período prolongado, durante o qual armazena dados em buffer na memória e no volume persistente (PV). Quando o Prometheus é terminado, carrega todos os dados no respetivo WAL para a memória no arranque.

Outra causa principal podem ser problemas de conetividade de rede (malha de serviços, redes físicas e superiores).

Solução alternativa: para recuperar deste estado, a ação recomendada é resolver a causa principal e fazer com que o Cortex fique em bom estado ou resolver os problemas de conetividade de rede. Em seguida, aguarde que o WAL do Prometheus seja esvaziado. Não perde dados, mas, se o Cortex estiver em baixo, o nó não está disponível durante o período de tempo necessário para o Cortex recuperar.

Em alternativa, pode reduzir o Prometheus STS para zero e eliminar o PV. Esta ação reduz o tempo total em que o nó está indisponível, mas resulta na perda de dados. Além disso, enquanto o Cortex estiver indisponível ou tiver problemas de conetividade de rede, tem de repetir esta ação periodicamente. Enquanto existir um problema de ligação entre o Prometheus e o Cortex, o PV volta a encher-se.

Siga estes passos para reduzir o Prometheus STS para zero e eliminar o PV:

  1. Reduza a escala do componente logmon-operator:

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

    Substitua ORG_SYSTEM_KUBECONFIG pelo caminho para o ficheiro kubeconfig no cluster do sistema da organização.

  2. Reduza a escala do componente anthos-prometheus-k8s:

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

  3. Elimine a reivindicação de volume persistente:

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

  4. Aumente a escala da logmon-operator:

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

  5. Aguarde até que o anthos-prometheus-k8s esteja pronto.

Arranque multizona

Funções de cluster em falta

Versões: 1.13.1

Sintomas: não existem funções específicas para a inicialização da multizona a usar em Adicionar funções necessárias.

Solução alternativa: use a função de cluster cluster-admin, conforme especificado nas instruções associadas. Isto dá ao utilizador mais do que o acesso mínimo necessário para realizar as tarefas posteriores.

Recurso Bootstrap incompatível

Versões: 1.13.1

Sintomas: o recurso Bootstrap criado no passo 3 de Crie o ficheiro de arranque é incompatível com a lógica que o processa.

Solução alternativa: edite o ficheiro YAML gerado conforme especificado no passo 4.

O recurso GlobalAPIZone não é criado na API global

Versões: 1.13.1

Sintomas: o plano de controlo não cria um recurso GlobalAPIZone para a zona na API global, o que faz com que os componentes que dependem deste recurso não funcionem corretamente.

Solução alternativa: crie o recurso conforme indicado em Criar recurso GlobalAPIZone.

Redes

A rede da grelha de nós de armazenamento de objetos não está operacional

Versões: 1.13.1, 1.13.3 e 1.13.4

Sintomas:

  1. Durante a fase de arranque do armazenamento de objetos, a rede de grelha é apresentada como inativa na IU do instalador do nó de administração de objetos.
  2. cables.csv e Cell CR mostram que o valor MPN em cables.csv é QSFP-100G-CU2.5M para ligações entre nós objsadmin de armazenamento de objetos e o comutador TOR.

Explicação Na versão 1.13, o campo MPN em cables.csv é usado para determinar a velocidade definida no comutador Tor. Se a velocidade não estiver definida nestas portas, a mudança do Tor para a conetividade do nó objsadmin falha. A lista usada para mapear o NSF à velocidade não teve em conta um valor fornecido pelo integrador de sistemas, o que fez com que o arranque do armazenamento de objetos falhasse. Na maioria das configurações 1.13, o fornecedor usado foi: QSFP-100G-CU2.5M.

Solução alternativa:

  1. Use kubectl get -A cell -oyaml no cluster de administrador principal para encontrar a ligação relacionada com o dispositivo de armazenamento de objetos e o comutador TOR.
  2. Altere todas as ocorrências de mpn para "QSFP-100G-CU3M" para objsadm -> torsw connect.

Segue-se um exemplo:

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

Não é possível alcançar o nó

Versões: 1.13.1, 1.13.3 e 1.13.4

Sintomas:

  1. Durante a fase de arranque da rede, alguns comutadores não estão acessíveis.
  2. Durante a fase de instalação do DHCP, alguns servidores não estão acessíveis através do respetivo endereço IP do iLO.

Solução alternativa:

  1. Atualize os comutadores de gestão afetados. Consulte o manual de procedimentos PNET-R0018 para ver detalhes.

PodCIDR não atribuído a nós, apesar de ClusterCIDRConfig ter sido criado

Versões: 1.13.1

Sintomas: um ClusterCIDRConfig é um objeto obrigatório para atribuir PodCIDRs. Apesar de o ClusterCIDRConfig ter sido criado, o PodCIDRs não foi atribuído. Este problema ocorre se for criado um ClusterCIDRConfig ao mesmo tempo que os pods ipam-controller estão a ser iniciados. A criação do cluster está bloqueada no estado de conciliação.

  1. Verifique se o objeto ClusterCIDRConfig foi criado no cluster:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    O resultado pode ter o seguinte aspeto:

    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. Execute o comando describe para um dos objetos de nó do cluster que está bloqueado na reconciliação e verifique se existe um evento CIDRNotAvailable no objeto de nó:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    Os eventos de saída podem ter o seguinte aspeto:

      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

Solução alternativa:

  1. Reinicie os auriculares ipam-controller-manager:

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

  2. Depois de os ipam-controller-manager pods estarem em execução, verifique se o podCIDR está atribuído aos nós:

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

    O resultado pode ter o seguinte aspeto:

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

Degradação do NTP

Versões: 1.13.1

Sintomas: um nó de VM tem uma hora incorreta ou desviada após estar em suspensão ou em execução durante algum tempo.

Solução alternativa:

  1. Estabeleça uma ligação SSH ao nó da VM e edite o ficheiro./etc/chrony.conf
  2. Substituir a linha makestep 1.0 3 por makestep 1.0 -1.

  3. Reinicie o serviço chronyd:

    systemctl restart chronyd

Só tem de fazer esta alteração uma vez em cada MV. A alteração não vai ser substituída.

Para uma correção rápida imediata para avançar no tempo, estabeleça uma ligação SSH ao nó da VM e execute chronyc -a makestep.

Os registos de auditoria do SyncServer não foram analisados

Versões: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Sintomas: os registos de auditoria do SyncServer não são analisados corretamente pelo log-remote-logger. Alguns registos de auditoria não estão disponíveis no Grafana e pode ver mensagens de erro no pod root-admin, como:log-remote-logger

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

Solução alternativa: os registos de auditoria continuam disponíveis no SyncServer. Siga as instruções em NTP-P0002 para aceder à IU do SyncServer e ver os registos em Logs > Events.

A mudança de imagem não conseguiu extrair a imagem

Versões: 1.13.3

Sintomas: pode ver uma mensagem como esta no objeto SwitchImageHostRequest quando executa uma RMA de comutação ou quando inicia o cluster de administrador principal:

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

Se tiver acesso ao kubectl, use-o para verificar se está a ter este problema:

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

O resultado pode ter o seguinte aspeto:

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

Solução alternativa:

Crie manualmente um SwitchImageHostRequest com a etiqueta de imagem correta:

  1. Inicie sessão no servidor de arranque.

  2. Use gdcloud para identificar a versão correta da imagem do comutador:

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

    O resultado pode ter o seguinte aspeto:

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

    A partir deste resultado, a versão correta da imagem do interruptor é 1.13.3-gdch.5385.

  3. Edite o objeto SwitchImageHostRequest que comunica o erro:

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

  4. Edite ou substitua os campos name, fromVersion e toVersion para corresponderem à versão da imagem de comutação esperada. Neste caso, é 1.13.3-gdch.5385. Veja o resultado diff seguinte, que ilustra as alterações a fazer ao 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

A comunicação do pod StatefulSet falha

Versões: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9, 1.13.10

Sintomas: problemas de conectividade ou interrupções devido à eliminação de objetos Cilium Endpoint (CEP) que não são processados corretamente após o reinício dos pods StatefulSet. Isto pode fazer com que a identidade do ponto final não gerido faça com que as políticas de rede rejeitem erroneamente tráfego legítimo. Pode verificar os pods afetados verificando a ausência do respetivo objeto CEP correspondente:

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

Solução alternativa: reinicie os pods StatefulSet afetados para atualizar o respetivo UID e atualizar os metadados associados:

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

Problemas de conetividade com instâncias de DBS

Versões: 1.13.0, 1.13.1

Sintomas: as instâncias dos serviços de base de dados (DBS) estão inacessíveis e os clientes da base de dados apresentam limites de tempo de ligação.

Este problema pode ser apresentado através de outro componente do sistema que dependa do DBS. Por exemplo, a faturação pode comunicar mensagens de erro como as seguintes:

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

Solução alternativa: a falha é causada por um componente do sistema de rede que não consegue agendar no cluster de serviços da organização.

  1. Defina as seguintes variáveis de ambiente:

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    Substitua o seguinte:

    • KUBECONFIG_PATH: o caminho para o ficheiro kubeconfig do cluster de administrador da organização.
    • ORG_NAME: o nome da sua organização, como org-1.

  2. Atualize a configuração do componente de rede para permitir que seja agendada:

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

A conetividade de rede é restaurada após alguns minutos.

A malha do cluster não está configurada com informações zonais

Versões: 1.13.5

Sintomas: uma VM não consegue estabelecer ligação a um cluster de base de dados no mesmo projeto. A conetividade ao balanceador de carga interno é afetada. Este problema é causado por um Clustermesh que não consegue trocar objetos de serviço entre clusters devido a informações de zona em falta na configuração do nome do cluster.

Solução alternativa: em ambientes inicializados como multizona, execute os seguintes passos manuais da solução alternativa para que o balanceador de carga interno funcione:

  1. No cluster de administrador da organização, obtenha o nome da zona:

    ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

    O resultado pode ter o seguinte aspeto:

    zone1

  2. No cluster de administrador da organização, obtenha o ID do site da zona:

    SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID

    O resultado pode ter o seguinte aspeto:

    1

  3. Liste todos os clusters:

    ​​kubectl get clusters -A

    O resultado pode ter o seguinte aspeto:

    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 cluster, construa o CILIUM_CLUSTERNAME:

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

    O resultado pode ter o seguinte aspeto:

    org-1-system-zone1

  5. Para cada cluster, defina os outros parâmetros da seguinte forma. O exemplo seguinte para org-1-system:

    CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592

  6. Para cada cluster, crie um objeto AddOnConfiguration e armazene-o num ficheiro addonconfig.yaml. Crie este ficheiro para todos os clusters existentes e quaisquer novos clusters que criar no futuro:

    Nesta página, defina as seguintes variáveis para atualizar o seguinte exemplo de código:

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

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

  7. Aplique o addonconfig.yaml no cluster de administrador da organização:

    kubectl apply -f addonconfig.yaml

  8. Nos clusters de sistema, de serviço e de utilizadores, certifique-se de que o cluster-name é atualizado no cilium-config no cluster. Esta atualização pode demorar algum tempo, mas este passo é necessário antes de reiniciar a implementação do clustermesh-apiserver.

    kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo

  9. Nos clusters do sistema, de serviço e de utilizador, reinicie a clustermesh-apiserverimplementação:

    kubectl rollout restart deployment -n kube-system clustermesh-apiserver

São gerados endereços IP EVPN incorretos

Versões: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Sintomas: os endereços IP de peering da sessão de interconexão EVPN (MZ) multizona gerados pelo sistema de gestão de recursos de hardware (HAMS) não terminam com .65 ou .66, o que está incorreto e impede o estabelecimento das sessões BGP EVPN MZ.

Solução alternativa:

Para resolver manualmente este problema, siga estes passos:

  1. Apresentar todos os recursos de InterconnectSession:

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

  2. Reveja os recursos InterconnectSession de várias zonas EVPN gerados que têm um valor interconnectType de ZonePeering e um 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. Para cada um dos recursos InterconnectSession que correspondem a estes parâmetros, aplique a seguinte correção:

    1. Verifique o nome do recurso personalizado da sessão de interligação.
    2. Se o nome terminar num número ímpar, atualize a última parte do endereço IP do par para 65 através do comando no passo seguinte.
    3. Se o nome terminar num número par, atualize a última parte do endereço IP do par para 66 através do comando no passo seguinte.

  4. Modifique o recurso InterconnectSession com o endereço IP do par incorreto:

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

  5. Aplique esta correção a todos os InterconnectSession recursos que estão a causar o erro.

O painel de controlo do plano de controlo de rede superior não mostra dados

Versões: 1.13.7

Sintomas: as consultas do Prometheus em TestUpperNetworkingMetrics falham devido a métricas em falta no cluster org-1-system. Os painéis de clustermesh no painel de controlo de rede superior para administradores da organização de E/S não mostram dados. O problema resulta de uma incompatibilidade na etiqueta source_cluster entre o Cilium e o sistema de monitorização.

Solução alternativa: remova o filtro source_cluster do painel de controlo do UNET para mostrar os dados.

Erros de pista falsa apresentados na instalação de rede

Versões: 1.13.1

Sintomas: durante a instalação de rede, são apresentadas algumas mensagens de aviso sobre cablagem. Por exemplo:

  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)

Pode ignorar estas mensagens de erro em segurança.

A criação de um PNP de saída total nega tráfego inesperado

Versões:

Todas as versões do Google Distributed Cloud (GDC) air-gapped podem ser afetadas.

Sintomas: a política de rede do projeto (PNP) do projeto allow-all-egress permite o tráfego para pontos finais no projeto e pontos finais externos fora do cluster, mas não permite o tráfego para pontos finais do sistema. Este problema pode levar ao bloqueio do acesso ao sistema e aos serviços originais, como a resolução de DNS e o armazenamento de objetos.

O allow-all-egress PNP pode ter o seguinte aspeto:

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

Solução alternativa: elimine o allow-all-egress PNP. Por predefinição, assim que a proteção contra exfiltração de dados é desativada, o tráfego é permitido para o projeto e pontos finais externos fora do cluster e dos pontos finais do sistema.

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

Armazenamento de objetos

Não é possível eliminar a organização de armazenamento

Versões: 1.13.1

Sintomas: a eliminação de uma organização pode não ser bem-sucedida devido a um problema que impede a conclusão da eliminação da SVM. Pode ver um aviso como este:

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

Alguns avisos de atualização do armazenamento de objetos podem ser ignorados

Versões: 1.13.3

Sintomas: quando atualiza o armazenamento de objetos, pode ver um aviso como este:

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

Solução alternativa:

  1. Verifique se cada nó tem credenciais SSH correspondentes armazenadas num segredo.

    1. Verifique os nós de administração:

      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. Verifique os nós de armazenamento:

      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

      O resultado bem-sucedido tem o seguinte aspeto para os nós de armazenamento:

      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

      Se não for encontrado um segredo, o erro tem este aspeto:

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

  2. Se o comando não devolver erros, pode ignorar com segurança os erros comunicados pelos reconciliadores.

ObjectStorageStorageNodeReconciler relatórios maintenance.gdu.gdu_server_locked

Versões: 1.13.3

Sintomas: mostram os detalhes do objectstoragestoragenode:

kubectl describe objectstoragestoragenode zv-aa-objs02

O resultado pode ter o seguinte aspeto:

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

Solução alternativa: pode ignorar este problema. O serviço GDU pode ser bloqueado temporariamente quando recebe demasiados pedidos, mas é desbloqueado após alguns minutos.

A verificação do armazenamento de objetos da atualização pós-voo de 1.12.x para 1.13.x falha

Versões: 1.13.x

Sintoma: o CR ObjectStorageUpgrade falha com o erro

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

Os pods gpc-system/upgrade-managed-check-objectstorageupgrade falham com o erro

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: A atualização do componente operacional de armazenamento de objetos de 1.12.x para 1.13.x falha se o cluster KIND de arranque não tiver sido desativado ou eliminado. Mesmo que a atualização seja bem-sucedida, os serviços de armazenamento de objetos comuns, como a criação de novos contentores ou credenciais do S3 através do RBAC do Kubernetes, podem falhar devido a erros de validação de certificados TLS. Isto deve-se ao facto de um pod de armazenamento de objetos específico no cluster KIND tentar continuamente instalar o certificado do servidor TLS do ponto final de gestão do StorageGRID, que era válido na versão 1.12.x, mas pode não ser reconhecido na versão 1.13.x. Durante a atualização, o StorageGRID instala um certificado de servidor TLS novo e validável, mas o pod do cluster KIND substitui-o pelo certificado antigo e inválido, o que causa o erro do certificado TLS.

Solução alternativa: Os seguintes requisitos têm de ser verdadeiros:

  • A atualização do armazenamento de objetos de 1.12.x para 1.13.x
  • O cluster de arranque (o cluster KIND) ainda existe

Siga os passos seguintes:

  1. Adquira um kubeconfig que tenha autorização de visualização e modificação para o recurso ObjectStorageSite no cluster de arranque (o cluster KIND).

  2. Defina um alias para kubectl estabelecer ligação ao cluster de arranque (o cluster KIND):

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

  3. Obtenha a instância de recurso personalizado ObjectStorageSite do cluster de arranque. Deve existir uma instância do recurso ObjectStorageSite:

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

  4. Adicione uma anotação de pausa de armazenamento de objetos à instância do recurso ObjectStorageSite:

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

  5. Verifique se a anotação de pausa do armazenamento de objetos foi adicionada à instância ObjectStorageSite:

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

  6. Adquira um kubeconfig que tenha acesso de visualização e autorização de aplicação de patches de estado aos recursos ObjectStorageCluster no cluster de administrador raiz.

  7. Defina um alias para o kubectl que se liga ao cluster de administrador raiz:

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

  8. Verifique se existe alguma instância de recurso ObjectStorageCluster no cluster de administrador raiz:

    kubectlrootadmin get ObjectStorageCluster

    Se não existir uma instância de recurso ObjectStorageCluster, a solução alternativa está concluída. Pode ter de repetir o procedimento de atualização do armazenamento de objetos.

  9. Obtenha o URL do ponto final de gestão a partir do estado do recurso ObjectStorageSite no cluster de arranque:

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

  10. Valide se a variável de ambiente $MGMT_ENDPOINT foi definida. O ponto final deve começar com https://:

    echo ${MGMT_ENDPOINT:?}

  11. Execute os restantes passos apenas quando existir exatamente uma instância de recurso ObjectStorageCluster no cluster de administrador raiz. Caso contrário, execute novamente o procedimento de atualização do armazenamento de objetos:

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

  12. Reinicie o pod gpc-system/obj-infra-cluster-cm:

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

  13. Verifique se o ponto final de gestão foi adicionado ao estado do recurso ObjectStorageCluster:

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

  14. Reinicie a verificação pós-voo eliminando a tarefa do Kubernetes de verificação pós-voo gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. A tarefa é recriada em breve.

Não é possível alcançar o nó na rede de dados

Este é um problema raro que pode ocorrer se o anetd pod ficar preso num ciclo de falhas.

Um recurso do kernel essencial para a conetividade do nó pode ficar bloqueado num estado danificado.

Este guia descreve os sintomas deste problema, bem como os passos que podem ser seguidos para o resolver.

Versões:

Todas as versões do Google Distributed Cloud (GDC) air-gapped podem ser afetadas.

Sintomas:

Se este problema ocorrer, pode ver os seguintes sintomas:

  • Os nós estão presos no estado NotReady
  • A descrição do nó mostra a mensagem kubelet:kubelet was found unhealthy; repair flag : true
  • Não é possível aceder ao nó através de SSH na rede de dados

Solução alternativa:

Use as instruções seguintes para reparar cada nó não saudável:

  1. Obtenha o endereço IP de gestão do nó afetado:

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

  2. Obtenha acesso SSH ao nó afetado.

  3. Ligue-se ao nó através de SSH com o endereço IP de gestão do nó.

  4. No nó, execute o seguinte comando e, em seguida, feche a ligação SSH:

    tc filter del dev bond0 egress

  5. Reinicie o conjunto de daemon anetd para o cluster com o nó afetado:

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

    O certificado do ponto final do equilibrador de carga do StorageGRID expirou

Versões: 1.13.10, 1.13.11, 1.13.12

Sintomas: o proxy de armazenamento de objetos está a comunicar 502 Bad Gateway.

Solução alternativa: siga o OBJ T0003.

Sistema operativo

Agrupamentos bloqueados num estado init

Versões: 1.13.1

Sintomas: o nó indica que está pronto, mas o acesso SSH ao nó é lento e e top -n 1 mostra > 100 processos zombie.

Solução alternativa:

  1. Siga o erro OS-P0001 para esvaziar o servidor. O consumo pode demorar mais de 20 minutos. Se a drenagem não for bem-sucedida após uma hora, avance para o passo seguinte.

  2. Reinicie o servidor estabelecendo uma ligação SSH ao servidor e emitindo o seguinte comando:

    systemctl reboot

  3. Pode ser necessário reiniciar novamente para recuperar totalmente o servidor.

  4. Verifique se o acesso SSH já não é lento e se o número de processos zombie é muito inferior, de preferência, inferior a 30.

  5. Desative a drenagem do servidor definindo maintenance como false no servidor.

bm-system-machine-preflight-check A tarefa do Ansible para um nó de metal puro ou de VM falha

Versões: 1.13.1

Sintomas: o módulo do kernel nf_tables não é carregado após o reinício, o que faz com que os trabalhos do Ansible do cluster falhem com um erro Either ip_tables or nf_tables kernel module must be loaded. Este problema ocorre quando o nó de metal puro ou da VM é reiniciado antes de estar totalmente aprovisionado. A tarefa do Ansible pode gerar um erro 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.'}"}

Solução alternativa:

Estabeleça uma ligação SSH ao nó e execute o seguinte comando:

modprobe nf_tables

MV sem espaço disponível no dispositivo

Versões: 1.13.1, 1.13.3, 1.13.4 e 1.13.5

Sintomas: quando o diretório de registo /var/log está cheio, o Node pode ficar bloqueado no estado NotReady e os pods podem não ser iniciados devido ao erro no space left on device. Para verificar esta situação, execute o seguinte comando no nó e verifique se a utilização está perto de 100%.

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

Solução alternativa:

  1. Inicie sessão no nó que encontra o problema e limpe os arquivos de registos antigos para /var/log/messages.

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

    Também recomendamos que continue a aplicar a seguinte solução alternativa para evitar que isto aconteça. A solução alternativa consiste em criar um AnsiblePlaybook e aplicar a alteração através de um CR OSPolicy personalizado responsável por configurar em segurança o SO de destino (máquinas BM+VM). Consulte o processo OS-P0005 para ver mais detalhes.

  2. Defina as seguintes variáveis de ambiente:

    export KUBECONFIG=<the path to the kubeconfig file>

  3. Crie um guia interativo do Ansible para a solução 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. Identifique os inventários de destino aos quais a alteração tem de ser aplicada. O destino pode ser um InventoryMachine individual ou um NodePool. Consulte o processo OS-P0005 (2. Identifique o inventário de destino para as configurações de tempo de execução) para obter detalhes.

    O exemplo OSPolicy seguinte incluía dois inventários de destino em spec.inventory. Pode adicionar mais inventários, conforme necessário.

    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. Validação

    Consulte o processo OS-P0005 (validação) para acompanhar o estado de execução da política.

Pods bloqueados num estado ContainerCreating

Versões: 1.13.3, 1.13.5, 1.13.6

Sintomas: um nó é apresentado como estando em bom estado, mas tem muitos pods bloqueados num estado ContainerCreating e não consegue estabelecer uma ligação SSH ao servidor.

Solução alternativa: reinicie o servidor e confirme que consegue estabelecer uma ligação SSH ao nó quando este voltar a ficar disponível.

Não é possível fazer SSH para o nó aprovisionado

Versões: 1.13.5

Sintomas: um nó é aprovisionado, mas o SSH excede o tempo limite nos IPs de gestão e de dados.

Solução alternativa: reinicie o nó através do iLO. Depois de arrancar, inicie sessão através de SSH e desative o clamonacc com systemctl stop clamonacc; systemctl disable clamonacc.

Os nós bare metal não conseguem arrancar a partir da imagem do SO mais recente porque o arranque seguro não reconhece a assinatura do SO

Versões: 1.13.12

Sintomas: após a atualização para a versão 1.13.12, se o nó for reiniciado, o SO não consegue arrancar no novo kernel. O ecrã da consola iLO apresenta um problema relacionado com o arranque seguro:

../../grub-core/loader/i386/efi/linux.c:385:(hd0,gpt2)/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64 has invalid signature,..:
 ../../grub-core/loader/i386/efi/linux.c:256: you need to load the kernel first.

Solução alternativa:

  1. Para qualquer nó que não arranque devido a este problema, aceda ao ecrã do GRUB através da consola iLO e selecione Rocky Linux 4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64 como destino de arranque. Este procedimento faz com que o nó arranque no kernel bom conhecido anterior.

  2. Para todos os servidores bare metal atualizados para a versão 1.13.12 do GDC, siga os passos abaixo para evitar a falha de arranque:

    1. Estabeleça uma ligação SSH ao servidor.
    2. Execute os seguintes comandos no servidor para remover o kernel problemático:
    dnf remove kernel-core-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64
    1. Verifique se o kernel predefinido foi reposto com êxito para uma versão conhecida e funcional:
    grubby --default-kernel

O resultado é /boot/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64.

Infraestrutura do Operations Suite (OI)

A SSA não é necessária para o Hardware 3.0

A configuração do adaptador RAID é diferente para o Hardware 3.0. Os servidores OIC de hardware 3.0 usam uma unidade autoencriptada, pelo que o início da administração de armazenamento inteligente (SSA) já não é necessário. São necessários passos adicionais para determinar os identificadores de disco por servidor. Consulte o bootstrap do servidor OI.

Segurança perimetral

O cluster do sistema da organização fica bloqueado durante o arranque da organização

Versões: 1.13.1

Sintomas: durante o arranque da organização, o cluster do sistema da organização pode ficar bloqueado. Os agrupamentos edr-sidecar-injector estão no estado pendente. Quando tenta eliminar estes pods, pode ver uma mensagem de erro como esta:

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

Ao mesmo tempo, alguns outros pods pendentes podem ter mensagens de erro como esta:

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

O sistema precisa de intervenção manual para se desbloquear.

Solução alternativa:

  1. Duplicar o MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg no cluster do sistema.
  2. Duplicar o ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration no cluster do sistema.
  3. Elimine o CR edr-sidecar-injector-webhook-cfg e o CR gatekeeper-validating-webhook-configuration do cluster do sistema.
  4. Aguarde que os pods edr-sidecar-injector voltem a ficar disponíveis e que o gatekeeper-controller-manager volte a ficar disponível.
  5. Restaure o CR do webhook com o comando kubectl apply.

Os grupos de endereços da firewall PANW não são atualizados com alterações de reivindicação de CIDR

Versões: 1.13.1

Sintomas: durante o arranque, o OCIT cidr-claim é atualizado com o valor correto, mas a firewall AddressGroups não. Um par de AddressGroups, especificamente vsys1-root-ocit-network-cidr-group e ocvsys1-root-ocit-network-cidr-group, use bloqueios de rede que não se sobreponham ao que está realmente em uso no OIR. O OIR não consegue resolver os registos de zona do GDC e as consultas expiram sem uma resposta.

Solução alternativa: Após as alterações cidr-claim, certifique-se de que o AddressGroup é atualizado com a versão mais recente cidr-claim reiniciando a implementação do fw-core-backend-controller no espaço de nomes fw-system no cluster de administrador principal.

Servidores físicos

O arranque do servidor falha devido a problemas de POST no servidor HPE

Versões: 1.13.1

Sintomas: o arranque do servidor falha quando um servidor não consegue ultrapassar o processo de arranque POST. Iniciar sessão no ILO e verificar a consola do servidor mostra o seguinte erro:

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.

Solução alternativa:

No iLO, clique no botão ligar/desligar e selecione Cold Boot.

Servidores bloqueados no estado de aprovisionamento

Versões: 1.13.1, 1.13.3, 1.13.5

Sintomas: os servidores ficam bloqueados num estado de aprovisionamento durante o arranque do servidor. Verifique o estado dos servidores:

k get servers -A | grep -v availabl

O resultado pode ter o seguinte aspeto:

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

Solução alternativa:

  1. Inicie o DHCP manualmente com uma configuração transferida do cluster KIND. Neste exemplo, /tmp/dhcp.conf é a configuração DHCP do cluster 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

    Substitua VERSION pela versão de lançamento, conforme descrito nas instruções de atualização em Atualização manual de componentes de ficheiros para clusters de administrador de raiz e de organização, por exemplo, 1.13.1-gdch.525.

  2. Verifique a configuração do BIOS no servidor e confirme que NetworkBoot não está ativado para NICs do plano de dados (denominados no padrão Slot{i}Nic{i}).

  3. Verifique a BIOS através da chamada da API:

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

    Onde $bmcUser e $bmcPassword são as palavras-passe dos ILOs, que podem ser encontradas no ficheiro ou diretório cellcfg num segredo denominado bmc-credentials-<server-name>, por exemplo, bmc-credentials-ai-aa-bm01. Verifique se o resultado deste comando mostra Slot1Nic1: Disabled.

  4. Se alguma dessas Slot{i}Nic{i} tiver NetworkBoot, desative-a com a API de definições da 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'

    Substitua Slot{i}Nic{i} pelo nome do espaço que tem o problema na carga útil.

  5. Reinicie o servidor.

O servidor DL380a não consegue o aprovisionamento

Versões: 1.13.3, 1.13.4, 1.13.5

Sintomas: o aprovisionamento do servidor falha na tarefa de encriptação para o modelo HPE DL380a. O estado do CR do servidor está bloqueado em available durante o arranque do servidor:

# server name
export SERVER_NAME=

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

Solução alternativa:

  1. Siga o procedimento IAM-R0004 para gerar o KUBECONFIG para o root-admin-cluster.

  2. Siga o procedimento PLATAUTH-G0001 para gerar a chave SSH root-id_rsa para CLUSTER_NS=root.

  3. Pausar o servidor adicionando a anotação server.system.private.gdc.goog/paused ao recurso personalizado do servidor:

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

  4. Inicie sessão no servidor a partir do IP de gestão:

    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. Ative a encriptação 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

    Deve esperar uma saída dos comandos semelhante a:

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

    Se verificar que o último comando não é bem-sucedido ou vir erros como "Invalid BIOS EKM status" (Estado do EKM do BIOS inválido), experimente reiniciar o servidor e o iLO e, em seguida, execute novamente este passo.

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

    Se o último comando tiver sido bem-sucedido, reinicie o servidor conforme indicado.

  6. Crie uma unidade lógica manualmente:

    Depois de o servidor terminar o reinício, inicie sessão no servidor a partir do IP de gestão novamente e liste todas as unidades disponíveis:

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

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

    O resultado do último comando pode ter o seguinte aspeto:

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

    Deve guardar os 2 IDs com Size igual a 1.60 TB, neste caso:EID:Slt

    252:1,252:2

    Em seguida, crie uma unidade lógica com IDs de EID:Slt:

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

    A saída do último comando tem o seguinte aspeto:

    /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. Simule o estado da encriptação do disco no CR do servidor.

    Edite o estado do CR do servidor:

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

    Adicione ou modifique o estado DiskEncryptionEnabled para verdadeiro:

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

  8. Elimine a tarefa de encriptação do servidor, se existir:

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

  9. Retome o servidor para que o aprovisionamento seja retomado:

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

A eliminação segura falha sem uma licença

Versões: 1.13.5

Sintomas: quando um servidor fica bloqueado durante a instalação do servidor, pode ver um estado no CR do servidor semelhante ao seguinte:

- 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

Solução alternativa: siga as instruções no manual de procedimentos SERV-R0014.

Segurança da plataforma

O reconciliador da subAC de BYO não está a verificar se os certificados têm uma chave pública correspondente

Versões: 1.13.1

Sintomas: quando o modo de subCA BYO de PKI gera um novo pedido de assinatura de certificado (CSR) enquanto um certificado assinado anteriormente é carregado para a subCA, o reconciliador não verifica se o novo CSR corresponde ao certificado assinado antigo e marca o recurso personalizado (CR) cert-manager CertificateRequest como Ready. Isto ocorre durante a renovação ou a rotação manual do certificado da SubCA. O controlador cert-manager tenta atualizar o estado do CR, o que aciona a seguinte mensagem de erro:Certificate

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

Solução alternativa:

Siga as instruções para carregar um novo certificado BYO SubCA assinado para o novo CSR.

O problema do cert-manager resulta na emissão sem êxito de PKI BYO com ACME

Versões: 1.13.1

Sintomas: a falha ocorre na primeira emissão ou renovação de certificados BYO com o protocolo Automatic Certificate Management Environment (ACME). Quando executa o comando para verificar o estado do certificado, vê que o certificado está not ready:

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

O resultado tem um aspeto semelhante ao seguinte:

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

Solução alternativa:

Reinicie a implementação do cert-manager no cluster de administrador da organização:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

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

Gestor de recursos

O estado do projeto não está disponível na consola do GDC

Versões: 1.13.1 ou superior

Sintomas: a consola do GDC não apresenta o estado de um projeto. Os projetos que não estão no estado Ready não podem suportar novos recursos nem processar novas modificações aos recursos existentes. Devido à incapacidade de confirmar o estado do projeto, não é claro quando os recursos de um projeto podem ser geridos, o que resulta em erros ao tentar novas ações do projeto.

Solução alternativa: consulte o manual de procedimentos RM-R0100 para imprimir o estado do projeto através da CLI kubectl.

Atualizar

bm-system e outras tarefas bloqueadas

Versões: 1.13.1

Sintomas: o bm-system e outros trabalhos que executam o playbook do Ansible estão bloqueados em gathering facts.

Solução alternativa: introduza o nome do nó que está bloqueado e execute multipath -ll | grep failed e multipath -ll | grep #. Se existir um resultado não vazio,siga os runbooks FILE R0020 e FILE R0021.

IP de gestão inacessível

Versões: 1.13.1, 1.13.3, 1.13.4 e 1.13.5

Sintomas: durante uma atualização, o IP de gestão de um servidor fica inacessível, especificamente após uma mudança.

Com o Rocky Linux, quando são adicionadas rotas estáticas, o IP de destino usado para alcançar as rotas estáticas tem de estar acessível antes de adicionar as rotas estáticas. Se o comutador for reiniciado após uma atualização do SO, esse IP de gestão pode ficar temporariamente inacessível.

Solução alternativa: estabeleça uma ligação SSH ao servidor através do endereço IP de dados e reinicie o serviço de rede para recriar as rotas estáticas em falta:

systemctl restart NetworkManager.service

O número da versão de storagecluster não é apresentado

Versões: 1.13.3

Sintomas: após uma atualização o CR não mostra nenhum valor para o campo de estado StorageVersion.StorageCluster

Verifique a versão:

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

Siga os passos na solução alternativa se o campo da versão estiver vazio.

Solução alternativa: reinicie a implementação do file-storage-backend-controller:

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

O servidor bare metal está bloqueado no estado de aprovisionamento

Versões: 1.13.1

Sintomas:

O servidor bare metal fica bloqueado no estado "Aprovisionamento" durante muito tempo quando está a ser criada uma organização.

Solução alternativa:

É possível que a configuração da BIOS do servidor tenha sido alterada para fazer com que o servidor use a placa de rede incorreta para o Pxebooting.

Siga estes passos para desativar o arranque de rede da NIC do plano de dados.

  • Acesso necessário:
    • Precisa de acesso às credenciais de administrador do BMC dos servidores que estão bloqueados.
    • Siga o procedimento IAM-R0005 para obter a função hardware-admin ClusterRole no cluster root-admin durante 1 hora.
    • Siga o procedimento IAM-R0004 para gerar o KUBECONFIG para o cluster root-admin.

  1. Defina o nome do servidor bloqueado.

    export SERVER_NAME=

  2. Defina o IP e as credenciais do BMC do 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. Identifique a ranhura PCIe da placa de rede do plano de dados no servidor.

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}

    Por exemplo, a saída seguinte indica que a placa de rede está instalada no Slot 3.

    ["s3p1","s3p2"]

    Defina a variável PCIEslot:

    export DATA_NIC_SLOT=3

  4. Confirme que o arranque de rede não está desativado.

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

    Se o resultado for "NetworkBoot", tem de o desativar explicitamente.

  5. Use o BMC para desativar a função de arranque de rede na placa de rede do plano de dados.

    Substitua "Slot3" no comando seguinte pelo número do espaço 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

    e, em seguida, reinicie o computador.

    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

    O servidor demora 10 a 15 minutos a ficar novamente disponível e retoma automaticamente o processo de aprovisionamento.

A atualização do armazenamento de objetos mostra um erro durante a verificação de pré-lançamento ou pós-lançamento

Versões: 1.13.1

Sintomas: as verificações pré-publicação ou pós-publicação falham com um erro. Verifique os registos:

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

O erro pode ter o seguinte aspeto:

 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

Solução alternativa:

  1. Se o erro ocorrer durante as verificações pós-voo e todas as outras verificações forem concluídas sem erros, ignore as verificações pós-voo. Quando o upgrade for reiniciado, também tem de ignorar as verificações prévias com o kubeconfig de administrador raiz:

    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 exemplo, se o erro ocorrer na organização org-1, o comando tem o seguinte aspeto:

    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. Se o erro ocorrer durante as verificações de pré-publicação e todas as outras verificações de pré-publicação forem concluídas sem erros, ignore as verificações de pré-publicação:

    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 exemplo, se o erro ocorrer na organização org-1, o comando tem o seguinte aspeto:

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

Pode ter de aplicar esta solução alternativa mais do que uma vez se não for aplicada.

Reversões de atualizações do Helm

Versões: 1.13.3

Sintomas: um problema de atualização do Helm resulta numa série de reversões, não conseguindo encontrar um Certificate e um ServiceEntry. Pode ver uma mensagem como esta:

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

Solução alternativa: siga os passos no manual de procedimentos OCLCM-R0122.

Atualização do nó ou ABM bloqueado devido ao pod dhcp-tftp-core-server não ter sido esvaziado

Versões: 1.13.3, 1.14.4, 1.14.5

Sintomas: a atualização do nó pode ficar bloqueada. No estado da máquina sem sistema operativo, o pod dhcp-tftp-core-server não é esvaziado. Pode ver uma mensagem como esta:

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

Solução alternativa: force a eliminação do pod dhcp-tftp-core-server-* para continuar. O comando tem o seguinte aspeto:

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

OrganizationUpgrade está bloqueado na fase de atualização do nó

Versões: 1.13.3

Sintomas: OrganizationUpgrade está bloqueado na fase de atualização do nó. Pode ver uma mensagem como esta:

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

Solução alternativa:

  1. Verifique se existem upgradetaskrequestCRs no cluster raizka get upgradetaskrequest -n gpc-system. Verifique se o nó ainda está no estado de execução. Certifique-se de que está bloqueado na tarefa para serviço.

    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. Crie manualmente nodeupgrade CRs para cada uma das reivindicações do node pool:

    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. Crie um nodeupgrade CR para cada uma das reivindicações do grupo de nós. Os detalhes da anotação upgrade.private.gdc.goog/target-release-version têm de ser obtidos a partir do nome do CRMD do SO do alvo:

    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. Use a versão daqui nas anotações 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. Aplique o seguinte yaml para cada um dos 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. Depois de as atualizações dos nós ficarem concluídas para os nós do cluster de serviço, atualize o estado do CR para Verdadeiro, para que a atualização da organização avance para a fase seguinte:UpgradeTaskRequest

        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. A atualização da organização deve avançar para a fase seguinte e o estado do serviço ou do nó vai ficar concluído:

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

O kernel não consegue criar um contentor

Versões: 1.13.3

Sintomas: o kernel não consegue atribuir memória cgroups, o que resulta em falhas na criação de novos contentores.

Pode ver uma mensagem como esta:

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.

e o nó está a usar um número muito grande de cgroups:

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

Solução alternativa:

Siga um dos seguintes procedimentos:

  1. Execute echo 3 > /proc/sys/vm/drop_caches no nó e reinicie o kubelet.
  2. Se o método anterior não funcionar, experimente reiniciar o nó.

Falha de conetividade intermitente ao VIP do cluster externo

Versões: 1.13.3

Sintomas: as falhas de ligação intermitentes ao IP virtual (VIP) do cluster externo, como o VIP do plano de controlo, o VIP do istio-gateway ou o VIP do Harbor, resultam num erro dial tcp :: connect: no route to host.

Para diagnosticar este problema, siga estes passos:

  1. Estabeleça ligação ao cluster de administrador principal. Esta solução alternativa pressupõe que está a depurar endereços IP num cluster de administrador principal. Se estiver a depurar problemas de conetividade com outros clusters do Kubernetes, como os clusters de administrador da organização ou do sistema da organização, altere o valor KUBECONFIG para o caminho kubeconfig correto do cluster.

  2. Existem duas categorias conhecidas de IPs que podem ser afetadas. Verifique se o Border Gateway Protocol (BGP) anuncia os endereços IP aos comutadores de topo de rack (ToR):

    • Se o IP for um endereço IP do plano de controlo do Kubernetes, como 192.0.2.100, use este comando para obter as informações de configuração:

      KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`

      Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig no cluster de administrador raiz.

    • Para algumas configurações, o recurso personalizado BGPAdvertisedRoutedefine que rotas no endereço IP são anunciadas a outras redes ou sistemas através do BGP. Se o endereço IP for anunciado pelo recurso personalizado BGPAdvertisedRoute, use este comando para obter as informações de configuração:

      TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP

      Substitua TARGET_IP_ADDRESS pelo endereço IP que está a ter problemas de conetividade intermitentes.

  3. Verifique o estado dos BGPSessionrecursos personalizados. Um BGPSessionrepresenta uma sessão de peering BGP individual estabelecida entre o seu cluster do Kubernetes e um par BGP externo. Inspecione os registos dos pods BGPAdvertiser e verifique se todos os recursos BGPSession estão no 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`

    A saída de um pod BGPAdvertiser em bom estado contém o seguinte 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. Verifique a estabilidade da ligação. Crie e execute um script para verificar se a conetividade é intermitente ou instável:

    1. Crie o script:

      #!/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. Execute o script:

      ./script.sh TARGET_IP_ADDRESS:PORT

      Substitua PORT pelo número da porta que está a ter problemas.

      Se a sua ligação tiver problemas, vê um resultado semelhante ao seguinte:

      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. O resultado anterior confirma o problema. Verifique as rotas nos comutadores TOR para ver se a configuração do comutador TOR é a origem do problema.

    Supondo que o tráfego é rejeitado para um endereço IP de exemplo de 192.0.2.201 e é anunciado pelo recurso BGPAdvertisedRoute, examine os saltos no recurso BGPAdvertisedRoute para identificar potenciais pontos de falha:

    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. Consulte os endereços IP no campo nextHops. Para cada endereço IP, encontre o nome do servidor. Por exemplo:

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

  7. Este resultado mostra que os próximos saltos são para servidores no rack aa e no rack ab. Inicie sessão nos comutadores TOR no rack aa e ab e compare as rotas em ambos os racks:

    show ip route 192.0.2.201 vrf root-external-vrf

  8. Se as rotas forem diferentes entre os comutadores TOR nos dois racks, está a ter o problema que a solução alternativa atenua. O resultado para este problema tem o seguinte aspeto:

    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

    Neste resultado, as rotas no rack aa estão no estado esperado, mostrando três saltos seguintes listados em relação ao prefixo. No entanto, no rack ab, o prefixo tem apenas dois saltos seguintes. Quando o tráfego destinado ao prefixo é aplicado hash ao rack, ab o nó correspondente ao próximo salto em falta nunca recebe o tráfego e a rede encontra o problema de conetividade.

Siga a solução alternativa para mitigar este problema.

Solução alternativa:

Esta solução alternativa ajuda a resolver problemas de conetividade intermitentes com determinados endereços IP em clusters do Kubernetes.

Para mitigar este problema, tem de aplicar várias alterações de configuração à sessão BGP entre os comutadores agregados. Os comutadores agregados (AGG) agregam o tráfego de vários comutadores TOR. Siga estes passos para atualizar todas as configurações necessárias:

  1. Um ficheiro de configuração denominado switchstaticconfig representa as configurações estáticas num único comutador. Transfira o ficheiro switchstaticconfig para ambos os comutadores 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. Obtenha o número do sistema autónomo (ASN) do ambiente:

    root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030

    Este resultado mostra um valor de ASN de 65030. Tem de usar o valor de ASN que é devolvido aqui nos passos seguintes.

  3. Um endereço IP de loopback num comutador AGG funciona como um endereço estável e sempre ativo para gestão, encaminhamento e resolução de problemas, mesmo que outras ligações de rede estejam inativas. Obtenha os endereços IP de loopback de cada um dos comutadores AGG:

    root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'

    O resultado tem um aspeto semelhante ao seguinte:

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

  4. Atualize o staticswitchconfig para o interrutor za-ab-aggsw01 AGG. Adicione este fragmento à secção 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

    Substitua o seguinte:

    • ASN: o valor ASN do passo anterior. Neste exemplo, este valor é 65030.
    • LOOPBACK_ADDRESS: este é o endereço IP de loopback do comutador AGG za-ac-aggsw01. Neste exemplo, o valor é 192.0.2.2.

  5. Aplique a mesma atualização ao outro comutador AGG, za-ac-aggsw01. Tem de fornecer o endereço de loopback correto. O endereço IP de loopback é diferente para cada comutador:

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

  6. Crie e execute o mesmo script usado para diagnosticar o problema neste passo para verificar se a correção foi bem-sucedida. O resultado não mostra mensagens de erro.

O erro Incorrect version of Trident é apresentado durante a atualização

Versões: 1.13.3, 1.13.4, 1.13.5

Sintomas: quando atualiza a partir de versões inferiores à 1.13.3, o ontap apresenta o erro Incorrect version of Trident. Pode ver uma mensagem como esta:

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:

Solução alternativa:

  1. Atualize o releasemetadata da versão para a qual está a fazer a atualização:

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

    O resultado pode ter o seguinte aspeto:

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

  2. Escolha a versão para a qual está a fazer a atualização, conforme mencionado no exemplo seguinte:

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

  3. Atualize o tridentVersion na secção fileBlockStorage do ficheiro .yaml para a versão mencionada no erro. Se a mensagem de erro tiver o seguinte aspeto:

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

    Altere o tridentVersion para v23.10.0-gke.5 em releasemetadata.yaml.

    Por exemplo, se o valor original fosse: infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6,

    Altere-o para o seguinte valor:

    infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5.

  4. Aplique as alterações:

    kubectl apply -f releasemetadata.yaml

  5. Aplique novamente a atualização de armazenamento do ontap.

Falha no agendamento dos pods

Versões: 1.13.3. 1.13.4 e 1.13.5

Sintomas: durante o aprovisionamento do cluster de utilizadores, não é possível agendar alguns pods. Pode ver uma mensagem como esta:

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

Solução alternativa:

Aumente a escala do node pool do painel de controlo do cluster de utilizadores:

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

Falha na atualização do subcomponente iac-zoneselection-global

Versões: 1.13.1

Sintomas: durante uma atualização para a versão 1.13.3, ocorre um erro no subcomponente iac-zoneselection-global. Pode ver uma mensagem como esta:

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

Solução alternativa:

A atualização para a versão 1.13.3 corrige o erro.

A verificação de atualização de tarefas excedeu o prazo

Versões: 1.12.x, 1.13.x

Sintomas: durante a atualização da organização, a verificação da atualização mostra o estado False com o motivo DeadlineExceeded. Pode ver uma mensagem como esta:

  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

Solução alternativa:

  1. Elimine as tarefas de verificação de atualização com falhas correspondentes às verificações de atualização com falhas.
  2. Aguarde até que as tarefas de verificação de atualização sejam recriadas.
  3. Analise os registos das tarefas recriadas e resolva os problemas.

O suplemento meta-monitoring falha devido à localização do strongswan estar num diretório de tempo de execução diferente

Versões: 1.12.x, 1.13.x

Sintomas: durante a atualização para a versão 1.13.4 ou 1.13.5, o suplemento meta-monitoring falha:

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

Verifique o suplemento:

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

A mensagem da condição pode ter o seguinte aspeto:

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

Solução alternativa:

  1. Certifique-se de que as sessões de BGP no cluster do sistema da organização estão a falhar, por exemplo:

    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. Certifique-se de que os ang-nodePods estão presosContainerCreating, por exemplo:

    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

    É apresentado o seguinte erro:

    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. Aplique a seguinte alteração à ang-overridesAddonConfiguration no cluster de administração da organização:

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

    Altere o seguinte:

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

    para o seguinte:

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

  4. Após cerca de um minuto, confirme que os ang-node Pods estão agora no 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. Certifique-se de que as sessões de BGP no cluster do sistema da organização estão agora em execução.

  6. O suplemento meta-monitoring vai avançar para a fase seguinte.

A atualização da organização de raiz está bloqueada devido a uma falha na tarefa de assinatura

Versões: 1.13.3, 1.13.4

Sintomas: quando atualiza de 1.13.3 para 1.13.4, pode ver uma mensagem como esta:

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

Solução alternativa:

  1. Desative a verificação prévia:

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

  2. Elimine a tarefa artifact-signature-verification-*** com falha.

  3. Aguarde até que a atualização de raiz esteja concluída.

  4. Opcional: ative a verificação pré-voo se o ambiente for atualizado para a versão 1.13.4 ou posterior.

Quando o comando tiver a versão 1.13.4, as atualizações não devem ter este problema.

A atualização da organização de inquilinos falha na fase de verificação prévia com ErrImagePull

Versões: 1.13.3

Sintomas: a atualização da organização de inquilinos falha na fase de verificação prévia com ErrImagePull para o pod de validação de pacotes. Pode ver uma mensagem como esta:

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

Os pods apresentam um ImagePullBackOff erro:

kubectl describe po -n package-validation-system POD_NAME

É apresentado um erro de obtenção de imagem, como no seguinte exemplo:

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"

Solução alternativa:

Ignore as verificações prévias:

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

Não foi possível encontrar serviceaccount durante a atualização da organização raiz

Versões: 1.13.8, 1.13.9

Sintomas: durante a atualização para a versão 1.13.8, a implementação do addon para RBACs falha se tiverem sido feitas atualizações anteriores e já existirem suplementos. Os sintomas podem estar num dos seguintes estágios:

  1. verificações prévias ou posteriores ao voo
  2. Qualquer fase que envolva uma tarefa de atualização e a mensagem indique que o trabalho está em execução, mesmo que a tarefa esteja bloqueada. A mensagem status.conditions indica que a tarefa está a ser executada durante muito tempo, o que indica que existe um problema.

Para verificar se existe uma falha na verificação prévia da atualização, verifique o estado do objeto OrganizationUpgrade correspondente da organização que está a fazer a atualização:

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

  1. Se a tarefa falhar em PreflightCheck, pode apresentar uma falha como esta ou uma mensagem UpgradeCheckRBACDeploymentInProgress:

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

  2. Se a tarefa estiver a falhar na fase do AnthosBareMetal (ABM) em que a tarefa está a ser executada, é apresentado o seguinte 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. Se a falha estiver nas verificações, o upgradecheckrequest CR falha:

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

    O resultado pode ter o seguinte aspeto:

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

  4. Se a falha estiver nas tarefas, o upgradetaskrequests CR falha:

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

    O resultado pode ter o seguinte aspeto:

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

  5. Se a falha indicar um erro de RBAC na procura de uma conta de serviço, verifique se foi implementado um suplemento 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

Solução alternativa:

  1. Verifique se foi implementado um suplemento 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. Obtenha os suplementos anteriores existentes para o mesmo componente, upgrade-task-mz para a tarefa:

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

  3. Eliminar este suplemento:

    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. Depois de eliminar o suplemento, também deve eliminar o upgradetaskrequest ou o upgradecheckrequest correspondente. É recriado.

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

  5. Continue a monitorizar o upgradetaskrequest, o upgradecheckrequest ou a tarefa correspondente recém-criados diretamente.

A atualização falha a shared-service-cluster upgrade

Versões: 1.13.3

Sintomas: a atualização do Anthos em bare metal está bloqueada com uma ou mais máquinas bare metal. Todas as outras máquinas bare metal foram atualizadas com êxito ou ainda não iniciaram a atualização. Uma máquina sem sistema operativo está no modo de manutenção, mas continua a apresentar a versão anterior para os campos CURRENT ABM VERSION e DESIRED ABM VERSION.

Siga as instruções do Anthos bare metal para obter o estado baremetalmachine e os detalhes do cluster:

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

Solução alternativa:

  1. Mova a máquina de inventário para fora do modo de manutenção:

    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. Aguarde que a máquina de inventário saia do modo de manutenção. Esta ação pode demorar até 10 minutos.

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

  3. Monitorize as baremetalmachines para ver se a máquina deteta a atualização da versão do ABM selecionada.

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

Falha na instalação do suplemento system-dashboards

Versões: 1.13.5

Sintomas: a atualização de 1.12.4 para 1.13.5 falha na atualização do suplemento para o suplemento 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

Solução alternativa: siga os passos no manual de instruções OCLCM-R0122.

O NodeUpgradeTask CR está bloqueado na condição NodeOSInPlaceUpgradePostProcessingCompleted

Versões: 1.13.5

Sintomas: durante a atualização para a versão 1.13.5, o NodeUpgradeTask CR fica bloqueado na condição NodeOSInPlaceUpgradePostProcessingCompleted.

Verifique se a tarefa os-artifact-collector correspondente está concluída. Se a tarefa estiver bloqueada durante muitas horas, é apresentada a seguinte mensagem:

  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

Solução alternativa:

  1. Elimine a tarefa ou o pod para forçar a nova tentativa.

A distribuição de imagens falha durante uma atualização

Versões: 1.13.5

Sintomas: a distribuição de imagens falha durante uma atualização da versão 1.12.4 para a 1.13.x:

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

Verifique os pods obj-proxy em gpc-system na organização para ver que está a falhar na validação de certificados:

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

Solução alternativa:

  1. Reinicie o pod obj-proxy com o comando KUBECONFIG da organização em que está a falhar:

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

  2. Verifique os registos de obj-proxy: 

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

    O resultado esperado é o seguinte:

    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. Verifique os registos dos pods disponíveis, por exemplo: 

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

  4. As tarefas de distribuição de imagens devem ser concluídas após a aplicação da solução alternativa.

O nó falha durante a atualização do cluster de utilizadores

Versões: 1.13.3

Sintomas: uma tarefa executada num nó falha durante a atualização do cluster de utilizadores e apresenta uma mensagem de erro como esta:

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

  1. Inicie sessão no nó e verifique se a partição está cheia:

    df -h /

    O resultado pode ter o seguinte aspeto:

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

  2. Verifique se /etc/kubernetes/tmp está a usar uma grande quantidade de espaço: du -s /etc/kubernetes/tmp. Este problema ocorre quando o Kubernetes faz mais cópias de segurança do que o habitual.

Solução alternativa:

  1. Limpe todas as cópias de segurança em rm -f /etc/kubernetes/tmp/*:

    df -h /

    O resultado pode ter o seguinte aspeto:

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

A atualização do administrador principal está a ser recriada e a falhar nas verificações prévias

Versões: 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9

Sintoma: a atualização da organização principal falha na verificação prévia, por exemplo:

│   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

O cluster de administrador principal e o kubeapiserver para o administrador principal foram atualizados para a versão do ABM escolhida.

Exemplo:

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

Exemplo de saída para kubectl describe kubeapiserver root-admin -n root:

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

Exemplo de saída para kubectl get cluster root-admin -n root:

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

Solução alternativa

Aplique a opção de ignorar a verificação prévia para continuar a atualização:

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

Os espaços de nomes platform-obs-obs-system ou platform-obs ficam presos no estado de encerramento

Versões: 1.13.5

Sintomas: os suplementos não são implementados durante a atualização ou o arranque e apresentam uma mensagem de erro semelhante a esta: 

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

É apresentado o seguinte resultado:

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

Se os estados DEPLOYED ou READY apresentarem false ou estiverem em branco, verifique os suplementos respetivos quanto ao erro, por exemplo:

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

É apresentado o seguinte resultado:

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

O suplemento está bloqueado devido à sua tentativa de criar conteúdo nos espaços de nomes em eliminação. Este bloqueio persiste, uma vez que a eliminação do espaço de nomes também está bloqueada.

Solução alternativa:

  1. Antes de iniciar uma atualização, anote os projetos para evitar a eliminação:

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

    É apresentado o seguinte 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

    Se o ambiente já estiver a apresentar os sintomas descritos anteriormente, siga esta solução alternativa:

  2. A eliminação do espaço de nomes está bloqueada devido a recursos com finalizadores. Para continuar com a eliminação, remova os finalizadores através do script fornecido: 

      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. Aguarde a eliminação do recurso. Depois de executar o script, elimine os recursos e os espaços de nomes de terminação. Pode ter de executar o script novamente se o espaço de nomes continuar no estado de encerramento. Após a rescisão, o espaço de nomes é recriado automaticamente. Verifique se os espaços de nomes foram recriados e estão no estado ATIVO:

      export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system

    É apresentado o seguinte resultado:

      NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s

    Com os espaços de nomes ativos, os suplementos que estavam bloqueados devem ser implementados em poucos minutos. Verifique se os respetivos estados DEPLOYED e READY são agora verdadeiros:

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

    É apresentado o seguinte resultado:

      NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998

UPORC crash loops in the KIND cluster during bootstrap

Versões: 1.13.x

Sintomas: a implementação uporc-root-backend-controller no espaço de nomes uporc-system entra em ciclos de falhas no cluster KIND.

Solução alternativa:

  1. Verifique se os objetos ComponentGroupReleaseMetadata e ReleaseMetadata correspondem:

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    Se os objetos corresponderem, não é necessária nenhuma solução alternativa.

  2. Se os objetos não corresponderem, contacte a equipa do UPORC para receber assistência, uma vez que isto pode indicar outros problemas subjacentes.

Falha na atualização do nó

Versões: 1.13.6

Sintomas: a atualização do nó falhou em NodeOSInPlaceUpgradeCompleted.

  1. Verifique os registos das tarefas da os-upgrade ospolicy.
  2. Se o registo incluir um erro que sugira que o ficheiro de configuração está danificado, introduza o computador do nó e verifique o conteúdo do ficheiro manualmente para ver se está danificado. O erro de registo pode mencionar o código de erro configparser.DuplicateOptionError e o ficheiro /etc/yum.repos.d/gdch.repo.

Solução alternativa: apenas se tiver confirmado que o ficheiro está danificado, elimine manualmente o ficheiro /etc/yum.repos.d/gdch.repo danificado no nó danificado.

A tarefa ansible para a atualização regenera o ficheiro automaticamente, como parte do playbook ansible.

### NodeUpgradeTask CR está bloqueada na condição NodeOSInPlaceUpgradePostProcessingCompleted

Versões: 1.13.5

Sintomas: durante a atualização para a versão 1.13.5, o NodeUpgradeTask CR fica bloqueado na condição NodeOSInPlaceUpgradePostProcessingCompleted.

Verifique se a tarefa os-artifact-collector correspondente está concluída. Se a tarefa estiver bloqueada durante muitas horas, é apresentada a seguinte mensagem:

  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

Solução alternativa:

  1. Elimine a tarefa ou o pod para forçar a nova tentativa.

O NodeUpgradeTask CR está bloqueado na condição NodeBIOSFirmwareUpgradeCompleted

Versões: 1.13.5

Sintomas: durante a atualização para a versão 1.13.5, o NodeUpgradeTask CR fica bloqueado na condição NodeBIOSFirmwareUpgradeCompleted.

Verifique se a condição NodeBIOSFirmwareUpgradeCompleted correspondente está bloqueada com a seguinte condição apresentada:

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

Solução alternativa:

  1. No NodeUpgrade CR, edite manualmente "U30 v3.20 (05/29/2024)" para "U30 v3.20 (05/27/2024)".

A atualização do cluster está bloqueada porque um nó não consegue entrar no modo de manutenção

Versões: 1.13.5, 1.13.6, 1.13.7

Sintomas: a atualização do cluster (administrador da organização, sistema ou cluster de utilizadores) está bloqueada devido a um nó que não consegue entrar no modo de manutenção.

O cluster mostra MaintenanceMode definido como true, mas Status está bloqueado em false quando executa o seguinte:

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

É apresentado o seguinte 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

Solução alternativa:

Defina o KUBECONFIG para o ficheiro kubeconfig do cluster que contém o nó que não está a ser drenado. O cluster pode ser o cluster de utilizadores ou um cluster de serviços partilhados.

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

Excedeu o limite de tempo persistente durante a raiz inicial organizationupgrade

Versões: 1.13.3

Sintomas: se a anotação ignore maintenance window estiver presente durante uma atualização da organização, o organizationupgrade CR é repetidamente corrigido, o que repõe o progresso.

Solução alternativa:

Pause o subcomponente rm-org e reduza as réplicas rm-org-backend-controller.

  1. Se o alias não for declarado, execute o seguinte comando:

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

  2. Pause o subcomponente e reduza a implementação para 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. Após a conclusão da atualização do cluster, reduza a implementação:

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

O subcomponente obj-syslog-server não consegue fazer a conciliação na organização de raiz

Versões: 1.13.3, 1.13.4, 1.13.5, 1.13.6

Sintomas: durante a atualização para a versão 1.13.x, o subcomponente obj-syslog-server encontra-se no estado ReconciliationError:

root        obj-syslog-server     ReconciliationError

com uma condição semelhante a:

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

Pode ver que o pod, syslog-server-abcdefg-wxyz, está num estado CrashLoopBackOff com o seguinte erro:

       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"

Solução alternativa:

Para repor o subcomponente num estado normal, remova o volumeMounts desnecessário.

  1. Edite a implementação atual:

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

    kubectl edit deployments syslog-server -n istio-system

  2. Remova os volumeMounts que não são necessários no spec.containers.volumeMounts. Remova os seguintes caminhos de montagem:

        - 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. Aplique as alterações e o subcomponente volta a ReconciliationCompleted depois de as alterações serem aplicadas.

A atualização do ABM ou do nó está bloqueada em maintenanceMode false

Versões: 1.13.4

Sintomas: o nó está bloqueado na atualização do cluster AnthosBaremetal e não entra no modo de manutenção.

Verifique a baremetalmachine num nó do cluster de serviço, por exemplo:

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

Solução alternativa:

Reinicie o anthos-cluster-operator para propagar o BMM.MaintenanceMode:

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

A atualização falha na atualização do suplemento atat-webhooks para a organização do inquilino

Versões: 1.13.5

Sintomas: a atualização do suplemento atat-webhooks não é recuperada:

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Pode ver uma mensagem como esta:

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

Verifique os pods para atat-webhooks-parameters-*****: 

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Pode ver um erro 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.

Solução alternativa:

  1. Crie uma cópia da carteira atual:

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

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

  2. Atualize portfolio-org-1 Pop End Date para uma data no futuro:

    kubectl delete portfolios -n atat-system portfolio-org-1

    Se este comando deixar de responder, elimine a condição .Metadata.Finalizers do portefólio ativo antes de eliminar o portefólio. A condição pode ter o seguinte aspeto:

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

  3. Volte a aplicar o ficheiro YAML copiado:

    kubectl apply -f portfolio-org-1

  4. Verifique novamente as datas para garantir que os portefólios e o configmap estão atualizados.

  5. Se a tarefa não for recuperada, elimine a tarefa atat-webhooks-parameters com falhas para que seja recuperada. Aguarde a conclusão:

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

A verificação pós-implementação ou de atualização falha devido a erros DeadlineExceeded ou BackoffLimitExceeded.

Versões: 1.13.8

Sintomas:

Durante a atualização da versão 1.13.7 para a 1.13.8, as verificações pós-voo continuam no estado pendente e mostram erros DeadlineExceeded ou 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]

Solução alternativa:

Identifique onde as tarefas estão a falhar:

  1. Verifique se as tarefas estão a falhar durante as verificações pré-voo ou pós-voo:

    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. Verifique se as tarefas estão a falhar durante a atualização:

    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. Elimine as tarefas:

    kubectl delete jobs -n gpc-system CHECK_NAME

As verificações de atualização incluem resultados irrelevantes para o nível de verificação

Versões: 1.13.x

Sintomas:

As verificações de atualização da organização podem falhar devido a resultados incluídos incorretamente de outros níveis. Por exemplo, as verificações da organização raiz podem mostrar resultados da organização inquilina ou as verificações da organização inquilina podem apresentar resultados do cluster de utilizadores.

Exemplos de registos de falhas para verificações da organização raiz:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

Solução alternativa:

Ignore totalmente as verificações prévias ou posteriores com:

Verificação prévia:

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

Pós-voo:

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

As APIs pré-preparadas mostram um estado Enabling na interface do utilizador

Versões: 1.13.1

Sintomas: o MonitoringTarget mostra um estado Not Ready quando os clusters de utilizadores estão a ser criados, o que faz com que as APIs pré-preparadas mostrem continuamente um estado Enabling na interface do utilizador.

Solução alternativa:

  1. Abra o menu no navegador Chrome (ícone de três pontos).
  2. Clique em Mais ferramentas > Ferramentas para programadores para abrir a consola.
  3. Clique no separador Rede na consola.
  4. Encontre os ai-service-status pedidos.
  5. Clique no separador Resposta num pedido ai-service-status para mostrar o conteúdo desse pedido.
  6. Verifique se tudo parece pronto, exceto os componentes MonitoringTarget e LoggingTarget.

A função de API pré-preparada streaming_recognize de Speech-to-Text falha

Versões: 1.13.3

Sintomas: quando chama a função de API pré-preparada streaming_recognize de Speech-to-Text, um problema com a biblioteca de cliente provoca uma mensagem de erro 400 semelhante à seguinte:

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

Solução alternativa: use o seguinte script Python para permitir que a função streaming_recognize funcione:

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)

Substitua o seguinte:

O script Python introduz as seguintes diferenças entre as funções streaming_recognize e recognize para permitir que a solução alternativa para streaming_recognize funcione:

  • Linha 4: uma declaração import adicional em comparação com o script recognize (from google.cloud.speech_v1p1beta1.services.speech import client).
  • Linha 18: o cliente é devolvido por client.SpeechClient() em vez de speech_v1p1beta1.SpeechClient().

O pod e o serviço de frontend de tradução não são inicializados

Versões: 1.11.x, 1.12.x, 1.13.x

Sintomas: durante as atualizações, o cluster da base de dados de tradução é recriado, o que faz com que o segredo do cluster do sistema ODS secret-store fique desatualizado e dessincronizado. Por este motivo, o pod e o serviço de frontend de tradução falham a inicialização.

Solução alternativa:

Elimine o segredo no cluster do sistema:

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

Substitua SYSTEM_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig no cluster do sistema.

Um controlador recria o Secret automaticamente e sincroniza-o novamente com o cluster de BD.

A sondagem do estado da tarefa não é suportada para a API batchTranslateDocument

Versões: 1.13.3

Sintomas: a Vertex AI não suporta operações GET e LIST nas APIs do serviço de tradução. Chamar a API BatchTranslateDocument Translation devolve uma operação de execução prolongada semelhante ao seguinte exemplo:

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Este problema deve-se a uma limitação da APIP (autorização) que impede a chamada direta do ponto final. Os pontos finais não suportam a sondagem do estado da tarefa e não pode realizar operações GET na operação de longa duração devido à limitação da APIP.

Solução alternativa: como operador de aplicações (AO), reveja o estado da tarefa verificando regularmente a pasta s3_destination e procure um ficheiro de saída da tarefa recém-criado. Se a pasta contiver o ficheiro de saída, a tarefa foi concluída com êxito.

batchTranslateDocument pedidos podem causar problemas de desempenho

Versões: 1.13.3

Sintomas: o serviço de tradução de documentos em lote lê um ou vários ficheiros de entrada do utilizador e escreve os ficheiros de saída traduzidos e de processamento temporário no StorageGRID. É criado um novo cliente curl para cada ação de leitura/escrita porque a reutilização do cliente falha.

Os clientes curl do S3 no ficheiro binário são de utilização única, o que significa que cada cliente só pode realizar uma única ação de leitura/escrita em contentores do StorageGRID. Por conseguinte, é criado um novo cliente curl sempre que a comunicação com o cliente do StorageGRID é estabelecida a partir do servidor batchTranslateDocument para ler e escrever ficheiros em contentores.

No entanto, esta opção não é ideal para clientes do curl. Pode levar aos seguintes problemas:

  • Degradação do desempenho: aumento da latência e diminuição da taxa de transferência
  • Esgotamento de recursos: sobrecarga de memória e CPU e esgotamento de tomadas
  • Sobrecarga do servidor: limitação de velocidade ou limitação

A consola GDC mostra um estado inconsistente após a ativação das APIs pré-preparadas

Versões: 1.13.3

Sintomas: quando ativa as APIs pré-preparadas pela primeira vez, a consola GDC pode apresentar um estado inconsistente após alguns minutos para o serviço ativado. A consola GDC muda o estado Enabling novamente para Disabled e mostra o botão Ativar novamente na interface do utilizador, mesmo que o serviço esteja, de facto, a ser ativado.

Solução alternativa: o estado torna-se consistente após alguns minutos e o serviço reflete o estado correto.

Para verificar o estado do serviço, abra o separador Rede na consola do navegador e verifique o estado do pedido ai-service-status. A carga útil tem de mostrar que o operador de nível 2 está ativado.

Os pedidos de tradução com mais de 250 carateres falham nos translation-prediction-server pods

Versões: 1.13.3

Sintomas: quando envia pedidos de tradução com aproximadamente 250 carateres ou mais (incluindo pedidos de tradução de documentos), os pods translation-prediction-0 ou translation-prediction-1 podem falhar, o que requer o recarregamento do modelo. O recarregamento do modelo ocorre automaticamente e este processo pode demorar cerca de 30 minutos a ser resolvido.

Este problema deve-se a uma limitação dos contentores de tradução.

Solução alternativa: divida os pedidos de tradução para que tenham menos de 250 carateres. Um intervalo entre 200 e 250 carateres é seguro para todos os idiomas. Não é necessária qualquer outra ação para mitigar o problema se um pedido longo falhar nos pods.

O GPUAllocation para o cluster de serviços partilhados não está configurado corretamente

Versões: 1.13.3

Sintomas: não é possível agendar cargas de trabalho do Vertex AI devido à falta de recursos de GPU suficientes. Por exemplo, se não conseguir ver nem ativar os pontos finais de serviço da Vertex AI, pode dever-se à falta de recursos de GPU suficientes.

Este problema de recursos pode ser causado por alguns dos recursos GPUAllocation localizados no cluster de serviços partilhados que não têm a seguinte anotação:

processed: "true"

Solução alternativa:

  1. Siga o procedimento IAM-R0004 para gerar o ficheiro kubeconfig para o g-ORG_NAME-shared-service-cluster.

  2. Liste todas as atribuições de GPU no cluster de serviços que não tenham a anotação processed: "true":

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

    O resultado é semelhante ao seguinte:

    zi-ad-bm08

  3. Para o recurso GPUAllocation que não está atribuído, abra-o num editor:

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. Edite a atribuição de GPU com base no número total de atribuições de GPU presentes no cluster de serviços:

    • Se existir apenas um recurso personalizado de atribuição de GPU, adicione-lhe a anotação processed: "true" e modifique a respetiva especificação para ser semelhante à seguinte:

      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

    • Se existirem dois recursos personalizados de atribuição de GPU, encontre o que não tem a anotação processed: "true", adicione-lhe a anotação processed: "true" e modifique a respetiva especificação para ficar semelhante à seguinte:

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • Se existirem quatro recursos personalizados de atribuição de GPU, procure o que não tem a anotação processed: "true", adicione-lhe a anotação processed: "true" e modifique a respetiva especificação para ser semelhante à seguinte:

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. Guarde as alterações ao recurso personalizado GPUAllocation e confirme se o respetivo estado de atribuição foi atualizado para true:

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

    O resultado é semelhante ao seguinte:

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

Quando atualiza da versão 1.9.x para a 1.13.3, o controlador OCLCM apresenta erros

Versões: 1.13.3

Sintomas: quando atualiza da versão 1.9.x para a 1.13.3, o controlador da gestão do ciclo de vida de componentes operacionais (OCLCM) para subcomponentes da Vertex AI pode apresentar erros. Este problema é causado por um erro na tarefa do suplemento ai_platform. Os erros que recebe durante a atualização indicam que o OCLCM não consegue transferir a propriedade destes componentes do Vertex AI.

Seguem-se os componentes do Vertex AI afetados no cluster de administrador da organização:

Nome Espaço de nomes
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

Solução alternativa: para resolver este problema, tem de remover manualmente os componentes afetados da Vertex AI do cluster de administrador da organização. Em seguida, a nova versão do Vertex AI baseada no OCLCM reinstala-os.

Remova manualmente os componentes afetados do Vertex AI no cluster de administrador da organização:

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

Substitua o seguinte:

  • ORG_ADMIN_CLUSTER_KUBECONFIG: o caminho para o ficheiro kubeconfig no cluster de administrador da organização.
  • NAMESPACE: o espaço de nomes do componente do Vertex AI que quer remover. Se o componente não tiver um espaço de nomes, remova -n NAMESPACE do comando.
  • COMPONENT_NAME: o nome do componente do Vertex AI que quer remover.

O exemplo seguinte mostra como remover o componente aip-l1operator-deployment que existe no espaço de nomes ai-system no cluster de administrador da organização:

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

Os pedidos de tradução podem gerar o código de erro RESOURCE_EXHAUSTED

Versões: 1.13.3

Sintomas: depois de enviar um pedido de tradução, recebe o código de erro RESOURCE_EXHAUSTED na mensagem de resposta. Este erro ocorre quando excede um limite de frequência do sistema. Um recurso foi esgotado, como uma quota por utilizador, o número máximo de consultas por segundo ou o sistema de ficheiros completo está sem espaço.

Solução alternativa: peça ao seu operador de infraestrutura (IO) para reiniciar os fragmentos de back-end do serviço de tradução. Em seguida, envie novamente pedidos de tradução com intervalos de tempo mais longos entre pedidos ou enviando pedidos mais curtos.

As solicitações batchTranslateDocument devolvem o erro 503

Versões: 1.13.3

Sintomas: depois de enviar um pedido batchTranslateDocument, recebe o código de erro 503 "Batch Document translation is not implemented" na mensagem de resposta. Este erro ocorre porque o método BatchTranslateDocument requer o serviço Aspose, que só é implementado quando o parâmetro enableRAG operável está definido como true no cluster.

Solução alternativa: peça ao operador de infraestrutura (IO) para definir o parâmetro enableRAG operable como true no cluster de administrador da organização seguindo estes passos:

  1. Crie um SubcomponentOverride recurso personalizado num ficheiro YAML denominado vai-translation.yaml com o parâmetro enableRAG operable 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

    Substitua ORG_ADMIN_NAMESPACE pelo espaço de nomes do cluster de administrador da organização.

  2. Aplique o recurso personalizado SubcomponentOverride ao cluster de administrador da organização:

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

    Substitua ORG_ADMIN_KUBECONFIG pelo caminho para o ficheiro kubeconfig no cluster de administrador da organização.

Serviços pré-treinados do Vertex AI indisponíveis

Versões: 1.13.7, 1.13.9

Sintomas: os serviços Vertex AI OCR e Translation não são iniciados devido a problemas de agendamento do Kubernetes. Pode ver um aviso como este nos registos:

 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.

Solução alternativa: adicione mais nós de trabalho ao conjunto predefinido e despeje os pods nos nós de GPU para que as cargas de trabalho de IA possam ser agendadas.

Máquinas virtuais

A importação de imagens BYO falha para imagens qcow2 e raw

Versões: 1.13.1, 1.13.3

Sintomas: quando as imagens de VMs locais são importadas através da CLI gdcloud compute images import, o estado de importação fica bloqueado em WaitingForTranslationVM ou ImportJobNotCreated. Isto deve-se ao facto de o disco temporário criado para traduzir ou importar usar o tamanho exato da imagem qcow2/raw, mas o LUKS adiciona uma sobrecarga de alguns MiBs que faz com que o aprovisionamento do disco falhe.

Solução alternativa:

Crie manualmente um novo VirtualMachineImageImport com o mesmo nome de imagem, mas com um spec.minimumDiskSize maior

Por exemplo, se este foi o comando usado para importar a imagem:

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

Se o grupo de recursos original VirtualMachineImageImport criado automaticamente pela CLI tiverminimumDiskSize como X Gi, crie um novo com X+1 Gi. O valor baseia-se no tamanho da imagem que está a ser importada. No caso do qcow2, seria o tamanho virtual. Por exemplo, 20 Gi deve ser substituído por 21 Gi.

Substitua os valores dos marcadores de posição com base na forma como a CLI foi chamada.

  1. Encontre o VirtualMachineImageImport:

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    Se o objeto não estiver presente, acione novamente o comando gdcloud compute images import .... Quando o resultado da consola transitar de Uploading image to .. para Image import has started for ..., prima ctrl+c para que a imagem local seja carregada para o armazenamento de objetos e o VirtualMachineImageImport seja preservado para referência na criação de um novo.

  2. Crie um novo VirtualMachineImageImport com um minimumDiskSize maior:

    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

O aprovisionamento de um disco a partir de uma imagem falha

Versões: 1.13.1, 1.13.3

Sintomas: quando aprovisiona um disco a partir de uma imagem personalizada, o minimumDiskSize pode estar demasiado próximo do tamanho virtual, o que faz com que o aprovisionamento do disco falhe. O disco da VM está num estado pendente, mas nunca é aprovisionado.

Solução alternativa: crie manualmente um novo disco com um spec.minimumDiskSize maior.

O plug-in de dispositivos NVIDIA DaemonSet falha quando um cluster tem GPUs

Versões: 1.13.3

Sintomas: o plug-in do dispositivo NVIDIA DaemonSet falha com a mensagem driver rpc error em nós do cluster com GPUs:

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

Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig no cluster.

Obtém um resultado semelhante ao seguinte exemplo:

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 faz com que as GPUs fiquem indisponíveis para máquinas virtuais (VM) e pods. As implicações baseiam-se nos seguintes tipos de clusters:

  • Cluster do sistema: o recurso personalizado GPUAllocation não é criado para esse nó bare metal e as GPUs nesse nó não são configuradas no modo de VM para consumo pelo serviço e pelo cluster de utilizadores. Consulte a solução alternativa para o cluster do sistema para resolver este problema.
  • Serviço ou cluster de utilizadores: o recurso personalizado GPUAllocation não é criado para esse nó de VM e os GPUs nesse nó não são consumíveis por pods no cluster. Consulte a solução alternativa para o serviço ou o cluster de utilizadores para resolver este problema.

Solução alternativa para o cluster do sistema:

Siga estes passos para resolver o problema no cluster do sistema:

  1. Defina a variável de ambiente KUBECONFIG com o caminho para o ficheiro kubeconfig no cluster do sistema. Para obter detalhes, consulte o manual de procedimentos IAM-R0004.

  2. Identifique o nó que está a ter o problema:

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

    O resultado tem de imprimir o nome do nó e o endereço IP do nó do Kubernetes.

    Se existirem vários nós, execute os passos em todos eles. Neste caso, o resultado tem o seguinte aspeto:

    Node:                 yy-ab-bm04/172.20.128.26

  3. Defina a variável de ambiente NODE_NAME com o nome do nó, por exemplo:

    export NODE_NAME=yy-ab-bm04

  4. Estabeleça uma ligação SSH com o nó. Para obter detalhes, consulte o manual de procedimentos PLATAUTH-G0001.

  5. Verifique se o nó tem GPUs:

    nvidia-smi -L

    O resultado tem de imprimir as GPUs no nó, como no exemplo seguinte:

    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. Ative o modo de persistência nas GPUs:

    nvidia-smi -pm 1

    Esta ação garante que os controladores da NVIDIA são sempre carregados para que o plug-in do dispositivo não expire.

    O resultado tem de ser semelhante ao seguinte exemplo:

    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. Saia da sessão SSH:

    exit

  8. Verifique se o plug-in do dispositivo está em execução consultando o DaemonSet:

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

  9. Verifique se o recurso personalizado GPUAllocation foi criado e configurado no modo de VM:

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    O resultado tem de ser semelhante ao seguinte exemplo:

    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

Solução alternativa para o serviço ou o cluster de utilizadores:

Siga estes passos para resolver o problema no serviço ou no cluster:

  1. Defina a variável de ambiente KUBECONFIG com o caminho para o ficheiro kubeconfig no serviço ou no cluster de utilizadores. Para obter detalhes, consulte o manual de procedimentos IAM-R0004.

  2. Identifique o nó que está a ter o problema:

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

    O resultado tem de imprimir o nome do nó e o endereço IP do nó do Kubernetes.

    Se existirem vários nós, execute os passos em todos eles. Neste caso, o resultado tem o seguinte aspeto:

    Node:                 vm-948fa7f4/172.20.128.21

  3. Defina a variável de ambiente NODE_NAME com o nome do nó, por exemplo:

    export NODE_NAME=vm-948fa7f4

  4. Estabeleça uma ligação SSH com o nó. Para obter detalhes, consulte o manual de procedimentos PLATAUTH-G0001.

  5. Verifique se o nó tem GPUs:

    nvidia-smi -L

    O resultado tem de imprimir as GPUs no nó, como no exemplo seguinte:

    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. Ative o modo de persistência nas GPUs:

    nvidia-smi -pm 1

    Esta ação garante que os controladores da NVIDIA são sempre carregados para que o plug-in do dispositivo não expire.

    O resultado tem de ser semelhante ao seguinte exemplo:

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

  7. Saia da sessão SSH:

    exit

  8. Verifique se o plug-in do dispositivo está em execução consultando o DaemonSet:

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

  9. Verifique se o recurso personalizado GPUAllocation foi criado e configurado no modo de VM:

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    O resultado tem de ser semelhante ao seguinte exemplo:

    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

A VM do cluster do sistema não está pronta

Versões: 1.13.3

Sintomas: a VM do cluster do sistema não está pronta. Pode ver uma mensagem como esta:

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

Solução alternativa:

  1. Encontre o ficheiro VirtualMachineInstance e elimine-o.
  2. Reiniciar uma nova VM.

Não foi encontrado o espaço temporário dos relatórios de volume de dados

Versões: 1.13.3, 1.13.4

Sintomas: quando cria um disco de VM, o volume de dados é apresentado como bem-sucedido:

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

No entanto, um pod de importação, como importer-gdc-vm-disk-vm-ce34b8ea-disk crash loops, com uma mensagem como esta:

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

Solução alternativa: elimine o pod do importador depois de confirmar que o estado do volume de dados é Succeeded.

As VMs em projetos com nomes que excedem 45 carateres permanecem num estado parado

Versões: 1.13.5

Sintomas: quando cria uma VM, esta permanece no estado Stopped se o nome do projeto tiver mais de 45 carateres.

Solução alternativa: crie um projeto com um nome que não tenha mais de 45 carateres.

Atribuição de GPU em falta no cluster de serviço

Versões: 1.13.5

Sintomas: o GPUAllocation está em falta no cluster de serviços partilhados de gpu-org. Pode ver uma mensagem quando recebe as atribuições de GPU:

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

O resultado tem o seguinte aspeto:

No resources found

Solução alternativa:

  1. Adicione uma restrição ao nó da GPU:

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

  2. Remova a restrição para permitir o agendamento do pod virt-launcher da VM.

Não é possível agendar a VM de trabalho do cluster de serviço partilhado

Versões: 1.13.6

Sintomas: uma VM de trabalho do Kubernetes não conseguiu agendar devido a recursos de CPU insuficientes no nó designado, apesar das GPUs disponíveis. Pode ver um 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.

Solução alternativa:

  1. Pare manualmente as VMs sem GPU para libertar recursos da CPU.
  2. Depois de agendar a VM pendente, inicie as VMs sem GPU.