Score:0

การติดตั้ง Kubernetes ใหม่ทั้งหมดบน Raspberry Pi ไม่ทำงาน

ธง cn

ฉันกำลังพยายามติดตั้ง Kubernetes 1.23.x ใหม่ทั้งหมดบนคลัสเตอร์ของ Raspberry Pis สี่ตัว โดยแต่ละตัวรันระบบปฏิบัติการ Raspberry Pi เวอร์ชัน x64 แต่ฉันพบปัญหาใหญ่ทันทีที่ฉันพยายามเรียกใช้ kubeadm เริ่มต้น บนโหนดหลัก (ก่อนที่จะพยายามรับโหนดอื่นเข้าร่วมด้วยซ้ำ) คือ: เพียงห้านาทีหลังจากโทร kubeadm เริ่มต้น บนโหนดหลัก คลัสเตอร์จะหยุดทำงาน ในความเป็นจริงมันไม่ได้ผลเลยที่จะเริ่มต้นด้วย ในตอนแรกเซิร์ฟเวอร์จะตอบกลับว่าโหนดไม่พร้อม แต่หลังจากผ่านไป 5 นาที เซิร์ฟเวอร์จะหยุดตอบสนองโดยสิ้นเชิง

นี่คือสิ่งที่ฉันทำและสิ่งที่ฉันเห็น: ฉันติดตั้งคอนเทนเนอร์และ kubeadm จากนั้นฉันรันคำสั่งต่อไปนี้บนโหนดหลักเพื่อลองและเริ่ม Kubernetes:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
    --token-ttl=0 --apiserver-advertise-address=192.168.1.194

หลังจากเรียกใช้คำสั่งนั้น และคัดลอกไฟล์ /etc/kubernetes/admin.conf ไปยัง ~/.kube/config ในภายหลัง ฉันก็สามารถเรียกใช้คำสั่งต่อไปนี้ได้:

$ kubectl รับโหนด

ชื่อ สถานะ บทบาท อายุ รุ่น
k8s-master-1 NotReady control-plane,master 3m36s v1.23.4

และจะแสดงสถานะ NotReady ต่อไปอีกประมาณ 5 นาที หลังจากนั้นคำสั่งเดียวกันจะให้ผลลัพธ์ที่แตกต่างกันมาก:

$ kubectl รับโหนด

การเชื่อมต่อกับเซิร์ฟเวอร์ 192.168.1.194:6443 ถูกปฏิเสธ - คุณระบุโฮสต์หรือพอร์ตที่ถูกต้องหรือไม่

ฉันไม่แน่ใจว่าทำไมสิ่งนี้ถึงเกิดขึ้น แต่มันสอดคล้องกันมาก ฉันได้ลองสองสามครั้งแล้วเพื่อ kubeadm รีเซ็ต แล้ว kubeadm เริ่มต้น อีกครั้ง และการหมดเวลาการเชื่อมต่อจะเกิดขึ้นที่เครื่องหมาย 5 นาทีเสมอ ดังนั้น ครั้งสุดท้ายที่ฉันพยายามทำสิ่งนี้ ฉันตัดสินใจที่จะหางไฟล์บันทึกทั้งหมดภายใต้ /var/log/คอนเทนเนอร์/. หลังจากผ่านไป 5 นาที ระบบจะบันทึกรูปแบบข้อผิดพลาดในการเชื่อมต่อซ้ำๆ เป็น 127.0.0.1:2379 ตัวอย่างเช่น:

127.0.0.1:2379 127.0.0.1 0 }. ข้อผิดพลาด: ข้อผิดพลาดในการเชื่อมต่อ: desc = "การขนส่ง: เกิดข้อผิดพลาดขณะหมุนหมายเลข tcp 127.0.0.1:2379: เชื่อมต่อ: การเชื่อมต่อถูกปฏิเสธ" กำลังเชื่อมต่อใหม่...

จาก Google ดูเหมือนว่า etcd กำลังทำงานบนพอร์ตนั้น แต่เมื่อถึงเครื่องหมาย 5 นาที บริการจำนวนมาก (รวมถึง etcd) ก็เริ่มปิดตัวลง ฉันได้อัปโหลดบันทึกทั้งหมดตั้งแต่เวลานั้น kubeadm เริ่มต้น วิ่งจนถึงก่อนเครื่องหมายที่น่ากลัว 5 นาที เป็นสาระสำคัญ.

ฉันได้ตรวจสอบแล้วว่าพอร์ตทั้งหมดเปิดอยู่เช่นกัน (ใช่แล้ว) ในช่วงห้านาทีแรกนั้น ฉันสามารถเทลเน็ตไปยังพอร์ตท้องถิ่น 2379 ทำไม Kubernetes ถึงไม่เริ่มทำงานบน Pi ของฉัน ฉันพลาดอะไรไป

อัปเดต: ตามที่ร้องขอ ฉันสามารถให้รายละเอียดเพิ่มเติมเล็กน้อยได้ ผมเห็นกระทู้แนะนำการตั้งค่าของ --apiserver-โฆษณาที่อยู่ ถึง 0.0.0.0 แทนที่จะเป็น IP โดยตรง ดังนั้นฉันจึงลอง แต่ดูเหมือนจะไม่สร้างความแตกต่าง ฉันพยายามวิ่ง kubelet สถานะ systemctl ซึ่งแสดงว่าบริการ kubelet "ทำงานอยู่" ในช่วง 5 นาทีแรกนั้น

ฉันยังวิ่ง kubectl อธิบายโหนด k8s-master-1ซึ่งแสดงสี่เหตุการณ์ในลำดับนี้:

  1. Kubelet มีหน่วยความจำเพียงพอ
  2. Kubeletไม่มีดิสก์ความดัน
  3. KubeletมีเพียงพอPID
  4. Kubeletไม่พร้อม

เหตุการณ์สุดท้ายนั้นมาพร้อมกับข้อความนี้: "เครือข่ายรันไทม์คอนเทนเนอร์ไม่พร้อม: NetworkReady=false เหตุผล: ข้อความ NetworkPluginNotReady: ปลั๊กอินเครือข่ายส่งคืนข้อผิดพลาด: ปลั๊กอิน cni ไม่ได้เริ่มต้น" นั่นจึงทำให้ฉันคิดว่า ฉันรอให้ Node แสดงสถานะ Ready ก่อนติดตั้ง Flannel (หรือที่เรียกว่าปลั๊กอิน CNI) แต่คราวนี้ฉันตัดสินใจลองติดตั้ง Flannel ในช่วง 5 นาทีแรกโดยใช้คำสั่งนี้:

ใช้ kubectl -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

และที่ทำให้ฉันประหลาดใจมาก มันได้ผล! ประเภทของ โหนดหลักเริ่มรายงานสถานะ "พร้อม" ในที่สุดและฉันสังเกตเห็นว่าพ็อดทั้งหมดของฉันมาพร้อมกับพ็อด coredns ที่โดดเด่น อย่างไรก็ตาม หลังจากนั้นไม่นาน kube-proxy pod (ในเนมสเปซระบบ kube) หยุดทำงานและค้างอยู่ใน CrashLoopBackoff จากนั้น kube-controller-manager และ kube-scheduler pods ก็เข้าสู่ CrashLoopBackoff ในทำนองเดียวกัน จากนั้น คราวนี้ หลังจากผ่านไปประมาณ 15 นาที คลัสเตอร์ทั้งหมดก็หยุดทำงานเหมือนเดิม (หมายความว่าฉันได้รับข้อความ 'การเชื่อมต่อกับเซิร์ฟเวอร์ถูกปฏิเสธ' เหมือนเดิม) ดังนั้นฉันจึงรู้สึกว่าฉันเข้าใกล้มากขึ้น แต่ก็ยังห่างไกลจากการทำงานนี้

การอัปเดตครั้งที่สอง: สองสิ่ง: ดูเหมือนว่าเมื่อฉันติดตั้งปลั๊กอิน Flannel CNI จะไม่มี coredns รวมอยู่ด้วยหรือไม่ทำงาน แต่เมื่อฉันติดตั้ง weave นั้น CNI ทำงานได้ อย่างน้อยมันก็พยายามหมุน coredns ขึ้นมา แม้ว่าโชคไม่ดีที่พ็อดเหล่านั้นติดอยู่ใน ContainerCreating และไม่เคยเปิดใช้งานจริง ตามที่ร้องขอ ฉันกำลังจัดเตรียมบันทึกเพิ่มเติมจำนวนหนึ่ง ยาวพอที่จะรับประกันการอัปโหลดแยกต่างหาก ดังนั้นนี่คือ เชื่อมโยงไปยังส่วนสำคัญ มีสี่บันทึก:

  1. วิ่ง kubectl -n kube-system บันทึก pod/coredns-...
  2. วิ่ง kubectl -n kube-system บันทึกพ็อด/kube-controller-manager-k8s-master-1
  3. วิ่ง kubectl -n kube-system บันทึก pod/kube-proxy-...
  4. วิ่ง kubectl อธิบายโหนด k8s-master-1

โปรดทราบว่าก่อนที่ทุกอย่างจะตาย พ็อด kube-controller-manager-... จะเริ่มทำงาน แต่ไม่นานก็พบว่าตัวเองอยู่ใน CrashLoopBackoff ในขณะที่ coredns pods ไม่เคยเริ่มต้นได้สำเร็จเลย

tilleyc avatar
us flag
dmesg หรือ syslog แสดงอะไร
mozello avatar
cn flag
เรียกใช้ `kubectl อธิบายโหนด nodename` เพื่อตรวจสอบสาเหตุที่โหนดไม่พร้อม ตรวจสอบ `systemctl สถานะ kubelet' และ 'journalctl -u kubelet' คุณปิดการแลกเปลี่ยนหรือไม่
cn flag
@mozello ฉันอัปเดตโพสต์ต้นฉบับพร้อมรายละเอียดเพิ่มเติมตามคำแนะนำของคุณ
mozello avatar
cn flag
coredns pods อยู่ในสถานะ 'รอดำเนินการ' หรือไม่ ตรวจสอบว่ามี 'เสีย' ใด ๆ เมื่อคุณเรียกใช้ 'kubectl อธิบายโหนด'
mozello avatar
cn flag
นอกจากนี้ โปรดเพิ่มบันทึกจาก kube-proxy pod `kubectl -n kube-system logs kube-proxy-...`
cn flag
@mozello ขอบคุณที่ติดตามฉันและขอโทษที่ล่าช้า ฉันได้แก้ไขโพสต์ต้นฉบับของฉันเพื่อเพิ่มบันทึกเพิ่มเติมจำนวนมากในลิงก์ Gist ในตอนท้าย ฉันซาบซึ้งมากที่คุณดูสิ่งนี้!

โพสต์คำตอบ

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