🧠FFVAcademy
🐄

Rancher: gerenciando múltiplos clusters K8s sem sofrer

16 min de leitura·+75 XP
Pré-requisitos (0/1)0%

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

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 é)

ÉUI + API de management que fala com N clusters (importados ou provisionados). Open source (Apache 2.0), mantido pela SUSE desde 2020.
ÉConjunto de produtos: Rancher Manager, RKE2/K3s, Fleet (GitOps), NeuVector (security), Longhorn (storage), Harvester (HCI/VM).
Não éUm fork do Kubernetes. Os clusters geridos continuam K8s padrão (CNCF-certified) — pode sair do Rancher e manter tudo.
Não éSubstituto de Argo CD, Prometheus ou Vault. É a cola que integra esses componentes em um único painel.
Quando brilhaDezenas de clusters heterogêneos (on-prem + EKS + Edge), times não especialistas em K8s, Edge com rede restrita, bancos/governo que precisam de painel auditável.
Quando atrapalha1 ou 2 clusters em uma única cloud. Você paga overhead sem ganho — melhor ir direto no EKS/GKE/AKS + GitOps simples.

Arquitetura: quem fala com quem

🗺️ Rancher em 1 diagrama
Management Cluster
🖥️
Rancher Manager
UI + API
🗄️
Embedded etcd
state do Rancher
🚚
Fleet Controller
GitOps
🛡️
Auth Provider
SAML/OIDC/LDAP
HTTPS + WebSocket
Downstream Clusters
☸️
Cluster A (EKS)
importado
☸️
Cluster B (RKE2)
on-prem
☸️
Cluster C (K3s)
Edge / filial
🤖
cattle-cluster-agent
em cada cluster
💡
Como o agent funciona. Em cada cluster importado, o Rancher instala um Deployment chamado cattle-cluster-agent. 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.

bash
# 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 ing
⚠️
Escolhendo 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.

bash
# 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.service
💡
RKE2 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.

🖱️UI: Cluster Management → Import Existingstep 1
Escolhe Generic. Dá um nome (ex.: eks-prod-eu-west-1).
gera
📜Rancher gera um kubectl apply com URL + tokenstep 2
Comando único, pode copiar pra pipeline.
executa no EKS
🤖cattle-cluster-agent é instalado no EKSstep 3
Namespace cattle-system. Connect-back via WebSocket.
aguarda
Cluster aparece como Activestep 4
Agora dá pra fazer kubectl via UI, criar Projects, instalar monitoring, conectar Fleet.
bash
# 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     Running
⚠️
Seguranç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 Cluster Registration Token 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.

🗺️ Fluxo do Fleet
📦GitRepo CRD no Rancherdefine repo + branch
Aponta para um repositório Git com bundles (fleet.yaml + manifests).
observa
🎯Target SelectormatchLabels
Seleciona clusters com labels (env=prod, region=eu-west).
empacota
📨Bundle geradopronto
Rancher gera um Bundle com os manifests finais.
deploy via agent
🤖fleet-agent em cada clusteraplica
Pull-based: agent do cluster busca bundle e aplica. Saudável pra Edge.
yaml
# 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
yaml
# 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-1
Por 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ãoSem Project (K8s puro)Com Project (Rancher)
GranularidadeRoleBinding por namespaceBinding no Project, herda em todos namespaces
Resource QuotaResourceQuota por namespaceQuota total do Project, fatiada entre namespaces
Network PolicyNetworkPolicy em cada nsProject Network Isolation: auto-aplica policy
Pod SecurityLabel/anotação por nsPod Security Admission herdado no Project
Adicionar nsReconfigurar RBAC + quotasMove pra dentro do Project, herda tudo
AuditoriaSpread em N namespacesDashboard agregado do Project
yaml
# 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-owner

Auth central + RBAC global

Auth ProvidersSAML (Okta, Azure AD, Google), OIDC, LDAP, GitHub, local. Configura uma vez, vale em todos clusters downstream.
Global RolesRole válido em todos os clusters (ex.: cluster-admin global para o time de platform).
Cluster RolesRole em um cluster específico (view, owner, custom).
Project RolesRole dentro de um Project (read-only, member, owner).
AuditoriaAPI Audit logs com quem fez o quê, quando, em qual cluster. Exporta pra SIEM (Splunk, Elastic).
💡
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 user: alice@empresa.com(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 logging-operator (Banzai Cloud): define ClusterFlow/Output e manda logs pra Loki, Elastic, S3, Splunk.
  • Observability stack externo — Nada impede você de usar Datadog/New Relic. Rancher não força.
bash
# 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=true

Rancher vs alternativas reais

DimensãoRancherRed Hat OCM/ACMCrossplaneSó Argo CD
Multi-cluster UISim, prontaSim (OpenShift)Não tem UIPor app, não por cluster
Provisiona clustersSim (RKE2, K3s, EKS, AKS, GKE via UI)Sim (OpenShift, managed)Sim, via APIsNão
GitOps multi-clusterFleet (hub-first)ACM Applications + ArgoCDConfigurationsArgo CD + ApplicationSets
RBAC globalSim (Global Roles)Sim (Cluster Role mgmt)Via IaCPor cluster, manual
Licença / vendorOpen source / SUSEComercial Red HatOpen source / CNCFOpen source / CNCF
Melhor paraHeterogêneo, Edge, on-prem + cloudEmpresa já em OpenShiftIaC avant-garde, cloud nativa1-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

Rancher + K3s

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 purofunciona mas sem visibilidade central vira pesadelo.

📋 SaaS B2B com 1 cluster EKS multi-tenant na AWS

EKS puro + Argo CD

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: Rancherinstale só se crescer pra multi-region com 5+ clusters.

📋 Banco com compliance PCI — clusters dev/hml/prod + DR em outra região

Rancher + RKE2 hardened

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: OpenShiftequivalente funcional mas com licença comercial cara.

📋 Startup com 1 cluster GKE e 4 devs

GKE + Argo CD

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 Backup (cron) e Restore como CRDs. Destino: S3, PVC, MinIO.
  • etcd snapshot — Em RKE2, rke2 etcd-snapshot save 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.
yaml
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: encryptionconfig

Perguntas típicas

Rancher trava em uma versão de Kubernetes?

Não. Ele suporta uma matriz de versões por release (ver docs). Clusters RKE2/K3s têm upgrade 1-clique via Rancher; EKS/GKE/AKS você atualiza pelo provedor e o Rancher acompanha.

Posso usar Rancher só para visualização?

Pode. Importar clusters read-only funciona — só que você perde RBAC agregado e Fleet. Muitos começam por aí e expandem depois.

Rancher Desktop é a mesma coisa?

Não. Rancher Desktop é app local (Mac/Win/Linux) que roda K8s via K3s + containerd, alternativa ao Docker Desktop. Rancher Manager é o painel multi-cluster. São produtos distintos da SUSE.

Fleet substitui Argo CD?

Não no caso geral. Fleet é superior em distribuir pra muitos clusters; Argo CD é superior em UI por aplicação, sync-waves, hooks, rollback manual. Em ambientes maduros rodam os dois.

Rancher tem suporte comercial?

Sim. SUSE oferece SUSE Rancher Prime (subscription). Em on-prem banco/governo costuma ser obrigatório pela política de suporte 24×7. Mantém-se 100% open source mesmo com subscription.
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.
🧩

Quiz rápido

4 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito

Continue lendo