Por que o Kubernetes na nuvem não é tão independente de fornecedor quanto parece — e o que fazer a respeito

F5

O Kubernetes é uma plataforma de código aberto. Portanto, você pode pensar que ela é independente de fornecedor, o que significa que é possível migrar facilmente de uma implementação do Kubernetes para outra.

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

Felizmente, isso não significa que você não possa aproveitar a nuvem pública como uma solução de hospedagem do Kubernetes caso queira evitar a dependência de um fornecedor. Você pode, mas precisa elaborar sua estratégia de Kubernetes de modo a não ficar preso ao serviço de Kubernetes de um provedor de nuvem específico e, ao mesmo tempo, aproveitar as vantagens do Kubernetes baseado em nuvem.

Opções de Kubernetes na nuvem

Atualmente, todos os principais provedores de nuvem pública oferecem serviços Kubernetes hospedados por meio de uma arquitetura SaaS. A Amazon oferece o Elastic Kubernetes Service. O Azure disponibiliza o Azure Kubernetes Service. O Google oferece o Google Kubernetes Engine. A IBM conta com o IBM Cloud Kubernetes Service.

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

Riscos de dependência de fornecedor no Kubernetes em nuvem

O fato de esses serviços de Kubernetes na nuvem parecerem agnósticos também aumenta seu apelo. À primeira vista, pode parecer relativamente fácil migrar de uma plataforma SaaS de Kubernetes para outra. Todas essas plataformas são baseadas no Kubernetes padrão e de código aberto. Elas oferecem acesso às mesmas ferramentas do Kubernetes (como o kubectl) e, em geral, são compatíveis com os mesmos tipos de configurações de armazenamento e rede. Sob essa perspectiva, elas parecem bastante independentes de fornecedor.

No entanto, ao analisar mais a fundo, você percebe que as nuvens públicas que oferecem o Kubernetes como serviço hospedado não são tão flexíveis e genéricas quanto parecem. Elas se integram e dependem, de várias maneiras, de outros serviços executados nas nuvens públicas que as hospedam. É necessário criar políticas de IAM na nuvem utilizada para gerenciar seus clusters do Kubernetes. Você pode acabar usando serviços específicos do fornecedor para autenticação, como o Azure Active Directory no caso do Azure Kubernetes Service. Além disso, em muitos casos, há ferramentas complementares ou substitutas que os serviços do Kubernetes preferem que você use, mesmo que não sejam estritamente obrigatórias. Por exemplo, o Google Kubernetes Engine recomenda o uso do gke-deploy em vez do kubectl, enquanto o Elastic Kubernetes Service foi projetado para ser usado com o eksctl, ferramenta proprietária da Amazon.

Portanto, embora o código subjacente do Kubernetes possa ser o mesmo independentemente da nuvem usada para hospedá-lo e, tecnicamente, seja possível continuar usando ferramentas genéricas se você realmente se esforçar, as ferramentas e configurações que você provavelmente acabará usando não são independentes de fornecedor. Elas são específicas do serviço Kubernetes utilizado.

Isso cria uma grande barreira caso você queira migrar, por exemplo, do Azure Kubernetes Service para o Google Kubernetes Engine. Mesmo que seja possível migrar suas cargas de trabalho do Kubernetes sem alterações, não é possível fazer o mesmo com as cadeias de ferramentas e os arquivos de configuração que dão suporte a elas.

Evite a dependência de um provedor de Kubernetes na nuvem

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 um fornecedor, há duas soluções básicas.

Uma opção é configurar manualmente seus próprios clusters usando máquinas virtuais baseadas na nuvem e depois gerenciá-los por conta própria. Com essa abordagem, você não conta com a automação e as integrações oferecidas pelas soluções SaaS de Kubernetes dos provedores de nuvem, mas ainda tem acesso à infraestrutura. Como você não usa ferramentas especializadas, é mais fácil migrar seus clusters de um provedor de nuvem para outro sem precisar reconstruir tudo. É claro que a desvantagem é a quantidade significativa de trabalho manual necessária 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, independentemente das nuvens em que estejam hospedados. Com essa estratégia, você basicamente substitui as ferramentas específicas de nuvem da plataforma de cada fornecedor por uma central de comando e controle que funciona com qualquer nuvem pública, facilitando a migração ou a replicação de clusters entre diferentes nuvens públicas. Você obtém a mesma capacidade de gerenciamento oferecida por serviços como o Google Kubernetes Engine e o Azure Kubernetes Engine, sem ficar preso a nuvens públicas específicas.

Conclusão

Não cometa o erro de presumir que Kubernetes é sempre igual, independentemente de onde ou como você o execute. Existem diferenças significativas entre os diversos serviços de Kubernetes baseados em nuvem, o que pode dificultar a portabilidade de clusters de Kubernetes de uma nuvem para outra (sem falar na dificuldade de gerenciar clusters em nuvens diferentes, já que cada uma conta com um conjunto distinto de ferramentas).

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

Sobre o autor

F5

Mais publicações de F5