VPN sidecar ต้องมีกฎการเริ่มและกฎการล้มเหลว

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

ลำดับเพียงกั้นคำขอแรก

Kubernetes รองรับวงจรชีวิต sidecar ที่สร้างจาก init container ที่รีสตาร์ตได้ ในแบบจำลองนั้น probe ตอนเริ่มสามารถยับยั้งขั้นตอนเริ่มต้นถัดไปจนกว่าอุโมงค์จะรายงานว่าพร้อม นี่เป็นการปรับปรุงจริง และควรใช้อย่างตั้งใจแทนการเพิ่ม sleep ลงในสคริปต์จุดเข้า ประตูจะดีได้เพียงเท่ากับเงื่อนไขที่มันทดสอบ

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

บอกว่าประตูสังเกตอะไร มีโปรเซสอยู่ มีอินเทอร์เฟซอยู่ แฮนด์เชกเสร็จสิ้น แต่ละข้อเป็นข้ออ้างที่อ่อนกว่า “เส้นทางข้อมูลไปยังปลายทางที่ pod นี้ต้องการทำงาน”

บังคับใช้เส้นทางข้อมูลแทนการสันนิษฐาน

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

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

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

ทดสอบทราฟฟิกที่คุณไม่ได้กล่าวถึง

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

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

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

เขียนบันทึกการดีพลอย

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

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

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