มาทำความรู้จัก Istio กัน
ทุกวันนี้หลายๆ ท่านก็คงได้สัมผัส Kubernetes กันมาบ้างแล้ว ซึ่งช่วยได้มากในปัญหาที่เกี่ยวกับ Microservices แต่ว่า K8s…
มาทำความรู้จัก Istio กัน

ทุกวันนี้หลายๆ ท่านก็คงได้สัมผัส Kubernetes กันมาบ้างแล้ว ซึ่งช่วยได้มากในปัญหาที่เกี่ยวกับ Microservices แต่ว่า K8s ก็ยังมีช่องว่างซึ่งมักจะเห็นชัดเจน ถ้าเราทำเรื่อง Load Test หรือ การทำสอบ Scaling ซึ่ง Istio ที่เป็น Open Source Project หนึ่งที่ ทาง IBM ร่วมกับ Google และ Lyft
เชื่อมต่อ , ปลอดภัย , ควบคุม , สังเกตุ เฝ้ามอง

4 ปัจจัยในการใช้ Istio ก็คือตามรูปภาพด้านบน ซึ่งทำให้เราสามารถนำประโยชน์ของ Istio นี้ไปใช้ควบคู่กับ Kubernetes โดยเพียงแค่เราติดตั้ง Istio บน K8s Clusters โดยการใช้ kubectl เพียง command เดียวเท่านั้น. การใช้ Istio คือการนำ concept ของ sidecar model เข้ามาเกี่ยวข้อง นั่นหมายความว่า ทุกๆ Pod ของ Kubernetes นั้น จะถูกติดตั้งด้วย Envoy container/proxy เพื่อช่วยในการจัดการ Traffic in/out ของ pod ใน K8s clusters. นอกเหนือจากนั้น Istio ติดตั้งอยู่บน top-level component บน Clusters จะช่วยในการจัดการ 3 อย่างด้านล่างนี้
- Service Introspection
- Application management at scale
- Hybrid deployment
Service introspection
Istio มากับหลายๆ tools ให้ developers สามารถใช้งานได้มากมาย กับ containers มาดูกันเลยว่ามีอะไรบ้าง
Metrics Capabilities
หลังจากติดตั้ง Istio ปกติแล้วจะมี Open Source Utilities สองตัวติดมาด้วย สำหรับ เก็บข้อมูล และ แสดงผลข้อมูล Metrics ที่มาจาก applications ใน containers / K8s Clusters ของเรานั่นเอง ตัวแรกเลยก็คือ Prometheus ซึ่งเป็นตัวรวบรวมข้อมูล และ จัดเก็บ Metrics ต่างๆ เอาไว้ ส่วนตัวที่สองก็คือ Grafana ที่หลาย Ops engineer คงจะคุ้นเคย เพราะว่ามันแสดงผลว่า clusters ที่เราใช้อยู่กิน hardware resources ไปเท่าไรซึ่ง Grafana นี้ เป็นที่นิยมแพร่หลาย แม้กระทั่ง OpenShift เองก็มี Grafana integrated ให้เสร็จสรรพ ให้ทาง DevOps ตัดสินใจได้ง่ายว่าจะ Set Auto Scaler อย่างไร ซึ่ง ทั้ง Prometheus และ Grafana นี้ เป็นส่วนหนึ่งที่ได้รับการสนันสนุนจาก Cloud Native Computing Foundation (CNCF)
เมื่อใช้งานร่วมกันทั้ง Prometheus และ Grafana ทำให้ Istio สามารถเก็บข้อมูล และแสดงผล Metrics ต่างๆ จาก Applicaitons ที่ทำงานอยู่บน K8s Clusters ผ่านทาง Istio Dashboard เช่น
- Mesh Summary : ผลสรุปที่เก็บผ่าน HTTP/gRPC และ TCP workload
- Individual Services : Request/Response metrics สำหรับทุกบริการ (Microservices) ที่แยกมาให้ด้วย เป็นแต่ละรายการ
- Individual Workloads แสดงผล workload ทั้งหมดแยกเป็นหมวดหมู่ในหน้าเดียว

Service Graph
Microservices ที่มี Services มากๆ เป็นเรื่องอะไรที่ปัญหาจะเรียกได้ว่ายกกำลังเลยก็ได้ ถ้าต้องการ Scale ลองคิดดูนะครับ เรื่อง Mesh เนี่ย จะสร้างความสับสนให้เยอะเลย สำหรับหลายๆ Services ที่ทำงานขึ้นต่อกัน ดังนั้นการวาดภาพ สร้างเครือข่ายระหว่าง Services หรือที่หลายๆ ท่านเรียกว่า สร้างภาพด้วยเส้นสปาเก็ตตี้ Istio ก็ช่วยในส่วนตรงนี้ สร้างภาพ Service Graph ออกมาให้เราเห็นเลย เริ่มจากไหน ไปไหน และ จบที่ไหน ดังรูปภาพด้านล่าง

Istio Service Graph
อีกหนึ่งทางเลือกจาก Istio Service Graph ก็คือ Kiali ซึ่งมี ผลแสดงบอก เกี่ยวกับ Request Traffic, Success Rate, Latency และ อื่นๆ อีกมากมาย. การแสดงผลออกมาเป็นรูปภาพ หรือ Graph แบบนี้ช่วยให้การทำงาน identify services ชัดเจนขึ้นมาก ยกตัวอย่างเช่น การค้นหาว่า Service ไหน มีปัญหา Bottleneck เราก็จะเห็นได้จาก Service Graph, Traffic Graph อย่างชัดเจน
Application management at scale
สำหรับขั้นตอนการ Scale Microservices เนี่ย เป็นเรื่องที่น่าปวดหัว ถึงแม้ว่าเรามี Docker และ Kubernetes มาช่วยแล้วก็ตาม ดังนั้น Istio สามารถช่วยอะไรได้บ้าง
Traffic Management
ช่วยเรื่องจราจร Istio เนี่ยอนุญาตให้ Developers เข้ามาจัดการ Flow ภายใน Clusters เอ๊ะ เดี๋ยว จัดการการจราจร จัดยังงัย ?
ยกตัวอย่างง่ายๆ เลย Kubernetes เนี่ย ช่วยให้เราสามารถ Deploy app ขึ้นไปบน Clusters ได้ เราสามารถ Deploy stable version ของ application เราได้เร็วขึ้น และ Kubernetes ช่วยจัดการตรงนี้ได้ตามเอกลักษณ์ของมัน แต่ถ้าบางกรณี เราต้องการให้ User บางกลุ่มใช้งาน App ล่าสุด และ User ที่เหลือ ใช้ Version เก่าไปก่อนละ เนี่ยละ เราต้องมีการจัดการจราจร และ การใช้ Istio ทำให้เราจัดการจราจรเนี่ย เป็นเรื่องแสนง่าย
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
...
http:
- route:
- destination:
host: service
subset: v1
weight: 90
- destination:
host: service
subset: v2
weight: 10
เราลองมองตดูตัวอย่างด้านบน เราจะเห็นว่ามี App มีการ deploy ไปแล้ว 2 versions (subset v1 / v2) ถ้าเรามองดูที่ weight หรือ นน. นั่นคือการบ่งบอกว่า 90% ของ user ก็ยังใช้ version 1ไปก่อน ส่วนเพียงแค่ 10% ไปใช้ version 2 โดย Istio จะจัดการจราจรให้ User ไปที่ version 2 จนเต็ม 10% ก่อน และ 90% user ที่มาทีหลังก็จะไปที่ version 1
Fault injection
Fault injection คือการใส่ค่าแปลกๆ เข้าไปที่ app จงใจให้มันเกิด error โดยที่ app ก็ยังคงทำงานได้ต่อไป ไม่สร้างผลกระทบให้กับ Services อื่นๆ ซึ่ง Istio เปิดโอกาสให้เราใช้งาน fault injection ในระดับ Network level สองแบบคือ
- Delays เป็นการตอบ response ช้าไปกว่ากำหนด ในกรณีที่ Services มีผู้เข้าใช้งานมากๆ
- Aborts ยกเลิก ปฏิเสธ เช่น การตอบกลับด้วย response 400/404.
ด้านล่างนี้ เป็นตัวอย่าง การเพิ่ม delay เข้าไป 5 วินาที
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- fault:
delay:
percent: 10
fixedDelay: 5s
route:
- destination:
host: ratings
subset: v1
นอกเหลือจากนั้น features อื่นๆ เยอะแยะ ก็มากับ Istio ดังข้างล่างนี้
- Rate limiting
- Access control
- Canary releases
- Security with mTLS
- Service discovery
Hybrid deployments
หัวใจหลักสำคัญของ Istio ก็คือ การสร้าง Service Mesh ที่ขยายไปครอบคลุม Multiple Clusters อื่นๆ
ตรงนี้อาจจะเข้ายากนิดนึง แต่ยกตัวอย่างง่ายๆ คือ บริษัท ก. อยากจะย้ายบริการ Services ต่างๆ ที่มีอยู่ และ run on-prem ไป Cloud ดังนั้นทำอย่างไร ในเมื่อการย้ายที่ละส่วนไป Cloud สุดท้ายแล้วก็ยังมี Services บางตัวที่ยังต้องขึ้นกับ Server ที่อยู่ run อยู่ใน office อยู่ดี ถ้าเราไม่มี Istio เราจะเห็นว่า การจัดการ traffic, service endpoints เป็นเรื่องที่ค่อนข้างวุ่นวาย
ด้วย คุณสมบัติของ Service Mesh จาก Istio ทำให้ เราสามารถ host application ที่มี Microservices ที่ run อยู่บน local kubernetes และ cluster ที่อยู่บน IBM Cloud Kubernetes Cluster ได้พร้อมๆกัน
Istio ก็ยังช่วยการจัดการ workloads โดยการสร้าง Central Control Plane และกระจายไปทั่ว Hybrid Environment อีกด้วย Istio ก็ยังเข้ามามีบทบาทของ Authentication (อย่าลืมว่า Security สำคัญมาก — DevSecOps) ช่วยให้ทุกๆ Environment ที่เปิดใช้ Istio สามารถพูดคุย เชื่อมต่อกันได้อย่างปลอดภัย เพราะ Service Mesh เปรียบเสมือนตาข่าย ที่ช่วยครอบ services จากหลายๆ hybrid environment พูดคุยกันได้ปลอดภัย ในตาข่ายที่ Istio วางเอาไว้นั่นเอง

ตัวอย่าง hybrid environment ที่เห็นว่า Services พูดคุยกันผ่าน Istio โดยที่ เราไม่ได้ต้องเขียน code เพิ่มเติมส่วนของ authentication ระหว่าง services เลย
ค่อนข้างยืดยาวสำหรับบทความนี้ แต่หวังว่าจะช่วยไขความกระจ่าง Istio ให้กับผู้อ่านนะครับ สำหรับผู้ที่สนใจ สามารถอ่านข้อมูลเพิ่มเติมได้จาก IBM website ด้านล่างนะครับ
และท้ายที่สุดแล้ว แนะนำกลุ่ม IBM Cloud Thailand นะครับ สามารถเข้ามาพูดคุย แลกเปลี่ยนประสบการณ์กันได้ครับ
메타데이터
- post_id
- d194b4bea1dc
- slug
- มาทำความรู้จัก-istio-กัน-d194b4bea1dc
- url
- https://medium.com/@nutta/%E0%B8%A1%E0%B8%B2%E0%B8%97%E0%B8%B3%E0%B8%84%E0%B8%A7%E0%B8%B2%E0%B8%A1%E0%B8%A3%E0%B8%B9%E0%B9%89%E0%B8%88%E0%B8%B1%E0%B8%81-istio-%E0%B8%81%E0%B8%B1%E0%B8%99-d194b4bea1dc
- canonical_url
- https://medium.com/@nutta/%E0%B8%A1%E0%B8%B2%E0%B8%97%E0%B8%B3%E0%B8%84%E0%B8%A7%E0%B8%B2%E0%B8%A1%E0%B8%A3%E0%B8%B9%E0%B9%89%E0%B8%88%E0%B8%B1%E0%B8%81-istio-%E0%B8%81%E0%B8%B1%E0%B8%99-d194b4bea1dc
- author_url
- https://medium.com/@nutta
- status
- ok
- fetched_at
- 2026-08-10 08:44:23