ศึกษา Kubernetes ด้วยตนเอง part 1/2

ถามใครจะเชื่อว่าแม่บุญเหลืออายุมากแล้ว Kubernetes ก็แจ๋ว แจ๋วกันตอนสามสิบ ไม่อยากจะเชื่อว่าตนเองต้องมาเรียนรู้วิธีจัดการสิ่งที่เรียกว่า Cluster เมื่อตอนอายุสามสิบ

ต่อจากนี้ไปจะขอเรียก Kubernetes (อ่านว่า คูเบอร์เนเตส) สั้นๆว่า Kube (ผมอ่านว่า คิวบ์) นะครับ เพราะชื่อมันยาวและต้องอ้างถึงบ่อยๆ อ่อ จริงๆแล้วคำว่า Kubernetes นี้ถูกย่อแล้วได้เป็น K8s (ก็คือ K ตัวแรกแล้วนับไปอีก 8 อักษรตามด้วยตัว s จบ)

คำถามที่ประดังเข้ามาในสมองเมื่อได้ยินชื่อนี้นั้นมีมากมาย ไม่ว่าจะเป็น

• ทำไมต้องใช้ Kube?
• เจอปัญหาอะไรถึงต้องใช้ Kube?
• Kube มีข้อดีอะไรสำหรับ environment ขนาดเล็ก?
• จริงไหมที่ว่า Kube มันฟรี พวก Dev จึงหามาใช้โดยไม่คำนึงถึง learning curve ที่เพิ่มขึ้น (ต้องหาเวลามาเรียนรู้ เอาแค่งาน dev ยังจะไม่รอด เขียนกันมั่วไปหมด)
• พูดถึง Kube ก็ต้องพูดถึง Master กับ Node มันยังไง? ไม่ยุ่งยากไปเหรอ?
• พูดถึง ​Kube ก็ต้องรู้ Docker
• ในเมื่อ Docker ยังไม่รู้จักแล้วจะเข้าใจ Kube ได้อย่างไร?
• เป็น Dev เฉยๆให้เก่งให้ลึกซึ้งในตัวงานก่อนไหมค่อยไปต่อกับ Kube?
• คนที่เขาอยากเรียน Kube เลยเนี่ยคือเขาทำงานด้านดูแลพวก server มาก่อนหรือเปล่า?
• และหากเราเป็นมือใหม่ที่ไม่รู้จะไปต่อทางไหนดี Kube คือแสงสว่างอย่างแรกที่ควรไปเรียนรู้เหรอ?
• ระหว่างมานั่งดูแล Kube กับเครื่อง server ขององค์กรที่เดี๋ยวดีเดี๋ยวไข้ หันไปกอดคนที่รักที่นอนเหงาเดียวดายดีกว่าไหม?
• แทนที่จะได้ทำงานที่ได้รับมอบหมายในฐานะ Dev เวลา push code ขึ้น hub ดันพังและ Kube ตะโกนใส่หน้าว่า “หา image ไม่เจอโว้ย!” มันเป็นความผิดของใคร?
• และความเจ็บปวด 15 ปีของ Google ในการจัดการ software กระทั่งก่อกำเนิดเป็น Kube และเขาแชร์มาให้พวกเราฟรีในฐานะ opensource พวกเราตื่นตัวและบอกว่ามันดีเลิศและประเสริฐมาก เรียกได้ว่าจัดประชุมวิชาการ เปิดคลาสเรียนกันเป็นเรื่องเป็นราว บางรายนั้นถามถึง certificate เท่านี้พอไหมให้ตัดสินใจเรียน Kube?
• เอาล่ะคุณได้ลืม Docker Swarm ไปแล้วใช่ไหม? สารภาพบาปมาเถอะ (ผมนี่ยังไม่รู้จัก 5555)

Intro และรูปมา!

https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/

เสน่ห์ของ Kube คือการ manage a cluster

ค่อยเป็นค่อยไป cluster นี้คืออะไร?

Cluster

ตรงตัวแปลว่า กลุ่ม การรวมกลุ่ม แล้ว Kube ให้ความสำคัญกับกลุ่มของอะไร?

จากรูปข้างต้น ใต้ภาพเขียนว่า Kubernetes cluster มันก็คือกลุ่มของสิ่งที่เรียกว่า Kubernetes นั่นแหละ ไม่ต้องงง เพราะเขาตั้งชื่อกลุ่มว่า Kubernetes

Kubernetes Clusters

เราจึงต้องมาดูต่อว่ากลุ่มของ Kube นี้ประกอบด้วยอะไรบ้าง

1. Master
2. Node

ใน 1 Kube cluster ต้องมีผู้ควบคุม 1 คนเป็นเสมือนวิศวกรโรงงาน ตำแหน่งคือ Master คอยควบคุมดูแลผู้ใช้แรงงานหรือคนงานให้ทำงานไปอย่างปกติสุข ผู้ใช้แรงงานหรือคนงานนี้เรียกว่า Node (บ้างเรียกว่า worker node) จะมีกี่คนก็ได้

Kube: Master

งานของ Master ก็คืองานที่อยู่ใน cluster ทั้งหมด ไม่ว่าจะเป็น

• Scheduling applications
• Maintaining applications เพื่อ desired state
• Scaling applications
• Rolling out new updates

Kube: Node

node อาจเป็น Virtual Machine (VM: โปรแกรมที่ทำงานจำลองตนเองเป็นเครื่องคอมพิวเตอร์) หรือเป็นเครื่องคอมพิวเตอร์จริงๆเลยก็ได้ ถูกรวมเข้าไว้เป็นกลุ่มซึ่งถูกจัดการโดย Master โดยแต่ละ Node จะมีส่วนที่เรียกว่า Kubelet (ผมอ่านว่า คิวบ์เลส) อันเป็นตัวแทนหรือจะเรียกว่าสมองของ Node ในการบริหารจัดการตัวมันเองอีกที

ภาพรวมคือเราเขียนโปรแกรมขึ้นมา จากนั้น deploy ไปไว้บน Kube เราจะต้องไปสั่งงาน Master ให้ไปรัน (Run) โปรแกรมของเรา ซึ่งโปรแกรมที่ถูกรันนี้จะทำงานบน Node

ตัดกลับมาที่ความเป็นจริง ความเจ็บปวดคืออะไร เหตุใดต้องใช้ Kube?

ตัดภาพไปในอดีตเลย!

Orchestration

เป็นคำที่อ่านยากมาก (ออเค็ซทเร-ฌัน) หมายถึง การเรียบเรียงดนตรีสำหรับเล่นในวงออเคสตร้า ง่ายๆว่า การผสมผสานที่ลงตัว ทำงานร่วมกันว่างั้นเถอะ

เครื่อง server จาก https://www.quickserv.co.th/knowledge-base/solutions/

แต่ก่อนเมื่อเราเขียนโปรแกรมเสร็จ ได้มา 1 application เราจะนำมัน (คัดลอก) ไปรันบนเครื่องคอมพิวเตอร์ที่เรียกว่า server เรียกกระบวนการนี้ว่า deployment ความซับซ้อนขึ้นอยู่กับขั้นตอนขององค์กร-หน่วยงานเป็นสำคัญ มักทำแบบ manual คือมีตำแหน่งที่เรียกว่าผู้ดูแลระบบค่อยดูแลให้ เช่น เขียนสคริปต์เอง ก๊อปปี้ให้เอง ส่วนมากเป็นผู้ที่มีความรู้ด้าน network ความผิดพลาดอาจเกิดขึ้นได้ยิ่งถ้าเป็นการรันบนเครื่องคอมพิวเตอร์ที่ผูกกันเป็นกลุ่ม (server cluster) ก็จะมีกระบวนการก๊อปปี้ application ย้ายไปย้ายมาอย่างสนุกสนาน ดื่มกาแฟอดหลับอดนอนกันหลายคืนเทียว

เมืองนอกมีอยู่ 3 จ้าวใหญ่ที่พยายามอย่างมากเพื่อจะแก้ไขปัญหาข้างต้น แข่งกันทำสิ่งที่เรียกว่า Orchestration กับประดาเครื่อง server ที่ผูกกันเป็นกลุ่ม (server cluster) กล่าวคือนำเครื่อง server มาพ่วงต่อกันเพื่อประมวลผลงานร่วมกันแทนการใช้เครื่อง server ที่มีศักยภาพสูงเพียงเครื่องเดียวมาจัดการข้อมูลซึ่งมีราคาแพงมาก หากข้อมูลเกิดความเสียหายก็ลำบากอีก

3 จ้าวได้แก่

• Apache Mesos
• Docker Swarm
• Kubernetes

Apache Mesos เน้นการจัดการ cluster แบบทำ data center ส่วน Docker Swarm เน้นการจัดการ cluster ของ Docker Engines (เรียกว่า swarm) ในขณะที่ Kubernetes แต่เดิมมาจากโปรเจกต์ชื่อ Borg ทว่าไปต่อไม่ได้เนื่องจากขาดการออกแบบสถาปัตยกรรมที่ดี Google จึงเรียนรู้และสร้างโปรเจกต์ใหม่ชื่อ Omega นำความคิดที่ดีจาก Borg มาใช้แล้วเพิ่มระบบการจัดเก็บสถานะของ cluster ไว้ที่ส่วนกลาง เหตุนี้วิศวกรกลุ่มหนึ่งใน Google จึงสร้างโปรเจกต์ขึ้นมาใหม่อีก ให้ชื่อว่า Kubernetes ที่เน้นการทำ orchestration สู้กับสองจ้าวที่เกิดขึ้นมาก่อน

หัวใจของ Kube คือการจัดการ cluster ให้ 1 clusterใดๆมี Master เป็นผู้ดูแลอยู่ตรงกลางค่อยรักษาสถานะ (state) ของแต่ละ Node ไว้

Orchestration สำหรับ Kube ก็คือการบริหารจัดการ Container และ Cluster

Orchestration = Container + Cluster

แล้ว container ที่กล่าวถึงนี้คืออะไร? ขอให้เก็บไว้ในใจ แปปเดียว

Environment ขนาดเล็ก Kube มีความจำเป็นขนาดไหน?

ตอบเลยว่าไม่มีความจำเป็น

application ใดๆหากต้องการทำ orchestration ด้วย Kube ตัวมันเองต้องมีสภาพแวดล้อมแบบ container มาก่อน หรือแม้แต่ application ยุคเก่าที่เรียกกันว่า leggacy ที่ยังไม่เป็น container ก็ต้องทำให้สำเร็จก่อน

งานที่ไม่ต้องการการ scale ไม่มี workload ที่น่าเป็นห่วง จำนวน request น้อย เหล่านี้ไม่จำเป็นต้องถึงมือ Kube อาจนำ application มาทำเป็น container แล้วหยุดเพียงเท่านั้น ดูแลด้วย Docker ก็น่าจะพอแล้ว

งานที่มีขนาดใหญ่เกินกำลังของเครื่อง server เพียงเครื่องเดียว จำเป็นต้องต่อพ่วงกับเครื่อง server อื่นๆเป็นกลุ่ม หรืองานที่เกินกำลังของ VM หนึ่งตัว อย่างนี้จึงเหมาะแก่การทำ orchestration ครับ

Kubernetes VS Minikube

ตัว Kubernetes ประกอบไปด้วยเครื่องมือหลายชิ้นในการบริหารจัดการ orchestration ได้แก่

• Kubectl เป็น command line เพื่อบริหารจัดการ Kube cluster
• Kubeadm เป็น command line เพื่อการจัดเตรียมความปลอดภัยแก่ Kube cluster บน cloud servers หรือ VM
• Kubefed เป็น command line เพื่อช่วยบริหารสิ่งที่เรียกว่า federated clusters
• Minikube เป็น Kube ที่เน้นการทำงานบนเครื่องตนเอง (เครื่อง local ของนักพัฒนา application) คือมองว่า 1 cluster มีแค่เครื่อง local นี่แหละ
• Dashboard เป็น web-based ที่มี user interface ของ Kube เราสามารถ deploy application (ที่เป็น containerized application) แก้ไขหรือจัดการทรัพยากรของมันได้เลย
• Helm เป็นเครื่องมือจัดการ package ของ Kube
• Kompose เป็นเครื่องมือช่วยเหลือ Docker Compose ย้ายไปยัง Kube

Minikube จึงเป็นคำตอบสำหรับนักพัฒนาที่ต้องการศึกษา Kube ในการทำ orchestration นั่นเองครับ

Container คืออะไร?

อันนี้อธิบายด้วย concept ของ Docker จะเห็นภาพชัดเจน หรือพ่วงหัวข้อไปเลยว่า Docker กับประสบการณ์ใช้งาน Oracle Database 12c

Docker กับ Oracle Database 12c

จะเห็นได้ว่า container ก็เป็นเพียงความคิดแบบหนึ่งในการจัดการ software ให้ software นั้นๆทำงานบน virtualization คือมี OS, memory, storage, network และวิธีการ input & output เป็นของตนเอง และสำหรับ Docker container มันก็คือการจัดเตรียม Docker image ที่ประกอบไปด้วยสิ่งจำเป็นในการทำงานของ software ที่ต้องการนั้นๆ อาจต้องการแค่ OS ของ Linux หรือของ Windows หรืออาจต้องการทั้ง OS และตัว Database server เช่น MySQL, MS SQL ติดตั้งไว้ด้วยเลยก็ได้ พอทำเสร็จก็นำไปแชร์กันบนอินเตอร์เน็ตยังสถานที่ที่เรียกว่า hub

เอาล่ะ อินกับ Kube แล้วหรือยังครับ? ถ้ายังผมขอกล่อมอีกหน่อย

Virtual Machine (VM) คือจุดเริ่มต้น

เนื้อหาของบทความนี้มันเริ่มต้นจาก VM กล่าวคือมีความต้องการจำลองเครื่องคอมฯ (virtual) บนเครื่องคอมฯจริงๆ (actual) อีกทีหนึ่ง

การจำลองเครื่องคอมฯเสมือนนี้เรียกว่า virtualization แต่แรกเลยเราต้องเป็นผู้กำหนดว่า เนี่ยจะสร้างคอมฯเสมือนขึ้นมา (virtual machine) ต้องมี CPU อย่างนั้นอย่างนี้ กำลังเท่านั้นเท่านี้ คอร์เท่านี้เท่านั้น มี memory แบบนั้นแบบนี้ ความจุเท่านี้เท่านั้น มี storage ความจุเท่าโน้นเท่านี้ ต่อกับอุปกรณ์ input & output แบบนี้แบบนั้น บลาๆๆ แล้วเลือก OS ที่ต้องการด้วยนะ OS นี้แหละตัวสำคัญ เรียกว่า Guest OS จำไว้ให้ดี

อีกอย่างเจ้าเครื่องคอมฯเสมือนนี้มันไม่รู้ตัวว่ามันเป็นตัวปลอมและทำงานอยู่บน OS อีกตัวหนึ่งที่ติดตั้งไว้กับเครื่องคอมฯจริงๆ เราเรียก OS บนเครื่องคอมฯจริงๆนี้ว่า Host OS

ไม่งงนะ ตอนนี้มี Guest OS กับ Host OS

stackoverflow: how-does-a-docker-engine-replace-a-hypervisor-and-guest-os

แต่ละ VM ประกอบด้วย App + Lib/Bin/Dep + Guest OS ภาพข้างต้นนี้มีทั้งสิ้น 3 VMs ที่ถูกแยกออกจากกันอย่างสมบูรณ์

โลกรู้จัก virtualization นี้มานานแล้ว เครื่อง server ที่จะขับ VM จำนวนมากได้ก็ต้องมีศักยภาพสูง (เครื่องมันต้องแรง มันต้องแพงแน่นวล)

ข้อเสียของ VM เหล่านี้คือใช้ทรัพยากรซ้ำซ้อนกัน ทำงานช้า (ถ้าเครื่อง Host OS ไม่แรงพอ) เปลืองพื้นที่เก็บ OS (เพราะแยกกัน) และโดยทั่วไปก็มักใช้ Guest OS เหมือนๆกันอีกต่างหาก คุณพระ!

ไม่นานความคิด container ก็ถูกสร้างขึ้นเพื่อแก้ไขข้อจำกัดของ virtualization โดยใช้ hardware และ OS เพียงชุดเดียวจึงช่วยลดความซ้ำซ้อนของการใช้ทรัพยากร และได้ย้ายส่วนของ VM ไปครอบ application แทน เหตุนี้ container จึงใช้ทรัพยากรน้อยกว่า virtualization ทันที (จากระดับ GB ลดเป็น MB) เมื่อใช้กำลังทำงานของเครื่องคอมฯจริงๆลดลงก็สามารถสร้าง container ได้มากขึ้น เกิดผลิตผลเพิ่มขึ้นอีกนะเออ

หนึ่งในยี้ห้อที่รับเอาความคิด container นี้ไปใช้ที่เป็นจ้าวดังก็คือ Docker ดูรูปสิ

stackoverflow: how-does-a-docker-engine-replace-a-hypervisor-and-guest-os

มองปุ๊บก็รู้ปั๊บว่า Guest OS หายไป เหลือแค่ Host OS แต่สสารไม่หายไปไหน Docker Engine ได้กลายเป็นผู้ผสานงานส่วนนี้ไปโดยปริยาย

แล้วโลกก็เกิดคำถาม

จะดีกว่านี้ไหม หากว่าสามารถควบคุมดูแลจัดการประดา container ทั้งหลายที่กระจายไปอยู่บนเครื่อง server เหล่านั้นให้ไม่ซับซ้อนจนเกินไป ทั้งยังสามารถเยียวยาตนเองได้เมื่อเครื่อง server ใดเสียหายหรือเกิดข้อผิดพลาด ก็ได้เกิดความคิดทำ orchestration กับกลุ่ม server cluster ทั้งที่เป็นเครื่องจริงและเครื่องเสมือน

และในที่สุดก็ได้เกิด Kubernetes

part ถัดไปลงมือปฏิบัติกันครับ

ศึกษา Kubernetes ด้วยตนเอง part 2: Overview and Practice

อ้างอิง

https://kubernetes.io/docs/reference/tools/

https://www.blognone.com/node/105928

https://www.blognone.com/node/106492