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 neste guia pode não ser adequada para suas necessidades reais de produção e casos de uso. 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.
configure seu ambiente
Requisitos de CPU, RAM e armazenamento
Para a instalação mínima, use um único host físico que execute ESXi.
Estes são os requisitos mínimos de recursos para seu host do ESXi:
- 8 CPUs físicas a 2,7 Ghz com hiperprocessamento ativado
- 80 gibibytes (GiB) de RAM
O requisito de armazenamento mínimo é de 470 GiB.
Exemplo de host e armazenamento 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
- Versão ESXi: 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
Configurar objetos do vSphere
Configure os seguintes objetos no ambiente do vSphere:
Balanceamento de carga
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.
Planejar seus endereços IP
Como vimos em Visão geral do GKE no VMware, uma instalação do GKE no VMware exige uma quantidade suficiente de endereços IP para todos os nós, além de endereços IP virtuais (VIPs) para acesso aos componentes do plano de controle, como Servidores da API Kubernetes e aplicativos em execução nos clusters de usuários. Também é preciso especificar intervalos de endereços CIDR adequados para comunicação entre os pods e os serviços nos clusters. 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.
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.
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. Suponha também que o administrador da rede diga que é possível usar 172.16.20.49 - 172.16.20.72 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 um 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 pode anunciar 172.16.20.63, e um nó de trabalho diferente pode anunciar 172.16.20.64.
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 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 dois nós extras: admin-vm-5 e user-vm-4. 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 complemento do cluster de administrador | 172.16.20.51 |
admin-vm-3 | Nó do complemento do cluster de administrador | 172.16.20.52 |
admin-vm-4 | Nó do plano de controle para o cluster de usuário. Este nó está no cluster de administrador. |
172.16.20.53 |
admin-vm-5 | 172.16.20.54 | |
user-vm-1 | Nó de trabalho do cluster de usuário | 172.16.20.55 |
user-vm-2 | Nó de trabalho do cluster de usuário | 172.16.20.56 |
user-vm-3 | Nó de trabalho do cluster de usuário | 172.16.20.57 |
user-vm-4 | 172.16.20.58 |
Exemplo de endereços IP: VIPs para o cluster de administrador
A tabela a seguir mostra um exemplo de como você pode especificar VIPs 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.59 |
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 do usuário está configurado no balanceador de carga do cluster de administrador. Isso porque, como você aprendeu na visão geral, o servidor da API Kubernetes para um cluster de usuário é executado em um nó do cluster de administrador.
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.61 |
VIP de entrada | Configurado no balanceador de carga para o cluster de usuário | 172.16.20.62 |
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. Observe que esse intervalo inclui o VIP de entrada. Este é um requisito para o balanceador de carga do MetalLB. |
172.16.20.62 - 172.16.20.71 |
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. Isso é especificado como parte da configuração do cluster, como você 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. Portanto, 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 vai ser tratado como no cluster e não vai atingir 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 particulares definidos pela RFC 1918 (em inglês) para os 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.
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.
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.
Para começar a configurar os recursos do Google Cloud, faça o seguinte:
- Escolha um projeto existente para sua instalação ou crie um novo.
- Anote o ID do projeto do Google Cloud.
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 precisa 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.projectIamAdmin
serviceusage.serviceUsageAdmin
iam.serviceAccountCreator
iam.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
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 do Google Cloud para garantir que você tenha a versão mais atualizada.
Configurar a conta de serviço de acesso a componentes
No seu projeto, configure uma conta de serviço que o GKE no VMware pode usar para fazer o download do código do componente do cluster em seu nome do Container Registry. Ela é conhecida como a conta de serviço de acesso ao componente e é a única que você precisa criar manualmente nessa instalação simples.
No projeto do Google Cloud escolhido, crie uma nova conta de serviço da seguinte maneira:
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 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"
Para mais informações sobre a conta de serviço de acesso a componentes e a concessão de papéis do IAM, consulte Contas de serviço e chaves.
Ative as APIs do Google
Ative as APIs a seguir no seu projeto do Google Cloud. Isso permite que você use 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 \ serviceusage.googleapis.com \ stackdriver.googleapis.com \ opsconfigmonitoring.googleapis.com \ monitoring.googleapis.com \ logging.googleapis.com \ iam.googleapis.com \ storage.googleapis.com