5 Concepts พื้นฐานที่ควรรู้ก่อนเริ่มใช้ Kubernetes

Kubernetes เครื่องมือจัดการ Container ที่มาแรงสุดๆ ในช่วงปีที่ผ่านมา (จาก CNCF Survey 2019) ที่สายงาน DevSecOps ไม่ควรพลาด (DevSecOps ต่างจาก DevOps อย่างไร) สำหรับใครที่ยังไม่รู้จักว่า Kubernetes คืออะไร มีข้อดีหรือประโยชน์อะไรบ้าง สามารถอ่านบทความ 5 ข้อดี Kubernetes ที่สาย Dev ต้องเหลียวมอง

ในบทความนี้เราจะมาพูดถึง 5 Concepts สำคัญของ Kubernetes ทำงานอย่างไร มีส่วนประกอบอะไรบ้าง ทำไมถึงสามารถช่วย Developer ให้สามารถ Deploy Software ต่างๆ ได้เร็วและมีประสิทธิภาพมากยิ่งขึ้น

ก่อนที่จะเริ่มดู Concept ต่างๆ ที่ใช้ใน Kubernetes ต้องเข้าใจ Architecture คร่าวๆ ของ Kubernetes กันก่อน

Kubernetes นั้นประกอบด้วย 2 Components หลักๆ คือ

1. Kubernetes Master หน้าที่หลักๆ คือ คอยควบคุมและดูแล Kubernetes node ต่างๆ เช่น คอย check ว่ามีตัวไหนพังหรือเปล่าหรือต้องการย้าย Container นี้ไปรันบน เครื่องอื่นหรือเปล่า โดยที่ตัว Kubernetes master นั้นไม่สามารถรัน Container ต่างๆ ได้ การสั่งงานจะ Kubernetes Master นั้นต้องสั่งผ่าน API เท่านั้น โดยสามารถสั่งได้ผ่าน Kubernetes CLI หรือ GUI Dashboard ของ Cloud เจ้าต่างๆ 
2. Kubernetes Node คือ ส่วนที่จะเป็นที่ไว้ให้ Container หรือ Service ต่างๆ รันอยู่ทำงาน โดยที่ Node เหล่านี้จะถูกควบคุมด้วย Kubernetes Master อีกที 

ทีนี้มาดู Concepts หลักของ Kubernetes กันเลยดีกว่า

Concept 1: Pod

สิ่งแรกที่ควรรู้ก่อนทำ Kubernetes ก็คือ Pod หรือกลุ่มของ resource ที่เราใช้งานอยู่ ซึ่งภายใน Pod นั้นประกอบไปด้วย 3 Components หลักๆ คือ

• Container/ Compute 
• Network/ IP (โดย 1 pod จะมี 1 IP เท่านั้น)
• Storage/ Volume 

1 Pod = 1 Container หรือไม่?

เป็นคำถามที่เราจะได้ยินกันบ่อยมาก ในความเป็นจริง 1 Pod สามารถมีได้หลาย Container แต่ 80% ของ Pod บนโลกใบนี้มี 1 Container หรือพูดอีกนัยนึงคือ เราสามารถ Deploy หลาย Container บน Pod เดียวกันได้ แต่ไม่เป็นที่นิยมเท่านั้นเอง โดยที่ Pod ไม่สามารถดูแลตัวเองได้ เราจึงต้องมี Concept ของการ Deployment เพื่อมาดูแล Pod อีกที เช่น ถ้าเราเซ็ตว่าเราต้องการ Deploy Service A เป็นจำนวน 3 Pod แต่ถ้ามีตัวใดตัวหนึ่งตายไป ตัว Deployment ก็จะคอยดูแลฟื้น Pod ที่ตายไปให้กลับคืนมาได้

Concept 2: Node Port

อย่างที่เราทราบว่าทุก Pod นั้นจะมี Internal IP ซึ่ง IP นี้ ไม่สามารถถูกเข้าถึงได้จากภายนอก Kubernetes ดังนั้นจึงมี Concept ว่าถ้าอยากให้คนภายนอกเข้าใช้งานในแต่ละ Pod ได้ ต้องสร้าง Service ขวางหน้าตัว Pod นอกจากนี้ Service ทุกตัวของ Kubernetes ยังทำหน้าที่เป็น Logic Loadbalancer อีกด้วย

โดยที่ Service ตัวแรกคือ Node Port ทำหน้าที่ในการ forward IP Pod แบบ Multiple Server ของแต่ละ Pod ไปสู่ IP ภายนอก

ถ้าสังเกตจากภาพจะเห็นได้ว่าจะมีการ forward port จากภายนอกที่เป็น 30007 เข้าสู่ port 80 ของแต่ละ Pod ซึ่งเราไม่สามารถควบคุมได้ว่ามันจะเข้า Pod ในเครื่องไหนก็ได้ เพราะ Service มีการทำงานแบบ Round Robin โดยที่การทำงานของ Node Port นั้นมีข้อเสียคือถ้าหาก Pod ไหนตายไป Pod ที่ถูกสร้างขึ้นใหม่จะถูกเปลี่ยน IP ไม่สามารถเข้าใช้งานได้เหมือนเดิม

Concept 3: Load Balance และ Cluster IP

เป็นอีกสอง Service ใน Kubernetes โดย Node Port จะมีข้อเสียคือ เมื่อ Pod ตายแล้วสร้างใหม่ เราจำเป็นที่จะต้อง map IP ใหม่แทบจะทุกครั้ง แต่ถ้าเราใช้ Service Load Balance เราจะมี Internal Load Balancer ที่คอยคุมใน Kubernetes และ External Load Balancer ที่ใช้ในการเชื่อมต่อกับโลกภายนอก (ตามภาพด้านล่าง)

ทำให้ถ้าเราใช้ Load Balancer จะทำให้เราสะดวกสบายมากขึ้นในการใช้งานเนื่องจาก มันจะสร้างทั้ง Internal และ External Load Balancer ให้เลย พร้อม IP Address ให้เราเข้าใช้งานได้เลย แต่ Load Balancer สามารถใช้ได้เพียงบน on-cloud เท่านั้น (Cloud Service ต่างๆ เช่น GCP, AWS, Azure) ไม่สามารถใช้งานบน on-premise (เครื่อง Server ที่ตั้งเอง) ถ้าเราอยากใช้แบบ on-premise ต้องมีการสร้าง load balancer เพื่อชี้เข้าไปที่ Node Port เอง เนื่องจาก 2 Service ก่อนหน้านี้นั้นทำงานเพื่อติดต่อด้านนอก แต่ถ้าเราต้องการติดต่อภายใน Cluster เดียวกันเองละ จึงมี Service ที่ 3 เกิดขึ้นมาคือ ClusterIP (ClusterIP เป็นการสร้าง Logic Internal Load Balancer)

Concept 4: Ingress

Ingress เป็น Concept ที่พัฒนาต่อจาก Service อีกทีนึง เนื่องจาก Service ประเภท Load Balancer มีปัญหาเรื่องการสร้าง External Load Balancer ตามจำนวนแอพที่มี ทำให้ cost ที่ใช้ในการ Deploy นั้นสูงตามไปด้วย จึงต้องการให้มี Load Balancer ตัวเดียวแต่สามารถแชร์ใช้ได้ในหลายแอพลิเคชั่น ดังนั้น Ingress จึงมาช่วยแก้ปัญหาตรงนี้ได้ โดยที่ Ingress นั้น จะมี Ingress Controller เป็นตัวช่วยควบคุม Traffic ในการกระจาย Load ไปยัง service ต่างๆ ใน Kubernestes

โดย Ingress Controller สามารถ implement ได้ด้วยหลาย Software เช่น Nginx, Istio เป็นต้น โดยที่ส่วนมากเราจะทำให้ Ingress Controller เป็นอีก 1 Node Pod ที่ใช้ในการช่วยควบคุม Traffic ที่เกิดขึ้นภายใน Kubernetes

Concept 5: Label และ Selector

Label และ Selector คือการแปะป้ายไว้ในแต่ละ Pod เพื่อทำให้ Service นั้นสามารถวิ่งเข้าไปหาในแต่ละ Pod ได้ถูกต้อง เช่น ภาพด้านล่าง เราเซ็ตว่า app=foo ใน Selector ของ Service แรก ส่งผลให้เมื่อไรที่เราเรียก Service แรก มันก็จะวิ่ง Traffic ไปหา Pod ที่มี Label: app=foo

แต่ถ้าเราสังเกต Pod ขวาสุดที่ Label เป็น app=baz เราจะสังเกตได้ว่าไม่มี Service ไหนส่ง Traffic ไปให้เลย เพราะ Label และ Selector ไม่ตรงกัน ทำให้เราไม่สามารถวิ่งเข้าไปใช้งาน Pod นั้นได้

ทั้ง 5 Concept ที่ได้นำมาเล่าในวันนี้ก็เป็นเพียง Concept พื้นฐานคร่าวๆ ของ Kubernetes เนื่องจากใน Kubernetes ยังมี Concept อีกหลายอย่าง เช่น Namespace, Rolling Update, Manifest File ,การใช้ Helm ให้ศึกษาอีกมาก

---

รวมทั้งการทำ Best practice ใน Kubernetes ก็สำคัญเนื่องจากระบบนั้นควรมีความมั่นคงในการทำงาน สำหรับใครที่อยากเรียนรู้ Kubernetes แบบเข้มข้นพร้อม Best practice ที่ประหยัดเวลา ไม่ต้องเสียเวลาในการงมหาความรู้เอง เราได้มีการรวบรวมเรื่องราวต่างๆ ไว้ในเวิร์กชอป DevOps Transformation!

เวิร์กชอปรูปแบบ Onsite หลักสูตร 3 วัน ที่คุณจะได้เริ่มต้นตั้งแต่เข้าใจทุกคอนเซปต์การทำ DevOps ผ่านการลงมือทำจริงอย่างถูกวิธี จากโจทย์การทำงานจริงกับผู้เชี่ยวชาญในวงการระดับ TOP พร้อมนำแนวคิดและวิธีการไปปรับใช้ได้อย่างเหมาะสมกับองค์กรของคุณ

สอนจากการทำงานจริงมากกว่า 15 ปี โดยคุณเดียร จิรายุส นิ่มแสง – ผู้ก่อตั้ง และ CEO จาก Opsta (Thailand) ผู้เชี่ยวชาญด้าน DevSecOps ให้คำปรึกษาองค์กรขนาดใหญ่มาแล้วทั่วประเทศ
.
ดูรายละเอียดหลักสูตร และสมัครเรียนได้ที่ 👉 คลิกที่นี่ (รับจำนวนจำกัด)

 

---

หรือเริ่มต้นเรียนได้ใน คอร์ส Kubernetes Mastery

คอร์สที่จะช่วยให้คุณสามารถ Deploy Application ลง Kubernetes และ Helm ได้อย่างผู้เชี่ยวชาญตัวจริงโดยคุณเดียร์ – จิรายุส นิ่มแสง (Certified Kubernetes Administrator และ Google Developers Expert ด้าน Google Cloud Platform)