Kubernetes Networking - คำแนะนำที่ครอบคลุมเกี่ยวกับแนวคิดระบบเครือข่ายใน Kubernetes

ในบล็อกก่อนหน้านี้ คุณต้องมีความเข้าใจเกี่ยวกับ Kubernetes ในบล็อกเกี่ยวกับระบบเครือข่าย Kubernetes นี้ฉันจะเน้นไปที่แนวคิดระบบเครือข่ายที่เกี่ยวข้องกับ Kubernetes เป็นหลัก

ในบล็อกของ Kubernetes Networking นี้คุณจะเข้าใจหัวข้อต่อไปนี้:

• Kubernetes คืออะไร?
• เครือข่ายใน Kubernetes
• การใช้ตัวช่วยสร้างความมั่งคั่ง
• Hands-On

Kubernetes คืออะไร?

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

ตอนนี้ทุกคนที่ทำงานกับ Kubernetes ต้องมีความเข้าใจอย่างชัดเจนเกี่ยวกับ Kubernetes Cluster เนื่องจากจะช่วยคุณในการทำความเข้าใจ Kubernetes Networking

คลัสเตอร์ Kubernetes

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

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

โทรโดยอ้างอิง c ++

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

ดังนั้นการตั้งค่าบริการคลัสเตอร์ทั้งหมดนี้และคนงานเองก็ประกอบขึ้นด้วยตัวเอง คลัสเตอร์ Kubernetes !!

คุณคิดว่าพ็อดที่จัดสรรแยกกันเหล่านี้สื่อสารกันได้อย่างไร?

คำตอบอยู่ใน Kubernetes Networking!

สมัครสมาชิกช่อง YouTube ของเราเพื่อรับการอัปเดตใหม่ .. !

ส่วนใหญ่มี 4 ปัญหาที่ต้องแก้ไขด้วยแนวคิดระบบเครือข่าย

• การสื่อสารระหว่างคอนเทนเนอร์กับคอนเทนเนอร์
• การสื่อสารแบบ Pod to pod
• Pod to service communication
• การสื่อสารภายนอกกับบริการ

ตอนนี้ให้ฉันบอกคุณว่าปัญหาข้างต้นได้รับการแก้ไขด้วย Kubernetes Networking อย่างไร

เครือข่าย Kubernetes

การสื่อสารระหว่างพ็อดบริการและบริการภายนอกกับคนในคลัสเตอร์ทำให้เกิดแนวคิดของเครือข่าย Kubernetes

ดังนั้นเพื่อความเข้าใจที่ดีขึ้นให้ฉันแบ่งแนวคิดออกเป็นดังต่อไปนี้

• การสื่อสารพ็อดและคอนเทนเนอร์
• บริการ
• การเชื่อมต่อภายนอกกับบริการผ่าน Ingress Network

การสื่อสารพ็อดและคอนเทนเนอร์

ก่อนที่ฉันจะบอกคุณว่าพ็อดสื่อสารอย่างไรให้ฉันแนะนำคุณว่าพ็อดคืออะไร?

พ็อด

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

ตอนนี้ขอสรุปให้ฟังว่าพ็อดเหล่านี้สื่อสารกันอย่างไร

มี 2 ​​ประเภทของการสื่อสาร การสื่อสารระหว่างโหนด และ การสื่อสารภายในโหนด

ดังนั้นเรามาเริ่มต้นด้วยการสื่อสารภายในโหนด แต่ก่อนหน้านั้นให้ฉันแนะนำส่วนประกอบของเครือข่ายพ็อดให้คุณทราบ

Intra-node ภายใต้เครือข่าย

เครือข่าย Intra-node pod เป็นพื้นฐานการสื่อสารระหว่างสองโหนดที่แตกต่างกันบนพ็อดเดียวกัน ให้ฉันอธิบายคุณด้วยตัวอย่าง

สมมติว่าแพ็กเก็ตกำลังเปลี่ยนจาก pod1 ถึง pod2

• แพ็กเก็ตจะออกจากเครือข่ายของ Pod 1 ที่ eth0 และเข้าสู่เครือข่ายรูทที่ veth0
• จากนั้นแพ็กเก็ตจะส่งผ่านไปยัง Linux bridge (cbr0) ซึ่งค้นหาปลายทางโดยใช้คำขอ ARP
• ดังนั้นหาก veth1 มี IP ตอนนี้บริดจ์จะรู้ว่าจะส่งต่อแพ็กเก็ตไปที่ใด

ในทำนองเดียวกันให้ฉันบอกคุณเกี่ยวกับการสื่อสารระหว่างโหนดพ็อด

อินเตอร์โหนดภายใต้เครือข่าย

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

ตอนนี้สมมติว่าแพ็กเก็ตเดินทางจาก pod1 ไปยัง pod4 ซึ่งอยู่บนโหนดอื่น

• แพ็กเก็ตออกจากเครือข่าย pod 1 และเข้าสู่เครือข่ายรูทที่ veth0
• จากนั้นแพ็กเก็ตจะส่งต่อไปยัง Linux bridge (cbr0) ซึ่งมีหน้าที่ในการร้องขอ ARP เพื่อค้นหาปลายทาง
• หลังจากบริดจ์ตระหนักว่าพ็อดนี้ไม่มีที่อยู่ปลายทางแพ็กเก็ตจะกลับมาที่อินเทอร์เฟซเครือข่ายหลัก eth0
• ตอนนี้แพ็กเก็ตออกจากโหนด 1 เพื่อค้นหาปลายทางของโหนดอื่นและเข้าสู่ตารางเส้นทางที่กำหนดเส้นทางแพ็กเก็ตไปยังโหนดที่บล็อก CIDR มี pod4
• ดังนั้นตอนนี้แพ็กเก็ตถึงโหนด 2 จากนั้นบริดจ์รับแพ็กเก็ตซึ่งทำให้คำขอ ARP เพื่อค้นหาว่า IP ที่เป็นของ veth0
• ในที่สุดแพ็คเก็ตจะข้ามท่อคู่และไปถึง pod4

นั่นคือวิธีที่พ็อดสื่อสารระหว่างกัน ตอนนี้เรามาดูกันว่าบริการช่วยในการสื่อสารของพ็อดได้อย่างไร

คุณคิดว่าบริการคืออะไร?

บริการ

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

ขณะนี้มีบริการหลายประเภทที่ให้ตัวเลือกแก่คุณในการเปิดเผยบริการนอกที่อยู่ IP ของคลัสเตอร์ของคุณ

ประเภทของบริการ

ส่วนใหญ่มีบริการ 4 ประเภท

คลัสเตอร์ IP: นี่คือประเภทบริการเริ่มต้นที่แสดงบริการบน IP ภายในคลัสเตอร์โดยทำให้บริการเข้าถึงได้ภายในคลัสเตอร์เท่านั้น

โหนดพอร์ต: ซึ่งจะแสดงบริการบน IP ของแต่ละโหนดที่พอร์ตแบบคงที่ เนื่องจากก คลัสเตอร์ บริการที่บริการ NodePort จะกำหนดเส้นทางจะถูกสร้างขึ้นโดยอัตโนมัติ เราสามารถติดต่อบริการ NodePort ภายนอกคลัสเตอร์

โหลดบาลานเซอร์: นี่คือประเภทบริการที่เปิดเผยบริการภายนอกโดยใช้ตัวจัดสรรภาระงานของผู้ให้บริการระบบคลาวด์ ดังนั้นบริการ NodePort และ ClusterIP ซึ่งตัวโหลดบาลานซ์ภายนอกจะกำหนดเส้นทางจะถูกสร้างขึ้นโดยอัตโนมัติ

ชื่อภายนอก : บริการประเภทนี้แมปบริการกับเนื้อหาของไฟล์ ชื่อภายนอก โดยส่งคืนไฟล์ CNAME บันทึกด้วยค่าของมัน

พวกที่เกี่ยวกับบริการ ตอนนี้คุณอาจสงสัยว่าบริการภายนอกเชื่อมต่อกับเครือข่ายเหล่านี้ได้อย่างไร?

นั่นไม่ใช่สิ่งอื่นใดนอกจาก เครือข่ายขาเข้า .

เครือข่ายขาเข้า

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

ตอนนี้ให้ฉันอธิบายการทำงานของ Ingress Network ด้วยตัวอย่าง

เรามี 2 โหนดโดยมีเนมสเปซเครือข่ายพ็อดและรูทพร้อมด้วยลินุกซ์บริดจ์ นอกจากนี้เรายังมีอุปกรณ์อีเธอร์เน็ตเสมือนใหม่ที่เรียกว่า flannel0 (ปลั๊กอินเครือข่าย) เพิ่มลงในเครือข่ายรูท

ตอนนี้เราต้องการให้แพ็กเก็ตไหลจาก pod1 ไปยัง pod 4

• ดังนั้นแพ็กเก็ตจึงออกจากเครือข่ายของ pod1 ที่ eth0 และเข้าสู่เครือข่ายรูทที่ veth0
• จากนั้นจะส่งต่อไปยัง cbr0 ซึ่งทำให้คำขอ ARP ค้นหาปลายทางและหลังจากนั้นพบว่าไม่มีใครในโหนดนี้ที่มีที่อยู่ IP ปลายทาง
• ดังนั้นบริดจ์จึงส่งแพ็กเก็ตไปที่ flannel0 เนื่องจากตารางเส้นทางของโหนดถูกกำหนดค่าด้วย flannel0
• ตอนนี้ flannel daemon พูดคุยกับเซิร์ฟเวอร์ API ของ Kubernetes เพื่อทราบ pod IPs ทั้งหมดและโหนดตามลำดับเพื่อสร้างการแมปสำหรับ IP พ็อดกับ IP ของโหนด
• ปลั๊กอินเครือข่ายจะรวมแพ็กเก็ตนี้ไว้ในแพ็กเก็ต UDP โดยมีส่วนหัวพิเศษที่เปลี่ยน IP ต้นทางและปลายทางเป็นโหนดตามลำดับและส่งแพ็กเก็ตนี้ออกทาง eth0
• ตอนนี้เนื่องจากตารางเส้นทางรู้วิธีกำหนดเส้นทางการรับส่งข้อมูลระหว่างโหนดแล้วจึงส่งแพ็กเก็ตไปยังโหนดปลายทาง 2
• แพ็กเก็ตมาถึงที่ eth0 ของ node2 และกลับไปที่ flannel0 เพื่อยกเลิกการแคปซูลและส่งกลับมาในเนมสเปซเครือข่ายรูท
• อีกครั้งแพ็กเก็ตจะถูกส่งต่อไปยังลินุกซ์บริดจ์เพื่อสร้างคำขอ ARP เพื่อค้นหา IP ที่เป็นของ veth1
• ในที่สุดแพ็กเก็ตก็ข้ามเครือข่ายรูทและไปถึง Pod4 ปลายทาง

นั่นคือวิธีการเชื่อมต่อบริการภายนอกด้วยความช่วยเหลือของเครือข่ายขาเข้า ในขณะที่ฉันกำลังพูดถึงปลั๊กอินเครือข่ายฉันขอแนะนำคุณเกี่ยวกับรายการปลั๊กอินเครือข่ายยอดนิยมที่มีให้

ตอนนี้ฉันได้บอกคุณมากมายเกี่ยวกับ Kubernetes Networking แล้วให้ฉันแสดงกรณีศึกษาในชีวิตจริง

กรณีศึกษา: Wealth Wizard โดยใช้ Kubernetes Networking

Wealth Wizards เป็นแพลตฟอร์มการวางแผนทางการเงินออนไลน์ที่รวมการวางแผนทางการเงินและเทคโนโลยีซอฟต์แวร์อันชาญฉลาดเพื่อให้คำแนะนำจากผู้เชี่ยวชาญในราคาประหยัด

ความท้าทาย

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

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

นอกจากนี้ยังใช้คุณลักษณะนโยบายเครือข่ายของ Kubernetes เพื่อให้สามารถควบคุมการรับส่งข้อมูลผ่านการ จำกัด การเข้าถึง

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

ดังนั้นทางออกเดียวที่ บริษัท สามารถหาได้คือการใช้ปลั๊กอินเครือข่ายและด้วยเหตุนี้พวกเขาจึงเริ่มใช้ Weave Net

สารละลาย

ปลั๊กอินเครือข่ายนี้สร้างเครือข่ายเสมือนที่มีตัวควบคุมนโยบายเครือข่ายเพื่อจัดการและบังคับใช้กฎใน Kubernetes ไม่เพียงแค่นี้ แต่ยังเชื่อมต่อคอนเทนเนอร์ Docker กับโฮสต์หลาย ๆ โฮสต์และเปิดใช้งานการค้นหาอัตโนมัติ

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

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

เอาล่ะตอนนี้คุณได้เรียนรู้ทฤษฎีมากมายเกี่ยวกับ Kubernetes Networking แล้วให้ฉันแสดงให้คุณเห็นว่ามันทำได้จริงแค่ไหน

Hands-On

ดังนั้นด้วยสมมติฐานที่ว่าคุณทุกคนได้ติดตั้ง Kubernetes ในระบบของคุณฉันจึงมีสถานการณ์ที่จะแสดง

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

ฉันจะดำเนินการตามตัวอย่างที่ระบุไว้ข้างต้นได้อย่างไร

มาเริ่มกันเลย!

ขั้นตอนที่ 1: สร้างโฟลเดอร์ในไดเร็กทอรีที่คุณต้องการและเปลี่ยนพา ธ ไดเร็กทอรีการทำงานไปยังโฟลเดอร์นั้น

mkdir HandsOn บน cd HandsOn /

ขั้นตอนที่ 2: ตอนนี้สร้างไฟล์ YAML สำหรับการปรับใช้เว็บแอปพลิเคชันและฐานข้อมูล MySQL

ขั้นที่ 3: เมื่อคุณสร้างไฟล์การปรับใช้แล้วให้ปรับใช้ทั้งสองแอปพลิเคชัน

ใช้ kubectl -f webapp.yml kubectl ใช้ -f mysql.yml

ขั้นตอนที่ 3.1: ตรวจสอบทั้งการปรับใช้

kubectl รับการปรับใช้

ขั้นตอนที่ 4: ตอนนี้คุณต้องสร้างบริการสำหรับทั้งแอปพลิเคชัน

ใช้ kubectl -f webservice.yml kubectl ใช้ -f sqlservice.yml

ขั้นตอนที่ 4.1: เมื่อสร้างบริการแล้วให้ปรับใช้บริการ

ขั้นตอนที่ 4.2: ตรวจสอบว่ามีการสร้างบริการหรือไม่

kubectl รับบริการ

ขั้นตอนที่ 5: ตอนนี้ตรวจสอบการกำหนดค่าของการเรียกใช้พ็อด

kubectl รับฝัก

ขั้นตอนที่ 6: เข้าไปในคอนเทนเนอร์ภายในพ็อด webapp

kubectl exec -it container_id bash nano var / www / html / index.php

ขั้นตอนที่ 6.1 : ตอนนี้เปลี่ยนไฟล์ $ servername จาก localhost ไปยังชื่อบริการ SQL ซึ่งคือ“ webapp-sql1 ” ในกรณีนี้และ $ รหัสผ่าน จากการ ' edureka ”. กรอกรายละเอียดฐานข้อมูลทั้งหมดที่จำเป็นและบันทึกไฟล์ index.php ของคุณโดยใช้แป้นพิมพ์ลัด Ctrl + x และหลังจากนั้นกด ย เพื่อบันทึกและกด ป้อน .

ขั้นตอนที่ 7: ตอนนี้ไปที่คอนเทนเนอร์ MySQL ที่มีอยู่ในพ็อด.

kubectl exec มัน container_id bash

ขั้นตอนที่ 7.1: เข้าถึงการใช้งานคอนเทนเนอร์ MySQL

mysql -u root -p edureka

โดยที่ -u แสดงถึงผู้ใช้และ -p คือรหัสผ่านของเครื่องของคุณ

ขั้นตอนที่ 7.2: สร้างฐานข้อมูลใน MySQL ซึ่งจะใช้ในการรับข้อมูลจาก webapp

สร้าง DATABASE ProductDetails

ขั้นตอนที่ 7.3: ใช้ฐานข้อมูลที่สร้างขึ้น

ใช้รายละเอียดสินค้า

ขั้นตอนที่ 7.4: สร้างตารางในฐานข้อมูลนี้ใน MySQL ซึ่งจะใช้ในการรับข้อมูลจาก webapp

สร้างผลิตภัณฑ์ตาราง (product_name VARCHAR (10), product_id VARCHAR (11))

ขั้นตอนที่ 7.5: ตอนนี้ออกจากคอนเทนเนอร์ MySQL เช่นกันโดยใช้คำสั่ง ทางออก .

ขั้นตอนที่ 8: ตรวจสอบหมายเลขพอร์ตที่เว็บแอปพลิเคชันของคุณใช้งานได้

kubectl รับบริการ

ขั้นตอนที่ 8.1: ตอนนี้เปิดเว็บแอปพลิเคชันบนหมายเลขพอร์ตที่จัดสรรไว้

ขั้นตอนที่ 9: เมื่อคุณคลิกที่ ส่งแบบสอบถาม ไปที่โหนดที่บริการ MySQL ของคุณกำลังทำงานอยู่จากนั้นเข้าไปในคอนเทนเนอร์

นี่จะแสดงผลลัพธ์ของรายการผลิตภัณฑ์ทั้งหมดที่คุณกรอกรายละเอียดไว้

หากคุณพบว่าบล็อก Kubernetes Networking นี้เกี่ยวข้องโปรดดูที่ โดย Edureka บริษัท การเรียนรู้ออนไลน์ที่เชื่อถือได้ซึ่งมีเครือข่ายผู้เรียนที่พึงพอใจมากกว่า 250,000 คนกระจายอยู่ทั่วโลก