As verificações de simulação são uma medida preventiva para ajudar a identificar problemas antes de você iniciar uma operação importante de cluster, como a criação ou o upgrade de clusters. Quando essas verificações são executadas automaticamente antes de uma operação, nenhuma alteração é feita nos clusters, a menos que a simulação seja aprovada. Também é possível executar verificações de simulação sob demanda.
Este documento descreve cada verificação, em que circunstâncias ela é executada automaticamente, como e quando executá-la manualmente e como interpretar os resultados.
No GDCV para Bare Metal, é possível executar verificações de simulação para diferentes situações:
O GDCV para Bare Metal executa verificações de simulação quando você cria ou faz upgrade de clusters e recursos de pool de nós com
bmctl. Se as verificações falharem, nenhuma alteração será feita. Também é possível ignorar essas verificações ou executá-las explicitamente.O GDCV para Bare Metal também executa verificações internas de simulação quando um cluster de administrador ou híbrido cria ou atualiza recursos do Kubernetes em clusters de usuário. As verificações são executadas antes que as alterações sejam aplicadas aos clusters de usuário afetados. Se as verificações falharem, nenhuma alteração será feita.
PreflightCheck recursos personalizados
Quando uma verificação de simulação é executada, o GDCV para Bare Metal cria um
recurso personalizado PreflightCheck. Os recursos personalizados PreflightCheck são permanentes e fornecem um
registro das atividades e dos resultados da verificação de simulação.
Para recuperar recursos personalizados PreflightCheck:
Acesse uma lista de verificações de simulação executadas para um determinado cluster:
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACESubstitua:
ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.CLUSTER_NAMESPACE: o namespace do cluster.
A resposta lista os recursos por namespace. É possível executar
kubectl get preflightchecksem todos os namespaces para ter uma lista abrangente. Para cada recurso, a resposta mostra a idade do recurso e se as verificações de simulação foram aprovadas ou não. O exemplo de resposta a seguir mostra recursosPreflightCheckpara o namespacecluster-test-admin001.NAMESPACE NAME PASS AGE cluster-test-admin001 test-admin001 true 52d cluster-test-admin001 test-admin001jkm4q true 52d cluster-test-admin001 test-admin001k79t7 true 6d20h cluster-test-admin001 upgrade-cluster-20231106-222746 true 6d20hRecupere os detalhes de um recurso personalizado
PreflightCheckespecífico:kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACESubstitua:
ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.CLUSTER_NAMESPACE: o namespace do cluster.
A resposta de comando de amostra a seguir mostra um recurso
PreflightCheckpara uma verificação de simulação bem-sucedida, executada como parte da criação do cluster:Name: create-cluster-20230922-175006 Namespace: cluster-test-user001 Labels: <none> Annotations: <none> API Version: baremetal.cluster.gke.io/v1 Kind: PreflightCheck Metadata: Creation Timestamp: 2023-09-22T17:50:11Z Generation: 1 Resource Version: 6502800 UID: 917daf64-963d-44b4-a1f9-c54972a39191 Spec: Check Image Version: latest Config YAML: --- apiVersion: v1 kind: Namespace metadata: name: cluster-test-user --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: test-user001 namespace: cluster-test-user001 spec: type: user profile: default anthosBareMetalVersion: 1.16.0 gkeConnect: projectID: clusters-project controlPlane: nodePoolSpec: nodes: - address: 192.0.2.53 ... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: node-pool-1 namespace: cluster-test-user001 spec: clusterName: test-user001 nodes: - address: 192.0.2.54 ... Status: Checks: 192.0.2.53: Job UID: d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c Message: Pass: true 192.0.2.53-gcp: Job UID: b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8 Message: Pass: true 192.0.2.54: Job UID: b67cf195-3951-46ad-b91c-0d79025cfc0a Message: Pass: true 192.0.2.54-gcp: Job UID: aed509e2-4bf7-44c4-bfa0-8147ef8ea74e Message: Pass: true Gcp: Job UID: ac479ac4-e1c4-4681-9f2b-5773069bf6ae Message: Pass: true Node - Network: Job UID: 8a57c4ee-ad17-4560-8809-b117c871ad5d Message: Pass: true Pod - Cidr: 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 ... Completion Time: 2023-09-22T17:51:22Z Conditions: Last Transition Time: 2023-10-02T23:59:06Z Observed Generation: 1 Reason: Reconciling Status: True Type: Reconciling Node Pool Specs: node-pool-1: Cluster Name: test-user001 Nodes: Address: 192.0.2.54 ... Pass: true Start Time: 2023-09-22T17:50:32Z Events: <none>No recurso personalizado
PreflightCheckanterior, a seçãoStatuscontém as seguintes informações:- A seção
Checkslista verificações de simulação individuais que foram executadas e se elas foram aprovadas ou não. Neste exemplo, as seguintes verificações foram executadas:192.0.2.53e192.0.2.54: verificações de nós (configuração do SO, recursos e configurações de software) para máquinas com endereços IP192.0.2.53e192.0.2.54.192.0.2.53-gpce192.0.2.54-gcp: verificações de conectividade do Google Cloud (acesso ao Container Registry e à API do Google) para máquinas com endereços IP192.0.2.53e192.0.2.54.Gcp: a conectividade do Google Cloud verifica o cluster.Node - Network: verificações de rede (conectividade, operaçãoetcd, acesso VIP e vinculação de porta) para o cluster.Pod - Cidr: o endereço IP do pod verifica se há endereços sobrepostos no cluster.
- A seção
Cluster Specmostra a configuração do cluster. - O campo
Passmostratrue, indicando que as verificações de simulação foram aprovadas coletivamente.
Registros de verificação de simulação
Quando as verificações de simulação são executadas como resultado de um comando bmctl, como bmctl check
preflight, o GDCV para Bare Metal cria arquivos de registros. Veja o que é gerado
e onde:
Os registros de verificação de simulação são gerados em um diretório com o seguinte padrão de nomenclatura
preflight-TIMESTAMP.Esse diretório de simulação é criado no diretório
logdo cluster no espaço de trabalhobmctl. Por padrão, o caminho do diretóriologébmctl-workspace/CLUSTER_NAME/log.Os registros de simulação consistem nos seguintes arquivos:
Arquivos de registros das verificações da máquina do nó, um para cada nó do cluster. Esses arquivos de registro são nomeados usando o endereço IP do nó. Por exemplo, um nome de arquivo pode ser
192.0.2.53.Arquivos de registros das verificações de acesso do Google Cloud, um para cada nó do cluster. Esses arquivos de registro são nomeados usando o endereço IP do nó. Por exemplo, um nome de arquivo pode ser
192.0.2.53-gcp.Arquivo de registros das verificações de acesso do cluster do Google Cloud, denominado
gcp.Arquivo de registro para verificações de rede de nós, chamado
node-network.
Se uma verificação de simulação falhar, esses arquivos de registro poderão ajudar você a identificar e resolver o problema.
Verificações de simulação para criação de clusters
Quando você cria clusters, a GDCV para Bare Metal executa automaticamente verificações de simulação antes que qualquer alteração seja feita.
O que é verificado?
As verificações de simulação para instalação verificam o seguinte:
Verificações de máquina do nó:
As máquinas de cluster estão usando um sistema operacional (SO) com suporte.
A versão do SO é suportada.
O SO está usando uma versão do kernel com suporte.
No Ubuntu, o Uncomplicated Firewall (UFW) está desativado.
Para o Ubuntu, o gerenciador de pacotes
apté operável e os pacotes necessários estão disponíveis.Para o Red Hat Enterprise Linux, o gerenciador de pacotes
dnfé operável e os pacotes necessários estão disponíveis.Para o Red Hat Enterprise Linux, o Podman não está instalado.
Máquinas de nós atendem aos requisitos mínimos de CPU.
As máquinas de nós atendem aos requisitos mínimos de memória.
Máquinas de nós atendem aos requisitos mínimos de armazenamento em disco.
A sincronização de tempo é configurada nas máquinas de nós.
kubeletestá ativo e em execução nas máquinas de nós.containerdestá ativo e em execução nas máquinas de nós.A rota padrão para rotear pacotes para o gateway padrão está presente nos nós.
O Sistema de Nomes de Domínio (DNS) está funcionando corretamente. Se o cluster estiver configurado para ser executado atrás de um proxy, essa verificação será ignorada.
Os CIDRs do pod não se sobrepõem aos endereços IP da máquina do nó.
Se o cluster estiver configurado para usar um espelho de registro, o espelho de registro poderá ser acessado.
O Google Cloud verifica o cluster e cada nó:
Container Registry,
gcr.io, a acessibilidade está verificada. Se o cluster estiver configurado para usar um espelho de registro, essa verificação será ignorada.As APIs do Google podem ser acessadas.
Verificações de rede de nós (variam com base na configuração do balanceamento de carga):
O VIP do servidor da API Kubernetes está acessível.
Os VIPs do balanceador de carga são acessíveis.
Os nós podem se comunicar nas portas necessárias.
A instância de eventos
etcdé provisionada e os requisitos de porta são atendidos.
Quando todas as verificações forem aprovadas, o GDCV para Bare Metal criará o cluster. Para mais informações sobre os requisitos para criar clusters, consulte a Visão geral dos pré-requisitos de instalação.
Executar verificações de simulação sob demanda para criação de clusters
Também é possível executar verificações de simulação de maneira independente, antes de criar um cluster. Isso pode ser benéfico porque as principais operações de cluster, como a criação de cluster, são demoradas. Identificar e resolver problemas separadamente antes de iniciar uma operação de cluster importante pode ajudar na programação.
Clusters autogerenciados
O comando a seguir valida o arquivo de configuração do cluster especificado, mas não tenta criar o cluster em si:
bmctl check config --cluster CLUSTER_NAMESubstitua
CLUSTER_NAMEpelo nome do cluster associado ao arquivo de configuração que você está verificando.Este comando verifica se as máquinas e a rede estão prontas para a criação do cluster:
bmctl check preflight --cluster CLUSTER_NAMESubstitua
CLUSTER_NAMEpelo nome do cluster que você está verificando.
Clusters de usuários
O comando a seguir valida o arquivo de configuração do cluster especificado, mas não tenta criar o próprio cluster:
bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIGSubstitua:
CLUSTER_NAME: o nome do cluster de usuário que você está verificando.ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador associado.
O comando a seguir verifica se as máquinas e a rede estão prontas para a criação do cluster:
bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
bmctl oferece suporte ao uso de --kubeconfig como um alias para
a sinalização --admin-kubeconfig.
Verificações de simulação para upgrades de cluster
Quando você faz upgrade de clusters, o GDCV para Bare Metal executa automaticamente verificações de simulação antes que qualquer alteração seja feita.
O que é verificado?
As verificações de simulação para upgrades de cluster verificam o seguinte:
Verificações de máquina do nó:
As máquinas de cluster estão usando um sistema operacional (SO) com suporte.
A versão do SO é suportada.
O SO está usando uma versão do kernel com suporte.
No Ubuntu, o Uncomplicated Firewall (UFW) está desativado.
Máquinas de nós atendem aos requisitos mínimos de CPU.
As máquinas de nó têm mais de 20% dos recursos de CPU disponíveis.
As máquinas de nós atendem aos requisitos mínimos de memória.
Máquinas de nós atendem aos requisitos mínimos de armazenamento em disco.
A sincronização de tempo é configurada nas máquinas de nós.
A rota padrão para rotear pacotes para o gateway padrão está presente nos nós.
O Sistema de Nomes de Domínio (DNS) está funcionando corretamente. Se o cluster estiver configurado para ser executado atrás de um proxy, essa verificação será ignorada.
Se o cluster estiver configurado para usar um espelho de registro, o espelho de registro poderá ser acessado.
* Nenhum nó do plano de controle ou do balanceador de carga está no modo de manutenção.
O Google Cloud verifica o cluster e cada nó:
Container Registry,
gcr.io, a acessibilidade está verificada. Se o cluster estiver configurado para usar um espelho de registro, essa verificação será ignorada.As APIs do Google podem ser acessadas.
Verificações de máquina:
kubeletestá ativo e em execução nas máquinas de nós.containerdestá ativo e em execução nas máquinas de nós.O status do endpoint de integridade da interface de rede de contêineres (CNI, na sigla em inglês) é íntegro.
Os CIDRs do pod não se sobrepõem aos endereços IP da máquina do nó.
Verificações de rede de nós (variam com base na configuração do balanceamento de carga):
O VIP do servidor da API Kubernetes está acessível.
Os VIPs do balanceador de carga são acessíveis.
Os nós podem se comunicar nas portas necessárias.
A instância de eventos
etcdé provisionada e os requisitos de porta são atendidos.
Quando todas as verificações forem aprovadas, o GDCV para Bare Metal fará o upgrade do cluster. Para mais informações sobre como fazer upgrade de clusters, consulte Práticas recomendadas de GDCV para upgrades de cluster Bare Metal e Ciclo de vida e estágios dos upgrades de cluster.
Executar verificações de simulação sob demanda para upgrades de cluster
O comando bmctl check preflight permite executar uma verificação de simulação antes de fazer upgrade do cluster. Para verificar se os clusters estão prontos para um upgrade,
execute o seguinte comando de verificação de simulação antes de iniciar o upgrade:
Atualize a versão do cluster (
anthosBareMetalVersion) no arquivo de configuração do cluster.Use o comando a seguir para conferir se os clusters estão prontos para um upgrade e execute uma verificação de simulação:
bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGSubstitua:
CLUSTER_NAME: o nome do cluster a se fazer upgrade.ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
Quando você cria a verificação de simulação com esse comando para testar um upgrade do cluster, um recurso personalizado
PreflightChecké criado no cluster de administrador.
Verificações de simulação interna em clusters atuais
O GDCV para Bare Metal executa verificações internas de simulação automaticamente quando você aplica recursos do Kubernetes a um cluster atual. Se alguma verificação falhar, a GDCV para Bare Metal não vai mudar nenhum dos nós relacionados, a menos que você ignore as verificações explicitamente.
Ignorar verificações de simulação ao aplicar recursos do Kubernetes
Para ignorar as verificações internas de simulação ao aplicar recursos a clusters atuais, defina o campo BypassPreflightCheck como true no
arquivo de configuração do cluster.
Esta é parte de um arquivo de configuração do cluster que mostra o campo bypassPreflightCheck definido como true:
apiVersion: v1
kind: Namespace
metadata:
name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user1
namespace: cluster-user1
spec:
type: user
bypassPreflightCheck: true
# Anthos cluster version.
anthosBareMetalVersion: 1.28.400-gke.77
...
Executar as verificações de simulação e de integridade mais recentes
Ao usar bmctl para executar verificações de integridade ou de simulação, é possível adicionar a
flag --check-image-version latest ao comando para realizar as
verificações da versão mais recente do patch Bare Metal do GDCV para
os testes. Isso pode ajudar você
a identificar problemas conhecidos sem criar ou fazer upgrade do cluster antes.
Para usar a lista de verificações mais recente a fim de determinar se as máquinas e a rede estão prontas para a criação de clusters:
bmctl check preflight --cluster CLUSTER_NAME --check-image-version latestSubstitua
CLUSTER_NAMEpelo nome do cluster que você está verificando.
Você também pode executar as verificações de integridade mais recentes de um cluster ativo para determinar se ele está íntegro.
Para realizar as verificações de integridade mais atualizadas em um cluster ativo:
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latestSubstitua
CLUSTER_NAMEpelo nome do cluster que você está verificando.
Ignorar os resultados das verificações automáticas de simulação
Se você executar verificações de simulação sob demanda antes de criar ou fazer upgrade de clusters, será possível ignorar as verificações de simulação automatizadas. Para ignorar as verificações de simulação automatizadas,
use a sinalização opcional --force ao executar bmctl create cluster ou
bmctl upgrade cluster.