
องค์ประกอบหลักของสถาปัตยกรรม Kubernetes คืออะไร และแต่ละองค์ประกอบมีหน้าที่รับผิดชอบอย่างไร
คลัสเตอร์ Kubernetes ประกอบด้วย ระนาบควบคุม และชุดเครื่องของผู้ปฏิบัติงานที่เรียกว่า โหนด ซึ่งเรียกใช้แอปพลิเคชันที่มีคอนเทนเนอร์ใน Pods ทุกคลัสเตอร์ต้องมีโหนดผู้ปฏิบัติงานอย่างน้อยหนึ่งโหนดเพื่อเรียกใช้ Pod
ตามแนวคิดแล้ว Kubernetes เป็นแบบ ประกาศ: คุณส่งสถานะที่ต้องการไปยังเซิร์ฟเวอร์ API (เก็บไว้ใน ฯลฯ ) และตัวควบคุมจะเรียกใช้ลูปการกระทบยอดอย่างต่อเนื่องที่คอยเฝ้าดูความแตกต่างและดำเนินการเพื่อขับเคลื่อนสถานะจริงไปสู่สถานะที่ต้องการ
ส่วนประกอบเครื่องบินควบคุม
ส่วนควบคุมทำการตัดสินใจทั่วโลกเกี่ยวกับคลัสเตอร์ (เช่น การกำหนดเวลา) และตอบสนองต่อเหตุการณ์ของคลัสเตอร์ ในการผลิตมักจะทำงานบนเครื่องหลายเครื่องเพื่อให้มีความพร้อมใช้งานสูง
- kube-apiserver — องค์ประกอบหลักที่เปิดเผย Kubernetes HTTP API เป็น ส่วนหน้า ของระนาบควบคุมและจุดติดต่อจุดเดียว: การรับรองความถูกต้อง การอนุญาต การตรวจสอบคำขอ และการอ่าน/เขียนสถานะคลัสเตอร์ที่ไหลผ่านทั้งหมด มันปรับขนาดตามแนวนอน ในการปรับใช้ปกติ เป็นเพียงองค์ประกอบ Kubernetes เท่านั้นที่อ่านและเขียนสถานะคลัสเตอร์โดยตรงใน ฯลฯ ส่วนประกอบอื่นๆ ทั้งหมดโต้ตอบกับสถานะผ่านเซิร์ฟเวอร์ API
- etcd — พื้นที่จัดเก็บคีย์-ค่าที่มีความสอดคล้องและพร้อมใช้งานสูง ซึ่งใช้เป็นที่เก็บข้อมูลสำรองของ Kubernetes สำหรับข้อมูลคลัสเตอร์ทั้งหมด: การกำหนดค่า สถานะ และข้อมูลเมตา ฯลฯd ถือเป็นข้อบังคับและเป็นแหล่งที่มาของความจริงเพียงแหล่งเดียว การที่สูญเสียไปหมายถึงการสูญเสียสถานะคลัสเตอร์ทั้งหมด ดังนั้นจึงต้องทำงานโดยมีองค์ประชุม (สมาชิกจำนวนคี่) และได้รับการสำรองข้อมูลอย่างสม่ำเสมอ
- kube-scheduler — เฝ้าดูพ็อดที่ยังไม่ได้เชื่อมโยงกับโหนดและกำหนดแต่ละพ็อดให้กับโหนดที่เหมาะสม โดยพิจารณาจากทรัพยากร ข้อจำกัด และนโยบาย
- kube-controller-manager — รันคอนโทรลเลอร์ที่ใช้ลักษณะการทำงานของ Kubernetes API (เช่น ตัวควบคุมโหนด, ตัวควบคุมงาน, ตัวควบคุม EndpointSlice) คอนโทรลเลอร์แต่ละตัวจะเฝ้าดูสถานะที่ต้องการและปรับสถานะตามจริงให้สอดคล้องกับสถานะนั้น
- cloud-controller-manager (ไม่บังคับ) — ผสานรวมกับผู้ให้บริการคลาวด์พื้นฐาน โดยแยกตรรกะเฉพาะคลาวด์ออกจากส่วนประกอบหลักของ Kubernetes
ส่วนประกอบโหนด
สิ่งเหล่านี้ทำงานบนทุกโหนด ทำให้ Pods ทำงานและจัดเตรียมสภาพแวดล้อมรันไทม์
- kubelet — เอเจนต์ที่ทำให้แน่ใจว่า Pods ทำงานอยู่ รวมถึงคอนเทนเนอร์ด้วย โดยจะเฝ้าดูเซิร์ฟเวอร์ API สำหรับการกำหนด Pod เริ่มคอนเทนเนอร์ผ่านรันไทม์ ติดตั้งวอลุ่ม รันโพรบความสด/ความพร้อม และรายงานสถานะโหนด
- kube-proxy — ใช้งานเครือข่ายบริการโดยการเขียนโปรแกรม iptables หรือกฎ IPVS บนโหนด ดังนั้นการรับส่งข้อมูลไปยังบริการจะถูกส่งต่อไปยัง Pod IP ที่ถูกต้อง มีการทำเครื่องหมายว่าเป็นทางเลือกเนื่องจากปลั๊กอิน CNI บางตัว (เช่น Cilium ในโหมด eBPF) เข้ารับหน้าที่แทน แต่ในคลัสเตอร์มาตรฐาน จำเป็นต้องมี
- รันไทม์คอนเทนเนอร์ — ซอฟต์แวร์ที่รับผิดชอบในการใช้งานคอนเทนเนอร์ (containerd, CRI-O ฯลฯ ผ่านทางอินเทอร์เฟซ CRI)
ส่วนเสริม
Addons ขยายฟังก์ชันการทำงานของคลัสเตอร์: DNS คลัสเตอร์ (CoreDNS ตามค่าเริ่มต้น), UI เว็บแดชบอร์ด, การตรวจสอบทรัพยากรคอนเทนเนอร์ และการบันทึกระดับคลัสเตอร์
การติดตามผลทั่วไป: การสื่อสารทั้งหมดไหลผ่านเซิร์ฟเวอร์ API — ตัวกำหนดเวลา ตัวควบคุม และคูเบเล็ตเพียงแค่เฝ้าดูและตอบสนอง — ซึ่งทำให้เซิร์ฟเวอร์ API เป็นศูนย์กลางที่สำคัญของคลัสเตอร์
