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
ebmctl
para criar e gerenciar clusters. Para instalar essas ferramentas, você precisa das ferramentasgcloud
egsutil
. As ferramentas de linha de comandogcloud
,gsutil
ekubectl
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 instalarkubectl
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 debmctl
. 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 porsudo
. - 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.
Ative a autenticação com senha de SSH
root
em cada máquina de nó do cluster removendo o comentário ou adicionando as linhasPermitRootLogin
ePasswordAuthentication
no arquivo/etc/ssh/sshd_config
e definindo os valores comoyes
.# $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.
Para aplicar as alterações de configuração do SSH, reinicie o serviço SSH:
sudo systemctl restart ssh.service
Gere um par de chaves privada/pública na estação de trabalho de 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 campospec.nodeAccess.loginUser
. Por padrão, esse campo é comentado. Especifique o nome de usuário não raiz comloginUser
durante a criação do cluster ou a qualquer momento depois disso. Veja mais informações emloginUser
.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.
Desative a autenticação de senha SSH nas máquinas do nó do cluster definindo
PasswordAuthentication
comono
no arquivosshd_config
e reiniciando o serviço SSH.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.