1. ทำความรู้จัก Service Dataplane: เมื่อ IP ไม่ใช่สิ่งที่เห็น
เวลาเราเขียนโปรแกรมใน Kubernetes เรามักจะเรียกใช้งานผ่าน Service ซึ่งเปรียบเสมือนตัวกลางในการติดต่อสื่อสาร แต่ความจริงที่น่าตกใจคือ ClusterIP ที่เราเห็นนั้นไม่ได้มีตัวตนอยู่จริงบนการ์ดแลน (Network Interface) ของเครื่องไหนเลย มันเป็นเพียงแค่ "ที่อยู่สมมติ" ที่ถูกสร้างขึ้นมาเพื่อให้ Pod ต่างๆ ใช้งานได้สะดวกขึ้นเท่านั้น
ลองนึกภาพว่าคุณกำลังส่งจดหมายไปที่ตู้ไปรษณีย์กลาง แต่จริงๆ แล้วจดหมายนั้นไม่ได้ไปหยุดที่ตู้ แต่มีระบบคัดแยกอัตโนมัติคอยเปลี่ยนเส้นทางจดหมายไปหาผู้รับตัวจริงตามบ้านต่างๆ ทันที ภายใน Kubernetes ก็เช่นกัน Service Dataplane คือระบบหลังบ้านที่คอยทำหน้าที่ "แปลง" เส้นทางจาก IP สมมติ ไปยัง IP ของ Pod จริงๆ ที่กำลังทำงานอยู่
การเข้าใจเรื่องนี้สำคัญมากสำหรับโปรแกรมเมอร์ เพราะถ้าวันหนึ่งระบบของคุณติดต่อ API ไม่ได้ การไล่เช็คแค่ IP ของ Service อาจไม่เพียงพอ คุณต้องเข้าใจว่า Packet (ข้อมูลขนาดเล็กที่ส่งผ่านเครือข่าย) เดินทางผ่านกลไกใดบ้าง เพื่อที่จะได้รู้ว่าปัญหาเกิดจากที่ไหนกันแน่
ตัวอย่าง: สมมติ Pod ฝั่ง Frontend (10.244.1.5) ต้องการเรียก API จาก Service (10.96.120.50) ระบบต้องเปลี่ยนเป้าหมายให้กลายเป็น IP ของ Pod ตัวใดตัวหนึ่งในกลุ่ม (เช่น 10.244.2.10) โดยอัตโนมัติ
2. บทบาทของ kube-proxy: ผู้จัดการจราจรประจำโหนด
kube-proxy คือโปรแกรมตัวเล็กๆ ที่ทำงานอยู่บนทุก Node ใน Cluster ของคุณ หน้าที่หลักของมันไม่ใช่การสร้าง Pod แต่เป็นการ "คอยฟัง" ข้อมูลจาก API Server ว่ามี Service หรือ Endpoint ใหม่เกิดขึ้นไหม แล้วนำข้อมูลเหล่านั้นมาสั่งการเครื่องให้จัดการเส้นทางจราจรให้ถูกต้อง
ให้เปรียบเทียบ kube-proxy เหมือนกับ "พนักงานจราจร" ที่ถือสมุดจดรายชื่อร้านค้า (Service) และตำแหน่งที่ตั้งของร้าน (Pod IP) อยู่ในมือ เมื่อใดก็ตามที่ร้านค้ามีการย้ายที่อยู่หรือเปิดสาขาใหม่ พนักงานคนนี้จะรีบไปอัปเดตป้ายบอกทางบนถนนทันที เพื่อให้ลูกค้าไม่หลงทาง
มือใหม่มักเข้าใจผิดว่า kube-proxy เป็นคนรับส่งข้อมูลเองโดยตรง แต่ความจริงมันแค่ "ตั้งกฎ" ไว้ที่ระดับ Kernel ของ Linux เท่านั้น เมื่อกฎถูกตั้งเสร็จแล้ว ข้อมูลจะวิ่งผ่านไปเองโดยที่ kube-proxy ไม่ต้องเข้ามาแทรกแซงในทุกๆ Packet ทำให้ระบบทำงานได้รวดเร็วมาก
ตัวอย่าง: การตรวจสอบว่า kube-proxy กำลังทำงานอยู่บนโหนดของคุณหรือไม่ สามารถเช็คได้ด้วยคำสั่ง:
# ตรวจสอบสถานะของ kube-proxy ใน Namespace kube-system
kubectl get pods -n kube-system -l k8s-app=kube-proxy
# ผลลัพธ์ที่ควรเห็นคือสถานะ Running ในทุกๆ โหนดของ Cluster
3. โลกของ iptables: วิธีการคลาสสิกในการส่งข้อมูล
iptables คือเครื่องมือมาตรฐานใน Linux ที่ใช้สำหรับจัดการกฎของ Firewall และการแปลงที่อยู่ของ Packet (Network Address Translation หรือ NAT) ซึ่ง kube-proxy ในยุคแรกเริ่มใช้เครื่องมือนี้ในการทำหน้าที่เป็นตัวกลางส่งต่อข้อมูลจาก ClusterIP ไปยัง Pod ปลายทาง
เมื่อ Packet วิ่งเข้ามาที่เครื่อง กฎของ iptables จะทำการตรวจสอบว่า "ปลายทางคือ Service ใช่ไหม?" ถ้าใช่ มันจะทำการทำ DNAT (Destination NAT) เพื่อเปลี่ยน IP ปลายทางจาก Service IP ให้กลายเป็น IP ของ Pod จริงๆ ที่พร้อมให้บริการอยู่แบบสุ่มหรือตามเงื่อนไขที่ตั้งไว้
จุดอ่อนที่สำคัญของวิธีนี้คือ Scaling Problem ยิ่งคุณมี Service จำนวนมาก กฎใน iptables ก็จะยิ่งยาวขึ้นเรื่อยๆ ทำให้การค้นหาเส้นทางในแต่ละครั้งต้องใช้เวลานานขึ้น ส่งผลให้ประสิทธิภาพของเครือข่ายลดลงเมื่อ Cluster มีขนาดใหญ่เกินกว่าที่เครื่องจะรับไหว
ตัวอย่าง: การดูรายการกฎที่ kube-proxy สร้างไว้ใน iptables (ต้องใช้สิทธิ์ root บนโหนด):
# รายการกฎทั้งหมดที่เกี่ยวกับ Service
sudo iptables -t nat -L KUBE-SERVICES -n
# สิ่งที่คุณจะเห็นคือตารางรายการ IP ที่ถูกแมปเข้าหากัน
4. IPVS: ทางเลือกใหม่ที่เร็วกว่าและเสถียรกว่า
IPVS (IP Virtual Server) ถูกพัฒนาขึ้นมาเพื่อแก้ปัญหาการขยายตัวของ iptables โดยเฉพาะ มันถูกออกแบบมาเพื่อทำหน้าที่เป็น Load Balancer ในระดับ Kernel โดยใช้โครงสร้างข้อมูลแบบ Hash Table ซึ่งช่วยให้การค้นหาเส้นทางทำได้รวดเร็วมากแม้จะมี Service เป็นพันรายการ
หาก iptables คือการอ่านป้ายบอกทางทีละป้ายจนกว่าจะเจอทางออก IPVS ก็เหมือนกับการมี "แผนที่ดิจิทัล" ที่บอกพิกัดปลายทางทันทีโดยไม่ต้องไล่อ่านทีละป้าย ทำให้การจัดการทราฟฟิกใน Cluster ขนาดใหญ่มีความเสถียรมากกว่าอย่างเห็นได้ชัด
สำหรับการเป็นโปรแกรมเมอร์ การรู้ว่า Cluster ของเราใช้ iptables หรือ IPVS จะช่วยให้เราเลือกเครื่องมือตรวจสอบ (Troubleshooting) ได้ถูกต้อง หากระบบช้าในระดับเครือข่าย การพิจารณาเปลี่ยนจาก iptables มาเป็น IPVS อาจเป็นทางออกที่ช่วยเพิ่มประสิทธิภาพได้ทันที
ตัวอย่าง: ตรวจสอบว่าปัจจุบัน Cluster ของคุณใช้โหมดการจัดการเครือข่ายแบบใด:
# ตรวจสอบ Log ของ kube-proxy เพื่อดูโหมดที่ใช้งาน
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep "Using"
# ผลลัพธ์จะแสดงว่าระบบเลือกใช้ iptables หรือ ipvs
5. eBPF: อนาคตของการสื่อสารใน Kubernetes
eBPF (Extended Berkeley Packet Filter) คือเทคโนโลยีที่ล้ำสมัยที่สุดในปัจจุบัน มันอนุญาตให้เราเขียนโปรแกรมขนาดเล็กไปรันในระดับ Kernel โดยตรง เพื่อดักจับและแก้ไข Packet ได้อย่างอิสระโดยไม่ต้องผ่านโครงสร้างที่ซับซ้อนของ iptables หรือ IPVS เลย
ให้นึกถึง eBPF เหมือนกับ "การเขียนโปรแกรมเสริม" ที่แทรกเข้าไปในระบบปฏิบัติการ เพื่อสั่งการให้ข้อมูลเดินทางแบบทางลัดที่สุดเท่าที่จะเป็นไปได้ ทำให้การสื่อสารระหว่าง Pod ทำได้รวดเร็วและปลอดภัยขึ้น แถมยังได้ข้อมูลเชิงลึก (Observability) ที่ละเอียดกว่าเดิมมาก
โปรเจกต์ชื่อดังอย่าง Cilium ได้นำ eBPF มาใช้เพื่อแทนที่หน้าที่บางส่วนของ kube-proxy ทำให้การจัดการเครือข่ายใน Kubernetes ยุคใหม่มีความคล่องตัวสูงขึ้นมาก นี่คือทักษะที่โปรแกรมเมอร์สาย Infrastructure ในอนาคตต้องให้ความสำคัญ
ตัวอย่าง: การใช้ eBPF ช่วยให้เราสามารถทำ Service Mesh ได้โดยไม่ต้องมี Sidecar Container ที่กินทรัพยากรเครื่อง ทำให้แอปพลิเคชันของคุณเบาและทำงานได้เร็วขึ้นอย่างมาก
6. สรุป: การเลือกใช้งานและการประยุกต์ใช้จริง
สรุปแล้ว การทำงานของ Service Dataplane คือหัวใจของการเชื่อมต่อใน Kubernetes โดยมีวิวัฒนาการมาตั้งแต่ iptables ที่เรียบง่าย, IPVS ที่เน้นความเร็ว, จนถึง eBPF ที่เน้นประสิทธิภาพขั้นสุด หัวใจสำคัญคือการเข้าใจว่า Packet วิ่งจากจุดหนึ่งไปยังอีกจุดหนึ่งผ่านกฎที่ใครเป็นคนสร้าง
สำหรับมือใหม่ เมื่อเจอปัญหา "ติดต่อ Service ไม่ได้" ให้เริ่มจาก:
- เช็คว่า Pod ปลายทางมีสถานะ Ready หรือไม่
- ตรวจสอบ
Serviceว่าชี้ไปยังEndpointsถูกต้องไหม - ตรวจสอบกฎ
iptablesหรือสถานะIPVSบนโหนดเพื่อหาจุดที่ Packet หายไป
การฝึกฝนเหล่านี้จะทำให้คุณไม่ได้เป็นแค่คนเขียนโค้ดที่รอให้ระบบทำงาน แต่เป็น "วิศวกร" ที่เข้าใจโครงสร้างพื้นฐานอย่างถ่องแท้ ซึ่งเป็นจุดต่างสำคัญที่ทำให้โปรแกรมเมอร์เก่งๆ แตกต่างจากคนทั่วไป ความรู้ใน Level 8 นี้คือรากฐานที่จะทำให้คุณรับมือกับปัญหาที่ซับซ้อนใน Production ได้อย่างมั่นใจครับ
ที่มา: Kubernetes Networking [Level-8: kube-proxy / iptables / IPVS / eBPF] — DEV Community
