Guia Completo de Kubernetes com Containerd e CRI-O: Configuração, Redes Dual-Stack e Otimização

Este tutorial detalhado explora a configuração e gerenciamento de clusters Kubernetes com os runtimes Containerd e CRI-O, abordando desde a instalação e configuração inicial até práticas avançadas de redes dual-stack (IPv4 e IPv6), segurança, otimização de recursos e monitoramento. Ideal para engenheiros de DevOps e administradores de sistemas que buscam implementar Kubernetes com alta performance, segurança e observabilidade.

Posted Nov 27, 2024

By Gean Martins

62 min read

Introdução

A orquestração de containers com Kubernetes é uma prática essencial para arquiteturas modernas de microsserviços e para ambientes de alta disponibilidade. Entre as escolhas cruciais para uma implementação eficiente de Kubernetes estão os runtimes de container, como Containerd e CRI-O, que oferecem alta performance e integração com a infraestrutura Kubernetes. Este tutorial visa guiar você através das configurações detalhadas de Kubernetes com esses runtimes, incluindo a configuração de redes dual-stack (IPv4 e IPv6), monitoramento avançado, otimização de recursos, e práticas recomendadas de segurança.

Além das configurações essenciais, este guia cobre a implementação de plugins de rede, como Calico e Cilium, que garantem suporte a redes dual-stack e oferecem funcionalidades avançadas de políticas de segurança e observabilidade. Este tutorial é ideal para administradores de sistemas e engenheiros de DevOps que buscam uma base sólida para implementar e gerenciar Kubernetes com alta performance, segurança e flexibilidade.

Sumário

Introdução ao Kubernetes e Runtimes de Containers
Configuração do Ambiente: Instalação do Kubernetes, Containerd e CRI-O
Integração do Kubernetes com Containerd
Integração do Kubernetes com CRI-O
Configuração do Kubelet para Uso de Múltiplos Runtimes
Criação e Gerenciamento de Pods e Deployments com Kubernetes
Monitoramento e Logs com Containerd e CRI-O
Segurança em Kubernetes com Containerd e CRI-O
Configuração de Redes e Plugins CNI com Containerd e CRI-O
Otimização de Performance e Gerenciamento de Recursos
Atualização e Manutenção de Cluster Kubernetes com Containerd e CRI-O
Troubleshooting e Solução de Problemas com Runtimes no Kubernetes
Configuração de Suporte IPv6 e Dual-Stack no Kubernetes com Calico
Configuração de Rede Dual-Stack IPv6 com Cilium em Kubernetes

1. Introdução ao Kubernetes e Runtimes de Containers

Objetivo:
Apresentar o Kubernetes e a importância dos runtimes de containers, especialmente o Containerd e o CRI-O, na orquestração de containers. Nesta seção, você entenderá o papel do Kubernetes, o conceito de runtimes de containers e por que Containerd e CRI-O são amplamente recomendados para ambientes Kubernetes modernos.

1.1 O que é Kubernetes?

O Kubernetes é uma plataforma de código aberto criada pelo Google para automação de implantação, escala e gerenciamento de aplicações em containers. Ele permite administrar clusters de máquinas virtuais ou físicas que executam containers, abstraindo complexidades da infraestrutura e simplificando o gerenciamento de aplicações em larga escala.

Principais Funções:
- Orquestração de Containers: Gerencia a implantação e escala de containers, controlando o ciclo de vida das aplicações.
- Resiliência: Monitora o estado das aplicações, reiniciando containers falhos e redistribuindo cargas conforme necessário.
- Escalabilidade: Ajusta a quantidade de réplicas de uma aplicação automaticamente, conforme a demanda.
- Atualização Contínua: Facilita a atualização e o rollback de aplicações em produção.

O Kubernetes é ideal para empresas que precisam executar e manter aplicações distribuídas, oferecendo uma maneira flexível de gerenciar complexos sistemas de microserviços.

1.2 Runtimes de Containers: Conceito e Importância

O runtime de container é o software responsável por iniciar, gerenciar e parar containers em um sistema. Ele se comunica diretamente com o sistema operacional para executar o isolamento e a execução do container. No Kubernetes, o runtime é fundamental para a criação de containers e gerenciamento dos recursos necessários para que os containers possam rodar de maneira eficiente e segura.

Por que é Importante?
O runtime é a ponte entre o Kubernetes e o sistema operacional. Ele permite que o Kubernetes execute comandos para iniciar, parar e gerenciar containers de forma padronizada, usando a Interface de Runtime de Containers (CRI).
Exemplos de Runtimes:
- Docker: Amplamente utilizado, mas inclui ferramentas extras além do runtime.
- Containerd: Um runtime mais leve e eficiente, recomendado pela CNCF para Kubernetes.
- CRI-O: Um runtime leve, projetado para executar containers seguindo o padrão CRI, ideal para Kubernetes.

1.3 Diferença entre Docker, Containerd e CRI-O

A evolução dos runtimes levou ao uso de ferramentas mais especializadas, como Containerd e CRI-O, em vez do Docker. Cada um desses runtimes possui características específicas que os tornam mais ou menos indicados para Kubernetes:

Runtime	Descrição	Ideal para
Docker	Inclui um conjunto completo de ferramentas para criação, distribuição e execução de containers, mas é um pacote maior do que o necessário para Kubernetes.	Desenvolvimento local, CI/CD.
Containerd	Uma versão mais leve e modular do Docker, foca apenas no runtime e gerenciamento de containers. Recomendado pela CNCF para Kubernetes.	Clusters Kubernetes de produção.
CRI-O	Um runtime desenvolvido especificamente para Kubernetes, focado na compatibilidade com a Interface de Runtime de Contêiner (CRI).	Kubernetes com performance otimizada.

Por que Containerd e CRI-O?
- Leves e Otimizados: Ambos são leves e especializados, integrando-se ao Kubernetes sem os componentes extras do Docker.
- Compatibilidade com CRI: Tanto o Containerd quanto o CRI-O foram projetados para serem compatíveis com a CRI, o que significa que eles funcionam diretamente com o Kubernetes sem a necessidade de camadas intermediárias.
- Performance e Estabilidade: Devido à sua simplicidade, Containerd e CRI-O oferecem melhor performance e menos sobrecarga, sendo mais eficientes em clusters de produção.

1.4 Por que Containerd e CRI-O são Mais Recomendados para Kubernetes?

Com a transição do Kubernetes para runtimes que seguem a CRI, como o Containerd e CRI-O, há várias vantagens:

Simplicidade e Modularidade:
- Diferente do Docker, que vem com ferramentas extras, Containerd e CRI-O são focados apenas no runtime, simplificando o gerenciamento de containers e reduzindo o risco de falhas.
Integração Direta com Kubernetes:
- Como ambos os runtimes são compatíveis com CRI, eles podem se integrar diretamente ao Kubernetes, facilitando a manutenção e evitando sobrecarga de componentes intermediários.
Segurança e Controle:
- Containerd e CRI-O oferecem configurações avançadas de segurança que permitem melhor controle sobre o ambiente de execução dos containers, atendendo às necessidades de ambientes de produção.
Comunidade e Suporte:
- Tanto Containerd quanto CRI-O são suportados pela CNCF e têm comunidades ativas, com atualizações regulares e práticas de segurança revisadas.

2. Configuração do Ambiente: Instalação do Kubernetes, Containerd e CRI-O

Objetivo:
Ensinar como preparar o ambiente, instalando e configurando o Kubernetes com os runtimes Containerd e CRI-O. Esta seção aborda o processo de instalação e verificação do ambiente em distribuições Linux Debian 12.

2.1 Instalação do Kubernetes em Distribuições Linux Debian 12

Para iniciar, é preciso configurar o ambiente com o Kubernetes, que será responsável por gerenciar os containers usando Containerd ou CRI-O como runtime.

Passo 1: Configurar Dependências do Kubernetes

Atualizar o sistema e instalar pacotes básicos:

        
sudo apt update && sudo apt upgrade -y
sudo apt install -y apt-transport-https curl

Adicionar a chave GPG do repositório Kubernetes:

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

Adicionar o repositório Kubernetes:

        
      
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

Passo 2: Instalar o Kubernetes (kubeadm, kubelet, kubectl)

Atualizar os repositórios e instalar os pacotes:

        
sudo apt update
sudo apt install -y kubelet kubeadm kubectl

Marcar as versões para evitar atualizações automáticas (mantendo a consistência do cluster):
1 sudo apt-mark hold kubelet kubeadm kubectl

Ativar e iniciar o kubelet:

        
      
sudo systemctl enable kubelet && sudo systemctl start kubelet

2.2 Instalação e Configuração do Containerd

Containerd é um runtime leve para Kubernetes, amplamente recomendado pela CNCF.

Passo 1: Instalar o Containerd

Instalar o Containerd:
1 sudo apt install -y containerd

Configurar o arquivo config.toml para ajustes básicos:

        
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

Ajuste de Configurações no config.toml
Para garantir que o Containerd funcione de forma ideal com o Kubernetes, edite o arquivo /etc/containerd/config.toml:
- Habilite o modo Systemd para o cgroup:
  1 2 3 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true

Iniciar e habilitar o Containerd:

        
sudo systemctl restart containerd
sudo systemctl enable containerd

2.3 Instalação e Configuração do CRI-O

O CRI-O é outro runtime leve, desenvolvido especialmente para rodar containers no Kubernetes com base no padrão CRI.

Passo 1: Configurar o Repositório CRI-O

Adicionar o repositório para a versão estável do CRI-O:

Primeiro, defina a variável de versão compatível com o Kubernetes. Exemplo para a versão 1.24:
1 VERSION=1.24

Adicionar o repositório e instalar o CRI-O:

        
echo "deb [signed-by=/usr/share/keyrings/libcontainers-archive-keyring.gpg] https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04/ /" | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/xUbuntu_20.04/Release.key | gpg --dearmor -o /usr/share/keyrings/libcontainers-archive-keyring.gpg

sudo apt update
sudo apt install -y cri-o cri-o-runc

Habilitar e Iniciar o CRI-O:

        
      
sudo systemctl daemon-reload
sudo systemctl enable crio
sudo systemctl start crio

2.4 Configuração para Comunicação do Kubernetes com os Runtimes

Para garantir que o Kubernetes utilize o runtime correto (Containerd ou CRI-O), precisamos configurar o kubelet para especificar o runtime de container.

Passo 1: Configurar o `kubelet` para Usar Containerd ou CRI-O

Editar o arquivo de configuração do kubelet (/var/lib/kubelet/config.yaml):

        
      
# Configuração para Containerd
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
containerRuntimeEndpoint: "unix:///run/containerd/containerd.sock"

# Configuração para CRI-O
# containerRuntimeEndpoint: "unix:///var/run/crio/crio.sock"

Reiniciar o kubelet para aplicar as alterações:
1 sudo systemctl restart kubelet

Verificar a Conexão entre Kubernetes e o Runtime

Para verificar se o Kubernetes reconhece o runtime de container configurado:

kubectl get nodes

Esse comando deve retornar o estado dos nós, indicando que eles estão ativos e reconhecem o runtime de container configurado.

Resumo da Seção

Nesta seção, configuramos o ambiente Kubernetes com os runtimes de containers Containerd e CRI-O. Instalar e configurar esses componentes é essencial para garantir que o cluster Kubernetes possa gerenciar containers de forma eficiente e com alta compatibilidade com o CRI. Na próxima seção, veremos como integrar o Kubernetes com Containerd, ajustando os parâmetros e verificando o funcionamento inicial do runtime no cluster.

3. Integração do Kubernetes com Containerd

Objetivo:
Demonstrar como integrar o Kubernetes ao runtime Containerd, configurando-o como o runtime padrão para execução de containers. Nesta seção, faremos os ajustes necessários no arquivo de configuração do Containerd e iniciaremos o Kubernetes com o runtime configurado.

3.1 Configuração do Containerd como Runtime Padrão no Kubernetes

O Containerd precisa estar configurado corretamente para servir como runtime do Kubernetes. Isso inclui ajustar o arquivo config.toml para garantir que o Containerd esteja integrado ao Kubernetes de forma otimizada.

Passo 1: Configurar o `config.toml` do Containerd

Verificar se o Containerd já possui uma configuração. Caso contrário, gerar a configuração padrão:

        
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

Configurar o uso do Systemd para Cgroups

O Kubernetes recomenda o uso de Systemd como driver de cgroup para ambientes de produção, o que garante um gerenciamento de recursos mais consistente e seguro.
- Abra o arquivo /etc/containerd/config.toml e ajuste o seguinte trecho para configurar o Systemd:
  1 2 3 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true
- Salve e feche o arquivo após a edição.
Reiniciar o Containerd para aplicar as alterações
1 sudo systemctl restart containerd

3.2 Configuração do Kubelet para Usar o Containerd

Agora, precisamos ajustar o kubelet para especificar o Containerd como runtime. Esse ajuste permite que o Kubernetes interaja diretamente com o Containerd.

Passo 1: Editar a Configuração do `kubelet`

Configurar o endpoint do runtime no arquivo do kubelet:

Edite o arquivo de configuração do kubelet, que geralmente está localizado em /var/lib/kubelet/config.yaml.
- Certifique-se de que o containerRuntimeEndpoint aponte para o Containerd:
  1 2 3 kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 containerRuntimeEndpoint: "unix:///run/containerd/containerd.sock"
Reiniciar o kubelet para que ele passe a usar o runtime configurado:
1 sudo systemctl restart kubelet

Passo 2: Verificar a Integração entre Kubernetes e Containerd

Depois de reiniciar o kubelet, podemos verificar se o Kubernetes está reconhecendo o Containerd como runtime ativo.

Verificar o estado dos nós do Kubernetes:
1 kubectl get nodes
- Esse comando deve mostrar os nós como Ready, indicando que o kubelet está integrado ao Containerd e que o cluster está funcionando corretamente.

Verificar o Runtime do Containerd em um Pod:

Podemos criar um pod de teste para verificar o runtime em uso. Crie um arquivo YAML para o pod:

        
      
# pod-containerd-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: containerd-test
spec:
  containers:
    - name: nginx
      image: nginx

Aplique o YAML com o comando:

kubectl apply -f pod-containerd-test.yaml

Verificar o Runtime Usado pelo Pod:

Após a criação do pod, use o comando abaixo para verificar qual runtime foi utilizado:
1 kubectl get pod containerd-test -o=jsonpath='{.status.containerStatuses[0].containerID}'
- O resultado deve incluir containerd://, confirmando que o Containerd está sendo usado para gerenciar o container.

3.3 Exemplo Prático: Iniciar um Nó Kubernetes com Containerd

Neste exemplo, criaremos e gerenciaremos um nó Kubernetes com o runtime Containerd configurado.

Passo 1: Iniciar um Cluster com `kubeadm`

Utilize o kubeadm para iniciar um cluster com o Containerd como runtime:

Criar o Cluster:
1 sudo kubeadm init --pod-network-cidr=10.244.0.0/16
- Nota: Certifique-se de ajustar o --pod-network-cidr de acordo com o plugin de rede CNI que será usado. Neste exemplo, usamos 10.244.0.0/16, que é compatível com Flannel.

Configurar o kubectl para o Usuário Local:

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

Verificar o Cluster e o Runtime do Nó:

Para verificar o runtime de cada nó, use o seguinte comando:
1 kubectl get nodes -o wide
Aplicar um Plugin de Rede CNI (exemplo com Flannel):

Após a inicialização do cluster, aplique um plugin de rede. Neste exemplo, usaremos Flannel:
1 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
Isso completa a configuração de um nó Kubernetes que utiliza o Containerd como runtime.

3.4 Checklist para Verificação da Integração

Verificar se o kubelet está configurado para usar o Containerd com o endpoint correto no arquivo /var/lib/kubelet/config.yaml.
Verificar o status do kubelet e do Containerd usando systemctl status kubelet e systemctl status containerd.
Verificar a criação de pods e o runtime do container, confirmando que os containers estão sendo executados com containerd://.

Resumo da Seção

Nesta seção, configuramos o Containerd como runtime padrão para o Kubernetes, ajustando o kubelet e verificando a integração entre os componentes. Agora, o Kubernetes utiliza o Containerd para iniciar e gerenciar containers, com uma configuração otimizada para ambientes de produção. A próxima seção será dedicada à integração com o CRI-O, outro runtime leve e eficiente para Kubernetes.

4. Integração do Kubernetes com CRI-O

Objetivo:
Demonstrar como configurar o Kubernetes para usar o CRI-O como runtime de containers. Nesta seção, vamos ajustar o kubelet para trabalhar com o CRI-O e verificar a integração entre o Kubernetes e o CRI-O.

4.1 Configuração do CRI-O como Runtime Padrão no Kubernetes

O CRI-O foi projetado especificamente para Kubernetes, tornando-o uma escolha natural para quem busca um runtime leve e eficiente.

Passo 1: Ajustar a Configuração do `kubelet` para Usar o CRI-O

Para integrar o Kubernetes ao CRI-O, o kubelet deve ser configurado para reconhecer o CRI-O como runtime de container.

Editar o arquivo de configuração do kubelet
Abra o arquivo de configuração do kubelet, normalmente localizado em /var/lib/kubelet/config.yaml, e defina o endpoint do CRI-O:
1 2 3 kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 containerRuntimeEndpoint: "unix:///var/run/crio/crio.sock"
Reiniciar o kubelet para que ele reconheça o CRI-O como runtime:
1 sudo systemctl restart kubelet

Passo 2: Verificar o Funcionamento do CRI-O com Kubernetes

Depois de reiniciar o kubelet, use o kubectl para verificar se o Kubernetes está reconhecendo o CRI-O como runtime ativo.

Verificar o Status dos Nós Kubernetes:
1 kubectl get nodes
- Esse comando deve retornar os nós como Ready, indicando que o Kubernetes reconhece o CRI-O como runtime.

Verificar o Runtime do Container em um Pod de Teste

Para garantir que o CRI-O está funcionando, crie um pod de teste usando o YAML abaixo:

        
      
# pod-crio-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: crio-test
spec:
  containers:
    - name: nginx
      image: nginx

Aplique o YAML:

kubectl apply -f pod-crio-test.yaml

Confirmar o Runtime Utilizado pelo Pod

Após criar o pod, use o comando a seguir para verificar o runtime:
1 kubectl get pod crio-test -o=jsonpath='{.status.containerStatuses[0].containerID}'
- O resultado deve incluir cri-o://, confirmando que o CRI-O está gerenciando o container.

4.2 Exemplo Prático: Inicialização de um Nó Kubernetes com CRI-O

Vamos inicializar um cluster Kubernetes usando o kubeadm, com o CRI-O como runtime.

Passo 1: Inicializar o Cluster com `kubeadm`

Para iniciar o cluster com kubeadm, execute:

        
      
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Nota: Ajuste o --pod-network-cidr conforme o plugin de rede que será utilizado. Neste exemplo, estamos utilizando a faixa 10.244.0.0/16, que é compatível com o Flannel.

Passo 2: Configurar o `kubectl` para o Usuário Local

Após a inicialização, configure o kubectl para o usuário local:

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

Passo 3: Aplicar um Plugin de Rede CNI (Exemplo com Flannel)

Para que os pods possam se comunicar, é necessário aplicar um plugin de rede. Neste exemplo, usaremos o Flannel:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Isso completa a configuração inicial do nó Kubernetes com o CRI-O.

4.3 Checklist para Verificação da Integração com CRI-O

Verificar o arquivo config.yaml do kubelet para garantir que o containerRuntimeEndpoint está apontando para o CRI-O (/var/run/crio/crio.sock).
Confirmar o status do kubelet e do CRI-O usando systemctl status kubelet e systemctl status crio.
Criar pods de teste para verificar o funcionamento do CRI-O, confirmando que o runtime usado é cri-o://.

Resumo da Seção

Nesta seção, configuramos o Kubernetes para usar o CRI-O como runtime de containers, realizando os ajustes necessários no kubelet e verificando a integração por meio de pods de teste. Com isso, o Kubernetes está preparado para gerenciar containers de maneira eficiente usando o CRI-O, um runtime projetado especificamente para ambientes Kubernetes. Na próxima seção, abordaremos a configuração do kubelet para uso de múltiplos runtimes, o que permite alternar entre Containerd e CRI-O conforme as necessidades do ambiente.

5. Configuração do Kubelet para Uso de Múltiplos Runtimes

Objetivo:
Demonstrar como configurar o kubelet para suportar múltiplos runtimes, como Containerd e CRI-O. Nesta seção, faremos os ajustes necessários para alternar entre os runtimes conforme as necessidades do ambiente Kubernetes, garantindo flexibilidade e facilidade de administração.

5.1 Por que Usar Múltiplos Runtimes no Kubernetes?

A capacidade de alternar entre diferentes runtimes permite que os administradores ajustem o ambiente Kubernetes de acordo com necessidades específicas, como requisitos de compatibilidade, desempenho ou características de segurança.

Cenários Comuns:

Desempenho Diferenciado: Permite escolher o runtime mais adequado para cargas de trabalho intensivas.
Compatibilidade e Teste: Ideal para ambientes de teste, onde você pode avaliar a compatibilidade de diferentes runtimes.
Flexibilidade em Clusters Híbridos: Pode ser útil em clusters que atendem múltiplos tipos de cargas de trabalho.

5.2 Configuração do Kubelet para Suporte a Múltiplos Runtimes

O Kubernetes permite a configuração do kubelet para alternar entre runtimes, definindo endpoints de runtime que apontam para o socket do Containerd ou do CRI-O.

Passo 1: Editar o Arquivo de Configuração do `kubelet`

Localizar e Abrir o Arquivo de Configuração
O arquivo de configuração do kubelet está localizado em /var/lib/kubelet/config.yaml.
Configurar o Endpoint do Runtime
No arquivo de configuração do kubelet, o parâmetro containerRuntimeEndpoint define o runtime a ser usado:
- Para Containerd:
  1 containerRuntimeEndpoint: "unix:///run/containerd/containerd.sock"
- Para CRI-O:
  1 containerRuntimeEndpoint: "unix:///var/run/crio/crio.sock"
Configuração Dinâmica
Infelizmente, o Kubernetes não suporta a configuração simultânea de múltiplos runtimes em um único nó. A escolha do runtime é feita ao editar e definir um único endpoint no config.yaml. Para alternar entre os runtimes, é necessário alterar o valor do containerRuntimeEndpoint e reiniciar o kubelet.

5.3 Exemplo Prático de Alteração Dinâmica entre Containerd e CRI-O

Aqui está um exemplo prático de como alternar entre os runtimes Containerd e CRI-O em um nó Kubernetes.

Passo 1: Configurar o Kubelet para Usar o Containerd

Editar o Arquivo config.yaml do kubelet para Apontar para o Socket do Containerd:
1 containerRuntimeEndpoint: "unix:///run/containerd/containerd.sock"
Reiniciar o kubelet para aplicar as mudanças:
1 sudo systemctl restart kubelet

Verificar o Runtime do Container
Crie um pod de teste e verifique o runtime, que deve retornar containerd://:

        
kubectl run test-containerd --image=nginx
kubectl get pod test-containerd -o=jsonpath='{.status.containerStatuses[0].containerID}'

Passo 2: Alterar o Kubelet para Usar o CRI-O

Editar o Arquivo config.yaml para Apontar para o Socket do CRI-O:

        
      
containerRuntimeEndpoint: "unix:///var/run/crio/crio.sock"

Reiniciar o kubelet:
1 sudo systemctl restart kubelet

Verificar o Novo Runtime do Container
Crie um pod de teste e verifique o runtime, que agora deve retornar cri-o://:

        
kubectl run test-crio --image=nginx
kubectl get pod test-crio -o=jsonpath='{.status.containerStatuses[0].containerID}'

5.4 Checklist para Alternar Entre Containerd e CRI-O

Verificar e Editar o Endpoint do Runtime no arquivo /var/lib/kubelet/config.yaml para garantir que o containerRuntimeEndpoint aponte para o runtime desejado.
Reiniciar o kubelet após qualquer alteração no arquivo config.yaml.
Verificar o Runtime Utilizado por Pods de Teste usando o comando kubectl get pod <pod-name> -o=jsonpath='{.status.containerStatuses[0].containerID}'.

Resumo da Seção

Nesta seção, configuramos o kubelet para alternar entre os runtimes Containerd e CRI-O, proporcionando flexibilidade para adaptar o ambiente conforme necessário. Esse processo permite configurar o Kubernetes com o runtime que melhor atende aos requisitos específicos de cada aplicação ou ambiente de teste. A próxima seção abordará como criar e gerenciar pods e deployments no Kubernetes com os runtimes Containerd e CRI-O.

6. Criação e Gerenciamento de Pods e Deployments com Kubernetes

Objetivo:
Explicar como criar e gerenciar pods e deployments no Kubernetes, utilizando os runtimes Containerd e CRI-O. A seção inclui exemplos práticos para deployment de aplicações, visualização de logs e verificação do runtime em uso.

6.1 Criação de Pods com Kubernetes e Verificação do Runtime

Para garantir que o Kubernetes está utilizando o runtime desejado (Containerd ou CRI-O), vamos criar um pod e verificar o runtime usado para gerenciar o container.

Passo 1: Criação de um Pod com o Kubernetes

Criar um arquivo YAML para o Pod

Salve o seguinte conteúdo em um arquivo chamado pod-example.yaml:

        
      
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: nginx
      image: nginx

Aplicar o YAML para criar o Pod:
1 kubectl apply -f pod-example.yaml
Verificar o Status do Pod:

Use o comando abaixo para verificar se o pod foi criado e está em execução:
1 kubectl get pods
Verificar o Runtime em Uso:

Confirme qual runtime está em uso pelo Kubernetes para o pod criado:
1 kubectl get pod example-pod -o=jsonpath='{.status.containerStatuses[0].containerID}'
- A saída indicará o runtime em uso, exibindo containerd:// ou cri-o:// conforme a configuração.

6.2 Criação de Deployments no Kubernetes

O Kubernetes permite a criação de Deployments, uma abstração que simplifica a gerência de múltiplas réplicas de um aplicativo e facilita operações como escalonamento e atualizações contínuas.

Passo 1: Criar um Deployment com Kubernetes

Criar o arquivo YAML para o Deployment

Salve o seguinte conteúdo em um arquivo chamado deployment-example.yaml:

        
      
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80

Aplicar o YAML para criar o Deployment:

kubectl apply -f deployment-example.yaml

Verificar o Status do Deployment:

Use o comando abaixo para verificar se o deployment e suas réplicas estão ativas:
1 2 kubectl get deployments kubectl get pods -l app=nginx

Passo 2: Escalonar o Deployment

Para aumentar o número de réplicas, use o comando scale:

kubectl scale deployment nginx-deployment --replicas=5

Verificação: Após o escalonamento, verifique o número de pods em execução:
1 kubectl get pods -l app=nginx

Passo 3: Atualizar o Deployment

Para atualizar o nginx para uma versão mais recente, como nginx:1.19, modifique o arquivo deployment-example.yaml:

        
      
containers:
  - name: nginx
    image: nginx:1.19

Aplique a atualização:

kubectl apply -f deployment-example.yaml

Verificação: Acompanhe o status da atualização com:

kubectl rollout status deployment nginx-deployment

6.3 Verificação de Logs e Status dos Pods e Deployments

O Kubernetes permite verificar os logs dos containers e o status dos pods em detalhes, o que facilita o monitoramento de aplicações e a detecção de problemas.

Passo 1: Verificar Logs de um Pod

Para verificar os logs de um pod específico:

kubectl logs <pod-name>

Exemplo:
1 kubectl logs example-pod

Passo 2: Descrever um Pod ou Deployment

Para visualizar detalhes e o histórico de eventos de um pod ou deployment, use o comando describe:

kubectl describe pod <pod-name>
kubectl describe deployment <deployment-name>

Exemplo:
1 kubectl describe pod example-pod
Esse comando exibe informações detalhadas sobre o status do pod, eventos e problemas encontrados durante a inicialização.

6.4 Exemplo Prático: Verificando o Runtime e Gerenciando Pods com Containerd/CRI-O

Vamos recapitular o uso do runtime de container (Containerd ou CRI-O) no Kubernetes com alguns passos práticos.

Confirmar o Runtime com um pod de teste:
- Ao criar um novo pod, confirme o runtime utilizado para o container com kubectl get pod example-pod -o=jsonpath='{.status.containerStatuses[0].containerID}'.
Escalonar e atualizar o Deployment:
- Crie réplicas adicionais e aplique uma atualização de imagem ao nginx-deployment para simular uma mudança em ambiente de produção.
Monitorar Logs e Status:
- Utilize kubectl logs e kubectl describe para obter informações de logs e status, ajudando a identificar e resolver possíveis problemas no cluster.

Resumo da Seção

Nesta seção, criamos e gerenciamos pods e deployments no Kubernetes com os runtimes Containerd e CRI-O, incluindo exemplos práticos de verificação do runtime, escalonamento e atualização de deployments. Com isso, você pode gerenciar aplicações de maneira eficiente, aproveitando a flexibilidade dos runtimes suportados pelo Kubernetes. Na próxima seção, abordaremos o monitoramento e o acesso a logs para Containerd e CRI-O, essencial para manter o ambiente em funcionamento e identificar problemas rapidamente.

7. Monitoramento e Logs com Containerd e CRI-O

Objetivo:
Ensinar como monitorar e acessar logs dos runtimes Containerd e CRI-O no Kubernetes, utilizando ferramentas como crictl para inspeção e monitoramento de containers. Monitorar os runtimes permite identificar e resolver problemas rapidamente, mantendo o ambiente Kubernetes estável e eficiente.

7.1 Ferramenta `crictl` para Inspeção e Monitoramento de Containers

A ferramenta crictl foi desenvolvida para interagir diretamente com runtimes que seguem a CRI (Container Runtime Interface), como Containerd e CRI-O. Ela fornece comandos para gerenciar containers, visualizar logs, inspecionar status e muito mais.

Instalação do `crictl`

Baixar a Versão mais Recente do crictl:

        
VERSION="v1.24.0"  # Substitua pela versão desejada
curl -L https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz | sudo tar -C /usr/local/bin -xz

Configurar o crictl para Usar o Runtime Certo
Para que o crictl se comunique corretamente com o runtime desejado, é preciso ajustar o arquivo de configuração. Crie o arquivo /etc/crictl.yaml:
- Configuração para Containerd:
  1 runtime-endpoint: "unix:///run/containerd/containerd.sock"
- Configuração para CRI-O:
  1 runtime-endpoint: "unix:///var/run/crio/crio.sock"
Verificar a Instalação
Execute um comando básico para garantir que o crictl está funcionando:
1 sudo crictl info
- Esse comando deve retornar informações sobre o runtime e sua configuração.

7.2 Monitoramento de Containers com `crictl`

O crictl fornece vários comandos para monitoramento e gerenciamento de containers em execução. Abaixo estão alguns dos comandos mais úteis:

Listar Containers em Execução

Para ver todos os containers que estão sendo gerenciados pelo runtime configurado, use:

sudo crictl ps

Parâmetros Úteis:
- -a: Exibe todos os containers, incluindo os parados.
- --name <container_name>: Filtra por nome do container.

Inspecionar Detalhes de um Container

Para inspecionar um container específico e obter detalhes como o runtime, status e recursos alocados:

sudo crictl inspect <container_id>

Dica: O container_id pode ser obtido com o comando crictl ps.

Ver Logs de um Container

Para acessar os logs de um container específico:

sudo crictl logs <container_id>

Esse comando é útil para identificar problemas específicos dentro do container e verificar logs de aplicações.

Parar e Remover Containers

Parar um Container:
1 sudo crictl stop <container_id>
Remover um Container:
1 sudo crictl rm <container_id>

Esses comandos são úteis para gerenciamento e manutenção de containers em clusters de desenvolvimento ou teste.

7.3 Logs do Runtime de Container no Kubernetes

Além do crictl, é importante configurar os logs do runtime para serem capturados e acessíveis no sistema.

Configuração de Logs no Containerd

Editar o Arquivo config.toml do Containerd:

Abra o arquivo /etc/containerd/config.toml e configure o nível de log conforme necessário:
1 2 [plugins."io.containerd.grpc.v1.cri".containerd] log_level = "info" # Altere para "debug" para log detalhado
Reiniciar o Containerd para Aplicar as Alterações:
1 sudo systemctl restart containerd
Visualizar Logs do Containerd

Os logs do Containerd podem ser visualizados usando o comando journalctl:
1 sudo journalctl -u containerd -f

Configuração de Logs no CRI-O

Editar o Arquivo de Configuração do CRI-O
O arquivo de configuração do CRI-O geralmente está em /etc/crio/crio.conf. Ajuste o nível de log conforme necessário:
1 2 [crio] log_level = "info" # Altere para "debug" para log detalhado
Reiniciar o CRI-O para Aplicar as Alterações:
1 sudo systemctl restart crio
Visualizar Logs do CRI-O

Para visualizar logs em tempo real do CRI-O:
1 sudo journalctl -u crio -f

7.4 Exemplos Práticos de Monitoramento e Troubleshooting com `crictl`

Vamos recapitular os comandos do crictl com alguns exemplos práticos para monitoramento e troubleshooting.

Listar Todos os Containers:
1 sudo crictl ps -a
Ver Logs de um Container Específico:
1 sudo crictl logs <container_id>
Diagnosticar Problemas com inspect:

Se um container está em estado de erro, use inspect para verificar detalhes:
1 sudo crictl inspect <container_id>
Verificar o Runtime Utilizado:

Confirme o runtime de um container específico para assegurar que o ambiente está funcionando como esperado:
1 kubectl get pod <pod-name> -o=jsonpath='{.status.containerStatuses[0].containerID}'

Resumo da Seção

Nesta seção, exploramos o uso do crictl para monitoramento e logs de containers no Kubernetes com runtimes Containerd e CRI-O. Com esses comandos e configurações, você poderá monitorar o desempenho e resolver problemas de containers de forma eficiente, usando ferramentas específicas para inspeção e diagnóstico. Na próxima seção, abordaremos práticas de segurança em Kubernetes, com foco em containers gerenciados pelo Containerd e CRI-O.

8. Segurança em Kubernetes com Containerd e CRI-O

Objetivo:
Explorar as práticas de segurança para Kubernetes usando os runtimes Containerd e CRI-O, incluindo políticas de segurança, uso de SELinux e AppArmor, e exemplos de aplicação de segurança para proteger containers e pods.

8.1 Configuração de Políticas de Segurança para Execução de Containers

No Kubernetes, a segurança pode ser reforçada com Policies que restringem ações de pods e containers. A Pod Security Policy (PSP) (descontinuada em versões recentes) ou políticas personalizadas permitem controlar o acesso a recursos e definir parâmetros de execução.

Alternativa Atual: Políticas de Segurança com Admission Controllers

Com o fim das PSPs, recomendamos o uso de ferramentas como OPA/Gatekeeper para definir regras de segurança avançadas.

Instalar o Gatekeeper (OPA):

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.7/deploy/gatekeeper.yaml

Configurar Políticas de Segurança com Gatekeeper
Com o Gatekeeper, você pode definir políticas de segurança que controlam o acesso e o comportamento dos pods, assegurando que padrões seguros sejam seguidos.

Exemplo de Política Básica:

Este exemplo impede que contêineres sejam executados com privilégios elevados.

        
      
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: disallow-privileged-containers
spec:
  enforcementAction: deny

8.2 Uso de SELinux e AppArmor para Proteção de Containers

SELinux e AppArmor são mecanismos de segurança em nível de kernel que controlam o acesso aos recursos do sistema pelos containers. Ambos podem ser configurados para restringir o comportamento dos pods e impedir acesso indevido a recursos do host.

Configuração de SELinux

Ativar o SELinux no Host:

No sistema host, verifique se o SELinux está ativo:
1 sudo setenforce 1 # Ativa o modo Enforcing
Configurar o Containerd e CRI-O para Trabalhar com SELinux

No arquivo de configuração do Containerd (/etc/containerd/config.toml), habilite o uso de SELinux:
1 2 [plugins."io.containerd.grpc.v1.cri".containerd] selinux = true
No CRI-O (/etc/crio/crio.conf), habilite o SELinux:
1 2 [crio.runtime] selinux = true
Aplicar Contextos de Segurança:
Ao configurar SELinux, certifique-se de aplicar os contextos de segurança necessários para restringir o acesso dos containers aos recursos do host.

Configuração de AppArmor

O AppArmor permite definir perfis de segurança que limitam as ações de processos em execução.

Ativar o AppArmor no Host:

Verifique se o AppArmor está ativo no sistema:
1 sudo systemctl status apparmor
Criar um Perfil AppArmor para o Container
Salve o perfil no diretório /etc/apparmor.d/. Exemplo de um perfil AppArmor restritivo:
1 sudo apparmor_parser -r /etc/apparmor.d/my-container-profile

Aplicar o Perfil AppArmor ao Pod
No manifesto do pod, aplique o perfil:

        
      
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
    - name: nginx
      image: nginx
      securityContext:
        apparmorProfile: "my-container-profile"

8.3 Configuração de SecurityContext no Kubernetes

O securityContext é usado para definir configurações de segurança específicas para pods e containers, restringindo o acesso a recursos e controlando permissões.

Exemplo de Configuração de SecurityContext para um Container

O securityContext pode ser usado para definir se um container roda com privilégios e quais são as permissões.

        
      
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
    - name: nginx
      image: nginx
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        privileged: false
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]

Parâmetros Importantes:
- runAsUser: Especifica o ID do usuário que o container usará, evitando o uso do root.
- privileged: Impede a execução do container em modo privilegiado.
- allowPrivilegeEscalation: Bloqueia a elevação de privilégios no container.
- capabilities: Remove todas as capacidades de root do container para minimizar os riscos.

8.4 Exemplo Prático de Política de Segurança em Containers com Containerd/CRI-O

Criar um Pod Restrito com SecurityContext

Definir o Manifesto do Pod

Salve o seguinte conteúdo em secure-pod.yaml:

        
      
apiVersion: v1
kind: Pod
metadata:
  name: secure-nginx
spec:
  containers:
    - name: nginx
      image: nginx
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]

Aplicar a Configuração do Pod:
1 kubectl apply -f secure-pod.yaml
Verificar o Pod e o SecurityContext:

Verifique se o pod está rodando com as configurações de segurança aplicadas:
1 kubectl describe pod secure-nginx
Esse comando mostrará os detalhes do securityContext aplicado ao pod, confirmando que as políticas de segurança estão em vigor.

8.5 Checklist de Segurança para Clusters Kubernetes com Containerd e CRI-O

Aplicar SecurityContexts Consistentes em todos os pods para garantir que apenas as permissões necessárias estejam habilitadas.
Utilizar Admission Controllers como Gatekeeper para reforçar políticas de segurança em nível de cluster.
Configurar SELinux ou AppArmor para adicionar camadas de segurança em nível de sistema.
Desativar Containers Privilegiados e evitar o uso de privilégios elevados sempre que possível.
Monitorar e Auditar Atividades regularmente para identificar e mitigar atividades suspeitas.

Resumo da Seção

Nesta seção, configuramos práticas de segurança para o Kubernetes com os runtimes Containerd e CRI-O, usando políticas de segurança, SELinux, AppArmor e configurações de securityContext. Esses elementos aumentam a segurança do ambiente de containers, limitando permissões e reduzindo o risco de acessos não autorizados. Na próxima seção, vamos abordar a configuração de redes e plugins CNI para Containerd e CRI-O, essenciais para a comunicação e segurança de redes no Kubernetes.

9. Configuração de Redes e Plugins CNI com Containerd e CRI-O

Objetivo:
Ensinar como configurar redes no Kubernetes usando plugins CNI com os runtimes Containerd e CRI-O, proporcionando conectividade e segurança na comunicação entre pods e nodes. Veremos como integrar plugins populares, como Calico e Flannel, para gerenciar redes de forma eficiente.

9.1 Introdução aos Plugins CNI no Kubernetes

O Container Network Interface (CNI) é um padrão que define como configurar redes para containers. Kubernetes utiliza plugins CNI para oferecer conectividade entre pods e gerenciar políticas de rede, incluindo isolamento e roteamento.

Principais Plugins CNI:

Calico: Focado em segurança de rede e políticas avançadas, permitindo criação de redes seguras e controle granular.
Flannel: Simples e leve, ideal para clusters menores ou onde políticas de segurança detalhadas não são necessárias.
Weave: Oferece funcionalidades de descoberta de rede e roteamento dinâmico entre pods.

9.2 Configuração de Containerd e CRI-O para Suporte a CNI

Antes de instalar e configurar um plugin CNI, é necessário garantir que o Containerd e o CRI-O estejam configurados para suportar redes CNI.

Verificar Diretório de Configuração do CNI

Os runtimes geralmente utilizam /etc/cni/net.d para armazenar as configurações de plugins CNI.

Criar o Diretório CNI (caso não exista):
1 sudo mkdir -p /etc/cni/net.d
Verificar Diretório de Plugins CNI
O diretório /opt/cni/bin armazena os binários dos plugins CNI.
1 sudo mkdir -p /opt/cni/bin

9.3 Instalação e Configuração de Plugins CNI

Abaixo estão os passos para instalar e configurar os plugins Calico e Flannel, dois dos plugins CNI mais utilizados no Kubernetes.

Instalação e Configuração do Calico

O Calico fornece funcionalidades avançadas de políticas de segurança, tornando-o ideal para clusters que necessitam de controles granulares de rede.

Aplicar a Configuração do Calico:

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Verificar a Instalação do Calico:

Após aplicar o YAML do Calico, confirme que os pods de rede foram criados e estão em execução:
1 kubectl get pods -n kube-system
- Dica: Verifique se os pods calico-kube-controllers e calico-node estão em estado Running.

Configurar Políticas de Rede com o Calico

Com o Calico instalado, você pode definir políticas de rede para controlar o tráfego entre pods e namespaces.

Exemplo de Política de Rede: Restringir o acesso ao nginx apenas para pods dentro do mesmo namespace.

        
      
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: default
spec:
  selector: app == "nginx"
  ingress:
    - action: Allow
      source:
        namespaceSelector: name == "default"

Aplicar a Política:
1 kubectl apply -f policy.yaml

Instalação e Configuração do Flannel

O Flannel é um plugin de rede simples e eficiente, ideal para clusters que não necessitam de políticas de segurança complexas.

Aplicar a Configuração do Flannel:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Verificar a Instalação do Flannel:

Assim como no Calico, verifique se os pods kube-flannel-ds estão em execução:
1 kubectl get pods -n kube-system -l app=flannel
Configuração de Rede com Flannel

O Flannel cria uma rede plana para todos os pods, sem a necessidade de configurações adicionais de políticas de rede.

9.4 Verificação da Conectividade de Rede entre Pods

Após configurar o plugin CNI, é importante verificar se os pods podem se comunicar entre si.

Criar Pods de Teste:

Crie dois pods simples para testar a conectividade de rede:

        
      
# pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
    - name: busybox
      image: busybox
      command: ["sleep", "3600"]

# pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
    - name: busybox
      image: busybox
      command: ["sleep", "3600"]

kubectl apply -f pod1.yaml
kubectl apply -f pod2.yaml

Testar Conectividade entre Pods:

Para verificar se os pods conseguem se comunicar, conecte-se ao pod1 e faça um ping para pod2:
1 kubectl exec -it pod1 -- ping <POD2_IP>
- Nota: Obtenha o IP de pod2 com o comando kubectl get pod pod2 -o wide.
Diagnosticar Problemas de Rede (se necessário)

Caso não haja conectividade, verifique os logs do plugin CNI no namespace kube-system para identificar possíveis erros.

9.5 Checklist para Configuração de Redes com Plugins CNI

Verificar o Diretório CNI: Assegure-se de que o diretório /etc/cni/net.d está configurado.
Instalar Plugins CNI: Confirme a instalação e o funcionamento dos pods do plugin CNI escolhido (Calico, Flannel).
Configurar Políticas de Rede: Caso utilize o Calico, defina políticas para controlar o acesso entre namespaces e pods.
Testar Conectividade entre Pods: Verifique se os pods conseguem se comunicar conforme esperado.

Resumo da Seção

Nesta seção, configuramos redes para Kubernetes com plugins CNI suportados por Containerd e CRI-O. Exploramos as funcionalidades dos plugins Calico e Flannel, além de testar a conectividade entre pods. Configurações de rede são essenciais para a comunicação segura entre aplicações em um cluster Kubernetes. Na próxima seção, veremos práticas de otimização de performance para Kubernetes usando Containerd e CRI-O.

10. Otimização de Performance e Gerenciamento de Recursos

Objetivo:
Explorar práticas de otimização de performance para clusters Kubernetes com runtimes Containerd e CRI-O, incluindo configuração de limites de CPU e memória, ajustes de parâmetros de rede e gerenciamento de recursos em tempo real. Essas práticas ajudam a manter o cluster responsivo, eficiente e adaptado às necessidades das cargas de trabalho.

10.1 Limitação de Recursos e Configuração de Parâmetros no Kubernetes

O Kubernetes permite configurar limites de CPU e memória em pods e containers, o que garante que os recursos do sistema sejam distribuídos de maneira eficiente.

Definir Requests e Limits para CPU e Memória

O uso de requests e limits permite que cada container receba uma quantidade mínima de recursos (requests) e define o máximo que ele pode utilizar (limits).

Exemplo de Configuração de Requests e Limits para CPU e Memória

Salve o seguinte conteúdo em um arquivo chamado resource-limits.yaml:

        
      
apiVersion: v1
kind: Pod
metadata:
  name: resource-pod
spec:
  containers:
    - name: nginx
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "500m"
        limits:
          memory: "512Mi"
          cpu: "1000m"

requests: Define o valor mínimo de memória e CPU que o container terá garantido.
limits: Define o valor máximo de memória e CPU que o container poderá consumir.

Aplicar a Configuração:

kubectl apply -f resource-limits.yaml

Verificar o Consumo de Recursos:

Use o comando kubectl describe pod para verificar os limites e as solicitações definidas:
1 kubectl describe pod resource-pod

Monitoramento de Utilização de Recursos em Tempo Real

Para monitorar o consumo de recursos em tempo real, você pode usar o kubectl top (necessita que o Metric Server esteja instalado).

Instalar o Metric Server (se não estiver instalado):

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Monitorar o Consumo de Recursos:
1 kubectl top pod resource-pod

10.2 Ajuste de Parâmetros de Network e Disk I/O no Containerd e CRI-O

Além de CPU e memória, ajustar os parâmetros de rede e I/O é essencial para garantir a performance em ambientes de alta demanda.

Ajustes no Containerd

Modificar Parâmetros de Network e Disk I/O no config.toml:

O arquivo de configuração do Containerd (/etc/containerd/config.toml) permite ajustes detalhados. Por exemplo, você pode ajustar o tempo de timeout e a largura de banda:
1 2 [plugins."io.containerd.grpc.v1.cri".containerd] snapshotter = "overlayfs"
Configurar o Systemd para Prioridade de Rede e I/O:

Para otimizar o Containerd, edite o serviço do containerd.service para ajustar as prioridades de CPU e I/O no Systemd:
1 2 3 [Service] CPUAccounting=true IOAccounting=true
Após a configuração, reinicie o serviço:
1 2 sudo systemctl daemon-reload sudo systemctl restart containerd

Ajustes no CRI-O

Ajustar Parâmetros de I/O no Arquivo crio.conf

No CRI-O, o arquivo de configuração (/etc/crio/crio.conf) também permite ajustes. Por exemplo, é possível definir o overlayfs como snapshotter para melhorar o desempenho de I/O:
1 2 [storage.options] storage_driver = "overlay"
Habilitar Systemd para Gerenciamento de Recursos

No CRI-O, você pode configurar o Systemd para gerenciar CPU e I/O:
1 2 3 [Service] CPUAccounting=true IOAccounting=true
Reinicie o serviço para aplicar as alterações:
1 2 sudo systemctl daemon-reload sudo systemctl restart crio

10.3 Configurações Avançadas para Otimização de Pods e Containers

Configuração de Affinity e Anti-Affinity

Configurar affinity e anti-affinity ajuda a gerenciar onde os pods serão alocados, o que pode otimizar o uso de recursos e minimizar a latência.

Affinity: Força pods a serem executados próximos de outros pods.
Anti-Affinity: Impede que certos pods sejam alocados no mesmo nó, evitando sobrecarga de recursos.

Exemplo de Anti-Affinity para Distribuir Carga

        
      
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-affinity
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: nginx
              topologyKey: "kubernetes.io/hostname"

Aplicar a Configuração de Affinity/Anti-Affinity:
1 kubectl apply -f nginx-affinity.yaml

Configuração de Autoscaling

Para otimizar o uso de recursos, configure o autoscaling para que o Kubernetes ajuste automaticamente a quantidade de pods conforme a demanda.

Configurar o Horizontal Pod Autoscaler (HPA):

        
      
kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Verificar o Status do Autoscaler:
1 kubectl get hpa

10.4 Monitoramento e Análise de Performance com Ferramentas de Observabilidade

Ferramentas de monitoramento e observabilidade são fundamentais para garantir que o cluster opere de forma otimizada.

Prometheus e Grafana
- Prometheus coleta métricas do cluster e exibe gráficos em tempo real.
- Grafana complementa o Prometheus oferecendo dashboards customizáveis.

Configuração Básica de Prometheus e Grafana

kubectl apply -f https://raw.githubusercontent.com/coreos/kube-prometheus/main/manifests/setup/prometheus-operator.yaml
kubectl apply -f https://raw.githubusercontent.com/coreos/kube-prometheus/main/manifests/

Acessar o Dashboard do Grafana para verificar os gráficos de utilização e desempenho.
1 kubectl port-forward svc/grafana 3000:3000 -n monitoring

10.5 Checklist para Otimização de Performance e Gerenciamento de Recursos

Definir Requests e Limits para CPU e Memória: Evita sobrecarga de recursos e melhora a previsibilidade de performance.
Configurar Affinity e Anti-Affinity: Distribui carga e otimiza o uso de recursos entre nós.
Implementar Autoscaling: Ajusta o número de pods conforme a demanda para otimizar o uso de recursos.
Usar Ferramentas de Monitoramento: Prometheus e Grafana oferecem visibilidade em tempo real do cluster.
Ajustar Parâmetros de Rede e I/O: Configurações detalhadas em Containerd e CRI-O podem melhorar a latência e o desempenho.

Resumo da Seção

Nesta seção, configuramos práticas de otimização de performance no Kubernetes com Containerd e CRI-O, incluindo ajustes de recursos, autoscaling, e ferramentas de monitoramento. Essas práticas garantem que o cluster Kubernetes funcione de maneira eficiente e responsiva. Na próxima seção, abordaremos a atualização e manutenção de clusters Kubernetes com esses runtimes, abordando boas práticas para ambientes de produção.

11. Atualização e Manutenção de Cluster Kubernetes com Containerd e CRI-O

Objetivo:
Explicar como manter e atualizar clusters Kubernetes com os runtimes Containerd e CRI-O, abordando a atualização segura do Kubernetes e dos runtimes de container. Nesta seção, veremos práticas recomendadas para manutenção programada e como garantir a continuidade do cluster durante as atualizações.

11.1 Planejamento de Manutenção e Atualizações

Antes de iniciar uma atualização, é importante planejar para minimizar impactos no cluster e nas aplicações em execução.

Passos para Planejar uma Atualização Segura

Verificar a Compatibilidade de Versão
Consulte a documentação oficial do Kubernetes para assegurar compatibilidade entre as versões do Kubernetes e dos runtimes (Containerd/CRI-O). Isso ajuda a evitar problemas de incompatibilidade durante o processo.
Planejar um Período de Manutenção
Se possível, execute atualizações durante períodos de baixa demanda para reduzir o impacto em aplicações críticas.
Realizar Backups do Cluster
Certifique-se de ter backups atualizados do cluster e dos volumes persistentes, utilizando ferramentas como Velero para realizar backups e facilitar a recuperação em caso de problemas.

11.2 Atualização do Kubernetes com Kubeadm

A ferramenta kubeadm facilita o processo de atualização do Kubernetes, começando pelo controle principal (master) e depois atualizando os nós de trabalho.

Passo 1: Atualizar o Nó Master

Atualizar Pacotes do Kubernetes:

        
sudo apt update
sudo apt install -y kubeadm=<nova_versão>

Executar a Atualização com o Kubeadm:

sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v<nova_versão>

Atualizar o kubelet e o kubectl para a nova versão:

        
sudo apt install -y kubelet=<nova_versão> kubectl=<nova_versão>
sudo systemctl restart kubelet

Passo 2: Atualizar os Nós de Trabalho

Nos nós de trabalho, o processo é semelhante ao do nó master, mas focado na atualização do kubelet.

Atualizar Pacotes do Kubernetes nos nós de trabalho:

        
sudo apt update
sudo apt install -y kubeadm=<nova_versão>

Executar a Atualização de Cada Nó:
1 sudo kubeadm upgrade node

Atualizar o kubelet e o kubectl:

        
sudo apt install -y kubelet=<nova_versão> kubectl=<nova_versão>
sudo systemctl restart kubelet

Verificar o Status dos Nós:

Após a atualização, confirme que todos os nós estão em status Ready:
1 kubectl get nodes

11.3 Atualização do Containerd e CRI-O

Manter os runtimes atualizados é essencial para segurança e compatibilidade com as versões mais recentes do Kubernetes.

Atualização do Containerd

Verificar a Versão Atual e Disponível:
1 containerd --version
Atualizar o Containerd:

Dependendo da distribuição, utilize o gerenciador de pacotes:
1 2 sudo apt update sudo apt install -y containerd
Reiniciar o Containerd para Aplicar as Alterações:
1 sudo systemctl restart containerd

Atualização do CRI-O

Verificar a Versão Atual:
1 crio --version
Atualizar o CRI-O:

No Debian ou Ubuntu, utilize o gerenciador de pacotes:
1 2 sudo apt update sudo apt install -y cri-o
Reiniciar o CRI-O:
1 sudo systemctl restart crio

11.4 Práticas de Manutenção para Ambientes de Produção

A manutenção preventiva ajuda a manter o cluster estável e seguro. Algumas práticas recomendadas incluem:

Monitorar Logs e Alertas Regularmente
Configure sistemas de monitoramento e alertas para identificar possíveis problemas de performance ou segurança.
Realizar Testes de Carga Periódicos
Execute testes de carga para avaliar como o cluster responde sob alta demanda. Isso permite ajustar a configuração antes que ocorra um pico de tráfego inesperado.
Automatizar Tarefas de Manutenção
Automatize tarefas de manutenção com scripts ou ferramentas como Ansible, para simplificar processos de atualização e monitoramento.
Utilizar Ferramentas de Gestão de Versão
Use ferramentas como Flux ou ArgoCD para gerenciar configurações e versões de aplicações e serviços no cluster.

11.5 Checklist de Atualização e Manutenção

Verificar a Compatibilidade de Versão antes de iniciar a atualização.
Planejar um Período de Manutenção para minimizar o impacto.
Fazer Backup do Cluster e Volumes Persistentes.
Atualizar o Nó Master com kubeadm upgrade apply.
Atualizar os Nós de Trabalho individualmente com kubeadm upgrade node.
Atualizar Runtimes de Containers (Containerd e CRI-O) usando o gerenciador de pacotes do sistema.
Reiniciar e Verificar o Status dos Serviços para garantir que todos os componentes estão em execução.

Resumo da Seção

Nesta seção, exploramos o processo de atualização e manutenção de clusters Kubernetes com os runtimes Containerd e CRI-O, cobrindo desde a atualização segura do Kubernetes com kubeadm até a manutenção de ambientes de produção. Essas práticas ajudam a garantir a continuidade das operações, mantendo o cluster atualizado e protegido. Na próxima seção, abordaremos troubleshooting e técnicas para resolver problemas comuns com os runtimes no Kubernetes.

12. Troubleshooting e Solução de Problemas com Runtimes no Kubernetes

Objetivo:
Explicar técnicas de troubleshooting para resolver problemas em clusters Kubernetes que utilizam Containerd e CRI-O como runtimes de container. Esta seção aborda o uso de ferramentas como crictl, kubectl logs, e kubectl describe, além de apresentar diagnósticos comuns e métodos de correção para problemas frequentes.

12.1 Ferramentas Essenciais para Troubleshooting em Kubernetes

Para diagnosticar e resolver problemas no Kubernetes com os runtimes Containerd e CRI-O, é importante conhecer algumas ferramentas essenciais.

kubectl describe: Exibe detalhes sobre objetos do Kubernetes, incluindo eventos e mensagens de erro.
1 kubectl describe pod <pod-name>
kubectl logs: Visualiza os logs de um container em execução.
1 kubectl logs <pod-name> -c <container-name>

crictl: Uma ferramenta CLI para gerenciamento de containers, que permite inspecionar containers, logs e informações do runtime.

        
      
sudo crictl ps        # Listar containers
sudo crictl logs <container-id>  # Verificar logs do container
sudo crictl inspect <container-id>  # Inspecionar detalhes do container

journalctl: Usado para verificar logs do sistema, incluindo logs do kubelet, containerd, e crio.

        
      
sudo journalctl -u kubelet -f
sudo journalctl -u containerd -f
sudo journalctl -u crio -f

12.2 Diagnóstico de Problemas Comuns

Problema 1: Pod em Estado de CrashLoopBackOff

O status CrashLoopBackOff indica que o pod está falhando repetidamente ao iniciar.

Solução:

Verificar os Logs do Pod:

kubectl logs <pod-name> -c <container-name>

Descrever o Pod para ver eventos específicos que podem estar causando falhas:
1 kubectl describe pod <pod-name>
Verificar Recursos de CPU e Memória: O pod pode estar falhando devido à falta de recursos.
1 kubectl top pod <pod-name>
Configurar RestartPolicy: Ajustar o restartPolicy para Never pode ajudar a inspecionar o pod sem que ele reinicie constantemente.

Problema 2: Containers Presos em Estado de “ContainerCreating”

Esse problema geralmente ocorre quando o container não consegue se conectar ao runtime, ou há problemas de rede.

Solução:

Verificar o Status do Runtime (Containerd ou CRI-O):

sudo systemctl status containerd
sudo systemctl status crio

Verificar Logs do Kubelet para mensagens relacionadas ao runtime:
1 sudo journalctl -u kubelet -f
Inspecionar o Pod:
1 kubectl describe pod <pod-name>
Verificar Problemas de Volume: Às vezes, problemas de PersistentVolume podem causar esse erro. Verifique o status dos volumes utilizados pelo pod.

Problema 3: Falha ao Iniciar o Container devido a Configuração de Segurança (SecurityContext)

Problemas de configuração de segurança podem ocorrer, especialmente ao usar SELinux ou AppArmor.

Solução:

Descrever o Pod para verificar se há mensagens sobre SecurityContext ou permissões:
1 kubectl describe pod <pod-name>
Verificar Perfis de Segurança (AppArmor, SELinux):
- No caso de AppArmor, verifique o perfil associado ao pod e, se necessário, desative-o para identificar se é a causa.
- No SELinux, ajuste as permissões no host ou desative-o temporariamente para testar.

12.3 Solução de Problemas Específicos para Containerd e CRI-O

Problema 1: Containerd Não Inicia

Se o Containerd não estiver funcionando, o kubelet não conseguirá criar containers.

Solução:

Verificar o Status e Reiniciar:

sudo systemctl status containerd
sudo systemctl restart containerd

Verificar Logs do Containerd:
1 sudo journalctl -u containerd -f
Revisar Configurações no config.toml para garantir que não há erros de configuração.

Problema 2: Falhas no CRI-O ao Tentar Iniciar Containers

Erros ao iniciar containers com CRI-O podem ser causados por falhas no arquivo crio.conf ou incompatibilidades com o kubelet.

Solução:

Verificar o Status do CRI-O:

sudo systemctl status crio
sudo systemctl restart crio

Revisar Logs do CRI-O:
1 sudo journalctl -u crio -f
Conferir Configurações no crio.conf: Verifique se há configurações incorretas ou se o arquivo foi alterado recentemente.

12.4 Diagnóstico de Problemas de Rede

Problemas de rede em um cluster Kubernetes podem impedir a comunicação entre pods ou entre os nós e o plano de controle (control plane).

Verificação de Problemas de Rede no CNI

Verificar o Status dos Plugins CNI:

        
kubectl get pods -n kube-system -l k8s-app=flannel  # Exemplo com Flannel
kubectl get pods -n kube-system -l k8s-app=calico   # Exemplo com Calico

Inspecionar Logs dos Plugins de Rede:

kubectl logs -n kube-system <cni-pod-name>

Testar Conectividade Entre Pods

Verificar Conectividade com um Pod: Execute um ping de um pod para outro para verificar a conectividade.
1 kubectl exec -it <pod1> -- ping <pod2-ip>
Utilizar o traceroute: Pode ser útil para identificar onde a conexão está falhando.

12.5 Checklist de Troubleshooting

Utilizar kubectl describe e kubectl logs para inspecionar problemas em pods e containers.
Verificar o Status e Logs dos Runtimes (Containerd e CRI-O) com systemctl status e journalctl.
Inspecionar Configurações de Segurança como SecurityContext, SELinux e AppArmor para identificar restrições que podem afetar containers.
Testar Conectividade de Rede entre pods para garantir que o plugin CNI está funcionando corretamente.
Revisar Logs do Kubelet para problemas relacionados ao runtime e rede.

Resumo da Seção

Nesta seção, cobrimos técnicas de troubleshooting e solução de problemas para Kubernetes com os runtimes Containerd e CRI-O, incluindo diagnóstico de problemas comuns e inspeção de logs de pods, containers e do sistema. Com essas técnicas, você estará preparado para identificar e resolver rapidamente problemas em clusters Kubernetes. Na próxima e última seção, vamos explorar práticas recomendadas para gerenciar clusters Kubernetes usando esses runtimes de forma eficiente e segura.

13. Práticas Recomendadas para Clusters Kubernetes com Containerd e CRI-O

Objetivo:
Apresentar práticas recomendadas para gerenciar clusters Kubernetes de forma segura e eficiente utilizando Containerd e CRI-O como runtimes de container. Abordaremos segurança, otimização, automação e dicas de manutenção para ambientes de produção.

13.1 Práticas de Segurança para Clusters Kubernetes

Manter a segurança de clusters Kubernetes é essencial para proteger dados, serviços e aplicações contra acessos não autorizados e ataques.

Segurança de Containers com SecurityContext

Definir SecurityContext para Pods e Containers:
Configure o SecurityContext para limitar privilégios dos containers, bloqueando a execução em modo privilegiado e definindo permissões mínimas.
Usar Perfis SELinux e AppArmor:
Aplicar perfis de segurança com SELinux e AppArmor em ambientes Linux oferece uma camada extra de controle de acesso, prevenindo que processos de containers acessem recursos do host sem permissão.
Políticas de Segurança com Gatekeeper:
Ferramentas como OPA/Gatekeeper permitem aplicar políticas de segurança avançadas, como impedir que pods sejam executados com privilégios elevados.

13.2 Otimização e Escalabilidade de Recursos

Para garantir que os recursos estejam sendo utilizados de forma otimizada, siga estas práticas:

Configurar Requests e Limits de CPU e Memória:
Defina requests e limits adequados para todos os containers. Isso ajuda o Kubernetes a alocar e distribuir recursos de forma eficiente, evitando sobrecarga.
Implementar Autoscaling:
Utilize o Horizontal Pod Autoscaler (HPA) para ajustar a quantidade de réplicas de pods com base no uso de CPU ou outras métricas de performance, permitindo que o cluster responda a variações na demanda.
Gerenciar Afinidade e Anti-Afinidade:
Configure políticas de afinidade e anti-afinidade para distribuir pods entre nós e evitar sobrecarga de recursos em nodes específicos.

13.3 Monitoramento e Observabilidade do Cluster

Monitorar o ambiente é fundamental para garantir disponibilidade e performance.

Implementar Prometheus e Grafana:
Configure o Prometheus para coleta de métricas e o Grafana para visualização. Essas ferramentas são essenciais para observar o uso de recursos, identificar gargalos e monitorar a saúde do cluster.
Usar Logs de Runtimes e Kubelet:
Monitore os logs dos runtimes (Containerd ou CRI-O) e do kubelet com journalctl para diagnosticar rapidamente falhas e resolver problemas de containers.
Definir Alertas para Eventos Críticos:
Configure alertas para eventos críticos, como pods em estado de CrashLoopBackOff, alto consumo de CPU/memória ou falhas de rede. Isso permite a intervenção rápida em problemas críticos.

13.4 Automação de Tarefas de Manutenção e Atualização

Automatizar tarefas ajuda a manter o cluster seguro e atualizado, além de reduzir o tempo de administração.

Automatizar Backups com Velero:
Use o Velero para automatizar backups de recursos e volumes persistentes do Kubernetes, garantindo que dados possam ser restaurados em caso de falhas.
Automatizar Atualizações com Ansible:
Ferramentas de automação como Ansible podem ser configuradas para realizar atualizações periódicas dos nós e dos componentes do Kubernetes, incluindo os runtimes Containerd e CRI-O.
Implementar GitOps para Gerenciamento de Configurações:
Com GitOps, você pode versionar e automatizar a aplicação de configurações no cluster Kubernetes. Ferramentas como ArgoCD e Flux sincronizam as configurações do Git com o cluster, garantindo consistência e facilitando o rollback em caso de problemas.

13.5 Checklist de Práticas Recomendadas para Kubernetes com Containerd e CRI-O

Configurar SecurityContext em todos os Pods para limitar privilégios e definir permissões mínimas.
Habilitar SELinux ou AppArmor para adicionar uma camada extra de segurança ao ambiente de containers.
Definir Requests e Limits de Recursos para garantir a distribuição eficiente de CPU e memória.
Implementar Autoscaling com Horizontal Pod Autoscaler para adaptar a quantidade de réplicas à demanda.
Configurar Prometheus e Grafana para monitoramento contínuo e visibilidade em tempo real.
Automatizar Backups e Atualizações com ferramentas como Velero e Ansible para facilitar a recuperação e manutenção.
Utilizar GitOps para Gerenciamento de Configurações e versionamento de alterações.

Resumo da Seção

Nesta seção, exploramos práticas recomendadas para gerenciamento de clusters Kubernetes com os runtimes Containerd e CRI-O, abordando segurança, otimização, monitoramento e automação. Seguir essas práticas ajuda a manter o cluster seguro, eficiente e bem gerenciado, garantindo alta disponibilidade e performance em ambientes de produção.

Configuração de Suporte IPv6 e Dual-Stack no Kubernetes com Calico

Objetivo:
Demonstrar como habilitar suporte a IPv6 e configurar uma rede dual-stack (IPv4 e IPv6) em um cluster Kubernetes. Este exemplo utiliza o kubeadm para configuração do cluster e o Calico como plugin CNI para gerenciar a rede dual-stack.

Passo 1: Configurar o Arquivo `kubeadm-config.yaml` para IPv6 e Dual-Stack

O arquivo de configuração do kubeadm permite definir sub-redes dual-stack para pods e serviços. Configuraremos o cluster para que ele utilize IPv4 e IPv6.

Criar o arquivo de configuração kubeadm-config.yaml:

        
      
# Arquivo kubeadm-config.yaml
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/14,fd02::/48
  serviceSubnet: 10.96.0.0/16,fd04::/112
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "192.168.200.50"
  bindPort: 6443
nodeRegistration:
  kubeletExtraArgs:
    node-ip: 192.168.200.50,fd00::50

Inicializar o Cluster com o arquivo de configuração:

        
      
sudo kubeadm init --config=kubeadm-config.yaml

Configurar o kubectl para Acessar o Cluster:

Após a inicialização, execute os comandos para configurar o kubectl:

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

Passo 2: Configuração dos Nós de Trabalho para Suporte Dual-Stack

Cada nó de trabalho precisa ser configurado para suportar tanto IPv4 quanto IPv6, especificando ambos os IPs no arquivo kubeadm-config.yaml.

Exemplo de Configuração para k-node-01

Configurar o kubeadm-config.yaml para o Nó de Trabalho:

        
      
# Arquivo kubeadm-config.yaml para k-node-01
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 192.168.200.50:6443
    token: "cv5m0b.aehl2kux0tai4mga"
    caCertHashes:
    - "sha256:9ac25b5e2fffee49faaa4288316fbf208454574c3ab411a9bfaf9afb71a2ab3d"
nodeRegistration:
  kubeletExtraArgs:
    node-ip: 192.168.200.100,fd00::100

Conectar o Nó ao Cluster:

        
      
sudo kubeadm join --config=kubeadm-config.yaml

Exemplo de Configuração para k-node-02

Repita o processo de configuração e edição do kubeadm-config.yaml para cada nó, substituindo os IPs conforme necessário.

        
      
# Arquivo kubeadm-config.yaml para k-node-02
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 192.168.200.50:6443
    token: "cv5m0b.aehl2kux0tai4mga"
    caCertHashes:
    - "sha256:9ac25b5e2fffee49faaa4288316fbf208454574c3ab411a9bfaf9afb71a2ab3d"
nodeRegistration:
  kubeletExtraArgs:
    node-ip: 192.168.200.101,fd00::101

Para conectar o nó:

        
      
sudo kubeadm join --config=kubeadm-config.yaml

Passo 3: Configurar o Calico para Suporte IPv6 Dual-Stack

O Calico permite configurar sub-redes IPv4 e IPv6, possibilitando a comunicação em redes dual-stack.

Criar o Arquivo custom-resources.yaml para Configuração do Calico:

Este arquivo define as sub-redes dual-stack para pods e serviços:

        
      
---
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  # Configuração da rede Calico.
  calicoNetwork:
    ipPools:
    - blockSize: 26
      cidr: 10.244.0.0/14
      encapsulation: VXLANCrossSubnet
      natOutgoing: Enabled
      nodeSelector: all()
    - blockSize: 122
      cidr: fd02::/48
      encapsulation: None
      natOutgoing: Enabled
      nodeSelector: all()
---
apiVersion: operator.tigera.io/v1
kind: APIServer
metadata:
  name: default
spec: {}

Aplicar a Configuração do Calico:

kubectl apply -f custom-resources.yaml

Passo 4: Verificar a Configuração Dual-Stack

Verificar a Configuração dos Pods e dos Serviços:

Para verificar se o cluster está usando dual-stack, crie um pod de teste e um serviço exposto com IPs IPv4 e IPv6.

        
      
# Arquivo dual-stack-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dual-stack-test
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: dual-stack-service
spec:
  selector:
    app: nginx
  ipFamilies:
    - IPv4
    - IPv6
  ipFamilyPolicy: RequireDualStack
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Aplique o arquivo de configuração:

kubectl apply -f dual-stack-test.yaml

Verificar IPs do Serviço Dual-Stack:

Use o comando kubectl get svc dual-stack-service para verificar os IPs atribuídos ao serviço:
1 kubectl get svc dual-stack-service -o wide
Esse comando deve retornar endereços IPv4 e IPv6, confirmando a configuração dual-stack.

Resumo

Nesta seção, configuramos suporte a IPv6 e redes dual-stack em um cluster Kubernetes usando o kubeadm e o Calico como plugin de rede CNI. A configuração dual-stack permite comunicação IPv4 e IPv6, aumentando a flexibilidade e a compatibilidade do cluster com infraestruturas modernas de rede.

Configuração de Rede Dual-Stack IPv6 com Cilium em Kubernetes

Objetivo:
Configurar uma rede dual-stack (IPv4 e IPv6) em Kubernetes utilizando o plugin Cilium, que oferece suporte avançado para políticas de segurança e observabilidade aprimorada com eBPF. Cilium se destaca em redes de alto desempenho, proporcionando baixa latência e monitoramento detalhado do tráfego.

Por Que Usar o Cilium?

O Cilium utiliza eBPF (Extended Berkeley Packet Filter) para manipulação de pacotes diretamente no kernel Linux, o que oferece:

Alto desempenho: eBPF permite filtragem e roteamento de pacotes com latência mínima e maior eficiência.
Observabilidade avançada: com Cilium, é possível monitorar o tráfego em tempo real e inspecionar fluxos detalhados usando o Hubble, sua ferramenta de visualização e observabilidade.
Suporte robusto para IPv6 e dual-stack: Cilium permite configurar redes com suporte simultâneo a IPv4 e IPv6, ideal para ambientes de produção modernos.

Pré-requisitos

Cluster Kubernetes com kubeadm configurado para dual-stack.
Kernel Linux que suporte eBPF (preferencialmente Linux 4.9 ou superior).
CLI do Kubernetes (kubectl) configurado para acessar o cluster.

Passo 1: Configurar o Cluster para Suporte Dual-Stack

Antes de instalar o Cilium, vamos configurar o cluster Kubernetes para dual-stack usando o kubeadm.

Criar o Arquivo de Configuração do kubeadm (kubeadm-config.yaml):

        
      
# Arquivo kubeadm-config.yaml para inicialização do cluster com dual-stack
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: 10.244.0.0/14,fd02::/48
  serviceSubnet: 10.96.0.0/16,fd04::/112
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "192.168.200.50"
  bindPort: 6443
nodeRegistration:
  kubeletExtraArgs:
    node-ip: 192.168.200.50,fd00::50

Inicializar o Cluster com o kubeadm:

        
      
sudo kubeadm init --config=kubeadm-config.yaml

Configurar o kubectl para Acessar o Cluster:

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

Passo 2: Instalar o Cilium com Suporte Dual-Stack

Baixar o CLI do Cilium

Baixe o Cilium CLI, que simplifica o processo de instalação e configuração:

        
      
curl -L --remote-name https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin/

Instalar o Cilium com Configuração Dual-Stack

Execute o comando de instalação do Cilium com suporte a dual-stack IPv4/IPv6:
1 cilium install --config enable-ipv4=true --config enable-ipv6=true
- Parâmetros importantes:
  - enable-ipv4=true: habilita suporte a IPv4.
  - enable-ipv6=true: habilita suporte a IPv6.
- Nota: Cilium detectará automaticamente as sub-redes configuradas no cluster.
Verificar a Instalação do Cilium

Confirme se todos os componentes do Cilium foram instalados corretamente:
1 cilium status

Passo 3: Configuração de Políticas de Segurança com Cilium

Uma das vantagens do Cilium é o suporte avançado a políticas de segurança, permitindo o controle detalhado de tráfego entre pods. A seguir, um exemplo de política que permite tráfego entre pods de um mesmo namespace.

Exemplo de Política de Segurança

Criar o Arquivo de Política de Segurança cilium-policy.yaml:

        
      
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-same-namespace
spec:
  endpointSelector:
    matchLabels:
      app: nginx
  ingress:
    - fromEndpoints:
        - matchLabels:
            namespace: default

Aplicar a Política de Segurança:
1 kubectl apply -f cilium-policy.yaml

Essa política permite o tráfego apenas entre pods que estão no namespace default e possuem o rótulo app: nginx.

Passo 4: Observabilidade com Hubble

Cilium inclui o Hubble, uma ferramenta de monitoramento e observabilidade para rastreamento em tempo real do tráfego de rede.

Habilitar o Hubble:
1 cilium hubble enable
Verificar o Status do Hubble:
1 cilium hubble status

Instalar o CLI do Hubble para Visualização de Logs

Baixe o CLI do Hubble:

        
      
curl -L --remote-name https://github.com/cilium/hubble/releases/latest/download/hubble-linux-amd64.tar.gz
tar xzvf hubble-linux-amd64.tar.gz
sudo mv hubble /usr/local/bin/

Visualizar o Tráfego com Hubble

Com o Hubble, você pode visualizar logs detalhados de tráfego em tempo real:
1 hubble observe
Esse comando exibirá o tráfego de rede entre os pods, incluindo informações de origem, destino, protocolo e status de conexão.

Passo 5: Verificação de Conectividade Dual-Stack

Para garantir que a configuração dual-stack está funcionando, crie um pod de teste e um serviço dual-stack.

Criar Pod e Serviço Dual-Stack

Arquivo dual-stack-test.yaml:

        
      
apiVersion: v1
kind: Pod
metadata:
  name: dual-stack-test
  labels:
    app: dual-stack-test
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: dual-stack-service
spec:
  selector:
    app: dual-stack-test
  ipFamilies:
    - IPv4
    - IPv6
  ipFamilyPolicy: RequireDualStack
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Aplicar o Pod e o Serviço:

kubectl apply -f dual-stack-test.yaml

Verificar os IPs do Serviço Dual-Stack

Use o comando abaixo para verificar os endereços IPv4 e IPv6 atribuídos ao serviço:
1 kubectl get svc dual-stack-service -o wide

Resumo

Nesta seção, configuramos o Cilium para habilitar uma rede dual-stack com suporte IPv4/IPv6 no Kubernetes. Cilium fornece recursos de alta performance com eBPF, além de observabilidade avançada com o Hubble, o que torna o Cilium uma excelente escolha para ambientes de produção que exigem desempenho e visibilidade detalhada do tráfego de rede.

Conclusão

A configuração e gerenciamento de clusters Kubernetes com Containerd e CRI-O oferecem grandes vantagens em ambientes de produção, garantindo estabilidade e integração nativa com a infraestrutura Kubernetes. Neste tutorial, percorremos desde a configuração inicial até práticas avançadas de otimização e segurança, incluindo monitoramento detalhado com o Cilium e o Hubble. A escolha entre plugins de rede, como Calico e Cilium, fornece um leque de possibilidades para ambientes que exigem escalabilidade e controle de tráfego entre containers.

Ao seguir este guia, você estará equipado para implementar um ambiente Kubernetes robusto, seguro e altamente escalável. Com o uso de técnicas avançadas de observabilidade, políticas de segurança detalhadas e uma configuração sólida de rede dual-stack, o cluster estará preparado para atender às demandas das aplicações modernas. Lembre-se de seguir as práticas recomendadas e de revisar regularmente as configurações de segurança e recursos para garantir a continuidade e eficiência do cluster. Aproveite as possibilidades que Kubernetes com Containerd e CRI-O oferecem e boa implementação!

Kubernetes, Containerd, CRI-O

Kubernetes Containerd CRI-O

This post is licensed under CC BY 4.0 by the author.

Introdução

Sumário

1. Introdução ao Kubernetes e Runtimes de Containers

1.1 O que é Kubernetes?

1.2 Runtimes de Containers: Conceito e Importância

1.3 Diferença entre Docker, Containerd e CRI-O

1.4 Por que Containerd e CRI-O são Mais Recomendados para Kubernetes?

2. Configuração do Ambiente: Instalação do Kubernetes, Containerd e CRI-O

2.1 Instalação do Kubernetes em Distribuições Linux Debian 12

Passo 1: Configurar Dependências do Kubernetes

Passo 2: Instalar o Kubernetes (kubeadm, kubelet, kubectl)

2.2 Instalação e Configuração do Containerd

Passo 1: Instalar o Containerd

2.3 Instalação e Configuração do CRI-O

Passo 1: Configurar o Repositório CRI-O

2.4 Configuração para Comunicação do Kubernetes com os Runtimes

Passo 1: Configurar o kubelet para Usar Containerd ou CRI-O

Verificar a Conexão entre Kubernetes e o Runtime

Resumo da Seção

3. Integração do Kubernetes com Containerd

3.1 Configuração do Containerd como Runtime Padrão no Kubernetes

Passo 1: Configurar o config.toml do Containerd

3.2 Configuração do Kubelet para Usar o Containerd

Passo 1: Editar a Configuração do kubelet

Passo 2: Verificar a Integração entre Kubernetes e Containerd

3.3 Exemplo Prático: Iniciar um Nó Kubernetes com Containerd

Passo 1: Iniciar um Cluster com kubeadm

3.4 Checklist para Verificação da Integração

Resumo da Seção

4. Integração do Kubernetes com CRI-O

4.1 Configuração do CRI-O como Runtime Padrão no Kubernetes

Passo 1: Ajustar a Configuração do kubelet para Usar o CRI-O

Passo 2: Verificar o Funcionamento do CRI-O com Kubernetes

4.2 Exemplo Prático: Inicialização de um Nó Kubernetes com CRI-O

Passo 1: Inicializar o Cluster com kubeadm

Passo 2: Configurar o kubectl para o Usuário Local

Passo 3: Aplicar um Plugin de Rede CNI (Exemplo com Flannel)

4.3 Checklist para Verificação da Integração com CRI-O

Resumo da Seção

5. Configuração do Kubelet para Uso de Múltiplos Runtimes

5.1 Por que Usar Múltiplos Runtimes no Kubernetes?

5.2 Configuração do Kubelet para Suporte a Múltiplos Runtimes

Passo 1: Editar o Arquivo de Configuração do kubelet

5.3 Exemplo Prático de Alteração Dinâmica entre Containerd e CRI-O

Passo 1: Configurar o Kubelet para Usar o Containerd

Passo 2: Alterar o Kubelet para Usar o CRI-O

5.4 Checklist para Alternar Entre Containerd e CRI-O

Resumo da Seção

6. Criação e Gerenciamento de Pods e Deployments com Kubernetes

6.1 Criação de Pods com Kubernetes e Verificação do Runtime

Passo 1: Criação de um Pod com o Kubernetes

6.2 Criação de Deployments no Kubernetes

Passo 1: Criar um Deployment com Kubernetes

Passo 2: Escalonar o Deployment

Passo 3: Atualizar o Deployment

6.3 Verificação de Logs e Status dos Pods e Deployments

Passo 1: Verificar Logs de um Pod

Passo 2: Descrever um Pod ou Deployment

6.4 Exemplo Prático: Verificando o Runtime e Gerenciando Pods com Containerd/CRI-O

Resumo da Seção

7. Monitoramento e Logs com Containerd e CRI-O

7.1 Ferramenta crictl para Inspeção e Monitoramento de Containers

Instalação do crictl

7.2 Monitoramento de Containers com crictl

Listar Containers em Execução

Inspecionar Detalhes de um Container

Ver Logs de um Container

Parar e Remover Containers

7.3 Logs do Runtime de Container no Kubernetes

Configuração de Logs no Containerd

Configuração de Logs no CRI-O

7.4 Exemplos Práticos de Monitoramento e Troubleshooting com crictl

Resumo da Seção

8. Segurança em Kubernetes com Containerd e CRI-O

8.1 Configuração de Políticas de Segurança para Execução de Containers

Alternativa Atual: Políticas de Segurança com Admission Controllers

8.2 Uso de SELinux e AppArmor para Proteção de Containers

Configuração de SELinux

Configuração de AppArmor

8.3 Configuração de SecurityContext no Kubernetes

Passo 1: Configurar o `kubelet` para Usar Containerd ou CRI-O

Passo 1: Configurar o `config.toml` do Containerd

Passo 1: Editar a Configuração do `kubelet`

Passo 1: Iniciar um Cluster com `kubeadm`

Passo 1: Ajustar a Configuração do `kubelet` para Usar o CRI-O

Passo 1: Inicializar o Cluster com `kubeadm`

Passo 2: Configurar o `kubectl` para o Usuário Local

Passo 1: Editar o Arquivo de Configuração do `kubelet`

7.1 Ferramenta `crictl` para Inspeção e Monitoramento de Containers

Instalação do `crictl`

7.2 Monitoramento de Containers com `crictl`

7.4 Exemplos Práticos de Monitoramento e Troubleshooting com `crictl`

Passo 1: Configurar o Arquivo `kubeadm-config.yaml` para IPv6 e Dual-Stack