Neste documento, mostramos como criar um cluster de administrador para o Google Distributed Cloud. O cluster de administrador gerencia clusters de usuário que executam suas cargas de trabalho.
Para mais detalhes sobre o cluster de administrador, consulte a visão geral da instalação.
Visão geral do procedimento
Estas são as principais etapas para criar um cluster de administrador:
- Prepare uma estação de trabalho de administrador.
- Essa máquina tem as ferramentas necessárias para criar novos clusters.
- Preencher os arquivos de configuração.
- Especifique os detalhes do novo cluster de administrador preenchendo e validando um arquivo de configuração do cluster de administrador, um arquivo de configuração de credenciais e possivelmente um arquivo de bloco de IP.
- Importe imagens do SO para o vSphere e envie imagens de contêiner para o registro particular, se aplicável.
- Execute o
gkectl prepare
.
- Criar um cluster de administrador.
- Use
gkectl
para criar um novo cluster de administrador, conforme especificado nos arquivos de configuração concluídos. Quando o Google Distributed Cloud cria um cluster de administrador, ele implanta um cluster (tipo) do Kubernetes no Docker para hospedar temporariamente os controladores do Kubernetes necessários para criar o cluster de administrador. Esse cluster temporário é chamado de cluster de inicialização. Os clusters de usuário são criados e atualizados pelo administrador de gerenciamento sem o uso de um cluster de inicialização.
- Verifique se o cluster de administrador está em execução.
- Use o
kubectl
para ver os nós do cluster.
No final do procedimento, você terá um cluster de administrador em execução para criar e gerenciar clusters de usuários.
Se você usar o VPC Service Controls, poderá ver erros ao executar alguns
comandos do gkectl
, como "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services"
. Para evitar esses erros, adicione o parâmetro --skip-validation-gcp
aos seus comandos.
Antes de começar
Consulte o documento de planejamento de endereços IP. Verifique se você tem endereços IP suficientes disponíveis para os três nós do plano de controle e para um VIP do plano de controle. Se você planeja criar qualquer cluster de usuário do Kubeception, é necessário ter endereços IP suficientes disponíveis para os nós do plano de controle desses clusters de usuário.
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. Para determinados balanceadores de carga, você precisa configurá-los antes de criar o cluster de administrador.
Analise a seção
privateRegistry
e decida se quer usar um registro público ou particular para componentes do Google Distributed Cloud.Analise o campo osImageType e decida que tipo de sistema operacional você quer executar nos nós do cluster de administrador.
Se sua organização exigir que o tráfego de saída passe por um servidor proxy, coloque nas listas de permissões as APIs necessárias e o endereço do Container Registry.
Na versão 1.29 e mais recentes, as verificações de simulação do lado do servidor estão ativadas por padrão. As verificações de simulação do lado do servidor exigem regras de firewall adicionais. Em Regras de firewall para clusters de administrador, procure "Verificações de simulação" e verifique se todas as regras de firewall necessárias estão configuradas. As verificações de simulação do lado do servidor são executadas no cluster de inicialização, e não localmente na estação de trabalho do administrador.
1. Preparar a estação de trabalho do administrador
Verifique se você configurou e pode fazer login na estação de trabalho do administrador, conforme descrito em Criar uma estação de trabalho de administrador. A estação de trabalho de administrador tem as ferramentas necessárias para criar seu cluster de administrador.
Siga todas as etapas restantes neste documento na sua estação de trabalho de administrador.
2. Preencher o arquivo de configuração
Se você usou gkeadm
para criar a estação de trabalho do administrador, ele gerou um arquivo de
configuração chamado admin-cluster.yaml
.
Se você não tiver usado gkeadm
para criar a estação de trabalho do administrador, gere
admin-cluster.yaml
executando este comando na estação de trabalho do administrador:
gkectl create-config admin
Esse arquivo de configuração serve para criar o cluster de administrador.
Para se familiarizar com o arquivo de configuração, leia o documento arquivo de configuração do cluster de administrador. É 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
Se você quiser especificar um nome para o cluster de administrador, preencha o
campo name
.
bundlePath
O pacote é um arquivo compactado que contém componentes de cluster. Ele está incluído na estação de trabalho de administrador. Este campo já foi preenchido para você.
vCenter
Os campos desta seção já estão preenchidos com os valores inseridos quando você criou a estação de trabalho do administrador.
network
Preencha a seção
network.controlPlaneIPBlock
e a seção
network.hostConfig
. Defina também
adminMaster.replicas
como 3
.
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.
Preencha os outros campos na seção de rede do arquivo de configuração conforme necessário.
loadBalancer
Separe um VIP para o servidor da API do Kubernetes do cluster de administrador. Forneça
seu VIP como o valor de
loadBalancer.vips.controlPlaneVIP
Para mais informações, consulte VIPs na sub-rede do cluster de administrador.
Decida qual tipo de balanceamento de carga você quer usar. As opções são:
Balanceamento de carga em pacote MetalLB. Defina
loadBalancer.kind
como"MetalLB"
.Balanceamento de carga integrado com a F5 BIG-IP. Defina
loadBalancer.kind
como"F5BigIP"
e preencha a seçãof5BigIP
.Balanceamento de carga manual. Defina
loadBalancer.kind
como"ManualLB"
e preencha a seçãomanualLB
.
Para mais informações, consulte Visão geral do balanceamento de carga.
antiAffinityGroups
Defina antiAffinityGroups.enabled
como true
ou false
de acordo com sua preferência.
Use este campo para especificar se você quer que o Google Distributed Cloud crie regras de antiafinidade do VMware Distributed Resource Scheduler (DRS) para os nós do cluster de administrador, fazendo com que eles sejam distribuídos por pelo menos três hosts físicos no data center.
adminMaster
Se você quiser especificar a CPU e a memória para os nós do plano de controle do cluster
de administrador, preencha os campos cpus
e memoryMB
no
adminMaster
.
Defina o campo replicas
na seção adminMaster
como 3
.
proxy
Se a rede que terá os nós do cluster de administrador estiver atrás de um servidor
proxy, preencha a
seção
proxy
.
privateRegistry
Decida onde você quer manter as imagens de contêiner para os componentes do Google Distributed Cloud. As opções são:
Container Registry
Seu próprio registro particular do Docker.
Se você quiser usar seu próprio registro particular, preencha a
seção
privateRegistry
.
componentAccessServiceAccountKeyPath
O Google Distributed Cloud usa sua conta de serviço de acesso a componentes para fazer o download de componentes de cluster do Container Registry. Esse campo contém o caminho de um arquivo de chave JSON para sua conta de serviço de acesso a componentes.
Este campo já foi preenchido para você.
gkeConnect
Registre seu cluster de administrador
em uma frota do Google Cloud preenchendo a
seção
gkeConnect
. 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
. Se os IDs do projeto não forem iguais, a criação do cluster falhará.
Nas versões 1.28 e mais recentes, você tem a opção de especificar uma região em que os serviços Fleet
e Connect são executados em gkeConnect.location
. Se você não incluir esse campo,
o cluster usará as instâncias globais desses serviços.
Se você incluir gkeConnect.location
, a região especificada precisará ser a mesma configurada em cloudAuditLogging.clusterLocation
, stackdriver.clusterLocation
e gkeOnPremAPI.location
. Se as regiões não forem iguais, a criação do cluster falhará.
gkeOnPremAPI
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
.
A região gkeOnPremAPI.location
precisa ser a mesma especificada em
cloudAuditLogging.clusterLocation
, gkeConnect.location
e stackdriver.clusterLocation
. Se as regiões não forem iguais, a criação do cluster falhará.
Se você quiser inscrever todos os clusters do 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
comofalse
. Se você não quiser registrar nenhum cluster no projeto, desativegkeonprem.googleapis.com
(o nome do serviço da API GKE On-Prem) no projeto. Para instruções, consulte Como desativar serviços.
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 admin
.
Observe os seguintes requisitos para novos clusters:
O ID em
stackdriver.projectID
precisa ser o mesmo que o ID emgkeConnect.projectID
ecloudAuditLogging.projectID
.A região do Google Cloud definida em
stackdriver.clusterLocation
precisa ser igual à região definida emcloudAuditLogging.clusterLocation
egkeConnect.location
(se o campo estiver incluído no seu arquivo de configuração). Além disso, segkeOnPremAPI.enabled
fortrue
, a mesma região precisará ser definida emgkeOnPremAPI.location
.
Se os IDs do projeto e as regiões não forem iguais, a criação do cluster vai falhar.
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 emgkeConnect.projectID
estackdriver.projectID
.A região do Google Cloud definida em
cloudAuditLogging.clusterLocation
precisa ser a mesma definida emstackdriver.clusterLocation
egkeConnect.location
(se o campo estiver incluído no seu arquivo de configuração). Além disso, segkeOnPremAPI.enabled
fortrue
, a mesma região precisará ser definida emgkeOnPremAPI.location
.
Se os IDs do projeto e as regiões não forem iguais, a criação do cluster vai falhar.
clusterBackup
Se você quiser ativar o
backup do cluster de administrador,
defina
clusterBackup.datastore
como o
repositório de dados do vSphere
em que você quer salvar os backups do cluster.
autoRepair
Se você quiser
ativar o reparo automático de nós
no cluster de administrador, defina
autoRepair.enabled
como true
.
secretsEncryption
Se você quiser ativar a
criptografia de Secrets sempre ativada,
preencha a
seção
secretsEncryption
.
osImageType
Decida o tipo de imagem do SO que você quer usar para os nós do cluster de administrador e
preencha a
seção
osImageType
conforme necessário.
Exemplo de arquivos de configuração preenchidos
Aqui está um exemplo de um arquivo de configuração de cluster de administrador preenchido. A configuração ativa alguns, mas não todos os recursos disponíveis.
vc-01-admin-cluster.yaml
apiVersion: v1 kind: AdminCluster name: "gke-admin-01" bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.28.0-gke.1-full.tgz" vCenter: address: "vc01.example" datacenter: "vc-01" cluster: "vc01-workloads-1" resourcePool: "vc-01-pool-1" datastore: "vc01-datastore-1" caCertPath: "/usr/local/google/home/me/certs/vc01-cert.pem"" credentials: fileRef: path: "credential.yaml" entry: "vCenter" network: hostConfig: dnsServers: - "203.0.113.1" - "198.51.100.1" ntpServers: - "216.239.35.4" serviceCIDR: "10.96.232.0/24" podCIDR: "192.168.0.0/16" vCenter: networkName: "vc01-net-1" controlPlaneIPBlock: netmask: "255.255.248.0" gateway: "21.0.143.254" ips: - ip: "21.0.140.226" hostname: "admin-cp-vm-1" - ip: "21.0.141.48" hostname: "admin-cp-vm-2" - ip: "21.0.141.65" hostname: "admin-cp-vm-3" loadBalancer: vips: controlPlaneVIP: "172.16.20.59" kind: "MetalLB" antiAffinityGroups: enabled: true adminMaster: cpus: 4 memoryMB: 16384 replicas: 3 componentAccessServiceAccountKeyPath: "sa-key.json" 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" disableVsphereResourceMetrics: false clusterBackup: datastore: "vc-01-datastore-bu" autoRepair: enabled: true osImageType: "ubuntu_containerd"
Validar o arquivo de configuração
Depois de preencher o arquivo de configuração do cluster de administrador,
execute gkectl check-config
para verificar se o arquivo é válido:
gkectl check-config --config ADMIN_CLUSTER_CONFIG
Substitua ADMIN_CLUSTER_CONFIG pelo caminho do arquivo de configuração do cluster de administrador.
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. Instalar imagens do SO
Execute gkectl prepare
para inicializar o ambiente do vSphere:
gkectl prepare --config ADMIN_CLUSTER_CONFIG
O comando gkectl prepare
executa as seguintes tarefas preparatórias:
Importa as imagens do SO para o vSphere e as marca como modelos de VM.
Se você estiver usando um registro particular do Docker, as imagens do contêiner serão enviadas para seu registro.
Como alternativa, valide os atestados de build das imagens do contêiner, verificando se as imagens foram criadas e assinadas pelo Google e estão prontas para implantação.
5. Crie o cluster de administrador
Crie o cluster de administrador:
gkectl create admin --config ADMIN_CLUSTER_CONFIG
Se você usar o VPC Service Controls, poderá ver erros ao executar alguns
comandos do gkectl
, como "Validation Category: GCP - [UNKNOWN] GCP
service: [Stackdriver] could not get GCP services"
. Para evitar esses erros, adicione o parâmetro --skip-validation-gcp
aos seus comandos.
Retomar a criação do cluster de administrador após uma falha
Se a criação do cluster de administrador falhar ou for cancelada, será possível executar o comando create
novamente:
gkectl create admin --config ADMIN_CLUSTER_CONFIG
Localizar o arquivo kubeconfig do cluster de administrador
O comando gkectl create admin
cria um arquivo kubeconfig chamado
kubeconfig
no diretório atual. Você precisará desse arquivo kubeconfig
mais tarde para interagir com o cluster de administrador.
O arquivo kubeconfig contém o nome do cluster de administrador. Para acessar o nome do cluster, execute o seguinte:
kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
A saída mostra o nome do cluster. Exemplo:
NAME gke-admin-tqk8x
Se preferir, é possível alterar o nome e o local do arquivo kubeconfig.
Gerenciar o arquivo checkpoint.yaml
Quando você executou o comando gkectl create admin
para criar o cluster de administrador, ele
criou um arquivo de ponto de controle na mesma pasta do armazenamento de dados do disco
de dados do cluster de administrador. Por padrão, esse arquivo tem o nome
DATA_DISK_NAME‑checkpoint.yaml
. Se o comprimento de
DATA_DISK_NAME for maior ou igual a 245 caracteres, devido
ao limite de vSphere no tamanho do nome de arquivo, o nome será
DATA_DISK_NAME.yaml
.
Esse arquivo contém o estado e as credenciais do cluster de administrador e é usado para upgrades futuros. Não exclua esse arquivo, a menos que você esteja seguindo o processo de exclusão de um cluster de administrador.
Se você tiver ativado a criptografia de VM na instância do vCenter Server, precisará ter o
privilégio
Operações criptográficas.Direct Access
antes de criar ou fazer upgrade do cluster de
administrador. Caso contrário, o checkpoint não será enviado. Se você não conseguir
esse privilégio, desative o upload do arquivo de checkpoint usando a
sinalização oculta --disable-checkpoint
ao executar um comando relevante.
O arquivo checkpoint.yaml
é atualizado automaticamente quando você executa o
comando gkectl upgrade admin
ou um comando gkectl update
que
afeta o cluster de administrador.
6. Verifique se o cluster de administrador está em execução
Verifique se o cluster de administrador está em execução:
kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de administrador.
A saída mostra os nós do cluster de administrador. Exemplo:
admin-cp-vm-1 Ready control-plane,master ... admin-cp-vm-2 Ready control-plane,master ... admin-cp-vm-3 Ready control-plane,master ...
7. Fazer backup de arquivos
Recomendamos que você faça backup do arquivo kubeconfig do cluster de administrador. Ou seja, copie o arquivo kubeconfig da estação de trabalho do administrador para outro local. Se você perder o acesso à estação de trabalho do administrador ou se o arquivo kubeconfig na estação de trabalho de administrador for excluído acidentalmente, você ainda terá acesso ao cluster de administrador.
Também recomendamos que você faça backup da chave SSH privada do cluster de administrador. Em seguida, se você perder o acesso ao cluster de administrador, ainda vai poder usar o SSH para se conectar aos nós desse cluster. Isso permite resolver e investigar problemas de conectividade com o cluster de administrador.
Extraia a chave SSH do cluster de administrador para um arquivo chamado
admin-cluster-ssh-key
:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key
Agora já é possível fazer backup do admin-cluster-ssh-key
em outro local que quiser.
Políticas de RBAC
Quando você preenche a
seção gkeConnect
no arquivo de configuração do cluster de administrador, o cluster é registrado na sua
frota durante a criação ou atualizar. Para ativar
a funcionalidade de gerenciamento de frota, o Google Cloud implanta o
agente do Connect e cria uma conta de serviço do Google
que representa o projeto em que o cluster está registrado.
O agente do Connect estabelece uma conexão com a conta de serviço para processar
solicitações para o servidor da API Kubernetes do cluster. Assim, você tem acesso aos
recursos de gerenciamento de clusters e cargas de trabalho no Google Cloud, incluindo o acesso
ao Console do Google Cloud, que permite interagir com
o cluster.
O servidor da API Kubernetes do cluster de administrador precisa autorizar solicitações do agente do Connect. Para garantir isso, as seguintes políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês) são configuradas na conta de serviço:
Uma política de falsificação de identidade que autoriza o agente do Connect a enviar solicitações ao servidor da API Kubernetes em nome de uma conta de serviço.
Uma política de permissões que especifica as operações permitidas em outros recursos do Kubernetes.
A conta de serviço e as políticas do RBAC são necessárias para gerenciar o ciclo de vida dos clusters de usuário no Console do Google Cloud.
Solução de problemas
Consulte Solução de problemas na criação e no upgrade de clusters.