Crie um cluster de utilizadores para utilização com domínios de topologia

No Google Distributed Cloud, as suas cargas de trabalho são executadas num ou mais clusters de utilizadores. Esta página mostra como criar um cluster de utilizadores para utilização em domínios de topologia do Google Distributed Cloud. É necessária a versão 1.31 ou superior do Google Distributed Cloud para usar domínios de topologia.

A configuração de um domínio de topologia requer que ative o cluster avançado. Tenha em atenção as seguintes limitações da pré-visualização avançada de clusters:

  • Só pode ativar o cluster avançado no momento da criação do cluster para novos clusters 1.31.
  • Depois de ativar o cluster avançado, não pode atualizar o cluster para a versão 1.32. Ative o cluster avançado apenas num ambiente de teste.

Esta página destina-se a administradores, arquitetos e operadores que configuram, monitorizam e gerem a infraestrutura técnica. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE.

Antes de começar

Vista geral do procedimento

Os seguintes passos principais estão envolvidos na utilização da gkectl para criar um cluster de utilizadores:

  1. Preencha o ficheiro de configuração do cluster de utilizadores
    Especifique os detalhes do novo cluster no ficheiro de configuração do cluster de utilizadores.
  2. Preencha o ficheiro de bloqueio de IPs
    Especifique os endereços IP para o gateway, a máscara de rede, os nós do plano de controlo e, opcionalmente, os nós de trabalho num ficheiro de bloco IP.
  3. Crie um cluster de utilizadores
    Execute gkectl create cluster para criar um cluster conforme especificado nos seus ficheiros de configuração.
  4. Verifique se o cluster de utilizadores está em execução
    Use kubectl para ver os nós do cluster.

No final deste procedimento, tem um cluster de utilizadores em execução onde pode implementar as suas cargas de trabalho.

Preencha o ficheiro de configuração do cluster de utilizadores

Se usou gkeadm para criar a sua estação de trabalho de administrador, gkeadm gerou um modelo para o ficheiro de configuração do cluster de utilizadores denominado user-cluster.yaml. Além disso, o gkeadm preencheu alguns dos campos por si.

Se não usou o gkeadm para criar a estação de trabalho de administrador, pode usar o gkectl para gerar um modelo para o ficheiro de configuração do cluster de utilizadores.

Para gerar um modelo para o ficheiro de configuração do cluster de utilizadores:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Substitua o seguinte:

OUTPUT_FILENAME: um caminho à sua escolha para o modelo gerado. Se omitir esta flag, gkectl atribui o nome user-cluster.yaml ao ficheiro e coloca-o no diretório atual.

VERSION: o número da versão pretendida. Por exemplo: gkectl create-config cluster --gke-on-prem-version=1.33.100-gke.89.

Familiarize-se com o ficheiro de configuração analisando o documento ficheiro de configuração do cluster de utilizadores. Recomendamos que mantenha este documento aberto num separador ou numa janela separada, porque vai consultá-lo à medida que conclui os passos seguintes.

name

Defina o campo name para um nome à sua escolha para o cluster de utilizadores.

gkeOnPremVersion

Este campo já está preenchido. Especifica a versão do Google Distributed Cloud. Por exemplo, 1.33.100-gke.89.

enableAdvancedCluster

Definir enableAdvancedCluster para true.

enableControlplaneV2

O plano de controlo V2 é obrigatório para todos os clusters de utilizadores 1.30 e superiores. Definir enableControlplaneV2 para true.

Quando o Controlplane V2 está ativado, o plano de controlo do cluster de utilizador é executado em nós no próprio cluster de utilizador.

enableDataplaneV2

Defina enableDataplaneV2 como true.

vCenter

Remova esta secção inteira. Em alternativa, configure as informações do vCenter no ficheiro de configuração da infraestrutura do vSphere por domínio de topologia.

network

  • Remova o seguinte do ficheiro de configuração:

    • Toda a secção network.hostConfig. Estas informações são configuradas no ficheiro de configuração da infraestrutura do vSphere por domínio de topologia.
    • O campo network.vCenter.networkName. Este campo é configurado no ficheiro de configuração da infraestrutura do vSphere por domínio de topologia.
    • Toda a secção network.controlPlaneIPBlock. Os endereços IP do gateway, da máscara de rede e dos nós do plano de controlo são configurados num ficheiro de bloco de IP.

  • Defina network.ipMode.ipBlockFilePath para o caminho do ficheiro de bloqueio de IPs.

  • Decida como quer que os nós de trabalho obtenham os respetivos endereços IP. As opções são:

    • A partir de um servidor DHCP que configurou antecipadamente. Defina network.ipMode.type como "dhcp".

    • A partir de uma lista de endereços IP estáticos que fornece no ficheiro de bloqueio de IP. Defina network.ipMode.type como "static".

    Os nós do plano de controlo do cluster de utilizadores têm de obter os respetivos endereços IP a partir de uma lista de endereços estáticos que fornece no ficheiro de bloco de IP. Isto aplica-se mesmo que os nós de trabalho obtenham os respetivos endereços a partir de um servidor DHCP.

    Independentemente de usar um servidor DHCP ou especificar uma lista de endereços IP estáticos, tem de ter endereços IP suficientes disponíveis para o seu cluster de utilizadores. Para uma explicação de quantos endereços IP precisa, consulte o artigo Planeie os seus endereços IP.

  • Os campos network.podCIDR e network.serviceCIDR têm valores pré-preenchidos que pode deixar inalterados, a menos que entrem em conflito com endereços já usados na sua rede. O Kubernetes usa estes intervalos para atribuir endereços IP a pods e serviços no seu cluster.

loadBalancer

advancedNetworking

Se planeia criar um gateway de NAT de saída, defina advancedNetworking como true.

multipleNetworkInterfaces

Defina multipleNetworkInterfaces como false. As várias interfaces de rede para pods não são suportadas com domínios de topologia.

storage

Defina storage.vSphereCSIDisabled como true para desativar a implementação de componentes do vSphere CSI.

masterNode

  • Se quiser especificar a CPU e a memória para os nós do plano de controlo do cluster de utilizadores, preencha os campos cpus e memoryMB na secção masterNode.

  • Apenas são suportados clusters de alta disponibilidade (HA). Defina o campo replicas como 3 para especificar que o cluster vai ter três nós do plano de controlo.

  • Para ativar a alteração automática do tamanho dos nós do plano de controlo, defina autoResize.enabled como true.

  • Remover toda a secção masterNode.vsphere.

  • Preencha o campo masterNode.topologyDomains com o nome do domínio de topologia no qual quer que os nós do plano de controlo estejam.

nodePools

Um conjunto de nós é um grupo de nós de trabalho num cluster que têm todos a mesma configuração. Por exemplo, pode querer configurar um domínio de topologia separado para cada conjunto de nós. Tem de especificar, pelo menos, um conjunto de nós preenchendo a secção nodePools.

Para cada conjunto de nós que especificar:

  • Preencha o campo nodePools[i].topologyDomains com o nome do domínio de topologia no qual quer que o conjunto de nós esteja.

  • Remova todos os campos na secção nodePools[i].vsphere, exceto nodePools[i].vsphere.tags. Especifica estas informações no ficheiro de configuração da infraestrutura do vSphere por domínio de topologia.

  • Defina nodePools[i].osImageType como ubuntu_cgroupv2 ou ubuntu_containerd.

Para informações mais gerais sobre conjuntos de nós, consulte os artigos Conjuntos de nós e Criar e gerir conjuntos de nós.

antiAffinityGroups

Definir antiAffinityGroups.enabled para false. As regras de antiafinidade do Distributed Resource Scheduler (DRS) não são suportadas com domínios de topologia.

stackdriver

Preencha a secção stackdriver para ativar o Cloud Logging e o Cloud Monitoring para o seu cluster.

Tenha em atenção os seguintes requisitos:

  • O ID em stackdriver.projectID tem de ser igual ao ID em gkeConnect.projectID e cloudAuditLogging.projectID.

  • A Google Cloud região definida em stackdriver.clusterLocation tem de ser igual à região definida em cloudAuditLogging.clusterLocation e gkeConnect.location. Além disso, se gkeOnPremAPI.enabled for true, tem de definir a mesma região em gkeOnPremAPI.location.

Se os IDs dos projetos e as regiões não forem os mesmos, a criação do cluster falha.

gkeConnect

O seu cluster de utilizadores tem de estar registado numa Google Cloud frota.

Preencha a secção gkeConnect para especificar um projeto anfitrião da frota e uma conta de serviço associada. O ID em gkeConnect.projectID tem de ser igual ao ID definido em stackdriver.projectID e cloudAuditLogging.projectID. Se os IDs dos projetos não forem iguais, a criação do cluster falha.

Opcionalmente, pode especificar uma região onde os serviços de frota e Connect são executados em gkeConnect.location. Se não incluir este campo, o cluster usa as instâncias globais destes serviços.

Se incluir gkeConnect.location no ficheiro de configuração, a região especificada tem de ser igual à região configurada em cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se as regiões não forem as mesmas, a criação de clusters falha.

gkeOnPremAPI

Esta secção descreve como os clusters são inscritos na API GKE On-Prem.

A ferramenta de linha de comandos gkectl é a única ferramenta de gestão do ciclo de vida do cluster disponível para clusters que usam domínios de topologia. Embora a Google Cloud consola, a CLI do Google Cloud e o Terraform não sejam suportados para clusters que usam domínios de topologia, pode inscrever opcionalmente o cluster na API GKE On-Prem quando é criado.

Se a API GKE On-Prem estiver ativada no seu Google Cloud projeto, todos os clusters no projeto são inscritos automaticamente na API GKE On-Prem na região configurada em stackdriver.clusterLocation. A região gkeOnPremAPI.location tem de ser igual à região especificada em cloudAuditLogging.clusterLocation, gkeConnect.location e stackdriver.clusterLocation.

  • Se quiser inscrever todos os clusters no projeto na API GKE On-Prem, certifique-se de que executa os passos em Antes de começar para ativar e usar a API GKE On-Prem no projeto.

  • Se não quiser inscrever o cluster na API GKE On-Prem, inclua esta secção e defina gkeOnPremAPI.enabled como false. Se não quiser inscrever nenhum cluster no projeto, desative gkeonprem.googleapis.com (o nome do serviço para a API GKE On-Prem) no projeto. Para ver instruções, consulte o artigo Desativar serviços.

cloudAuditLogging

Se quiser integrar os registos de auditoria do servidor da API Kubernetes do seu cluster com os registos de auditoria da nuvem, preencha a secção cloudAuditLogging.

Tenha em atenção os seguintes requisitos:

# advanced-cluster-change #

Defina cloudAuditLogging.serviceAccountKeyPath para o mesmo caminho que stackdriver.serviceAccountKeyPath.

  • O ID em cloudAuditLogging.projectID tem de ser igual ao ID em gkeConnect.projectID e stackdriver.projectID.

  • A região em cloudAuditLogging.clusterLocation tem de ser igual à região definida em gkeConnect.location (se o campo estiver incluído no ficheiro de configuração) e stackdriver.clusterLocation. Além disso, se gkeOnPremAPI.enabled for true, tem de definir a mesma região em gkeOnPremAPI.location.

Se os IDs dos projetos e as regiões não forem os mesmos, a criação do cluster falha.

preparedSecrets

Remova o campo preparedSecrets. As credenciais preparadas não são suportadas quando os domínios de topologia estão ativados.

schedulerConfiguration

Se quiser configurar configurações adicionais que vão ser transmitidas para kube-scheduler, adicione a secção schedulerConfiguration ao ficheiro de configuração.

Exemplo de ficheiros de configuração preenchidos

Segue-se um exemplo de um ficheiro de bloqueio de IP e um ficheiro de configuração de cluster de utilizadores:

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
  - netmask: 255.255.255.0
    gateway: 100.115.223.254
    ips:
    - ip: 100.115.222.205
      hostname: cp-1
      isControlPlane: true
    - ip: 100.115.222.206
      hostname: cp-2
      isControlPlane: true
    - ip: 100.115.222.207
      hostname: cp-3
      isControlPlane: true

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.33.100-gke.89
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
loadBalancer:
  vips:
    controlPlaneVIP: "100.115.222.200"
    ingressVIP: "172.16.21.30"
  kind: "ManualLB"
  manualLB:
    ingressHTTPNodePort: 32527
    ingressHTTPSNodePort: 30139
    controlPlaneNodePort: 30968
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  topologyDomains:
  - "domain1"
antiAffinityGroups:
  enabled: false
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  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

Seguem-se os pontos importantes a compreender no exemplo anterior:

  • O campo nodePools.replicas está definido como 3, o que significa que existem três nós de trabalho em "worker-node-pool". Todos os nós de trabalho usam endereços IP estáticos porque network.ipMode.type está definido como "static".

  • Os endereços IP dos nós do plano de controlo e dos nós de trabalho são especificados num ficheiro de bloco de IP. O ficheiro de bloqueio de IP tem quatro endereços para nós de trabalho, embora existam apenas três nós de trabalho. O endereço IP do nó de trabalho adicional é necessário durante a atualização, a atualização e a reparação automática do cluster. Os endereços IP dos nós do plano de controlo têm a flagisControlPlane: true.

  • Os clusters avançados, o Controlplane V2 e o Dataplane V2 estão ativados.

  • O campo masterNode.replicas está definido como 3, pelo que o cluster tem um plano de controlo de alta disponibilidade.

  • O VIP do plano de controlo está na mesma VLAN que os nós do plano de controlo e o VIP de entrada está na mesma VLAN que os nós de trabalho

Preencha o ficheiro de bloqueio de IPs

Copie o modelo do ficheiro de blocos de IP para o ficheiro no diretório que especificou no campo network.ipMode.ipBlockFilePath no ficheiro de configuração do cluster de utilizadores. Crie ficheiros de bloqueio de IPs separados para o cluster de administrador e para cada cluster de utilizador.

Adicione os endereços IP do gateway, da máscara de rede e dos nós do plano de controlo ao ficheiro de bloco de IP. Para cada endereço IP do nó do plano de controlo, adicione isControlPlane: true, conforme mostrado no exemplo anterior. Se quiser um cluster de utilizadores de alta disponibilidade (HA), especifique três endereços IP. Caso contrário, especifique um endereço IP. O número de endereços IP que especificar para os nós do plano de controlo tem de corresponder ao número no campo masterNode.replicas no ficheiro de configuração do cluster de utilizadores.

Se network.ipMode.type estiver definido como "static", adicione os endereços IP dos nós de trabalho ao ficheiro de bloqueio de IP. Certifique-se de que especifica um endereço IP adicional para utilização durante a atualização, a atualização e a reparação automática do cluster.

Cada endereço de gateway no ficheiro de bloco de IP tem de corresponder ao endereço especificado num campo topologyDomains[i].network.gateway no ficheiro de configuração da infraestrutura do vSphere. Para mais informações, consulte o exemplo para domínios de topologia.

Crie um cluster de utilizadores

Execute o seguinte comando para criar um cluster de utilizadores:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Localize o ficheiro kubeconfig do cluster de utilizadores

O comando gkectl create cluster cria um ficheiro kubeconfig denominado USER_CLUSTER_NAME-kubeconfig no diretório atual. Vai precisar deste ficheiro kubeconfig mais tarde para interagir com o cluster de utilizadores.

O ficheiro kubeconfig contém o nome do cluster de utilizadores. Para ver o nome do cluster, pode executar o seguinte comando:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

O resultado mostra o nome do cluster. Por exemplo:

NAME
my-user-cluster

Se quiser, pode alterar o nome e a localização do ficheiro kubeconfig.

Verifique se o cluster de utilizadores está em execução

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de utilizadores.

O resultado mostra os nós do cluster de utilizadores. Por 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

Configure o seu PodTemplate

A etiqueta de topologia é preenchida para etiquetas de nós no domínio de topologia. A menos que a configuração do domínio de topologia tenha usado a restrição predefinida, "topology.kubernetes.io/zone" como chave de topologia, tem de configurar a chave de topologia no modelo de pod da sua implementação, StatefulSet ou ReplicaSet, conforme aplicável.

Por exemplo, suponhamos que definiu a chave na etiqueta de topologia como "topology.examplepetstore.com/zone". Em PodTemplate, especifica a chave como o valor do campo topologySpreadConstraints.topologyKey. Isto permite que o programador do Kubernetes distribua os pods pelo domínio da topologia para garantir a elevada disponibilidade e evitar a concentração excessiva numa única área em caso de falha.

Resolução de problemas

Consulte o artigo Resolução de problemas de criação e atualização de clusters.

O que se segue?