คอนเทนเนอร์· ~15 นาที· อัปเดตล่าสุด 15 ก.ค. 2569

ประเภทของ Service (ClusterIP / NodePort / LoadBalancer)

เลือกวิธีเปิดให้เข้าถึงจากในคลัสเตอร์หรือจากภายนอก

Service ใน Kubernetes สามารถเลือกเปิดรับการเชื่อมต่อได้ 3 รูปแบบหลัก เพื่อตอบสนองตามความต้องการด้านความปลอดภัยและการเข้าถึง

ระดับการเปิดประตูออฟฟิศ

เทียบระดับการเปิดประตู: ClusterIP = ประตูภายในออฟฟิศ (คนในเท่านั้น), NodePort = เปิดหน้าต่างเลขห้องเฉพาะให้คนนอกปีนเข้า, LoadBalancer = จ้างประชาสัมพันธ์หน้าตึกคอยพาลูกค้าเข้ามา

ยิ่งลงล่างยิ่งเปิดกว้างสู่ภายนอก (สร้างต่อยอดกัน)

ClusterIPภายในคลัสเตอร์เท่านั้น

NodePortเปิดพอร์ตเดียวกันบนทุก node

LoadBalancerLB จริงจาก cloud หน้าสุด

LoadBalancer → ใช้ NodePort → ใช้ ClusterIP เบื้องหลัง

ClusterIP (ในคลัสเตอร์) → NodePort (เปิดพอร์ตทุก node) → LoadBalancer (LB ของ cloud หน้าสุด)

ClusterIP (ค่าเริ่มต้น) — เข้าถึงได้เฉพาะภายในคลัสเตอร์ เหมาะให้ service คุยกันเอง (เช่น frontend → backend)
NodePort — เปิดพอร์ตเดียวกันบนทุก node (ช่วง 30000–32767) ให้เข้าจากภายนอกผ่าน <NodeIP>:<port> เหมาะทดสอบ/on-prem
LoadBalancer — ขอload balancer จริงจาก cloud (เช่น AWS ELB) มาไว้หน้าสุด เหมาะเปิดสู่อินเทอร์เน็ตใน production บน cloud
ExternalName — แมป service เป็นชื่อ DNS ภายนอก (ไม่มี proxy) ใช้ชี้ไปบริการนอกคลัสเตอร์

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP          # เปลี่ยนเป็น NodePort/LoadBalancer ได้
  selector:
    app: web               # ส่ง traffic ให้ Pod ที่ label app=web
  ports:
    - port: 80             # พอร์ตที่ Service เปิด
      targetPort: 8080     # พอร์ตของ container ปลายทาง

service.yaml — ClusterIP หน้ากลุ่ม Pod app=web

สรุป Key Takeaways

ClusterIP = ภายในเท่านั้น (ดีฟอลต์) · NodePort = เปิดพอร์ตทุก node · LoadBalancer = LB จริงจาก cloud
ทั้งหมดสร้างต่อยอดกัน: LoadBalancer → NodePort → ClusterIP
production บน cloud เปิดสู่โลกภายนอกด้วย LoadBalancer (มักผ่าน Ingress)

คำถามที่พบบ่อย

ClusterIP, NodePort, LoadBalancer ใช้ตอนไหน

ClusterIP (default) = คุยกันภายใน cluster (service ส่วนใหญ่ควรเป็นแบบนี้) · NodePort = เปิดพอร์ตบนทุก node ให้ยิงจากนอกได้ (เหมาะ dev/ทดลอง) · LoadBalancer = ให้ cloud สร้าง LB จริงชี้เข้ามา (ทางมาตรฐานของ production บน cloud) — งานจริงมัก ClusterIP + Ingress แทนการเปิด LoadBalancer ทีละ service

ทำไมไม่ควรใช้ LoadBalancer ทุก service

LB ของ cloud คิดเงินต่อตัว — สิบ service = สิบ LB = ค่าใช้จ่ายและ IP บาน — แบบแผนที่ถูกคือ LoadBalancer ตัวเดียวชี้เข้า Ingress controller แล้วให้ Ingress route ตาม host/path ไปยัง service ภายในที่เป็น ClusterIP ทั้งหมด

อ่านจบแล้วอย่าลืมทำเครื่องหมาย

ก่อนหน้าทำไม Pod IP เชื่อถือไม่ได้ — ต้องมี Service ถัดไปDNS และ Service Discovery ในคลัสเตอร์