Calico Network Policy Event Driven Design — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Calico Network Policy แบบ Event Driven Design คืออะไร

Calico Network Policy Event Driven Design คือแนวทางการออกแบบนโยบายเครือข่ายในคลัสเตอร์ Kubernetes ที่ใช้ Calico เป็นเครื่องมือหลัก

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

ผมทำงานกับระบบกระจายศูนย์และซอฟต์แวร์เทรดมาหลายปี พร้อมกับการเทรดฟอเร็กซ์ 13 ปี บทเรียนที่ได้เหมือนกันทั้งสองโลกคือ "กฎที่ไม่ปรับตัวตามตลาดหรือตามระบบ คือกฎที่พาเราไปเจอปัญหา" ในเทรดเราปรับ stop loss ตาม volatility ในคลัสเตอร์เราก็ต้องปรับกฎเครือข่ายตาม lifecycle ของพอด แนวคิดแบบขับเคลื่อนด้วยเหตุการณ์จึงไม่ใช่แค่ศัพท์เท่ แต่คือความจำเป็นจริง ๆ เมื่อพอดถูกสเกลขึ้นลงทุกนาทีผ่าน Horizontal Pod Autoscaler

หัวใจของการทำงานคือ Calico ไม่ได้ดูแลแค่การบังคับใช้กฎผ่าน eBPF หรือ iptables เท่านั้น แต่ยังมี Calico Network Policy API ที่ละเอียดกว่า Kubernetes NetworkPolicy มาตรฐาน เช่น การระบุกฎตามลำดับชั้น (tier) การบันทึก log การเชื่อมต่อที่ถูกปฏิเสธ และการอ้างอิงตาม service account หรือ namespace label เมื่อเราผูกทั้งหมดเข้ากับตัวควบคุมแบบเหตุการณ์ เช่น Kubernetes Operator หรือ webhook controller ที่เราเขียนเองด้วยภาษาโปรแกรมอย่าง Go ระบบจะแปลเหตุการณ์จาก Kubernetes API Server ให้กลายเป็นการอัปเดตกฎทันทีแบบที่มนุษย์ไม่ต้องยุ่งเลย บทความชุดนี้จะพาไปทีละชั้นตั้งแต่หลักคิด สถาปัตยกรรม ตัวอย่างจริง ไปจนถึงแนวปฏิบัติที่ผมใช้ในระบบงานปี 2026

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

วิธีนี้เคยพอไหวในยุคที่สถาปัตยกรรมระบบคงที่ แต่ในปี 2026 ที่ระบบเน้นการขยายตัวอัตโนมัติ งานแบบ serverless ภายในคลัสเตอร์ และการเรียกบริการกันข้ามทีมจำนวนมาก กฎ static จะล้าหลังตัวเองภายในไม่กี่ชั่วโมง ยกตัวอย่างง่าย ๆ พอดที่ถูกขยายจำนวนในตอนตีสามเพราะ traffic เพิ่ม ถ้ากฎอ้างอิงชื่อพอดแบบตายตัว พอดชุดใหม่อาจถูกตัดขาดจากฐานข้อมูลจนระบบล่มโดยที่ไม่มีใครแตะโค้ดเลย

แบบเดิมที่ทีมสายโครงข่ายนิยมคือเขียนกฎ NetworkPolicy เป็นไฟล์เก็บในระบบควบคุมเวอร์ชัน แล้ว deploy ครั้งคราวตอนมีการเปลี่ยนแปลงโครงสร้าง วิธีนี้เคยพอไหวในยุคที่สถาปัตยกรรมระบบคงที่ แต่ในปี 2026 ที่ระบบเน้นการขยายตัวอัตโนมัติ งานแบบ serverless ภายในคลัสเตอร์ และการเรียกบริการกันข้ามทีมจำนวนมาก กฎ static จะล้าหลังตัวเองภายในไม่กี่ชั่วโมง ยกตัวอย่างง่าย ๆ พอดที่ถูกขยายจำนวนในตอนตีสามเพราะ traffic เพิ่ม ถ้ากฎอ้างอิงชื่อพอดแบบตายตัว พอดชุดใหม่อาจถูกตัดขาดจากฐานข้อมูลจนระบบล่มโดยที่ไม่มีใครแตะโค้ดเลย

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

ในการออกแบบจริง ผมแบ่งระบบออกเป็นสี่ชั้นที่ทำงานร่วมกัน ชั้นแรกคือแหล่งเหตุการณ์ (event source) ซึ่งส่วนใหญ่มาจาก Kubernetes API Server

ผ่านการเฝ้าดูทรัพยากรอย่างต่อเนื่อง เช่น เหตุการณ์การเพิ่ม แก้ไข ลบของพอด เซอร์วิส หรือเนมสเปซ เสริมด้วยแหล่งอื่นอย่างผลการตรวจสุขภาพ ข้อมูลจาก Hubble หรือ Calico log การเชื่อมต่อที่ถูกปฏิเสธ และเครื่องมือตรวจจับความผิดปกติ ชั้นที่สองคือตัวประมวลผลเหตุการณ์ มักเป็น Controller หรือ Operator ที่เขียนด้วยเฟรมเวิร์กอย่าง Kubebuilder หรือใช้เครื่องมือสำเร็จรูปอย่าง Argo Events ทำหน้าที่กรอง จัดลำดับ และแปลงเหตุการณ์ดิบให้เป็นคำสั่งที่มีความหมาย

สถาปัตยกรรมและองค์ประกอบของระบบแบบขับเคลื่อนเหตุการณ์

ในการออกแบบจริง ผมแบ่งระบบออกเป็นสี่ชั้นที่ทำงานร่วมกัน ชั้นแรกคือแหล่งเหตุการณ์ (event source) ซึ่งส่วนใหญ่มาจาก Kubernetes API Server ผ่านการเฝ้าดูทรัพยากรอย่างต่อเนื่อง เช่น เหตุการณ์การเพิ่ม แก้ไข ลบของพอด เซอร์วิส หรือเนมสเปซ เสริมด้วยแหล่งอื่นอย่างผลการตรวจสุขภาพ ข้อมูลจาก Hubble หรือ Calico log การเชื่อมต่อที่ถูกปฏิเสธ และเครื่องมือตรวจจับความผิดปกติ ชั้นที่สองคือตัวประมวลผลเหตุการณ์ มักเป็น Controller หรือ Operator ที่เขียนด้วยเฟรมเวิร์กอย่าง Kubebuilder หรือใช้เครื่องมือสำเร็จรูปอย่าง Argo Events ทำหน้าที่กรอง จัดลำดับ และแปลงเหตุการณ์ดิบให้เป็นคำสั่งที่มีความหมาย

ชั้นที่สามคือตัวตัดสินนโยบาย (policy engine) อาจเป็นกฎที่เราเขียนไว้ในรูปแบบ declarative เช่น ใช้ภาษา OPA ร่วมกับข้อมูลจากเหตุการณ์ เพื่อหาคำตอบว่าควรสร้าง แก้ไข หรือคืนค่ากฎ Calico แบบไหน ชั้นสุดท้ายคือผู้บังคับใช้ นั่นคือ Calico ที่แปลงกฎเป็นกลไกระดับเคอร์เนลผ่าน eBPF ให้มีผลทันทีที่ระดับพอด สิ่งที่ผมย้ำกับทีมเสมอคือแต่ละชั้นต้องแยกขาดกันชัดเจน อย่าผสมตรรกะการตัดสินใจเข้าไปในตัวบังคับใช้ เพราะจะทดสอบยากและแก้ไขเมื่อเกิดเหตุไม่คาดฝันก็ยากตามไปด้วย

ตารางด้านล่างสรุปองค์ประกอบหลักและบทบาทของแต่ละส่วนตามที่ผมใช้งานจริง

องค์ประกอบ	บทบาทหลัก	เครื่องมือที่นิยม	จุดที่ต้องระวัง
แหล่งเหตุการณ์	จับการเปลี่ยนแปลงสถานะระบบ	Kubernetes API, Calico Flow Log	เหตุการณ์ซ้ำซ้อนต้องกรอง
ตัวประมวลผล	แปลงเหตุการณ์เป็นคำสั่ง	Argo Events, Custom Controller	ระวังคิวล้นเมื่อเหตุการณ์พร้อมกันมาก
เอนจินนโยบาย	ตัดสินใจว่ากฎควรเป็นอย่างไร	OPA, กฎเขียนเอง	ต้องมีชุดทดสอบกฎครบถ้วน

หลักการเขียนกฎที่ผมยึดคือ "ประกาศเจตนา ไม่ใช่รายละเอียด" แทนที่จะเขียนกฎอนุญาตที่อ้างอิงชื่อพอดโดยตรง ให้ใช้ป้ายกำกับ (label) ที่มีความหมายทางธุรกิจ

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

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

การออกแบบกฎ Calico ให้ตอบสนองต่อเหตุการณ์อย่างปลอดภัย

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

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

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

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

สุดท้ายคือเรื่องการทดสอบ กฎที่ตอบสนองเหตุการณ์ต้องทดสอบในสถานการณ์จำลองก่อนขึ้นของจริงเสมอ ใช้เครื่องมืออย่าง Calico's policy test หรือสร้างคลัสเตอร์จำลองด้วย Kind แล้วสั่งเกิดเหตุการณ์ต่าง ๆ ดูว่ากฎที่ออกมาถูกต้องหรือไม่ เหมือนนักเทรดทดสอบกลยุทธ์บนข้อมูลย้อนหลังก่อนใช้เงินจริง การข้ามขั้นตอนนี้คือการพนันโดยที่ไม่รู้อัตราจ่าย

แนวปฏิบัติและข้อผิดพลาดที่พบบ่อยจากประสบการณ์จริง

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

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

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

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

ตัวอย่างการนำไปใช้งานจริงทีละขั้นตอน

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

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

คำถามที่พบบ่อย

Calico Network Policy Event Driven Design คืออะไร และแตกต่างจากการเขียน NetworkPolicy แบบ static อย่างไร?

Calico Network Policy Event Driven Design คือแนวทางการออกแนวนโยบายเครือข่ายในคลัสเตอร์ Kubernetes ที่ให้กฎการอนุญาตหรือปฏิเสธการเชื่อมต่อถูกสร้าง แก้ไข และลบออกโดยอัตโนมัติตามเหตุการณ์ที่เกิดขึ้นในระบบ เช่น การสร้างพอดใหม่ การเปลี่ยนแท็กของพอด การย้ายเวิร์กโหลดระหว่างเนมสเปซ หรือสัญญาณจากระบบตรวจจับภัยคุกคาม ต่างจากแบบ static ที่เขียนไฟล์ NetworkPolicy เก็บไว้แล้ว deploy ครั้งคราวตอนมีการเปลี่ยนแปลงโครงสร้าง แนวทางขับเคลื่อนเหตุการณ์จะทำให้ความปลอดภัย "ขยับตาม" สถานะจริงของระบบเสมอ ไม่มีช่องโหว่ช่วงที่กฎล้าสมัย ซึ่งสำคัญมากในยุคที่พอดถูกสเกลขึ้นลงตลอดเวลาผ่าน Horizontal Pod Autoscaler เพราะกฎที่อ้างอิงชื่อพอดแบบตายตัวอาจทำให้พอดชุดใหม่ถูกตัดขาดจากฐานข้อมูลจนระบบล่มโดยไม่มีใครแตะโค้ดเลย

ทำไมในปี 2026 ถึงต้องใช้แนวทาง Event Driven กับนโยบายเครือข่าย?

ในปี 2026 ระบบเน้นการขยายตัวอัตโนมัติ งานแบบ serverless ภายในคลัสเตอร์ และการเรียกบริการกันข้ามทีมจำนวนมาก ทำให้กฎ static ล้าหลังตัวเองภายในไม่กี่ชั่วโมง ด้านความปลอดภัย ผู้ไม่หวังดีสมัยนี้โจมตีด้วยระบบอัตโนมัติ ถ้าเราตอบสนองด้วยมนุษย์ในขณะที่คู่ต่อสู้ตอบสนองด้วยสคริปต์ ผลลัพธ์จะต่างกันมาก เมื่อกฎถูกปรับอัตโนมัติภายในไม่กี่วินาทีหลังเกิดเหตุการณ์ เช่น พบพอดทำงานผิดปกติ ระบบจะแคบขอบเขตการเชื่อมต่อของพอดนั้นทันที ช่วยจำกัดความเสียหายได้ดีกว่าการรอคนกดอนุมัติในเช้าวันรุ่งขึ้น อีกทั้งยังลดต้นทุนการดำเนินงาน เพราะทีมเล็กที่ดูแลคลัสเตอร์ขนาดใหญ่ไม่มีแรงพอไล่แก้กฎทีละเนมสเปซทุกครั้ง การประกาศนโยบายเจตนา (intent) แล้วให้ระบบแปลงเป็นกฎจริงช่วยลดข้อผิดพลาดจากมนุษย์ได้มหาศาล

ระบบแบบขับเคลื่อนเหตุการณ์มีองค์ประกอบอะไรบ้าง?

ระบบออกแบบเป็นสี่ชั้นที่ทำงานร่วมกัน ชั้นแรกคือแหล่งเหตุการณ์ (event source) ส่วนใหญ่มาจาก Kubernetes API Server ผ่านการเฝ้าดูทรัพยากรอย่างต่อเนื่อง เช่น เหตุการณ์การเพิ่ม แก้ไข ลบของพอด เซอร์วิส หรือเนมสเปซ เสริมด้วยแหล่งอื่นอย่างผลการตรวจสุขภาพ ข้อมูลจาก Hubble หรือ Calico log การเชื่อมต่อที่ถูกปฏิเสธ และเครื่องมือตรวจจับความผิดปกติ ชั้นที่สองคือตัวประมวลผลเหตุการณ์ มักเป็น Controller หรือ Operator ที่เขียนด้วยเฟรมเวิร์กอย่าง Kubebuilder หรือใช้เครื่องมือสำเร็จรูปอย่าง Argo Events ทำหน้าที่กรอง จัดลำดับ และแปลงเหตุการณ์ดิบให้เป็นคำสั่งที่มีความหมาย ชั้นที่สามคือตัวตัดสินนโยบาย (policy engine) ซึ่งอาจเป็นกฎที่เขียนในรูปแบบ declarative เช่น การใช้ภาษา OPA ร่วมกับข้อกำหนดที่ทีมกำหนดไว้ล่วงหน้า

Calico Network Policy API มีความสามารถอะไรที่ละเอียดกว่า Kubernetes NetworkPolicy มาตรฐาน?

Calico ไม่ได้ดูแลแค่การบังคับใช้กฎผ่าน eBPF หรือ iptables เท่านั้น แต่ยังมี Calico Network Policy API ที่ละเอียดกว่า Kubernetes NetworkPolicy มาตรฐานหลายด้าน ได้แก่ การระบุกฎตามลำดับชั

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6