K8s/Kubernetes: AWS vs. GCP vs. Azure

O Kubernetes (muitas vezes estilizado como “K8s”) venceu a batalha das ferramentas de orquestração de contêineres anos atrás. No entanto, ainda existem muitas maneiras de implementar o Kubernetes hoje e fazê-lo funcionar com várias infraestruturas e muitas ferramentas – algumas com melhor manutenção do que outras. Talvez o desenvolvimento mais interessante nessa frente seja que os principais provedores de nuvem decidiram lançar suas próprias versões gerenciadas do Kubernetes:

• O Microsoft Azure oferece o Serviço Azure Kubernetes (AKS)
• A AWS oferece o Amazon Elastic Kubernetes Service (EKS)
• O Google Cloud oferece o Google Kubernetes Engine (GKE)

Do ponto de vista do DevOps, o que essas plataformas oferecem? Eles cumprem suas promessas? Como o tempo de criação deles e outros benchmarks se comparam? Quão bem eles se integram com suas respectivas plataformas, especialmente suas ferramentas CLI? Como é manter e trabalhar com eles? Abaixo, vamos nos aprofundar nessas perguntas e muito mais.

Nota: Para os leitores que gostariam de explicar os conceitos de um cluster Kubernetes antes de continuar lendo, Dmitriy Kononov oferece uma excelente introdução.

AKS x EKS x GKE: recursos anunciados

Decidimos agrupar os diferentes recursos disponíveis para cada versão gerenciada do Kubernetes em silos:

• Visão geral global
• Rede
• Escalabilidade e Desempenho
• Segurança e Monitoramento
• Ecossistema
• Preços

Observação: esses detalhes podem mudar com o tempo, pois os provedores de nuvem atualizam regularmente seus produtos.

Visão geral global

O próprio Kubernetes foi um projeto do Google, então faz sentido que eles tenham sido os primeiros a propor uma versão hospedada em 2014.

Dos três que estão sendo comparados aqui, o Azure foi o próximo com o AKS e teve algum tempo para melhorar: Se você se lembra do mecanismo acs, que foi usado para provisionar Kubernetes no Azure há alguns anos, você apreciará o esforço da Microsoft em sua substituição, aks-motor.

A AWS foi a última a lançar sua própria versão, EKS, então às vezes pode parecer estar atrasada na frente dos recursos, mas eles estão se atualizando.

Em termos de preços, é claro, as coisas estão sempre mudando, e o Google decidiu se juntar à AWS em seu preço de US$ 0,10/hora, a partir de junho de 2020. O Azure é o forasteiro aqui, oferecendo gratuitamente o serviço AKS, mas não está claro como tempo que pode durar.

Outra diferença principal está no recurso de atualização do cluster. Os upgrades mais automatizados estão no GKE e são ativados por padrão. No entanto, AKS vs. EKS são semelhantes entre si aqui, no sentido de que ambos exigem solicitações manuais para poder atualizar os nós mestre ou de trabalho.

Rede

No lado da rede, os três provedores de nuvem estão muito próximos um do outro. Todos eles permitem que os clientes implementem políticas de rede com o Calico, por exemplo. Em relação ao balanceamento de carga, todos eles implementam sua integração com seus próprios recursos de balanceador de carga e dão aos engenheiros a escolha do que usar.

A principal diferença encontrada aqui é baseada no valor agregado da malha de serviço. O AKS não oferece suporte a nenhuma malha de serviço pronta para uso (embora os engenheiros possam instalar manualmente o Istio). A AWS desenvolveu sua própria malha de serviço chamada App Mesh. Por fim, o Google lançou sua própria integração com o Istio (embora ainda em beta) que os clientes podem adicionar diretamente ao criar o cluster.

Melhor aposta: GKE

Escalabilidade e Desempenho

Em relação ao desempenho e escalabilidade do GKE x AKS x EKS, o GKE parece estar à frente. Na verdade, ele suporta o maior número de nós (5.000) e oferece extensa documentação sobre como dimensionar adequadamente um cluster. Todos os recursos para alta disponibilidade estão disponíveis e são fáceis de ajustar. Além disso, o GKE lançou recentemente o Anthos, um projeto para criar um ecossistema em torno do GKE e suas funcionalidades; com o Anthos, você pode implantar o GKE On-Prem.

No entanto, a AWS tem uma vantagem importante: é a única que permite que nós bare-metal executem seu cluster Kubernetes.

Em junho de 2020, o AKS não possui alta disponibilidade para o mestre, o que é um aspecto importante a ser considerado. Mas, como sempre, isso pode mudar em breve.

Melhor aposta: GKE

Segurança e Monitoramento

Em termos de conformidade, todos os três provedores de nuvem são equivalentes. No entanto, em termos de segurança, o EKS e o GKE fornecem outra camada de segurança com seus serviços de gerenciamento de chaves incorporados.

Quanto ao monitoramento, o Azure e o Google Cloud fornecem seu próprio ecossistema de monitoramento em torno do Kubernetes. Vale a pena notar que o do Google foi atualizado recentemente para usar o Kubernetes Engine Monitoring, projetado especificamente para o Kubernetes.

O Azure fornece seu próprio sistema de monitoramento de contêiner, que foi originalmente criado para um ecossistema de contêiner básico não Kubernetes. Eles adicionaram monitoramento para algumas métricas e recursos específicos do Kubernetes (saúde do cluster, implantações) — no modo de visualização, a partir de junho de 2020.

A AWS oferece monitoramento leve para o plano de controle diretamente no Cloudwatch. Para monitorar os trabalhadores, você pode usar as métricas do Kubernetes Container Insights fornecidas por meio de um agente específico do CloudWatch que pode ser instalado no cluster.

Melhor aposta: GKE

Ecossistema

Em termos de ecossistemas, os três provedores têm pontos fortes e ativos diferentes. O AKS agora possui uma documentação muito completa em torno de sua plataforma e é o segundo em termos de postagens no Stack Overflow. O EKS tem o menor número de postagens no Stack Overflow, mas se beneficia da força do AWS Marketplace. O GKE, como a plataforma mais antiga, tem o maior número de postagens no Stack Overflow e um número razoável de aplicativos em seu mercado, mas também a documentação mais abrangente.

Melhores apostas: GKE e EKS

Preços

Com relação ao preço geral, mesmo com a mudança do GKE para implementar o preço de US$ 0,10/hora para qualquer cluster, ele continua sendo de longe a nuvem mais barata. Isso se deve a algo específico do Google: descontos por uso prolongado, que são aplicados sempre que o uso mensal de recursos sob demanda atinge um determinado mínimo.

É importante observar que a linha de preço de exemplo não leva em consideração o tráfego para o cluster Kubernetes pelo qual o provedor de nuvem pode cobrar.

O motivo pelo qual a AWS não permite o uso de seu nível gratuito para testar um cluster EKS é que o EKS requer máquinas maiores do que o nível tX.micro, e o preço por hora do EKS não está no nível gratuito.

No entanto, ainda pode ser econômico testar qualquer uma dessas opções gerenciadas do Kubernetes com uma carga decente usando os nós spot/preemptivos de cada provedor de nuvem - essa tática economizará facilmente de 80 a 90% no preço final. (Claro, não é recomendado executar cargas de produção com estado nessas máquinas!)

Recursos anunciados e vantagem do Google

Ao analisar os diferentes recursos anunciados on-line, parece haver uma correlação entre há quanto tempo a versão gerenciada do Kubernetes está no mercado e o número de recursos. Como mencionado, o Google ter sido o iniciador do projeto Kubernetes parece ser uma vantagem inegável, resultando em uma integração melhor e mais forte com sua própria plataforma em nuvem.

Mas AKS e EKS não devem ser subestimados à medida que amadurecem; ambos podem tirar proveito de seus recursos exclusivos. Por exemplo, a AWS é a única a ter integração de nós bare-metal e também possui o maior número de aplicativos em seu mercado.

Agora que os recursos anunciados para cada oferta do Kubernetes estão claros, vamos nos aprofundar com alguns testes práticos.

Kubernetes: AWS x GCP x Azure na prática

Publicidade é uma coisa, mas como as diferentes plataformas se comparam quando se trata de atender cargas de produção? Como engenheiro de nuvem, sei a importância de quanto tempo leva para gerar e derrubar um cluster ao aplicar a infraestrutura como código. Mas eu também queria explorar as possibilidades de cada CLI e comentar como é fácil (ou não) cada provedor de nuvem gerar um cluster.

Experiência do usuário de criação de cluster

AKS

No AKS, gerar um cluster é semelhante a criar uma instância na AWS. Basta encontrar o menu AKS e percorrer uma sucessão de menus diferentes. Depois que a configuração é validada, o cluster pode ser criado, um processo de duas etapas. É muito simples e os engenheiros podem iniciar um cluster com facilidade e rapidez com as configurações padrão.

EKS

A criação de cluster é definitivamente mais complexa no EKS vs. AKS. Em primeiro lugar, e por padrão, a AWS exige uma viagem ao IAM primeiro para criar uma nova função para o plano de controle do Kubernetes e atribuir o engenheiro a ela. É importante notar também que esta criação de cluster não inclui a criação dos nós, então quando eu medi 11 minutos em média, isso é apenas para a criação do mestre. A criação do grupo de nós é outra etapa para o administrador, novamente precisando de uma função para os trabalhadores com três políticas necessárias a serem feitas através do painel de controle do IAM.

GKE

Para mim, a experiência de criar um cluster manualmente é mais agradável no GKE. Depois de encontrar o Kubernetes Engine no Console do Google Cloud, clique para criar um cluster. Diferentes categorias de configurações aparecem em um menu à esquerda. O Google preencherá o novo cluster com um pool de nós padrão facilmente modificável. Por último, mas não menos importante, o GKE tem o tempo de geração de cluster mais rápido, o que nos leva à próxima tabela.

Hora de gerar um cluster

Realizei esses testes na mesma região (Frankfurt e Europa Ocidental para AKS) para remover o possível impacto dessa diferença no tempo de desova. Também tentei selecionar o mesmo tamanho para os nós do cluster: três nós, cada um com duas vCPUs e sete ou oito GB de memória, um tamanho padrão para executar uma pequena carga no Kubernetes e começar a experimentar. Criei cada cluster três vezes para calcular uma média.

Nesses testes, o GKE permaneceu muito à frente com um tempo de geração sempre inferior a três minutos.

Kubernetes: AWS vs. GCP vs. Visão geral da CLI do Azure

Nem todas as CLIs são criadas iguais, mas, neste caso, todas as três CLIs são, na verdade, módulos de uma CLI maior. Como é começar a trabalhar com a cadeia de ferramentas CLI de cada provedor de nuvem?

AKS CLI (via az )

Depois de instalar o az tooling e, em seguida, o módulo AKS (via az aks install-cli ), os engenheiros precisam autorizar a CLI para se comunicar com a conta do Azure do projeto. Esta é uma questão de obter as credenciais para atualizar o arquivo kubeconfig local por meio de um simples az aks get-credentials --resource-group myResourceGroup --name myAKSCluster .

Da mesma forma, para criar um cluster: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI (via aws ou eksctl )

Na AWS, encontramos uma abordagem diferente — existem duas ferramentas CLI oficiais diferentes para gerenciar clusters EKS. Como sempre, o aws pode se conectar a recursos da AWS, principalmente clusters. Obter credenciais em um kubeconfig local pode ser feito por meio de: aws eks update-kubeconfig --name cluster-test .

No entanto, os engenheiros também podem usar eksctl , desenvolvido pela Weaveworks e escrito em Go, para criar e gerenciar facilmente um cluster EKS. Um grande benefício que o EKS oferece aos engenheiros de nuvem é que eles podem combiná-lo com arquivos de configuração YAML para criar infraestrutura como código (IaC), já que está trabalhando com o CloudFormation. É definitivamente um ativo a ser considerado ao integrar um cluster EKS em uma infraestrutura maior na AWS.

Criar um cluster via eksctl é tão fácil quanto eksctl create cluster , nenhum outro parâmetro é necessário.

CLI do GKE (via gcloud )

Para o GKE, as etapas são muito semelhantes: instale o gcloud e autentique via gcloud init . As possibilidades a partir daí: Os engenheiros podem criar, excluir, descrever, obter credenciais, redimensionar, atualizar ou atualizar um cluster ou listar clusters.

A sintaxe para criar um cluster com gcloud é simples: gcloud container clusters create myGCloudCluster --num-nodes=1

AKS x EKS x GKE: resultados da avaliação gratuita

Na prática, podemos ver que o GKE é certamente o mais rápido para ativar um cluster básico, em termos de simplicidade do console e tempo de geração do cluster. Em termos de UX, com o botão conectar ao lado do cluster, tornando a conexão a um cluster mais simples também.

Em termos de ferramentas CLI, os três provedores de nuvem implementaram funcionalidades semelhantes; no entanto, podemos enfatizar a ferramenta extra fornecida pelo Weaveworks for EKS. eksctl é a ferramenta perfeita para você implementar infraestrutura como código sobre sua infraestrutura AWS preexistente, combinando outros serviços com o EKS.

Ofertas gerenciadas do Kubernetes Avante: AWS vs. GCP vs. Azure

Para quem está começando no mundo do Kubernetes, a implementação principal para mim é o GKE, pois é o mais simples. É fácil de configurar, possui um UX simples e rápido para geração e está bem integrado ao ecossistema do Google Cloud Platform.

Embora a AWS tenha sido a última a entrar na corrida, ela tem algumas vantagens inegáveis, como nós bare metal e o simples fato de estar integrada ao provedor com maior participação.

Finalmente, a AKS fez grandes progressos desde a sua criação. A paridade de ferramentas e recursos provavelmente não levará muito tempo, deixando espaço no processo para inovar. E, como em qualquer oferta gerenciada do Kubernetes, para aqueles que já estão na plataforma pai, a integração será um ponto de venda.

Depois que uma equipe escolher um provedor de nuvem Kubernetes, pode ser interessante observar as experiências de outras equipes, principalmente as falhas. Esses post-mortems são um reflexo de casos do mundo real — sempre um bom ponto de partida para desenvolver as próprias melhores práticas de ponta. Aguardo seus comentários abaixo!