ฉันมี 2 คลัสเตอร์ kubernetes ในระบบคลาวด์ของ IBM โดยกลุ่มหนึ่งมี 2 โหนด และอีกกลุ่มหนึ่งมี 4
อันที่มี 4 โหนดนั้นทำงานได้อย่างถูกต้อง แต่อีกอันหนึ่งฉันต้องลบโหนดผู้ปฏิบัติงานออกชั่วคราวเนื่องจากเหตุผลทางการเงิน (ไม่ควรจ่ายในขณะที่ไม่ได้ใช้งาน)
เมื่อฉันเปิดใช้งานโหนดทั้งสองอีกครั้ง ทุกอย่างดูเหมือนจะเริ่มต้นได้ตามปกติ และตราบใดที่ฉันไม่พยายามโต้ตอบกับ Pods มันก็ยังดูดีบนพื้นผิว ไม่มีข้อความเกี่ยวกับความพร้อมใช้งานหรือสถานะสุขภาพที่สำคัญ โอเค ฉันลบสิ่งที่ล้าสมัยไปแล้ว 2 รายการ เนมสเปซ
ที่ติดอยู่ใน สิ้นสุด
สถานะ แต่ฉันสามารถแก้ไขปัญหานั้นได้โดยการรีสตาร์ทโหนดคลัสเตอร์ (ไม่ทราบแน่ชัดอีกต่อไปว่าเป็นโหนดใด)
เมื่อทุกอย่างดูดี ฉันพยายามเข้าถึงแดชบอร์ดของ kubernetes (ทุกอย่างที่ทำก่อนหน้านี้อยู่ในระดับการจัดการของ IBM หรือในบรรทัดคำสั่ง) แต่น่าประหลาดใจที่ฉันพบว่าไม่สามารถเข้าถึงได้โดยมีหน้าแสดงข้อผิดพลาดในเบราว์เซอร์ระบุว่า:
503: บริการไม่พร้อมใช้งาน
มีข้อความ JSON เล็กๆ ที่ด้านล่างของหน้าซึ่งกล่าวว่า:
{
"ชนิด": "สถานะ",
"apiVersion": "v1",
"ข้อมูลเมตา": { },
"สถานะ": "ล้มเหลว",
"ข้อความ": "ข้อผิดพลาดในการพยายามเข้าถึงบริการ: อ่าน tcp 172.18.190.60:39946-\u003e172.19.151.38:8090: อ่าน: การเชื่อมต่อถูกรีเซ็ตโดยเพียร์",
"เหตุผล": "บริการไม่พร้อมใช้งาน",
"รหัส": 503
}
ฉันส่ง kubectl บันทึก kubernetes-dashboard-54674bdd65-nf6w7 --namespace=kube-system
ที่ไหน พ็อด
แสดงเป็นกำลังทำงานอยู่ แต่ผลลัพธ์ไม่ใช่บันทึกให้ดู แต่เป็นข้อความนี้แทน:
ข้อผิดพลาดจากเซิร์ฟเวอร์: รับ "https://10.215.17.75:10250/containerLogs/kube-system/kubernetes-dashboard-54674bdd65-nf6w7/kubernetes-dashboard":
อ่าน tcp 172.18.135.195:56882->172.19.151.38:8090:
อ่าน: การเชื่อมต่อถูกรีเซ็ตโดยเพียร์
จากนั้นฉันก็พบว่าฉันไม่สามารถรับบันทึกของ ใดๆ พ็อด
ทำงานในคลัสเตอร์นั้น และฉันไม่สามารถปรับใช้ออบเจกต์ kubernetes ที่กำหนดเองใหม่ใดๆ ที่ต้องมีการตั้งเวลา (อันที่จริงฉันสามารถใช้ บริการ
เอส หรือ ConfigMap
s แต่ไม่มี พ็อด
, ชุดแบบจำลอง
, การปรับใช้
หรือคล้ายกัน).
ฉันพยายามแล้ว
- รีโหลดโหนดผู้ปฏิบัติงานในพูลผู้ปฏิบัติงาน
- รีสตาร์ทโหนดผู้ปฏิบัติงานในพูลผู้ปฏิบัติงาน
- รีสตาร์ทแดชบอร์ด kubernetes
การปรับใช้
ขออภัย การดำเนินการข้างต้นไม่ได้เปลี่ยนแปลงการเข้าถึงของ พ็อด
ส.
มีอีกสิ่งหนึ่งที่อาจเกี่ยวข้อง (แม้ว่าฉันจะไม่ค่อยแน่ใจว่าจริงหรือไม่):
ในกลุ่มอื่นที่ทำงานได้ดีมีสามผ้าดิบ พ็อด
กำลังทำงานและทั้งสามขึ้นมาในขณะที่อยู่ในกลุ่มที่มีปัญหาเพียง 2 ในสามของผ้าดิบ พ็อด
กำลังดำเนินการอยู่ ส่วนที่สามยังคงอยู่ใน รอดำเนินการ
รัฐและก kubectl อธิบาย pod calico-blablabla-blabla
เผยเหตุผลก เหตุการณ์
คำเตือน FailedScheduling 13s default-scheduler
มี 0/2 โหนด: 2 โหนดไม่มีพอร์ตว่างสำหรับพอร์ตพ็อดที่ร้องขอ
ใครมีเงื่อนงำเกี่ยวกับสิ่งที่เกิดขึ้นในคลัสเตอร์นั้นและสามารถชี้ให้ฉันเห็นวิธีแก้ปัญหาที่เป็นไปได้ ฉันไม่ต้องการลบคลัสเตอร์และวางไข่ใหม่
แก้ไข
ผลลัพธ์ของ kubectl อธิบาย pod kubernetes-dashboard-54674bdd65-4m2ch --namespace=kube-system
:
ชื่อ: kubernetes-dashboard-54674bdd65-4m2ch
เนมสเปซ: ระบบ kube
ลำดับความสำคัญ: 2000000000
ชื่อคลาสลำดับความสำคัญ: system-cluster-critical
โหนด: 10.215.17.82/10.215.17.82
เวลาเริ่ม: จันทร์ที่ 15 พ.ย. 2564 09:01:30 +0100
ป้ายกำกับ: k8s-app=kubernetes-dashboard
ฝักแม่แบบแฮช = 54674bdd65
คำอธิบายประกอบ: cni.projectcalico.org/containerID: ca52cefaae58d8e5ce6d54883cb6a6135318c8db53d231dc645a5cf2e67d821e
cni.projectcalico.org/podIP: 172.30.184.2/32
cni.projectcalico.org/podIPs: 172.30.184.2/32
container.seccomp.security.alpha.kubernetes.io/kubernetes-dashboard: รันไทม์/ค่าเริ่มต้น
kubectl.kubernetes.io/restartedAt: 2021-11-10T15:47:14+01:00
kubernetes.io/psp: ibm-privileged-psp
สถานะ: กำลังดำเนินการ
ไอพี: 172.30.184.2
IP:
ไอพี: 172.30.184.2
ควบคุมโดย: ReplicaSet/kubernetes-dashboard-54674bdd65
ตู้คอนเทนเนอร์:
แดชบอร์ด kubernetes:
รหัสคอนเทนเนอร์: containerd://bac57850055cd6bb944c4d893a5d315c659fd7d4935fe49083d9ef8ae03e5c31
รูปภาพ: Registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard:v2.3.1
รหัสรูปภาพ: Registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard@sha256:f14f581d36b83fc9c1cfa3b0609e7788017ecada1f3106fab1c9db35295fe523
พอร์ต: 8443/TCP
พอร์ตโฮสต์: 0/TCP
อาร์กิส:
--auto-generate-ใบรับรอง
--namespace=kube ระบบ
รัฐ: วิ่ง
เริ่มเมื่อ: จันทร์ที่ 15 พ.ย. 2564 09:01:37 น. +0100
พร้อม:จริง
เริ่มนับใหม่: 0
คำขอ:
ซีพียู: 50 ม
หน่วยความจำ: 100Mi
ความมีชีวิตชีวา: http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3
ความพร้อม: http-get https://:8443/ delay=10s timeout=30s period=10s #success=1 #failure=3
สภาพแวดล้อม: <ไม่มี>
ภูเขา:
/ใบรับรองจาก kubernetes-dashboard-certs (rw)
/tmp จากปริมาณ tmp (rw)
/var/run/secrets/kubernetes.io/serviceaccount จาก kube-api-access-sc9kw (ro)
เงื่อนไข:
พิมพ์สถานะ
เริ่มต้น True
พร้อมทรู
ตู้คอนเทนเนอร์เรดดี้ทรู
PodScheduled จริง
ปริมาณ:
kubernetes-dashboard-certs:
ประเภท: ความลับ (ไดรฟ์ข้อมูลที่เป็นความลับ)
ชื่อลับ: kubernetes-dashboard-certs
ตัวเลือก: เท็จ
ปริมาณ tmp:
ประเภท: EmptyDir (ไดเร็กทอรีชั่วคราวที่แชร์อายุการใช้งานของพ็อด)
ปานกลาง:
SizeLimit: <unset>
kube-api-เข้าถึง-sc9kw:
ประเภท: Projected (วอลุ่มที่มีข้อมูลที่ฉีดจากหลายแหล่ง)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <ไม่มี>
DownwardAPI: จริง
คลาส QoS: ระเบิดได้
ตัวเลือกโหนด: <ไม่มี>
ความคลาดเคลื่อน: node-role.kubernetes.io/master:NoSchedule
node.kubernetes.io/not-ready:NoExecute op=มีอยู่เป็นเวลา 600 วินาที
node.kubernetes.io/unreachable:NoExecute op=มีอยู่เป็นเวลา 600 วินาที
เหตุการณ์: <ไม่มี>