Kubernetes หนทางสู่การทำระบบที่ไม่มีวันล่ม
Kubernetes คือ อะไร ?
” Kubernetes ” หรือ “K8s” คือ “Container Orchestration”เป็น OpenSource จาก Google ที่จะมาช่วย ในการ จัดการคอนเทนเนอร์ ( เช่น Docker, LXC) ซึ่งเจ้า K8s นี่ก็ไม่ได้เป็นเทคโนโลยีเดียวที่ใช้ในการจัดการคอนเทนเนอร์ เพราะยังมี Docker Swarm ที่ใช้จัดการคอนเทนเนอร์ได้เช่นกัน ซึ่งหน้าที่หลักๆของมันคือ ช่วยให้เราสามารถติดตั้ง (Deployment) จัดสรรทรัพยากร หรือ เพิ่มลดทรัพยากรแบบอัตโนมัติได้ (Managing & Scaling) นอกจากนั้นยังช่วยให้ Application ที่ทำงานอยู่บนคอนเทนเนอร์สามารถทำงานได้อย่างต่อเนื่อง ด้วยระบบที่พร้อมใช้งานตลอดเวลา (Auto Self-Healing) พูดง่ายๆ คือ สามารถทำระบบที่ฆ่ายังไงก็ไม่ตายนั่นเอง! (โกงกว่านี้มีอีกมั้ย?)
จากภาพข้างต้นจะเห็นว่า Kubenetes เป็นการต่อยอดหลังจากที่เราสร้าง Container ให้กับ App แล้ว (สามารถอ่านเพิ่มเติมเกี่ยวกับ Docker ได้ค่ะ) ก็คือมี Container แล้วยังไงต่อ? จะ Manage มันยังไงดีให้ได้ประสิทธิภาพสูงสุดกันไปเลย นี่เลยเป็นที่มาของการนำ Kubernetes เข้ามาเพื่อควบคุม Container พวกนั้นทั้งหมดอีกที โดยวิธีการง่ายๆคือสร้าง Config สั่งมันไว้แผ่นนึง (เป็นไฟล์ .yaml) เขียนบอกมันว่า ให้ทำแบบนั้นแบบนี้นะ แล้วปล่อยให้มันควบคุมให้เราเองเลย ดังนั้นมันจึง Centralized มากขึ้น ลดการทำงานที่ซับซ้อนได้ แถมยังเป็นไปแบบ Automatic อีกด้วย ส่วนมันออโต้ได้ขนาดไหน? เลื่อนลงไปอ่านกันต่อเลยค่ะ
ภาพรวมการทำงานของ Kubernetes
ยากไป? งั้นมาดูเคสตัวอย่างกันเลยดีกว่าจ้า
เคสแรก หากต้องการเพิ่มเครื่อง ต่อให้เรามี Container แล้ว เราก็ยังต้องเปิดทีละเครื่องใหม่ แล้วเอา container ไปวางเพื่อ run ใหม่อีกที หากมีสักสิบเครื่องร้อยเครื่องก็ต้องทำวนๆไป แต่ถ้าหากนำ Kubernetes มาใช้ มันจะกระจายงานให้เครื่องในระบบเองอัตโนมัติเลย แค่เราเขียนบอกมันว่าจะให้มันทำอะไรแค่นั้นเอง
อีกสักเคส… คือเราสามารถสั่งให้มัน Auto Scaling ได้ด้วย เช่น กำหนดไว้ว่าหาก CPU Usage เกิน 80% ให้ Auto Scale Up ขยายทรัพยากรให้เลยนะ ดังนั้น มันจะทำให้การจัดการเราเป็นไปอย่าง Automatic มากขึ้น โดยเราแทบไม่ต้องไปทำอะไรเลย เอาเวลาไปนอน จิบกาแฟสวยๆดีกว่าจ้า
The History Of Kubernetes
ก่อนอื่น ขอเล่าถึงต้นกำเนิดของมันหน่อย K8s นั้นเกิดมาจาก pain ที่บริษัท Google เจอมาตลอด ในการพยายามจะจัดการ Data Center ของตัวเองมานานกว่า 15 ปี (แต่ก็ยังไม่ยาวเท่าที่เรารอตอนจบโคนัน) เดิมเค้าก็เรียกระบบนี้ว่า “Borg” และจากความผิดพลาด ปัญหาต่างๆที่เคยเจอและแก้ไขมาตลอดระยะเวลายาวนาน ทุกอย่างกลายเป็น Lesson Learned จนเกิดเป็นเจ้า “Kubernetes” ขึ้นมา แถมอากู๋แกก็ไม่หยุดโชว์ความยิ่งใหญ่ด้วยการเปิดให้เป็น Opensource ไปเลยจ้า
Kubernetes Feature
- Container Clustering: สามารถทำ Configuration เพื่อสั่งระบบให้ทำงานตามที่ ต้องการโดยอัตโนมัติ (เรียกได้อีกแบบว่า เป็นการกำหนด Desired State)
- Auto Scaling: เรองรับการเพิ่มหรือลดทรัพยากร โดยอัตโนมัติตามความต้องการ
- Auto Self-healing : รองรับการทำงานแบบ HA เพื่อช่วยให้ระบบสามารถทำงานได้อย่างปกติ
- Auto Binpacking :จัดสรรทรัพยากรสำหรับคอนเทนเนอร์โดยอัตโนมัติ
- Load Balancing: แบ่งการทำงานระหว่างคอนเทนนอร์ได้อย่างเหมาะสม และมีประสิทธิภาพสูงสุด
- Zero Downtime : รองรับการอัพเดทระบบแบบไม่มี Downtime
- Dashboard : มีแดชบอร์ดสำหรับควบคุม และบริหารจัดการทรัพยากร
- Community : มีผู้ใช้งานจากทั่วโลกช่วยพัฒนา และอัพเดทฟีเจอร์ใหม่ๆ อยู่ตลอดเวลา
องค์ประกอบของ Kubernetes
Cluster
ให้นึกภาพตามว่า K8s จะเข้ามาครอบมวลมหาประชา Server เอาไว้ ให้เสมือนว่ามันมีแค่ Server ใหญ่ๆ เพียงเครื่องเดียว หากใช้ Cloud ตรงนี้ต้องดูด้วยว่า Platform ของ Cloud นั้นรองรับไหม โดยหลักการ Cluster ของ K8s คือมันจะจัดการให้เองว่าอะไรควรรันไว้ที่ไหน โดย Node ก็จะมีอยู่ 2 ประเภท คือ Master Node และ Worker Node ส่วนวิธีการทำงานร่วมกันของแต่ละส่วนนั้น จะขอกล่าวถึงในหัวข้อถัดๆไปนะคะ
what is kubernetes to datacenter(source : Mesosphere)
K8s Cluster Diagram(source:kubernetes.io)
Deployment
k8s นั้นมีตัวละครหนึ่งที่เป็นพระเอกของเรื่องเลย ก็คือตัว Kubernetes Deployment Controller ซึ่งจะคอยจัดการกับ Instance ต่างๆของแต่ละ Node , ดังนั้นการจะนำ app ของเราไปรันใน K8s เราจะต้องสร้างสิ่งที่เรียกว่า Deployment ก่อน เพื่อเป็นการกำหนด Configuration (การทำ Desired State เพื่อระบุว่าเวลาที่ทุกอย่างปกติดี ควรจะมีอะไรทำงานยังไงบ้าง) โดยที่ K8s จะพยายามดูแลให้เป็นไปตาม config ให้ตลอดเวลา หากเกิดความผิดพลาดอะไรจะ Auto Self-healing ตัวเองโดยอัตโนมัติ
โดยการ Config เราจะทำในไฟล์ .yaml
Node and Pod
“Container -> Pod -> Worker Node -> Master Node ”
Part l : Pod
จัดว่าเป็นหน่วยที่เล็กที่สุดของ K8s ซึ่งภายในแต่ละ Pod จะประกอบไปด้วย
- Container (หรืออาจจะเป็นกลุ่มของ Container ก็ได้ ในบางกรณีที่ต้องการทำ Load-Balance ของข้อมูล)
- Resource ของ Container นั้นๆ ยกตัวอย่างก็เช่น Storage , Network และ IP
- Config ต่างๆของ Container แต่ละอัน รันยังไง คุยผ่านพอทไหน
What object can be include in pod(source:kubernetes.io)
Part ll : Worker Node or Minion
เป็นเหมือนสำนักงานย่อย โดยแต่ละ node มี process ชื่อ kubelet ไว้สื่อสารกับ master node และมี docker ในตัว เพื่อรัน container และเนื่องจาก Pod จะรันอยู่บน Node เสมอ นั่นหมายความว่า ในแต่ละ Worker Node นั้นสามารถประกอบไปด้วย Pod หลายๆตัวได้
Many pod can be include in same worker node(source:kubernetes.io)
Part lll : Master Node
เป็นเหมือนเป็นศูนย์บัญชาการ คอยสั่งการ Node ลูกต่างๆ(Worker Node & Minion) ว่าต้องทำอะไรบ้าง ดังนั้นเวลาเราจะแก้ไขหรือ Deploy ติดตั้งอะไร จะสั่งการผ่าน Node นี้เท่านั้น
จากรูปด้านบนจะเห็นการทำงานของ Master Node ชัดเจนมาก ว่าทำหน้าที่อะไรบ้าง ทั้งในส่วนของการติดต่อกับ API , การ Controller Node ต่างๆให้ทำงานตาม Config (ที่เรากำหนด Desired State ตอนไป Deployment มานั่นแหละ) ของเราโดยอัตโนมัติ , การทำ Scheduler เพื่อควบคุม Workload ของแต่ละ Node และเป็นตัวที่จะควบคุมการติดต่อสื่อสารของ Node ทั้งหมดด้วย
Anatomy of Kubenetes Node
ถ้าเปรียบเทียบองค์ประกอบของ K8s อยากจะให้จินตนาการกันง่ายๆประมาณว่าPod = เซลล์ , Worker Node = อวัยวะต่างๆในร่างกาย , Master Node = สมอง ….ประมาณว่าเซลล์หลายๆเซลล์(Pod) ประกอบขึ้นมาเป็นอวัยวะต่างๆ (Worker Node) แต่ละอวัยวะก็ทำหน้าที่ของมันแตกต่างกันไป และอวัยวะต่างๆในร่างกายนั้นก็สามารถที่จะทำงานร่วมกันได้ โดยมีสมอง (Master Node) เป็นตัวควบคุมสั่งการทุกอย่าง
ReplicaSet
มีหน้าที่หลักคือทำให้ Pod มีจำนวนเท่ากับตอนที่เราสั่งมัน ควบคุมดูแลตาม Config ตอนที่เราทำ Deployment ให้เป็นไปอย่าง Automatic คือหากมีจำนวนมากไปจากที่กำหนดก็ทำลายทิ้งให้ หรือหากน้อยไปก็สร้างเพิ่มให้ (Self- Healing) แถมเรายังสามารถใช้มันในการทำ Auto-Scale เพื่อใช้ประโยชน์ได้ เช่นกำหนดลงไปใน Config ว่า หาก CPU Usage over 80% ให้สร้าง Pod เพิ่มขึ้นมาอีก
Services
เนื่องจากการทำงานของ k8s นั้นจะต้องมีการ Self-Healing อยู่ตลอดเวลา ดังนั้น k8s จึงมี service ที่ทำหน้าที่กระจาย Load balance ไปยังแต่ละ pod สามารถทำหน้าที่เป็น API Gateway ในตัว นั่นทำให้เวลาเกิดการ เพิ่ม/ลด ของ pod ตัวที่ทำการเรียกมายัง pod ดังกล่าว จะไม่รู้สึกเลยว่าหลังบ้านของ pod มีการเปลี่ยนแปลง เพราะ มี service เป็นกลไกการทำงาน และเป็นตัวกลางสื่อสารให้เอง (ตัวกลางแบบ Client to Pod และ Pod to Pod )
Services มีส่วนสำคัญในการทำให้การอัพเดทระบบไม่มี down time (zero down time)
โดยใน Service มีการใช้ Labelsซึ่งตั้งค่าเอาไว้ที่ config file (.yaml) โดย set Label ไว้ที่แต่ละ Pod และไป Set ที่ Service อีกทีว่าถ้าเรียก Service นี้ จะให้เชื่อมต่อไปยัง Pod ที่มี Label อะไรบ้าง
จากภาพคือเราสามารถที่จะใส่ Label ไว้ที่แต่ละ Pod ได้ หลังจากนั้นก็เอาไปบอก Service ว่าใน Service นี้จะให้กระจายโหลดไปยัง Pod อะไรก็ตามที่มี Label = Prod และ Label = Be หลังจากนั้น มันก็จะกระจายโหลดไปตาม Pod ที่ Label เป็น Prod และ Be ให้เองเลย ถึงแม้ Pod นั้นจะมี Label ของ เวอร์ชันอยู่ด้วยก็ตาม ทำให้มันเหมาะในเรื่องของการอัพเดทเวอร์ชันแอพพลิเคชัน
แต่ถ้าอยากจะใช้ Service เรียกแบบระบุเวอร์ชันจริงๆ ก็แค่ไป Set Label และระบุ Version ที่ตัว Pod ที่ตัวการ แล้วก็ไปบอก Service ว่าจะให้กระจายโหลดไปเฉพาะ Pod ที่มี Label เป็นเวอร์ชันที่กำหนดไว้เท่านั้น
พร้อมลุยหรือยัง!
หากศึกษาและพร้อมที่จะลุยกันแล้วสามารถเลือกศึกษาข้อมูลเพิ่มเติมได้ตามลิ้งค์ด้านล่างเลยค่ะ
- สามารถดูคำสั่งทั้งหมดได้ที่ Kubernetes Cheat Sheet
- สามารถศึกษาเพิ่มเติมได้จากเว็บไซต์ที่สอน ที่นี่
- สามารถเรียนผ่าน Web Browser ได้โดยตรงทันที มาเรียนพื้นฐานของ Kubernetes ฟรีๆ กันเถอะ
0 Comments