Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

Verificações de integridade

As verificações de integridade são uma maneira de testar e monitorar a operação dos clusters existentes. As verificações de integridade são executadas sozinhas, periodicamente. Também é possível usar bmctl para executar verificações de integridade sob demanda. Este documento descreve cada verificação, em quais circunstâncias ela é executada automaticamente, como e quando ela é executada manualmente e como interpretar os resultados.

O que é verificado?

Há duas categorias de verificações de integridade do Google Distributed Cloud:

Verificações da máquina do nó
Verificações no cluster

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

Verificações da máquina do nó

Esta seção descreve o que é avaliado pelas verificações de integridade das máquinas de nó. Essas verificações confirmam que as máquinas de nó estão configuradas corretamente e que elas 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 com o nome 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 HealthCheck recursos personalizados.

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

As máquinas do cluster estão usando um sistema operacional (SO) com suporte.
A versão do SO é compatível.
O SO está usando uma versão do kernel com suporte.
O kernel tem a opção do compilador Just In Time (JIT) do BPF ativada (CONFIG_BPF_JIT=y).
No Ubuntu, o Uncomplicated Firewall (UFW) está desativado.
As máquinas de nó 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ó atendem aos requisitos mínimos de memória.
As máquinas de nó atendem aos requisitos mínimos de armazenamento em disco.
A sincronização é configurada nas máquinas de nó.
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á funcional. Essa verificação é 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, esse espelho poderá ser acessado.

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

O Container Registry, gcr.io, pode ser acessado. Essa verificação é ignorada se o cluster estiver configurado para usar um espelho de registro.
As APIs do Google são acessíveis.

As verificações de integridade da máquina consistem em:

kubelet está ativo e em execução nas máquinas de nó.
containerd está ativo e em execução nas máquinas de nó.
O status do endpoint de integridade da interface de rede de contêiner (CNI) está íntegro.
Os CIDRs de pods 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 no cluster

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

Verificações de rede

As seguintes verificações de rede de nó do cluster do lado do cliente são executadas automaticamente como parte de verificações de integridade periódicas. As verificações de rede não podem ser executadas sob demanda. Essas verificações correspondem aos recursos personalizados HealthCheck do bare metal com o nome bm-system-network 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 HealthCheck.

Se o cluster usa balanceamento de carga agrupado, os nós no pool de nós de balanceamento de carga precisam ter conectividade de protocolo de resolução de endereço (ARP, na sigla em inglês) de camada 2. O ARP é necessário para a descoberta de 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 clusters, 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 conferir uma lista das verificações de rede para uma verificação de simulação, consulte Verificações de simulação para criação de clusters ou Verificações de simulação para upgrades de cluster.

Kubernetes

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

Essas verificações correspondem aos recursos personalizados HealthCheck do Bare Metal chamados 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 HealthCheck recursos personalizados.

O servidor da API está funcionando.
O operador anetd está configurado corretamente.
Todos os nós do plano de controle são operacionais.
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 das verificações de pré-voo e de integridade periódicas e podem ser executadas sob demanda. Essa verificação de integridade não vai retornar um erro se algum dos complementos listados estiver ausente. A verificação só retorna erros se os complementos existirem e tiverem erros no momento da execução do comando.

Essas verificações correspondem aos recursos personalizados HealthCheck do Bare Metal com o nome 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 HealthCheck recursos personalizados.

Os componentes do Stackdriver do Cloud Logging e o agente do Connect são operacionais:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
Os recursos gerenciados pelo Google Distributed Cloud não mostram mudanças manuais (desvio de configuração):
- Os valores dos campos 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 uma variação de configuração, o valor Status.Pass do recurso personalizado HealthCheck do bare metal bm-system-add-ons será definido como false. O campo Description na seçã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 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 recursos no registro e o manifesto do recurso alterado.

Recursos personalizados `HealthCheck`

Quando uma verificação de integridade é executada, o Google Distributed Cloud 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 do 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 nos namespaces do cluster. Os recursos HealthCheck do Bare Metal são responsáveis por criar jobs e jobs de cron de verificação de integridade. Esses recursos são atualizados constantemente com os resultados mais recentes.
Recursos personalizados HealthCheck do Anthos (API Version: anthos.gke.io/v1): esses recursos são usados para informar métricas de verificação de integridade. Esses recursos estão no namespace kube-system de cada cluster. As atualizações desses recursos são o melhor esforço possível. Se uma atualização falhar devido a um problema, como um erro de rede transitório, a falha será ignorada.

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

Bare Metal HealthChecks Verificações de integridade do GKE Enterprise Gravidade

Bare Metal HealthChecks	Verificações de integridade do GKE Enterprise	Gravidade
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: complementos Nome: `bm-system-add-ons`	Tipo: complementos Nome: `bm-system-add-ons-add-ons` Nome: `bm-system-add-ons-configdrift`	Opcional

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: 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 da HealthCheck:

Para ler os resultados das verificações de integridade periódicas, é possível acessar 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 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

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.

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

Para conferir 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 a seguir 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 de 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. O CronJob também inclui um contêiner ansible-runner que executa a verificação de integridade estabelecendo uma conexão de shell segura (SSH) aos nós.

Para recuperar informações sobre cron jobs:

Confira uma lista de jobs cron 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 execução de job de verificação de integridade na sintaxe de programação. Por exemplo, o job bm-system-kubernetes é executado 17 minutos depois da hora (17) a cada hora (*/1) de cada dia (* * *). Os intervalos de tempo para verificações de integridade periódicas não podem ser editados, mas são úteis para solucionar problemas para saber quando elas precisam ser executadas.

Extraia os 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 uma CronJob bem-sucedida:

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. Os registros são enviados ao Cloud Logging, seja quando você executa as verificações de integridade com bmctl ou quando elas são executadas automaticamente como parte de verificações periódicas. Ao executar verificações de integridade sob demanda, os arquivos de registro são criados em uma pasta com carimbo de data/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 em um cluster chamado test-cluster, os registros serão encontrados em um diretório como bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Conferir registros localmente

É possível usar kubectl para conferir os registros de verificações de integridade periódicas:

Acesse os pods e encontre o pod de verificação de integridade específico que você quer:

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

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

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

Ver registros no Cloud Logging

Os registros de verificação de integridade são transmitidos por streaming para o Cloud Logging e podem ser visualizados no Explorador de registros. As verificações de integridade periódicas são classificadas como pods nos registros do console.

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

Acessar o Explorador de registros

No campo Consulta, digite a seguinte consulta:

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

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

Confira uma lista de consultas para verificações de integridade periódicas:

Máquina de 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 de integridade periódicas

Por padrão, as verificações de integridade periódicas são executadas a cada 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) do Bare Metal no cluster de administrador. As verificações de rede, Kubernetes e complementos são realizadas no nível do cluster, portanto, há um único recurso para cada verificação. Uma verificação de máquina é executada para cada nó no cluster de destino, portanto, há um recurso para cada nó.

Para listar os recursos HealthCheck do Bare Metal de 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 de healthchecks.baremetal.cluster.gke.io indica se a última verificação de integridade foi bem-sucedida (true) ou falhou (false).

Para mais informações sobre como verificar o status de verificações de integridade periódicas, consulte Recursos personalizados 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. É possível desativar as verificações de integridade periódicas de um cluster definindo o campo periodicHealthCheck.enable como false no recurso do cluster.

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

Edite o arquivo de configuração do cluster e 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
  ...

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.
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 as 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, poderá reativá-las definindo o campo periodicHealthCheck.enable como true no recurso de cluster.

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

Edite o arquivo de configuração do cluster e 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
  ...

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.
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.
Pode levar alguns minutos para os recursos aparecerem.

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 seguintes regras se aplicam:

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 flag --kubeconfig.
Os registros são gerados em um diretório com carimbo de data/hora na pasta de registro do cluster na estação de trabalho do administrador (bmctl-workspace/CLUSTER_NAME/log por padrão).
Os 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 outras opções de comandos bmctl, consulte a referência de comandos 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 conferir uma lista do que está marcado, consulte Complementos na seção "O que está marcado" deste documento.

Essa verificação gera arquivos de registro em um diretório check-addons-TIMESTAMP na pasta de registro 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.

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 bmctl procura o arquivo de configuração do cluster em bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml por padrão.

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 conferir uma lista do que foi verificado, consulte as seguintes seções na seção "O que foi verificado" deste documento:

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

Essa verificação gera arquivos de registro em um diretório check-cluster-TIMESTAMP na pasta de registro 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.

Configuração

Verifique o arquivo de configuração do cluster. Essa verificação espera que você tenha gerado e editado o arquivo de configuração para especificar os detalhes de configuração do cluster. O objetivo desse comando é determinar se alguma configuração está errada, ausente ou tem erros de sintaxe. Você informa 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 acessoGoogle 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 registro 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.

Conectividade com Google Cloud

Verifique se todas as máquinas de nó do 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 Google Cloud necessários:
```
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 registro 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.

Kubernetes

Verifique a integridade dos operadores essenciais do Kubernetes em execução no plano de controle. Essa verificação confirma se os operadores críticos 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 da plataforma 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 conferir uma lista do que foi verificado, consulte Kubernetes na seção "O que foi verificado" deste documento.

Essa verificação gera arquivos de registro em um diretório check-kubernetes-TIMESTAMP na pasta de registro 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.

Nós

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

Para verificar a integridade das máquinas de nó 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ó.
- ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

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

Essa verificação gera arquivos de registro para cada máquina de nó do cluster em um diretório check-nodes-TIMESTAMP na pasta de registro do cluster na estação de trabalho de 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 de VM

A verificação de simulação do ambiente de execução de VM no GDC valida um conjunto de pré-requisitos da máquina de nó antes de usar o ambiente de execução de VM no GDC e as VMs. Se a verificação de simulação do ambiente de execução de VM no GDC 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 de VM no GDC é executada automaticamente.

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

Para mais informações, consulte Verificação de simulação do ambiente de execução de VM no GDC.

Executar as verificações de integridade mais recentes

As verificações de integridade e de simulação são atualizadas à medida que os problemas conhecidos são identificados. Para direcionar bmctl a executar as verificações da imagem de patch mais recente da versão secundária instalada, use a flag de opção --check-image-version latest:

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

Substitua CLUSTER_NAME pelo nome do cluster que você está verificando.

Isso pode ajudar a detectar problemas conhecidos identificados recentemente sem precisar fazer upgrade do cluster.

Também é possível realizar as verificações de simulação mais recentes antes de instalar ou fazer upgrade de um cluster. Para mais informações, consulte Executar as verificações de simulação mais recentes.

Detecção de desvio de configuração

Quando a verificação de integridade dos complementos é executada, ela verifica, entre outras coisas, mudanças inesperadas nos recursos gerenciados pelo Google Distributed Cloud. Especificamente, a verificação avalia os manifestos desses recursos para determinar se as mudanças foram feitas por entidades externas. Essas verificações podem ajudar a avisar sobre mudanças inadvertidas que podem ser prejudiciais à integridade do cluster. Eles também fornecem informações valiosas para solução de problemas.

Quais manifestos são verificados

Com algumas exceções, a verificação de integridade dos complementos analisam todos os recursos gerenciados pelo Google Distributed Cloud para seus clusters. Esses são recursos instalados e administrados pelo software do Google Distributed Cloud. Há centenas desses recursos, e a maioria dos manifestos deles é verificada quanto à deriva de configuração. Os manifestos são para todos os tipos de recursos, incluindo, entre outros:

ClusterRoles
ClusterRoleBindings
CustomResourceDefinitions
DaemonSets
Implantações
HorizontalPodAutoscalers
Emissores

MetricsServers
MutatingWebhookConfigurations
Namespaces
Redes
NetworkLoggings
PodDisruptionBudgets
Provedores

Papéis
RoleBindings
Serviços
StorageClasses
ValidatingWebhookConfigurations

Quais manifestos não são verificados

Por design, alguns manifestos são excluídos da análise. 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 complementos também ignora alguns recursos e campos de recursos, porque esperamos que eles sejam alterados e não queremos que as mudanças ativem erros de desvio de configuração. Por exemplo, a verificação ignora os campos replicas em implantações, porque o autoescalador pode modificar esse valor.

Como excluir outros manifestos ou partes deles da análise

Em geral, recomendamos que você não faça mudanças nos recursos gerenciados pelo Google Distributed Cloud ou ignore as mudanças feitas neles. No entanto, sabemos que os recursos às vezes precisam de modificações para atender a requisitos de casos específicos ou corrigir problemas. Por esse motivo, fornecemos um ConfigMap ignore-config-drift para cada cluster na sua frota. Use esses ConfigMaps para especificar recursos e campos de recursos específicos a serem excluídos da avaliação.

O Google Distributed Cloud cria um ConfigMap ignore-config-drift para cada cluster. Esses ConfigMaps estão localizados no cluster de administração (administrador ou híbrido) no namespace correspondente. Por exemplo, se você tiver um cluster de administrador (admin-one) que gerencia dois clusters de usuário (user-one e user-two), poderá encontrar o ConfigMap ignore-config-drift para o cluster user-one no cluster admin-one no namespace cluster-user-one.

Para excluir um recurso ou campos de recursos da análise:

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

Esse campo recebe uma matriz de strings JSON, com cada string especificando um recurso e, opcionalmente, campos específicos no recurso.
Especifique o recurso e, opcionalmente, os campos específicos a serem ignorados como um objeto JSON na matriz de strings:

O objeto JSON de 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:
- RESOURCE_VERSION: (opcional) o valor apiVersion do recurso.
- RESOURCE_KIND: (opcional) o valor kind do recurso.
- RESOURCE_NAMESPACE: (opcional) o valor metadata.namespace do recurso.
- RESOURCE_NAME: (opcional) o valor metadata.name do recurso.
- FIELD_NAME: (opcional) especifique uma matriz de campos de recursos a serem ignorados. Se você não especificar nenhum campo, a verificação de complementos vai ignorar todas as mudanças no recurso.
Cada um dos campos no objeto JSON é opcional, então várias permutações são permitidas. É possível excluir categorias inteiras de recursos ou ser muito preciso e excluir campos específicos de um recurso específico.

Por exemplo, se você quiser que a verificação de complementos ignore as mudanças na seção command da implantação ais no cluster de administrador, o JSON poderá ter a seguinte aparência:
```
{
  "Version": "apps/v1",
  "Kind": "Deployment",
  "Namespace": "anthos-identity-service",
  "Name": "ais",
  "Fields": [
    "command"
  ]
}
```
Você adicionaria esse objeto JSON a ignore-resources no ConfigMap config-drift-ignore como um valor de string em uma matriz, conforme mostrado no exemplo abaixo:
```
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"]}]'
  ...
```
Esse exemplo de configuração do ConfigMap permite adicionar, remover ou editar campos command na implantação ais sem acionar erros de desvio de configuração. No entanto, as edições em campos fora da seção command na implantação ainda são detectadas pela verificação de complementos e informadas como desvio de configuração.

Se você quiser excluir todas as implantações, o valor ignore-resources poderá ser semelhante a este:
```
...
data:
  ignore-resources: '[{"Kind":"Deployment"}]'
...
```
Como ignore-resources aceita uma matriz de strings JSON, é possível especificar vários padrões de exclusão. Se você estiver resolvendo problemas ou testando seus clusters e não quiser acionar erros de desvio de configuração, essa flexibilidade para excluir recursos muito específicos e campos de recursos ou categorias mais amplas de recursos da detecção de desvio pode ser útil.

Verificações de integridade

O que é verificado?

Verificações da máquina do nó

Verificações no cluster

Verificações de rede

Kubernetes

Complementos

Recursos personalizados HealthCheck

Cron jobs de verificação de integridade

Registros de verificação de integridade

Conferir registros localmente

Ver registros no Cloud Logging

Verificações de integridade periódicas

Desativar verificações de integridade periódicas

Reativar as verificações de integridade periódicas

Verificações de integridade sob demanda

Complementos

Cluster

Configuração

Conectividade com Google Cloud

Kubernetes

Nós

Simulação

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

Executar as verificações de integridade mais recentes

Detecção de desvio de configuração

Quais manifestos são verificados

Quais manifestos não são verificados

Como excluir outros manifestos ou partes deles da análise

A seguir

Recursos personalizados `HealthCheck`