พ็อดใน kubernetes ไม่สามารถสื่อสารกับพ็อดอื่นและโฮสต์คลัสเตอร์ภายนอกได้

ฉันมีโหนดหลัก 2 ตัวและโหนดผู้ปฏิบัติงาน 3 ตัวและพร็อกซี HA หนึ่งตัวสำหรับ controlePlan ฉันมีไมโครเซอร์วิสจาวาจำนวนมากที่สื่อสารร่วมกันและสื่อสารกับ DB หรือ KAFKA นอกคลัสเตอร์ kubernetes การเข้าถึงเครือข่ายสามารถเปิดได้ในทุกโฮสต์ ฉันสร้างการปรับใช้สำหรับทุกไมโครเซอร์วิส แต่เมื่อฉันดำเนินการกับคอนเทนเนอร์ ฉันไม่มีการเชื่อมต่อ tcp บนพอร์ตระหว่างพ็อดกับ DB หรือ KAFKA นอกคลัสเตอร์ kubernetes

จากโฮสต์ฉันมี telnet ถึง DB หรือ KAFKA แต่ในคอนเทนเนอร์พ็อดฉันไม่สามารถเข้าถึงได้

จากโฮสต์:

[root@master1 ~]# telnet oracle.local 1521
ลอง 192.198.10.30...
เชื่อมต่อกับ oracle.local
อักขระ Escape คือ '^]'
^C^Cการเชื่อมต่อถูกปิดโดยโฮสต์ต่างประเทศ
[รูท@มาสเตอร์1 ~]#

จากพ็อด เช่น busybux :

[root@master1 ~]# kubectl run -i --tty busybox --image=busybox --restart=Never -- sh
หากคุณไม่เห็นพรอมต์คำสั่ง ให้ลองกด Enter
/ # เทลเน็ต 192.168.10.30 1521
telnet: ไม่สามารถเชื่อมต่อกับโฮสต์ระยะไกล (192.168.10.30): การเชื่อมต่อหมดเวลา

สถานะคลัสเตอร์:

[root@master1 ~]# kubectl รับโหนด -o กว้าง
ชื่อ สถานะ บทบาท อายุ เวอร์ชัน ภายใน-IP ภายนอก-IP OS-อิมเมจ เคอร์เนล-เวอร์ชัน คอนเทนเนอร์-รันไทม์
master1.project.co Ready control-plane, master 11d v1.22.2 192.168.10.1 <ไม่มี> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
master2.project.co Ready control-plane, master 11d v1.22.2 192.168.10.2 <ไม่มี> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker1.project.co พร้อม <ไม่มี> 11d v1.22.2 192.168.10.3 <ไม่มี> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker2.project.co พร้อม <ไม่มี> 11d v1.22.2 192.168.10.4 <ไม่มี> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker3.project.co พร้อม <ไม่มี> 11d v1.22.2 192.168.10.5 <ไม่มี> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9

อธิบาย pod busybox:

[root@master1 ~]# kubectl อธิบาย pod busybox
ชื่อ: busybox
เนมสเปซ: ค่าเริ่มต้น
ลำดับความสำคัญ: 0
โหนด: worker3.project.co/192.168.10.5
เวลาเริ่ม: ส. 02 ต.ค. 2564 10:27:05 น. +0330
ป้ายกำกับ: run=busybox
คำอธิบายประกอบ: cni.projectcalico.org/containerID: 75d7222e8f402c68d9161a7b399df2de6b45e7194b2bb3b0b2730adbdac680c4
              cni.projectcalico.org/podIP: 192.168.205.76/32
              cni.projectcalico.org/podIPs: 192.168.205.76/32
สถานะ: รอดำเนินการ
ไอพี:
IPs: <ไม่มี>
ตู้คอนเทนเนอร์:
  กล่องยุ่ง:
    รหัสคอนเทนเนอร์:
    รูปภาพ: busybox
    รหัสรูปภาพ:
    พอร์ต: <ไม่มี>
    พอร์ตโฮสต์: <ไม่มี>
    อาร์กิส:
      ช
    รัฐ: กำลังรอ
      เหตุผล: การสร้างคอนเทนเนอร์
    พร้อม: เท็จ
    เริ่มนับใหม่: 0
    สภาพแวดล้อม: <ไม่มี>
    ภูเขา:
      /var/run/secrets/kubernetes.io/serviceaccount จาก kube-api-access-69snv (ro)
เงื่อนไข:
  พิมพ์สถานะ
  เริ่มต้น True
  พร้อมเท็จ
  ตู้คอนเทนเนอร์พร้อมเป็นเท็จ
  PodScheduled จริง
ปริมาณ:
  kube-api-เข้าถึง-69snv:
    ประเภท: Projected (วอลุ่มที่มีข้อมูลที่ฉีดจากหลายแหล่ง)
    TokenExpirationSeconds: 3607
    ConfigMapName: kube-root-ca.crt
    ConfigMapOptional: <ไม่มี>
    DownwardAPI: จริง
คลาส QoS: BestEffort
ตัวเลือกโหนด: <ไม่มี>
ความคลาดเคลื่อน: node.kubernetes.io/not-ready:NoExecute op=มีอยู่เป็นเวลา 300 วินาที
                             node.kubernetes.io/unreachable:NoExecute op=มีอยู่เป็นเวลา 300 วินาที
เหตุการณ์:
  พิมพ์อายุเหตุผลจากข้อความ
  ---- ------ ---- ---- -------
  ตัวกำหนดตารางเวลาเริ่มต้น 21s ตามกำหนดการปกติ กำหนดค่าเริ่มต้น/ไม่ว่างให้กับ worker3.project.co สำเร็จแล้ว
  การดึงปกติ 20s kubelet การดึงรูปภาพ "busybox"

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

1. ตรวจดูว่ามีหรือไม่ นโยบายเครือข่าย ใช้โดยการดำเนินการ kubectl -n <namespace> รับ netpol. NetworkPolicies สามารถจำกัดการสื่อสารภายในและภายนอกคลัสเตอร์
2. ให้ Pod ทำงานกับ โฮสต์เครือข่าย: จริง ตัวเลือก (ไม่ ในการผลิตเช่นเดียวกับการทดสอบ) และลองทดสอบการเชื่อมต่ออีกครั้ง (ในทั้งสองทิศทาง)
3. ตรวจสอบว่าเครือข่ายของคลัสเตอร์ของคุณได้รับการกำหนดค่าอย่างถูกต้องหรือไม่โดยการติดตามการโทรผ่านเครือข่าย เราเตอร์ได้รับการกำหนดค่าอย่างถูกต้องและสามารถใช้งานได้โดยแอปพลิเคชันภายในคลัสเตอร์หรือไม่
4. ตรวจสอบว่าของคุณ การเข้าถึงเครือข่ายสามารถเปิดได้ในทุกโฮสต์ คำสั่งเป็นจริง อาจเป็นปัญหาเกี่ยวกับการกำหนดค่าไฟร์วอลล์

โบนัส: ดูเหมือนว่าคุณจะมีโหนดหลักเพียง 2 โหนดเท่านั้น ไม่สมเหตุสมผลเลย หาก etcd ทำงานภายในคลัสเตอร์ Kubernetes (kubectl -n kube-system รับพ็อด | grep เป็นต้น จะแสดง 2 พ็อดหากเป็นเช่นนั้น) การมีสมาชิก etcd 2 คนทำให้คุณมีความทนทานต่อความล้มเหลวเหมือนกับคลัสเตอร์ 1 โหนด แต่คุณเสียทรัพยากรไปกับการมี VM อื่นที่ใช้หน่วยความจำ ซีพียู ฯลฯ. พิจารณาเพิ่มโหนดหลักของคุณเป็น 3 เพื่อให้มีค่าเผื่อความล้มเหลวที่หนึ่ง ต้องมีเสมอ ส่วนใหญ่ ของคลัสเตอร์ etcd ที่กำลังทำงานอยู่ โปรดทราบว่าส่วนใหญ่ของ 2 ยังคงเป็น 2