Kubernetes Deployment Strategies เลือกใช้แบบไหนดี?

clock
01 August 2022

ในยุคของการพัฒนาแอปพลิเคชันสมัยใหม่หรือการพัฒนาแอปพลิเคชันในรูปแบบ Container สิ่งที่ขาดไม่ได้เลยในการบริหารจัดการ Container เหล่านั้นไม่ว่าจะเป็น Upgrade, Scale และอื่นๆอีกมากมาย นั่นคือ Container orchestration ซึ่งถ้ากล่าวถึงจุดนี้คงไม่มีใครไม่รู้จัก Kubernetes

กลยุทธ์ที่ใช้ในการ deploy แอปพลิเคชันไปยัง Container orchestration อย่าง Kubernetes จะเป็นตัวกำหนดประสิทธิภาพ ความเร็ว และประสบการณ์ของผู้ใช้งาน  แล้วอะไรคือวิธีที่ดีที่สุดที่ใช้ในการ deploy แอปพลิเคชัน?

เป็นที่รู้กันดีว่ามาตรฐานการพัฒนาแอปพลิเคชันสมัยใหม่  ให้ความสำคัญกับการพัฒนาที่รวดเร็วและต่อเนื่องเพื่อเพิ่มประสบการณ์การใช้งานที่ดีให้แก่ผู้ใช้งาน  นั่นหมายความว่า แอปพลิเคชันก็จะมีอัพเกรดเวอร์ชันอยู่เสมอ  ดังนั้นการ deploy แอปพลิเคชันให้ราบรื่นและไม่กระทบการใช้งานของผู้ใช้งานจึงเป็นส่วนสำคัญ
ในบทความนี้ จะได้เรียนรู้เทคนิคการ deploy แอปพลิเคชันใน Kubernetes ซึ่งก็มีหลายวิธี  จึงมีความจำเป็นต้องเลือกกลยุทธ์ที่เหมาะสมเพื่อทำให้ระหว่างการอัปเดตแอปพลิเคชันนั้นไม่กระทบต่อผู้ใช้งานนั่นเอง
ภาพจาก https://www.workday.com/en-us/customer-experience/deployment.html

1. Recreate deployment
เป็นการปิดเวอร์ชันเก่าทั้งหมดแล้วเปิดใช้เวอร์ชันใหม่  เหมาะสมกับ development environment  โดยใช้หลักการทำงานง่ายๆคือ แอปพลิเคชันเวอร์ชันเก่าทั้งหมดจะถูกปิดและทำลายลง  จากนั้นจะถูกแทนที่ด้วยแอปพลิเคชันเวอร์ชันใหม่ทั้งหมด

ข้อดี
แอปพลิเคชันทั้งหมดจะถูกแทนที่ด้วยเวอร์ชันใหม่ ดังนั้น ผู้พัฒนา(developer) จะสามารถจัดการกับ process ได้ครั้งละหนึ่ง process  และ codebase จะถูกจัดระเบียบอยู่เสมอ ซึ่งผู้พัฒนา(developer) สามารถมองเห็นเวิร์กโฟลว์ของตนได้อย่างเต็มที่

ข้อเสีย
ในทางกลับแอปพลิเคชันต้องหยุดทำงานชั่วคราว  สำหรับแอปพลิเคชันที่สำคัญซึ่งจำเป็นต้องใช้งานได้ทุกวันตลอด 24 ชั่วโมง เช่น แพลตฟอร์มทางการแพทย์หรือซอฟต์แวร์เซิร์ฟเวอร์  วิธีการ deploy แบบนี้จึงไม่เหมาะสม

ภาพแสดงปริมาณการเข้าถึงแอปพลิเคชันระหว่างการ deploy ด้วยเทคนิค Recreate deployment

2. Ramped (Rolling deployment)
ถือเป็นค่าเริ่มต้น(Default) ของ Kubernetes Deployment Strategies เป็นการค่อยๆเปิดใช้เวอร์ชันใหม่และค่อยๆปิดเวอร์ชันเก่าในเวลาเดียวกัน  วิธีนี้จะมีการสร้าง ReplicaSet สำหรับแอปพลิเคชันเวอร์ชันใหม่  จากนั้นจะเริ่มใช้งานแอปพลิเคชันเวอร์ชันใหม่อย่างช้าๆ โดยการแทนที่ pod เดิมทีละรายการจนกว่าจะเปิด pod ใหม่ครบทั้งหมด  จากนั้นเวอร์ชันเดิมจะถูกลบออกและปิดตัวลง

ข้อดี
รูปแบบการ  rolling deployment  ช่วยให้สามารถ  deploy ได้อย่างต่อเนื่องในแอปพลิเคชันที่มีการใช้งานอยู่  วิธีนี้ช่วยลดการหยุดทำงาน(downtime) ของแอปพลิเคชัน เหมาะสำหรับแอปพลิเคชันที่เป็น stateful ที่สามารถจัดการสมดุล(rebalancing) ของข้อมูลได้

ข้อเสีย
การถอยกลับ(rollout/rollback) อาจทำได้ช้า  เนื่องจากต้องดำเนินการทีละน้อยๆ  และยากต่อการจัดการสำหรับแอปพลิเคชันที่รองรับหลาย APIs  รวมถึงยากต่อการควบคุมทราฟฟิค ดังนั้นสิ่งสำคัญคือทีม deploy ต้องตั้งค่าอัลกอริธึมเพื่อควบคุมทราฟฟิคของผู้ใช้งานให้ได้

ภาพแสดงปริมาณการเข้าถึงแอปพลิเคชันระหว่างการ deploy ด้วยเทคนิค Ramped (Rolling deployment)

3. Blue/green deployment
เป็นการเปิดเวอร์ชันใหม่ควบคู่ไปกับเวอร์ชันเก่าแล้วจึงสลับการรับส่งข้อมูลจากเวอร์ชันเก่าไปยังเวอร์ชันใหม่  เป็นวิธีที่ดีที่สุดต่อการจัดการเวอร์ชันของ APIs  โดย Blue/green deployment นั้นมีความแตกต่างจาก Ramped deployment  เนื่องจากแอปพลิเคชันเวอร์ชันเก่า "สีเขียว" ถูกปรับใช้ควบคู่ไปกับเวอร์ชันใหม่ "สีน้ำเงิน" หลังจากทดสอบว่าเวอร์ชันใหม่สามารถทำงานได้ตรงตามข้อกำหนด  จากนั้นจึงจะอัปเดตออบเจ็กต์ Kubernetes Service ที่ทำหน้าที่เป็นตัวโหลดบาลานซ์เพื่อส่งปริมาณการใช้งานไปยังเวอร์ชันใหม่

ข้อดี
สามารถ rollout/rollback ได้รวดเร็ว  และหลีกเลี่ยงปัญหาการกำหนดเวอร์ชันของแอปพลิเคชัน

ข้อเสีย
ต้องสามารถรองรับ ต้องมีทรัพยากรรองรับเพิ่มขึ้น ที่ต้องการเพิ่มขึ้นเป็น 2 เท่า  อีกทั้งแอปพลิเคชันควรได้รับการทดสอบเป็นอย่างดีก่อนนำไปใช้จริง  และค่อนข้างจัดการได้ยากถ้าเป็น stateful application

ภาพแสดงปริมาณการเข้าถึงแอปพลิเคชันระหว่างการ deploy ด้วยเทคนิค Blue/green deployment

4. Canary deployment
วิธีนี้เป็นการให้ผู้ใช้งานเป็นผู้ทดสอบก่อนนำไปใช้จริงแบบเต็มรูปแบบ  โดยการกำหนดเส้นทางผู้ใช้บางส่วนไปยังฟังก์ชันใหม่  ส่วนแอปพลิเคชันเวอร์ชันเดิมก็ยังคงทำอยู่  จากนั้นหลังจากผ่านไประยะหนึ่งหากไม่พบข้อผิดพลาดใดๆ  ก็จะทำการขยายจำนวน replica ของเวอร์ชันใหม่และลบเวอร์ชันเก่าออกไป
การใช้เทคนิค ReplicaSet นี้ต้องเพิ่ม pod ให้ได้มากเท่าที่จำเป็นเพื่อให้ได้เปอร์เซ็นต์การเข้าการเข้าใช้งานที่เหมาะสม   หากคุณต้องการส่งทราฟฟิก 1% ไปยังเวอร์ชัน B คุณต้องมีหนึ่ง pod ที่ทำงานด้วยเวอร์ชัน B และ 99 pod ที่ทำงานด้วยเวอร์ชัน A ซึ่งค่อนข้างไม่สะดวกในการจัดการ  ดังนั้นหากคุณกำลังมองหาวิธีการจัดการทราฟฟิคที่ดีกว่า  อาจจะใช้ตัวช่วยอย่าง  load balancer  เช่น HAProxy หรือ service mesh เช่น Linkerd ซึ่งช่วยให้สามารถควบคุมทราฟฟิคได้ดีขึ้น

ข้อดี
ด้วยการทดสอบประสิทธิภาพการทำงานจริง  ผู้พัฒนา(developer) สามารถลดความเสี่ยงในการ deploy โดยมีแอปพลิเคชันสองเวอร์ชันที่ใช้งานได้  ดังนั้นผู้ใช้งานจึงไม่มีปัญหาการเข้าใช้งานไม่ได้(downtimes)  นอกจากนี้ เวอร์ชัน Canary จะช่วยให้เห็นภาพความสามารถในการจัดการโหลด  ความเร็วและประสิทธิภาพการใช้งานได้ด้วย

ข้อเสีย
ข้อเสียเปรียบหลักประการหนึ่งของวิธีนี้คือต้องใช้ทรัพยากรมาก เช่น (99% A/ 1%B = 99 pod A, 1 pod B)  อีกทั้งยังใช้เวลาค่อนข้างนาน  รวมถึงการทดสอบและการ deploy ต้องใช้เวลาในการตรวจสอบและประเมินผลอย่างละเอียด  ด้วยเหตุนี้ผู้ใช้บางคนจึงไม่ได้ใช้ประโยชน์จากคุณลักษณะและได้อัปเกรดแอปพลิชันใหม่ได้ในทันทีหลังจากการปล่อยให้ใช้งาน(release)  ซึ่งการใช้งานแอปพลิเคชันทั้งสองเวอร์ชันพร้อมกัน  ผู้พัฒนา(developer) จำเป็นต้องคำนึงถึงและตรวจสอบข้อมูลใน database และ tech stack ให้รองรับการทำงานทั้ง 2 เวอร์ชันด้วย

ภาพแสดงปริมาณการเข้าถึงแอปพลิเคชันระหว่างการ deploy ด้วยเทคนิค Canary deployment

5. A/B testing
วิธีนี้เหมาะสมที่สุดกับการทดสอบในกลุ่มตัวอย่าง  ซึ่งเป็นเทคนิคที่ช่วยการตัดสินใจในธุรกิจโดยพิจารณาจากสถิติด้วย  โดยสามารถประยุกต์ใช้ร่วมกับ canary deployment  และเพิ่มด้วยเงื่อนไขในการกำหนดกลุ่มเป้าหมาย เช่น น้ำหนัก  ค่าคุกกี้  การหาตำแหน่งทางภูมิศาสตร์  เวอร์ชันเบราว์เซอร์  ขนาดหน้าจอ  ระบบปฏิบัติการ  หรือภาษา เป็นต้น  ซึ่ง Istio ก็เป็นอีกหนึ่งใน service mesh  ที่รองรับการทำงานลักษณะนี้เนื่องจากมีความละเอียดในการแยก service instance  โดยอาศัยข้อ HTTP header ในการ routing ได้

ข้อดี
รองรับการทำงานของแอปพลิเคชันได้มากกว่า 1 เวอร์ชันพร้อมกัน  ซึ่งสามารถควบคุม traffic เพื่อรองรับการทดสอบประสิทธิภาพบนการใช้งานจริงและรองรับการย้อนกลับ (rollback)  เทคนิคนี้จึงเป็นวิธีที่ดีที่สุดในการวัดประสิทธิภาพของฟังก์ชันการทำงานของแอปพลิเคชันโดยกลุ่มตัวอย่างที่ช่วยให้มีสถิติการใช้งานและพฤติกรรมของผู้ใช้งานจริง

ข้อเสีย
มีความซับซ้อนโดยต้องใช้กลุ่มตัวอย่าง  และอาจเป็นเรื่องยากที่จะรับประกันความถูกต้องของผลการทดสอบ  อีกทั้งยังมีความท้าทายอีกประการหนึ่งคือการ trace และสืบค้นในกรณเกิดปัญหา เนื่องจากแอปพลิเคชันทั้งเวอร์ชัน A และ B ทำงานพร้อมกันอยู่นั่นเอง

ภาพแสดงปริมาณการเข้าถึงแอปพลิเคชันระหว่างการ deploy ด้วยเทคนิค A/B testing

บทสรุป
การ deploy แอปพลิเคชันก็มีหลายวิธีให้เลือกใช้  สำหรับการใช้งานบน development หรือ staging environment เทคนิค Recreate หรือ Ramped deployment ก็ถือเป็นตัวเลือกที่ดี
ในส่วนของ production environment ในกรณีที่แพลตฟอร์มได้รับการทดสอบอย่างดีแล้วเทคนิค Ramped หรือ Blue/green deployment ก็จะเป็นตัวเลือกที่เหมาะสม  แต่หากไม่มั่นใจในความเสถียรของแพลตฟอร์มหรืออาจมีผลกระทบจากการเปิดตัวซอฟต์แวร์เวอร์ชันใหม่  ก็ควรเลือกใช้ Canary deployment  การทำเช่นนี้ทำให้ผู้ใช้งานสามารถทดสอบแอปพลิเคชันและการผสานรวมเข้ากับแพลตฟอร์มได้  แต่สุดท้ายแล้วหากธุรกิจต้องการทดสอบคุณลักษณะใหม่ในกลุ่มผู้ใช้เฉพาะ เช่น ผู้ใช้ทั้งหมดที่เข้าถึงแอปพลิเคชันโดยใช้โทรศัพท์มือถือจะถูกส่งไปยังเวอร์ชัน A  ส่วนผู้ใช้ทั้งหมดที่เข้าถึงผ่านเดสก์ท็อปจะไปที่เวอร์ชัน B จากนั้น  อาจต้องการใช้เทคนิค A/B testing โดยใช้ service mesh ในการกำหนดกลุ่มเป้าหมายนั่นเอง

ข้อมูลอ้างอิง
-  https://www.techmagic.co/blog/best-application-deployment-strategies/
-  https://blog.container-solutions.com/kubernetes-deployment-strategies

Tags:#Container

Author
Writer: DevOps Team

ทีม DevOps ของ Blockfint ที่มีความเชี่ยวชาญ Cloud Native Services & Solutions


Interested to be our partner?
Mailbox