O Kubernetes começou como um orquestrador de contêineres, aproveitando a popularidade rapidamente adquirida do Docker, a ferramenta de conteinerização responsável por tornar tudo mais fácil e por esse motivo muito popular, para construir, executar e distribuir contêineres.

Outros projetos semelhantes de orquestração de código aberto começaram na mesma época em que o Kubernetes, sendo o Cloud Foundry e o Mesos os mais destacados. Pode-se argumentar que os outros projetos tinham objetivos variados, por serem focados em assuntos diferentes, onde deveriam ser posicionados. Por exemplo, o Mesos é um agendador genérico, porém alguns profissionais acham que eles sempre foram concorrentes diretos.

O Kubernetes foi evoluindo até vencer a batalha, tornando-se não apenas um dos projetos de código aberto mais bem-sucedidos de todos os tempos, mas também a plataforma de orquestração de contêineres padrão em todo o setor.

Segundo documentação da The Linux Foundation na página kubernetes.io , o Kubernetes evoluiu precisamente para ser um “sistema para automatizar a implantação, dimensionamento e gerenciamento de aplicativos em contêineres”, sendo adotado por todos os principais fornecedores de nuvem, que também oferecem recursos e funcionalidades adicionais em suas ofertas.

O Kubernetes trabalha com o conceito de cluster, um conjunto de recursos agrupados por meio de máquinas virtuais ou máquinas físicas, também conhecidas como nós / hosts, que podem executar cargas de trabalho em contêineres. Ele permite que você gerencie esse pool de recursos ou o cluster de forma eficiente e fácil, além de definir e fornecer um mecanismo simples para implantar e gerenciar o ciclo de vida do seu aplicativo em contêiner nesse pool.

Além disso, o Kubernetes define os mecanismos de rede, armazenamento, dimensionamento, atualização e exploração dos aplicativos implantados. Por baixo de tudo, ele pode orquestrar réplicas do mesmo aplicativo em vários nós / hosts, permitindo que os mesmos nós / hosts também sejam compartilhados por aplicativos diferentes.

Indo além de um único cluster

Quando um único cluster não é suficiente? Por que alguém precisaria de vários clusters? Em 2015, no artigo Requirements Analysis and Product Proposal da Kubernetes Cluster Federation foi introduzido o conceito de um plano de controle de cluster múltiplo, também conhecido como “Ubernetes”, e foi feito um excelente trabalho ao destacar as principais razões para vários clusters. Essas razões ainda são válidas hoje. Abordaremos abaixo a maioria dos casos de uso relevantes para o Kubernetes, citados nesse documento.

Os casos de uso de Kubernetes com vários clusters

Multi-tenancy (multi-locação)

O Kubernetes oferece recursos que podem fornecer algum nível de multilocação, mas não é realmente um sistema multilocatário. Isso se deve em parte ao fato de a conteinerização não oferecer isolamento perfeito entre aplicativos localizados no mesmo espaço.

Muitos casos de uso no mundo real precisam considerar as implicações de segurança com o compartilhamento de recursos entre vários inquilinos, o que na maioria dos casos leva ao não compartilhamento dos mesmos recursos. Em vez disso, os inquilinos são particionados por nós do cluster ou são colocados em clusters completamente diferentes.

Na maioria das vezes, as grandes empresas optam por executar a última opção, ou seja, clusters diferentes para diferentes inquilinos. O mesmo é verdadeiro para sua finalidade. É bastante comum ouvir “clusters de desenvolvimento”, “clusters de teste”, “clusters de produtos” etc., não é? Pode-se argumentar que a multilocação não é uma razão para executar vários clusters, mas na prática, observamos que é uma das justificativas mais comuns pelas quais as empresas fazem isso.

Capacity overflow e cloud bursting

Cloud bursting ou ruptura de aplicação executada em nuvem é provavelmente um dos cenários de usuário multicloud mais úteis e economicamente importantes. Use os recursos mais caros de nuvem pública somente quando os recursos on-premises não forem suficientes.

De fato, esse conceito antecede o Kubernetes e muitas empresas o implementaram de sua própria maneira. Antes que os softwares PaaS ganhassem amplo uso, os softwares IaaS tinha soluções para esse conceito. Um exemplo em código aberto foi o Jacket for OpenStack. Para o Kubernetes, não existe uma solução clara de código-fonte aberto, no entanto, os fornecedores de serviços gerenciados de Kubernetes podem fornecer uma saída para se obter essa funcionalidade.

Alta disponibilidade

Um cluster único fornece tolerância razoável a falhas para contêineres simples e pode cuidar de contêineres fora de operação ou que não estão respondendo. No entanto, não pode suportar interrupções na rede, o que é bastante comum, problemas de datacenter, calamidades naturais etc. É razoavelmente comum que aplicativos estejam em vários clusters em diferentes datacenters, diferentes fornecedores e diferentes geografias com o objetivo de garantir alta disponibilidade.

Conformidade

A necessidade de estar em conformidade com as leis e políticas de segurança locais é um caso de uso comum, especialmente no setor bancário e de telecomunicações. Geralmente, um único cluster não pode estar conforme com todas as regras, de todos os lugares. Ter clusters dedicados, auditados para requisitos específicos, geralmente é a solução. As empresas também precisam garantir que os aplicativos sejam auditados, identificados quanto à conformidade e executados nos clusters rotulados e adequados.

Afinidade de localização

Embora a Internet pública seja rápida, ela ainda tem limitações físicas. Esse é o motivo pelo qual as organizações às vezes optam por hospedar aplicativos na região em que os usuários os estão usando. Clusters diferentes em diferentes geografias atendem a esse caso específico.

Evitar a dependência de um único fornecedor

Existem muitos fornecedores de nuvem no mercado e suas ofertas obviamente não são criadas da mesma forma. A maioria dos grandes usuários de nuvem não se vincula a um único fornecedor. Como os modelos e as ofertas de precificação mudam, os usuários também mudam seus modelos de uso ao longo do tempo. O Kubernetes permite que os aplicativos sejam independentes da nuvem, sendo que ter vários clusters é uma solução quando há necessidade de usar vários fornecedores ou mover aplicativos de uma nuvem para outra ao longo do tempo.

A evolução do SIG multicluster em Kubernetes

Ubernetes, Ser ou Não Ser

As discussões multicluster na comunidade Kubernetes começaram no início de 2015, na época em que o próprio Kubernetes estava em seus estágios iniciais de desenvolvimento.

Alguns membros fundadores do Kubernetes consideraram que valia a pena iniciar as discussões e garantir que as nuances do multicluster fossem incorporadas à API desde o início. Esta apresentação é uma das primeiras palestras que abordou o assunto de vários clusters e foi apresentada em um dos primeiros KubeCons (conferências dedicadas a Kubernetes e outras tecnologias nativas de nuvem).

A ideia inicial estava focada em uma solução única para todos os possíveis problemas de multicluster do Kubernetes, também conhecida como “Ubernetes”. A maioria das partes interessadas pensou que seria possível construir um mecanismo de controle semelhante ao sistema de controle do Kubernetes, que pudesse atender a todos os casos de uso multicloud em que se poderia pensar.

Isso não se mostrou possível. Os problemas relacionados se mostraram incrivelmente difíceis de resolver de forma coletiva. Além disso, nos anos seguintes, o próprio Kubernetes também se tornou um gigante, deixando claro que deveria haver esforços especiais para dividir todo esse grande conjunto em pedaços menores e complementares.

De Ubernetes para Federação

Os esforços subsequentes tiveram que reduzir os problemas multicluster que estavam se repetindo em vários estágios. Os primeiros esforços convergiram a definição de Ubernetes para “Federação”, ao aplicar o conceito de servidor de API do Kubernetes a vários clusters. Considerava clusters semelhantes a nós e o mecanismo de controle da Federação semelhante ao mecanismo de controle do Kubernetes. Isso significava usar a API de recursos Kubernetes também como APIs federadas, em um nível superior de abstração.

Essa visão veio com seus próprios desafios, principalmente porque não havia uma área clara de API para especificar e validar propriedades específicas de múltiplos clusters. Todas elas residiam em anotações de propósito geral. Um breve exemplo: essa abordagem utilizou um servidor de APIs federadas como um cliente simples para vários servidores de APIs de Kubernetes, usando a mesma API do recurso do Kubernetes.

Portanto, um usuário federado poderia criar o mesmo recurso em um servidor de APIs federadas, por exemplo, um Deployment ou um ConfigMap que ele criaria em um servidor de API Kubernetes.

Parecia promissor por sua simplicidade, pois os mesmos clientes e ferramentas de clientes poderiam funcionar no servidor de APIs federadas. Na verdade, parecia bastante elegante na época e o conceito foi aprovado até a implementação do protótipo. No entanto, não foi possível amadurecer um caminho claro para sua evolução, mantendo o mesmo ritmo de evolução das APIs de Kubernetes e ao mesmo tempo oferecendo suporte à mesma API exposta como uma API federada.

Se federação não pode simplesmente reutilizar a API inteira, perguntas como “Onde fica o conteúdo federado específico da API?” e “Como dar um propósito a cada tipo de recurso em vários clusters?” ficaram difíceis de responder.

Distribuir uniformemente as réplicas, por exemplo, no caso de cargas de trabalho de replicação e a criação do mesmo recurso em todos os clusters, como no caso de uma chave ou mapa de configuração, não era coerente.

Posteriormente, o foco dos grupos de interesse especial (Special Interest Groups – SIG) também foi alterado para incluir outras soluções e projetos possíveis e a Federação SIG foi alterada para SIG Multicluster.

Na Federação, esforços adicionais restringem ainda mais o escopo, para ser aplicado apenas ao gerenciamento de recursos da API, mantendo as implementações de baixo nível, por exemplo, sobreposição de rede multicluster ou armazenamento de multicluster completamente fora do escopo. O objetivo era ser capaz de definir uma API e building blocks que pudessem ser desenvolvidos de forma independente, replicados e ampliados para implementação personalizada. O esforço da comunidade nesse formato está se desenvolvendo na Kubernetes Cluster Federation, também conhecida como KubeFed.

Para onde estamos indo?

O desafio dos multicluster para a comunidade Kubernetes é um grande tema em aberto e os problemas a serem resolvidos são complexos. Não é à toa que a visão original do Ubernetes como uma solução única para todos os problemas não deu certo.

Outra dificuldade nessa área foi que, ao longo dos anos, não se viu o envolvimento dos colaboradores de código aberto, patrocinadores, para ser exato, como o assunto merece. Por exemplo, os grandes fornecedores de nuvem AWS e Azure estão ausentes e a participação do Google é quase insignificante atualmente no SIG. Podemos dizer que isso se deve em parte ao enorme potencial financeiro que essa área apresenta.

Os grandes fornecedores provavelmente estão entendendo se tratar de uma grande oportunidade para competir no mercado, em vez de colaborar e impulsionar soluções padrão que beneficiariam a todos.

O caminho do Google é um bom exemplo. Acharam mais sensato abordar todo o mercado com um conjunto de soluções. Após o sucesso do GKE, eles começaram a desenvolver o GKE on-premises, foram fundamentais para tornar o Istio extremamente bem adotado entre os usuários, lançaram o Stackdriver e criaram o Google Cloud Interconnect. A aquisição da Velostrata completou todas as peças do quebra-cabeça, com um conjunto geral de soluções eventualmente rotuladas como Anthos. Os preços do Anthos refletem a confiança do Google no potencial de monetização desse mercado.

Será bem interessante observar como os outros fornecedores de nuvem criarão suas próprias soluções para marcar a sua participação. Também será curioso observar como as colaborações de código aberto no grupo SIG multicluster se concretizarão nos próximos meses e que direção será tomada.

Como mencionado anteriormente, é difícil resolver tudo de uma vez. Atualmente, alguns dos maiores esforços no SIG devem ser capazes de alcançar a comunidade e os usuários que usam multiclusters do Kubernetes e se concentrar na solução dos problemas mais comuns primeiro. Eles também estão procurando colaboradores e ideias que possam trazer contribuições mais amplas da comunidade no futuro próximo.

A Turbonomic é uma empresa parceira da Leadcomm, que trabalha na elaboração de funcionalidades multicluster para sua plataforma de análise de dados, em colaboração com o SIG Multicluster, particularmente no projeto Kubernetes Cluster Federation (KubeFed), visando amadurecer o conceito e melhorar sua aplicabilidade.

Este texto foi adaptado do artigo A Brief History of Multicluster Kubernetes (Turbonomic, 2019)