Esta é a primeira parte de um guia que mostra uma pequena instalação de prova de conceito do GKE no VMware com um único cluster de usuário.
Este documento mostra como configurar ambientes mínimos do vSphere e do Google Cloud para essa instalação e planejar seus endereços IP, enquanto a próxima seção Criar clusters básicos mostra como criar uma estação de trabalho de administrador, um cluster de administrador e um cluster de usuário.
A infraestrutura configurada com este guia talvez não seja adequada para suas necessidades de produção e casos de uso reais. Para mais informações sobre as instalações de produção, consulte a Visão geral da instalação e os guias.
Antes de começar
Leia a Visão geral do GKE no VMware, que fornece uma visão geral de como o GKE no VMware funciona, incluindo o papel de cada componente que você instalará nesta configuração.
Consulte as versões compatíveis com o vSphere.
Consulte os requisitos de licença do vSphere. Para uma instalação mínima, uma licença do vSphere Standard é suficiente.
Você precisa de uma instância em execução do vCenter Server.
Você precisa de uma conta de usuário do vCenter com privilégios suficientes. Anote o nome de usuário e a senha dessa conta.
Você precisa conhecer alguns conceitos básicos do Google Cloud, incluindo projetos, permissões do IAM e contas de serviço. Caso contrário, consulte os seguintes guias para mais informações:
Visão geral do procedimento
Estas são as principais etapas envolvidas na configuração:
- Configure o ambiente. Verifique se você atende aos requisitos de recursos. Fornecemos um exemplo de configuração para um host ESXi e repositório de dados do vSphere que atendem aos requisitos para essa instalação.
- Configurar objetos do vSphere. Os componentes do GKE no VMware são executados em uma hierarquia de objetos do vSphere.
- Planejar seus endereços IP O GKE no VMware exige que você forneça endereços IP para todos os nós, além dos endereços IP virtuais (VIPs) para acesso de administradores e usuários à implantação. Nesta configuração, você usará endereços IP estáticos para os nós do cluster. Oferecemos exemplos, mas recomendamos que você consulte seu administrador de rede para escolher endereços adequados para sua própria rede.
- Configure as regras de firewall e de proxy
- Configure os recursos do Google Cloud, incluindo um projeto do Google Cloud que você vai usar ao configurar e gerenciar o GKE no VMware e uma conta de serviço com as permissões necessárias para acessar e fazer o download de softwares dos componentes do GKE no VMware.
1. configurar seu ambiente
Para a instalação mínima, use um único host físico que execute ESXi.
Verifique se o host tem as seguintes capacidades mínimas de CPU, RAM e armazenamento:
- 8 CPUs físicas a 2,7 Ghz com hiperprocessamento ativado
- 80 gibibytes (GiB) de RAM
- 470 GiB de armazenamento
Verifique se você tem o ESXi versão 7.0u2 ou superior instalado.
Verifique se você está usando o vCenter Server versão 7.0u2 ou superior.
Exemplo de host e repositório de dados
Veja um exemplo de um host ESXi e um armazenamento de dados vSphere que atendem aos requisitos:
Configuração do host ESXi:
- Fabricante: Dell Inc.
- CPUs físicas: 8 CPUs a 2,7 GHz
- Tipo de processador: CPU Intel(R) Xeon(R) Platinum 8168 a 2,70 GHz
- Soquetes de processador: 2
- ESXi versão: 7.0u2 ou mais recente
- Versão do vCenter Server: 7.0u2 ou mais recente
- Hyperthreading: ativado
Configuração do Datastore:
- Tipo: VMFS 6.82
- Tipo de unidade: SSD
- Fornecedor: DELL
- Tipo de unidade: lógica
- Nível RAID: RAID1
2. Configurar objetos do vSphere
Configure os seguintes objetos no ambiente do vSphere:
Anote os nomes do data center, do cluster, do repositório de dados e da rede do vSphere, porque eles serão necessários ao configurar a estação de trabalho do administrador em Criar clusters básicos.
Se você tiver configurado um repositório de dados vSAN, use govc para criar uma pasta no diretório datastore para usar na máquina virtual (VMDK) do GKE no VMware:
govc datastore.mkdir -namespace=true data-disks
3. Planejar seus endereços IP
Como você viu na Visão geral do GKE no VMware, uma instalação do GKE no VMware requer vários endereços IP, incluindo:
- Endereços IP para todos os nós
- Endereços IP virtuais (VIPs) para acessar componentes do plano de controle, como servidores da API Kubernetes e aplicativos em execução nos clusters de usuário
- Intervalos de CIDR para comunicação entre pods e serviços
Por isso, uma parte importante da configuração do GKE no VMware é planejar seus endereços IP, incluindo garantir que você não crie conflitos de endereçamento. Talvez seja necessário que seu administrador da rede ajude você a encontrar valores adequados para configuração, mesmo para essa instalação simples. No restante desta seção, fornecemos exemplos ilustrativos de valores que funcionam para essa instalação em uma rede hipotética. Os valores são diferentes.
Os clusters nesta instalação mínima usam o balanceador de carga MetalLB. Esse balanceador de carga é executado nos nós do cluster. Portanto, nenhuma outra VM é necessária para o balanceamento de carga.
Com o GKE no VMware, é possível escolher entre endereços IP estáticos para os nós do cluster ou usar um servidor DHCP. Nesta instalação simples, você usará endereços IP estáticos.
Exemplo de VLAN
Para essa pequena instalação, recomendamos que você coloque a estação de trabalho do administrador, os nós do cluster de administrador e os nós do cluster de usuário na mesma VLAN na rede do vSphere. Por exemplo, suponha que todos os endereços IP no intervalo 172.16.20.0/24 sejam roteados para uma VLAN específica. Além disso, suponha que seu administrador de rede diga que você pode usar 172.16.20.49 - 172.16.20.69 para VMs e endereços IP virtuais (VIPs).
O diagrama a seguir ilustra uma VLAN que tem uma estação de trabalho de administrador, um cluster de administrador e um cluster de usuário. Observe que os VIPs não são mostrados associados a nenhum nó específico em um cluster. Isso ocorre porque o balanceador de carga do MetalLB pode escolher qual nó anuncia o VIP de um Serviço individual. Por exemplo, no cluster de usuário, um nó de trabalho poderia anunciar 172.16.20.64 e um nó de trabalho diferente poderia anunciar 172.16.20.65.
Exemplo de endereço IP: estação de trabalho do administrador
Para a estação de trabalho do administrador, este exemplo usa o primeiro endereço no intervalo fornecido a você pelo administrador da rede: 172.16.20.49.
Exemplo de endereços IP: nós de cluster
A tabela a seguir mostra um exemplo de como endereços IP podem ser usados para nós de cluster. A tabela mostra endereços para dois nós extras: admin-vm-6 e user-vm-5. Os nós extras são necessários durante upgrades, atualizações e reparos automáticos de clusters. Para mais informações, consulte Gerenciar endereços IP de nós.
| Nome do host da VM | Descrição | Endereço IP |
|---|---|---|
| admin-vm-1 | Nó do plano de controle para o cluster de administrador. | 172.16.20.50 |
| admin-vm-2 | Nó do plano de controle para o cluster de administrador. | 172.16.20.51 |
| admin-vm-3 | Nó do plano de controle para o cluster de administrador. | 172.16.20.52 |
| user-vm-1 | Nó do plano de controle para o cluster de usuário. | 172.16.20.53 |
| user-vm-2 | Nó de trabalho do cluster do usuário | 172.16.20.54 |
| user-vm-3 | Nó de trabalho do cluster do usuário | 172.16.20.55 |
| user-vm-4 | Nó de trabalho do cluster do usuário | 172.16.20.56 |
| user-vm-5 | 172.16.20.57 |
Exemplo de endereços IP: VIPs para o cluster de administrador
A tabela a seguir mostra um exemplo de como especificar um VIP do plano de controle para o cluster de administrador.
| VIP | Descrição | Endereço IP |
|---|---|---|
| VIP para o servidor da API Kubernetes do cluster de administrador | Configurado no balanceador de carga para o cluster de administrador. | 172.16.20.58 |
Exemplo de endereços IP: VIPs para o cluster de usuário
A tabela a seguir mostra um exemplo de como você pode especificar VIPs para o cluster de usuário.
O VIP do servidor da API Kubernetes do cluster de usuário e o VIP de entrada estão na mesma VLAN que os nós de trabalho e os nós do plano de controle.
| VIP | Descrição | Endereço IP |
|---|---|---|
| VIP para o servidor da API Kubernetes do cluster de usuário | Configurado no balanceador de carga para o cluster de administrador. | 172.16.20.59 |
| VIP de entrada | Configurado no balanceador de carga para o cluster de usuário. | 172.16.20.60 |
| VIPs de serviço | 10 endereços para serviços do tipo LoadBalancer.Configurado conforme necessário no balanceador de carga para o cluster de usuário. Esse intervalo inclui o VIP de entrada. Esse é um requisito do balanceador de carga do MetalLB. |
172.16.20.60 - 172.16.20.69 |
Endereços IP para pods e Serviços
Além dos endereços IP dos nós do cluster e do acesso à implantação, você também precisa especificar os intervalos de endereços que podem ser usados dentro de cada cluster para o tráfego no cluster.
Para fazer isso, especifique um intervalo CIDR a ser usado para endereços IP do pod e outro intervalo CIDR a ser usado para os endereços ClusterIP dos serviços do Kubernetes. Eles são especificados como parte da configuração do cluster, como você vai ver na próxima parte deste guia.
Como parte do seu planejamento de IP, decida quais intervalos CIDR você quer usar para pods e Serviços. A menos que você tenha um motivo para fazer o contrário, use os seguintes intervalos padrão:
| Finalidade | Intervalo CIDR padrão |
|---|---|
| Pods de cluster de administrador | 192.168.0.0/16 |
| Pods de cluster de usuário | 192.168.0.0/16 |
| Serviços de cluster de administrador | 10.96.232.0/24 |
| Serviços de cluster de usuário | 10.96.0.0/20 |
Os valores padrão ilustram estes pontos:
O intervalo CIDR do pod pode ser o mesmo para vários clusters.
O intervalo CIDR do serviço de um cluster não pode se sobrepor ao intervalo CIDR do serviço de qualquer outro cluster.
Normalmente, você precisa de mais pods do que Serviços. Por isso, para um determinado cluster, você provavelmente quer um intervalo CIDR de pod maior que o intervalo CIDR de Serviço. Por exemplo, o intervalo padrão do pod para um cluster de usuário tem 2^(32-16) = 2^16 endereços, mas o intervalo padrão do serviço para um cluster de usuário tem apenas 2^(32-20) = 2^12 endereços.
Evitar sobreposição
Em alguns casos, pode ser necessário usar intervalos CIDR não padrão para evitar a sobreposição com endereços IP que podem ser acessados na rede. Os intervalos de serviços e pods não podem se sobrepor a nenhum endereço fora do cluster que você queira acessar de dentro dele.
Por exemplo, suponha que seu intervalo de serviço seja 10.96.232.0/24 e seu intervalo de pod seja 192.168.0.0/16. Qualquer tráfego enviado de um pod para um endereço em qualquer um desses intervalos será tratado como no cluster e não alcançará nenhum destino fora dele.
Os intervalos de serviços e pods não podem se sobrepor a:
Endereços IP de nós em qualquer cluster
Endereços IP usados por máquinas de balanceador de carga
VIPs usados por nós do plano de controle e balanceadores de carga
Endereço IP dos servidores vCenter, DNS e NTP
Recomendamos que você use os intervalos de endereços IP internos definidos pela RFC 1918 para seus intervalos de pods e serviços.
Veja um motivo por que recomendamos usar endereços RFC 1918. Suponha que o intervalo de pods ou de serviços contenha endereços IP externos. Qualquer tráfego enviado de um pod para um desses endereços externos será tratado como tráfego no cluster e não chegará ao destino externo.
Servidor DNS e gateway padrão
Antes de criar os clusters de administrador e de usuário, é preciso saber os endereços IP de:
Um servidor DNS que possa ser usado pela estação de trabalho do administrador e pelos nós do cluster
Um servidor NTP que pode ser usado pelos nós do cluster
O endereço IP do gateway padrão da sub-rede que tem a estação de trabalho do administrador e os nós do cluster. Por exemplo, suponha que a estação de trabalho de administrador, os nós de cluster de administrador e os nós de cluster de usuário estejam todos na sub-rede 172.16.20.0/24. O endereço do gateway padrão da sub-rede pode ser 172.16.20.1.
4. Configurar seu firewall e proxy
Configure o firewall e o proxy para permitir o tráfego necessário do GKE no VMware seguindo as regras de proxy e firewall. Você precisará dos endereços IP do nó do cluster identificados na seção anterior para realizar essa tarefa. Como os endereços IP dos clusters de usuário e de administrador não são atribuídos a nós específicos, todas as regras de firewall relevantes precisam ser aplicadas a todos os endereços IP de cada cluster.
5. Configurar recursos do Google Cloud
Os projetos do Google Cloud são a base para criar, ativar e usar todos os serviços do Google Cloud, incluindo os usados para instalar e gerenciar o GKE no VMware. Se você não sabe usar os projetos do Google Cloud, veja mais informações em Como criar e gerenciar projetos.
Escolha um projeto atual do Google Cloud ou crie um novo.
Anote o ID do projeto do Google Cloud porque ele será necessário mais tarde.
Configure a Google Cloud CLI
A Google Cloud CLI é uma ferramenta de linha de comando que pode ser usada para trabalhar com seu projeto. Siga as instruções em Como instalar o SDK Google Cloud para garantir que você tenha a versão mais atualizada.
Permissões necessárias
Se você é o proprietário do projeto, por exemplo, o projeto foi criado, já tem todas as permissões necessárias para executar o restante desta instalação simples. Se você não for o proprietário do projeto, você ou o administrador dele vão precisar garantir que sua Conta do Google tenha as permissões necessárias.
Os papéis do IAM a seguir permitem criar uma conta de serviço, atribuir papéis do IAM a ela, ativar APIs e garantir que a ferramenta gkeadm possa criar e gerenciar contas de serviço para você na segunda parte desta configuração:
resourcemanager.projectIamAdminserviceusage.serviceUsageAdminiam.serviceAccountCreatoriam.serviceAccountKeyAdmin
Para detalhes sobre as permissões necessárias para conceder papéis do IAM por conta própria, consulte Como conceder, alterar e revogar acesso a recursos. Se você não tiver essas permissões, outra pessoa na sua organização precisará conceder os papéis para você.
Para conceder os papéis:
Linux e macOS
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountKeyAdmin"
Windows
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountKeyAdmin"
Substitua:
PROJECT_ID: o ID do seu projeto do Google Cloud;ACCOUNT: o endereço de e-mail de identificação da sua Conta do Google.
Configurar contas de serviço
Seu projeto do Google Cloud precisa ter quatro contas de serviço para o GKE no VMware usar. Neste exercício, duas dessas contas de serviço são geradas automaticamente para você. Mas você precisa criar as outras duas contas de serviço manualmente:
- Conta de serviço Connect-register (gerada automaticamente)
- Conta de serviço Logging-monitoring (gerada automaticamente)
- Conta de serviço de geração de registros de auditoria (criar manualmente)
- Conta de serviço de acesso a componentes (criada manualmente)
Conta de serviço do Audit Logging
No projeto do Google Cloud, crie uma conta de serviço que o GKE no VMware possa usar para enviar registros de auditoria do Kubernetes do cluster para os registros de auditoria do Cloud. Isso é chamado de conta de serviço de registro de auditoria.
gcloud iam service-accounts create audit-logging-sa \ --project PROJECT_ID
Crie uma chave JSON para sua conta de serviço de registro de auditoria:
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL
Substitua SERVICE_ACCOUNT_EMAIL pelo endereço de e-mail da conta de serviço de geração de registros de auditoria.
Não é preciso conceder papéis à conta de serviço do registro de auditoria.
Conta de serviço de acesso a componentes
No projeto do Google Cloud, crie uma conta de serviço que o GKE no VMware possa usar para fazer o download do código do componente do cluster em seu nome do Container Registry. Isso é chamado de conta de serviço de acesso a componentes.
gcloud iam service-accounts create component-access-sa \ --display-name "Component Access Service Account" \ --project PROJECT_ID
Substitua PROJECT_ID pelo ID do projeto do Google Cloud.
Criar uma chave JSON para sua conta de serviço de acesso a componentes:
gcloud iam service-accounts keys create component-access-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL
Substitua SERVICE_ACCOUNT_EMAIL pelo endereço de e-mail de identificação exclusivo da sua conta de serviço.
Adicione os seguintes papéis do IAM à conta de serviço de acesso a componentes:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role "roles/serviceusage.serviceUsageViewer"gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role "roles/iam.roleViewer"gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role "roles/iam.serviceAccountViewer"
ative as APIs do Google
Ative as APIs a seguir no seu projeto do Google Cloud. Isso permite usar todos os serviços do Google Cloud necessários para o GKE no VMware no seu projeto.
gcloud services enable --project PROJECT_ID \ anthos.googleapis.com \ anthosgke.googleapis.com \ anthosaudit.googleapis.com \ cloudresourcemanager.googleapis.com \ connectgateway.googleapis.com \ container.googleapis.com \ gkeconnect.googleapis.com \ gkehub.googleapis.com \ gkeonprem.googleapis.com \ serviceusage.googleapis.com \ stackdriver.googleapis.com \ opsconfigmonitoring.googleapis.com \ monitoring.googleapis.com \ logging.googleapis.com \ iam.googleapis.com \ storage.googleapis.comSe esta é a primeira vez que você ativa a API GKE On-Prem (
gkeonprem.googleapis.com) no projeto, é necessário inicializar a API. Para fazer isso, chame um comando da CLI gcloud que exibe as versões disponíveis que podem ser usadas para criar um cluster de usuário:gcloud container vmware clusters query-version-config \ --project=PROJECT_ID \ --location="us-central1"A seguir