Programação · DevOps · orquestração

O que é o Kubernetes?

Uma vez empacotada uma app num contentor, surge um novo problema: quem o arranca, o reinicia quando ele falha, lança mais cópias sob carga, e os liga a todos – em dezenas de máquinas? É a orquestração, e o Kubernetes é o sistema que a maioria das equipas usa para isso. Este guia explica o que é o Kubernetes, os conceitos que importam, a sua ligação ao Docker e quando precisa realmente dele.

A definição curta

O Kubernetes é uma plataforma open source para executar e coordenar contentores num grupo de máquinas. Descreve o estado desejado – «arranca cinco cópias desta app, mantém-nas saudáveis, expõe-nas neste endereço» – e o Kubernetes trabalha continuamente para que a realidade corresponda: coloca os contentores nas máquinas, reinicia os que falham, ajusta a escala e encaminha o tráfego para eles. Abrevia-se muitas vezes para K8s (K, oito letras, s).

O problema que resolve

Arrancar um contentor à mão é simples. Arrancar centenas, de forma fiável, não é. As máquinas caem, o tráfego explode, é preciso implementar novas versões sem interrupção, e os contentores têm de se encontrar e falar entre si. Fazer tudo manualmente é fonte de erros e nunca dorme. O Kubernetes torna-o num sistema declarativo: descreve o que quer, e o ciclo de controlo da plataforma aplica-o sem cessar – substituindo um contentor que falhou ou replaneando o trabalho para fora de uma máquina morta, sem acordar um engenheiro às 3 da manhã.

Os conceitos-chave

• Cluster – o sistema inteiro: um grupo de máquinas que o Kubernetes gere como um todo. Tem um plano de controlo (o cérebro que decide) e nós de trabalho (onde os seus contentores correm de facto).
• Nó – uma única máquina (física ou virtual) do cluster que executa contentores.
• Pod – a mais pequena unidade que o Kubernetes executa: um ou mais contentores estreitamente ligados que partilham um armazenamento e um endereço de rede. Executam-se em geral muitos pods idênticos de uma app.
• Deployment – uma declaração do estado desejado para os seus pods: que imagem, quantas réplicas, e como implementar as atualizações. O Kubernetes alinha o estado real com ele.
• Service – um endereço de rede estável e um balanceador de carga para um conjunto de pods, para que as outras partes do sistema os alcancem mesmo quando os pods individuais vão e vêm.

Como funciona, em resumo

Submete uma descrição do que quer – muitas vezes um ficheiro YAML que define um deployment e um service. O plano de controlo regista esse estado desejado e planeia os pods em nós que tenham espaço. Um ciclo de controlo compara depois continuamente o estado desejado e o estado real: se um pod morre ou um nó falha, o Kubernetes repara e recria noutro lado os pods em falta. A escala segue a mesma ideia – passe de «5 réplicas» para «20» e o escalonador colmata a diferença. Este modelo declarativo e auto-reparador está no cerne da confiança depositada no Kubernetes em produção.

Kubernetes vs Docker

São complementares, não rivais. O Docker constrói e executa um contentor individual numa máquina. O Kubernetes orquestra muitos contentores em muitas máquinas – planeia-os, escala-os, repara-os e liga-os em rede. O Docker empacota e executa um contentor; o Kubernetes gere uma frota. O Kubernetes executa contentores construídos segundo os padrões abertos que o Docker popularizou: ambos ocupam camadas diferentes da mesma pilha em vez de concorrerem.

Precisa realmente dele?

Honestamente, muitas vezes não – pelo menos ainda não. O Kubernetes brilha quando executa muitos serviços, precisa de alta disponibilidade e dispõe da equipa para o operar. Para uma única app ou um pequeno projeto, é geralmente excessivo: um servidor único, um serviço de contentores gerido ou uma platform-as-a-service será mais simples e mais barato. O custo do Kubernetes é uma verdadeira complexidade – rede, armazenamento, segurança e atualizações exigem competência. Adote-o quando a escala justificar o sobrecusto, não por moda.

Gerido vs auto-alojado

Pode executar o Kubernetes você mesmo, mas a maioria das equipas usa um serviço gerido em que um fornecedor cloud opera o plano de controlo por si, de modo que só gere as suas cargas de trabalho. Isto retira grande parte do fardo operacional e constitui a escolha por defeito razoável para a maioria dos projetos que precisam realmente de orquestração.

Os contentores expõem em geral uma API e falam entre si por protocolos como gRPC ou REST. Explore outras explicações claras no nosso índice de guias.

Perguntas frequentes