Fernanda Regina da Conceição Barreto; Jorge Carlos Valverde Rebaza

DOI: 10.22167/2675-6528-202600799

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

O avanço da computação em nuvem impulsionou a busca por soluções escaláveis, automatizadas e resilientes. Este trabalho investigou, na prática, como o Kubernetes transforma a gestão de ambientes modernos e se as diferenças entre os principais provedores gerenciados (AWS EKS, GCP GKE, Azure AKS) impactam o dia a dia. A metodologia combinou revisão bibliográfica com experimentos simultâneos nos três provedores, utilizando uma aplicação de microsserviços padronizada, stack de observabilidade e clusters Kubernetes 1.29 provisionados via Terraform. Testes de escalabilidade via HPA, simulação de falhas, carga de até 1.000 usuários e ciclos de deploy contínuo foram executados ao longo de quatro semanas. Os resultados demonstraram quedas de latência P95 entre 46% e 49%, recuperação automática em 90 a 130 segundos e disponibilidade acima de 98% sob falha. Observou-se que o GCP GKE se destacou na observabilidade nativa, o AWS EKS pelo Karpenter, e o Azure AKS exigiu configuração mais trabalhosa. Concluiu-se que a portabilidade multicloud é parcial; enquanto aplicações migram bem, a rede e os autoscalers permanecem específicos de cada provedor, fornecendo dados comparativos para decisões baseadas em evidências.

Palavras-chave: Automação; Computação em nuvem multicloud; Escalabilidade automática; Orquestração de contêineres; Tolerância a falhas.

1. Introdução

A arquitetura de microsserviços transformou profundamente o desenvolvimento de software, tornando-se um padrão da indústria não por modismo, mas pela incapacidade de monólitos sustentarem a complexidade e o crescimento das aplicações modernas (Lewis; Fowler, 2014; Newman, 2015). Nesse cenário, dezenas ou centenas de serviços independentes operam em contêineres, cada um exigindo implantação, escalonamento, monitoramento e recuperação coordenados. A conteinerização resolveu o desafio do empacotamento e da portabilidade (Merkel, 2014), mas criou uma nova problemática: como gerenciar centenas de contêineres distribuídos em múltiplos servidores e provedores sem comprometer a disponibilidade, desperdiçar infraestrutura ou travar o ciclo de entrega? Sem orquestração, o resultado previsível inclui serviços fora do ar, recursos subutilizados e equipes de Desenvolvimento e Operação (DevOps) e Site Reliability Engineering (SRE) em constante modo de “apagar incêndios” (Brewer, 2015; Verma et al., 2015).

O Kubernetes surgiu como a resposta direta a esse problema. Sua origem remonta a 2013, como Borg, o sistema interno do Google que gerenciava bilhões de contêineres por semana em seus data centers (Verma et al., 2015). Em junho de 2014, foi lançado como projeto de código aberto e, em 2016, doado à Cloud Native Computing Foundation (CNCF), consolidando-se como padrão de uso por volta de 2018. A adoção massiva é confirmada pelos números da CNCF (CNCF, 2024; Hightower et al., 2022), que indicam que mais de 96% das organizações que utilizam contêineres em produção já adotaram ou estão em processo de adoção do Kubernetes.

Contudo, a adoção bem-sucedida do Kubernetes não é trivial, pois a plataforma exige domínio de múltiplas camadas técnicas. Isso inclui o controle de acesso via Role-Based Access Control (RBAC), que define permissões para usuários e serviços dentro do cluster; redes definidas por software; armazenamento distribuído; e observabilidade (Li et al., 2020). Adicionalmente, a escolha do provedor de nuvem é crucial, uma vez que AWS EKS, Google Cloud GKE e Azure AKS possuem características, custos e comportamentos operacionais distintos que impactam diretamente a performance e a resiliência das aplicações (Santos et al., 2023). Além dos aspectos técnicos, o sucesso da implementação também depende de um lado humano, exigindo uma cultura DevOps enraizada na equipe para evitar gargalos operacionais (Kim et al., 2016).

O problema concreto que motivou este trabalho é a lacuna na literatura técnica sobre Kubernetes. Embora existam estudos que abordam aspectos isolados como performance (Li et al., 2020), auto-scaling (Casalicchio; Perciballi, 2017) e segurança (Islam Shamim et al., 2020), há uma escassez de comparações experimentais controladas entre AWS EKS, Google Cloud GKE e Azure AKS. Tais estudos deveriam utilizar carga de trabalho equivalente, as mesmas ferramentas e os mesmos protocolos aplicados simultaneamente. Essa ausência de evidências empíricas leva a decisões de escolha de provedor baseadas em benchmarks isolados, materiais dos próprios fornecedores ou experiência de mercado. A falta de dados comparativos tem um custo real, pois diferenças significativas de precificação entre provedores impactam diretamente o orçamento de infraestrutura, e comportamentos distintos de escalabilidade e recuperação de falhas afetam diretamente os Service Level Agreements (SLAs) corporativos.

Este estudo se justifica pela necessidade de fornecer dados comparativos robustos para embasar decisões estratégicas em ambientes de nuvem. Os resultados são de interesse para engenheiros e arquitetos de nuvem que buscam fundamentação técnica para a escolha de provedores, para equipes de SRE/DevOps responsáveis pela confiabilidade em produção, para líderes que avaliam custo e time-to-market, e para pesquisadores que buscam benchmarks reproduzíveis. Assim, o objetivo deste trabalho é analisar e comparar, de forma teórica e experimental, como o Kubernetes se comporta nos três principais provedores gerenciados em termos de escalabilidade, automação e resiliência.

2. Material e Métodos

A presente pesquisa caracterizou-se por uma abordagem metodológica mista, combinando revisão bibliográfica sistemática com experimentação prática controlada. O estudo foi organizado em seis etapas sequenciais, visando analisar e comparar o comportamento do Kubernetes em termos de escalabilidade, automação e resiliência nos três principais provedores de nuvem gerenciados: AWS EKS, Google Cloud GKE e Azure AKS. A estratégia central consistiu em padronizar ao máximo os ambientes e ferramentas para isolar as variáveis de infraestrutura dos provedores.

A primeira etapa, de revisão bibliográfica sistemática, foi conduzida entre janeiro e março de 2025. Foram consultadas publicações datadas de 2014 a 2025, abrangendo temas como arquitetura, performance, segurança e operação de clusters Kubernetes em produção. Adicionalmente, foram analisados textos técnicos dos provedores, relatórios anuais da Cloud Native Computing Foundation (CNCF, 2024), documentação oficial do Kubernetes e a documentação dos projetos utilizados na experimentação.

Na segunda etapa, realizou-se o provisionamento dos ambientes experimentais. Foram configurados três clusters Kubernetes, um em cada provedor (AWS EKS na região us-east-1, GCP GKE em us-central1 e Azure AKS em eastus), todos operando na versão 1.29. Cada cluster foi composto por três nós workers de propósito geral, com 2 vCPUs e 4 GB de RAM (t3.medium para AWS, e2-medium para GCP e Standard_B2s para Azure), distribuídos em duas zonas de disponibilidade.

A seleção desses provedores foi baseada em sua consolidação no mercado corporativo e no equilíbrio que oferecem entre controle operacional e gerenciamento do Control Plane. Distribuições como Red Hat OpenShift, K3s e Minikube foram excluídas por não se alinharem aos critérios de equivalência experimental ou representatividade de ambientes de produção com alta disponibilidade (Xavier; Macedo, 2022).

Toda a infraestrutura foi provisionada utilizando Terraform, por meio de módulos independentes para cada provedor, o que garantiu a rastreabilidade e reprodutibilidade dos ambientes. Cada cluster foi segmentado em três namespaces funcionalmente isolados: “app” para a aplicação, “monitoring” para as ferramentas de observabilidade e “ci-cd” para o pipeline de entrega contínua.

O controle de acesso foi implementado seguindo o princípio do menor privilégio, utilizando Role-Based Access Control (RBAC) com roles específicas por namespace. A camada de entrada foi padronizada nos três clusters com Ingress Controller NGINX e certificados TLS, provisionados automaticamente pelo cert-manager e integrados à autoridade certificadora de cada provedor.

A terceira etapa consistiu na configuração das ferramentas de suporte. O stack de observabilidade e automação foi instalado de forma idêntica nos três clusters, utilizando Helm Charts versionados em um repositório Git comum. Essa padronização foi crucial para atribuir as diferenças observadas nos resultados ao comportamento da infraestrutura de cada provedor, e não a variações de configuração experimental (Burns, 2018; Li et al., 2020).

Para observabilidade, o Prometheus foi configurado para coletar métricas a cada 15 segundos via ServiceMonitors. O Grafana foi utilizado para visualização, com cinco dashboards criados, incluindo uma visão comparativa multicloud. O AlertManager foi responsável pelo roteamento de alertas críticos, configurado para detectar eventos como CrashLoopBackOff, altos níveis de CPU e memória, e latência P95 acima de 500 ms.

A entrega contínua foi implementada com ArgoCD, que monitorou o mesmo repositório Git nos três clusters, com sincronização automática a cada 3 minutos. O Argo Rollouts foi utilizado para habilitar deploys Canary, direcionando 20% do tráfego para novas versões e realizando análise automática de métricas pós-deploy, com rollback automático em caso de latência P95 superior a 300 ms ou taxa de erros acima de 1%.

A escalabilidade foi gerenciada pelo Horizontal Pod Autoscaler (HPA), configurado com um threshold de 60% de CPU e um mínimo de 2 e máximo de 10 réplicas para o serviço de API backend. O Vertical Pod Autoscaler (VPA) operou em modo Recommendation para os demais serviços, observando o uso de recursos por 72 horas. No AWS EKS, o Karpenter substituiu o Cluster Autoscaler padrão, priorizando instâncias Spot e o tipo de instância mais econômico.

Na quarta etapa, realizou-se o deploy da aplicação de microsserviços. A aplicação foi composta por quatro serviços com perfis de carga distintos: um frontend React servido via NGINX, um API backend Node.js com endpoints RESTful, um serviço de autenticação para geração e validação de tokens JWT, e um banco de dados PostgreSQL com volume persistente via PersistentVolumeClaim.

Os manifestos Helm foram estruturados com um arquivo `values.yaml` base idêntico para os três ambientes e arquivos `values-{provedor}.yaml` específicos para cada provedor, contendo apenas as diferenças de anotações de Ingress, storage class e nome do registry. A lógica de negócio, limites de recursos e políticas de HPA e VPA foram mantidos rigorosamente iguais em todos os clusters.

A quinta etapa compreendeu a execução dos testes, realizada ao longo de quatro semanas em paralelo. Para garantir a simultaneidade, os testes foram disparados a partir de um único host de controle, conectado aos três clusters via `kubectl`. Um script shell orquestrou o disparo simultâneo do K6 nos três ambientes, eliminando vieses de latência de rede.

Na primeira semana, avaliou-se a escalabilidade (HPA e VPA), simulando um aumento progressivo de 50 a 500 usuários virtuais em 10 minutos. Na segunda semana, testou-se a tolerância a falhas e o auto-healing, com cenários de desligamento de nó via API e falha intencional no endpoint de health check do serviço de autenticação.

A terceira semana focou na carga progressiva com K6, aplicando três patamares de usuários virtuais (100, 500 e 1.000 VUs), cada um por 10 minutos após um ramp-up de 2 minutos. Na quarta semana, foram executados 38 deploys contínuos com ArgoCD e Argo Rollouts, incluindo atualizações de features, hotfixes e rollouts canary com regressão de latência intencional para acionar o rollback automático.

A sexta e última etapa envolveu a coleta, análise e consolidação dos dados. O Prometheus coletou métricas continuamente durante todo o período, com resolução de 15 segundos para latência e throughput, e 1 minuto para CPU, memória e nós ativos. Ao final de cada semana, os dados foram exportados para arquivos .CSV e importados em planilhas para análise comparativa.

A análise foi conduzida em três camadas: quantitativa, com cálculo de percentis de latência (P50, P95, P99), throughput e taxa de erros por patamar de teste; de eventos, com a reconstrução da sequência de falhas a partir dos logs exportados para CloudWatch, Cloud Logging e Azure Monitor; e qualitativa, com o registro dos desafios de configuração e ações corretivas. A triangulação de dados experimentais, literatura acadêmica e dados de mercado (Li et al., 2020; CNCF, 2024) foi empregada para sustentar as conclusões.

3. Resultados e Discussão

A análise dos resultados da pesquisa revelou como o Kubernetes se comporta nos principais provedores gerenciados de nuvem, focando em escalabilidade, automação e resiliência, e identificando as nuances operacionais que surgem em um contexto multicloud. Os achados confirmam a eficácia da orquestração de contêineres na gestão de ambientes modernos, ao mesmo tempo em que expõem as diferenças intrínsecas de cada provedor. A discussão é estruturada para apresentar os resultados dos experimentos semanais, os desafios de implementação e uma síntese comparativa geral, sempre em alinhamento com o problema de pesquisa e os objetivos estabelecidos.

A revisão bibliográfica inicial organizou a arquitetura do Kubernetes em oito categorias funcionais, desde o Control Plane até a segurança, evidenciando que a escolha das ferramentas em cada camada não é um detalhe de configuração, mas uma decisão de design com impacto direto na complexidade operacional e nos resultados. Por exemplo, o Control Plane gerencia o estado desejado do cluster, enquanto os Worker Nodes executam os pods das aplicações. As ferramentas implementadas no experimento, como NGINX Ingress, Prometheus Adapter e ArgoCD, representam as escolhas mais comuns em ambientes de produção, conforme dados da CNCF (2024).

A camada de observabilidade, por exemplo, utilizou Prometheus para coleta de métricas e Grafana para visualização, enquanto a segurança foi abordada com RBAC. Para escalonamento, foram empregados HPA e VPA. Essa estrutura ressalta a natureza modular do Kubernetes, onde cada componente tem uma função principal e ferramentas associadas, como `kubectl` para o Control Plane e `containerd` para os Worker Nodes. A escolha de padronizar essas ferramentas nos três provedores permitiu isolar as diferenças de comportamento à infraestrutura subjacente de cada nuvem (Burns, 2018; Li et al., 2020).

O ecossistema CNCF, com seus projetos em diferentes estágios de maturidade (Sandbox, Incubating, Graduated), foi mapeado para identificar ferramentas emergentes. Das oito ferramentas analisadas, cinco já alcançaram o estágio Graduated, indicando sua maturidade para uso em produção. Contudo, apenas o Karpenter no AWS EKS e o Argo Rollouts nos três clusters foram efetivamente implantados no experimento. Essa decisão metodológica visou evitar a introdução de variáveis adicionais que pudessem mascarar as diferenças atribuíveis ao comportamento dos provedores, como ocorreria com o Cilium, que substituiria a camada de rede nativa.

Ferramentas como Cilium, que oferece networking L3-L7 e políticas de segurança via eBPF, e KEDA, para escalonamento automático baseado em eventos externos, foram consideradas, mas não utilizadas. O Cilium, embora Graduated e com alta adoção, alteraria a camada de rede nativa, inviabilizando a comparação de Ingress entre os provedores. O KEDA seria adequado para cargas de trabalho event-driven, mas a aplicação utilizada no estudo emprega requisições HTTP síncronas, tornando o HPA a escolha mais apropriada. Essa abordagem garantiu que as comparações fossem focadas nas características intrínsecas de cada provedor.

Desafios identificados na implementação multicloud

A operação simultânea dos três ambientes revelou que a complexidade do Kubernetes não reside apenas na plataforma em si, mas em sua interação com as particularidades de cada provedor. Seis desafios técnicos principais foram identificados durante a implementação multicloud. O primeiro foi a configuração do RBAC, que, por padrão, nega todas as operações. A conta de serviço do ArgoCD, por exemplo, foi criada sem o `RoleBinding` adequado no namespace `app`, bloqueando os deploys iniciais. A solução envolveu a definição de `Roles` mínimas por função e a segregação estrita por namespace, versionando as políticas no repositório Git.

O segundo desafio envolveu o Ingress e Load Balancer, que são implementados de forma distinta por cada provedor. O AWS EKS exigiu anotações específicas para integração com o AWS ALB, enquanto o GCP GKE demandou `backend config` para `health checks`, e o Azure AKS utilizou `IngressClass` explícita. Esses comportamentos distintos resultaram em erros HTTP 502/504 nos primeiros dias, evidenciando que a portabilidade do Kubernetes não se estende à camada de rede do provedor. A ação corretiva foi a criação de arquivos `values-{provider}.yaml` com anotações específicas, mantendo o restante dos manifestos idênticos.

O dimensionamento de recursos, especialmente em relação a eventos de OOMKill (Out Of Memory Kill), constituiu o terceiro desafio. O serviço de autenticação, que valida tokens JWT, apresentou 14 eventos de OOMKill em 24 horas com um limite inicial de 128 Mi. A causa raiz foi o dimensionamento sem histórico de carga real, pois a validação de JWT tem picos de consumo de memória não lineares. A adoção do VPA (Vertical Pod Autoscaler) no modo `Recommendation`, após 72 horas de observação, sugeriu a elevação para 256 Mi, eliminando os OOMKills e validando a importância de uma etapa de observação antes de mover serviços para o modo `Auto`.

A observabilidade multinamespace foi o quarto desafio, com um erro no `namespaceSelector` dos `ServiceMonitors` do Prometheus que impedia a coleta de métricas dos pods no namespace `app`. Isso resultou em dados ausentes nos dashboards do Grafana durante as primeiras 48 horas. A separação de namespaces, embora correta do ponto de vista de segurança, aumentou a complexidade da configuração da observabilidade. A ação corretiva foi a revisão de todos os `ServiceMonitors` para incluir o seletor correto e a validação com `promtool` antes do deploy, garantindo a visibilidade completa das métricas.

O quinto desafio, a portabilidade multicloud, revelou que a premissa de que o Kubernetes é 100% portável entre provedores não se sustenta na prática. O GCP GKE provisionou nós em média 25 segundos mais rápido que o AWS EKS e Azure AKS, devido ao `Node Problem Detector` nativo com polling de 5 segundos, um fato não documentado comparativamente. Além disso, o Karpenter (EKS) e o Cluster Autoscaler (GKE/AKS) apresentaram comportamentos de escalonamento distintos, impactando os resultados dos testes. Isso exigiu o mapeamento das diferenças e a aceitação de que a portabilidade real se restringe à camada de aplicação, não à infraestrutura.

Por fim, o custo de nuvem acima do orçamento inicial foi o sexto desafio, especialmente no AWS EKS, onde o custo mensal atingiu 38% acima do previsto. As causas incluíram a cobrança fixa de USD 0,10/hora pelo control plane do EKS (inexistente no GKE e AKS), a cobrança por hora de cada Ingress com AWS ALB mesmo sem tráfego, e nós subutilizados que permaneciam ativos entre as semanas de teste. A implementação do Karpenter para substituição automática de nós ociosos, o uso de NLB em vez de ALB, e um script para desligamento de nós entre sessões de teste reduziram o custo em 30% nas últimas duas semanas.

A análise conjunta desses desafios revela três padrões recorrentes com implicações diretas para a adoção do Kubernetes. O primeiro é o custo oculto da abstração: embora o Kubernetes abstraia a infraestrutura subjacente, cada provedor a implementa de forma diferente, especialmente nas camadas de rede e escalabilidade. Essas diferenças não são evidentes na documentação, mas surgem na operação real. O segundo padrão é a tensão entre segurança e operabilidade, onde o RBAC e a separação de namespaces, embora essenciais para segurança, aumentam a complexidade de configuração de ferramentas como Prometheus e ArgoCD, que precisam operar entre namespaces. Essas situações são trade-offs arquiteturais que exigem gerenciamento consciente.

O terceiro padrão é que os desafios identificados não são novos. RBAC mal configurado, dimensionamento inadequado de recursos e custos inesperados de nuvem são consistentemente apontados na literatura e em dados de mercado (Li et al., 2020; CNCF, 2024) como os principais obstáculos à adoção bem-sucedida do Kubernetes. Este experimento, portanto, reflete as dificuldades práticas enfrentadas pela indústria, validando a relevância dos achados em um contexto real de produção.

Semana 1 — Escalabilidade horizontal (HPA)

O teste de escalabilidade horizontal (HPA) demonstrou a capacidade do Kubernetes de adaptar automaticamente a capacidade da aplicação a variações de carga. Durante o ramp-up de 50 a 500 usuários virtuais em 10 minutos, a latência P95 nos três provedores permaneceu controlada, entre 150 e 250 ms, com um pico moderado próximo a 20 minutos, antes da estabilização pelo escalonamento. Em contraste, uma máquina virtual sem orquestração apresentou latência crescente, atingindo cerca de 300 ms ao final dos 60 minutos, sem mecanismos de reação ao aumento da carga.

O HPA atuou de forma preventiva, com disparos em T+38s para GCP GKE, T+47s para AWS EKS e T+54s para Azure AKS. Após cada disparo, a latência do provedor correspondente caiu e se estabilizou em torno de 150 ms, à medida que as réplicas adicionais absorveram a carga. A diferença de 16 segundos entre o GKE e o AKS é atribuída à frequência padrão do Metrics Server: 15 segundos no GCP GKE Standard contra 60 segundos no AWS EKS e Azure AKS (Li et al., 2020). Essa diferença na coleta de métricas se traduz diretamente na velocidade de reação sob pressão.

O comportamento do sistema durante o teste de HPA pode ser dividido em três fases. Na fase inicial (T=0 a T≈20min), os três provedores mantiveram 2 réplicas, o mínimo configurado, enquanto os usuários virtuais aumentaram de 50 para cerca de 330. Nesse período, os nós t3.medium/e2-medium absorveram a carga sem que a CPU ultrapassasse o threshold de 60% do HPA, indicando que o escalonamento não foi acionado por não ser necessário. Isso demonstra a capacidade inicial dos nós de lidar com a carga moderada sem a necessidade de expansão imediata de réplicas.

Na fase de escalonamento (T≈20min a T≈27min), a CPU ultrapassou o threshold, e o HPA começou a provisionar réplicas em degraus discretos, um comportamento característico do mecanismo que adiciona réplicas inteiras a cada ciclo de avaliação. O GCP GKE iniciou o escalonamento primeiro, seguido pelo AWS EKS e Azure AKS, com uma pequena defasagem que reflete as diferenças na frequência do Metrics Server entre os provedores. Cada degrau visível no gráfico corresponde a um ciclo de avaliação que identificou a CPU acima de 60% e, consequentemente, provisionou mais uma réplica para atender à demanda crescente.

Na fase estabilizada (T≈27min até o final do teste), os três provedores convergiram para 5 réplicas e permaneceram nesse estado, mesmo com o aumento contínuo de usuários virtuais até 500. As cinco réplicas foram suficientes para absorver a carga final, mantendo a latência dentro dos limites aceitáveis. Em termos absolutos, o HPA demonstrou eficácia consistente: a latência P95 caiu entre 46,7% e 49,0% nos três provedores, e o throughput triplicou, variando de +229,2% a +254,2%. A taxa de erros permaneceu abaixo de 0,4% após a atuação do HPA, confirmando a eliminação do gargalo de capacidade.

A diferença de velocidade de disparo do HPA entre os provedores é configurável, mas não foi alterada no experimento para preservar a comparação em condições de fábrica. Operacionalmente, a diferença de 31 ms no P95 final entre GCP GKE (181 ms) e Azure AKS (212 ms) é real, mas de baixa magnitude para a maioria dos casos de uso. O achado mais relevante é que todos os provedores entregaram o mesmo comportamento fundamental: réplicas escalonadas de 2 para 5, throughput triplicado, taxa de erros abaixo de 0,5% e latência estabilizada em menos de 8 minutos após o disparo. O Kubernetes cumpriu sua função central de escalabilidade automática sem intervenção humana.

Semana 2 — Tolerância a falhas e auto-healing

O teste de tolerância a falhas e auto-healing simulou o desligamento de um nó worker, com 200 usuários virtuais ativos, para avaliar a capacidade do Kubernetes de detectar, isolar e recuperar a situação com impacto mínimo. Os três provedores operaram em uma linha de base de latência P95 de aproximadamente 200 ms até o momento da falha. As detecções ocorreram de forma escalonada: GCP GKE em T+9s, AWS EKS em T+12s e Azure AKS em T+15s. A partir desses intervalos, a latência começou a subir, pois o tráfego ativo tentava alcançar pods no nó perdido, resultando em recusa de conexão ou timeout.

O pico de impacto ocorreu entre T+30s e T+50s, com a latência P95 atingindo cerca de 400 ms em todos os provedores, uma elevação de 100% sobre a linha de base. No entanto, o sistema permaneceu longe de um colapso total, pois os pods nos dois nós remanescentes continuaram respondendo às requisições. A sequência de recuperação foi marcada pelo início do rescheduling: GCP GKE em T+35s, AWS EKS em T+48s e Azure AKS em T+55s. O GCP GKE demonstrou a recuperação mais rápida, retornando à linha de base de 200 ms por volta de T+100s, enquanto o AWS EKS e o Azure AKS levaram um pouco mais de tempo.

A decomposição temporal do incidente de falha de nó worker revelou achados com implicações operacionais diretas. O GCP GKE detectou a falha em T+9s, iniciando o rescheduling em T+35s, com os pods totalmente restaurados em T+1m30s. O AWS EKS detectou em T+12s, iniciando o rescheduling em T+48s, e restaurando os pods em T+1m52s. O Azure AKS, por sua vez, detectou em T+15s, iniciou o rescheduling em T+55s, e restaurou os pods em T+2m10s. A disponibilidade no intervalo foi de 99,4% para GCP GKE, 99,1% para AWS EKS e 98,8% para Azure AKS, com erros em transações ativas de 0,3%, 0,4% e 0,6%, respectivamente.

A principal causa da diferença de detecção entre provedores é a instalação padrão do Node Problem Detector com polling de 5 segundos no GCP GKE Standard, componente ausente por padrão no AWS EKS e Azure AKS. Esse atraso inicial se propagou por toda a cadeia de recuperação, resultando em uma diferença de 40 segundos no tempo de restauração completa entre GCP GKE e Azure AKS. Esse achado destaca a importância de componentes nativos de detecção de falhas para a resiliência do ambiente.

O segundo achado relevante é que o Azure AKS registrou uma disponibilidade marginalmente abaixo de 99% (98,8%) durante o evento de falha. Em um contrato de produção com SLA de 99% ou superior, essa disponibilidade representaria uma violação. Para ambientes com requisitos estritos de SLA, o Azure AKS exigiria ajustes adicionais, como a redução do `tolerationSeconds` ou a instalação manual do Node Problem Detector, para garantir o nível contratual sob falhas de nó. Isso sublinha a necessidade de configurações específicas para atender a requisitos de alta disponibilidade em diferentes provedores.

O terceiro achado, e o mais relevante em termos de valor da plataforma, é a recuperação autônoma em 90 a 130 segundos nos três provedores. Isso representa uma redução de 77% a 89% em comparação com o tempo estimado de recuperação manual, que varia entre 5 e 15 minutos para equipes bem treinadas (Brewer, 2015). Nenhum dos provedores exigiu intervenção humana, reinicialização manual de serviços ou resultou em perda de dados no PostgreSQL com volume persistente. Isso demonstra a capacidade do Kubernetes de fornecer auto-healing robusto, um pilar fundamental para a resiliência de aplicações modernas.

Semana 3 — Carga progressiva com K6

O teste de carga progressiva com K6 avaliou o comportamento dos três ambientes sob diferentes níveis de carga, utilizando patamares de 100, 500 e 1.000 usuários virtuais (VUs). No patamar de 100 VUs, os três provedores foram praticamente indistinguíveis, com latência P95 entre 150 e 200 ms e curvas sobrepostas. Esse comportamento é metodologicamente importante, pois sob carga leve, os ambientes responderam de forma idêntica, confirmando a eficácia do controle experimental. Qualquer diferença observada nos patamares seguintes reflete o comportamento da infraestrutura sob pressão, não variações de configuração inicial.

A transição para 500 VUs em T≈13min resultou em uma subida imediata e conjunta da latência P95 para aproximadamente 300-350 ms. As curvas se estabilizaram e permaneceram próximas, com variação natural de ±30 ms. Esse patamar ainda estava dentro da capacidade confortável dos clusters com o HPA atuando. A transição para 1.000 VUs em T≈25min foi o ponto em que as diferenças entre provedores se tornaram estatisticamente relevantes, com as curvas se separando de forma visível pela primeira vez.

No patamar de 1.000 VUs, o GCP GKE estabilizou em torno de 530 ms, o AWS EKS na faixa de 580 ms e o Azure AKS em torno de 610 ms. Essa separação reflete as diferenças no CNI nativo, na frequência do Metrics Server e no comportamento do autoscaler de nós, variáveis intrínsecas de cada provedor que se tornam determinantes quando o cluster opera próximo ao limite de capacidade. A taxa de erros confirmou essa tendência: zero erros a 100 VUs, aproximadamente 0,4-0,5% a 500 VUs e uma diferenciação clara a 1.000 VUs. O aumento de erros não indica falha do Kubernetes, mas saturação da capacidade da infraestrutura provisionada, uma condição esperada e documentada nos objetivos do teste.

Três achados principais merecem análise separada. O primeiro é a magnitude da degradação: a latência P95 aumentou aproximadamente 3,5 vezes nos três provedores entre 100 e 1.000 VUs. O fato de a degradação ser proporcional nos três indica que o gargalo é compartilhado, com o cluster atingindo o limite de CPU disponível nos nós de 2 vCPUs. Isso não é um problema de provedor, mas sim de capacidade de infraestrutura. Para sustentar 1.000 VUs com taxa de erros próxima de zero, seriam necessários nós maiores, mais réplicas ou otimizações arquiteturais, como cache distribuído e decomposição do serviço de API, que foi o componente de maior pressão de CPU.

O segundo achado está na linha de réplicas e nós: o HPA escalou ao máximo de 10 réplicas, e o autoscaler adicionou 3 nós extras em todos os provedores, passando de 3 para 6 nós ativos. Com 6 nós e 10 réplicas, o sistema estava no limite da capacidade provisionada, condição que explica tanto a degradação da latência quanto o aparecimento de erros. Isso demonstra que, mesmo com a automação de escalonamento, há um limite físico de recursos que, uma vez atingido, impacta diretamente a performance e a taxa de erros da aplicação.

O terceiro achado é o mais revelador: a diferença relativa entre provedores não aumentou com a carga. O spread de P95 foi de 15,1% a 1.000 VUs, similar aos 14,7% a 100 VUs. O GCP GKE não degradou de forma mais controlada que os demais; ele simplesmente partiu de um baseline menor e manteve essa vantagem proporcional. A diferença absoluta de 80 ms entre GKE e AKS no P95 a 1.000 VUs é real, mas sua origem está no comportamento do Metrics Server e do CNI nativo de cada provedor, não em uma capacidade superior de gerenciar carga. Isso reforça que as diferenças de performance são inerentes à infraestrutura de cada nuvem.

Semana 4 — Deploy contínuo com ArgoCD e Argo Rollouts

A avaliação do pipeline GitOps com ArgoCD e Argo Rollouts ao longo de 14 dias e 38 deploys por provedor revelou padrões importantes no lead time de deploy. O primeiro padrão é a consistência das médias ao longo do tempo: 3,7 min no GCP GKE, 4,3 min no AWS EKS e 4,6 min no Azure AKS. A diferença de 0,9 minutos entre GCP GKE e Azure AKS, embora pequena, foi persistente. A principal causa é o menor tempo de sincronização do ArgoCD no GCP GKE (1m28s), comparado a 1m42s no AWS EKS e 1m55s no Azure AKS. Isso se deve à latência de pull de imagem do Artifact Registry para o cluster GCP GKE, ambos na mesma rede Google, combinada com a maior velocidade de aplicação de manifestos pelo control plane.

O segundo padrão é a variabilidade diária, que revela o impacto do tipo de deploy no lead time. Nenhum provedor apresentou lead time constante, com as barras oscilando entre 2,5 e 6 minutos dependendo do dia. Dias com lead time acima da média corresponderam majoritariamente a deploys canary que acionaram a análise de métricas do Argo Rollouts. A fase de análise adiciona o tempo de observação de P95 e taxa de erros antes de promover ou reverter o deploy. Dias abaixo da média foram hotfixes e atualizações diretas sem fase canary, que seguem o caminho mais curto do pipeline, demonstrando a flexibilidade da estratégia GitOps.

O terceiro padrão é a concentração de picos no Azure AKS. Os três valores mais altos do gráfico, nos dias 4, 11 e 13, todos acima de 5 minutos, pertenceram ao Azure AKS e não tiveram equivalente no AWS EKS ou GCP GKE nos mesmos dias. Esses picos estão diretamente correlacionados com os 3 rollbacks automáticos registrados pelo Argo Rollouts no Azure AKS. Em todos os casos, deploys canary em que a latência P95 ultrapassou o threshold de 300 ms durante a fase de análise acionaram a reversão automática para a versão anterior, adicionando o tempo de rollback ao lead time do dia. O GCP GKE registrou apenas 1 rollback nos 14 dias, e sua barra mais baixa, no dia 14 com aproximadamente 2,7 minutos, representa um deploy direto sem fase canary em condições de latência bem abaixo do threshold.

As métricas do pipeline GitOps consolidam esses achados. O tempo médio de sincronização do ArgoCD, de 1m28s no GCP GKE a 1m55s no Azure AKS, representa a etapa em que o ArgoCD detecta a mudança no repositório Git e aplica os manifestos. Esse componente responde por aproximadamente 38–41% do lead time total. A diferença de 27 segundos entre GCP GKE e Azure AKS reflete a latência de pull de imagem do registry para o cluster, com o Artifact Registry e o cluster GCP GKE operando na mesma rede Google, o que otimiza o tempo de download da imagem a cada deploy.

O lead time médio total, de 3m52s a 4m38s, representa o ciclo completo do commit ao código em produção respondendo requisições. A decomposição desse tempo inclui sincronização do ArgoCD (aproximadamente 38%), pull e extração da imagem Docker (aproximadamente 30%), inicialização do pod e passagem nos health checks (aproximadamente 20%), e análise de métricas do Argo Rollouts nos deploys canary (aproximadamente 12%). O GCP GKE foi 10,1% mais rápido que o AWS EKS e 16,5% mais rápido que o Azure AKS, com a vantagem acumulando em todas as etapas da cadeia de entrega contínua.

A taxa de sucesso e os rollbacks automáticos são faces da mesma métrica. O GCP GKE teve 97,4% de sucesso e 1 rollback; o AWS EKS, 94,7% e 2 rollbacks; e o Azure AKS, 92,1% e 3 rollbacks. Em todos os casos, o Argo Rollouts detectou que a latência P95 ultrapassou o threshold de 300 ms durante a fase canary, com apenas 20% do tráfego na nova versão, e reverteu automaticamente. O Azure AKS, com P95 base mais alto em todos os testes de carga, estava naturalmente mais próximo do threshold, o que explica a maior frequência de rollback. Isso demonstra que o pipeline funcionou como projetado, protegendo o usuário final antes que a regressão afetasse 100% do tráfego.

O drift detectado e corrigido, com 7 ocorrências idênticas nos três provedores, é um dado de grande implicação conceitual. Drift é a divergência entre o estado desejado no repositório Git e o estado real do cluster, tipicamente causado por mudanças manuais acidentais, rotação de secrets ou atualizações automáticas de componentes do provedor. O fato de os 7 eventos serem idênticos nos três provedores confirma que todos vieram do repositório ou da aplicação, não da infraestrutura de cada provedor. Em todos os casos, o ArgoCD detectou e corrigiu a divergência automaticamente no próximo ciclo de sincronização de 3 minutos, sem intervenção humana, garantindo a consistência do ambiente.

A disponibilidade de 100% durante os deploys é o resultado operacionalmente mais significativo. Zero downtime em 114 deploys totais (38 por provedor), incluindo os 6 rollbacks automáticos, demonstra que a estratégia canary com análise automática de métricas cumpre sua promessa: atualização contínua da aplicação sem nenhuma interrupção perceptível ao usuário final. A redução estimada de 83–87% frente a processos manuais foi calculada com base no tempo médio do processo equivalente feito à mão, estimado em 28 a 30 minutos por deploy. Frente a esse tempo de referência, lead times de 3m52s a 4m38s representam uma aceleração que, multiplicada por 38 deploys, equivale a 15,6 horas de trabalho operacional eliminado por provedor.

Síntese e comparativo geral multicloud

A avaliação comparativa multicloud nas seis dimensões operacionais testadas revela que os três provedores gerenciados de Kubernetes entregam desempenho operacional equivalente. Os polígonos no diagrama radar são próximos em todas as dimensões, indicando que nenhum provedor é expressivamente superior ou inferior aos demais em nenhum eixo. Isso constitui o resultado central do estudo: o Kubernetes, independentemente do provedor, oferece um desempenho operacional consistente para escalabilidade, automação e resiliência em ambientes de pequeno e médio porte, conforme o objetivo da pesquisa.

As diferenças observadas, embora existam, estão concentradas em pontos específicos. O GCP GKE apresentou vantagem em tolerância a falhas e escalabilidade devido ao Node Problem Detector nativo e à maior frequência do Metrics Server. O AWS EKS se diferenciou pelo custo do control plane de USD 72/mês, ausente no GCP GKE e Azure AKS. O Azure AKS ficou marginalmente abaixo de 99% de disponibilidade durante falha de nó, o que tem implicações para ambientes com SLA contratual estrito. Essas nuances, embora mensuráveis, não comprometem a funcionalidade central da plataforma em nenhum dos provedores.

A síntese dos resultados das quatro semanas de experimentos reforça que nenhum dos três provedores falhou em qualquer dimensão relevante. O GCP GKE demonstrou uma vantagem quantitativa consistente, o AWS EKS se destacou pelo Karpenter e pela profundidade de seu ecossistema, e o Azure AKS entregou desempenho plenamente aceitável, com um diferencial estratégico em ambientes Microsoft. A escolha entre os provedores deve ser guiada pelo ecossistema organizacional, pela competência da equipe e pelo custo total de operação, e não pelas diferenças de dezenas de milissegundos registradas neste experimento, que são de baixa magnitude para a maioria dos casos de uso.

Em suma, os experimentos confirmaram que o Kubernetes cumpre sua promessa central nos três provedores: escalabilidade automática, recuperação autônoma de falhas e entrega contínua sem downtime, todos dentro de margens operacionalmente aceitáveis para ambientes de pequeno e médio porte. As diferenças entre provedores são mensuráveis e impactam a velocidade de reação e o custo, mas não definem qual é o melhor provedor de forma absoluta. Em vez disso, elas indicam qual provedor é mais adequado para cada contexto organizacional específico, fornecendo dados comparativos robustos para decisões baseadas em evidências, conforme o objetivo principal deste estudo.

4. Conclusão

Este estudo analisou e comparou, de forma teórica e experimental, o comportamento do Kubernetes nos três principais provedores gerenciados de nuvem — AWS EKS, GCP GKE e Azure AKS — em termos de escalabilidade, automação e resiliência. Verificou-se que a plataforma cumpriu sua promessa central em todos os ambientes, demonstrando escalabilidade automática com quedas de latência P95 entre 46% e 49% sob carga crescente, recuperação autônoma de falhas em 90 a 130 segundos e disponibilidade acima de 98% mesmo em cenários de interrupção de nó. Observou-se que o pipeline de deploy contínuo, implementado com ArgoCD e Argo Rollouts, permitiu a entrega de atualizações sem downtime, com uma redução estimada de 83% a 87% no tempo de deploy em comparação com processos manuais. As diferenças entre os provedores, embora mensuráveis, como a vantagem do GCP GKE na velocidade de detecção de falhas e a necessidade de mais configuração no Azure AKS, não comprometeram a funcionalidade essencial da plataforma. Identificou-se que a portabilidade multicloud é parcial, estendendo-se à camada de aplicação, mas não à rede e aos autoscalers, cujos comportamentos permanecem específicos de cada provedor. Os desafios operacionais encontrados, como configuração de RBAC, Ingress e dimensionamento de recursos, refletem obstáculos já documentados na literatura, validando a relevância prática dos achados.

Este trabalho apresenta algumas limitações, incluindo a ausência de testes com GPUs, service mesh, múltiplas regiões por provedor ou workloads stateful intensivos em I/O. A máquina de testes utilizada em us-east-1 introduziu uma assimetria de latência de rede que não pôde ser completamente eliminada, e os dados de custo refletem os preços de setembro a dezembro de 2025. Como sugestão para estudos futuros, propõe-se a expansão da pesquisa para clusters maiores, utilizando o Cilium como CNI uniforme para eliminar a variável de rede nativa, e a avaliação do impacto de ferramentas como K8sGPT no tempo de resolução de incidentes. A principal contribuição deste estudo reside em fornecer dados comparativos robustos, obtidos sob condições controladas, que podem embasar decisões estratégicas sobre a escolha de provedores de Kubernetes, superando a dependência de suposições ou materiais de fornecedores.

Referências Bibliográficas

Brewer, E.A. 2015. Kubernetes and the path to cloud native. ACM Symposium on Cloud Computing, Santa Clara, CA, USA. p. 167-175.

CNCF. 2024. CNCF annual survey 2024. Disponível em: https://www.cncf.io/reports/. Acesso em: 10 abr. 2025.

Hightower, K.; Burns, B.; Beda, J. 2022. Kubernetes: up and running. 3.ed. O’Reilly Media

Lewis, J.; Fowler, M. 2014. Microservices: a definition of this new architectural term. Disponível em: https://martinfowler.com/articles/microservices.html. Acesso em: 10 abr. 2025.

Merkel, D. 2014. Docker: lightweight Linux containers for consistent development and deployment. Linux Journal 239: 2.

Newman, S. 2015. Building microservices: designing fine-grained systems. O’Reilly Media, Sebastopol, CA, USA.

Verma, A.; Pedrosa, L.; Korupolu, M.; Oppenheimer, D.; Tune, E.; Wilkes, J. 2015. Large-scale cluster management at Google with Borg. Proceedings of the 10th European Conference on Computer Systems (EuroSys). p. 1-17.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy