Architecture: Control Plane และ Node

ไอเดียหลักในหนึ่งประโยค

control plane ของ cluster ตัดสินใจและเก็บ state ส่วน node รัน Pod และทุกการตัดสินใจ ทุก byte ของ state นั้น ต้องผ่านประตูเดียวคือ API server

Control plane คือสมองของ cluster

control plane คือ component ชุดเล็ก ๆ ที่มักรันอยู่ด้วยกัน และร่วมกันตัดสินใจว่า cluster ควรทำอะไร พร้อมจดจำสิ่งที่ตัดสินใจไปแล้ว

kube-apiserver คือประตูหน้าของ cluster เปิด REST API ที่ทุก component อื่น รวมถึงทุกคำสั่ง kubectl ที่คุณรัน ต้องคุยด้วย ทำหน้าที่ตรวจสอบและ authenticate request และเป็น component เดียวเท่านั้นที่คุยกับ etcd โดยตรง
etcd คือ distributed key-value store ที่มีความ consistent เก็บ cluster state ทั้งหมด ทุก object ที่คุณสร้าง สถานะปัจจุบันของตัวเอง ทุกอย่าง ถ้า etcd หายไปโดยไม่มี backup ความจำของ cluster ก็หายไปด้วย
kube-scheduler คอยดู Pod ที่เพิ่งสร้างใหม่และยังไม่มี node กำหนด แล้วตัดสินใจว่าแต่ละตัวควรรันบน node ไหน โดยดูจาก resource requirement, constraint และ load ปัจจุบันของ cluster
kube-controller-manager รัน controller ในตัวทั้งหมดเป็น process เดียว เช่น node controller (สังเกตเมื่อ node เข้าไม่ถึง) replication controller (รักษาจำนวน Pod replica ให้ถูกต้อง) endpoint controller (อัปเดต endpoint ของ Service ให้ทันสมัย) และอื่น ๆ ตรงนี้คือที่ที่ reconciliation loop จากบทก่อนหน้าทำงานจริง
cloud-controller-manager เป็น optional และมีเฉพาะบน managed cloud cluster ทำหน้าที่เชื่อม concern ระดับ cluster เช่น load balancer และ node lifecycle เข้ากับ API ของ cloud provider

คุณดู Pod ของ control plane เองได้บน cluster สไตล์ kubeadm เหมือน workload ทั่วไป

kubectl get pods -n kube-system

Node component คือที่ที่ Pod รันจริง

ทุก node ใน cluster รันสามอย่างนี้

kubelet คือ node agent เป็น component ที่ทำให้ container ตาม Pod spec ที่ assign มาให้ node นี้รันอยู่จริงและ healthy kubelet เริ่ม container, restart เมื่อ container ตาย, รัน probe ของตัวเอง และรายงานสถานะของ node กับ Pod กลับไปยัง API server ไม่มีอะไรรันบน node ได้ ถ้าไม่มี kubelet เป็นคนสั่ง
kube-proxy ดูแล network rule บน node ที่ทำให้ Service ทำงานได้ คือ route traffic ที่ยิงไปยัง virtual IP ของ Service ไปหา Pod ตัวใดตัวหนึ่งที่ match ไม่ว่าจะรันอยู่ที่ไหน
container runtime เช่น containerd หรือ CRI-O คือตัวที่ pull image และรัน container จริง ๆ โดยคุยกับ kubelet ผ่าน Container Runtime Interface (CRI)

ตรวจสอบ component และสถานะของ node โดยตรงได้ด้วย

kubectl describe node <node-name>

ทุกอย่างคุยกับ etcd ผ่าน API server เท่านั้น

นี่คือข้อเท็จจริงเชิง architecture ที่ควรจำ kube-scheduler, kube-controller-manager, kubelet และทุกอย่างอื่น ไม่เคยแตะ etcd โดยตรง ทุกตัวอ่านและเขียน cluster state ผ่านการเรียก API server เท่านั้น ที่เป็น single source of truth และเป็นผู้มีอำนาจเดียวของทั้ง cluster ทำให้ Kubernetes มีจุดเดียวที่สม่ำเสมอสำหรับ authentication, authorization, validation และ watch notification controller ทุกตัวและ kubelet ทุกตัว จริง ๆ แล้วก็แค่เป็น client ของ REST API ตัวเดียวกับที่คุณใช้กับ kubectl

flowchart TB
  subgraph cp["Control Plane"]
    api["kube-apiserver"]
    etcd["etcd"]
    sched["kube-scheduler"]
    cm["kube-controller-manager"]
  end
  subgraph n1["Node"]
    kubelet["kubelet"]
    proxy["kube-proxy"]
    cri["container runtime (containerd / CRI-O)"]
  end
  sched --> api
  cm --> api
  api --> etcd
  kubelet --> api
  proxy --> api

Control plane and node components, and the single path to etcd

☸️ The one-line takeaway

control plane — kube-apiserver, etcd, kube-scheduler และ kube-controller-manager (บวก cloud-controller-manager ที่เป็น optional) — ตัดสินใจว่าควรเกิดอะไรขึ้นและจดจำ cluster state ทั้งหมด ส่วนแต่ละ node รัน kubelet (ตัวที่เริ่มและเฝ้าดู container จริง) kube-proxy (ตัวที่ทำให้ Service เข้าถึงได้) และ container runtime ที่คุยผ่าน CRI ทุก component เหล่านี้ ไม่มีข้อยกเว้น อ่านและเขียน state ผ่าน API server เท่านั้น ที่เป็นประตูเดียวสู่ etcd