DEV Community: Silvio Silva

Configurando um Cluster Kubernetes em Alta Disponibilidade (5/5)

Silvio Silva — Thu, 11 Jun 2020 20:02:38 +0000

Continuando o post anterior

Adicionando os `workers` ao Cluster

Agora que terminamos o Control Plane, podemos adicionar os workers e o processo é bem parecido com o que fizemos para os masters.

Você precisa mudar para a janela 2-workers no TMUX e para isso pode usar o comando C-b 2 ou o modo mouse para clicar no nome da janela.

Assim como nos masters, a janela 2-workers terá três painéis cada um com o comando ./conn.sh pronto para executar.

Vá em frente e pressione ENTER para executar o comando e conectar nos três workers.

Para realizar o join dos workers, você precisará usar somente os dois primeiros tokens (--token e --discovery-token-ca-cert-hash) obtidos anteriormente para compor o comando abaixo:

NODE_NAME=$(hostname --short) && \
sudo kubeadm join lb:6443 \
  --node-name "${NODE_NAME}" \
  --token wx6o8y.mdmkxmj9gfeiq1fe \
  --discovery-token-ca-cert-hash sha256:65446ecd54074326caff65fdbbac91118dd591593930eae0842f5ea2a72e2bdf \
  --v 1

Join dos workers iniciando:

Concluído com sucesso:

Agora você pode retornar à janela master-1 e observar o status do Cluster.

No próximo post, mostrarei algumas operações no Cluster usando Deployment, Rollout, Services (com ClusterIP e NodePort) e HAProxy Ingress Controller.

Até mais!

Configurando um Cluster Kubernetes em Alta Disponibilidade (4/5)

Silvio Silva — Thu, 11 Jun 2020 20:02:31 +0000

Continuando o post anterior

Adicionando os outros `masters` ao Cluster

Agora que o master-1 está pronto, podemos adicionar o master-2 e o master-3 ao Control Plane usando o comando kubeadm join com o parâmetro --control-plane.

Para montar o comando de join, precisaremos dos valores dos seguintes tokens gerados durante a inicialização do master-1:

token
discovery-token-ca-cert-hash
certificate-key

Execute o comando abaixo para obter os valores dos tokens a partir do arquivo de log gerado durante a inicialização do master-1:

KUBEADM_LOG_FILE="${HOME}/kubeadm-init.log" && \
grep "\-\-certificate-key" "${KUBEADM_LOG_FILE}" --before 2 | grep \
  --only-matching \
  --extended-regexp "\-\-.*" | sed 's/\-\-control-plane //; s/^/  /'

A saída do comando anterior deve se parecer com isso:

Você deve copiar as três últimas linhas como as que listei abaixo:

  --token wx6o8y.mdmkxmj9gfeiq1fe \
  --discovery-token-ca-cert-hash sha256:65446ecd54074326caff65fdbbac91118dd591593930eae0842f5ea2a72e2bdf \
  --certificate-key cfcf9ea9ee8adafd9210858fa8f344596888d1041ef96cce6125b4e960cd3e41

Monte o comando de join adicionando as 3 linhas copiadas anteriormente como no exemplo abaixo:

NODE_NAME=$(hostname --short) && \
LOCAL_IP_ADDRESS=$(grep ${NODE_NAME} /etc/hosts | head -1 | awk '{ print $1 }') && \
echo "" && \
echo "NODE_NAME..................: ${NODE_NAME}" && \
echo "LOCAL_IP_ADDRESS...........: ${LOCAL_IP_ADDRESS}" && \
sudo kubeadm join lb:6443 \
  --v 3 \
  --control-plane \
  --node-name "${NODE_NAME}" \
  --apiserver-advertise-address "${LOCAL_IP_ADDRESS}" \
  --token wx6o8y.mdmkxmj9gfeiq1fe \
  --discovery-token-ca-cert-hash sha256:65446ecd54074326caff65fdbbac91118dd591593930eae0842f5ea2a72e2bdf \
  --certificate-key cfcf9ea9ee8adafd9210858fa8f344596888d1041ef96cce6125b4e960cd3e41

Executando o comando no `master-2`

Você deve mudar para o painel do master-2 e pode fazer isso usando C-b + seta-para-baixo + seta-para-direita ou ativar o modo mouse com C-b m e simplesmente clicar no painel.

Tanto faz em qual master (master-2 ou master-3) você executará o comando de join primeiro e inclusive pode executar no master-3 enquanto ainda estiver executando no master-2.

Novos masters adicionados e prontos:

Nota sobre `etcd`

Durante o processo que deve levar menos de 1 minuto, você pode notar uma mensagem com a informação de que o etcd leader mudou.

Isso acontece porque nesta configuração o etcd cluster é criado nos mesmos nodes do Control Plane, isto é, usando os masters (configuração chamada de stacked).

O cluster etcd precisa de no mínimo 3 integrantes para que possa haver a "eleição" do líder.

Como novos integrantes desse cluster estão sendo incluídos é esperado que essa "eleição" ocorra.

Mais detalhes sobre a configuração do etcd em modo stacked podem ser encontradas aqui.

Próximo: Adicionando os workers ao Cluster

Configurando um Cluster Kubernetes em Alta Disponibilidade (3/5)

Silvio Silva — Thu, 11 Jun 2020 20:02:24 +0000

Continuando o post anterior

Instalando o `Control Plane` no primeiro `Master`

Ao mudar para a janela 1-masters o comando ./conn.sh deve estar pronto para ser executado. Faça isso pressionando ENTER.

Configure o auto completion para o kubectl

cat <<EOF | tee --append ~/.bashrc

source <(kubectl completion bash)
alias k=kubectl
complete -F __start_kubectl k
EOF
source ~/.bashrc

Além de configurar o completion, o comando anterior também criou um alias que permite usar apenas k ao invés de kubectl.

Atenção: deste ponto em diante, você deve realizar a configuração apenas no primeiro `master`

Para isso, você precisa desativar a sincronização de janelas no TMUX.

A configuração que usei consiste na combinação C-b y. Caso queira usar a mesma combinação de teclas, sugiro criar o arquivo ${HOME}/.tmux.conf exatamente como criei aqui.

Você também pode pressionar C-b (CTRL+b) e digitar o comando abaixo (incluindo os dois pontos no início da linha) para desativar a sincronização dos painéis:

:set-window-option synchronize-panes off

Tenha certeza de que os painéis não estão mais sincronizados (digite algo no terminal ou pressione ENTER algumas vezes para ter certeza):

Configurando a versão do Kubernetes

Neste exemplo você pode manter a versão 1.18 mas este processo também foi testado com sucesso na 1.17.

KUBERNETES_DESIRED_VERSION='1.18' && \
KUBERNETES_VERSION="$(sudo apt-cache madison kubeadm | grep ${KUBERNETES_DESIRED_VERSION} | head -1 | awk '{ print $3 }')" && \
KUBERNETES_BASE_VERSION="${KUBERNETES_VERSION%-*}" && \
LOCAL_IP_ADDRESS=$(grep $(hostname --short) /etc/hosts | awk '{ print $1 }') && \
LOAD_BALANCER_PORT='6443' && \
LOAD_BALANCER_NAME='lb' && \
CONTROL_PLANE_ENDPOINT="${LOAD_BALANCER_NAME}:${LOAD_BALANCER_PORT}" && \
echo "" && \
echo "LOCAL_IP_ADDRESS...........: ${LOCAL_IP_ADDRESS}" && \
echo "CONTROL_PLANE_ENDPOINT.....: ${CONTROL_PLANE_ENDPOINT}" && \
echo "KUBERNETES_BASE_VERSION....: ${KUBERNETES_BASE_VERSION}" && \
echo ""

Três informações serão exibidas:

O endereço IP da máquina (192.168.10.11)
O Control Plane Endpoint (lb:6443 - endereço que será usado por todos os nodes para comunicação com o Control Plane)
A versão mais recente encontrada no repositório

Observe a imagem abaixo:

Inicializando o `Control Plane`

SECONDS=0 && \
KUBEADM_LOG_FILE="${HOME}/kubeadm-init.log" && \
NODE_NAME=$(hostname --short) && \
sudo kubeadm init \
  --v 3 \
  --node-name "${NODE_NAME}" \
  --apiserver-advertise-address "${LOCAL_IP_ADDRESS}" \
  --kubernetes-version "${KUBERNETES_BASE_VERSION}" \
  --control-plane-endpoint "${CONTROL_PLANE_ENDPOINT}" \
  --upload-certs | tee "${KUBEADM_LOG_FILE}" && \
printf '%d hour %d minute %d seconds\n' $((${SECONDS}/3600)) $((${SECONDS}%3600/60)) $((${SECONDS}%60))

Esse processo não deve levar mais que 1 minuto pois já havíamos efetuado o preloading das imagens usadas por ele.

Ao término da execução você deve visualizar as seguintes informações no terminal:

Você deve configurar o acesso do `kubectl` ao cluster recém criado

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Verificando o Status do Cluster

Neste momento, o Control Plane está ativo porém, o único nó do cluster é o master-1 e ele está como NotReady.

Isso acontece porque ainda não instalamos o plugin de CNI (Container Network Interface) para habilitar a POD Network que é a rede que permite a comunicação entre as PODs no Cluster.

Para entender melhor, vamos deixar executando um comando que vai exibir os nós e alguns objetos que já foram criados no namespace kube-system usando o comando abaixo:

watch -n 3 'kubectl get nodes,pods,services -o wide -n kube-system'

Observe o status do master-1:

Perceba também que as duas PODs do coredns estão com o status Pending e continuarão assim até que seja instalado um plugin CNI.

Como esse ambiente destina-se ao aprendizado de Kubernetes e temos uma limitação considerável de memória, usaremos o Plugin Weave.

Você pode encontrar uma lista de plugins e suas instruções de instalação aqui.

Antes de executar o comando para instalar o plugin Weave, criarei um novo painel no TMUX para executar os comandos e manter o monitoramento do passo anterior na tela.

Optei por fazer isso para que você possa perceber quando:

O master-1 mudar de NotReady para Ready
As novas PODs para o agente Weave forem criadas, e
As PODs do coredns mudarem para Running.

Para criar um novo painel no TMUX (considerando que você está usando a mesma configuração que eu no arquivo ${HOME}/.tmux.conf), use o comando C-b ".

O painel do master-1 será então dividido em dois:

Você pode ajustar os tamanhos dos painéis usando o mouse.

Para habilitar isso, pode usar o comando C-b m (esse comando ativa ou desativa o modo mouse).

Veja como reduzi o tamanho dos painéis inferiores:

No novo painel, precisamos conectar ao master-1 usando ssh. Para isso usaremos a função nativa do Vagrant:

vagrant ssh master-1

Nova conexão ao master-1 realizada:

Agora execute o comando para instalar o plugin Weave Net para a Pod Network.

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Após executar o comando anterior você verá um log de alguns objetos criados e no painel superior poderá acompanhar a atualização das PODs e do status do master-1.

Após alguns segundos, verifique que as atualizações mencionadas anteriormente aconteceram:

Próximo: Adicionando os outros masters ao Cluster

Configurando um Cluster Kubernetes em Alta Disponibilidade (2/5)

Silvio Silva — Thu, 11 Jun 2020 20:02:14 +0000

Continuando o post anterior.

Preparando as Máquinas Virtuais

Neste ponto, optei por usar o TMUX para executar os comandos um a um nas máquinas pois acho que faz parte do processo de perceber o que está sendo feito nelas.

É perfeitamente possível e recomendável automatizar esse tipo de processo usando ferramentas como Terraform ou Ansible mas lembre-se que o objetivo aqui é ter uma melhor visão do todo.

Usando o `TMUX` para acessar várias máquinas ao mesmo tempo

Para ajudar na criação de uma janela para cada máquina, sugiro que você baixe e configure este script em um diretório no seu path.

Copie o script ktx em sua máquina em um diretório que esteja incluído na variável de ambiente PATH.

A partir do diretório kubernetes/install/kubeadm/vagrant/, execute o script para abrir o TMUX e criar várias janelas divididas em painés, um painel para cada máquina virtual.

ktx

O TMUX iniciará uma sessão chamada "k8s" e criará 4 janelas:

0-bash
1-masters
2-workers
3-all (janela ativa)

Essas janelas estarão sincronizadas, isto é, o que for digitado em uma será repetido nas demais permitindo executar os próximos comandos em paralelo nas seis máquinas (masters e workers).

Pressione ENTER para conectar nas 6 máquinas virtuais.

Em alguns segundos a sua tela deve estar parecida com a imagem abaixo.

Pressione CTRL+l (L minúsculo) para limpar os terminais para que você possa ter uma visualização melhor.

Teste a Conectividade das máquinas com o `Load Balancer` (`lb`) na porta `6443`

nc -d lb 6443 && echo "OK" || echo "FAIL"

A sua tela deve se parecer com a da imagem abaixo exibindo um "OK" como resultado do comando.

Pressione CTRL+l (L minúsculo).

Verifique se a rota para `10.96.0.0` foi configurada

route -n | grep --quiet "10.96.0.0" && echo "OK" || echo "FAIL"

A saída do comando deve exibir um "OK". Pressione CTRL+l novamente.

Atualize os pacotes do sistema e adicione a chave GPG do Google

sudo apt-get update | grep --invert-match --extended-regexp "^Hit|^Get" && \

sudo curl --silent "https://packages.cloud.google.com/apt/doc/apt-key.gpg" | sudo apt-key add -

A saída do comando deve se parecer com a imagem abaixo com um "OK" no final.

Pressione CTRL+l novamente (sugiro fazer isso após executar cada comando).

Adicione o Repositório do Kubernetes e atualize a lista de pacotes

cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

sudo apt-get update | grep --invert-match --extended-regexp "^Hit|^Get"

O resultado deve ser:

Defina a versão do Kubernetes que deseja instalar

Algumas variáveis de ambiente serão atualizadas com formatos diferentes da versão mais recente encontrada no repositório adicionado no passo anterior.

KUBERNETES_DESIRED_VERSION='1.18' && \
KUBERNETES_VERSION="$(sudo apt-cache madison kubeadm | grep ${KUBERNETES_DESIRED_VERSION} | head -1 | awk '{ print $3 }')" && \
KUBERNETES_BASE_VERSION="${KUBERNETES_VERSION%-*}" && \
echo "" && \
echo "KUBERNETES_DESIRED_VERSION.: ${KUBERNETES_DESIRED_VERSION}" && \
echo "KUBERNETES_VERSION.........: ${KUBERNETES_VERSION}" && \
echo "KUBERNETES_BASE_VERSION....: ${KUBERNETES_BASE_VERSION}" && \
echo ""

Os três diferentes formatos devem ser exibidos dessa forma:

Instale em todos o kubeadm e o kubelet e somente o kubectl nos masters

SECONDS=0 && \
if grep --quiet "master" <<< $(hostname --short); then
  sudo apt-get install --yes \
    kubeadm="${KUBERNETES_VERSION}" \
    kubelet="${KUBERNETES_VERSION}" \
    kubectl="${KUBERNETES_VERSION}" && \
  sudo apt-mark hold \
    kubelet \
    kubeadm \
    kubectl
else
  sudo apt-get install --yes \
    kubeadm="${KUBERNETES_VERSION}" \
    kubelet="${KUBERNETES_VERSION}" && \
  sudo apt-mark hold \
    kubelet \
    kubeadm
fi && \
printf '%d hour %d minute %d seconds\n' $((${SECONDS}/3600)) $((${SECONDS}%3600/60)) $((${SECONDS}%60))

A instalação deve demorar menos de 1 minuto:

Agora que o utilitário crictl também foi instalado no passo anterior, configure o containerd e teste se consegue listar as imagens (neste momento a lista estará vazia)

sudo crictl config \
  runtime-endpoint unix:///var/run/containerd/containerd.sock \
  image-endpoint   unix:///var/run/containerd/containerd.sock && \
sudo crictl images

A lista de imagens estará vazia mas indica que o Container Runtime (containerd) está funcionando:

Faça o preloading das imagens para acelerar o tempo no momento em que formos configurar o Control Plane nos masters e adicionar os workers no cluster

SECONDS=0 && \
if grep --quiet "master" <<< $(hostname --short); then
  sudo kubeadm config images pull
else
  sudo crictl pull "k8s.gcr.io/kube-proxy:v${KUBERNETES_BASE_VERSION}"
fi
sudo crictl pull docker.io/weaveworks/weave-kube:2.6.4
sudo crictl pull docker.io/weaveworks/weave-npc:2.6.4
printf '%d hour %d minute %d seconds\n' $((${SECONDS}/3600)) $((${SECONDS}%3600/60)) $((${SECONDS}%60))

O processo deve levar um pouco mais de 1 minuto:

Liste as imagens que foram baixadas

sudo cricrtl images

Serão exibidas imagens diferentes nos masters e nos workers:

Deste ponto em diante, as máquinas virtuais serão configuradas separadamente.

Você pode fechar a janela 3-all do TMUX pressionando CTRL+d duas vezes (a primeira para desconectar das máquinas virtuais e a segunda para sair dos 6 terminais abertos na janela "all" o que, consequentemente, fechará essa janela).

Para mudar para a janela 1-masters, você deve pressionar CTRL+b e em seguida pressionar 1 (o número de identificação da janela).

Essa notação no TMUX é representada assim: C-b 1

Você também pode digitar exit e pressionar ENTER e repetir essa ação para fechar os painéis e a janela 3-all.

Na imagem abaixo são mostrados os painéis após digitar a primeira sequência:

Próximo: Instalando o Control Plane no primeiro Master

Configurando um Cluster Kubernetes em Alta Disponibilidade (1/5)

Silvio Silva — Thu, 11 Jun 2020 20:01:59 +0000

Resumo

Seguir os passos aqui descritos me ajudou a entender melhor como um Cluster Kubernetes funciona e a testar aspectos que só fazem sentido em um ambiente com vários servidores.

Fique à vontade para entrar em contato comigo e esclarecer qualquer dúvida, vamos continuar aprendendo juntos!

No entanto, acho importante enfatizar que o Cluster criado aqui tem como finalidade somente o aprendizado e não deve ser usado em ambientes de produção.

Dito isso, mãos à obra!

Seguindo este e os próximos posts você conseguirá:

Provisionar 8 máquinas virtuais:

Caso queira mudar o número de máquinas, a quantidade de memória, a faixa de endereços IP (192.168.10.0/26) assim como o domínio example.com, altere os valores no arquivo Vagrantfile. Os scripts que criam os servidores DNS e o Load Balancer HAProxy buscam essas informações de lá.

Máquina	RAM	IP
dns	512 MB	192.168.10.2
loadbalancer	512 MB	192.168.10.10
master-1	2 GB	192.168.10.11
master-2	2 GB	192.168.10.12
master-3	2 GB	192.168.10.13
worker-1	2 GB	192.168.10.21
worker-2	2 GB	192.168.10.22
worker-3	2 GB	192.168.10.23

*Sites como Spiceworks Subnet Calculator ajudam a entender melhor como funciona o dimensionamento de sub nets (CIDR - Classless Inter-Domain Routing).

Dica: digite 192.168.10.0/26 no campo "First Address or CIDR" e clique em "Generate". No campo "Last Address" você verá o último endereço dessa faixa de IP.

Configurar as Máquinas com os Pré-requisitos

Instalar o Ubuntu 18.04
Desativar o Swap
Configurar parâmetros de DNS
Configurar IP Fixo (usando netplan)
Configurar Rota para o Services (10.96.0.0/8)
Configurar Host Name com FQDN (ex: dns.example.com)
Instalar o containerd 1.2.13 como Container Runtime (CRI)

*Vale ressaltar que é possível usar outros Containers Runtimes como o Docker por exemplo como descrito na documentação aqui.

Porém, o Docker já usa o containerd e o Kubernetes já possui as features de network e storage que o Docker instala também e que não serão utilizadas.

A Ana Calin explica muito bem neste vídeo (em inglês sem legendas) a experiência de migrar de Docker para containerd e as motivações.

Assim, usar o containerd faz com que a nossa instalação seja mais "leve".

O containerd também é usado no projeto Moby (Moby Project) mantido pela Docker e o Moby é usado na Azure, ou seja, em última instância, clusters Kubernetes rodando na Azure (AKS) usam o containerd como Container Runtime.

Preparar os Nodes

Item	Ação	Masters	Workers
kubeadm	Instalar	Sim	Sim
kubelet	Instalar	Sim	Sim
kubectl	Instalar	Sim	Opcional
api-server	Pull	Sim	Não
controller-manager	Pull	Sim	Não
coredns	Pull	Sim	Opcional
etcd	Pull	Sim	Não
scheduler	Pull	Sim	Não
kube-proxy	Pull	Sim	Sim
pause	Pull	Sim	Sim
weave-kube	Pull	Opcional	Opcional
weave-npc	Pull	Opcional	Opcional

Do que você vai precisar

Host Linux (usei um notebook com Ubuntu 20.04 e 16GB de RAM)
Virtualbox 6.1
Vagrant 2.2.9
Git
TMUX (Opcional mas muito útil)

Provisionando as Máquinas Virtuais

Clone e acesse o Repositório

git clone git@github.com:smsilva/kubernetes.git

cd kubernetes/install/kubeadm/vagrant

Verifique o Status das Máquinas Virtuais

vagrant status

Resultado esperado:

Current machine states:

dns                       not created (virtualbox)
loadbalancer              not created (virtualbox)
master-1                  not created (virtualbox)
master-2                  not created (virtualbox)
master-3                  not created (virtualbox)
worker-1                  not created (virtualbox)
worker-2                  not created (virtualbox)
worker-3                  not created (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.

Crie as máquinas virtuais

./provision.sh

O processo de provisionamento deve levar em torno de 10 minutos (dependendo da velocidade da sua conexão) para criar as 8 máquinas virtuais e nesse processo está incluída a configuração dos servidores DNS e HAProxy Load Balancer.

Caso queira mais detalhes sobre o provisionamento, ele é feito através da execução de scripts que estão disponíveis no diretório kubernetes/install/kubeadm/vagrant/ubuntu/.

Cada escript é chamado no momento do provisionamento das máquinas e essas chamadas são coordenadas no arquivo kubernetes/install/kubeadm/vagrant/Vagrantfile.

Verifique novamente o status após a conclusão do processo de provisionamento.

vagrant status

Resultado esperado:

Current machine states:

dns                       running (virtualbox)
loadbalancer              running (virtualbox)
master-1                  running (virtualbox)
master-2                  running (virtualbox)
master-3                  running (virtualbox)
worker-1                  running (virtualbox)
worker-2                  running (virtualbox)
worker-3                  running (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.

Próximo passo: Preparando as Máquinas Virtuais

DEV Community: Silvio Silva

Configurando um Cluster Kubernetes em Alta Disponibilidade (5/5)

Adicionando os workers ao Cluster

Configurando um Cluster Kubernetes em Alta Disponibilidade (4/5)

Adicionando os outros masters ao Cluster

Executando o comando no master-2

Nota sobre etcd

Configurando um Cluster Kubernetes em Alta Disponibilidade (3/5)

Instalando o Control Plane no primeiro Master

Atenção: deste ponto em diante, você deve realizar a configuração apenas no primeiro master

Configurando a versão do Kubernetes

Inicializando o Control Plane

Você deve configurar o acesso do kubectl ao cluster recém criado

Verificando o Status do Cluster

Configurando um Cluster Kubernetes em Alta Disponibilidade (2/5)

Preparando as Máquinas Virtuais

Usando o TMUX para acessar várias máquinas ao mesmo tempo

Teste a Conectividade das máquinas com o Load Balancer (lb) na porta 6443

Verifique se a rota para 10.96.0.0 foi configurada

Configurando um Cluster Kubernetes em Alta Disponibilidade (1/5)

Resumo

Provisionar 8 máquinas virtuais:

Configurar as Máquinas com os Pré-requisitos

Preparar os Nodes

Do que você vai precisar

Provisionando as Máquinas Virtuais

Verifique o Status das Máquinas Virtuais

Crie as máquinas virtuais

Adicionando os `workers` ao Cluster

Adicionando os outros `masters` ao Cluster

Executando o comando no `master-2`

Nota sobre `etcd`

Instalando o `Control Plane` no primeiro `Master`

Atenção: deste ponto em diante, você deve realizar a configuração apenas no primeiro `master`

Inicializando o `Control Plane`

Você deve configurar o acesso do `kubectl` ao cluster recém criado

Usando o `TMUX` para acessar várias máquinas ao mesmo tempo

Teste a Conectividade das máquinas com o `Load Balancer` (`lb`) na porta `6443`

Verifique se a rota para `10.96.0.0` foi configurada