Verificações de integridade

Version 1.28 (latest)

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

As verificações de integridade são uma maneira de testar e monitorar a operação dos seus clusters. As verificações de integridade são executadas por conta própria e periodicamente. Também é possível usar bmctl para executar verificações de integridade sob demanda. Neste documento, descrevemos cada verificação, em que circunstâncias ela é executada automaticamente, como e quando executá-la manualmente e como interpretar os resultados.

O que é verificado?

Há duas categorias de GDCV para verificações de integridade Bare Metal:

• Verificações de máquinas de nós

• Verificações em todo o cluster

As seções a seguir descrevem o que é verificado em cada categoria. Essas verificações são usadas para verificações de integridade periódicas e sob demanda.

Verificações de máquinas de nós

Nesta seção, descrevemos o que é avaliado pelas verificações de integridade das máquinas de nós. Essas verificações confirmam que as máquinas de nós estão configuradas corretamente e se têm recursos e conectividade suficientes para a criação, os upgrades e a operação do cluster.

Essas verificações correspondem aos recursos personalizados HealthCheck do Bare Metal chamados bm-system-NODE_IP_ADDRESS-machine (por exemplo, bm-system-192.0.2.54-machine) que são executados no cluster de administrador no namespace do cluster. Para mais informações sobre recursos de verificação de integridade, consulte Recursos personalizados do HealthCheck.

Observação: as verificações de máquina comuns e as verificações de máquina do Google Cloud também são usadas em verificações de simulação.

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

• As máquinas de cluster estão usando um sistema operacional (SO) com suporte.

• A versão do SO é suportada.

• O SO está usando uma versão do kernel com suporte.

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

• No Ubuntu, o Uncomplicated Firewall (UFW) está desativado.

• Máquinas de nós atendem aos requisitos mínimos de CPU.

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

• As máquinas de nós atendem aos requisitos mínimos de memória.

• Máquinas de nós atendem aos requisitos mínimos de armazenamento em disco.

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

• A rota padrão para rotear pacotes para o gateway padrão está presente nos nós.

• O Sistema de Nomes de Domínio (DNS) está funcionando. Essa verificação será ignorada se o cluster estiver configurado para ser executado por trás de um proxy.

• Se o cluster estiver configurado para usar um espelho de registro, ele poderá ser acessado.

As verificações do Google Cloud da máquina consistem no seguinte:

• Container Registry, gcr.io, estará acessível. Essa verificação será ignorada se o cluster estiver configurado para usar um espelho de registro.

• As APIs do Google podem ser acessadas.

As verificações de integridade da máquina são compostas por:

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

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

• O status do endpoint de integridade da interface de rede de contêineres (CNI, na sigla em inglês) é íntegro.

• Os CIDRs do pod não se sobrepõem aos endereços IP da máquina do nó.

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

Verificações em todo o cluster

Nesta seção, descrevemos o que é avaliado pelas verificações de integridade de um cluster.

Verificações de rede

As verificações de rede de nó de cluster do lado do cliente a seguir são executadas automaticamente como parte das verificações de integridade periódicas. As verificações de rede não podem ser feitas sob demanda. Essas verificações correspondem aos recursos personalizados HealthCheck do Bare Metal chamados bm-system-network que são executados no cluster de administrador no namespace do cluster. Para mais informações sobre os recursos de verificação de integridade, consulte Recursos personalizados do HealthCheck.

• Se o cluster usar balanceamento de carga em pacote, os nós no pool de nós do balanceamento de carga precisarão ter conectividade do protocolo de resolução de endereço (ARP, na sigla em inglês) da camada 2. O ARP é obrigatório para a descoberta VIP.

• Os nós do plano de controle têm as portas 8443 e 8444 abertas para uso pelo serviço de identidade do GKE.

• Os nós do plano de controle têm as portas 2382 e 2383 abertas para uso pela instância etcd-events.

Para informações sobre protocolos e uso de portas para seus clusters do GKE em Bare Metal, consulte Requisitos de rede.

As verificações de rede para uma verificação de simulação são diferentes das verificações de integridade da rede. Para uma lista das verificações de rede para uma verificação de simulação, consulte Verificações de simulação para criação de cluster ou Verificações de simulação para upgrades de cluster.

Kubernetes

As verificações do Kubernetes, executadas automaticamente como parte de verificações de integridade periódicas e de simulação, também podem ser executadas sob demanda. Essas verificações de integridade não vão retornar um erro se algum dos componentes do plano de controle listados estiver ausente. A verificação só retornará erros se os componentes existirem e tiverem erros no momento da execução do comando.

Essas verificações correspondem aos recursos personalizados HealthCheck Bare Metal chamados recursos bm-system-kubernetes em execução no cluster de administrador no namespace do cluster. Para mais informações sobre recursos de verificação de integridade, consulte Recursos personalizados do HealthCheck.

• O servidor da API está funcionando.

• O operador anetd está configurado corretamente.

• Todos os nós do plano de controle podem ser operados.

• Os seguintes componentes do plano de controle estão funcionando corretamente:

  • anthos-cluster-operator

  • controller-manager

  • cluster-api-provider

  • ais

  • capi-kubeadm-bootstrap-system

  • cert-manager

  • kube-dns

Complementos

As verificações de complementos são executadas automaticamente como parte de verificações de simulação e verificações de integridade periódicas e podem ser executadas sob demanda. Essa verificação de integridade não retornará um erro se algum dos complementos listados estiver ausente. A verificação só retornará erros se os complementos existirem e tiverem erros no momento da execução do comando.

Essas verificações correspondem aos recursos personalizados HealthCheck Bare Metal chamados recursos bm-system-add-ons* em execução no cluster de administrador no namespace do cluster. Para mais informações sobre recursos de verificação de integridade, consulte Recursos personalizados do HealthCheck.

• Os componentes do Stackdriver do Cloud Logging e do Connect Agent podem ser operados:

  • stackdriver-log-aggregator

  • stackdriver-log-forwarder

  • stackdriver-metadata-agent

  • stackdriver-prometheus-k8

  • gke-connect-agent

• O GDCV para recursos gerenciados por Bare Metal não mostram alterações manuais (desvio de configuração):

  • Os valores do campo não foram atualizados

  • Os campos opcionais não foram adicionados ou removidos

  • Os recursos não foram excluídos

Se a verificação de integridade detectar deslocamento de configuração, o valor Status.Pass do recurso personalizado bm-system-add-ons do HealthCheck Bare Metal será definido como false. O campo Description na seção Failures contém detalhes sobre os recursos que foram alterados, incluindo as seguintes informações:

• Version: a versão da API para o recurso.
• Kind: o esquema do objeto, como Deployment, para o recurso.
• Namespace: o namespace em que o recurso está.
• Name: o nome do recurso.
• Diff: uma comparação de formato de string das diferenças entre o manifesto de recurso registrado e o manifesto do recurso alterado.

HealthCheck recursos personalizados

Quando uma verificação de integridade é executada, o GDCV para Bare Metal cria um recurso personalizado HealthCheck. Os recursos personalizados HealthCheck são permanentes e fornecem um registro estruturado das atividades e dos resultados da verificação de integridade. Há duas categorias de recursos personalizados HeathCheck:

• Recursos personalizados HealthCheck Bare Metal (API Version: baremetal.cluster.gke.io/v1): esses recursos fornecem detalhes sobre verificações de integridade periódicas. Esses recursos estão no cluster de administrador em namespaces do cluster. Os recursos HealthCheck do Bare Metal são responsáveis por criar cron jobs e jobs de verificação de integridade. Esses recursos são atualizados de modo consistente com os resultados mais recentes.

• Recursos personalizados HealthCheck do Anthos (API Version: anthos.gke.io/v1): esses recursos são usados para relatar métricas de verificação de integridade. Esses recursos estão no namespace kube-system de cada cluster. É importante fazer o melhor esforço para atualizar esses recursos. Se uma atualização falhar em um problema, como um erro de rede temporário, a falha será ignorada.

A tabela a seguir lista os tipos de recursos criados para qualquer uma da categoria HealthCheck:

Verificações de integridade bare metal	Verificações das condições do GKE Enterprise	Gravidade
Tipo: machine Nome: bm-system-NODE_IP_ADDRESS-machine	Tipo: machine Nome: bm-system-NODE_IP_ADDRESS-machine	Crítica
Tipo: network Nome: bm-system-network	Tipo: network Nome: bm-system-network	Crítica
Tipo: kubernetes Nome: bm-system-kubernetes	Tipo: kubernetes Nome: bm-system-kubernetes	Crítica
Tipo: complementos Nome: bm-system-add-ons	Tipo: complementos Nome: bm-system-add-ons-add-ons Nome: bm-system-add-ons-configdrift	Opcional

Para recuperar o status HealthCheck:

1. Para ler os resultados das verificações de integridade periódicas, veja os recursos personalizados associados:

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

   Substitua ADMIN_KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de administrador.

   O exemplo a seguir mostra as verificações de integridade que são executadas periodicamente e se elas 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
   

   Observação: todos os recursos de verificação de integridade periódica têm o rótulo baremetal.cluster.gke.io/periodic-health-check=true.

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

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

   Substitua:

   • HEALTHCHECK_NAME: o nome da verificação de integridade.
   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   Quando você analisa o recurso, a seção Status: contém os seguintes campos importantes:

   • Pass: indica se o último job de verificação de integridade foi aprovado ou não.
   • Checks: contém informações sobre o job de verificação de integridade mais recente.
   • Failures: contém informações sobre o job com falha mais recente.
   • Periodic: contém informações como quando foi a última vez que um job de verificação de integridade foi programado e instrumentado.

   O exemplo de HealthCheck a seguir é para uma verificação de 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 exemplo de HealthCheck a seguir é para uma verificação de 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 ver uma lista de verificações de integridade das métricas, use o seguinte comando:

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

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

   O exemplo abaixo mostra o formato da resposta:

   NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
   kube-system   bm-system-10.200.0.3-machine                                            Healthy   56m
   kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
   kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
   kube-system   bm-system-kubernetes                                                    Healthy   57m
   kube-system   bm-system-kubernetes-1.16.1-non-periodic                                Healthy   25d
   kube-system   bm-system-network                                                       Healthy   32m
   kube-system   check-kubernetes-20231114-190445-non-periodic                           Healthy   3h6m
   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
   

Cron jobs de verificação de integridade

Para verificações de integridade periódicas, cada recurso personalizado HealthCheck bare metal tem um CronJob correspondente com o mesmo nome. Esse CronJob é responsável por programar a verificação de integridade correspondente para ser executada em intervalos definidos.

Para recuperar informações sobre cron jobs:

1. Receba uma lista de cron jobs que foram executados para um determinado cluster:

   kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Substitua:

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   O exemplo a seguir 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 job de verificação de integridade executado na sintaxe de programação. Por exemplo, o job bm-system-kubernetes é executado 17 minutos após a hora (17) a cada hora (*/1) de todos os dias (* * *). Os intervalos de tempo de verificações de integridade periódicas não são editáveis, mas é útil para a solução de problemas saber quando elas devem ser executadas.

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

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

   Substitua:

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   O exemplo a seguir 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
   

Registros de verificação de integridade

Quando as verificações de integridade são executadas, elas geram registros. Se você executar verificações de integridade com bmctl ou elas forem executadas automaticamente como parte de verificações de integridade periódicas, os registros serão enviados ao Cloud Logging. Ao executar verificações de integridade sob demanda, os arquivos de registro são criados em uma pasta com data e hora no diretório log/ da pasta do cluster na estação de trabalho do administrador. Por exemplo, se você executar o comando bmctl check kubernetes para um cluster chamado test-cluster, encontrará registros em um diretório como bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Ver registros localmente

Use kubectl para ver registros de verificações de integridade periódicas:

1. Receba pods e encontre o pod de verificação de integridade específico em que você tem interesse:

   kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Substitua:

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   A resposta de amostra a seguir mostra alguns pods de verificação de integridade:

   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. Recupere os registros do pod:

   kubectl logs POD_NAME  --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
   

   Substitua:

   • POD_NAME: o nome do pod de verificação de integridade.
   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAMESPACE: o namespace do cluster.

   No exemplo a seguir, mostramos parte de um registro do pod para uma verificação de integridade da máquina 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 a seguir mostra parte de um registro do pod de verificação de integridade da máquina do nó com falha. O exemplo mostra que a verificação de kubelet (check_kubelet_pass) falhou, indicando que kubelet não está em execução no 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']"}
   ...
   

Ver registros no Cloud Logging

Os registros de verificação de integridade são transmitidos para o Cloud Logging e podem ser visualizados na Análise de registros. Verificações periódicas de integridade são classificadas como pods nos registros do console.

1. No console do Google Cloud, acesse a página Explorador de registros no menu Logging.

   Acessar o Explorador de registros

2. No campo Consulta, digite a seguinte consulta:

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

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

Veja a seguir uma lista de consultas para verificações de integridade periódicas:

• Máquina do nó

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

• Complementos

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

Verificações periódicas de integridade

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

• Máquina
• Rede
• Kubernetes
• Complementos

É possível verificar a integridade do cluster analisando os recursos personalizados HealthCheck (healthchecks.baremetal.cluster.gke.io) da Bare Metal no cluster de administrador. As verificações de rede, Kubernetes e complementos são verificações no nível do cluster. Portanto, há um único recurso para cada verificação. É executada uma verificação de máquina para cada nó no cluster de destino. Portanto, há um recurso para cada nó.

• Para listar recursos HealthCheck do Bare Metal para um determinado cluster, execute o seguinte comando:

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

  Substitua:

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

  • CLUSTER_NAMESPACE: o namespace do cluster de destino da verificação de integridade.

  O exemplo de resposta a seguir 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 integridade foi aprovada (true) ou reprovada (false).

Para saber mais sobre como conferir o status de verificações de integridade periódicas, consulte Recursos personalizados do HealthCheck e Registros de verificação de integridade.

Desativar verificações de integridade periódicas

As verificações de integridade periódicas são ativadas por padrão em todos os clusters. Para desativar as verificações de integridade periódicas de um cluster, defina o campo periodicHealthCheck.enable como false no recurso Cluster.

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

1. Edite o arquivo de configuração do cluster, adicione o campo periodicHealthCheck.enable à especificação do cluster e defina o 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. Para atualizar o cluster, execute o comando bmctl update:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster que você quer atualizar.

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

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

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

   Substitua:

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

   • CLUSTER_NAMESPACE: o namespace do cluster de destino da verificação de integridade.

Reativar verificações de integridade periódicas

As verificações de integridade periódicas são ativadas por padrão em todos os clusters. Se você tiver desativado as verificações de integridade periódicas, será possível reativá-las definindo o campo periodicHealthCheck.enable como true no recurso do cluster.

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

1. Edite o arquivo de configuração do cluster, adicione o campo periodicHealthCheck.enable à especificação do cluster e defina o 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. Para atualizar o cluster, execute o comando bmctl update:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster que você quer atualizar.

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

3. Para verificar se as verificações de integridade periódicas estão ativadas, execute o seguinte comando para confirmar se 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:

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

   • CLUSTER_NAMESPACE: o namespace do cluster de destino da verificação de integridade.

   Os recursos podem levar alguns minutos para aparecer.

Verificações de integridade sob demanda

As seções a seguir descrevem as verificações de integridade que podem ser executadas sob demanda com bmctl check. Quando você usa bmctl check para executar verificações de integridade, as regras a seguir são aplicadas:

• Ao verificar um cluster de usuário com um comando bmctl check, especifique o caminho do arquivo kubeconfig para o cluster de administrador com a sinalização --kubeconfig.

• Os registros são gerados em um diretório com carimbo de data/hora na pasta de registros do cluster na estação de trabalho do administrador (por padrão, bmctl-workspace/CLUSTER_NAME/log).

• Registros de verificação de integridade também são enviados para o Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

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

Complementos

Verifique se os complementos do Kubernetes especificados para o cluster especificado são operáveis.

• Para verificar os complementos de um cluster:

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

  Substitua:

  • CLUSTER_NAME: o nome do cluster que você está verificando.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

Para ver uma lista do que está marcado, consulte Complementos na seção O que é verificado deste documento.

Essa verificação gera arquivos de registro em um diretório check-addons-TIMESTAMP na pasta de registros do cluster na estação de trabalho do administrador. Os registros também são enviados ao Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

Cluster

Verifique todos os nós do cluster, a rede de nós, o Kubernetes e os complementos do cluster especificado. Você fornece o nome do cluster e, por padrão, bmctl procura o arquivo de configuração em bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

• Para verificar a integridade de um cluster:

  bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua:

  • CLUSTER_NAME: o nome do cluster que você está verificando.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

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

• Verificações de nó no nível da máquina
• Verificações de rede
• Kubernetes
• Complementos

Essa verificação gera arquivos de registro em um diretório check-cluster-TIMESTAMP na pasta de registros do cluster na estação de trabalho do administrador. Os registros também são enviados ao Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

Configuração

Verifique o arquivo de configuração do cluster. Essa verificação pressupõe que você gerou o arquivo de configuração e o editou para especificar os detalhes de configuração do cluster. O objetivo desse comando é determinar se alguma configuração está incorreta, ausente ou tem erros de sintaxe. Você fornece o nome do cluster, e bmctl procura o arquivo de configuração do cluster em bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml, por padrão.

• Para verificar um arquivo de configuração de cluster:

  bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua:

  • CLUSTER_NAME: o nome do cluster que você está verificando.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

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

Essa verificação gera arquivos de registro em um diretório check-config-TIMESTAMP na pasta de registros do cluster na estação de trabalho do administrador. Os registros também são enviados ao Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

GCP

Verifique se todas as máquinas de nós de cluster podem acessar o Container Registry (gcr.io) e o endpoint das APIs do Google (googleapis.com).

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

  bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua:

  • CLUSTER_NAME: o nome do cluster que você está verificando.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

Essa verificação gera arquivos de registro em um diretório check-gcp-TIMESTAMP na pasta de registros do cluster na estação de trabalho do administrador. Os registros também são enviados ao Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

Kubernetes

Verificar a integridade dos operadores críticos do Kubernetes em execução no plano de controle. Essa verificação confere se os operadores essenciais estão funcionando corretamente e se os pods não estão falhando. Essa verificação de integridade não retorna um erro se algum dos componentes do plano de controle estiver ausente. Ela só retorna erros se os componentes existirem e tiverem erros no momento da execução do comando.

• Para verificar a integridade dos componentes do Kubernetes no cluster:

  bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
  

  Substitua:

  • CLUSTER_NAME: o nome do cluster que contém os nós que você está verificando.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

Para uma lista do que foi verificado, consulte Kubernetes na seção "O que é verificado" deste documento.

Essa verificação gera arquivos de registro em um diretório check-kubernetes-TIMESTAMP na pasta de registros do cluster na estação de trabalho do administrador. Os registros também são enviados ao Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

Nós

Verifique as máquinas de nós do cluster para confirmar se estão configuradas corretamente e se têm recursos e conectividade suficientes para upgrades e operações de cluster.

• Para verificar a integridade das máquinas de nós no cluster:

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

  Substitua:

  • CLUSTER_NAME: o nome do cluster que contém os nós que você está verificando.
  • NODE_IP_ADDRESSES: uma lista separada por vírgulas de endereços IP para máquinas de nós.
  • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

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

Essa verificação gera arquivos de registros para cada máquina de nó de cluster em um diretório check-nodes-TIMESTAMP na pasta de registros do cluster na estação de trabalho do administrador. Os registros também são enviados para o Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.

Simulação

Para informações sobre como usar bmctl para executar verificações de simulação, consulte Executar verificações de simulação sob demanda para a criação de clusters e Executar verificações de simulação sob demanda para upgrades de cluster.

Verificação de simulação do ambiente de execução da VM

A verificação de simulação do ambiente de execução do VM no Google Distributed Cloud valida um conjunto de pré-requisitos da máquina do nó antes de usar o ambiente de execução da VM no Google Distributed Cloud e nas VMs. Se o ambiente de execução da VM na verificação de simulação do Google Distributed Cloud falhar, a criação da VM será bloqueada. Quando spec.enabled é definido como true no recurso personalizado VMRuntime, a verificação de simulação do ambiente de execução do VM no Google Distributed Cloud é executada automaticamente.

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

Para mais informações, consulte VM Runtime na verificação de simulação do Google Distributed Cloud.

A seguir

• Detector de problemas do nó

• Verificar a conectividade do cluster com o nettest

• Criar snapshots para ajudar a diagnosticar problemas de cluster