Configure uma infraestrutura mínima

Esta é a primeira parte de um guia que explica uma pequena instalação de prova de conceito do Google Distributed Cloud (apenas software) para VMware com um cluster de utilizador único. Esta página destina-se a administradores, arquitetos e operadores que configuram, monitorizam e gerem a infraestrutura técnica. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns de utilizadores do GKE.

Este documento mostra como configurar ambientes vSphere e Google Cloud mínimos para esta instalação e planear os seus endereços IP, enquanto o documento de seguimento Crie clusters básicos mostra como criar uma estação de trabalho de administrador, um cluster de administrador e um cluster de utilizador.

A infraestrutura que configurar através deste guia pode não ser adequada para as suas necessidades de produção e exemplos de utilização reais. Para mais informações sobre instalações de produção, consulte a Vista geral da instalação e os guias.

Antes de começar

Vista geral do procedimento

Seguem-se os principais passos envolvidos nesta configuração:

  1. Configure o seu ambiente. Certifique-se de que cumpre os requisitos de recursos. Disponibilizamos um exemplo de configuração para um anfitrião ESXi e um arquivo de dados do vSphere que cumprem os requisitos desta instalação.
  2. Configure objetos do vSphere. Os componentes do Google Distributed Cloud são executados numa hierarquia de objetos do vSphere.
  3. Planeie os seus endereços IP. O Google Distributed Cloud requer que faculte endereços IP para todos os nós, além de endereços IP virtuais (VIPs) para acesso de administrador e utilizador à sua implementação. Para esta configuração, vai usar endereços IP estáticos para os nós do cluster. Fornecemos exemplos, embora recomendemos que consulte o administrador de rede para ajudar a escolher endereços adequados para a sua própria rede.
  4. Configure as regras de proxy e firewall
  5. Configure Google Cloud recursos, incluindo um Google Cloud projeto que vai usar quando configurar e gerir o Google Distributed Cloud, e uma conta de serviço com as autorizações necessárias para aceder e transferir o software de componentes do Google Distributed Cloud.

1. Configure o seu ambiente

Para esta instalação mínima, pode usar um único anfitrião físico que execute o ESXi.

  1. Certifique-se de que o anfitrião tem a seguinte capacidade mínima de CPU, RAM e armazenamento:

    • 8 CPUs físicas a 2,7 GHz com hyperthreading ativado
    • 80 gibibytes (GiB) de RAM
    • 470 GiB de armazenamento
  2. Certifique-se de que tem a versão 7.0u2 ou superior do ESXi instalada.

  3. Certifique-se de que está a usar a versão 7.0u2 ou superior do vCenter Server.

Exemplo de anfitrião e armazenamento de dados

Segue-se um exemplo de um anfitrião ESXi e um repositório de dados vSphere que cumprem os requisitos:

  • Configuração do anfitrião ESXi:

    • Fabricante: Dell Inc.
    • CPUs físicas: 8 CPUs a 2,7 GHz
    • Tipo de processador: Intel(R) Xeon(R) Platinum 8168 CPU a 2,70 GHz
    • Entradas de processador: 2
    • Versão do ESXi: 7.0u2 ou posterior
    • Versão do vCenter Server: 7.0u2 ou posterior
    • Hyperthreading: ativado
  • Configuração do armazenamento de dados:

    • Tipo: VMFS 6.82
    • Tipo de tração: SSD
    • Fornecedor: DELL
    • Tipo de tração: lógico
    • Nível de RAID: RAID1

2. Configure objetos do vSphere

Configure os seguintes objetos no seu ambiente do vSphere:

Tome nota dos nomes do centro de dados, do cluster, do armazenamento de dados e da rede do vSphere, uma vez que vai precisar destes nomes quando configurar a estação de trabalho do administrador em Criar clusters básicos.

Se configurou um arquivo de dados vSAN, use govc para criar uma pasta no diretório datastore a usar para o disco da máquina virtual (VMDK) do Google Distributed Cloud:

govc datastore.mkdir -namespace=true data-disks

3. Planeie os seus endereços IP

Conforme viu na vista 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 acesso a componentes do plano de controlo, como servidores da API Kubernetes, e a aplicações em execução nos seus clusters de utilizadores
  • Intervalos CIDR para comunicação entre pods e serviços

Por este motivo, uma parte importante da configuração do Google Distributed Cloud é o planeamento dos seus endereços IP, incluindo certificar-se de que não cria conflitos de endereçamento. Pode precisar da ajuda do administrador de rede para encontrar valores adequados para configurar, mesmo para esta instalação simples. No resto desta secção, apresentamos exemplos ilustrativos de valores que funcionam para esta instalação numa rede hipotética. Os seus valores serão diferentes.

  • Os clusters nesta instalação mínima usam o balanceador de carga MetalLB incluído. Este balanceador de carga é executado nos nós do cluster, pelo que não são necessárias VMs adicionais para o balanceamento de carga.

  • O Google Distributed Cloud permite-lhe escolher entre fornecer endereços IP estáticos para os nós do cluster ou usar um servidor DHCP. Nesta instalação simples, vai usar endereços IP estáticos.

VLAN de exemplo

Para esta pequena instalação, recomendamos que coloque a estação de trabalho do administrador, os nós do cluster de administrador e os nós do cluster de utilizador na mesma VLAN na sua rede do vSphere. Por exemplo, suponhamos que todos os endereços IP no intervalo 172.16.20.0/24 são encaminhados para uma VLAN específica. Suponha também que o administrador de rede afirma que pode usar 172.16.20.49 a 172.16.20.69 para VMs e endereços IP virtuais (VIPs).

O diagrama seguinte ilustra uma VLAN que tem uma estação de trabalho de administrador, um cluster de administrador e um cluster de utilizador. Tenha em atenção que os IPs virtuais não são apresentados associados a nenhum nó específico num cluster. Isto deve-se ao facto de o balanceador de carga do MetalLB poder escolher que nó anuncia o VIP para um serviço individual. Por exemplo, no cluster de utilizadores, 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 para um cluster de administrador e um cluster de utilizador.
Endereços IP para um cluster de administrador e um cluster de utilizador (clique para aumentar)

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 que lhe foi dado pelo administrador de rede: 172.16.20.49.

Exemplos de endereços IP: nós de cluster

A tabela seguinte dá um exemplo de como os endereços IP podem ser usados para nós de cluster. Tenha em atenção que a tabela mostra endereços para dois nós adicionais: admin-vm-6 e user-vm-5. Os nós adicionais são necessários durante as atualizações, as atualizações e a reparação automática do cluster. Para mais informações, consulte o artigo Faça a gestão dos endereços IP dos nós.

Nome do anfitrião da VM Descrição Endereço IP
admin-vm-1 Nó do plano de controlo para o cluster de administrador. 172.16.20.50
admin-vm-2 Nó do plano de controlo para o cluster de administrador. 172.16.20.51
admin-vm-3 Nó do plano de controlo para o cluster de administrador. 172.16.20.52
user-vm-1 Nó do plano de controlo para o cluster de utilizadores. 172.16.20.53
user-vm-2 Nó trabalhador do cluster de utilizadores 172.16.20.54
user-vm-3 Nó trabalhador do cluster de utilizadores 172.16.20.55
user-vm-4 Nó trabalhador do cluster de utilizadores 172.16.20.56
user-vm-5 172.16.20.57

Exemplos de endereços IP: VIP para o cluster de administrador

A tabela seguinte dá um exemplo de como pode especificar um VIP do plano de controlo para o cluster de administrador.

VIP Descrição Endereço IP
VIP para o servidor da API Kubernetes do cluster de administrador Configurado no equilibrador de carga para o cluster de administrador. 172.16.20.58

Exemplos de endereços IP: VIPs para o cluster de utilizadores

A tabela seguinte dá um exemplo de como pode especificar VIPs para o seu cluster de utilizadores.

Tenha em atenção que o VIP para o servidor da API Kubernetes do cluster de utilizadores e o VIP de entrada estão ambos na mesma VLAN que os nós de trabalho e os nós do plano de controlo.

VIP Descrição Endereço IP
VIP para o servidor da API Kubernetes do cluster de utilizador Configurado no equilibrador de carga para o cluster de administrador. 172.16.20.59
Ingress VIP Configurado no equilibrador de carga para o cluster de utilizadores. 172.16.20.60
VIPs de serviço Dez moradas para serviços do tipo LoadBalancer.
Configurado conforme necessário no equilibrador de carga para o cluster de utilizadores.
Repare que este 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 para aceder à sua implementação, também tem de especificar os intervalos de endereços que podem ser usados em cada cluster para tráfego no cluster.

Para tal, especifica um intervalo CIDR a usar para os endereços IP dos pods e outro intervalo CIDR a usar para os endereços ClusterIP dos serviços Kubernetes. Estes são especificados como parte da configuração do cluster, como verá na parte seguinte deste guia.

Como parte do planeamento de IP, decida que intervalos CIDR quer usar para pods e serviços. A menos que tenha um motivo para fazer o contrário, use os seguintes intervalos predefinidos:

FinalidadeIntervalo CIDR predefinido
Pods do cluster de administrador192.168.0.0/16
Pods do cluster de utilizadores192.168.0.0/16
Serviços de cluster de administrador10.96.232.0/24
Serviços de cluster de utilizadores10.96.0.0/20

Os valores predefinidos ilustram estes pontos:

  • O intervalo CIDR de pods pode ser o mesmo para vários clusters.

  • O intervalo CIDR de serviço de um cluster não pode sobrepor-se ao intervalo CIDR de serviço de qualquer outro cluster.

  • Normalmente, precisa de mais pods do que serviços. Por isso, para um determinado cluster, é provável que queira um intervalo CIDR de pods maior do que o intervalo CIDR de serviços. Por exemplo, o intervalo de pods predefinido para um cluster de utilizadores tem 2^(32-16) = 2^16 endereços, mas o intervalo de serviços predefinido para um cluster de utilizadores tem apenas 2^(32-20) = 2^12 endereços.

Evite a sobreposição

Em alguns casos, pode ter de usar intervalos CIDR não predefinidos para evitar a sobreposição com endereços IP acessíveis na sua rede. Os intervalos de serviços e de pods não podem sobrepor-se a nenhum endereço fora do cluster que quer alcançar a partir do interior do cluster.

Por exemplo, suponhamos que o seu intervalo de serviços é 10.96.232.0/24 e o seu intervalo de pods é 192.168.0.0/16. Qualquer tráfego enviado de um pod para um endereço num desses intervalos é tratado como no cluster e não chega a nenhum destino fora do cluster.

Em particular, os intervalos de serviços e pods não podem sobrepor-se a:

  • Endereços IP de nós em qualquer cluster

  • Endereços IP usados por máquinas do balanceador de carga

  • VIPs usados por nós do plano de controlo e balanceadores de carga

  • Endereço IP dos servidores vCenter, servidores DNS e servidores NTP

Recomendamos que use os intervalos de endereços IP internos definidos pela RFC 1918 para os intervalos de pods e serviços.

Segue-se um motivo para a recomendação de usar endereços RFC 1918. Suponhamos que o intervalo do seu pod ou serviço contém endereços IP externos. Todo o tráfego enviado de um pod para um desses endereços externos é tratado como tráfego no cluster e não chega ao destino externo.

Servidor DNS e gateway predefinido

Antes de criar os clusters de administrador e de utilizador, também tem de saber os endereços IP de:

  • Um servidor DNS que pode 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 predefinido para a sub-rede que tem a sua estação de trabalho de administrador e nós do cluster. Por exemplo, suponhamos que a sua estação de trabalho de administrador, os nós do cluster de administrador e os nós do cluster de utilizador estão todos na sub-rede 172.16.20.0/24. O endereço do gateway predefinido para a sub-rede pode ser 172.16.20.1.

4. Configure a firewall e o proxy

Configure a firewall e o proxy para permitir o tráfego necessário do Google Distributed Cloud, seguindo as regras de proxy e firewall. Precisa dos endereços IP dos nós do cluster que identificou na secção anterior para realizar esta tarefa. Tenha em atenção que, como os endereços IP dos clusters de utilizadores e administradores não são atribuídos a nós específicos, tem de se certificar de que todas as regras de firewall relevantes se aplicam a todos os endereços IP de cada cluster.

5. Configure Google Cloud recursos

OsGoogle Cloud projetos formam a base para criar, ativar e usar todos os Google Cloud serviços, incluindo os usados para instalar e gerir o Google Distributed Cloud. Se não estiver familiarizado com o trabalho com Google Cloud projetos, pode encontrar muitas mais informações no artigo Criar e gerir projetos.

  1. Escolha um Google Cloud projeto existente ou crie um novo.

  2. Tome nota do Google Cloud ID do projeto, porque é necessário mais tarde.

Configure a CLI Google Cloud

A CLI Google Cloud é uma ferramenta de linha de comandos que pode usar para trabalhar com o seu projeto. Siga as instruções em Instalar o SDK do Google Cloud para garantir que tem a versão mais atualizada.

Autorizações necessárias

Se for o proprietário do projeto (por exemplo, se tiver criado o projeto), já tem todas as autorizações necessárias para realizar o resto desta instalação simples. Se não for o proprietário do projeto, tem de garantir, juntamente com o administrador do projeto, que a sua Conta Google tem as autorizações necessárias.

As seguintes funções do IAM permitem-lhe criar uma conta de serviço, atribuir-lhe funções do IAM, ativar APIs e garantir que a ferramenta gkeadm pode criar e gerir contas de serviço por si na segunda parte desta configuração:

  • resourcemanager.projectIamAdmin
  • serviceusage.serviceUsageAdmin
  • iam.serviceAccountCreator
  • iam.serviceAccountKeyAdmin

Para ver detalhes das autorizações necessárias para conceder funções de IAM, consulte o artigo Conceder, alterar e revogar o acesso a recursos. Se não tiver estas autorizações, outra pessoa na sua organização tem de lhe conceder as funções.

Para conceder as funções:

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 o seguinte:

  • PROJECT_ID: o ID do seu Google Cloud projeto
  • ACCOUNT: o endereço de email de identificação da sua Conta Google

Configure contas de serviço

O seu projeto do Google Cloud tem de ter quatro contas de serviço para o Google Distributed Cloud usar. Neste exercício, duas dessas contas de serviço são geradas automaticamente. No entanto, tem de criar manualmente as outras duas contas de serviço:

  • Conta de serviço de registo de ligação (gerada automaticamente)
  • Conta de serviço de registo e monitorização (gerada automaticamente)
  • Conta de serviço de registo de auditoria (criar manualmente)
  • Conta de serviço de acesso a componentes (criar manualmente)

Conta de serviço de registo de auditoria

  1. No seu Google Cloud projeto, crie uma conta de serviço que o Google Distributed Cloud possa usar para enviar registos de auditoria do Kubernetes do seu cluster para os registos de auditoria da nuvem. Isto chama-se conta de serviço de registo 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 seu projetoGoogle Cloud .

  2. Obtenha o endereço de email da conta de serviço de registo de auditoria recém-criada:

    gcloud iam service-accounts list \
        --project PROJECT_ID
    
  3. Crie uma chave JSON para a sua conta de serviço de registo 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 email da sua conta de serviço de registo de auditoria.

    Não precisa de conceder funções à sua conta de serviço de registo de auditoria.

Conta de serviço de acesso a componentes

  1. No seu Google Cloud projeto, crie uma conta de serviço que o Google Distributed Cloud possa usar para transferir o código do componente do cluster em seu nome a partir do Artifact Registry. Isto chama-se conta de serviço de acesso aos componentes.

    gcloud iam service-accounts create component-access-sa \
        --display-name "Component Access Service Account" \
        --project PROJECT_ID
    

    Substitua PROJECT_ID pelo ID do seu projetoGoogle Cloud .

  2. Obtenha o endereço de email da conta de serviço de acesso aos componentes recém-criada:

    gcloud iam service-accounts list \
        --project PROJECT_ID
    
  3. Crie uma chave JSON para a 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 email da sua conta de serviço de acesso aos componentes.

  4. Adicione as seguintes funções do IAM à sua conta de serviço de acesso aos 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 Google

  1. Ative as seguintes APIs Google no seu Google Cloud projeto. Isto permite-lhe usar todos os serviços necessários pelo Google Distributed Cloud no seu projeto. Google Cloud

    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
  2. Se esta for a primeira vez que ativa a API GKE On-Prem (gkeonprem.googleapis.com) no seu projeto, tem de inicializar a API. Pode fazê-lo chamando um comando da CLI gcloud que apresenta as versões disponíveis que pode usar para criar um cluster de utilizadores:

    gcloud container vmware clusters query-version-config \
        --project=PROJECT_ID \
        --location="us-central1"
    

    O que se segue?

Crie clusters básicos