Kubernetes & GitOps
Deploy de produção em k3s (Kubernetes leve, nó único) numa VPS da Hostinger, com entrega contínua declarativa via Argo CD. Decisão em ADR-0006. Visão visual em Diagramas → Fluxo de entrega.
Ambiente de produção (k3s na VPS)
- k3s já instalado na VPS Hostinger (single-node).
- Traefik como ingress, mas subido por nós (Helm, com nossos values, versionado no GitOps) — o Traefik embutido do k3s fica desabilitado (
--disable traefik). Não usamos Ingress-NGINX. - DNS/TLS/exposição: ver Rede e exposição (Cloudflare +
technodevbr.com). - Gerenciamento (ver pods etc.): ver Gerenciamento do cluster.
- Atenção (nó único): sem alta disponibilidade — reboot/manutenção derruba os serviços. Fazer backup do volume do Postgres e dos manifests (GitOps já cobre a config).
Empacotamento de manifests
Estratégia (ver ADR-0015):
- Serviços próprios (backend, collector, frontend) → Kustomize (
base/+overlays/{dev,staging,prod}). Manifests são nossos, simples e explícitos; sem a indireção de templates de Helm. - Componentes de terceiros (Traefik, cert-manager, RabbitMQ, Redis/PostgreSQL operadores, observabilidade, etc.) → Helm (charts oficiais da comunidade), com nossos values versionados.
- Base dos manifests próprios em
deploy/k8s/no repo de aplicação; overlays por ambiente ficam no repo GitOps (environments/{dev,staging,prod}). - Argo CD suporta os dois nativamente (Application aponta para chart Helm ou diretório Kustomize).
Argo CD
- Sincroniza o estado desejado (repo GitOps) → cluster.
- Oferece diff, rollback com 1 clique, self-heal e histórico de sync.
- Padrão app-of-apps para orquestrar todas as Applications.
Estratégia de release
- Rolling update por padrão.
- Canary / blue-green via Argo Rollouts quando precisar de deploy progressivo.
Plataforma no cluster
- Traefik (subido por nós via Helm; o do k3s fica desabilitado) + cert-manager com DNS-01 da Cloudflare (TLS Let's Encrypt, válido também para hosts internos). Detalhes em Rede e exposição.
- Segredos: Sealed Secrets ou External Secrets Operator (nunca segredo em claro no Git).
- Storage: o
local-pathpadrão do k3s não suporta VolumeSnapshot. Para snapshots de volume diários usamos Longhorn (CSI com snapshot) + external-snapshotter +VolumeSnapshotClass. Ver Backup & DR. - Banco em produção: no nó único, CloudNativePG (operador) com volume persistente e backup em camadas (snapshot da VPS + VolumeSnapshot diário do PVC + WAL archiving off-site com PITR); um Postgres gerenciado externo é a alternativa mais segura se o orçamento permitir. Evitar banco como pod "solto" sem backup. Ver Backup & DR.
Fluxo completo (código → produção)
GitHub (push/PR no busca-busca)
→ GitHub Actions: build + testes + SonarQube (Quality Gate) + Trivy (scan)
→ build da imagem Docker (multi-stage) + push no Harbor (re-scan por política)
→ bump da tag de imagem no repo busca-busca-gitops (commit automatizado)
→ Argo CD detecta o diff e sincroniza
→ Kubernetes aplica (rolling/canary via Argo Rollouts)
→ Observabilidade + Agente IA/MCP monitoramVer CI/CD, Registry (Harbor) e Observabilidade.