Esta página é a primeira parte de um guia que explica a utilização do Google Distributed Cloud (apenas software) para hardware físico (anteriormente conhecido como Google Distributed Cloud Virtual, anteriormente conhecido como clusters do Anthos em hardware físico) para criar uma pequena instalação de prova de conceito de clusters do GKE no seu hardware físico. Este documento mostra como configurar um ambiente de hardware mínimo e planear os seus endereços IP. O seguimento Crie clusters básicos mostra como criar um cluster de administrador e um cluster de utilizador.
Esta página destina-se a administradores, arquitetos e operadores que configuram, monitorizam e gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns de utilizador do GKE.
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 o artigo Escolha um modelo de implementação.
Antes de começar
- Leia o artigo Acerca do Google Distributed Cloud.
- Familiarize-se com alguns Google Cloud conceitos básicos, incluindo projetos, autorizações da 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.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator
(
roles/resourcemanager.projectCreator
), which contains theresourcemanager.projects.create
permission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator
(
roles/resourcemanager.projectCreator
), which contains theresourcemanager.projects.create
permission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
- Tome nota do Google Cloud ID do projeto, porque é necessário mais tarde.
Configure a sua estação de trabalho de administrador. Configure uma estação de trabalho de administrador Linux para tarefas de gestão no local. Pode ser uma máquina existente ou dedicada, que pode gerir vários clusters.
Configure as máquinas de nós do cluster. Configure, pelo menos, três máquinas para os nós: um nó do cluster de administrador, um nó do plano de controlo do cluster de utilizador e um nó de trabalho do cluster de utilizador.
Planeie a sua rede de contactos. Planeie os endereços IP para as suas máquinas de nós, os endereços IP virtuais (VIPs) e os intervalos CIDR de serviços e pods.
Reveja os recursos Google Cloud necessários. Para criar clusters, o seu Google Cloud projeto requer APIs Google e contas de serviço específicas.
- CPU com um mínimo de 2 núcleos
- Pelo menos 4 GiB de RAM
- Pelo menos, 128 GiB de armazenamento
Configure o Ubuntu
Instale a CLI gcloud
Instale
kubectl
Instale
bmctl
Desative a firewall não complicada (UFW) e verifique o respetivo estado:
sudo ufw disable sudo ufw status
Remova qualquer versão anterior do Docker, atualize o gestor de pacotes e instale a versão mais recente do Docker:
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 está a executar 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 superior, conforme mostrado na seguinte resposta de exemplo:
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 de
docker
.sudo groupadd docker
Adicione-se ao grupo Docker:
sudo usermod -aG docker $USER
Execute o seguinte comando para ativar as alterações ao grupo:
newgrp docker
Execute o seguinte comando para verificar se o relógio do sistema está sincronizado:
timedatectl
O resultado de
timedatectl
deve conter o seguinte estado:System clock synchronized: yes
Inicie sessão 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 seu projetoGoogle Cloud .Verifique se as propriedades
account
eproject
estão definidas corretamente:gcloud config list
O resultado mostra os valores das propriedades
account
eproject
. Por exemplo:[core] account = my-name@google.com disable_usage_reporting = False project = my-project-1234 Your active configuration is: [default]
Execute o seguinte comando na estação de trabalho de administração:
gcloud components install kubectl
Crie um diretório
baremetal
e adicione-o ao seu caminho. Se estiver no diretório inicial, os comandos são:mkdir baremetal export PATH="$HOME/baremetal:$PATH"
Execute o seguinte comando para transferir a versão mais recente do ficheiro binário
bmctl
e torná-lo executável:gcloud storage cp gs://anthos-baremetal-release/bmctl/1.33.100-gke.89/linux-amd64/bmctl . chmod +x ./bmctl
Verifique se o
bmctl
está instalado e é executável:bmctl version
A resposta deve ter um aspeto semelhante ao seguinte:
[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
- Conetividade da camada 3 a todas as máquinas de nós do cluster.
- Acesso ao VIP do plano de controlo.
- Acesso SSH sem palavra-passe a todas as máquinas de nós do cluster como
root
ou como um utilizador com privilégiossudo
sem palavra-passe. Uma máquina para um cluster de administrador com um nó do plano de controlo.
Duas máquinas para um cluster de utilizadores com um nó do painel de controlo e um nó de trabalho.
- CPU com um mínimo de 2 núcleos
- Pelo menos 4 GiB de RAM
- Pelo menos, 128 GiB de armazenamento
Instale e configure o SSH em todas as máquinas
Crie chaves SSH e copie a chave pública para cada máquina de nó
Desative a autenticação por palavra-passe em máquinas de nós
Valide o acesso SSH entre a estação de trabalho do administrador e os computadores dos nós
Se 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
Ative a autenticação de palavras-passe SSH descomentando ou adicionando as linhas
PermitRootLogin
ePasswordAuthentication
no ficheiro/etc/ssh/sshd_config
e definindo os valores comoyes
:root
# Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 ... PasswordAuthentication yes
Defina uma palavra-passe de 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 a máquina.
Verifique se o SSH está a funcionar estabelecendo uma ligação SSH a partir de outro computador.
Na estação de trabalho de administração, gere um par de chaves pública e privada. Não defina uma frase de acesso para as chaves:
ssh-keygen -t rsa
Na estação de trabalho de administração, copie a chave pública gerada para cada uma das máquinas de nós:
ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP
Substitua o seguinte:
PUBLIC_KEY
: o caminho para o ficheiro que contém a chave pública de SSH. Por predefinição, o caminho é/home/USERNAME/.ssh/id_rsa.pub
CLUSTER_NODE_IP
: o endereço IP da máquina do nó
Abra
/etc/ssh/sshd_config
e definaPasswordAuthentication
comono
e guarde o ficheiro.Reinicie o serviço SSH.
sudo systemctl restart ssh.service
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 o seguinte:
PRIVATE_KEY
: o caminho para o ficheiro que contém a chave privada de SSH. Por predefinição, o caminho é/home/USERNAME/.ssh/id_rsa
CLUSTER_NODE_IP
: o endereço IP da máquina do nó
- Nós do cluster: precisa de um endereço IP para cada máquina de nó
- Endereços IP virtuais (VIPs): precisa de VIPs para aceder aos servidores da API Kubernetes, ao proxy de entrada e aos serviços do tipo LoadBalancer
- Pods e serviços: precisa de intervalos de endereços CIDR para acomodar todos os pods e serviços em execução nos seus clusters
O intervalo CIDR do pod pode ser o mesmo para vários clusters no modelo de rede predefinido, o modo isolado.
O intervalo CIDR do serviço pode ser o mesmo para vários clusters.
Normalmente, precisa de mais pods do que serviços num cluster, por isso, é provável que queira um intervalo CIDR de pods maior do que o intervalo CIDR de serviços. Por exemplo, o intervalo de pods sugerido para um cluster de utilizadores tem 2(32-16) = 216 endereços, mas o intervalo de serviços sugerido para um cluster de utilizadores tem apenas 2(32-20) = 212 endereços.
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 DNS ou dos servidores NTP
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
Vista geral do procedimento
A configuração mínima da infraestrutura consiste nestes passos principais:
1. Configure a sua estação de trabalho de administrador
A estação de trabalho de administração aloja ferramentas e ficheiros de configuração para criar e trabalhar com os seus clusters.
Requisitos de hardware
A estação de trabalho do administrador requer uma capacidade de computação, memória e armazenamento significativas para executar ferramentas e armazenar os recursos associados à criação e gestão de clusters.
Certifique-se de que a estação de trabalho do administrador cumpre os seguintes requisitos de hardware:
Requisitos do sistema operativo
Para executar o bmctl
e criar um cluster, a estação de trabalho do administrador tem os mesmos requisitos do sistema operativo (SO) que os nós. Cada máquina tem de executar
uma versão suportada do Ubuntu.
Configure o sistema operativo e o software
Na estação de trabalho do administrador, instala e configura o seguinte:
Configure o sistema operativo
Execute os seguintes comandos para atualizar as definições da firewall, instalar e configurar o Docker e garantir que cada máquina usa a sincronização de tempo:
Instale a CLI Google Cloud
Para instalar a Google Cloud CLI no Ubuntu, siga as instruções neste guia de instalação.
Execute os seguintes passos na estação de trabalho do administrador para configurar a CLI gcloud:
Instale a app kubectl
Para instalar o kubectl
:
Instale a app bmctl
bmctl
é a ferramenta de linha de comandos proprietária do Google Distributed Cloud que pode usar para a criação e a gestão de clusters.
Para instalar o bmctl
na sua estação de trabalho de administrador:
Conetividade
A estação de trabalho do administrador precisa de acesso a Google Cloud e a todos os nós do cluster.
Acesso a Google Cloud
A estação de trabalho do administrador acede Google Cloud para transferir e instalar ferramentas e imagens, processar pedidos de autorização, criar contas de serviço, gerir o registo e a monitorização, entre outras ações. Não pode criar clusters sem acesso a Google Cloud.
Aceda a partir da estação de trabalho do administrador
Para criar e gerir clusters a partir da sua estação de trabalho de administração, precisa do seguinte acesso às máquinas de nós:
A secção seguinte contém instruções para configurar o SSH na estação de trabalho do administrador e nas máquinas dos nós.
2. Configure as máquinas de nós do cluster
Para a instalação mínima de um único cluster de administrador de não alta disponibilidade e um único cluster de utilizador de não alta disponibilidade, precisa de três máquinas:
Requisitos de hardware
Cada máquina de nó tem de cumprir os seguintes requisitos de hardware:
Requisitos do sistema operativo
Cada máquina de nó tem de executar uma versão suportada do Ubuntu.
Configure o Ubuntu
Configure o Ubuntu em cada nó com as mesmas instruções que foram usadas para a estação de trabalho de administração.
Configure o acesso SSH aos nós
A estação de trabalho do administrador precisa de acesso SSH sem palavra-passe a todas as máquinas de nós do cluster. Pode configurar o SSH como root
ou com um utilizador que tenha privilégios
sudo
sem palavra-passe.
Seguem-se os passos gerais para configurar o SSH para o Google Distributed Cloud:
Instale e configure o SSH em todas as máquinas
O Google Distributed Cloud requer comunicação SSH sem palavra-passe entre a estação de trabalho do administrador e os nós do cluster. Tem de seguir os passos abaixo na estação de trabalho do administrador e em cada máquina de nó.
Para configurar o SSH em máquinas com o Ubuntu:
Crie chaves SSH e copie a chave pública para cada máquina de nó
Para ligações seguras sem palavra-passe entre a estação de trabalho do administrador e os nós, crie uma chave SSH na estação de trabalho do administrador e partilhe a chave pública com os nós.
Desative a autenticação por palavra-passe em máquinas de nós
Neste momento, já não precisa de ter a autenticação por palavra-passe ativada.
Para cada máquina de nó:
Valide o acesso SSH entre a estação de trabalho de administração e os computadores dos nós
Quando o SSH está configurado corretamente, pode estabelecer uma ligação SSH à máquina do nó a partir da estação de trabalho do administrador (como raiz) sem uma palavra-passe.
Para verificar se a autenticação de chave pública funciona entre a estação de trabalho de administração e os nós do cluster:
3. Planeie a sua rede
Ao instalar clusters, é importante planear os 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 endereços adequados, mesmo para esta instalação simples. Sem contar com os CIDRs de pods e serviços, precisa de, pelo menos, 15 endereços IP únicos para uma instalação mínima de um cluster de administrador e um cluster de utilizador.
Planeie e especifique os endereços IP para os seguintes componentes do cluster:
O resto desta secção tem exemplos ilustrativos de valores que funcionam para esta instalação numa rede hipotética. Os seus 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 utilizador no mesmo domínio da camada 2. Por exemplo, suponhamos que todos os endereços IP no intervalo 172.16.20.0/24
são encaminhados para um domínio de camada 2 específico. Suponhamos também que o administrador de rede diz que pode usar
172.16.20.10
- 172.16.20.12
para endereços de máquinas de nós e 172.16.0.13
-
172.16.20.24
para VIPs.
O diagrama seguinte ilustra um domínio da camada 2 que tem uma estação de trabalho de administração, um cluster de administração e um cluster de utilizadores:
Exemplo de endereços IP de nós de cluster
A tabela seguinte dá um exemplo de como os endereços IP podem ser usados para nós de cluster:
Máquina | Descrição | Endereço IP |
---|---|---|
Nó do plano de controlo do cluster de administrador | Máquina física que funciona como o nó do plano de controlo para o cluster de administração | 172.16.20.10 |
Nó do plano de controlo do cluster de utilizadores | Máquina física que funciona como o nó do plano de controlo para o cluster de utilizadores | 172.16.20.11 |
Nó trabalhador do cluster de utilizadores | Máquina física que executa cargas de trabalho do utilizador | 172.16.20.12 |
Exemplos de endereços IP virtuais (VIPs)
A tabela seguinte apresenta um exemplo de como pode especificar VIPs para os seus clusters:
VIP | Descrição | Endereço IP |
---|---|---|
Endereço VIP do plano de controlo do cluster de administrador | Endereço VIP do plano de controlo do cluster de administrador (servidor da API Kubernetes do cluster de administrador) | 172.16.20.13 |
Endereço VIP do plano de controlo do cluster de utilizadores | Endereço VIP do plano de controlo do cluster de utilizadores (servidor da API Kubernetes do cluster de utilizadores) | 172.16.20.14 |
Endereço VIP de entrada | VIP de entrada (incluído no intervalo do conjunto de endereços do MetalLB) | 172.16.20.15 |
Endereços VIP de serviço | Dez endereços para utilização como endereços IP externos para serviços do tipo
LoadBalancer . Os endereços são atribuídos conforme necessário nos nós do cluster de utilizadores.
Este intervalo inclui o VIP de entrada. Esta sobreposição de endereços IP é um requisito para o MetalLB, o equilibrador de carga incluído predefinido. |
172.16.20.15 - 172.16.20.24 |
Endereços IP para pods e serviços
Além dos endereços IP que especificou para nós de cluster e IPs virtuais,
tem de especificar endereços para pods e serviços. Especifica um intervalo de CIDR a usar para endereços IP de pods e outro intervalo de CIDR a usar para os endereços ClusterIP
de serviços Kubernetes. Use endereços IP no espaço de endereço privado, conforme descrito na RFC 1918.
Estas moradas são especificadas como parte da configuração do cluster, conforme ilustrado
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 sugeridos:
Finalidade | Intervalo CIDR pré-preenchido |
---|---|
Pods do cluster de administrador | 192.168.0.0/16 |
Serviços de cluster de administrador | 10.96.0.0/20 |
Pods do cluster de utilizadores | 192.168.0.0/16 |
Serviços de cluster de utilizadores | 10.96.0.0/20 |
Os intervalos sugeridos ilustram estes pontos:
Evite a sobreposição
Para evitar a sobreposição com endereços IP acessíveis na sua rede, pode ter de usar intervalos CIDR diferentes das sugestões anteriores. Os intervalos de serviços e de pods não podem sobrepor-se a nenhum endereço fora do cluster ao qual quer aceder 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
. O tráfego enviado de um pod para um endereço num desses intervalos é tratado como no cluster e não pode alcançar nenhum destino fora do cluster.
Em particular, os intervalos de serviços e pods não podem sobrepor-se a:
4. Reveja os Google Cloud recursos necessários
Antes de poder criar clusters, o Google Distributed Cloud requer um conjunto específico de APIs Google ativadas no seu Google Cloud projeto associado. Para usar as APIs Google, o Google Distributed Cloud requer contas de serviço configuradas com funções do IAM específicas no seu projeto Google Cloud associado.
O processo de criação de clusters na parte seguinte deste guia, Crie clusters básicos, ativa as APIs e cria automaticamente contas de serviço para si.
Seguem-se as APIs Google que são ativadas automaticamente:
A tabela seguinte descreve as contas de serviço criadas automaticamente:
Conta de serviço | Finalidade | Funções |
---|---|---|
anthos-baremetal-gcr | O Google Distributed Cloud usa esta conta de serviço para transferir imagens de contentores do Artifact Registry. | Nenhum |
anthos-baremetal-connect | O Connect Agent usa esta conta de serviço para manter uma ligação entre o cluster e o Google Cloud. Isto permite o acesso ao cluster e às funcionalidades de gestão de cargas de trabalho, incluindo a consola e o gateway de ligação para interagir com o seu cluster. Google Cloud | roles/gkehub.connect |
anthos-baremetal-register | O agente Connect usa esta conta de serviço para registar os seus clusters numa frota. | roles/gkehub.admin |
anthos-baremetal-cloud-ops | O agente do Stackdriver usa esta conta de serviço para exportar registos 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 |