Criar um cluster de usuário (controle V2)

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

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. O plano de controle V2 é a configuração padrão e recomendada para a criação de clusters.

Visão geral do procedimento

Estas são as principais etapas envolvidas na criação de um cluster de usuários:

  1. Conectar-se à estação de trabalho do administrador
    A estação de trabalho de administrador é uma VM que tem as ferramentas necessárias para criar um cluster de usuário.
  2. Preencher os arquivos de configuração
    Para especificar os detalhes do novo cluster, preencha um arquivo de configuração de cluster de usuário, um arquivo de configuração de credenciais e possivelmente um arquivo de bloco de IP.
  3. (Opcional) Importe imagens do SO para o vSphere e envie imagens de contêiner para o
    registro particular, se aplicável.
    Execute gkectl prepare.
  4. Criar um cluster de usuário
    Execute gkectl create cluster para criar um cluster conforme especificado no arquivo de configuração.
  5. Verificar se o cluster de usuário está em execução
    Use o kubectl para ver os nós do cluster.

No final deste procedimento, você terá um cluster de usuários em execução para implantar as cargas de trabalho.

Antes de começar

  • Verifique se você criou uma estação de trabalho de administrador e um cluster de administrador.

  • Consulte o documento de planejamento de endereços IP. Verifique se você tem endereços IP suficientes disponíveis e reveja sua decisão sobre como quer que os nós do cluster recebam os endereços IP: DHCP ou estático. Se você decidir usar endereços IP estáticos, preencha um arquivo de blocos de IP que contenha os endereços escolhidos.

  • Consulte a visão geral do balanceamento de carga e reveja sua decisão sobre o tipo de balanceador de carga que você quer usar. É possível usar o balanceador de carga MetalLB empacotado ou configurar manualmente um balanceador de carga de sua escolha. Para balanceamento de carga manual, configure o balanceador de carga antes de criar o cluster de usuário.

  • Consulte a seção vCenter. Considere se você quer usar clusters do vSphere separados para os clusters de administrador e de usuário e se quer usar data centers separados. Pense também se você quer usar instâncias separadas do vCenter Server.

  • Consulte a seção nodePools. Pense em quantos pools de nós você precisa e em qual sistema operacional você quer executar em cada um deles.

1. Conectar-se à estação de trabalho do 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.

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

2. Preencher o arquivo de configuração

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

Para se familiarizar com o arquivo de configuração, leia o documento arquivo de configuração do cluster de usuário. É recomendável manter esse documento aberto em uma guia ou janela separada para fazer referência a ele ao concluir as etapas a seguir.

name

Defina o campo name como um nome de sua escolha para o cluster de usuário.

gkeOnPremVersion

Este campo já foi preenchido para você. Ela especifica a versão do GKE no VMware. Por exemplo, 1.15.0-gke.581.

enableControlplaneV2

Defina enableControlplaneV2 como true.

enableDataplaneV2

Defina enableDataplaneV2 como true.

vCenter

Os valores definidos na seção vCenter do arquivo de configuração do cluster de administrador são globais. Ou seja, elas se aplicam ao cluster de administrador e aos clusters de usuário associados.

Para cada cluster de usuário criado, você tem a opção de modificar alguns dos valores globais de vCenter.

Para substituir qualquer um dos valores vCenter globais, preencha os campos relevantes na seção vCenter do seu arquivo de configuração do cluster de usuário.

Talvez você queira usar clusters do vSphere separados para o cluster de administrador e os clusters de usuário. Em vez disso, use data centers separados para o cluster de administrador e os clusters de usuário.

Como usar um data center e um cluster do vSphere

A opção padrão é usar um data center e um cluster do vSphere para o cluster de administrador e o cluster de usuário. Para essa opção, não defina valores vCenter no arquivo de configuração do cluster de usuário. Os valores vCenter serão herdados do cluster de administrador.

Como usar clusters do vSphere separados

Se você quiser criar um cluster de usuário que esteja no próprio cluster do vSphere, especifique um valor para vCenter.cluster no arquivo de configuração do cluster de usuário.

Se o cluster de administrador e o cluster de usuário estiverem em clusters separados do vSphere, eles podem estar no mesmo data center ou em data centers diferentes.

Como usar data centers separados do vSphere

Os clusters de usuário e de administrador podem estar em diferentes data centers. Nesse caso, eles também estão em clusters separados do vSphere.

Se você especificar vCenter.datacenter no arquivo de configuração do cluster de usuário, também será necessário especificar:

  • vCenter.networkName
  • vCenter.datastore ou vCenter.storagePolicyName
  • vCenter.cluster ou vCenter.resourcePool

Como usar contas do vCenter separadas

Um cluster de usuário pode usar uma conta do vCenter diferente, com vCenter.credentials diferentes, do cluster de administrador. A conta do vCenter do cluster de administrador precisa acessar o data center do cluster de administrador, enquanto a conta do vCenter do cluster de usuário só precisa de acesso ao data center do cluster de usuário.

Como usar instâncias separadas do 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.

Preencha 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"

Preencha também o campo network.vCenter.networkName.

network

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

  • De um servidor DHCP configurado com antecedência. 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. Para ver um exemplo de arquivo de bloco de IP, consulte Exemplo de arquivos de configuração preenchidos.

Se você decidiu usar endereços IP estáticos para os nós de trabalho, preencha o campo network.ipMode.ipBlockFilePath.

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. Para especificar endereços IP estáticos para os nós do plano de controle, preencha a seção network.controlPlaneIPBlock. Se você quiser um cluster de usuário de alta disponibilidade (HA, na sigla em inglês), especifique três endereços IP. Caso contrário, especifique um endereço IP.

Para especificar os servidores DNS e NTP, preencha a seção hostConfig. Esses servidores DNS e NTP são para os nós do plano de controle. Se você estiver usando endereços IP estáticos para os nós de trabalho, esses servidores DNS e NTP também serão para os nós de trabalho.

O network.podCIDR e o network.serviceCIDR têm valores pré-preenchidos que não podem ser alterados, a menos que entrem em conflito com endereços que já estão em uso na sua rede. O Kubernetes usa esses intervalos para atribuir endereços IP a pods e serviços no cluster.

Independentemente de você depender de um servidor DHCP ou especificar uma lista de endereços IP estáticos, é necessário ter endereços IP suficientes disponíveis para o cluster de usuário. Para uma explicação de quantos endereços IP você precisa, consulte Planejar seus endereços IP.

loadBalancer

Reserve um VIP para o servidor da API Kubernetes do seu cluster de usuários. Reserve outro VIP para o serviço de entrada do seu cluster de usuários. Forneça seus VIPs como valores para loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

Decida qual tipo de balanceamento de carga você quer usar. As opções são:

Para mais informações, consulte Visão geral do balanceamento de carga.

advancedNetworking

Se você planeja criar um gateway NAT de saída, defina advancedNetworking como true.

multipleNetworkInterfaces

Decida se quer configurar várias interfaces de rede para pods e defina multipleNetworkInterfaces conforme necessário.

storage

Se você quiser desativar a implantação de componentes do CSI do vSphere, defina storage.vSphereCSIDisabled como true.

masterNode

Na seção masterNode, especifique quantos nós do plano de controle você quer para o cluster de usuário: um ou três. Também é possível especificar um repositório de dados para os nós do plano de controle e se você quer ativar o redimensionamento automático dos nós do plano de controle.

Lembre-se de que você especificou endereços IP para os nós do plano de controle na seção network.controlPlaneIPBlock.

nodePools

Um pool de nós é um grupo de nós em um cluster, que têm a mesma configuração. Por exemplo, os nós em um pool podem executar o Windows e os nós em outro pool podem executar o Linux.

Preencha a seção nodePools para especificar pelo menos um pool de nós.

Para mais informações, consulte Pools de nós e Como criar e gerenciar pools de nós.

antiAffinityGroups

Defina antiAffinityGroups.enabled como true ou false.

Esse campo especifica se o GKE no VMware cria regras antiafinidade do Distributed Resource Scheduler (DRS) para os nós de trabalho, fazendo com que eles sejam distribuídos por pelo menos três hosts físicos no seu data center.

stackdriver

Se você quiser ativar o Cloud Logging e o Cloud Monitoring para o cluster, preencha a seção stackdriver.

Esta seção é obrigatória por padrão. Ou seja, se você não preencher essa seção, inclua a sinalização --skip-validation-stackdriver ao executar gkectl create cluster.

Observe os seguintes requisitos para novos clusters:

  • O ID em stackdriver.projectID precisa ser o mesmo que o ID em gkeConnect.projectID e cloudAuditLogging.projectID.

  • A região do Google Cloud definida em stackdriver.clusterLocation precisa ser igual à região definida em cloudAuditLogging.clusterLocation. Além disso, se gkeOnPremAPI.enabled for true, a mesma região precisará ser definida em gkeOnPremAPI.location.

Se os IDs do projeto e as regiões não forem iguais, a criação do cluster vai falhar.

gkeConnect

Seu cluster de usuário precisa ser registrado em uma frota do Google Cloud.

Preencha a seção gkeConnect para especificar um projeto host de frota e uma conta de serviço associada.

Se você incluir as seções stackdriver e cloudAuditLogging no arquivo de configuração, o ID em gkeConnect.projectID precisará ser o mesmo definido em stackdriver.projectID e cloudAuditLogging.projectID. de dois minutos. Se os IDs do projeto não forem iguais, a criação do cluster falhará.

gkeOnPremAPI

Na versão 1.16 e mais recentes, se a API GKE On-Prem estiver ativada no projeto do Google Cloud, todos os clusters no projeto serão registrados na API GKE On-Prem automaticamente na região configurada em stackdriver.clusterLocation.

  • Se você quiser registrar todos os clusters no projeto na API GKE On-Prem, siga as etapas em Antes de começar para ativar e usar a API GKE On-Prem no projeto.

  • Se você não quiser registrar o cluster na API GKE On-Prem, inclua esta seção e defina gkeOnPremAPI.enabled como false. Se você não quiser registrar nenhum cluster no projeto, desative gkeonprem.googleapis.com (o nome do serviço da API GKE On-Prem) no projeto. Para instruções, consulte Como desativar serviços.

usageMetering

Se você quiser ativar a medição de uso do cluster, preencha a seção usageMetering.

cloudAuditLogging

Se você quiser integrar os registros de auditoria do servidor da API Kubernetes do cluster com os registros de auditoria do Cloud, preencha a seção cloudAuditLogging.

Observe os seguintes requisitos para novos clusters:

  • O ID em cloudAuditLogging.projectID precisa ser o mesmo que o ID em gkeConnect.projectID e stackdriver.projectID.

  • A região do Google Cloud definida em cloudAuditLogging.clusterLocation precisa ser igual à região definida em stackdriver.clusterLocation. Além disso, se gkeOnPremAPI.enabled for true, a mesma região precisará ser definida em gkeOnPremAPI.location.

Se os IDs do projeto e as regiões não forem iguais, a criação do cluster vai falhar.

Exemplo de arquivos de configuração preenchidos

Confira um exemplo de um arquivo de bloco de IP e 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

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.15.0-gke.581
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  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"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: 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.

Validar o arquivo de configuração

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

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua:

  • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig para o cluster de administrador.

  • USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

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.

3. (Opcional) Importe imagens do SO para o vSphere e envie imagens de contêiner para um registro particular

Execute gkectl prepare se alguma das seguintes condições for verdadeira:

  • O cluster de usuário está em um data center do vSphere diferente do cluster de administrador.

  • O cluster de usuário tem um servidor vCenter diferente do cluster de administrador.

  • O cluster de usuário usa um registro de contêiner particular diferente do registro particular usado pelo cluster de administrador.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Substitua:

  • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;

  • BUNDLE: o caminho do arquivo do pacote. Esse arquivo está na estação de trabalho do administrador em /var/lib/gke/bundles/. Exemplo:

    /var/lib/gke/bundles/gke-onprem-vsphere-1.14.0-gke.421-full.tgz

  • USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

4. Criar um cluster de usuário

Crie um cluster de usuário:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Localizar o arquivo kubeconfig do cluster de usuário

O comando gkectl create cluster cria um arquivo kubeconfig chamado USER_CLUSTER_NAME-kubeconfig no diretório atual. Você precisará desse arquivo kubeconfig mais tarde para interagir com seu cluster de usuários.

O arquivo kubeconfig contém o nome do cluster de usuário. Para acessar o nome do cluster, execute o seguinte:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

A saída mostra o nome do cluster. Exemplo:

NAME
my-user-cluster

Se preferir, é possível alterar o nome e o local do arquivo kubeconfig.

5. Verificar se o cluster de usuário está em execução

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

A saída mostra os nós do cluster de usuário. 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

Fazer upgrade de um cluster de usuários

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

Excluir um cluster

Para excluir um cluster de usuário que tenha o plano de controle V2 ativado, siga as instruções em Como excluir um cluster de usuário.

Quando você exclui um cluster de usuário com o Controlplane V2 ativado, o disco de dados é excluído automaticamente.

Solução de problemas

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

A seguir