Configurar a infraestrutura mínima

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

Visão geral do procedimento

Estas são as principais etapas envolvidas na configuração:

  1. 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.
  2. Configurar objetos do vSphere. Os componentes do GKE no VMware são executados em uma hierarquia de objetos do vSphere.
  3. 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.
  4. Configure as regras de firewall e de proxy
  5. 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.

Endereços IP de um cluster de administrador e um cluster de usuário.
Endereços IP de um cluster de administrador e um cluster de usuário (clique para ampliar)

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:

FinalidadeIntervalo CIDR padrão
Pods de cluster de administrador192.168.0.0/16
Pods de cluster de usuário192.168.0.0/16
Serviços de cluster de administrador10.96.232.0/24
Serviços de cluster de usuário10.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:

  1. Escolha um projeto existente para sua instalação ou crie um novo.
  2. 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.

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

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

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

A seguir

Criar clusters básicos