O que é AKS e por que dominar sua integração?
Azure Kubernetes Service (AKS) é uma plataforma gerenciada que simplifica a implantação, administração e operações do Kubernetes no Azure. Diferentemente de gerenciar um cluster Kubernetes manualmente, o AKS cuida da camada de controle (control plane), deixando você responsável apenas pelos nós de trabalho e pela orquestração de suas aplicações. Quando você integra AKS com Azure Active Directory (AAD), Azure Container Registry (ACR) e Azure Monitor, cria um ecossistema robusto onde autenticação, armazenamento de imagens e observabilidade funcionam em harmonia.
A integração desses três serviços resolve problemas críticos: controle de acesso baseado em identidade corporativa (AAD), pull de imagens de forma segura sem expor credenciais (ACR), e visibilidade completa do comportamento de suas aplicações em produção (Monitor). Este artigo o guiará através de cada integração com exemplos práticos que você pode aplicar imediatamente.
Integração com Azure Active Directory (AAD)
Por que integrar AAD ao AKS?
Quando você integra AAD ao AKS, habilita autenticação e autorização baseadas em identidades corporativas. Seus desenvolvedores se autenticam no cluster usando suas credenciais corporativas, eliminando a necessidade de gerenciar certificados e tokens manualmente. Além disso, você pode granularizar permissões usando Role-Based Access Control (RBAC) nativo do Kubernetes, vinculado aos grupos do AAD.
Configurando integração com AAD
Primeiro, você precisa criar um cluster AKS com AAD integrado ou habilitar em um existente. Vou mostrar como criar um novo cluster com essa configuração:
#!/bin/bash
# Variáveis
RESOURCE_GROUP="meu-rg"
CLUSTER_NAME="meu-aks"
LOCATION="eastus"
AAD_TENANT_ID="seu-tenant-id"
AAD_ADMIN_GROUP_ID="seu-grupo-aad-id"
# Criar Resource Group
az group create --name $RESOURCE_GROUP --location $LOCATION
# Criar cluster AKS com AAD integrado
az aks create \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--location $LOCATION \
--enable-aad \
--aad-admin-group-object-ids $AAD_ADMIN_GROUP_ID \
--aad-tenant-id $AAD_TENANT_ID \
--node-count 2 \
--vm-set-type VirtualMachineScaleSets \
--enable-managed-identity
Após criar o cluster, você obtém credenciais para acessá-lo. A primeira vez que um usuário tenta acessar o cluster via kubectl, ele é redirecionado para autenticação AAD:
# Obter credenciais do cluster
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --overwrite-existing
# Na primeira execução, você será solicitado a fazer login no navegador
kubectl get nodes
Configurando RBAC com AAD
Depois da autenticação, você controla o que cada usuário pode fazer usando RBAC. Crie um ClusterRoleBinding que atribua um grupo do AAD a um papel (role) específico:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: aks-developers-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: edit
subjects:
- kind: Group
name: "aks-developers@seudominio.com"
apiGroup: rbac.authorization.k8s.io
Aplique este manifesto no seu cluster:
kubectl apply -f clusterrolebinding.yaml
Agora, qualquer membro do grupo aks-developers pode editar recursos (pods, deployments, etc.) no cluster, mas não pode criar ou deletar namespaces ou gerenciar RBAC.
Integração com Azure Container Registry (ACR)
A necessidade de pull seguro de imagens
Quando você executa containers no AKS, precisa que o cluster puxe imagens de algum lugar. O ACR é o registro de imagens nativo do Azure, integrado perfeitamente com AKS. A vantagem: você não precisa armazenar credenciais docker em secrets do Kubernetes. Em vez disso, usa Managed Identity, um mecanismo seguro onde o cluster se autentica automaticamente.
Criando um ACR e integrando ao AKS
Primeiro, crie um Azure Container Registry:
#!/bin/bash
ACR_NAME="meuregistry"
RESOURCE_GROUP="meu-rg"
LOCATION="eastus"
CLUSTER_NAME="meu-aks"
# Criar ACR
az acr create \
--resource-group $RESOURCE_GROUP \
--name $ACR_NAME \
--sku Standard \
--location $LOCATION
# Habilitar integração entre AKS e ACR
az aks update \
--name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--attach-acr $ACR_NAME
Esse comando automaticamente configura o Managed Identity do AKS para ter permissão de pull no ACR. Nenhuma credencial extra necessária.
Fazendo push de imagens e testando o pull
Faça login no ACR e envie uma imagem de teste:
#!/bin/bash
ACR_NAME="meuregistry"
RESOURCE_GROUP="meu-rg"
# Fazer login no ACR
az acr login --name $ACR_NAME
# Build de uma imagem local (exemplo simples)
cat > Dockerfile << 'EOF'
FROM nginx:latest
RUN echo "Hello from AKS" > /usr/share/nginx/html/index.html
EOF
docker build -t minha-imagem:v1 .
# Tag da imagem com o repositório ACR
docker tag minha-imagem:v1 $ACR_NAME.azurecr.io/minha-imagem:v1
# Push para ACR
docker push $ACR_NAME.azurecr.io/minha-imagem:v1
Agora, crie um deployment no AKS que puxe essa imagem:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: meuregistry.azurecr.io/minha-imagem:v1
ports:
- containerPort: 80
kubectl apply -f deployment.yaml
# Verificar se os pods estão rodando
kubectl get pods
Graças à integração Managed Identity, o AKS puxou a imagem do ACR sem você ter criado nenhum ImagePullSecret.
Integração com Azure Monitor para Observabilidade
O tripé da observabilidade: logs, métricas e traces
Azure Monitor é a plataforma de observabilidade do Azure. Quando integrado ao AKS, coleta logs de seus containers, métricas de CPU/memória, eventos do cluster e muito mais. Essa visibilidade é crítica em produção: você sabe quando algo está errado antes que seus usuários reclamem.
Habilitando Container Insights no AKS
Container Insights é a solução de monitoramento específica para containers. Habilite durante a criação do cluster ou em um cluster existente:
#!/bin/bash
RESOURCE_GROUP="meu-rg"
CLUSTER_NAME="meu-aks"
# Se o cluster já existe, habilitar Container Insights
az aks enable-addons \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--addons monitoring \
--workspace-resource-id "/subscriptions/SEU_ID_SUBSCRIPTION/resourcegroups/$RESOURCE_GROUP/providers/microsoft.operationalinsights/workspaces/SEU_WORKSPACE"
Se você não tem um Log Analytics Workspace, crie um:
WORKSPACE_NAME="meu-workspace"
az monitor log-analytics workspace create \
--resource-group $RESOURCE_GROUP \
--workspace-name $WORKSPACE_NAME
Consultando logs e métricas
Depois de habilitar, o Container Insights começa a coletar dados. Você pode consultar tudo via Azure Portal ou usar queries KQL (Kusto Query Language). No portal, vá para seu cluster AKS → Insights.
Para consultas avançadas, use o Log Analytics Workspace diretamente:
// Listar todos os pods e seu uso de CPU/memória
ContainerInventory
| where TimeGenerated > ago(1h)
| join kind=inner (Perf | where ObjectName == "K8SContainer") on ContainerID
| project ContainerName, PodName, CpuPercent, MemoryRss
| sort by CpuPercent desc
// Contar restarts de containers nos últimos 24h
ContainerInventory
| where TimeGenerated > ago(24h)
| where ContainerState == "Restarting"
| summarize RestartCount = count() by ContainerName, PodName
Alertas baseados em métricas
Crie um alerta que o notifique quando um pod consome mais de 80% de CPU:
#!/bin/bash
ALERT_NAME="alert-cpu-alto"
RESOURCE_GROUP="meu-rg"
CLUSTER_NAME="meu-aks"
WORKSPACE_RESOURCE_ID="/subscriptions/SEU_ID/resourcegroups/$RESOURCE_GROUP/providers/microsoft.operationalinsights/workspaces/meu-workspace"
az monitor metrics alert create \
--name $ALERT_NAME \
--resource-group $RESOURCE_GROUP \
--scopes $WORKSPACE_RESOURCE_ID \
--condition "avg Percentage CPU > 80" \
--window-size 5m \
--evaluation-frequency 1m \
--action email-receiver --email seu@email.com
Enviando logs customizados de sua aplicação
Sua aplicação pode enviar logs estruturados para o Monitor. Use a Application Insights SDK em sua linguagem favorita. Aqui está um exemplo em Python:
from applicationinsights import TelemetryClient
import os
# Obter a chave de instrumentação do Application Insights
instrumentation_key = os.getenv("APPINSIGHTS_INSTRUMENTATION_KEY")
client = TelemetryClient(instrumentation_key)
# Registrar um evento de negócio
client.track_event("PedidoProcessado", {"id_pedido": "12345", "valor": 99.99})
# Registrar uma métrica customizada
client.track_metric("TempoProcessamento", 150) # em ms
# Registrar um erro
try:
1 / 0
except Exception as e:
client.track_exception()
# Enviar dados
client.flush()
Configure a variável de ambiente no seu deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: minha-app
spec:
replicas: 1
selector:
matchLabels:
app: minha-app
template:
metadata:
labels:
app: minha-app
spec:
containers:
- name: app
image: meuregistry.azurecr.io/minha-app:v1
env:
- name: APPINSIGHTS_INSTRUMENTATION_KEY
valueFrom:
secretKeyRef:
name: appinsights-secret
key: instrumentation-key
ports:
- containerPort: 8000
Crie o secret com a chave:
INSTRUMENTATION_KEY="seu-chave-aqui"
kubectl create secret generic appinsights-secret \
--from-literal=instrumentation-key=$INSTRUMENTATION_KEY
Colocando tudo junto: um cenário real
Você tem uma aplicação Python que processa pedidos. Quer rodar no AKS com segurança corporativa (AAD), imagens armazenadas seguramente (ACR) e monitoramento completo (Monitor). Aqui está o fluxo completo:
-
Desenvolvedor faz login: Autentica via AAD. Seu grupo corporativo tem permissão de deploy no namespace "production".
-
Pipeline CI/CD: Build da aplicação, tag com versão, push para ACR automaticamente.
-
Deploy no AKS: Kubernetes pull da imagem do ACR usando Managed Identity. Nenhuma credencial exposta.
-
Telemetria em tempo real: Aplicação envia logs e métricas para Application Insights. Você vê erros, latência, uso de recursos em um dashboard unificado.
Esse é o padrão moderno de entrega segura e observável de software no Azure.
Conclusão
Dominar a integração entre AKS, AAD, ACR e Azure Monitor significa que você não apenas roda containers, mas faz isso de forma segura, rastreável e eficiente. O primeiro aprendizado é que Managed Identity elimina a necessidade de armazenar credenciais — é autenticação baseada em confiança entre serviços Azure. O segundo aprendizado é que RBAC granular com AAD permite governança real de acesso sem complexidade operacional. O terceiro aprendizado é que observabilidade não é opcional — logs, métricas e alertas bem configurados te colocam em controle, não em reação.