Kubernetes là công nghệ rất quen thuộc với anh em làm DevOps, việc sử dụng các công cụ hỗ trợ quản lý và thao tác K8s cluster cũng rất nhiều, mình thường sử dụng k9s terminal luôn nhưng trong nhiều trường hợp các công cụ như Rancher và Lens cực kỳ đáng cân nhắc.

Đặc biệt là sau khi sử dụng ngày càng nhiều vấn đề hơn:

• Ai được vào cluster nào?
• Ai cấp quyền cho team mới?
• Cluster nào đang lệch version?
• Policy áp cho production ở đâu?
• Audit khi có sự cố thì xem chỗ nào?

Đến lúc đó mới thấy Rancher và Lens không cùng một vai trò

Theo mình có thể hiểu:

• Lens giúp kỹ sư nhìn và thao tác với cluster dễ hơn.
• Rancher giúp tổ chức quản lý nhiều cluster có kiểm soát hơn.

Khác nhau nằm ở đó.

Nhìn nhanh trước đã

Một cách nhớ đơn giản:

• Lens giống kính lúp cho kỹ sư.
• Rancher giống phòng điều phối cho platform team.

Kính lúp rất cần. Nhưng kính lúp không thay cho hệ thống quản lý quyền, lifecycle và vận hành cluster.

Lens hợp khi người dùng cần làm việc nhanh với cluster

Lens khá dễ thích.

Mở kubeconfig lên, connect vào cluster, thấy workload, logs, shell, events, resource usage. Với người làm DevOps hay SRE, cảm giác này tiện hơn nhiều so với việc gõ kubectl liên tục.

Một case dễ áp dụng như là team có vài cluster dev và staging. Ông dev thỉnh thoảng cần xem pod crash vì sao, đọc log, kiểm tra config map, restart deployment. Nếu mọi việc đều phải nhờ platform team, luồng làm việc bị chậm.

Lens giải quyết khá tốt đoạn này.

Dev có quyền vừa đủ, mở Lens lên xem được service của mình. Không cần nhớ quá nhiều câu lệnh. Người mới vào team cũng bắt nhịp nhanh hơn.

Nhưng mà Lens không phải nơi để đặt mô hình quản trị đối với mình.

Nếu mỗi người tự giữ kubeconfig, tự thêm cluster, tự quản context, tự chia sẻ file cấu hình qua Slack hoặc password manager, nghe cũng có vẻ nhanh. Về sau rất dễ lộn xộn mình cũng trải rồi :))

Như là:

• Ai còn quyền vào production?
• Người nghỉ việc đã bị thu hồi chưa?
• Team A có nhìn thấy namespace của team B không?
• Có log lại thao tác nhạy cảm không?

Lens không sinh ra để trả lời hết những câu đó. Nó là công cụ làm việc với cluster. Không phải nền tảng quản trị cluster.

Rancher hợp khi cluster không còn là chuyện của một nhóm nhỏ

Rancher thường xuất hiện khi tổ chức bắt đầu có nhiều cluster hơn dự tính ban đầu.

• Một cluster cho dev.
• Một cluster cho staging.
• Hai cluster production.
• Thêm cluster ở region khác.
• Rồi cluster cho data platform, cluster cho internal tools, cluster cho khách hàng enterprise.

Từ vài cluster thành nhiều cluster nhanh lắm. Nhất là khi Kubernetes đã trở nên cực kỳ phổ biến với nhiều team DevOps trong State of DevOps Vietnam 2026 anh em đều hiểu rồi.

Lúc này, vấn đề không còn là xem pod có chạy không. Vấn đề là quản lý cả một đội hình cluster.

Rancher giúp gom các cluster vào một nơi, quản lý access, project, namespace, role, policy, version, node, workload. Với platform team, đây là kiểu nhìn rất khác Lens.

Không phải nhìn từ góc một người đang debug service. Mà nhìn từ góc người phải giữ hệ thống vận hành đều, có quyền hạn rõ, có chuẩn chung.

Một case production khá quen: công ty có nhiều team sản phẩm dùng chung hạ tầng Kubernetes. Nếu đưa thẳng kubeconfig production cho từng team, rủi ro rất cao. Platform team dùng Rancher để chia project, namespace, role theo team. Người dùng vào UI, thấy đúng phần mình được phép thấy.

• Khi cần thêm người vào team, cấp quyền từ một chỗ.
• Khi cần thu hồi, cũng từ một chỗ.
• Khi cần kiểm tra cluster nào đang chạy version cũ, không phải hỏi từng nhóm.

Đó là chỗ Rancher có giá trị.

Chỗ dễ chọn sai

Nhiều team dùng Lens rồi nghĩ đã ổn phần quản lý Kubernetes.

Đúng là mới ổn phần thao tác hằng ngày.

Lens làm cho việc nhìn vào cluster dễ hơn. Nhưng càng nhiều người dùng, càng nhiều cluster, càng nhiều môi trường, thì câu chuyện bắt đầu chuyển sang quyền, chuẩn, audit, lifecycle.

Ngược lại, cũng có team đưa Rancher vào quá sớm.

Chỉ có một cluster nhỏ, vài người vận hành, chưa có nhu cầu phân quyền phức tạp, chưa có nhiều môi trường. Dựng Rancher lúc đó có thể hơi nặng. Thêm một hệ thống để vận hành, backup, nâng cấp, phân quyền. Không phải lúc nào cũng đáng.

Câu nên hỏi trước không phải:

Rancher hay Lens tốt hơn?

Mà là:

• Team đang cần nhìn vào cluster cho nhanh,
• hay cần quản lý nhiều cluster cho có trật tự?

Cần vì thao tác chậm -> nghĩ tới Lens.

Cần vì cluster, quyền và team bắt đầu rối -> nghĩ tới Rancher.

Có dùng cả hai không?

Có. Và khá hợp lý.

Platform team dùng Rancher để quản lý cluster, user, quyền, namespace, policy. Kỹ sư dùng Lens để làm việc hằng ngày với cluster trong phạm vi quyền được cấp.

Hai công cụ không quá cồng kềnh đâu.

• Một bên là lớp quản trị.
• Một bên là lớp thao tác.

Điểm cần cẩn thận là đừng để Lens trở thành đường vòng qua quản trị. Nếu Rancher đã kiểm soát quyền, kubeconfig đưa cho người dùng cũng nên đi theo mô hình quyền đó. Không nên có một luồng chính thức qua Rancher, rồi một luồng không chính thức bằng file kubeconfig truyền tay.

Chỗ đó mới là phức tạp và rất nguy hiểm :))

Kết lại

Với cá nhân mình sử dụng thực tế thì thấy Rancher và Lens khác nhau khá xa, dù cùng xoay quanh Kubernetes.

• Lens hợp với người cần nhìn, debug, thao tác nhanh với cluster.
• Rancher hợp với team cần quản lý nhiều cluster, nhiều user, nhiều quyền và nhiều môi trường.

Nếu chỉ có vài cluster nhỏ, Lens có thể đủ cho công việc hằng ngày.

Nếu Kubernetes đã thành nền tảng chung cho nhiều team, Rancher bắt đầu đáng cân nhắc hơn. Không phải vì nó xịn hơn, mà vì lúc đó vấn đề đã đổi từ xem pod sang quản trị vận hành.

Nói ngắn gọn:

• Lens giúp kỹ sư đỡ mỏi tay.
• Rancher giúp platform team đỡ mất kiểm soát.

Chọn theo cái nào giải quyết vấn đề của team. Đừng chọn theo giao diện nhìn thích hơn. Hay “thấy xã hội dùng thì dùng” cá nhân mình là thế nhé các bác 😀