กรณีศึกษาการเพิ่มเสถียรภาพเครือข่ายของ Cilium: ผลลัพธ์น่าทึ่งจากการแก้โค้ดเพียงเล็กน้อย

 (gosuda.org)
9 คะแนน โดย lemonmint 2025-04-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนะนำกรณีของ PR ที่ช่วยยกระดับเสถียรภาพของระบบอย่างมากด้วยการแก้โค้ดเพียงเล็กน้อย (เพิ่ม if เพียงหนึ่งบรรทัด)
  • ผลกระทบและความสำคัญของ PR "bpf:nat: Restore ORG NAT entry if it's not found"

หลักการพื้นฐานของ NAT(Network Address Translation)

  • NAT คือเทคโนโลยีที่ทำให้อุปกรณ์หลายเครื่องสามารถใช้ public IP ร่วมกันได้
  • ทำให้การสื่อสารระหว่างอุปกรณ์ภายใน (Private IP:Port) กับอินเทอร์เน็ตภายนอกเป็นไปได้
  • ตาราง NAT จะเก็บข้อมูลการแมประหว่างที่อยู่ต้นทางกับที่อยู่ที่ถูกแปลงแล้ว
  • กระบวนการ:
    1. อุปกรณ์ภายในพยายามเชื่อมต่อไปยังเซิร์ฟเวอร์ภายนอก
    2. อุปกรณ์ NAT แปลง IP/พอร์ตต้นทางเป็น public IP/พอร์ต (SNAT)
    3. แปลงการตอบกลับจากเซิร์ฟเวอร์ภายนอกกลับไปยังอุปกรณ์ภายในอีกครั้ง (DNAT)

การใช้งาน NAT ใน Kubernetes

  • มีสองกรณีหลักที่ NAT ถูกใช้อย่างสำคัญใน Kubernetes:
    1. การสื่อสารจาก Pod ออกไปนอกคลัสเตอร์: แปลง IP ภายในของ Pod เป็น public IP ของโหนด
    2. การสื่อสารจากภายนอกเข้าสู่ Pod ผ่าน NodePort: เราต์คำขอจากภายนอกไปยัง Pod ที่กำหนด

วิธีที่ Cilium ใช้งาน NAT

  • โดยทั่วไปบน Linux จะจัดการ NAT ด้วย conntrack และ iptables
  • Cilium ใช้เทคโนโลยี eBPF เพื่อข้าม Linux network stack แบบดั้งเดิม
  • Cilium จัดการตาราง NAT โดยตรงด้วย LRU hash map (BPF_MAP_TYPE_LRU_HASH)

สาเหตุของปัญหา

  • ปัญหาการค้นหา (Lookup): เพื่อจัดการแพ็กเก็ตสองทิศทาง (ขาออก/ขาเข้า) จึงบันทึกข้อมูลชุดเดียวกันสองครั้ง (RevSNAT)
  • ข้อจำกัดของ LRU: ด้วยทรัพยากรที่จำกัด รายการที่ถูกใช้น้อยอาจถูกลบออก
  • **การสูญเสียการเชื่อมต่อ # กรณีที่ Cilium เพิ่มเสถียรภาพเครือข่ายได้มากจากการแก้โค้ดเล็กน้อย

บทนำ: พลังของการเปลี่ยนโค้ดเพียงเล็กน้อย

  • กรณีตัวอย่างที่การเพิ่มบล็อก if เพียงหนึ่งจุดช่วยยกระดับเสถียรภาพของระบบอย่างมหาศาล
  • PR ที่เกี่ยวข้อง: "bpf:nat: Restore ORG NAT entry if it's not found"
  • อธิบายให้เข้าใจได้แม้ไม่ใช่ผู้เชี่ยวชาญด้านเครือข่าย

หลักการพื้นฐานของ NAT(Network Address Translation)

  • NAT คือเทคโนโลยีที่ทำให้อุปกรณ์หลายเครื่องใช้ public IP เดียวกันได้
  • ทำงานด้วยการแมปคู่ค่า Private IP:Port ภายในไปเป็น Public IP:Port ภายนอก
  • ลำดับการทำงาน:
    • อุปกรณ์ภายในพยายามเชื่อมต่อกับเซิร์ฟเวอร์ภายนอก
    • อุปกรณ์ NAT แปลงการสื่อสารภายในให้เป็นการสื่อสารภายนอก (SNAT)
    • เมื่อมีการตอบกลับ ก็แปลงกลับเป็นการสื่อสารภายในเดิมอีกครั้ง (DNAT)
    • ข้อมูลการแปลงจะถูกบันทึกไว้ในตาราง NAT

การใช้งาน NAT ใน Kubernetes

  • Kubernetes มีโครงสร้างเครือข่ายที่ซับซ้อน และใช้งาน NAT ในหลายจุด
  • กรณีใช้งาน NAT หลัก:
    1. การสื่อสารจาก Pod ออกไปนอกคลัสเตอร์: แปลง private IP ของ Pod เป็น public IP ของโหนด (SNAT)
    2. การสื่อสารจากภายนอกเข้าสู่ Pod ผ่าน NodePort: ทำ DNAT และ SNAT พร้อมกันเพื่อส่งทราฟฟิกภายนอกไปยัง Pod ที่เหมาะสม

แนวทางเฉพาะของ Cilium

  • ในระบบ Linux ทั่วไป มักจัดการ NAT ผ่าน conntrack subsystem และ iptables
  • Cilium ใช้เทคโนโลยี eBPF เพื่อข้าม Linux network stack แบบดั้งเดิม
  • สำหรับการจัดการ SNAT จะดูแลตาราง SNAT เองโดยตรงในรูปแบบ LRU hash map (BPF_MAP_TYPE_LRU_HASH)

สาเหตุและอาการของปัญหา

  • ปัญหาการค้นหา (Lookup):

    • ต้องค้นหาใน hash table เพื่อยืนยันการประมวลผล NAT
    • เพื่อให้ค้นหาได้เร็ว จึงแทรกข้อมูลชุดเดียวกันลงตารางสองครั้งในรูปแบบ RevSNAT โดยสลับค่า src และ dst

  • ปัญหา LRU (Least Recently Used):

    • เนื่องจากข้อจำกัดของทรัพยากร ข้อมูลอาจถูกลบออกด้วยตรรกะ LRU

  • ปัญหาที่เกิดจากการประกอบกัน:

    • สำหรับการเชื่อมต่อ TCP หนึ่งครั้ง ข้อมูลเดียวกันจะถูกบันทึกสองครั้ง
    • หากข้อมูลชุดใดชุดหนึ่งจากสองชุดถูก LRU ลบออก การเชื่อมต่อทั้งหมดอาจขาดได้

วิธีแก้ที่เรียบง่ายแต่ได้ผลมาก

  • แนวคิดหลัก: เมื่อพบแพ็กเก็ตในทิศทางหนึ่ง ให้รีเฟรชรายการของทิศทางตรงข้ามไปพร้อมกัน
  • ด้วยวิธีง่าย ๆ นี้:
    • รายการทั้งสองทิศทางจะถูกอัปเดต ทำให้ไกลจากลำดับความสำคัญในการถูกลบแบบ LRU
    • ลดโอกาสเกิดสถานการณ์ที่มีเพียงรายการด้านเดียวถูกลบจนการสื่อสารทั้งหมดสะดุด
    • ในการทดสอบ benchmark พบว่าเสถียรภาพเครือข่ายดีขึ้นอย่างมาก

บทสรุปและบทเรียน

  • เป็นกรณีที่แสดงให้เห็นว่าแม้ในระบบที่ซับซ้อน แนวคิดที่เรียบง่ายก็สร้างการเปลี่ยนแปลงใหญ่ได้
  • แก้ปัญหาโดยอาศัยความรู้พื้นฐานด้าน CS (วิธีการทำงานของ NAT)
  • อีกแนวทางหนึ่งในการหลีกเลี่ยงปัญหาคือเพิ่มขนาดของตาราง NAT
  • ขอคารวะต่อความทุ่มเทของนักพัฒนาที่วิเคราะห์ปัญหาอย่างละเอียดและมีข้อมูลเชิงประจักษ์รองรับ

คุณค่าของแนวทางเชิงเทคนิค

  • ความสำคัญของการเข้าใจต้นตอของปัญหาและแก้ไขมันอย่างถูกจุด
  • บทเรียนว่าการแก้โค้ดเพียงเล็กน้อยสามารถยกระดับเสถียรภาพของทั้งระบบได้มาก
  • ความสำคัญของการเข้าใจหลักการพื้นฐาน แม้ในระบบที่ซับซ้อน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
ethanhur 2025-04-14

ขอบคุณที่มาแบ่งปันประสบการณ์ที่ยอดเยี่ยมครับ!