Por que o Cloud Kubernetes não é tão independente de fornecedores quanto parece – e o que fazer sobre isso

Kubernetes é uma plataforma de código aberto. Você pode pensar, então, que é uma plataforma independente de fornecedor, o que significa que você pode facilmente mudar de uma implementação do Kubernetes para outra.

Mas você estaria errado. A realidade é que muitas soluções Kubernetes — em particular, aquelas que estão vinculadas a uma nuvem pública específica — são muito menos independentes de fornecedores do que você imagina.

Felizmente, isso não significa que você não pode aproveitar a nuvem pública como uma solução de hospedagem Kubernetes se quiser evitar aprisionamento. Você pode, mas precisa projetar sua estratégia de Kubernetes de uma forma que o liberte de ficar preso ao serviço Kubernetes de um provedor de nuvem específico e, ao mesmo tempo, permita que você aproveite as vantagens do Kubernetes baseado em nuvem.

Opções de Kubernetes baseadas em nuvem

Hoje, todas as principais nuvens públicas oferecem serviços Kubernetes hospedados por meio de uma arquitetura SaaS. A Amazon tem o Elastic Kubernetes Service. O Azure fornece o Serviço Azure Kubernetes. O Google oferece o Google Kubernetes Engine. A IBM tem o IBM Cloud Kubernetes Service.

Como esses serviços combinam infraestrutura baseada em nuvem com software que ajuda a automatizar a implantação e o gerenciamento do Kubernetes, eles são uma solução atraente para organizações que buscam começar a usar o Kubernetes rapidamente.

Riscos de bloqueio do Cloud Kubernetes

O fato de esses serviços de nuvem do Kubernetes parecerem agnósticos também aumenta seu apelo. À primeira vista, pode parecer que seria fácil migrar de uma plataforma Kubernetes SaaS para outra. Todas essas plataformas são baseadas no Kubernetes padrão e de código aberto. Eles fornecem acesso às mesmas ferramentas do Kubernetes (como o kubectl) e geralmente oferecem suporte aos mesmos tipos de configurações de armazenamento e rede. Diante disso, eles parecem bastante independentes de fornecedores.

No entanto, quando você se aprofunda, percebe que as nuvens públicas que oferecem o Kubernetes como um serviço hospedado não são tão flexíveis e genéricas quanto parecem. Eles se integram e dependem de várias maneiras de outros serviços executados nas nuvens públicas que os hospedam. Você precisa criar políticas de IAM em qualquer nuvem que você usar para gerenciar seus clusters do Kubernetes. Você pode acabar usando serviços específicos do fornecedor, como o Azure Active Directory no caso do Azure Kubernetes Service, para autenticação. E, em muitos casos, há ferramentas complementares ou de substituição que os serviços do Kubernetes preferem que você use, mesmo que eles não sejam estritamente necessários. O Google Kubernetes Engine quer que você use gke-deploy em vez de kubectl, por exemplo, enquanto o Elastic Kubernetes Service foi projetado para uso com eksctl, a ferramenta proprietária da Amazon.

Portanto, embora o código subjacente do Kubernetes possa ser o mesmo, não importa qual nuvem você use para hospedar o Kubernetes, e embora você possa tecnicamente ficar com ferramentas genéricas se realmente tentar, as ferramentas e configurações que você provavelmente acabará usando não são independentes de fornecedor. Eles são específicos para qualquer serviço do Kubernetes que você usar.

Isso cria uma grande barreira se você quiser migrar, digamos, do Azure Kubernetes Service para o Google Kubernetes Engine. Mesmo que você consiga transferir e transferir suas cargas de trabalho do Kubernetes, não é possível fazer o mesmo com as cadeias de ferramentas e os arquivos de configuração que as suportam.

Evite o bloqueio do Cloud Kubernetes

Se você quiser aproveitar a conveniência e a escalabilidade da nuvem pública ao implantar clusters do Kubernetes, mas não quiser ficar preso a ela, há duas soluções básicas.

Uma delas é configurar seus próprios clusters manualmente usando máquinas virtuais baseadas em nuvem e depois gerenciá-los você mesmo. Com essa abordagem, você não obtém a automação e as integrações que vêm com as ofertas de SaaS Kubernetes dos provedores de nuvem, mas ainda obtém a infraestrutura. Como você não está usando ferramentas especializadas, é mais fácil migrar seus clusters de um host de nuvem para outro sem reconstruir tudo. Claro, a desvantagem aqui é que é necessário um esforço manual significativo para configurar e gerenciar seus clusters.

A outra abordagem — mais automatizada e escalável — é usar uma solução como o serviço VoltStack® da Volterra para gerenciar seus clusters, não importa em quais nuvens eles estejam localizados. Com essa estratégia, você essencialmente substitui as ferramentas específicas da nuvem da plataforma de cada fornecedor por um centro de comando e controle centralizado que funciona com qualquer nuvem pública, facilitando a migração ou replicação de clusters entre diferentes nuvens públicas. Você obtém a mesma capacidade de gerenciamento que teria com serviços como Google Kubernetes Engine e Azure Kubernetes Engine, sem a dependência de nuvens públicas específicas.

Conclusão

Não cometa o erro de presumir que o Kubernetes é Kubernetes, não importa onde ou como você o executa. Há grandes diferenças entre os diferentes serviços do Kubernetes baseados em nuvem, o que pode dificultar a portabilidade dos clusters do Kubernetes de uma nuvem para outra (sem mencionar que dificulta o gerenciamento de clusters em nuvens diferentes, porque cada uma tem um conjunto diferente de ferramentas).

A boa notícia é que existe uma solução: ao usar uma solução de gerenciamento Kubernetes independente de nuvem, como o serviço VoltStack da Volterra, para gerenciar todos os seus clusters, você se livra da dependência de um provedor de nuvem específico e ainda aproveita a facilidade de uso do Kubernetes baseado em nuvem.