Criar um cluster de usuário com um novo modelo de instalação

Neste documento, mostramos como criar um cluster de usuário que usa um novo modelo de instalação disponível como um recurso em fase de pré-lançamento na versão 1.13 dos clusters do Anthos no VMware (GKE On-Prem).

O que é kubeception?

O termo kubeception é usado para transmitir a ideia de que um cluster do Kubernetes é usado para criar e gerenciar outros clusters do Kubernetes. No contexto dos clusters do Anthos no VMware, o kubeception se refere ao caso em que o plano de controle de um cluster de usuário é executado em um ou mais nós em um cluster de administrador.

A partir da versão 1.13.0, você tem a opção de executar o plano de controle de um cluster de usuário em um ou mais nós no próprio cluster. Nas versões anteriores dos clusters do Anthos no VMware, o kubeception era a única opção. Ou seja, todos os clusters de usuário tinham planos de controle no cluster de administrador.

O novo modelo de instalação traz consistência arquitetônica entre os clusters de administrador e de usuário e separa o cluster de usuário do cluster de administrador. Essa é uma vantagem para cenários como a execução de clusters em diferentes locais geográficos.

Antes de começar

É necessário ter um cluster de administrador, e a versão dele precisa ser 1.13.0 ou mais recente.

Planejar seus endereços IP

Ao planejar os endereços IP para o cluster de usuário, esteja ciente destes requisitos para o novo modelo de instalação:

  • Os nós do plano de controle do cluster de usuário precisam receber os endereços IP de uma lista de endereços estáticos fornecidos por você, mesmo se os nós de trabalho receberem os endereços de um servidor DHCP. Você precisa de três nós de plano de controle para um cluster de usuário de alta disponibilidade (HA), mas apenas um nó do plano de controle para um cluster de usuário que não seja de alta disponibilidade.

  • Os nós do plano de controle do cluster de usuário precisam estar na mesma VLAN que os nós de trabalho do cluster de usuário. Isso é diferente do modelo kubeception.

  • O VIP do plano de controle do cluster de usuário precisa estar na mesma VLAN que os nós de trabalho do cluster de usuário e os nós do plano de controle do cluster de usuário. Isso é diferente do modelo kubeception.

Planejar o ambiente do vSphere

O arquivo de configuração do cluster de administrador e o arquivo de configuração do cluster de usuário têm uma seção vCenter em que é possível especificar os recursos do vSphere que você quer que o cluster de administrador ou de usuário use.

Para um cluster de usuário, não é necessário preencher a seção vCenter, porque, por padrão, um cluster de usuário usa os mesmos recursos do vSphere que o cluster de administrador. Mas, se você quiser que o cluster de usuário use os recursos do vSphere diferentes dos especificados para o cluster de administrador, preencha os campos de sua escolha na seção vCenter do arquivo de configuração do cluster de usuário. Para mais informações, consulte Configurar a hierarquia de objetos do vSphere.

No novo modelo de instalação, os nós do plano de controle do cluster de usuário estão no próprio cluster de usuário. Portanto, os nós do plano de controle usam os recursos do vSphere especificados no arquivo de configuração do cluster de usuário. Por exemplo, suponha que você especifique datacenter-1 para o cluster de administrador e datacenter-2 para o cluster de usuário. Os nós do plano de controle do cluster de usuário estarão em datacenter-2.

Grupos antiafinidade

O arquivo de configuração do cluster de administrador e o arquivo de configuração do cluster de usuário têm um campo antiAffinityGroups.enabled que pode ser definido como true ou false.

No novo modelo de instalação, os nós do plano de controle do cluster de usuário são distribuídos de acordo com o valor antiAffinityGroups.enabled no arquivo de configuração do cluster de usuário.

Por outro lado, com o modelo kubeception, os nós do plano de controle do cluster de usuário são distribuídos de acordo com o valor antiAffinityGroups.enabled no arquivo de configuração do cluster de administrador.

Exemplo

Aqui apresentamos um exemplo de cluster de usuário que tem as seguintes características:

  • Há três nós de trabalho.

  • Os nós de trabalho têm endereços IP estáticos.

  • Há três nós do plano de controle. Ou seja, é um cluster de alta disponibilidade.

  • O balanceador de carga é o MetalLB.

  • O cluster de usuário usa os mesmos recursos do vSphere que o cluster de administrador.

O diagrama a seguir ilustra a rede para os clusters de administrador e de usuário:

Cluster de administrador e de usuário
Um cluster de administrador e um cluster de usuário (clique para ampliar)

Veja um exemplo de um arquivo de bloco de IP e uma parte de um arquivo de configuração de cluster de usuário.

usuario-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

apiVersion: v1
kind: UserCluster
...
kubeception: false
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  enableLoadBalancer: true

Estes são os pontos importantes que você precisa entender no exemplo anterior:

  • Os endereços IP estáticos dos nós de trabalho são especificados em um arquivo de bloco de IP. O arquivo de bloco de IP tem quatro endereços, mesmo que haja apenas três nós de trabalho. O endereço IP extra é necessário durante o upgrade, a atualização e o reparo automático do cluster.

  • Os endereços IP estáticos dos três nós do plano de controle são especificados na seção network.controlPlaneIPBlock do arquivo de configuração do cluster de usuário. Não é necessário ter um endereço IP extra neste bloco.

  • O campo masterNode.replicas está definido como 3.

  • O VIP do plano de controle e o VIP de entrada estão na mesma VLAN dos nós de trabalho e do plano de controle.

  • Os VIPs definidos para os serviços do tipo LoadBalancer são especificados na seção loadBalancer.metalLB.addressPools do arquivo de configuração do cluster de usuário. Esses VIPs estão na mesma VLAN que os nós de trabalho e os nós do plano de controle.

  • O arquivo de configuração do cluster de usuário não inclui uma seção vCenter. Portanto, o cluster de usuário usa os mesmos recursos do vSphere que o cluster de administrador.

Criar regras de firewall

Além das regras de firewall padrão, crie as seguintes regras de firewall conforme necessário:

De

Porta de origem

Até

Dst port

Protocolo

Descrição

Nós do cluster de administrador

Tudo

VIP do plano de controle do cluster de usuário

443

https

Permite que nós e pods no cluster de administrador se comuniquem com o servidor da API Kubernetes do cluster de usuário.

Nós do cluster de administrador

Tudo

Nós do plano de controle do cluster de usuários

443

https

Permite que nós e pods no cluster de administrador se comuniquem com o servidor da API Kubernetes do cluster de usuário usando o endereço IP de um nó do plano de controle do cluster de usuário.

Nós do cluster de administrador

Tudo

Servidor vCenter do cluster de usuário

443

https

Permite que o cluster de administrador gerencie o ciclo de vida do cluster de usuários. Obrigatório se você especificou um valor para vCenter.address diferente do endereço do vCenter no arquivo de configuração do cluster de administrador.

Nós do plano de controle do cluster de usuários

1024 - 65535

Registro local do Docker

Depende do registro

TCP/https

Obrigatório se você tiver especificado um registro particular no arquivo de configuração do cluster de administrador.

Criar um cluster de usuário com o novo modelo

Nesta seção, mostramos como criar um cluster de usuário que usa o novo modelo de instalação. Neste exemplo, o cluster de usuário usa a mesma instância do vCenter Server que o cluster de administrador.

Siga as instruções em Criar um cluster de usuário.

Durante o preenchimento do arquivo de configuração do cluster de usuário:

  • Defina kubeception como false.

  • não especifique um valor para vCenter.address;

  • Preencha a seção network.controlPlaneIPBlock. Se você quiser um cluster de usuário de alta disponibilidade, especifique três endereços IP. Caso contrário, especifique um endereço IP.

Quando o cluster de usuário estiver em execução, verifique se o plano de controle está em execução em um ou três nós no cluster de usuário:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

A saída mostra um ou três nós do plano de controle junto dos nós de trabalho. Exemplo:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Verifique se o plano de controle do cluster de usuário não está em execução no cluster de administrador:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de administrador.

A saída mostra um nó do plano de controle para o cluster de administrador, mas não mostra nenhum nó do plano de controle para o cluster de usuário. Exemplo:

admin-vm-1   Ready    control-plane,master   82m
admin-vm-2   Ready                           71m
admin-vm-3   Ready                           71m

Fazer upgrade de um cluster de usuários

Siga as instruções em Como fazer upgrade de clusters do Anthos no VMware.

Quando você faz upgrade de um cluster de usuário com o novo modelo de instalação, todo o cluster de usuário, incluindo os nós do plano de controle do usuário, é atualizado.

Por outro lado, nos clusters de usuário implantados com o modelo kubeception, os nós do plano de controle não são atualizados durante o upgrade do cluster de usuário e não é feito upgrade até que aconteça o upgrade do cluster de administrador.

Excluir um cluster de usuário

Para excluir um cluster de usuário, faça o seguinte:

gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER

Substitua USER_CLUSTER pelo nome do cluster de usuário.

Quando você exclui um cluster de usuário que usa o novo modelo de instalação, os discos de dados do cluster não são excluídos automaticamente. Portanto, exclua os discos de dados manualmente. Um cluster de alta disponibilidade tem três discos de dados, e um cluster que não é de alta disponibilidade tem um disco de dados.

Os discos de dados do cluster de usuário estão em um destes locais:

  • ADMIN_CLUSTER/USER_CLUSTER/

  • ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/

Substitua ADMIN_CLUSTER pelo nome do cluster de administrador.

Se você especificou uma pasta no campo vCenter.dataDisk do arquivo de configuração do cluster de administrador, substitua ADMIN_DISK_FOLDER pelo nome da pasta.

Para um cluster que não seja de alta disponibilidade, o disco de dados é nomeado USER_CLUSTER-0-data.vmdk.

Para um cluster de alta disponibilidade, os discos de dados são nomeados:

  • USER_CLUSTER-0-data.vmdk.
  • USER_CLUSTER-1-data.vmdk.
  • USER_CLUSTER-2-data.vmdk.

Use o cliente do vSphere para excluir os discos de dados.

Criar um cluster de usuário com o próprio vCenter Server

Em determinadas situações, faz sentido criar um cluster de usuário que use a própria instância do vCenter Server. Ou seja, o cluster de administrador e um cluster de usuário associado usam instâncias diferentes do vCenter Server.

Por exemplo, em um local de borda, convém ter uma máquina física executando o vCenter Server e uma ou mais máquinas físicas executando o ESXi. Em seguida, use a instância local do vCenter Server para criar uma hierarquia de objetos do vSphere, incluindo data centers, clusters, pools de recursos, repositórios de dados e pastas.

Siga as instruções em Criar um cluster de usuário com o novo modelo.

Além das etapas fornecidas nessa seção, preencha toda a seção vCenter do arquivo de configuração do cluster de usuário. Especificamente, especifique um valor para vCenter.address diferente do endereço do vCenter Server especificado no arquivo de configuração do cluster de administrador.

Exemplo

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Solução de problemas

Consulte Solução de problemas na criação e no upgrade de clusters.

A seguir