Noções básicas sobre as verificações de simulação

Esta página é destinada a operadores de infraestrutura ou administradores de plataforma.

No modo particular do Anthos, é possível executar verificações de simulação para diferentes situações:

O modo particular do Anthos executa verificações de simulação quando você cria ou atualiza clusters de administrador ou de usuário e recursos de pool de nós com actl. Se as verificações falharem, nenhuma alteração será feita. Também é possível ignorar essas verificações.
O modo particular do Anthos executa verificações de simulação internas quando você aplica recursos do Kubernetes a clusters de usuários provenientes de um cluster de administrador. 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. Também é possível ignorar essas verificações ou executá-las de maneira explícita.

Preparar verificações ao criar clusters usando `actl`

Quando você cria clusters de administrador ou de usuário com o comando actl, o modo particular do Anthos executa automaticamente verificações de simulação antes que qualquer alteração seja feita.

Quando as verificações são aprovadas, o modo particular do Anthos cria os clusters.

Ignorar os resultados das verificações automáticas de simulação

Se você quiser ignorar essas verificações de simulação automatizadas, use a sinalização opcional --force no comando.

Executar verificações de simulação de forma independente

Também é possível executar verificações de simulação antes da criação do cluster. Isso pode ajudar a economizar tempo garantindo que os recursos do seu nó e da sua máquina sejam aprovados nas verificações.

Esse comando verifica se as máquinas e a rede estão prontas para a criação do cluster:

actl clusters baremetal check preflight CLUSTER_NAME

Verificações de simulação para criação do cluster de usuário

Clusters de usuário são criados com base em um cluster de administrador existente. O modo particular do Anthos executa automaticamente verificações de simulação antes de fazer qualquer alteração. Também é possível executar verificações de simulação com kubectl antes de criar um cluster.

Crie um arquivo de configuração do cluster de usuário seguindo o arquivo de configuração de usuário de amostra.
Crie um namespace para o novo cluster de usuário. Por exemplo, para criar um novo cluster de usuário chamado user1, crie um namespace chamado cluster-user1. Este é o comando kubectl para criar o namespace, em que ADMIN_KUBECONFIG especifica o caminho para o arquivo kubeconfig do cluster de administrador:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create namespace cluster-user1
```
Faça upload do arquivo de chave privada SSH no novo namespace como um secret para estabelecer suas credenciais. Aqui está o comando de amostra, em que ADMIN_KUBECONFIG especifica o caminho para o arquivo kubeconfig do cluster de administrador e SSH_PRIVATE_KEY_FILE_PATH especifica o caminho para o arquivo de chave privada SSH:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create secret generic ssh-key -n cluster-user1 --from-file=id_rsa=SSH_PRIVATE_KEY_FILE_PATH
```
Crie um novo arquivo YAML de verificação de simulação com a estrutura a seguir: No campo configYAML, insira o conteúdo de texto do arquivo de configuração do cluster de usuário criado na etapa 1:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: PreflightCheck
metadata:
generateName: preflightcheck-
namespace: cluster-user1
spec:
configYAML: |
# insert user cluster config file content here.
```
O comando kubectl a seguir executa a verificação de simulação do cluster de usuário, em que ADMIN_KUBECONFIG especifica o caminho para o arquivo kubeconfig do cluster de administrador e USER_CLUSTER_PREFLIGHT_CHECK_CONFIG especifica o caminho para o teste antecipado do arquivo YAML criado na etapa anterior:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f USER_CLUSTER_PREFLIGHT_CHECK_CONFIG
```
Por exemplo, para uma configuração de verificação de simulação do cluster de usuário chamada user1-preflight.yaml, o comando é:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f user1-preflight.yaml
```
O sistema retorna a seguinte mensagem, com o ID da verificação de simulação:
```
preflightcheck.baremetal.cluster.gke.io/preflightcheck-g7hfo4 created
```

Consulte o status do job de verificação de simulação usando o comando kubectl:

kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-user1 get preflightchecks preflightcheck-g7hfo4

Se o job de verificação de simulação falhar, verifique o status dele e verifique os registros detalhados do job para ver qual falhou. Corrija os problemas mencionados nos jobs adequadamente e execute as verificações novamente.

Verificações de simulação interna em clusters atuais

O modo particular do Anthos também executa verificações de simulação internas quando você aplica recursos Cluster do Kubernetes a um cluster de administrador atual. Se alguma verificação falhar, o modo particular do Anthos não fará alterações nos nós relacionados, a menos que você tenha ignorado especificamente as verificações.

Ignorar verificações de simulação ao aplicar recursos do Kubernetes

Para ignorar as verificações de simulação internas ao aplicar recursos Cluster a um cluster de administrador atual, é necessário definir o campo BypassPreflightCheck como true no recurso do cluster.

Este é um fragmento de um arquivo YAML de configuração do cluster, mostrando o campo bypassPreflightCheck definido como true.

# Sample cluster config to bypass preflight check errors:

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

Reativar verificações de simulação

É possível acionar explicitamente uma nova rodada de verificações de simulação para que o modo particular do Anthos possa atualizar ou criar novos clusters após a conclusão da verificação de simulação.

Crie um novo arquivo YAML de verificação de simulação com o conteúdo a seguir. Preencha os campos namespace e clusterName com o nome do cluster que você está criando:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: PreflightCheck
metadata:
generateName: preflightcheck-
namespace: CLUSTER_NAMESPACE
spec:
clusterName: CLUSTER_NAME
```
Emita o comando kubectl para executar a verificação de simulação do cluster, em que ADMIN_KUBECONFIG especifica o caminho para o arquivo kubeconfig do cluster de administrador e CLUSTER_PREFLIGHT_CHECK_CONFIG especifica o caminho para o arquivo YAML da verificação de simulação criado anteriormente:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f CLUSTER_PREFLIGHT_CHECK_CONFIG
```
Por exemplo, para uma configuração de verificação de simulação do cluster de usuário chamada user1-preflight.yaml, o comando é:
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f user1-preflight.yaml
```
O sistema responde com o ID do job da verificação de simulação:
```
preflightcheck.baremetal.cluster.gke.io/preflightcheck-g7hfo4 created
```

Consulte o ID de status do job de verificação de simulação usando o comando kubectl:

kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-cluster1 get preflightchecks preflightcheck-g7hfo4

Após a conclusão do job de verificação de simulação, o modo particular do Anthos cria o cluster e os recursos dele.

Detalhes da verificação de simulação da instalação

O modo particular do Anthos verifica uma variedade de condições de pré-requisito de máquina, sistema operacional e software ao executar verificações de simulação.

Para informações mais detalhadas, consulte Requisitos.

Verificações de simulação de autenticação

Para fins de autenticação, as verificações de simulação verificam a configuração do OpenID Connect (OIDC) para evitar a aplicação de um perfil incorreto.

Essas verificações incluem o ping do endpoint OIDC usando o mecanismo de descoberta OIDC em /.well-known/openid-configuration.

A seguir

Criar clusters de usuários.