Pré-requisitos da estação de trabalho do administrador

A estação de trabalho do administrador hospeda ferramentas de interface de linha de comando (CLI) e arquivos de configuração para provisionar clusters durante a instalação, além de ferramentas de CLI para interagir com clusters provisionados após a instalação.

É possível fazer o download e executar ferramentas, como bmctl e a Google Cloud CLI, na estação de trabalho de administrador para interagir com clusters e recursos do Google Cloud. A estação de trabalho de administrador hospeda arquivos de configuração para provisionar clusters durante a instalação, os upgrades e as atualizações. Após a instalação, a estação de trabalho do administrador hospedará arquivos kubeconfig para que você possa usar kubectl a fim de interagir com clusters provisionados. Você também acessa registros de operações críticas do cluster na estação de trabalho do administrador. Uma única estação de trabalho de administrador pode ser usada para criar e gerenciar muitos clusters.

Verifique se a estação de trabalho de administrador atende aos pré-requisitos nas seções a seguir.

Sistema operacional e software

Para executar bmctl a fim de funcionar como um nó do plano de controle, a estação de trabalho do administrador tem os mesmos requisitos de sistema operacional (SO) que os nós. A estação de trabalho de administrador requer o Docker, mas não para uso como um ambiente de execução de contêiner. Quando os clusters do Anthos em bare metal criam clusters, ele implanta um cluster do Kubernetes no Docker (tipo) na estação de trabalho de administrador. Este cluster de inicialização hospeda os controladores do Kubernetes necessários para criar clusters. A menos que você especifique o contrário, o cluster de inicialização será removido quando a criação do cluster for concluída com êxito. O cluster de inicialização requer que o Docker extraia imagens de contêiner.

A estação de trabalho de administrador precisa atender aos seguintes requisitos antes da instalação de um cluster:

  • O sistema operacional é uma distribuição Linux com suporte.

    Para ver uma lista de sistemas operacionais e versões do Linux suportados, consulte Selecionar seu sistema operacional. Essa página tem links para instruções de configuração, incluindo a configuração do Docker, para cada SO.

  • Docker versão 19.03 ou posterior instalada. No entanto, se o sistema usa o cgroup v2, a instalação do Docker na estação de trabalho do administrador precisa ser a versão 20.10.0 ou mais recente. É possível saber se o sistema usa o cgroup v2 pela presença do arquivo /sys/fs/cgroup/cgroup.controllers. O cgroup v2 é compatível apenas como um recurso de pré-lançamento. Não recomendamos o uso de recursos e funções em fase de pré-lançamento em ambientes de produção.

  • O usuário não raiz é membro do grupo docker. Para ver instruções, acesse Gerenciar o Docker como um usuário não raiz.

  • A Google Cloud CLI instalada.

    Use as ferramentas kubectl e bmctl para criar e gerenciar clusters. Para instalar essas ferramentas, você precisa das ferramentas gcloud e gsutil. As ferramentas de linha de comando gcloud, gsutil e kubectl são componentes da CLI gcloud. Para instruções de instalação, incluindo instruções para instalação de componentes, consulte Instalar a CLI gcloud.

  • kubectl instalado. Use a CLI gcloud para instalar kubectl com o seguinte comando:

    gcloud components install kubectl
    
  • bmctl está instalado para a versão do cluster que você está criando ou operando.

    A instalação consiste no uso de gsutil para fazer o download de pacotes de imagens ou binários de bmctl. Para instruções, consulte Downloads de clusters do Anthos em bare metal.

Requisitos de recursos 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.

Por padrão, as operações de upgrade e criação de clusters usam um cluster de inicialização. Quando um cluster de inicialização é usado, há um aumento significativo no uso de CPU e memória. Se você pretende usar a estação de trabalho de administrador como um nó do plano de controle, use pelo menos a quantidade mais alta e recomendada de CPUs e RAM para evitar que as atividades da estação de trabalho de administrador interrompam as funções do plano de controle do cluster.

Dependendo do tamanho do banco de dados etcd e do número de nós do plano de controle, as operações de backup e restauração de cluster consomem RAM significativa. A estimativa aproximada da RAM necessária para backups é de 3 a 5 GiB por nó do plano de controle. Falha no processo de backup, pois não há memória suficiente. Planeje seus requisitos de RAM de acordo.

A tabela a seguir mostra os requisitos mínimos e recomendados de hardware para a estação de trabalho de administrador:

Recurso Minimum Recomendações
CPUs / vCPUs* 2 núcleos 4 núcleos
RAM Ubuntu: 4 GiB
CentOS/RHEL: 6 GiB
Ubuntu: 8 GiB
CentOS/RHEL: 12 GiB
Storage 128 GiB 256 GiB

* O GKE em Bare Metal é compatível apenas com CPUs e vCPUs de x86-64 no nível de microarquitetura de CPU v3 (x86-64-v3) ou mais recente.

Requisitos de rede

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.

O acesso ao Google Cloud pode ser direto ou por meio de um servidor proxy. Para informações sobre as diferentes maneiras de se conectar ao Google Cloud, consulte Conectar-se ao Google. Para informações sobre como configurar um servidor proxy, consulte Instalar atrás de um proxy.

Para informações sobre as consequências do acesso interrompido ao Google Cloud, consulte Impacto da desconexão temporária do Google Cloud.

Acesso aos nós

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 root sem senha a todas as máquinas de nó do cluster por SSH. O acesso SSH pode ser direto ou por sudo.
  • Acesso ao VIP do plano de controle.

Encaminhamento de IP

O encaminhamento de IP precisa estar ativado na estação de trabalho do administrador. Sem o encaminhamento de IP, o cluster de inicialização não pode ser criado, o que bloqueia a criação do cluster. Se o encaminhamento de IP estiver desativado, um erro como o seguinte será exibido ao tentar criar um cluster:

Error message: E0202 14:53:25.979322 225917 console.go:110] Error creating cluster: create kind cluster failed: error creating bootstrap cluster: failed to init node with kubeadm: command "docker exec --privileged bmctl-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1

Verifique a configuração de encaminhamento de IP com o seguinte comando:

cat /proc/sys/net/ipv4/ip_forward

Um valor de 1 indica que o encaminhamento de IP está ativado. Se o encaminhamento de IP estiver desativado (0), use o seguinte comando para ativá-lo:

echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward

Configurar o acesso SSH root aos nós

Para ativar conexões seguras e sem senha entre a estação de trabalho de administrador e as máquinas de nós do cluster, crie uma chave SSH nela e compartilhe a chave pública com os nós do cluster.

  1. Ative a autenticação com senha de SSH root em cada máquina de nó do cluster removendo o comentário ou adicionando as linhas PermitRootLogin e PasswordAuthentication no arquivo /etc/ssh/sshd_config e definindo os valores como yes.

    # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
    
    # This is the sshd server system-wide configuration file.  See
    # sshd_config(5) for more information.
    
    ...
    
    # Authentication:
    
    #LoginGraceTime 2m
    PermitRootLogin yes
    #StrictModes yes
    #MaxAuthTries 6
    #MaxSessions 10
    
    ...
    
    PasswordAuthentication yes
    

    Inicialmente, você precisa da autenticação de senha SSH ativada nas máquinas de nós do cluster remoto para compartilhar chaves da estação de trabalho de administrador.

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

    sudo systemctl restart ssh.service
    
  3. Gerar um par de chaves privada e pública na estação de trabalho do administrador. Não defina uma senha longa para as chaves. Gere as chaves com o seguinte comando:

    ssh-keygen -t rsa
    

    Também é possível usar o acesso de usuário sudo às máquinas de nó do cluster para configurar o SSH. No entanto, para conexões de usuários não raiz sem senha, é necessário atualizar o arquivo de configuração do cluster com o campo spec.nodeAccess.loginUser. Por padrão, esse campo é comentado. Especifique o nome de usuário não raiz com loginUser durante a criação do cluster ou a qualquer momento depois disso. Veja mais informações em loginUser.

  4. Adicione a chave pública gerada às máquinas de nós do cluster.

    ssh-copy-id -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
    

    Substitua:

    • PATH_TO_IDENTITY_FILE: o caminho para o arquivo que contém a chave pública SSH. Por padrão, o caminho para o arquivo de identidade que contém a chave pública é /home/USERNAME/.ssh/id_rsa.pub.
    • CLUSTER_NODE_IP: o endereço IP da máquina de nó a que você está adicionando a chave pública SSH.
  5. Desative a autenticação de senha SSH nas máquinas do nó do cluster definindo PasswordAuthentication como no no arquivo sshd_config e reiniciando o serviço SSH.

  6. Use o seguinte comando na estação de trabalho de administrador para verificar se a autenticação da chave pública funciona entre a estação de trabalho e as máquinas de nó.

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

    Quando o SSH estiver configurado corretamente, será possível fazer login na máquina de nós pela estação de trabalho de administrador (como root) sem precisar inserir uma senha.

A seguir