Pod, โน้ด หรือคลัสเตอร์: VPN sidecar เปลี่ยนเส้นทางอะไรจริง ๆ

VPN sidecar ใน Pod ของ Kubernetes ดูเหมือน VPN ระดับโฮสต์ที่มีมารยาทดีกว่า และความคล้ายคลึงสิ้นสุดที่ขอบเขตของเนมสเปซ คอนเทนเนอร์ใน Pod เดียวกันใช้เนมสเปซเครือข่ายร่วมกัน รวมถึงพื้นที่แอดเดรสและพอร์ต ดังนั้น sidecar ที่ติดตั้งเส้นทางและนโยบายจึงเปลี่ยนปลายทางของแพ็กเก็ตแอปพลิเคชันจริง ๆ มันไม่เปลี่ยนอะไรให้ Pod อื่นบนโน้ด และไม่แตะสแต็กของโน้ดเอง เว้นแต่คุณจะกำหนดค่าให้เป็นเช่นนั้น การเข้าใจขอบเขตนี้อย่างถูกต้องเป็นตัวกำหนดทั้งสิ่งที่คุณปรับใช้ได้และสิ่งที่ต้องทดสอบ หัวข้อด้านล่างติดตามเรื่องนี้จากเนมสเปซออกไปด้านนอก

เนมสเปซร่วม ผลลัพธ์ร่วม

คอนเทนเนอร์สองตัวใน Pod พูดคุยกันผ่าน loopback และเห็นอินเทอร์เฟซเดียวกัน นั่นคือเหตุผลที่รูปแบบ sidecar ทำงานได้ แอปพลิเคชันไม่จำเป็นต้องรู้ว่ามีทันเนลอยู่ เพราะเส้นทางที่มันแก้ไขถูกติดตั้งในเนมสเปซที่มันใช้งาน คุณสมบัติเดียวกันหมายความว่าความผิดพลาดของ sidecar คือความผิดพลาดของแอปพลิเคชัน เส้นทางที่ดักจับมากเกินไป หรือการเปลี่ยน DNS ที่ชี้ไปยังตัวแก้ไขชื่อภายในทันเนล จะมีผลทันทีกับทุกโพรเซสใน Pod นั้น ในเนมสเปซร่วมไม่มีเราเตอร์รายคอนเทนเนอร์ sidecar จึงถูกจำกัดให้อยู่เพียงโพรเซสเดียวไม่ได้

นี่คือกลไกที่ควรจำไว้ระหว่างการตรวจสอบ รัศมีของผลกระทบคือ Pod ไม่ใช่โน้ดและไม่ใช่คลัสเตอร์

สิ่งที่ sidecar เข้าไม่ถึง

Pod อื่นยังคงมีเนมสเปซและการเปลี่ยนเส้นทางของตัวเอง workload ที่ต้องการอีเกรสเดียวกันจึงต้องใช้ sidecar เดียวกัน หรือใช้การออกแบบระดับโน้ดแทน ทราฟฟิกของโน้ดเองก็อยู่นอกเนมสเปซของ Pod และ Pod ที่ใช้เครือข่ายโฮสต์เลือกที่จะออกจากการแยกตัวนี้โดยสิ้นเชิง ถ้าคุณรัน sidecar ด้วยเครือข่ายโฮสต์เพื่อเข้าถึงสิ่งที่สะดวก คุณได้ขยายขอบเขตจาก Pod เดียวไปทั้งโน้ด และควรพูดเรื่องนี้ให้ชัด

ทราฟฟิกไปยังบริการของคลัสเตอร์คือความประหลาดใจทั่วไปอีกเรื่อง เส้นทางดีฟอลต์ที่กว้างภายใน Pod อาจดักจับคำขอที่มุ่งไปยัง API เซิร์ฟเวอร์หรือบริการ ClusterIP ซึ่งต่อมาล้มเหลวในลักษณะที่ดูเหมือนทันเนลเสีย

แผนเส้นทาง: ช่วง Pod, บริการ, โน้ด และ VPN

จดช่วงทั้งสี่ไว้และตรวจสอบการทับซ้อนก่อนปรับใช้อะไร CIDR ของ Pod, CIDR ของบริการ, แอดเดรสของโน้ด และปลายทางหลัง VPN การทับซ้อนระหว่างช่วงส่วนตัวของ VPN กับพื้นที่ของคลัสเตอร์เองไม่ใช่เรื่องแปลก และเส้นทางดีฟอลต์เป็นวิธีแก้ที่ผิดสำหรับเรื่องนี้ แผนเส้นทางควรอยู่ในรีโปเดียวกับ manifest เพราะคลัสเตอร์ถัดไปอาจให้ช่วง Pod และบริการที่แตกต่างกันโดยสิ้นเชิง

DNS เป็นส่วนหนึ่งของแผน ไม่ใช่ความกังวลแยกต่างหาก sidecar ที่ เขียนการกำหนดค่าตัวแก้ไขชื่อใหม่ อาจทำให้การค้นพบบริการภายในคลัสเตอร์เสีย ขณะที่การค้นหาภายนอกทำงานสมบูรณ์

การเริ่มต้นและความล้มเหลวเป็นสถานะที่ชัดเจน

โพรเซส sidecar ที่กำลังทำงานไม่ใช่นโยบายอีเกรส ตัดสินใจว่าทราฟฟิกใดไหลได้ก่อนที่ทันเนลจะพร้อม และ จะเกิดอะไรขึ้นถ้ามันตายหลังจากนั้น แล้วนำการตัดสินใจนั้นไปใช้ เช่น โพรบที่กั้นคอนเทนเนอร์แอปพลิเคชัน นโยบายเครือข่ายที่ปฏิเสธโดยดีฟอลต์ หรือทั้งสองอย่าง หากไม่มีอย่างใดอย่างหนึ่ง แอปพลิเคชันจะเริ่มทำงาน แก้ไขชื่อ และส่งทราฟฟิกออกนอกเส้นทางปกติของโน้ดในขณะที่ทันเนลยังเชื่อมต่ออยู่

ช่องว่างนั้นสั้นในคลัสเตอร์ที่แข็งแรงและถาวรในคลัสเตอร์ที่เสีย และนั่นคือคุณสมบัติที่ผู้โจมตีหรือการรั่วไหลของข้อมูลโดยอุบัติเหตุชื่นชอบ

จับคู่ลำดับกับทดสอบความล้มเหลว ฆ่า sidecar และยืนยันว่าแอปพลิเคชันสูญเสียอีเกรสที่ตั้งใจไว้ แทนที่จะถอยกลับอย่างเงียบ ๆ

ความสามารถ นโยบาย และการทดสอบจากคอนเทนเนอร์แอป

การให้ความสามารถที่จำเป็นในการสร้างอินเทอร์เฟซและเปลี่ยนเส้นทางเป็นการตัดสินใจเรื่องสิทธิพิเศษ และสิทธิพิเศษที่เหมาะกับ Pod ที่แยกเดี่ยวนั้นไม่ได้เหมาะกับสแต็กของโน้ดโดยอัตโนมัติ ใช้กลไกนโยบายเครือข่ายและความปลอดภัยที่คลัสเตอร์รองรับ และอย่าสมมติว่าทุกการใช้งาน CNI หรือนโยบายปฏิบัติต่ออินเทอร์เฟซ VPN เหมือนกัน ความแตกต่างจะปรากฏในกรณีล้มเหลวที่คุณใส่ใจ

ทดสอบจากคอนเทนเนอร์แอปพลิเคชันจริง ด้วยคำขอใหม่ไปยังปลายทางส่วนตัว บริการในคลัสเตอร์ และอินเทอร์เน็ตสาธารณะ การทดสอบจาก sidecar พิสูจน์ว่าทันเนลทำงาน ไม่ได้พิสูจน์ว่าแอปพลิเคชันเข้าถึงสิ่งที่ต้องการ

จัดทำเอกสารสมมติฐานเครือข่ายของคลัสเตอร์ไว้ข้างการกำหนดค่า VPN การย้าย workload ไปยังคลัสเตอร์อื่นจึงเป็นการตรวจสอบแผนเส้นทาง ไม่ใช่การเปลี่ยนอิมเมจที่หยุดทำงานอย่างเงียบ ๆ