Esta página é a primeira parte de um guia que explica o uso do software Google Distributed Cloud (anteriormente conhecido como Google Distributed Cloud Virtual) para criar uma pequena instalação de prova de conceito de clusters do GKE no seu hardware bare metal. Neste documento, mostramos como configurar um ambiente de hardware mínimo e planejar os endereços IP. A continuação Criar clusters básicos mostra como criar um cluster de administrador e um de usuário.
A infraestrutura configurada usando este guia pode não ser adequada para suas necessidades e casos de uso reais de produção. Para mais informações sobre instalações de produção, consulte Escolher um modelo de implantação.
Antes de começar
- Leia Sobre o Google Distributed Cloud.
- Familiarize-se com alguns conceitos básicos do Google Cloud, incluindo projetos, permissões do IAM e contas de serviço.
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
- 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:
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.
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.
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.
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.
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:
Desative o firewall não complicado e verifique o status dele:
sudo ufw disable sudo ufw status
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
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 ...
Crie o grupo
docker
.sudo groupadd docker
Adicione-se ao grupo do Docker:
sudo usermod -aG docker $USER
Execute o seguinte comando para ativar as alterações no grupo:
newgrp docker
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:
Faça login para definir a propriedade
account
da CLI gcloud:gcloud auth login
Defina a propriedade
project
da CLI gcloud:gcloud config set project PROJECT_ID
Substitua
PROJECT_ID
pelo ID do projeto do Google Cloud.Verifique se as propriedades
account
eproject
estão definidas corretamente:gcloud config list
A saída mostra os valores das propriedades
account
eproject
. Exemplo:[core] account = my-name@google.com disable_usage_reporting = False project = my-project-1234 Your active configuration is: [default]
Instale o kubectl
(em inglês)
Para instalar kubectl
:
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 do Google Distributed Cloud que
pode ser usada para criação e gerenciamento de clusters.
Para instalar o bmctl
na estação de trabalho do administrador:
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"
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.29.100-gke.251/linux-amd64/bmctl . chmod +x ./bmctl
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 SSH sem senha a todas as máquinas de nós do cluster como
root
ou como um usuário com privilégiossudo
sem senha.
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 SSH sem senha a todas as máquinas de nós do
cluster. É possível configurar o SSH como root
ou com um usuário que tenha privilégios
sudo
sem senha.
Estas são as etapas avançadas para configurar o SSH para o Google Distributed Cloud:
Instalar e configurar o SSH em todas as máquinas
Criar chaves SSH e copiar a chave pública para cada máquina de nó
Desativar a autenticação por senha em máquinas de nós
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 Google Distributed Cloud 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:
Se você ainda não tiver um servidor SSH em execução, instale um agora:
sudo apt update sudo apt install openssh-server sudo systemctl status ssh
Para ativar a autenticação de senha SSH
root
, remova a marca de comentário ou adicione as linhasPermitRootLogin
ePasswordAuthentication
ao arquivo/etc/ssh/sshd_config
e defina os valores comoyes
:# Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 ... PasswordAuthentication yes
Defina uma senha raiz:
sudo passwd root
Para aplicar as alterações de configuração do SSH, reinicie o serviço SSH:
sudo systemctl restart ssh.service
Reinicie o computador.
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.
Na estação de trabalho do administrador, gere um par de chaves privada e pública. Não defina uma senha longa para as chaves:
ssh-keygen -t rsa
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ó:
Abra
/etc/ssh/sshd_config
, definaPasswordAuthentication
comono
e salve o arquivoReinicie 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:
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.
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:
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) = 216 endereços, mas o intervalo de serviço sugerido para um cluster de usuário tem apenas 2(32-20) = 212 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 Google Distributed Cloud exige que um conjunto específico de APIs do Google esteja ativado no projeto associado do Google Cloud. Para usar as APIs do Google, o Google Distributed Cloud exige 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 Google Distributed Cloud 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 a recursos de gerenciamento de carga de trabalho, incluindo o console do Google Cloud e o gateway de conexão, para interagir com seu 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 |