Esta página foi traduzida pela API Cloud Translation.

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

Backup e restauração

A edição do plano de restauração de backup do cluster está corrompida

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomas:

Não é possível editar o recurso personalizado RestorePlan usando o console do GDC.

Alternativa:

Crie um plano de restauração e exclua o antigo ou edite o plano de restauração usando a CLI kubectl.

Tamanho do disco de origem inválido

Versões: 1.14.4, 1.14.5

Sintomas:a interface mostra incorretamente o tamanho de um disco como 0 MB e o tempo de criação como "Desconhecido" devido a uma mudança no modelo de dados do back-end após a migração para a arquitetura da organização v2.

Alternativa:não há outro método para acessar essas informações na UI.

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

Versões:1.14.3, 1.14.4

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 dos pods para 2 GiB.

Os SLOs de backup e restauração não são aplicados

Versões:1.14.3, 1.14.4

Sintomas:as métricas e os alertas de objetivo de nível de serviço (SLO) do GDC não são configurados por padrão porque a definição de recurso personalizado necessária não está instalada. Esses alertas são usados no Grafana.

Soluções alternativas:para ativar os SLOs de backup e restauração no GDC, siga o runbook BACK-T0001.

As políticas de retenção não são aplicadas aos backups importados

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

Sintomas:anexar um repositório de backup ao cluster sincroniza todos os metadados de backup e restauração e trata os repositórios como backups importados. Esses backups importados são ignorados incorretamente durante a reconciliação, o que significa que as políticas de retenção são ignoradas e os backups são mantidos por tempo indeterminado.

Solução alternativa:os backups importados são rotulados com backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME. Para permitir a reconciliação normal e a aplicação de políticas de retenção, remova o rótulo dos backups usando os seguintes comandos kubectl:

Defina as variáveis de ambiente necessárias:
```
export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE
```
Substitua:
- KUBECONFIG: o caminho para o arquivo kubeconfig.
- BACKUP_REPOSITORY_NAME: o nome do repositório de backup.
- NAMESPACE: o namespace que contém o plano de backup.

Liste todos os backups importados:

kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME

Remova os rótulos conforme necessário:

Remova os rótulos de todos os backups:

kubectl get backups.backup.gdc.goog -l
backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
-o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
$NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-

Remova os rótulos de um único backup:

export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
$NAMESPACE backup.gdc.goog/imported-repository-

Falha no backup parcial da VM

Versões: 1.14.3, 1.14.4

Sintomas: se uma VM de várias não fizer backup, todo o backup da VM será marcado como falho.

Solução alternativa: limite o número de VMs por plano de backup.

Limpar recursos de backup órfãos após a exclusão de um cluster de usuário ou de serviço

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomas: quando um cluster de usuário ou de serviço é excluído, os recursos do agente de backup associados (como StatefulSet, pods, secret etc.) criados na infraestrutura da organização e no cluster de gerenciamento não são limpos automaticamente. Isso pode deixar recursos órfãos e, se o cluster for criado novamente com o mesmo nome, o pod do agente de backup não vai funcionar.

Solução alternativa: os recursos órfãos existem em um namespace dedicado no cluster de infraestrutura da organização. Para limpar, exclua esse namespace.

Defina os arquivos kubeconfig para clusters de gerenciamento e infraestrutura da organização.

export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>

Identifique o namespace dos recursos órfãos. O namespace segue o padrão gpc-backup-<cluster-name>-system. Exemplo:
- gpc-backup-user-vm-1-cluster-system
- gpc-backup-user-vm-2-cluster-system
- gpc-backup-g-org-1-shared-service-cluster-system

Exclua o namespace. Isso vai excluir todos os recursos dentro dele, incluindo o StatefulSet e o pod do agente de backup na infraestrutura e o secret no cluster de gerenciamento.

# Replace <namespace-name> with the actual namespace
kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"

Para confirmar se a limpeza foi bem-sucedida, execute o comando get all novamente.
```
# Replace <namespace-name> with the actual namespace
kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
```
O comando vai falhar porque o namespace não existe mais. Você vai receber um erro como Error from server (NotFound): namespaces "<namespace-name>" not found.

A exclusão de VirtualMachineRestore não é compatível com a CLI ou UI.

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomas: o controlador VirtualMachineRestore não limpa automaticamente os recursos subjacentes (VolumeRestore, Restore) após a exclusão de um recurso VirtualMachineRestore. Isso exige uma limpeza manual. Isso se aplica à exclusão usando kubectl delete ou a UI.

Solução alternativa: exclua manualmente os recursos dependentes na ordem correta e remova o finalizador do recurso VirtualMachineRestore.

Defina o arquivo kubeconfig para apontar para o cluster de gerenciamento.
```
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
```

Identifique o VirtualMachineRestore a ser excluído e o namespace dele.

export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
export NAMESPACE=<namespace-of-vm-restore>

Encontre e exclua os recursos VolumeRestore associados. Eles são criados com um rótulo que os vincula ao VirtualMachineRestore.

# Find and delete all associated VolumeRestores.
kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

Encontre e exclua os recursos Restore associados. Eles são criados com um rótulo que os vincula ao VirtualMachineRestore.

# Find and delete all associated Restores.
kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

Agora, execute kubectl delete se ainda não tiver feito isso e remova o finalizador do recurso VirtualMachineRestore. Essa é a etapa final que permite que o coletor de lixo do Kubernetes exclua o recurso.

kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"

Verifique a exclusão.

kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

O comando vai retornar um erro NotFound, confirmando que o recurso foi excluído.

O pod do plano de controle de backup falha devido à falta de memória

Versões: 1.14.4 e mais recentes

Sintomas:o pod gpcbackup-controlplane-controller no namespace do sistema gpc-backup do cluster de infraestrutura da organização mostra o status CrashLoopBackOff. Quando esse erro ocorre, as operações de backup e restauração falham, param de responder ou não funcionam como esperado.

Solução alternativa:aumente os limites de memória da implantação gpcbackup-controlplane-controller seguindo BACK-R0005. Esse método aplica um SubcomponentOverride para ajustar a CPU, as solicitações e os limites de memória.

A exclusão do cluster de usuário está paralisada

Versões: 1.14.7 e mais recentes

Sintomas:os clusters ficam presos no estado de exclusão devido a problemas de finalização.

Solução alternativa: verifique se os volumes de armazenamento têm relações SnapMirror antes de excluir o cluster. Para mais informações, consulte BACK-R0109.

A restauração está travada devido a uma reivindicação de volume permanente pendente

Versões: 1.14.3 e mais recentes

Sintomas:às vezes, os controladores de solicitação de volume permanente (PVC) não conseguem se comunicar com agentes de backup no cluster de infraestrutura da organização. Embora esse problema não afete a funcionalidade de backup, ele pode fazer com que uma operação de restauração de volume fique presa em um estado Pending e, eventualmente, atinja o tempo limite. Esse problema afeta operações de restauração que envolvem uma restauração de volume, como o recurso de restauração do serviço de banco de dados para clonagem e uma restauração de carga de trabalho do usuário.

Se esse problema ocorrer, as operações de restauração subsequentes no cluster afetado vão falhar até que você reinicie manualmente o agente de backup correspondente.

Para confirmar se o problema de restauração está relacionado a essa questão específica, investigue os registros do agente de backup:

Siga IAM-R0005 para receber o papel necessário do BACK Debugger (back-cluster-debugger) ao aplicar o recurso ExpirationClusterRoleBinding.
Siga IAM-R0004 para gerar o arquivo kubeconfig do cluster de infraestrutura da organização. Todos os agentes de backup são executados no cluster de infraestrutura da organização.

Identifique o agente de backup que está facilitando a restauração:

kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
    --all-namespaces | grep gpcbackup-agent

Substitua ORG_INFRA_KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de infraestrutura da organização.

O resultado será assim:

NAMESPACE                                          NAME                                     READY   AGE
gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
gpc-backup-system                                  gpcbackup-agent                          1/1     22d
gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d

Leia a saída e determine o agente de backup que corresponde à sua restauração. Por exemplo, se o namespace do conjunto stateful afetado na saída for gpc-backup-user-vm-1-cluster-system, o agente de backup será gpcbackup-agent-user-vm-1.

Procure a mensagem de erro nos registros do conjunto stateful para confirmar o problema:
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
```
Substitua:
- ORG_INFRA_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de infraestrutura da organização.
- BACKUP_AGENT: o agente de backup que você identificou na etapa anterior.
- NAMESPACE: o namespace que você identificou na etapa anterior.
Se houver registros correspondentes, você está enfrentando esse problema conhecido.

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

Reinicie o agente de backup:
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE
```
Substitua:
- ORG_INFRA_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de infraestrutura da organização.
- BACKUP_AGENT: o agente de backup que você identificou ao confirmar o problema.
- NAMESPACE: o namespace que você identificou ao confirmar o problema.
O resultado será assim:
```
statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
```
Aguarde até 20 minutos para que as operações pendentes sejam retomadas automaticamente.

É possível fazer outra restauração para o mesmo cluster de destino depois que a reinicialização do agente de backup for concluída. Depois de concluir essa solução alternativa, não haverá efeitos colaterais. Só é necessário concluir essa solução alternativa uma vez por cluster afetado.

Gerenciamento de clusters

O subcomponente `kub-gpu-controller` não faz reconciliação

Versões: 1.14.3

Sintomas:o subcomponente g-gdchservices-shared-service-cluster/kub-gpu-controller na organização gdchservices não é reconciliado. A seguinte saída é retornada:

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

Essa falha impede que as máquinas de GPU sejam iniciadas na organização gdchservices.

Solução alternativa:faça upgrade para a versão 1.14.4 ou mais recente para atenuar o problema.

Não é possível remover um pool de nós de um cluster padrão

Versões: 1.14.3, 1.14.4, 1.14.5

Corrigido: 1.14.6

Sintomas:a remoção de pools de nós obsoletos de clusters padrão falha, e os pools de nós não são excluídos no período esperado. Os clusters padrão estão em visualização particular e podem não estar disponíveis para todos os clientes.

Solução alternativa:remova manualmente os pools de nós obsoletos.

Cluster preso no estado de exclusão

Versões: 1.14.6 e mais recentes

Sintomas:ao excluir um cluster do Kubernetes, ele pode ficar preso em um estado Deleting. Verifique o estado do cluster executando o seguinte comando:

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

O resultado será assim:

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

Você também pode verificar o problema conferindo o estado do namespace do cluster:

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

O resultado será assim:

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

O namespace do cluster está preso em um status Terminating, e as condições NamespaceContentRemaining e NamespaceFinalizersRemaining estão definidas como True.

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

Faça o patch da API de regras de encaminhamento:

kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'

Adicione um patch à API de serviços de back-end:

kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'

Serviço de banco de dados

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

Clonagem de banco de dados do AlloyDB Omni travada

Versões: 1.14.6 e anteriores

Corrigido: 1.14.7

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.

DNS

GlobalCustomerRootDNSServerNotReachable disparando um alerta falso

Versões:1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7, 1.14.8

Sintomas:o alerta DNS-A0021 é acionado, sugerindo GlobalCustomerRootDNSServerNotReachable. O CR de sondagem para global-customer-root-dns em org-mp não tem egress: true na especificação.

Alternativa:

Defina o caminho KUBECONFIG para org-mgmt:

export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG

Pause o subcomponente core-mz que gerencia o CR de sondagem:

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true

Edite o CR de sondagem atual de org-mp:

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns

Atualize a especificação para incluir egress: True e aplique a mudança. Observe que CLUSTER_NAME e GLOBAL_CUSTOMER_ROOT_IP não foram alterados.

apiVersion: prober.private.gdc.goog/v1alpha1
kind: Probe
metadata:
  name: global-customer-root-dns
spec:
  egress: True
  matchClusters:
  - CLUSTER_NAME
  probeJobs:
  - moduleName: dns_udp_global_customer_root
    name: healthy-dns-global-customer-root
    targets:
    - GLOBAL_CUSTOMER_ROOT_IP

Essa solução alternativa corrige o verificador, e os alertas falsos desaparecem em 15 minutos.

Armazenamento de arquivos/blocos

Não é possível ativar o volume de compartilhamento de arquivos na VM

Versões: 1.14.6, 1.14.7

Sintomas: há uma falha ao atualizar as permissões de armazenamento de rede quando um novo nó é adicionado a um cluster, o que pode fazer com que as solicitações de montagem do NFS sejam negadas. É possível que um erro access denied by server apareça ao montar um compartilhamento de arquivos NFS.

Solução alternativa: reinicie os reconciliadores file-share ou proxy-group ou modifique o recurso FileShare para acionar uma atualização.

Firewall

A regra da política de segurança está ausente para o endereço no CR da sub-rede

Versões: 1.14.3

Sintomas:uma organização fica inacessível porque o grupo de endereços do firewall está ausente no recurso personalizado da sub-rede global criado pelo cliente no servidor da API global da organização.

Solução alternativa:siga as etapas no manual de serviço FW-G0002 para adicionar manualmente uma regra de política de segurança e permitir o tráfego.

Os firewalls do GDC negam o tráfego para o OIR nos planos de gerenciamento e de dados.

Versões: 1.14.3, 1.14.4

Sintomas:depois que o recurso personalizado OCITTopology é implantado, a conectividade entre o OIR e o plano de gerenciamento e o plano de dados do GDC é interrompida.

Solução alternativa:siga as etapas no manual de serviço FW-G0002 para adicionar manualmente regras de política de segurança no cluster de administrador raiz e permitir o tráfego.

As seguintes regras de política de segurança são obrigatórias:

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

Substitua:

OCIT_CIDR: os intervalos de endereços IP no campo ocitCIDR do Questionário de entrada do cliente (CIQ, na sigla em inglês).
MGMT_CIDR: os intervalos de endereços IP no campo oobManagementCIDRs do Questionário de entrada do cliente (CIQ, na sigla em inglês).
ZONE_INFRA_CIDR: os intervalos de endereços IP no campo zoneInfraCIDRs do Questionário de entrada do cliente (CIQ, na sigla em inglês).

O firewall do GDC nega o tráfego entre zonas e organizações.

Versões: 1.14.3, 1.14.4, 1.14.5

Sintomas:o tráfego entre zonas e organizações é bloqueado por padrão pelos firewalls.

Solução alternativa:siga as etapas do runbook para adicionar manualmente regras de política de segurança e permitir o tráfego.

O firewall não oferece suporte a AttachmentGroup cujo identificador é igual ao nome da organização

Versões: 1.14.3 e mais recentes

Sintomas:depois que um AttachmentGroup é implantado, se o campo identifier nesse objeto AttachmentGroup for igual a orgName, o firewall não vai analisar esse objeto, e as atualizações de configuração do firewall vão ficar travadas. Confira um exemplo de AttachmentGroup problemático:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

Solução alternativa:evite usar o nome da organização como identificador. Há algumas opções para corrigir o AttachmentGroup incorreto.

Escolha uma das seguintes opções para corrigir o AttachmentGroup problemático.

Anexe uma string ao final do identificador original com um símbolo de traço:

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: myorg-orgdx
  entities:
    - orgName: myorg
      domainType: OrgMixed

Adicione uma string ao início do identificador original com um símbolo de traço:

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: orgdx-myorg
  entities:
    - orgName: myorg
      domainType: OrgMixed

Substitua o identificador original por uma string diferente:

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: dxidentifier
  entities:
    - orgName: myorg
      domainType: OrgMixed

Porto

O secret da CLI do Harbor fica inválido após o backup e a restauração

Versões:1.14.3

Sintomas:depois de um backup e restauração do Harbor, os segredos da CLI ficam inválidos e precisam ser criados novamente.

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

Faça login no Harbor com uma conta de usuário do IAP.
Clique no seu nome de usuário e selecione Perfil de usuário.
Clique em Mais.
Crie outro secret da CLI de forma automática ou manual.

Para mais informações sobre o Harbor no GDC, consulte Visão geral do Harbor.

O trabalho de backup e restauração do Harbor disputa permissão

Versões: 1.14.3, 1.14.4

Sintomas:quando há várias instâncias do Harbor em projetos de usuários diferentes, as operações de backup e restauração competem por controles de acesso baseados em função e têm uma alta taxa de falha.

Solução alternativa:para atenuar esse problema, siga estas etapas para criar manualmente uma vinculação de função para cada namespace em que as instâncias do Harbor são criadas:

Defina as variáveis de ambiente necessárias:
```
INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
```
Substitua:
- INFRA_CLUSTER_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de infraestrutura.
- INSTANCE_NAMESPACE: o namespace em que as instâncias do Harbor do serviço gerenciado do Harbor (MHS) são criadas.

Crie a vinculação de papel para a solução alternativa:

kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
--role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
--namespace=haas-system

O tamanho do backup do Harbor mostra valores zero

Versões: 1.14.3, 1.14.4

Sintomas:no momento, a medição do tamanho do backup do Harbor não está implementada. No console do GDC, os campos SizeBytes mostram um valor de 0, e a coluna Tamanho mostra um valor de 0 MB. Essa configuração é o comportamento esperado por enquanto.

Erro de permissão nos recursos de backup na página do console do Harbor Registry

Versões: 1.14.3, 1.14.4

Sintomas:se você não tiver a função de administrador da instância do Harbor, vai aparecer um erro de permissão no recurso de backup ao acessar a página Harbor Container Registry no console do GDC. Esse erro é mostrado porque as informações de backup foram adicionadas recentemente à página Harbor Container Registry, mas a permissão de leitura do recurso de backup não foi concedida a papéis do IAM que não sejam o administrador da instância do Harbor.

Os outros elementos do console do GDC na página Harbor Container Registry ainda funcionam como esperado. Para mais informações sobre papéis no GDC, consulte Definições de papéis.

A página de rotação de senha do banco de dados está travada

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Sintomas:erros gerados relacionados à autenticação de solicitações ao banco de dados, como failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), e muitas solicitações de rotação geradas automaticamente estão presentes para um único segredo rotativo.

Solução alternativa:exclua outras solicitações de rotação não prontas para um secret rotativo.

Defina KUBECONFIG como o servidor da API mp.
Exporte o namespace:
```
NAMESPACE=haas-system
```

Verifique se há secrets rotativos em haas-system que não estão prontos:

kubectl get rotatablesecrets -n ${NAMESPACE?}

A saída pode ser semelhante a este exemplo:

NAME                        CREDENTIALID   READY     AGE
haasdb-pw-ar-test           HAAS-0002      True      109d
haasdb-pw-gardener-harbor   HAAS-0002      True      178d
haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
haasdb-pw-myinstance        HAAS-0002      True      80d
haasdb-pw-osd               HAAS-0002      True      158d
haasdb-pw-saptest           HAAS-0002      True      91d

Exporte o nome do secret rotativo, por exemplo:
```
ROTATABLE_SECRET=haasdb-pw-haas-alice
```

Exclua solicitações de rotação extras que não estão prontas:

CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')

kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}

Módulo de segurança de hardware

As licenças de teste desativadas do HSM ainda são detectáveis

Versões:1.14.3, 1.14.4, 1.14.5

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

Os HSMs falham com o erro `ValidateNetworkConfig` após a inicialização

Versões: 1.14.x

Sintomas:os recursos personalizados do HSM não entram em um estado Ready e falham devido a um erro ValidateNetworkConfig. Esse erro mostra a seguinte mensagem: data0 interface MAC address {} is not active. Esse erro ocorre se o sistema for reinicializado e uma interface de dados primária diferente for definida.

Solução alternativa:siga o runbook HSM-R0059 e reaplique a configuração de rede do HSM para a rede de dados. Este runbook pode ser seguido mesmo que mais de um HSM tenha esse erro.

INTEGRIDADE

Alertas de SLO de alarme falso

Versões: 1.14.3

Sintomas: um SLO de successRange está sendo disparado erroneamente.

Solução alternativa: peça ao operador de infraestrutura (IO) para verificar se o alerta é um problema real ou um alarme falso.

Para isso, quando um alerta for acionado, siga o runbook correspondente para resolver a causa do alerta de objetivo de nível de serviço (SLO).

Caso 1: se o runbook resolver o problema e o alerta parar de ser acionado, o IO poderá encerrar o incidente associado.

Caso 2: se o runbook for concluído, mas o alerta continuar sendo disparado, isso indica um possível alarme falso. Verifique se o SLO está violado:

kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'

Com base na saída: se ela confirmar que o alerta é um falso alarme, o IO deverá silenciar o alerta na instância isolada do GDC. Caso contrário, encaminhe para o suporte do Cloud.
Em qualquer caso, é adequado que o IO encaminhe o problema ao Suporte do Cloud para verificar se o componente operacional está íntegro.

Configurações inválidas de SLO com base em indicadores

Versões: 1.14.3, 1.14.4

Sintomas: um subconjunto de objetivos de nível de serviço (SLOs) não vai preencher eventos bons, ruins ou totais devido a uma configuração incorreta. Os SLOs em questão são baseados em indicadores do Prometheus e precisam ser configurados de acordo.

Alternativa:

Versão 1.14.3: não há alternativa. Como consequência, os alertas de SLO não serão disparados para os SLOs afetados.

Versão 1.14.4: uma solução alternativa está disponível para corrigir o SLO. Para resolver esse problema, a configuração isGauge: true precisa ser aplicada à especificação de SLO.

Exemplo de uma configuração de medidor para um SLO:

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

A lista conhecida de SLOs corrigidos com essa configuração é:

SLOs de firewall:
- fw-packet-discard-errors-slo
- fw-packet-discard-no-error-slo
- fw-packet-discard-unknown-protocol-slo
- fw-uptime-slo
SLOs de arquivo:
- file-ontap-appliance-availability-slo
- file-ipsec-networking-availability-slo
- file-ontap-networking-availability-slo
- file-iscsi-client-availability-slo
- file-multipath-client-availability-slo
- file-trident-client-availability-slo

Gerenciamento de identidade e acesso

Falha na criação da vinculação de papel do IAM

Versões:1.14.3

Sintomas:os nomes de vinculação de papéis do IAM são gerados pelo sistema. Esses nomes têm um comprimento máximo de 63 caracteres, no formato user-idp-prefix-rolename. Em casos em que o nome gerado excede o limite de 63 caracteres, as vinculações de função não são criadas. Consequentemente, as permissões definidas usando papéis predefinidos ou personalizados não serão atribuídas aos usuários.

Solução alternativa:a criação de vinculação de papéis pode ser bem-sucedida se o nome do papel predefinido ou personalizado for muito curto, por exemplo, de quatro a cinco caracteres.

Falha ao criar a vinculação de papel do IAM para contas de serviço do projeto

Versões:1.14.3, 1.14.4, 1.14.5 e 1.14.6

Sintomas:uma conta de serviço do projeto (PSA, na sigla em inglês) com a função organization-iam-admin não pode usar o comando gdcloud projects add-iam-policy-binding para atribuir a si mesma outra função, como project-iam-admin. Essa deficiência impede que uma PSA gerencie as próprias permissões.

Solução alternativa:confirme se você tem o papel organization-iam-admin. Em seguida, atribua a si mesmo a função project-iam-admin no namespace do projeto do PSA de destino e atribua a função project-iam-admin ao PSA. Essa configuração de permissões permite que o PSA atribua outras permissões a si mesmo ou a outros PSAs.

Atrasos na criação de projetos com papéis predefinidos

Versões: 1.14.3

Sintomas:quando um novo projeto é criado, ele não tem papéis padrão, como project-bucket-object-admin.

Solução alternativa:aguarde de 15 a 60 minutos ou reinicie manualmente o controlador iam-org-admin-cm-backend-controller no namespace iam-system no cluster de infraestrutura da organização.

O console do GDC não pode criar a primeira vinculação de função

Versões:1.14.4

Sintomas:ao criar a primeira vinculação de função para uma nova identidade de serviço usando o console do GDC, a criação da vinculação de função é informada como concluída, mas não funciona. Outras ações na identidade de serviço vão falhar e não terão efeito, incluindo a adição ou exclusão de vinculações de papéis.

Solução alternativa:use a CLI gdcloud para criar a primeira vinculação de função para uma identidade de serviço. Todas as ações futuras com a identidade de serviço realizadas usando o console do GDC funcionam corretamente depois que a primeira vinculação de função é anexada. Para mais informações, consulte Atribuir uma vinculação de função à identidade de serviço.

Os AOs não podem conceder a si mesmos acesso a papéis no cluster de infraestrutura.

Versões: 1.14.3. 1.14.4

Corrigido: 1.14.3 hotfix 21

Sintomas: os AOs não têm como conceder a si mesmos ou a outros usuários acesso a qualquer função no cluster de infraestrutura.

Solução alternativa: os usuários da AO precisam entrar em contato com os IOs para receber o acesso necessário. Os IOs podem usar o IAC para fornecer aos usuários do AO o acesso necessário.

O token da conta de serviço atual fica inválido

Versões: 1.14.3

Corrigido: 1.14.3 hotfix 21

Sintomas: o token da conta de serviço emitido pelo cluster de usuário fica inválido porque o argumento service-account-issuer apiserver é alterado depois que o cluster está em estado de execução após a inicialização. Esse problema faz com que o pod, por exemplo, o pod com um contêiner sidecar istio-proxy, no cluster de usuário falhe na autenticação usando o token da conta de serviço. Além disso, leva horas para que o token da conta de serviço seja atualizado com as novas configurações.

Solução alternativa: reinicie manualmente o pod no cluster de usuário para que o token da conta de serviço seja renovado com as novas configurações.

Infraestrutura como código (IAC)

Falha na reconciliação de subcomponentes devido à falta de namespace

Versões:1.14.3

Sintomas:um subcomponente não é reconciliado. Isso acontece porque o namespace config-management-monitoring necessário não é criado automaticamente no cluster gdchservices-mp.

Solução alternativa:crie o namespace config-management-monitoring no cluster gdchservices-mp usando o seguinte manifesto:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

A coleta de métricas do ConfigSync do IAC falha

Versões:1.14.3, 1.14.4

Sintomas:um problema no subsistema de monitoramento do ConfigSync do IAC impede o início da implantação do otel-collector. As métricas do ConfigSync não são coletadas para monitoramento e alertas.

Solução alternativa:conclua as etapas a seguir no cluster root-admin:

Pause o subcomponente iac-configsync-mon.
Edite o objeto MetricsProxySidecar/iac-configsync-metrics no namespace config-management-monitoring.

No YAML MetricsProxySidecar/iac-configsync-metrics, encontre o seguinte:

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-target-cert

Mude esta seção para o seguinte:

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-mon-target-cert

Reinicie a implantação otel-collector no namespace config-management-monitoring.

Falha do RootSync do IAC

Versões:1.14.3

Sintomas:há um problema na sincronização de recursos do ConfigSync do GitLab para clusters devido a um segredo iac-creds ausente . Os iac-creds não são rotacionados devido a um problema no iacmanager.

Solução alternativa:siga estas etapas no cluster:

Siga o runbook IAC-R0015 para resolver o problema da chave secreta iac-creds ausente. Ele gira a credencial do gerenciador de IaC e do ConfigSync.

Inventário

A auditoria de inventário não é reconciliada

Versões:1.14.3

Sintomas:o subcomponente inv-audit não consegue fazer a conciliação porque o HarborRobotAccount está disponível apenas no plano de gerenciamento.

Solução alternativa:crie um silêncio no AlertManager para silenciar o alerta component_reconciliation_errors para component: inv.

Sistema de gerenciamento de chaves

O KMS configurado para usar uma chave raiz do CTM não faz failover quando um HSM está indisponível

Versões:1.14.x

Sintomas:algumas solicitações ao KMS falham quando um HSM está indisponível e há outros HSMs disponíveis que poderiam ter sido usados. Esse problema só é aplicável quando o KMS está configurado para usar uma chave raiz do CTM.

Solução alternativa:remova o HSM indisponível do HSMCluster seguindo o runbook HSM-P0006. Em seguida, reinicie a implantação do kms-backend:

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

Esse comando reinicia os pods kms-backend e restabelece a conexão com os HSMs no HSMCluster.

Balanceadores de carga

A criação do balanceador de carga global falha devido ao esgotamento do CIDR da sub-rede

Versões:1.14.3

Sintomas:a criação de um balanceador de carga global externo ou interno falha devido à falta de endereços IP em sub-redes globais. O sistema não consegue alocar endereços IP dinamicamente para balanceadores de carga globais devido a um controlador que usa um codepath incorreto. O balanceador de carga faz referência a apenas uma sub-rede. Se ela não tiver mais endereços IP disponíveis, não será possível mudar para outra sub-rede. Essa limitação faz com que o erro seja mostrado.

Solução alternativa:crie sua própria sub-rede e endereços IP estáticos para seus recursos do ForwardingRule. Para mais informações sobre como criar sub-redes, consulte Configurar sub-redes para rede de carga de trabalho. Ao criar um recurso ForwardingRule, é possível especificar a sub-rede no campo cidrRef.

Versões: 1.14.3

Sintoma:os objetos do balanceador de carga não estão entrando em um estado Ready.

Solução alternativa:crie recursos Backend em que o campo spec tenha um valor. Os recursos Backend identificam endpoints para o balanceador de carga. Se você não fornecer um valor para o campo spec, poderão ocorrer estados de erro.

A modificação dos recursos do balanceador de carga não reconcilia os serviços

Versões: 1.14.3

Sintomas:a modificação de recursos personalizados do balanceador de carga não reconcilia os serviços do balanceador de carga.

Solução alternativa:para reduzir esse problema, exclua e recrie o balanceador de carga excluindo os recursos BackendService e ForwardingRule dele.

Nomes de zonas incorretos não são rejeitados

Versões: 1.14.3

Sintomas:o recurso global BackendService não rejeita nomes de zona incorretos. Se o nome da zona estiver incorreto, o balanceador de carga vai falhar em vez de validar e rejeitar a configuração.

Solução alternativa:forneça os nomes corretos das zonas em uso. Se o balanceador de carga estiver configurado incorretamente, os recursos personalizados dele precisarão ser excluídos e recriados.

Erro de webhook do balanceador de carga global e por zona

Versões: 1.14.3

Sintomas:o seguinte erro é retornado:

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

Solução alternativa:para minimizar esse problema, reinicie e exclua o pod unet-global-cm:

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

Logging

O pod do Loki falha ou é OOMKilled durante a repetição do WAL

Versões: 1.14.3, 1.14.4, 1.14.5

Sintomas:

Os pods audit-logs-loki-io no namespace obs-system entram em um estado CrashLoopBackOff. Isso é causado por falhas prematuras na sondagem de atividade ou por uma interrupção por falta de memória (OOM) durante a repetição do registro de gravação antecipada (WAL) devido a um valor wal_replay_ceiling que excede o limite de memória do pod.

Alternativa:

Siga estas etapas para ajustar a configuração do Loki e permitir uma repetição bem-sucedida do WAL. As mudanças precisam ser aplicadas ao cluster afetado (por exemplo, root-admin ou org-infra).

Defina KUBECONFIG=/path/to/affected-cluster.kubeconfig como uma variável de ambiente.

Pause o LoggingPipelineReconciler para impedir que o controlador reverta as mudanças manuais. Aplique este manifesto:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: log-logging-pipeline-pause
  namespace: root
spec:
  subComponentRef: "log-admin"
  backend:
    operableParameters:
      controller:
        disableReconcilers: "LoggingPipelineReconciler"

Confirme se a substituição está ativa. A saída deve incluir "disable-reconcilers=LoggingPipelineReconciler".

kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq

Diminua o replay_memory_ceiling no ConfigMap audit-logs-loki-io-cm para 8GB.

kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}

Modifique a seção wal:

[...]
  wal:
    replay_memory_ceiling: 8GB ## <-- Change to 8GB
[...]

Opcional: dimensione o proxy de objeto. Se os pods obj-proxy estiverem perto dos limites de recursos, dimensione a implantação para processar o aumento da carga durante a recuperação.

a. Verifique o uso de recursos:
```
kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
```
b. Se o uso for alto, dimensione a implantação:
```
kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
```
c. Se necessário, também é possível aumentar o limite de memória do pod (por exemplo, de 12000Mi para 16000Mi).
Aumente o tamanho do PVC para o pod afetado (por exemplo, loki-storage-audit-logs-loki-io-0 de 70Gi para 75Gi) para evitar a pressão no disco. Siga o procedimento interno SUPP-R001 para redimensionar o PVC. O reinício na próxima etapa aplica o novo tamanho.
Adicione um startupProbe ao audit-logs-loki-io StatefulSet para permitir tempo para a repetição do WAL antes do início das verificações de atividade. Salvar a mudança aciona uma reinicialização gradual dos pods (5 a 10 minutos).
```
kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
```
Adicione este startupProbe à especificação do contêiner audit-logs-loki-io:
```
startupProbe:
  failureThreshold: 1000
  httpGet:
    path: /ready
    port: loki
    scheme: HTTP
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 10
```

Verificar a solução alternativa

Verifique o status do pod e do StatefulSet: verifique se todos os pods audit-logs-loki-io estão Running e se o StatefulSet mostra todas as réplicas como prontas.

kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}

Confirme se o PVC foi redimensionado. A saída esperada é 75Gi.

kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo

Confirme se a recuperação do WAL foi bem-sucedida verificando os registros do pod em busca de mensagens errors=false.
```
kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
```

Verifique se o uso do diretório /wal dentro do pod está baixo.

kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal

Verificar o status do Loki Ring:

a. Encaminhe o serviço Loki:

DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}

b. Verifique se todas as instâncias estão íntegras em http://<DATA_IP>:43100/ring.

Limpar a substituição e o proxy de objeto

Depois da verificação, siga estas etapas de limpeza.

Remova a substituição de subcomponente:

kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}

Se você aumentou o escalonamento da implantação obj-proxy, reduza-o para o tamanho original.

Monitoramento

Os webhooks do AlertManager não enviam alertas para alguns clusters

Versão: 1.14.3

Sintomas:os webhooks do AlertManager não enviam solicitações e notificações de alerta para o ServiceNow de qualquer cluster que não seja o cluster de administrador raiz ou aquele em que a instância do ServiceNow reside. Portanto, não são criados alertas no ServiceNow para a organização.

É possível identificar que o webhook não envia alertas se você receber mensagens de registro de erros repetidamente. Siga estas etapas para procurar erros repetidos:

Exporte variáveis de ambiente:
```
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
```
Substitua MGMT_API_KUBECONFIG pelo caminho para o arquivo kubeconfig do servidor da API Management.

Encontre o pod:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
  -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-

Acesse os registros:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system

Substitua POD_NAME pelo nome do pod.

Procure erros repetidos semelhantes a estes:

Errorsendingtherequest ... read: connection reset by peer

Solução alternativa:a solução recomendada para esse problema é pausar dois subcomponentes, um para alertas de meta-monitoramento e outro para alertas regulares. Em seguida, substitua o rótulo egress.networking.gke.io/enabled: "true" por networking.private.gdc.goog/infra-access: enabled na implantação mon-alertmanager-servicenow-webhook-backend do cluster afetado. Esse rótulo permite que o pod se comunique com outros clusters de infraestrutura sem depender de um gateway de saída.

Siga estas etapas para aplicar a solução alternativa recomendada:

Exporte variáveis de ambiente:
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG
```
Substitua:
- ROOT_KUBECONFIG: o caminho para o arquivo kubeconfig do cluster de administrador raiz.
- MGMT_API_KUBECONFIG: o caminho para o arquivo kubeconfig do servidor da API Management.
- ORG: o namespace da organização.

Pausar subcomponentes:

Pause o subcomponente mon-alertmanager-servicenow-webhook:

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

Pause o subcomponente mon-meta-monitoring:

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

Atualize a implantação mon-alertmanager-servicenow-webhook-backend que abrange a maioria dos alertas:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system mon-alertmanager-servicenow-webhook-backend

Substitua o rótulo em spec.template.metadata.labels de egress.networking.gke.io/enabled: "true" para networking.private.gdc.goog/infra-access: "enabled".

Atualize a implantação meta-alertmanager-servicenow-webhook que abrange alertas relacionados à pilha de monitoramento:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system meta-alertmanager-servicenow-webhook

Substitua o rótulo em spec.template.metadata.labels de egress.networking.gke.io/enabled: "true" para networking.private.gdc.goog/infra-access: "enabled".

Como alternativa, use o Grafana para ver os mesmos alertas.

Os incidentes do ServiceNow são duplicados ocasionalmente

Versão: 1.14.3

Sintomas:você pode encontrar incidentes duplicados do ServiceNow para o mesmo pod.

Solução alternativa:é possível identificar tíquetes duplicados comparando as impressões digitais na descrição do incidente.

As métricas de infraestrutura podem ser sensíveis demais

Versão: 1.14.3

Sintomas:você pode receber alarmes para o alerta oclcm-reconciler-success-rate.

Solução alternativa:é possível silenciar o alerta com segurança. Esse alerta é muito ruidoso, e estamos trabalhando para melhorar o sinal.

As métricas de conciliação podem ser sensíveis demais

Versão: 1.14.3, 1.14.4, 1.14.5

Sintomas:você pode receber alarmes para o alerta component_reconciliation_errors.

Solução alternativa:é possível silenciar o alerta com segurança seguindo o runbook MON-R2009. Esse alerta é muito ruidoso.

Dois alertas falsos estão abertos no cluster de administrador raiz

Versão: 1.14.3

Sintomas:os alertas MON-A0001_slow e MON-A0001_fast estão em estado de disparo no cluster de administrador raiz.

O incidente no ServiceNow é semelhante ao exemplo a seguir:

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

O incidente tem a seguinte descrição:

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

Solução alternativa:siga estas etapas para resolver o problema apenas no cluster de administrador raiz:

Exclua o marcador monitoring.gdc.goog/metamonitoring-project=mon-system em mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

Exclua todas as regras de gravação com o nome mon_metrics_pipeline_absent e o valor do rótulo do cluster ORG_NAME-admin de mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

O exemplo a seguir mostra uma regra de gravação mon_metrics_pipeline_absent a ser excluída:

Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
    Labels:
      _source_project:  blackbox-monitoring-obs-system
      Cluster:          gdchservices-admin
      Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
    Record:             mon_metrics_pipeline_absent

Os alertas MON_A0001_slow e MON_A0001_fast voltam ao estado Normal após alguns minutos (cerca de 40 minutos).

O gerenciador do controlador de administrador raiz mostra uma alta taxa de erros

Versão: 1.14.3

Sintomas:você pode receber alarmes para o alerta ControllerReconciliationErrorRateHigh. O gerenciador de controladores vai mostrar registros dizendo: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Solução alternativa:você pode desativar o controlador com erro sem problemas.

Exporte variáveis de ambiente:
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
```
Edite a implantação do gerenciador de controladores de administrador raiz:
```
kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller
```
No contêiner manager, se ainda não houver um argumento --disable-reconcilers, adicione um com o valor --disable-reconcilers=ApplianceStorageTunnelReconciler. Se houver, adicione o conciliador ApplianceStorageTunnelReconciler com uma vírgula. Por exemplo: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler

Os registros de erros devem ser limpos.

Os painéis do KUB não mostram dados em nenhum dos painéis de PA

Versões: 1.14.3

Sintomas:os painéis do KUB não mostram dados em todos os painéis do Grafana para administradores da plataforma.

Solução alternativa:pause o subcomponente do KSM e atualize monitoringtarget e metricsproxysidecar:

Pause o subcomponente:

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

Substitua:

ORG_NAME: o nome da organização.
ROOT_ADMIN_KUBECONFIG: o caminho para o kubeconfig root-admin

Adicione o seguinte ao mon-kube-state-metrics-metrics-proxy metricsproxysidecar na seção .spec.destinations:

  - certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

O metricsproxysidecar atualizado pode ficar assim:

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

Remova a seção matchClusters: do mon-pa-kube-state-metrics monitoringtarget spec. O mon-pa-kube-state-metrics monitoringtarget spec atualizado pode ter esta aparência:

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics

Permissões mal configuradas para a função observability-admin-debugger

Versões: 1.14.3, 1.14.4

Sintomas:os IOs não conseguem reiniciar os pods do cortex ou do prometheus no namespace mon-system.

Alternativa:

Para organizações:

Pause o subcomponente iam-common.

Atualize o observability-admin-debugger/iam-system roleTemplate para o seguinte:

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

Para administrador raiz:

Pause o subcomponente iam-common.

Atualize o observability-admin-debugger-root/iam-system roleTemplate para o seguinte:

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

Função do depurador do Grafana ausente

Versões: 1.14.3, 1.14.4

Sintomas:a função grafana-debugger-cp não está presente nos namespaces do projeto de observabilidade (*-obs-system). Os usuários não podem receber o conjunto correto de permissões necessárias para depurar problemas relacionados ao Grafana.

Solução alternativa: crie o seguinte recurso personalizado ClusterRoleTemplate em infra-cp e use o ClusterRole correspondente que é criado para receber as permissões grafana-debugger.

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

Métricas e registros entre zonas não ficam visíveis após a adição de uma nova zona

Versões: 1.14.*

Sintomas:o painel do Grafana não mostra registros e métricas da zona recém-adicionada.

Solução alternativa 1:reinicie a implantação do datasource-proxy:

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

Isso vai reiniciar os pods do datasource-proxy e atualizar a configuração do endpoint entre zonas para a zona recém-adicionada.

O finalizador `MonitoringTarget` bloqueia a exclusão do namespace

Versões: 1.14.3, 1.14.4

Sintomas:o namespace não está sendo excluído, e há clusters não íntegros na organização respectiva.

Solução alternativa:remova manualmente os finalizadores dos recursos personalizados MonitoringTarget que bloquearam a exclusão do namespace.

Exclusão de projeto travada devido a finalizadores pendentes do painel e da fonte de dados

Versões: 1.14.3, 1.14.4

Corrigido: hotfix 22 da versão 1.14.3

Sintomas: os projetos não são excluídos e o namespace de encerramento tem erros como no exemplo a seguir:

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

Solução alternativa: exclua manualmente os finalizadores do painel e da fonte de dados.

As métricas do KSM não estão visíveis

Versões: 1.14.3

Corrigido: hotfix 22 da versão 1.14.3

Sintomas: os painéis do KUB mostram No Data em todos os painéis.

Solução alternativa: pause o subcomponente do KSM e atualize monitoringtarget e metricsproxysidecar.

Pausar subcomponente:

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

Substitua:

ORG_NAME: o nome da organização.
ROOT_ADMIN_KUBECONFIG: o caminho para o kubeconfig do administrador raiz.

Adicione o seguinte a mon-kube-state-metrics-metrics-proxy metricsproxysidecar em .spec.destinations:

- certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

O mon-kube-state-metrics-metrics-proxy metricsproxysidecar atualizado fica assim:

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

Remova a seção matchClusters: da especificação mon-pa-kube-state-metrics monitoringtarget. A especificação mon-pa-kube-state-metrics monitoringtarget atualizada fica assim:

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics`

O pipeline de métricas do sistema está inativo

Versão: 1.14.3

Sintomas:o alerta MON-A0001 permanece ativo mesmo depois de seguir o runbook MON-R0001.

Alternativa:

Se o problema for detectado no cluster de administrador, crie o seguinte SubcomponentOverride em root-admin usando o runbook IAC-R0004. Para outros clusters, como de usuário, perímetro ou compartilhados, crie o SubcomponentOverride em ${ORG}-mp.

kind: SubcomponentOverride
metadata:
  name: mon-cortex-tenant
  namespace: <NAMESPACE>
spec:
  backend:
    operableParameters:
      concurrency: 1024
      resourcesLimit:
        cpu: "8"
        memory: 16Gi
  subComponentRef: mon-cortex-tenant

Encontre o NAMESPACE correto:

kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

A saída é a seguinte:

org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
root                 mon-cortex-tenant                      47h   ReconciliationCompleted

O namespace é a raiz, se o pipeline estiver inativo para root-admin, ou org-1, se o pipeline estiver inativo para org-1 admin:

kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

A saída é a seguinte:

g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted

Nesse caso, o namespace correto pode ser g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster ou user-vm-2-cluster, dependendo de qual cluster o pipeline de métricas do sistema está inativo.

Depois de aplicar o SubcomponentOverride, reinicie o deployment do cortex-tenant nos respectivos clusters. Verifique se os valores foram atualizados no cluster respectivo:
```
kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
```
Atualize o campo de simultaneidade.

Reinicie as implantações do cortex-tenant:

kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system

Multilocação

O console não indica falhas na criação do pool de nós

Versão: 1.14.4, 1.14.5, 1.14.6

Corrigido: 1.14.7

Sintomas:no console do GDC, quando a criação de um pool de nós falha, a UI mostra incorretamente uma mensagem creation in progress, indicando que o pool de nós foi criado.

Solução alternativa:use a CLI gdcloud para validar a criação do pool de nós.

Várias zonas

A zona inacessível redireciona para a página de autenticação

Versão: 1.14.x

Sintomas:quando uma zona está inacessível, o console do GDC redireciona para uma página que mostra um erro de autenticação. No entanto, a inacessibilidade da zona pode não ser causada por um problema de autenticação, mas sim por uma interrupção zonal.

Solução alternativa:use o URL zonal para contornar o problema. Se o URL zonal também não funcionar, peça ao operador de infraestrutura (IO) para diagnosticar se a zona em que você está recebendo problemas de autenticação está inativa.

A função para visualizar zonas usando a CLI gdcloud não é aplicada

Versão: 1.14.x

Sintomas:o papel do IAM necessário para usar o comando gdcloud zones list não é aplicado ao universo do GDC por padrão. A função ausente, que não está disponível como uma função predefinida, impede o uso da CLI gdcloud para listar zonas.

Solução alternativa:aplique o papel do IAM global-zone-viewer e os recursos de vinculação de papel ao servidor de API global:

Crie um arquivo YAML de função, como global-zone-viewer.yaml, com o seguinte conteúdo:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: global-zone-viewer
  namespace: mz-system
rules:
- apiGroups:
  - location.mz.global.private.gdc.goog
  resources:
  - zones
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: global-zone-viewer-binding
  namespace: mz-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: global-zone-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

Aplique o arquivo YAML ao servidor de API global da organização:

kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml

Essa vinculação de função autentica todos os usuários no sistema para visualizar zonas usando gdcloud zones list.

Erros intermitentes de login no URL do console global

Versões: 1.14.x

Sintomas:ao fazer login no console do GDC com o URL global, você pode receber erros informando que sua sessão não é mais válida. Esse erro pode ser causado por um bug de rede subjacente e não por uma representação precisa do status da sua sessão.

Solução alternativa:faça login no console do GDC com os URLs zonais para gerenciar recursos globais em cada zona. Para mais informações sobre como alternar contextos zonais no console do GDC, consulte Gerenciar recursos em várias zonas.

Rede

Ajustar a ordem das zonas `MultiZoneNetworkConfig` causa falha na substituição da configuração

Versões: todas as versões 1.14.x podem ser afetadas.

Sintomas:

O status READY para interruptores de topo de rack (ToR) é "False". Para confirmar, execute o seguinte comando:
```
kubectl get torswitches -A
```
A substituição da configuração de chave falha com um erro indicando que a entrada já existe. Isso pode ser visto nos registros de substituição da configuração do switch. A mensagem de erro é semelhante a esta:
```
% Insertion failed - entry already exists
```

Esse problema é causado pelo ajuste da ordem das zonas no MultiZoneNetworkConfig. O sistema gera números de sequência para regras de lista de controle de acesso do BGP com base na posição de cada zona na lista de configuração. Se a ordem das zonas for alterada, o sistema vai gerar novas regras com números de sequência diferentes que entram em conflito com as regras já presentes no switch.

Alternativas:

Para resolver esse problema, remova manualmente a configuração conflitante da lista de controle de acesso do caminho AS do BGP de cada switch ToR afetado. Isso permite que o sistema concilie e aplique a configuração correta.

Estabeleça uma conexão SSH com cada switch ToR que não esteja no estado Ready.
Insira o modo de configuração global:
```
config t
```
Remova a configuração conflitante da lista de acesso:
```
no ip as-path access-list other-zones
```
Sair do modo de configuração.

Depois que esse comando for executado em todos os switches afetados, o reconciliador vai aplicar a configuração correta, e os switches vão passar para um estado READY.

Validade do commit de substituição de configuração

Versões: todas as versões 1.14.x podem ser afetadas.

Sintomas:

Um grande número de listas de controle de acesso (ACLs) causa um tempo limite ao configurar switches de rede. O recurso personalizado BorderLeafSwitch não está no estado Ready e, ao estabelecer uma conexão SSH com a chave não pronta, o status Commit expiry é exibido.

Por exemplo, o comando a seguir mostra o status:

sh config-replace log verify

O resultado será assim:

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

Alternativa:

Nas versões 1.14.3 ou 1.14.7+, edite o recurso personalizado SubcomponentOverride chamado pnet-core-override no namespace root e adicione um campo httpTimeout a .spec.operableParameters.netDevGW.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

Aguarde 15 minutos para que a infraestrutura de automação envie novas configurações aos switches. Configure o httpTimeout conforme necessário até que as mensagens de Commit expiry desapareçam.

Nas versões 1.14.4, 1.14.5 e 1.14.6, faça manualmente o config-replace e confirme as mudanças.

Pausar a troca:

export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"

Siga o manual de procedimentos PNET-P0001 para acessar o interruptor.
Encontre a configuração a ser substituída:
```
switch-cli# dir | grep new_config
```
Conclua o config-replace:
```
switch-cli# configure replace <new_config_file>
```
Isso pode levar mais de cinco minutos.
Depois que o config-replace for concluído, faça o commit da mudança:
```
switch-cli# configure replace commit
```

Retome a troca:

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-

A implantação com ASN do BGP de 4 bytes falha

Versões: 1.14.3, 1.14.4

Sintomas: a configuração do protocolo de gateway de borda (BGP) com um número de sistema autônomo (ASN) de 4 bytes em switches de rede causa falhas de configuração. Sem uma configuração do BGP aplicada corretamente, a rede nessa zona do GDC pode não conseguir estabelecer o roteamento adequado, o que causa problemas de conectividade, incapacidade de anunciar rotas ou instabilidade geral da rede. No momento, não há uma alternativa.

Tráfego global de anycast bloqueado

Versões: 1.14.3

Sintomas:o tráfego direcionado aos endpoints anycast globais é bloqueado pelas listas de controle de acesso (ACLs).

Alternativa:

Para resolver o problema em que o tráfego de anycast global é bloqueado por listas de controle de acesso (ACLs), crie um recurso personalizado SubcomponentOverride no cluster de administrador raiz para permitir explicitamente o tráfego para os blocos CIDR de anycast do servidor DNS global. Siga estas etapas:

Encontre todos os blocos CIDR de anycast global. Para encontrar os blocos CIDR de anycast global a serem atualizados, siga estas etapas:
1. Conecte-se ao servidor da API global raiz.
2. Liste todos os recursos personalizados de sub-rede em todos os namespaces usando o comando:
```
kubectl get subnet -A
```
3. Filtre a saída para encontrar recursos de sub-rede em que o filtro metadata.name contenha a palavra-chave anycast.
4. Para cada recurso de sub-rede encontrado com anycast no nome, anote o valor de spec.subnet. Esse valor representa um bloco CIDR de anycast global.

No cluster de administrador raiz, crie um recurso personalizado SubcomponentOverride chamado pnet-trafficpolicy-dc-override no namespace raiz. Para cada sub-rede anycast identificada na etapa anterior, adicione as regras conforme mostrado no arquivo YAML:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-trafficpolicy-dc-override
  namespace: root
spec:
  backend:
    operableParameters:
      breakglassRules:
        default-traffic-policy-data:
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: INTERCONNECT_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataInterconnect
          sourceEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: HAIRPIN_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataHairpin
          sourceEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
  subComponentRef: pnet-trafficpolicy-dc

Substitua:

INTERCONNECT_RULE_DESCRIPTION: o texto descritivo da regra de rede do Interconnect.
GLOBAL_ANYCAST_CIDR: o bloco CIDR de anycast global, como 136.125.38.128/28. Para cada anycast encontrado na etapa anterior, crie a regra usando este arquivo YAML.
HAIRPIN_RULE_DESCRIPTION: o texto descritivo da regra de rede de hairpin.

Falha parcial de DCI causa perda de tráfego

Versões: 1.14.3

Sintomas:quando os dois links de interconexão do data center (DCI) que conectam o switch de borda de uma zona ao switch da operadora ou quando o switch de borda de uma zona sofre uma falha de hardware, cerca de 50% do tráfego de rede entre zonas é perdido.

O nome da VRF é muito longo

Versões: 1.14.2

Sintomas:talvez você veja uma mensagem como este exemplo, indicando que as chaves não estão íntegras ao executar este comando:

sh config-replace log verify

A saída pode ser semelhante a este exemplo:

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

Solução alternativa:o nome do CR da organização pode ter no máximo 19 caracteres.

Falha na comunicação do pod StatefulSet

Versões: 1.14.3, 1.14.4

Corrigido: hotfix 23 1.14.3, 1.14.5

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

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

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

Problema do painel do Grafana do SLO de disponibilidade entre zonas e em várias zonas

Versões: 1.14.3

Sintomas: no Grafana, o painel de SLO pnet-cross-zone-availability não mostra nenhuma métrica.

Solução alternativa: siga o runbook PNET-P0001 para acessar o switch e verificar manualmente a sessão do BGP multizona e o status da conectividade.

Falha na reconciliação dos gateways de entrada do plano de dados e de gerenciamento

Versões: 1.14.3

Sintomas:os subcomponentes asm-dataplane-ingress ou asm-management-ingress não estão sendo reconciliados com o seguinte erro:

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

Outros valores possíveis na string de erro em vez de BackendService são ForwardingRuleInternal e ForwardingRuleExternal. Da mesma forma, o nome do recurso pode ser dataplane-ingress-gateway, dataplane-ingress-gateway-global ou management-ingress-gateway-global em vez de management-ingress-gateway.

Solução alternativa:identifique se o recurso está presente no servidor da API de gerenciamento ou no servidor da API global. Isso pode ser inferido da versão da API do tipo de recurso na string de erro. Por exemplo, um recurso com o sufixo networking.gdc.goog está presente no servidor da API de gerenciamento, enquanto um recurso com o sufixo networking.global.gdc.goog está presente no servidor da API global.

Depois de identificar o servidor da API, exclua o recurso usando o arquivo kubeconfig correspondente. Exemplo:

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

A página de política de rede do projeto não é compatível com o campo do seletor de projetos na API ProjectNetworkPolicy

Versões: 1.14.3, 1.14.4

Sintomas: ao criar uma política de rede de projeto que inclui o campo projectSelector e visualizá-la no console do GDC, a UI mostra todos os projetos selecionados para a política em vez dos projetos no campo projectSelector.

Solução alternativa: use a API para criar e ler uma política de rede do projeto que inclua o campo projectSelector.

Sistema operacional

Falha no provisionamento do servidor

Versões: 1.14.3

Sintomas: durante o provisionamento do servidor, os seguintes erros 401 podem aparecer no recurso personalizado BaremetalHost correspondente ao baixar a imagem do SO do registro do Harbor, e o servidor fica preso em um loop de desprovisionamento e reprovisionamento.

Para verificar esses erros, descreva o recurso personalizado BaremetalHost:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

A saída pode ser semelhante a este exemplo:

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

Alternativa:

Consiga o nome e o namespace do nodePoolClaim a que o servidor pertence:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'

A saída pode ser semelhante a este exemplo:

{
"name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
"namespace": "gpu-org-lancer"
}

Consiga o nome da imagem do SO do NodePoolClaim:

kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'

Consiga o URL da imagem do SO no OSImageMetadata:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'

Atualize o recurso personalizado Server com o URL da imagem do SO mais recente:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'

O OS NodeUpgrade pode ficar travado na etapa NodeOSInPlaceUpgradePostProcessingCompleted

Versões: 1.14.3, 1.14.4

Sintomas:

Durante um upgrade de nó, o NodeUpgradeTask fica preso na etapa NodeOSInPlaceUpgradePostProcessingCompleted com um erro do reconciliador com a mensagem failed verifying delta after upgrade e não foi possível concluir. Esse erro indica que o processo de verificação de upgrade encontrou discrepâncias inesperadas de pacotes no nó. Especificamente, ele identifica pacotes que ainda estão no estado "need-upgrade" ou aparecem como "only-in-new" após a tentativa de upgrade.

A mensagem de erro lista pacotes específicos que não foram verificados. Exemplo de snippet:

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

Esse sintoma pode ser causado por dois problemas. Primeiro, detecte qual problema é a causa:

Cause-A: máquina inacessível, fazendo com que OSArtifactSnapShot fique desatualizado.

Verifique se o nó em upgrade ainda está íntegro ou não e se o trabalho OSArtifactSnapShot correspondente está falhando.

Se OSArtifactSnapShot estiver desatualizado e a máquina não estiver acessível por mais de 20 minutos, siga para Mitigation-A. Caso contrário, continue verificando se há Cause-B.
Cause-B: falha silenciosa na atualização da RPM

Em casos raros, o upgrade do RPM em uma máquina pode falhar sem aviso após um upgrade parcial. Deve haver dois ConfigMaps contendo a diferença de pacote antes e depois do upgrade:
```
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
```
Se o "after-upgrade" tiver menos pacotes que o configmap "before-upgrade", isso significa que o upgrade foi cancelado silenciosamente e nem todos os pacotes foram atualizados. Continue para Mitigation-B.

Alternativa:

Mitigation-A: corrigir máquina inacessível

Tente reiniciar a máquina para corrigir o problema. Se a máquina ainda estiver inacessível após as tentativas de reinicialização, entre em contato com a equipe do SERV para receber mais ajuda. Depois que a máquina estiver acessível novamente, exclua o OSArtifactSnapShot para forçar a reconciliação. Quando OSArtifactSnapShot for reconciliado, NodeUpgradeTask vai passar para a próxima etapa.

Mitigation-B: tente novamente o NodeUpgradeTask

Faça SSH na máquina que está sendo atualizada e colete os seguintes registros para solução de problemas futuros. Os seguintes arquivos precisam ser coletados:
- /var/log/dnf.log
- /var/log/dnf.rpm.log
- dnf history > dnf_history.log
- rpm -qa --last > rpm_last.log
Exclua o NodeUpgradeTask com falha. Isso vai acionar uma nova tentativa do NodeUpgradeTask no nó específico. O novo NodeUpgradeTask vai concluir o upgrade do RPM e seguir para a próxima etapa.

O NodeUpgrade do SO pode ficar preso na etapa de criação do servidor de pacotes

Versões: 1.14.3, 1.14.4

Sintomas:

Quando um CR NodeUpgrade é criado, retomado e permanece em in-progress por mais de 30 minutos, ele pode falhar silenciosamente na etapa de criação do servidor de pacotes. O sintoma é um NodeUpgrade que permanece com: .status.upgradeStatus=in-progress, mas não há .status.tasks carregado:

status:
  duration: 0s
  upgradeStatus: in-progress

Para confirmar ainda mais que isso falha na criação do servidor de pacotes, leia o registro do controlador de upgrade do SO:

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Se o registro do controlador mostrar failed to create package server e failed to create package repo server DNS registration com um motivo detalhado (qualquer um dos seguintes):

spec.fqdnPrefix already used in an existing DNS registration
name already used in an existing DNS.

Em seguida, ele sugere que alguns outros recursos do servidor de pacotes usados por outros NodeUpgrade ainda estão ativos e entram em conflito com o recurso a ser criado para o NodeUpgrade pendente atual.

Alternativa:

Para confirmar ainda mais, verifique o recurso real do servidor de pacotes (de determinada API, como dnsregistration.network.private.gdc.goog no servidor de API de gerenciamento do cluster que gerencia o CR NodeUpgrade) e encontre o NodeUpgrade proprietário desses recursos. Se o NodeUpgrade proprietário do DNSRegistration já tiver terminado, mas o recurso DNSRegistration ainda não tiver sido excluído, será possível excluir o objeto DNSRegistration se todos os objetos NodeUpgrade referenciados tiverem sido concluídos.

Liste todos os CRs DNSRegistration para o servidor de pacotes NodeUpgrade:

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm

Consulte o CR do proprietário para um DNSRegistration específico:NodeUpgrade

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'

Os upgrades do SO do nó podem encontrar problemas e parar em qualquer estágio do processo.

Versões: 1.14.4, 1.14.5, 1.14.6

Sintomas:

NodeUpgradeTask CR ainda abaixo de in-progress há mais de 2 horas, mas pode ser concluído automaticamente se houver tempo suficiente.

O CR NodeUpgradeTask está em andamento há mais de duas horas. Embora ele possa ser concluído automaticamente, o problema subjacente é a incapacidade do os-policy-reconciler de gerenciar com eficiência um grande volume de CRs OSPolicy. Esse problema ocorre durante a etapa NodeOSInPlaceUpgradeCompleted.

Para confirmar ainda mais essa falha durante a criação do servidor de pacotes, consulte o registro do controlador de upgrade do SO.

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Se o registro do controlador não tiver uma entrada OSPolicy do NodeUpgradeTask, isso indica que o controlador está sobrecarregado.

Alternativa:

Pause todos os CRs OSPolicy não essenciais durante o processo de upgrade.

"storage cp" de um arquivo grande derruba o kube-api org-mgmt

Versões: 1.14.3 e mais recentes

Sintomas: durante uma operação gdcloud storage cp ou gdcloud system container-registry load-oci em uma estação de trabalho OIC, há uma pequena chance de perda do acesso à infraestrutura da organização, seguida pela queda do kube-api do org-mgmt. Esse é um problema raro, e a coleta de dados para engenharia é útil.

Solução alternativa: quando esse problema ocorrer, siga estas etapas:

Para cada nó do plano de controle (CP), execute uptime para verificar se os nós foram reinicializados nas últimas 24 horas.
Anote a hora da reinicialização.
Verifique se houve falhas fatais do kernel em cada nó do CP antes da reinicialização executando dmesg | grep -i 'kernel panic'.
Em cada nó do plano de controle, verifique se as placas de rede Mellanox estão instaladas executando: lspci | grep -i eth | grep -i mellanox. Se não houver NICs Mellanox, pare de ler este problema conhecido.

Em cada nó do CP, verifique estas configurações de rede em data0:

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: on  # <--- Check this value

Se rx-gro-hw (veja acima) estiver definido como "off" em todos os nós, pare de ler este problema conhecido.

Reúna algumas informações para ajudar o Google a diagnosticar o problema:

k8s.org get po -n anthos-identity-service -l k8s-app=ais

k8s.org get po -n management-kube-system

k8s.org get po -n kube-system -l component=kube-apiserver

k8s.org get nodes -l node-role.kubernetes.io/control-plane

Em cada nó do plano de controle, execute os seguintes comandos:

dmesg | grep -i 'kernel panic'

journalctl -u disable-rx-gro-hw.service

systemctl status disable-rx-gro-hw

modinfo mlx5_core | grep ^version:

Para minimizar o problema de configurações de rede, rx-gro-hw precisa ser off. Para isso, execute os seguintes comandos em todos os nós do plano de controle:
```
ethtool -K data0 rx off gro off lro off
ethtool -K data1 rx off gro off lro off
ethtool -K bond00 rx off gro off lro off
```

Verifique as configurações novamente:

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: off # <--- Check this, should be "off"

Repita a operação original, como gdcloud storage cp ou gdcloud system container-registry load-oci. Se ainda houver uma falha, entre em contato com a engenharia.

Infrastructure: Core Services do pacote de operações (OIC)

Desempenho ruim do Jumphost

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

Sintomas: as operações do navegador ou do sistema levam muito tempo para serem concluídas.

Alternativa:

Aumente a contagem de vCPUs nos jump hosts usando o gerenciador do Hyper-V no BM03 e no BM04:

Selecione uma VM de jump host e clique em Configurações no painel de ações.
Selecione Processador e aumente a contagem em Número de processadores virtuais para 4 ou mais, dependendo da carga de trabalho.
Repita o processo para os Jumphosts restantes.

Gerente de recursos

Não é possível excluir projetos no console do GDC

Versões: 1.14.3, 1.14.4

Sintomas: o console do GDC fornece o botão excluir Excluir para projetos atuais na página Detalhes do projeto, mas o botão não funciona.

Solução alternativa: para excluir um projeto, use a CLI gdcloud. Para mais informações, consulte Excluir um projeto.

Manuais do Ansible da organização ausentes

Versões: 1.14.3

Sintomas: ao criar uma organização, o job create-ansible-playbooks que cria os playbooks do Ansible necessários falha sem aviso. Os playbooks do Ansible ausentes causam problemas como falta de máquinas virtuais de perímetro e problemas na criação de uma organização global.

Solução alternativa: siga o runbook OS-R0009 para criar manualmente os playbooks do Ansible da organização que estão faltando.

A organização global assimétrica mostra configurações zonais inexistentes

Versões: 1.14.4

Sintomas: ao criar uma organização global v1 com apenas um subconjunto de configurações de organização zonal, todas as zonas ainda mostram um status de réplica da organização. Por exemplo, se você tiver um universo do GDC com três zonas, mas criar uma configuração de organização zonal para apenas duas delas, a terceira ainda vai mostrar um status de réplica incorreto para a terceira organização zonal inexistente.

Para confirmar o status incorreto, imprima o status da organização global:

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

A saída YAML será semelhante a esta:

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

Isso só acontece em organizações da v1, já que configurações zonais assimétricas não são compatíveis com organizações da v2.

Solução alternativa: ignore o status de réplica incorreto, já que a organização zonal não existe, a menos que você a tenha criado especificamente.

Cluster

O pool de nós de worker do cluster de infraestrutura não é excluído

Versões: 1.14.3, 1.14.4

Sintomas: ao remover um pool de nós de worker da especificação do CR Organization, o pool de nós não é excluído automaticamente. Ou seja, o comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} ainda gera o pool de nós a ser excluído.

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

Solução alternativa: depois de remover o pool de nós de trabalho da especificação do CR Organization, exclua manualmente o CR NodePoolClaim desse pool de nós do cluster de administrador raiz executando o comando: sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

Aguarde até que o NodePoolClaim e os CRs NodePool associados sejam totalmente excluídos. Ou seja, o comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} não mostra mais o pool de nós de trabalho.

Armazenamento

Não é possível excluir buckets criados com o comando `gdcloud config set zone`

Versões: 1.14.7 e mais recentes

Sintomas: os buckets criados com o comando gdcloud config set zone não são excluídos devido a problemas de permissão, porque o comando tenta operar na zona errada.

Solução alternativa: use o console para definir a zona específica de um bucket ou substitua a flag --zone por --location no comando gdcloud.

Alertas de SLO de OBJ disparados

Versões: 1.14.3, 1.14.4

Sintomas: os alertas de SLO para OBJ estão sendo disparados devido ao erro ErrFailedStreamingDecryptRequest no proxy OBJ: obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo.

Solução alternativa: silencie o alerta. O erro está sendo identificado incorretamente como um erro do sistema quando é causado pelo usuário ao encerrar a conexão, o que não conta para o SLO.

ETag vazia do S3 UploadPart

Versões: 1.14.3

Sintomas: depois de enviar uma solicitação UploadPart, você recebe um código de status 200 Success na mensagem de resposta, mas o campo ETag está vazio. Esse erro ocorre porque um InternalServerError acontece devido a uma interrupção na rede, e o código de status não é atualizado para 500 InternalServerError.

Solução alternativa: repita a solicitação como se ela tivesse falhado anteriormente.

Os pods não são ativados devido a um erro `mkfs.ext4` do Trident

Versões: 1.14.3

Sintomas: depois de tentar montar pods, você observa que todos os pods que estão em transição para ou de um nó específico falham. Uma mensagem de erro de RPC: DeadlineExceeded desc = context deadline exceeded aparece, indicando que o nó está travado. Quando essa mensagem aparece, você perde a capacidade de realizar outras operações do Trident no nó em questão. Os volumes que atendem aos dados não são afetados, mas os volumes que se movem para e do nó podem sofrer uma interrupção.

Alternativa:

Inspecione os registros do Trident no nó em que o pod está tentando fazer a montagem e verifique se a fila está aumentando. Os registros podem ser semelhantes a este:

2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"

Faça login no nó e confira a saída de dmesg. Os registros podem ser semelhantes a este:

Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)

Depois de confirmar que você está enfrentando um erro do Trident mkfs.ext4, reinicialize o nó.

O Trident não consegue criar um volume devido a um erro já existente

Versões: 1.14.3

Sintomas:

Um PVC não é provisionado e mostra um evento como este:

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

Quando isso acontece, a PVC não é provisionada até que você execute a solução alternativa.

Alternativa:

Siga estas etapas para resolver o problema:

Anote o nome do volume interno do evento. Por exemplo, o evento de amostra mostrado na seção Sintomas mostra o nome interno do volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
Siga o runbook FILE-R0105 para acessar o ONTAP.

Exclua o volume:

volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

`file_block_iscsi_sessions_unhealthy alert` informa um falso positivo

Versões: 1.14.3

Sintomas: em alguns ambientes, o alerta file_block_iscsi_sessions_unhealthy é acionado, indicando que um ou mais nós estão apresentando falhas no iSCSI. O controlador file-observability usa um coletor de métricas personalizado para rastrear a integridade das sessões iSCSI em cada nó do Kubernetes. No entanto, em alguns casos, o coletor de métricas não consegue analisar a saída do comando iscsiadm e informa zero sessões iSCSI em execução, mesmo que o iSCSI tenha sessões íntegras.

Alternativa:

Siga estas etapas para verificar se o iSCSI não está com problemas e silencie o alerta se ele for um falso positivo:

Na página de análise do Grafana, execute a consulta fb_sessions_running_count{job="file-observability-backend-target.file-system"}. A consulta retorna uma métrica para cada nó no cluster. Se algum nó estiver informando uma métrica fb_sessions_running_count de 0, anote o nome do nó.
Para cada nó com métricas fb_sessions_running_count que retornam 0, execute os seguintes comandos:
1. Estabeleça uma conexão SSH com o nó afetado.
2. Execute o comando iscsiadm -m session. Várias linhas vão aparecer. Cada linha é uma sessão iSCSI em execução. Se nada for retornado do comando ou se houver erros na saída, encaminhe o problema para a equipe de engenharia de bloqueio de arquivos.
3. Se o comando anterior retornou sessões iSCSI com êxito, você confirmou que o alerta para esse nó é um falso positivo.
Quando você confirmar que todos os nós afetados têm sessões iSCSI íntegras e estão causando o disparo incorreto do alerta, crie um silêncio no AlertManager para silenciar o alerta file_block_iscsi_sessions_unhealthy.

O alerta `file_block_storage_disk_failure` é acionado para discos sobressalentes

Versões: 1.14.3

Sintomas: em alguns ambientes, o alerta file_block_storage_disk_failure é acionado, indicando que um ou mais discos no ONTAP estão com problemas. O controlador file-observability usa um coletor de métricas personalizado para rastrear a integridade de cada disco no ONTAP. No entanto, em versões anteriores do GDC, o coletor não considera um disco sobressalente como íntegro e aciona um alerta para ele.

Alternativa:

Siga estas etapas para verificar se os discos são sobressalentes e silencie o alerta para o disco:

Na página de análise do Grafana, execute a consulta disks_labels_healthy{job="file-observability-backend-target.file-system"}. A consulta vai retornar uma métrica para cada disco no ONTAP. Se algum disco estiver informando uma métrica de 0 (não íntegro), anote o nome dele.
Para cada disco com métricas disks_labels_healthy que retornam 0, execute os seguintes comandos:
1. Faça SSH no cluster ONTAP e execute o comando disk show -disk <disk-name> -fields state usando o nome do disco coletado da consulta de métrica.
2. Verifique se a saída do comando indica que o estado do disco é present ou spare. Se o disco estiver em qualquer outro estado além de present ou spare, encaminhe o problema para a equipe de engenharia de bloqueio de arquivos.
3. Se o disco em questão estiver informando present ou spare, podemos confirmar que o alerta não deve ser acionado para esse disco. Crie um silêncio no AlertManager para silenciar o alerta file_block_storage_disk_failure com o rótulo disk_name definido como o nome do disco.
Depois de criar silêncios para todos os discos sobressalentes, navegue até o Grafana para verificar se os alertas pararam de ser acionados.

O alerta "file_block_storage_node_peer_connection_unhealthy" é acionado depois que a conexão é restaurada

Versões: 1.14.3

Sintomas: em alguns ambientes, o alerta file_block_storage_node_peer_connection_unhealthy é acionado, indicando que uma ou mais conexões entre os nós do ONTAP estão falhando. O controlador file-observability usa um coletor de métricas personalizadas para rastrear a integridade dessas conexões. Há um problema conhecido em que esse alerta continua sendo acionado mesmo depois que a conexão com falha é restaurada.

Alternativa:

Siga estas etapas para verificar se as conexões entre os nós estão íntegras e silencie o alerta para os nós:

Na página de análise do Grafana, execute a consulta storage_node_peer_connections{job="file-observability-backend-target.file-system"}. A consulta retorna uma métrica para cada conexão entre nós de armazenamento no cluster. Se alguma conexão estiver informando uma métrica storage_node_peer_connections de 0, anote os rótulos source_node, destination_ip e storage_cluster_name da métrica.
Para cada métrica storage_node_peer_connections que retorna 0, execute os seguintes comandos:
1. Estabeleça uma conexão SSH com o cluster de armazenamento ONTAP usando o rótulo storage_cluster_name.
2. Execute o comando a seguir no cluster ONTAP usando os valores dos rótulos source_node e destination_ip:
```
ping -node <node-name> -destination <destination-ip> -verbose -show-detail
```
Se o comando ping falhar, encaminhe o problema para a equipe de engenharia de bloqueio de arquivos. Se o comando ping for bem-sucedido, isso confirma que as conexões de nó estão íntegras e o alerta está sendo acionado erroneamente.
1. Crie um silêncio no AlertManager para silenciar o alerta file_block_storage_node_peer_connection_unhealthy com os rótulos source_node e destination_ip definidos como o nó de origem e o IP de destino da métrica.
Depois que os silenciamentos forem criados para todos os nós íntegros, navegue até o Grafana para verificar se os alertas pararam de ser acionados.

O alerta "file_block_nodes_not_reachable" é acionado depois que a conexão é restaurada

Versões: 1.14.3

Sintomas: em alguns ambientes, o alerta file_block_nodes_not_reachable é acionado, indicando que uma ou mais conexões dos serviços IPsec nos nós do Kubernetes com o ONTAP estão falhando. O controlador file-observability usa um coletor de métricas personalizadas para rastrear a integridade dessas conexões. Há um problema conhecido em que esse alerta continua sendo acionado mesmo depois que a conexão com falha é restaurada.

Alternativa:

Siga estas etapas para verificar se as conexões nos nós estão íntegras e silencie o alerta para os nós:

Na página de análise do Grafana, execute a consulta fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}. A consulta retorna uma métrica para cada nó no cluster. Se algum nó estiver informando uma métrica fb_all_nodes_reachable de 0, anote o nome do nó.
Para cada nó com métricas fb_all_nodes_reachable que retornam 0, execute os seguintes comandos:
1. Estabeleça uma conexão SSH com o nó afetado.
2. Execute este comando:
```
journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
```
  O comando vai tentar fazer ping no ONTAP usando todas as conexões IPsec. Se algum ping no comando falhar, encaminhe o problema para a equipe de engenharia de bloqueio de arquivos. Se os comandos de ping forem bem-sucedidos, isso confirma que as conexões de nó estão íntegras e que o alerta está sendo acionado erroneamente.
3. Se todos os pings no comando forem bem-sucedidos, confirmamos que as conexões no nó estão íntegras e que o alerta está sendo disparado erroneamente. Crie um silêncio no AlertManager para silenciar o alerta file_block_nodes_not_reachable com o rótulo node_name definido como o nome do nó.
Depois que os silenciamentos forem criados para todos os nós íntegros, navegue até o Grafana para verificar se os alertas pararam de ser acionados.

`file_block_storage_high_node_total_latency` alertas são acionados durante cargas de trabalho pesadas

Versões: 1.14.3

Sintomas: o alerta file_block_storage_high_node_total_latency pode ser acionado em determinados ambientes devido a cargas de trabalho pesadas em nós de armazenamento. Esse alerta vai persistir até que essas cargas de trabalho sejam totalmente processadas. Mesmo quando o desempenho de leitura e gravação em volumes é rápido, os nós de armazenamento ainda podem relatar alta latência para operações de bloco específicas.

Alternativa:

Para verificar latências de volume normais e silenciar o alerta de latência do nó de armazenamento, siga estas etapas:

Verifique os alertas de latência de volume:
1. No Grafana, confirme se os alertas file_block_storage_high_volume_write_latency e file_block_storage_high_volume_read_latency não estão sendo acionados e estão informando tempos de latência ideais para os volumes.
Encaminhe se a latência do volume for alta:
1. Se os alertas de gravação ou leitura de volume forem acionados, isso indica alta latência em todo o sistema de armazenamento. Encaminhe esse problema para a equipe de engenharia de bloqueio de arquivos.
Silenciar o alerta de latência do nó (se os volumes estiverem íntegros):
1. Se os alertas de gravação e leitura de volume estiverem íntegros, o alerta de latência do nó provavelmente será um falso positivo.
2. Crie um período de silêncio no AlertManager para o alerta file_block_storage_high_node_total_latency.
3. Depois de criar o silêncio, navegue até o Grafana para confirmar que o alerta parou de ser acionado.

Upgrade de nó bloqueado

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomas: esse bloqueio ocorre quando um LUN (número de unidade lógica) se torna somente leitura, geralmente devido a problemas com snapshots. Quando isso acontece, o nó é isolado para mover o pod afetado para um nó diferente. Como o processo de upgrade de nós tem uma pré-verificação para garantir que os nós não estejam isolados, esse estado impede que o upgrade prossiga.

Solução alternativa: desative manualmente o subcomponente file-read-only-lun-cleanup antes de iniciar o processo de upgrade:

Identifique cada organização afetada.

Aplique um SubcomponentOverride para cada organização no ambiente.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: file-read-only-lun-cleanup
  namespace: ORG_NAMESPACE
spec:
  subComponentRef: "file-read-only-lun-cleanup"
  disable: true

Verifique se nenhum dos nós nas organizações afetadas está isolado:

Liste os nós na organização:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

O resultado será assim:

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

Anote os nomes dos nós com o status SchedulingDisabled. Para este exemplo de saída, o nó isolado é admin-node0-zone1.

Remova o isolamento dos nós que retornaram o status SchedulingDisabled da etapa anterior:
```
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
```

Verifique se todos os nós estão prontos:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

O resultado será assim:

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

O alerta `file_block_zombie_luns_present` é acionado depois que os erros de multipath são resolvidos

Versões: 1.14.3 e mais recentes

Sintomas: o alerta file_block_zombie_luns_present pode ser acionado em determinados ambientes porque o controlador file-observability não consegue analisar a saída do comando multipath -ll. Essa situação resulta em um disparo constante do alerta de LUNs zumbis, mesmo quando o serviço multipath está íntegro em todos os nós.

Alternativa:

Para verificar se os serviços de multipath estão funcionando corretamente nos nós em questão, siga estas etapas:

Na página de análise do Grafana, execute a consulta zombie_lun_exists{job="file-observability-backend-target.file-system"}. A consulta retorna uma métrica para cada nó no cluster. Se algum nó informar uma métrica zombie_lun_exists de 1, anote o nome do nó.
Para cada nó com métricas zombie_lun_exists que retornam 1, execute os seguintes comandos:
1. Estabeleça uma conexão SSH com o nó afetado.
2. Execute este comando:
```
multipath -ll
```
  O comando retorna informações sobre todos os dispositivos de bloco gerenciados pelo serviço multipath. Verifique se nenhum dos dispositivos de transferência por blocos contém a string failed undef unknown ou failed faulty running nos status.
3. Se algum dispositivo tiver o status failed faulty running, siga o runbook FILE-R0020 para resolver as LUNs zumbis.
4. Se algum dispositivo tiver o status failed undef unknown, siga o runbook FILE-R0021 para resolver os LUNs superzumbis.
Silencie os alertas de LUNs zumbis se os nós estiverem íntegros:
1. Se nenhum dispositivo de bloco inválido for encontrado em nenhum dos nós, o alerta de LUN zumbi será um falso positivo.
2. Crie um período de silêncio no AlertManager para o alerta file_block_zombie_luns_present.
3. Depois de criar o período de silêncio, navegue até o ServiceNow para confirmar que o alerta parou de ser acionado.

Não é possível excluir um bucket vazio do console

Versões: 1.14.4 e mais recentes

Sintomas: no console do GDC, não é possível excluir um bucket vazio. O bucket pode ter marcadores de exclusão e outras versões de objetos quando o controle de versões de objetos está ativado com políticas de retenção. Você pode receber um erro como este:

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

Solução alternativa: use o comando gdcloud storage rm -a para excluir objetos, incluindo marcadores de exclusão, e tornar o bucket excluível.

Registro de artefatos do sistema

Os jobs de replicação do Harbor estão travando

Versões: 1.14.3

Sintomas:os jobs de replicação de artefatos do Harbor ficam presos. Esse problema impede a distribuição de artefatos para a organização e a criação de novas organizações.

Solução alternativa:para minimizar esse problema, siga as etapas no runbook SAR-R1010.

O status de erro temporário não foi limpo ao reconciliar o recurso personalizado da conta de robô do Harbor.

Versões: 1.14.3

Sintomas:um alerta CustomResourceErrorStatusAlert rotulado com kind=HarborRobotAccount e code=SAR2002 está sendo disparado erroneamente. Por exemplo, o alerta falso tem o campo message definido como "Error getting robot: failed to list robots: 503 Service Unavailable".

Solução alternativa:peça ao operador de infraestrutura (IO) para verificar se o alerta é um problema real ou um alarme falso e silencie o alerta se for um alarme falso, de acordo com as instruções a seguir.

Quando um alerta for acionado, siga o runbook SAR-E2002 para identificar e resolver a causa dele.

Devido a esse problema conhecido, mesmo que o runbook resolva a causa subjacente, o alerta pode continuar sendo acionado erroneamente. Continue verificando o status de erro do objeto de recurso personalizado (CR) HarborRobotAccount (HRD) de destino que está recebendo o alerta:

Defina as variáveis de ambiente necessárias:
```
export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE
```
Substitua:
- KUBECONFIG: o caminho para o arquivo kubeconfig.
- HRD_NAME: o nome da CR HarborRobotAccount de destino.
- HRD_NAMESPACE: o namespace que contém a CR HarborRobotAccount de destino.

Verifique o status de erro do CR HarborRobotAccount de destino:

kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'

Se o valor lastUpdateTime indicar que o campo errorStatus foi atualizado há mais de 30 minutos, o alerta será um alarme falso. Para reduzir o alarme falso, silencie o alerta na instância isolada do GDC seguindo o runbook MON-R2009.

Alarme falso para o alerta SAR-R0003

Versões: 1.14.3 e mais recentes

Sintomas:um alerta com código SAR-R0003, OC SAR e gravidade critical está sendo acionado erroneamente.

Solução alternativa:siga o manual de procedimentos MON-R2009 para silenciar o alerta.

Sistema de emissão de tíquetes

O MID Server do ServiceNow não inicia corretamente

Versões: 1.14.3

Corrigido: 1.14.4

Sintomas: o servidor MID do ServiceNow, que se integra ao Splunk, não se registra no ServiceNow na inicialização devido a uma incompatibilidade de versão.

Alternativa:

Pause o subcomponente ts-mid-server.

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

Substitua a string de versão do servidor MID.

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

Fazer upgrade

A anotação do cluster de serviço compartilhado não é atualizada após um upgrade bem-sucedido do cluster

Versões: 1.14.4

Sintomas:os CRs de perímetro e de clusters de serviço compartilhado para clusters.baremetal.cluster.gke.io refletem a versão correta do GKE após o upgrade. Os CRs clusters.cluster.gdc.goog ainda mostram a versão anterior do GKE.

Solução alternativa:atualize a anotação upgrade.gdc.goog/version em clusters.baremetal.cluster.gke.io para o novo nome UserClusterMetadata correspondente à versão atualizada do GKE.

O upgrade do nó de administrador da organização está travado

Versões: 1.14.6

Corrigido: 1.14.7

Sintomas:o processo de upgrade de nós para o plano de controle de administrador da organização gdchservices está travado. O upgrade do nó falha porque não é possível estabelecer uma conexão SSH com ele, resultando em um erro Connection timed out.

O upgrade do complemento está travado

Versões: 1.14.6

Corrigido: 1.14.7

Sintomas:o upgrade do complemento para o cluster de administrador raiz fica travado durante o upgrade de qualquer versão 1.14.x anterior para a 1.14.6. Uma mensagem de status pode indicar que o upgrade excedeu o limite de tempo esperado:

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

Solução alternativa: atualize manualmente o spec.addOnSetTemplateRef do recurso addonset do administrador raiz para apontar para o modelo correto da nova versão.

Falhas no relatório de suporte

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Corrigido: 1.14.7

Sintomas:o comando gdcloud resource-support get-report falha quando é executado para um cluster de usuário devido a um problema de permissões.

A inicialização da VM pode ficar travada após a conclusão do upgrade do nó do SO

Versões: 1.14.6

Sintomas: durante o upgrade da versão 1.14.3 para a 1.14.6, as máquinas virtuais no perímetro ou nos clusters de serviço compartilhado não conseguem inicializar e ficam inacessíveis após um upgrade do SO.

Por exemplo, o comando a seguir pode confirmar o problema:

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

A saída do registro do console da VM mostra uma mensagem de falha do kernel semelhante a esta:

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

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

Configure as variáveis de ambiente a seguir:

export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
export VM_NAMESPACE=VM_NAMESPACE
export VM_NAME=FAILED_VM_NAME

Pare a VM com falha:

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
    $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

Abra o editor para remover o disco de inicialização da VM com falha:

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME

Substitua o disco de inicialização por um nome de marcador de posição na especificação da VM:

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      # This is a random placeholder name you put here. Doesn't need to exist
      name: VM_DISK_PLACEHOLDER_NAME

Crie um secret de script de inicialização:

cat <<'EOF' > script
#!/bin/bash
username="newuser"
password="Lime+blaze8legend"
sudo useradd -m -s /bin/bash "$username"
echo "$username:$password" | sudo chpasswd
sudo usermod -aG sudo "$username"
EOF

kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script

Crie uma VM auxiliar:

Recebe a imagem da VM para o disco de inicialização da VM. A imagem não pode ter a mesma família de SO do disco de inicialização do nó da VM com problema. Use grep para encontrar a imagem do Ubuntu:

# find the latest ubuntu-20.04 OS version
UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')

Crie o disco de inicialização e a VM. Crie um novo disco de inicialização e uma nova VM com um disco secundário anexado e um script de inicialização para acesso ao console:

kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: HELPER_VM_BOOT_DISK_NAME
spec:
  source:
    image:
      name: UBUNTU_OS_VERSION
      namespace: vm-system
  size: 20Gi
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: HELPER_VM_NAME
spec:
  compute:
    virtualMachineType: n3-standard-2-gdc
  disks:
  - virtualMachineDiskRef:
      name: HELPER_VM_NAME-disk
    boot: true
    autoDelete: true
  - virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK
    autoDelete: false
  startupScripts:
  - scriptSecretRef:
      name: configure-password
    name: configure-password
EOF

Verifique se a VM auxiliar está em execução:

kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME

Console para a VM auxiliar e gere novamente o initramfs:

Console para a VM auxiliar:

kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG

Use as seguintes credenciais:

username="newuser"

password="Lime+blaze8legend"

Ative as partições do disco anexado:

sudo mkdir /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/

sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
sudo mount -t proc procfs /mnt/kernelpanic/proc/
sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/

Estabeleça uma conexão chroot com o ponto de montagem e gere novamente o initramfs:
```
sudo chroot /mnt/kernelpanic/
dracut --regenerate-all --force
```

Verifique se o novo initramfs para a nova versão do kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 foi gerado:

ls /boot/initramfs-* -l

A saída será assim:

-rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
-rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
-rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img

Pare a VM auxiliar:

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

Desconecte o disco da VM auxiliar:

Abra a especificação da VM auxiliar em um editor:

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME

Remova o seguinte código do arquivo YAML:

- virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

Reanexe o disco de inicialização à VM com falha:

Abra a especificação da VM com falha em um editor:

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME

Atualize a especificação da seguinte maneira:

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK

Inicie a VM com falha:

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'

Verifique se o upgrade foi corrigido:

Verifique se o recurso personalizado Node dessa VM mostra Ready e usa a versão mais recente do kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64:

kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide

O resultado será assim:

NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0

Verifique a versão do kernel depois de estabelecer uma conexão SSH com a VM:
```
uname -a
```
A saída precisa mostrar a nova versão do kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.

O ingester permanece não íntegro e não é esquecido automaticamente após o upgrade

Versões: 1.14.x

Sintomas:o subcomponente log-infra não está em um estado íntegro após o upgrade. Para verificar, execute: none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Para verificar a integridade de um subcomponente, use o kubeconfig do cluster principal para KUBECONFIG e o namespace do cluster atual para CLUSTER_NAMESPACE. O comando vai retornar o STATUS do subcomponente. Se o STATUS não for ReconciliationCompleted, isso indica que o subcomponente não está íntegro nesse cluster.

Alguns pods do Loki no cluster não estão íntegros. Para listar todos os pods do Loki, execute: none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Esse comando mostra todos os pods do Loki, incluindo as colunas STATUS e READY. Um pod é considerado não íntegro se o STATUS não for Running ou se alguns dos contêineres não estiverem prontos. A coluna READY, formatada como a/b, indica o número de contêineres prontos a do total b. Um pod está íntegro quando a e b são iguais.

Verifique os registros de pods do Loki não íntegros: none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

Exemplo de registros de saída de pods não íntegros:

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

Solução alternativa:para excluir um ingeridor não íntegro do anel do Loki, consulte o runbook AL-R0031.

Vertex AI

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

Versões: 1.14.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.14.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: SHARED_SERVICE_CLUSTER_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

Substitua SHARED_SERVICE_CLUSTER_NAMESPACE pelo namespace do cluster de serviço compartilhado.

Aplique o recurso personalizado SubcomponentOverride ao cluster de administrador da organização:
```
kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
```
Substitua ORG_MGMT_KUBECONFIG pelo caminho para o arquivo kubeconfig de gerenciamento no cluster de administrador da organização.

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

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

Sintomas:durante os upgrades, o cluster de banco de dados é recriado, o que faz com que o segredo do ODS secret-store no cluster de serviço compartilhado fique desatualizado e fora de sincronia. Por isso, o pod e o serviço de front-end de tradução ou OCR não conseguem ser inicializados.

Alternativa:

Exclua o secret no cluster de serviço compartilhado:

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

Substitua SHARED_SERVICE_CLUSTER_KUBECONFIG pelo caminho para o arquivo kubeconfig no cluster de serviço compartilhado.

Se o serviço problemático for o Translation, substitua VAI_API_NAMESPACE por "g-vai-translation-sie". Se o serviço problemático for o OCR, substitua VAI_API_NAMESPACE por "g-vai-ocr-sie".

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

Vertex AI para Pesquisa

Componentes de pesquisa travados no estado de reconciliação

Versões: 1.14.6

Sintomas:os subcomponentes vaisearch-conversation e vaisearch-frontend ficam presos em um estado Reconciling se nenhum recurso personalizado SearchConfig for criado na organização.

Solução alternativa:o problema pode ser ignorado. Após a criação do recurso personalizado SearchConfig, os subcomponentes precisam concluir a reconciliação.

Servidor

A rotação de credenciais do BIOS travou no estágio "reset-requested"

Versões: 1.14.4

Sintomas:a rotação de credenciais do BIOS fica travada no estado "redefinição solicitada". Para verificar isso, confira a anotação gdch.cluster.gke.io/rotation-status do secret bios-credentials do servidor:

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

Substitua SERVER_NAME pelo nome do servidor. A saída do comando será "reset-requested" se a rotação estiver travada.

Solução alternativa:para concluir a rotação de credenciais da BIOS, siga o runbook SERV-R0018.

Não é possível provisionar servidores instalados anteriormente

Versões: 1.14.6

Sintomas:os servidores não são provisionados após serem desprovisionados e reprovisionados, especificamente relacionados a problemas com o gerenciamento de chaves iLO (Integrated Lights-Out) e HSM (módulo de segurança de hardware). Os servidores, que antes faziam parte de uma organização desativada, encontram erros durante o provisionamento de imagens, indicando a incapacidade de encontrar um dispositivo adequado, geralmente devido a discos bloqueados de chaves antigas ou excluídas. Você pode encontrar um erro como este:

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

Solução alternativa:exclua e reinstale os servidores afetados para que eles entrem em um estado provisionado. Para mais informações, consulte os runbooks SERV-R0020 e SERV-R0021.

Máquinas virtuais

Falhas na importação de imagens

Versões: 1.14.4. 1.14.5

Corrigido: 1.14.6

Sintomas:uma importação de imagem usando o comando gdcloud compute images import falha com um erro Unauthorized devido a tempos limite de sessão.

Solução alternativa: use a API KRM para a importação da sua própria imagem em vez da CLI gdcloud.

A importação de imagens do KRM demora muito

Versões: 1.14.6 e mais recentes

Sintomas:uma importação de imagem usando a API KRM leva muito tempo para ser concluída. O recurso VirtualMachineImageImport permanece em um estado TranslationJobInProgress por um longo período, indicando que a fase de tradução não está sendo concluída conforme o esperado. O pod image-translation entra no estado CrashLoopBackOff.

Alternativa:

Tente importar novamente criando um novo recurso VirtualMachineImageImport com outro nome.
Monitore o status VirtualMachineImageImport verificando periodicamente o recurso até que o status mude para WaitingForTranslationJob. Para mais informações, consulte o runbook VMM R0007.

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

Backup e restauração

A edição do plano de restauração de backup do cluster está corrompida

Tamanho do disco de origem inválido

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

Os SLOs de backup e restauração não são aplicados

As políticas de retenção não são aplicadas aos backups importados

Falha no backup parcial da VM

Limpar recursos de backup órfãos após a exclusão de um cluster de usuário ou de serviço

A exclusão de VirtualMachineRestore não é compatível com a CLI ou UI.

O pod do plano de controle de backup falha devido à falta de memória

A exclusão do cluster de usuário está paralisada

A restauração está travada devido a uma reivindicação de volume permanente pendente

Gerenciamento de clusters

O subcomponente kub-gpu-controller não faz reconciliação

Não é possível remover um pool de nós de um cluster padrão

Cluster preso no estado de exclusão

Serviço de banco de dados

Clonagem de banco de dados do AlloyDB Omni travada

DNS

GlobalCustomerRootDNSServerNotReachable disparando um alerta falso

Armazenamento de arquivos/blocos

Não é possível ativar o volume de compartilhamento de arquivos na VM

Firewall

A regra da política de segurança está ausente para o endereço no CR da sub-rede

Os firewalls do GDC negam o tráfego para o OIR nos planos de gerenciamento e de dados.

O firewall do GDC nega o tráfego entre zonas e organizações.

O firewall não oferece suporte a AttachmentGroup cujo identificador é igual ao nome da organização

Porto

O secret da CLI do Harbor fica inválido após o backup e a restauração

O trabalho de backup e restauração do Harbor disputa permissão

O tamanho do backup do Harbor mostra valores zero

Erro de permissão nos recursos de backup na página do console do Harbor Registry

A página de rotação de senha do banco de dados está travada

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

Os HSMs falham com o erro ValidateNetworkConfig após a inicialização

INTEGRIDADE

Alertas de SLO de alarme falso

Configurações inválidas de SLO com base em indicadores

Gerenciamento de identidade e acesso

Falha na criação da vinculação de papel do IAM

Falha ao criar a vinculação de papel do IAM para contas de serviço do projeto

Atrasos na criação de projetos com papéis predefinidos

O console do GDC não pode criar a primeira vinculação de função

Os AOs não podem conceder a si mesmos acesso a papéis no cluster de infraestrutura.

O token da conta de serviço atual fica inválido

Infraestrutura como código (IAC)

Falha na reconciliação de subcomponentes devido à falta de namespace

A coleta de métricas do ConfigSync do IAC falha

Falha do RootSync do IAC

Inventário

A auditoria de inventário não é reconciliada

Sistema de gerenciamento de chaves

O KMS configurado para usar uma chave raiz do CTM não faz failover quando um HSM está indisponível

Balanceadores de carga

A criação do balanceador de carga global falha devido ao esgotamento do CIDR da sub-rede

A modificação dos recursos do balanceador de carga não reconcilia os serviços

Nomes de zonas incorretos não são rejeitados

Erro de webhook do balanceador de carga global e por zona

Logging

O pod do Loki falha ou é OOMKilled durante a repetição do WAL

Verificar a solução alternativa

Limpar a substituição e o proxy de objeto

Monitoramento

Os webhooks do AlertManager não enviam alertas para alguns clusters

Os incidentes do ServiceNow são duplicados ocasionalmente

As métricas de infraestrutura podem ser sensíveis demais

As métricas de conciliação podem ser sensíveis demais

Dois alertas falsos estão abertos no cluster de administrador raiz

O gerenciador do controlador de administrador raiz mostra uma alta taxa de erros

Os painéis do KUB não mostram dados em nenhum dos painéis de PA

Permissões mal configuradas para a função observability-admin-debugger

Função do depurador do Grafana ausente

Métricas e registros entre zonas não ficam visíveis após a adição de uma nova zona

O finalizador MonitoringTarget bloqueia a exclusão do namespace

Exclusão de projeto travada devido a finalizadores pendentes do painel e da fonte de dados

As métricas do KSM não estão visíveis

O pipeline de métricas do sistema está inativo

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

O subcomponente `kub-gpu-controller` não faz reconciliação

Os HSMs falham com o erro `ValidateNetworkConfig` após a inicialização

O finalizador `MonitoringTarget` bloqueia a exclusão do namespace

Ajustar a ordem das zonas `MultiZoneNetworkConfig` causa falha na substituição da configuração

Não é possível excluir buckets criados com o comando `gdcloud config set zone`

Os pods não são ativados devido a um erro `mkfs.ext4` do Trident

`file_block_iscsi_sessions_unhealthy alert` informa um falso positivo

O alerta `file_block_storage_disk_failure` é acionado para discos sobressalentes

`file_block_storage_high_node_total_latency` alertas são acionados durante cargas de trabalho pesadas

O alerta `file_block_zombie_luns_present` é acionado depois que os erros de multipath são resolvidos

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

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