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

Cópia de segurança e restauro

O plano de restauro da cópia de segurança do cluster de edição está danificado

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

Sintomas:

Não é possível editar o recurso personalizado RestorePlan através da consola do GDC.

Solução alternativa:

Crie um novo plano de restauro e elimine o antigo ou edite o plano de restauro através da CLI kubectl.

Tamanho do disco de origem inválido

Versões: 1.14.4, 1.14.5

Sintomas: a IU apresenta incorretamente um tamanho do disco de 0 MB e a respetiva hora de criação como "Desconhecida" devido a uma alteração do modelo de dados de back-end após a migração para a arquitetura da organização v2.

Solução alternativa: não existe um método alternativo para ver estas informações através da IU.

Os pods do agente e do plano de controlo 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 controlo podem ser reiniciados se ficarem sem memória.

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

Os SLOs de cópia de segurança e restauro não são aplicados

Versões: 1.14.3, 1.14.4

Sintomas: as métricas e os alertas do objetivo ao nível do serviço (SLO) do GDC não estão configurados por predefinição, uma vez que a definição de recursos personalizada necessária não está instalada. Estes alertas são usados no Grafana.

Soluções alternativas: para ativar os SLOs para a cópia de segurança e o restauro no GDC, siga o manual de procedimentos BACK-T0001.

As políticas de retenção não são aplicadas a cópias de segurança importadas

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

Sintomas: anexar um repositório de cópias de segurança ao cluster sincroniza todos os metadados de cópias de segurança e restauro, e trata os repositórios como cópias de segurança importadas. Estas cópias de segurança importadas são ignoradas incorretamente durante a conciliação, o que significa que as políticas de retenção são ignoradas e as cópias de segurança são retidas indefinidamente.

Solução: as cópias de segurança importadas são etiquetadas com backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME. Para permitir a conciliação normal e a aplicação de políticas de retenção, remova a etiqueta das cópias de segurança através dos seguintes comandos kubectl:

  1. Defina as variáveis de ambiente necessárias:

    export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE

    Substitua o seguinte:

    • KUBECONFIG: o caminho para o ficheiro kubeconfig.
    • BACKUP_REPOSITORY_NAME: o nome do repositório de cópias de segurança.
    • NAMESPACE: o espaço de nomes que contém o plano de cópia de segurança.

  2. Apresente todas as cópias de segurança importadas:

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

  3. Remova as etiquetas conforme necessário:

    • Remova as etiquetas de todas as cópias de segurança:

      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 as etiquetas de uma única cópia de segurança:

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

Falha na cópia de segurança parcial da VM

Versões: 1.14.3, 1.14.4

Sintomas: se uma VM entre várias VMs não conseguir fazer uma cópia de segurança, a cópia de segurança de todas as VMs é marcada como falhada.

Solução alternativa: limite o número de VMs por plano de cópia de segurança.

Limpe os recursos de cópia de segurança órfãos após a eliminação do utilizador ou do cluster de serviços

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

Sintomas: quando um cluster de utilizador ou de serviço é eliminado, os recursos do agente de cópia de segurança associados (como StatefulSet, pods, segredo, etc.) criados na infraestrutura da organização e no cluster de gestão não são limpos automaticamente. Isto pode deixar recursos órfãos e, se o cluster for criado novamente com o mesmo nome, o pod do agente de cópia de segurança não funciona.

Solução alternativa: os recursos órfãos existem num espaço de nomes dedicado no cluster de infraestrutura da organização. Para os limpar, tem de eliminar este espaço de nomes.

  1. Defina os ficheiros kubeconfig para a infraestrutura da organização e os clusters de gestão.

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

  2. Identifique o espaço de nomes dos recursos órfãos. O espaço de nomes segue o padrão gpc-backup-<cluster-name>-system. Por exemplo:

    • gpc-backup-user-vm-1-cluster-system
    • gpc-backup-user-vm-2-cluster-system
    • gpc-backup-g-org-1-shared-service-cluster-system

  3. Elimine o espaço de nomes. Esta ação elimina todos os recursos no respetivo interior, incluindo o StatefulSet e o pod do agente de cópia de segurança na infraestrutura e o segredo no cluster de gestão.

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

  4. Para confirmar que a limpeza foi bem-sucedida, execute novamente o comando get all.

    # 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 deve falhar porque o espaço de nomes já não existe. Deve ver um erro como Error from server (NotFound): namespaces "<namespace-name>" not found.

A eliminação de VirtualMachineRestore não é suportada através da CLI nem da IU

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

Sintomas: o controlador VirtualMachineRestore não limpa automaticamente os recursos subjacentes (VolumeRestore, Restore) após a eliminação de um recurso VirtualMachineRestore. Isto requer a realização de uma limpeza manual. Isto aplica-se quer a eliminação seja feita através de kubectl delete ou da IU.

Solução alternativa: a solução alternativa envolve a eliminação manual dos recursos dependentes pela ordem correta e, em seguida, a remoção do finalizador do recurso VirtualMachineRestore.

  1. Defina o ficheiro kubeconfig para apontar para o cluster de gestão.

    export MGMT_KUBECONFIG=<path_to_management_kubeconfig>

  2. Identifique o VirtualMachineRestore a eliminar e o respetivo espaço de nomes.

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

  3. Encontre e elimine os recursos VolumeRestore associados. Estas são criadas com uma etiqueta que as associa 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:?}"

  4. Encontre e elimine os recursos Restore associados. Estas são criadas com uma etiqueta que as associa 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:?}"

  5. Agora, execute o comando kubectl delete, se ainda não o tiver feito, e remova o finalizador do recurso VirtualMachineRestore. Este é o passo final que permite ao coletor de lixo do Kubernetes eliminar o recurso.

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

  6. Valide a eliminação.

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

    O comando deve devolver um erro NotFound, confirmando que o recurso foi eliminado.

O pod do plano de controlo da cópia de segurança falha devido a memória insuficiente

Versões: 1.14.4 e posteriores

Sintomas: o agrupamento gpcbackup-controlplane-controller no espaço de nomes do sistema gpc-backup do cluster de infraestrutura da organização apresenta o estado CrashLoopBackOff. Quando este erro ocorre, as operações de cópia de segurança e restauro falham, deixam de responder ou não funcionam como esperado.

Solução alternativa: aumente os limites de memória da implementação gpcbackup-controlplane-controller seguindo o procedimento BACK-R0005. Este método aplica um SubcomponentOverride para ajustar a CPU, os pedidos de memória e os limites.

A eliminação do cluster de utilizadores está bloqueada

Versões: 1.14.7 e posteriores

Sintomas: os clusters estão bloqueados no estado de eliminação devido a problemas de finalização.

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

O restauro está bloqueado devido a uma reivindicação de volume persistente pendente

Versões: 1.14.3 e posteriores

Sintomas: por vezes, os controladores de reivindicação de volume persistente (PVC) não conseguem comunicar com os agentes de cópia de segurança no cluster de infraestrutura da organização. Embora este problema não afete a funcionalidade de cópia de segurança, pode fazer com que uma operação de restauro de volume fique bloqueada num estado Pending e, eventualmente, expire. Este problema afeta as operações de restauro que envolvem um restauro de volume, como a funcionalidade de restauro do serviço de base de dados para clonagem e um restauro da carga de trabalho do utilizador.

Se este problema surgir, as operações de restauro subsequentes no cluster afetado falham até reiniciar manualmente o agente de cópia de segurança correspondente.

Para confirmar que o seu problema de restauro está relacionado com este problema específico, tem de investigar os registos do agente de cópia de segurança:

  1. Siga as instruções em IAM-R0005 para obter a função de depurador BACK necessária (back-cluster-debugger) através da aplicação do recurso ExpirationClusterRoleBinding.

  2. Siga as instruções do artigo IAM-R0004 para gerar o ficheiro kubeconfig para o cluster de infraestrutura da organização. Todos os agentes de cópia de segurança são executados no cluster de infraestrutura da organização.

  3. Identifique o agente de cópia de segurança que está a facilitar o restauro:

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

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

    O resultado é semelhante ao seguinte:

    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 o resultado e determine o agente de cópia de segurança que corresponde ao seu restauro. Por exemplo, se o espaço de nomes do conjunto com estado afetado da saída for gpc-backup-user-vm-1-cluster-system, o agente de cópia de segurança é gpcbackup-agent-user-vm-1.

  4. Pesquise a mensagem de erro nos registos do conjunto com estado para confirmar o problema:

    kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"

    Substitua o seguinte:

    • ORG_INFRA_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de infraestrutura da organização.

    • BACKUP_AGENT: o agente alternativo que identificou no passo anterior.

    • NAMESPACE: o espaço de nomes que identificou no passo anterior.

    Se existirem registos correspondentes, está a ter este problema conhecido.

Solução alternativa: para contornar o problema, conclua os seguintes passos:

  1. Reinicie o agente de cópia de segurança:

    kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE

    Substitua o seguinte:

    • ORG_INFRA_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de infraestrutura da organização.

    • BACKUP_AGENT: o agente de cópia de segurança que identificou ao confirmar o problema.

    • NAMESPACE: o espaço de nomes que identificou quando confirmou o problema.

    O resultado é semelhante ao seguinte:

    statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted

  2. Aguarde até 20 minutos para que as operações pendentes sejam retomadas automaticamente.

Pode fazer outra restauração para o mesmo cluster de destino após a conclusão do reinício do agente de cópia de segurança. Depois de concluir esta solução alternativa, não existem efeitos secundários. Só é necessário concluir esta solução alternativa uma vez por cluster afetado.

Gestão de clusters

O subcomponente kub-gpu-controller não é reconciliado

Versões: 1.14.3

Sintomas: o subcomponente g-gdchservices-shared-service-cluster/kub-gpu-controller na organização gdchservices não é reconciliado. É devolvido o seguinte resultado:

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

Esta falha impede o início das máquinas com GPU na organização gdchservices.

Contorno: atualize para a versão 1.14.4 ou superior para mitigar o problema.

Não é possível remover um conjunto de nós do 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 eliminados dentro do prazo esperado. Os clusters padrão estão em pré-visualização privada e podem não estar disponíveis para todos os clientes.

Solução alternativa: remova manualmente os node pools obsoletos.

O cluster está bloqueado no estado de eliminação

Versões: 1.14.6 e posteriores

Sintomas: quando elimina um cluster do Kubernetes, este pode ficar bloqueado num estado Deleting. Verifique o estado do cluster executando o seguinte comando:

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

O resultado é semelhante ao seguinte:

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

Também pode validar o problema verificando o estado do espaço de nomes do cluster:

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

O resultado é semelhante ao seguinte:

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 espaço de nomes do cluster está bloqueado no estado Terminating e as condições NamespaceContentRemaining e NamespaceFinalizersRemaining estão definidas como True.

Solução alternativa: para contornar o problema, conclua os seguintes passos:

  1. Aplique patches à 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'

  2. Corrija a 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 base de dados

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

Clone da base de dados do AlloyDB Omni bloqueado

Versões: 1.14.6 e anteriores

Corrigido: 1.14.7

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

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

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

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

Exemplos de resultados:

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

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

DNS

GlobalCustomerRootDNSServerNotReachable a acionar 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 de DNS DNS-A0021 é acionado, sugerindo GlobalCustomerRootDNSServerNotReachable. O CR de teste para global-customer-root-dns em org-mp não tem egress: true na especificação.

Solução alternativa:

  1. Defina o caminho KUBECONFIG para org-mgmt:

    export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG

  2. Pause a CR de teste de gestão de subcomponentes core-mz:

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

  3. Edite a CR de teste atual de org-mp:

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

  4. Atualize a especificação para incluir egress: True e aplique a alteração. Tenha em atenção que CLUSTER_NAME e GLOBAL_CUSTOMER_ROOT_IP permanecem inalterados.

    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

Esta solução alternativa corrige o verificador e quaisquer alertas falsos diminuem em 15 minutos.

Armazenamento de ficheiros/blocos

Não é possível montar o volume de partilha de ficheiros na VM

Versões: 1.14.6, 1.14.7

Sintomas: ocorre uma falha na atualização das autorizações de armazenamento de rede quando é adicionado um novo nó a um cluster, o que pode fazer com que os pedidos de montagem de NFS sejam recusados. Pode ver um erro access denied by server ao montar uma partilha de ficheiros NFS.

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

Firewall

Falta a regra da política de segurança para o endereço no CR da sub-rede

Versões: 1.14.3

Sintomas: uma organização está inacessível devido ao grupo de endereços da firewall que falta no recurso personalizado da sub-rede global criado pelo cliente no servidor da API global da organização.

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

As firewalls do GDC negam o tráfego em direção ao OIR para o plano de gestão e de dados

Versões: 1.14.3, 1.14.4

Sintomas: após a implementação do recurso personalizado OCITTopology, a conetividade entre o OIR e o plano de gestão e o plano de dados do GDC fica danificada.

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

As seguintes regras da 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 o seguinte:

  • OCIT_CIDR: os intervalos de endereços IP no campo ocitCIDR do questionário de informações do cliente (CIQ).
  • MGMT_CIDR: os intervalos de endereços IP no campo oobManagementCIDRs do questionário de informações do cliente (CIQ).
  • ZONE_INFRA_CIDR: os intervalos de endereços IP no campo zoneInfraCIDRs do questionário de informações do cliente (CIQ).

A firewall da GDC nega o tráfego entre zonas e entre organizações

Versões: 1.14.3, 1.14.4, 1.14.5

Sintomas: por predefinição, o tráfego entre zonas e entre organizações é bloqueado pelas firewalls.

Solução alternativa: siga os passos no runbook para adicionar manualmente regras de política de segurança para permitir o tráfego.

A firewall não suporta AttachmentGroup cujo identificador é igual ao nome da organização

Versões: 1.14.3 e posteriores

Sintomas: após a implementação de um AttachmentGroup, se o campo identifier nesse objeto AttachmentGroup for igual a orgName, a firewall não consegue analisar este objeto e as atualizações da configuração da firewall ficam bloqueadas. Segue-se um exemplo de um 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. Existem algumas opções para corrigir o AttachmentGroup de má qualidade.

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

  • Acrescentar 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

  • Anexe 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 torna-se inválido após a cópia de segurança e o restauro

Versões: 1.14.3

Sintomas: após uma cópia de segurança e um restauro do Harbor, os segredos da CLI tornam-se inválidos e têm de ser criados novamente.

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

  1. Inicie sessão no Harbor com uma conta de utilizador do IAP.
  2. Clique no seu nome de utilizador e selecione Perfil do utilizador.
  3. Clique em Mais.
  4. Crie outro segredo da CLI de forma automática ou manual.

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

A tarefa de cópia de segurança e restauro do Harbor compete pela autorização

Versões: 1.14.3, 1.14.4

Sintomas: quando existem várias instâncias do Harbor em diferentes projetos de utilizadores, as operações de cópia de segurança e restauro competem pelos controlos de acesso baseados em funções e registam uma elevada taxa de falhas.

Solução alternativa: para mitigar este problema, siga estes passos para criar manualmente uma associação de funções para cada espaço de nomes onde são criadas instâncias do Harbor:

  1. Defina as variáveis de ambiente necessárias:

    INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG

    Substitua o seguinte:

    • INFRA_CLUSTER_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de infraestrutura.
    • INSTANCE_NAMESPACE: o espaço de nomes onde as instâncias do Harbor do serviço Harbor gerido (MHS) são criadas.

  2. Crie a associação de funções 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 da cópia de segurança do Harbor mostra 0 valores

Versões: 1.14.3, 1.14.4

Sintomas: a medição do tamanho da cópia de segurança para cópias de segurança do Harbor não está implementada de momento. Na consola do GDC, os campos SizeBytes mostram um valor de 0 e a coluna Size mostra um valor de 0 MB. Esta configuração é o comportamento esperado por agora.

Erro de autorização nos recursos de cópia de segurança na página da consola do registo do Harbor

Versões: 1.14.3, 1.14.4

Sintomas: se não tiver a função de administrador da instância do Harbor, é apresentado um erro de autorização no recurso de cópia de segurança quando vê a página Harbor Container Registry na consola do GDC. Este erro é apresentado porque as informações de cópia de segurança foram adicionadas recentemente à página Harbor Container Registry, mas a autorização de leitura para o recurso de cópia de segurança não foi concedida a funções do IAM que não sejam o administrador da instância do Harbor.

Os outros elementos da consola GDC na página Harbor Container Registry continuam a funcionar como esperado. Para mais informações sobre as funções no GDC, consulte o artigo Definições de funções.

A rotação da palavra-passe da base de dados está bloqueada na página

Versões: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Sintomas: são apresentados erros relativos à autenticação de pedidos à base de dados, como failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), e existem muitos pedidos de rotação gerados automaticamente para um único segredo rotativo.

Solução alternativa: elimine pedidos de rotação não preparados adicionais para um segredo rotativo.

  1. Defina KUBECONFIG para o servidor da API mp.

  2. Exporte o espaço de nomes:

    NAMESPACE=haas-system

  3. Verifique se existem Secrets rotativos em haas-system que não estão prontos:

    kubectl get rotatablesecrets -n ${NAMESPACE?}

    O resultado pode ter o seguinte aspeto:

    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

  4. Exporte o nome do segredo rotativo, por exemplo: 

    ROTATABLE_SECRET=haasdb-pw-haas-alice

  5. Elimine pedidos de rotação adicionais que não estejam prontos:

    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 avaliação desativadas do HSM ainda são detetáveis

Versões: 1.14.3, 1.14.4, 1.14.5

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

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

Fuga de descritores de ficheiros do anfitrião do HSM

Versões: 1.14.x

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

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

sudo systemctl restart host-daemon

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

Os HSMs falham com o erro ValidateNetworkConfig após o arranque

Versões: 1.14.x

Sintomas: os recursos personalizados do HSM não entram num estado Ready e falham devido a um erro ValidateNetworkConfig. Este erro apresenta a seguinte mensagem: data0 interface MAC address {} is not active. Este erro ocorre se o sistema for reiniciado e for definida uma interface de dados principal diferente.

Solução alternativa: siga o manual de procedimentos HSM-R0059 e volte a aplicar a configuração de rede do HSM para a rede de dados. Este manual de procedimentos é seguro de seguir, mesmo que mais do que um HSM tenha este erro.

SAÚDE

Alertas de SLO de falsos alarmes

Versões: 1.14.3

Sintomas: um SLO successRange está a ser acionado incorretamente.

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

Para tal, quando um alerta é acionado, siga o manual de procedimentos correspondente para resolver a causa subjacente do alerta de objetivo ao nível do serviço (SLO).

  1. Caso 1: se o manual de procedimentos resolver o problema com êxito e o alerta deixar de ser acionado, o IO pode fechar o incidente associado.

  2. Caso dois: se o manual de procedimentos for concluído, mas o alerta continuar a ser acionado, indica um potencial falso alarme. Verifique se o SLO está danificado:

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

  3. Com base no resultado: se confirmar que o alerta é um falso alarme, o IO deve desativar o alerta na instância isolada do GDC; caso contrário, encaminhe o problema para o apoio técnico da nuvem.

  4. Em qualquer dos casos, é adequado que o IO encaminhe o problema para o apoio técnico do Google Cloud para verificar se o componente operacional está em bom estado.

Configurações de SLO baseadas em indicadores inválidas

Versões: 1.14.3, 1.14.4

Sintomas: um subconjunto de objetivos ao nível do serviço (SLOs) não preenche eventos bons, maus ou totais devido a uma configuração incorreta. Os SLOs em questão baseiam-se em indicadores do Prometheus e têm de ser configurados em conformidade.

Solução alternativa:

Versão 1.14.3: não existe solução alternativa. Consequentemente, os alertas de SLO não são acionados para os SLOs afetados.

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

Exemplo de uma configuração de indicador 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 que são corrigidos com esta definição é a seguinte:

  • 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 ficheiros:
    • 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

Gestão de identidade e de acesso

Falha na criação da associação de funções de IAM

Versões: 1.14.3

Sintomas: os nomes de associações de funções de IAM são gerados pelo sistema. Estes nomes têm um comprimento máximo de 63 carateres, no formato user-idp-prefix-rolename. Nos casos em que o nome gerado excede o limite de 63 carateres, não é possível criar associações de funções. Consequentemente, as autorizações definidas através de funções predefinidas ou personalizadas não são atribuídas aos utilizadores.

Solução alternativa: a criação da associação de funções pode ter êxito se o nome da função predefinida ou personalizada tiver poucos carateres, por exemplo, 4 a 5.

Falha ao criar a associação de funções de IAM para project-service-accounts

Versões: 1.14.3 1.14.4 1.14.5 1.14.6

Sintomas: uma conta de serviço do projeto (PSA) com a função organization-iam-admin não pode usar o comando gdcloud projects add-iam-policy-binding para atribuir-se outra função, como a função project-iam-admin. Esta deficiência impede que um PSA faça a gestão das suas próprias autorizações.

Solução alternativa: confirme se tem a função de organization-iam-admin. Em seguida, atribua-se a si mesmo a função project-iam-admin no espaço de nomes do projeto do PSA de destino e atribua ao PSA a função project-iam-admin. Esta configuração de autorizações permite que o PSA atribua autorizações adicionais a si próprio ou a outros PSAs.

Os novos projetos sofrem atrasos na criação de funções predefinidas

Versões: 1.14.3

Sintomas: quando é criado um novo projeto, faltam-lhe funções predefinidas, como project-bucket-object-admin.

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

A consola GDC não pode criar a primeira associação de funções

Versões: 1.14.4

Sintomas: quando cria a primeira vinculação de funções para uma nova identidade de serviço através da consola do GDC, a criação da vinculação de funções é comunicada como bem-sucedida, mas, na verdade, não funciona. Quaisquer ações adicionais na identidade do serviço falham e não têm efeito, incluindo a adição de associações de funções adicionais ou a eliminação de associações de funções.

Solução alternativa: use a CLI gcloud para criar a primeira associação de funções para uma identidade de serviço. Todas as ações futuras com a identidade de serviço realizadas através da consola do GDC funcionam corretamente após a primeira vinculação de funções ser anexada. Para mais informações, consulte o artigo Atribua uma associação de funções à identidade do serviço.

Os AOs não podem conceder a si próprios acesso a funções no cluster de infraestrutura

Versões: 1.14.3. 1.14.4

Corrigido: hotfix 21 da versão 1.14.3

Sintomas: os AOs não têm forma de conceder a si próprios nem a outros utilizadores acesso a quaisquer funções no cluster de infraestrutura.

Solução alternativa: os utilizadores da AO têm de contactar os IOs para obterem o acesso necessário. Os IOs podem usar o IAC para conceder aos utilizadores da AO o acesso necessário.

O símbolo da conta de serviço existente torna-se inválido

Versões: 1.14.3

Corrigido: hotfix 21 da versão 1.14.3

Sintomas: o token da conta de serviço existente emitido pelo cluster de utilizadores torna-se inválido devido à alteração do argumento service-account-issuer apiserver depois de o cluster estar em estado de execução após o arranque. Este problema faz com que o pod, por exemplo, o pod com um contentor sidecar istio-proxy, no cluster de utilizador falhe a autenticação através do token da conta de serviço e demoraria horas até que o token da conta de serviço fosse atualizado com as novas configurações.

Solução alternativa: reinicie manualmente o pod no cluster de utilizadores para renovar o token da conta de serviço com as novas configurações.

Infraestrutura como código (IAC)

Falha na conciliação do subcomponente devido à falta de espaço de nomes

Versões: 1.14.3

Sintomas: um subcomponente não é reconciliado. Isto ocorre porque o espaço de nomes config-management-monitoringobrigatório não é criado automaticamente no cluster gdchservices-mp.

Solução alternativa: crie o espaço de nomes config-management-monitoring no cluster gdchservices-mp com 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 recolha de métricas do ConfigSync de IAC falha

Versões: 1.14.3, 1.14.4

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

Solução alternativa: conclua os seguintes passos no cluster root-admin:

  1. Pause o subcomponente iac-configsync-mon.
  2. Edite o objeto MetricsProxySidecar/iac-configsync-metrics no espaço de nomes config-management-monitoring.

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

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

    Altere esta secção para o seguinte:

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

  4. Reinicie a implementação otel-collector no espaço de nomes config-management-monitoring.

O RootSync do IAC falha

Versões: 1.14.3

Sintomas: existe um problema na sincronização de recursos do ConfigSync do Gitlab para clusters devido a um segredo iac-creds em falta . Os iac-creds não são rodados devido a um problema do iacmanager.

Solução alternativa: conclua os seguintes passos no cluster:

  1. Siga o runbook IAC-R0015 para resolver o problema de iac-creds secretos em falta. Roda as credenciais do gestor 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 é reconciliado, uma vez que o HarborRobotAccount só está disponível no plano de gestão.

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

Sistema de gestão de chaves

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

Versões: 1.14.x

Sintomas: alguns pedidos ao KMS falham quando um HSM não está disponível e existem outros HSMs disponíveis que poderiam ter sido usados. Este problema só é aplicável quando o KMS está configurado para usar uma chave raiz CTM.

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

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

Este comando reinicia os pods kms-backend e restabelece a ligação aos 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 do balanceador de carga externo ou interno global falha devido a endereços IP insuficientes nas sub-redes globais. O sistema não consegue atribuir dinamicamente endereços IP para equilibradores de carga globais devido a um controlador que usa um caminho de código incorreto. O balanceador de carga faz referência apenas a uma sub-rede e, se essa sub-rede não tiver mais endereços IP disponíveis, não existe forma de mudar para outra sub-rede. Esta limitação faz com que o erro seja apresentado.

Solução alternativa: tem de criar a sua própria sub-rede e criar endereços IP estáticos para os seus recursos do ForwardingRule. Para mais informações sobre a criação de sub-redes, consulte o artigo Configure sub-redes para a rede de cargas de trabalho. Ao criar um recurso ForwardingRule, pode especificar a sub-rede no campo cidrRef.

Versões: 1.14.3

Sintoma: os objetos do equilibrador de carga não entram num estado Ready.

Solução alternativa: tem de criar recursos Backend em que o campo spec tenha um valor. Os recursos Backend identificam os pontos finais do balanceador de carga. Se não fornecer um valor para o campo spec, podem 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 equilibrador de carga não reconcilia os serviços do equilibrador de carga.

Solução alternativa: para mitigar este problema, elimine e recrie o balanceador de carga eliminando os recursos BackendService e ForwardingRule desse balanceador de carga.

Os nomes de zonas incorretos não são rejeitados

Versões: 1.14.3

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

Solução alternativa: tem de fornecer os nomes corretos das zonas que estão a ser usadas. Se o equilibrador de carga estiver configurado incorretamente, os recursos personalizados do equilibrador de carga têm de ser eliminados e recriados.

Erro de webhook do balanceador de carga global e zonal

Versões: 1.14.3

Sintomas: é devolvido o seguinte erro:

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 mitigar este problema, reinicie e elimine 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

Registo

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

Versões: 1.14.3, 1.14.4, 1.14.5

Sintomas:

Os pods no espaço de nomes obs-system entram num estado CrashLoopBackOff.audit-logs-loki-io Isto é causado por falhas prematuras da sondagem de atividade ou por uma eliminação por falta de memória (OOM) durante a repetição do registo de transações (WAL), devido a um valor wal_replay_ceiling que excede o limite de memória do pod.

Solução alternativa:

Siga estes passos para ajustar a configuração do Loki de modo a permitir uma repetição da WAL bem-sucedida. As alterações devem ser aplicadas ao cluster afetado (por exemplo, root-admin ou org-infra)

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

  2. Pause a LoggingPipelineReconciler para impedir que o controlador reverta as alterações 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. O resultado 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

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

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

    Modifique a secção wal:

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

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

    a. Verifique a utilização de recursos:

    kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}

    b. Se a utilização for elevada, dimensione a implementação:

    kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}

    c. Também pode aumentar o limite de memória do pod (por exemplo, de 12000Mi para 16000Mi), se necessário.

  5. Aumente o tamanho do PVC para o pod afetado (por exemplo, loki-storage-audit-logs-loki-io-0 de 70Gi a 75Gi) para evitar pressão no disco. Siga o procedimento interno SUPP-R001 para redimensionar o PVC. O reinício no passo seguinte aplica o novo tamanho.

  6. Adicione um startupProbe ao audit-logs-loki-io StatefulSet para permitir tempo para a repetição de WAL antes do início das verificações de atividade. Guardar a alteração aciona um reinício contínuo dos pods (5 a 10 minutos).

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

    Adicione este startupProbe à especificação do contentor audit-logs-loki-io:

    startupProbe:
  failureThreshold: 1000
  httpGet:
    path: /ready
    port: loki
    scheme: HTTP
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 10

Valide a solução alternativa

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

    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}

  2. Confirme que o PVC foi redimensionado. O resultado esperado é 75Gi.

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

  3. Confirme a recuperação bem-sucedida do WAL verificando as mensagens errors=false nos registos do pod.

    kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"

  4. Verifique se a utilização do diretório /wal no interior do pod é baixa.

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

  5. Verifique o estado do anel Loki:

    a. Encaminhe a porta do 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 em bom estado em http://<DATA_IP>:43100/ring.

Limpe a substituição e o proxy de objeto

Após a validação bem-sucedida, execute os seguintes passos de limpeza.

  1. Remova a substituição do subcomponente:

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

  2. Se aumentou a implementação do obj-proxy, reduza-a para o tamanho original.

Monitorização

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

Versão: 1.14.3

Sintomas: os webhooks do AlertManager não enviam pedidos nem notificações de alertas para o ServiceNow a partir de qualquer cluster que não seja o cluster de administrador raiz ou o cluster onde reside a instância do ServiceNow. Por conseguinte, não são criados alertas no ServiceNow para a organização.

Pode identificar que o webhook não envia alertas se receber repetidamente mensagens de registo de erros. Siga estes passos para procurar erros repetidos:

  1. Exportar variáveis de ambiente:

    export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG

    Substitua MGMT_API_KUBECONFIG pelo caminho para o ficheiro kubeconfig do servidor da API Management.

  2. Encontre o pod:

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

  3. Obtenha os registos:

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

    Substitua POD_NAME pelo nome do pod.

  4. Procure erros repetidos semelhantes aos seguintes:

    Errorsendingtherequest ... read: connection reset by peer

Resolução alternativa: a resolução alternativa recomendada para este problema é pausar dois subcomponentes, um para alertas de metamonitorização e outro para alertas normais. Em seguida, substitua a etiqueta egress.networking.gke.io/enabled: "true" por networking.private.gdc.goog/infra-access: enabled na implementação mon-alertmanager-servicenow-webhook-backend do cluster afetado. Esta etiqueta permite que o pod comunique com outros clusters de infraestrutura sem depender de um gateway de saída.

Siga estes passos para aplicar a solução alternativa recomendada:

  1. Exportar variáveis de ambiente:

    export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG

    Substitua o seguinte:

    • ROOT_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador raiz.
    • MGMT_API_KUBECONFIG: o caminho para o ficheiro kubeconfig do servidor da API Management.
    • ORG: o espaço de nomes da organização.

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

  3. Atualize a implementaçã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

  4. Substitua a etiqueta em spec.template.metadata.labels de egress.networking.gke.io/enabled: "true" para networking.private.gdc.goog/infra-access: "enabled".

  5. Atualize a implementação meta-alertmanager-servicenow-webhook que abrange alertas relacionados com a pilha de monitorização:

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

  6. Substitua a etiqueta em spec.template.metadata.labels de egress.networking.gke.io/enabled: "true" para networking.private.gdc.goog/infra-access: "enabled".

Em alternativa, pode usar o Grafana para ver os mesmos alertas.

Os incidentes do ServiceNow são duplicados ocasionalmente

Versão: 1.14.3

Sintomas: pode ver incidentes duplicados do ServiceNow para o mesmo pod.

Solução alternativa: pode identificar pedidos duplicados fazendo a correspondência das impressões digitais na descrição do incidente.

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

Versão: 1.14.3

Sintomas: pode ver alarmes para o alerta oclcm-reconciler-success-rate.

Solução alternativa: pode silenciar o alerta com segurança. Este é um alerta demasiado ruidoso e estamos a trabalhar para melhorar o sinal.

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

Versão: 1.14.3, 1.14.4, 1.14.5

Sintomas: pode ver alarmes para o alerta component_reconciliation_errors.

Solução alternativa: pode silenciar o alerta com toda a segurança seguindo o manual de procedimentos MON-R2009. Este é um alerta demasiado 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 num estado de acionamento no cluster de administrador raiz.

O incidente no ServiceNow tem o seguinte aspeto:

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 estes passos para resolver o problema apenas no cluster de administrador principal:

  1. Elimine a etiqueta monitoring.gdc.goog/metamonitoring-project=mon-system em mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

  2. Elimine todas as regras de gravação com o nome mon_metrics_pipeline_absent e o valor da etiqueta do cluster ORG_NAME-admin do mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

    O exemplo seguinte mostra uma mon_metrics_pipeline_absent regra de gravação a eliminar:

    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 gestor do controlador de administrador principal mostra uma taxa de erros elevada

Versão: 1.14.3

Sintomas: pode ver alarmes para o alerta ControllerReconciliationErrorRateHigh. O gestor de comandos mostra registos com a seguinte mensagem: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Solução alternativa: pode desativar com segurança o controlador com erro.

  1. Exportar variáveis de ambiente:

    export ROOT_KUBECONFIG=ROOT_KUBECONFIG

  2. Edite a implementação do gestor do controlador do administrador principal:

    kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller

    No contentor manager, se ainda não existir um argumento --disable-reconcilers, adicione um com o valor --disable-reconcilers=ApplianceStorageTunnelReconciler. Se existir, adicione o ApplianceStorageTunnelReconciler reconciliador com uma vírgula. Por exemplo: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler

Os registos de erros devem ser limpos.

Os painéis de controlo do KUB não mostram dados em todos os painéis de PA

Versões: 1.14.3

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

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

  1. 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 o seguinte:

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

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

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

    O metricsproxysidecar atualizado pode ter o seguinte aspeto:

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

  3. Remova a secção matchClusters: do mon-pa-kube-state-metrics monitoringtarget spec. O mon-pa-kube-state-metrics monitoringtarget spec atualizado pode ter o seguinte aspeto:

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

Autorizações configuradas incorretamente 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 córtex ou do prometheus no espaço de nomes mon-system.

Solução alternativa:

Para organizações:

  1. Pause o subcomponente iam-common.

  2. Atualize o roleTemplate observability-admin-debugger/iam-system 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 o administrador principal:

  1. Pause o subcomponente iam-common.

  2. Atualize o roleTemplate observability-admin-debugger-root/iam-system 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 em falta

Versões: 1.14.3, 1.14.4

Sintomas: a função grafana-debugger-cp não está presente nos espaços de nomes do projeto de sombra de observabilidade (*-obs-system). Não é possível conceder aos utilizadores o conjunto correto de autorizações necessárias para depurar problemas relacionados com o Grafana.

Solução alternativa: crie o seguinte recurso personalizado ClusterRoleTemplate em infra-cp e use o ClusterRole correspondente que é criado para obter as autorizaçõ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"

As métricas e os registos entre zonas não são visíveis após a adição de uma nova zona

Versões: 1.14.*

Sintomas: o painel de controlo do Grafana não mostra registos nem métricas para a zona recém-adicionada.

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

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

Esta ação reinicia os pods datasource-proxy e atualiza a configuração do ponto final entre zonas para a zona adicionada recentemente.

O finalizador MonitoringTarget bloqueia a eliminação do espaço de nomes

Versões: 1.14.3, 1.14.4

Sintomas: o espaço de nomes não está a ser eliminado e existem clusters não íntegros na respetiva organização.

Solução alternativa: remova os finalizadores manualmente dos recursos personalizados MonitoringTarget que bloquearam a eliminação do espaço de nomes.

A eliminação do projeto está bloqueada devido a finalizadores pendentes do painel de controlo e da origem de dados

Versões: 1.14.3, 1.14.4

Corrigido: 1.14.3 hotfix 22

Sintomas: os projetos não são eliminados e a terminação do espaço de nomes tem erros, como no seguinte exemplo:

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

Solução alternativa: elimine os finalizadores do painel de controlo e da origem de dados manualmente.

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

Versões: 1.14.3

Corrigido: 1.14.3 hotfix 22

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

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

  1. 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 o seguinte:

    • ORG_NAME: o nome da organização.
    • ROOT_ADMIN_KUBECONFIG: o caminho para o kubeconfig de administrador principal.

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

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

    As métricas mon-kube-state-metrics-metrics-proxy atualizadas do proxy do sidecar têm o seguinte aspeto:

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

  3. Remova a secção matchClusters: da especificação mon-pa-kube-state-metrics monitoringtarget. A especificação mon-pa-kube-state-metrics monitoringtarget atualizada tem o seguinte aspeto:

    ...
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 está ativo mesmo depois de seguir o manual de procedimentos MON-R0001.

Solução alternativa:

  1. Se o problema for detetado no cluster de administração, crie o seguinte SubcomponentOverride em root-admin através do manual de procedimentos IAC-R0004. Para outros clusters, como o utilizador, o perímetro ou o partilhado, 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

  2. Encontre o NAMESPACE correto:

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

    O resultado é o seguinte:

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

    O espaço de nomes é a raiz, se o pipeline estiver inativo para o root-admin, ou org-1, se o pipeline estiver inativo para o org-1 admin:

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

    O resultado é o 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

    Aqui, o espaço de nomes correto pode ser g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster ou user-vm-2-cluster, consoante o cluster para o qual o pipeline de métricas do sistema está inativo.

  3. Depois de aplicar o SubcomponentOverride, reinicie a implementação do cortex-tenant nos respetivos clusters. Verifique se os valores são atualizados no cluster respetivo:

    kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml

  4. Atualize o campo de concorrência.

  5. Reinicie as implementações do cortex-tenant:

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

Multitenancy

A consola não indica falhas na criação do node pool

Versão: 1.14.4, 1.14.5, 1.14.6

Corrigido: 1.14.7

Sintomas: na consola do GDC, quando a criação de um conjunto de nós falha, a IU apresenta incorretamente uma mensagem creation in progress, indicando que o conjunto de nós foi criado com êxito.

Solução alternativa: use a CLI gcloud para validar a criação do conjunto 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, a consola do GDC redireciona para uma página que apresenta 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 seu operador de infraestrutura (IO) para diagnosticar se a zona para a qual está a receber problemas de autenticação está inativa.

A função para ver zonas através da CLI gdcloud não é aplicada

Versão: 1.14.x

Sintomas: a função de IAM necessária para usar o comando gdcloud zones list não é aplicada ao universo do GDC por predefinição. A função em falta, que não está disponível como uma função predefinida, bloqueia a capacidade de usar a CLI gdcloud para listar zonas.

Solução alternativa: aplique os recursos global-zone-viewer e de associação de funções do IAM ao servidor da API global:

  1. Crie um ficheiro 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

  2. Aplique o ficheiro YAML ao servidor de API global da organização:

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

Esta associação de funções autentica todos os utilizadores no sistema para verem zonas através de gdcloud zones list.

Erros intermitentes de início de sessão no URL da consola global

Versões: 1.14.x

Sintomas: quando inicia sessão na consola do GDC com o URL global, pode receber erros que indicam que a sua sessão já não é válida. Este erro pode ser causado por um erro de rede subjacente e não por uma representação precisa do estado da sua sessão.

Solução: inicie sessão na consola do GDC com os URLs zonais para gerir recursos globais a partir de cada zona. Para mais informações sobre como mudar os contextos zonais a partir da consola GDC, consulte o artigo Gerir recursos em várias zonas.

Redes

O ajuste da ordem das zonas MultiZoneNetworkConfig causa uma falha na substituição da configuração

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

Sintomas:

  1. O estado READY dos comutadores Top of Rack (ToR) é Falso. Pode confirmar isto executando o seguinte comando:

    kubectl get torswitches -A

  2. A substituição da configuração do comutador falha com um erro que indica que a entrada já existe. Isto pode ser visto nos registos de substituição da configuração do comutador. A mensagem de erro é semelhante à seguinte:

    % Insertion failed - entry already exists

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

Soluções alternativas:

Para resolver este problema, remova manualmente a configuração da lista de acesso do caminho AS do BGP em conflito de cada comutador ToR afetado. Isto permite que o sistema concilie e aplique a configuração correta.

  1. Estabeleça uma ligação SSH a cada comutador ToR que não esteja num estado Ready.

  2. Aceda ao modo de configuração global:

    config t

  3. Remova a configuração da lista de acesso em conflito:

    no ip as-path access-list other-zones

  4. Saia do modo de configuração.

Depois de este comando ser executado em todos os comutadores afetados, o reconciliador aplica a configuração correta e os comutadores passam para um estado READY.

Config-replace commit expiry

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

Sintomas:

Um grande número de listas de controlo de acesso (ACLs) provoca um limite de tempo ao configurar comutadores de rede. O recurso personalizado BorderLeafSwitch não está num estado Ready e, quando estabelece uma ligação SSH com o comutador não preparado, é apresentado o estado Commit expiry.

Por exemplo, o seguinte comando mostra o estado:

sh config-replace log verify

O resultado é semelhante ao seguinte:

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

Solução alternativa::

Nas versões 1.14.3 ou 1.14.7 e posteriores, edite o recurso personalizado SubcomponentOverride denominado pnet-core-override no espaço de nomes 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 permitir que a infraestrutura de automatização envie novas configurações para os comutadores. Configure o httpTimeout conforme necessário até que as mensagens Commit expiry desapareçam.

Nas versões 1.14.4, 1.14.5 e 1.14.6, execute manualmente a substituição da configuração e confirme as alterações.

  1. Pausar o interruptor:

    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"

  2. Siga o manual de procedimentos PNET-P0001 para obter acesso por comutador.

  3. Encontre a configuração a substituir:

    switch-cli# dir | grep new_config

  4. Conclua a substituição da configuração:

    switch-cli# configure replace <new_config_file>

    Esta ação pode demorar mais de cinco minutos.

  5. Depois de o config-replace ser bem-sucedido, confirme a alteração:

    switch-cli# configure replace commit

  6. Desative a pausa do interruptor:

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

A implementação com o ASN BGP de 4 bytes falha

Versões: 1.14.3, 1.14.4

Sintomas: a configuração do Border Gateway Protocol (BGP) com um número de sistema autónomo (ASN) de 4 bytes em comutadores de rede provoca falhas de configuração. Sem uma configuração BGP aplicada corretamente, a rede nessa zona do GDC pode não conseguir estabelecer o encaminhamento adequado, o que leva a problemas de conetividade, incapacidade de anunciar rotas ou instabilidade geral da rede. De momento, não existe nenhuma solução alternativa.

Tráfego de anycast global bloqueado

Versões: 1.14.3

Sintomas: o tráfego direcionado para os pontos finais anycast globais é bloqueado por listas de controlo de acesso (ACLs).

Solução alternativa:

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

  1. Encontre todos os blocos CIDR de anycast globais. Para encontrar os blocos CIDR anycast globais a atualizar, siga estes passos:

    1. Estabeleça ligação ao servidor de API global de raiz.

    2. Apresente uma lista de todos os recursos personalizados de sub-rede em todos os espaços de nomes através do comando:

      kubectl get subnet -A

    3. Filtre o resultado para encontrar recursos de sub-rede onde o filtro metadata.name contém a palavra-chave anycast.

    4. Para cada recurso de sub-rede encontrado com anycast no respetivo nome, tome nota do valor de spec.subnet. Este valor representa um bloco CIDR de anycast global.

  2. No cluster de administrador raiz, crie um recurso personalizado SubcomponentOverridedenominado pnet-trafficpolicy-dc-override no espaço de nomes raiz. Para cada sub-rede de transmissão geral que identificou no passo anterior, adicione as regras conforme mostrado no ficheiro 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 o seguinte:

    • INTERCONNECT_RULE_DESCRIPTION: o texto descritivo da regra de rede de interligação.
    • GLOBAL_ANYCAST_CIDR: o bloco CIDR de anycast global, como 136.125.38.128/28. Para cada anycast que encontrar no passo anterior, crie a regra com este ficheiro YAML.
    • HAIRPIN_RULE_DESCRIPTION: o texto descritivo da regra de rede de hairpin.

A falha parcial da DCI provoca perda de tráfego

Versões: 1.14.3

Sintomas: quando ambos os links de interligação de centros de dados (DCI) que ligam o switch de folha de limite de uma zona ao switch do operador, ou quando o switch de folha de limite de uma zona sofre uma falha de hardware, cerca de 50% do tráfego de rede entre zonas é perdido.

O nome do VRF é demasiado longo

Versões: 1.14.2

Sintomas: pode ver uma mensagem semelhante a este exemplo, que indica que os comutadores não estão em bom estado quando executa este comando:

sh config-replace log verify

O resultado pode ter o seguinte aspeto:

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 um máximo de 19 carateres.

A comunicação do pod StatefulSet falha

Versões: 1.14.3, 1.14.4

Corrigido: 1.14.3 hotfix 23, 1.14.5

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

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

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

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

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

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

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

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

Versões:

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

Sintomas:

Se este problema ocorrer, pode ver os seguintes sintomas:

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

Solução alternativa:

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

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

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

  2. Obtenha acesso SSH ao nó afetado.

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

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

    tc filter del dev bond0 egress

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

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

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

Versões:

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

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

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

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

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

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

Problema do painel de controlo do Grafana do SLO de disponibilidade entre zonas e multizonas

Versões: 1.14.3

Sintomas: no Grafana, o painel de controlo do pnet-cross-zone-availability SLO não apresenta métricas.

Solução alternativa: siga o manual de procedimentos PNET-P0001 para obter acesso por comutador e verifique manualmente a sessão BGP de várias zonas e o estado de conectividade.

Os gateways de entrada do plano de dados e de gestão não conseguem reconciliar

Versões: 1.14.3

Sintomas: os subcomponentes asm-dataplane-ingress ou asm-management-ingress não estão a ser 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 gestão ou no servidor da API global. Isto pode ser inferido a partir 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 gestão, enquanto um recurso com o sufixo networking.global.gdc.goog está presente no servidor da API global.

Depois de identificar o servidor da API, elimine o recurso através do ficheiro kubeconfig correspondente. Por exemplo:

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

A página da política de rede do projeto não suporta o campo do seletor de projetos na API ProjectNetworkPolicy

Versões: 1.14.3, 1.14.4

Sintomas: quando cria uma política de rede do projeto que inclui o campo projectSelector e a visualiza na consola do GDC, a IU 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 operativo

O aprovisionamento do servidor falha

Versões: 1.14.3

Sintomas: durante o aprovisionamento do servidor, podem ser apresentados os seguintes erros 401 no recurso personalizado BaremetalHost correspondente ao transferir a imagem do SO do registo do Harbor, e o servidor fica bloqueado num ciclo de anulação do aprovisionamento e reaprovisionamento.

Para verificar a existência destes erros, descreva o BaremetalHostrecurso personalizado:

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

O resultado pode ter o seguinte aspeto:

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

Solução alternativa:

  1. Obtenha o nome e o espaço de nomes do nodePoolClaim a que o servidor pertence:

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

    O resultado pode ter o seguinte aspeto:

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

  2. Obtenha o nome da imagem do SO a partir de NodePoolClaim:

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

  3. Obtenha o URL da imagem do SO a partir do OSImageMetadata:

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

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

A atualização do nó do SO pode ficar bloqueada no passo NodeOSInPlaceUpgradePostProcessingCompleted

Versões: 1.14.3, 1.14.4

Sintomas:

Durante uma atualização de nó, o NodeUpgradeTask fica bloqueado no passo NodeOSInPlaceUpgradePostProcessingCompleted com um erro do reconciliador com a mensagem failed verifying delta after upgrade e não foi possível concluir a atualização. Este erro indica que o processo de validação da atualização encontrou discrepâncias inesperadas nos pacotes no nó. Especificamente, identifica pacotes que ainda se encontram no estado "need-upgrade" ou que aparecem como pacotes "only-in-new" após a tentativa de atualização.

A mensagem de erro apresenta pacotes específicos cuja validação falhou. Exemplo de fragmento:

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

Este sintoma pode ser causado por dois problemas. Detete primeiro qual é o problema que está a causar a situação:

  1. Cause-A: a máquina está inacessível, o que faz com que OSArtifactSnapShot fique desatualizado.

    Verifique se o nó em atualização ainda está em bom estado ou não e se a tarefa OSArtifactSnapShot correspondente está a falhar.

    Se OSArtifactSnapShot estiver desatualizado e a máquina não estiver acessível durante mais de 20 minutos, avance para Mitigation-A. Caso contrário, continue a verificar se existem Cause-B.

  2. Cause-B: falha na atualização silenciosa da RPM

    Em casos raros, a atualização do RPM numa máquina pode falhar silenciosamente após uma atualização parcial. Devem existir dois elementos ConfigMap com a diferença do pacote antes e depois da atualização:

    in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade

    Se a configuração "after-upgrade" contiver um número inferior de pacotes do que a configuração "before-upgrade", significa que a atualização foi anulada silenciosamente e nem todos os pacotes foram atualizados. Continuar para Mitigation-B.

Solução alternativa:

Mitigation-A: reparar máquina inacessível

Tentar reparar a máquina reiniciando-a. Se a máquina continuar inacessível após as tentativas de reinício, contacte a equipa de serviços para receber assistência adicional. Depois de a máquina estar novamente acessível, elimine o OSArtifactSnapShot para forçar a conciliação. Assim que OSArtifactSnapShot for reconciliado, NodeUpgradeTask deve avançar para o passo seguinte.

Mitigation-B: tente novamente o NodeUpgradeTask

  1. Use SSH na máquina que está a ser atualizada e recolha os seguintes registos para resolução de problemas futura. Devem ser recolhidos os seguintes ficheiros:

    • /var/log/dnf.log
    • /var/log/dnf.rpm.log
    • dnf history > dnf_history.log
    • rpm -qa --last > rpm_last.log

  2. Elimine o NodeUpgradeTask com falha. Esta ação aciona uma nova tentativa de NodeUpgradeTask no nó específico. O novo NodeUpgradeTask deve concluir a atualização do RPM e avançar para o passo seguinte.

A atualização do nó do SO pode ficar bloqueada no passo de criação do servidor de pacotes

Versões: 1.14.3, 1.14.4

Sintomas:

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

status:
  duration: 0s
  upgradeStatus: in-progress

Para confirmar ainda mais que esta ação falha na criação do servidor de pacotes, leia o registo do controlador de atualização do SO:

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

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

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

Em seguida, 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.

Solução alternativa:

Para confirmar ainda mais, pode verificar o recurso do servidor de pacotes real (de determinada API, como dnsregistration.network.private.gdc.goog no servidor da API de gestão do cluster que gere o CR NodeUpgrade) e encontrar o NodeUpgrade que detém esses recursos. Se o NodeUpgrade proprietário do DNSRegistration já tiver terminado, mas o recurso DNSRegistration ainda não tiver sido eliminado, pode eliminar o objeto DNSRegistration se todos os objetos NodeUpgrade referenciados tiverem terminado.

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

    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

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

As atualizações do SO do nó podem encontrar problemas e parar em qualquer fase 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, embora possa ser possível concluir automaticamente se tiver tempo suficiente.

A CR NodeUpgradeTask está em curso há mais de duas horas. Embora possa ser concluído automaticamente, o problema subjacente é a incapacidade do os-policy-reconciler de gerir eficientemente um grande volume de CRs OSPolicy. Este problema ocorre durante o passo NodeOSInPlaceUpgradeCompleted.

Para confirmar ainda mais esta falha durante a criação do servidor de pacotes, consulte o registo do controlador de atualização do SO.

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

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

Solução alternativa:

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

"storage cp" de um ficheiro grande faz com que o kube-api de gestão da organização fique inativo

Versões: 1.14.3 e posteriores

Sintomas: durante uma operação gdcloud storage cp ou uma operação gdcloud system container-registry load-oci a partir de uma estação de trabalho OIC, existe uma ligeira probabilidade de perder o acesso à infraestrutura da organização, seguido da indisponibilidade do org-mgmtkube-api. Este é um problema raro e a recolha de dados para engenharia é útil.

Solução alternativa: quando este problema ocorrer, experimente os seguintes passos:

  1. Para cada nó do plano de controlo (CP), execute uptime para ver se os nós foram reiniciados nas últimas 24 horas.
  2. Tome nota da hora do reinício.
  3. Verifique se ocorreram kernel panics em cada nó do CP imediatamente antes do reinício executando dmesg | grep -i 'kernel panic'.
  4. Em cada nó de CP, verifique se as placas NIC Mellanox estão instaladas através do seguinte comando: lspci | grep -i eth | grep -i mellanox. Se não existirem NICs Mellanox, pare de ler este problema conhecido.

  5. Em cada nó do CP, verifique estas definiçõ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.

  6. Recolha algumas informações para a Google ajudar 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

  7. Em cada nó de CP, 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:

  8. Para mitigar o problema das definições de rede, o rx-gro-hw tem de estar off executando os seguintes comandos em todos os nós do CP:

    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

  9. Verifique novamente as definições:

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

  10. Volte a tentar a operação original, como gdcloud storage cp ou gdcloud system container-registry load-oci. Se continuar a haver uma falha, contacte a equipa de engenharia.

Serviços principais da infraestrutura do Operations Suite (OIC)

Fraco desempenho do Jumphost

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

Sintomas: as operações do navegador ou do sistema demoram demasiado tempo a ser concluídas.

Solução alternativa:

Aumente a contagem de vCPUs nos Jumphosts através do gestor do Hyper-V no BM03 e BM04:

  1. Selecione uma VM de Jumphost e, de seguida, clique em definições no painel de ações.
  2. Selecione Processador e, de seguida, aumente a contagem em Número de processadores virtuais para 4 ou mais, consoante a carga de trabalho.
  3. Repita o processo para os restantes Jumphosts.

Gestor de recursos

Não é possível eliminar projetos na consola do GDC

Versões: 1.14.3, 1.14.4

Sintomas: a consola GDC apresenta o botão Eliminar para projetos existentes na página Detalhes do projeto, mas o botão não funciona.

Solução alternativa: para eliminar um projeto existente, tem de usar a CLI gdcloud. Para mais informações, consulte o artigo Elimine um projeto.

Guias interativos do Ansible da organização em falta

Versões: 1.14.3

Sintomas: quando cria uma organização, a tarefa create-ansible-playbooks que cria os livros de jogadas do Ansible necessários falha silenciosamente. Os playbooks do Ansible em falta causam problemas, como máquinas virtuais de perímetro em falta e problemas na criação de uma organização global.

Solução alternativa: siga o runbook OS-R0009 para criar manualmente os guias interativos do Ansible da organização em falta.

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

Versões: 1.14.4

Sintomas: quando cria uma organização global v1 com apenas um subconjunto de configurações de organização zonais, todas as zonas continuam a apresentar um estado de réplica da organização. Por exemplo, se tiver um universo GDC com três zonas, mas criar apenas uma configuração de organização zonal para duas zonas, a terceira zona continua a apresentar um estado de réplica com erros para a terceira organização zonal inexistente.

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

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

O resultado YAML tem um aspeto semelhante ao seguinte:

...

- 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

...

Tenha em atenção que isto só ocorre para organizações da versão 1, uma vez que as configurações zonais assimétricas não são suportadas para organizações da versão 2.

Solução alternativa: pode ignorar o estado de réplica erróneo, uma vez que a organização zonal não existe, a menos que a tenha criado especificamente.

Cluster

O grupo de nós de trabalho do cluster de infraestrutura não é eliminado

Versões: 1.14.3, 1.14.4

Sintomas: quando remove um conjunto de nós de trabalho da especificação do CR Organization, o conjunto de nós não é eliminado automaticamente, ou seja, o comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} continua a gerar o conjunto de nós a ser eliminado.

# 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 node pool de trabalho da especificação CR Organization, elimine manualmente o CR NodePoolClaim para este node pool 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 respetivos CRs NodePool associados sejam totalmente eliminados, ou seja, o comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} já não produz o conjunto de nós de trabalho.

Armazenamento

Os contentores criados com o comando gdcloud config set zone não são eliminados

Versões: 1.14.7 e posteriores

Sintomas: os contentores criados com o comando gdcloud config set zone não são eliminados devido a problemas de autorização, porque o comando tenta operar na zona errada.

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

OBJ SLO alerts firing

Versões: 1.14.3, 1.14.4

Sintomas: os alertas de SLO para OBJ estão a ser acionados devido a um 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á a ser identificado incorretamente como um erro do sistema quando é causado pelo utilizador a terminar a ligação, o que não conta para o SLO.

S3 UploadPart Empty ETag

Versões: 1.14.3

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

Solução alternativa: tente novamente o pedido como se tivesse falhado anteriormente.

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

Versões: 1.14.3

Sintomas: depois de tentar montar pods, observa que todos os pods que estão em transição para ou a partir de um nó específico falham. É apresentada uma mensagem de erro de RPC: DeadlineExceeded desc = context deadline exceeded, que indica que o nó está bloqueado. Quando esta mensagem ocorre, perde a capacidade de realizar operações adicionais do Trident no nó em questão. Os volumes que fornecem dados não são afetados, mas os volumes que se movem para e a partir do nó podem sofrer uma interrupção.

Solução alternativa:

  1. Inspeccione os registos do Trident no nó que o pod está a tentar montar e verifique se a fila está a aumentar. Os registos podem ter um aspeto semelhante ao seguinte:

    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"

  2. Inicie sessão no nó e consulte o resultado de dmesg. Os registos podem ter um aspeto semelhante ao seguinte:

    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)

  3. Depois de confirmar que está a ter um erro mkfs.ext4 do Trident, reinicie o nó.

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

Versões: 1.14.3

Sintomas:

Não é aprovisionado um PVC e é apresentado um evento como o seguinte:

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 este evento ocorre, o PVC não é aprovisionado até que execute a solução alternativa.

Solução alternativa:

Siga estes passos para resolver o problema:

  1. Tome nota do nome do volume interno do evento. Por exemplo, o evento de amostra apresentado na secção Sintomas mostra o nome do volume interno trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
  2. Siga o manual de procedimentos FILE-R0105 para aceder ao ONTAP.

  3. Elimine o volume:

    volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

file_block_iscsi_sessions_unhealthy alert comunica 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 a ter falhas de iSCSI. O controlador file-observability usa um coletor de métricas personalizado para acompanhar o estado das sessões iSCSI em cada nó do Kubernetes, mas, em alguns casos, o coletor de métricas não consegue analisar a saída do comando iscsiadm e comunica zero sessões iSCSI em execução, mesmo que o iSCSI tenha sessões em bom estado.

Solução alternativa:

Siga estes passos para verificar se o iSCSI não está a ter problemas e desativar o alerta se este for, de facto, um falso positivo:

  1. Na página de exploração do Grafana, execute a consulta fb_sessions_running_count{job="file-observability-backend-target.file-system"}. A consulta devolve uma métrica para cada nó no cluster. Se algum nó estiver a comunicar uma métrica fb_sessions_running_count de 0, anote o nome do nó.

  2. Para cada nó com métricas fb_sessions_running_count que devolvem 0, execute os seguintes comandos:

    1. Estabeleça uma ligação SSH com o nó afetado.

    2. Execute o comando iscsiadm -m session. Tem de ver várias linhas devolvidas. Cada linha é uma sessão iSCSI em execução. Se não for devolvido nada pelo comando ou existirem erros no resultado, encaminhe o problema para a equipa de engenharia de bloqueio de ficheiros.

    3. Se o comando anterior devolveu sessões iSCSI com êxito, confirmou que o alerta para este nó é um falso positivo.

  3. Quando confirmar que todos os nós afetados têm sessões iSCSI em bom estado e estão a acionar o alerta de forma errada, 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 sobresselentes

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 não estão em bom estado. O controlador file-observability usa um coletor de métricas personalizado para monitorizar o estado de cada disco no ONTAP, mas, em versões anteriores do GDC, o coletor não considera um disco sobresselente como estando em bom estado e aciona um alerta para o disco sobresselente.

Solução alternativa:

Siga estes passos para verificar se os discos são sobresselentes e desativar o alerta para o disco:

  1. Na página de exploração do Grafana, execute a consulta disks_labels_healthy{job="file-observability-backend-target.file-system"}. A consulta devolve uma métrica para cada disco no ONTAP. Se algum disco estiver a comunicar uma métrica de 0 (não saudável), anote o nome do disco.

  2. Para cada disco com métricas disks_labels_healthy que devolvem 0, execute os seguintes comandos:

    1. Use o SSH no cluster ONTAP e execute o comando disk show -disk <disk-name> -fields state com o nome do disco recolhido da consulta de métricas.

    2. Verifique se o resultado do comando indica que o estado do disco é present ou spare. Se o disco estiver noutro estado que não present ou spare, encaminhe o problema para a equipa de engenharia de bloqueio de ficheiros.

    3. Se o disco em questão estiver a comunicar present ou spare, podemos confirmar que o alerta não deve ser acionado para este disco. Crie um silêncio no AlertManager para silenciar o alerta file_block_storage_disk_failure com a etiqueta disk_name definida para o nome do disco.

  3. Depois de criar os silêncios para todos os discos sobresselentes, navegue para o Grafana para verificar se os alertas deixaram de ser acionados.

O alerta file_block_storage_node_peer_connection_unhealthy é acionado após o restabelecimento da ligação

Versões: 1.14.3

Sintomas: em alguns ambientes, o alerta file_block_storage_node_peer_connection_unhealthy é acionado indicando que uma ou mais ligações entre os nós do ONTAP estão a falhar. O controlador file-observability usa um coletor de métricas personalizado para acompanhar o estado destas associações. Existe um problema conhecido em que este alerta continua a ser acionado mesmo depois de a ligação com falhas ter sido restaurada.

Solução alternativa:

Siga estes passos para verificar se as ligações entre os nós estão em bom estado e desativar o alerta para os nós:

  1. Na página de exploração do Grafana, execute a consulta storage_node_peer_connections{job="file-observability-backend-target.file-system"}. A consulta devolve uma métrica para cada associação entre nós de armazenamento no cluster. Se alguma associação estiver a comunicar uma métrica storage_node_peer_connections de 0, anote as etiquetas source_node, destination_ip e storage_cluster_name da métrica.

  2. Para cada métrica storage_node_peer_connections que devolva 0, execute os seguintes comandos:

    1. Estabeleça uma ligação SSH com o cluster de armazenamento ONTAP a partir da etiqueta storage_cluster_name.

    2. Execute o seguinte comando no cluster ONTAP com os valores das etiquetas 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 equipa de engenharia de bloqueio de ficheiros. Se o comando ping for bem-sucedido, isso confirma que as ligações dos nós estão em bom estado e que o alerta está a ser acionado incorretamente.

    1. Crie um silêncio no AlertManager para silenciar o alerta file_block_storage_node_peer_connection_unhealthy com as etiquetas source_node e destination_ip definidas para o nó de origem e o IP de destino da métrica.

  3. Depois de criar silêncios para todos os nós em bom estado, navegue para o Grafana para verificar se os alertas deixaram de ser acionados.

O alerta file_block_nodes_not_reachable é acionado após o restabelecimento da ligação

Versões: 1.14.3

Sintomas: em alguns ambientes, o alerta file_block_nodes_not_reachable é acionado indicando que uma ou mais ligações dos serviços IPsec nos nós do Kubernetes ao ONTAP estão a falhar. O controlador file-observability usa um coletor de métricas personalizado para acompanhar o estado destas associações. Existe um problema conhecido em que este alerta continua a ser acionado mesmo depois de a ligação com falhas ter sido restaurada.

Solução alternativa:

Siga estes passos para verificar se as ligações nos nós estão em bom estado e desativar o alerta para os nós:

  1. Na página de exploração do Grafana, execute a consulta fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}. A consulta devolve uma métrica para cada nó no cluster. Se algum nó estiver a comunicar uma métrica fb_all_nodes_reachable de 0, anote o nome do nó.

  2. Para cada nó com métricas fb_all_nodes_reachable que devolvem 0, execute os seguintes comandos:

    1. Estabeleça uma ligação SSH com o nó afetado.

    2. Execute o seguinte 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 tenta enviar um ping para o ontap através de todas as ligações IPsec. Se algum ping no comando falhar, encaminhe o problema para a equipa de engenharia de bloqueio de ficheiros. Se os comandos ping forem bem-sucedidos, isso confirma que as ligações dos nós estão em bom estado e que o alerta está a ser acionado incorretamente.

    3. Se todos os pings no comando forem bem-sucedidos, confirmámos que as ligações no nó estão em bom estado e que o alerta está a ser acionado incorretamente. Crie um silêncio no AlertManager para silenciar o alerta file_block_nodes_not_reachable com a etiqueta node_name definida para o nome do nó.

  3. Depois de criar silêncios para todos os nós em bom estado, navegue para o Grafana para verificar se os alertas deixaram de ser acionados.

O alerta file_block_storage_high_node_total_latency é acionado durante cargas de trabalho elevadas

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 elevadas nos nós de armazenamento. Este alerta persiste até que estas cargas de trabalho sejam totalmente processadas. Mesmo quando o desempenho de leitura e escrita nos volumes é rápido, os nós de armazenamento podem continuar a comunicar uma latência elevada para operações de blocos específicas.

Solução alternativa:

Para validar as latências de volume normais e desativar o alerta de latência do nó de armazenamento, siga estes passos:

  1. Verifique os alertas de latência de volume:

    1. No Grafana, confirme que os alertas file_block_storage_high_volume_write_latency e file_block_storage_high_volume_read_latency não estão a ser acionados e estão a comunicar tempos de latência ideais para os volumes.

  2. Encaminhe se a latência de volume for elevada:

    1. Se os alertas de gravação ou leitura de volume estiverem a ser acionados, indica uma latência elevada em todo o sistema de armazenamento. Encaminhe este problema para a equipa de engenharia de bloqueio de ficheiros.

  3. Silenciar o alerta de latência do nó (se os volumes estiverem em bom estado):

    1. Se os alertas de gravação e leitura de volume estiverem em bom estado, é provável que o alerta de latência do nó seja um falso positivo.

    2. Crie um silêncio no AlertManager para o alerta file_block_storage_high_node_total_latency.

    3. Depois de criar o silêncio, navegue para o Grafana para confirmar que o alerta deixou de ser acionado.

Atualização de nó bloqueada

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

Sintomas: este bloqueio ocorre quando um LUN (Logical Unit Number) se torna apenas de leitura, muitas vezes devido a problemas com as capturas de ecrã. Quando isto acontece, o nó é isolado para mover o pod afetado para um nó diferente. Uma vez que o processo de atualização dos nós tem uma verificação prévia para garantir que os nós não estão isolados, este estado impede a continuação da atualização.

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

  1. Identifique cada organização afetada.

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

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

    1. Liste os nós na organização:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

      O resultado é semelhante ao seguinte:

      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

      Tome nota dos nomes dos nós que têm o estado SchedulingDisabled. Para este resultado de exemplo, o nó isolado é admin-node0-zone1.

    2. Desative a restrição dos nós que devolveram um estado de SchedulingDisabled no passo anterior:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME

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

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

      O resultado é semelhante ao seguinte:

      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 de os erros de vários caminhos serem resolvidos

Versões: 1.14.3 e posteriores

Sintomas: o alerta file_block_zombie_luns_present pode ser acionado em determinados ambientes devido à falha do controlador file-observability na análise da saída do comando multipath -ll. Esta situação resulta num acionamento constante do alerta de LUNs zumbis, mesmo quando o serviço de vários caminhos está em bom estado em todos os nós.

Solução alternativa:

Para validar serviços de vários caminhos saudáveis nos nós em questão, siga estes passos:

  1. Na página de exploração do Grafana, execute a consulta zombie_lun_exists{job="file-observability-backend-target.file-system"}. A consulta devolve uma métrica para cada nó no cluster. Se algum nó comunicar uma métrica de zombie_lun_exists 1, anote o nome do nó.

  2. Para cada nó com métricas zombie_lun_exists que devolvem 1, execute os seguintes comandos:

    1. Estabeleça uma ligação SSH com o nó afetado.

    2. Execute o seguinte comando:

      multipath -ll

      O comando devolve informações sobre todos os dispositivos de bloco geridos pelo serviço de vários caminhos. Verifique se nenhum dos dispositivos de blocos contém a string failed undef unknown ou a string failed faulty running nos respetivos estados.

    3. Se algum dispositivo tiver o estado failed faulty running, siga o manual de procedimentos FILE-R0020 para resolver os LUNs inativos.

    4. Se algum dispositivo tiver o estado failed undef unknown, siga o manual de procedimentos FILE-R0021 para resolver os LUNs super zombie.

  3. Silencie os alertas de LUNs zumbis, se os nós estiverem em bom estado:

    1. Se não forem encontrados dispositivos de bloqueio inválidos em nenhum dos nós, o alerta de LUN fantasma é um falso positivo.

    2. Crie um silêncio no AlertManager para o alerta file_block_zombie_luns_present.

    3. Depois de criar o silêncio, navegue para o ServiceNow para confirmar que o alerta deixou de ser acionado.

Não é possível eliminar o contentor vazio da consola

Versões: 1.14.4 e posteriores

Sintomas: na consola do GDC, não pode eliminar um contentor vazio. O contentor pode ter marcadores de eliminação e, potencialmente, outras versões de objetos quando a criação de versões de objetos está ativada com políticas de retenção. Pode ver 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 eliminar objetos, incluindo marcadores de eliminação, para tornar o contentor eliminável.

Artifact Registry do sistema

As tarefas de replicação do Harbor estão a ficar bloqueadas

Versões: 1.14.3

Sintomas: as tarefas de replicação de artefactos do Harbor ficam bloqueadas. Este problema bloqueia a distribuição de artefactos à organização e impede a criação de organizações.

Solução alternativa: para mitigar este problema, siga os passos no manual de instruções SAR-R1010.

O estado de erro transitório não é limpo quando reconcilia o recurso personalizado da conta de robô do Harbor

Versões: 1.14.3

Sintomas: um alerta CustomResourceErrorStatusAlert etiquetado com kind=HarborRobotAccount e code=SAR2002 está a ser acionado incorretamente. Por exemplo, o alerta falso tem o campo message definido como "Error getting robot: failed to list robots: 503 Service Unavailable" (Erro ao obter o robô: falha ao listar robôs: 503 Serviço indisponível).

Solução alternativa: peça ao operador de infraestrutura (IO) para verificar se o alerta é um problema genuíno ou um falso alarme e desative o som do alerta se for um falso alarme, de acordo com as instruções seguintes.

Quando um alerta é acionado, siga o manual de procedimentos SAR-E2002 para identificar e resolver a causa subjacente do alerta.

Devido a este problema conhecido, mesmo que o manual de procedimentos resolva com êxito a causa subjacente, o alerta pode continuar a ser acionado incorretamente. Continue a verificar o estado de erro do objeto de recurso personalizado (CR) HarborRobotAccount (HRD) que está a receber o alerta:

  1. Defina as variáveis de ambiente necessárias:

    export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE

    Substitua o seguinte:

    • KUBECONFIG: o caminho para o ficheiro kubeconfig.
    • HRD_NAME: o nome do CR de HarborRobotAccount destino.
    • HRD_NAMESPACE: o espaço de nomes que contém o CR HarborRobotAccount de destino.

  2. Verifique o estado de erro do CR HarborRobotAccount alvo:

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

Se o valor lastUpdateTime indicar que o campo errorStatus foi atualizado pela última vez há mais de 30 minutos, o alerta é um falso alarme. Para mitigar o alarme falso, silencie o alerta na instância com isolamento de ar do GDC seguindo o manual de procedimentos MON-R2009.

Falso alarme para o alerta SAR-R0003

Versões: 1.14.3 e posteriores

Sintomas: está a ser acionado um alerta com o código SAR-R0003, OC SAR e gravidade critical de forma errónea.

Solução alternativa: siga o guia interativo MON-R2009 para silenciar o alerta.

Sistema de venda de bilhetes

O servidor MID do ServiceNow não é iniciado corretamente

Versões: 1.14.3

Corrigido: 1.14.4

Sintomas: o ServiceNow MID Server, que se integra com o Splunk, não se regista no ServiceNow no arranque devido a uma incompatibilidade de versões.

Solução alternativa:

  1. Pause o subcomponente ts-mid-server.
KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true
  1. Substitua a string da 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

Atualizar

A anotação do cluster de serviços partilhados não é atualizada após uma atualização bem-sucedida do cluster

Versões: 1.14.4

Sintomas: os CRs do perímetro e dos clusters de serviços partilhados para clusters.baremetal.cluster.gke.io refletem a versão correta do GKE após a atualização. Os clusters.cluster.gdc.goog CRs continuam a mostrar a versão do GKE anterior.

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

A atualização do nó de administrador da organização está bloqueada

Versões: 1.14.6

Corrigido: 1.14.7

Sintomas: o processo de atualização de nós para o painel de controlo de administrador da organização gdchservices está bloqueado. A atualização do nó falha porque não é possível estabelecer uma ligação SSH ao nó, o que resulta num erro Connection timed out.

A atualização do suplemento está bloqueada

Versões: 1.14.6

Corrigido: 1.14.7

Sintomas: a atualização do suplemento para o cluster de administrador principal fica bloqueada durante a atualização de qualquer versão 1.14.x anterior para a versão 1.14.6. Uma mensagem de estado pode indicar que a atualização 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: atualize manualmente o addonset recurso do administrador principalspec.addOnSetTemplateRef para apontar para o modelo correto da nova versão.

Falha no relatório de apoio técnico

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 utilizadores devido a um problema de autorizações.

O arranque da VM pode ficar bloqueado após a conclusão da atualização do nó do SO

Versões: 1.14.6

Sintomas: durante a atualização de 1.14.3 para 1.14.6, as máquinas virtuais nos clusters de perímetro ou de serviços partilhados não são iniciadas e ficam inacessíveis após uma atualização do SO.

Por exemplo, o seguinte comando pode confirmar o problema:

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

A saída do registo da consola da VM mostra uma mensagem de pânico do kernel semelhante à seguinte:

[    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: conclua os seguintes passos para contornar o problema:

  1. Defina as seguintes variáveis de ambiente:

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

  2. Pare a VM com falhas:

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

  3. Abra o editor para desanexar o disco de arranque da VM com falha:

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

  4. Substitua o disco de arranque 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

  5. Crie um Secret de script de arranque:

    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

  6. Crie uma VM auxiliar:

    1. Obtenha a imagem da VM para o disco de arranque da VM. A imagem não pode ter a mesma família de SO que o disco de arranque do nó da VM com problemas. Por isso, 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}')

    2. Crie o disco de arranque e a VM. Crie um novo disco de arranque e uma nova VM com um disco secundário anexado e um script de arranque para acesso à consola:

      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

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

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

  7. Consola para a VM auxiliar e regenere o initramfs:

    1. Consola para a VM auxiliar:

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

    2. Use as seguintes credenciais:

      username="newuser"

      password="Lime+blaze8legend"

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

    4. Estabeleça uma ligação chroot ao ponto de montagem e regenere o initramfs:

      sudo chroot /mnt/kernelpanic/
dracut --regenerate-all --force

    5. 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 é gerado:

      ls /boot/initramfs-* -l

      O resultado tem um aspeto semelhante ao seguinte:

      -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

  8. Pare a VM auxiliar:

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

  9. Desassocie o disco da VM auxiliar:

    1. Abra a especificação da VM auxiliar num editor:

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

    2. Remova o seguinte código do ficheiro YAML:

      - virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

  10. Volte a anexar o disco de arranque à VM com falha:

    1. Abra a especificação da VM com falhas num editor:

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

    2. Atualize a especificação da seguinte forma:

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

  11. Inicie a VM com falhas:

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

  12. Verifique se a atualização está corrigida:

    1. Verifique se o recurso personalizado Node desta VM mostra Ready e usa a versão do kernel mais recente 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 é semelhante ao seguinte:

      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

    2. Verifique a versão do kernel após estabelecer uma ligação SSH à VM:

      uname -a

      O resultado tem de mostrar a nova versão do kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.

O carregador permanece em mau estado e não é esquecido automaticamente após a atualização

Versões: 1.14.x

Sintomas: o subcomponente log-infra não está num estado saudável após a atualização. Para verificar, execute: none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Para verificar o estado de um subcomponente, tem de usar o kubeconfig do cluster principal para KUBECONFIG e o espaço de nomes do cluster atual para CLUSTER_NAMESPACE. O comando devolve o STATUS do subcomponente. Se o STATUS não for ReconciliationCompleted, indica que o subcomponente não está em bom estado nesse cluster.

Alguns pods Loki no cluster não estão em bom estado. Para apresentar uma lista de todos os pods Loki, execute: none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Este comando apresenta todos os pods Loki, incluindo as respetivas colunas STATUS e READY. Um pod é considerado não saudável se o seu STATUS não for Running ou se alguns dos seus contentores não estiverem prontos. A coluna READY, formatada como a/b, indica o número de contentores prontos a do total de b. Um pod está em bom estado quando a e b são iguais.

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

Os registos de saída de pods não íntegros são semelhantes aos seguintes:

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 eliminar um carregador não saudável do anel Loki, consulte o manual de procedimentos AL-R0031.

Vertex AI

Os pedidos de tradução podem gerar o código de erro RESOURCE_EXHAUSTED

Versões: 1.14.3

Sintomas: depois de enviar um pedido de tradução, recebe o código de erro RESOURCE_EXHAUSTED na mensagem de resposta. Este erro ocorre quando excede um limite de frequência do sistema. Um recurso foi esgotado, como uma quota por utilizador, o número máximo de consultas por segundo ou o sistema de ficheiros completo está sem espaço.

Solução alternativa: peça ao seu operador de infraestrutura (IO) para reiniciar os fragmentos de back-end do serviço de tradução. Em seguida, envie novamente pedidos de tradução com intervalos de tempo mais longos entre pedidos ou enviando pedidos mais curtos.

As solicitações batchTranslateDocument devolvem o erro 503

Versões: 1.14.3

Sintomas: depois de enviar um pedido batchTranslateDocument, recebe o código de erro 503 "Batch Document translation is not implemented" na mensagem de resposta. Este erro ocorre porque o método BatchTranslateDocument requer o serviço Aspose, que só é implementado quando o parâmetro enableRAG operável está definido como true no cluster.

Solução alternativa: peça ao operador de infraestrutura (IO) para definir o parâmetro enableRAG operable como true no cluster de administrador da organização seguindo estes passos:

  1. Crie um SubcomponentOverride recurso personalizado num ficheiro YAML denominado vai-translation.yaml com o parâmetro enableRAG operable definido como true:

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

    Substitua SHARED_SERVICE_CLUSTER_NAMESPACE pelo espaço de nomes do cluster de serviços partilhados.

  2. 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 ficheiro kubeconfig de gestão 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 as atualizações, o cluster de BD é recriado, o que faz com que o segredo ODS secret-store no cluster de serviço partilhado fique desatualizado e dessincronizado. Por este motivo, o pod e o serviço de frontend de tradução ou OCR falham a inicialização.

Solução alternativa:

Elimine o segredo no cluster de serviço partilhado:

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

Substitua SHARED_SERVICE_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig no cluster de serviço partilhado.

Se o serviço problemático for o serviço de tradução, 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 segredo automaticamente e sincroniza-o novamente com o cluster da base de dados.

Vertex AI Search

Componentes de pesquisa bloqueados no estado de conciliação

Versões: 1.14.6

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

Solução alternativa: pode ignorar o problema. Após a criação do recurso personalizado SearchConfig, os subcomponentes devem concluir a respetiva conciliação.

Servidor

A rotação de credenciais do BIOS fica bloqueada na fase de pedido de reposição

Versões: 1.14.4

Sintomas: a rotação das credenciais da BIOS fica bloqueada no estado de pedido de reposição. Pode verificar isto consultando a anotação gdch.cluster.gke.io/rotation-status para o segredo das credenciais biométricas 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. O resultado do comando é reset-requested se a rotação estiver bloqueada.

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

Não é possível aprovisionar servidores instalados anteriormente

Versões: 1.14.6

Sintomas: não é possível aprovisionar servidores após a anulação do aprovisionamento e o novo aprovisionamento, especificamente relacionados com problemas com a gestão de chaves do iLO (Integrated Lights-Out) e do HSM (Hardware Security Module). Os servidores, anteriormente parte de uma organização desativada, encontram erros durante o aprovisionamento de imagens, o que indica uma incapacidade de encontrar um dispositivo adequado, muitas vezes devido a discos bloqueados de chaves antigas ou eliminadas. Pode ver 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: elimine e reinstale os servidores afetados para ajudar os servidores a entrar num estado aprovisionado. Para mais informações, consulte os runbooks SERV-R0020 e SERV-R0021.

Máquinas virtuais

Falha na importação de imagens

Versões: 1.14.4. 1.14.5

Corrigido: 1.14.6

Sintomas: uma importação de imagens através do comando gdcloud compute images import falha com um erro Unauthorized devido a limites de tempo da sessão.

Solução alternativa: use a API KRM para a importação de imagens próprias em vez da CLI gdcloud.

A importação de imagens KRM demora muito tempo

Versões: 1.14.6 e posteriores

Sintomas: uma importação de imagens através da API KRM demora muito tempo a ser concluída. O recurso VirtualMachineImageImport permanece num estado TranslationJobInProgress durante um período prolongado, o que indica que a fase de tradução não está a ser concluída conforme esperado. O agrupamento image-translation entra num estado CrashLoopBackOff.

Solução alternativa:

  1. Experimente importar novamente criando um novo recurso VirtualMachineImageImport com um nome diferente.
  2. Monitorize o estado VirtualMachineImageImport verificando periodicamente o recurso até que o respetivo estado mude para WaitingForTranslationJob. Para mais informações, consulte o manual de procedimentos R0007 do VMM.