Module 2: Understanding Services & The Stable IP

Chào mừng bạn đến với Module 2, nơi chúng ta sẽ giải quyết một trong những vấn đề đau đầu nhất khi vận hành hệ thống phân tán: Làm sao để tìm thấy nhau khi mọi thứ liên tục thay đổi?

1. The Problem: "Pods are Mortal" (Pods là sinh vật phù du)

Trong Kubernetes, Pod cũng giống như con người: được sinh ra, sống một cuộc đời ngắn ngủi, và rồi qua đời. Khi một Pod chết đi (do crash, do node update, hoặc do ta lỡ tay xóa), Kubernetes sẽ tạo ra một Pod mới để thay thế. Nhưng vấn đề là: Pod mới sẽ có một địa chỉ IP hoàn toàn mới.

Hãy tưởng tượng kịch bản sau:

1. Frontend Pod (IP A) kết nối tới Database Pod (IP B).
2. Một ngày đẹp trời, Database Pod bị lỗi và restart.
3. K8s tạo ra Database Pod Mới (IP C).
4. Frontend Pod vẫn cố gắng gọi tới IP B (đã chết) và... CRASH! 💥

Nếu bạn cấu hình Hard-code IP giữa các Pod, hệ thống của bạn sẽ sụp đổ ngay khi có sự thay đổi. Chúng ta cần một giải pháp ổn định hơn.

2. The Solution: Service (ClusterIP) - Địa chỉ IP "Bất Tử"

Để giải quyết vấn đề "Pod mortal", Kubernetes giới thiệu khái niệm Service.

Service là một đối tượng trừu tượng (abstraction) định nghĩa một tập hợp các Pods và chính sách để truy cập chúng.

Hãy nghĩ về Service như một Tổng đài chăm sóc khách hàng (Hotline):

• Công ty có thể sa thải và tuyển dụng nhân viên trực tổng đài (Pod backend) liên tục.
• Nhưng số Hotline (Service IP) thì không bao giờ thay đổi.
• Khách hàng (Frontend) chỉ cần gọi vào số Hotline, không cần biết nhân viên nào sẽ bắt máy.

Cơ chế hoạt động: kube-proxy

Khi bạn tạo một Service loại ClusterIP (loại mặc định), Kubernetes sẽ cấp cho nó một Virtual IP (VIP). IP này ổn định và tồn tại suốt vòng đời của Service.

Bên dưới lớp vỏ, một thành phần tên là kube-proxy chạy trên mỗi Node đóng vai trò như "Cảnh sát giao thông":

• Nó quan sát Service và các Pods thay đổi.
• Nó cập nhật các luật mạng (iptables hoặc IPVS) để chuyển tiếp traffic.
• Load Balancing: Mặc định, Service sẽ phân phối traffic tới các Pod backend theo cơ chế Round-Robin (lần lượt từng Pod).

3. The Glue: Selectors & Labels (Chất kết dính)

Làm sao Service biết được Pod nào là "nhân viên" của mình để gửi traffic tới? Câu trả lời nằm ở cặp đôi quyền lực: Labels (Nhãn) và Selectors (Bộ lọc).

• Labels: Là những chiếc tem bạn dán lên Pod. Ví dụ: app: backend, env: prod.
• Selectors: Là tiêu chí lọc được định nghĩa trong Service. Ví dụ: "Tôi chỉ nhận traffic cho những Pod nào có dán tem app: backend".

Visualizing the Relationship

Biểu đồ dưới đây minh họa cách Service gom nhóm các Pods dựa trên Label:

Endpoints: Danh sách thực tế

Service không trực tiếp trỏ tới Pod. Nó thông qua một object trung gian gọi là Endpoints.

• Service: Giữ IP ổn định.
• Endpoints: Giữ danh sách các IP thực tế của Pods (thay đổi liên tục). Khi Pod chết/sống lại, Kubernetes tự động cập nhật danh sách IP trong object Endpoints này.

Deep Tech Note: ClusterIP is Virtual

Có một điều thú vị: Nếu bạn SSH vào một Node và thử ping tới ClusterIP của Service, có thể nó sẽ hoạt động, nhưng ClusterIP không hề gắn với bất kỳ card mạng vật lý nào!

Nó hoàn toàn là "ảo thuật" của Linux Kernel (thông qua iptables hoặc IPVS).

• Traffic gửi tới ClusterIP sẽ bị Kernel "bắt cóc" (DNAT) và đổi địa chỉ đích thành IP của một trong các Pod backend trước khi gói tin kịp rời khỏi máy.
• Vì nó là Virtual, bạn không thể truy cập ClusterIP từ bên ngoài Cluster (trừ khi dùng NodePort hoặc LoadBalancer - sẽ bàn ở các bài sau).

---

👉 Next: Managing Resources & QoS