ฉันอ่านสิ่งนี้ ในเอกสาร:
พ็อดทุกพ็อดได้รับที่อยู่ IP ของตัวเอง พ็อดบนโหนดสามารถสื่อสารกับพ็อดทั้งหมดบนโหนดทั้งหมดโดยไม่ต้องใช้ NAT
ฉันควรอ่านว่า "ทุกฝักมีของตัวเอง คลัสเตอร์เฉพาะกว้าง ที่อยู่ IP"?
ฉันคิดว่าเป็นกรณีนี้ แต่เหตุผลที่ฉันถามคือฉันสังเกตเห็นพ็อดที่มีที่อยู่ IP เดียวกันในโหนดที่แตกต่างกัน หลังจากที่ฉันเริ่มต้นคลัสเตอร์ใหม่ตามคำแนะนำ ที่นี่. คลัสเตอร์มี 3 โหนด ทดสอบ vm{4,5,6}, กับ ทดสอบ vm4 เป็นมาสเตอร์ ทำงานบนเครือข่ายจำลองท้องถิ่น 10.1.4.0/16 ฉันใช้ผ้าสักหลาดสำหรับ CNI และตั้งค่าดังนี้:
kubectl patch node test-vm{4..6} -p '{ "spec": { "podCIDR": "10.244.0.0/16" } }' # ต้องทำเช่นนี้เพราะไม่ได้ตั้งค่าไว้ในคลัสเตอร์ init ดู https://stackoverflow.com/a/60944959/2038383
ใช้ kubectl -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
สังเกตว่า 3 IP เกิดขึ้นสองครั้งสำหรับ 2 พ็อดที่แตกต่างกัน - 10.244.0.{2,3,4}:
$ kubectl รับพ็อด --all-namespaces -o กว้าง -w
NAMESPACE NAME สถานะพร้อม เริ่มใหม่ อายุ IP NODE NODE NOMINATED NODE READINESS GATES
ขดเริ่มต้น 1/1 ทำงาน 0 14m 10.244.0.4 test-vm6 <ไม่มี> <ไม่มี>
เริ่มต้น my-nginx-cf54cdbf7-d6s9m 1/1 ทำงาน 0 17m 10.244.0.3 test-vm6 <ไม่มี> <ไม่มี>
เริ่มต้น my-nginx-cf54cdbf7-twrvw 1/1 วิ่ง 0 17m 10.244.0.2 test-vm6 <ไม่มี> <ไม่มี>
เริ่มต้น my-nginx-cf54cdbf7-xpff6 1/1 ทำงาน 0 17m 10.244.0.4 test-vm5 <ไม่มี> <ไม่มี>
เริ่มต้น my-nginx-more-5f79688b9d-4c9jk 1/1 ทำงาน 0 3m10s 10.244.0.6 test-vm5 <ไม่มี> <ไม่มี>
เริ่มต้น my-nginx-more-5f79688b9d-7htsn 1/1 ทำงาน 0 3m18s 10.244.0.5 test-vm5 <ไม่มี> <ไม่มี>
เริ่มต้น my-nginx-more-5f79688b9d-gqz9b 1/1 ทำงาน 0 3m4s 10.244.0.7 test-vm5 <ไม่มี> <ไม่มี>
เริ่มต้น nginx1 1/1 ทำงาน 0 9s 10.244.0.8 test-vm5 <ไม่มี> <ไม่มี>
kube-system coredns-64897985d-kt82d 1/1 ทำงาน 0 41m 10.244.0.2 test-vm5 <ไม่มี> <ไม่มี>
ระบบ kube coredns-64897985d-rd7gz 1/1 ทำงาน 0 41m 10.244.0.3 test-vm5 <ไม่มี> <ไม่มี>
kube-system etcd-test-vm4 1/1 กำลังทำงาน 0 41m 10.1.4.36 test-vm4 <ไม่มี> <ไม่มี>
ระบบ kube kube-apiserver-test-vm4 1/1 ทำงาน 0 41m 10.1.4.36 test-vm4 <ไม่มี> <ไม่มี>
ระบบ kube kube-controller-manager-test-vm4 1/1 ทำงาน 0 41m 10.1.4.36 test-vm4 <ไม่มี> <ไม่มี>
ระบบ kube kube-flannel-ds-snkhk 1/1 ทำงาน 0 29m 10.1.4.38 test-vm6 <ไม่มี> <ไม่มี>
ระบบ kube kube-flannel-ds-wtmqg 1/1 ทำงาน 0 29m 10.1.4.37 test-vm5 <ไม่มี> <ไม่มี>
ระบบ kube kube-flannel-ds-x46xw 1/1 ทำงาน 0 29m 10.1.4.36 test-vm4 <ไม่มี> <ไม่มี>
ระบบ kube kube-proxy-mjl69 1/1 ทำงาน 0 41m 10.1.4.37 test-vm5 <ไม่มี> <ไม่มี>
ระบบ kube kube-proxy-vz2p2 1/1 ทำงาน 0 41m 10.1.4.36 test-vm4 <ไม่มี> <ไม่มี>
ระบบ kube kube-proxy-xg4gg 1/1 ทำงาน 0 41m 10.1.4.38 test-vm6 <ไม่มี> <ไม่มี>
ระบบ kube kube-scheduler-test-vm4 1/1 กำลังทำงาน 0 41m 10.1.4.36 test-vm4 <ไม่มี> <ไม่มี>
แม้ว่าเอกสารจะระบุไว้อย่างไร พ็อดทั้งหมดก็ไม่สามารถสื่อสารระหว่างกันได้ พวกเขาสามารถสื่อสารกับพ็อดบนโหนดเดียวกันเท่านั้นและทำให้เกิดข้อผิดพลาด สงสัยว่านี่เป็นธงสีแดงว่ามีบางอย่างผิดปกติหรือไม่ และกำลังมองหาคำชี้แจงในประเด็นนี้เกี่ยวกับความเป็นเอกลักษณ์ของที่อยู่ IP ของพ็อด
ฉันคิดออก ประการแรก ใช่ พ็อดควรจะมีที่อยู่ IP เฉพาะของคลัสเตอร์ เป็นพื้นฐานของวิธีการทำงานของ k8s เอกสาร k8s ที่เชื่อมโยงนั้นไร้สาระและปล่อยให้คำถามเปิดอยู่เล็กน้อย แหล่งคำพูดที่ดีกว่า:
แพลตฟอร์มเช่น Kubernetes ถือว่าแต่ละคอนเทนเนอร์ (พ็อด) มี IP ที่กำหนดเส้นทางได้ภายในคลัสเตอร์ ข้อดีของโมเดลนี้คือช่วยขจัดความซับซ้อนในการแมปพอร์ตที่มาจากการแบ่งปัน IP โฮสต์เดียว -- https://github.com/flannel-io/flannel#networking-details
หนึ่งในข้อกำหนดหลักของโมเดลเครือข่าย Kubernetes คือทุกพ็อดควรได้รับที่อยู่ IP ของตัวเอง และทุกพ็อดในคลัสเตอร์ควรสามารถพูดคุยกับพ็อดโดยใช้ที่อยู่ IP นี้ -- https://ronaknathani.com/blog/2020/08/how-a-kubernetes-pod-gets-an-ip-address/
คำถามก็คือ ทำไมพ็อดของฉันจึงถูกกำหนดที่อยู่ IP เดียวกัน โดยทั่วไปการทำเช่นนี้อยู่ที่ flannel CNI init คือ ผิด (ผมคัดลอกคำแนะนำนี้มาจาก คำตอบ SO นี้):
kubectl patch node test-vm{4..6} -p '{ "spec": { "podCIDR": "10.244.0.0/16" } }' # ต้องทำเช่นนี้เพราะไม่ได้ตั้งค่าไว้ในคลัสเตอร์ init
podCIDR จะต้องไม่ซ้ำกันสำหรับแต่ละโหนด นี่คือวิธีที่ k8s รับรองว่าพ็อดตามกำหนดการแต่ละรายการมีที่อยู่ IP ที่ไม่ซ้ำกัน - แต่ละโหนดจะกำหนด IP บางส่วนใน podCIDR ดูนี่ โพสต์บล็อกที่ดีอธิบายมัน. ข้างต้นไม่เทียบเท่ากับการตั้งค่า --pod-เครือข่าย-cidr บน kubeadm เริ่มต้น เหมือนที่คุณควรจะ เดอะ --pod-เครือข่าย-cidr ตัวเลือกบรรทัดคำสั่งสอดคล้องกับ การกำหนดค่าคลัสเตอร์ networking.podSubnet. ดังนั้นหากคุณต้องการตั้งค่าหลังจากที่คุณลบผ้าสักหลาดออกแล้วให้แก้ไขการกำหนดค่าคลัสเตอร์ (ยังไม่ได้ทดสอบวิธีนี้จริง ๆ ฉันเพิ่งเริ่มต้นใหม่ด้วย --pod-network-cidr set):
kubectl ลบ -f kube-flannel.yml
kubectl แก้ไข cm -n kube-system kubeadm-config # และเพิ่มการตั้งค่า
เมื่อตั้งค่าแล้ว:
ระนาบควบคุมจะจัดสรร CIDR โดยอัตโนมัติสำหรับทุกโหนด -- https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/.
หากคุณจะตั้งค่าแต่ละโหนด PodCIDR การตั้งค่าจะต้องไม่ซ้ำกันสำหรับแต่ละโหนด คุณควรหลีกเลี่ยงการตั้งค่าด้วยตนเองหากคาดว่าโหนดจะมาและดำเนินไปแบบไดนามิก ซึ่งเป็นสถานการณ์ปกติ
อัปเดต: วิธีการตั้งค่าข้างต้น การกำหนดค่าคลัสเตอร์ networking.podSubnet หลังจาก init ใช้งานไม่ได้จริง มันใช้งานไม่ได้ถ้าคุณยกเลิกการลงทะเบียนและลงทะเบียนโหนดผู้ปฏิบัติงานทั้งหมดอีกครั้งซึ่งน่ารำคาญAFAIK วิธีเดียวที่จะทำให้การตั้งค่า podCIDR ของโหนดอัตโนมัติทำงานคือการทำให้คลัสเตอร์ของคุณหมดไปและเริ่มต้นใหม่ด้วย --pod-เครือข่าย-cidr ชุด หรือ networking.podSubnet ตั้งค่าในการกำหนดค่าเริ่มต้น (ดู --การกำหนดค่า ตัวเลือก).
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
