As verificações de integridade são uma maneira de testar e monitorar a operação dos clusters
atuais. As verificações de integridade são executadas sozinhas e 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 executá-la 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 em máquinas de nós. Essas verificações confirmam se 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 HealthCheck
recursos personalizados.
As verificações comuns por máquina consistem no seguinte:
As máquinas do cluster usam um sistema operacional (SO) compatível.
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ós atendem aos requisitos mínimos de CPU.
As máquinas de nós têm mais de 20% dos recursos da CPU disponíveis.
As máquinas de nós atendem aos requisitos mínimos de memória.
As máquinas de nós atendem aos requisitos mínimos de armazenamento em disco.
A sincronização de tempo é configurada em máquinas de nó.
A rota padrão para rotear pacotes para o gateway padrão está presente em 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 atrás de um proxy.
Se o cluster estiver configurado para usar um espelho de registro, esse espelho pode ser acessado.
As verificações do Google Cloud por máquina consistem em:
O Container Registry,
gcr.io
, pode ser acessado. Essa verificação será 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ó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êiner (CNI, na sigla em inglês) está í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 seguintes verificações de rede de nós de cluster do lado do cliente são executadas automaticamente como parte
de verificações de integridade periódicas. Verificações de rede não podem ser executadas 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
HealthCheck
.
Se o cluster usar balanceamento de carga em pacote, os nós no pool de nós de balanceamento de carga precisarão ter conectividade com o protocolo de resolução de endereços (ARP, na sigla em inglês) 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 dos seus clusters do Google Distributed Cloud, 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 a 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 de verificações de integridade de simulação e periódicas, também podem ser executadas sob demanda. Essas verificações de integridade não retornarão um erro se algum dos componentes do plano de controle listados 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-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 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 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ó vai retornar 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*
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 podem ser usados:
stackdriver-log-aggregator
stackdriver-log-forwarder
stackdriver-metadata-agent
stackdriver-prometheus-k8
gke-connect-agent
Os recursos gerenciados pelo Google Distributed Cloud não apresentam 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 desvios de configuração, o valor Status.Pass
do recurso personalizado
HealthCheck
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 do recurso.Kind
: o esquema do objeto, comoDeployment
, 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 do recurso registrado e o do recurso alterado.
HealthCheck
recurso personalizado
Quando uma verificação de integridade é executada, o Google Distributed Cloud cria um recurso
personalizado HealthCheck
. Os recursos personalizados do HealthCheck
são persistentes 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
(API Version: baremetal.cluster.gke.io/v1
) em Bare Metal: esses recursos fornecem detalhes sobre verificações de integridade periódicas. Esses recursos estão no cluster de administrador em namespaces de cluster. Os recursosHealthCheck
do Bare Metal são responsáveis pela criação de 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 namespacekube-system
de cada cluster. Atualizar esses recursos é o melhor esforço. Se uma atualização falhar para um problema, como um erro de rede temporário, a falha será ignorada.
A tabela abaixo lista os tipos de recursos criados para a
categoria HealthCheck
:
Verificações de integridade bare metal | Verificações de integridade do GKE Enterprise | Gravidade |
---|---|---|
Tipo: machine
Nome: |
Tipo: machine
Nome: |
Crítica |
Tipo: rede
Nome: |
Tipo: rede
Nome: |
Crítica |
Tipo: kubernetes
Nome: |
Tipo: kubernetes
Nome: |
Crítica |
Tipo: complementos
Nome: |
Tipo: complementos
Nome:
Nome: |
Opcional |
Para recuperar o status de HealthCheck
:
Para ler os resultados das verificações de integridade periódicas, acesse 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 quando foram executadas pela última vez:
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.
Quando você revisa 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 agendado e instrumentado.
O exemplo de
HealthCheck
a seguir serve 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 é referente a 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 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.Veja na amostra a seguir 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 uma
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:
Receba uma lista de cron jobs executados em 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 do cronograma. Por exemplo, o jobbm-system-kubernetes
é executado 17 minutos após a hora (17
) a cada hora (*/1
) de todos os dias (* * *
). Os intervalos de tempo das verificações de integridade periódicas não são editáveis, mas é útil para resolver problemas saber quando elas precisam ser executadas.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 registros serã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
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
É possível usar kubectl
para ver os registros de verificações de integridade periódicas:
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 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
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 da máquina do nó com falha. O exemplo mostra que a verificação de
kubelet
(check_kubelet_pass
) falhou, indicando quekubelet
não está em execução nesse 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. 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.
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ó.
Aqui está uma lista de consultas para verificações de integridade periódicas:
Máquina de nós
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"
Rede
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-network.*"
Kubernetes
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-kubernetes.*"
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:
É possível verificar a integridade do cluster consultando os recursos personalizados HealthCheck
(healthchecks.baremetal.cluster.gke.io
) 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. 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 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
dehealthchecks.baremetal.cluster.gke.io
indica se a última verificação de integridade foi aprovada (true
) ou falhou (false
).
Para mais informações 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:
Edite o arquivo de configuração do cluster, adicione o campo
periodicHealthCheck.enable
à especificação do cluster e defina o valor comofalse
: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 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ê desativou as verificações de integridade periódicas, é possível 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, adicione o campo
periodicHealthCheck.enable
à especificação do cluster e defina o valor comotrue
: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 comando abaixo e confirme 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
regras a seguir 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 sinalização--kubeconfig
.Os registros são gerados em um diretório com data e hora na pasta de registros do cluster na estação de trabalho do administrador (por padrão,
bmctl-workspace/CLUSTER_NAME/log
).Os registros de verificação de integridade também são enviados ao Cloud Logging. Para mais informações sobre os registros, consulte Registros de verificação de integridade.
Para mais informações sobre as opções dos comandos bmctl
, consulte a referência do comando
bmctl.
Complementos
Verifique se os complementos do Kubernetes especificados para o cluster especificado estão operáveis.
Para verificar complementos para 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 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 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 é verificado, consulte as seguintes seções na seção "O que está verificado" deste documento:
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. Para essa verificação, espera-se que o arquivo de configuração tenha sido gerado e editado para especificar os detalhes de configuração do cluster. O objetivo desse comando é determinar se
alguma definição de configuração está errada, 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 ao 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 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 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
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 vai retornar um erro se algum dos componentes do plano de controle estiver ausente. Ela só vai retornar 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 é verificado, consulte Kubernetes na seção "O que está marcado" 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 elas estão configuradas corretamente e se têm recursos e conectividade suficientes para upgrades e operação 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 conferir uma lista do que é verificado, consulte Verificações da máquina de nós na seção "O que é verificado" deste documento.
Essa verificação gera arquivos de registros para cada máquina de nó do 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 ao 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 clusters.
Verificação de simulação do ambiente de execução da VM
A verificação de simulação do ambiente de execução de VMs no Google Distributed Cloud valida um conjunto de pré-requisitos da máquina de nó
antes de usar o ambiente de execução de VM no Google Distributed Cloud e em VMs. Se
a verificação de simulação do ambiente de execução da VM no 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 de 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 Tempo de execução de VM na verificação de simulação do Google Distributed Cloud.