Rancher: quản trị nhiều cluster từ một chỗ
Hai bài trước bạn đã có bộ đôi mạnh: Helm đóng gói, ArgoCD đồng bộ từ git. Nhưng cả hai đều mặc định một điều kiện ngầm mà đời thật hay phá vỡ:
Hai bài trước bạn đã có bộ đôi mạnh: Helm đóng gói, ArgoCD đồng bộ từ git. Nhưng cả hai đều mặc định một điều kiện ngầm mà đời thật hay phá vỡ:
Bạn chỉ có một cluster.
Thực tế sau vài tháng: một cluster dev, một staging, một prod on-prem, rồi khách hàng đòi thêm một cluster riêng, rồi team AI xin một cluster có GPU. Bỗng dưng bạn có 5 cluster — và mọi thứ nhân lên 5 lần: 5 kubeconfig, 5 bộ RBAC, 5 lần cài monitoring, 5 chỗ để lỡ tay xóa nhầm.
Rancher là lớp nền tảng giải bài toán đó: một nơi để quản trị mọi cluster — dựng, nhập, phân quyền, giám sát, nâng cấp, sao lưu. Và điểm hay: app catalog của nó chính là Helm (Bài 01), GitOps engine của nó (Fleet) cùng họ với ArgoCD (Bài 02). Bạn không học lại từ đầu — bạn ráp những gì đã biết vào một mặt bảng điều khiển.
Vấn đề: một cluster thì ổn, năm cluster thì loạn
❌ Quản 5 cluster bằng kubectl thuần:
~/.kube/config ← 5 context chen chúc trong một file
│
├─ dev kubectl config use-context dev
├─ staging kubectl config use-context staging
├─ prod kubectl config use-context prod ← 😱
├─ khach-hang-A
└─ gpu-cluster
→ Pitfall Bài 01 chặng K8s thành hiện thực:
"kubectl delete" tưởng ở dev, hóa ra context đang trỏ PROD.
→ RBAC: phân quyền cho 1 dev mới = làm 5 lần, ở 5 cluster.
→ Monitoring: cài Prometheus 5 lần, 5 Grafana rời rạc.
→ Backup: nhớ chạy etcd snapshot ở... cả 5 nơi?
→ Nâng cấp K8s: kubeadm upgrade thủ công × 5.
→ Sếp/QA/dev không rành kubectl → không ai xem được gì nếu thiếu bạn.Ba nỗi đau cốt lõi:
- Không có tầm nhìn tổng — không màn hình nào cho biết "tất cả cluster của tôi đang thế nào".
- Vận hành nhân bản — mọi việc (RBAC, monitoring, backup, upgrade) phải lặp lại ở từng cluster.
- Rào cản kubectl — chỉ người thạo CLI mới chạm được cluster; QA/dev/sếp bị khóa ngoài.
Rancher là gì
Rancher là nền tảng quản trị Kubernetes đa cluster (mã nguồn mở, do SUSE duy trì). Nó không thay thế K8s — nó là lớp quản trị ngồi bên trên các cluster K8s của bạn.
┌──────────────────────────┐
│ RANCHER SERVER │ ← 1 nơi điều khiển tất cả
│ UI · RBAC · Catalog · │
│ Monitoring · Fleet · │
│ Backup · Cluster mgmt │
└────────────┬─────────────┘
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Cluster │ │ Cluster │ │ Cluster │
│ prod │ │ dev │ │ khach-A │
│ (kubeadm │ │ (RKE2 do │ │ (EKS trên │
│ Bài 09!) │ │ Rancher │ │ cloud) │
│ │ │ dựng) │ │ │
└───────────┘ └───────────┘ └───────────┘
↑ agent ↑ agent ↑ agent
(cattle-cluster-agent — cài vào mỗi cluster "downstream")Hai cách đưa cluster vào Rancher:
IMPORT Cluster đã có sẵn (kubeadm ở Bài 09, EKS, GKE, K3s...)
→ Rancher cho bạn 1 lệnh kubectl apply để cài agent vào.
→ Cluster vẫn nguyên vẹn; Rancher chỉ "nhìn thấy" và quản.
PROVISION Rancher tự DỰNG cluster mới cho bạn
→ trên VM/bare-metal (RKE2), hoặc gọi API cloud (EKS/GKE/AKS)
→ khỏi làm lại 9 bước kubeadm bằng tay.⚠️ Điểm quan trọng nhất, ghi nhớ ngay: Rancher server chết KHÔNG làm cluster chết. Các cluster downstream vẫn chạy bình thường (K8s vốn tự vận hành), bạn chỉ mất giao diện quản trị cho tới khi Rancher lên lại. Rancher là bảng điều khiển, không phải động cơ.
RKE2 vs K3s vs kubeadm — chọn "distro" nào
Rancher không chỉ quản mà còn cung cấp các bản K8s riêng. Đặt cạnh cái bạn đã biết:
kubeadm K8s "chính chủ", bạn tự lắp từng mảnh (Bài 09)
→ học rõ nhất, kiểm soát hoàn toàn, tốn công nhất
RKE2 K8s của Rancher, cứng cáp cho production
→ 1 binary, tự bao gồm containerd/CNI/etcd
→ mặc định bảo mật cao (đạt chuẩn CIS/FIPS)
→ hợp: production on-prem, môi trường cần chuẩn bảo mật
K3s K8s siêu nhẹ (~60MB, 1 binary)
→ lược bỏ thành phần ít dùng, mặc định dùng SQLite thay etcd
→ hợp: edge, IoT, dev/lab, Raspberry Pi, CI runner
(K3s & RKE2 đều là K8s ĐẠT CHUẨN — không phải "hàng nhái".
API, YAML, kubectl của bạn dùng y hệt.)💡 Kiến thức 9 bài chặng K8s dùng lại 100% trên RKE2/K3s. Pod vẫn là Pod, Service vẫn là Service. Khác nhau ở cách dựng và đóng gói cluster, không phải cách dùng.
Các khái niệm riêng của Rancher
Project — tầng trên Namespace
Đây là khái niệm Rancher thêm vào mà K8s thuần không có:
Cluster
└── Project "Team Thanh Toán" ← RANCHER thêm tầng này
├── Namespace: payment-dev
├── Namespace: payment-staging
└── Namespace: payment-prod
→ Gán quyền MỘT LẦN cho cả Project (thay vì từng namespace).
→ Đặt ResourceQuota cho cả Project (nhớ Bài 04 chặng K8s).
→ Team chỉ thấy đúng namespace của mình trong UI.→ Nhớ Bài 04 (Namespace + RBAC): Rancher gom nhiều namespace thành một Project, rồi phân quyền theo Project. Đỡ hẳn việc lặp RoleBinding cho từng namespace.
Xác thực tập trung
Rancher nối vào AD / LDAP / SAML / GitHub / Google, rồi ánh xạ người dùng vào RBAC của K8s (Bài 04):
Nhân viên mới vào công ty (đã có tài khoản AD)
│
▼
Rancher: gán "nhóm AD Dev-Team" → vai trò "Read Only" trên Project X
│
▼
Người đó login Rancher bằng tài khoản công ty → thấy đúng thứ được phép,
trên MỌI cluster — không cần phát kubeconfig, không cần tạo RoleBinding tay.
Nhân viên nghỉ việc → khóa tài khoản AD → mất quyền ở TẤT CẢ cluster ngay.→ So với việc phát ~/.kube/config cho từng người (và không bao giờ thu hồi được khi họ nghỉ), đây là một bước nhảy về bảo mật.
App Catalog = Helm (Bài 01!)
Rancher có "cửa hàng ứng dụng" — và bên dưới nó chính là Helm:
Rancher UI → Apps → chọn chart → điền form (values.yaml render thành form!)
→ Install
↓ thực chất là
helm install <chart> -f <values do bạn điền>Bạn thêm được repo Helm riêng của công ty vào catalog. Dev không rành Helm vẫn cài được app chuẩn — vì họ chỉ điền form, còn values.yaml do bạn định nghĩa.
Fleet = GitOps (Bài 02!)
Rancher có sẵn engine GitOps tên Fleet:
Fleet ArgoCD
───── ──────
Tích hợp sẵn trong Rancher Cài riêng, độc lập
Mạnh ở: deploy 1 app xuống Mạnh ở: quản lý sâu 1 (hoặc vài) cluster,
HÀNG TRĂM cluster cùng lúc UI trực quan, diff/sync chi tiết
(edge, chi nhánh, cửa hàng)
Dùng khi: đã xài Rancher & Dùng khi: cần GitOps mạnh, UI đẹp,
cần scale ra rất nhiều cluster không phụ thuộc Rancher→ Hai thứ không loại trừ nhau: nhiều nơi dùng Rancher để quản hạ tầng cluster, và vẫn dùng ArgoCD để deploy ứng dụng. Chọn theo nhu cầu, đừng chọn theo "cái nào ngầu hơn".
Những việc Rancher làm đỡ bạn
Đây là chỗ Rancher hoàn trả công sức bỏ ra — nó gói sẵn đúng những mảnh Day-2 mà chặng K8s phải làm tay:
Monitoring Cài Prometheus + Grafana cho 1 cluster bằng 1 cú click
(thay vì helm install rồi tự cấu hình — Bài 09)
Logging Gom log tập trung (Fluentd/Banzai) — cấu hình từ UI
Backup rancher-backup operator: sao lưu chính Rancher;
snapshot etcd theo lịch cho cluster RKE2/K3s
(nhớ etcdctl snapshot ở Bài 09 — giờ có lịch tự động)
Security scan Quét cluster theo chuẩn CIS Benchmark → báo cáo vi phạm
(ăn khớp với Bài 08: Pod Security, non-root, capabilities)
Upgrade Nâng cấp K8s của cluster RKE2/K3s từ UI, cuốn chiếu từng node
(thay vì kubeadm upgrade thủ công từng máy)
Cluster template Định nghĩa "khuôn" cluster chuẩn → mọi cluster mới đều
giống nhau (cùng CNI, cùng chính sách bảo mật)⚠️ Đừng để Rancher thành cái cớ không học kubectl. UI tiện, nhưng khi sự cố xảy ra lúc 2 giờ sáng, thứ cứu bạn vẫn là kubectl describe và logs --previous (Bài 02 chặng K8s). Rancher là bàn điều khiển, không phải thay thế hiểu biết.
Cạm bẫy lớn nhất: click-ops phá vỡ GitOps
Đây là mâu thuẫn tôi muốn bạn thấy trước khi vấp — nó nối thẳng về Bài 02:
Bài 02 dạy: Git là nguồn sự thật. selfHeal giết configuration drift.
Rancher cho: Một cái UI đẹp, ai cũng bấm sửa được replicas, env, image...
→ Ai đó vào UI Rancher, sửa replicas 3 → 10.
→ Nếu app đó do ArgoCD quản: ArgoCD kéo về 3 ngay (selfHeal). Người kia
bối rối "sao tôi sửa mà không ăn?".
→ Nếu app KHÔNG do GitOps quản: thay đổi đó tồn tại, KHÔNG có trong git,
không ai review, không ai biết → CONFIGURATION DRIFT quay lại. 💀Nguyên tắc dung hòa:
Dùng Rancher UI cho: hạ tầng & vận hành
(dựng cluster, phân quyền, xem log/metric,
backup, upgrade, debug — CHỈ ĐỌC là chính)
Dùng Git/ArgoCD cho: cấu hình ứng dụng
(replicas, image, env, ingress...)
→ UI để NHÌN và VẬN HÀNH. Git để THAY ĐỔI.🚀 Lab — Rancher quản cluster kind
Cách nhanh nhất để nếm thử: chạy Rancher server bằng Docker, rồi import cluster kind của bạn.
1. Chạy Rancher server (Docker, chỉ để học)
docker run -d --restart=unless-stopped \
-p 8080:80 -p 8443:443 \
--privileged \
--name rancher-server \
rancher/rancher:latest
# Lấy mật khẩu bootstrap
docker logs rancher-server 2>&1 | grep "Bootstrap Password:"
# Mở https://localhost:8443 (bỏ qua cảnh báo self-signed cert)⚠️ Cách này chỉ để học. Production phải cài Rancher bằng Helm lên một cluster K8s riêng (đúng bài 01!) để có HA:
# (production — tham khảo)
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm install rancher rancher-latest/rancher -n cattle-system --create-namespace \
--set hostname=rancher.cty.vn --set replicas=32. Import cluster kind vào Rancher
Trong UI Rancher:
Cluster Management → Import Existing → Generic → đặt tên "lab"
→ Rancher đưa cho bạn một lệnh kubectl apply# Dán lệnh Rancher cho vào terminal (đang trỏ context kind):
kubectl config current-context # kiểm tra ĐÚNG cluster (pitfall Bài 01!)
kubectl apply -f https://<rancher-host>/v3/import/xxxxx.yaml
kubectl get pods -n cattle-system # agent đang lên
# → Vài phút sau, cluster "lab" hiện Active trong UI Rancher ✨3. Khám phá
• Cluster Dashboard → CPU/RAM/Pod của cả cluster trong 1 màn hình
• Workloads → thấy Deployment/StatefulSet/Job đã học ở chặng trước
• Projects/Namespaces→ tạo Project "Team A", gộp vài namespace vào
• Apps → Charts → cài Monitoring (Prometheus+Grafana) bằng 1 click
→ đây chính là helm install, có form thay cho values.yaml4. Kiểm chứng: Rancher chết, cluster vẫn sống
docker stop rancher-server # "giết" bảng điều khiển
kubectl get pods -A # cluster VẪN CHẠY BÌNH THƯỜNG ✅
docker start rancher-server # bật lại → UI trở về, không mất gì→ Khoảnh khắc "à há": Rancher là bảng điều khiển, không phải động cơ. Mất nó bạn mất tầm nhìn, không mất hệ thống.
5. Dọn
docker rm -f rancher-server
kubectl delete ns cattle-system fleet-system 2>/dev/nullCâu chuyện thực tế
Khi startup lớn lên, chúng tôi từ 1 cluster thành 4: dev, staging, prod, và một cluster riêng cho khách hàng lớn (họ yêu cầu tách biệt hạ tầng).
Nỗi đau đến rất nhanh. Onboarding một dev mới giờ là: tạo cert/user ở 4 cluster, viết RoleBinding ở 4 nơi, gửi 4 file kubeconfig, dặn "nhớ đổi context cẩn thận nhé". Mất gần 2 tiếng mỗi người. Và mỗi lần có người nghỉ việc, tôi lạnh sống lưng — kubeconfig đã phát ra thì không thu hồi được; muốn chắc phải xoay cert cả cluster.
Rồi chuyện phải đến đã đến. Một chiều, một bạn dọn dẹp môi trường dev: kubectl delete namespace test-old. Lệnh chạy ngon. Nhưng context đang trỏ staging — bạn ấy quên đổi sau khi debug staging lúc sáng. Cả namespace staging bốc hơi (đúng pitfall "xóa namespace cuốn sạch mọi thứ" ở Bài 04). May là staging, không phải prod. Nhưng khoảng cách giữa staging và prod chỉ là một dòng trong kubectl config use-context — và điều đó khiến tôi không ngủ được.
Chúng tôi dựng Rancher trong 2 ngày. Kết quả sau một quý:
- Onboarding dev: từ ~2 tiếng → ~5 phút. Gán nhóm AD vào Project là xong; họ login bằng tài khoản công ty, thấy đúng phần được phép, trên cả 4 cluster.
- Thu hồi quyền: từ "xoay cert cả cluster" → khóa tài khoản AD. Nhân viên nghỉ việc, mất quyền mọi nơi trong 1 giây.
- Không còn ai cầm kubeconfig prod (cộng hưởng với GitOps ở Bài 02 — deploy đã là merge PR rồi).
- Monitoring 4 cluster: từ 4 lần cài tay → 4 cú click, và một chỗ để nhìn tất cả.
- QA và bạn PM tự xem được log/trạng thái app trong UI, không phải nhắn tôi "anh ơi check hộ pod".
Nhưng Rancher cũng cho tôi một cú tát, đúng cái tôi cảnh báo ở trên. Vài tuần sau, một bạn thấy prod chậm, vào UI Rancher bấm sửa replicas 3 → 8. Tiện quá mà. Ứng dụng đó do ArgoCD quản (selfHeal: true) — ArgoCD kéo về 3 sau 30 giây. Bạn ấy sửa lại, ArgoCD lại kéo về. Ba vòng như thế, bạn ấy nhắn tôi: "Anh ơi Rancher hỏng rồi, em sửa không ăn!".
Rancher không hỏng. GitOps đang làm đúng việc của nó. Chúng tôi ra luật rõ ràng ngay hôm đó: UI để nhìn và vận hành hạ tầng; git để thay đổi ứng dụng. Muốn 8 replica? Sửa values-prod.yaml, mở PR. Mất 3 phút, nhưng có review, có lịch sử, và nó tồn tại thật.
Bài học:
Một cluster thì kubectl là đủ. Từ ba cluster trở lên, bạn cần một bảng điều khiển. Nỗi đau tăng theo cấp số nhân, không phải cấp số cộng.
Xác thực tập trung là món quà lớn nhất của Rancher. Không phát kubeconfig nữa = thu hồi được quyền. Đây là thứ khó làm bằng kubectl thuần.
Rancher server chết ≠ cluster chết. Bảng điều khiển, không phải động cơ. Nhưng vẫn nên chạy Rancher HA (3 replica trên cluster quản trị riêng), vì mất nó lúc sự cố là mất mắt.
UI tiện là con dao hai lưỡi — click-ops giết GitOps. Ra luật rõ: UI để nhìn & vận hành hạ tầng; git để thay đổi ứng dụng. Không có luật này, drift quay lại bằng cửa sau.
Rancher không thay thế việc hiểu K8s. 2 giờ sáng, thứ cứu bạn vẫn là
describe,logs --previous,get endpoints. UI chỉ giúp bạn tới đó nhanh hơn.Context switching là một rủi ro thật, không phải chuyện đùa.
use-contextsai một dòng có thể xóa nhầm cả namespace. Nếu chưa dùng Rancher, ít nhất hãy hiện context lên prompt shell.
Pitfalls
Tưởng Rancher chết là cluster chết. Không — downstream vẫn chạy. Đừng hoảng; nhưng cũng đừng để Rancher là SPOF (chạy HA).
Cài Rancher production bằng
docker run. Cách đó chỉ để học/lab. Production:helm installlên một cluster quản trị riêng, nhiều replica.Click-ops trên app do GitOps quản → ArgoCD/Fleet kéo về, người dùng hoang mang "UI hỏng". Ra luật phân vai UI vs git.
Chạy Rancher server trên chính cluster prod mà nó đang quản → sự cố prod làm mất luôn bảng điều khiển đúng lúc cần nhất. Tách cluster quản trị riêng.
Không backup Rancher. Mất Rancher = mất toàn bộ cấu hình Project/RBAC/catalog. Dùng
rancher-backupoperator.Bỏ qua ma trận tương thích version. Rancher ↔ K8s ↔ RKE2 có bảng hỗ trợ; nâng cấp lệch nhau gây lỗi khó hiểu. Đọc support matrix trước khi upgrade.
Phát quyền
cluster-adminqua UI cho nhanh. Đúng pitfall RBAC ở Bài 04 chặng K8s, chỉ đổi vỏ. Least privilege, dùng Project role.Import cluster khi context đang trỏ nhầm nơi. Lệnh import là
kubectl apply— trỏ nhầm là cài agent vào sai cluster.current-contexttrước, luôn luôn.Dùng K3s cho production nặng chỉ vì "nó nhẹ". K3s tuyệt cho edge/lab; production nghiêm túc trên bare-metal thường chọn RKE2 (hoặc kubeadm) — hợp chuẩn bảo mật và etcd đầy đủ.
Coi Rancher là thay thế cho học kubectl. Sự cố thật sẽ lôi bạn về CLI. UI là lối tắt, không phải nền móng.
Tóm tắt
- Rancher = nền tảng quản trị đa cluster (không thay thế K8s — là lớp bên trên). Một nơi để dựng, nhập, phân quyền, giám sát, nâng cấp, sao lưu mọi cluster.
- Import cluster có sẵn (kubeadm/EKS/GKE) hoặc provision cluster mới (RKE2/K3s/cloud).
- ⭐ Rancher server chết KHÔNG làm cluster chết — nó là bảng điều khiển, không phải động cơ.
- Distro: kubeadm (chính chủ, học rõ) · RKE2 (production, bảo mật CIS) · K3s (siêu nhẹ, edge/lab). Cả ba đều là K8s chuẩn — kiến thức 9 bài dùng lại 100%.
- Project = tầng trên Namespace (gộp namespace, phân quyền & quota theo team).
- Xác thực tập trung (AD/LDAP/SAML) → ánh xạ vào RBAC. Không phát kubeconfig = thu hồi được quyền.
- App Catalog = Helm (Bài 01, values render thành form). Fleet = GitOps (họ hàng ArgoCD — Bài 02; Fleet mạnh khi có rất nhiều cluster).
- Gói sẵn Day-2: monitoring, logging, backup (etcd theo lịch), CIS security scan, cluster upgrade từ UI.
- ⚠️ Click-ops giết GitOps. Luật vàng: UI để nhìn & vận hành hạ tầng; git để thay đổi ứng dụng.
- ⚠️ Rancher không thay thế việc hiểu K8s — sự cố thật vẫn cần
describe/logs --previous.
Bạn giờ có đủ ba lớp công cụ trên nền K8s: Helm (đóng gói), ArgoCD (git điều khiển), Rancher (quản trị hạm đội). Cái còn thiếu để khép vòng là nhìn thấy — khi 4 cluster và 50 service cùng chạy, làm sao biết cái nào sắp hỏng trước khi khách hàng gọi? Đó là Observability (Prometheus + Grafana + Loki), và CI/CD để tự động hóa đoạn từ git push tới image mới trong registry.
Nếu hôm nay bạn tắt Rancher server và thấy cluster vẫn thản nhiên chạy — bạn đã hiểu đúng vai trò của một bảng điều khiển: nó giúp bạn nhìn, chứ không giữ hệ thống sống.
— Minh Hưng