Lens The Kubernetes IDE

Lens The Kubernetes IDE

สวัสดีครับ DevOps 101 ของเราวันนี้ นำเสนอ Lens ครับ .. ตอนนี้ ก็ออกมาถึง version 5.x.x กันแล้ว ณ ตอนที่ผมเขียน blog ก็เป็น version 5.1.3 เพื่อนๆ บางท่าน อาจจะเคยใช้งานกันมาบ้างแล้ว .. แต่สำหรับบางท่านที่ยังไม่เคยใช้งาน อาจจะยังสงสัยว่ามันคืออะไรกัน เจ้า Lens .. จากคำอธิบายในเว็บของเค้าคือ ..

“Lens is the only IDE you’ll ever need to take control of your Kubernetes clusters. It’s built on open source and free.”

สรุปสั้นๆ เข้าใจง่ายๆ ก็คือ Lens เป็น IDE ที่ช่วยจัดการ Kubernetes (k8s) cluster ของเรา เป็น Open Source และ Free 🙂
สำหรับท่านที่เคยใช้ kube-proxy ที่เป็น Dashboard ของ k8s เอง .. จะพบว่า มันใช้งานไม่ค่อยสะดวกเท่าไรนัก .. ลองเปลี่ยนมาใช้ Lens ดูครับ จะพบว่าสะดวกกว่ามากๆ ..

สำหรับวิธีการติดตั้ง Lens ก็ไป download ได้เลยครับที่ https://k8slens.dev/ มีทั้งบน Mac OS, Windows และ Linux ครับ .. ตัว Lens เองจะใช้ file config เดียวกับ kubectl ของเราคือจะอยู่ที่ ~/.kube/config ซึ่งถ้าใครใช้งาน kubectl ได้อยู่แล้ว ก็จะไม่มีปัญหา อะไร .. แต่ถ้าเปิด Lens ขึ้นมาแล้ว ยังใช้งานไม่ได้ ก็ให้ไปลองดูที่ ~/.kube/config ว่ามีค่า config ต่างๆ ถูกต้องไหม .. หรือถ้าใครใช้ EKS อยู่ วิธีการง่ายๆ ก็คือ การสั่ง update kube config ครับ ดังตัวอย่าง ..

aws eks update-kubeconfig --name tono-eks \
--region ap-southeast-1 \
--profile tono-admin

สิ่งที่อยากจะนำเสนอเพิ่มเติม สำหรับเจ้า Lens ก็คือ Lens Metrics ซึ่งตรงนี้ จะทำให้เราดู resource ของ k8s cluster เราได้ง่ายขึ้น สะดวกขึ้นครับ .. จริงๆ แล้ว ก็คือการติดตั้ง Prometheus + Kube State Metrics + node exporter เข้าไป เพื่อเก็บ metrics ต่างๆ จาก k8s cluster เราลงบน Prometheus นั่นเองครับ .. มาดูวิธีการ enable ตรงนี้กันครับ ..

1.คลิกขวาที่ icon ของ k8s cluster ของเรา แล้วเลือก Settings

คลิกขวา ที่ icon k8s cluster แล้วเลือก Settings

2.มาที่ Lens Metrics แล้วทำการ Enable PROMETHEUS, KUBE STATE METRICS, NODE EXPORTER จากนั้นกด Apply

Lens Metrics กด Enable ทั้ง 3 อัน

3.กลับมาที่หน้าหลักของ Lens ไปที่ Workloads > Pods ก็จะเห็นว่า pods ต่างๆ ที่เกี่ยวข้องกับ Lens Metrics ของเราเขียวแล้ว

Pods ที่เกี่ยวกับ Lens Metrics เขียวแล้ว

4.กดไปที่ Cluster หรือ Nods ก็จะเห็น Metrics ต่างๆ แสดงผลแล้วครับ

แสดง Metrics ของ k8s cluster ได้แล้ว

ขั้นตอนต่างๆ ก็ง่ายๆ ประมาณนี้ครับ เราก็จะได้ Lens Metrics ที่เป็น Dashboard & Monitoring สำหรับ ดู รายละเอียดต่างๆ ของ k8s cluster ของเรากันแล้วครับ ..

ในครั้งต่อไป ผมจะมาพูดถึง การทำ Dashboad & Monitoring ของ k8s cluster ที่จะดูได้ละเอียดกว่านี้ ด้วย Grafana ครับ .. รอติดตามตอนต่อไปครับ 🙂

Grafana k8s Dashboard & Monitoring

ออกแบบ DevOps Architecture CI/CD Pipeline ให้เหมาะกับงาน และองค์กร

DevOps Architecture CI/CD Pipeline

สวัสดีครับ .. DevOps 101 ของเรา วันนี้มีโจทย์ มาอันนึงครับ ให้ออกแบบ Architecture, Tech Stack และ CI/CD Pipeline ของ Application ที่มีคนใช้งานจำนวนมาก app นึง ให้กับองค์กร ขนาดใหญ่ ระดับพนักงาน 200,000 คน ++ ..

จริงๆ ในการออกแบบ ไม่มีอะไรถูกอะไรผิดครับ .. หลักการง่ายๆ ก็คือ “Simply the best” .. ทำให้ deploy ง่ายๆ .. รองรับ load สูงๆ ให้ได้ .. มีระบบ Monitoring ที่ดี .. และเหมาะสม กับงานและองค์กร ..

เนื่องจาก ทางองค์กร มี Single Sign-On อยู่แล้ว ซึ่งสามารถใช้งานผ่าน AWS Cognito ได้ .. เราก็เลยสามารถ ใช้งานได้เลย และเอาไปต่อกับ CI/CD Tools ที่จำเป็นของเราได้ ไม่ว่าจะเป็น GitLab, Jenkins, Nexus Repository และอื่นๆ ในอนาคต ..

ในที่นี้ ตัว Application เราเลือกพัฒนาโดยใช้ Next.js เพราะว่า ต้องรองรับ user ที่เข้าใช้งานหลากหลาย ไม่ว่าจะเป็น บน Desktop และ Mobile .. และทางทีม Developer มีความเชี่ยวชาญในส่วนของ Next.js อยู่แล้ว .. ในส่วนของ CI/CD Tools เราเลือกใช้ Jenkins และทำ CI/CD Pipeline เป็น Jenkinsfile (Declarative Pipeline) แบบง่ายๆ stage ตรงไปตรงมา ใครมาอ่าน ก็เข้าใจ .. เพราะว่าอนาคต เราอยากเอา template นี้ ไป reuse ให้ทีมอื่น ในองค์กร เราได้ใช้ตามด้วย ..

ในส่วนของ Artifactory ที่ใช้เก็บ Docker Images และ binary files ต่างๆ เราเลือกใช้ Nexus Repository เป็น private repository ของเรา .. ส่วน SCM (Source Code Management) อันนี้จริงๆ เราคิดว่า เป็นอะไรก็ได้ ไม่ว่าจะ github, gitlab, ecr, bitbucket .. แต่องค์กรเรามี GitLab อยู่แล้ว ก็เลยใช้ตัวนี้ไปเลย .. ส่วนของ static code scan เราเลือกใช้ SonarQube แต่สิ่งที่เราอยากดูจริงๆ ก็เป็นส่วนของ code coverage มากกว่า ..

ในส่วนของ Server ที่เราจะใช้ในการ deploy ตัว Application ของเราขึ้นไป เราเลือกใช้ Amazon EKS (มันคือ k8s cluster บน AWS) เพราะว่าเราไม่ต้องวุ่นวายในการสร้าง k8s cluster ขึ้นมาใช้งานเอง และตัว cost ของ Amazon EKS ก็ไม่ได้แพงกว่า EC2 ธรรมดา เท่าไรนัก ..

ทำไมถึงเลือกใช้ EKS ไม่ใช้ ECS ?

– ผมเองต้องออกตัวไว้ก่อนครับ ว่าความรู้เกี่ยวกับ ECS ของผม แทบจะเป็น 0 .. แต่จากการได้เข้า training กับ AWS ในส่วนของการใช้งาน ECS + DevOps .. ทำให้ผมพอได้รู้บ้างว่า ตัว ECS ทำงานอย่างไร .. เราสามารถ ทำอะไรกับมันได้บ้าง .. ทำให้ผมตัดสินใจได้ทันที ว่างั้นเราไป EKS เถอะ .. เพราะว่า ในการทำ Application ที่รองรับคนใช้งานจำนวนมากนั้น .. การ scale และการ monitoring metrics ต่างๆ ถือว่าเป็นเรื่องสำคัญมาก ซึ่งผมเองคิดว่า EKS ที่เป็น k8s cluster eco system มัน flexible กว่า .. อาจจะเป็นเหตุผลที่เอนเอียงนิดหน่อย จากการที่ผมคุ้นเคยกับ Container Platform ที่เป็น k8s ด้วย .. (k8s, OpenShift)

ในส่วนของ Dashboard & Monitoring Tools ในที่นี้เราเลือกใช้ APM (Application Performance Monitoring) + ELK Stack ในการ monitoring Application ของเรา ที่เป็น Next.js .. ในส่วนของตัว EKS (k8s Cluster) เราเลือกใช้ Lens + Prometheus เป็น manage และ monitoring metrics ต่างๆ .. แต่ตัว Lens เอง มันคือดูแบบ เครื่องใครเครื่องมัน .. อนาคต ถ้าเราอยากทำเป็น dashboard ให้ทั้งทีม ได้ดูผ่านจอ TV LED ร่วมกัน ก็น่าจะเอา Grafana มาทำ dashboard ในส่วนนี้ .. ส่วนตัว Alert Notification เราใช้เป็น webhook ของ MS Teams เพราะว่าทีมเรา และองค์กรเรา ใช้ MS Teams เป็นหลัก ในการทำงานอยู่แล้ว ..

Tech Stack

– Next.js
– GitLab
– Jenkins
– Nexus Repository
– SonarQube
– nginx
– Docker
– Kubernetes (k8s)
– AWS Cognito
– AWS EKS
– Elasticsearch
– Logstash + APM
– Kibana
– Prometheus
– Lens/Grafana
– Microsoft Teams

Jenkins Pipeline Examples

https://github.com/pornpasok/iam-demo-app

สำหรับท่านใด ที่สนใจ ในการออกแบบ Architecture, Tech Stack และ CI/CD Pipeline ก็สามารถ มา comment พูดคุย แลกเปลี่ยน ปรึกษากันได้ตรงนี้นะครับ .. อย่างที่ผมเน้นย้ำตลอด ไม่มีแบบไหนผิด แบบไหนถูก .. แต่แบบไหนที่เหมาะกับเรา นั่นแหละ คือดีที่สุด ครับ .. 🙂