Case: bug tracking leve em K3s com BugSink

Contexto

Precisávamos de um bug tracking simples em cluster K3s, sem montar uma stack pesada. A ideia era capturar erros com UI própria, email, worker de ingestão e expor via ingress HTTPS.

O que foi feito

• Manifesto único (k8s/prod/bugsink.yaml) com namespace, secrets de app/DB, deployments (web + worker snappea), service e ingress TLS.
• Scripts bin/k8s-apply e bin/k8s-status usam kubeconfig compartilhado (siedos-lib-elasticstack/k8s-config por default) para aplicar e debugar pods/logs.
• Readiness/liveness TCP no pod web; limits/requests definidos para evitar consumo excessivo.
• Worker dedicado (bugsink-runsnappea) para processar eventos em background.

Fluxo (simplificado)

flowchart LR
  Apply[k8s-apply] --> NS[Namespace/Secrets/Deploys]
  NS --> Web[Deployment web (bugsink)]
  NS --> Worker[Deployment worker snappea]
  Web --> SVC[Service 8000]
  SVC --> Ingress[Ingress TLS\nbugsink.siedos.com.br]
  Status[k8s-status] -->|pods/logs/describe| NS

Operação e devX

• k8s-apply: aplica o manifesto completo e lista pods.
• k8s-status: mostra pods, describe, logs de todos os containers, deployments/ingress/services; flag --watch para acompanhar pods.
• Kubeconfig padrão pode ser trocado via KUBECONFIG env.

Impacto (anonimizado)

• Bug tracking leve rodando no próprio cluster, sem dependências externas.
• Deploy/debug em minutos com scripts curtos; mais fácil validar ingestão e alertas.
• Configuração transparente (secrets separados, probes, ingress TLS) para replicar em outros ambientes.

O que você pode reutilizar

• Manifesto único versionado com secrets por namespace e deployments separados (web/worker).
• Scripts finos para aplicar e coletar status/logs com kubeconfig parametrizável.
• Probes TCP simples para apps leves quando não há endpoint HTTP de health.