Configurar aplicações no AKS com ConfigMaps, Segredos e armazenamento persistente

radio_button_uncheckedshort_text1. Externalizar estado sem perder segurança ou confiabilidade

Uma API de inferência costuma mudar endpoints e sinalizadores entre ambientes, autenticar-se em serviços de modelo ou dados e gravar embeddings, cache, conversas, uploads ou logs. Embutir isso na imagem acopla configuração à release, expõe credenciais e perde dados quando o Pod é substituído.

O AKS separa essas responsabilidades. ConfigMaps guardam valores não confidenciais, Segredos representam dados sensíveis e PersistentVolumes com PersistentVolumeClaims fornecem armazenamento fora do sistema de arquivos do contêiner. O resultado são rollouts previsíveis, governança e cargas de IA com estado que sobrevivem a reinícios e reagendamentos.

• Injetar ConfigMaps como variáveis ou arquivos montados.
• Referenciar Segredos do Kubernetes ou serviços centralizados do Azure.
• Solicitar capacidade durável por PVC e StorageClass.
• Aplicar e verificar configuração, credenciais e persistência com kubectl.

Resumo do tópico

Mantenha código e imagem estáveis enquanto configuração, credenciais e dados duráveis seguem ciclos independentes.

radio_button_uncheckedshort_text2. Definir ConfigMaps para configurações não confidenciais

ConfigMap é um objeto do Kubernetes com escopo de namespace cujo campo data armazena pares de chave e valor em texto. Serve para sinalizadores, endpoints, ajustes e arquivos de configuração, não para senhas ou tokens. Chaves aceitam caracteres alfanuméricos, hífen, sublinhado e ponto.

Cada ConfigMap está limitado a 1 MiB. Use binaryData para valores binários codificados em base64 quando necessário e volume persistente ou serviço externo para conteúdo maior. O limite preserva sincronização eficiente com nós e armazenamento no etcd.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings
data:
  FEATURE_X_ENABLED: "true"
  SERVICE_ENDPOINT: "https://api.example.com"
  app.config: |
    log_level=info
    timeout_seconds=30

Resumo do tópico

ConfigMaps externalizam configurações pequenas e não sensíveis; arquivos grandes e dados confidenciais pertencem a armazenamentos específicos.

radio_button_uncheckedshort_text3. Injetar chaves selecionadas ou todas as chaves como variáveis

configMapKeyRef associa uma chave a uma variável do contêiner. envFrom com configMapRef importa todas as chaves e reduz YAML repetitivo. Referências individuais são explícitas e permitem renomear variáveis; a importação em massa convém quando todas as chaves pertencem ao ambiente do processo.

env:
- name: FEATURE_X_ENABLED
  valueFrom:
    configMapKeyRef:
      name: app-settings
      key: FEATURE_X_ENABLED
# Load every key instead:
# envFrom:
# - configMapRef:
#     name: app-settings

volumes:
- name: config-volume
  configMap:
    name: app-settings
containers:
- name: api
  volumeMounts:
  - name: config-volume
    mountPath: /app/config
    readOnly: true

Variáveis são capturadas na inicialização. Alterar o ConfigMap não modifica contêineres existentes: é preciso rollout ou reinício. Valide com kubectl describe pod, printenv via kubectl exec e logs, sem revelar valores confidenciais.

Resumo do tópico

Use configMapKeyRef para chaves explícitas, envFrom para importação em massa e reinicie Pods quando valores de ambiente mudarem.

radio_button_uncheckedshort_text4. Montar ConfigMaps como arquivos e entender a atualização

Aplicações que esperam JSON, INI ou outro arquivo podem montar um volume baseado em ConfigMap. Cada chave vira um arquivo; items seleciona chaves e renomeia caminhos. Marque como somente leitura, pois o ConfigMap é a fonte da verdade.

O kubelet atualiza periodicamente o conteúdo de um volume normal após a alteração. A aplicação precisa observar ou reler o arquivo. Montagem subPath não recebe atualização automática e variáveis de ambiente nunca mudam no lugar. Teste o padrão exato antes de depender de atualização dinâmica.

Resumo do tópico

Monte arquivos quando a aplicação os espera, distinguindo atualização do volume, variáveis estáticas e subPath sem atualização.

radio_button_uncheckedshort_text5. ConfigMaps imutáveis e Configuração de Aplicativos centralizada

immutable: true impede alteração acidental e permite ao Kubernetes fechar watches, reduzindo carga da API. A imutabilidade não pode ser revertida e os dados não podem ser editados. Publique novo ConfigMap versionado e atualize a referência; reutilizar o nome exige excluir e recriar, enquanto Pods existentes preservam o mount antigo até reiniciar.

Para valores compartilhados entre aplicações, ambientes ou clusters, o provedor Kubernetes da Configuração de Aplicativos recupera valores e sinalizadores e gera ConfigMaps padrão. Ele também resolve referências ao Cofre de Chaves. As aplicações continuam consumindo variáveis ou arquivos enquanto a operação ganha visão centralizada.

Resumo do tópico

Use ConfigMaps imutáveis e versionados para valores ligados à release e Configuração de Aplicativos para gerenciamento central entre ambientes.

radio_button_uncheckedshort_text6. Criar e consumir Segredos do Kubernetes

Um Secret mantém chaves, strings de conexão e credenciais fora da imagem e da configuração comum. O tipo Opaque atende strings arbitrárias; kubernetes.io/dockerconfigjson representa credenciais de registro e kubernetes.io/tls representa certificados e chaves TLS. Segredos podem vir de literais, arquivos ou manifestos, mas um manifesto com valores reais não deve ir para o repositório.

kubectl create secret generic app-secrets   --from-literal=DB_CONNECTION="Host=db;User=app;Password=secure"   --from-literal=API_KEY="your-api-key"

kubectl get secrets
kubectl describe secret app-secrets
kubectl describe deployment web-api

env:
- name: DB_CONNECTION
  valueFrom:
    secretKeyRef:
      name: app-secrets
      key: DB_CONNECTION
- name: API_KEY
  valueFrom:
    secretKeyRef:
      name: app-secrets
      key: API_KEY

secretKeyRef injeta a chave quando o Pod inicia. O valor permanece em memória e não é gravado em disco por padrão. kubectl describe secret mostra metadados e nomes sem imprimir valores; kubectl describe deployment confirma a referência. RBAC deve restringir leitura e alteração a identidades necessárias.

Resumo do tópico

Escolha o tipo apropriado, use secretKeyRef, valide nomes sem imprimir dados e aplique RBAC de privilégio mínimo.

radio_button_uncheckedshort_text7. Rotação, criptografia e operação segura de Segredos

Base64 não é criptografia. Evite valores literais no Git, histórico do shell, logs e diagnósticos. Habilite criptografia em repouso dos dados do Kubernetes, limite acesso à API, rotacione credenciais e execute rollout quando consumidores por variável precisarem do novo valor.

• Conceda get, list, watch, create, update ou patch apenas quando necessário.
• Prefira identidade gerenciada e armazenamento externo em produção.
• Audite acessos e falhas de rotação e ensaie revogação emergencial.
• Nunca use ConfigMap para senha apenas porque ela é uma configuração.

Resumo do tópico

Segurança exige criptografia, RBAC, rotação, comportamento de rollout, auditoria e prevenção de exposição em código e logs.

radio_button_uncheckedshort_text8. CSI do Cofre de Chaves ou Configuração de Aplicativos com referências

O provedor do Cofre de Chaves para Secrets Store CSI Driver monta segredos diretamente no sistema de arquivos do Pod. Eles permanecem no cofre; identidade gerenciada ou Workload ID concede acesso. Rotação automática pode atualizar o mount e um Secret sincronizado opcional. Variável de ambiente baseada no Secret sincronizado ainda exige reinício do Pod.

Integração direta é ideal quando o segredo deve permanecer exclusivamente no cofre e cada acesso exige auditoria, rotação, rede privada e conformidade. O provedor Kubernetes da Configuração de Aplicativos pode manter referências ao Cofre de Chaves, resolvê-las e gerar Secrets nativos; escolha-o para mapear centralmente quais segredos cada aplicação recebe.

Resumo do tópico

Use CSI direto para segredos residentes e auditados no cofre; use Configuração de Aplicativos para mapeamento central entregue como recurso Kubernetes.

radio_button_uncheckedshort_text9. PersistentVolume, PersistentVolumeClaim e StorageClass

O sistema de arquivos do contêiner é efêmero. PersistentVolume representa armazenamento durável do cluster, PersistentVolumeClaim solicita capacidade e acesso e StorageClass identifica política e tecnologia. Com provisionamento dinâmico, aplicar o PVC faz o AKS criar e associar o armazenamento do Azure adequado; geralmente não é preciso escrever um PV manual.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: default

Dimensione capacidade e planeje crescimento e expansão compatível. A reivindicação fica Pending quando nenhuma classe ou volume atende tamanho, modo, topologia, cota ou requisitos. Bound não prova permissão da aplicação nem desempenho suficiente.

Resumo do tópico

PVC expressa a intenção da aplicação, StorageClass dirige o provisionamento e PV é o recurso durável associado fora do ciclo do Pod.

radio_button_uncheckedshort_text10. Escolher Disco, Arquivos, Blobs ou Armazenamento de contêineres do Azure

Drivers CSI expõem serviços do Azure pelo padrão Kubernetes. Armazenamento em Disco do Azure fornece bloco para um nó e atende banco ou estado de nó único. Arquivos do Azure oferece SMB ou NFS compartilhado entre nós e Pods. Armazenamento de Blobs do Azure pode ser montado para imagens, documentos, logs e mídia não estruturada.

Armazenamento de contêineres do Azure é opção gerenciada e nativa para blocos em cargas com estado, com operação pelo Kubernetes e anexação/desanexação rápida. Atende I/O intensivo ou escala rápida. Valide o pool: configurações de NVMe ou SSD local podem ser efêmeras, embora outros pools ofereçam persistência.

Resumo do tópico

Associe bloco, arquivo compartilhado, objeto ou armazenamento nativo à concorrência, latência, formato, durabilidade e custo.

radio_button_uncheckedshort_text11. Modos de acesso e StorageClasses CSI incorporadas

ReadWriteOnce permite montagem de leitura e gravação por um nó, não necessariamente por um único Pod. ReadWriteMany permite montagens simultâneas em nós diferentes. Classes de Disco usam RWO; classes de Arquivos oferecem RWX.

Resumo do tópico

Escolha RWO para bloco por nó e RWX para arquivos compartilhados e selecione Standard ou Premium por latência e vazão medidas.

radio_button_uncheckedshort_text12. Montar e comprovar persistência após substituir o Pod

O Pod declara volume com persistentVolumeClaim.claimName e o contêiner define volumeMount e mountPath. Confirme que o usuário da imagem pode ler e gravar; propriedade, permissões, security context, protocolo e identidade podem causar falha em execução.

spec:
  template:
    spec:
      volumes:
      - name: data-volume
        persistentVolumeClaim:
          claimName: data-pvc
      containers:
      - name: api
        image: myregistry.azurecr.io/web-api:v1
        volumeMounts:
        - name: data-volume
          mountPath: /app/data

kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl apply -f pvc.yaml
kubectl apply -f deployment.yaml
kubectl describe configmap app-settings
kubectl describe pvc data-pvc
kubectl describe pod -l app=web-api
kubectl exec <pod-name> -- printenv | grep FEATURE

1. Aplique o PVC antes ou junto do Deployment.
2. Confirme PVC Bound e Pod Running.
3. Grave arquivo identificável em /app/data.
4. Exclua o Pod e aguarde o substituto.
5. Leia o arquivo no novo Pod e faça pequeno teste de I/O.

Resumo do tópico

PVC Bound vira persistência comprovada quando o Pod substituto remonta, lê dados anteriores e atende a meta de I/O.

radio_button_uncheckedshort_text13. Laboratório guiado: configurar uma API no AKS

O exercício de cerca de 30 minutos implanta Registro de Contêiner do Azure e AKS, cria e envia a imagem, configura valores com ConfigMaps, credenciais com Secrets e logs com PVC, expõe por LoadBalancer, testa endpoints em Python, lê logs persistidos e remove recursos.

1. Baixe o projeto e identifique os espaços de ConfigMap, Secret, PVC, Deployment e Service.
2. Implante recursos e publique a imagem no registro.
3. Atualize e aplique YAML e verifique associações e configuração.
4. Chame a API, inspecione logs, substitua o Pod e confirme os dados.
5. Remova todos os recursos cobrados.

Pré-requisitos: assinatura do Azure com permissão, Visual Studio Code, Python 3.12 ou posterior, CLI do Azure atual e kubectl. Tarefas do Registro de Contêiner do Azure podem exigir pagamento conforme o uso porque créditos gratuitos podem não cobri-las.

Resumo do tópico

O laboratório comprova configuração, entrega de segredo, acesso público e logs duráveis em um fluxo completo de AKS.

radio_button_uncheckedshort_text14. Avaliação, checklist de produção e referências

• Versione configurações e documente atualização/reinício.
• Mantenha credenciais no Cofre de Chaves quando custódia e auditoria exigirem.
• Valide RBAC, criptografia, rotação e identidade.
• Escolha armazenamento por acesso, desempenho, durabilidade, topologia e custo.
• Teste associação, permissões, substituição, sobrevivência e I/O.

1. ConfigMaps in Kubernetes
2. Secrets in Kubernetes
3. Persistent volumes in Kubernetes
4. Storage options for applications in AKS
5. CSI drivers for Azure Disk, Azure Files, and Azure Blob in AKS
6. Azure Key Vault provider for Secrets Store CSI Driver
7. Azure Key Vault secret autorotation in AKS
8. Azure App Configuration Kubernetes Provider
9. Azure Container Storage documentation

Resumo do tópico

A prova decide por sensibilidade, forma de consumo e intenção de armazenamento; produção acrescenta identidade, rotação, observabilidade e evidência de desempenho.