Version 1.6. This version is no longer supported. For more information see the version support policy.

Como criar um cluster de administrador

Nesta página, mostramos como criar um cluster de administrador para clusters do Anthos no VMware (GKE On-Prem).

As instruções aqui são completas. Para uma introdução mais rápida à criação de um cluster de administrador, consulte Criar um cluster de administração (guia de início rápido).

Antes de começar

Criar uma estação de trabalho de administrador.

Consiga uma conexão SSH para a estação de trabalho do administrador

Lembre-se de que gkeadm ativou a conta de serviço de acesso a componentes na estação de trabalho de administrador.

Realize todas as etapas restantes neste tópico na estação de trabalho de administrador no diretório inicial.

Arquivo de configuração de credenciais

Quando você usou gkeadm para criar a estação de trabalho de administrador, preencheu um arquivo de configuração de credenciais chamado credential.yaml. Esse arquivo contém o nome de usuário e a senha do servidor vCenter.

Arquivo de configuração do cluster de administrador

Quando gkeadm criou a estação de trabalho do administrador, foi gerado um arquivo de configuração chamado admin-cluster.yaml. Esse arquivo de configuração serve para criar seu cluster de administrador.

Como preencher o arquivo de configuração

`bundlePath`

Este campo já foi preenchido para você.

`vCenter`

A maioria dos campos nesse campo já está preenchida com os valores que você inseriu quando criou sua estação de trabalho de administrador. A exceção é o campo dataDisk, que precisa ser preenchido agora.

`network`

Decida como você quer que os nós de cluster recebam os endereços IP deles. As opções são:

A partir de um servidor DHCP. Defina network.ipMode.type como "dhcp".
A partir de uma lista de endereços IP estáticos fornecidos. Defina network.ipMode.type como "static" e crie um arquivo de bloco de IPs que forneça os endereços IP estáticos.

Forneça valores para os campos restantes na seção network.

Independentemente de você depender de um servidor DHCP ou de especificar uma lista de endereços IP estáticos, você precisa de endereços IP suficientes para atender às seguintes condições:

Três nós no cluster de administrador para executar o plano de controle e os complementos do cluster de administrador.
Outro nó no cluster de administrador que será usado temporariamente durante os upgrades.
Para cada cluster de usuário que você pretende criar, um ou três nós no cluster de administrador para executar os componentes do plano de controle para o cluster do usuário. Se você quiser que o plano de controle de um cluster de usuário esteja altamente disponível (HA, na sigla em inglês), precisará de três nós no cluster de administrador para o plano de controle do cluster do usuário. Caso contrário, só é necessário um nó no cluster de administrador para o plano de controle do cluster do usuário.

Por exemplo, suponha que você pretenda criar dois clusters de usuário: um com um plano de controle de alta disponibilidade e outro que não seja de alta disponibilidade. Nesse caso, você precisará de oito endereços IP para os seguintes nós no cluster de administrador:

Três nós para o plano de controle e complementos do cluster do administrador
Um nó temporário
Três nós para o plano de controle do cluster de usuário de alta disponibilidade
Um nó para o plano de controle do cluster de usuário que não é de alta disponibilidade

Conforme mencionado anteriormente, se você quiser usar endereços IP estáticos, será necessário fornecer um arquivo de bloco de IPs. Veja um exemplo de arquivo de bloco de IP com oito hosts:

blocks:
  - netmask: 255.255.252.0
    gateway: 172.16.23.254
    ips:
    - ip: 172.16.20.10
      hostname: admin-host1
    - ip: 172.16.20.11
      hostname: admin-host2
    - ip: 172.16.20.12
      hostname: admin-host3
    - ip: 172.16.20.13
      hostname: admin-host4
    - ip: 172.16.20.14
      hostname: admin-host5
    - ip: 172.16.20.15
      hostname: admin-host6
    - ip: 172.16.20.16
      hostname: admin-host7
    - ip: 172.16.20.17
      hostname: admin-host8

`loadBalancer`

Separe um VIP para o servidor da API do Kubernetes do cluster de administrador. Reserve outro VIP para o servidor de complementos. Forneça seus VIPs como valores para loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.addonsVIP.

Decida qual tipo de balanceamento de carga você quer usar. Veja as opções abaixo:

Segue o balanceamento de carga em pacote. Defina loadBalancer.kind como "Seesaw" e preencha a seção loadBalancer.seesaw.
Balanceamento de carga integrado com a F5 BIG-IP. Defina loadBalancer.kind como "F5BigIP" e preencha a seção f5BigIP.
Balanceamento de carga manual. Defina loadBalancer.kind como "ManualLB" e preencha a seção manualLB.

`antiAffinityGroups`

Defina antiAffinityGroups.enabled como true ou false de acordo com sua preferência.

`proxy`

Se a rede que terá os nós do cluster de administrador estiver atrás de um servidor proxy, preencha a seção proxy.

`privateRegistry`

Decida onde você quer manter as imagens de contêiner para os clusters do Anthos nos componentes do VMware. As opções são:

gcr.io. Não preencha a seção privateRegistry.
Seu próprio registro particular do Docker. Preencha a seção privateRegistry.

`gcrKeyPath`

Defina gcrKeyPath como o caminho do arquivo de chave JSON para sua conta de serviço de acesso ao componente.

`stackdriver`

Preencha a seção stackdriver.

`cloudAuditLogging`

Se você quiser que os registros de auditoria do Kubernetes sejam integrados aos registros de auditoria do Cloud, preencha a seção cloudAuditLogging.

`autoRepair`

Se você quiser ativar o reparo automático de nós, defina autoRepair.enabled como true. Caso contrário, defina como false.

`adminMaster`

Se você quiser configurar manualmente as CPUs e a memória para o nó do plano de controle do administrador, preencha a seção adminMaster.

Como validar seu arquivo de configuração

Depois de preencher o arquivo de configuração do cluster de administrador, execute gkectl check-config para verificar se o arquivo é válido:

gkectl check-config --config [CONFIG_PATH]

em que [CONFIG_PATH] é o caminho do arquivo de configuração do cluster de administrador.

Se o comando retornar mensagens, corrija os problemas e valide o arquivo novamente.

Se quiser pular as validações mais demoradas, transmita a sinalização --fast. Para pular validações individuais, use as sinalizações --skip-validation-xxx. Para saber mais sobre o comando check-config, consulte Como executar verificações de simulação.

Como executar `gkectl prepare`

Execute gkectl prepare para inicializar o ambiente do vSphere:

gkectl prepare --config [CONFIG_PATH]

O comando gkectl prepare executa as seguintes tarefas preparatórias:

Importa as imagens do SO para o vSphere e as marca como modelos de VM.
Se você estiver usando um registro particular do Docker, esse comando enviará as imagens do contêiner do Docker para o registro.
Opcionalmente, esse comando valida os atestados de build das imagens do contêiner, verificando se as imagens foram criadas e assinadas pelo Google e estão prontas para implantação.

Como criar um balanceador de carga do Seesaw para o cluster de administrador

Se você escolheu usar o balanceador de carga do Seesaw em pacote, siga as etapas nesta seção. Caso contrário, pule esta seção.

Crie e configure as VMs para o balanceador de carga do Seesaw:

gkectl create loadbalancer --config [CONFIG_PATH]

Como criar o cluster de administrador

Crie o cluster de administrador:

gkectl create admin --config [CONFIG_PATH]

em que [CONFIG_PATH] é o caminho do arquivo de configuração do cluster de administrador.

O comando gkectl create admin cria um arquivo kubeconfig chamado kubeconfig no diretório atual. Você precisará desse arquivo kubeconfig mais tarde para interagir com o cluster de administrador.

Como verificar se o cluster de administrador está em execução

Verifique se o cluster de administrador está em execução:

kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig.

A saída mostra os nós do cluster de administrador.

Solução de problemas

Como diagnosticar problemas de cluster usando `gkectl`

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Comportamento de geração de registros padrão

Para gkectl e gkeadm, basta usar as configurações de geração de registros padrão:

Por padrão, as entradas de registro são salvas da seguinte maneira:
- Para gkectl, o arquivo de registros padrão é /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e está vinculado ao arquivo logs/gkectl-$(date).log no diretório local em que você executa gkectl.
- Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log no diretório local em que você executa gkeadm.
Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam impressas no terminal (quando --alsologtostderr é false).
O nível de detalhamento -v5 (padrão) abrange todas as entradas de registro exigidas pela equipe de suporte.
O arquivo de registros também contém o comando executado e a mensagem de erro.

Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.

Como especificar um local não padrão para o arquivo de registros

Se quiser especificar um local não padrão para o arquivo de registros gkectl, use a sinalização --log_file. O arquivo de registro que você especificar não será vinculado ao diretório local.

Se quiser especificar um local não padrão para o arquivo de registros gkeadm, use a sinalização --log_file.

Como localizar registros da API Cluster no cluster de administrador

Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```

Como depurar problemas de F5 BIG-IP com o kubeconfig do nó do plano de controle do cluster de administrador

Após uma instalação, os clusters do Anthos no VMware geram um arquivo kubeconfig no diretório inicial da estação de trabalho de administrador chamado internal-cluster-kubeconfig-debug. Esse arquivo kubeconfig é idêntico ao kubeconfig do cluster de administrador, com a diferença de que ele aponta diretamente para o nó do plano de controle do cluster de administrador, em que o plano de controle de administrador é executado. É possível usar o arquivo internal-cluster-kubeconfig-debug para depurar problemas de F5 BIG-IP.

Falha na validação de `gkectl check-config`: não é possível encontrar partições de F5 BIG-IP

Sintomas: A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.
Causas possíveis: Um problema com a API F5 BIG-IP pode causar falha na validação.
Resolução: Tente executar gkectl check-config novamente.

Falha em `gkectl prepare --validate-attestations`: não foi possível validar o atestado de versão

Sintomas

Executar gkectl prepare com a sinalização --validate-attestations opcional retorna o seguinte erro:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

Causas possíveis

Um atestado pode não existir para as imagens afetadas.

Resolução

Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme instruído em Como criar uma estação de trabalho de administrador. Se o problema persistir, entre em contato com o Google para receber ajuda.

Como depurar usando os registros do cluster de inicialização

Durante a instalação, os clusters do Anthos no VMware criam um cluster de inicialização temporário. Após uma instalação bem-sucedida, os clusters do Anthos no VMware exclui o cluster de inicialização, deixando você com o cluster de administrador e o cluster de usuário. Geralmente, não há motivo para interagir com esse cluster.

Se algo der errado durante uma instalação e você tiver transmitido --cleanup-external-cluster=false para gkectl create cluster, talvez seja útil realizar a depuração usando os registros do cluster de inicialização. Encontre o pod e acesse os registros dele:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Para mais informações, consulte Solução de problemas.

A seguir

Como criar um cluster de usuários

Como criar um cluster de administrador

Antes de começar

Consiga uma conexão SSH para a estação de trabalho do administrador

Arquivo de configuração de credenciais

Arquivo de configuração do cluster de administrador

Como preencher o arquivo de configuração

bundlePath

vCenter

network

loadBalancer

antiAffinityGroups

proxy

privateRegistry

gcrKeyPath

stackdriver

cloudAuditLogging

autoRepair

adminMaster