Esta página foi traduzida pela API Cloud Translation.

Problemas conhecidos do Google Distributed Cloud com isolamento físico 1.13.x

Artifact Registry

Erro de reconciliação do subcomponente `sar-failoverregistry`

Versões: 1.13.1, 1.13.3, 1.13.4

Sintomas:ao criar o cluster de administrador raiz com o comando gdcloud system admin-cluster install, a operação poderá falhar se houver uma longa lista de servidores durante a inicialização. A mensagem de erro é esta:

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

Solução alternativa:para minimizar esse problema, siga estas etapas:

No mesmo cluster do Kubernetes que o subcomponente, liste os servidores e confirme se cada recurso personalizado do servidor tem um rótulo com a chave como cluster.private.gdc.goog/inventory-machine:
```
kubectl get servers -n gpc-system
```

Encontre o recurso personalizado do componente que se parece com o 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

No recurso personalizado do componente System Artifact Registry (SAR), adicione o seletor de rótulo nos servidores runtimeParameterSources para sar-failover-registry:

Confira o recurso server atual:

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

Atualize o campo "servers" 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"

Verifique se as mudanças no componente SAR da etapa anterior foram propagadas para o subcomponente sar-failverregistry:
1. Confira os detalhes do componente SAR:
```
kubectl get component | grep sar
```
2. Confira os detalhes do componente sar-failoverregistry:
```
kubectl get subcomponent sar-failoverregistry -n root
```
  Use a flag -n para especificar o namespace.

Backup e restauração

Falha nos snapshots devido à falta de espaço no volume

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

Sintomas:há um problema intermitente com o backup de volume permanente que pode afetar os fluxos de trabalho de jobs de backup periódicos. Para alguns volumes com uma alta taxa de mudança, os instantâneos de volume criados para backups em andamento podem fazer com que o volume fique sem espaço, o que coloca o volume no modo somente leitura.

Solução alternativa:para evitar um possível impacto nas cargas de trabalho de produção, siga as etapas no runbook BACK-R0104. Se quiser, também é possível remover snapshots acumulados seguindo o runbook BACK-R0106.

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

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

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

Solução alternativa:aumente a memória para o plano de controle e os pods do agente seguindo as instruções no runbook BACK-R0005. Aumente a memória para os pods para 2 GiB.

Falha no backup do snapshot do PVC

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

Sintomas:as falhas de backup ocorreram devido ao excesso do limite de snapshots do ONTAP de 1.023 por recurso PersistentVolumeClaim (PVC).

Solução alternativa:Para minimizar esse problema, siga estas etapas:

Atualize o plano de backup para que os limites nunca sejam atingidos. Configure um plano de backup para fazer backup a cada hora ou reduza o deleteLockDays para três para que o número de snapshots não aumente 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:
- LOCK_DAYS: bloqueia a exclusão do backup pelo número de dias especificado após a criação. Use os valores a seguir:
  - Se o campo volumeStrategy for definido como LocalSnapshotOnly, use o valor 2.
  - Se o campo volumeStrategy for definido como ProvisionerSpecific, use o valor 7.
- RETENTION_DAYS: exclui backups após o número de dias especificado após a criação do backup. Se o campo volumeStrategy estiver definido como um valor de LocalSnapshotOnly, use um valor menor que 3.

Exclua manualmente os snapshots em excesso do seu ambiente usando comandos de exclusão de snapshots de volume. Siga estas etapas:

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:

ORG_NAME: o nome da organização.
PVC_NAME: o nome do recurso PVC relacionado ao plano de backup.

O NetApp ONTAP é um sistema operacional usado para administrar o armazenamento do GDC. Receber 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

Liste todos os snapshots 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 senha da etapa anterior para fazer login na máquina no endereço IP definido pela variável MGMT_IP.

Encontre o PVC com a maior contagem de snapshots:

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

Defina o nome do recurso PVC como aquele com a alta contagem de snapshots:
```
export PV_NAME=
```

Exclua o snapshot do recurso PVC que contém a contagem alta de snapshots. O limite para o número de snapshots de um recurso PVC é 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

Faça login no ONTAP e execute estes comandos para excluir o snapshot:

echo $PASSWORD

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

Execute os comandos listados na etapa anterior para excluir o snapshot. Quando terminar, saia da sessão SSH.

Repita as etapas de exclusão até que todos os snapshots PVC ofensivos sejam limpos.

Restaurar de um backup incompatível com a cota de SVM

Versões: 1.13.1

Sintomas:o problema é uma incompatibilidade entre os recursos da NetApp. Essa incompatibilidade impede a entrega da cota do locatário e a implementação bem-sucedida das restaurações. O problema só ocorre ao restaurar um backup em um cluster de usuário com restrição de cota.

Solução alternativa:se esse problema ocorrer, a restauração vai falhar com a mensagem de erro DP volumes are not supported on storage-limit enabled Vserver, e o operador de infraestrutura (IO) precisará desativar a cota para esse cluster de usuário e reiniciar o processo de restauração. Depois que a restauração for concluída, o IO precisará reativar as cotas do locatário, e o sistema vai continuar funcionando como esperado. Consulte o runbook FILE A0030 para mais detalhes.

Faturamento

As métricas de faturamento não aparecem corretamente no painel de faturamento

Versões: 1.13.1

Sintomas:as métricas de faturamento 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.

Exporte a seguinte variável kubeconfig:
```
export KUBECONFIG=KUBECONFIG_PATH
```
Substitua a variável KUBECONFIG_PATH pelo caminho para o arquivo kubeconfig do cluster de administrador da organização. Siga as etapas em Manual de serviços IAM-R0101 para gerar o arquivo kubeconfig necessário para essa solução alternativa.

Crie um recurso billing-monetizer MetricsProxySidecar para os namespaces billing-system e partner-billing-system:

Para obter 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 obter 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

Execute o script a seguir para atualizar o metricExpression. Isso 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 usuário não consegue criar `BillingAccountBinding` devido a bugs no webhook de validação.

Versões: 1.13.0, 1.13.1, 1.13.3

Sintomas:o bug está na lógica do webhook de validação BillingAccountBinding. Se um usuário tentar criar um recurso BillingAccountBinding, o webhook vai retornar o erro permission denied.

Solução alternativa:para criar recursos BillingAccountBinding, notifique o operador de infraestrutura e crie os recursos correspondentes usando a IAC.

Armazenamento em blocos

Pods do Grafana travados no estado `Init` devido a erros de ativação de volume.

Versões: 1.13.3

Sintomas:

Os pods do Grafana nos namespaces anthos-identity-service-obs-system e platform-obs-obs-system estão travados no estado Init devido a erros de ativação de volume. A mensagem de erro nos registros do kubelet indica um problema de multiencadeamento. O problema decorre de um bug no Trident, em que ele não consegue identificar e verificar corretamente o dispositivo subjacente para mapeamentos LUKS, resultando em um erro de multiencadeamento.

Alternativa:

Verifique se o PVC tem um "deletionTimestamp". Se não houver deletionTimestamp (migração de pod), siga estas etapas:

Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado no momento.
Isolar os Nodes no cluster que não correspondem a esse valor.
Exclua o Pod com falha. Isso vai fazer com que ele migre de volta para o Node original.

Depois de verificar, se houver um "deletionTimestamp" (exclusão de volume), siga estas etapas:

Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado no momento.
No Node, gere o conteúdo do arquivo de rastreamento:
```
cat /var/lib/trident/tracking/PVC_NAME.json
```
Valide se o dispositivo LUKS encontrado no campo devicePath da saída do arquivo de rastreamento está realmente fechado. Este caminho não pode existir neste momento:
```
stat DEVICE_PATH
```
Valide se o número de série está mapeado para algum dispositivo multipath.
1. Copie o valor no campo iscsiLunSerial do arquivo de rastreamento.
2. Converta esse valor no valor hexadecimal esperado:
```
echo 'iISCSILUNSERIAL' | xxd -l 12 -ps
```
3. Com esse novo valor, verifique se a entrada de vários caminhos ainda existe:
```
multipath -ll | grep SERIAL_HEX
```
4. Se ele não existir, exclua o arquivo de rastreamento.
5. Se ele existir, você vai encontrar um valor hexadecimal serial um pouco mais longo do que o pesquisado, chamado de multipathSerial. Execute o comando a seguir e encontre os dispositivos de bloco:
```
multipath -ll MULTIPATH_SERIAL
```
6. Em seguida, execute os comandos a seguir. O último é executado exclusivamente para cada dispositivo de transferência por blocos:
```
systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
```

Falha no mapeamento de volumes dos pods de inicialização de máquinas virtuais

Versões: 1.13.1

Sintomas:

Talvez você veja um aviso como este:

 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 estas etapas:

Verifique se os volumes e os pods estão no mesmo nó.
Encontre o nó em que os pods estão e verifique a integridade dele.
Verifique a conectividade do nó.
Verifique o IPSEC.
Verifique o multipath para ver se há um zumbi.

Verifique os registros do trident para descobrir qual etapa no fluxo do CSI pode ter introduzido esse zumbi:

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

Solução alternativa: para contornar esse problema, siga as etapas nos seguintes playbooks:

Para problemas relacionados a nós, consulte o runbook FILE-R0010.
Para problemas com IPSEC, consulte o runbook FILE-R0007.
Para problemas com LUNs zumbis, consulte o runbook FILE-R0020.
Para problemas com LUNs superzumbi, consulte o runbook FILE-R0021.

Falhas relacionadas ao armazenamento

Versões: 1.13.1

Sintomas: falhas relacionadas ao armazenamento podem ser identificadas pelo disparo do alerta file_block_zombie_luns_present ou pela falha ao iniciar o pod devido a um problema na chamada MountVolume que persiste por mais de um loop de reconciliação. O tempo limite pode ser de cerca de dois minutos. Uma repetição da mesma falha indica que algo deu errado no caminho NodeStage ou NodePublish do CSI e requer uma solução alternativa. A única exceção é a indicação de uma falha de tempo limite. Você pode encontrar 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

Alternativa:

Para ver se o Node que tem o Pod pode ser corrigido para o PVC com falha, isole o nó atual em que o pod está programado e exclua o Pod:
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE
```
O Pod precisa ser programado para um Node completamente diferente, o que força o Trident a executar completamente NodeStage, NodePublish, NodeUnpublish e NodeUnstage. Isso pode não corrigir o volume imediatamente porque ainda pode haver sessões abertas para esse volume no Node original.
Depois que a etapa anterior for concluída, remova o isolamento do nó em questão:
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE
```
Se ainda houver falhas, isole todos os outros Nodes, exceto aquele em que o Pod foi programado originalmente, e exclua o Pod. Isso vai fazer com que o Pod comece no Node original, onde os dispositivos atuais ainda podem permanecer.
Depois que a etapa anterior for concluída, remova o isolamento dos nós em questão.
Como último recurso para salvar o PV e os dados dele, o Node pode ser reinicializado para limpar falhas de multipath, udev e devmapper no Node. Embora essa etapa seja bastante árdua, é a mais provável de dar certo.
Se as mitigações anteriores não resolverem o problema com o volume, isso indica que os dados foram corrompidos e estão inutilizáveis. A única opção restante para continuar com o comportamento pretendido do contêiner é excluir os PV, PVC e Pod com falha, seguido por uma reinicialização do nó em que o PV estava hospedado. Essa ação resulta na perda completa de dados de tudo o que já foi gravado no volume.

Volumes permanentes criados com tamanho incorreto

Versões: 1.13.1

Sintomas: as cargas de trabalho com um volume permanente são criadas com cerca de 16 MiB a menos. Se as cargas de trabalho dependerem exatamente do tamanho anunciado por um volume permanente, a pequena discrepância fará com que a carga de trabalho falhe ao ser expandida ou provisionada. Esse problema é mais provável para volumes permanentes provisionados com uma classe de armazenamento standard-block do que com uma classe de armazenamento standard-rwo. Esse problema pode ocorrer em volumes permanentes com uma classe de armazenamento standard-rwo que usa o modo volumemode:block.

Solução alternativa: aloque um volume permanente que seja pelo menos 16 MiB maior do que o realmente necessário.

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

Versões: 1.13.1

Sintomas: o StorageVirtualMachine pode mostrar 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: exclua o finalizador de StorageVirtualMachines no namespace da organização.

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

Versões: 1.13.1

Sintomas: ao desativar uma organização, alguns recursos do StorageVirtualMachines são deixados para trás, 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: exclua esses recursos.

Falha na reconciliação da exclusão

Versões: 1.13.1

Sintomas: quando um StorageVirtualMachine é excluído antes da limpeza de clusters que dependem desse StorageVirtualMachine, há potencial para um problema na limpeza de alguns volumes persistentes (PVs) dos clusters. Especificamente, quando os PVs criptografados com LUKS não são limpos, o segredo deles impede a exclusão do namespace em que estão. Talvez você veja um aviso nos registros como este:

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:exclua o finalizador dos secrets g-luks-gdc-vm-disk-* no namespace do cluster de serviço.

Upgrade bare metal travado

Versões: 1.13.1, 1.13.5, 1.13.6

Sintomas:os jobs do Ansible ficam presos na coleta de fatos quando há LUNs zumbis. A execução do comando multipath -ll pode mostrar 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

Você 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 conectividade SSH com o nó de destino e use o seguinte playbook: FILE-R0020.

Erro de várias anexações do Trident

Versões: 1.13.3

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

Alternativa:

Verifique o PVC para um deletionTimestamp:

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

Se não houver deletionTimestamp (migração de pod):
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 esse valor.
3. Exclua o pod com falha. Essa ação migra o POD de volta para o nó original.
Observação: essa ação não vai criar um zumbi porque o valor hexadecimal serial que o Trident usa para a entrada de vários caminhos vem do recurso LUN real no ONTAP. Se o dispositivo já estiver presente, ele vai recuperar o valor original. Se o dispositivo não estiver presente, o valor será criado corretamente.
Se houver uma deletionTimestamp (exclusão de volume):
1. Verifique o VolumeAttachment do PVC para identificar onde o volume está anexado.
2. No nó, gere o conteúdo do arquivo de rastreamento, /var/lib/trident/tracking/PVC_NAME.json.
3. Valide se o dispositivo LUKS encontrado no campo devicePath da saída do arquivo de rastreamento está realmente fechado. Este caminho não pode existir neste ponto: stat DEVICE_PATH. Se o caminho ainda existir, o problema é outro.
4. Valide se o número de série está mapeado para algum dispositivo multipath.
5. Copie o valor no campo iscsiLunSerial do arquivo de rastreamento.
6. Converta este valor no valor hexadecimal esperado: echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
7. Com esse novo valor, verifique se a entrada de vários caminhos ainda existe: multipath -ll | grep SERIAL_HEX.
8. Se ele não existir, exclua o arquivo de rastreamento.
9. Se ele existir, você vai encontrar um valor hexadecimal serial um pouco mais longo do que o que você pesquisou. Registre esse valor como MULTIPATH_SERIAL. Execute multipath -ll MULTIPATH_SERIAL e você vai ver 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 comandos a seguir:
  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 maneira exclusiva para cada dispositivo de transferência por blocos.

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é-compartilhada (PSK) inválida que contém 0X, interpretada como uma string hexadecimal.

Talvez você veja 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: ""

Alternativa:

Receba as conexões de criptografia de armazenamento:

kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

Procure a entrada com Ready=False e anote o nome do PRESHAREKEY. A saída pode ser semelhante a este exemplo:

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

Esta máquina está executando uma organização de GPU. Portanto, exclua secrets gpc-system/vm-5a77b2a2-pre-shared-key em gpu-org-admin.
Aguarde o sistema recriar secret/vm-5a77b2a2-pre-shared-key.
Procure um job com um padrão como gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Os últimos oito caracteres são gerados aleatoriamente. Quando a chave estiver disponível novamente, exclua o job, como jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl em gpu-org-admin.

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

Versões: 1.13.5

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

Você pode ver um erro do controlador de armazenamento como este, indicando 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"}

Alternativa:

Exclua o pod file-storage-backend-controller.
Deixe o controlador de armazenamento buscar novamente as máquinas de inventário presentes.

Falha na reconciliação das redes intercluster de armazenamento

Versões: 1.13.5, 1.13.6

Sintomas: após um upgrade, 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 informa 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 esse erro ocorrer, a reivindicação de sub-rede entre clusters usada pelo cluster de armazenamento não incluirá o campo kind na referência. Ao inspecionar o recurso personalizado StorageCluster, você vai encontrar uma referência de solicitação de sub-rede entre clusters com apenas um nome e um namespace, assim:

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 implantação file-storage-backend-controller e verifique se o cluster de armazenamento está pronto.

Gerenciamento de clusters

O job `machine-init` falha durante o provisionamento do cluster

Versões: 1.13.1

Sintomas:

Durante o provisionamento do cluster, o job machine-init do segundo nó do plano de controle falha com a seguinte mensagem:

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

Veja os registros:

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

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

Alternativa:

Alterne a permissão de /etc/kubernetes/pki/etcd/ca.crt. Essa é uma operação muito sensível ao tempo. A troca de permissão precisa acontecer depois da execução anterior do job machine-init, mas antes da próxima execução do job machine-init, já que machine-init substitui a permissão de volta para a raiz.
Reinicie o etcd no segundo nó para recuperar o etcd no primeiro nó de um loop de falhas.

Depois de concluir essas duas etapas, o kube-apiserver no primeiro nó começa a ser executado, e o próximo job machine-init é concluído.

Sem conectividade do cluster de serviço ao bucket de armazenamento de objetos

Versões: 1.13.1

Sintomas:a conexão de um pod de banco de dados em execução no cluster de serviço com um bucket de armazenamento de objetos no cluster de administrador da organização falha.

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

Falhas na verificação de simulação

Versões: 1.13.1

Sintomas: você pode ver a seguinte mensagem no status do objeto do cluster:

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

Você também vai encontrar um objeto PreflightCheck correspondente com o mesmo nome e namespace do objeto de cluster que está lá há várias horas, mesmo que o erro ou falha indicado no objeto PreflightCheck não seja mais um problema.

Solução alternativa: exclua o objeto PreflightCheck.

Falha na criação do pool de nós de trabalho do cluster de usuário

Versões: 1.13.5

Sintomas: a criação do pool de nós de trabalho do cluster de usuário pode parar de responder para um destes tipos de máquina:

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

Solução alternativa: exclua o pool de nós e recrie-o selecionando outros tipos de máquina disponíveis no menu suspenso da UI de criação de cluster de usuário.

Os clusters de usuários recriados podem ficar presos na reconciliação devido a uma limpeza inadequada.

Versões: 1.13.x

Sintomas: quando clusters de usuário são criados com o mesmo nome de um cluster excluído anteriormente, eles podem ficar presos em Reconciling indefinidamente com status mencionando o estágio de instalação do complemento ONE.

Solução alternativa: desinstale o complemento do Helm CLUSTER_NAME-abm-overrides e reinicie a implantação do managed-adm-controller. Siga MKS-R0004 para conferir as etapas detalhadas.

Serviço de banco de dados

Esta seção contém problemas conhecidos do serviço de banco de dados.

Clonagem do banco de dados do AlloyDB Omni travada

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

Sintomas: quando um usuário clona um cluster do AlloyDB Omni de um determinado ponto no tempo, o cluster de banco de dados clonado fica preso com o erro DBSE0005 e não pode ficar pronto. O recurso restore.alloydb correspondente está preso na fase "ProvisionInProgress".

Solução alternativa: para contornar esse problema, escolha cuidadosamente o ponto no tempo do COMPLETETIME dos backups concluídos.

Lista os backups disponíveis do AlloyDB Omni para clonar no servidor da API de gerenciamento.

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

Exemplos de saída:

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 de COMPLETETIME como o ponto no tempo para o clone. O horário está em UTC.

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

Versões: 1.13.1

Solução alternativa: para resolver esse problema, siga uma destas opções:

Aumente o tamanho do armazenamento.
Substitua a cota de IOPS.

Erro de reconciliação ao fazer upgrade do subcomponente `dbs-fleet`

Versões: 1.13.3

Sintomas: ao fazer upgrade da organização raiz da versão 1.13.1 para a 1.13.3, talvez você veja um erro de reconciliação. Verifique se há erros de reconciliaçã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 esta aparência:

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

Solução alternativa: siga as etapas no runbook OCLCM-R0122.

Falha na criação do DBCluster

Versões: 1.13.3

Sintomas: depois de fazer upgrade para o 1.13.3, os novos DBclusters não são reconciliados, com o seguinte erro no status:

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

Alternativa

Verifique se há localrollout CRs terminadas em cpa-v0.12.46 e cpa-v0.12.51 no cluster de administrador da organização. 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 exclua CRs localrollout que terminam em cpa-v0.12.46, garantindo que outras CRs localrollout não sejam afetadas.

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

Isso vai retornar uma lista como esta:

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

Exclua cada uma delas:

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

Verifique se os CRs localrollout 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 precisam ser desativadas explicitamente em resolved.conf

Versões: 1.13.1, 1.13.3, 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á falhando, estabeleça uma conexão SSH com o nó afetado e execute systemctl status systemd-resolved. A saída contém linhas como DNSSEC validation failed for question . IN SOA: no-signature.

Alternativa:

Adicione a seguinte linha a /etc/systemd/resolved.conf no nó afetado.
```
DNSSEC=false
```

Reinicie o serviço systemd-resolved:

systemctl restart systemd-resolved.service

Serviço do Harbor

Falha na criação do serviço do Harbor

Versões: 1.13.6

Sintomas: a criação de uma instância do Harbor falha devido a uma incompatibilidade de namespace causada por uma limitação de comprimento no nome ServiceIsolationEnvironment. Você pode receber 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. Verifique se o comprimento combinado do PROJECT_NAME e do HARBOR_INSTANCE_NAME é inferior a 27 caracteres.

Excluir instâncias do Harbor não exclui os espelhos de registro 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 exclusão de instâncias do Harbor não exclui os espelhos de registro associados. O pool de nós pode estar preso em um estado de Provisioning. Isso acontece porque os espelhos de registro criados pelo controlador do MHS não são excluídos quando as instâncias do Harbor são excluídas.

Solução alternativa: remova os espelhos de registro manualmente. Para minimizar esse problema, siga estas etapas:

Conecte-se ao cluster de administrador da organização. Para mais informações, consulte Arquitetura de cluster do GDC.

Execute este script para remover todos os espelhos de registro que correspondem ao valor da variável de ambiente HARBOR_INSTANCE_URL de todos os clusters do Kubernetes que têm o rótulo 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 teste desativadas do HSM ainda são detectáveis

Versões:1.13.1, 1.13.3 a 1.13.11

Sintomas:devido a um problema conhecido no CipherTrust Manager, as licenças de teste desativadas ainda são detectáveis e podem acionar avisos de expiração falsos.

Solução alternativa:consulte HSM-R0003 para verificar as licenças normais ativas e excluir as licenças de teste desativadas.

Vazamento de descritor de arquivo do daemon do host do HSM

Versões:1.13.x

Sintomas:se os HSMs forem executados por mais de 30 dias, um vazamento de descritor de arquivo poderá fazer com que o serviço host-daemon pare de responder, resultando em um erro ServicesNotStarted.

Solução alternativa: reinicie o serviço host-daemon. Para fazer isso, peça ao operador de infraestrutura (IO) para se conectar ao HSM por SSH como o usuário ksadmin e execute o seguinte comando:

sudo systemctl restart host-daemon

Se isso não funcionar, o IO poderá reiniciar o HSM não íntegro.

Certificados de HSM expirados

Versões: 1.13.11

Sintomas: ao fazer upgrade de uma organização, talvez você veja 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á preso em um upgrade de versão do ABM devido a certificados HSM (módulo de segurança de hardware) expirados.

Você também pode ver um erro como este exemplo no HPE server iLO, StorageGRID ou ONTAP:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Alternativa:

Faça a rotação manual da CA raiz e do certificado da interface da Web com ksctl:

Pausar todas as respostas automáticas de HSM, HSMCluster e HSMTenant.

Crie uma nova CA raiz com atributos copiados da antiga. Encontre o ID da CA antiga com ksctl ca locals list. Um exemplo seria assim:

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

Autoassine a nova CA com duração de um ano. Um exemplo seria assim:

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

Atualize a interface da Web para usar essa nova CA na geração automática de certificados. Um exemplo seria assim:

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

Gere um novo certificado de interface da Web, assinado pela nova CA. A flag --url é o IP de gerenciamento do HSM (de kubectl get hsm -n gpc-system). Um exemplo seria assim:

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

Neste ponto, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text ainda mostra o certificado antigo. É necessário reiniciar o HSM para usar 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.

Exclua a CA antiga do CR do HSM:

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

Retome o HSM:

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

Verifique se o HSM está íntegro.

Repita essas etapas para os outros dois HSMs. Eles já têm a nova CA raiz autassinada porque ela é compartilhada entre HSMs em um cluster. Pule as etapas 2 e 3, mas repita as etapas de 4 a 8.
Siga a tarefa HSM T0008 de rotação de CA para automatizar a rotação de todos os certificados, mas pule a etapa Finalize the rotation by adding a new rotation annotation to hsmcluster where the ca-rotation-finalizing annotation is added.

Faça upload do novo nome da CA para o iLO:

Na interface do iLO, abra a página "Administração - Gerenciador de chaves" e clique na guia Gerenciador de chaves.
Gire o nome do certificado.
Faça uma reinicialização a frio.
Verifique se o handshake SSL voltou a funcionar.

Gerenciamento de identidade e acesso

Os pods `gatekeeper-audit` no namespace `opa-system` são reiniciados com frequência.

Versões: 1.13.3

Sintomas:verifique o status dos pods gatekeeper-audit-*** no namespace opa-system:

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

A saída pode ser semelhante a este exemplo:

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

Esse problema é causado por limites de recursos baixos.

Infraestrutura como código (IAC)

A criação excessiva de tokens do GitLab pode preencher os bancos de dados do GitLab.

Versões:1.13.1

Sintomas:o subcomponente iac-manager cria um novo token para o usuário configsync-ro repetidamente, mesmo quando não é necessário. Isso pode fazer com que o banco de dados do GitLab seja preenchido e torne o IAC inacessível. O pod pg-gitlab-database-0 no namespace gitlab-system pode não conseguir iniciar e mostrar 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

Alternativa:

Trabalhe com seu contato do Google para receber hotfix_3 para a versão 1.13.1 e faça a inscrição.

Key Management System (KMS)

Mudar o tipo de chave raiz invalida todas as chaves atuais.

Versões: 1.13.x

Sintomas:depois que uma organização é criada, o KMS é provisionado automaticamente com uma chave raiz de software. Para migrar de uma chave raiz de software para uma chave CTM, os usuários substituem um subcomponente. Isso muda o tipo de chave raiz, o que invalida todas as chaves de software atuais no KMS.

Solução alternativa:evite atualizar o tipo de chave raiz, se possível. Se você atualizar o tipo de chave raiz, todas as chaves atuais serão invalidadas.

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

Versões: 1.13.1

Sintomas:quando o uso de memória kms-rootkey-controller excede o limite 600Mi, o controlador entra em um CrashLoopBackOff devido a um status OOMKilled.

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

Crie um recurso personalizado SubcomponentOverride:

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

No exemplo a seguir, você vê um recurso personalizado SubcomponentOverride completo:

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

Aplique o recurso SubcomponentOverride:

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

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

Logging

O gravador de registros de auditoria do armazenamento de objetos não consegue resolver o host DNS

Versões: 1.13.x

Sintomas:

No cluster de administrador raiz, a implantação do 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: adicione um patch à implantaçã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 implantação do 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: faça upgrade para a versão 1.13.8 para corrigir o erro. Como alternativa, modifique a implantação obs-system/log-remote-logger da seguinte maneira:

Nos argumentos do contêiner remote-logger, atualize a flag --disabled-loggers para incluir sanidade e HaaS:

YAML

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

Falha no registrador de Santricity

Versões: 1.13.x

Sintomas:

No cluster de administrador raiz, a implantação do 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: faça upgrade para a versão 1.13.8 para corrigir o erro.

Os registros do destino do Logging são enviados para o projeto errado

Versões: 1.13.x

Sintomas: os registros do DaemonSet obs-system/oplogs-forwarder mostram avisos semelhantes a este:

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

Esses alertas fazem com que os registros sejam encaminhados para o projeto errado (ID do locatário). Esse problema decorre de um bug conhecido no Fluent Bit. Para mais informações, consulte o problema do Fluent Bit no GitHub (em inglês).

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

Os registros de auditoria do namespace da plataforma não ficam visíveis para o PA.

Versões: 1.13.x

Sintomas: os registros de auditoria do namespace da plataforma ficam visíveis para o operador de infraestrutura (IO) em vez do administrador da plataforma (PA).

Solução alternativa: adicione manualmente o rótulo observability.gdc.goog/auditlog-destination=pa ao namespace platform em todos os clusters da organização. Siga estas etapas para implementar essa solução alternativa manual:

Defina KUBECONFIG como o cluster de destino.

Adicione o rótulo necessário ao namespace:

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

Confirme se o rótulo foi adicionado:

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

Falha ao inicializar contêineres

Versões: 1.13.x

Sintomas: os pods não estão sendo criados com um erro semelhante a este:

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 │

Esses erros impedem que os pods sejam iniciados em um nó específico. O comportamento observado surge de um caso extremo conhecido em que o arquivo de status logrotate-daemon fica bloqueado, impedindo que o daemon execute a rotação de arquivos esperada. Para confirmar esse erro, siga estas etapas:

Defina KUBECONFIG como o cluster de destino.

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

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

Extraia os registros da instância anthos-audit-logs-forwarder-xxxx programada no nó para verificar.

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

Alternativa:

Siga estas etapas para resolver o problema:

Faça a recuperação manual de espaço em disco no diretório /var/log do nó.
Defina KUBECONFIG como o cluster de destino.

Identifique o nó de destino no cluster.

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

Conecte-se ao nó usando SSH e libere espaço manualmente no diretório /var/log no nó. O logrotate gerencia arquivos nesses 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

Verifique se há arquivos de registro muito grandes (mais de 100 MB) ou com mais de alguns dias. Quando você tiver o arquivo de destino, poderá truncar os registros da seguinte maneira:
```
truncate -s 1G <target_file>
```

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

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

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

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

Marketplace

A extração de imagens da Prisma Cloud falha

Versões: 1.13.7

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

Alternativa:

Edite a implantação twistlock-console para modificar a tag da imagem:

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

Encontre a seguinte linha:

image: HARBOR_IP/library/twistlock/console:console_33_01_137

Substitua console_33_01_137 por console_33.01.137:

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

Verifique se o pod está sendo executado corretamente:

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

A saída pode ser semelhante a este exemplo:

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

Monitoramento

Grande número de alertas criados no ServiceNow

Versões: 1.13.x

Sintomas:

Depois de configurar o Monitoring para enviar alertas ao ServiceNow usando as tarefas de esforço MON-T0016 e MON-T1016, um grande número de incidentes é criado automaticamente no ServiceNow.

O problema tem as seguintes características:

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

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

Vários alertas duplicados criados no ServiceNow

Versões: 1.13.x

Sintomas:

Depois de configurar o Monitoring para enviar alertas ao ServiceNow usando as tarefas de esforço MON-T0016, MON-T1016 e MON-T0018, vários alertas duplicados são criados no ServiceNow.

O problema tem as seguintes características:

Vários incidentes duplicados estão sendo criados para alguns alertas, mesmo depois de aplicar a tarefa de esforço MON-T0018.

Solução alternativa: siga a tarefa repetitiva MON-T0019 imediatamente após executar as tarefas repetitivas 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 oferece suporte a métricas criptografadas para serviços da Vertex AI. Se o serviço da Vertex AI não for ativado em mais de uma hora, reinicie o pod do controlador mon-admin.

Erro de reconciliação em `mon-cortex`

Versões: 1.13.1, 1.13.9

Sintomas: o pod mon-cortex tem um erro de reconciliação. Confira o status do pod mon-cortex:

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

A saída pode ser semelhante a esta:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Uma mensagem como esta pode ser registrada:

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

Alternativa:

Verifique qual pod do Cortex está mostrando 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

Exclua o PVC associado a esse pod e reinicie-o.

O pod `metrics-server-exporter` no cluster do sistema está em loop de falha

Versões: 1.13.1

Sintomas:o pod metrics-server-exporter no cluster do sistema está em loop de falha com OOMKilled, mas não parece estar atingindo o limite. Diagnostique o erro:

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

A saída pode ser semelhante a esta:

[...]
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 veiculados no endpoint de métricas excluindo o pod e permitindo que ele seja reiniciado. O time-series antigo mantido na memória é limpo ao fazer isso, reduzindo a memória necessária.

Ignorar mensagens de erro de reconciliação do `ObservabilityPipeline`

Versões: 1.13

Sintomas:

O objeto ObservabilityPipeline mostra registros Reconciler error como os 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"}

Alternativa:

Ignore os registros que atendam a todas as condições a seguir:

"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 você estiver depurando um alerta devido a erros de reconciliação altos, ignore esses registros, porque eles são falsos negativos.

O ConfigMap `mon-prober-backend-prometheus-config` é redefinido

Versões: 1.13.0 e 1.13.1

Sintomas:

O alerta MON-A0001 é acionado.

O ConfigMap mon-prober-backend-prometheus-config é redefinido para não incluir jobs 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

Alternativa:

Siga estas etapas para resolver o problema:

Configure as variáveis de ambiente a seguir:
- KUBECONFIG: o caminho para o arquivo kubeconfig no cluster.
- TARGET_CLUSTER: o nome do cluster em que você está resolvendo o problema.

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

Exemplo:

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

Reinicie o controlador de administrador do MON em cada cluster de administrador:
```
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller
```
O ConfigMap do Prober é preenchido à medida que cada sondagem é registrada.
Siga o runbook MON-R2009 para silenciar o alerta MON-A0001, Blackbox monitoring metrics pipeline down, porque ele vai continuar sendo acionado.

Crashloop OOMKilled do componente de gateway da loja do Cortex

Versões: 1.13.3

Sintomas: se você encontrar erros no Grafana ao carregar métricas ou se elas não carregarem, o pod cortex-store-gateway pode estar em loop de falha.

Para diagnosticar o pod cortex-store-gateway e verificar se ele está em loop de falha, analise o status dele:

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

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

Se o pod estiver em loop de falha, a saída será semelhante ao exemplo a seguir:

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

Solução alternativa: aumente temporariamente o limite de memória cortex-store-gateway usando um SubcomponentOverride. Para detalhes sobre como implementar um SubComponentOverride, consulte o runbook MON-R2008.

Confira a seguir um exemplo de 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 em vigor até que todos os pods cortex-store-gateway tenham um status Ready e verifique se o subcomponente mon-cortex não está pausado:

Verifique se os pods cortex-store-gateway têm o status Ready:
```
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway
```
A saída será parecida com o exemplo a seguir se todos os pods tiverem o status Ready:
```
NAME                   READY   AGE
cortex-store-gateway   3/3     70d
```
A coluna READY precisa mostrar um valor N/N para que todos os pods estejam prontos. Caso contrário, ele vai mostrar valores como 1/3 ou 2/3.
Verifique se o subcomponente mon-cortex não está pausado em uma determinada organização:
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused
```
Substitua:
- ORG_ADMIN_KUBECONFIG: o caminho para o arquivo kubeconfig do cluster de administrador da organização.
- SYSTEM_CLUSTER: o nome do cluster do sistema.
Se o subcomponente estiver pausado, a saída vai mostrar a seguinte linha:
```
lcm.private.gdc.goog/paused: true
```
Caso contrário, a saída fica vazia.

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

Versões: 1.13.3

Sintomas: quando as métricas relacionadas a kube-scheduler ou 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 espera exponencial de extração de imagem com o pod kube-control-plane-metrics-proxy.

Para diagnosticar o pod kube-control-plane-metrics-proxy e verificar se ele tem um problema de espera exponencial de extração de imagem, analise o status dele:

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 arquivo kubeconfig do cluster de usuário.

Se o pod tiver um problema de espera exponencial de extração de imagem, a saída será semelhante ao exemplo a seguir:

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

Solução alternativa: siga estas etapas para resolver o problema:

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

O projeto library é usado para artefatos a serem implantados no cluster de usuário.

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 controle do sistema informa eventos NodeHasInsufficientMemory e EvictionThresholdMet:

kubectl describe node NODE_NAME | grep Events -A100

A saída pode ser semelhante ao exemplo a seguir:

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 (registro de gravação antecipada), o que afeta a memória do nó. O crescimento do WAL pode ocorrer porque o Cortex não foi implantado. Portanto, esse problema pode ser uma consequência da inatividade do Cortex. A instância do Prometheus perde a conectividade com o Cortex por um longo período, durante o qual ela armazena dados em buffer na memória e no volume permanente (PV). Quando o Prometheus é encerrado, ele carrega todos os dados no WAL para a memória na inicialização.

Outra causa raiz pode ser problemas de conectividade de rede (redes de serviços, físicas e superiores).

Solução alternativa: para se recuperar desse estado, a ação recomendada é resolver a causa raiz e deixar o Cortex íntegro ou resolver problemas de conectividade de rede. Aguarde o WAL do Prometheus ser esgotado. Você não perde dados, mas, se o Cortex estiver inativo, o nó não estará disponível durante o período necessário para a recuperação do Cortex.

Se preferir, reduza a escala do Prometheus STS para zero e exclua o PV. Essa ação reduz o tempo total em que o nó fica indisponível, mas resulta em perda de dados. Além disso, enquanto o Cortex estiver inativo ou você tiver problemas de conectividade de rede, repita essa ação periodicamente. Enquanto houver um problema de conexão entre o Prometheus e o Cortex, o PV vai se encher novamente.

Siga estas etapas para reduzir escala vertical o Prometheus STS a zero e excluir o PV:

Reduza o 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 arquivo kubeconfig no cluster do sistema da organização.

Reduza a escala vertical do componente anthos-prometheus-k8s:

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

Exclua a declaração de volume permanente:

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

Aumente a escala vertical do logmon-operator novamente:

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

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

Bootstrap multizona

Funções de cluster ausentes

Versões: 1.13.1

Sintomas:não há papéis específicos para inicializar várias zonas a serem usadas em Adicionar papéis obrigatórios.

Solução alternativa:use a função de cluster cluster-admin, conforme especificado nas instruções vinculadas. Isso dá ao usuário 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 na etapa 3 de Criar o arquivo de bootstrap é incompatível com a lógica que o processa.

Solução alternativa:edite o arquivo YAML gerado conforme especificado na etapa 4.

O recurso `GlobalAPIZone` não é criado na API global.

Versões: 1.13.1

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

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

Rede

Rede de grade de nós de armazenamento de objetos inativa

Versões: 1.13.1, 1.13.3, 1.13.4

Sintomas:

Durante a fase de inicialização do armazenamento de objetos, a rede de grade aparece como inativa na UI do instalador do nó de administrador do OBJ.
cables.csv e Cell CR mostram que o valor do MPN em cables.csv é QSFP-100G-CU2.5M para conexões entre nós objsadmin de armazenamento de objetos e o switch TOR.

Explicação Na versão 1.13, o campo MPN em cables.csv é usado para determinar qual velocidade é definida no switch Tor. Se a velocidade não estiver definida nessas portas, a troca do tor para a conectividade do nó objsadmin vai falhar. A lista usada para mapear MPN para velocidade não considerou um valor fornecido pelo integrador de sistemas, fazendo com que a inicialização do armazenamento de objetos falhasse. Na maioria das configurações 1.13, o fornecedor usado foi: QSFP-100G-CU2.5M.

Alternativa:

Use kubectl get -A cell -oyaml no cluster root-admin para encontrar a conexão relacionada ao dispositivo de armazenamento de objetos e ao switch TOR.
Mude todas as ocorrências de mpn para "QSFP-100G-CU3M" em objsadm -> torsw connect.

Exemplo:

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

O nó não está disponível

Versões: 1.13.1, 1.13.3, 1.13.4

Sintomas:

Durante a fase de inicialização da rede, alguns switches não podem ser acessados.
Durante a fase de instalação do DHCP, alguns servidores não podem ser acessados pelo endereço IP do iLO.

Alternativa:

Recarregue os switches de gerenciamento afetados. Consulte o runbook PNET-R0018 para mais detalhes.

`PodCIDR` não atribuído a nós, mesmo que `ClusterCIDRConfig` seja 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. Esse problema ocorre se um ClusterCIDRConfig for criado ao mesmo tempo em que os pods ipam-controller estão fazendo bootstrap. A criação do cluster está travada no estado de reconciliação.

Verifique se o objeto ClusterCIDRConfig foi criado no cluster:

kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

A saída pode ser semelhante a esta:

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

Execute "describe" para um dos objetos de nó do cluster que está preso na reconciliação e verifique se um evento CIDRNotAvailable está presente no objeto de nó:

kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

Os eventos de saída podem ser assim:

  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

Alternativa:

Reinicie os pods ipam-controller-manager:

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

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

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

A saída pode ser semelhante a esta:

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

Desvio de NTP

Versões: 1.13.1

Sintomas: um nó de VM ficou com horário impreciso ou defasado após ficar inativo ou em execução por um tempo.

Alternativa:

Estabeleça uma conexão SSH com o nó da VM e edite o arquivo /etc/chrony.conf.
Substitua a linha makestep 1.0 3 por makestep 1.0 -1.
Reinicie o serviço chronyd:
```
systemctl restart chronyd
```

Você só precisa fazer essa mudança uma vez em cada VM. A mudança não será substituída.

Para uma correção rápida e imediata que acelere o processo, estabeleça uma conexão SSH com o nó da VM e execute chronyc -a makestep.

Registros de auditoria do SyncServer não analisados

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

Sintomas: os registros de auditoria do SyncServer não são analisados corretamente pelo log-remote-logger. Alguns registros de auditoria não estarão disponíveis no Grafana, e você poderá receber mensagens de erro no pod log-remote-logger do administrador raiz, como:

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

Solução alternativa: os registros de auditoria ainda estão disponíveis no SyncServer. Siga NTP-P0002 para acessar a interface do SyncServer e ver os registros em Logs > Events.

Falha ao extrair a imagem do switch

Versões: 1.13.3

Sintomas: talvez você veja uma mensagem como esta no objeto SwitchImageHostRequest ao realizar um RMA do Switch ou ao inicializar o cluster root-admin:

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

Se você tiver acesso ao kubectl, use-o para verificar se está enfrentando esse problema:

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

A saída pode ser semelhante ao exemplo a seguir:

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

Alternativa:

Crie manualmente um SwitchImageHostRequest com a tag de imagem correta:

Faça login no servidor de bootstrap.
Use gdcloud para identificar a versão correta da imagem de troca:
```
release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch
```
A saída pode ser semelhante ao exemplo a seguir:
```
│   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385
```
Nessa saída, a versão correta da imagem do botão é 1.13.3-gdch.5385.

Edite o objeto SwitchImageHostRequest que informa o erro:

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

Edite ou substitua os campos name, fromVersion e toVersion para corresponder à versão esperada da imagem de troca. Neste caso, é 1.13.3-gdch.5385. Confira a saída diff a seguir, que ilustra as mudanças a serem feitas no 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

Falha na comunicação do pod StatefulSet

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 ou interrupções de conectividade devido à exclusão de objetos do endpoint do Cilium (CEP) que não são processados corretamente após reinicializações do pod StatefulSet. Isso pode fazer com que a identidade do endpoint não gerenciado cause a remoção incorreta do tráfego legítimo pelas políticas de rede. É possível verificar os pods afetados conferindo a ausência do objeto CEP correspondente:

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

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

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

Problemas de conectividade com instâncias do DBS

Versões: 1.13.0, 1.13.1

Sintomas: as instâncias do Database Services (DBS) ficam inacessíveis, e os clientes de banco de dados mostram tempos limite de conexão.

Esse problema pode aparecer em outro componente do sistema que depende do DBS. Por exemplo, o faturamento pode informar mensagens de erro como estas:

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 fazer o agendamento no cluster de serviço da organização.

Configure as variáveis de ambiente a seguir:
```
export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME
```
Substitua:
- KUBECONFIG_PATH: o caminho até o arquivo kubeconfig do cluster de administrador da organização.
- ORG_NAME: o nome da organização, como org-1.

Atualize a configuração do componente de rede para permitir o agendamento:

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 conectividade de rede é restaurada após alguns minutos.

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

Versões: 1.13.5

Sintomas: uma VM não consegue se conectar a um cluster de banco de dados no mesmo projeto. A conectividade com o balanceador de carga interno é afetada. Esse problema é causado por um Clustermesh que não troca objetos de serviço entre clusters devido à falta de informações de zona na configuração do nome do cluster.

Solução alternativa: em ambientes inicializados como multizona, siga as etapas manuais de solução alternativa abaixo para que o balanceador de carga interno funcione:

No cluster de administrador da organização, encontre o nome da zona:
```
ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME
```
A saída pode ser semelhante a este exemplo:
```
zone1
```
No cluster de administrador da organização, consiga o ID do site da zona:
```
SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID
```
A saída pode ser semelhante a este exemplo:
```
1
```

Liste todos os clusters:

kubectl get clusters -A

A saída pode ser semelhante a este exemplo:

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

Para cada cluster, crie o CILIUM_CLUSTERNAME:

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

A saída pode ser semelhante a este exemplo:

org-1-system-zone1

Para cada cluster, defina os outros parâmetros da seguinte maneira. O exemplo a seguir para org-1-system:
```
CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592
```

Para cada cluster, crie um objeto AddOnConfiguration e armazene-o em um arquivo addonconfig.yaml. Crie esse arquivo para todos os clusters atuais e para os novos clusters que você criar no futuro:

Nesta página, defina as seguintes variáveis para atualizar o 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

Aplique o addonconfig.yaml no cluster de administrador da organização:
```
kubectl apply -f addonconfig.yaml
```
Nos clusters de sistema, serviço e usuário, verifique se o cluster-name foi atualizado no cilium-config do cluster. Isso pode levar algum tempo para ser atualizado, mas é necessário antes de reiniciar a implantação do clustermesh-apiserver.
```
kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo
```
Nos clusters de sistema, serviço e usuário, reinicie a implantação do clustermesh-apiserver:
```
kubectl rollout restart deployment -n kube-system clustermesh-apiserver
```

Endereços IP EVPN incorretos são gerados

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 multizona (MZ) gerados pelo Sistema de gerenciamento de recursos de hardware (HAMS, na sigla em inglês) não terminam com .65 ou .66, o que é incorreto e impede o estabelecimento das sessões BGP EVPN MZ.

Alternativa:

Para resolver o problema manualmente, siga estas etapas:

Listar todos os recursos InterconnectSession:

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

Revise os recursos InterconnectSession multizona de 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: {}

Para cada um dos recursos InterconnectSession que correspondem a esses parâmetros, aplique a seguinte correção:
1. Verifique o nome do recurso personalizado da sessão de interconexão.
2. Se o nome terminar em um número ímpar, atualize a última parte do endereço IP do peer para 65 usando o comando na próxima etapa.
3. Se o nome terminar em um número par, atualize a última parte do endereço IP do peer para 66 usando o comando na próxima etapa.

Modifique o recurso InterconnectSession com o endereço IP incorreto do peer:

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

Aplique essa correção a todos os recursos InterconnectSession que estão causando o erro.

O painel de controle de rede superior não mostra dados

Versões: 1.13.7

Sintomas: as consultas do Prometheus em TestUpperNetworkingMetrics falham devido à falta de métricas no cluster org-1-system. Os painéis do clustermesh no painel de controle de rede superior para administradores da organização de IO não mostram dados. O problema decorre de uma incompatibilidade no rótulo source_cluster entre o Cilium e o sistema de monitoramento.

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

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

Versões: 1.13.1

Sintomas: durante a instalação da rede, algumas mensagens de aviso sobre o cabeamento são mostradas. 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)

Essas mensagens de erro podem ser ignoradas com segurança.

Criar uma PNP de saída de permissão total nega tráfego inesperado

Versões:

Todas as versões do Google Distributed Cloud (GDC) com isolamento físico podem ser afetadas.

Sintomas: a política de rede do projeto (PNP) allow-all-egress permite o tráfego para endpoints dentro do projeto e endpoints externos fora do cluster, mas não permite o tráfego para endpoints do sistema. Esse problema pode bloquear o acesso ao sistema e aos serviços próprios, como resolução de DNS e armazenamento de objetos.

O PNP allow-all-egress pode ser semelhante a este:

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: exclua o PNP allow-all-egress. Por padrão, quando a proteção contra exfiltração de dados é desativada, o tráfego é permitido para o projeto e endpoints externos fora do cluster e endpoints do sistema.

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

Armazenamento de objetos

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

Versões: 1.13.1

Sintomas: a exclusão de uma organização pode não ser concluída devido a um problema que impede a conclusão da exclusão da SVM. Talvez você veja 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 upgrade do armazenamento de objetos podem ser ignorados

Versões: 1.13.3

Sintomas: ao fazer upgrade do armazenamento de objetos, talvez apareça 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

Alternativa:

Verifique se cada nó tem as credenciais de SSH correspondentes armazenadas em um secret.

Verifique os nós de administrador:

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

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

A saída bem-sucedida é semelhante a este exemplo para 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 um secret não for encontrado, o erro vai aparecer assim:

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

Se o comando não retornar erros, ignore os erros informados pelos reconciliadores.

Relatórios do `ObjectStorageStorageNodeReconciler` `maintenance.gdu.gdu_server_locked`

Versões: 1.13.3

Sintomas: mostram os detalhes do objectstoragestoragenode:

kubectl describe objectstoragestoragenode zv-aa-objs02

A saída pode ser semelhante ao exemplo a seguir:

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: esse problema pode ser ignorado. O serviço GDU pode ser bloqueado temporariamente quando recebe muitas solicitações, mas ele é desbloqueado após alguns minutos.

A verificação de armazenamento de objetos pós-migração 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

Falha nos pods gpc-system/upgrade-managed-check-objectstorageupgrade com 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 raiz: o upgrade do componente operacional do Object Storage da versão 1.12.x para a 1.13.x falha se o cluster KIND de inicialização não tiver sido desativado ou excluído. Mesmo que o upgrade seja bem-sucedido, os serviços comuns de armazenamento de objetos, como a criação de novos buckets ou credenciais do S3 usando o RBAC do Kubernetes, podem falhar devido a erros de validação do certificado TLS. Isso ocorre porque um pod de armazenamento de objetos específico no cluster KIND tenta instalar continuamente o certificado do servidor TLS do endpoint de gerenciamento 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 o upgrade, o StorageGRID instala um novo certificado de servidor TLS verificável, mas o pod do cluster KIND o substitui pelo certificado antigo e inválido, causando o erro de certificado TLS.

Solução alternativa: Os seguintes requisitos precisam ser verdadeiros:

O upgrade do Object Storage da versão 1.12.x para 1.13.x
O cluster de inicialização (o cluster KIND) ainda existe.

Siga estas etapas:

Adquira um kubeconfig com permissão de visualização e modificação para o recurso ObjectStorageSite no cluster de bootstrap (o cluster KIND).

Defina um alias para kubectl que se conecta ao cluster de bootstrap (o cluster KIND):

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

Receba a instância do recurso personalizado ObjectStorageSite do cluster de bootstrap. Deve haver uma instância de recurso ObjectStorageSite:
```
SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')
```

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

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

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
```
Adquira um kubeconfig que tenha acesso de visualização e permissão de patch de status para recursos ObjectStorageCluster no cluster de administrador raiz.

Defina um alias para o kubectl que se conecta ao cluster de administrador raiz:

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

Verifique se há alguma instância de recurso ObjectStorageCluster no cluster de administrador raiz:
```
kubectlrootadmin get ObjectStorageCluster
```
Se não houver uma instância de recurso ObjectStorageCluster, a solução alternativa estará concluída. Talvez seja necessário realizar o procedimento de upgrade do Object Storage novamente.

Receba o URL do endpoint de gerenciamento do status do recurso ObjectStorageSite no cluster de inicialização:

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

Valide se a variável de ambiente $MGMT_ENDPOINT foi definida. O endpoint precisa começar com https://:
```
echo ${MGMT_ENDPOINT:?}
```
Execute as etapas restantes somente quando houver exatamente uma instância de recurso ObjectStorageCluster no cluster de administrador raiz. Caso contrário, repita o procedimento de upgrade do Object Storage:
```
kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"
```

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

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

Verifique se o endpoint de gerenciamento foi adicionado ao status do recurso ObjectStorageCluster:
```
kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq
```
Para reiniciar a verificação pós-voo, exclua o job do Kubernetes gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. O job será recriado em breve.

Não é possível acessar o nó na rede de dados

Esse é um problema raro que pode acontecer se o pod anetd ficar preso em um loop de falhas.

Um recurso do kernel essencial para a conectividade do nó pode ficar preso em um estado corrompido.

Este guia descreve os sintomas desse problema e as etapas que podem ser seguidas para resolvê-lo.

Versões:

Todas as versões do Google Distributed Cloud (GDC) com isolamento físico podem ser afetadas.

Sintomas:

Se esse problema ocorrer, você poderá notar os seguintes sintomas:

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

Alternativa:

Use as instruções a seguir para reparar cada nó com falha:

Consiga o endereço IP de gerenciamento do nó afetado:

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

Consiga acesso SSH ao nó afetado.
Conecte-se ao nó usando SSH com o endereço IP de gerenciamento dele.
No nó, execute o seguinte comando e feche a conexão SSH:
```
tc filter del dev bond0 egress
```

Reinicie o daemonset anetd para o cluster com o nó afetado:

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

Sistema operacional

Pods travados no estado `init`

Versões: 1.13.1

Sintomas: o nó informa que está pronto, mas o acesso SSH a ele é lento e e top -n 1 mostra mais de 100 processos zumbi.

Alternativa:

Siga OS-P0001 para drenar o servidor. O processo pode levar mais de 20 minutos. Se a drenagem não funcionar após uma hora, siga para a próxima etapa.
Para reiniciar o servidor, estabeleça uma conexão SSH com ele e execute o seguinte comando:
```
systemctl reboot
```
Talvez seja necessário reiniciar o servidor uma segunda vez para recuperá-lo totalmente.
Verifique se o acesso SSH não está mais lento e se o número de processos zumbi é muito menor, de preferência menos de 30.
Remova o isolamento do servidor definindo maintenance como false no servidor.

`bm-system-machine-preflight-check` Falha no job do Ansible para um nó bare metal ou de VM

Versões: 1.13.1

Sintomas:o módulo do kernel nf_tables não é carregado após a reinicialização, fazendo com que os jobs do Ansible do cluster falhem com um erro Either ip_tables or nf_tables kernel module must be loaded. Esse problema ocorre quando o nó bare-metal ou da VM é reinicializado antes de ser totalmente provisionado. O job 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.'}"}

Alternativa:

Estabeleça uma conexão SSH com o nó e execute o seguinte comando:

modprobe nf_tables

VM sem espaço livre no dispositivo

Versões: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Sintomas:quando o diretório de registros /var/log está cheio, o Node pode ficar preso no status NotReady, e os pods podem não iniciar devido ao erro no space left on device. Para verificar isso, execute o seguinte comando no nó e confira se o uso está em torno 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

Alternativa:

Faça login no nó que está com o problema e limpe os arquivos de registro antigos de /var/log/messages.
```
find /var/log -name "messages*" -mtime +4 -delete
```
Também recomendamos continuar aplicando a solução alternativa a seguir para evitar que isso aconteça. A solução alternativa é criar um AnsiblePlaybook e aplicar a mudança usando um OSPolicy CR personalizado responsável por configurar com segurança o SO de destino (máquinas BM+VM). Consulte o processo OS-P0005 para mais detalhes.

Configure as variáveis de ambiente a seguir:

export KUBECONFIG=<the path to the kubeconfig file>

Crie um playbook 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

Identifique os inventários de destino que precisam aplicar a mudança. 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.

O exemplo de OSPolicy a seguir inclui dois inventários de destino em spec.inventory. É possível 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

Validação

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

Pods travados no estado `ContainerCreating`

Versões: 1.13.3, 1.13.5, 1.13.6

Sintomas: um nó aparece como íntegro, mas tem muitos pods presos em um estado ContainerCreating, e não é possível estabelecer uma conexão SSH com o servidor.

Solução alternativa: reinicie o servidor e confirme se é possível estabelecer uma conexão SSH com o nó quando ele voltar a funcionar.

Não é possível usar o SSH no nó provisionado

Versões: 1.13.5

Sintomas: um nó é provisionado, mas o SSH atinge o tempo limite nos IPs de gerenciamento e de dados.

Solução alternativa: reinicie o nó usando o iLO. Depois que ele for inicializado, use ssh e desative clamonacc com systemctl stop clamonacc; systemctl disable clamonacc.

Infraestrutura do pacote de operações (OI)

SSA not needed for 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 autogerenciada, então não é mais necessário iniciar a administração de armazenamento inteligente (SSA, na sigla em inglês). Etapas adicionais são necessárias para determinar os identificadores de disco em cada servidor. Consulte Inicialização do servidor OI.

Segurança do perímetro

O cluster do sistema da organização travou durante a inicialização da organização

Versões: 1.13.1

Sintomas:durante a inicialização da organização, o cluster do sistema da organização pode ficar preso. Os pods edr-sidecar-injector estão no estado pendente. Ao tentar excluir esses pods, talvez você veja 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.

Alternativa:

Duplique o CR MutatingWebhookConfiguration edr-sidecar-injector-webhook-cfg no cluster do sistema.
Duplique o CR ValidatingWebhookConfiguration gatekeeper-validating-webhook-configuration no cluster do sistema.
Exclua a CR edr-sidecar-injector-webhook-cfg e a CR gatekeeper-validating-webhook-configuration do cluster do sistema.
Aguarde o retorno dos pods edr-sidecar-injector e do gatekeeper-controller-manager.
Restaure o CR do webhook com o comando kubectl apply.

Os grupos de endereços do firewall da PANW não são atualizados com as mudanças de reivindicação de CIDR

Versões: 1.13.1

Sintomas:durante o bootstrap, o OCIT cidr-claim é atualizado com o valor correto, mas o firewall AddressGroups não. Um par de AddressGroups, especificamente vsys1-root-ocit-network-cidr-group e ocvsys1-root-ocit-network-cidr-group, usa blocos de rede que não se sobrepõem ao que está em uso no OIR. O OIR não consegue resolver registros de zona do GDC, e as consultas atingem o tempo limite sem uma resposta.

Solução alternativa: depois das mudanças no cidr-claim, reinicie a implantação do fw-core-backend-controller no namespace fw-system do cluster root-admin para garantir que o AddressGroup seja atualizado com o cidr-claim mais recente.

Servidores físicos

A inicialização do servidor falha devido a problemas de POST no servidor HPE

Versões: 1.13.1

Sintomas:a inicialização do servidor falha quando um servidor não consegue passar pelo processo de inicialização POST. Ao fazer login no ILO e verificar o console do servidor, o seguinte erro é mostrado:

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.

Alternativa:

No iLO, clique no botão liga/desliga e selecione Cold Boot.

Servidores travados no estado de provisionamento

Versões: 1.13.1, 1.13.3, 1.13.5

Sintomas:os servidores ficam presos em um estado de provisionamento durante o bootstrap do servidor. Verifique o estado dos servidores:

k get servers -A | grep -v availabl

A saída pode ser semelhante a esta:

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

Alternativa:

Inicie o dhcp manualmente com uma configuração baixada do cluster KIND. Neste exemplo, /tmp/dhcp.conf é a configuração de 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 upgrade em Upgrade manual do componente File para clusters de administrador raiz e da organização, por exemplo, 1.13.1-gdch.525.
Verifique a configuração da BIOS no servidor e confira se NetworkBoot não está ativado para NICs de plano de dados (nomeadas no padrão Slot{i}Nic{i}).
Verificar a BIOS com a chamada de API:
```
curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword
```
Em que $bmcUser e $bmcPassword são as senhas dos ILOs, que podem ser encontradas no arquivo ou diretório cellcfg em um secret chamado bmc-credentials-<server-name>, por exemplo, bmc-credentials-ai-aa-bm01. Verifique se a saída desse comando mostra Slot1Nic1: Disabled.

Se algum desses Slot{i}Nic{i} tiver NetworkBoot, desative-o com a API de configurações do 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 slot que tem o problema no payload.

Reinicie o servidor.

Falha no provisionamento do servidor DL380a

Versões: 1.13.3, 1.13.4, 1.13.5

Sintomas:o provisionamento do servidor falha no job de criptografia para o modelo HPE DL380a. O estado do CR do servidor fica preso em available durante a inicialização do servidor:

# server name
export SERVER_NAME=

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

Alternativa:

Siga IAM-R0004 para gerar o KUBECONFIG para o root-admin-cluster.
Siga PLATAUTH-G0001 para gerar a chave SSH root-id_rsa para CLUSTER_NS=root.

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

Faça login no servidor usando o IP de gerenciamento:

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

Ative a criptografia 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

A saída dos comandos será semelhante a esta:

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 o último comando não for concluído ou você encontrar erros como "Invalid BIOS EKM status", reinicie o servidor e o iLO e execute esta etapa novamente.

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 foi bem-sucedido, reinicialize o servidor conforme as instruções.

Criar uma unidade lógica manualmente:

Depois que o servidor terminar de reiniciar, faça login nele novamente usando o IP de gerenciamento e liste todas as unidades disponíveis:

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

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

A saída do último comando pode ser parecida com este exemplo:

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

Salve os dois IDs EID:Slt com Size igual a 1.60 TB. Neste caso:

252:1,252:2

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

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

A saída do último comando é semelhante a este exemplo:

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

Simule o status de criptografia do disco no CR do servidor.

Edite o status do CR do servidor:

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

Adicione ou modifique o status DiskEncryptionEnabled para "true":

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

Exclua o job de criptografia do servidor, se houver:

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

Ative o servidor para que o provisionamento seja retomado:

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

A exclusão segura falha sem uma licença

Versões: 1.13.5

Sintomas: quando um servidor fica preso durante a instalação, um status como este pode aparecer no CR do servidor:

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

Segurança da plataforma

O reconciliador de subCA BYO não verifica se os certificados têm chaves públicas correspondentes.

Versões: 1.13.1

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

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

Alternativa:

Siga as instruções para fazer upload de um novo certificado BYO SubCA assinado para a nova CSR.

Um problema no gerenciador de certificados resulta na emissão sem sucesso de BYO de PKI com ACME

Versões: 1.13.1

Sintomas:a falha ocorre na primeira emissão ou renovação de certificados BYO com o Ambiente de gerenciamento de certificados automatizado (ACME). Ao executar o comando para verificar o status do certificado, você vai ver que ele está not ready:

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

A saída será assim:

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

Alternativa:

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

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

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

Gerente de recursos

O status do projeto não está disponível no console do GDC

Versões: 1.13.1 ou mais recente

Sintomas:o console do GDC não mostra o status de um projeto. Projetos que não estão no estado Ready não podem oferecer suporte a novos recursos nem processar novas modificações em recursos atuais. Como não é possível confirmar o status do projeto, não fica claro quando os recursos dele podem ser gerenciados, o que resulta em erros ao tentar novas ações.

Solução alternativa:consulte o runbook RM-R0100 para imprimir o status do projeto usando a CLI kubectl.

Fazer upgrade

`bm-system` e outros jobs presos

Versões: 1.13.1

Sintomas:o bm-system e outros jobs que executam o playbook do Ansible ficam presos em gathering facts.

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

IP de gerenciamento inacessível

Versões: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Sintomas: durante um upgrade, o IP de gerenciamento de um servidor fica inacessível, principalmente após uma troca.

Com o Rocky Linux, quando rotas estáticas são adicionadas, o IP de destino usado para alcançar as rotas estáticas precisa estar acessível antes da adição. Se o switch estiver reiniciando após um upgrade do SO, esse IP de gerenciamento poderá ficar temporariamente inacessível.

Solução alternativa: estabeleça uma conexão SSH com o servidor usando o endereço IP de dados e reinicie o serviço de rede para recriar as rotas estáticas ausentes:

systemctl restart NetworkManager.service

O número da versão de `storagecluster` não é exibido

Versões: 1.13.3

Sintomas: após um upgrade, o CR StorageCluster não mostra nenhum valor para o campo de status StorageVersion.

Verifique a versão:

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

Siga as etapas da solução alternativa se o campo "Versão" estiver vazio.

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

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

Servidor bare metal preso no estado de provisionamento

Versões: 1.13.1

Sintomas:

O servidor bare metal fica preso no estado "provisionamento" por muito tempo quando uma organização está sendo criada.

Alternativa:

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

Siga estas etapas para desativar a inicialização de rede da NIC do plano de dados.

Acesso necessário:
- Você precisa ter acesso às credenciais de administrador do BMC dos servidores que estão travados.
- Siga IAM-R0005 para receber a função hardware-admin do ClusterRole no cluster root-admin por uma hora.
- Siga IAM-R0004 para gerar o KUBECONFIG do cluster root-admin.

Defina o nome do servidor travado.
```
export SERVER_NAME=
```

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)

Identifique o slot 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 a seguir indica que a placa de rede está instalada no slot 3.

["s3p1","s3p2"]

Defina a variável PCIEslot:

export DATA_NIC_SLOT=3

Confirme se a inicialização de rede não está desativada.

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", você precisará desativá-lo explicitamente.

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

Substitua "Slot3" no comando a seguir pelo número real do slot.

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 reinicie a máquina.

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

O servidor leva de 10 a 15 minutos para voltar a funcionar e retoma automaticamente o processo de provisionamento.

O upgrade do armazenamento de objetos mostra um erro durante a verificação de simulação ou pós-simulação

Versões: 1.13.1

Sintomas:as verificações de simulação ou pós-voo falham com um erro. Verificar os registros:

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

O erro pode ter esta aparência:

 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

Alternativa:

Se o erro ocorrer durante as verificações pós-voo e todas as outras forem concluídas sem erros, pule as verificações pós-voo. Quando o upgrade for reiniciado, pule as verificações de simulação também usando 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 em org-1, o comando será assim:

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

Se o erro ocorrer durante as verificações de simulação e todas as outras forem concluídas sem erros, ignore as verificações de simulaçã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 em org-1, o comando será assim:

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

Talvez seja necessário aplicar essa solução alternativa mais de uma vez se ela não for aplicada.

Reversões de upgrade do Helm

Versões: 1.13.3

Sintomas: um problema de upgrade do Helm resulta em uma série de rollbacks, sem conseguir encontrar um Certificate e um ServiceEntry. Você pode receber 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 as etapas no runbook OCLCM-R0122.

Upgrade do nó ou ABM travado porque o pod dhcp-tftp-core-server não foi drenado

Versões: 1.13.3, 1.14.4, 1.14.5

Sintomas: o upgrade do nó pode ficar travado. No status da máquina bare metal, o pod dhcp-tftp-core-server não é esgotado. Você pode receber 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 exclusão do pod dhcp-tftp-core-server-* para continuar. O comando é assim:

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

`OrganizationUpgrade` está travado na etapa de upgrade do nó

Versões: 1.13.3

Sintomas: OrganizationUpgrade está travado na fase de upgrade do nó. Você pode receber 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

Alternativa:

Verifique os CRs upgradetaskrequest no cluster raiz ka get upgradetaskrequest -n gpc-system. Verifique se o nó ainda está no status de execução. Verifique se ele está preso na tarefa do 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

Crie manualmente nodeupgrade CRs para cada uma das reivindicações do pool de nós:

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

Crie uma CR nodeupgrade para cada solicitação de pool de nós. Os detalhes da anotação upgrade.private.gdc.goog/target-release-version precisam ser obtidos do nome do CRMD do SO do destino:

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

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

Aplique o seguinte yaml para cada 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

Depois que os upgrades de nós forem concluídos para os nós do cluster de serviço, atualize o status do CR UpgradeTaskRequest para "True", para que o upgrade da organização avance para a próxima etapa:

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

O upgrade da organização vai para a próxima etapa, e o status do serviço ou nó será 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 contêiner

Versões: 1.13.3

Sintomas: o kernel não aloca cgroups de memória, resultando em falhas na criação de novos contêineres.

Você pode receber 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á usando um número muito grande de cgroups:

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

Alternativa:

Siga uma destas opções:

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

Falha intermitente de conectividade com o VIP do cluster externo

Versões: 1.13.3

Sintomas: falhas de conexão intermitentes com o IP virtual (VIP) do cluster externo, como o VIP do plano de controle, o VIP do istio-gateway ou o VIP do Harbor, resultam em um erro dial tcp :: connect: no route to host.

Para diagnosticar esse problema, siga estas etapas:

Conecte-se ao cluster de administrador raiz. Essa solução alternativa pressupõe que você está depurando endereços IP em um cluster de administrador raiz. Se você estiver depurando problemas de conectividade com outros clusters do Kubernetes, como os clusters de administrador ou de sistema da organização, mude o valor KUBECONFIG para o caminho correto do kubeconfig do cluster.
Há duas categorias conhecidas de IPs que podem ser afetadas. Verifique se o protocolo de gateway de borda (BGP) divulga os endereços IP para os switches de topo de rack (ToR):
- Se o IP for um endereço IP do plano de controle do Kubernetes, como 192.0.2.100, use este comando para receber 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 arquivo kubeconfig no cluster de administrador raiz.
- Em algumas configurações, o recurso personalizado BGPAdvertisedRoute define quais rotas no endereço IP são anunciadas para outras redes ou sistemas usando o BGP. Se o endereço IP for divulgado pelo recurso personalizado BGPAdvertisedRoute, use este comando para receber 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á com problemas de conectividade intermitente.

Verifique o status dos recursos personalizados BGPSession. Um BGPSession representa uma sessão de peering do BGP individual estabelecida entre seu cluster do Kubernetes e um peer do BGP externo. Inspecione os registros 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 íntegro contém o seguinte snippet:

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\

Verifique a estabilidade da conexão. Crie e execute um script para verificar se a conectividade é intermitente ou instável:

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"

Execute o script:

./script.sh TARGET_IP_ADDRESS:PORT

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

Se a conexão tiver problemas, você vai ver uma saída como esta:

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`

A saída anterior confirma o problema. Verifique as rotas nos switches TOR para saber se a configuração deles é a origem do problema.

Supondo que o tráfego seja descartado para um exemplo de endereço IP de 192.0.2.201 e seja anunciado pelo recurso BGPAdvertisedRoute, examine os saltos no recurso BGPAdvertisedRoute para identificar possíveis 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

Confira os endereços IP no campo nextHops. Para cada endereço IP, encontre o nome do servidor. Exemplo:
```
- 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01
```
Essa saída mostra que os próximos saltos são para servidores nos racks aa e ab. Faça login nos switches TOR nos racks aa e ab e compare as rotas nos dois racks:
```
show ip route 192.0.2.201 vrf root-external-vrf
```

Se as rotas forem diferentes entre as chaves TOR nos dois racks, você está enfrentando o problema que a solução alternativa atenua. A saída para esse problema será semelhante a esta:

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

Nesta saída, as rotas no rack aa estão no estado esperado, mostrando três próximos saltos listados em relação ao prefixo. No entanto, no rack ab, o prefixo tem apenas dois próximos saltos. Quando o tráfego destinado ao prefixo é hashizado para o rack ab, o nó correspondente ao próximo salto ausente nunca recebe o tráfego, e a rede encontra o problema de conectividade.

Siga a solução alternativa para minimizar esse problema.

Alternativa:

Essa solução alternativa ajuda com problemas intermitentes de conectividade com determinados endereços IP em clusters do Kubernetes.

Para mitigar esse problema, aplique várias mudanças de configuração à sessão do BGP entre os switches agregados. Os switches de agregação (AGG) agregam o tráfego de vários switches TOR. Siga estas etapas para atualizar todas as configurações necessárias:

Um arquivo de configuração chamado switchstaticconfig representa as configurações estáticas em um único switch. Faça o download do arquivo switchstaticconfig para as duas chaves 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

Receba o número de sistema autônomo (ASN) do ambiente:
```
root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030
```
Essa saída mostra um valor de ASN de 65030. Você precisa usar o valor de ASN retornado aqui nas etapas a seguir.
Um endereço IP de loopback em um switch AGG funciona como um endereço estável e sempre ativo para gerenciamento, roteamento e solução de problemas, mesmo que outras conexões de rede estejam inativas. Consiga os endereços IP de loopback de cada um dos switches AGG:
```
root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'
```
A saída será assim:
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
Atualize o staticswitchconfig para a chave za-ab-aggsw01 AGG. Adicione este snippet à seçã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:
- ASN: o valor do ASN da etapa anterior. Neste exemplo, o valor é 65030.
- LOOPBACK_ADDRESS: este é o endereço IP de loopback do switch AGG za-ac-aggsw01. Neste exemplo, o valor é 192.0.2.2.
Aplique a mesma atualização ao outro switch AGG, za-ac-aggsw01. Você precisa informar o endereço de loopback correto. O endereço IP de loopback é diferente para cada switch:
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
Crie e execute o mesmo script usado para diagnosticar o problema nesta etapa para verificar se a correção foi bem-sucedida. A saída não mostra mensagens de erro.

O erro `Incorrect version of Trident` aparece durante o upgrade

Versões: 1.13.3, 1.13.4, 1.13.5

Sintomas: ao fazer upgrade de versões anteriores à 1.13.3, o ontap mostra o erro Incorrect version of Trident. Você pode receber 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:

Alternativa:

Atualize o releasemetadata da versão para a qual você está fazendo upgrade:

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

A saída pode ser semelhante a esta:

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

Escolha a versão para a qual você está fazendo upgrade, conforme mencionado no exemplo a seguir:
```
kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml
```
Atualize o tridentVersion na seção fileBlockStorage de .yaml para a versão mencionada no erro. Se a mensagem de erro for parecida com esta:
```
Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5
```
Mude 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,

Mude para o seguinte valor:

infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5.
Aplique as alterações:
```
kubectl apply -f releasemetadata.yaml
```
Aplique o upgrade de armazenamento ontap novamente.

Falha ao programar pods

Versões: 1.13.3. 1.13.4, 1.13.5

Sintomas: durante o provisionamento do cluster de usuário, alguns pods não são programados. Você pode receber 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

Alternativa:

Aumente a escala do pool de nós do plano de controle do cluster de usuário:

  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 no upgrade do subcomponente `iac-zoneselection-global`

Versões: 1.13.1

Sintomas:durante um upgrade para a versão 1.13.3, ocorre um erro no subcomponente iac-zoneselection-global. Você pode receber 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

Alternativa:

Fazer upgrade para a versão 1.13.3 corrige o erro.

O prazo dos jobs de verificação de upgrade foi excedido

Versões: 1.12.x, 1.13.x

Sintomas:durante o upgrade da organização, a verificação de upgrade mostra o status False com o motivo DeadlineExceeded. Você pode receber 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

Alternativa:

Exclua os jobs de verificação de upgrade com falha correspondentes às verificações de upgrade com falha.
Aguarde até que os jobs de verificação de upgrade sejam recriados.
Analise os registros dos jobs recriados e trie os problemas.

O complemento `meta-monitoring` falha porque o local do strongswan está em um diretório de tempo de execução diferente.

Versões: 1.12.x, 1.13.x

Sintomas:durante o upgrade para a versão 1.13.4 ou 1.13.5, o complemento 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 complemento:

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

A mensagem de condição pode ser assim:

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

Alternativa:

Verifique se as sessões do BGP no cluster do sistema da organização estão falhando. 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

Verifique se os pods ang-node estão presos em ContainerCreating, 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

O seguinte erro é exibido:

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

Faça a seguinte mudança no ang-overrides AddonConfiguration no cluster de administrador da organização:

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

Mude o seguinte:

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

para o seguinte:

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

Após cerca de um minuto, confirme se os pods ang-node estão 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

Verifique se as sessões do BGP no cluster do sistema da organização estão em execução.
O complemento meta-monitoring vai para a próxima etapa.

O upgrade da organização raiz parou devido a uma falha no job de assinatura

Versões: 1.13.3, 1.13.4

Sintomas: ao fazer upgrade da versão 1.13.3 para a 1.13.4, você 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

Alternativa:

Desative a verificação de simulação:

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

Exclua o job artifact-signature-verification-*** com falha.
Aguarde até que o upgrade da raiz seja concluído.
Opcional: ative a verificação de simulação se o ambiente for atualizado para a versão 1.13.4 ou mais recente.

Quando o controlador estiver na versão 1.13.4, os upgrades não terão esse problema.

O upgrade da organização do locatário falha na fase de verificação de simulação com `ErrImagePull`

Versões: 1.13.3

Sintomas: o upgrade da organização do locatário falha na etapa de verificação de simulação com ErrImagePull para o pod de validação de pacote. Você pode receber uma mensagem como esta:

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

Os pods mostram um erro ImagePullBackOff:

kubectl describe po -n package-validation-system POD_NAME

Um erro de extração de imagem é exibido, como no exemplo a seguir:

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"

Alternativa:

Pule as verificações de simulação:

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

Não foi possível encontrar `serviceaccount` durante o upgrade da organização raiz

Versões: 1.13.8, 1.13.9

Sintomas: durante o upgrade para a versão 1.13.8, a implantação de addon para RBACs falha se houver upgrades anteriores e complementos já existentes. Os sintomas podem estar em um dos seguintes estágios:

verificações de simulação ou pós-voo
qualquer etapa que envolva uma tarefa de upgrade e a mensagem indique que o job está em execução, mesmo que a tarefa esteja travada. A mensagem status.conditions indica que o job está sendo executado há muito tempo, o que significa que há um problema.

Para verificar se há uma falha na verificação de simulação de upgrade, confira o status do objeto OrganizationUpgrade correspondente da organização que está sendo atualizada:

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

Se o job falhar em "PreflightCheck", ele poderá mostrar uma falha como esta ou uma mensagem UpgradeCheckRBACDeploymentInProgress:

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

Se o job falhar na etapa do AnthosBareMetal (ABM) em que o job de tarefa está sendo executado, a seguinte saída será exibida:

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

Se a falha estiver nas verificações, o CR upgradecheckrequest vai falhar:

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

A saída pode ser semelhante a este exemplo:

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

Se a falha estiver nas tarefas, o CR upgradetaskrequests vai falhar:

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

A saída pode ser semelhante a este exemplo:

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

Se a falha indicar um erro de RBAC ao procurar uma conta de serviço, verifique se um complemento anterior foi implantado:

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

Alternativa:

Verifique se um complemento anterior foi implantado:

  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

Receba os complementos anteriores que existem 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

Exclua este complemento:

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

Depois de excluir o complemento, exclua também o upgradetaskrequest ou upgradecheckrequest correspondente. Ele será recriado.
```
kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc
```
Continue monitorando o upgradetaskrequest, o upgradecheckrequest ou o job correspondente recém-criado.

Falha no upgrade em `shared-service-cluster upgrade`

Versões: 1.13.3

Sintomas:o upgrade do Anthos Bare Metal fica travado com uma ou mais máquinas bare metal. Todas as outras máquinas bare metal foram atualizadas ou ainda não iniciaram a atualização. Uma máquina bare metal está no modo de manutenção, mas ainda mostra a versão anterior nos campos "ABM VERSION" e "DESIRED ABM VERSION".

Siga Anthos bare metal para conferir o status e os detalhes do cluster baremetalmachine:

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

Saída esperada:

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'

Saída esperada:

true

Alternativa:

Remova a máquina de inventário 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}}'

Aguarde a saída do modo de manutenção da máquina de inventário. Isso pode levar até 10 minutos.

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

Monitore os baremetalmachines para verificar se a máquina vê a atualização da versão do ABM selecionada.
```
kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}
```

Falha na instalação do complemento `system-dashboards`

Versões: 1.13.5

Sintomas: o upgrade da versão 1.12.4 para a 1.13.5 falha no upgrade do complemento system-dashboards:

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

Solução alternativa:siga as etapas no runbook OCLCM-R0122.

`NodeUpgradeTask` CR está preso na condição `NodeOSInPlaceUpgradePostProcessingCompleted`

Versões: 1.13.5

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

Verifique se o job os-artifact-collector correspondente foi concluído. Se o job ficar parado por muitas horas, a seguinte mensagem será exibida:

  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

Alternativa:

Exclua o job ou o pod para forçar uma nova tentativa.

A distribuição de imagens falha durante um upgrade

Versões: 1.13.5

Sintomas: a distribuição de imagens falha durante um upgrade 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 se a verificação de certificado está falhando:

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

Alternativa:

Reinicie o pod obj-proxy usando KUBECONFIG da organização em que ele está falhando:

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

Verifique os registros de obj-proxy:

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

A saída esperada é esta:

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

Verifique os registros dos pods disponíveis. Por exemplo:
```
kubectl logs obj-proxy-gdgzp -n gpc-system
```
Os jobs de distribuição de imagens serão concluídos depois que a solução alternativa for aplicada.

Falha do nó durante o upgrade do cluster de usuário

Versões: 1.13.3

Sintomas: um job em execução em um nó falha durante o upgrade do cluster de usuário e mostra 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

Faça login no nó e verifique se a partição está cheia:

df -h /

A saída pode ser semelhante a este exemplo:

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

Verifique se /etc/kubernetes/tmp está usando muito espaço: du -s /etc/kubernetes/tmp. Esse problema ocorre quando o Kubernetes faz mais backups do que o normal.

Alternativa:

Limpe todos os backups em rm -f /etc/kubernetes/tmp/*:

df -h /

A saída pode ser semelhante a este exemplo:

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

O upgrade do administrador raiz está sendo recriado e falhando nas verificações de simulação

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

Sintoma: o upgrade da organização raiz falha na verificação de simulação. 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 root-admin e o kubeapiserver para root-admin foram atualizados para a versão escolhida do abm.

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

Alternativa

Aplique a opção de ignorar a verificação de simulação para continuar o upgrade:

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 namespaces `platform-obs-obs-system` ou `platform-obs` ficam travados no estado de encerramento

Versões: 1.13.5

Sintomas: os complementos não são implantados durante o upgrade ou a inicialização e mostram uma mensagem de erro como esta:

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

Você verá a seguinte resposta:

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

Se os status DEPLOYED ou READY mostrarem false ou estiverem em branco, verifique os complementos respectivos para encontrar o erro. Por exemplo:

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

Você verá a seguinte resposta:

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

O complemento foi bloqueado porque tentou criar conteúdo nos namespaces em processo de exclusão. Esse bloqueio persiste porque a exclusão do namespace também está bloqueada.

Alternativa:

Antes de iniciar um upgrade, adicione anotações aos projetos para evitar a exclusão:

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

Você verá a seguinte resposta:

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 apresentando os sintomas descritos anteriormente, siga esta solução alternativa:

A exclusão do namespace está bloqueada devido a recursos com finalizadores. Para continuar com a exclusão, remova os finalizadores usando o 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.

Aguarde a exclusão do recurso. Depois de executar o script, exclua os recursos e os namespaces de encerramento. Talvez seja necessário executar o script novamente se o namespace ainda estiver travado no estado de encerramento. Depois de encerrado, o namespace será recriado automaticamente. Verifique se os namespaces foram recriados e estão no estado ACTIVE:

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

Você verá a seguinte resposta:

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

Com os namespaces ativos, os complementos que estavam presos serão implantados em alguns minutos. Verifique se os status DEPLOYED e READY agora são verdadeiros:

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

Você verá a seguinte resposta:

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

Loops de falha do UPORC no cluster KIND durante a inicialização

Versões:1.13.x

Sintomas:o loop de falhas da implantação uporc-root-backend-controller no namespace uporc-system no cluster KIND.

Alternativa:

Verifique se os objetos ComponentGroupReleaseMetadata e ReleaseMetadata correspondem:
```
export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata
```
Se os objetos forem iguais, não será necessário usar uma solução alternativa.
Se os objetos não corresponderem, entre em contato com a equipe da UPORC para receber ajuda, já que isso pode indicar outros problemas.

Falha no upgrade do nó

Versões: 1.13.6

Sintomas: falha no upgrade do nó em NodeOSInPlaceUpgradeCompleted.

Verifique os registros dos jobs de ospolicy os-upgrade.
Se o registro incluir um erro que sugere que o arquivo de configuração está corrompido, entre na máquina do nó e verifique o conteúdo do arquivo manualmente para saber se ele está corrompido. O erro de registro pode mencionar o código de erro configparser.DuplicateOptionError e o arquivo /etc/yum.repos.d/gdch.repo.

Solução alternativa: somente se você tiver confirmado que o arquivo está corrompido, exclua manualmente o arquivo /etc/yum.repos.d/gdch.repo corrompido no nó com falha.

O job do Ansible para o upgrade regenera o arquivo automaticamente como parte do playbook do Ansible.

### NodeUpgradeTask CR is stuck at the NodeOSInPlaceUpgradePostProcessingCompleted condition

Versões: 1.13.5

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

Verifique se o job os-artifact-collector correspondente foi concluído. Se o job ficar parado por muitas horas, a seguinte mensagem será exibida:

  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

Alternativa:

Exclua o job ou o pod para forçar uma nova tentativa.

`NodeUpgradeTask` CR está preso na condição `NodeBIOSFirmwareUpgradeCompleted`

Versões: 1.13.5

Sintomas: durante o upgrade para a versão 1.13.5, o CR NodeUpgradeTask fica preso na condição NodeBIOSFirmwareUpgradeCompleted.

Verifique se a condição NodeBIOSFirmwareUpgradeCompleted correspondente está travada com a seguinte condição exibida:

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

Alternativa:

Na resposta automática NodeUpgrade, edite manualmente "U30 v3.20 (05/29/2024)" para "U30 v3.20 (05/27/2024)".

O upgrade do cluster está bloqueado porque um nó não entrou no modo de manutenção

Versões: 1.13.5, 1.13.6, 1.13.7

Sintomas: o upgrade do cluster (administrador da organização, sistema ou cluster de usuário) é bloqueado porque um nó não entra no modo de manutenção.

O cluster mostra MaintenanceMode definido como true, mas Status fica preso em false ao executar o seguinte:

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

Você verá a seguinte resposta:

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

Alternativa:

Defina KUBECONFIG como o arquivo kubeconfig do cluster que contém o nó que não está sendo drenado. O cluster pode ser o de usuário ou um cluster de serviços compartilhados.

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

Tempo limite persistente durante a `organizationupgrade` raiz inicial

Versões: 1.13.3

Sintomas: se a anotação "ignorar janela de manutenção" estiver presente durante um upgrade da organização, o CR organizationupgrade será corrigido repetidamente, redefinindo o progresso.

Alternativa:

Pause o subcomponente rm-org e reduzir escala vertical as réplicas rm-org-backend-controller.

Se o alias não for declarado, execute:

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

Pause o subcomponente e reduzir escala vertical o escalonamento da implantaçã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

Depois que o upgrade do cluster for concluído, reduza a implantação:

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

O subcomponente `obj-syslog-server` não faz a reconciliação na organização raiz

Versões: 1.13.3, 1.13.4, 1.13.5, 1.13.6

Sintomas:durante o upgrade para a versão 1.13.x, o subcomponente obj-syslog-server está em um 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

Talvez você veja que o pod syslog-server-abcdefg-wxyz está no 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"

Alternativa:

Para trazer o subcomponente de volta a um estado íntegro, remova o volumeMounts desnecessário.

Edite a implantação atual:

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

kubectl edit deployments syslog-server -n istio-system

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

Aplique as mudanças. O subcomponente vai voltar para ReconciliationCompleted depois que as mudanças forem aplicadas.

O upgrade do ABM ou do nó parou em `maintenanceMode false`

Versões: 1.13.4

Sintomas: o nó fica preso no upgrade do cluster AnthosBaremetal e não entra no modo de manutenção.

Verifique o baremetalmachine em um nó de 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

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

Falha no upgrade do complemento atat-webhooks para a organização do locatário

Versões: 1.13.5

Sintomas: o upgrade do complemento atat-webhooks não é recuperado:

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Você pode receber 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 de atat-webhooks-parameters-*****:

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Você pode encontrar 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.

Alternativa:

Faça uma cópia da carteira atual:

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

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

Atualize portfolio-org-1 Pop End Date para uma data futura:
```
kubectl delete portfolios -n atat-system portfolio-org-1
```
Se esse comando parar de responder, exclua a condição .Metadata.Finalizers do portfólio ativo antes de excluir o portfólio. A condição pode ser assim:
```
│     portfolio.finalizers.atat.config.google.com 
```
Reaplique o arquivo YAML copiado:
```
kubectl apply -f portfolio-org-1
```
Confira as datas para garantir que os portfólios e o configmap foram atualizados.
Se o job não for recuperado, exclua o job atat-webhooks-parameters com falha. Ele será recuperado. Aguarde a conclusão:
```
kubectl delete jobs -n org-1 atat-webhooks-parameters
```

Falhas no pós-voo ou na verificação de upgrade devido a erros `DeadlineExceeded` ou `BackoffLimitExceeded`.

Versões: 1.13.8

Sintomas:

Ao fazer upgrade da versão 1.13.7 para a 1.13.8, as verificações pós-voo ainda estão pendentes 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]

Alternativa:

Identifique onde os jobs estão falhando:

Verifique se os jobs estão falhando durante as verificações de simulação ou pós-simulação:

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

Verifique se os jobs estão falhando durante o upgrade:

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

Exclua os jobs:

kubectl delete jobs -n gpc-system CHECK_NAME

As verificações de upgrade incluem resultados irrelevantes para o nível de verificação

Versões: 1.13.x

Sintomas:

As verificações de upgrade 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 do locatário, ou as verificações da organização do locatário podem exibir resultados do cluster de usuários.

Exemplo de registros de falha 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 ...

Alternativa:

Pule as verificações de simulação ou pós-voo completamente com:

Simulaçã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

Pós-veiculação:

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é-treinadas mostram um estado `Enabling` na interface do usuário

Versões: 1.13.1

Sintomas: o MonitoringTarget mostra um status Not Ready quando os clusters de usuários estão sendo criados, fazendo com que as APIs pré-treinadas mostrem continuamente um estado Enabling na interface do usuário.

Alternativa:

Abra o menu no navegador Chrome (ícone de três pontos).
Clique em Mais ferramentas > Ferramentas para desenvolvedores para abrir o console.
Clique na guia Rede no console.
Encontre as solicitações ai-service-status.
Clique na guia Resposta em uma solicitação ai-service-status para mostrar o conteúdo dela.
Verifique se tudo parece pronto, exceto os componentes MonitoringTarget e LoggingTarget.

A função de API pré-treinada `streaming_recognize` do Speech-to-Text falha

Versões: 1.13.3

Sintomas: ao chamar a função de API pré-treinada streaming_recognize do Speech-to-Text, um problema com a biblioteca de cliente causa uma mensagem de erro 400 semelhante a esta:

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:

ENDPOINT: o endpoint do Speech-to-Text. Para mais informações, consulte os status e endpoints dos serviços.
APPLICATION_DEFAULT_CREDENTIALS_FILENAME: o nome do arquivo JSON que contém as chaves da conta de serviço criadas no projeto, como my-service-key.json.
CERT_NAME: o nome do arquivo de certificado da autoridade de certificação (CA), como org-1-trust-bundle-ca.cert. Para mais informações, consulte Gerar o arquivo de certificado da CA do pacote de confiança em um ambiente de desenvolvimento.

O script Python apresenta 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 instrução import adicional em comparação com o script recognize (from google.cloud.speech_v1p1beta1.services.speech import client).
Linha 18: o cliente é retornado por client.SpeechClient() em vez de speech_v1p1beta1.SpeechClient().

O pod e o serviço de front-end de tradução não são inicializados

Versões: 1.11.x, 1.12.x, 1.13.x

Sintomas: durante os upgrades, o cluster do banco de dados de tradução é recriado, o que faz com que o segredo secret-store do cluster do sistema ODS fique desatualizado e dessincronizado. Por isso, o pod e o serviço de front-end de tradução não são inicializados.

Alternativa:

Exclua o secret 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 arquivo kubeconfig no cluster do sistema.

Um controlador recria o secret automaticamente e o ressincroniza com o cluster de banco de dados.

A pesquisa de status do job não é compatível com a API `batchTranslateDocument`.

Versões: 1.13.3

Sintomas: a Vertex AI não oferece suporte às operações GET e LIST nas APIs do serviço de tradução. Chamar a API Translation BatchTranslateDocument retorna uma operação de longa duração semelhante ao exemplo a seguir:

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Esse problema ocorre devido a uma limitação da APIP (autorização) que impede a chamada direta do endpoint. Os endpoints não oferecem suporte à pesquisa de status do job, e não é possível realizar operações GET na operação de longa duração devido à limitação da APIP.

Solução alternativa: como um operador de aplicativos (AO, na sigla em inglês), revise o status do job verificando regularmente a pasta s3_destination e procure um arquivo de saída de job recém-criado. Se a pasta contiver o arquivo de saída, o job foi concluído com sucesso.

As solicitações `batchTranslateDocument` 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 arquivos de entrada do usuário e grava os arquivos temporários de processamento e saída traduzidos no StorageGRID. Um novo cliente curl é criado para cada ação de leitura e gravação porque o reúso do cliente falha.

Os clientes S3 curl no binário são de uso único, ou seja, cada cliente só pode realizar uma única ação de leitura/gravação em buckets do StorageGRID. Portanto, um novo cliente curl é criado sempre que a comunicação com o cliente do StorageGRID é estabelecida do servidor batchTranslateDocument para ler e gravar arquivos em buckets.

No entanto, isso não é ideal para clientes curl. Isso pode causar os seguintes problemas:

Degradação da performance: aumento da latência e diminuição da capacidade de processamento
Esgotamento de recursos: sobrecarga de memória e CPU e esgotamento de soquetes
Sobrecarga do servidor: limitação de taxa ou limitação

O console do GDC mostra um status inconsistente após a ativação de APIs pré-treinadas

Versões: 1.13.3

Sintomas: quando você ativa as APIs pré-treinadas pela primeira vez, o console do GDC pode mostrar um status inconsistente após alguns minutos para o serviço ativado. O console do GDC muda o estado Enabling de volta para Disabled e mostra o botão Ativar novamente na interface do usuário, mesmo que o serviço esteja sendo ativado.

Solução alternativa: o status fica consistente após alguns minutos, e o serviço reflete o status correto.

Para verificar o status do serviço, abra a guia Rede no console do navegador e confira o status da solicitação ai-service-status. O payload precisa mostrar que o operador L2 está ativado.

As solicitações de tradução com mais de 250 caracteres falham nos pods `translation-prediction-server`

Versões: 1.13.3

Sintomas: quando você envia solicitações de tradução com aproximadamente 250 caracteres ou mais (incluindo solicitações de tradução de documentos), os pods translation-prediction-0 ou translation-prediction-1 podem falhar, exigindo o recarregamento do modelo. A recarga do modelo acontece automaticamente e pode levar cerca de 30 minutos para ser concluída.

Esse problema ocorre devido a uma limitação dos contêineres de tradução.

Solução alternativa: divida as solicitações de tradução para que tenham menos de 250 caracteres. Um intervalo entre 200 e 250 caracteres é seguro para todos os idiomas. Nenhuma outra ação é necessária para resolver o problema se uma solicitação longa falhar nos pods.

O `GPUAllocation` para o cluster de serviço compartilhado não está configurado corretamente

Versões: 1.13.3

Sintomas: não é possível programar cargas de trabalho da Vertex AI devido à falta de recursos de GPU suficientes. Por exemplo, se não for possível visualizar ou ativar os endpoints de serviço da Vertex AI, isso pode ser causado pela falta de recursos de GPU suficientes.

Esse problema de recursos pode ser causado por alguns dos recursos GPUAllocation localizados no cluster de serviço compartilhado que não têm a seguinte anotação:

processed: "true"

Alternativa:

Siga IAM-R0004 para gerar o arquivo kubeconfig do g-ORG_NAME-shared-service-cluster.

Liste todas as alocações de GPU no cluster de serviço que não têm 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 será assim:

zi-ad-bm08

Para o recurso GPUAllocation que não está alocado, abra-o em um editor:
```
kubectl edit gpuallocation -n vm-system NODE_NAME
```

Edite a alocação de GPU com base no número total de alocações de GPU presentes no cluster de serviço:

Se houver apenas um recurso personalizado de alocação de GPU, adicione a anotação processed: "true" a ele e modifique a especificação para ficar assim:

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 houver dois recursos personalizados de alocação de GPU, encontre aquele sem a anotação processed: "true", adicione a anotação processed: "true" a ele e modifique a especificação para ficar assim:

annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

Se houver quatro recursos personalizados de alocação de GPU, encontre aquele sem a anotação processed: "true", adicione a anotação processed: "true" a ele e modifique a especificação para ficar assim:

annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

Salve as mudanças no recurso personalizado GPUAllocation e confirme se o status de alocação foi atualizado para true:

kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

O resultado será assim:

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

Ao fazer upgrade da versão 1.9.x para a 1.13.3, o controlador OCLCM mostra erros

Versões: 1.13.3

Sintomas: ao fazer upgrade da versão 1.9.x para a 1.13.3, o controlador de gerenciamento do ciclo de vida de componentes operáveis (OCLCM, na sigla em inglês) para subcomponentes da Vertex AI pode mostrar erros. Esse problema é causado por um erro no job do complemento ai_platform. Os erros recebidos durante o upgrade indicam que o OCLCM não pode transferir a propriedade desses componentes da Vertex AI.

Estes são os componentes afetados da Vertex AI no cluster de administrador da organização:

Nome	Namespace
`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 esse problema, remova manualmente os componentes afetados da Vertex AI do cluster de administrador da organização. Em seguida, a nova versão da Vertex AI baseada no OCLCM os reinstala.

Remova manualmente os componentes afetados da Vertex AI no cluster de administrador da organização:

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

Substitua:

ORG_ADMIN_CLUSTER_KUBECONFIG: o caminho para o arquivo kubeconfig no cluster de administrador da organização.
NAMESPACE: o namespace do componente da Vertex AI que você quer remover. Se o componente não tiver um namespace, remova -n NAMESPACE do comando.
COMPONENT_NAME: o nome do componente da Vertex AI que você quer remover.

O exemplo a seguir mostra como remover o componente aip-l1operator-deployment que existe no namespace ai-system no cluster de administrador da organização:

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

As solicitações de tradução podem gerar o código de erro `RESOURCE_EXHAUSTED`

Versões: 1.13.3

Sintomas: depois de enviar uma solicitação de tradução, você recebe o código de erro RESOURCE_EXHAUSTED na mensagem de resposta. Esse erro ocorre quando você excede um limite de frequência do sistema. Um recurso foi esgotado, como uma cota por usuário, o número máximo de consultas por segundo ou todo o sistema de arquivos está sem espaço.

Solução alternativa: peça ao operador de infraestrutura (IO) para reiniciar os fragmentos de back-end do serviço de tradução. Em seguida, envie as solicitações de tradução novamente com atrasos mais longos entre elas ou enviando solicitações mais curtas.

`batchTranslateDocument` solicitações retornam erro `503`

Versões: 1.13.3

Sintomas: depois de enviar uma solicitação batchTranslateDocument, você recebe o código de erro 503 "Batch Document translation is not implemented" na mensagem de resposta. Esse erro ocorre porque o método BatchTranslateDocument exige o serviço Aspose, que só é implantado quando o parâmetro operável enableRAG é definido como true no cluster.

Solução alternativa: peça ao operador de infraestrutura (IO) para definir o parâmetro operável enableRAG como true no cluster de administrador da organização seguindo estas etapas:

Crie um recurso personalizado SubcomponentOverride em um arquivo YAML chamado vai-translation.yaml com o parâmetro operável enableRAG definido como true:

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

Substitua ORG_ADMIN_NAMESPACE pelo namespace do cluster de administrador da organização.

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 arquivo kubeconfig no cluster de administrador da organização.

Serviços pré-treinados da Vertex AI indisponíveis

Versões: 1.13.7, 1.13.9

Sintomas: os serviços de OCR e tradução da Vertex AI não iniciam devido a problemas de programação do Kubernetes. Talvez você veja um aviso como este nos registros:

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

Solução alternativa: adicione mais nós de trabalho ao pool padrão e despeje os pods nos nós da GPU para que as cargas de trabalho de IA possam ser programadas.

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 imagens de VM locais são importadas usando a CLI gdcloud compute images import, o status da importação fica preso em WaitingForTranslationVM ou ImportJobNotCreated. Isso acontece porque o disco temporário criado para tradução ou importação usa o mesmo tamanho da imagem qcow2/raw, mas o LUKS adiciona uma sobrecarga de alguns MiBs que causa falha no provisionamento do disco.

Alternativa:

Crie um novo VirtualMachineImageImport manualmente 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 VirtualMachineImageImport original criado automaticamente pela CLI tiver minimumDiskSize como X Gi, crie um novo com X+1 Gi. O valor é baseado no tamanho da imagem que está sendo importada. No caso de qcow2, seria o tamanho virtual. Por exemplo, 20Gi deve ser substituído por 21Gi.

Substitua os valores do marcador de acordo com a forma como a CLI foi chamada.

Encontre o VirtualMachineImageImport:
```
kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml
```
Se o objeto não estiver presente, acione o comando gdcloud compute images import ... novamente. Quando a saída do console passar de Uploading image to .. para Image import has started for ..., pressione ctrl+c para que a imagem local seja enviada por upload para o armazenamento de objetos e o VirtualMachineImageImport seja preservado para referência e criação de um novo.

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 provisionamento de um disco com base em uma imagem falha

Versões: 1.13.1, 1.13.3

Sintomas: ao provisionar um disco de uma imagem personalizada, o minimumDiskSize pode estar muito próximo do tamanho virtual, causando falha no provisionamento do disco. O disco da VM está em um estado pendente, mas nunca é provisionado.

Solução alternativa: crie um novo disco manualmente com um spec.minimumDiskSize maior.

O plug-in do dispositivo 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 arquivo kubeconfig no cluster.

Você vai receber uma saída semelhante a este 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

Esse problema faz com que as GPUs fiquem indisponíveis para máquinas virtuais (VMs) e pods. As implicações são baseadas nos seguintes tipos de cluster:

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 usuário. Consulte a solução alternativa para o cluster do sistema e resolva o problema.
Cluster de serviço ou de usuário: o recurso personalizado GPUAllocation não é criado para esse nó de VM, e as GPUs nesse nó não podem ser consumidas por pods no cluster. Consulte a solução alternativa para o serviço ou cluster de usuário para resolver esse problema.

Solução alternativa para o cluster do sistema:

Siga estas etapas para resolver o problema no cluster do sistema:

Defina a variável de ambiente KUBECONFIG com o caminho para o arquivo kubeconfig no cluster do sistema. Para mais detalhes, consulte o runbook IAM-R0004.
Identifique o nó que está com o problema:
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
A saída precisa imprimir o nome do nó e o endereço IP do nó do Kubernetes.

Se houver vários nós, siga as etapas em todos eles. Nesse caso, a saída será semelhante ao exemplo a seguir:
```
Node:                 yy-ab-bm04/172.20.128.26
```
Defina a variável de ambiente NODE_NAME com o nome do nó. Por exemplo:
```
export NODE_NAME=yy-ab-bm04
```
Estabeleça uma conexão SSH com o nó. Para mais detalhes, consulte o runbook PLATAUTH-G0001.

Observação: o endereço IP do nó de gerenciamento é diferente do endereço IP do comando anterior. Use o endereço IP do nó de gerenciamento, conforme mencionado no runbook.

Verifique se o nó tem GPUs:

nvidia-smi -L

A saída precisa imprimir as GPUs no nó, como no exemplo a seguir:

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)

Ative o modo de persistência nas GPUs:
```
nvidia-smi -pm 1
```
Essa ação garante que os drivers da NVIDIA sempre sejam carregados para que o plug-in do dispositivo não atinja o tempo limite.

A saída será semelhante ao exemplo a seguir:
```
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.
```
Observação: o modo de persistência está ativado para a inicialização atual. Essa ação é revertida na próxima reinicialização. Se o problema persistir após a reinicialização, repita essas etapas.
Saia da sessão SSH:
```
exit
```

Verifique se o plug-in de dispositivo está em execução consultando o DaemonSet:

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

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

A saída será semelhante ao exemplo a seguir:

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 cluster de usuário:

Siga estas etapas para resolver o problema no serviço ou cluster:

Defina a variável de ambiente KUBECONFIG com o caminho para o arquivo kubeconfig no cluster de serviço ou de usuário. Para mais detalhes, consulte o runbook IAM-R0004.
Identifique o nó que está com o problema:
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
A saída precisa imprimir o nome do nó e o endereço IP do nó do Kubernetes.

Se houver vários nós, siga as etapas em todos eles. Nesse caso, a saída será semelhante ao exemplo a seguir:
```
Node:                 vm-948fa7f4/172.20.128.21
```
Defina a variável de ambiente NODE_NAME com o nome do nó. Por exemplo:
```
export NODE_NAME=vm-948fa7f4
```
Estabeleça uma conexão SSH com o nó. Para mais detalhes, consulte o runbook PLATAUTH-G0001.

Observação: o endereço IP do nó de gerenciamento é diferente do endereço IP do comando anterior. Use o endereço IP do nó de gerenciamento, conforme mencionado no runbook.

Verifique se o nó tem GPUs:

nvidia-smi -L

A saída precisa imprimir as GPUs no nó, como no exemplo a seguir:

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

Ative o modo de persistência nas GPUs:
```
nvidia-smi -pm 1
```
Essa ação garante que os drivers da NVIDIA sempre sejam carregados para que o plug-in do dispositivo não atinja o tempo limite.

A saída será semelhante ao exemplo a seguir:
```
Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.
```
Observação: o modo de persistência está ativado para a inicialização atual. Essa ação é revertida na próxima reinicialização. Se o problema persistir após a reinicialização, repita essas etapas.
Saia da sessão SSH:
```
exit
```

Verifique se o plug-in de dispositivo está em execução consultando o DaemonSet:

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

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

A saída será semelhante ao exemplo a seguir:

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. Você pode receber 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.

Alternativa:

Encontre e exclua o VirtualMachineInstance.
Reinicie uma nova VM.

Os relatórios de volume de dados não encontraram espaço de trabalho temporário

Versões: 1.13.3, 1.13.4

Sintomas: ao criar um disco de VM, o volume de dados é informado como bem-sucedido:

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

No entanto, um pod de importador, como importer-gdc-vm-disk-vm-ce34b8ea-disk, entra em loop de falha 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: exclua o pod do importador depois de confirmar que o status do volume de dados é Succeeded.

As VMs em projetos com nomes que excedem 45 caracteres permanecem em estado interrompido

Versões: 1.13.5

Sintomas: ao criar uma VM, ela permanece no estado Stopped se o nome do projeto tiver mais de 45 caracteres.

Solução alternativa: crie um projeto com um nome de até 45 caracteres.

Alocação de GPU ausente no cluster de serviço

Versões: 1.13.5

Sintomas: o GPUAllocation está faltando no cluster de serviço compartilhado de gpu-org. Você pode receber uma mensagem ao receber as alocações de GPU:

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

A saída será semelhante ao seguinte:

No resources found

Alternativa:

Adicione um taint ao nó da GPU:

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

Remova o taint para permitir o agendamento do pod virt-launcher da VM.

Não é possível programar a VM de worker do cluster de serviço compartilhado

Versões: 1.13.6

Sintomas: uma VM de worker do Kubernetes não foi programada devido a recursos de CPU insuficientes no nó designado, apesar das GPUs disponíveis. Você pode encontrar 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.

Alternativa:

Interrompa manualmente as VMs sem GPU para liberar recursos de CPU.
Depois que a VM pendente for programada, inicie as VMs sem GPU.

Problemas conhecidos do Google Distributed Cloud com isolamento físico 1.13.x Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Artifact Registry

Erro de reconciliação do subcomponente sar-failoverregistry

Backup e restauração

Falha nos snapshots devido à falta de espaço no volume

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

Falha no backup do snapshot do PVC

Restaurar de um backup incompatível com a cota de SVM

Faturamento

As métricas de faturamento não aparecem corretamente no painel de faturamento

O usuário não consegue criar BillingAccountBinding devido a bugs no webhook de validação.

Armazenamento em blocos

Pods do Grafana travados no estado Init devido a erros de ativação de volume.

Falha no mapeamento de volumes dos pods de inicialização de máquinas virtuais

Falhas relacionadas ao armazenamento

Volumes permanentes criados com tamanho incorreto

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

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

Falha na reconciliação da exclusão

Upgrade bare metal travado

Erro de várias anexações do Trident

Erro na configuração do IPsec

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

Falha na reconciliação das redes intercluster de armazenamento

Gerenciamento de clusters

O job machine-init falha durante o provisionamento do cluster

Sem conectividade do cluster de serviço ao bucket de armazenamento de objetos

Falhas na verificação de simulação

Falha na criação do pool de nós de trabalho do cluster de usuário

Os clusters de usuários recriados podem ficar presos na reconciliação devido a uma limpeza inadequada.

Serviço de banco de dados

Clonagem do banco de dados do AlloyDB Omni travada

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

Erro de reconciliação ao fazer upgrade do subcomponente dbs-fleet

Falha na criação do DBCluster

DNS

As DNSSEC precisam ser desativadas explicitamente em resolved.conf

Serviço do Harbor

Falha na criação do serviço do Harbor

Excluir instâncias do Harbor não exclui os espelhos de registro associados

Módulo de segurança de hardware

As licenças de teste desativadas do HSM ainda são detectáveis

Vazamento de descritor de arquivo do daemon do host do HSM

Certificados de HSM expirados

Gerenciamento de identidade e acesso

Os pods gatekeeper-audit no namespace opa-system são reiniciados com frequência.

Infraestrutura como código (IAC)

A criação excessiva de tokens do GitLab pode preencher os bancos de dados do GitLab.

Key Management System (KMS)

Mudar o tipo de chave raiz invalida todas as chaves atuais.

kms-rootkey-controller CrashLoopBackOff devido a OOMKILL

Logging

O gravador de registros de auditoria do armazenamento de objetos não consegue resolver o host DNS

O HaaS Logger mostra erros no cluster de administrador raiz

Falha no registrador de Santricity

Os registros do destino do Logging são enviados para o projeto errado

Os registros de auditoria do namespace da plataforma não ficam visíveis para o PA.

Falha ao inicializar contêineres

Marketplace

A extração de imagens da Prisma Cloud falha

Monitoramento

Grande número de alertas criados no ServiceNow

Vários alertas duplicados criados no ServiceNow

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

Erro de reconciliação em mon-cortex

O pod metrics-server-exporter no cluster do sistema está em loop de falha

Ignorar mensagens de erro de reconciliação do ObservabilityPipeline

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

Crashloop OOMKilled do componente de gateway da loja do Cortex

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

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

Bootstrap multizona

Funções de cluster ausentes

Recurso Bootstrap incompatível

O recurso GlobalAPIZone não é criado na API global.

Rede

Rede de grade de nós de armazenamento de objetos inativa

O nó não está disponível

PodCIDR não atribuído a nós, mesmo que ClusterCIDRConfig seja criado

Desvio de NTP

Problemas conhecidos do Google Distributed Cloud com isolamento físico 1.13.x

Erro de reconciliação do subcomponente `sar-failoverregistry`

O usuário não consegue criar `BillingAccountBinding` devido a bugs no webhook de validação.

Pods do Grafana travados no estado `Init` devido a erros de ativação de volume.

O job `machine-init` falha durante o provisionamento do cluster

Erro de reconciliação ao fazer upgrade do subcomponente `dbs-fleet`

Os pods `gatekeeper-audit` no namespace `opa-system` são reiniciados com frequência.

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

Erro de reconciliação em `mon-cortex`

O pod `metrics-server-exporter` no cluster do sistema está em loop de falha

Ignorar mensagens de erro de reconciliação do `ObservabilityPipeline`

O ConfigMap `mon-prober-backend-prometheus-config` é redefinido

Recurso `Bootstrap` incompatível

O recurso `GlobalAPIZone` não é criado na API global.

`PodCIDR` não atribuído a nós, mesmo que `ClusterCIDRConfig` seja criado

Relatórios do `ObjectStorageStorageNodeReconciler` `maintenance.gdu.gdu_server_locked`

Pods travados no estado `init`

`bm-system-machine-preflight-check` Falha no job do Ansible para um nó bare metal ou de VM

Pods travados no estado `ContainerCreating`

`bm-system` e outros jobs presos

O número da versão de `storagecluster` não é exibido

`OrganizationUpgrade` está travado na etapa de upgrade do nó

O erro `Incorrect version of Trident` aparece durante o upgrade

Falha no upgrade do subcomponente `iac-zoneselection-global`

O complemento `meta-monitoring` falha porque o local do strongswan está em um diretório de tempo de execução diferente.

O upgrade da organização do locatário falha na fase de verificação de simulação com `ErrImagePull`

Não foi possível encontrar `serviceaccount` durante o upgrade da organização raiz

Falha no upgrade em `shared-service-cluster upgrade`

Falha na instalação do complemento `system-dashboards`

`NodeUpgradeTask` CR está preso na condição `NodeOSInPlaceUpgradePostProcessingCompleted`

Os namespaces `platform-obs-obs-system` ou `platform-obs` ficam travados no estado de encerramento

`NodeUpgradeTask` CR está preso na condição `NodeBIOSFirmwareUpgradeCompleted`

Tempo limite persistente durante a `organizationupgrade` raiz inicial

O subcomponente `obj-syslog-server` não faz a reconciliação na organização raiz

O upgrade do ABM ou do nó parou em `maintenanceMode false`