Bài 9. Một request đi qua Kubernetes như thế nào?

Bạn đã deploy ứng dụng lên Kubernetes. Nhưng khi người dùng truy cập https://my-app.com, request sẽ đi đâu trước? Làm sao Kubernetes biết phải chuyển request đến đúng Pod?

Hãy cùng theo dõi hành trình của một request từ trình duyệt đến ứng dụng của bạn.

---

Bức tranh tổng quan

Browser
    │
    ▼
Ingress
    │
    ▼
Service
    │
    ▼
   Pod
    │
    ▼
Application

Chỉ có 4 thành phần tham gia vào hành trình này:

• Ingress: Cửa chính của Cluster.
• Service: Người điều phối lưu lượng.
• Pod: Nơi ứng dụng đang chạy.
• Application: Xử lý request và trả về kết quả.

---

Bước 1. Người dùng gửi request

Ví dụ, người dùng truy cập:

https://shop.example.com/products

Request đầu tiên sẽ đi đến Ingress.

Bạn có thể hình dung Ingress giống như lễ tân của một tòa nhà.

Nhiệm vụ của lễ tân không phải xử lý công việc, mà là xem bạn muốn gặp ai rồi chỉ đúng phòng.

---

Bước 2. Ingress tìm đúng Service

Ingress đọc URL và áp dụng các rule đã được cấu hình.

Ví dụ:

  /shop
    │
    ▼
shop-service

  /api
    │
    ▼
api-service

Nếu request là:

https://shop.example.com/products

Ingress sẽ chuyển request sang shop-service.

---

Bước 3. Service chọn một Pod

Service không xử lý request.

Nó chỉ biết:

"Có 3 Pod đang chạy ứng dụng này."

Ví dụ:

shop-service

├── Pod A
├── Pod B
└── Pod C

Khi có request mới, Service sẽ chọn một Pod để chuyển tiếp.

Nhờ vậy, nhiều Pod có thể cùng phục vụ người dùng và chia sẻ tải với nhau.

---

Bước 4. Pod xử lý request

Request cuối cùng đến ứng dụng bên trong Pod.

Ví dụ:

GET /products

Ứng dụng sẽ:

• Đọc dữ liệu
• Gọi Database (nếu cần)
• Trả về danh sách sản phẩm

Sau đó response sẽ quay ngược lại theo đúng đường cũ:

Application
    ▲
   Pod
    ▲
Service
    ▲
Ingress
    ▲
Browser

Người dùng sẽ nhìn thấy kết quả trên trình duyệt.

---

Tại sao phải đi qua nhiều lớp?

Nhiều người mới thường thắc mắc:

"Tại sao không cho Browser gọi thẳng Pod?"

Bởi vì Pod không ổn định.

Pod có thể:

• Bị xóa.
• Được tạo lại.
• Thay đổi địa chỉ IP.
• Được tăng hoặc giảm số lượng khi scale.

Nếu Browser kết nối trực tiếp đến Pod, chỉ cần Pod được tạo lại là ứng dụng sẽ không còn truy cập được.

Đó là lý do Kubernetes thêm Service và Ingress vào giữa để che đi những thay đổi phía sau, giúp ứng dụng luôn có một điểm truy cập ổn định.

---

Tổng kết

Một request trong Kubernetes thường đi theo đường sau:

Browser
    │
    ▼
Ingress
    │
    ▼
Service
    │
    ▼
   Pod
    │
    ▼
Application

Mỗi thành phần chỉ làm một nhiệm vụ duy nhất:

• Ingress nhận request từ bên ngoài Cluster.
• Service tìm Pod phù hợp và cân bằng tải.
• Pod chạy ứng dụng.
• Application xử lý nghiệp vụ và trả kết quả.

Nhờ cách phân chia này, Kubernetes có thể thay thế Pod, mở rộng hệ thống hoặc cập nhật phiên bản mới mà người dùng hầu như không nhận ra.

---

Bài tiếp theo

Trong bài này, chúng ta đã thấy Service chọn một Pod để xử lý request.

Nhưng có một câu hỏi thú vị:

Làm sao Service biết Pod nào thuộc về nó?

Đó chính là lúc Labels và Selectors xuất hiện. Đây là "ngôn ngữ" giúp các thành phần trong Kubernetes tìm thấy nhau, và cũng là nền tảng của gần như mọi cơ chế trong Kubernetes.