Kubernetes เป็น platform ที่มีความซับซ้อนสูง ทั้งความสามารถที่หลากหลาย ความยืดหยุ่น และ ความนิยมที่สูงทำให้มีหลายเจ้า หลาย implementation ไม่ว่าจะเป็น public cloud เช่น Google Kubernetes Engine, Amazon Elastic Container Service for Kubernetes, etc.. หรือจะเป็น framework เช่น Redhat Openshift, Rancher, etc…
การทำความเข้าใน Kubernetes ในฐานะ orchestration framework หรือ cluster จึงค่อนข้างยาก ผมอยากชวนทุกท่านลองมามองมันโดยเปรียบกับสิ่งใกล้ตัว Personal Computer ซักเครื่อง
Personal Computer
Computer ที่เราใช้กันอยู่นั้นจริงแล้วซับซ้อนไม่น้อยเลย มีทั้ง Hardware และ Software OS ทำงานประสานกัน Hardware ก็มีหลากหลายเจ้าประกอบกัน Software OS เองก็มีหลายเจ้า
แต่ Hardware เองไม่ว่าจะมีชิ้นส่วนหลากหลายขนาดไหน ก็จะแบ่งเป็นหมวดใหญ่ๆได้ดังนี้
- CPU และ Memory: หน่วยประมวลผล
- I/O: input และ output ในที่นี้มองถึงส่วนการรับและส่งข้อมูลทั้งหมด เพื่อส่งต่อไปยังข้อแรกเพื่อประมวลผล ในที่นี้รวมถึง จอภาพ ส่วนติดต่อผู้ใช้ ระบบเนตเวิร์คด้วย
- Storage: พื้นที่เก็บข้อมูล ในบางทีอาจเป็นต้นทางหรือปลายทางสำหรับ I/O ได้เช่นกัน
Software OS เองก็เช่นกัน ไม่ว่าเราจะใช้ Mac/Linux/Windows โครงสร้างใหญ่ๆของ Software OS แบ่งได้ดังนี้
- ส่วนติดต่อผู้ใช้: ส่วนที่ผู้ใช้มาป้อนหรือรับข้อมูลกับระบบ
- API สำหรับ Software ภายนอก: เป็น interface สำหรับให้ software ภายนอกติดต่อกับ OS
- Core OS: แกนกลางของระบบที่จัดการนำข้อมูลมาส่งต่อให้หน่วยประมวลผล (input) และนำข้อมูลที่ประมวลผลเสร็จแล้วมาส่งต่อให้ปลายทาง (output) แกนกลางยังมีหน้าที่ประสานงาน (orchestrate) ให้ Hardware แต่ละชิ้นทำงานประสานกันได้ และยังแจ้งเตือนในกรณีที่เกิดข้อผิดพลาดขึ้นกับระบบ แต่แกนกลางเองไม่ได้คุยกับ Hardware โดยตรง แต่กำหนด interface ให้ hardware
- Device driver: Software ที่จัดการ hardware แต่ละชิ้นโดยตรง โดยคุยกับ Core OS ในข้อ 3 ผ่าน OS interface โดย hardware แต่ละชิ้นก็จะมี device driver เฉพาะของตนเอง เพื่อที่จะทำให้สามารถเป็นส่วนหนึ่งและทำงานร่วมกับระบบทั้งหมดได้
ลองนึกภาพสมัยเราลง OS ใหม่ๆ และ Hardware เราเก่ามากจนไม่มี Device driver รองรับ ต่อให้ OS ดีขนาดไหน ระบบ Personal Computer ก็ไม่สามารถทำงานได้อย่างสมบูรณ์
Kubernetes Cluster
จากความซับซ้อนของ Personal Computer ด้านบน, Kubernetes cluster ก็มีความซับซ้อนไม่ต่างกัน เพราะก็เป็นระบบ Computer เช่นเดียวกัน
แต่ที่ทำให้ซับซ้อนกว่าหลายเท่าเพราะเป็นระบบ cluster ที่มีหลาย CPU, I/O, Storage จากหลากหลาย vendor
ในมุมของผู้ใช้หรือ software ที่มาติดตั้ง กลุ่ม cluster เหล่านี้จะถูกมองเป็นเครื่องใหญ่ๆเครื่องเดียว ผู้ใช้ หรือ software ไม่ได้สนใจเท่าไรนักว่า software จะไปถูกติดตั้งลงไปที่ worker node ไหน หรือ ตอนนี้ จะถูกย้ายไปไหน แต่สนใจว่า software ที่ถูกติดตั้ง ยังสามารถทำงานได้อย่างถูกต้องบน cluster นั้น
cluster เองจึงต้องบริหารจัดการความถูกต้องนี้บน
- ความซับซ้อนของ hardware ด้านล่าง ไม่ว่าจะเป็นความหลากหลายของ CPU, I/O, Disk ที่มองในมุมของผู้ใช้ เป็น pool resource แต่ในความเป็นจริงแยกกันอยู่
- ความซับซ้อนเรื่อง logical view เช่น Pod ที่อยู่คนละ Node กันยังสามารถคุยกันเหมือนอยู่ Node เดียวกัน หรือ ทุก Pod ไม่ว่าจะย้ายไปอยู่ที่ไหน ยังสามารถ access disk ได้เหมือนมี disk ของตัวเองตามไปทุกที่
- ความเสี่ยงของ Hardware failure ไม่ว่าจะเป็น worker node หรือ master node โดย Kubernetes จะทำการ self-healing ตัวเองเพื่อให้ระบบสามารถกลับมาทำงานเหมือนเดิม โดยในที่นี้รวมถึงการย้าย software มาทำงานบน worker node ที่ยังทำงานได้อยู่โดยอัตโนมัติ
- ความเสี่ยงของ resource ไม่พอ โดย Kubernetes ต้อง scale resource เพิ่มเพื่อให้ software ยังทำงานได้ตาม SLA ที่กำหนดไว้
ข่าวดีคือ สี่ข้อนี้ Kubernetes มีให้ out of the box แต่ที่เราต้องลงแรงทำเพิ่มคือการติดตั้ง Kubernetes ลงบน Hardware เพื่อสร้าง Node เมื่อต้องติดตั้งบน Hardware ความยากจึงมาอยู่ที่ส่วน Device driver หรือที่ Kubernetes เรียก Plugin โดยส่วนหลักๆอยู่ที่ Network plugin และ Storage plugin
Kubernetes Architecture
ถ้าย้อนกลับไปดูเรื่อง Software OS ส่วนที่ซับซ้อนทีสุดอยู่ที่ CoreOS สำหรับ Kubernetes ก็ไม่ต่างกัน
Core ของ Kubernetes แบ่งเป็น 2 ส่วนหลักสำคัญ คือ Master และ Node ทำงานประสานกันเพื่อให้ได้ความสามารถตามที่กล่าวไว้ด้านบน โดยในแต่ละส่วนก็ยังมี component ย่อยๆแบ่งกันทำหน้าที่ดังนี้
Master Node
Master Node ทำหน้าที่ตัดสินในภาพรวมต่างๆใน cluster นั้น ไม่ว่าจะเป็น เพิ่มลด node หรือ ติดตั้ง pod เพิ่ม ตามเหตุการณ์ต่างๆที่เกิดขึ้น พูดง่ายๆคือ Master มีหน้าที่สอดส่องความเป็นไปของ สมาชิกใน cluster ทั้งหมด และ บริหารจัดการให้ cluster ยังทำงานได้ตามที่กำหนดไว้
Component ที่ช่วยให้ Master node ทำงานมีดังนี้
- Kube-controller-manager: ผู้จัดการของ cluster นี้ คอยจัดการเพิ่ม ลด node เมื่อ node เกิดข้อผิดพลาดเกิดขึ้น, เพิ่มลด pod ให้ตรงตาม spec ที่กำหนดไว้, กำหนด endpoint ให้ service ต่างๆ, จัดการเรื่อง access token
- Kube-scheduler: ทุก pod ต้องมีที่ยืน คือ concept ของ scheduler โดยจะคอยจัดหา node ที่ยังพอมีที่ว่างให้ pod ลงไปทำงานได้
- etcd: Key-value data store ของ cluster ข้อมูลแทบทุกอย่างที่ Kubernetes ใช้บริหารจัดการ cluster จะถูกเก็บไว้ในนี้
- Kube-apiserver: เป็น gateway หลักในการสื่อสารกับ Master node ทั้งจาก Worker node , Control manager หรือ User เอง
Worker Node
Worker node เป็นสถานที่ที่ software ไปรันจริงๆ Worker node อาจเป็นเครื่อง physical ทั้งเครื่องหรือ virtual machine ก็ได้ ขอแค่ co-located ด้วยกันก็พอ Worker Node ประกอบด้วย component ต่างๆเพื่อให้สามารถทำงานประสานกันกับ Node อื่นๆได้อย่างราบรื่นดังนี้
- Kubelet: Manager ของ Node มีหน้าที่จัดการ state ของ container ให้ทำงานได้อย่างราบรื่นตามคำสั่งที่มาจาก Controller-manager ที่อยู่ใน Master node, Kubelet ยังรายงานสุขภาพของ Node และ Pod ไปยัง Master node เพื่อให้ Master ทราบและจัดการ
- Kube-proxy: เป็นช่องทางให้ software ที่ทำงานสามารถติดต่อออกสู่โลกภายนอกได้
- Pod: Pod ประกอบไปด้วย container runtime ซึ่งอาจเป็น Docker, Containerd, etc. Pod เป็นที่ให้ container สามารถทำงานได้ แต่ละ Pod มี IP address เป็นของตัวเอง ซึ่งทำให้แต่ละ node สามารถมีหลาย pod ที่ให้บริการ software เดียวกันที่ port เดียวกันได้ และ Pod เป็น Mutable คือเกิดได้ตายได้ตลอดเวลา
การ provisioning Kubernetes cluster สุดท้ายแล้วคือการทำให้มี Master node และ worker node ขึ้นมาไม่ว่าจะเป็นบน GKE / Infrastructure node / Bare metal และให้ Master-worker ทำงานประสานกันได้เท่านั้นเอง
ตอนหน้าเรามาว่ากันเรื่อง Rancher ช่วยให้เรา provisioning Kubernetes cluster ง่ายขึ้นยังไงกันครับ
0 Comments