Azure Kubernetes Service
ORIENTAÇÃO AUTORITATIVA — CONFORMIDADE OBRIGATÓRIA
Este skill produz uma configuração de cluster AKS recomendada com base nos requisitos do usuário, distinguindo decisões de Day-0 (rede, servidor de API — difíceis de alterar posteriormente) de recursos de Day-1 (podem ser habilitados após a criação). Consulte a referência da CLI para comandos.
Referência Rápida
| Propriedade | Valor |
|---|---|
| Melhor para | Planejamento de cluster AKS e decisões de Day-0 |
| Ferramentas MCP | mcp_azure_mcp_aks |
| CLI | az aks create, az aks show, kubectl get, kubectl describe |
| Skills relacionados | azure-diagnostics (solução de problemas no AKS), azure-validate (verificações de preparação) |
Quando Usar Este Skill
Ative este skill quando o usuário quiser:
- Criar um novo cluster AKS
- Planejar a configuração do cluster AKS para cargas de trabalho de produção
- Projetar a rede do AKS (acesso ao servidor de API, modelo de IP de pod, egress)
- Configurar identidade e gerenciamento de segredos no AKS
- Configurar governança do AKS (Azure Policy, Deployment Safeguards)
- Habilitar observabilidade no AKS (Container Insights, Prometheus Gerenciado, Grafana)
- Definir estratégia de upgrade e patching do AKS
- Habilitar visibilidade e análise de custos no AKS
- Entender as diferenças entre os SKUs AKS Automático vs Standard
- Obter um checklist Day-0 para configuração e criação do cluster AKS
Regras
- Comece com os requisitos do usuário para provisionar computação, rede, segurança e outras configurações.
- Use o servidor MCP
azuree selecionemcp_azure_mcp_aksprimeiro para descobrir as ferramentas MCP específicas do AKS expostas pelo cliente. Escolha a menor ferramenta AKS descoberta que atenda à tarefa e recorra à CLI do Azure (az aks) apenas quando a funcionalidade necessária não estiver exposta através da superfície MCP do AKS. - Determine se o SKU AKS Automático ou Standard é mais apropriado com base na necessidade do usuário por controle versus conveniência. Padrão: AKS Automático, a menos que personalizações específicas sejam necessárias.
- Documente as decisões e a justificativa para as escolhas de configuração do cluster, especialmente para decisões de Day-0 que são difíceis de alterar posteriormente (rede, acesso ao servidor de API).
Entradas Necessárias (Pergunte apenas o que for necessário)
Se o usuário estiver inseguro, use padrões seguros.
- Tipo de ambiente AKS: dev/test ou produção
- Região(ões), zonas de disponibilidade, tamanhos de VM de nó preferidos
- Escala esperada (número de nós/cluster, tamanho da carga de trabalho)
- Requisitos de rede (acesso ao servidor de API, modelo de IP de pod, controle de entrada/saída)
- Requisitos de segurança e identidade, incluindo registro de imagem
- Preferências de upgrade e observabilidade
- Restrições de custo
Fluxo de Trabalho
1. Tipo de Cluster
- AKS Automático (padrão): Melhor para a maioria das cargas de trabalho de produção, oferece uma experiência curada com práticas recomendadas pré-configuradas para segurança, confiabilidade e desempenho. Use a menos que você tenha requisitos personalizados específicos para rede, auto scaling ou configurações de pool de nós não suportados pelo Node Auto-Provisioning (NAP).
- AKS Standard: Use se você precisar de controle total sobre a configuração do ambiente, o que requer sobrecarga adicional para configurar e gerenciar.
2. Rede (IP de Pod, Egress, Ingress, Dataplane)
Modelo de IP de Pod (decisão chave de Day-0):
- Azure CNI Overlay (recomendado): IPs de pod de um intervalo de overlay privado, não roteáveis na VNet, escala para ambientes grandes e é bom para a maioria das cargas de trabalho
- Azure CNI (roteável na VNet): IPs de pod diretamente da VNet (sub-rede de pod ou sub-rede de nó), use quando os pods precisarem ser diretamente endereçáveis a partir da VNet ou on-premises
- Documentação: https://learn.microsoft.com/azure/aks/azure-cni-overlay
Dataplane e Política de Rede:
- Azure CNI com Cilium (recomendado): baseado em eBPF para processamento de pacotes de alto desempenho, políticas de rede e observabilidade
Egress:
- Static Egress Gateway para IPs de saída estáveis e previsíveis
- Para egress restrito: UDR + Azure Firewall ou NVA
Ingress:
- Complemento App Routing com Gateway API — padrão recomendado para cargas de trabalho HTTP/HTTPS
- Istio service mesh com Gateway API — para gerenciamento de tráfego avançado, mTLS, lançamentos canary
- Application Gateway for Containers — para balanceamento de carga L7 com integração WAF
DNS:
- Habilite LocalDNS em todos os pools de nós para resolução de DNS confiável e de alto desempenho
3. Segurança
- Use Microsoft Entra ID em todos os lugares (plano de controle, Workload Identity para pods, acesso a nós). Evite credenciais estáticas.
- Azure Key Vault via Secrets Store CSI Driver para segredos
- Habilite Azure Policy + Deployment Safeguards
- Habilite Criptografia em repouso para etcd/servidor de API; em trânsito para nó a nó
- Permita apenas imagens assinadas e aprovadas por política (Azure Policy + Ratify), prefira Azure Container Registry
- Isolamento: Use namespaces, políticas de rede, logs com escopo
4. Observabilidade
- Use Prometheus Gerenciado e Container Insights com Grafana para observabilidade do AKS (logs + métricas).
- Habilite as Configurações de Diagnóstico para coletar logs do plano de controle e logs de auditoria em um workspace do Log Analytics para monitoramento de segurança e solução de problemas.
- Para outras ferramentas de monitoramento e solução de problemas, use recursos como o Agentic CLI para AKS, Application Insights, Resource Health Center, detectores AppLens e Azure Advisors.
5. Upgrades e Patching
- Configure Janelas de Manutenção para controle de tempo de upgrade
- Habilite auto-upgrades para o plano de controle e SO do nó para manter-se atualizado com patches de segurança e versões do Kubernetes
- Considere versões LTS para estabilidade empresarial (suporte de 2 anos) atualizando seu ambiente AKS para o nível Premium
- Upgrades em frota: Use AKS Fleet Manager para implantação em estágios entre ambientes de teste e produção
6. Desempenho
- Use discos de SO efêmeros (
--node-osdisk-type Ephemeral) para inicialização mais rápida do nó - Selecione Azure Linux como SO do nó (pegada menor, inicialização mais rápida)
- Habilite KEDA para auto scaling orientado a eventos além do HPA
7. Pools de Nós e Computação
- Pool de nós de sistema dedicado: Pelo menos 2 nós, taintados apenas para cargas de trabalho do sistema (
CriticalAddonsOnly) - Habilite Node Auto Provisioning (NAP) em todos os pools para economia de custos e scaling responsivo
- Use SKUs da geração mais recente (v5/v6) para otimizações em nível de host
- Evite VMs da série B — SKUs burstáveis causam problemas de desempenho/confiabilidade
- Use SKUs com pelo menos 4 vCPUs para cargas de trabalho de produção
- Defina restrições de distribuição de topologia para distribuir pods entre hosts/zonas de acordo com o SLO
8. Confiabilidade
- Implante em 3 Zonas de Disponibilidade (
--zones 1 2 3) - Use o nível Standard para plano de controle com redundância de zona + SLA de 99,95% para disponibilidade do servidor de API
- Habilite Microsoft Defender for Containers para proteção em tempo de execução
- Configure PodDisruptionBudgets para todas as cargas de trabalho de produção
- Use restrições de distribuição de topologia para garantir a distribuição de pods entre domínios de falha
9. Controles de Custos
- Use pools de nós Spot para cargas de trabalho em lote/interruptíveis (economia de até 90%)
- Parar/Iniciar clusters dev/test:
az aks stop/start - Considere Instâncias Reservadas ou Planos de Economia para cargas de trabalho de estado estável
Guardrails / Segurança
- Não solicite nem produza segredos (tokens, chaves).
- Se os requisitos forem ambíguos para decisões críticas de Day-0, faça perguntas esclarecedoras ao usuário. Para recursos habilitados em Day-1, proponha 2 a 3 opções seguras com trade-offs e escolha um padrão conservador.
- Não prometa tempo de inatividade zero; aconselhe salvaguardas de carga de trabalho (PDBs, probes, réplicas) e upgrades em estágios, juntamente com práticas recomendadas de confiabilidade e desempenho.
Ferramentas MCP
| Ferramenta | Propósito | Parâmetros Chave |
|---|---|---|
mcp_azure_mcp_aks | Ponto de entrada MCP do AKS usado para descobrir as ferramentas exatas específicas do AKS expostas pelo cliente | Descubra primeiro a ferramenta AKS chamável e, em seguida, use os parâmetros dessa ferramenta |
Tratamento de Erros
| Erro / Sintoma | Causa Provável | Remediação |
|---|---|---|
| A chamada da ferramenta MCP falha ou expira | Credenciais inválidas, assinatura ou contexto AKS | Verifique az login, confirme o contexto de assinatura ativo com az account show e verifique o grupo de recursos de destino sem ecoar identificadores de assinatura de volta ao usuário |
| Cota excedida | Limites regionais de vCPU ou recursos | Solicite aumento de cota ou selecione região/SKU de VM diferente |
| Conflito de rede (esgotamento de IP) | Sub-rede de pod muito pequena para overlay/CNI | Replaneje os intervalos de IP; pode exigir recriação do cluster (Day-0) |
| Workload Identity não funcionando | Emissor OIDC ou credencial federada ausente | Habilite --enable-oidc-issuer --enable-workload-identity, configure a identidade federada |