พอดของ GKE สูญเสียการเข้าถึง VPN หลัง 1.14: สองวิธีในการแก้ไขต้นทาง

มีการอัปเกรดเข้ามา และระบบอีกฟากของอุโมงค์เริ่มปฏิเสธทราฟฟิกพอดที่เคยทำงานได้เมื่อสัปดาห์ก่อน อุโมงค์ยังขึ้นอยู่ กฎไฟร์วอลล์ไม่ได้ถูกแตะ และไม่มีใครแก้ไขนโยบายของ peer สิ่งที่เปลี่ยนไปมองไม่เห็นในบันทึกของคลัสเตอร์:ที่อยู่ต้นทางที่ระบบเหล่านั้นเห็นอยู่ในตอนนี้ ช่องว่างนี้อธิบายความล้มเหลวที่ดูเหมือนเครือข่ายล่มแต่มีพฤติกรรมเหมือนปัญหาสิทธิ์

มีคำตอบที่ถูกต้องสองแบบ และทั้งสองพาคุณไปคนละที่ เลือกสัญญาต้นทางก่อนแก้ไข ConfigMap

กฎเริ่มต้นที่ระบบเลิกติดตั้งไปแล้ว

รีลีส GKE รุ่นก่อนติดตั้งกฎ masquerade ที่แทนที่ต้นทางของพอดด้วยที่อยู่โหนดทุกครั้งที่ปลายทางอยู่นอก 10.0.0.0/8 เกตเวย์ VPN ที่อยู่ในช่วงนั้นเห็นที่อยู่ของพอด ขณะที่สิ่งที่อยู่ไกลออกไปดูเหมือนมาจากโหนด peer สร้างรายการอนุญาตและเส้นทางย้อนกลับรอบที่อยู่โหนดเพราะนั่นคือสิ่งที่พวกเขาสังเกต

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

ไม่มีอะไรเสียหายในความหมายของชิ้นส่วนที่ตายแล้ว ทั้งสองฝ่ายเพียงแต่ไม่ตรงกันว่าต้นทางใดชอบด้วยกฎ

เลือกต้นทางที่ peer ควรเห็น

การเก็บที่อยู่ของพอดไว้เป็นสัญญาที่แม่นยำกว่า ฝ่ายไกลเห็นเวิร์กโหลดที่สร้างทราฟฟิก บันทึกยังซื่อตรง และนโยบายรายพอดเป็นไปได้ ราคาที่ต้องจ่ายคือ peer ต้องพาเพรฟิกซ์ของพอดไปด้วย

การเก็บที่อยู่โหนดไว้เป็นสัญญาที่ถูกกว่า เปิด masquerade สำหรับปลายทางนั้นอีกครั้ง แล้ว peer จะยังเห็นที่อยู่ที่ไว้วางใจอยู่แล้ว

คำถามข้อเดียวตัดสินระหว่างสองทาง: peer ทำอะไรกับต้นทาง หากบันทึก ใช้นโยบายรายต้นทาง หรือบังคับเส้นทางย้อนกลับแบบแคบ ที่อยู่ของพอดก็คุ้มกับการตั้งค่าเพิ่มเติม หากต้องการเพียงส่งคำตอบ การทำ masquerade ถูกกว่าและไม่ขออะไรจากอีกฝ่าย ทางเลือกใดก็ป้องกันได้ตราบใดที่ทั้งสองทีมเขียนไว้

ทางเลือกที่สามมักเป็นความผิดพลาด: ทำ masquerade ทุกอย่างแล้วสูญเสียความสามารถในการระบุที่มาของทราฟฟิก หลีกเลี่ยงเว้นแต่ peer จะกำหนดเส้นทางอื่นนอกเหนือจากที่อยู่โหนดไม่ได้จริง ๆ

ชี้ nonMasqueradeCIDRs ไปที่ช่วงจริง

GKE รัน ip-masq-agent ใน kube-system และ ConfigMap ของมันระบุปลายทางที่ข้าม masquerade การจะรักษาต้นทางของพอดไปยังอุโมงค์ ช่วงพอด ซับเน็ตโหนด และเพรฟิกซ์ภายในล้วนอยู่ในรายการนั้น

แทนที่ค่าตัวอย่างด้วยช่วงจากคลัสเตอร์ของคุณเอง อย่าทำรายการกว้างเกินกว่าที่ข้อกำหนดระบุ เพราะทุกรายการเพิ่มเติมเปลี่ยนสิ่งที่ปลายทางอื่นเห็น สามรายการด้านล่างแทนเครือข่ายพอด ซับเน็ตโหนด และเพรฟิกซ์หลังอุโมงค์:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

รายการ 0.0.0.0/0 ปิด masquerade สำหรับทุกปลายทาง ซึ่งเปลี่ยนวิธีที่เวิร์กโหลดที่ไม่เกี่ยวข้องปรากฏต่อบริการภายนอก และแทบไม่เคยเป็นเจตนา เอเจนต์อ่านการตั้งค่าของตนใหม่ที่ resyncInterval ดังนั้นปกติไม่จำเป็นต้องรีสตาร์ต ตรวจสอบว่าพอดของเอเจนต์ทำงานอยู่ แล้วเปิดไฟล์ที่เมานต์ไว้ภายในนั้น การอ่านไฟล์นั้นคือสิ่งที่พิสูจน์ว่าการเปลี่ยนแปลงมาถึง

เส้นทางคำตอบคืออีกครึ่งหนึ่ง

masquerade เปลี่ยนต้นทางของคำขอและไม่เปลี่ยนอย่างอื่น ไม่ว่า peer จะได้รับต้นทางใด ก็ยังต้องมีเส้นทางกลับไปยังต้นทางนั้น และคลัสเตอร์ก็ยังต้องมีเส้นทางไปยัง peer

การดักจับที่เกตเวย์ VPN แยกความล้มเหลวสองอย่างได้เร็ว แพ็กเก็ตที่มาพร้อมที่อยู่พอดและไม่เคยได้คำตอบหมายความว่า peer ไม่มีเส้นทางสำหรับเพรฟิกซ์ของพอด คำตอบที่ปรากฏที่เกตเวย์แต่ไม่เคยถึงคลัสเตอร์หมายความว่าเส้นทางภายในหายไป ไม่ว่าอย่างไรให้เขียนสัญญาลงในตั๋ว: peer เห็นต้นทางใด และส่งคำตอบกลับไปยังเพรฟิกซ์ใด

ตรวจสอบอีกครั้งหลังทุกการอัปเกรด

พฤติกรรมเริ่มต้นของ masquerade เปลี่ยนไปแล้วครั้งหนึ่ง และการเปลี่ยนพูลโหนดอาจรีเซ็ตเครือข่ายของคลัสเตอร์ มองสัญญาต้นทางเป็นสิ่งที่ต้องตรวจสอบ ไม่ใช่สิ่งที่ต้องสันนิษฐาน

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