Rancher: gerenciando múltiplos clusters K8s sem sofrer
Um cluster Kubernetes já é complexo. Agora imagine 20, 40, 200 clusters: dev, staging, prod, Edge na fábrica, branch office no banco, ambiente cliente em tenant. Cada um com RBAC, logging, backup, ingress, Helm chart, monitoring, política de segurança. Quem cuida disso só com kubectl em terminal vira refém do caos. Rancher (SUSE, antes independente) nasceu pra esse problema: é o plano de controle de planos de controle. Você vê todos os clusters em uma UI, roda GitOps centralizado (Fleet), aplica RBAC unificado, instala apps de um catálogo e mantém auditoria consolidada — sem abrir mão do K8s puro por baixo.
O que Rancher é (e o que não é)
Arquitetura: quem fala com quem
Como o agent funciona. Em cada cluster importado, o Rancher instala um Deployment chamado . Ele abre uma conexão WebSocket de saída pro Rancher Manager (cluster em rede privada não precisa abrir porta de entrada). Comandos (kubectl via UI, apply de bundles do Fleet) trafegam por essa conexão. Por isso Rancher funciona em Edge/filial mesmo atrás de NAT.
Instalando o Rancher Manager (HA) com Helm
Padrão de produção: Rancher Manager em um cluster K8s dedicado (3 nodes, HA). Helm é o jeito oficial. Em teste local, k3d ou kind servem bem.
# 1) cert-manager (Rancher usa pra emitir certificados internos)
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.crds.yaml
helm repo add jetstack https://charts.jetstack.io
helm upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager --create-namespace \
--version v1.15.3
# 2) Rancher Manager (stable channel)
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
kubectl create namespace cattle-system
helm upgrade --install rancher rancher-stable/rancher \
--namespace cattle-system \
--set hostname=rancher.empresa.com \
--set bootstrapPassword=ChangeMeOnFirstLogin \
--set ingress.tls.source=letsEncrypt \
--set letsEncrypt.email=ops@empresa.com \
--set replicas=3
# 3) Verifica rollout
kubectl -n cattle-system rollout status deploy/rancher
kubectl -n cattle-system get ingEscolhendo a distro do management cluster. Em ambiente com suporte SUSE: RKE2. Em EKS/GKE/AKS: qualquer cluster gerenciado funciona — mas lembre que se ele cai, todos os Rancher agents perdem o controlador (pods seguem rodando; só o management fica offline). HA com 3 nodes e etcd backup é obrigatório em produção.
RKE2 em 3 comandos (cluster downstream)
RKE2 é a distro opinionada da SUSE. Instala tudo em um binário. Vantagem: bootstrap reprodutível, hardening CIS padrão, Air Gap suportado.
# No primeiro server node
curl -sfL https://get.rke2.io | sh -
systemctl enable --now rke2-server.service
# Pega kubeconfig
sudo cp /etc/rancher/rke2/rke2.yaml ~/.kube/config
sudo chown $USER ~/.kube/config
# Pega o token (pra adicionar novos nodes)
sudo cat /var/lib/rancher/rke2/server/node-token
# Em um segundo server node (HA control plane)
mkdir -p /etc/rancher/rke2
cat <<'EOF' | sudo tee /etc/rancher/rke2/config.yaml
server: https://10.0.0.10:9345
token: K10<TOKEN-DO-PRIMEIRO-NODE>
EOF
curl -sfL https://get.rke2.io | sh -
systemctl enable --now rke2-server.service
# Em um agent (worker)
cat <<'EOF' | sudo tee /etc/rancher/rke2/config.yaml
server: https://10.0.0.10:9345
token: K10<TOKEN>
EOF
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=agent sh -
systemctl enable --now rke2-agent.serviceRKE2 vs K3s. Mesmo time da SUSE. K3s é minimalista: binário de ~60MB, SQLite no lugar do etcd por padrão, roda até em Raspberry Pi — ideal para Edge. RKE2 é a versão hardened, com etcd, hardening CIS e certificação FedRAMP/FIPS — ideal para datacenter e governo. Rancher gerencia os dois.
Importando um cluster EKS no Rancher
Você tem um EKS já existente. Não precisa destruir nada. Rancher importa via agent.
# Comando gerado pelo Rancher (colado em quem tem kubectl no EKS)
kubectl apply -f https://rancher.empresa.com/v3/import/abc123xyz_c-xxxxx.yaml
# Verifica
kubectl -n cattle-system get pods
# NAME READY STATUS
# cattle-cluster-agent-7d4c9b5b6c-xxxxx 1/1 RunningSegurança. O YAML de import contém um token. Quem aplica no cluster ganha write no K8s via Rancher. Use pipeline protegido e rotacione o token via após o import.
Fleet: GitOps multi-cluster
Fleet é a arma secreta do Rancher em escala. Você versiona manifests + Helm no Git, define targets por label e Fleet propaga pros clusters certos.
# fleet-gitrepo.yaml — apply no management cluster do Rancher
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: apps-prod
namespace: fleet-default
spec:
repo: https://github.com/empresa/k8s-gitops
branch: main
paths:
- apps/payments
- apps/orders
targets:
- name: prod-eu
clusterSelector:
matchLabels:
env: prod
region: eu-west
- name: prod-us
clusterSelector:
matchLabels:
env: prod
region: us-east# apps/payments/fleet.yaml — customizações por target
defaultNamespace: payments
helm:
chart: ./chart
values:
replicas: 2
targetCustomizations:
- name: prod-eu
helm:
values:
replicas: 5
region: eu-west-1
- name: prod-us
helm:
values:
replicas: 5
region: us-east-1Por que Fleet escala. Cada cluster tem um agent leve que puxa bundles. O hub não mantém conexão push a 1000 clusters. Perda de rede? O agent retoma quando volta. Rollback? Reverte o commit no Git. É a forma mais honesta de fazer GitOps em escala.
Projects: RBAC que não dá nó
Em um cluster grande, um time pode ter 5-10 namespaces (api, worker, db, cache, staging). Configurar RBAC namespace a namespace é receita pra erro. Project (conceito Rancher) agrupa namespaces sob uma política comum.
| Dimensão | Sem Project (K8s puro) | Com Project (Rancher) |
|---|---|---|
| Granularidade | RoleBinding por namespace | Binding no Project, herda em todos namespaces |
| Resource Quota | ResourceQuota por namespace | Quota total do Project, fatiada entre namespaces |
| Network Policy | NetworkPolicy em cada ns | Project Network Isolation: auto-aplica policy |
| Pod Security | Label/anotação por ns | Pod Security Admission herdado no Project |
| Adicionar ns | Reconfigurar RBAC + quotas | Move pra dentro do Project, herda tudo |
| Auditoria | Spread em N namespaces | Dashboard agregado do Project |
# Exemplo: Project "payments" agrega 3 namespaces e aplica quota+rbac
apiVersion: management.cattle.io/v3
kind: Project
metadata:
name: p-payments
namespace: c-m-xxxxx # id interno do cluster no Rancher
spec:
displayName: payments
description: "Time de pagamentos — payments-api, payments-worker, payments-db"
resourceQuota:
limit:
limitsCpu: "20"
limitsMemory: "40Gi"
pods: "50"
namespaceDefaultResourceQuota:
limit:
requestsCpu: "2"
requestsMemory: "4Gi"
---
apiVersion: management.cattle.io/v3
kind: ProjectRoleTemplateBinding
metadata:
name: prb-payments-lead
namespace: c-m-xxxxx
projectName: c-m-xxxxx:p-payments
subjectKind: User
subjectName: alice@empresa.com
roleTemplateName: project-ownerAuth central + RBAC global
Impersonation. Rancher autentica o usuário com seu Auth Provider, gera um JWT interno e quando o usuário faz kubectl via UI ou via kubeconfig gerado pelo Rancher, o API server de cada cluster recebe como (via impersonation). Assim os audit logs do K8s também têm o nome real, não só "cattle-cluster-agent".
Monitoring e Logging
Rancher embala catálogos de apps mas monitoring merece destaque:
- • Rancher Monitoring — Helm chart oficial com kube-prometheus-stack (Prometheus, Grafana, Alertmanager) pronto, com dashboards de cluster/node/workload.
- • Rancher Logging — Integração com (Banzai Cloud): define / e manda logs pra Loki, Elastic, S3, Splunk.
- • Observability stack externo — Nada impede você de usar Datadog/New Relic. Rancher não força.
# Install Rancher Monitoring (no cluster downstream)
helm repo add rancher-charts https://charts.rancher.io
kubectl create namespace cattle-monitoring-system
helm upgrade --install rancher-monitoring rancher-charts/rancher-monitoring \
--namespace cattle-monitoring-system \
--set prometheus.prometheusSpec.retention=15d \
--set grafana.persistence.enabled=trueRancher vs alternativas reais
| Dimensão | Rancher | Red Hat OCM/ACM | Crossplane | Só Argo CD |
|---|---|---|---|---|
| Multi-cluster UI | Sim, pronta | Sim (OpenShift) | Não tem UI | Por app, não por cluster |
| Provisiona clusters | Sim (RKE2, K3s, EKS, AKS, GKE via UI) | Sim (OpenShift, managed) | Sim, via APIs | Não |
| GitOps multi-cluster | Fleet (hub-first) | ACM Applications + ArgoCD | Configurations | Argo CD + ApplicationSets |
| RBAC global | Sim (Global Roles) | Sim (Cluster Role mgmt) | Via IaC | Por cluster, manual |
| Licença / vendor | Open source / SUSE | Comercial Red Hat | Open source / CNCF | Open source / CNCF |
| Melhor para | Heterogêneo, Edge, on-prem + cloud | Empresa já em OpenShift | IaC avant-garde, cloud nativa | 1-5 clusters, time avançado |
Quando Rancher (não) vale a pena
📋 Indústria com 50 fábricas, cada uma precisa de K8s local (Edge) com sensores/MES conectados
K3s roda em hardware modesto; Rancher importa os 50 via agent outbound (NAT friendly); Fleet distribui o app central. Um time de 2 pessoas consegue manter.
Alt: K3s puro —
📋 SaaS B2B com 1 cluster EKS multi-tenant na AWS
Rancher aqui vira overhead. Você não tem problema multi-cluster — tem problema multi-tenant dentro de 1 cluster (Namespace/Project K8s puro resolve).
Alt: Rancher —
📋 Banco com compliance PCI — clusters dev/hml/prod + DR em outra região
RKE2 já entrega hardening CIS e FIPS. Rancher dá painel auditável, RBAC integrado com AD, Projects pra segregar ambientes. Auditores adoram ver tudo em um lugar.
Alt: OpenShift —
📋 Startup com 1 cluster GKE e 4 devs
Rancher vira peso. O plano gratuito do GKE + Argo CD resolve CI/CD, RBAC via Google IAM. Adote Rancher só depois que o número de clusters passar de 5.
Backup e Disaster Recovery do Rancher
Se o Rancher Manager morrer, os clusters downstream continuam rodando (K8s é K8s). Mas você perde histórico, Projects, RBAC customizado, Fleet state. Backup é obrigatório.
- • rancher-backup operator — Chart oficial. Define (cron) e como CRDs. Destino: S3, PVC, MinIO.
- • etcd snapshot — Em RKE2, automatiza. Em cluster gerenciado (EKS), o provedor já backupa etcd do control plane.
- • Velero — Complementa para backup de PVs e recursos K8s por namespace/label.
apiVersion: resources.cattle.io/v1
kind: Backup
metadata:
name: rancher-nightly
spec:
storageLocation:
s3:
bucketName: rancher-backups
region: us-east-1
credentialSecretName: s3-creds
credentialSecretNamespace: cattle-resources-system
schedule: "0 3 * * *" # 03:00 UTC
retentionCount: 14
encryptionConfigSecretName: encryptionconfigPerguntas típicas
❓ Rancher trava em uma versão de Kubernetes?
❓ Posso usar Rancher só para visualização?
❓ Rancher Desktop é a mesma coisa?
❓ Fleet substitui Argo CD?
❓ Rancher tem suporte comercial?
Take-aways. (1) Rancher é plano de controle de clusters — não é fork de K8s. (2) RKE2/K3s são distros opinionadas da SUSE para datacenter e Edge. (3) Fleet faz GitOps hub-first escalando a milhares de clusters. (4) Projects salvam RBAC em clusters grandes. (5) Auth + audit centralizados reduzem compliance a uma tela. (6) Em 1-2 clusters, não use Rancher — você paga overhead sem ganho. (7) Backup do Rancher é obrigatório: use rancher-backup + etcd snapshot + S3 fora do cluster.
Discussão
Carregando…