From Kubernetes to Amazon EKS Blueprints
เนื่องจากผู้เขียนได้มีโอกาสเข้า Karpenter Workshop ของทาง AWS มา ซึ่งผู้เขียนมองว่า ค่อนข้างน่าสนใจ และอยากจะมาเล่าต่อให้กับเพื่อนๆ
อนึ่ง เพราะความยากในการจัดเตรียม Environment และด้วย Workshop ของ AWS นั้นทำได้ดีมากอยู่แล้ว ในบทความนี้จึงจะมาเล่าเพียง ทฤษฏี และเครื่องมือต่างๆโดยสรุปเท่านั้น
เพื่อนๆที่สนใจสามารถ Follow Workshop ได้ที่ Link นี้
What is Kubernetes?
an open-source system for automating deployment, scaling, and management of containerized applications.
เพื่อนๆที่เคยใช้ Docker น่าจะใช้เพราะสามารถควบคุม Environment ได้ง่าย ติดตั้งได้รวดเร็ว
แต่เมื่อ Application ของเพื่อนๆใหญ่ขึ้น อาจต้องรองรับมากกว่า 1 Environment หรือจำเป็นต้องติดตั้งหลาย Node เพื่อรองรับ Load
สังเกตว่า เพื่อนๆต้อง Install , Deploy Docker เหล่านี้ในแต่ละ Node. แล้วถ้าวันหนึ่ง Node ใดซัก Node ล่มขึ้นมา เพื่อนๆจำเป็นต้องเข้าไป Manage ใน Node นั้นๆเพื่อให้ระบบกลับมาทำงานตามปกติ
Kubernetes เกิดขึ้นมาเพื่อแก้ปัญหาเหล่านี้ โดย K8S จะจัดการ Container ต่างๆใน Node ให้เรา ตามค่าที่เรา Settingไว้ใน config
Keyword สำคัญอีกอย่างของ K8 คือ ใช้การกำหนดเป้าหมาย (Desired State) แล้ว K8S จะจัดการให้ State มีลักษณะเหมือนเป้าหมาย โดยไม่ต้องกำหนดกระบวนการ(Declarative)
ตัวอย่างคือ ถ้าเรากำหนดให้มี 3 Node ในระบบ ถ้า 1 Node ตายลงไป K8S จะหาทางทำให้ระบบมี 3 Node เช่นเดิม
อาจจะเป็น Restart Node หรือหาเครื่องสำหรับเพิ่ม Node ให้ครบ 3
Kubernetes architecture
- Node : หรือ Worker Node คือส่วนที่ Container ของเพื่อนๆที่ Deploy ลงไปทำงานอยู่ ติดต่อกับ K8S ผ่านทาง kubelet
- Control Plane : ตัวควบคุมการทำงานของ Worker Node ที่น่าสนใจคือ etcd ที่เก็บ Actual State เพื่อเปรียบเทียบกับ Desired State
- เมื่อ Actual State ต่างกับ Desired State kube-scheduler จะจัดการ Worker เพื่อให้เข้าสู่ Desired State อีกครั้ง
What is EKS (Amazon Elastic Kubernetes Service) ?
สมมุติถ้าเพื่อนๆจะติดตั้ง K8S บน AWS สิ่งที่เพื่อนๆต้องทำคือ
- สร้าง EC2 instances สำหรับ Worker Node
- สร้าง EBS volumes เพื่อเก็บฐานข้อมูลอย่าง etcd
- ใช้ Load balancer Service เพื่อรับ-ส่ง connections ระหว่าง Node
- ใช้ CloudWatch เพื่อตรวจสอบการทำงานของ K8S
- ถ้า K8S Update เพื่อนๆต้อง Update K8S ในแต่ละ Node รวมไปถึงต้องตรวจสอบว่า Version ใหม่นั้น สามารถทำงานร่วมกับ AWS ได้
ซึ่งใช้หลายขั้นตอน และใช้ความเข้าใจในแต่ละ Service ของ AWS อย่างมาก
Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service that makes it easy for you to run Kubernetes on AWS
EKS จึงเป็นเครื่องมือที่จะทำให้เพื่อนๆสามารถเริ่มต้นใช้งาน K8S บน AWS ได้อย่างง่ายดาย
เพิ่มเติม Fargate คือ Serverless Container กล่าวคือ แทนที่จะเช่า EC2 instances โดยเลือกขนาด(Size)ด้วยตัวเอง จัดการ OS ด้วยตัวเอง
Fargate จะยอมให้นำ Docker ไป Deploy แล้วเก็บค่าบริการตามทรัพยากรที่ Docker นั้นๆใช้
What is EKS Blueprint?
เมื่อมีผู้ใช้งาน EKS เยอะขึ้น ก็เริ่มมีคำถามที่พบบ่อยกับทาง AWS
- ต่อ EKS กับ Prometheus ยังไง
- รัน Big Data บน EKS ยังไง
- ต้องการ Best practices สำหรับ EKS + Argo CD
ทาง AWS จึงทำ Blueprint เพื่อเป็น Best practices สำหรับการ Migrate Infrastructure เหล่านั้นขึ้นมา ตั้งแต่ Docs , Workshop จนถึงตัวล่าสุดอย่าง IaC (Infrastructure as code)
อนึ่ง ผู้บรรยายได้บอกว่า Blueprint เหมาะกับทีมที่ยังไม่มี Best practices สำหรับ EKS ถ้านำ Blueprint มาใช้ร่วมกับ EKS เดิม มักจะเกิดปัญหาความเข้ากัน(Compatibility)
What is IaC (Infrastructure as code) ?
uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure
ถ้าเพื่อนติดตั้ง Infrastructure Tools อย่าง ArgoCD , Karpenter บน Linux สิ่งที่เพื่อนๆจะทำ อาจจะเป็น
- apt-get install
- Check Version + Update Version
- เมื่อ Scaling , เปลี่ยน Instance จำเป็นต้องติดตั้งใหม่ตั้งแต่ K8S + Infrastructure Tools
งานที่ซ้ำซ้อนเหล่านี้ เราจะเริ่มเขียน Script เพื่อควบคุมการติดตั้ง เริ่มจากการเขียน Bash Script
เมื่อเป็น Code สิ่งที่เกิดขึ้นคือ
- เมื่อเปลี่ยน Environment ( UAT , Production ) จะใช้ Code เดิมรันได้ทันที
- ลดความผิดพลาดจากการ Set Environment
- เมื่อเป็น Code สามารถใช้งานร่วมกับ version control ได้ ง่ายต่อการส่งมอบต่อ
การใช้ Code เพื่อติดตั้ง , จัดการ Infrastructureนี่เอง คือจุดเริ่มต้นของ IaC
Imperative VS Declarative?
ก่อนจะไปต่อ ต้องอธิบาย Concept ระหว่าง Imperative , Declarative เสียก่อน
##########Imperative####################
let numbers = [1, 2, 3, 4, 5];
let doubledNumbers = [];
for (let i = 0; i < numbers.length; i++) {
doubledNumbers.push(numbers[i] * 2);
}
###########Declarative###########################
let numbers = [1, 2, 3, 4, 5];
let doubledNumbers = numbers.map(num => num * 2);
- Imperative : “ต้องทำอย่างไร”
- Declarative : “ต้องการผลลัพท์ใด”
เมื่อเพื่อนๆเรียน Programming101 จะสังเกตว่า เพื่อนๆจะใช้ Pattern Imperative เป็นส่วนใหญ่ เพราะตรงไปตรงมา และเป็นรากฐานกับ Pattern อื่นๆในอนาคตอย่าง OOP
Declarative เพื่อนๆอาจไม่คุ้นเคยนัก แต่ถ้าเพื่อนๆสังเกต SQL , REGEX รวมไปถึง K8S ในต้นบทความ นั้นอยู่ในหมวดหมู่นี้
(ถ้าเพื่อนๆเคยตั้งข้อสงสัยว่า ทำไม SQL ถึงทำงานไม่เหมือนกับ Programming Language อื่นๆเลย ถือว่าตั้งข้อสงสัยได้ถูกแล้วครับ)
แล้วมันเกี่ยวข้องกับ IaC และ EKS อย่างไร?
What is Terraform?
ด้วยข้อดีต่างๆของการ Declarative จึงมีผู้พัฒนา IaC ที่ใช้การ Declarative ขึ้นมา โดยใช้ชื่อ Terraform
จึงเป็นเหตุผลที่ EKS Blueprint นั้น ใช้งานบน Terraform
ถึงตรงนี้ เพื่อนๆน่าจะพอมีพื้นฐานพอที่จะตาม Workshop EKS Blueprints for Terraform แล้วครับ
เพิ่มเติม เพื่อนๆน่าจะคิดแน่ๆว่า IaC หรือ Tools อย่าง Terraform นั้น ทำงานซับซ้อนกับ Docker ตั้งแต่ต้นบทความเลยนี่นา ซึ่งมันก็มีส่วนจริงครับ
แต่ความสามารถ Docker นั้นมีอยู่อย่างจำกัด ตัวมันเองไม่ได้ install ตัวเองไว้บน Instance จริงๆ แต่อยู่ใน Container
Function อย่าง AutoScaling (และอีกหลายคุณสมบัติที่สำคัญ) นั้นไม่สามารถทำงานได้บน Docker
What is Argo CD?
“Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.”
ใช้สำหรับการ CD (continuous delivery) บน K8S
เพื่อนๆน่าจะเคย Deploy Project กัน สมมุติว่าถ้าเพื่อนๆใช้ Docker-Compose ในการ Deploy บน Instance
สิ่งที่เพื่อนๆต้องทำคือ
- pull project บน Instance
- ปิด Service เก่า
- รัน Docker-Compose ใหม่
เมื่อเพื่อนๆใช้ K8S ขั้นตอนเหล่านี้จะลดลงเป็นการสั่งการผ่าน kubectl เท่านั้น (แต่บางคำสั่งก็ถือว่าซับซ้อน)
เพื่อลดขั้นตอนดังกล่าว ArgoCD จะลดขั้นตอนดังกล่าว โดย ArgoCD จะสั่งการ kubectl ให้ Deploy เอง เมื่อมีการ Push Git (อันเป็นหลักการของ GitOps CD)
Feature ที่สำคัญอีกอย่างของ Argo CD คือ การทำ BlueGreen Deployment Strategy (คิดสภาพ Web ที่ Deploy แล้วไม่มีจังหวะให้ Web Down แม้แต่ 1 วินาทีดู)
ด้วยความสะดวกเหล่านี้ EKS Blueprint จึงรวม Argo CD ไว้เป็น Best practice ด้วย
What is Karpenter?
ก่อนเปิดตัวของ Karpenter หากผู้ใช้ต้องการที่จะปรับความสามารถในการทำ scaling บน Kubernetes คลัสเตอร์จำเป็นต้องใช้ Amazon EC2 Auto Scaling groups ควบคู่กันกับ Kubernetes Cluster Autoscaler เพื่อรองรับการทำ dynamic scaling ของคลัสเตอร์
โดยลูกค้าที่ใช้งาน Kubernetes เกือบครึ่งบน AWS รายงานว่า การกำหนดค่าการปรับขนาดคลัสเตอร์โดยใช้ Kubernetes Cluster Autoscaler (CA) นั้นทำได้ยากและมีข้อจำกัดเยอะ
Autoscaling with Karpenter
เพื่อนๆอาจจะตกใจแต่ว่า ที่เกริ่นนำมาทั้งหมด พึ่งจะมาถึงส่วน Workshop ที่เจ้าของบทความได้ Follow ตามเท่านั้น
อย่างไรก็ตาม Workshop นี้ใช้การเตรียมการที่นานมาก หัวข้อนี้จึงอยากจะเล่าแค่ว่า การใช้ Karpenter สะดวกกว่าวิธีเดิมแค่ไหน ต้อง Setting อะไรบ้าง แต่ถ้าอยากใช้งาน Karpenter แนะนำให้ Follow ตาม Workshop
มาถึงตรงนี้แล้ว ต่อให้เพื่อนๆไม่ได้ทำตาม Workshop น่าจะมั่นใจได้ว่า ถ้าไม่ใช้ EKS Blueprint แล้ว Setting เอง งานนี้จะยากขนาดไหน (ลองคิดว่าแก้ Compatibility ระหว่าง K8S , Terraform , ArgoCD , Karpenter )
เมื่อเป็นอย่างนี้แล้ว ได้เวลาที่เพื่อนๆจะเริ่ม Workshop แล้วครับ
บทส่งท้าย
ตอนแรก ผมมีความคิดว่าจะได้ไปเรียน Workshop K8S แบบชิวๆ สรุปว่า K8S ของผมนั้น จบตั้งแต่ 10 นาทีแรก จากนั้นต่อด้วย EKS + Infra tools รัวๆ จนผมคิดว่าตัวเองเป็น DevOps ไปชั่วขณะ
จริงๆบทความนี้เล่าได้เพียง ทฤษฏี , ที่มาของเครื่องมือแต่ละอย่างแบบผิวเผินมากๆ ด้วยความที่เครื่องมือแต่ละตัวนั้นลึกมาก จนไม่สามารถใส่ทุกอย่างไว้ในบทความเดียวได้ (รวมถึงยัดใน Workshop เดียวด้วย TT )
อนาคต จะมีบทความที่เจาะลึกแต่ละเครื่องมือต่อไปครับ (แน่นอนว่า ผมก็ต้องไปเรียนมาก่อนเหมือนกัน LOL)
ท้ายที่สุด ขอขอบคุณทางบริษัท Gosoft (Thailand) Co.,Ltd ที่มอบโอกาสให้ได้ไปเรียนรู้เทคโนโลยีใหม่ๆ , ทาง AWS ที่มอบ Workshop ดีๆให้ รวมไปถึงเพื่อนๆที่ติดตามบทความนี้ของผมนะครับ
นี่เป็นบทความที่ยาวที่สุดตั้งแต่ที่เคยเขียนMedium มาเลย ถ้ามีอะไรผิดพลาด หรืออยากแนะนำอะไร สามารถ DM มาได้ที่ Page AstralAria นะครับ