VPN ของ Pod ใน Kubernetes กับเกตเวย์ขาออก: อุโมงค์เป็นของใคร
Pod มีเนมสเปซเครือข่ายของตัวเอง ดังนั้นทางเลือกจริงคือชั้นไหนที่เป็นเจ้าของอุโมงค์: ตัวตนต่อเวิร์กโหลดหรือการออกผ่าน CNI ด้วยแหล่งต้นทางร่วมเดียว
คุณปรับใช้ Pod ชื่อ vpn-gateway ชี้ไคลเอนต์ทดสอบไปที่ที่อยู่ของมัน แล้วเห็นแพ็กเก็ตหายไป ไม่มีอะไรผิดในแมนิเฟสต์และ kubelet ก็ไม่มีข้อร้องเรียน เหตุผลเป็นเชิงโครงสร้างไม่ใช่การกำหนดค่า: Kubernetes ให้ทุก Pod มีเนมสเปซเครือข่ายของตัวเอง ชื่อ ป้ายกำกับ หรือเนมสเปซ API ที่แชร์กันจึงไม่เปลี่ยนอะไรว่าของแพ็กเก็ตไปที่ไหน การตัดสินใจว่าทราฟฟิก VPN ออกจากคลัสเตอร์อย่างไรจึงเริ่มจากคำถามเรื่องความเป็นเจ้าของ ไม่ใช่เรื่องอิมเมจคอนเทนเนอร์
สองกลไกครอบคลุมการปรับใช้จริงส่วนใหญ่ และทั้งสองใช้แทนกันไม่ได้ กลไกหนึ่งวางอุโมงค์ไว้ในเนมสเปซเครือข่ายของเวิร์กโหลดเอง อีกกลไกขอให้ CNI นำทราฟฟิกที่เลือกผ่านโหนดเกตเวย์ที่กำหนด ทั้งสองล้มเหลวต่างกัน สเกลต่างกัน และขึ้นกับทีมต่างกัน นี่คือเหตุผลที่คำถามเรื่องคอนเทนเนอร์มักสร้างการถกเถียงที่ไม่จบลง
ขอบเขตของ Pod คือเนมสเปซ ไม่ใช่โฮสต์กระโดด
เนมสเปซเครือข่ายของ Linux เป็นเจ้าของอินเทอร์เฟซ ที่อยู่ เส้นทาง และกฎไฟร์วอลล์ของตัวเอง และทุก Pod ได้รับหนึ่งอัน คอนเทนเนอร์ใน Pod นั้นเข้าร่วมกับมัน และนั่นคือเหตุผลที่คอนเทนเนอร์ช่วยเหลือสามารถเขียนเส้นทางใหม่ซึ่งแอปพลิเคชันจะตามในภายหลัง Pod ข้างเคียงมีสแตกที่ดูเหมือนกันแต่แยกจากกันโดยสิ้นเชิง ไม่มีตารางที่แชร์กันให้ Pod เกตเวย์สืบทอด และไม่มีการส่งต่อทราฟฟิกโดยนัยจากเนมสเปซหนึ่งไปอีกเนมสเปซ
นี่คือเหตุผลที่รูปแบบ Pod เกตเวย์ทำงานได้ก็ต่อเมื่อมีบางสิ่งต้นน้ำส่งแพ็กเก็ตมาที่มันจริง ๆ: Service, เส้นทางแบบคงที่บนโหนด หรือนโยบายการนำทางใน CNI ที่อยู่เดี่ยว ๆ ไม่ดึงดูดอะไร
อุโมงค์ต่อ Pod ให้อะไร และมีต้นทุนเท่าไร
อุโมงค์ที่ทำงานในเนมสเปซของเวิร์กโหลดให้เวิร์กโหลดนั้นมีตัวตนไคลเอนต์ของตัวเอง ซึ่งบริการเข้าถึงระยะไกลหลายแห่งต้องการก่อนจะอนุญาตหรือคิดบัญชีเซสชัน รัศมีของความเสียหายก็ยังคงอยู่ในวงแคบ: อุโมงค์ที่พังจะทำให้ Deployment หนึ่งตัวล่มแทนที่จะเป็นเส้นทางร่วมที่ทุกอย่างใช้ วิธีที่มันทำงานขึ้นกับการนำไปใช้ และนี่คือจุดที่ผู้คนเดาผิด
การตั้งค่าที่ต้องการเพียงสถานะของเคอร์เนลสามารถจบในคอนเทนเนอร์ init แล้วออกไปได้ เดมอนในพื้นที่ผู้ใช้ที่ต้องอยู่ตลอดอายุของ Pod ต้องใช้รูปแบบคอนเทนเนอร์ init ที่รีสตาร์ตได้ซึ่งเปิดตัวเป็นไซด์คาร์แบบเนทีฟใน Kubernetes 1.29 และความแตกต่างนั้นมาจากการนำอุโมงค์ไปใช้ไม่ใช่จากรสนิยม ต้นทุนของรูปแบบนี้คือการทำซ้ำ: ทุกรีพลิกาพิสูจน์ตัวตน ได้รับที่อยู่อุโมงค์ของตัวเอง และใช้ช่องเซสชันระยะไกลหนึ่งช่อง เหตุการณ์ออโตสเกลจึงกลายเป็นเหตุการณ์ด้านความจุที่อีกฟากของลิงก์ การคัดลอกข้อมูลรับรองชุดเดียวไปยังทุกรีพลิกาไม่ได้ขจัดต้นทุนนั้น มันขจัดร่องรอยการตรวจสอบ สิทธิ์ก็สมควรได้รับการตรวจสอบแบบเดียวกัน เพราะอุโมงค์ที่ต้องการ NET_ADMIN ในเนมสเปซของตัวเองไม่มีเหตุผลจะสืบทอดอำนาจเหนือโฮสต์ทั้งหมดจากตัวอย่างที่มี privileged: true
เมื่อ CNI เป็นเจ้าของขาออก
ถ้า CNI รองรับ เกตเวย์ขาออกจะเลือกทราฟฟิกตามเวิร์กโหลดและช่วงปลายทาง แล้วส่งผ่านโหนดที่เลือกภายใต้ที่อยู่ต้นทางเดียวที่คาดเดาได้ เวอร์ชันของ Cilium เป็นเอกสารอ้างอิงทั่วไป และเอกสารของมันระบุชัดว่าฟีเจอร์นี้ต้องมีการกำหนดค่า Cilium เฉพาะบวกกับโหนดเกตเวย์ที่จัดสรรอินเทอร์เฟซและที่อยู่ที่ถูกต้อง ยังกล่าวถึงช่วงเริ่มต้นหลังสร้าง Pod ที่การนำทางยังไม่ถูกบังคับใช้ ซึ่งเป็นข้อมูลป้อนเข้าของการออกแบบไม่ใช่เชิงอรรถ
อ่านความล่าช้านั้นเทียบกับคำสัญญาของคุณ ถ้ากฎคือไม่มีทราฟฟิกใดออกไปทางอื่นได้ Pod ใหม่ที่ส่งระหว่างช่องว่างนั้นได้ละเมิดกฎไปแล้ว ลำดับการเริ่มต้นจึงต้องมีคำตอบของตัวเอง: กั้นแอปพลิเคชันไว้จนกว่านโยบายจะมีผล หรือยอมรับหน้าต่างนั้นและบันทึกไว้
รักษาข้ออ้างให้แคบ เกตเวย์ขาออกเลือกและแปลเส้นทาง มันไม่ได้ยุติ VPN และไม่ได้เปลี่ยนคลัสเตอร์ให้เป็นไคลเอนต์ของเครือข่ายระยะไกลของคุณโดยไม่มีการเชื่อมต่อที่รองรับอยู่ข้างหลัง
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
การแปลเปลี่ยนสิ่งที่ฝั่งไกลเห็นอย่างเงียบ ๆ
เมื่อเกตเวย์เขียนต้นทางใหม่ ที่อยู่ต่อ Pod ก็หายไป รายการที่อนุญาตซึ่งอิงตัวตนจึงกลายเป็นรายการที่อิงที่อยู่ร่วมเดียว นี่คือการแลกเปลี่ยนไม่ใช่ข้อบกพร่อง: กฎที่ต้องดูแลน้อยลง การระบุที่มาที่หยาบขึ้นเมื่อมีบางอย่างทำงานผิดปกติ
การพิสูจน์ตัวตนระดับแอปพลิเคชันและการบันทึกคำขอต้องรับสิ่งที่เครือข่ายไม่รายงานอีกต่อไป มองความจุและการเปลี่ยนเกตเวย์เป็นโครงสร้างพื้นฐานร่วม เพราะการรีบูตโหนดเดียวตอนนี้ขัดจังหวะทุกเวิร์กโหลดที่อยู่ข้างหลัง และตรวจเส้นทางขากลับแต่เนิ่น ๆ: ปลายทางไกลต้องรู้ว่าจะเข้าถึงที่อยู่ที่แปลแล้วได้อย่างไร โดยปกติผ่านเส้นทางหรือ NAT ที่คน ไม่ใช่แมนิเฟสต์ ต้องเป็นเจ้าของ การวางแผนที่อยู่ก็อยู่ตรงนี้ด้วย เพราะช่วงของคลัสเตอร์และระยะไกลที่ทับซ้อนกันทำให้ทั้งสองรูปแบบพัง และการใช้ IPv6 ไม่ได้เป็นข้อแก้ตัวสำหรับแผนที่ขัดแย้งกัน
ตัดสินด้วยความเป็นเจ้าของ แล้วทดสอบความล้มเหลวที่คุณสัญญาไว้
เลือกอุโมงค์ต่อ Pod เมื่อบริการระยะไกลพิสูจน์ตัวตนเวิร์กโหลดแต่ละตัว เมื่อมีเพียงไม่กี่ Deployment ที่ต้องใช้ลิงก์ และเมื่อความล้มเหลวควรอยู่ในวงแคบ เลือกเกตเวย์เมื่อทีมเครือข่ายเป็นเจ้าของเส้นทางอยู่แล้ว เมื่อเวิร์กโหลดจำนวนมากใช้ปลายทางร่วมกัน และเมื่อที่อยู่ต้นทางที่เสถียรคือจุดหมายทั้งหมดของการฝึกนี้
ไม่ว่าจะทางไหน ให้ตรวจสอบคุณสมบัติที่คุณขายไม่ใช่สภาวะคงที่ สร้าง Pod ปล่อยให้ส่งทันที และดูไม่กี่วินาทีแรกถ้าคำสัญญาคือไม่มีอะไรหลุดออกจากอุโมงค์ สเกลเป็นห้ารีพลิกาและนับเซสชันที่ปลายทางไกลรายงานถ้าคำสัญญาคือตัวตนต่อเวิร์กโหลด การตรวจสองอย่างนี้เผยข้อจำกัดของกลไกได้เร็วกว่าการทบทวนแมนิเฟสต์มาก และบอกคุณว่าทีมไหนเป็นเจ้าของเหตุการณ์ถัดไป