Kubernetes: o que tem de tão especial

Kubernetes: o que tem de tão especial? O k8s é, sem sombra de dúvidas, uma ferramenta fantástica e que, de algum modo, está também sobre os ombros de gigantes. Quando se trabalha apenas com containers, seja com docker, podman ou qualquer outro runtime, é fundamental ter em mente o conceito de que ele é feito para ser efêmero.

Em outras palavras, ele é feito para morrer a qualquer momento. Isto posto, é fundamental ter estratégias inteligentes para lidar com estruturas na memória do container, com o storage ou mesmo com a comunicação de rede, de modo que se outro container subir com as mesmas características tudo voltará a funcionar normalmente.

Entretanto quando estamos falando de aplicações mais complexas e que exigem alta escala e disponibilidade há a necessidade de se construir muitos fragmentos em micro-serviços. Por isso possuem uma dinâmica efêmera mais sofisticada: podendo ter diversos estruturas iguais para processar as demandas, denominadas workers.

Estado desejado

Antes de mais nada há outro conceito importante: o estado desejado. Por exemplo: uma aplicação pode estar estruturada para lidar com grande quantidade de requisições por segundo. Por isso, após muitos testes pode-se chegar a conclusão de que são necessários 20 workers para equilibrar a carga. Assim, se containeres morrerem o kubernetes se encarrega de colocar mais para garantir 20 workers atuando.

Por outro lado, se a aplicação possuir uma inteligência para medir o consumo e dinamicamente crescer e diminuir a quantidade de força de trabalho, o kubernetes se encarregará de adequar a quantidade, seja criando ou destruíndo workers. Desse modo há um ideal de quantidade de trabalho: esse conceito é chamado de estado desejado.

A princípio o Kubernetes tem como missão garantir a melhor entrega do estado desejado de uma aplicação. Por isso os nós do cluster possuem um conjunto de estratégias para se comunicarem sobre o estado atual. Assim o k8s se encarregará de prover o estado desejado ou o melhor que ele puder considerando todas as restrições que podem haver.

Em suma, esse artigo se empenhará em explicar todos os elementos da arquitetura do kubernetes que ajudará a entender o que há de especial no kubernetes e como ele operacionaliza o modelo de estado atual / estado desejado.

Os princípios do Kubernetes

Segurança: O Kubernetes é estruturado para ser seguro em sua essência.

Facilidade de uso: Poucos comandos são suficientes para sua operação.

Extensibilidade: O k8s favorece fornecedores, é altamente personalizável e configurável.

Visão geral dos componentes da arquitetura do kubernetes

Esse diagrama acima é amplamente utilizado para representar todo o conjunto de componentes macro do kubernetes e suas interrelações. Em resumo há dois grandes componentes: control plane e compute machine (ou workers).

Control Plane

O Control plane é a estrutura central do cluster responsável por todo o seu gerenciamento. Os nodos desse tipo observam o estado atual das aplicações, os recursos disponíveis e demais restrições do ambiente. A partir dessa observação ele toma ações na tentativa de garantir que o estado desejado ocorra nos nodes.

Kube-apiserver

Por outro lado, o kube-api-server oferece meios para a interação com o kubernetes através de APIs REST. Desse modo dá-se o acesso aos métodos do cluster através da API, seja diretamente por requisições HTTPS, seja pela linha de comando do kubeadm ou do kubectl. Além disso, ele é estruturado para suportar o permissionamento baseado em RBAC e é extensível por meio de CRD (Custom Resource Definitions).

Kube-scheduler

Já esse componente é o responsável por agendar a alocação dos workloads nos workers. Ele analisa dados dos nodes (quantidade de memória, cpu, afinidades) e as restrições (há memória disponível no node para executar o workload?), afinidades relacionadas, pod disruption budgets e outras características. A partir dessa análise ele agenda a execução desses workloads, além de avaliar continuamente a integridade do cluster.

Kube-controller-manager

O kubernetes possui alguns controladores responsáveis por executar ações exclusivas e fundamentais para o cluster. O Controller manager é o responsável por gerenciar todos os controlers de maneira unificada. Exemplos de Controllers:

• Analise do estado desejado
• Conector de pods aos endpoints corretos
• Conector do cluster a volumes e discos
• Gerenciador de tokens de acesso a APIs

Etcd

O Etcd é um Banco de dados do tipo chave-valor utilizado para armazenar dados sobre o cluster como labels, nomes, estado dos componentes, etc. O etcd é distribuído e feito para ser tolerante a falhas. Ele é a principal fonte de informação do cluster.

Compute Machine ou workers

Os workers ou compute machines são nodos responsável por executar, efetivamente, os diferentes workloads do kubernetes (pod, replicaset, deployment, deamonset, job e cronjob). Um componente do worker, o kubelet, conversa com o control-plane e recebe solicitações para a execução do que for solicitado através do container runtime instalado nele.

Node

Ele é um grande bloco responsável pela execução de workloads. Ao mesmo tempo cada compute machine é, na prática, um node. Assim o Kube-scheduller faz o agendamento de workloads para serem executados em um node específico. Por fim é responsabilidade do node, juntamente com o container runtime, efetivamente executarem os workloads solicitados.

Pod / Workload

Ele é o nível mais micro da representação dos objetos do kubernetes do ponto de vista de topologia. Ainda existe o container, que fica dentro do cluster, mas não possui o nível de gestão do pod, por isso não é considerado o nível mais micro. O Pod representa uma instância de uma aplicação. Há outros workloads mas o pod é o mais fundamental de todos (pod, replicaset, deployment, deamonset, job e cronjob)

Container runtime

Ele é o responsável por interpretar o arquivo de imagem do container e transportá-lo para a memória bem como garantir o isolamento com os demais processos do sistema operacional. O mais conhecido do mercado é o Docker, mas ele não é compliant com a OCI (Open Container Iniciative) e a k8s não o recomenda, mas pode funcionar. Outros container runtimes conhecidos são: containerg, cri-o, rkt. Esse componente é um dos mais importantes e o que faz o Kubernetes ser tão especial.

Kubelet

O kubelet é o responsável pela conversa interna entre o control-plane e o worker. O kubelet fala para o control-plane qual é o estado de node e dos workloads que estão nele. Assim o Control-plane saberá qual é a melhor alocação. Por outro lado o kubelet recebe comunicação do control-plane indicando que o worker deve alocar certa computação para executar algum workload específico. Ele expõe a porta 10255 do node.

Kube-proxy

Essa é um camada de proteção de rede do kubernetes. Ela viabiliza a comunicação interna do cluster (ClusterIP e NodeIP) e comunicação externa do cluster (LoadBalancer), funcionando como um DNS interno. Comandos como port-forward, por exemplo, utilizam esse componente. O kube-proxy é quem pode expor as APIs do kubernetes para acesso por fora do cluster.

Armazenamento

Há uma complexidade importante quando o assunto são os dados no ambiente do kubernetes. Entenda que um conjunto de workloads pode executar uma mesma aplicação que trabalha com um mesmo dado. Isso implica que o volume associado a ele esteja organizado e estruturado para suportar tais acessos simultaneos de escrita e leitura.

Portanto há uma estrutura que faz gestão dos volumes e estruturas referentes a dados das aplicações, podendo ou não ter integração direta com algum provedor de nuvem, realmente fazendo do kubernetes algo tão especial.

Persistent Volume

Componente para gerenciamento de discos e locais de armazenamento de dados persistentes (volumes anexados, fora do pod). Aplicações podem exigir volumes sem ter necessidade de conhecer a infraestrutura subjacente. Além disso ele pode lidar com estruturas locais ou em nuvem.

Container Registry

Componente que armazena e controla as imagens dos container utilizados na infraestrutura do kubernetes.

Infraestrutura subjacente

Ambiente onde o kubernetes está instalado. A infraestrutura pode ser on-premisse, hibrida ou na nuvem. É muito comum a utilização de infraestrutura gerenciada em núvem para clusters kubernetes, como por exemplo AKS (Azure), GKE (Google) ou EKS (Amazon).

Conclusão: Kubernetes é especial mesmo?

Kubernetes: o que tem de tão especial? Essa ferramenta possui uma embricada reelação entre componentes para suportar nívels muito altos de escala e resiliência, mas a ferramenta não faz mágica. Um bom profissional por tras da manutenção do produto é absolutamente fundamental para o seu uso bem sucedido.