Cluster API, Imutabilidade e o Futuro da Infraestrutura Kubernetes

Desde o anúncio de lançamento do Cluster API 1.12 [1], continuo recebendo perguntas sobre imutabilidade no Kubernetes. Em meio a essa nova onda de interesse, o que se destaca é como a comunidade Kubernetes está abordando este tópico de uma perspectiva diferente do passado. Hoje, os adotantes estão menos focados na imutabilidade no nível de nó individual e mais interessados em como os princípios imutáveis se aplicam ao operar uma frota inteira de clusters. Esta é a razão fundamental pela qual o projeto Cluster API existe, e neste blog gostaria de compartilhar minha perspectiva como mantenedor do Cluster API.

Por que a imutabilidade é importante

A importância da imutabilidade deriva dos benefícios que essa abordagem oferece às aplicações que rodam sobre o Kubernetes. Com base na minha experiência, os benefícios mais importantes que os adotantes do Kubernetes obtêm da imutabilidade são os seguintes:

Velocidade

Na TI moderna, a velocidade é primordial. Por exemplo, você precisa de velocidade ao escalar sua infraestrutura para lidar com picos de requisições de usuários; você precisa de velocidade ao realizar implantações blue/green ou ao reduzir a infraestrutura para manter os custos da aplicação sob controle ou liberar recursos para outras tarefas. A velocidade também é crucial ao lidar com operações de manutenção que devem se encaixar em uma janela de tempo limitada, ou ao lidar com qualquer tipo de interrupção dentro do amplo espectro que vai desde problemas em uma única instância de aplicação até quando você está lidando com uma região inteira fora do ar.

A imutabilidade é um facilitador fundamental para alcançar velocidade em todos os cenários acima e ainda mais. É graças à imutabilidade que você pode ter ferramentas para iniciar dez Pods idênticos em milissegundos, ferramentas para criar novos clones de Machines que hospedam nós Kubernetes em segundos, ou para iniciar um novo cluster Kubernetes totalmente operacional em minutos.

Operações em escala

De certo ponto de vista, as operações de TI hoje se situam na interseção entre escala e velocidade. A imutabilidade é crucial para lidar com esses tipos de problemas, porque a imutabilidade fornece a base para criar clones consistentes e confiáveis de seus pods, de suas VMs, de seu cluster Kubernetes inteiro. Quando você começa a usar esses tipos de clones confiáveis, você ganha a confiança de que seus ambientes de desenvolvimento, QA e produção se comportam de forma consistente. Sem clones confiáveis, sua equipe de operações terá que lidar com o configuration drift, e "snowflakes" (instâncias únicas e não padronizadas) não escalam bem.

Segurança

A imutabilidade também é frequentemente ligada à segurança. Embora isso seja geralmente verdade, com base na minha experiência pessoal, há algumas vantagens distintivas que a imutabilidade oferece do ponto de vista da segurança. Mas para outros aspectos da segurança, também existem alternativas válidas que uma organização pode e deve considerar.

Como exemplo de uma vantagem distintiva, a imutabilidade fornece a base para a construção de sistemas onde as VMs subjacentes são efêmeras porque são periodicamente recriadas do zero, proporcionando assim um "alvo móvel" que torna o trabalho dos atacantes muito mais complexo. Por outro lado, por exemplo, um OS imutável pode ser usado com sucesso para reduzir a superfície de ataque dentro de uma VM, mas muitas organizações estão alcançando o mesmo objetivo usando AppArmor, SELinux, imagens hardened, etc.

Continuando com o mesmo exemplo, o processo de atualização A/B que é típico de um OS imutável também pode ter uma alternativa válida e possivelmente mais robusta quando você considera implantar mudanças criando novas máquinas e excluindo as antigas. Mesmo resultado, mas reutilizando primitivas simples de criação e exclusão como o Kubernetes faz para Pods.

Estabilidade

Como engenheiro de software e mantenedor de código aberto, estou sempre lidando com o fato de que há uma quantidade limitada de complexidade que um projeto ou sistema pode absorver em um determinado período de tempo. Quando o orçamento de complexidade se esgota, coisas ruins acontecem. A qualidade diminui e não conseguimos corrigir bugs e CVEs em tempo hábil. A imutabilidade ajuda muito a lidar com o orçamento de complexidade. Ela permite que os engenheiros reduzam drasticamente o número de variáveis a serem consideradas, por exemplo, ao gerenciar o ciclo de vida de objetos como uma VM que hospeda um Node Kubernetes. Como resultado, sistemas baseados em imutabilidade geralmente fornecem uma plataforma mais simples, mais estável e confiável para sua aplicação. E estabilidade e confiabilidade importam hoje, assim como para a sustentabilidade a longo prazo de sua stack de aplicações.

Como alcançar a imutabilidade no Kubernetes

A imutabilidade em sua essência é um conceito, uma filosofia. Para torná-la real, você precisa de tecnologias que abracem esse conceito. O Kubernetes é um ótimo ponto de partida: ele fornece primitivas como Pods imutáveis e abstrações de nível superior como Deployments, StatefulSet, etc., para gerenciar esses Pods. Mas o Kubernetes não cuida da infraestrutura subjacente. É aqui que o Cluster API se encaixa, porque um dos princípios fundamentais do projeto é "é Kubernetes até o fim" (it's Kubernetes all the way down).

O Cluster API torna possível tratar uma Machine, uma peça de infraestrutura como uma VM que hospeda um nó Kubernetes, como um componente imutável. Quando uma mudança é necessária, em vez de modificar a Machine no local, o Cluster API cria uma nova máquina e exclui a antiga, de forma semelhante a como o Kubernetes substitui Pods. E ao oferecer abstrações para gerenciar grupos de Machines, como KubeadmControlPlane e MachineDeployment, você pode usar o Cluster API para ampliar os benefícios da imutabilidade ao gerenciar um cluster inteiro ou uma frota de Clusters.

Se você tem um conhecimento profundo do Cluster API, a essa altura você pode objetar que existe uma área cinzenta, que é o OS hospedado na máquina gerenciada pelo CAPI. O Cluster API não tem uma opinião forte sobre o OS hospedado na máquina, porque, com base no que aprendemos nos últimos anos, é aqui que diferentes organizações e produtos podem e devem adotar abordagens diferentes. Em primeiro lugar, cada organização tem opiniões diferentes sobre qual OS usar e quais trade-offs são aceitáveis no nível do OS. Em segundo lugar, muitas organizações não querem implementar tratamento especial para o OS das Machines em um cluster Kubernetes, elas preferem ter apenas um sistema operacional suportado e usá-lo em diferentes plataformas e tipos de aplicações, e na maioria dos casos este não é um OS imutável.

A chave para lidar com esses diferentes requisitos e tecnologias são os muitos pontos de extensibilidade do Cluster API. Usando esses pontos de extensibilidade, agora é possível realizar um conjunto cuidadosamente validado de operações de atualização in-place de forma segura e totalmente automatizada. Se você estiver interessado em um aprofundamento neste tópico, também o discutiremos na sessão "In-place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure" [2] na KubeCon EU em Amsterdã!

Alguns exemplos

Rolling upgrades

Em vez de realizar procedimentos complexos para atualizar Machines existentes, o Cluster API passa por um rollout onde novas Machines "pristine" (intocadas) são criadas para substituir as antigas. Essa abordagem, derivada dos princípios de imutabilidade, não apenas permite que você realize upgrades do Kubernetes, mas também permite que você realize qualquer tipo de mudança nas Machines (infraestrutura, OS e componentes do Kubernetes) suportando duas primitivas simples: criar e excluir Machine. O processo é inerentemente repetível e previsível; substituir cada Machine garante que cada nó atinja o estado desejado sem as surpresas frequentemente causadas pelo configuration drift. É simples, robusto, rápido e seguro. Além disso, o Cluster API garante que seus critérios de disponibilidade sejam sempre atendidos durante um rollout. Ele também suporta upgrades encadeados e do Kubernetes abrangendo múltiplos minors do Kubernetes, e os nós de worker podem pular upgrades para releases intermediárias do Kubernetes sempre que permitido pelas políticas de version skew do Kubernetes.

Remediação de Machines não saudáveis

Como você pode lidar com máquinas que falham consistentemente, por exemplo, quando o Node Kubernetes hospedado na Machine reporta a condição Ready como false por mais de cinco minutos? O Cluster API permite que você defina MachineHealthChecks para lidar com esses casos, e quando a remediação automática entra em ação, o sistema aproveita a imutabilidade para resolver o problema de forma rápida e eficiente: Uma nova Machine de substituição "pristine" é rapidamente criada e a antiga é excluída — novamente, utilizando as mesmas duas primitivas simples: criar e excluir Machine.

Evitando rollouts desnecessários

Machines são componentes complexos, e às vezes você quer fazer mudanças que não exigem um node drain ou reinício de pod; por exemplo, mudar o certificado do image registry. Se por algum motivo você quiser realizar esses tipos de mudanças sem um rollout completo da Machine, o Cluster API oferece pontos de extensibilidade para tornar isso possível, permitindo um conjunto cuidadosamente validado de operações de atualização in-place de forma segura e totalmente automatizada. Mesmo nesses casos, o configuration drift é evitado aplicando a mesma mudança consistentemente em todas as Machines. A mesma experiência de usuário (UX), imutabilidade e o melhor da mutabilidade, tudo sob estrito controle.

Conclusão

A imutabilidade impulsiona muitos sistemas cloud-native, porque permite velocidade, escala operacional e práticas de segurança mais robustas. Ao mesmo tempo, combinar infraestrutura imutável com operações mutáveis cuidadosamente controladas permite que as organizações aproveitem outras abordagens operacionais bem conhecidas quando apropriado. Este é o "sweet spot" entre infraestrutura imutável e mutável que permite às equipes alcançar velocidade, segurança e confiabilidade ao operar Kubernetes em escala.

Referências [1] Cluster API 1.12 [2] KubeCon Session

Descubra mais do VMware Cloud Foundation (VCF) Blog Assine para receber as últimas postagens por e-mail. Digite seu e-mail… Assinar