ConfigMaps e Secrets: configuração externa

Você nunca quer hardcode de URL, flag ou senha no manifesto do Deployment. ConfigMap guarda config não-sensível (URLs, flags, nomes) e Secret guarda config sensível (senhas, tokens, chaves). Ambos viram variáveis de ambiente ou arquivos dentro do container.

ConfigMap

Três formas de criar:

# 1. Por chave/valor na linha de comando
kubectl create configmap app-config \
  --from-literal=LOG_LEVEL=info \
  --from-literal=API_URL=https://api.exemplo.com

# 2. De um arquivo (cada linha vira uma chave)
kubectl create configmap app-config --from-file=app.properties

# 3. De um diretório (cada arquivo vira uma chave)
kubectl create configmap app-config --from-file=./conf/

Ou via YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_URL: "https://api.exemplo.com"
  app.properties: |
    server.port=8080
    cache.ttl=300

Secret

Igual ao ConfigMap, mas pra dados sensíveis. Os valores são base64-encoded dentro do YAML (não é criptografia - é só pra não aparecer em texto claro no kubectl get):

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  # echo -n "minha-senha" | base64
  DB_PASSWORD: bWluaGEtc2VuaGE=
  API_KEY: YWJjZGVmZ2hpamtsbW5vcA==

Ou, mais legível, com stringData (você escreve plain text, o k8s converte pra base64 ao aplicar):

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  DB_PASSWORD: minha-senha
  API_KEY: abcdefghijklmnop

Atenção: o k8s guarda Secrets em etcd. Por padrão, não são criptografados em disco. Pra produção real, habilite encryption at rest no etcd ou use um secret manager externo (Vault, AWS Secrets Manager, Sealed Secrets).

Usando no Pod

Três formas de expor ConfigMap/Secret dentro do container:

1. Variável de ambiente

spec:
  containers:
    - name: api
      image: luciano/api:1.0
      env:
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: LOG_LEVEL
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: DB_PASSWORD

2. Todas as chaves de uma vez (envFrom)

spec:
  containers:
    - name: api
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets

Útil quando o ConfigMap tem muitas chaves e você quer todas no env.

3. Como arquivo (volume mount)

spec:
  containers:
    - name: api
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Dentro do container, /etc/config/LOG_LEVEL, /etc/config/API_URL, etc. Bom pra arquivos de configuração complexos (nginx.conf, application.properties).

Padrão útil: externalizar via env no Service Account

Pra apps que precisam puxar secrets de um secret manager externo (AWS, Vault), em vez de injetar o segredo como env var (mais fácil de vazar em logs), use um sidecar que lê o segredo e expõe via volume. Mais seguro e flexível.

Três conceitos que você acabou de aprender:

ConfigMap = config normal, texto claro. Secret = config sensível, base64 (não é criptografia).
Três formas de usar: env (uma chave por vez), envFrom (todas de uma vez) e volumeMount (como arquivo).
Secrets no k8s não são criptografados por padrão - use encryption at rest ou secret manager externo em produção.

Dica: mude config sem rebuildar a imagem. kubectl edit configmap app-config ou kubectl rollout restart deployment api (esse último força os Pods a recarregarem a config).

No próximo nó, vamos falar de persistência - como ter disco que sobrevive ao Pod morrer.