Pod IP, ClusterIP หรือโหลดบาลานเซอร์ภายในสำหรับผู้ใช้ VPN
Pod IP ถูกกำหนดเส้นทางผ่าน VPN ได้จนกว่า Pod จะถูกแทนที่ เปรียบเทียบการเข้าถึง Pod โดยตรง, ClusterIP และบาลานเซอร์ภายใน และดูว่าการเข้าถึงแต่ละแบบมีต้นทุนอะไรกับคุณ
ด้วย VPC CNI นั้น Pod สามารถถือที่อยู่จาก VPC ได้ และผู้ใช้ VPN ที่มีเส้นทางที่ถูกต้องก็เข้าถึงได้โดยตรง นั่นทำให้การเข้าถึง Pod โดยตรงดูเป็นตัวเลือกที่ง่ายที่สุด และก็เป็นเช่นนั้นจริงจนกว่า Pod จะถูกแทนที่ ที่อยู่ที่ผู้ใช้จดจำควรเป็นของแอปพลิเคชัน ไม่ใช่ของรีพลิกา การเปรียบเทียบทางเข้าทั้งสามจึงขึ้นอยู่กับว่าวัตถุใดถือครองที่อยู่ และอะไรต้องทำงานต่อไปเมื่อเวิร์กโหลดย้าย
เลือกตามวงจรชีวิตก่อน แล้วจึงเลือกตามสิ่งที่เครือข่ายต้องทำเพื่อให้ทางเข้าเข้าถึงได้
สามทางเข้า สามวงจรชีวิต
Pod IP เป็นของ Pod คือจัดสรรไปพร้อมกันและคืนเมื่อสิ้นสุด ส่วน ClusterIP เป็นของ Service และเป็นที่อยู่เสมือน มีความหมายเฉพาะที่ที่มีการกำหนดเส้นทางบริการของคลัสเตอร์อยู่เท่านั้น ส่วนโหลดบาลานเซอร์ภายในเป็นของทรัพยากรคลาวด์ที่คอนโทรลเลอร์ของคลัสเตอร์ตั้งโปรแกรมด้วยแบ็กเอนด์ โมเดลความเป็นเจ้าของเหล่านี้บอกล่วงหน้าว่าคุณจะเจอความล้มเหลวแบบใด ที่อยู่ที่ตกยุค ชื่อที่เข้าถึงไม่ได้ หรือชุดแบ็กเอนด์ที่ล้าสมัย
เขียนการเปรียบเทียบไว้ก่อนเลือก เมื่อระบุเจ้าของและความล้มเหลวได้แล้ว การเลือกมักเกิดขึ้นเอง
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
การเข้าถึง Pod โดยตรง: มีประโยชน์ ชั่วคราว
การเข้าถึงโดยตรงมีประโยชน์จริงสำหรับการตรวจสอบที่ควบคุมได้ คือผู้ดูแลหนึ่งคน เซสชันสั้นหนึ่งครั้ง พอร์ตที่เจาะจงหนึ่งพอร์ต แต่เป็นสัญญาที่แย่สำหรับผู้ใช้ เพราะที่อยู่เป็นรายละเอียดการทำงานที่เปลี่ยนทุกครั้งที่ปรับใช้ และการจดมันลงในวิกิก็คือทางที่ทำให้บริการที่ใช้งานได้กลายเป็นข่าวลือ
ยังชักนำให้เกิดกฎที่กว้างด้วย การอนุญาตให้ผู้ดูแลหนึ่งคนเข้าถึง Pod หนึ่งตัวไม่ใช่การอนุญาตทุกที่อยู่ในซับเน็ตของโหนด และสิ่งที่มักถูกเขียนคืออย่างหลัง
ClusterIP: จำกัดอยู่ในคลัสเตอร์ตามการออกแบบ
ClusterIP ทำงานได้เพราะระนาบข้อมูลของคลัสเตอร์กำหนดเส้นทางให้อยู่ภายในคลัสเตอร์ จากแล็ปท็อปบน VPN ที่อยู่นั้นไม่มีความหมาย เว้นแต่มีบางอย่างเปิดเผยมันโดยเจตนา ชื่อที่ลงท้ายด้วย svc.cluster.local เป็นของ DNS ของคลัสเตอร์ การคัดลอกไปยังไคลเอนต์ที่มีตัวแปลงชื่ออื่นจึงได้ชื่อที่ไม่มีอยู่จริงแทนที่จะเป็นข้อผิดพลาดในการกำหนดเส้นทาง
ClusterIP ยังคงเป็นทางเข้าที่ถูกต้องสำหรับผู้เรียกภายในคลัสเตอร์ รวมถึงเวิร์กโหลดอื่น เพียงแต่ไม่ใช่กลไกการเผยแพร่สำหรับผู้ใช้ที่อยู่นอกโดเมนการกำหนดเส้นทางของคลัสเตอร์
โหลดบาลานเซอร์ภายใน: เส้นทางที่เผยแพร่
โหลดบาลานเซอร์ภายในให้ที่อยู่ส่วนตัวที่คงที่และชื่อที่โซนของคุณชี้ไปได้ ขณะที่คอนโทรลเลอร์คอยทำให้ชุดแบ็กเอนด์เป็นปัจจุบัน ดังที่คู่มือการทำโหลดบาลานซิงของ EKSอธิบาย นี่คือทางเข้าที่อยู่รอดจากการแทนที่ Pod ตามปกติโดยไม่มีใครแก้เอกสาร ต้นทุนของมันคือทรัพยากรคลาวด์ การกำหนดค่าคอนโทรลเลอร์ และเส้นทางจาก VPN และนั่นคือส่วนที่คนมักประเมินต่ำ
ใช้รูปแบบคอนโทรลเลอร์ที่คลัสเตอร์ใช้งานจริง คำอธิบายประกอบที่เขียนสำหรับการผสานรวมหนึ่งไม่ใช้กับอีกอัน
ใครคือที่อยู่ต้นทาง
กลุ่มความปลอดภัยเห็นต้นทางที่มาถึงขอบเขตของตน ซึ่งอาจเป็นไคลเอนต์ที่เชื่อมต่อหรือที่อยู่ที่ถูกแปล ขึ้นอยู่กับเส้นทาง VPN และการทำโหลดบาลานซิง บนโหนดที่ใช้ EC2 นั้น Pod ของ VPC CNI ทั่วไปสืบทอดกลุ่มของ ENI ของโหนดโดยค่าเริ่มต้น ขณะที่การกำหนดค่าที่รองรับสามารถแนบกลุ่มเฉพาะของ Pod ได้ จงเขียนกฎสำหรับเส้นทางที่บันทึกไว้ ไม่ใช่สำหรับที่อยู่แล็ปท็อปที่คาดเดา
แยกตัวรับฟังและการพิสูจน์ตัวตนของแอปพลิเคชันเองออกเป็นกลไกควบคุมต่างหาก กฎเครือข่ายที่อนุญาตให้เกิดการไหลไม่ใช่การตัดสินใจอนุญาต และไม่ควรถือเป็นเช่นนั้น
จะมอบอะไรให้ผู้ใช้
ให้ชื่อบริการแก่ผู้ใช้ ไม่ใช่ที่อยู่ เผยแพร่ชื่อในโซนส่วนตัว ชี้ไปที่ทางเข้าภายใน แล้วทดสอบด้วยการแทนที่ Pod ฝั่งแบ็กเอนด์ขณะที่ไคลเอนต์เปิดชื่อเดิมไว้ แบบฝึกหัดนั้นทดสอบคุณสมบัติที่สำคัญ คือการเข้าถึงแอปพลิเคชันเดียวกันได้หลังการปรับใช้ตามปกติ
เก็บการเข้าถึง Pod โดยตรงไว้เป็นข้อยกเว้นเชิงปฏิบัติการที่บันทึกไว้โดยมีขอบเขตของตัวเอง ห่างจากคำแนะนำสำหรับผู้ใช้