Como instalar o GKE On-Prem

Nesta página, explicamos como instalar o GKE On-Prem no vSphere. Nas instruções desta página, mostramos como criar um cluster de administrador e um cluster de usuário. Depois de criar o cluster de administrador e o cluster de usuário inicial, é possível criar mais clusters de usuário.

Antes de começar

  1. Configure seu ambiente no local conforme descrito em Requisitos do sistema.

  2. Conclua os procedimentos em Primeiros passos.

  3. Crie uma estação de trabalho de administrador no vSphere.

  4. Crie um registro particular do Docker, se quiser usar um.

  5. Saiba como ativar o balanceamento de carga manual, se quiser usá-lo.

  6. Configure IPs estáticos, se quiser usá-los.

  7. Conecte-se por SSH à sua estação de trabalho do administrador:

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

  8. Autorize gcloud a acessar o Google Cloud:

    gcloud auth login

  9. Registre gcloud como um auxiliar de credenciais do Docker (Leia mais sobre este comando):

    gcloud auth configure-docker

  10. 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 executar gcloud config get-value project.

Criar chaves privadas de contas de serviço na estação de trabalho de administrador

Em Primeiros passos, você criou quatro contas de serviço. Agora, você precisa criar um arquivo de chave privada JSON para cada uma dessas contas. 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
NAME                                    EMAIL
                                        access-service-account@my-gcp-project.iam.gserviceaccount.com
                                        register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-service-account@my-gcp-project.iam.gserviceaccount.com
                                        stackdriver-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, você fornece a conta de e-mail da conta relevante.

Acessar conta de serviço

gcloud iam service-accounts keys create access-key-file \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

em que [ACCESS_SERVICE_ACCOUNT_EMAIL] é o endereço de e-mail da conta de serviço de acesso.

Registrar conta de serviço

gcloud iam service-accounts keys create register-key \
--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 \
--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 \
--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 ativar a conta de serviço de acesso para a Google Cloud CLI

Ativar a conta de serviço de acesso para a gcloud CLI faz com que todos os comandos gcloud e gsutil sejam executados como essa conta de serviço. Como a conta de serviço de acesso tem permissão para acessar os binários do GKE On-Prem, ativar a conta para a gcloud CLI concede a você permissão para fazer o download dos binários do GKE On-Prem no Cloud Storage.

Para ativar a conta de serviço de acesso, execute o seguinte comando. Informe o caminho para o arquivo de chave da conta, se ele não estiver no diretório de trabalho atual:

gcloud auth activate-service-account --key-file=access-key.json

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.

bundlepath

Um pacote do GKE On-Prem é um conjunto de arquivos YAML. Coletivamente, os arquivos YAML descrevem todos os componentes em uma versão específica do GKE On-Prem.

Quando você cria uma estação de trabalho de administrador, ela vem com um pacote em /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz.

Defina o valor de bundlepath como o caminho do seu arquivo de pacote. 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.

É possível manter seu arquivo de pacote em um local diferente ou atribuir outro nome. No arquivo de configuração, verifique se o valor de bundlepath é o caminho para o arquivo de pacote, seja ele qual for.

gkeplatformversion

O campo gkeplatformversion mantém a versão do Kubernetes da versão do GKE On-Prem que você está instalando. Ele tem este formato:

[KUBERNETES_VERSION]-[GKE_PATCH]

Um exemplo de versão do Kubernetes é 1.12.7-gke.19.

Ao executar gkectl create-config, esse campo é preenchido para você.

Os esquemas de controle de versões para bundlepath e gkeplatformversion são diferentes. No entanto, uma determinada versão do pacote tem uma versão da plataforma GKE correspondente. Por exemplo, se a versão do pacote for 1.0.10, a versão da plataforma do GKE precisará ser 1.12.7-gke.19.

Para saber mais sobre a correspondência entre uma versão do pacote e a da plataforma do GKE, extraia o arquivo de pacote e veja os arquivos YAML. Em particular, abra gke-onprem-vsphere-[VERSION]-images.yaml e observe o campo osImages. É possível ver a versão da plataforma GKE no nome do arquivo de imagem do SO. Por exemplo, na imagem do SO a seguir, é possível ver que a versão da plataforma do GKE é 1.12.7-gke.19.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

vcenter

Use esse campo para declarar as configurações globais do seu vCenter Server. O GKE On-Prem precisa saber o endereço IP, o nome de usuário e a senha da instância do vCenter Server. Defina os valores em vcenter para especificar essas informações. Por exemplo:

vcenter:
  credentials:
    address: "203.0.113.1"
    username: "my-name"
    password: "my-password"

O GKE On-Prem precisa de algumas informações sobre a estrutura do ambiente do vSphere. Defina os valores em vcenter para especificar essas informações. Por exemplo:

vcenter:
  ...
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"
  resourcepool: "my-pool"

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. Por exemplo:

vcenter:
  ...
  datadisk: "my-disk.vmdk"

Se você quiser que o GKE On-Prem coloque o VMDK em um diretório, crie manualmente o diretório com antecedência. Por exemplo, use govc para criar um diretório:

govc datastore.mkdir my-gke-on-prem-directory

Em seguida, inclua o diretório no campo vcenter.datadisk:

vcenter:
  ...
  datadisk: "my-gke-on-prem-directory/my-disk.vmdk"

Quando um cliente, como o GKE On-Prem, envia uma solicitação ao vCenter Server, o servidor precisa provar a identidade ao cliente por meio de um certificado. O certificado é assinado por uma autoridade de certificação (CA). O cliente verifica o certificado do servidor usando o certificado da CA.

Defina vcenter.cacertpath como o caminho do certificado da CA. Exemplo:

vcenter:
  ...
  cacertpath: "/my-cert-directory/altostrat.crt"

Para informações sobre como fazer o download do certificado da CA, consulte Como fazer o download e instalar certificados raiz do vCenter Server (em inglês).

Se o vCenter Server usa um certificado autoassinado, é possível extrair o certificado conectando-se ao vCenter com openssl pela estação de trabalho de administrador:

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

gcrkeypath

Defina o valor de gcrkeypath como o caminho do arquivo de chave JSON para sua conta de serviço de acesso. Por exemplo:

gcrkeypath: "/my-key-directory/access-key.json"

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. Por exemplo:

lbmode: Integrated

gkeconnect

O campo gkeconnect contém informações que o GKE On-Prem precisa para configurar o gerenciamento dos clusters locais 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.

Se você quiser que o agente do Connect use um proxy para se comunicar com o Google Cloud, defina o valor de gkeconnect.proxy como o URL do proxy. Use o formato http(s)://[PROXY_ADDRESS].

Exemplo:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-directory/register-key.json"
  agentserviceaccountkeypath: "/my-key-directory/connect-key.json"
  proxy: https://203.0.113.20

stackdriver

O campo stackdriver contém informações que o GKE On-Prem precisa para armazenar entradas de registro geradas pelos clusters locais.

Defina stackdriver.projectid como o ID do projeto do Google Cloud em que você quer visualizar os registros do Stackdriver pertencentes aos clusters locais.

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.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"
  proxyconfigsecretname: ""
  enablevpc: false
  serviceaccountkeypath: "/my-key-directory/logging-key.json

privateregistryconfig

Se você tiver um registro particular do Docker, o campo privateregistryconfig conterá informações que o GKE On-Prem usa para enviar imagens ao seu registro particular. Se você não especificar um registro particular, o gkectl extrairá 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.

Quando o Docker recebe 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-directory/registry-ca.crt

admincluster

O campo admincluster contém informações que o GKE On-Prem precisa para criar o cluster de administrador.

Rede do vCenter: cluster de administrador

Em admincluster.vcenter.network, é possível escolher uma rede do vCenter diferente para o cluster de administrador. Isso substitui a configuração global que você forneceu em vcenter. Por exemplo:

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

DHCP ou endereços IP estáticos: cluster de administrador

Decida se você quer usar o protocolo de configuração de host dinâmico (DHCP, na sigla em inglês) para atribuir endereços IP aos nós do cluster de administrador. A alternativa é usar endereços IP estáticos para os nós do cluster. Se você optou por usar o modo de balanceamento de carga manual, precisará usar endereços IP estáticos para os nós do cluster.

Se você usar o DHCP, deixe o campo admincluster.ipblockfilepath comentado.

Se você usar endereços IP estáticos, precisará 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-directory/my-admin-hostconfig.yaml"

Balanceamento de carga integrado: cluster de administrador

Se você usa o modo de balanceamento de carga integrado, o GKE On-Prem precisa saber o endereço IP, o nome de usuário e a senha do balanceador de carga BIG-IP. Defina os valores em admincluster.bigip para especificar essas informações. Exemplo:

admincluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

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"

Balanceamento de carga manual: cluster de administrador

Se você usa o modo de balanceamento de carga manual, precisa usar endereços IP estáticos para os nós do cluster. Verifique se você definiu um valor para admincluster.ipblockfilepath. Exemplo:

admincluster:
  ipblockfilepath: "/my-config-directory/my-admin-hostconfig.yaml"

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. Por exemplo:

admincluster:
  manuallbspec:
    ...
    addonsnodeport: 30562

vips: cluster de administrador

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

serviceprange e podiprange: cluster de administração

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 os de sua escolha. Para informações sobre como escolher intervalos de IPs de serviço e pod, consulte Como otimizar a alocação de endereços IP.

Os intervalos de serviços e pods não podem se sobrepor. Além disso, os intervalos de serviços e pods escolhidos para o cluster de administrador não podem se sobrepor aos escolhidos para o cluster de usuário.

Exemplo:

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

usercluster

O campo usercluster contém informações que o GKE On-Prem precisa para criar o cluster de usuário inicial.

Rede do vCenter: cluster de administrador

Em admincluster.vcenter.network, é possível escolher uma rede do vCenter diferente para os clusters de usuário. Isso substitui a configuração global que você forneceu em vcenter. Por exemplo:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

DHCP ou endereços IP estáticos: cluster de usuário

Decida se quer usar o DHCP para atribuir endereços IP aos seus nós de cluster de usuário. A alternativa é usar endereços IP estáticos para os nós do cluster. Se você tiver escolhido o modo de balanceamento de carga manual, precisará usar endereços IP estáticos para os nós do cluster.

Se você usar o DHCP, deixe o campo usercluster.ipblockfilepath comentado.

Se você usar endereços IP estáticos, precisará 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-directory/my-user-hostconfig.yaml"

Balanceamento de carga integrado: cluster de usuário

Se você usa o modo de balanceamento de carga integrado, o GKE On-Prem precisa saber o endereço IP, o nome de usuário e a senha do balanceador de carga BIG-IP que você pretende usar no cluster de usuário. Defina os valores em usercluster.bigip para especificar essas informações. Exemplo:

usercluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"
  ...

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

Balanceamento de carga manual: cluster de usuário

Se você usa o modo de balanceamento de carga manual, precisa usar endereços IP estáticos para os nós do cluster. Verifique se você definiu um valor para usercluster.ipblockfilepath. Exemplo:

usercluster:
  ipblockfilepath: "/my-config-directory/my-user-hostconfig.yaml"
  ...

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

vips: cluster de usuário

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

serviceprange e podiprange: cluster de usuário

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 os de sua escolha. Para informações sobre como escolher intervalos de IPs de serviço e pod, consulte Como otimizar a alocação de endereços IP.

Os intervalos de serviços e pods não podem se sobrepor. Além disso, os intervalos de serviços e pods escolhidos para o cluster de usuário não podem se sobrepor aos escolhidos para o cluster de administrador.

Exemplo:

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

clustername

Defina o valor de usercluster.clustername como um nome de sua escolha. Por exemplo:

usercluster:
  ...
  clustername: "my-user-cluster-1"

masternode

O campo usercluster.masternode.replicas especifica quantos nós do plano de controle você quer que o cluster de usuário tenha. Os nós do plano de controle para o cluster de usuário executam os componentes do plano de controle para o cluster de usuário. Esse valor precisa ser 1 ou 3.

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

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.

Na versão 1.0.2-gke.3, os campos obrigatórios a seguir foram adicionados. Esses campos permitem fazer login em um cluster pelo Console do Cloud:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Se você não quer fazer login em um cluster pelo Console do Cloud, mas quer usar o OIDC, pode inserir valores do marcador nesses campos:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Para mais informações, consulte Como autenticar com o OIDC.

sni

Se você quiser fornecer um outro certificado de exibição para o servidor da API Kubernetes do cluster de usuário, insira valores em usercluster.sni.certpath e usercluster.sni.keypath. Por exemplo:

usercluster:
  ...
  sni:
    certpath: "/my-cert-directory/my-second-cert.crt"
    keypath: "/my-cert-directory/my-second-cert.key"

workernode

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.

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ó de trabalho do cluster de usuário. Por exemplo:

usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

Como validar o arquivo de configuração

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]

Se o comando retornar mensagens FAILURE, corrija os problemas e valide o arquivo novamente.

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 da instalação, execute 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ê usa 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 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 e também validou o arquivo. 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, execute o seguinte comando:

gkectl create cluster --config [CONFIG_FILE]

em que [CONFIG_FILE] é o arquivo de configuração que você gerou e modificou.

É possível reutilizar o arquivo de configuração para criar outros clusters de usuário.

Como conectar clusters ao Google

  • Quando você cria um cluster de usuário, ele é registrado automaticamente no Google Cloud. É possível ver um cluster do GKE On-Prem registrado no menu Clusters do Kubernetes no Console do Cloud. Nele, é possível fazer login no cluster para ver 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:

  1. Crie um Secret que contenha seu certificado e sua chave.
  2. 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.

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.

Comportamento de geração de registros padrão

Para gkectl e gkeadm, basta usar as configurações de geração de registros padrão:

  • Por padrão, as entradas de registro são salvas da seguinte maneira:

    • Para gkectl, o arquivo de registros padrão é /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e está vinculado ao arquivo logs/gkectl-$(date).log no diretório local em que você executa gkectl.
    • Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log no diretório local em que você executa gkeadm.
  • Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam impressas no terminal (quando --alsologtostderr é false).
  • O nível de detalhamento -v5 (padrão) abrange todas as entradas de registro exigidas pela equipe de suporte.
  • O arquivo de registros também contém o comando executado e a mensagem de erro.

Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.

Como especificar um local não padrão para o arquivo de registros

Se quiser especificar um local não padrão para o arquivo de registros gkectl, use a sinalização --log_file. O arquivo de registro que você especificar não será vinculado ao diretório local.

Se quiser especificar um local não padrão para o arquivo de registros gkeadm, use a sinalização --log_file.

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:

  1. 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

  2. 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