KEYNOTE: Improve Container Networking Performance with BGP

ในยุคก่อนหน้านี้ เทคโนโลยีที่ถูกพูดถึงอย่างมาก คือ virtualization แต่ในยุคปัจจุบันเทคโนโลยีที่กำลังถูกพูดถึงอย่างมากกลายมาเป็น คอนเทนเนอร์ (container) ซึ่งมีส่วนเกี่ยวข้องกับ Kubernetes ค่อนข้างมาก ดังนั้น สิ่งที่เป็นความท้าทายต่อมาก็คือ DevSecOps ปัจจุบัน คนที่ทำงานสาย network หรือสาย system ไม่ได้ทำเฉพาะงานนั้น ๆ อีกต่อไป งานทั้งสองแทบจะรวมอยู่ในคนคนเดียว อาทิ คนที่ทำงานสาย network ก็ต้องมีความรู้ในสาย system ไม่ว่าจะเป็น VM หรือคอนเทนเนอร์ รวมถึงฝั่ง system ก็ต้องรู้ด้วยเช่นกัน เนื่องจากปัจจุบันเริ่มมีการ virtualization และคอนเทนเนอร์ ทำให้กลายเป็นองค์ความรู้ที่ใกล้เคียงกัน

Kubernetes cluster ของ NIPA Cloud ถูกวางอยู่บน OpenStack (Victoria) และใช้ network plugin ร่วมกับ Tungsten Fabric ซึ่งไม่ได้ติดตั้ง Kubernetes แบบ manual แต่ใช้ตัว deployment ที่เรียกว่า Rancher สำหรับการ deploy Kubernetes cluster ขึ้นมา หลังจากนั้นให้ Kubernetes cluster integrate กับ OpenStack API เข้าไป โดยดึงความสามารถของ OpenStack มาเชื่อมต่อกับ Cinder volume เพื่อทำ persistent volume บน Kubernetes และอีกส่วนหนึ่ง คือ การดึง load balancer จากเซอร์วิสใน OpenStack หรือโมดูลที่ชื่อว่า Octavia มาทำเป็น service type load balance บน Kubernetes

ปัญหาแรกที่พบ คือ pod-to-pod communication เนื่องจากว่าเรา run Kubernetes บน OpenStack platform ทำให้การสร้าง Rancher เป็นตัว deployer จะมีการ call API ไปหา OpenStack และสร้างเป็น instance ขึ้นมาเพื่อทำเป็นคลัสเตอร์ของ Kubernetes ไม่ว่าจะเป็น master node หรือ worker node ก็ตาม Rancher จะทำการ call API ของ OpenStack Nova เพื่อสร้าง instance

ด้วยความที่ NIPA Cloud เป็น public cloud ที่มี multi-tenancy network และมีการทำ network underlay ด้วยการ encapsulation โดยมีการทำ VXLan หรือ IP-IP ระหว่าง node กันอยู่แล้ว ซึ่งเป็นเลเยอร์แรกที่ทำ encapsulation ระหว่าง compute โดยจากรูปด้านบนแสดงให้เห็นว่า pod A จะวิ่งข้ามไปหา pod B ที่อยู่คนละ worker node และ worker node ก็อยู่กันคนละ compute node ทำให้ต้องมีการ double encapsulation

การ encapsulation รอบแรกเป็นการ encapsulate แพ็กเกจที่ระดับของ worker node ส่วนการ encapsulation รอบที่สอง คือ ระดับ compute node ทำให้แพ็กเกจที่วิ่งถูกห่อหุ้มทั้งหมดสองรอบ ปัญหาแรกที่เกิดขึ้น คือ performance impact และ CPU ที่ใช้ในการ process encapsulation package ปัญหาที่สองคือเรื่อง network throughput degraded เมื่อเราติดตั้งเสร็จใหม่ ๆ ใน Kubernetes cluster เราต้องทำการทดสอบ pod-to-pod bandwidth โดยพบว่า instance ไม่สามารถใช้งานได้เต็มที่ตามที่ควรจะเป็น อาทิ บน instance เคยเทสต์ได้ 10 Gbps แต่บนพอร์ตของ worker node ก็อาจจะได้แค่ 3-4 Gbps เท่านั้น

อย่างที่เราทราบกันดีว่า Kubernetes เราจะเข้าถึงแอปพลิเคชันได้ต้องอาศัย load balancer ที่เป็น external load balancer เพื่อเชื่อมต่อไปยัง backend หลังบ้าน หรือก็คือ pod ซึ่งอีกหนึ่งสิ่งที่สำคัญก็คือ Cluster IP ซึ่งคล้ายกับความ VIP ที่เอาไว้คุยกันภายใน Kubernetes ซึ่งพอเป็น external load balancer ส่วนใหญ่ก็จะรองรับการทำงานแบบ active-passive ซึ่งทำให้เกิดปัญหาคอขวด เพราะมันทำงานตัวเดียว และเป็น active ตัวเดียว อีกตัวคือ standby ไว้เฉย ๆ ไม่ได้ทำอะไร รอแค่ตัวที่เป็น active เกิดปัญหาจึงจะสวิตช์กลับมาที่ตัว standby ทำให้ resource ของเราอาจจะใช้งานได้ไม่เต็มที่ รวมถึงตอนที่มัน health check จะต้องทำระหว่าง 2 ตัว เพราะต้อง sync กันอยู่ตลอดว่ายัง active อยู่ และทำงานอยู่ได้ปกติด้วย protocol VRRP

ปัญหาอีกประการที่เจอก็คือ เมื่อ sync กันผ่านเลเยอร์สอง ก็มีโอกาสที่จะเกิดปัญหาขึ้น เช่น L2 มีปัญหาลูปที่มันเกิดขึ้น และมองว่าจริง ๆ แล้ว ตัว active ยังทำงานอยู่ปกติ ทำให้เวลาเกิดปัญหา L2 ตัวที่เป็น passive หรือตัว standby จะไปไม่ถึงตัว active ก็จะเกิดปัญหาขึ้นอีก หรือการแย่งกันเป็น active ก็จะทำให้แอปพลิเคชันเข้าไม่ได้

จากปัญหาดังกล่าว และด้วยความที่ในบริษัทหนึ่งก็อาจจะมี Kubernetes cluster หลายคลัสเตอร์ด้วยกัน โดยที่แต่ละทีมก็จะแยกกันดูแลแต่ละคลัสเตอร์ และหากต้องการที่จะให้บางเซอร์วิสที่อยู่คนละคลัสเตอร์คุยข้ามกัน เราต้องให้มันสามารถวิ่งข้ามกันได้โดยไม่ต้องผ่าน external load balancer เพื่อจะลดความซับซ้อนของการติดตั้งและดูแล

จากปัญหาทั้งหมดที่ข้างต้น จะแบ่งการ improvement ออกเป็น 3 หัวข้อหลัก ได้แก่

1. Pod-to-pod network improvement
2. Service IP ที่จะให้ยูสเซอร์เข้าใช้งานมาจาก service IP นั่นเอง โดยจะต้องมีการแก้ไขปรับปรุงเพิ่มเติม โดยใช้ BGP เข้ามาช่วย
3. Across cluster improvement

ในหัวข้อแรก คือ pod-to-pod network improvement จะพูดถึงการ tuning Kubernetes ผ่านการใช้งาน MTU Jumbo frame การเซ็ต Kubernetes proxy IPVS การทำ Calico GBP peering mode และ Calico overlay network

ในส่วนของ MTU Jumbo frame จะช่วยเพิ่มประสิทธิภาพของ throughput ที่วิ่งระหว่าง pod-to-pod ได้ด้วยตัว default ของ Calico CNI ที่เราติดตั้งบน Kubernetes โดยมีการกำหนด default MTU ไว้ให้ใช้ได้กับทุก cloud environment หรือ cloud provider ไม่ว่าจะเป็น GCP, AWS ซึ่งใน default config​ MTU ที่ทำให้ไม่สามารถใช้ throughput ได้เต็ม bandwidth ที่มี ก็ควรที่จะปรับค่า MTU calico ให้เหมาะสมกับ overlay network ของคลาวด์ที่เราใช้ โดยที่ OpenStack network ก็จะสามารถรองรับ MTU ได้สูงสุดถึง 9,000 Mbps

ส่วนต่อมาในการ improvement คือการปรับ Kubernetes proxy IPVS ตามคำแนะนำของ Thaijira เนื่องจากว่าในหมวดของ IPVS จะมีข้อดีในการที่เอามาใช้เป็น load balancer ที่ให้ performance ดีกว่า ในด้านของการทำ patching และ chain มี load balancer algorithm ให้เราเลือกใช้งานได้มากกว่าโหมดของ IPVS และก็ต้องไม่ทำให้การทำงานช้าลง เมื่อ apply policy ของ Kubernetes เมื่อเซอร์วิสของ Kubernetes มีจำนวนมาก ทั้งสองส่วนนี้จากการปรับ MTU ก็จะช่วยลดจำนวนของการทำ fragmentation บน package ของ host worker ซึ่งจะช่วยลด CPU ที่ใช้งานในการ deencapsulation และ decapsulation ทำให้ performance ของ pod-to-pod ดีมากขึ้น

ส่วนต่อมาที่มีการ improve ก็คือ caligo BGP peering mode ด้วย default ของ Kubernetes cluster ที่ใช้ CNI เป็น Caligo ที่ติดตั้งโดย Rancher มีการใช้ mode ของการ peer ระหว่าง node เป็น full mesh หรือที่เราเรียกอีกชื่อหนึ่งก็คือ node-to-node mesh จะเป็นการใช้ Caligo node ที่ด้านใน มี burst ใช้ peer BGP ไปหา node อื่น ๆ และ broadcast Route L3 ทั้งคลัสเตอร์ เพื่อให้แต่ละ pod ที่อยู่คนละ worker node คุยกันได้ เมื่อเรา scale node worker ไปจำนวนมาก เราจะพบปัญหาว่า จำนวน peer บน BGP peer ระหว่าง node-to-node มีจำนวนมาก เนื่องจากว่าทุก node ต้อง peer ไป node อื่น ๆ ให้ครบ

การแก้ปัญหา คือ เราต้องปรับเปลี่ยนตัว Caligo peering mode โดยการแบ่ง resource เป็นสองส่วน ส่วนที่เป็น route reflector server จากภาพด้านบน เราจะนำตัวคู่ master node มาทำเป็น reflector server ที่จะทำการ peer I-BGP ภายใน และรับ routing information มาจาก worker node และจะกำหนดให้ worker node มา peer กับ route reflector ให้ route reflector node เป็น route reflector client มา peer กับ master node เพื่อรับ routing information ไป ก็จะสามารถลดจำนวน peer ไปที่ worker node ได้ การ peer ไปหา node อื่น ๆ ให้เหลือแค่มา peer หา route reflector server เท่านั้น ทำให้มีการใช้ bandwidth ในการสื่อสารลดลง และลดจำนวน CPU ที่ใช้ในการแลกเปลี่ยน route กันในคลัสเตอร์ด้วย

ถัดมาก็เป็นเรื่อง Caligo overlay network อย่างที่เราทราบว่า การที่ pod-to-pod จะคุยกันได้ ต้องมีการทำ encapsulation อย่างที่เราเกริ่นไปก่อนหน้านี้ก็คือ มีข้อกังวลประการหนึ่งว่า ถ้าเรา run Kubernetes บน BareMetal ได้นั้น มันจะไม่เป็นปัญหา เนื่องจากเป็นการ encapsulation แค่เลเยอร์เดียว แต่เมื่อใดก็ตามที่เรา run Kubernetes บนคลาวด์ นั่นหมายความว่า การที่ pod คุยกับ pod จะต้องทำการ encapsulation สองรอบ

รอบแรกก็คือในระดับของ worker node ที่จะต้องทำ encapsulation ลงไปยัง hypervisor เพื่อที่จะข้ามไปยัง compute node ของคลาวด์และทำ encapsulation อีกรอบ เพื่อรองรับ multi tenancy เนื่องจาก infrastructure ของ NIPA รองรับการทำ cross subnet ซึ่งเป็นประเภทหนึ่งของ overlay ของ Kubernetes คราวนี้ cross subnet มันทำงานโดยที่ pod-to-pod ที่อยู่ใน worker และอยู่ใน subnet เดียวกัน มันจะไม่ทำการ encapsulation แต่จะทำการ encapsulation ก็ต่อเมื่อมันคือการ cross subnet โดยที่ worker อยู่คนละ sub network กัน เท่านั้น จะทำให้ throughput ของการที่ pod-to-pod ที่อยู่ใน worker และอยู่ใน subnet เดียวกันดีขึ้น ทั้งในเรื่องของ performance และเรื่องของการที่ไม่ต้องทำตัว encapsulation หรือ decapsulation นั่นหมายความว่า CPU ก็จะถูกใช้งานบนตัว worker node ได้เต็มประสิทธิภาพมากขึ้น

จากรูปจะเห็นว่า mode default ที่เป็นการ enable IP-IP สังเกตว่า IP ของ pod ที่ไฮไลต์สีแดงจะมาจาก ทุก worker node ที่มันได้รับการจัดสรรตัว IP ให้พอร์ตไปในแต่ละ worker node คราวนี้ next hob สุดท้ายก็คือ ตรง even interface ปรับขึ้น panel ศูนย์ นั่นก็คือ จะต้องมีการ encapsulation เมื่อ pod ต้องการที่จะคุยกับ pod ที่อยู่ต่าง worker node กัน

คราวนี้ หากปรับมาเป็น cross subnet ซึ่ง infrastructure ของเรารองรับอยู่แล้ว เมื่อไหร่ที่เปลี่ยนเป็น cross subnet จะเห็นว่า subnet ของ pod แต่ละ worker ไม่มีการเปลี่ยนจาก panel ศูนย์กลายเป็น eth ศูนย์ธรรมดา นั่นหมายความว่า pod-to-pod ไม่มีการ encapsulation แล้วนั่นหมายความว่าก็ทำให้ได้ประโยชน์เรื่องของ throughput และเรื่องของ CPU ที่ไม่ต้องมาทำเรื่องการ encapsulation และ decapsulation

การ improve อีกประการหนึ่ง คือ เรื่องของ service IP โดยปกติ service IP ก็ต้องการ load balancer ซึ่ง environment ของ NIPA ก็รองรับได้ แต่อย่างที่ทราบกันดีคือ topology ในการทำ active passive ก็ยังมี issue อย่างที่กล่าวไปก่อนหน้านี้

สิ่งที่ทำเพิ่มขึ้นคือ เรื่องการทำ peering BGP ในระดับ top of rack ซึ่งเป็นการจำลองมาในลักษณะเดียวกัน แต่ว่าของ NIPA Cloud จะมีเซอร์วิสที่เรากำลังพัฒนาอยู่ คือ BGP-as-a-Service ที่รันอยู่บนคลาวด์ แล้วเชื่อมในการทำ BGP peering เพื่อเอา IP service ออกมาจาก Kubernetes และ advertise ออกไปด้านนอก ไม่ว่าจะเป็น on-premise ผ่าน IP sec VPN ในระดับแอปพลิเคชันที่ต้องการความเป็นส่วนตัว หรืออยากจะให้เข้ามาถึงจากอินเทอร์เน็ตก็ได้ เช่นเดียวกันสิ่งที่ได้จากรูปแบบนี้ ได้แก่

1. ไม่ต้องใช้ external load balancer
2. BGP สามารถรองรับ ECMP นั่นหมายความว่า ทถ้าเรามี BGP-as-a-Service 2 nodes ซึ่ง active ทั้งคู่ ทำให้ปัญหาเรื่องคอขวด เรื่องของการแก้ไขปัญหา failure ก็จะเร็วขึ้น รวมถึงความสามารถควบคุม traffic ได้มากขึ้น

อย่างที่เราทราบ ถ้าเป็น BGP เรื่องของ attribute ต่าง ๆ เช่น ต้องการที่จะเป็นตัวแทน BGP-as-a-Service ตัวที่ 2 ก็แค่ทำเรื่องของตัวขาเข้า โดยอาจจะใช้แค่ตัวทำ AH path VPN ส่วนขาออกก็ทำตัว local pep คราวนี้แอปพลิเคชันเราก็จะวิ่งแค่ node ด้านซ้าย node ด้านขวา เมื่อ traffic หมด เราก็จะชัตดาวน์ตามปกติ นั่นหมายความว่า เราสามารถที่จะควบคุม downtime ได้ดีมากยิ่งขึ้น โดยเราเป็นคนควบคุม ไม่ใช้อัลกอริทึม อย่างเช่น BRP เป็นคนตัดสินใจ ถัดมาก็คือพอมันเป็น path BGP แล้วอีกอย่างหนึ่งที่เห็นได้ชัดเจนคือ source address ของ client ที่มีการ request เข้ามาใช้งานแอปพลิเคชันเรา ไม่มีการทำ NAT

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

ที่กล่าวมาทั้งหมดเหมือนจะมีแต่ข้อดี แต่ก็มีสิ่งที่เราจะต้องพิจารณาก็คือ BGP-as-a-Service หรือซอฟต์แวร์ OS ที่เราต้องเลือกมาใช้ ก็ต้องรองรับการ enable multi path บน BGP attribute ซึ่งส่วนใหญ่แล้วก็น่าจะรองรับแทบจะทั้งหมด ซึ่ง environment ก็เลือกใช้ BYOS เพราะว่ามันรองรับบน Qcow2 อยู่บน hypervisor ที่เป็น KVM ที่เราใช้อยู่บน OpenStack

อีกหนึ่งข้อที่ต้องพิจารณา คือ ถ้าเรารันแค่ router เดียวก็จะไม่มีประโยชน์ แถมยังเป็น single point of failure อีก อย่างน้อย ๆ ต้องมี 2 ตัว เพื่อทำ redundancy และจะได้ประโยชน์ของ active-active ด้วย ถัดมาก็จะเป็นเรื่องของการที่ IP pool ต้องมีการ create ขึ้นมาแล้วก็ allow prefix ที่มาจากข้างนอกด้วย เพื่อให้เข้าถึง service IP ที่เราประกาศไป ใน Kubernetes config ที่เราใส่เข้าไป และสุดท้าย คือ เรื่องการที่ต้องเลือกประเภทของเซอร์วิสของ Kubernetes ที่จะเข้ามาใช้งานให้ถูกต้อง อย่างเช่น ถ้าเราเลือก external traffic policy เป็น local แล้ว ประเภทของเซอร์วิสก็ควรจะเป็น load balancer หรือไม่ก็ node port

รูปด้านบนคือตัวอย่างว่า หลังจากที่เรามีการปรับเรื่องอาการ PLBP จาก full mesh ที่เป็น default ไปเป็น route reflector แล้ว ผลประโยชน์อีกอย่างหนึ่งที่เพิ่มเติมขึ้นมา คือ พอเรามี BGP-as-a-Service ที่จะ advertise ออกไปข้างนอกแล้ว การ peer ก็ไม่ต้องไม่จำเป็นต้อง peer full mesh แต่ peer แค่ master node ให้ทำหน้าที่เป็น route reflector server นั่นหมายความว่า route ทุกอย่างที่ BGP-as-a-Service ประกาศให้ route reflector server หรือ master node ทั้ง 3 ตัวนี้ก็จะถูก advertise ไปยังทุก worker node ที่อยู่ภายในคลัสเตอร์ของ Kubernetes แล้วใส่ keep record ให้กลับมาเป็น BGP-as-a-Service เพื่อทำ BCNP ต่อไป

นี่คือตัวอย่าง configuration บางส่วน ภาพแรก คือ การที่อุปกรณ์ของเรา หรือ router OS รองรับ ECMP หรือบน BGP เรียกว่า multi path ซึ่งน่าจะรองรับทั้งหมด ถัดมารูปที่สอง คือ การที่เมื่อเป็น route reflector แล้ว สิ่งหนึ่งที่เราต้อง configure เข้าไปใน Kubernetes ก็คือ master node ที่เป็น route reflector หมายความว่า เราต้องใส่ cluster ID ให้มันด้วย เพราะไม่อย่างนั้นมันจะแย่งกันทำงาน ในคลัสเตอร์ของ Kubernetes จะเป็น IVP นั่นหมายความว่า พอทำ route reflector แล้ว ต้องใส่คลัสเตอร์ให้มันรู้ว่าทั้ง 3 ตัวคือตัวที่เป็นเซิร์ฟเวอร์ เพื่อจะทำ route reflector ให้กับ client ที่เป็น worker node ถัดมาก็จะเป็นรูปตรงกลาง เป็นเรื่องของการสร้าง IP pool ขึ้นมาเพื่อ allow การรับ route prefix จากข้างนอกเข้ามา และรูปด้านขวาก็จะเป็นเรื่องการกำหนด external policy ที่เป็น local เพื่อให้ใช้งานร่วมกับ load balancer ที่เป็นแอปของเราในการเทสต์

reuslt หลัก ๆ ที่ต้องการจะสื่อก็คือ การทำ ECMP เพราะว่าหัวข้อนี้เป็นเรื่องของการ improve BGP ของ Kubernetes ที่เราทดสอบกัน โดยใช้วิธีสร้างตัวเซอร์วิสขึ้นมาตัวหนึ่ง เป็น Nginx เป็น load balancer IP 1.2.167.170 ประเภทหนึ่ง สองรูปด้านล่าง คือ result ของ BGP-as-a-Service ที่เห็น next hob ในกรอบสีแดง จะเห็นว่า next hob ขึ้นมาทั้ง 6 ตัว คือ worker 3 และ worker อีก 3 นั่นหมายความว่า ถ้าเซอร์วิสอยู่ที่ worker ทั้ง 3 ตัว เวลา traffic วิ่ง จะวิ่งลงไปที่ node ไหนก็ได้ ขึ้นอยู่กับเรื่องตัวการที่ทำ hashing หรือก็คือบน Linux Kernel อย่างที่เราทราบ มันมีเรื่องของการตั้ง policy ถ้าเกิดเป็น type 0 คือ hash ด้วย source IP และ HIP แต่ถ้าเกิดเราเปลี่ยนเป็น policy type 1 คือการเป็น file tube แล้วก็ hash ด้วย source IP HIP Pod , source pod, death pod และ IP protocol ซึ่งมันก็จะ hash และบาลานซ์ NCP ได้ดีกว่าประเภท type 0

รูปสุดท้ายเป็นรูปที่บอกว่า ไม่ใช่แค่ในส่วนของ BGP-as-a-Service ที่ต้องทำ ECMP แต่ worker node ก็ต้องทำเช่นเดียวกัน เพราะว่าจะต้องออกได้ทุกทาง หาก ECMP มีแค่ฝั่งเดียว ตอนตอบมันก็อาจจะไม่มีประโยชน์ ตอนที่ failover ก็อาจจะมีปัญหาเช่นเดียวกัน นี่เป็นรูปของ worker node ส่วนหนึ่งที่จะเห็นว่า IP address สมมติว่าเป็นภาพ​ IP ที่มาจากต่างประเทศ ถ้ามันเห็น 3 node นั่นหมายความว่า มี BGP-as-a-Service 3 ตัวที่มันจะส่งไปได้ทั้ง 3 ทาง ซึ่งให้น้ำหนักเท่ากันด้วย

ต่อมา คือ inter-communication ระหว่าง Kubernetes cluster จำนวน 2 คลัสเตอร์ โดยที่เรานำ BGP มาประยุกต์ใช้ในการให้ pod ที่อยู่ในคลัสเตอร์หนึ่งสามารถคุยข้ามไปยังเซอร์วิสที่อยู่อีกคลัสเตอร์หนึ่งได้

จุดประสงค์ คือ เมื่อเรามีคลัสเตอร์จำนวนหลายคลัสเตอร์แล้วแบ่งให้แต่ละทีมแยกกันดูแล แต่ก็ยังมีบางเซอร์วิสที่เราต้องการให้แอปพลิเคชันคุยข้ามกัน อย่างเช่น การมอนิเตอร์ การทำ logging หรือแม้กระทั่งการ ingress load balance ในยูสเคส ก็จะเป็นการอธิบายถึงการทำ 1 คลัสเตอร์ให้เป็น ingress load balancer จากภายนอก และให้ configure ตัว Caligo โดยใช้ burst ในการ peer กับ external router และทำการ advertise ตัว public IP prefix/32 เข้าไปให้ router ประกาศออกไปจากตัว router คราวนี้ เมื่อนำ IP มาสร้างเป็น service type load balancer เราจึงสามารถเข้าถึง software ingress ของเรา อย่างเช่น API 6 หรือ Nginx ingress ผ่าน public IP โดยที่ router จะส่ง request มาให้ worker node ที่มี pod ของ Nginx ingress controller รันอยู่ เพราะว่าเรา advertise เป็นแบบ external traffic policy แบบ local ซึ่งจะเห็นว่า best มาจาก worker node เลยนั่นเอง ส่วนต่อมาคือ การที่เรานำ master node ของ cluster A ไปคุยกับ master node ของ cluster B ด้วยการ peer BGP เข้าหากัน จะทำให้ pod ที่อยู่บนคลัสเตอร์แรกสามารถเห็น route ที่จะไปยังเซอร์วิสของคลัสเตอร์ที่สอง โดยคลัสเตอร์ที่สองก็ต้อง peer BGP และประกาศ service cluster IP มาให้ตัว burst ในฝั่งของคลัสเตอร์แรกรับรู้ว่าจะต้องไปที่ next hop ใด ก็คือ next hob ที่เห็นจะเป็น worker node ที่มี work load รันอยู่

จุดนี้ เมื่อเราคุยจาก pod ของ cluster A ไปยังคลัสเตอร์ที่รันแอปพลิเคชันอยู่ข้างหลัง ก็จะมีการ encapsulation มาให้เรียบร้อย เนื่องจากว่าอยู่คนละ subnet และเป็นการ encapsulation แบบ IP-IP มาจากคลัสเตอร์แรก

จากตรงนี้ เราก็ได้ประโยชน์สองส่วน ส่วนแรก ปกติแล้วต้องไปสร้าง external load balancer อาจจะ web proxy 2 ตัว กับ WIP อีก 1 IP ก็จะรวมเป็น public IP 3 IP แต่เราใช้แค่ /32 IP เท่านั้น

Public IP เพียงปีเดียวในการ advertise ให้ router ก็จะได้ทำเป็น service ingress ให้ใช้งานได้ รองรับทั้งการ scale เพราะว่าตัว router ที่มี HA อยู่แล้ว ก็จะ ECMP path ลงมาที่ Kubernetes ด้วย

ส่วนที่สอง คือ คนที่ดูแล Kubernetes cluster ไม่จำเป็นต้องไปจัดการ external load balancer ไม่ต้องสร้าง VM เพื่อทำ internal load balance และ external load balancer เราสามารถใช้ซอฟต์แวร์ที่อยู่บน Kubernetes ingress ได้เลย ซึ่งช่วยให้การจัดการระบบง่ายขึ้น

สิ่งที่ NIPA Cloud จะทำต่อ คือ การทำ self-service ของ BGP-as-a-Service ให้บริการในอนาคต

ต่อจากนี้ เราจะทำให้การทำ BGP-as-a-Service integrate ร่วมกันกับ Kubernetes-as-a-Service ซึ่งช่วยให้เข้าถึงได้จากอินเทอร์เน็ตในอนาคต รวมถึงเรื่องของการทำให้ public pool สามารถใช้งานเป็น multi tenancy จาก Kubernetes หลาย ๆ Kubernetes หรือหลายโปรเจกต์ได้ สุดท้ายก็คือ เรื่องของการที่เราจะปรับปรุงและพัฒนาBGP-performance-as-a-Service ด้วยเทคโนโลยี DPDK, SR-IOV หรือ SmartNIC

ผู้บรรยาย

ชาญศิลป์ ชิ้นประเสริฐ, Chief Innovation Officer

จีรพัฒน์ ศุภอภินันต์, Cloud Network Manager & PM

ประทิน บุญรอด, Site Reliability Engineer Architect

วันและเวลา

15 มิถุนายน 2566

เวลา 11:30 น. (ตามเวลาท้องถิ่น PDT)

สถานที่

Vancouver Convention Centre