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:
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 como3
.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
comofalse
.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.