DEV Community

Cover image for Rancher: O “Canivete Suíço” do Kubernetes que Ainda Vale Muito em 2025
Kauê Matos
Kauê Matos

Posted on

Rancher: O “Canivete Suíço” do Kubernetes que Ainda Vale Muito em 2025

Rancher: O “Canivete Suíço” do Kubernetes que Ainda Vale Muito em 2025

Se você trabalha com Kubernetes em 2025, provavelmente já ouviu falar do Rancher.

Mesmo com o ecossistema Kubernetes amadurecendo rápido (EKS, GKE, AKS, DigitalOcean, Linode, etc.), o Rancher continua sendo uma das ferramentas mais adotadas por empresas médias e grandes que querem controlar múltiplos clusters Kubernetes de forma centralizada, segura e simples.

O que é o Rancher?

Rancher é uma plataforma open-source (agora mantida pela SUSE) que simplifica a vida de quem precisa:

  • Provisionar clusters Kubernetes em qualquer lugar (nuvem, on-premise, bare-metal, air-gapped)
  • Gerenciar dezenas ou centenas de clusters a partir de um único painel
  • Aplicar políticas de segurança, RBAC, backups, monitoramento e logging de forma consistente
  • Fazer deploy de aplicações com Helm ou o próprio catálogo do Rancher de forma idiot-proof

Em resumo: o Rancher é o “control plane dos control planes”.

Ele não substitui o Kubernetes — ele coloca ordem na bagunça quando você tem mais de 2–3 clusters.

Rancher 2.x em 2025: O que mudou e o que ainda importa

A versão atual (2.8+ em 2025) já roda 100% sobre Kubernetes e trouxe melhorias importantes:

  • Multi-cluster apps com GitOps nativo (baseado em Fleet)
  • Suporte nativo a Longhorn (block storage distribuído)
  • Rancher Backup + restore integrado
  • Continual Security com OPA Gatekeeper, Kyverno e CIS Benchmark
  • Integração profunda com Harvester (HCI open-source da SUSE)
  • Suporte oficial a Kubernetes 1.29–1.31 e clusters arm64

Casos de uso reais onde o Rancher brilha

  1. Empresas com ambiente híbrido/multi-cloud

    50 clusters: 20 no AWS EKS, 15 no Azure AKS, 10 no VMware on-prem, 5 no Hetzner.

    Tudo gerenciado por um único Rancher com SSO (Keycloak, Azure AD, Okta, Google).

  2. Ambientes air-gapped / governamentais / bancos

    Rancher pode ser instalado totalmente offline.

    Você baixa os imagens, leva num pendrive e sobe tudo sem internet.

  3. Edge Computing massivo

    Empresas de varejo, óleo & gás e telecom usam Rancher + k3s para gerenciar milhares de clusters leves em lojas, poços de petróleo ou antenas 5G.

  4. Plataforma interna para times de desenvolvimento

    Muitas empresas transformam o Rancher em um “Kubernetes as a Service” interno:

    • Dev cria projeto no Rancher
    • Namespace + quota + NetworkPolicy são criados automaticamente
    • CI/CD com Fleet + ArgoCD integrado

Rancher vs Alternativas em 2025

Ferramenta Quando escolher Quando evitar
Rancher Multi-cluster, híbrido, on-prem, air-gapped, equipes grandes Se você tem só 1–2 clusters na nuvem pública
EKS/AKS/GKE Quer pagar para não pensar em nada Quer controle total ou custo previsível
OpenShift Precisa de suporte enterprise pesado e certificações Orçamento apertado (é caro)
Lens + k9s Você é dev e quer só uma UI bonita Gerenciar mais de 5 clusters vira caos
Kubernetes Dashboard Quer o mínimo possível Qualquer coisa além de laboratório

Componentes principais do Rancher (2025)

  • Rancher Server → O cérebro (roda como pod no cluster de management)
  • Fleet → GitOps contínuo para múltiplos clusters
  • Longhorn → Storage distribuído (o “EBS da vida real” para quem está on-prem)
  • Rancher Backup → Backup/restore de etcd e recursos
  • Monitoring → Prometheus + Grafana pré-configurados
  • Logging → Fluentd/Fluent Bit + Elasticsearch ou Loki
  • CIS Scan + OPA/Kyverno → Segurança automatizada

Como instalar o Rancher hoje (5 minutos)

Opção mais rápida em 2025:

# 1. Crie um cluster k3s simples (pode ser uma VM com 4 vCPU + 8GB RAM)
curl -sfL https://get.k3s.io | sh -

# 2. Instale Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# 3. Adicione repo do Rancher
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

# 4. Crie namespace
kubectl create ns cattle-system

# 5. Instale (use um hostname real ou nipp.io)
helm upgrade -i rancher rancher-latest/rancher \
  --namespace cattle-system \
  --set hostname=rancher.seudominio.com \
  --set replicas=3 \
  --set bootstrapPassword=admin123 \
  --version 2.8.10
Enter fullscreen mode Exit fullscreen mode

Acesse https://rancher.seudominio.com → login admin/admin123 → troque a senha.

Pronto. Você tem um Rancher production-ready.

Rancher é “morto”? (o mito de 2024–2025)

Em 2024 muita gente falou que “Rancher morreu” porque a SUSE comprou e o ritmo de features desacelerou um pouco.

Em 2025 isso já foi desmentido:

  • Rancher 2.8+ trouxe melhorias enormes
  • Comunidade ativa (mais de 50k estrelas no GitHub)
  • Empresas como Vivo, Itaú, Petrobras, TIM, Globo e milhares de outras continuam usando em produção

Rancher não está morto — ele só saiu da moda dos “hype trains” e virou infraestrutura séria.

Conclusão: Vale a pena usar Rancher em 2025?

Sim, se você tem qualquerior:

  • Mais de 3 clusters Kubernetes
  • Ambiente híbrido ou on-prem
  • Necessidade de air-gap ou conformidade pesada
  • Quer entregar Kubernetes como plataforma interna
  • Não quer pagar dezenas de milhares de dólares por mês em managed Kubernetes

Não, se você tem 1–2 clusters na AWS/GCP/Azure e está feliz pagando o managed service.

Rancher continua sendo, em 2025, a melhor ferramenta open-source para quem precisa de controle total sobre múltiplos clusters Kubernetes sem vender um rim.

Link oficial: https://rancher.com

Repositório: https://github.com/rancher/rancher

Comunidade BR muito ativa no Telegram e Discord.

Se você gerencia Kubernetes de verdade, Rancher ainda é imbatível no custo-benefício.

Top comments (1)

Collapse
 
primetarget profile image
Ethan Anderson

Excelente resumo. Fato legal: o Harvester (HCI da SUSE) é construído sobre Kubernetes, usa KubeVirt para VMs e Longhorn para storage, e integra direto no Rancher. Outro: o Fleet, GitOps nativo do Rancher, permite orquestrar milhares de clusters a partir de um único repositório.