TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
ในการนำ Application มาทำงานอยู่บน Kubernetes ต้องทำอะไรบ้าง เพื่อให้สามารถทำงานได้ดี ใน Webinar ครั้งนี้ทีมงาน Red Hat ได้แก่คุณวรวิทย์ เลิศกิติพงศ์พันธ์และคุณนัทที จิรัฐติวงศ์วิบูล ได้มาสรุป Best Practice เอาไว้ดังนี้
Configuration ด้าน Resource
1 Keep Application Configuration Outside Container Image
Developer ควรจะต้องพัฒนา code ให้สามารถอ่าน configuration จากภายนอกได้ เช่น ใช้ property file หรือใช้ environment variables โดยทาง Kubernetes สามารถใช้ ConfigMap และ Secrets ในการเก็บ configuration โดย Config Map ใช้เก็บ configuration ทั่วๆ ไป สำหรับ configuration ที่เป็น Confidential ควรใช้ Secret โดยควรมีการทำ Role Base Access Control (RBAC) เพื่อควบคุมสิทธิ์ในการเข้าถึง Secret และการทำเข้ารหัสเพิ่มเติมสำหรับข้อมูล secret ที่เก็บบน etcd ด้วย (encrypt data at rest)
วิธีการนี้จะทำให้ เรามี configuration สำหรับแต่ละ environment โดยใช้ container image เดียวกันได้
2 Specify Resources Request and Limit in Pod Definition
การกำหนดทรัพยากรขั้นต่ำและค่าสูงสุดที่ต้องการใช้งานได้ในการทำงานของแต่ละ pod จะทำให้ผู้ดูแลระบบมั่นใจได้ว่าทรัพยากรโดยรวมนั้นจะไม่ถูกใช้งานหมดไปในการทำงาน และไม่ทำให้ Application หนึ่งๆ นั้นใช้งานทรัพยากรไปจนหมด โดยทรัพยากรขั้นต่ำที่ต้องการ (Request) และสูงสุดที่จะใช้ได้ (Limit) จะมีผลกับ Quality of Service (QoS) ที่ Kubernetes ใช้ในการบริหารจัดการ pod
อย่างไรก็ดี Developer ก็มักไม่ทราบว่าควรจะตั้งค่าตรงนี้ให้สูงแค่ไหนดี ซึ่งตรงนี้ก็จะมีเครื่องมือช่วย
ในการวัดปริมาณทรัพยากรที่เหมาะสมนั้นอาจทำได้ทั้งการทำ Load Test เพื่อทดสอบ หรือการใช้เครื่องมืออย่าง Limit Range สำหรับการกำหนด Request หรือ Limit ให้กับ pod ที่ไม่ได้ถูกกำหนดค่า Request หรือ Limit ไว้ และ Vertical Pod Autoscaler (VPA) ที่สามารถตรวจสอบทรัพยากรที่ใช้ในจริงแล้วให้คำแนะนำ Request และ Limit ที่เหมาะสม หรือจัดการกำหนดค่าให้กับเราโดยอัตโนมัติ
3 Always Defined Liveness and Readiness Probe
ควรมีการทำ Health Check เพื่อให้ทราบว่าแต่ละส่วนของ Application บนระบบนั้นพร้อมให้บริการหรือไม่ ทำให้ Application พร้อมใช้งานอยู่เสมอ
การตรวจสอบ Liveness คือการตรวจว่า Pod ยังทำงานอยู่หรือเปล่า ถ้าไม่ทำงานก็จะ Restart ให้ ส่วน Readiness จะดูที่ Application แต่ละ Pod พร้อมให้บริการหรือไม่ ถ้ามีปัญหาก็จะไม่ส่ง Traffic เข้าไป
ในเชิงการทำงานจะมี Startup Probe เพิ่มเข้ามาอีกอัน สำหรับกรณีตรวจสอบการ Start ระบบขึ้นมาทำงาน
ในการ Probe ทำได้ 3 แบบ คือ HTTP/HTTPS, TCP และการเรียกใช้ Command ภายในระบบ
Configuration ด้าน Reliability & Visibility
4 Protect Application with Pod Disruption Budget
ตั้งค่าระบบให้มั่นใจว่าในระหว่างที่มีการ Maintenance Node อยู่ หรือบาง Node มีปัญหาจริงๆ Cluster จะจัดการให้ยังมีจำนวน Pod มากพอสำหรับให้บริการได้ โดยการกำหนดค่า PodDisruptionBudget ว่า maxUnavailable หรือ minAvailable ควรจะเป็นเท่าไหร่
5 Ensure that Pods Terminate Gracefully
Kubernetes มีกระบวนการในการทำให้ Pod นั้นสามารถ Terminate ได้อย่างถูกต้องโดยเมื่อ Pod เข้าสู่สถานะ Terminating แล้ว Pod จะไม่ได้รับ Traffic ใหม่เพิ่มเติม และ เริ่มเคลียร์ Resource เมื่อได้รับ SIGTERM Signal โดยสามารถทำ preStop hook เพิ่มเติมได้ ถ้ามีความจำเป็นพิเศษในการจัดการ resources ที่ pod ใช้งาน จากนั้นจึงรอเวลาช่วงหนึ่งตาม terminationGracePeriodSeconds โดยค่า default คือ 30 วินาที ก่อนที่จะส่ง SIGKILL ไปยัง Pod นั้นๆ
ตรงนี้เองเป็นสาเหตุว่าทำไมตอนสั่ง Kill Pod ถึงต้องมีเวลาช่วงหนึ่งก่อนที่ Pod จะหยุดทำงานไปจริงๆ
6 Implement Application Monitoring and Alert
ตรวจสอบให้มั่นใจได้อยู่ตลอดว่าระบบสามารถให้บริการได้ในระดับ Application Level ด้วยการใช้ Prometheus, Grafana และ Alert Manager มาช่วยในระดับ Ops ส่วนในระดับ Application นั้นสามารถกำหนด metrics ในระดับ Application โดยใช้ library ต่างๆ เช่น MicroProfile Metrics ในกรณีที่ใช้ Java
ใน Red Hat OpenShift จะมี Developer Console มาให้ และเลือกดู Metric เพิ่มเติมได้ตามต้องการ รวมถึงตั้งเงื่อนไขการ Alert ได้เลย ทำให้สะดวกในการตรวจสอบการทำงานเบื้องต้นได้เลยเป็นอีกทางเลือกหนึ่งที่ช่วยอำนวยความสะดวก ไม่ต้องทำการติดตั้ง monitoring stack เองภายนอก
7 Configure the Applications to Write their Logs to stdout/stderr
ช่วยให้สามารถตรวจสอบได้ว่า Application นั้นยังคงทำงานตอบสนองต่อความต้องการทางธุรกิจได้ตลอด โดย Developer สามารถเขียนข้อมูลลง Log ผ่าน stdout/stderr ได้เลย แล้ว ที่ Node ของ Kubernetes จะใช้ log collector เช่น fluentd คอยตรวจสอบ ก่อนจะรวมข้อมูล Log ไปเก็บไว้ศูนย์กลางโดยสามารถใช้ Kibana / Elasticsearch มาช่วยได้ และ ควรกำหนด Role ให้แต่ละคนเข้าถึงข้อมูลเฉพาะที่เกี่ยวกับตัวเองได้
8 Run One Process per Container
ควรออกแบบ Application ให้แต่ละ Container มี 1 Process เพื่อให้เหมาะสมต่อการใช้งานภายในสถาปัตยกรรม Microservice มากที่สุด และทำให้การทำ Signal Routing เกิดขึ้นได้อย่างเหมาะสม รวมถึงลดโอกาสการเสียทรัพยากรไปกับ Zombie Process และ ในกรณีที่มีความจำเป็น อาจจะทำหลายๆ container ใน 1 pod ก็ได้
9 Implement Resilience Measures – Circuit Breaker, Timeout, Retries and Rate Limits
เก็บข้อมูลเพิ่มเติมเพื่อให้สามารถเพิ่มความทนทานให้กับระบบได้ เช่น การใช้ Hystrix ในระดับโค้ด หรือการใช้ Service Mesh อย่าง Istio ทำให้จัดการกับกรณีที่เกิด Failure ในระบบได้ง่ายยิ่งขึ้น ควบคุมพฤติกรรมของระบบได้จาก Platform โดยตรงเลย
Configuration ด้าน Security ให้กับ Application และ Platform โดยพยายามยึดเรื่อง ShiftLeft Security เป็นหลัก
10 Use Trusted Base Container
ควรใช้ Base Image จาก Source ที่เชื่อใช้ เช่น จาก Vendor ที่มีการจัดการดีๆ และใช้ DevOps Tool ในการทำ Image Sacnning, ตั้งค่าให้ Cluster ดึง Image มาจาก Registry ที่เชื่อใจเท่านั้น ก็จะทำให้ทุกคนเริ่มใช้ของจากแหล่งที่ปลอดภัยมาก่อน
เดือนธันวาคมที่ผ่านมา กว่า 51% ของ Image ใน Docker Hub นั้นมีช่องโหว่ CVE และบางส่วนนั้นก็มี Malware อยู่ภายในระบบด้วย จึงต้องระวังในส่วนนี้ให้ดี
Red Hat เองก็มี Registry ของตนเองให้ใช้ โดยมี Base Image ที่เป็นที่นิยมให ้โดย Red Hat จะคอย Scan และ Update ให้อยู่ตลอด พร้อมระบุ Health Index ที่มีการอัปเดตให้เสมอ และจะทราบทันทีว่า Image เก่าๆ มีปัญหาอะไรบ้าง
11 Use a Separate Build Image and Runtime Image
แยกตัว Build Image กับ Runtime Image ออกจากกัน จะทำให้บริหารจัดการขนาดของ Container ได้ดีขึ้น และลด Attack Surface ที่จะเกิดขึ้นให้เหลือน้อยลงได้
เทคนิคที่เหมาะสมนั้นก็คือการใช้ Multistage Docker Build, การใช้ความสามารถ OpenShift S2I (Source to Image) สำหรับ Java, Go และ C# ที่ช่วยทำ Multistage Build ได้อย่างอัตโนมัติ หรือเลือกใช้ Quarkus สำหรับ Java
12 Use TLS to Protect Communication Between Applications
เราสามารถใช้ Service Mesh เข้ามาช่วยให้มีการเข้ารหัสในการสื่อสารระหว่าง Service ภายใน Cluster ให้หมด จะได้ปกป้องข้อมูลสำคัญที่มีการรับส่งได้ วิธีนี้จะทำให้สะดวกเพราะเป็น Configuration ไม่ต้องทำที่ระดับ Code ของ Application
แนะนำ Free E-Book: Kubernetes Patterns
ทีมงาน Red Hat ได้แนะนำให้ผู้ที่สนใจสามารถศึกษาข้อมูลเชิงลึกเพิ่มเติมได้จาก E-Book ที่ Red Hat แจกฟรีภายใต้ชื่อ Kubernetes Patterns ที่ได้รวบรวมเอาเนื้อหาเหล่านี้เอาไว้อย่างครบถ้วนแล้วที่ https://www.redhat.com/en/topics/cloud-native-apps/introduction-to-kubernetes-patterns
สนใจติดต่อ Red Hat ได้ทันที
ผู้ที่สนใจรายละเอียดเพิ่มเติม สามารถศึกษาข้อมูลเพิ่มเติมได้ที่ https://www.openshift.com/ หรือติดต่อทีมงาน Red Hat ประจำประเทศไทยได้ที่ Email rchemae@redhat.com
