Verificações de funcionamento

As verificações de funcionamento são uma forma de testar e monitorizar o funcionamento dos clusters existentes. As verificações de funcionamento são executadas de forma independente e periódica. Também pode usar bmctl para executar verificações de saúde a pedido. Este documento descreve cada verificação, em que circunstâncias é executada automaticamente, como e quando a executar manualmente, e como interpretar os resultados.

O que é verificado?

Existem duas categorias de verificações de estado do Google Distributed Cloud:

• Verificações da máquina do nó

• Verificações ao nível do cluster

As secções seguintes descrevem o que é verificado para cada categoria. Estas verificações são usadas para verificações de funcionamento periódicas e a pedido.

Verificações da máquina do nó

Esta secção descreve o que é avaliado pelas verificações de funcionamento para máquinas de nós. Estas verificações confirmam que as máquinas de nós estão configuradas corretamente e que têm recursos e conetividade suficientes para a criação, as atualizações e o funcionamento do cluster.

Estas verificações correspondem aos recursos personalizados do Bare Metal HealthCheckdenominadosbm-system-NODE_IP_ADDRESS-machine (por exemplo, bm-system-192.0.2.54-machine) que são executados no cluster de administrador no espaço de nomes do cluster. Para mais informações sobre os recursos de verificação do estado de funcionamento, consulte os HealthCheck recursos personalizados.

Nota: as verificações comuns da máquina e as verificações Google Cloud da máquina também são usadas nas verificações prévias.

As verificações comuns da máquina consistem no seguinte:

• As máquinas do cluster estão a usar um sistema operativo (SO) compatível.

• A versão do SO é suportada.

• O SO está a usar uma versão do kernel suportada.

• O kernel tem a opção do compilador Just In Time (JIT) do BPF ativada (CONFIG_BPF_JIT=y).

• Para o Ubuntu, a firewall não complicada (UFW) está desativada.

• As máquinas de nós cumprem os requisitos mínimos de CPU.

• As máquinas de nós têm mais de 20% dos recursos da CPU disponíveis.

• As máquinas de nós cumprem os requisitos mínimos de memória.

• As máquinas de nós cumprem os requisitos mínimos de armazenamento em disco.

• A sincronização de tempo está configurada nas máquinas dos nós.

• A rota predefinida para encaminhar pacotes para o gateway predefinido está presente nos nós.

• O Sistema de Nomes de Domínio (DNS) está funcional (esta verificação é ignorada se o cluster estiver configurado para ser executado através de um proxy).

• Se o cluster estiver configurado para usar um espelho do registo, o espelho do registo está acessível.

As verificações Google Cloud automáticas consistem no seguinte:

• O Artifact Registry, gcr.io, está acessível (esta verificação é ignorada se o cluster estiver configurado para usar uma imagem espelhada do registo).

• As APIs Google são acessíveis.

As verificações de funcionamento da máquina consistem no seguinte:

• O kubelet está ativo e em execução em máquinas de nós.

• O containerd está ativo e em execução em máquinas de nós.

• O estado do ponto final de verificação do estado da interface de rede do contentor (CNI) é bom.

• Os CIDRs de pods não se sobrepõem aos endereços IP das máquinas dos nós.

• Os certificados kubeadm não expiraram.

Para mais informações acerca dos requisitos da máquina do nó, consulte os pré-requisitos da máquina do nó do cluster.

Verificações ao nível do cluster

Esta secção descreve o que é avaliado pelas verificações de funcionamento de um cluster.

Verificações predefinidas

As verificações de cluster predefinidas, que são executadas automaticamente como parte das verificações de estado periódicas, também podem ser executadas a pedido como parte das verificações de estado do cluster. Estas verificações garantem que os recursos do cluster do Kubernetes estão configurados corretamente e a funcionar corretamente.

Estas verificações correspondem aos recursos personalizados Bare Metal HealthCheck denominados bm-system-default-*recursos executados no cluster de administrador no espaço de nomes do cluster. Para mais informações sobre os recursos de verificação do estado de funcionamento, consulte os HealthCheck recursos personalizados.

As verificações de cluster predefinidas auditam os seguintes tipos de recursos e condições:

• DaemonSet

  • As configurações são válidas
  • Os DaemonSets não têm problemas

• Implementação

  • As configurações são válidas
  • As implementações estão em bom estado

• Nó (seguem-se todas as condições do nó)

  • Estado de prontidão do nó
  • kubelet disk pressure
  • kubelet memory pressure
  • Pressão do ID do processo (PID) do kubelet
  • Frequência de reinício do kubelet
  • O kubelet está em bom estado
  • Disponibilidade da rede
  • função containerd
  • Frequência de reinício do containerd
  • Função Docker Overlay2
  • Frequência de reinício do Docker
  • Frequência de eventos de anulação do registo de dispositivos de rede
  • Bloqueios do kernel
  • O KubeProxy não tem problemas
  • Sistema de ficheiros só de leitura

• Pod

  • As configurações são válidas
  • Os pods estão em bom estado
  • Os contentores não têm problemas

• PodDisruptionBudget (PDB)

  • As configurações são válidas
  • Função de tempo de execução PDB
  • Os PDBs correspondem aos agrupamentos
  • Pods não geridos por vários PDBs

• Pedidos de recursos

  • Os pods nos nós de destino têm pedidos de CPU e memória definidos
  • O pedido de recursos médio por nó está dentro do limite monitorizado

• Serviço

  • As configurações são válidas
  • Os serviços estão em bom estado

• StatefulSet

  • As configurações são válidas
  • StatefulSet

Verificações de rede

As seguintes verificações de rede de nós de cluster do lado do cliente são executadas automaticamente como parte das verificações de estado periódicas. Não é possível executar verificações de rede a pedido. Estas verificações correspondem aos recursos personalizados do Bare Metal HealthCheckdenominados bm-system-network que são executados no cluster de administrador no espaço de nomes do cluster. Para mais informações sobre recursos de verificação de estado, consulte o artigo HealthCheckrecursos personalizados.

• Se o cluster usar o equilíbrio de carga agrupado, os nós no conjunto de nós de equilíbrio de carga têm de ter conectividade do protocolo de resolução de endereços (ARP) da camada 2. O ARP é obrigatório para a descoberta de VIPs.

• Os nós do plano de controlo têm as portas 8443 e 8444 abertas para utilização pelo GKE Identity Service.

• Os nós do plano de controlo têm as portas 2382 e 2383 abertas para utilização pela instância etcd-events.

Para obter informações sobre os protocolos e a utilização de portas para os seus clusters, consulte os requisitos de rede. As verificações de rede para uma verificação prévia diferem das verificações de funcionamento da rede. Para ver uma lista das verificações de rede para uma verificação prévia, consulte o artigo Verificações prévias para a criação de clusters ou Verificações prévias para atualizações de clusters.

Kubernetes

As verificações do Kubernetes, que são executadas automaticamente como parte das verificações prévias e periódicas do estado de funcionamento, também podem ser executadas a pedido. Estas verificações de estado não devolvem um erro se algum dos componentes do plano de controlo indicados estiver em falta. A verificação só devolve erros se os componentes existirem e tiverem erros no momento da execução do comando.

Estas verificações correspondem aos recursos personalizados Bare Metal HealthCheck denominados bm-system-kubernetesrecursos executados no cluster de administrador no espaço de nomes do cluster. Para mais informações sobre os recursos de verificação do estado de funcionamento, consulte os HealthCheck recursos personalizados.

• O servidor da API está a funcionar.

• O operador anetd está configurado corretamente.

• Todos os nós do plano de controlo estão operacionais.

• Os seguintes componentes do plano de controlo estão a funcionar corretamente:

  • anthos-cluster-operator

  • controller-manager

  • cluster-api-provider

  • ais

  • capi-kubeadm-bootstrap-system

  • cert-manager

  • kube-dns

Suplementos

As verificações de suplementos são executadas automaticamente como parte das verificações prévias e das verificações de funcionamento periódicas, e podem ser executadas a pedido. Esta verificação de funcionamento não devolve um erro se algum dos suplementos listados estiver em falta. A verificação só devolve erros se os suplementos existirem e tiverem erros no momento da execução do comando.

Estas verificações correspondem a recursos personalizados do Bare Metal HealthCheck denominados bm-system-add-ons*recursos em execução no cluster de administração no espaço de nomes do cluster. Para mais informações sobre os recursos de verificação do estado de funcionamento, consulte os HealthCheck recursos personalizados.

• Os componentes do Stackdriver do Cloud Logging e o agente de ligação estão operacionais:

  • stackdriver-log-aggregator

  • stackdriver-log-forwarder

  • stackdriver-metadata-agent

  • stackdriver-prometheus-k8

  • gke-connect-agent

• Os recursos geridos pelo Google Distributed Cloud não mostram alterações manuais (desvio de configuração):

  • Os valores dos campos não foram atualizados

  • Os campos opcionais não foram adicionados nem removidos

  • Os recursos não foram eliminados

Se a verificação do estado de funcionamento detetar uma deriva de configuração, o valor do recurso personalizado bm-system-add-ons Bare Metal HealthCheck é definido como Status.Pass.false O campo Description na secção Failures contém detalhes sobre todos os recursos que foram alterados, incluindo as seguintes informações:

• Version: a versão da API para o recurso.
• Kind: o esquema de objetos, como Deployment, para o recurso.
• Namespace: o espaço de nomes em que o recurso se encontra.
• Name: o nome do recurso.
• Diff: uma comparação do formato de string das diferenças entre o manifesto do recurso registado e o manifesto do recurso alterado.

HealthCheck recursos personalizados

Quando uma verificação de funcionamento é executada, o Google Distributed Cloud cria um recurso personalizado.HealthCheck Os recursos personalizados HealthChecksão persistentes e fornecem um registo estruturado das atividades e dos resultados da verificação de funcionamento. Existem duas categorias de HeathCheck recursos personalizados:

• Recursos personalizados do Bare Metal HealthCheck (API Version: baremetal.cluster.gke.io/v1): estes recursos fornecem detalhes sobre as verificações de estado periódicas. Estes recursos encontram-se no cluster de administração nos espaços de nomes do cluster. Os recursos do Bare Metal HealthCheck são responsáveis pela criação de tarefas cron e tarefas de verificação de funcionamento. Estes recursos são atualizados consistentemente com os resultados mais recentes.

• HealthCheckRecursos personalizados do Anthos (API Version: anthos.gke.io/v1): estes recursos são usados para comunicar métricas de verificação de estado. Estes recursos encontram-se no espaço de nomes kube-system de cada cluster. As atualizações destes recursos são de melhor esforço. Se uma atualização falhar devido a um problema, como um erro de rede transitório, a falha é ignorada.

A tabela seguinte lista os tipos de recursos criados para a categoria HealthCheck:

Verificações de estado do Bare Metal	Anthos HealthChecks	Gravidade
Tipo: predefinição Nome: bm-system-default-daemonset Nome: bm-system-default-deployment Nome: bm-system-default-node Nome: bm-system-default-pod Nome: bm-system-default-poddisruptionbudget Nome: bm-system-default-resource Nome: bm-system-default-service Nome: bm-system-default-statefulset	Tipo: predefinição Nome: bm-system-default-daemonset Nome: bm-system-default-deployment Nome: bm-system-default-node Nome: bm-system-default-pod Nome: bm-system-default-poddisruptionbudget Nome: bm-system-default-resource Nome: bm-system-default-service Nome: bm-system-default-statefulset	Crítico
Tipo: máquina Nome: bm-system-NODE_IP_ADDRESS-machine	Tipo: máquina Nome: bm-system-NODE_IP_ADDRESS-machine	Crítico
Tipo: rede Nome: bm-system-network	Tipo: rede Nome: bm-system-network	Crítico
Tipo: kubernetes Nome: bm-system-kubernetes	Tipo: kubernetes Nome: bm-system-kubernetes	Crítico
Tipo: suplementos Nome: bm-system-add-ons	Tipo: suplementos Nome: bm-system-add-ons-add-ons Nome: bm-system-add-ons-configdrift	Opcional

Para obter o estado HealthCheck:

1. Para ler os resultados das verificações de saúde periódicas, pode obter os recursos personalizados associados:

   kubectl get healthchecks.baremetal.cluster.gke.io \
       --kubeconfig ADMIN_KUBECONFIG \
       --all-namespaces
   

   Substitua ADMIN_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de administrador.

   O exemplo seguinte mostra as verificações de funcionamento executadas periodicamente e se as verificações foram aprovadas na última execução:

   NAMESPACE               NAME                               PASS    AGE
   cluster-test-admin001   bm-system-192.0.2.52-machine       true    11d
   cluster-test-admin001   bm-system-add-ons                  true    11d
   cluster-test-admin001   bm-system-kubernetes               true    11d
   cluster-test-admin001   bm-system-network                  true    11d
   cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
   cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
   cluster-test-user001    bm-system-add-ons                  true    56d
   cluster-test-user001    bm-system-kubernetes               true    56d
   cluster-test-user001    bm-system-network                  true    56d
   

   Nota: todos os recursos de verificação do estado de funcionamento periódica têm a etiqueta baremetal.cluster.gke.io/periodic-health-check=true.

2. Para ler os detalhes de uma verificação de estado específica, use kubectl describe:

   kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • HEALTHCHECK_NAME: o nome da verificação de funcionamento.
   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

   Quando revê o recurso, a secção Status: contém os seguintes campos importantes:

   • Pass: indica se a última tarefa de verificação de funcionamento foi aprovada ou não.
   • Checks: contém informações sobre a tarefa de verificação de estado mais recente.
   • Failures: contém informações sobre a tarefa com falhas mais recente.
   • Periodic: contém informações como a data da última vez que foi agendada e instrumentada uma tarefa de verificação de saúde.

   O seguinte exemplo de HealthCheck destina-se a uma verificação da máquina bem-sucedida:

   Name:         bm-system-192.0.2.54-machine
   Namespace:    cluster-test-user001
   Labels:       baremetal.cluster.gke.io/periodic-health-check=true
                 machine=192.0.2.54
                 type=machine
   Annotations:  <none>
   API Version:  baremetal.cluster.gke.io/v1
   Kind:         HealthCheck
   Metadata:
     Creation Timestamp:  2023-09-22T18:03:27Z
     ...
   Spec:
     Anthos Bare Metal Version:  1.16.0
     Cluster Name:               nuc-user001
     Interval In Seconds:        3600
     Node Addresses:
       192.168.1.54
     Type:  machine
   Status:
     Check Image Version:  1.16.0-gke.26
     Checks:
       192.168.1.54:
         Job UID:  345b74a6-ce8c-4300-a2ab-30769ea7f855
         Message:
         Pass:     true
     ...
     Cluster Spec:
       Anthos Bare Metal Version:  1.16.0
       Bypass Preflight Check:     false
       Cluster Network:
         Bundled Ingress:  true
         Pods:
           Cidr Blocks:
             10.0.0.0/16
         Services:
           Cidr Blocks:
             10.96.0.0/20
     ...
     Conditions:
       Last Transition Time:  2023-11-22T17:53:18Z
       Observed Generation:   1
       Reason:                LastPeriodicHealthCheckFinished
       Status:                False
       Type:                  Reconciling
     Node Pool Specs:
       node-pool-1:
         Cluster Name:  nuc-user001
       ...
     Pass:                  true
     Periodic:
       Last Schedule Time:                    2023-11-22T17:53:18Z
       Last Successful Instrumentation Time:  2023-11-22T17:53:18Z
     Start Time:                              2023-09-22T18:03:28Z
   Events:
     Type    Reason                  Age                  From                    Message
     ----    ------                  ----                 ----                    -------
     Normal  HealthCheckJobFinished  6m4s (x2 over 6m4s)  healthcheck-controller  health check job bm-system-192.0.2.54-machine-28344593 finished
   

   O HealthCheck exemplo seguinte destina-se a uma verificação da máquina com falha:

   Name:         bm-system-192.0.2.57-machine
   Namespace:    cluster-user-cluster1
   ...
   API Version:  baremetal.cluster.gke.io/v1
   Kind:         HealthCheck
   ...
   Status:
     Checks:
       192.0.2.57:
         Job UID:  492af995-3bd5-4441-a950-f4272cb84c83
         Message:  following checks failed, ['check_kubelet_pass']
         Pass:     false
     Failures:
       Category:     AnsibleJobFailed
       Description:  Job: machine-health-check.
       Details:       Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn].
       Reason:       following checks failed, ['check_kubelet_pass']
     Pass:                  false
     Periodic:
       Last Schedule Time:                    2023-10-24T23:04:21Z
       Last Successful Instrumentation Time:  2023-10-24T23:31:30Z
     ...
   

3. Para obter uma lista de verificações de funcionamento para métricas, use o seguinte comando:

   kubectl get healthchecks.anthos.gke.io \
       --kubeconfig CLUSTER_KUBECONFIG \
       --namespace kube-system
   

   Substitua CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de destino.

   O exemplo seguinte mostra o formato da resposta:

   NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
   kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
   kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
   kube-system   bm-system-default-daemonset                                             Healthy   52m
   kube-system   bm-system-default-deployment                                            Healthy   52m
   kube-system   bm-system-default-node                                                  Healthy   52m
   kube-system   bm-system-default-pod                                                   Healthy   52m
   kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
   kube-system   bm-system-default-resource                                              Healthy   52m
   kube-system   bm-system-default-service                                               Healthy   52m
   kube-system   bm-system-default-statefulset                                           Healthy   57m
   kube-system   bm-system-kubernetes                                                    Healthy   57m
   kube-system   bm-system-network                                                       Healthy   32m
   kube-system   component-status-controller-manager                                     Healthy   5s
   kube-system   component-status-etcd-0                                                 Healthy   5s
   kube-system   component-status-etcd-1                                                 Healthy   5s
   kube-system   component-status-scheduler                                              Healthy   5s
   

Tarefas cron de verificação de funcionamento

Para verificações de estado periódicas, cada recurso personalizado HealthCheck tem um CronJob correspondente com o mesmo nome. Este CronJob é responsável por agendar a verificação de funcionamento correspondente para ser executada a intervalos definidos. O CronJob também inclui um contentor ansible-runner que executa a verificação de estado estabelecendo uma ligação Secure Shell (SSH) aos nós.

Para obter informações sobre tarefas cron:

1. Obtenha uma lista de tarefas cron que foram executadas para um determinado cluster:

   kubectl get cronjobs \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

   O exemplo seguinte mostra uma resposta típica:

   NAMESPACE           NAME                           SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   cluster-test-admin   bm-system-10.200.0.3-machine   17 */1 * * *   False     0        11m             25d
   cluster-test-admin   bm-system-add-ons              25 */1 * * *   False     0        3m16s           25d
   cluster-test-admin   bm-system-kubernetes           16 */1 * * *   False     0        12m             25d
   cluster-test-admin   bm-system-network              41 */1 * * *   False     0        47m             25d
   

   Os valores na coluna SCHEDULE indicam a programação de cada execução da tarefa de verificação de estado no formato de sintaxe de programação. Por exemplo, a tarefa bm-system-kubernetes é executada 17 minutos após a hora (17) a cada hora (*/1) de todos os dias (* * *). Os intervalos de tempo das verificações de estado periódicas não são editáveis, mas é útil para a resolução de problemas saber quando devem ser executadas.

2. Recupere detalhes de um CronJob recurso personalizado específico:

   kubectl describe cronjob CRONJOB_NAME \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

   O exemplo seguinte mostra um CronJob bem-sucedido:

   Name:                          bm-system-network
   Namespace:                     cluster-test-admin
   Labels:                        AnthosBareMetalVersion=1.16.1
                                  baremetal.cluster.gke.io/check-name=bm-system-network
                                  baremetal.cluster.gke.io/periodic-health-check=true
                                  controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613
                                  type=network
   Annotations:                   target: node-network
   Schedule:                      41 */1 * * *
   Concurrency Policy:            Forbid
   Suspend:                       False
   Successful Job History Limit:  1
   Failed Job History Limit:      1
   Starting Deadline Seconds:     <unset>
   Selector:                      <unset>
   Parallelism:                   <unset>
   Completions:                   1
   Active Deadline Seconds:       3600s
   Pod Template:
     Labels:           baremetal.cluster.gke.io/check-name=bm-system-network
     Annotations:      target: node-network
     Service Account:  ansible-runner
     Containers:
     ansible-runner:
       Image:      gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5
       Port:       <none>
       Host Port:  <none>
       Command:
         cluster
       Args:
         -execute-command=network-health-check
         -login-user=root
         -controlPlaneLBPort=443
       Environment:  <none>
       Mounts:
         /data/configs from inventory-config-volume (ro)
         /etc/ssh-key from ssh-key-volume (ro)
     Volumes:
     inventory-config-volume:
       Type:      ConfigMap (a volume populated by a ConfigMap)
       Name:      bm-system-network-inventory-bm-system-ne724a7cc3584de0635099
       Optional:  false
     ssh-key-volume:
       Type:            Secret (a volume populated by a Secret)
       SecretName:      ssh-key
       Optional:        false
   Last Schedule Time:  Tue, 14 Nov 2023 18:41:00 +0000
   Active Jobs:         <none>
   Events:
     Type    Reason            Age   From                Message
     ----    ------            ----  ----                -------
     Normal  SuccessfulCreate  48m   cronjob-controller  Created job bm-system-network-28333121
     Normal  SawCompletedJob   47m   cronjob-controller  Saw completed job: bm-system-network-28333121, status: Complete
     Normal  SuccessfulDelete  47m   cronjob-controller  Deleted job bm-system-network-28333061
   

Registos de verificação de funcionamento

Quando as verificações de funcionamento são executadas, geram registos. Quer execute verificações de funcionamento com o comando bmctl ou sejam executadas automaticamente como parte das verificações de funcionamento periódicas, os registos são enviados para o Cloud Logging. Quando executa verificações de estado a pedido, são criados ficheiros de registo numa pasta com indicação de data/hora no diretório log/ da pasta do cluster na estação de trabalho do administrador. Por exemplo, se executar o comando bmctl check kubernetes para um cluster denominado test-cluster, encontra registos num diretório como bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Veja os registos localmente

Pode usar kubectl para ver os registos de verificações de funcionamento periódicas:

1. Aceda aos pods e encontre o pod de verificação de estado específico que lhe interessa:

   kubectl get pods \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

   A resposta de exemplo seguinte mostra alguns pods de verificação de estado:

   NAME                                                              READY   STATUS      RESTARTS   AGE
   bm-system-10.200.0.4-machine-28353626-lzx46                       0/1     Completed   0          12m
   bm-system-10.200.0.5-machine-28353611-8vjw2                       0/1     Completed   0          27m
   bm-system-add-ons-28353614-gxt8f                                  0/1     Completed   0          24m
   bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c   0/1     Completed   0          75m
   bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk   0/1     Completed   0          74m
   bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj   0/1     Completed   0          67m
   bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj   0/1     Completed   0          77m
   bm-system-kubernetes-28353604-4tc54                               0/1     Completed   0          34m
   bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn   0/1     Completed   0          63m
   bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z   0/1     Completed   0          77m
   ...
   bm-system-network-28353597-cbwk7                                  0/1     Completed   0          41m
   bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd   0/1     Completed   0          76m
   bm-system-network-preflight-check-create275a0fdda700cb2b44b264c   0/1     Completed   0          77m
   

2. Obtenha registos de pods:

   kubectl logs POD_NAME  \
       --kubeconfig ADMIN_KUBECONFIG \
       --namespace CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • POD_NAME: o nome do pod de verificação de funcionamento.
   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o espaço de nomes do cluster.

   O exemplo seguinte mostra parte de um registo de pod para uma verificação do estado de funcionamento do nó bem-sucedida:

   ...
   TASK [Summarize health check] **************************************************
   Wednesday 29 November 2023  00:26:22 +0000 (0:00:00.419)       0:00:19.780 ****
   ok: [10.200.0.4] => {
       "results": {
           "check_cgroup_pass": "passed",
           "check_cni_pass": "passed",
           "check_containerd_pass": "passed",
           "check_cpu_pass": "passed",
           "check_default_route": "passed",
           "check_disks_pass": "passed",
           "check_dns_pass": "passed",
           "check_docker_pass": "passed",
           "check_gcr_pass": "passed",
           "check_googleapis_pass": "passed",
           "check_kernel_version_pass": "passed",
           "check_kubelet_pass": "passed",
           "check_memory_pass": "passed",
           "check_pod_cidr_intersect_pass": "passed",
           "check_registry_mirror_reachability_pass": "passed",
           "check_time_sync_pass": "passed",
           "check_ubuntu_1804_kernel_version": "passed",
           "check_ufw_pass": "passed",
           "check_vcpu_pass": "passed"
       }
   }
   ...
   

   O exemplo seguinte mostra parte de um registo do pod de verificação do estado de funcionamento da máquina do nó com falha. O exemplo mostra que a verificação kubelet (check_kubelet_pass) falhou, o que indica que o kubelet não está a ser executado neste nó.

   ...
   TASK [Reach a final verdict] ***************************************************
   Thursday 02 November 2023  17:30:19 +0000 (0:00:00.172)       0:00:17.218 *****
   fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"}
   ...
   

Veja registos no Cloud Logging

Os registos de verificação de funcionamento são transmitidos para o Cloud Logging e podem ser vistos no Explorador de registos. As verificações de funcionamento periódicas são classificadas como pods nos registos da consola.

1. Na Google Cloud consola, aceda à página Explorador de registos no menu Registo.

   Aceda ao Explorador de registos

2. No campo Consulta, introduza a seguinte consulta básica:

   resource.type="k8s_container"
   resource.labels.pod_name=~"bm-system.*-machine.*"
   

3. A janela Resultados da consulta mostra os registos das verificações de funcionamento da máquina do nó.

Segue-se uma lista de consultas para verificações de estado periódicas:

• Predefinição

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system.default-*"
  

• Máquina de nós

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system.*-machine.*"
  

• Rede

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system-network.*"
  

• Kubernetes

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system-kubernetes.*"
  

• Suplementos

  resource.type="k8s_container"
  resource.labels.pod_name=~"bm-system-add-ons.*"
  

Verificações de funcionamento periódicas

Por predefinição, as verificações de funcionamento periódicas são executadas de hora a hora e verificam os seguintes componentes do cluster:

• Predefinição
• Máquina
• Rede
• Kubernetes
• Suplementos

Pode verificar o estado de funcionamento do cluster consultando os recursos personalizados do Bare Metal HealthCheck (healthchecks.baremetal.cluster.gke.io) no cluster de administrador. As verificações de rede, Kubernetes e suplementos são verificações ao nível do cluster, pelo que existe um único recurso para cada verificação. É executada uma verificação da máquina para cada nó no cluster de destino, pelo que existe um recurso para cada nó.

• Para apresentar uma lista de recursos HealthCheck Bare Metal para um determinado cluster, execute o seguinte comando:

  kubectl get healthchecks.baremetal.cluster.gke.io \
      --kubeconfig=ADMIN_KUBECONFIG \
      --namespace=CLUSTER_NAMESPACE
  

  Substitua o seguinte:

  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

  • CLUSTER_NAMESPACE: o espaço de nomes do cluster de destino da verificação de estado.

  A seguinte resposta de exemplo mostra o formato:

  NAMESPACE               NAME                               PASS    AGE
  cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
  cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
  cluster-test-user001    bm-system-add-ons                  true    56d
  cluster-test-user001    bm-system-kubernetes               true    56d
  cluster-test-user001    bm-system-network                  true    56d
  

  O campo Pass para healthchecks.baremetal.cluster.gke.io indica se a última verificação de estado foi aprovada (true) ou reprovada (false).

Para mais informações sobre como verificar o estado das verificações de saúde periódicas, consulte os HealthCheckrecursos personalizados e os registos de verificação de saúde.

Desative as verificações de funcionamento periódicas

As verificações de estado periódicas estão ativadas por predefinição em todos os clusters. Pode desativar as verificações de estado periódicas de um cluster definindo o campo periodicHealthCheck.enable como false no recurso Cluster.

Para desativar as verificações de funcionamento periódicas:

1. Edite o ficheiro de configuração do cluster, adicione o campo periodicHealthCheck.enable à especificação do cluster e defina o respetivo valor como false:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user-basic
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user-basic
     namespace: cluster-user-basic
   spec:
     type: user
     profile: default
     ...
     periodicHealthCheck:
       enable: false
     ...
   

2. Atualize o cluster executando o seguinte comando:

   bmctl update cluster -c CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster que quer atualizar.

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

3. Para verificar se as verificações de estado periódicas foram desativadas, execute o seguinte comando para confirmar que os recursos healthchecks.baremetal.cluster.gke.io correspondentes foram eliminados:

   kubectl get healthchecks.baremetal.cluster.gke.io \
       --kubeconfig=ADMIN_KUBECONFIG \
       --namespace=CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

   • CLUSTER_NAMESPACE: o espaço de nomes do cluster de destino da verificação de estado.

Reative as verificações de funcionamento periódicas

As verificações de estado periódicas estão ativadas por predefinição em todos os clusters. Se tiver desativado as verificações de estado periódicas, pode voltar a ativá-las definindo o campo periodicHealthCheck.enable como true no recurso de cluster.

Para reativar as verificações de funcionamento periódicas:

1. Edite o ficheiro de configuração do cluster, adicione o campo periodicHealthCheck.enable à especificação do cluster e defina o respetivo valor como true:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user-basic
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user-basic
     namespace: cluster-user-basic
   spec:
     type: user
     profile: default
     ...
     periodicHealthCheck:
       enable: true
     ...
   

2. Atualize o cluster executando o seguinte comando:

   bmctl update cluster -c CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster que quer atualizar.

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

3. Para verificar se as verificações de estado periódicas estão ativadas, execute o seguinte comando para confirmar que os recursos healthchecks.baremetal.cluster.gke.io correspondentes estão presentes:

   kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
       --namespace=CLUSTER_NAMESPACE
   

   Substitua o seguinte:

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

   • CLUSTER_NAMESPACE: o espaço de nomes do cluster de destino da verificação de estado.

   Os recursos podem demorar alguns minutos a aparecer.

Verificações de funcionamento a pedido

As secções seguintes descrevem as verificações de funcionamento que pode executar a pedido com o bmctl check. Quando usa bmctl check para executar verificações de funcionamento, aplicam-se as seguintes regras:

• Quando verifica um cluster de utilizadores com um comando bmctl check, especifique o caminho do ficheiro kubeconfig para o cluster de administrador com a flag --kubeconfig.

• Os registos são gerados num diretório com data/hora na pasta de registo do cluster na estação de trabalho do administrador (por predefinição, bmctl-workspace/CLUSTER_NAME/log).

• Os registos de verificação de funcionamento também são enviados para o Cloud Logging. Para mais informações acerca dos registos, consulte o artigo Registos de verificação do estado.

Nota: as verificações de funcionamento são atualizadas à medida que são identificados problemas conhecidos. Para direcionar o bmctl para executar as verificações a partir da imagem de patch mais recente da versão secundária instalada, use a flag de opção --check-image-version latest. Para mais informações, consulte o artigo Execute as verificações de funcionamento mais recentes.

Para mais informações sobre outras opções de comandos do bmctl, consulte a bmctl referência de comandos.

Suplementos

Verifique se os suplementos do Kubernetes especificados para o cluster especificado estão operacionais.

• Para verificar os suplementos de um cluster:

  bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster que está a verificar.
  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Para ver uma lista do que é verificado, consulte Suplementos na secção O que é verificado deste documento.

Esta verificação gera ficheiros de registo num diretório check-addons-TIMESTAMP na pasta de registo do cluster na sua estação de trabalho de administração. Os registos também são enviados para o Cloud Logging. Para mais informações sobre os registos, consulte o artigo Registos de verificação de estado.

Cluster

Verifique todos os nós do cluster, a rede de nós, o Kubernetes e os suplementos do cluster especificado. Indica o nome do cluster e, por predefinição, o bmctl procura o ficheiro de configuração do cluster em bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

• Para verificar o estado de um cluster:

  bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster que está a verificar.
  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Para ver uma lista do que é verificado, consulte as seguintes secções na secção O que é verificado deste documento:

• Verificações ao nível da máquina do nó
• Verificações predefinidas
• Verificações de rede
• Kubernetes
• Suplementos

Esta verificação gera ficheiros de registo num diretório check-cluster-TIMESTAMP na pasta de registo do cluster na sua estação de trabalho de administração. Os registos também são enviados para o Cloud Logging. Para mais informações sobre os registos, consulte o artigo Registos de verificação de estado.

Configuração

Verifique o ficheiro de configuração do cluster. Esta verificação espera que tenha gerado o ficheiro de configuração e o tenha editado para especificar os detalhes de configuração do cluster para o seu cluster. O objetivo deste comando é determinar se alguma definição de configuração está incorreta, em falta ou tem erros de sintaxe. Indica o nome do cluster e o bmctl procura o ficheiro de configuração do cluster em bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml por predefinição.

• Para verificar um ficheiro de configuração do cluster:

  bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster que está a verificar.
  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Este comando verifica a sintaxe YAML do ficheiro de configuração do cluster, Google Cloud o acesso e as autorizações da conta de serviço especificada no ficheiro de configuração do cluster.

Esta verificação gera ficheiros de registo num diretório check-config-TIMESTAMP na pasta de registo do cluster na sua estação de trabalho de administração. Os registos também são enviados para o Cloud Logging. Para mais informações sobre os registos, consulte o artigo Registos de verificação de estado.

Conetividade com Google Cloud

Verifique se todas as máquinas de nós do cluster podem aceder ao Artifact Registry (gcr.io) e ao ponto final das APIs Google (googleapis.com).

• Para verificar o acesso do cluster aos Google Cloud recursos necessários:

  bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster que está a verificar.
  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Esta verificação gera ficheiros de registo num diretório check-gcp-TIMESTAMP na pasta de registo do cluster na sua estação de trabalho de administração. Os registos também são enviados para o Cloud Logging. Para mais informações sobre os registos, consulte o artigo Registos de verificação de estado.

Kubernetes

Verifique o estado de funcionamento dos operadores críticos do Kubernetes em execução no plano de controlo. Esta verificação confirma que os operadores críticos estão a funcionar corretamente e que os respetivos pods não estão a falhar. Esta verificação de funcionamento não devolve um erro se algum dos componentes do plano de controlo estiver em falta: apenas devolve erros se os componentes existirem e tiverem erros no momento da execução do comando.

• Para verificar o estado dos componentes do Kubernetes no seu cluster:

  bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster que contém os nós que está a verificar.
  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Para ver uma lista do que é verificado, consulte Kubernetes na secção O que é verificado deste documento.

Esta verificação gera ficheiros de registo num diretório check-kubernetes-TIMESTAMP na pasta de registo do cluster na sua estação de trabalho de administração. Os registos também são enviados para o Cloud Logging. Para mais informações sobre os registos, consulte o artigo Registos de verificação de estado.

Nós

Verifique as máquinas dos nós do cluster para confirmar que estão configuradas corretamente e que têm recursos e conetividade suficientes para atualizações e funcionamento do cluster.

• Para verificar o estado das máquinas de nós no seu cluster:

  bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster que contém os nós que está a verificar.
  • NODE_IP_ADDRESSES: uma lista de endereços IP separados por vírgulas para máquinas de nós.
  • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Para ver uma lista do que é verificado, consulte Verificações da máquina do nó na secção O que é verificado deste documento.

Esta verificação gera ficheiros de registo para cada máquina de nó de cluster num diretório check-nodes-TIMESTAMP na pasta de registo do cluster na sua estação de trabalho de administração. Os registos também são enviados para o Cloud Logging. Para mais informações sobre os registos, consulte o artigo Registos de verificação de estado.

Verificação prévia

Para obter informações sobre a utilização do bmctl para executar verificações prévias, consulte os artigos Executar verificações prévias a pedido para a criação de clusters e Executar verificações prévias a pedido para atualizações de clusters.

Verificação prévia do tempo de execução da VM

A verificação prévia do VM Runtime no GDC valida um conjunto de pré-requisitos da máquina do nó antes de usar o VM Runtime no GDC e nas VMs. Se a verificação prévia do tempo de execução da VM no GDC falhar, a criação da VM é bloqueada. Quando o valor de spec.enabled é definido como true no recurso personalizado VMRuntime, a verificação prévia do tempo de execução da VM no GDC é executada automaticamente.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

Para mais informações, consulte o artigo Verificação prévia do tempo de execução da VM no GDC.

Execute as verificações de funcionamento mais recentes

As verificações de funcionamento (e as verificações prévias) são atualizadas à medida que são identificados problemas conhecidos. Para direcionar o bmctl para executar as verificações a partir da imagem de patch mais recente da versão secundária instalada, use a opção --check-image-version latest:

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

Substitua CLUSTER_NAME pelo nome do cluster que está a verificar.

Isto pode ajudar a detetar problemas conhecidos identificados recentemente sem primeiro atualizar o cluster.

Também pode executar as verificações de pré-implementação mais recentes antes de instalar ou atualizar um cluster. Para mais informações, consulte o artigo Execute as verificações pré-publicação mais recentes.

Deteção de desvio de configuração

Quando a verificação do estado dos suplementos é executada, entre outras coisas, verifica se existem alterações inesperadas aos recursos geridos pelo Google Distributed Cloud. Especificamente, a verificação avalia os manifestos destes recursos para determinar se foram feitas alterações por entidades externas. Estas verificações podem ajudar a alertar para alterações inadvertidas que podem ser prejudiciais para o estado de funcionamento do cluster. Também fornecem informações valiosas para a resolução de problemas.

Que manifestos são verificados

Com algumas exceções, a verificação do estado dos suplementos revisa todos os recursos geridos pelo Google Distributed Cloud para os seus clusters. Estes são recursos instalados e administrados pelo software Google Distributed Cloud. Existem centenas destes recursos e a maioria dos respetivos manifestos é verificada quanto a desvio de configuração. Os manifestos destinam-se a todos os tipos de recursos, incluindo, entre outros, os seguintes:

ClusterRoles ClusterRoleBindings CustomResourceDefinitions DaemonSets Implementações HorizontalPodAutoscalers Emissores

MetricsServers MutatingWebhookConfigurations Espaços de nomes Redes NetworkLoggings PodDisruptionBudgets Fornecedores

Funções RoleBindings Serviços StorageClasses ValidatingWebhookConfigurations

Que manifestos não são verificados

Por predefinição, excluímos alguns manifestos da revisão. Ignoramos tipos específicos de recursos, como certificados, segredos e contas de serviço, por motivos de privacidade e segurança. A verificação de suplementos também ignora alguns recursos e campos de recursos, porque esperamos que sejam alterados e não queremos que as alterações acionem erros de desvio de configuração. Por exemplo, a verificação ignora os campos replicas nas implementações, porque o escalador automático pode modificar este valor.

Como excluir manifestos adicionais ou partes de manifestos da revisão

Em geral, recomendamos que não faça alterações aos recursos geridos pelo Google Distributed Cloud nem ignore as alterações que lhes estão a ser feitas. No entanto, sabemos que, por vezes, os recursos requerem modificações para resolver requisitos de casos únicos ou corrigir problemas. Por este motivo, fornecemos um ignore-config-drift ConfigMap para cada cluster na sua frota. Use estes ConfigMaps para especificar recursos e campos de recursos específicos a excluir da avaliação.

O Google Distributed Cloud cria um ignore-config-drift ConfigMap para cada cluster. Estes ConfigMaps estão localizados no cluster de gestão (administrador ou híbrido) no espaço de nomes do cluster correspondente. Por exemplo, se tiver um cluster de administrador (admin-one) que gere dois clusters de utilizadores (user-one e user-two), pode encontrar o ConfigMap ignore-config-drift para o cluster user-one no cluster admin-one no espaço de nomes cluster-user-one.

Para excluir um recurso ou campos de recursos da revisão:

1. Adicione um campo data.ignore-resources ao ignore-config-drift ConfigMap.

   Este campo recebe uma matriz de strings JSON, com cada string a especificar um recurso e, opcionalmente, campos específicos no recurso.

2. Especifique o recurso e, opcionalmente, os campos específicos a ignorar como um objeto JSON na matriz de strings:

   O objeto JSON para um recurso e campos tem a seguinte estrutura:

   {
     "Version": "RESOURCE_VERSION",
     "Kind": "RESOURCE_KIND",
     "Namespace": "RESOURCE_NAMESPACE",
     "Name": "RESOURCE_NAME",
     "Fields": [
       "FIELD_1_NAME",
       "FIELD_2_NAME",
       ...
       "FIELD_N_NAME"
     ]
   }
   

   Substitua o seguinte:

   • RESOURCE_VERSION: (opcional) o valor apiVersion para o recurso.

   • RESOURCE_KIND: (opcional) o valor kind para o recurso.

   • RESOURCE_NAMESPACE: (opcional) o valor de metadata.namespace para o recurso.

   • RESOURCE_NAME: (opcional) o valor metadata.name para o recurso.

   • FIELD_NAME: (opcional) especifique uma matriz de campos de recursos a ignorar. Se não especificar nenhum campo, a verificação de suplementos ignora todas as alterações ao recurso.

   Cada um dos campos no objeto JSON é opcional, pelo que são permitidas várias permutações. Pode excluir categorias inteiras de recursos ou ser muito preciso e excluir campos específicos de um recurso específico.

   Por exemplo, se quiser que a verificação de suplementos ignore quaisquer alterações apenas à secção commandais da implementação no cluster de administrador, o JSON pode ter o seguinte aspeto:

   {
     "Version": "apps/v1",
     "Kind": "Deployment",
     "Namespace": "anthos-identity-service",
     "Name": "ais",
     "Fields": [
       "command"
     ]
   }
   

   Adicionaria este objeto JSON a ignore-resources no config-drift-ignore ConfigMap como um valor de string numa matriz, conforme mostrado no exemplo seguinte:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     creationTimestamp: "2024-09-24T00:39:45Z"
     name: config-drift-ignore
     namespace: cluster-example-admin
     ownerReferences:
     - apiVersion: baremetal.cluster.gke.io/v1
       kind: Cluster
       name: example-admin
     ...
   data:
     ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]'
     ...
   

   Esta definição de ConfigMap permite-lhe adicionar, remover ou editar command campos na implementação ais sem acionar erros de desvio de configuração. No entanto, as edições a campos fora da secção command na implementação são detetadas pela verificação de suplementos e comunicadas como desvio de configuração.

   Se quiser excluir todas as implementações, o valor ignore-resources pode ter o seguinte aspeto:

   ...
   data:
     ignore-resources: '[{"Kind":"Deployment"}]'
   ...
   

   Uma vez que ignore-resources aceita uma matriz de strings JSON, pode especificar vários padrões de exclusão. Se estiver a resolver problemas ou a fazer experiências com os seus clusters e não quiser acionar erros de desvio de configuração, esta flexibilidade para excluir recursos muito segmentados e campos de recursos ou categorias mais amplas de recursos da deteção de desvio pode ser útil.

O que se segue?

Para mais informações, consulte o seguinte:

• Node Problem Detector

• Verifique a conetividade do cluster com o nettest

• Crie instantâneos para ajudar a diagnosticar problemas de clusters

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

• Requisitos para abrir um registo de apoio ao cliente.
• Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
• Componentes suportados.