Planeie uma instalação básica no seu hardware

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

  1. Leia o artigo Acerca do Google Distributed Cloud.
  2. Familiarize-se com alguns Google Cloud conceitos básicos, incluindo projetos, autorizações da 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.

    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 the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify 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.

    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 the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  7. Verify that billing is enabled for your Google Cloud project.

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

    9. 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. 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.

    2. 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.

    3. 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.

    4. 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.

    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:

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

    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 Ubuntu

    • Instale a CLI gcloud

    • Instale kubectl

    • Instale bmctl

    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:

    1. Desative a firewall não complicada (UFW) e verifique o respetivo estado:

      sudo ufw disable
sudo ufw status

    2. 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

    3. 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
  ...

    4. Crie o grupo de docker.

      sudo groupadd docker

    5. Adicione-se ao grupo Docker:

      sudo usermod -aG docker $USER

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

      newgrp docker

    7. 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

    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:

    1. Inicie sessão 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 seu projetoGoogle Cloud .

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

      gcloud config list

      O resultado mostra os valores das propriedades account e project. Por exemplo:

      [core]
account = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

    Instale a app kubectl

    Para instalar o kubectl:

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

      gcloud components install 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:

    1. 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"

    2. 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

    3. 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

    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:

    • 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.

    Requisitos de hardware

    Cada máquina de nó tem de cumprir os seguintes requisitos de hardware:

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

    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:

    1. Instale e configure o SSH em todas as máquinas

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

    3. Desative a autenticação por palavra-passe em máquinas de nós

    4. Valide o acesso SSH entre a estação de trabalho do administrador e os computadores dos nós

    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:

    1. 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

    2. Ative a autenticação de palavras-passe SSH descomentando ou adicionando as linhas PermitRootLogin e PasswordAuthentication no ficheiro /etc/ssh/sshd_config e definindo os valores como yes:root

      # Authentication:

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

    3. Defina uma palavra-passe de 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 a máquina.

    6. Verifique se o SSH está a funcionar estabelecendo uma ligação SSH a partir de outro computador.

    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.

    1. 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

    2. 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ó
    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ó:

    1. Abra /etc/ssh/sshd_config e defina PasswordAuthentication como no e guarde o ficheiro.

    2. Reinicie o serviço SSH.

      sudo systemctl restart ssh.service
    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:

    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 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ó

    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:

    • 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 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:

    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ç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:

    • 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.

    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:

    • 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

    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:

    • 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 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

    O que se segue?

    Crie clusters básicos