Criar um cluster de usuário com o Controlplane V2

Este documento mostra como criar um cluster de usuário com o Controlplane V2 ativado.

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 do GKE 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.

Com o Controlplane V2, o plano de controle de um cluster de usuário é executado em um ou mais nós no próprio cluster de usuário.

Os benefícios do Controlplane V2 incluem:

  • Consistência da arquitetura entre os clusters de administrador e de usuário

  • Isolamento de falhas. Uma falha no cluster de administrador não afeta os clusters de usuário.

  • Separação operacional. Um upgrade de cluster de administrador não causa inatividade dos clusters de usuário.

  • Separação de implantação. É possível colocar os clusters de administrador e de usuário em diferentes domínios de falha ou locais geográficos. Por exemplo, um cluster de usuário em um local de borda pode estar em um local geográfico diferente do cluster de administrador.

Antes de começar

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

Requisitos

Um cluster de usuário com o Controlplane V2 ativado:

  • É necessário usar o balanceador de carga MetalLB agrupado
  • O Dataplane V2 precisa estar ativado

Planejar seus endereços IP

Ao planejar os endereços IP para o cluster de usuário, esteja ciente destes requisitos para o ControlVe V2:

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

Com o Controlplane V2, 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.

Com o Controlplane V2, 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 Dataplane V2 e o Controlplane V2 estão ativados.

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

user-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
...
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"
...
enableControlplaneV2: true
enableDataplaneV2: true
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 servidores DNS e NTP são especificados na seção hostConfig. Neste exemplo, esses servidores DNS e NTP são destinados aos nós do plano de controle e dos nós de trabalho. Isso ocorre porque os nós de trabalho têm endereços IP estáticos. Se os nós de trabalho recebessem os endereços IP de um servidor DHCP, esses servidores DNS e NTP seriam apenas para os nós do plano de controle.

  • 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 conjunto de VIPs especificados nesta seção precisa incluir o VIP de entrada e não deve incluir o VIP 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.

Regras de firewall para o Controlplane V2

Além das regras de firewall padrão, crie as seguintes regras de firewall:

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.

As regras de firewall padrão a seguir não são necessárias para um cluster de usuário com o Controlplan V2 ativado:

De

Porta de origem

Até

Dst port

Protocolo

Descrição

Nós de trabalho do cluster de administrador

Tudo

Nós do cluster de usuário

22

SSH

Servidor de API para comunicação do kubelet em um túnel SSH

Nós de trabalho do cluster de usuário

Tudo

VIP do plano de controle do cluster de usuário

8132

GRPC

Conexão do Konnectivity

Criar um cluster de usuário com o Controlplane V2 ativado

Nesta seção, mostramos como criar um cluster de usuário com o Controlplane V2 ativado. 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 enableControlplaneV2 como true.

  • Defina enableDataplaneV2 como true.

  • Defina loadBalancer.kind como "MetalLB"

  • 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

Verifique se não há pods em execução no cluster de administrador no namespace USER_CLUSTER_NAME. Isso é diferente do modelo kubeception em que há vários pods do plano de controle em execução no namespace USER_CLUSTER_NAME do cluster de administrador:

kubectl --kubeconfig kubeconfig get pods --namespace USER_CLUSTER_NAME

Saída:

No resources found in ... namespace.

Verifique se há pods de plano de controle em execução no cluster de usuário:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods\
    --namespace kube-system\
    --selector tier=control-plane

Exemplo de saída:

clusterapi-controllers-5bbfb6bd9f-57gz8   3/3     Running   1
…
etcd-cp-vm-1                              1/1     Running   0
…
kube-apiserver-cp-vm-1                    1/1     Running   0
…
kube-controller-manager-cp-vm-1           1/1     Running   0
…
kube-scheduler-cp-vm-1                    1/1     Running   0

Conexões SSH com os nós

Com o Controlplane V2, para receber uma conexão SSH com um nó do plano de controle do cluster de usuário, use a mesma chave SSH usada para se conectar aos nós de trabalho do cluster de usuário.

Isso é diferente de um cluster de usuário do kubeception, em que você usa a mesma chave SSH usada para se conectar a nós de trabalho do cluster de administrador.

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 que tem o Controlplane V2 ativado, 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 com o Controlplane V2 ativado, 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 dos nós do plano de controle do cluster de usuário estão no armazenamento de dados especificado no campo masterNode.vSphere.datastore do arquivo de configuração do cluster de usuário.

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 plano de controle V2 ativado.

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"

Regras de firewall

Além das regras de firewall padrão e das regras de firewall necessárias para o Controlplane V2 em geral, crie a seguinte regra de firewall se o cluster de usuário tiver um servidor vCenter:

De

Porta de origem

Até

Dst port

Protocolo

Descrição

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.

Solução de problemas

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

A seguir