Pular para o conteúdo
NyverraNyverra
Artigos
⌘K
InícioArtigosSite institucional
🇧🇷

Nyverra

Canal editorial

Artigos sobre tecnologia, operações e parceiros — infraestrutura, monitoramento e ambientes críticos.

Explorar

  • Início
  • Artigos
  • Categorias
  • Tags
  • Autores
  • Sobre
  • Contato
  • RSS
  • Site institucional

© 2026 Nyverra. Todos os direitos reservados.

blog.nyverra.com

Aplicações precisam guardar arquivos: anexos, imagens, backups, evidências. Block storage (PVC) não é ideal para isso; object storage é.

MinIO oferece uma API compatível com S3 dentro do cluster. É leve, roda em Kubernetes e escala com erasure coding.

Selo do curso: testado em Kubernetes 1.35 com MinIO Operator e Tenant de 4 servidores.

Object storage em 30 segundos

  • Bucket: contêiner de objetos.
  • Objeto: arquivo + metadados, acessado por chave.
  • S3 API: HTTP com assinatura (SigV4).
  • Presigned URL: URL temporária para upload/download sem credencial.

Diferente de um PVC, você não monta; a aplicação fala HTTP com o bucket. Isso facilita múltiplos pods e acesso externo.

O Tenant MinIO

O operador cria um Tenant com N servidores. Cada servidor tem seu PVC; o conjunto forma um pool com erasure coding.

apiVersion: minio.min.io/v2
kind: Tenant
metadata:
  name: portal-minio
  namespace: portal
spec:
  features:
    bucketDNS: false
  requestAutoCert: false
  configuration:
    name: minio-tenant-config
  pools:
    - name: pool-0
      servers: 4
      volumesPerServer: 1
      volumeClaimTemplate:
        metadata:
          name: data
        spec:
          accessModes: ["ReadWriteOnce"]
          storageClassName: portal-nfs
          resources:
            requests:
              storage: 10Gi

Com 4 servidores, o MinIO usa erasure coding: tolera a perda de servidores/discos sem perder dados, desde que haja quórum (metade + 1).

Serviços típicos:

  • minio-s3 (API S3, porta 9000).
  • minio (console/API, conforme o manifesto).
  • portal-minio-hl (headless).

Credenciais: root não é para a aplicação

O operador cria um secret de root (minio-tenant-creds) com accesskey/secretkey. Não use root na aplicação.

Crie usuários/service accounts com policy mínima:

mc alias set local http://minio-s3:9000 "$ROOT_USER" "$ROOT_PASS"
mc admin user add local portal-backend '<secret-forte>'
mc admin policy attach local readwrite --user portal-backend

Ou service account (credencial vinculada a um usuário):

mc admin user svcacct add local portal-backend

Para produção, crie uma policy restrita aos buckets necessários (ex.: portal-storage, whatsapp-backup) em vez de readwrite global.

O caso INF-SEC-01

Nosso app usava minioadmin como access/secret. A imagem nova tinha um guard que recusa credenciais default em produção. O deploy falhou — e o guard estava certo.

Lição: a aplicação nunca deve usar a credencial root do MinIO, e credenciais default devem ser rotacionadas antes do deploy.

Buckets, versionamento e lifecycle

mc mb local/portal-storage
mc version enable local/portal-storage
mc ilm add local/portal-storage --expiry-days 90
  • Versionamento: protege contra sobrescrita/exclusão acidental.
  • Lifecycle: move/expira objetos antigos.
  • Object lock/WORM: retenção legal (compliance), quando necessário.

Cada bucket tem política. Não torne tudo público; prefira presigned URLs.

Acesso externo

Opções:

  • Ingress com path /minio → Service do MinIO.
  • Subdomínio dedicado minio.exemplo.com.
  • Acesso interno apenas (a aplicação fala http://minio-s3:9000).

Cuidado com presigned URL: ela usa o endpoint configurado. Se o endpoint interno for minio-s3, a URL não funciona no navegador. Configure a URL pública (MINIO_PUBLIC_URL) corretamente.

Laboratório

  1. Confira o Tenant:
kubectl -n portal get tenant.minio.min.io
kubectl -n portal get pods -l v1.min.io/tenant=portal-minio
kubectl -n portal get pvc | grep minio
  1. Use mc de dentro de um pod MinIO:
kubectl -n portal exec portal-minio-pool-0-0 -c minio -- sh
mc --config-dir /tmp/.mc alias set local http://127.0.0.1:9000 "$ROOT_USER" "$ROOT_PASS"
mc --config-dir /tmp/.mc ls local
  1. Crie um bucket e um usuário de aplicação com policy mínima.

  2. Faça upload/download:

echo hello > /tmp/hello.txt
mc --config-dir /tmp/.mc cp /tmp/hello.txt local/portal-storage/
mc --config-dir /tmp/.mc cat local/portal-storage/hello.txt
  1. Gere uma presigned URL e teste no navegador.

Erros comuns

Sintoma Causa
Tenant não fica Ready PVC, recurso, imagem ou config
ImagePullBackOff imagem não está no nó/registry
App recebe 403 policy/usuário errado
Presigned URL não abre endpoint público errado
Console 404 no Ingress path rewrite errado
Performance ruim NFS lento ou poucos discos

Checklist

  • [ ] Tenant com 4 servidores e PVCs Bound.
  • [ ] Root creds fora da aplicação.
  • [ ] Service account/policy mínima por app.
  • [ ] Versionamento/lifecycle definidos.
  • [ ] Endpoint público e presigned URLs testados.
  • [ ] Backup dos buckets (Velero ou mc mirror).
  • [ ] Rotação de credenciais documentada.

Glossário

  • Tenant: recurso do MinIO Operator.
  • erasure coding: redundância por fragmentação.
  • bucket: contêiner de objetos.
  • presigned URL: URL assinada temporária.
  • service account: credencial vinculada a um usuário MinIO.
  • lifecycle: regras de expiração/migração.

Próximo

Agora que temos banco e object storage, vamos às filas e cache: RabbitMQ e Redis com quórum, sentinel e PDB.

Próximo: Curso Kubernetes 17 — RabbitMQ e Redis: quórum, sentinel e PDB

Compartilhar

Continuar a ler

Leia também

  • Kubernetes de Verdade — do zero ao cluster em produção
    Kubernetes

    Kubernetes de Verdade — do zero ao cluster em produção

    Uma trilha prática para entender, montar e operar um cluster Kubernetes — do primeiro pod ao failover do Postgres.

    30 de outubro de 20264 min de leitura
  • Curso Kubernetes 28 — DR e capstone: provar que o cluster volta
    Kubernetes

    Curso Kubernetes 28 — DR e capstone: provar que o cluster volta

    RPO, RTO e drills reais: cenários de desastre, runbook, restore medido e o capstone que fecha o curso com um cluster que se recupera.

    30 de outubro de 20265 min de leitura
  • Curso Kubernetes 27 — SLO/SLI, on-call e postmortem blameless
    Kubernetes

    Curso Kubernetes 27 — SLO/SLI, on-call e postmortem blameless

    O que prometer, como medir e o que fazer quando o erro estoura: SLI, SLO, error budget, alertas que acordam alguém e postmortem sem caça às bruxas.

    30 de outubro de 20264 min de leitura

Comentários

Ainda sem comentários

Seja o primeiro a compartilhar sua opinião sobre este artigo.

Deixe um comentário

Newsletter

Receba novos artigos

Inscreva-se para receber publicações do blog Nyverra no seu e-mail. Enviaremos um link de confirmação.

​
  1. Início
  2. Kubernetes
  3. Curso Kubernetes 16 — MinIO: erasure coding, buckets e credenciais
Kubernetes
#Curso Kubernetes#K8S#Kubernetes

Curso Kubernetes 16 — MinIO: erasure coding, buckets e credenciais

Wedson LopesWedson Lopes
30 de outubro de 20264 min de leitura