Ingress — ประตูหน้าเดียวสู่หลาย Service
route HTTP ตาม host/path เข้าหลาย service ด้วย LB ตัวเดียว
Ingress (อินเกรส): คือ กฎหรือข้อกำหนดในการจัดระเบียบ Traffic ที่มาจากภายนอกให้วิ่งไปหา Service ภายในได้อย่างถูกต้อง โดยใช้โดเมนเนมหรือ Path เป็นตัวบอกทิศทาง
Ingress เหมือนพนักงานต้อนรับหน้าตึก ที่ดูว่าแขกมาหาแผนกไหน (ดูจากชื่อโดเมน/path) แล้วชี้ทางไปห้องที่ถูก · แทนที่จะจ้าง LoadBalancer (ซึ่งมีค่าใช้จ่าย) หนึ่งตัวต่อ service เราใช้ Ingress ตัวเดียวคุมหลาย service
ปัญหาของ Service แบบ LoadBalancer คือ ถ้ามี 10 service ก็ต้องมี 10 LB (แพงและจัดการยาก) · Ingress ให้เราใช้จุดเข้า HTTP/HTTPS จุดเดียว แล้วกำหนดกฎ routing ตาม host หรือ path
Ingress ตัวเดียวแยก traffic ตาม path ไปหลาย Service
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: main
spec:
rules:
- host: example.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service: { name: web, port: { number: 80 } }
- path: /api
pathType: Prefix
backend:
service: { name: api, port: { number: 80 } }สรุป Key Takeaways
- Ingress = กฎ routing HTTP/HTTPS ตาม host/path เข้าหลาย Service ด้วยจุดเข้าเดียว
- ประหยัดกว่าการมี LoadBalancer หนึ่งตัวต่อ service
- ต้องมี Ingress Controller (NGINX/ALB) ทำงานตามกฎจริง
- มักทำ TLS termination ที่ Ingress
คำถามที่พบบ่อย
Ingress กับ Service LoadBalancer ต่างกันยังไง
LoadBalancer ทำงานที่ L4 — หนึ่ง service หนึ่ง LB ส่วน Ingress ทำงานที่ L7 (HTTP) — จุดเข้าเดียว route ตาม host/path ไปหลาย service, ทำ TLS termination, จบที่ LB ตัวเดียว — เว็บ/API หลายตัวใน cluster เดียว = Ingress คือคำตอบมาตรฐาน
Ingress resource กับ Ingress controller ต่างกันยังไง (จุดที่มือใหม่งงสุด)
Ingress resource = "กฎ" ที่เราเขียน (host ไหน path ไหนไป service ไหน) ส่วน Ingress controller = "ตัวทำงานจริง" (nginx, traefik, ALB controller) ที่อ่านกฎแล้ว config ตัวเองตาม — สร้าง Ingress แล้วไม่มีอะไรเกิดขึ้น 90% คือยังไม่ได้ติดตั้ง controller