"Điều gì sẽ xảy ra nếu cả công ty cùng dùng chung một Kubernetes Cluster?"

Hãy tưởng tượng công ty bạn có 3 team:

• Team Backend
• Team Frontend
• Team AI

Mỗi team đều triển khai ứng dụng lên cùng một Kubernetes Cluster.

Ban đầu mọi thứ đều ổn.

Nhưng chỉ sau một thời gian, bạn bắt đầu gặp những vấn đề như:

• Có nhiều Pod cùng tên, rất khó phân biệt.
• Team AI vô tình xóa Deployment của Team Backend.
• Team Frontend sử dụng quá nhiều tài nguyên khiến ứng dụng của các team khác bị ảnh hưởng.
• Việc quản lý quyền truy cập trở nên hỗn loạn.

Rõ ràng, chúng ta cần một cách để chia Cluster thành nhiều "không gian làm việc" độc lập.

Đó chính là lý do Namespace ra đời.

1. Namespace là gì?

Namespace là cách Kubernetes chia một Cluster thành nhiều khu vực logic riêng biệt.

Bạn có thể hình dung:

Kubernetes Cluster
│
├── Namespace: backend
│   ├── Deployment
│   ├── Service
│   └── Pod
│
├── Namespace: frontend
│   ├── Deployment
│   ├── Service
│   └── Pod
│
└── Namespace: monitoring
    ├── Prometheus
    ├── Grafana
    └── Alertmanager

Mặc dù tất cả đều nằm trong cùng một Cluster, nhưng mỗi Namespace hoạt động gần như một "thế giới riêng".

2. Namespace mang lại lợi ích gì?

1. Tổ chức tài nguyên gọn gàng

Thay vì để hàng trăm Pod lẫn lộn với nhau, bạn có thể nhóm chúng theo:

• Team
• Dự án
• Môi trường (dev, staging, production)
• Chức năng (monitoring, logging...)

2. Tránh trùng tên

Trong cùng một Namespace, tên tài nguyên phải là duy nhất.

Nhưng ở hai Namespace khác nhau, bạn hoàn toàn có thể có:

backend/api
frontend/api

Cả hai Deployment đều tên api nhưng không hề xung đột.

3. Phân quyền dễ dàng

Bạn có thể cho phép:

• Team Backend chỉ được thao tác trong Namespace backend.
• Team Frontend chỉ được truy cập Namespace frontend.

Điều này giúp giảm đáng kể rủi ro thao tác nhầm.

3. Các Namespace mặc định

Khi tạo một Cluster mới, Kubernetes đã có sẵn một vài Namespace:

• default: nơi các tài nguyên sẽ được tạo nếu bạn không chỉ định Namespace.
• kube-system: chứa các thành phần quan trọng của Kubernetes.
• kube-public: chứa các tài nguyên có thể được truy cập công khai.
• kube-node-lease: phục vụ việc theo dõi trạng thái của các Node.

Đối với ứng dụng của bạn, không nên triển khai tất cả vào default. Hãy tạo Namespace riêng để dễ quản lý ngay từ đầu.

4. Khi nào nên tạo Namespace?

Một số cách chia phổ biến:

dev
staging
production

Hoặc:

backend
frontend
monitoring
logging

Không có một quy tắc cố định. Điều quan trọng là cách chia phải giúp việc quản lý trở nên đơn giản và rõ ràng.

Tổng kết

Namespace giống như việc chia một tòa nhà thành nhiều phòng ban. Mọi người vẫn làm việc trong cùng một tòa nhà (Cluster), nhưng mỗi phòng ban có không gian, tài nguyên và quyền hạn riêng.

Đối với các dự án nhỏ, bạn có thể chưa cảm nhận được giá trị của Namespace. Nhưng khi số lượng ứng dụng, đội ngũ và môi trường ngày càng tăng, Namespace sẽ trở thành nền tảng giúp Kubernetes luôn gọn gàng và dễ quản lý.

Ở bài tiếp theo, chúng ta sẽ tìm hiểu ServiceAccount – "danh tính" mà Kubernetes cấp cho mỗi Pod để chúng có thể giao tiếp với API Server một cách an toàn.