qa-kubernetes-rancher-article
qa-kubernetes-rancher-article

Kubernetes คืออะไร?

ทุกคนคงรู้จักคําว่า Docker กันดีอยู่แล้วล่ะในตอนนี้ 🙂 คําว่า Docker ไม่ใช่เรื่องใหม่แล้ววว แต่ถ้าใครยังไม่รู้จักคําว่า Docker ให้อ่านได้จากที่นี้เลย รวมบทความฮิต Docker พออ่านเสร็จแล้วขอแนะนําให้ลงมือเล่นจริงๆด้วยน่ะ ด้วยการลอง pull code ใน github ของ howtoautomate มาเล่น ก็จะเข้าใจหลักการณ์ทํางานของ Docker, DockerFile และ Docker Compose แล้ว

ทีนี้หลังจากเข้าใจว่า Docker คืออะไรแล้ว ลองจินตนาการถึงการนํา Docker ไปใช้ใน Production จริงๆสิ ว่าเราจะนํา Container เหล่านั้นไป Deploy บน Production environment ได้อย่างไร? มันก็คงมีหลากหลายวิธีกันไป เช่น

  • Manual เลย เอา Docker Compose File ไปวางแล้วสั่งรันด้วยมือเราเอง (ไม่ดีน่ะ ลองคิดว่าเรามีเป็นร้อยๆเครื่องสิ ตายน่ะครับพี่น้อง … ยังไม่พอแล้วจะให้มันทํางานเชื่อมกันได้อย่างไรล่ะ อันนึงวิ่งไปแล้ว อีกอันยัง start ไม่ขึ้นเลย)
  • หรือ ขอให้ DevOps ทําให้  (อ่าว เห่ย …. ไม่เหมือนที่คุยกันไว้นี้หว่า)

ไม่หรอกจริงๆแล้ววิธีที่ถูกในการจัดการ deployment/manage container production environment คือการใช้ Docker Swarm นั้นแหละ หรือ ไม่ก็ Kubernetes 🙂

  • เช่น ใช้ Docker Swarm เพื่อ Orchestration ควบคุม Worker (เครื่องที่คอยรับคําสั่งจาก Manager Node) ต่างๆ

    docker-swarm-architecture
    docker-swarm-architecture
  •  หรือใช้เจ้า Kubernetes ที่จะพูดถึงวันนี้เนี่ยแหละ ในการจัดการ Orchestration container ทั้งหมด
    k8s-cluster-diagram
    k8s-cluster-diagram

    Orchestration เอาภาษาบ้านๆเลยน่ะ มันคือการประสาน Container ต่างๆเข้าด้วยกันให้ทํางานไปในทิศทางเดียวกันไรแบบนั้น 🙂

ที้นี้เจ้า Kubernetes เนี่ยมันมีความแตกต่างกับ Docker Swarm อยู่ ถึงแม้จะดูเหมือนคล้ายกันแต่ Concept ของ Kubernetes เนี่ย มันคือเรื่องของการมองแต่ละส่วนเป็น Clustering มาเป็นหลักเลย ซึ่งโดยรวมแล้ว ถือว่าค่อนข้างดีกว่ามากทั้ง feature auto scaling, rolling update, auto healing อีก และ รวมไปถึง Community ต่างๆของ Kubernetes ก็ค่อนข้างใหญ่มากๆๆๆๆเลย ถ้าเทียบกับ Docker Swarm แถมยังผลิตด้วย Google อีก เพราะฉะนั้น เรียนรู้มันไว้น่ะจร้าา

k8s-vs-dockerswarm-activity
k8s-vs-dockerswarm-activity (https://platform9.com/blog/kubernetes-docker-swarm-compared/)

ต่อไปจะไม่ใช้คําว่า kubernetes แล้วน่ะจะเรียกชื่อย่อมันชื่อ K8s แทนเพราะในภาษากรีกคําว่า ubernetes แปลว่า 8 พอเอามารวมกับคําส่วนหัวและท้ายเป็น k + 8 + s = k8s นั้นเอง (จริงๆแค่ขี้เกรี้ยจพิมพ์)

Kubernetes Architecture

k8s-architecture-overview
k8s-architecture-overview

จําไว้เลยพื้นฐานของ k8s มีแค่ 5 อย่างนี้เท่านั้น

  1. Deployment
  2. Pod and Nodes
  3. Services
  4. Scale
  5. Update

Deployment

เริ่มจาก basic ที่สุดของ k8s ที่เราจําเป็นต้องรู้เลยล่ะ Deployment

k8s-deployment-controller
k8s-deployment-controller (https://kubernetes.io/docs/tutorials/kubernetes-basics/deploy-intro/)

เจ้านี้คือภาพรวมของ k8s cluster นึง ซึงในแต่ละ cluster จะประกอบไปด้วยหลักๆๆคือ Master และ Worker Node และจะคุยกันผ่าน k8s API

พอลงลึกก็จะเข้าใจว่า k8s มี Kubernetes Deployment Controller อยู่เพื่อคอย manage instance ของ node ต่างๆถ้าวันใดวันนึงมันหายไปเจ้า Deployment Controller ก็จะทําหน้าที่ Self-healing mechanism ให้มันกลับมาได้เอง 🙂 โดยที่เรานั่งกินขนมเฉยๆไม่ต้องทําเองเลยล่ะ ส่วนการที่เราจะเข้าไป interact กับ Deployment ได้เราจะใช้เจ้า Kubectl ที่ทําหน้าที่ส่งข้อมูลคุยกับ cluster ผ่าน k8s API นั้นเอง

Pod and Worker Node

ซึ่งการ Deployment แต่ละครั้ง k8s จะสร้างสิ่งที่เรียกว่า Pod ขึ้นมา สิ่งเป็นสิ่งที่เรียกแทนของกลุ่มของ Application Container ก็ว่าได้ ซึ่งในเจ้าตัว pod เนี่ย มันจะ share อะไรด้วยกันหลายอย่างมากกกก เช่น storage, networking (ใช้ cluster IP เดียวกัน) และ information อื่นๆๆเช่น port ด้วย

k8s-pod-overview
k8s-pod-overview

เจ้า Pod นี้จะรันบน node เสมอน่ะ ซึ่ง node นึงเนี่ยมีหลาย pod ได้น่ะ ผสมกันไป แบบรูปข้างล่างนี้เลย

k8s-multiple-pod-in-node
k8s-multiple-pod-in-node

จะเห็นว่าหนึ่ง Node จะมี kublet ที่เป็นตัวไว้ติดต่อสื่อสารกับ Master เผื่อในกรณีเกิดปัญหาไรขึ้นมา Self-healing จะทํางานผ่าน k8s API นั้นเอง และใน node ก็มีหลาย pod แยกๆกันไปได้

โดยคําสั่งหลักๆในการใช้งานที่ต้องรู้ไว้เลยน่ะคือ

  1. kubectl get <pod/services> (list resources ทั้งหมด)
  2. kubectl describe <pod/services> (show infromation of resources)
  3. kubectl logs (ดู log container)
  4. kubectl exec (execute command ใน container)
  5. kubectl proxy (ยังจําได้มั้ยว่า Pod มันทํางานแยกกัน isolate network ไปเลย เพราะฉะนั้นการที่จะเข้าไปติดต่อมันได้เนี่ยต้องสร้าง proxy คุยกันนั้นเอง)

เจ้า Pod เนี่ยมันมี Life Cycle ของมันเองน่ะ หมายถึงว่า มันเกิด แก่ เจ็บ ตายได้ 🙂  เมื่อ Node หรือ Worker Node ตายเนี่ยเจ้า Pod มันก็ตายไปด้วย

Services

k8s-services
k8s-services

Services มันเป็นอารมณ์ abstraction ที่ทําให้ Pods มันตายแล้วเกิดใหม่ได้อะ โดยไม่กระทบกับ application ของเรา เช่น สมมุติจากรูปข้างบนน่ะ มันเป็น backend cluster ที่รอ frontend เรียกเข้ามา … สมมุติว่า worker node ของ Service B ตายไปตัวนึง มันก็ยังมีอีกตัวนึงให้กับ frontend เรียกเข้ามาอยู่ดี โดย FE ไม่มีความจําเป็นต้องรู้อะไรเลยว่ามันมีการตายไป เพราะมัน route traffic จาก pod นึงไปอีก pod นึงด้วยตัวเองด้วย Kubernetes Services ซึ่งท่ามาตราฐานที่นิยมทํากันก็คือจะติด label ให้กับ services เพื่อให้อนาคตมาเรียกใช้ง่ายๆนั้นเอง แบบรูปข้างล่างเลย

k8s-services-label
k8s-services-label

โดยคําสั่งหลักๆในการใช้งานที่ต้องรู้ไว้เลยน่ะคือ

  1. kubectl expose (เพื่อสร้าง services ใหม่และ bind port เพื่อให้ external traffic ใช้ได้นั้นเอง)
  2. kubectl label (ติด label เพื่อเรียกใช้งาน services)

Scaling

ถึงเวลา Scale ต่างๆๆออกไปกันดีกว่า คือปกติแล้วเวลาบน production เราคงไม่มีแค่ instance เดียวหรอกใช้มั้ย? เราก็ต้องมีเป็น 10,100 หรือ 1,000 instance เพื่อรองรับ Load อันมหาศาลจาก User นั้นเอง ทีนี้เจ้า k8s เองก็มี feature ที่รองรับเรื่องแบบนี้อยู่อย่าง Auto Scaling แต่นอกประเด็น วันนี้เรามาดูเรื่องพื้นฐานก่อนดีกว่า

k8s-deployment-scaling
k8s-deployment-scaling

จะเห็นว่าเวลาเรา get deployments ออกมาจาก kubectl มันจะมี column หลายแบบเช่น DESIRED, CURRENT, UP-TO-DATE,AVAILABLE ซึ่งแต่ละตัวมีความหมายถึงเรื่อง scale ทั้งนั้น

  • DESIRED (configured number of replicas)
  • CURRENT (จํานวน replicas ที่กําลังทํางานอยู่)
  • UP-TO-DATE (จํานวน replicas ที่ได้รับการ update ส่วนของ desired (configured) state)
  • AVAILABLE (จํานวน replica ที่พร้อมให้ user ใช้งานนั้นเอง)

คือต้องพูดว่าอาจจะยังนึกภาพไม่ออกน่ะ แต่อยากให้นึกถึงภาพของรูปแรกๆเลยที่เรียนกันมา

k8s-deployment-controller
k8s-deployment-controller

นึกถึงเจ้าตัวนี้แต่ให้นึกถึงเจ้าพวกนี้กระจายตัวออกไปเรื่อยๆๆๆๆๆๆๆ เพื่อ replica ให้ user ใช้งานนั้นเอง

k8s-scale-4-replica
k8s-scale-4-replica

อย่างตัวอย่างข้างบนแปลว่า replica ออกมามี deployment 4 ตัวแล้วล่ะ 🙂 ง่ายๆแค่คําสั่งเดียวเอง

คําสั่งหลักๆเลยก็คือ

  1. kubectl scale <deployment name> –replicas=<Number of deployment replica>

Update

คราวนี้เริ่มยุ่งล่ะ หลังจาก scale เสร็จ … แล้วเราจะทํายังไงให้เมื่อมันมี update ในแต่ละส่วน เช่นสมมุติถ้าต้องกรจะเปลี่ยน version ของ deployment ล่ะ? เจ้า k8s มี Rolling update feature ที่มีหน้าที่หลักๆเลยคือการ ให้เจ้า deployment’s update แบบ zero downtime ด้วยการ update ด้วยการสร้างตัวใหม่ขึ้นมาให้ใช้งานเลย

k8s-rolling-update
k8s-rolling-update

แบบเจ้าตัวสีม่วงอะ มันสร้าง Pod ตัวใหม่ขึ้นมาเฉยเลยอะ แล้วก็ค่อยๆสร้างตัวใหม่มาแทนที่แล้วก็เปลี่ยนอีกทีนั้นเอง 🙂

คําสั่งหลักๆเลยที่ใช้ก็

  1. kubectl set <deployment name> <image:version>
  2. kubectl rollout undo <deployment name>

และนี้ก็คือทั้งหมดหัวใจหลักของ k8s เลย ไม่ยากใช่มั้ยล่ะ มีหลักๆแค่

  1. Deployment
  2. Pod and Nodes
  3. Services
  4. Scale
  5. Update

พวกนี้เท่านั้นเอง 🙂

แตกต่างกับ Docker Swarm ยังไง?

คงเป็นคําถามที่คนส่วนใหญ่ชอบถามแหละว่า อ่าวแล้วมันแตกต่างกับ Docker Swarm ยังไง? จริงๆเจ้า Pros and Cons ของทั้งสองตัวนี้มีเยอะแยะไปหมดเลยน่ะ โดยหลักการณ์น่ะ มันคล้ายกันคือต้องการเป็นตัว Orchestration สําหรับ container เหมือนกัน แต่มันแตกต่างกันโดย design cluster-based กับ worker-node-based วิธีการมองไม่เหมือนกัน อย่างที่เห็นในอธิบายมา มันจะเน้นเรื่องของ Cluster เป็นก้อนๆๆไป แล้วสร้าง Node ต่างๆกันไป แต่ถ้า Swarm มันมองเป็น Worker based คือเหมือนเอา agent ไป run container บนนั้นซะมากกว่า

แล้ว feature ต่างๆ ก็ต้องยกให้เจ้า k8s เนี่ยค่อนข้างเหนือกว่ามากๆ ในเรื่อง feature และ limitation กับ Docker API เช่นเรื่องเข้าใจง่ายๆก็เรื่องของ health check ใน docker swarm เนี่ยเราต้องไป add functional check เองซึ่งยุ่งยากน่าดู แต่ในทางกลับกัน k8s มี functionality ที่ไว้จัดการ liveness (app start แล้วแต่ยังเตรียม services ไม่เสร็จ) และ readiness (app start แล้วและ services พร้อมทํางาน)

นี้แค่ส่วนเล็กๆน้อยท่ีข้อดีข้อเสีย แต่ feature come with a price เสมอ….. เจ้า k8s เองก็ต้องใช้ learning curve ในการเรียนรู้ค่อนข้างมาก รวมถึงการติดตั้งเป็นแบบ “Do-it-yourself installation” จะบ้าตายเลยละ ฮ๋าๆ แต่ด้วยความที่ว่าเจ้า community ของ k8s ก็ใหญ่โตมากๆก็เลยมีให้เข้าไปอ่านได้เยอะ

วิธีลองเล่น k8s บนเครื่อง?

เนื่องด้วยมันเป็น Cluster-based ไอ้เราก็นึกว่าจะใช้งานลําบากแล้ว แต่ที่ไหนได้เค้ามีเตรียมให้เราเล่นแล้ววว นั้นก็คือ Minikube เครื่องมือที่จะรัน cluster บน local machine เลย

บน Mac ก็ง่ายหน่อยแค่

brew cask install minikube

อ่านรายละเอียดได้ที่ github repo

ซึ่งหลังจาก install minikube เสร็จแล้วแค่ใช้คําสั่ง

minikube start

เราก็จะสามารถใช้ kubectl ได้เหมือนอยู่บน cluster จริงๆแล้ว สร้างพวก deployment,node,pod อะไรได้ตามใจชอบเลย

ถ้าไปเล่นบน Server จริง?

แนะนําให้เล่นตามคู่มือนี้น่ะ บน CentOs 7 เป็นอะไรที่ง่ายสุดล่ะ ไม่งั้นขั้นตอนหลายอย่างจะยุ่งยากมากๆเวลาลง

แต่เชื่อสิ ถึงเวลาจริงๆ ปัญหาอีกเยอะแน่ๆ LOL 🙂

อะไรคือ Rancher?

rancher-platform
rancher-platform

คืออย่างที่บอกที่เราเรียนรู้กันมากับ k8s มันไม่ยากอะไรเพราะมันมี interact shell ให้เราพร้อมใช้งานอยู่แล้ว เพียงแค่กดๆๆตามมันไป แต่ลองคิดภาพที่เราต้องจัดการ env. ทั้งหมดบน production เองสิ ตายหยั่งเขียนเลยอะ ที่ต้องมาลง k8s เองอะไรเอง เลยอยากจะนําเสนอ rancher tools ที่เป็น management platform สําหรับ k8s ได้ดีเลย อารมณ์ลงโปรแกรมให้ ทํา env. ให้ 🙂 แค่นี้ชีวิตเราก็ดีขึ้นเยอแล้วล่ะ

rancher-feature-star
rancher-feature-star

จุดขายมันเลยล่ะ 3 อย่างนี้ คือ setup k8s ให้, ลง application stack ให้ และก็ stay update ตลอดเวลา

สรุปภาพรวมของอนาคต

อย่างที่รู้กันอยู่แล้ว ยุคนี้คือ Cloud ทุกอย่างมันจะเป็น as-a-services ทั้งหมด หลายๆบริษัทก็เริ่มปรับตัวเรื่องของ maintinace cost ลดเครื่อง ลด infra ลงไปทุ่มเทกับ cloud มากขึ้น 1 ใน keypoint สําคัญของ cloud ก็คือตัว clustering และ k8s ก็เป็นหนึ่งในตัวเลือกเด็ดๆที่เรามีในยุคนี้เลย

แถมเรายังเอาไปต่อยอดกับ google cloud ได้อีกด้วย 🙂 ซึ่งพอต่อยอดกับ google cloud ก็ยาวไปถึง machine learning และอื่นๆอีกมากมายเลยล่ะ

here-is-your-potato (https://zusiddiqui.wordpress.com/2012/08/17/the-potato/)
here-is-your-potato (https://zusiddiqui.wordpress.com/2012/08/17/the-potato/)
0 0 vote
Article Rating
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback

[…] ถึงเวลาเล่นของใหญ่อย่าง Kubernetes […]