Bài 8. Ingress - Đưa ứng dụng Kubernetes lên Internet
"Ứng dụng đã chạy trong Kubernetes. Service cũng đã có. Nhưng tại sao mình vẫn không thể mở website từ trình duyệt?"
Đây chính là lúc Ingress xuất hiện.
Chúng ta đang gặp vấn đề gì?
Ở bài trước, chúng ta đã biết Service giúp các Pod giao tiếp với nhau.
Ví dụ:
Frontend Service
Backend Service
Auth Service
Các Service này đều hoạt động tốt bên trong Kubernetes.
Nhưng nếu bạn mở trình duyệt và truy cập:
https://myapp.com
thì Kubernetes không biết phải chuyển request đến Service nào.
Nếu mỗi Service đều dùng kiểu LoadBalancer, bạn sẽ phải tạo rất nhiều địa chỉ IP công khai.
Frontend -> LoadBalancer
Backend -> LoadBalancer
Auth -> LoadBalancer
Điều này vừa tốn kém, vừa khó quản lý.
1. Ingress là gì?
Hãy tưởng tượng Kubernetes giống như một tòa nhà văn phòng.
- Pod là các nhân viên.
- Service là các phòng ban.
- Ingress chính là lễ tân.
Mọi khách đến tòa nhà đều đi qua lễ tân trước.
Lễ tân sẽ hỏi:
"Bạn muốn gặp ai?"
Nếu khách muốn gặp phòng Kế toán thì được hướng đến phòng Kế toán.
Nếu khách muốn gặp phòng Nhân sự thì được hướng đến phòng Nhân sự.
Ingress cũng hoạt động tương tự.
Nó nhận toàn bộ request từ Internet rồi quyết định sẽ chuyển đến Service nào.
Internet
│
▼
+------------+
| Ingress |
+------------+
│ │
▼ ▼
Frontend Backend
Service Service
2. Ingress quyết định chuyển request như thế nào?
Thông thường, Ingress dựa vào:
Theo tên miền
api.myapp.com
│
▼
Backend Service
shop.myapp.com
│
▼
Frontend Service
Theo đường dẫn (Path)
myapp.com/api
│
▼
Backend
myapp.com/admin
│
▼
Admin Service
myapp.com/
│
▼
Frontend
Nhờ vậy, chỉ cần một địa chỉ IP nhưng có thể phục vụ rất nhiều ứng dụng.
3. Ingress Controller là gì?
Ingress chỉ là bản mô tả luật định tuyến.
Để các luật đó thực sự hoạt động, Kubernetes cần một thành phần gọi là Ingress Controller.
Bạn có thể hình dung:
- Ingress = bản hướng dẫn.
- Ingress Controller = người thực hiện hướng dẫn.
Một số Ingress Controller phổ biến:
- NGINX Ingress Controller
- Traefik
- HAProxy
- Kong
4. Khi người dùng truy cập website thì chuyện gì xảy ra?
Browser
│
▼
Ingress Controller
│
▼
Ingress Rules
│
▼
Service
│
▼
Pod
Toàn bộ quá trình này chỉ diễn ra trong vài mili giây.
Tóm tắt
Sau bài này, bạn cần nhớ ba ý chính:
- Service giúp Pod giao tiếp và cung cấp một địa chỉ ổn định trong cluster.
- Ingress là cổng vào của Kubernetes, nhận request từ Internet và định tuyến đến đúng Service.
- Ingress Controller là thành phần thực thi các quy tắc của Ingress.
Bài tiếp theo
Đến đây chúng ta đã có thể đưa ứng dụng lên Internet.
Nhưng lại xuất hiện một câu hỏi mới:
Nếu ứng dụng cần đọc file cấu hình hoặc API URL khác nhau giữa môi trường Development và Production thì sao? Có phải build lại Docker Image mỗi lần thay đổi?
Trong bài tiếp theo, chúng ta sẽ tìm hiểu ConfigMap – cách Kubernetes quản lý cấu hình một cách linh hoạt mà không cần sửa lại ứng dụng.
All rights reserved