Nesta página, explicamos como instalar o GKE local para um VMware vSphere 6.5 ou 6.7 Update 3 usando IPs estáticos. Também é possível fazer a instalação usando um servidor DHCP.
Visão geral
Nas instruções desta página, você verá como criar um cluster de administrador e um cluster de usuário com três nós. Depois de criar os clusters, será possível criar outros clusters de usuário e adicionar ou remover nós em um cluster de usuário.
Antes de começar
Configure seu ambiente conforme descrito nestes tópicos:
Crie uma estação de trabalho de administrador no vSphere.
Saiba como ativar o balanceamento de carga manual, se quiser usá-lo.
Conecte-se à sua estação de trabalho do administrador:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
-
Se você tiver um proxy, todos os comandos
gkectl
usarão automaticamente o mesmo proxy definido noconfig.yaml
para solicitações de Internet da estação de trabalho de administrador. Esse é o ambiente recomendado, em que a estação de trabalho de administrador e todos os clusters usam o mesmo proxy. Neste caso de uso, não é necessário definir variáveis de ambiente de proxy.Opções de proxy manuais: se a estação de trabalho do administrador não estiver no mesmo proxy, você precisará configurar manualmente o ambiente para garantir que ele tenha acesso à Internet. É possível definir a variável de ambiente
HTTPS_PROXY
para usar o proxy em todas as solicitações deHTTPS
, incluindo os comandosgkectl
, mas também é necessário configurar a variável de ambienteNO_PROXY
para todas as solicitações que você quer excluir do proxy.Se você também precisar executar individualmente os comandos
gcloud
egsutil
, poderá configurar a Google Cloud CLI para sempre usar um proxy específico. Para mais instruções, consulte Como configurar a CLI gcloud para usar com um proxy/firewall.Use as seguintes opções para definir manualmente um proxy para os comandos
gkectl
:- Todos os comandos
gkectl
:É possível usar a variável de ambiente
HTTPS_PROXY
eNO_PROXY
para definir manualmente como todos os comandosgkectl
são enviados por proxy:- Defina um proxy diferente para os comandos
gkectl
. Exemplo:HTTPS_PROXY="http://my.other.proxy" NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
- Exclua os comandos
gkectl
do proxy. Exemplo:HTTPS_PROXY=""
export HTTP_PROXY="http://[PROXY_ADDRESS]" export HTTPS_PROXY="http://[PROXY_ADDRESS]" export NO_PROXY="[NO_PROXY_ADDRESSES]"
em que
- [PROXY_ADDRESS] pode estar vazio (
""
), ser um endereço IP de proxy ou o nome do host do proxy; - [NO_PROXY_ADDRESSES] pode ser uma lista separada por vírgulas de URLs, endereços IP ou nomes de host que você quer excluir do proxy.
- Defina um proxy diferente para os comandos
- Comandos
gkectl
únicos:Também é possível prefixar um comando
gkectl
individual com a variável de ambiente para usar um proxy especificado somente para essa chamada.Exemplos:
Para proxy dos comandos
gkectl
por meio de um proxy diferente do especificado no arquivo de configuração (config.yaml
), use a variável de ambienteHTTPS_PROXY
:- Para usar o proxy
http://my.other.proxy
:-
HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
-
HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
-
- Use um valor vazio para excluir um proxy:
HTTPS_PROXY="" gkectl create cluster --config config.yaml
HTTPS_PROXY="" gkectl check-config --config config.yaml
- Para usar o proxy
- Todos os comandos
Faça login no Google Cloud usando as credenciais da conta de usuário. A conta de usuário precisa ter pelo menos o papel de visualizador do IAM:
gcloud auth login
Configure um projeto padrão. Isso faz com que todos os comandos da CLI gcloud sejam executados no projeto, de modo que você não precise especificar o projeto para cada comando:
gcloud config set project [PROJECT_ID]
Substitua
[PROJECT_ID]
pelo ID do projeto. É possível encontrar o ID do projeto no Console do Cloud ou ao executargcloud config get-value project
.
Como escolher um registro de imagem de contêiner para instalação
Para a instalação, o GKE On-Prem precisa saber onde receber os componentes do cluster em contêiner. Você tem duas opções:
Container Registry
Por padrão, o GKE On-Prem usa um registro de imagem de contêiner do Google
hospedado pelo Container Registry.
Não é necessário fazer outras configurações: basta configurar o proxy para permitir
o tráfego do gcr.io
.
Registro particular do Docker
É possível optar por um registro particular do Docker para instalação. O GKE On-Prem
envia os componentes do cluster para esse registro do Docker. Para especificar um registro particular do Docker, defina o campo privateregistryconfig
.
Como configurar um registro particular do Docker para instalação (opcional)
Nesta seção, explicamos como configurar um registro do Docker para
instalar o GKE On-Prem. Para saber como criar um registro do Docker, consulte
Executar um registro acessível externamente.
Depois de configurar o registro, preencha o campo
privateregistryconfig
do arquivo de configuração do GKE On-Prem.
Se você quiser usar o registro particular do Docker para instalação, a VM da estação de trabalho do administrador precisará confiar na autoridade de certificação (CA, na sigla em inglês) que assinou o certificado. O GKE On-Prem não é compatível com registros do Docker não seguros. Ao iniciar o registro do Docker, você precisa fornecer um certificado e uma chave. O certificado pode ser assinado por uma autoridade de certificação (CA) pública ou autoassinado.
Para estabelecer essa confiança, execute as seguintes etapas na VM da estação de trabalho do administrador:
Crie uma pasta para manter o certificado:
sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
[REGISTRY_SERVER] é o endereço IP ou o nome do host da VM que executa o registro do Docker.
Copie o arquivo de certificado para
/etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt
. Você precisa nomear o arquivoca.crt
, mesmo que ele tenha outro nome.Reinicie o serviço do Docker:
sudo service docker restart
Verifique se é possível fazer login no Docker:
docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]
[USERNAME] e [PASSWORD] são as credenciais para fazer login no registro do Docker.
Agora, quando você executa gkectl prepare
durante a instalação, as imagens necessárias
são enviadas para o registro do Docker.
Solução de problemas da configuração do registro
GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
: verifique se você tem o endereço IP correto para a VM que executa o registro do Docker.login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized
: verifique se o nome de usuário e a senha estão corretos.GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority
: a VM da estação de trabalho do administrador não confia no certificado.
Como configurar endereços IP estáticos
Se você quiser usar endereços IP estáticos, precisará criar dois arquivos de configuração de host: um para o cluster de administrador e outro para o cluster de usuário. Os arquivos de configuração do host informam ao GKE On-Prem quais endereços IP e nomes de host precisam ser atribuídos aos nós do cluster.
Endereços IP estáticos para o cluster de administrador
O cluster de administrador precisa de endereços para os seguintes nós:
- Um nó para o plano de controle do cluster de administrador
- Dois nós para complementos no cluster de administrador
- Um nó temporário durante um upgrade do cluster de administrador
- Para cada cluster de usuário associado, um ou três nós
Para um cluster de usuário de alta disponibilidade (HA, na sigla em inglês), o cluster de administrador tem três nós que executam componentes do plano de controle para o cluster do usuário. Para um cluster de usuário que não seja de HA, o cluster de administrador tem um nó que executa componentes do plano de controle para o cluster de usuário.
Suponha que N seja o número de clusters de usuário que não sejam de HA que você pretende criar e H seja o número de clusters de usuário de HA que você quer criar. Em seguida, no arquivo de configuração do host do cluster de administrador, especifique pelo menos esta quantidade de endereços IP:
4 + N + 3 x H
Por exemplo, suponha que você queira criar um cluster de administrador e um de usuário de HA. Você precisará reservar sete endereços IP para o cluster de administrador. Veja um exemplo de arquivo de configuração de host de administrador que especifica sete endereços IP:
hostconfig: dns: 172.16.255.1 tod: 216.239.35.0 otherdns: - 8.8.8.8 - 8.8.4.4 othertod: - ntp.ubuntu.com blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7
Como visto no exemplo anterior, um arquivo de configuração de host contém uma estrutura de dados YAML.
O campo ips
é uma matriz de endereços IP e nomes de host. Esses são os endereços IP
e nomes de host que o GKE On-Prem atribuirá aos nós do
cluster de administrador.
No arquivo de configuração do host, você também especifica os endereços dos servidores DNS, servidores de horário e gateway padrão que os nós do cluster de administrador usarão.
Endereços IP estáticos para um cluster de usuário
Um cluster de usuário precisa de um endereço IP para cada nó e um endereço IP extra a ser usado para um nó temporário durante um upgrade do cluster de usuário.
Por exemplo, suponha que você queira criar um cluster de usuário que tenha cinco nós. Nesse caso, você precisará reservar seis endereços IP para o cluster de usuário. Veja um exemplo de arquivo de configuração de host de usuário que especifica seis pares de IP/nome do host.
hostconfig: dns: 172.16.255.1 tod: 216.239.35.0 otherdns: - 8.8.8.8 - 8.8.4.4 othertod: - ntp.ubuntu.com blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.17 hostname: user-host1 - ip: 172.16.20.18 hostname: user-host2 - ip: 172.16.20.19 hostname: user-host3 - ip: 172.16.20.20 hostname: user-host4 - ip: 172.16.20.21 hostname: user-host5 - ip: 172.16.20.22 hostname: user-host6
Cada hostname
é interpretado como um nome do host local, mas sem o domínio dele. Se você
especificar um nome de domínio totalmente qualificado, o domínio será cortado. Por exemplo,
host1.enterprise.net
torna-se host1
. O valor de um campo hostname
precisa estar em letras minúsculas.
Criar chaves privadas de contas de serviço na estação de trabalho de administrador
Em Como se preparar para a instalação, você criou quatro contas de serviço. Agora, você precisa criar um arquivo de chave privada JSON para cada uma dessas contas de serviço. Você fornecerá essas chaves durante a instalação.
Listar endereços de e-mail de contas de serviço
Primeiro, liste as contas de serviço no projeto do Google Cloud:
gcloud iam service-accounts list
Para um projeto do Google Cloud denominado my-gcp-project
, a saída deste comando
terá esta aparência:
gcloud iam service-accounts list ... EMAIL allowlisted-service-account@my-gcp-project.iam.gserviceaccount.com connect-register-service-account@my-gcp-project.iam.gserviceaccount.com connect-agent-service-account@my-gcp-project.iam.gserviceaccount.com log-mon-service-account@my-gcp-project.iam.gserviceaccount.com
Anote o endereço de e-mail de cada conta. Para cada uma das seções a seguir, forneça o e-mail da conta relevante.
Conta de serviço permitida na lista
gcloud iam service-accounts keys create whitelisted-key.json --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
[ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] é o endereço de e-mail da conta de serviço incluída na lista de permissões.
Registrar conta de serviço
gcloud iam service-accounts keys create register-key.json \ --iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]
[REGISTER_SERVICE_ACCOUNT_EMAIL] é o endereço de e-mail da conta de serviço de registro.
Conectar conta de serviço
gcloud iam service-accounts keys create connect-key.json \ --iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]
[CONNECT_SERVICE_ACCOUNT_EMAIL] é o endereço de e-mail da conta de serviço de conexão.
Conta de serviço do Cloud Monitoring
gcloud iam service-accounts keys create stackdriver-key.json \ --iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]
[STACKDRIVER_SERVICE_ACCOUNT_EMAIL] é o endereço de e-mail da conta de serviço do Cloud Monitoring.
Como gerar um arquivo de configuração
Para iniciar uma instalação, execute gkectl create-config
para gerar um
arquivo de configuração. Modifique o arquivo com as especificações do ambiente
e com as especificações do cluster que você quer.
Para gerar o arquivo, execute o seguinte comando, em que
--config [PATH]
é opcional e aceita um caminho e
um nome para o arquivo de configuração. Omitir
--config
cria config.yaml
no diretório de trabalho atual:
gkectl create-config [--config [PATH]]
Como modificar o arquivo de configuração
Agora que você gerou o arquivo de configuração, é necessário modificá-lo para que se adeque ao ambiente e atenda às expectativas dos clusters. As seções a seguir explicam cada campo, os valores esperados e onde é possível encontrar as informações. Alguns campos são comentados por padrão. Se alguns campos forem relevantes para a instalação, remova a marca de comentário e insira valores.
Nesta seção, mostramos instruções de como usar um único comando que cria um cluster de administrador e um cluster de usuário. Da versão 1.2 em diante, é possível criar os clusters de administrador e de usuário separadamente.
bundlepath
O arquivo de pacote do GKE On-Prem
contém todos os componentes em uma determinada versão do GKE On-Prem.
Quando você cria uma estação de trabalho de administrador, ela inclui um
pacote completo em
/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
. A versão desse pacote
corresponde à versão do
OVA que você importou
para criar a estação de trabalho do administrador.
Defina o valor de bundlepath
como o caminho do arquivo de pacote
da estação de trabalho do administrador. Ou seja, defina bundlepath
como:
/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
[VERSION] é a versão do GKE On-Prem que você está instalando. A versão mais recente é 1.3.2-gke.1.
É possível manter seu arquivo de pacote em um local diferente ou dar
um nome diferente. No arquivo de configuração, verifique se o valor
de bundlepath
é o caminho para o arquivo de pacote, seja ele qual for.
Especificação do vCenter
A especificação vcenter
contém informações sobre a instância do servidor vCenter.
O GKE On-Prem precisa dessas informações para se comunicar com o servidor
vCenter.
vcenter.credentials.address
O campo vcenter.credentials.address
contém o endereço IP ou o nome do host
do servidor vCenter.
Antes de preencher o vsphere.credentials.address field
, faça o download
do certificado de exibição do servidor vCenter e inspecione-o. Digite o comando a seguir para fazer o
download do certificado e salvá-lo em um arquivo chamado vcenter.pem
.
true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
Abra o arquivo de certificado para ver o nome comum e o alternativo do assunto:
openssl x509 -in vcenter.pem -text -noout
A saída mostra o nome comum (CN, na sigla em inglês) Subject
. Pode ser um endereço IP ou
um nome do host. Exemplo:
Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example
A saída também pode incluir um ou mais nomes de DNS em
Subject Alternative Name
:
X509v3 Subject Alternative Name: DNS:vcenter.my-domain.example
Escolha o nome comum Subject
ou um dos nomes de DNS em
Subject Alternative Name
para usar como o valor de vcenter.credentials.address
no arquivo de configuração. Por exemplo:
vcenter: credentials: address: "203.0.113.1" ...
vcenter: credentials: address: "my-host.my-domain.example" ...
Você precisa escolher um valor que apareça no certificado. Por exemplo, se o endereço IP
não aparecer no certificado, não será possível usá-lo para
vcenter.credentials.address
.
vcenter.credentials
O GKE On-Prem precisa saber o nome de usuário e a senha do servidor
vCenter. Para fornecer essas informações, defina os valores username
e password
em vcenter.credentials
. Por exemplo:
vcenter: credentials: ... username: "my-name" password: "my-password"
vcenter.datacenter, .datastore, .cluster, .network
O GKE On-Prem precisa de algumas informações sobre a estrutura do
ambiente do vSphere. Defina os valores em vcenter
para fornecer essas informações.
Por exemplo:
vcenter: ... datacenter: "MY-DATACENTER" datastore: "MY-DATASTORE" cluster: "MY-VSPHERE-CLUSTER" network: "MY-VIRTUAL-NETWORK"
vcenter.resourcepool
Um pool de recursos do vSphere
é um agrupamento lógico de VMs no cluster do vSphere. Se você estiver usando
um pool de recursos diferente do padrão, forneça um nome para
vcenter.resourcepool
. Por exemplo:
vcenter: ... resourcepool: "my-pool"
Se você quiser
que o GKE local implante os nós no pool de recursos padrão do
cluster do vSphere, forneça uma string vazia para vcenter.resourcepool
. Por exemplo:
vcenter: ... resourcepool: ""
vcenter.datadisk
O GKE On-Prem cria um disco de máquina virtual (VMDK, na sigla em inglês) a fim de
armazenar os dados do objeto do Kubernetes para o cluster de administrador. O instalador cria o VMDK para
você, mas é necessário fornecer um nome para o VMDK no campo vcenter.datadisk
.
Exemplo:
vcenter: ... datadisk: "my-disk.vmdk"
- Armazenamento de dados vSAN: como criar uma pasta para o VMDK
Se você estiver usando um armazenamento de dados vSAN, será necessário colocar o VMDK em uma pasta. Você precisa criar a pasta manualmente com antecedência. Para fazer isso, use
govc
para criar uma pasta:govc datastore.mkdir -namespace=true my-gke-on-prem-folder
Em seguida, defina
vcenter.datadisk
como o caminho do VMDK, incluindo a pasta. Exemplo:vcenter: ... datadisk: "my-gke-on-prem-folder/my-disk.vmdk"
Na versão 1.1.1 e anteriores, um problema conhecido exige que você forneça o caminho do identificador universal exclusivo (UUID, na sigla em inglês) da pasta, em vez do caminho do arquivo, para
vcenter.datadisk
. Copie isso da saída do comandogovc
acima.Em seguida, forneça o UUID da pasta no campo
vcenter.datadisk
. Não coloque uma barra antes do UUID. Por exemplo:vcenter: ... datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
Esse problema foi corrigido nas versões 1.1.2 e mais recentes.
vcenter.cacertpath
Quando um cliente, como o GKE On-Prem, envia uma solicitação ao servidor vCenter, o servidor precisa provar a própria identidade ao cliente, apresentando um certificado ou um pacote de certificados. Para verificar o certificado ou o pacote, o GKE On-Prem precisa ter o certificado raiz na cadeia de confiança.
Defina vcenter.cacertpath
como o caminho do certificado raiz. Exemplo:
vcenter: ... cacertpath: "/my-cert-folder/the-root.crt"
A instalação do VMware tem uma autoridade de certificação (CA, na sigla em inglês) que emite um certificado para o servidor vCenter. O certificado raiz na cadeia de confiança é um certificado autoassinado criado pela VMware.
Se você não quiser usar a CA do VMWare, que é o padrão, configure o VMware para usar uma autoridade de certificação diferente.
Se o servidor vCenter usar um certificado emitido pela CA do VMware padrão, haverá várias maneiras de conseguir o certificado raiz:
curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip
[SERVER_ADDRESS] é o endereço do servidor vCenter.
Em um navegador, digite o endereço do servidor vCenter. Na caixa cinza à direita, clique em Fazer o download de certificados de CA raiz confiáveis.
Digite este comando para receber o certificado de exibição:
true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts
Na saída, encontre um URL como este: https://[SERVER_ADDRESS]/afd/vecs/ca. Digite o URL em um navegador. Isso faz o download do certificado raiz.
O arquivo baixado é denominado downloads.zip
.
Descompacte o arquivo:
unzip downloads.zip
Se o comando para descompactar não funcionar na primeira vez, digite o comando novamente.
Encontre o arquivo de certificado em certs/lin
.
Especificação de proxy
Se a rede estiver protegida por um servidor proxy, preencha o campo proxy
com o proxy
HTTPS e os endereços que precisam ser excluídos do proxy. Por exemplo:
proxy: url: "https://username:password@domain" noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"
proxy.url
é o URL do proxy HTTPS.proxy.noproxy
inclui os intervalos de CIDR, os endereços IP, os domínios e os nomes de host que não podem ser encaminhados por proxy. Por exemplo, as chamadas para os endereços IP dos nós do cluster não podem ser encaminhadas por proxy. Portanto, se você tiver uma sub-rede que contenha somente nós de cluster, liste o intervalo CIDR da sub-rede no camponoproxy
. Seprivateregistryconfig
for especificado, esse endereço será adicionado automaticamente para evitar chamadas ao seu registro particular.
Especificação do cluster de administrador
A especificação admincluster
contém as informações de que o GKE On-Prem
precisa para criar o cluster de administrador.
admincluster.vcenter.network
Em admincluster.vcenter.network
, é possível especificar uma rede
vCenter para os nós do cluster de administrador. Isso modifica a configuração global que você
forneceu em vcenter
. Por exemplo:
admincluster: vcenter: network: MY-ADMIN-CLUSTER-NETWORK
admincluster.ipblockfilepath
Como você está usando endereços IP estáticos, é necessário ter um
arquivo de configuração de host, conforme descrito em
Como configurar IPs estáticos. Forneça o caminho para seu arquivo de
configuração de host no campo admincluster.ipblockfilepath
. Por exemplo:
admincluster: ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"
admincluster.manuallbspec (modo de balanceamento de carga manual)
O controlador de entrada no cluster de administrador é implementado como um
serviço do tipo NodePort.
O serviço tem um
ServicePort
para HTTP e outro para HTTPS. Se você estiver usando o modo de balanceamento de carga
manual, será necessário escolher valores nodePort
para esses ServicePorts.
Especifique os valores nodePort
em ingresshttpnodeport
e
ingresshttpsnodeport
. Por exemplo:
admincluster: ... manuallbspec: ingresshttpnodeport: 32527 ingresshttpsnodeport: 30139
O servidor da API Kubernetes no cluster de administrador é implementado como um serviço do
tipo NodePort
. Se você estiver usando o balanceamento de carga manual, será necessário escolher um
valor nodePort
para o serviço. Especifique o valor nodePort
em
controlplanenodeport
. Exemplo:
admincluster: ... manuallbspec: ... controlplanenodeport: 30968
O servidor de complementos no cluster de administrador é implementado como um serviço do
tipo NodePort
. Se você estiver usando o balanceamento de carga manual, será necessário escolher um
valor nodePort
para o serviço. Especifique o valor nodePort
em
controlplanenodeport
. Exemplo:
admincluster: manuallbspec: ... addonsnodeport: 30562
admincluster.bigip.credentials (modo de balanceamento de carga integrado)
Se você não estiver usando o modo de balanceamento de carga integrado,
deixe admincluster.bigip
com marca de comentário.
Se você estiver usando o modo de balanceamento de carga integrado, o GKE On-Prem precisará saber
o endereço IP ou o nome do host, o nome de usuário e a senha do balanceador de carga
F5 BIG-IP. Defina os valores em admincluster.bigip
para fornecer essas informações.
Por exemplo:
admincluster: ... bigip: credentials: address: "203.0.113.2" username: "my-admin-f5-name" password: "rJDlm^%7aOzw"
admincluster.bigip.partition (modo de balanceamento de carga integrado)
Se estiver usando o modo de balanceamento de carga integrado, você precisará
criar uma partição BIG-IP
para o cluster de administrador. Defina admincluster.bigip.partition
como o nome da
partição. Por exemplo:
admincluster: ... bigip: partition: "my-admin-f5-partition"
admincluster.vips
Se você usa o balanceamento de carga integrado ou manual para o
cluster de administrador, é necessário preencher o campo admincluster.vips
.
Defina o valor de admincluster.vips.controlplanevip
como o
endereço IP que você escolheu configurar no balanceador de carga
para o servidor da API Kubernetes do cluster de administrador. Defina o valor de
ingressvip
como o endereço IP que você escolheu configurar no balanceador de carga
para o controlador de entrada do cluster de administrador. Por exemplo:
admincluster: ... vips: controlplanevip: 203.0.113.3 ingressvip: 203.0.113.4
admincluster.serviceiprange e admincluster.podiprange
O cluster de administrador precisa ter um
intervalo de endereços IP
para usar em serviços e um para usar em pods. Esses intervalos
são especificados pelos campos admincluster.serviceiprange
e
admincluster.podiprange
. Esses campos são preenchidos quando você executa gkectl create-config
. Se quiser,
é possível alterar os valores preenchidos para valores de sua escolha.
Os intervalos de serviços e pods não podem se sobrepor. Além disso, os intervalos de serviços e pods não podem se sobrepor a endereços IP usados para nós em nenhum cluster.
Exemplo:
admincluster: ... serviceiprange: 10.96.232.0/24 podiprange: 192.168.0.0/16
Especificação do cluster de usuário
A especificação do cluster de usuário, usercluster
, contém informações que o
GKE On-Prem precisa para criar o cluster de usuário inicial.
Como desativar regras antiafinidade do VMware DRS (opcional)
O GKE On-Prem cria automaticamente regras de antiafinidade do VMware Distributed Resource Scheduler (DRS) para os nós do cluster de usuário, fazendo com que eles sejam distribuídos em pelo menos três hosts físicos no data center.
Esse recurso exige que o ambiente vSphere atenda às seguintes condições:
- O VMware DRS está ativado. O VMware DRS requer a edição de licença do vSphere Enterprise Plus. Para saber como ativar o DRS, consulte Como ativar o VMware DRS em um cluster.
- A conta de usuário do vSphere fornecida no campo
vcenter
tem a permissãoHost.Inventory.EditCluster
. - Há pelo menos três hosts físicos disponíveis.
Lembre-se de que, se você tiver uma licença padrão do vSphere, não será possível ativar o VMware DRS.
Se você não tiver o DRS ativado ou se não tiver pelo menos três hosts para
os quais as VMs do vSphere podem ser programadas, adicione
usercluster.antiaffinitygroups.enabled: false
ao arquivo de configuração.
Por exemplo:
usercluster: ... antiaffinitygroups: enabled: false
Para mais informações, consulte as Notas de lançamento 1.1.0-gke.6.
- Para clusters que executam mais de três nós
- Se o vSphere vMotion mover um nó para outro host, as cargas de trabalho do nó precisarão ser reiniciadas antes de serem distribuídas novamente entre os hosts.
usercluster.vcenter.network
Em usercluster.vcenter.network
, é possível especificar uma rede
vCenter para os nós do cluster de usuário. Isso modifica a configuração global que você
forneceu em vcenter
. Por exemplo:
usercluster: vcenter: network: MY-USER-CLUSTER-NETWORK
usercluster.ipblockfilepath
Como você está usando endereços IP estáticos, é necessário ter um arquivo de configuração
de host, conforme descrito em Como configurar IPs estáticos.
Forneça o caminho para seu arquivo de
configuração de host no campo usercluster.ipblockfilepath
. Por exemplo:
usercluster: ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"
usercluster.manuallbspec
(modo de balanceamento de carga manual)
O controlador de entrada no cluster do usuário é implementado como um
serviço do tipo NodePort.
O serviço tem um
ServicePort
para HTTP e outro para HTTPS. Se você estiver usando o modo de balanceamento de carga
manual, será necessário escolher valores nodePort
para esses ServicePorts.
Especifique os valores nodePort
em ingresshttpnodeport
e
ingresshttpsnodeport
. Por exemplo:
usercluster: manuallbspec: ingresshttpnodeport: 30243 ingresshttpsnodeport: 30879
O servidor da API Kubernetes no cluster de usuário é implementado como um serviço do
tipo NodePort
. Se você estiver usando o balanceamento de carga manual, será necessário escolher um
valor nodePort
para o serviço. Especifique o valor nodePort
em
controlplanenodeport
. Por exemplo:
usercluster: ... manuallbspec: ... controlplanenodeport: 30562
usercluster.bigip.credentials
(modo de balanceamento de carga integrado)
Se você estiver usando
o modo de balanceamento de carga integrado,
o GKE On-Prem precisará saber o endereço IP ou o nome do host, o nome de usuário e
a senha do balanceador de carga F5 BIG-IP que você pretende usar para o cluster de
usuário. Defina os valores em usercluster.bigip
para fornecer essas informações.
Por exemplo:
usercluster: ... bigip: credentials: address: "203.0.113.5" username: "my-user-f5-name" password: "8%jfQATKO$#z" ...
usercluster.bigip.partition
(modo de balanceamento de carga integrado)
Se estiver usando o modo de balanceamento de carga integrado, você precisará
criar uma partição BIG-IP
para seu cluster de usuário. Defina usercluster.bigip.partition
como o nome da
partição. Por exemplo:
usercluster: ... bigip: partition: "my-user-f5-partition" ...
usercluster.vips
Se você usa o balanceamento de carga integrado ou manual para o cluster
de usuário, é necessário preencher o campo usercluster.vips
.
Defina o valor de usercluster.vips.controlplanevip
como o
endereço IP que você escolheu configurar no balanceador de carga
para o servidor da API Kubernetes do cluster de usuário. Defina o valor de
ingressvip
como o endereço IP que você escolheu configurar no balanceador de carga
para o controlador de entrada do cluster de usuário. Por exemplo:
usercluster: ... vips: controlplanevip: 203.0.113.6 ingressvip: 203.0.113.7
usercluster.serviceiprange
e usercluster.podiprange
O cluster de usuário precisa ter um
intervalo de endereços IP
para usar em serviços e um para usar em pods. Esses intervalos
são especificados pelos campos usercluster.serviceiprange
e
usercluster.podiprange
. Esses campos são preenchidos quando você executa gkectl create-config
. Se quiser,
é possível alterar os valores preenchidos para valores de sua escolha.
Os intervalos de serviços e pods não podem se sobrepor. Além disso, os intervalos de serviços e pods não podem se sobrepor a endereços IP usados para nós em nenhum cluster.
Exemplo:
usercluster: ... serviceiprange: 10.96.233.0/24 podiprange: 172.16.0.0/12
usercluster.clustername
Defina o valor de usercluster.clustername
como um nome de sua escolha. Escolha um
nome com até 40 caracteres. Por exemplo:
usercluster: ... clustername: "my-user-cluster-1"
usercluster.masternode.replicas
O campo usercluster.masternode.replicas
especifica quantos nós do plano de controle você quer que o cluster do usuário tenha. O nó do plano de controle do cluster de usuário executa o plano de controle do usuário, os componentes do plano de controle do Kubernetes. Esse valor precisa ser 1
ou 3
:
- Defina este campo como
1
para executar um plano de controle do usuário. - Defina este campo como
3
se quiser ter um plano de controle de usuário de alta disponibilidade (HA) composto de três nós, cada um executando um plano de controle de usuário.
usercluster.masternode.cpus
e usercluster.masternode.memorymb
Os campos usercluster.masternode.cpus
e usercluster.masternode.memorymb
especificam o número de CPUs e a quantidade de memória, em megabytes, que são alocadas para cada nó do plano de controle do cluster de usuário. Por exemplo:
usercluster: ... masternode: cpus: 4 memorymb: 8192
usercluster.workernode.replicas
O campo usercluster.workernode.replicas
especifica quantos nós de trabalho você
quer que o cluster de usuário tenha. Os nós de trabalho executam as cargas de trabalho do cluster.
usercluster.workernode.cpus
e usercluster.workernode.memorymb
Os campos usercluster.masternode.cpus
e usercluster.masternode.memorymb
especificam
quantas CPUs e quanta memória, em megabytes, são alocadas para cada
nó de trabalho do cluster de usuário. Por exemplo:
usercluster: ... workernode: cpus: 4 memorymb: 8192 replicas: 3
usercluster.oidc
Se você quiser que os clientes do cluster de usuário usem a autenticação OIDC, defina
valores para os campos em usercluster.oidc
. A configuração do protocolo OIDC é opcional.
Para saber como configurar o OIDC, consulte Como autenticar com o OIDC.
- Sobre a instalação da versão 1.0.2-gke.3
A versão 1.0.2-gke.3 introduz os campos OIDC (
usercluster.oidc
) a seguir. Esses campos permitem fazer login em um cluster do console do Google Cloud:- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
Na versão 1.0.2-gke.3, se você quiser usar o OIDC, o campo
clientsecret
será obrigatório, mesmo que você não queira fazer login em um cluster no console do Google Cloud. Nesse caso, forneça um valor de marcador paraclientsecret
:oidc: clientsecret: "secret"
usercluster.sni
A Server Name Indication (SNI), uma extensão do Transport Layer Security (TLS), permite que os servidores apresentem vários certificados em apenas um endereço IP e uma porta TCP, dependendo do nome do host indicado pelo cliente.
Se a CA já estiver distribuída como uma CA confiável para clientes fora do cluster de usuário e você quiser confiar nessa cadeia para identificar clusters confiáveis, configure o servidor da API Kubernetes com um certificado extra que é apresentado a clientes externos do endereço IP do balanceador de carga.
Para usar a SNI com seus clusters de usuário, você precisa ter sua própria CA e infraestrutura de chave pública (ICP). Provisione um certificado de exibição separado para cada cluster de usuário. O GKE On-Prem adicionará cada certificado de exibição extra ao respectivo cluster de usuário.
Se quiser configurar a SNI para o servidor da API Kubernetes do cluster de usuário, forneça
valores para usercluster.sni.certpath
(caminho para o certificado externo) e
usercluster.sni.keypath
(caminho para o arquivo de chave privada do certificado externo).
Por exemplo:
usercluster: ... sni: certpath: "/my-cert-folder/example.com.crt" keypath: "/my-cert-folder/example.com.key"
lbmode
É possível usar o balanceamento de carga integrado ou o balanceamento de carga manual. A escolha do modo de balanceamento de carga se aplica ao cluster de administrador e ao cluster de usuário inicial. Isso também se aplicará a todos os outros clusters de usuário que você criar no futuro.
Para especificar sua opção de balanceamento de carga, defina o valor de lbmode
como
Integrated
ou Manual
. Exemplo:
lbmode: Integrated
gkeconnect
A especificação gkeconnect
contém informações de que o GKE On-Prem
precisa para configurar o gerenciamento dos clusters no local no console do Google Cloud.
Defina gkeconnect.projectid
como o ID do projeto do Google Cloud
em que você quer gerenciar os clusters locais.
Defina o valor de gkeconnect.registerserviceaccountkeypath
como o caminho do
arquivo de chave JSON para a
conta de serviço de registro.
Defina o valor de gkeconnect.agentserviceaccountkeypath
como o caminho do
arquivo de chave JSON para a
conta de serviço de conexão.
Exemplo:
gkeconnect: projectid: "my-project" registerserviceaccountkeypath: "/my-key-folder/register-key.json" agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
stackdriver
A especificação stackdriver
contém informações que o GKE On-Prem
precisa para armazenar entradas de registro geradas pelos clusters no local.
Defina stackdriver.projectid
como o ID do projeto do Google Cloud
em que você quer visualizar os registros do Stackdriver pertencentes aos clusters no local.
Defina stackdriver.clusterlocation
como uma região do Google Cloud em que você quer
armazenar registros do Stackdriver. É recomendável escolher uma região próxima
ao data center local.
Defina stackdriver.enablevpc
como true
se você tiver a rede do cluster
controlada por uma VPC. Isso garante que toda
a telemetria flua pelos endereços IP restritos do Google.
Defina stackdriver.serviceaccountkeypath
como o caminho do arquivo de chave JSON para
a
conta de serviço do Stackdriver Logging.
Exemplo:
stackdriver: projectid: "my-project" clusterlocation: "us-west1" enablevpc: false serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"
privateregistryconfig
Se você tiver um
registro privado do Docker,
o campo privateregistryconfig
conterá informações que o GKE On-Prem
usa para enviar imagens para seu registro particular. Se você não especificar um registro
particular, gkectl
receberá as imagens de contêiner do GKE On-Prem do
repositório do Container Registry, gcr.io/gke-on-prem-release
, durante a instalação.
Em privatedockerregistry.credentials
, defina address
como o endereço IP da
máquina que executa o registro particular do Docker. Defina username
e
password
como o nome de usuário e a senha do registro particular do Docker. O valor definido para address
é adicionado automaticamente a proxy.noproxy
.
Quando o Docker extrai uma imagem do seu registro particular, o registro precisa comprovar a própria identidade apresentando um certificado. O certificado do registro é assinado por uma autoridade de certificação (CA). O Docker usa o certificado da CA para validar o certificado do registro.
Defina privateregistryconfig.cacertpath
como o caminho do certificado da CA. Exemplo:
privateregistryconfig ... cacertpath: /my-cert-folder/registry-ca.crt
gcrkeypath
Defina o valor de gcrkeypath
como o caminho do arquivo de chave JSON para a
conta de serviço incluída na lista de permissões.
Exemplo:
gcrkeypath: "/my-key-folder/whitelisted-key.json"
cloudauditlogging
Se você quiser enviar os registros de auditoria do Kubernetes para o projeto do Google Cloud, preencha a especificação cloudauditlogging
. Por exemplo:
cloudauditlogging: projectid: "my-project" # A GCP region where you would like to store audit logs for this cluster. clusterlocation: "us-west1" # The absolute or relative path to the key file for a GCP service account used to # send audit logs from the cluster serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"
Saiba mais sobre como usar a geração de registros de auditoria.
Como validar o arquivo de configuração
Conclua esta etapa na sua estação de trabalho de administrador.
Depois de modificar o arquivo de configuração, execute gkectl check-config
para
verificar se o arquivo é válido e pode ser usado para instalação:
gkectl check-config --config [PATH_TO_CONFIG] --fast
Se o comando retornar mensagens FAILURE
, corrija os problemas e valide o
arquivo novamente. Use a sinalização --fast
para pular as verificações que criam VMs de teste, que
dependem da imagem do SO de nó que está sendo enviada da estação de trabalho do administrador para o
vCenter por gkectl prepare
.
Como pular validações
Os comandos gkectl
a seguir executam automaticamente validações no seu
arquivo de configuração:
gkectl prepare
gkectl create cluster
gkectl upgrade
Para pular as validações de um comando, transmita --skip-validation-all
. Por exemplo,
para pular todas as validações de gkectl prepare
:
gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all
Para ver todas as sinalizações disponíveis e pular validações específicas:
gkectl check-config --help
Como executar gkectl prepare
Antes de instalar, você precisa executar gkectl prepare
na estação de trabalho do administrador
para inicializar o ambiente do vSphere. O gkectl prepare
executa as
seguintes tarefas:
Importe a imagem do SO do nó para o vSphere e marque-a como um modelo.
Se você estiver usando um registro particular do Docker, envie imagens do GKE On-Prem 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.
Execute gkectl prepare
com o arquivo de configuração do GKE On-Prem, em que
--validate-attestations
é opcional:
gkectl prepare --config [CONFIG_FILE] --validate-attestations
A saída positiva de --validate-attestations
é Image [IMAGE_NAME] validated
.
Como validar o arquivo de configuração novamente
Depois de fazer upload da imagem do SO de nó executando gkectl prepare
, execute
gkectl check-config
sem a sinalização --fast
, para que outras verificações que
criam VMs de teste possam ser executadas.
gkectl check-config --config [PATH_TO_CONFIG]
Se o comando retornar mensagens FAILURE
, corrija os problemas e valide o
arquivo novamente.
Como instalar o GKE On-Prem
Você criou um arquivo de configuração que especifica a aparência do ambiente
e as características do cluster. Além disso, também validou os arquivos. Você executou
gkectl prepare
para inicializar o ambiente com o software
GKE On-Prem. Agora você está pronto para iniciar uma nova instalação do
GKE On-Prem.
Para instalar o GKE On-Prem, crie os clusters de administrador e usuário. As etapas a seguir criam o cluster de administrador e de usuário durante o mesmo processo. Se quiser, consulte Como criar clusters de administradores e usuários separadamente para mais detalhes.
Para criar os clusters de administrador e usuário:
Execute o comando
gkectl create cluster
para criar o cluster de administrador e o cluster de usuário.gkectl create cluster --config [CONFIG_FILE]
em que [CONFIG_FILE] é o arquivo de configuração que você já criou.
O comando
gkectl create cluster
cria arquivoskubeconfig
chamados[CLUSTER_NAME]-kubeconfig
no diretório atual em que [CLUSTER_NAME] é o nome que você definiu paracluster
. Exemplo:MY-VSPHERE-CLUSTER-kubeconfig
A documentação do GKE On-Prem usa os seguintes marcadores para se referir a esses arquivos
kubeconfig
:- Cluster de administrador: [ADMIN_CLUSTER_KUBECONFIG]
- Cluster de usuário: [USER_CLUSTER_KUBECONFIG]
Verifique se o cluster foi criado e está em execução:
Para verificar o cluster de administrador, execute o seguinte comando:
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
A saída mostra os nós do cluster de administrador.
Para verificar o cluster de usuário, execute o seguinte comando:
kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]
A saída mostra os nós do cluster de usuário. Por exemplo:
NAME STATUS ROLES AGE VERSION xxxxxx-1234-ipam-15008527 Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-1500852a Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-15008536 Ready <none> 12m v1.14.7-gke.24
Aprenda a reutilizar o arquivo de configuração para criar clusters de usuário extras.
Como retomar uma instalação
Se a instalação for interrompida após a criação do cluster de administrador, será possível retomar a instalação seguindo estas etapas:
- Remova a especificação
admincluster
do arquivo de configuração. Execute
gkectl create cluster
com as sinalizações--kubeconfig
e--skip-validation-all
para transmitir no arquivo kubeconfig do cluster de administrador e pular as verificações de simulação:gkectl create cluster \ --config [CONFIG_FILE] \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --skip-validation-all
[ADMIN_CLUSTER_NAME] é o kubeconfig do cluster de administrador, que foi criado no diretório de trabalho quando você iniciou a instalação.
Como conectar clusters ao Google
Quando você preenche a especificação
gkeconnect
, seu cluster de usuário é registrado automaticamente no console do Google Cloud. É possível ver um cluster do GKE On-Prem registrado no menu Clusters do Kubernetes do console do Google Cloud. Nele, é possível fazer login no cluster para visualizar as cargas de trabalho.Se o cluster não aparecer no Console do Cloud dentro de uma hora após a criação dele, consulte Solução de problemas de conexão.
Como ativar a entrada
Depois que o cluster de usuário estiver em execução, você precisará ativar a entrada criando um objeto de gateway. A primeira parte do manifesto de gateway é sempre esta:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system
É possível personalizar o restante do manifesto de acordo com suas necessidades. Por exemplo, este manifesto diz que os clientes podem enviar solicitações na porta 80 usando o protocolo HTTP/2 e qualquer nome do host:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system servers: - port: number: 80 protocol: HTTP2 name: http hosts: - "*"
Se você quiser aceitar solicitações HTTPS, forneça um ou mais certificados que o controlador de entrada possa apresentar aos clientes.
Para fornecer um certificado:
- Crie um Secret que contenha seu certificado e sua chave.
- Crie um objeto de gateway, ou modifique um que já exista, que faça referência
ao Secret. O nome do objeto de gateway precisa ser
istio-autogenerated-k8s-ingress
.
Por exemplo, suponha que você já tenha criado um arquivo de certificado
ingress-wildcard.crt
e um arquivo de chave ingress-wildcard.key
.
Crie um Secret chamado ingressgateway-wildcard-certs
:
kubectl create secret tls \ --namespace gke-system \ ingressgateway-wildcard-certs \ --cert ./ingress-wildcard.crt \ --key ./ingress-wildcard.key
Este é um manifesto de um gateway que se refere ao Secret. Os clientes podem chamar na porta 443 usando o protocolo HTTPS e qualquer nome do host que corresponda a *.example.com. Observe que o nome do host no certificado precisa corresponder ao nome do host no manifesto, *.example.com, neste exemplo:
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-autogenerated-k8s-ingress namespace: gke-system spec: selector: istio: ingress-gke-system servers: - port: number: 80 protocol: HTTP2 name: http hosts: - "*" - hosts: - "*.example.com" port: name: https-demo-wildcard number: 443 protocol: HTTPS tls: mode: SIMPLE credentialName: ingressgateway-wildcard-certs
Para criar vários certificados TLS para hosts diferentes, modifique o manifesto de gateway.
Salve o manifesto em um arquivo chamado my-gateway.yaml
e crie o gateway:
kubectl apply -f my-gateway.yaml
Agora, é possível usar objetos de Entrada do Kubernetes de maneira padrão.
Como criar clusters de administrador e de usuário separadamente
Do GKE On-Prem versão 1.2 em diante, é possível criar clusters de administrador e de usuário separadamente. Ou seja, é possível começar criando somente um cluster de administrador. Em seguida, é possível criar um ou mais clusters de usuário conforme necessário.
Antes da versão 1.2:
Seu primeiro cluster de usuário sempre usou o armazenamento de dados dos clusters de administrador. Os clusters de usuário criados posteriormente podem usar um armazenamento de dados separado do armazenamento de dados do cluster de administrador.
Se você especificou um armazenamento de dados separado para um cluster de usuário, os nós de trabalho do cluster de usuário e os PersistentVolumes (PVs) dos nós de trabalho usaram o armazenamento de dados separado. No entanto, as VMs do plano de controle do usuário e os PVs associados usaram o armazenamento de dados do cluster de administrador.
Da versão 1.2 em diante:
Qualquer cluster de usuário, mesmo o primeiro cluster de uso, pode usar um armazenamento de dados separado do cluster de administrador.
Se você especificar um armazenamento de dados separado para um cluster de usuário, os nós de trabalho desse cluster, os PVs para esses nós, as VMs do plano de controle do usuário e os PVs dessas VMs usarão esse armazenamento.
Para criar somente um cluster de administrador, remova a seção usercluster
inteira
do arquivo de configuração do cluster. Em seguida, insira o comando gkectl create
:
gkectl create --config [ADMIN_CONFIG_FILE]
[ADMIN_CONFIG_FILE] é o caminho do arquivo de configuração que
tem a seção usercluster
removida.
Em seguida, crie um arquivo de configuração que tenha a seção admincluster
inteira
removida. Nesse arquivo, é possível especificar um armazenamento de dados do vSphere que seja diferente
do armazenamento de dados do cluster de administrador. Para especificar um armazenamento de dados, insira um valor para
vcenter.credentials.datastore
. Por exemplo:
vcenter: credentials: ... ... datastore: "my-user-cluster-datastore"
Para criar um cluster de usuário, digite este comando:
gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
em que:
- [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador;
- [USER_CLUSTER_CONFIG] é o arquivo de configuração do cluster de usuário.
Limitações do GKE On-Prem
Limitação | Descrição |
---|---|
Limites máximo e mínimo para clusters e nós | Consulte Cotas e limites. O desempenho do ambiente pode afetar esses limites. |
Exclusividade para nomes de cluster de usuário | Todos os clusters de usuário registrados no mesmo projeto do Google Cloud precisam ter nomes exclusivos. |
Não é possível implantar em mais de um data center do vCenter e/ou do vSphere | Atualmente, é possível implantar apenas um cluster de administrador e um conjunto de clusters de usuário associados a somente um data center do vCenter e/ou do vSphere. Não é possível implantar os mesmos clusters de administrador e de usuário em mais de um data center do vCenter e/ou do vSphere. |
Não é possível alterar as configurações do cluster de maneira declarativa após a criação | Embora você consiga criar outros clusters e redimensionar clusters atuais, não é possível alterar um cluster atual por meio do arquivo de configuração. |
Solução de problemas
Para mais informações, consulte Solução de problemas.
Como diagnosticar problemas de cluster usando gkectl
Use os comandos gkectl diagnose
para identificar problemas de cluster
e compartilhar informações do cluster com o Google. Consulte
Como diagnosticar problemas de cluster.
Como executar comandos gkectl
de maneira detalhada
-v5
Como registrar erros gkectl
em stderr
--alsologtostderr
Como localizar registros gkectl
na estação de trabalho do administrador
Mesmo que você não transmita as sinalizações de depuração, é possível visualizar
os registros gkectl
no seguinte diretório da estação de trabalho do administrador:
/home/ubuntu/.config/gke-on-prem/logs
Como localizar registros da API Cluster no cluster de administrador
Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:
Encontre o nome do pod de controladores da API Cluster no namespace
kube-system
, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use
grep
ou uma ferramenta semelhante para pesquisar erros:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
Como depurar problemas de F5 BIG-IP com o kubeconfig do nó do plano de controle do cluster de administrador
Após uma instalação, o GKE On-Prem gera um arquivo kubeconfig no diretório inicial da estação de trabalho do administrador denominado internal-cluster-kubeconfig-debug
. Esse arquivo kubeconfig é idêntico ao kubeconfig do cluster de administrador, com a diferença de que ele aponta diretamente para o nó do plano de controle do cluster de administrador, em que o plano de controle de administrador é executado. É possível usar o arquivo internal-cluster-kubeconfig-debug
para depurar problemas de F5 BIG-IP.
Falha na validação de gkectl check-config
: não é possível encontrar partições de F5 BIG-IP
- Sintomas
A validação falha porque não são encontradas partições de F5 BIG-IP, embora elas existam.
- Causas possíveis
Um problema com a API F5 BIG-IP pode causar falha na validação.
- Resolução
Tente executar
gkectl check-config
novamente.
Falha em gkectl prepare --validate-attestations
: não foi possível validar o atestado de versão
- Sintomas
Executar
gkectl prepare
com a sinalização--validate-attestations
opcional retorna o seguinte erro:could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
- Causas possíveis
Um atestado pode não existir para as imagens afetadas.
- Resolução
Tente fazer o download e implantar o OVA da estação de trabalho de administrador novamente, conforme instruído em Como criar uma estação de trabalho de administrador. Se o problema persistir, entre em contato com o Google para receber ajuda.
Como depurar usando os registros do cluster de inicialização
Durante a instalação, o GKE On-Prem cria um cluster temporário de inicialização. Após uma instalação bem-sucedida, o GKE On-Prem exclui o cluster de inicialização, deixando você com o cluster de administrador e de usuário. Geralmente, não há motivo para interagir com esse cluster.
Se algo der errado durante uma instalação e você tiver transmitido
--cleanup-external-cluster=false
para gkectl create cluster
,
talvez seja útil realizar a depuração usando os registros do cluster de inicialização. Encontre
o pod e acesse os registros dele:
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]
A seguir
- Aprenda a criar outros clusters de usuário.
- Veja seus clusters no Console do Google Cloud.
- Faça login nos clusters.