Bài 36: Kubernetes Networking: Service và Ingress

Chốt ý nhanh

Chủ đề	Điểm cần nhớ
Kubernetes Networking	Muốn debug đúng phải hiểu đường đi traffic từ client đến pod qua Service, Ingress và đôi khi thêm Load Balancer.
Service	Là lớp ổn định để truy cập workload, giúp ẩn việc pod thay đổi liên tục phía sau.
Ingress	Là cách publish HTTP/HTTPS theo host/path thay vì mở từng service một cách rời rạc.

Phần thực hành mở rộng: nhìn Kubernetes networking như đường đi thật của request

Nhiều người học Kubernetes networking theo kiểu nhớ khái niệm rồi quên rất nhanh. Cách chắc hơn là luôn tự hỏi: request đi từ đâu, qua lớp nào, dừng ở đâu nếu lỗi. Khi hình dung được đường đi này, anh sẽ debug nhanh hơn nhiều so với việc chỉ nhìn YAML.

Lab 1: Quan sát Service và endpoint đang trỏ đi đâu

kubectl get svc -A
kubectl get endpoints -A
kubectl describe svc webdemo

Nếu service có selector đúng nhưng endpoint rỗng, lỗi không nằm ở Ingress mà có thể nằm ở label pod hoặc pod chưa Ready.

Lab 2: Dựng một ứng dụng mẫu và expose qua ClusterIP

kubectl create deployment webdemo --image=nginx
kubectl expose deployment webdemo --port=80 --type=ClusterIP
kubectl get svc,pods -l app=webdemo -o wide

Lab này giúp hiểu Service không “chạy app”, nó chỉ cung cấp điểm truy cập ổn định tới pod phía sau.

Lab 3: Kiểm tra đường đi nội bộ bằng port-forward hoặc curl trong cluster

kubectl port-forward svc/webdemo 8080:80
curl -I http://127.0.0.1:8080

Nếu port-forward ổn nhưng Ingress lỗi, vấn đề thường nằm ở lớp publish ra ngoài chứ chưa chắc ở pod ứng dụng.

Lab 4: Tạo Ingress tối thiểu và đọc describe

kubectl get ingress -A
kubectl describe ingress webdemo
kubectl get ingressclass

Điểm rất quan trọng: Ingress resource chỉ có ý nghĩa khi cluster thật sự có Ingress Controller xử lý nó.

Lab 5: Bài tập debug 404, 502 và timeout

404: kiểm tra host/path rule có khớp không
502/503: kiểm tra service port, endpoint và pod readiness
timeout: kiểm tra network path, controller log hoặc app phản hồi chậm

Tình huống thực tế

Một website chạy trong Kubernetes có thể lỗi vì nhiều lớp: DNS trỏ sai, LB chưa attach, Ingress rule nhầm host, Service publish sai port hoặc pod backend crash. Nếu không tách lớp theo đường đi của request, người vận hành rất dễ sửa nhầm chỗ.

Lỗi phổ biến

Nhầm port của Service với port thật trong container.
Tạo Ingress nhưng cluster không có controller.
Service selector không match label pod.
Chỉ nhìn pod Running rồi nghĩ mạng chắc chắn ổn.

Kết bài

Nếu bài này ngấm, anh sẽ bớt sợ Kubernetes networking vì đã có một khung rất thực dụng để debug. Sang bài tiếp theo về Storage, tư duy tương tự vẫn giữ nguyên: đừng chỉ học object, hãy nhìn dữ liệu thật đang nằm đâu và được cấp cho workload ra sao.