Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Configurar a infraestrutura mínima

Esta é a primeira parte de um guia que explica uma pequena instalação de prova de conceito do Google Distributed Cloud (somente software) para VMware com um único cluster de usuário. Esta página é destinada a administradores, arquitetos e operadores que configuram, monitoram e gerenciam a infraestrutura de tecnologia. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.

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 usando este 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 o Visão geral do Google Distributed Cloud (somente software) para VMware, que inclui uma visão geral 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 Google Distributed Cloud são executados em uma hierarquia de objetos do vSphere.
Planejar seus endereços IP O Google Distributed Cloud requer que você forneça endereços IP para todos os nós, além dos endereços IP virtuais (VIPs) para acesso de administrador e usuário à sua 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ê usará ao configurar e gerenciar o Google Distributed Cloud e uma conta de serviço com as permissões necessárias para acessar e fazer o download do software do componente do Google Distributed Cloud.

1. Configure 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
- Versão do 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

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ê configurou um repositório de dados vSAN, use govc para criar uma pasta no diretório datastore e usar no disco de máquina virtual (VMDK) do Google Distributed Cloud:

govc datastore.mkdir -namespace=true data-disks

3. Planejar seus endereços IP

Como você viu na Visão geral do Google Distributed Cloud, uma instalação do Google Distributed Cloud 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 Google Distributed Cloud é planejar seus endereços IP, incluindo garantir que não haja conflitos de endereço. 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 Google Distributed Cloud, é possível escolher entre fornecer 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. Suponha também que o administrador da rede diga que é possível 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. Os VIPs não são exibidos associados a nenhum nó específico de 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.64, e um nó de trabalho diferente pode anunciar 172.16.20.65.

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 os endereços de 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 dá 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. Este é um requisito para o 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 aprender 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 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ê utilize os intervalos de endereços IP internos definidos pelo RFC 1918 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 alcançará o 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 Google Distributed Cloud, 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, inclusive aqueles usados para instalar e gerenciar o Google Distributed Cloud. Se você não sabe usar os projetos do Google Cloud, veja mais informações em Como criar e gerenciar projetos.

Escolha um dos projetos 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 do projeto 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

Configurar contas de serviço

Seu projeto do Google Cloud precisa ter quatro contas de serviço para o Google Distributed Cloud utilizar. Neste exercício, duas dessas contas de serviço são geradas automaticamente para você. Mas você precisa criar os outros dois serviços contas manualmente:

Conta de serviço connect-register (gerada automaticamente)
Conta de serviço logging-monitoring (gerada automaticamente)
Conta de serviço de registro de auditoria (criar manualmente)
Conta de serviço de acesso a componentes (criar manualmente)

Conta de serviço do Audit Logging

No projeto do Google Cloud, crie uma conta de serviço que o Google Distributed Cloud pode usar para enviar registros de auditoria do Kubernetes do seu cluster aos Registros de auditoria do Cloud. Essa é a sua conta de serviço de registro de auditoria.
```
gcloud iam service-accounts create audit-logging-sa \
    --display-name "Audit Logging Service Account" \
    --project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do projeto do Google Cloud.
Consiga o endereço de e-mail da conta de serviço de registro de auditoria recém-criada:
```
gcloud iam service-accounts list \
    --project PROJECT_ID
```
Crie uma chave JSON para sua conta de serviço de geração de registro de auditoria:
```
gcloud iam service-accounts keys create audit-logging-key.json \
    --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING
```
Substitua SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING pelo endereço de e-mail da conta de serviço de geração de registro de auditoria.

Não é necessário conceder papéis à conta de serviço de registro de auditoria.

Conta de serviço de acesso a componentes

No projeto do Google Cloud, crie uma conta de serviço que o Google Distributed Cloud pode usar para fazer o download do código do componente do cluster em seu nome pelo Container Registry. 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.
Encontre o endereço de e-mail da conta de serviço de acesso a componentes recém-criada:
```
gcloud iam service-accounts list \
    --project PROJECT_ID
```
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_COMPONENT_ACCESS
```
Substitua SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS pelo endereço de e-mail da conta de serviço de acesso a componentes.

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_COMPONENT_ACCESS" \
    --role "roles/serviceusage.serviceUsageViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.roleViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --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 pelo Google Distributed Cloud 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 \
    kubernetesmetadata.googleapis.com \
    serviceusage.googleapis.com \
    stackdriver.googleapis.com \
    opsconfigmonitoring.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com \
    iam.googleapis.com \
    storage.googleapis.com

Se esta for a primeira vez que você ativa a API GKE On-Prem (gkeonprem.googleapis.com) no seu projeto, será 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

Criar clusters básicos