Fala pessoal, tudo bem?
Hoje vamos para a parte 2, da nossa sequência de postagens Kubernetes do
Zero.
Vamos preparar nosso ambiente que servirá de laboratório para começarmos
a colocar um pouco a mão na massa.
O ambiente
Para o laboratório eu vou utilizar a seguinte infraestrutura:
- Meu notebook rodando Windows
- Hypervisor – VirtualBox
- 3 VMs com Ubuntu server
instalado (versão 26.04)
o
1 VM será o control plane
§ 2 vCPUs
§ 3 GB memória (pela documentação do kubernetes.io , pode ser apenas 2GB)
§ 20 GB de disco
o
2 VMs serão os workers
§ 2 vCPUs
§ 3 GB memória (pela documentação do kubernetes.io , pode ser apenas 2GB)
- Placas em modo Bridge, assim as
VMs receberão um IP da minha rede DHC.
Importante: Não precisamos instalar o
Ubuntu nas 3 VMs. Podemos fazer a instalação de uma VM e depois usar o recurso
de clone do VirtualBox. Assim poupamos um pouco de tempo de instalação. Apenas
a parte da instalação e criação do cluster kubernetes que iremos fazer em cada
uma devido a particularidade.
Preparação
Com as VMs criadas e com sistema operacional instalado, vamos agora fazer a preparação necessária antes de instalar o kubernetes e começar a subir nosso cluster.
Desativar o swap
O kubernetes exige que a memória swap seja desativada. Nas 3 máquinas
vamos executar o seguinte comando:
sudo swapoff -a
É necessário com o vim, deletar a linha do swap no /etc/fstab e assim
não fazer com que suba novamente caso o servidor reinicie.
Obs.: Isso deve ser feito nos workers também.
Carregar módulos do kernel
Para o kubernetes funcionar corretamente, precisamos carregar os módulos overlay e br_netfilter.
- Overley – sistema de arquivos de sobreposição que permitirá unir múltiplos diretórios ou partições em uma única estrutura de arquivos virtual e transparente.
- Br_netfilter – vai permitir que o tráfego de
rede que passar por nossa interface de rede seja processado pelas regras do
firewall Iptables.
No terminal, vamos executar o seguinte bloco de comandos:
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter
Ativar o encaminhamento do IP (Sysctl)
Isso é necessário para que nosso Linux, seja capaz de funcionar como um
roteador, repassando pacotes de dados de uma rede para outra.
No terminal, execute o seguinte bloco de comandos:
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl –system
Instalar o containerd
Como falamos na primeira parte, o kubernetes não executa nativamente,
por assim dizer os containers, então para isso vamos instalar o containerd. Ele
será o nosso container runtime.
Novamente no terminal, execute o seguinte bloco de comandos:
sudo apt update sudo apt install containerd -y sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml
· O kubernetes trabalha com
cgroups.
Cgroups – ou control groups (grupos de
controle), é um recurso do kernel do Linux que permite limitar, contabilizar e
isolar o uso de recursos de hadware, como CPU, memória, I/O de disco e rede
para um determinado grupo de processos.
Para isso funcionar, vamos permitir que o containerd use cgroups. No
arquivo de configuração /etc/containerd/config.toml, o parâmetro
SystemdCgroup será alterado de false para true.
Novamente no
terminal, execute o seguinte bloco de comandos:
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml sudo systemctl restart containerd sudo systemctl enable containerd
Pronto!!!
O que era pré-requisito já foi feito.
Só lembrando ... reforçando ... Esses procedimentos precisam ser feitos
em todos os nós do cluster. No nosso caso, no nó 1 que é o control plane e no
nó 2 e 3 que são os workers.
Agora, vamos adicionar o repositório do kubernetes nos 3 nós e instalar
os pacotes necessários.
Instalando
os pacotes base e os pacotes do kubernetes
Para adicionar o repositório e o certificado, vamos executar o bloco de
comandos abaixo:
sudo apt install apt-transport-https ca-certificates curl gnupg conntrack curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.37/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list
Para instalar o kubeadm, kubelet e kubectl, o bloco de comandos abaixo:
sudo apt update sudo apt install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl
O apt-mark hold serve para que toda vez que alguém executar o
update/upgrade no servidor, não corra o risco de atualizar automaticamente o
kubernetes também. Isso evita muita dor de cabeça para nada quebrar durante uma
atualização não planejada.
Finalmente, vamos subir nosso cluster =]
Subindo nosso primeiro cluster kubernetes
Agora, esse comando será executado apenas no control plane. Que no nosso
laboratório será a VM kub-node1
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=<O IP QUE VAI FALAR COM OS NODES>
Veja que podemos informar o endereçamento de rede que queremos usar na
comunicação interna (rede escolhida 10.244.0.0/16), entre os pods e também
informar o IP do nosso apiserve que nada mais é do que nosso control plane (192.168.0.62)
Então no nosso caso, o comando ficaria assim:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.0.62
Essa parte pode demorar um pouco, mediante a performance do ambiente e
também da conectividade de rede/internet. Uma vez que começa toda a preparação
de validar pré-requisitos e baixar tudo que é necessário para criar a estrutura
do cluster.
Dando tudo certo, ao final teremos uma saída assim:
Veja que temos duas informações importantes aqui.
1° - Para podermos usar o cluster, com um usuário regular, temos alguns comandos a serem executados no control plane.
- Criar o diretório para o arquivo de configuração do kubernetes no nosso diretório home
- Copiar o arquivo de configuração do kubernetes para essa diretório criado no home do nosso usuário
·
Trocar o grupo e o dono para
nosso usuário neste arquivo de configuração
2° - Não menos importante, veja que ele trás o comando que vamos
precisar executar nos nodes workers para eles serem membros do nosso cluster efetivamente.
Lembrando que para dar certo, precisamos executar com o sudo. Então ficaria
assim, de acordo com nosso exemplo:
Sudo kubeadm join 192.168.0.62:6443 --token 48trth.zgu9q9l8t0tve24v --discovery-token-ca-cert-hash sha256:0674a4a83bd943e86fc5a1784cd5d410c7571336bdb417dbb5b264bbb2876aa5
Dando tudo certo (que é o esperado), devemos receber um log semelhante a
esse:
E por fim, para validar, no shell do servidor do control plane:
$ kubectl get nodes
Prontinho!!!
Nosso cluster está pronto, certo?
Só que não rs...
Veja que na coluna STATUS ainda temos tudo como NotReady. Mas por
que será?
Ainda falta instalarmos nosso CNI para kubernetes e assim ele conseguir
proporcionar a comunicação entre os pods. E aí sim, tudo estará funcional em
nosso cluster para ele ficar pronto ... ou no caso, Ready.
Mas o
que é CNI?
CNI (Container Network Interface) é uma especificação e conjunto de
bibliotecas para as configurações de rede em containers. É através dele que temos
a comunicação entre os pods e serviços facilitada.
Existem várias opções de CNI, como Calico, Flannel, Cilium e etc...
Eu gosto do Cilium, então ele será o CNI escolhido para o nosso
ambiente.
Segue o site do projeto https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/ contendo todas informações e documentações.
De acordo com a página de documentação do Cilium, para instalarmos no
nosso ambiente Linux que já contém um cluster, devemos rodar o seguinte bloco
de comandos:
CILIUM_CLI_VERSION=$(curl -s
https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64;
fi
curl -L --fail --remote-name-all
https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
Isso fará o download do binário do Cilium e o moverá para o diretório
/usr/local/bin permitindo que você consiga executa-lo com seu usuário.
Após o download, vamos rodar a instalação com o comando:
$ cilium install
E vamos acompanhar o processo com o comando:
$ cilium status
Ou
$ cilium status -w
(isso fará com que o shell fique informando a cada atualização, sem que seja necessário executar o comando de status várias vezes)
É normal olharmos o status e aparecerem alguns erros durante o processo
de subida. Isso ocorre devido ao cilium estar preparando o ambiente.
Se você tiver mais curiosidade e for impaciente como eu, o cilium faz o
deploy dos seus serviços no namespace do kube-system. Para acompanhar podemos
ver tudo com o comando:
$ kubectl get pods -n kube-system
Na coluna STATUS, iremos ver status de Init, ContainerCreating e dando
tudo certo ... Running.
Assim que tudo estiver running, podemos validar novamente o status dos
nodes:
$ kubectl get nodes
Agora sim. Nosso cluster está funcional no que diz respeito a todos os
nodes estarem como Ready, com comunicação e visíveis para o control plane.
Fazendo
um teste subindo nosso primeiro deployment
Para fazermos um teste bem rápido se está tudo OK, podemos rodar o
seguinte comando:
$ kubectl create deployment nginx --image=nginx --replicas 4
Isso vai instruir a criação de um deploy do serviço do nginx, com 4
réplicas. Ou seja, 4 pods espalhados pelos workers.
O processo de subida dos pods pode demorar um pouco também, algo entre de
1 – 4 minutos. Mas vale levar em consideração que o kubernetes vai precisar
baixar a imagem, fazer as criações e inicializações dos pods, então isso pode
levar esse tempinho ou um pouco a mais.
Tudo como Running!
Que demais!!!
Mas será que o scheduler trabalhou direitinho e balanceou as réplicas
pra gente? Já que ele é o responsável por este trabalho?
Vamos validar e para isso vamos executar o comando:
$ kubectl get pods -o wide
Veja que na coluna NODE, temos a informação de onde cada pod está
rodando.
Como pedimos 4 réplicas, o scheduler colocou 2 réplicas no kub-node3 e 2
no kub-node2.
- Mas por que ele não usou o control plane, se ele é um node também?
Por via de regra, não teremos nossos pods em execução no control plane.
É possível habilitar isso? Sim. Mas não é recomendado.
É até recomendado termos mais de um nó só para o control plane por
questões de redundância e resiliência do nosso cluster.
- Eu consigo pegar mais informações dos nossos nodes?
Consegue sim. Basta executar o comando describe, da seguinte forma:
$ kubectl describe node kub-node2
Este é um exemplo do describe do node2
Aqui é apenas um trecho, pois a saída de informações é muito maior.
- Consigo fazer o describe também nos pods?
Sim!!!
$ kubectl describe pods nginx-69b9cdbbdd-bb8lj
Então, para reforçar:
- Usamos o get quando queremos
pegar alguma informação
- Usamos o describe quando
queremos pegar mais informações com detalhes
Finalizando
a parte 2
Hoje aprendemos como preparar nosso ambiente para receber a instalação
do kubernetes e como subir nosso primeiro cluster, contemplando a instalação do
nosso CNI para permitir a comunicação entre os pods no ambiente e também como
podemos validar se os nodes estão funcionando corretamente através de um deploy
da aplicação do nginx.
Vamos ver o que nos espera na parte 3 ..., mas posso garantir pra vocês
que essa jornada está apenas começando e ainda tem muita coisa legal para
aprendermos.
Abs e até a próxima.
