ทำไมพอดของ GKE จึงเข้าถึงโฮสต์ภายในองค์กรผ่าน VPN ไม่ได้

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

อ่านรายการที่บังคับใช้ก่อนเปลี่ยนอะไร

GKE มาพร้อมเอเจนต์ที่ตัดสินใจตามช่วงปลายทางว่าทราฟฟิกของพอดจะถูกเขียนใหม่เป็นที่อยู่ของโหนดตอนออกหรือไม่ การกำหนดค่าที่จัดส่งมาระบุบล็อก RFC1918 สามบล็อก คือ 10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16 เป็นปลายทางที่ยกเว้น ดังนั้นทุกอย่างที่คุณส่งจากพอดไปยังโฮสต์ 10.x ภายในจะออกจากโหนดโดยที่ที่อยู่ของพอดเองยังติดอยู่ ทราฟฟิกของโหนดเองไม่ถูกเขียนใหม่ และนั่นคือเหตุผลที่ปิงของโหนดทำงาน

อ่านการกำหนดค่าที่ตั้งใจและกฎที่ติดตั้งไว้ เพราะทั้งสองอาจไม่ตรงกัน kubectl -n kube-system get configmap ip-masq-agent -o yaml แสดงสิ่งที่บอกเอเจนต์ไป และ kubectl -n kube-system get pods -l k8s-app=ip-masq-agent แสดงว่ามีอะไรทำงานเพื่อบังคับใช้หรือไม่ บนโหนด iptables-save | grep -i masq แสดงกฎที่มีอยู่จริงในเคอร์เนล เมื่อ ConfigMap พูดอย่างหนึ่งและกฎพูดอีกอย่าง ผู้ต้องสงสัยคือเอเจนต์ ไม่ใช่เครือข่าย

ยืนยันที่อยู่ต้นทางด้วยการดักจับ

ดักจับก่อนที่คุณจะเปลี่ยนรายการ ตัวกรองที่ปลายทางเดียวทำให้ผลลัพธ์อ่านได้: tcpdump -ni any host 10.20.30.40

เปรียบเทียบกับสิ่งที่ฝั่งตรงข้ามรายงาน การดักจับฝั่งภายในที่แสดงที่อยู่พอดและไม่มีคำตอบปิดวงจร รายการยกเว้นอธิบายความไม่สมมาตรได้โดยไม่มีความผิดพลาดของอุโมงค์ การสังเกตที่อยู่ต้นทางเดียวสองครั้งก็พอที่จะหยุดคาดเดาเรื่อง CNI

จำกัดการยกเว้นให้แคบลงถึง CIDR ของพอด

การซ่อมที่ได้รับการสนับสนุนทำให้การยกเว้นแคบลงแทนที่จะลบทิ้ง: เก็บ CIDR ของพอดไว้เป็นข้อยกเว้นและปล่อยส่วนที่เหลือของพื้นที่ 10.x ไป รายการนั้นอยู่ใน ConfigMap ของเอเจนต์ภายใต้ nonMasqueradeCIDRs และการเปลี่ยนคือการแก้ไขตามด้วยการเปิดตัว แทนที่รายการกว้างด้วยช่วงพอดจริงของคลัสเตอร์ เก็บบล็อกส่วนตัวอื่นไว้หากทราฟฟิกภายในคลัสเตอร์ยังต้องการ และปล่อย resyncInterval ไว้ตามเดิมเว้นแต่คุณมีเหตุผล นำไปใช้ ยืนยันว่าพอดของเอเจนต์รีสตาร์ทแล้ว และยืนยันว่ากฎของเคอร์เนลเปลี่ยนแล้ว

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

ในคลัสเตอร์ที่มีพูลโหนดหลายพูล ตรวจสอบว่าเอเจนต์ถูกจัดตารางบนโหนดที่พอดที่ได้รับผลกระทบทำงานจริง พูลที่ไม่มี DaemonSet จะเก็บกฎเก่าไว้ และไม่มีอะไรใน ConfigMap จะแสดงให้เห็น

ทางเลือกและต้นทุน

อีกทางเลือกหนึ่งเก็บที่อยู่พอดไว้ไม่แตะต้องและสอนเส้นทางให้รู้จัก CIDR ของพอดจะเข้าไปในตัวเลือกทราฟฟิกของ Cloud VPN และฝั่งภายในต้องการเส้นทางขากลับเพื่อให้คำตอบรู้ว่าจะไปที่ไหน วิธีนี้รักษาเอกลักษณ์ของพอดซึ่งแบบจำลองความปลอดภัยบางแบบต้องการ และขยายทั้งขอบเขตการกำหนดเส้นทางและไฟร์วอลล์ที่ฝั่งตรงข้ามต้องยอมรับ

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

ตรวจสอบและย้อนกลับ

รันการดักจับเดิมอีกครั้ง หากการดักจับระดับโหนดยังพิมพ์ที่อยู่พอดหลังการแก้ไขของคุณ แสดงว่ากฎไม่เคยเปลี่ยน ไม่ว่า ConfigMap จะพูดอะไร สายคือข้อเท็จจริง ที่เหลือคือการอนุมาน

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

การย้อนกลับคือ ConfigMap ก่อนหน้า นำไปใช้แบบเดียวกัน พร้อมการยืนยันเดียวกันว่าเอเจนต์รีสตาร์ทและกฎเปลี่ยนแล้ว เก็บบันทึกที่อยู่ต้นทางก่อนและหลังสำหรับคำขอที่รู้จักหนึ่งรายการไว้ในบันทึกการเปลี่ยนแปลง เพราะบรรทัดเดียวนั้นคือสิ่งที่พิสูจน์ว่าการเปลี่ยนแปลงทำตามที่คุณบอก คู่มือเอเจนต์ IP masquerade ของ GKE อธิบายค่าเริ่มต้นและฟิลด์ของ ConfigMap หากที่อยู่ต้นทางไม่เปลี่ยนหลังการเปิดตัว เอเจนต์ไม่ได้ทำงานบนโหนดนั้น และการแก้ไข YAML ไม่ว่าจะมากเพียงใดก็ไม่ช่วย