Verificações de integridade do cluster

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 periodicamente por conta própria. Também é possível usar gkectl diagnose cluster para executar verificações de integridade sob demanda. Neste documento, descrevemos 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 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 da máquina do nó

Nesta seção, descrevemos o que é avaliado pelas verificações de integridade para máquinas de nós. Essas verificações confirmam que as máquinas de nós estão configuradas corretamente e que têm recursos e conectividade suficientes para a criação, upgrades e 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 HealthCheckrecursos personalizados.

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

• 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á funcionando (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 de máquina Google Cloud consistem no seguinte:

• O Artifact 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 no seguinte:

• 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 de nós, consulte Requisitos de CPU, RAM e armazenamento.

Verificações em todo o cluster

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

Verificações padrão

As verificações de cluster padrão, que são executadas automaticamente como parte das verificações de integridade periódicas, também podem ser executadas sob demanda como parte das verificações de integridade do cluster. Essas verificações garantem que os recursos do cluster do Kubernetes estejam configurados corretamente e funcionando de maneira adequada.

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

As verificações de cluster padrão auditam os seguintes tipos de recursos e condições:

• DaemonSet

  • As configurações são válidas
  • Os DaemonSets estão íntegros

• Implantação

  • As configurações são válidas
  • As implantações estão íntegras

• Nó (as seguintes são todas as condições de nó)

  • Status de prontidão do nó
  • Pressão de disco do kubelet
  • Pressão da memória do kubelet
  • Pressão do ID do processo (PID) do kubelet
  • frequência de reinicialização do kubelet
  • o kubelet está íntegro
  • Disponibilidade da rede
  • função containerd
  • Frequência de reinicialização do containerd
  • Função Docker Overlay2
  • Frequência de reinicialização do Docker
  • Frequência de eventos de cancelamento de registro de dispositivos de rede
  • Impasse do kernel
  • O KubeProxy está íntegro
  • Sistema de arquivos somente leitura

• Pod

  • As configurações são válidas
  • Os pods estão íntegros
  • Os contêineres estão íntegros

• PodDisruptionBudget (PDB)

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

• Solicitações de recursos

  • Os pods nos nós de destino têm solicitações de CPU e memória definidas
  • A solicitação média de recursos por nó está dentro do limite monitorado

• Serviço

  • As configurações são válidas
  • Os serviços estão íntegros

• StatefulSet

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

Verificações de rede

As seguintes verificações de rede do nó do cluster do lado do cliente são executadas automaticamente como parte das verificações de integridade periódicas. Não é possível executar verificações de rede on demand. 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 recursos de verificação de integridade, consulte recursos personalizados do HealthCheck.

• Se o cluster usar o balanceamento de carga em pacote, os nós no pool de nós de balanceamento de carga precisarão ter conectividade do protocolo de resolução de endereços (ARP) da 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 nos seus clusters, consulte Regras de proxy e firewall.

Kubernetes

As verificações do Kubernetes, que são executadas automaticamente como parte das verificações de simulação e de integridade periódicas, também podem ser executadas sob demanda. Essas verificações de integridade não retornam um erro se algum dos componentes listados do plano de controle estiver ausente. A verificação só retorna 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-kubernetesresources em execução no cluster de administrador no namespace do cluster. Para mais informações sobre recursos de verificação de integridade, consulte HealthCheckrecursos personalizados.

• O servidor de API está funcionando.

• O operador anetd está configurado corretamente.

• Todos os nós do plano de controle estã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 simulação e de integridade periódicas e podem ser executadas sob demanda. Essa verificação de integridade não retorna um erro se algum dos complementos listados estiver faltando. 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 chamados bm-system-add-ons*resources em execução no cluster de administrador no namespace do cluster. Para mais informações sobre recursos de verificação de integridade, consulte HealthCheckrecursos personalizados.

• Os componentes do Stackdriver do Cloud Logging e o agente do Connect estã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

  • Nenhum campo opcional foi adicionado ou removido

  • Os recursos não foram excluídos

Se a verificação de integridade detectar uma deriva 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 os recursos que mudaram, incluindo as seguintes informações:

• Version: a versão da API para o recurso.
• Kind: o esquema de 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.

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 do HeathCheck:

• Recursos personalizados do Bare Metal HealthCheck (API Version: baremetal.cluster.gke.io/v1): fornecem detalhes sobre verificações de integridade periódicas. Esses recursos estão no cluster de administrador em namespaces do cluster. Os recursos do Bare Metal HealthCheck são responsáveis por criar jobs e cron jobs 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 feitas com o melhor esforço. 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:

Verificações de integridade do Bare Metal	Verificações de integridade do Anthos	Gravidade
Tipo: padrã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: padrã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: machine Nome: bm-system-NODE_IP_ADDRESS-machine	Tipo: machine Nome: bm-system-NODE_IP_ADDRESS-machine	Crítico
Tipo: network Nome: bm-system-network	Tipo: network Nome: bm-system-network	Crítico
Tipo: kubernetes Nome: bm-system-kubernetes	Tipo: kubernetes Nome: bm-system-kubernetes	Crítico
Tipo: add-ons Nome: bm-system-add-ons	Tipo: add-ons Nome: bm-system-add-ons-add-ons Nome: bm-system-add-ons-configdrift	Opcional

Para recuperar o status do HealthCheck:

1. Para ler os resultados das verificações de integridade periódicas, extraia 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
   

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

3. Para receber uma lista de verificações de integridade 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 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-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
   

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 seguro (SSH) com os nós.

Para recuperar informações sobre cron jobs:

1. 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 após a hora (17) a cada hora (*/1) de todos os dias (* * *). Os intervalos de tempo para verificações de integridade periódicas não podem ser editados, 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ê executa verificações de integridade com gkectl diagnose cluster ou elas são executadas automaticamente como parte de verificações periódicas, os registros são enviados ao Cloud Logging. Quando você executa verificações de integridade sob demanda, os arquivos de registro são criados em /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log.

Ver registros localmente

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

1. Receba 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 exemplo 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.

   O exemplo a seguir mostra parte de um registro de pod para uma verificação de integridade bem-sucedida da máquina do nó:

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

consulta de registros no Cloud Logging

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

1. No console Google Cloud , acesse a página Explorador de registros no menu Geração de registros.

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

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

• Padrão

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

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

• Padrão
• Máquina
• Rede
• Kubernetes
• Complementos

Para verificar a integridade do cluster, consulte 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 feitas 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 recursos do Bare Metal HealthCheck 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.

  Confira a seguir um exemplo de resposta:

  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 aprovada (true) ou falhou (false).

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

Verificações de integridade sob demanda

Para executar verificações de integridade sob demanda, use o comando gkectl diagnose cluster. Ao usar o gkectl diagnose cluster para executar verificações de integridade, as seguintes regras se aplicam:

• Ao verificar um cluster de usuário com um comando gkectl diagnose cluster, especifique o caminho do arquivo kubeconfig do cluster de administrador com a flag --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 de administrador (por padrão, /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log).

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

Detecção de desvio de configuração

Quando a verificação de integridade de 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 alertar sobre mudanças inadvertidas que podem prejudicar a integridade do cluster. Elas também fornecem informações valiosas para a solução de problemas.

Quais manifestos são verificados

Com algumas exceções, a verificação de integridade dos complementos analisa todos os recursos gerenciados pelo Google Distributed Cloud nos 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 a desvio 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, excluímos alguns manifestos da análise. Ignoramos tipos específicos de recursos, como certificados, secrets 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 acionem erros de desvio de configuração. Por exemplo, a verificação ignora campos replicas em implantações, porque o autoescalador pode modificar esse valor.

Como excluir outros manifestos ou partes deles da revisão

Em geral, recomendamos que você não faça mudanças nos recursos gerenciados pelo Google Distributed Cloud nem ignore as mudanças feitas neles. No entanto, sabemos que, às vezes, os recursos precisam de modificações para atender a requisitos exclusivos de casos ou corrigir problemas. Por isso, 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 gerenciamento (administrador ou híbrido) no namespace do cluster 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:

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

   Esse campo recebe uma matriz de strings JSON, em que cada string especifica um recurso e, opcionalmente, campos específicos no recurso.

2. 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 apenas as mudanças na seção command da implantação ais no cluster de administrador, o JSON pode ter esta aparência:

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

   Adicione esse objeto JSON a ignore-resources no ConfigMap config-drift-ignore como um valor de string em uma matriz, conforme mostrado no exemplo a seguir:

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

   Essa configuração de 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 segmentados e campos de recursos ou categorias mais amplas de recursos da detecção de desvio pode ser útil.

A seguir

Para ver mais informações, consulte os seguintes tópicos:

• Criar snapshots de diagnóstico quando o cluster avançado estiver ativado

• Entenda o impacto das falhas no Google Distributed Cloud

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:

• Requisitos para abrir um caso de suporte.
• Ferramentas para ajudar você a resolver problemas, como registros e métricas.
• Componentes, versões e recursos compatíveis do Google Distributed Cloud para VMware (somente software).