ใช้ Istio จัดการ K8s apps โดยไม่ต้องแตะ Code
ต่อจากบทความที่แล้วเกี่ยวกับ Istio นะครับ (ถ้าใครยังไม่ทราบว่า Istio คืออะไร สามารถอ่านได้จากบทความที่แล้วด้านล่างได้เลยครับ)
ใช้ Istio จัดการ K8s apps โดยไม่ต้องแตะ Code
ต่อจากบทความที่แล้วเกี่ยวกับ Istio นะครับ (ถ้าใครยังไม่ทราบว่า Istio คืออะไร สามารถอ่านได้จากบทความที่แล้วด้านล่างได้เลยครับ)
ว่า เอา Istio มาใช้อย่างไร ในเมื่อเรารู้ข้อดีของมันแล้ว แล้วเราจะต้องทำอย่างไร ในเมือง K8s apps เนี่ย เราก็ Deploy ไปแล้วเรียบร้อย แล้วยิ่งถ้าเรา Deploy K8s ไปที่ Cloud หลายๆ เจ้าด้วยละ แย่ละสิ ทำอย่างไร วันนี้ เรามาดูในหัวข้อนี้กัน
ใครๆ ก็ไป Multicloud
สำหรับ Multicloud ก็ถือว่าเป็นเรื่องที่ถกเถียงกันมาก ว่าทำไม เราต้องใช้ Multicloud คือเป็นการใช้ Public Cloud หลายๆ เจ้าร่วมกัน (IBM Cloud, AWS, Azure, CGP, etc…) หรือแม้กระทั่ง Hybrid Cloud คือการใช้ Public Cloud ควบคู่กับ Private Cloud / On-Prem สาเหตุหลักๆ นั่นก็คือ เป็นการกระจายระบบ app นั่นเอง ไม่ว่าจะสาเหตุด้วยความปลอดภัย ความเสถียร หรือ Availability ของ Cloud Provider ท้ายที่สุดแล้ว ก็เปรียบได้สั้นๆ ยกตัวอย่างให้เห็นภาพคือ สายการบิน เราจะเห็นว่า ไม่ว่า Thai Aiways, Singapore Airline หรือ สายการบินต่างๆ ทั่วโลก มีการใช้ Aircraft ทั้งจาก Airbus และ Boeing
ลองคิดกันเล่นๆ ดูนะครับ ว่าถ้า Bank นึงใช้ระบบที่มาจาก Boeing อย่างเดียว แล้วเผอิญเกิดปัญหาทางด้านเทคนิดอย่าง Boeing 737 Max ซึ่งนั่นหมายความว่าผลกระทบ จะมาอย่างมหาศาล โดยที่ไม่มีตัวทดแทนการใข้งานแทนได้เลย
ในเมื่อองค์กรตัดสินใจย้ายไปที่ Cloud แล้ว ส่วนมากแล้วในโลกของ Enterprise อย่าง Bank, Finance Institutions เนี่ย มักไม่ค่อยมีความประสงค์ที่จะย้ายไปที่ Cloud เจ้าเดียว นั่นเป็นที่มาที่ไปอีกสาเหตุนึง ว่าทำไม Multicloud หรือ Hybrid Cloud เป็นเรื่องที่เราไม่ควรมองข้าม
แล้วความปลอดภัย?
เมื่อนึกจะใช้ Multicloud แล้ว เรื่องความปลอดภัยก็มาเป็นอันดับหนึ่งเลย เพราะว่ามี Cloud หลายๆ เจ้า แล้วเราจะทำอย่างไรให้ apps ของเรา ที่ Deploy ไปที่หลายๆ Cloud Providers เนี่ย คุยกันอย่างปลอดภัย อย่างเช่น คุยกันในระดับ API Access ก็อาจจะใช้ OAuth2 หรือ ป้องกัน man-in-the-middle attacks ด้วย Traffic Encryption แม้กระทั่งการใช้ TLS ในระดับของ Service Access Control
โห แล้วจะจัดการยังงัย หลายๆ Microservices หลายๆ apps หลายๆ Cloud Providers (สำหรับกรณีนี้เราจะพูดถึง K8s apps อย่างเดียวนะครับ)
ก็ใช้ Istio กับ Kubernetes สิ
ปกติแล้ว Orchestration service อย่าง Kubernetes / Apache Mesos ก็ไม่ได้มากกับระบบความปลอดภัยที่ครอบคลุมจักรวาล นั่นคือเหตุผลหลักๆ ที่เราควรจะใช้ Istio ควบคู่ด้วย ในแง่ของ Security ทั้งระบบ
Istio เด่นด้วย Feature หลักคือ Service Mesh ก็จริง แต่เบี้องหลังแล้ว ก็ยังมีการจัดการด้วย TLS, Jason Web Token (JWT) Validation ถ้าเราเอาสองสิ่งนี้มาใช้ความคู่กับ การส่ง-ตรวจจับระยะไกล กับ Policy function เราก็จะสามารถเพิ่มประสิทธิภาพความปลอดภัย ทั้ง Authentication, Authorization และ Access Control ทั้ง end users และ APIs ควบคู่กับ App Identity และ Access Adapter
App Identity and Access Adapter เป็น Open Source Project ที่ช่วยให้การใช้ Istio สามารถความคุม app ในส่วนของ Authentication, Authorization policies ผ่าน network ได้
App Identity และ Adapter Access มีคุณลักษณะ แจกแจงไว้ตามนี้
- Secure APIs และ Web Apps ด้วย Authentication และ Access Control Policies
- สามารถปรับแต่งให้ทำงานกับ OAuth2/OIDC-compiant identity providers (เช่น IBM Cloud App ID)ได้
- ใช้ Adapter ป้องกัน Multicloud workloads โดยไม่ต้องแก้ไข Code
สำหรับ App Identity/Access Adapter เราใช้ติดตั้งลงไปที่ Cluster ที่เราต้องการเพิ่มความปลอดภัยเข้าไป โดยมันจะเข้าไปทำงานเกี่ยวข้องกับ Custom policies เพิ่อความคุม Identity และ Access Management กระจายบน Service Mesh
Custom Access Management Policies ที่เราปรับแต่งเพิ่มเติมด้วย App Identity/Access Adapter จะเชื่อมโดยตรงผ่าน Service ของ K8s และเราสามารถปรับแต่ง endpoints ได้ด้วย จะแสดงให้เห็นตัวอย่างต่อไปนะครับ
อันดับแรก Cloud เจ้าเดียวก่อน กับ App Identity/Access Adapter
เพื่อป้องกันความสับสน เราเริ่มต้นมองภาพจาก Cloud เจ้าเดียวก่อนนะครับ ดังภาพด้านล่าง เราจะเห็นว่า Traffic ขาเข้า จะถูก Monitored ด้วย Access policies และ Authentication ก็จะขั้นกับ Policies ที่เราสร้างไว้เริ่มแรก ส่วน OIDC workflows จะทำงานอัตโนมัติกับ Identity Provider ที่เราปรับค่าไว้แต่แรก ควบคู่กับ Adapter และ Tokens ที่เราใส่เพิ่มเข้าไปใน Header ของ Request นั่นเอง

flow ตัวอย่างสำหรับ Cloud provider เจ้าเดียว
เมื่อเราพอเข้าใจ Concept ของ Security สำหรับ Cloud เจ้าเดียวแล้ว ดังนั้น เราไปที่ Multicloud ต่อกันเลยนะครับ
Multicloud กับ App Identity/Access Adapter
สำหรับ Multicloud แน่นอนว่าเราจะต้องเจออะไรซับซ้อนขึ้นเยอะ ดังภาพด้านล่าง

frorntend / backend ของ apps ที่ run อยู่บน Multicloud
จาก flow ด้านบน เราจะเห็นว่า
- Frontend ซึ่งอยู่บน Cloud Provider 1 ใช้ Public OIDC ในการ Authenticate
- เมื่อยืนยัน Authentication ผ่านแล้ว Request นั้นๆ ก็จะถูกเพิ่ม Tokens เข้าไปที่ Header ของ Request , สำหรับ users ที่ Authenticated ไม่ผ่าน ก็จะถูกตีตกไป
- สำหรับ Cloud Provider ที่ 2, Backend ก็จะตรวจสอบ Tokens จาก Header ของ Request นั้น และ Validation ก็จะทำงานฝั่ง Backend
- Response ก็จะถูกส่งกลับจาก Backend ไปยัง Frontend ที่ run อยู่บน Cloud Provider 1
มาถึงจุดนี้แล้ว เราจะเห็นว่า Multicloud แน่นอนว่าดูซับซ้อนกว่า Cloud เจ้าเดียว แต่ ณ จุดนี้ทุกท่านคงมองเห็นภาพการทำงานคร่าวแล้วนะครับ สำหรับ Multicloud และ เราจะจัดการเพิ่มความปลอดภัยกัน แต่ก่อนอื่น ผมได้เกริ่น App ID ไปก่อนหน้านี้ ดังนั้นเรามาทำความรู้จัก App ID กันซักนิดก่อนนะครับ
App ID คือ?
IBM Cloud App ID (OIDC compliant) ช่วยให้เราสามารถใส่ Authentication และ Authorization เข้าไปที่ applications หรือ APIs ที่เรา deploy ไว้บน IBM Cloud ได้อย่างง่ายดาย (สำหรับ IBM Cloud Service : App ID สามารถใช้งานได้ฟรีบน IBM Cloud นะครับ Register IBM Cloud Account แล้วสามารถทดลองเล่นได้เลย ไม่ต้องใส่หมายเลขบัตรเครดิต) ด้วย Service’s SDK และ APIs เราสามารถสร้าง flow การ login เข้าระบบได้อย่างรวดเร็ว รวมถึงการสร้าง user profiles ด้วย
เอาละ พอเข้าใจภาพรวมทั้งหมดแล้ว ดังนั้นต่อไป เราเริ่มมองหา app ตัวอย่าง กันได้เลย
App ตัวอย่างที่เราจะนำมาใช้
แน่นอนว่า บทความนี้ นำเสนอการเพิ่มประสิทธิภาพความปลอดภัย ดังนั้น เราต้องมี App ตัวอย่าง ตาม link ด้านล่างนี้
ที่เราจะไม่เกริ่นถึง App มากนัก บอกสั้นๆ ได้ว่าเป็น Node.js app แล้วก็ deployed ไปอยู่บน K8s clusters ซึ่งมี Frontend และ มี APIs หลังบ้านที่เราต้องการเเพิ่มความปลอดภัยเข้าไป
ว่ากันด้วย APIs หลังบ้านที่เราจะลงมือทำการทดลอง เราต้องการใส่ Authentication Grant Flow เข้าไป เมื่อส่วนของ Authentication ทำงานแล้ว เราก็จะแสดง Access Token ของ User นั้นๆ ที่หน้า Frontend
App ตัวอย่าง มีการใช้ JWT flow อยู่แล้ว ดังนั้นการ Validate จะตรวจสอบที่ Token Signatures โดยใช้ Public Keys จาก App ID นี่เป็น flow คร่าวๆ ชองสิ่งที่เราจะเริ่มต้นลงมือทำนะครับ ถัดไปมาดูกันว่าเราต้องใช้อะไรบ้าง
สิ่งที่ต้องมี
อันดับแรกเลย เราต้องมี IBM Cloud Account ก่อน Signup แบบ Free / Lite plan นะครับ หรือถ้า ต้องการ Free Credits บน IBM Cloud สามารถทำตามบทความด้านล่างนี้นะครับ หรือ ดูขั้นตอนการสมัคร IBM Cloud ได้จาก https://ibm.biz/createibmcloud
- IBM Cloud App ID Instance
- Kubernetes Cluster (K8s Cluster เปิดให้ใช้งานได้ฟรี 1 เดือน ไม่จำกัด หลังจาก upgrade account เป็นแบบ Pay-As-You-Go หรือ สั้นๆ เมื่อใส่บัตรเครดิตนั่นเอง แต่ไม่ต้องห่วงครับ ไม่โดน Charge แน่นอน K8s Cluster แบบ Free จะถูก Terminate อัตโนมัติหลังจากครบ 1 เดือน)
- Helm
- Istio
- References สำหรับ yaml files ที่ Download ได้จาก Github
- ติดตั้ง Adapter บน K8s Cluster ขั้นตอนการติดตั้งดูได้จาก README
หรือ ข้ามขั้นตอนการติดตั้ง ไปแล้วไปใช้ IBM Cloud Managed Kubernetes Service เพื่อดึง Add-on Istio มาใช้งานกับ Managed K8s Cluster ได้เลย บน IBM Cloud (อ่านเพิ่มเติมเกี่ยวกับ Istio Add-on ได้ที่ Managed Istio On IBM Cloud)
สำหรับขั้นตอนการลงมือทำ ติดตามตอนที่ 2 ได้เลยครับ
และท้ายที่สุดแล้ว แนะนำกลุ่ม IBM Cloud Thailand นะครับ สามารถเข้ามาพูดคุย แลกเปลี่ยนประสบการ์ณกันได้ครับ
메타데이터
- post_id
- d310ce1a2bfd
- slug
- ใช้-istio-จัดการ-k8s-apps-โดยไม่ต้องแตะ-code-d310ce1a2bfd
- url
- https://medium.com/@nutta/%E0%B9%83%E0%B8%8A%E0%B9%89-istio-%E0%B8%88%E0%B8%B1%E0%B8%94%E0%B8%81%E0%B8%B2%E0%B8%A3-k8s-apps-%E0%B9%82%E0%B8%94%E0%B8%A2%E0%B9%84%E0%B8%A1%E0%B9%88%E0%B8%95%E0%B9%89%E0%B8%AD%E0%B8%87%E0%B9%81%E0%B8%95%E0%B8%B0-code-d310ce1a2bfd
- canonical_url
- https://medium.com/@nutta/%E0%B9%83%E0%B8%8A%E0%B9%89-istio-%E0%B8%88%E0%B8%B1%E0%B8%94%E0%B8%81%E0%B8%B2%E0%B8%A3-k8s-apps-%E0%B9%82%E0%B8%94%E0%B8%A2%E0%B9%84%E0%B8%A1%E0%B9%88%E0%B8%95%E0%B9%89%E0%B8%AD%E0%B8%87%E0%B9%81%E0%B8%95%E0%B8%B0-code-d310ce1a2bfd
- author_url
- https://medium.com/@nutta
- status
- ok
- fetched_at
- 2026-08-10 08:44:23