Neste documento, mostramos como configurar ambientes mínimos do vSphere e do Google Cloud para uma pequena instalação de prova de conceito de clusters do Anthos no VMware (GKE On-Prem).
A instalação inclui uma estação de trabalho de administrador, um cluster de administrador e um cluster de usuário.
Antes de começar
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.
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 do ESXi: 6.7U3
- Versão do servidor do vCenter: 6.7U3
- 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
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
Depois, ao criar clusters básicos, você especificará endereços IP estáticos para os nós do cluster.
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 o upgrade, a atualização e o reparo automático do cluster. 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 |
| VIP de complementos do cluster de administrador | Configurado no balanceador de carga para o cluster de administrador | 172.16.20.60 |
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.
Observe que o VIP do servidor da API Kubernetes do cluster de usuário é
configurado no balanceador de carga do cluster de administrador. Isso ocorre porque o
servidor da API Kubernetes para um cluster de usuário é executado em um nó no cluster de administrador.
Observe que, nos arquivos de configuração do cluster, o campo em que você especifica, o VIP de um servidor da API Kubernetes é chamado de controlPlaneVIP:
| 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
Antes de criar um cluster, é preciso especificar um
intervalo de
CIDR a ser usado para endereços IP do pod e outro intervalo CIDR a ser usado para
os endereços ClusterIP de Serviços do Kubernetes.
Decida quais intervalos CIDR você quer usar para pods e serviços. A menos que você tenha uma razão para fazer o contrário, é possível usar 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
Talvez seja necessário usar intervalos CIDR não padrão para evitar a sobreposição com endereços IP acessíveis 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
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 de acordo com as Regras de proxy e firewall.
Configurar recursos do Google Cloud
Escolha um dos projetos do Google Cloud ou crie um novo. Anote o ID do projeto do Google Cloud.
No projeto do Google Cloud, crie uma conta de serviço para acessar clusters do Anthos nos componentes do VMware. Isso é chamado de conta de serviço de acesso ao componente:
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 da conta de serviço de acesso a componentes.
Conceda papéis do IAM à sua 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.
gcloud services enable --project PROJECT_ID \
anthos.googleapis.com \
anthosgke.googleapis.com \
anthosaudit.googleapis.com \
cloudresourcemanager.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