O Kubernetes em si é a mesma plataforma, seja no EKS da AWS ou no AKS do Azure. Os manifestos YAML que descrevem Deployments, Services, ConfigMaps e HPAs funcionam sem modificação entre os dois. O que muda são as integrações com a nuvem subjacente — e é aí que o AKS tem características próprias que valem conhecer.
Este artigo cobre a criação de um cluster AKS com Terraform, a integração com Microsoft Entra ID para autenticação, o Workload Identity como substituto do IRSA da AWS, o KEDA (Kubernetes Event-Driven Autoscaling) para escalonamento baseado em eventos do Azure Service Bus, e o GitOps com Flux — a alternativa nativa ao ArgoCD amplamente usada no ecossistema Azure.
AKS vs. EKS: As Diferenças que Importam
Ambos os serviços gerenciam o control plane do Kubernetes, mas com modelos ligeiramente diferentes.
No EKS, o control plane tem custo fixo por hora (aproximadamente USD 0,10/hora), independentemente do número de nós. Os nós são instâncias EC2 gerenciadas pelo usuário ou pelo EKS Managed Node Groups. O Karpenter é o provisionador de nós recomendado para escalonamento rápido.
No AKS, o control plane é gratuito no tier Free (sem SLA de uptime garantido) e tem custo no tier Standard (SLA de 99,95% para o API server). Os nós são Azure VMs em Node Pools. O escalonamento de nós é feito pelo Cluster Autoscaler nativo, e o KEDA cuida do escalonamento de pods baseado em eventos.
O AKS Free Tier é especialmente útil para ambientes de desenvolvimento e staging — o control plane gratuito representa uma economia significativa comparada ao EKS, que cobra pelo control plane independentemente do ambiente.
Provisionando um Cluster AKS com Terraform
O cluster AKS no Terraform é declarado com o recurso azurerm_kubernetes_cluster. Os pontos mais importantes são: o sku_tier = "Standard" para o SLA de produção; o automatic_channel_upgrade = "patch" para atualizações automáticas de segurança; o default_node_pool com only_critical_addons_enabled = true reservando esse pool apenas para componentes do sistema; e o oidc_issuer_enabled = true com workload_identity_enabled = true que habilita o equivalente ao OIDC do EKS para o Workload Identity.
A rede é configurada com o profile azure e network_plugin_mode = "overlay" — o Azure CNI Overlay é recomendado para clusters grandes pois não consome IPs da VNet para cada pod, diferente do CNI tradicional. A integração com Entra ID é declarada no bloco azure_active_directory_role_based_access_control com azure_rbac_enabled = true e um grupo de administradores.
Os node pools de aplicação são declarados separadamente com azurerm_kubernetes_cluster_node_pool. A boa prática no AKS é manter node pools distintos para o sistema e para as aplicações — o pool do sistema tem o taint implícito CriticalAddonsOnly, garantindo que workloads de aplicação não compitam com componentes do cluster. Um terceiro pool Spot com priority = "Spot" e min_count = 0 permite escalar para zero quando não há carga, zerando custos de compute em horários de baixa.
Para autenticar o kubectl no AKS, usa-se az aks get-credentials — equivalente ao aws eks update-kubeconfig do EKS. O kubelogin é o componente que faz a autenticação interativa via Entra ID, equivalente ao aws-iam-authenticator do EKS.
Workload Identity: O IRSA do Azure
No EKS, o IRSA (IAM Roles for Service Accounts) permitia que pods assumissem IAM Roles sem credenciais hardcoded — bastava anotar a ServiceAccount com o ARN do role. O AKS tem o equivalente chamado Workload Identity, que usa o mesmo mecanismo OIDC por baixo mas com a sintaxe do ecossistema Azure.
O fluxo é o mesmo: o cluster emite tokens OIDC para os pods, a Azure aceita esses tokens como prova de identidade e emite tokens de acesso aos recursos Azure solicitados.
Na AWS com IRSA, cria-se um IAM Role com trust policy apontando para o OIDC provider do EKS e um Condition restringindo ao namespace e ServiceAccount específicos. A ServiceAccount é anotada com o ARN do role.
No Azure com Workload Identity, cria-se uma User Assigned Managed Identity, depois um Federated Identity Credential que liga a ServiceAccount Kubernetes à identidade (declarando o issuer como o URL OIDC do cluster e o subject como system:serviceaccount:namespace:nome-da-sa). A ServiceAccount é anotada com o client-id da Managed Identity. O Deployment precisa do label azure.workload.identity/use: "true" para que os webhooks do Workload Identity injetem as variáveis de ambiente e o token no pod.
O SDK Azure para Node.js, Python, Java e outras linguagens detecta automaticamente o Workload Identity via variáveis de ambiente — new DefaultAzureCredential() funciona sem configuração adicional tanto em desenvolvimento (usando a CLI do Azure) quanto em produção (usando o Workload Identity).
Para montar secrets do Key Vault diretamente como variáveis de ambiente ou arquivos no pod, usa-se o recurso SecretProviderClass do Secrets Store CSI Driver — habilitado no AKS via o bloco key_vault_secrets_provider no Terraform.
KEDA: Escalonamento Baseado em Eventos
O KEDA (Kubernetes Event-Driven Autoscaling) é um componente open-source criado pela Microsoft e Red Hat que estende o HPA do Kubernetes para escalonar pods baseado em fontes de eventos externas — não apenas CPU e memória.
No EKS, o escalonamento baseado em tamanho de fila SQS requer configurar métricas customizadas no CloudWatch, expô-las via adapter e configurar o HPA — um processo relativamente complexo. No AKS com KEDA, a integração com Azure Service Bus é nativa e declarativa.
O KEDA é instalado via Helm com kedacore/keda no namespace keda. A autenticação com os serviços Azure é configurada via TriggerAuthentication com provider: azure-workload — sem connection strings estáticas. O ScaledObject declara o Deployment alvo, os limites de réplicas (minReplicaCount: 0 para scale to zero) e os triggers. Para Service Bus, o trigger especifica o namespace, o nome da fila e a proporção de mensagens por réplica — por exemplo, messageCount: "100" cria uma nova réplica para cada 100 mensagens na fila.
O KEDA suporta dezenas de scalers além do Service Bus: Azure Storage Queue, Azure Event Hubs, Redis, PostgreSQL, MySQL, HTTP requests, métricas do Prometheus e muitos outros. Essa flexibilidade é uma das razões pelas quais o KEDA se tornou padrão de facto em clusters Kubernetes independentemente da nuvem.
Azure Container Registry (ACR)
O Azure Container Registry é o equivalente do Amazon ECR. A integração com o AKS é nativa: basta uma azurerm_role_assignment atribuindo o role AcrPull ao kubelet_identity do cluster. Após isso, o Kubernetes faz pull de imagens do ACR sem image pull secrets configurados nos pods.
O SKU Premium do ACR oferece geo-replicação (disponibilidade global das imagens com baixa latência), scan de vulnerabilidades automático ao fazer push, e políticas de retenção de imagens. O az acr build permite fazer build da imagem diretamente no ACR sem precisar de Docker local — o build roda em infraestrutura gerenciada da Microsoft.
GitOps com Flux no AKS
No currículo principal, o GitOps foi implementado com ArgoCD. No ecossistema Azure, a alternativa nativa e igualmente popular é o Flux — o outro projeto de GitOps da CNCF. O AKS oferece Flux como extensão gerenciada, eliminando a necessidade de instalar e manter o Flux manualmente.
A extensão é instalada via azurerm_kubernetes_cluster_extension com extension_type = "microsoft.flux". A configuração do GitOps é declarada com azurerm_kubernetes_flux_configuration, apontando para um repositório Git (URL, branch, intervalo de sync) e definindo Kustomizations — subpaths do repositório para aplicar. É possível declarar dependências entre Kustomizations (apps dependem de infraestrutura estar sincronizada primeiro).
No repositório GitOps, o Flux usa dois recursos principais: HelmRelease para instalar charts Helm (equivalente ao ArgoCD Application com source do tipo Helm) e Kustomization para aplicar manifestos YAML organizados com Kustomize. O prune: true garante que recursos removidos do Git sejam deletados do cluster — equivalente ao syncPolicy.automated.prune do ArgoCD.
Monitoramento com Azure Monitor e KQL
O KQL (Kusto Query Language) é a linguagem de query do Log Analytics Workspace — mais poderosa que o CloudWatch Insights. Queries úteis para operação do AKS incluem: listar pods em estado não-Running nos últimos 30 minutos (KubePodInventory | where PodStatus != "Running"); calcular uso de CPU por namespace com Perf e agregação por bin de tempo; detectar evictions com KubeEvents | where Reason == "Evicted"; e identificar containers com muitas reinicializações com KubePodInventory | where RestartCount > 3.
Referências para Aprofundamento
— O Que É o Azure Kubernetes Service: https://learn.microsoft.com/pt-br/azure/aks/what-is-aks — Workload Identity no AKS: https://learn.microsoft.com/pt-br/azure/aks/workload-identity-overview — KEDA — Azure Service Bus Scaler: https://keda.sh/docs/2.14/scalers/azure-service-bus/ — Conceitos do Flux: https://fluxcd.io/flux/concepts/ — Introdução ao Azure Container Registry: https://learn.microsoft.com/pt-br/azure/container-registry/container-registry-intro — azurerm_kubernetes_cluster no Terraform Registry: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster