ฉันตั้งค่าคลัสเตอร์ k8s ไม่มากก็น้อย คู่มือนี้. ฉันจึงมีโหนดหลักและระนาบควบคุมสามโหนด ฉันใช้ haproxy เป็นตัวโหลดบาลานเซอร์ด้วยการกำหนดค่าต่อไปนี้:
#/etc/haproxy/haproxy.cfg
#--------------------------------------------- --------------------
# การตั้งค่าส่วนกลาง
#--------------------------------------------- --------------------
ทั่วโลก
บันทึก /dev/log local0.log
บันทึก /dev/log ข้อมูล local1
ภูต
#--------------------------------------------- --------------------
# ค่าเริ่มต้นทั่วไปที่ส่วนฟังและส่วนหลังทั้งหมดจะทำ
# ใช้หากไม่ได้กำหนดไว้ในบล็อกของพวกเขา
#--------------------------------------------- --------------------
ค่าเริ่มต้น
โหมด http
เข้าสู่ระบบทั่วโลก
ตัวเลือก httplog
ตัวเลือก dontlognull
ตัวเลือก http-ปิดเซิร์ฟเวอร์
ตัวเลือก forwardfor ยกเว้น 127.0.0.0/8
ตัวเลือกการจัดส่งซ้ำ
ลองใหม่ 1
หมดเวลา http-request 10 วินาที
หมดเวลาคิว 20 วินาที
หมดเวลาเชื่อมต่อ 5 วินาที
ลูกค้าหมดเวลา 20 วินาที
เซิร์ฟเวอร์หมดเวลา 20 วินาที
หมดเวลา http-keep-alive 10 วินาที
ตรวจสอบการหมดเวลา 10 วินาที
#--------------------------------------------- --------------------
# ส่วนหน้า apiserver ซึ่งพร็อกซีไปยังโหนดระนาบควบคุม
#--------------------------------------------- --------------------
apiserver ส่วนหน้า
ผูก *:8443
โหมด tcp
ตัวเลือก tcplog
default_backend apiserver
#--------------------------------------------- --------------------
# โรบินสมดุลสำหรับ apiserver
#--------------------------------------------- --------------------
apiserver แบ็กเอนด์
ตัวเลือก httpchk GET /healthz
http- ตรวจสอบสถานะคาดหวัง 200
โหมด tcp
ตัวเลือก ssl-hello-chk
ตัวเลือก tcp-ตรวจสอบ
วงเวียนสมดุล
ตรวจสอบเซิร์ฟเวอร์ k8s1 x.x.x.15:6443
ตรวจสอบเซิร์ฟเวอร์ k8s2 x.x.x.16:6443
ตรวจสอบเซิร์ฟเวอร์ k8s3 x.x.x.17:6443
เช่นเดียวกับ Keepalived สำหรับการจัดการวีไอพี:
! /etc/keepalived/keepalive.conf
! ไฟล์คอนฟิกูเรชันสำหรับ Keepalive
global_defs {
router_id LVS_DEVEL
}
vrrp_script check_apiserver {
สคริปต์ "/etc/keepalived/check_apiserver.sh"
ช่วง 3
หมดเวลา 5
ตก 10
เพิ่มขึ้น 2
}
vrrp_instance VI_1 {
รัฐสำรอง
อินเทอร์เฟซ ens18
virtual_router_id53
ลำดับความสำคัญ 101
การรับรองความถูกต้อง {
auth_type ผ่าน
auth_pass 123456
}
virtual_ipaddress {
x.x.x.18
}
track_script {
ตรวจสอบ_apiserver
}
}
และสคริปต์ check_apiserver:
#!/usr/bin/env ทุบตี
errorExit () {
เสียงสะท้อน "*** $*" 1>&2
ทางออก 1
}
curl --silent --max-time 2 --insecure https://localhost:6443/ -o /dev/null || errorExit "ข้อผิดพลาด GET https://localhost:6443/"
ถ้า ip addr | grep -q ${วีไอพี}; แล้ว
curl --silent --max-time 2 --insecure https://x.x.x.18:8443/ -o /dev/null || errorExit "ข้อผิดพลาด GET https://x.x.x.18:8443/"
ไฟ
kubelet, kubeadm และ kubectl เป็นเวอร์ชัน 1.22.2 ทั้งหมด
ฉันสร้างคลัสเตอร์โดยใช้
sudo kubeadm init --control-plane-endpoint "x.x.x.18:8443" --upload-certs --v=5 --pod-network-cidr=172.31.0.0/16
และเพิ่มการทอโดยใช้
kubectl ใช้ -f "https://cloud.weave.works/k8s/net?k8s-version=$(เวอร์ชัน kubectl | base64 | tr -d '\n')&env.IPALLOC_RANGE=172.31.0.0/16"
ด้วยการกำหนดค่านี้ ฉันสามารถสร้างได้เช่น คลัสเตอร์ EMQX ปัญหาปรากฏขึ้นเมื่อใดก็ตามที่ฉันหยุดหนึ่งโหนด statefulset ทุกชุดที่มี Pod ทำงานบนโหนดที่หยุดทำงานจะไม่ตอบสนองเป็นเวลาเกือบ 15 นาทีพอดี
ตรวจสอบ Keepalived โดยใช้ ip a s ens18
ฉันเห็นวีไอพีย้ายไปที่โหนดที่กำลังทำงานอยู่เกือบจะทันที การใช้แดชบอร์ด haproxy stats โหนดจะถูกทำเครื่องหมายว่าใช้งานขึ้นและลดลงหลังจากผ่านไป 2 วินาที และใช้งานหรือสำรองข้อมูลลดลงหลังจากผ่านไปอีก 4 วินาที ดูเหมือนว่าจะทำงานได้เช่นกัน
การแก้ไขการหมดเวลาของ kubernetes (เช่น เวลาการขับไล่พ็อด) ทำงานได้ เพื่อให้พ็อดถูกทำเครื่องหมายว่ายุติก่อนหน้านี้ แต่ statefulset ยังคงไม่ตอบสนองเป็นเวลา 15 นาทีไม่ว่าจะออกเวลาใดก็ตาม
การตั้งค่าเครือข่ายประเภทโหนดสามโหนดด้วยโหนดมาสเตอร์และคอนโทรลเพลนทั้งหมดไม่แสดงพฤติกรรมนี้ ซึ่งเป็นสาเหตุที่ทำให้ฉันเดาว่ามันเป็นปัญหาการกำหนดค่า k8s แต่ฉันขาดอะไรไป
แก้ไข 1: คลัสเตอร์ยังคงสามารถเข้าถึงได้ในเวลานั้นเพื่อให้ฉันทำได้ ดู kubectl รับทั้งหมด --all-namespaces -o กว้าง
เพื่อตรวจสอบสถานะคลัสเตอร์ ทั้งหมดที่ฉันเห็นคือพ็อดจากโหนดที่หยุดทำงานยังคงอยู่ในสถานะสิ้นสุด
แก้ไข 2: พฤติกรรมที่น่าสงสัยเพียงอย่างเดียวคือการตรวจหาที่อยู่ MAC ใหม่หลังจากผ่านไป 15 นาทีเพื่อเพิ่มความเร็วการค้นหาข้อผิดพลาด ฉันเริ่มต้นแบบไม่มี CNI ของตัวเองและใช้การสานแทน ด้วยวิธีนี้ฉันสามารถบรรลุบันทึกที่เหมือนกันและปัญหาเดียวกันกับคลัสเตอร์ kubernetes "ของจริง" น่าเสียดายที่ฉันไม่มีโชคกับบันทึกการดีบักของ weaves ดังนั้นฉันจึงเปลี่ยนไปใช้ calico CNI และเปลี่ยน podSubnet เป็น 192.168.0.0/16 สิ่งนี้ช่วยแก้ปัญหาได้ แต่การใช้วิธีแก้ปัญหาเดียวกันกับคลัสเตอร์ kubernetes ของฉันทำให้ฉันมีปัญหาเดิมอีกครั้ง ...