Planejar a instalação

Version 1.15 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Esta página é a primeira parte de um guia que explica uma pequena instalação de prova de conceito do GDCV para Bare Metal. Este documento mostra como configurar um ambiente de hardware mínimo e planejar seus endereços IP. O complemento Criar clusters básicos mostra como criar 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 instalações de produção, consulte Escolher um modelo de implantação.

Antes de começar

1. Leia Sobre o GKE em Bare Metal.
2. Familiarize-se com alguns conceitos básicos do Google Cloud, incluindo projetos, permissões do IAM e contas de serviço.
3. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

7. Make sure that billing is enabled for your Google Cloud project.

8. Anote o ID do projeto do Google Cloud, porque ele será necessário mais tarde.

Visão geral do procedimento

A configuração mínima da infraestrutura consiste nestas etapas principais:

1. Configure a estação de trabalho do administrador. Configure uma estação de trabalho de administrador do Linux para tarefas de gerenciamento no local. Ela pode ser uma máquina atual ou dedicada capaz de gerenciar vários clusters.

2. Configure as máquinas de nó do cluster. Defina pelo menos três máquinas para os nós: um nó de cluster de administrador, um do plano de controle do cluster do usuário e um de trabalho do cluster do usuário.

3. Planeje sua rede. Planeje os endereços IP para suas máquinas de nó, endereços IP virtuais (VIPs) e intervalos de CIDR de serviço e pod.

4. Revise os recursos necessários do Google Cloud. Para criar clusters, seu projeto do Google Cloud requer APIs específicas do Google e contas de serviço.

1. Configurar a estação de trabalho do administrador

A estação de trabalho do administrador hospeda ferramentas e arquivos de configuração para criar e trabalhar com os clusters.

Requisitos de hardware

A estação de trabalho de administrador requer poder de computação, memória e armazenamento significativos para executar ferramentas e armazenar os recursos associados à criação e ao gerenciamento do cluster.

Verifique se a estação de trabalho do administrador atende aos seguintes requisitos de hardware:

• No mínimo, 2 núcleos de CPU
• Pelo menos 4 GiB de RAM
• Pelo menos 128 GiB de armazenamento

Configurar o sistema operacional e o software

Na estação de trabalho do administrador, instale e configure o seguinte:

• Configurar o Ubuntu

• Instalar a CLI gcloud

• Instalar kubectl

• Instalar bmctl

Configurar o sistema operacional

Para executar bmctl e criar um cluster, a estação de trabalho do administrador tem os mesmos requisitos do sistema operacional (SO) dos nós. Cada máquina precisa executar uma versão compatível do Ubuntu, como o Ubuntu 20.04.

Observação: embora o GKE em Bare Metal seja compatível com vários sistemas operacionais Linux, este exemplo mínimo usa o Ubuntu para simplificar. Todas as etapas ou comportamentos específicos do Ubuntu são destacados nos documentos.

Execute os seguintes comandos para atualizar as configurações de firewall, instalar e configurar o Docker e garantir que cada máquina use a sincronização de tempo:

1. Desative o firewall não complicado e verifique o status dele:

   sudo ufw disable
   sudo ufw status
   

2. Remova qualquer versão anterior do Docker, atualize o gerenciador de pacotes e instale a versão mais recente:

   sudo apt-get remove docker docker-engine docker.io containerd runc
   sudo apt-get update
   sudo apt-get install \
     apt-transport-https \
     ca-certificates \
     curl \
     gnupg-agent \
     software-properties-common \
     docker.io
   

3. Verifique se você está executando a versão 19.03 ou posterior do Docker:

   sudo docker version
   

   As versões do cliente e do servidor devem ser 19.03 ou superiores, conforme mostrado na seguinte amostra de resposta:

   Client:
    Version:           20.10.21
    API version:       1.41
    Go version:        go1.18.1
    ...
   
   Server:
    Engine:
     Version:          20.10.21
     API version:      1.41 (minimum version 1.12)
     Go version:       go1.18.1
     ...
   

4. Crie o grupo docker.

   sudo groupadd docker
   

5. Adicione-se ao grupo do Docker:

   sudo usermod -aG docker $USER
   

6. Execute o seguinte comando para ativar as alterações no grupo:

   newgrp docker
   

7. Execute o seguinte comando para verificar se o relógio do sistema está sincronizado:

   timedatectl
   

   A saída de timedatectl precisa conter o seguinte status:

   System clock synchronized: yes
   

Instale a CLI do Google Cloud

Para instalar a Google Cloud CLI no Ubuntu, siga as instruções neste guia de instalação.

Siga estas etapas na estação de trabalho do administrador para configurar a CLI gcloud:

1. Faça login para definir a propriedade account da CLI gcloud:

   gcloud auth login
   

2. Defina a propriedade project da CLI gcloud:

   gcloud config set project PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

3. Verifique se as propriedades account e project estão definidas corretamente:

   gcloud config list
   

   A saída mostra os valores das propriedades account e project. Exemplo:

   [core]
   account = [e-mail]
   disable_usage_reporting = False
   project = my-project-1234
   Your active configuration is: [default]
   

Instale o kubectl (em inglês)

Para instalar kubectl:

1. Execute o seguinte comando na estação de trabalho do administrador:

   gcloud components install kubectl
   

Instale o bmctl (em inglês)

bmctl é a ferramenta de linha de comando reservada para o GKE em Bare Metal que pode ser usada para criação e gerenciamento de clusters.

Para instalar o bmctl na estação de trabalho do administrador:

1. Crie um diretório baremetal e adicione-o ao caminho. Se você estiver no diretório principal, os comandos serão:

   mkdir baremetal
   export PATH="$HOME/baremetal:$PATH"
   

2. Execute o seguinte comando para fazer o download da versão mais recente do arquivo binário bmctl e torná-lo executável:

   gsutil cp gs://anthos-baremetal-release/bmctl/1.15.11/linux-amd64/bmctl .
   chmod +x ./bmctl
   

3. Verifique se bmctl está instalado e é executável:

   bmctl version
   

   A resposta deverá ser semelhante a esta:

   [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023
   

Conectividade

A estação de trabalho de administrador precisa de acesso ao Google Cloud e a todos os nós do cluster.

Acesso ao Google Cloud

A estação de trabalho de administrador acessa o Google Cloud para fazer o download e instalar ferramentas e imagens, processar solicitações de autorização, criar contas de serviço, gerenciar a geração de registros e monitoramento e muito mais. Não é possível criar clusters sem acesso ao Google Cloud.

Acesso na estação de trabalho do administrador

Para criar e gerenciar clusters na estação de trabalho de administrador, você precisa do seguinte acesso às máquinas de nó:

• Conectividade da camada 3 com todas as máquinas de nó do cluster.
• Acesso ao VIP do plano de controle.
• Acesso root sem senha a todas as máquinas de nó do cluster por SSH. O acesso SSH pode ser direto ou por sudo.

A seção a seguir contém instruções para configurar o SSH na estação de trabalho de administrador e nas máquinas de nó.

2. Configurar as máquinas de nó do cluster

Para a instalação mínima de um único cluster de administrador de alta disponibilidade e de um cluster de usuário de alta disponibilidade, são necessárias três máquinas:

• Uma máquina para um cluster de administrador com um nó do plano de controle.

• Duas máquinas para um cluster de usuário com um nó do plano de controle e um nó de trabalho.

Requisitos de hardware

Cada máquina de nó precisa atender aos seguintes requisitos de hardware:

• No mínimo, 2 núcleos de CPU
• Pelo menos 4 GiB de RAM
• Pelo menos 128 GiB de armazenamento

Configurar o Ubuntu

Configure o Ubuntu em cada nó com as mesmas instruções usadas para a estação de trabalho do administrador.

Configurar o acesso SSH aos nós

A estação de trabalho do administrador precisa de acesso root sem senha a todas as máquinas de nó do cluster por SSH. O acesso SSH pode ser direto ou por sudo.

Estas são as etapas avançadas para configurar o SSH para o GKE em Bare Metal:

1. Instalar e configurar o SSH em todas as máquinas

2. Criar chaves SSH e copiar a chave pública para cada máquina de nó

3. Desativar a autenticação por senha em máquinas de nós

4. Verificar o acesso SSH entre a estação de trabalho de administrador e as máquinas de nó

Instalar e configurar o SSH em todas as máquinas

O GKE em Bare Metal requer comunicação SSH sem senha entre a estação de trabalho do administrador e os nós do cluster. As etapas a seguir precisam ser executadas na estação de trabalho do administrador e em cada máquina de nó.

Para configurar o SSH em máquinas que executam o Ubuntu, faça o seguinte:

1. Se você ainda não tem um servidor SSH em execução, instale um agora:

   sudo apt update
   sudo apt install openssh-server
   sudo systemctl status ssh
   

2. Para ativar a autenticação de senha SSH root, remova a marca de comentário ou adicione as linhas PermitRootLogin e PasswordAuthentication ao arquivo /etc/ssh/sshd_config e defina os valores como yes:

   Observação: PasswordAuthentication está ativado temporariamente para ajudar na configuração do SSH. PasswordAuthentication é desativado nas máquinas de nós em uma seção subsequente.

   # Authentication:
   
   #LoginGraceTime 2m
   PermitRootLogin yes
   #StrictModes yes
   #MaxAuthTries 6
   #MaxSessions 10
   ...
   PasswordAuthentication yes
   

3. Defina uma senha raiz:

   sudo passwd root
   

4. Para aplicar as alterações de configuração do SSH, reinicie o serviço SSH:

   sudo systemctl restart ssh.service
   

5. Reinicie o computador.

6. Verifique se o SSH está funcionando estabelecendo uma conexão SSH de outra máquina.

Criar chaves SSH e copiar a chave pública para cada máquina de nó

Para conexões seguras e sem senha entre a estação de trabalho de administrador e os nós, crie uma chave SSH na estação de trabalho de administrador e compartilhe a chave pública com os nós.

1. Na estação de trabalho do administrador, gere um par de chaves privada/pública. Não defina uma senha longa para as chaves:

   ssh-keygen -t rsa
   

2. Na estação de trabalho do administrador, copie a chave pública gerada para cada uma das máquinas de nó:

   ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP
   

   Substitua:

   • PUBLIC_KEY: o caminho para o arquivo que contém a chave pública SSH. Por padrão, o caminho é /home/USERNAME/.ssh/id_rsa.pub.
   • CLUSTER_NODE_IP: o endereço IP da máquina do nó.

Desativar a autenticação por senha em máquinas de nós

Não é mais necessário ativar a autenticação por senha.

Para cada máquina de nó:

1. Abra /etc/ssh/sshd_config, defina PasswordAuthentication como no e salve o arquivo

2. Reinicie o serviço SSH.

   sudo systemctl restart ssh.service
   

Verificar o acesso SSH entre a estação de trabalho de administrador e as máquinas de nó

Quando o SSH estiver configurado corretamente, você poderá estabelecer uma conexão SSH com a máquina de nó pela estação de trabalho de administrador (como raiz) sem uma senha.

Para verificar se a autenticação de chave pública funciona entre a estação de trabalho de administrador e os nós do cluster:

1. Na estação de trabalho do administrador, execute o seguinte comando para cada máquina de nó:

   ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP
   

   Substitua:

   • PRIVATE_KEY: o caminho para o arquivo que contém a chave particular SSH. Por padrão, o caminho é /home/USERNAME/.ssh/id_rsa.
   • CLUSTER_NODE_IP: o endereço IP da máquina do nó.

3. Planejar sua rede

Ao instalar clusters, é importante planejar seus endereços IP, incluindo a garantia de que você não criará conflitos de endereçamento. Talvez seja necessário que o administrador da rede ajude você a encontrar endereços adequados, mesmo para esta instalação simples. Sem contar os CIDRs de pods e serviços, você precisa de pelo menos 15 endereços IP exclusivos para um cluster de administrador e de usuário no mínimo.

Planeje e especifique endereços IP para os seguintes componentes do cluster:

• Nós de cluster: você precisa de um endereço IP para cada máquina de nó
• Endereços IP virtuais (VIPs): você precisa de VIPs para acesso aos servidores da API Kubernetes, ao proxy de entrada e aos serviços do tipo LoadBalancer
• Pods e serviços: você precisa de intervalos de endereços CIDR para acomodar todos os pods e serviços em execução nos clusters.

O restante desta seção tem exemplos ilustrativos de valores que funcionam para essa instalação em uma rede hipotética. Os valores serão diferentes.

Para esta pequena instalação, coloque a estação de trabalho do administrador, o nó do cluster de administrador e os nós do cluster de usuário no mesmo domínio da camada 2. Por exemplo, suponha que todos os endereços IP no intervalo 172.16.20.0/24 sejam roteados para um domínio de camada 2 específico. Suponha também que o administrador de rede diga que você pode usar 172.16.20.10 - 172.16.20.12 para endereços de máquina do nó e 172.16.0.13 - 172.16.20.24 para VIPs.

Importante: os exemplos de endereços IP usados neste documento atendem aos requisitos do GKE em Bare Metal. No entanto, é preciso usar os endereços IP disponíveis na sua rede. Se você estiver instalando o GKE em Bare Metal em uma rede doméstica, provavelmente vai precisar ajustar os endereços das máquinas de nós e dos VIPs do cluster.

O diagrama a seguir ilustra um domínio da camada 2 que tem uma estação de trabalho de administrador, 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)

Exemplos de endereços IP do nó do cluster

A tabela a seguir mostra um exemplo de como endereços IP podem ser usados para nós de cluster:

Máquina	Descrição	Endereço IP
Nó do plano de controle do cluster de administrador	Máquina física que atua como o nó do plano de controle para o cluster de administrador	172.16.20.10
Nó do plano de controle do cluster do usuário	Máquina física que atua como o nó do plano de controle para o cluster de usuário	172.16.20.11
Nó de trabalho do cluster do usuário	Máquina física que executa cargas de trabalho do usuário	172.16.20.12

Exemplos de endereços IP virtuais (VIPs)

A tabela a seguir mostra um exemplo de como especificar VIPs para seus clusters:

VIP	Descrição	Endereço IP
Endereço VIP do plano de controle do cluster de administrador	Endereço VIP do plano de controle do cluster de administrador (servidor da API Kubernetes do cluster de administrador)	172.16.20.13
Endereço VIP do plano de controle do cluster de usuário	Endereço VIP do plano de controle do cluster de usuário (servidor da API Kubernetes do cluster de usuário)	172.16.20.14
Endereço VIP de entrada	VIP de entrada (incluído no intervalo de pools de endereços do MetalLB)	172.16.20.15
Endereços VIP do serviço	Dez endereços para uso como endereços IP externos para Serviços do tipo LoadBalancer. Os endereços são alocados conforme necessário nos nós do cluster de usuário. Esse intervalo inclui o VIP de entrada. Essa sobreposição de endereços IP é um requisito do MetalLB, o balanceador de carga em pacote padrão.	172.16.20.15 - 172.16.20.24

Endereços IP para pods e Serviços

Além dos endereços IP especificados para nós de cluster e VIPs, você precisa especificar endereços para pods e serviços. Especifique um intervalo CIDR para ser usado nos endereços IP do pod e outro intervalo CIDR para ser usado nos endereços ClusterIP dos Serviços do Kubernetes. Use endereços IP no espaço de endereço privado, conforme descrito na RFC 1918. Esses endereços são especificados como parte da configuração do cluster, conforme ilustrado 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 sugeridos:

Purpose	Intervalo CIDR pré-preenchido
Pods de cluster de administrador	192.168.0.0/16
Serviços de cluster de administrador	10.96.0.0/20
Pods de cluster de usuário	192.168.0.0/16
Serviços de cluster de usuário	10.96.0.0/20

Os intervalos sugeridos ilustram estes pontos:

• O intervalo CIDR do pod pode ser o mesmo para vários clusters no modelo de rede padrão do modo ilha.

• O intervalo CIDR do serviço pode ser o mesmo para vários clusters.

• Normalmente, você precisa de mais pods do que serviços em um cluster, então provavelmente você quer um intervalo de CIDR de pod maior que o intervalo de CIDR de serviço. Por exemplo, o intervalo de pod sugerido para um cluster de usuário tem 2^(32-16) = 2¹⁶ endereços, mas o intervalo de serviço sugerido para um cluster de usuário tem apenas 2^(32-20) = 2¹² endereços.

Evitar sobreposição

Para evitar a sobreposição com endereços IP acessíveis na rede, talvez seja necessário usar intervalos CIDR diferentes das sugestões anteriores. 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 o intervalo de serviço seja 10.96.232.0/24 e o intervalo de pod seja 192.168.0.0/16. O tráfego enviado de um pod para um endereço em qualquer um desses intervalos é tratado como no cluster e não pode alcançar nenhum destino fora do cluster.

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 de servidores DNS ou NTP

4. Revisar os recursos necessários do Google Cloud

Antes de criar clusters, o GKE em Bare Metal exige que um conjunto específico de APIs do Google seja ativado no projeto associado do Google Cloud. Para usar as APIs do Google, o GKE em Bare Metal requer contas de serviço configuradas com papéis específicos do IAM no projeto associado do Google Cloud.

O processo de criação de clusters na próxima parte deste guia, Criar clusters básicos, ativa APIs e cria contas de serviço automaticamente.

Veja as APIs do Google que são ativadas automaticamente:

• anthos.googleapis.com
• anthosaudit.googleapis.com
• anthosgke.googleapis.com
• cloudresourcemanager.googleapis.com
• connectgateway.googleapis.com
• container.googleapis.com
• gkeconnect.googleapis.com
• gkehub.googleapis.com
• gkeonprem.googleapis.com
• iam.googleapis.com
• logging.googleapis.com
• monitoring.googleapis.com
• opsconfigmonitoring.googleapis.com
• serviceusage.googleapis.com
• stackdriver.googleapis.com
• storage.googleapis.com

A tabela a seguir descreve as contas de serviço criadas automaticamente:

Conta de serviço	Purpose	Papéis
anthos-baremetal-gcr	O GDCV para Bare Metal usa essa conta de serviço para fazer o download de imagens de contêiner do Container Registry.	Nenhuma
anthos-baremetal-connect	O Agente do Connect usa essa conta de serviço para manter uma conexão entre seu cluster e o Google Cloud. Isso permite acesso ao cluster e aos recursos de gerenciamento de carga de trabalho, incluindo o console do Google Cloud e o gateway do Connect para interagir com o cluster.	roles/gkehub.connect
anthos-baremetal-register	O agente do Connect usa essa conta de serviço para registrar seus clusters com uma frota.	roles/gkehub.admin
anthos-baremetal-cloud-ops	O Agente do Stackdriver usa essa conta de serviço para exportar registros e métricas de clusters para o Cloud Logging e o Cloud Monitoring.	roles/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor

A seguir

Criar clusters básicos