บทเรียนเบื้องต้นจากการทดลองใช้งาน Istio 1.5

มาเริ่มกันเลยครับ Istio เป็นระบบทำ Service Mesh หรือระบบจัดการเครือข่ายสำหรับแอปพลิเคชันแบบไมโครเซอร์วิสที่กำลังได้รับความนิยมสูงมากในปัจจุบัน ซึ่งโครงการนี้เป็นโครงการโอเพนซอร์สที่ร่วมกันโดย Google และพาร์ทเนอร์อย่าง IBM และ Red Hat

ผมเองได้เริ่มมาลองเล่นกับ Istio ก็พอจะได้รับบทเรียนเกี่ยวกับเครื่องมือชิ้นใหม่นี้มาบ้าง เลยอยากจะนำประสบการณ์การใช้งาน Istio เบื้องต้นมาแชร์ให้ฟังเผื่อใครจะมีไอเดียไปลองเล่นกัน

Istio เวอร์ชันที่ผมได้ลองเล่นนี้เป็น Istio 1.5 เดี๋ยวผมจะมาอธิบายเบื้องต้นให้ฟังว่า เวอร์ชันใหม่นี้เปลี่ยนไปจาก Istio เวอร์ชันเก่ามากแค่ไหนกัน

Istio คืออะไร

ก่อนที่จะเริ่มต้นบทเรียนการใช้งาน Istio เราก็ต้องมารู้จักกันก่อนว่า Istio และ Service Mesh คืออะไร?

Service Mesh เป็นศัพท์ที่ใช้เรียกเน็ตเวิร์คของไมโครเซอร์วิส ซึ่งตัวไมโครเซอร์วิสนับได้ว่าเป็นส่วนย่อยๆ ที่จะประสานงานจนเกิดเป็นแอปพลิเคชันหนึ่งขึ้นมา

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

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

ภาพจาก Istio

ตามที่โครงการ Istio ระบุไว้ งานของ Istio จะมีทั้งหมด 4 ประเภทใหญ่ คือ

• Connect เชื่อมต่อและควบคุมการไหลของทราฟฟิกระหว่างเซอร์วิส
• Secure จัดการเรื่องระบบความปลอดภัยของเซอร์วิส เช่น การยืนยันตัวตน การให้สิทธิ์ การเข้ารหัส เป็นต้น
• Control จัดการดูแลและบังคับใช้ Policy ต่างๆ กับเซอร์วิส
• Observe ตรวจสอบว่าเกิดอะไรขึ้นบ้าง ผ่านระบบ Logging, Monitoring และ Tracing

ภาพจาก Istio

Istio ถือกำเนิดขึ้นมาเพื่อให้สามารถมองเห็นการติดต่อระหว่างเซอร์วิส โดยองค์ประกอบหลักของ Istio มีหลายตัวด้วยกัน คือ

• Envoy คือ Proxy ทรงประสิทธิภาพที่พัฒนาขึ้นด้วยภาษา C++ ผู้เริ่มต้นพัฒนาคือ Lyft (บริษัทเรียกรถคู่แข่ง Uber) เป็นโครงการภายใต้ CNCF (องค์กรที่ดูแล Kubernetes) ซึ่ง Istio ก็นำเอา Envoy มาใช้ด้วยการวางเป็นคอนเทนเนอร์ที่ทำงานใน Pod เดียวกันกับ Workload ในศัพท์ Istio จะเรียกคอนเทนเนอร์นี้ว่า Sidecar ซึ่ง Sidecar นี้จะคอยทำงานควบคุมทราฟฟิกใน Service Mesh ตาม Policy ที่กำหนดมาจากส่วนกลางของ Istio
• Ingress Gateway และ Egress Gateway เป็น Envoy ที่ถูกเซ็ทไว้ควบคุมทราฟฟิกที่จะวิ่งเข้าและออกจาก Istio สามารถเซ็ทให้ทำ TLS Termination หรือ TLS Origination ได้
• Pilot กำหนด Service Discovery ให้ตัว Sidecar คือถ้าเกิดสร้างเซอร์วิสใหม่หรือกำหนด Policy ใดๆ ขึ้นมา ตัว Pilot จะมีหน้าที่ไปจัดการ Sidecar ให้รู้จักกับเซอร์วิสใหม่และนำ Policy เหล่านั้นไปใช้งาน
• Citadel ระบบจัดการ Identity และ Credential ภายใน Istio หน้าที่หลักคือดูแลระบบยืนยันตัวตนระหว่างเซอร์วิส หรือเซอร์วิสกับ End-user
• Galley เป็นระบบที่จะคอยตรวจสอบ ใส่ และจัดการให้ส่วนต่างๆ ของ Istio ตามคอนฟิกที่ผู้ใช้สร้างขึ้นมา
• Mixer จัดการ Access Control Policy และรวบรวมข้อมูลจาก Envoy แต่ละตัว พร้อมรองรับการเสริมด้วย Adapter อีกหลายตัว

ภาพจาก Istio

เมื่อก่อนส่วนประกอบทั้งหมดนี้จะอยู่แยกกัน แต่เมื่อ Istio เกิดเป็นเวอร์ชัน 1.5 ขึ้นมา ทางโครงการก็ได้รวบ Pilot, Citadel และ Galley เข้าด้วยกันเป็นไบนารีตัวเดียวชื่อว่า istiod โดยให้เหตุผลว่าจะช่วยลดเวลาในการสตาร์ท เนื่องจากส่วนต่างๆ ไม่ต้องรอกัน สามารถสตาร์ทได้เลย ลดความซับซ้อน และการอัพเกรดเวอร์ชันก็ง่ายขึ้น

ส่วน Mixer จะถอดออกตั้งแต่เวอร์ชัน 1.5 เนื่องจาก Istio เริ่มนำระบบการเขียนส่วนขยายแบบใหม่ที่ใช้ WebAssembly อินทิเกรตเข้ากับ Envoy ได้โดยตรง ให้ประสิทธิภาพโดยรวมดีกว่าการใช้ Adapter ต่อเข้ากับ Mixer มาใช้แทน ทำให้ Istio ไม่จำเป็นต้องมี Mixer ที่เป็นตัวลงแยกอีกต่อไป ตอนนี้ Mixer จึงอยู่ในสถานะตัวเลือกเสริมสำหรับผู้จำเป็นต้องใช้ Adapter เก่า ไม่ได้ติดตั้งมากับแพคเกจหลักของ Istio แล้ว เท่ากับว่าใครเคยใช้ Istio มาก่อนหน้าเวอร์ชัน 1.5 ต้องปรับตัวกันใหม่เยอะเลยทีเดียว อ่านรายละเอียดการเปลี่ยนแปลงของ Istio 1.5 ได้ที่ Announcing Istio 1.5

แม้ว่าจะออกแบบมาเป็นไมโครเซอร์วิส เอาเข้าจริงแล้วตอนติดตั้งและอัพเกรด Istio ผู้ใช้ส่วนใหญ่ก็จะทำทั้ง Stack ถือเป็นกรณีศึกษาที่น่าสนใจสำหรับไมโครเซอร์วิส ว่าถ้าไม่ได้ติดตั้งและทำงานแยกกันได้จริงๆ แยกกันไปก็มีแต่จะสร้างความซับซ้อนโดยไม่จำเป็น ดังที่อธิบายไปแล้วด้านบน

Istio จะนิยมใช้งานกันมากบน Kubernetes แต่ก็นำไปใช้กับ VM ได้เช่นกัน และช่วงหลังๆ Istio ก็ถูกนำไปต่อยอดเพื่อใช้งานกับระบบอื่นด้วย อย่างเช่น Knative ระบบ Deploy แบบ Serverless เป็นต้น แต่ยังครับ…ยังไม่จบครับ เพราะที่ว่ามาด้านบนคือส่วนประกอบหลัก แต่เพื่อสนับสนุนการทำงานของ Istio ผมจึงติดตั้งอุปกรณ์เหล่านี้เพิ่มเติมด้วย ได้แก่

• Grafana สำหรับทำ Dashboard เพื่อดูรายละเอียดของ Istio เช่น ปริมาณ Request ที่วิ่งผ่านแอปพลิเคชันหนึ่งๆ
• Prometheus สำหรับเก็บเมตริกต่างๆ ของ Istio ปัจจุบันเป็นโครงการหนึ่งภายใต้ CNCF
• Kiali สำหรับวาดกราฟเพื่อแสดงภาพกว้างๆ และจัดการคอนฟิกส่วนต่างๆ ของ Istio
• Jaeger ระบบ Tracing ที่เริ่มต้นพัฒนาโดย Uber ปัจจุบันอยู่ภายใต้ CNCF ตัว Jaeger จะทำให้เห็นข้อมูลที่วิ่งไปวิ่งมาในแต่ละ Request บน Istio ซึ่งถ้าเป็นทราฟฟิก HTTP จะแสดงให้เราเห็นด้วยว่า Request/Response เป็นอย่างไร รวมถึงวาดเป็นแผนภาพมาให้ดูได้ง่ายๆ

เนื่องจาก Istio เป็นโครงการโอเพนซอร์ส จึงมีวิธีติดตั้งให้เลือกหลายแบบ และเลือกติดตั้งส่วนต่างๆ ได้ตามที่ต้องการ รวมถึง Cloud บางเจ้าก็อาจจะมี Managed Istio ที่ติดตั้ง Istio ให้โดยที่เราแทบไม่ต้องทำอะไรเลย ดังนั้นส่วนประกอบของ Istio ที่แต่ละคนติดตั้งก็อาจจะแตกต่างกันไปบ้าง

เริ่มต้นใช้งาน Istio

แนวคิดของ Istio อย่างที่อธิบายไปแล้ว คือเราจะใช้ Envoy ไปแปะเป็นคอนเทนเนอร์ที่ทำงานควบคู่กับคอนเทนเนอร์หลักหรือที่เรียกว่า Sidecar ดังนั้นทราฟฟิกที่จะวิ่งทุกอย่างจะต้องผ่าน Envoy เพื่อให้เราสามารถเก็บเมตริก เลือกเส้นทางที่ใช้วิ่ง จัดการเรื่อง TLS และติดตามข้อมูลต่างๆ ของระบบให้ได้ ส่วนตัวแอปเองไม่ต้องทำหน้าที่เหล่านี้เลย

ภาพจาก Istio

ภาพข้างต้นเป็นภาพคร่าวๆ ของทราฟฟิกบน Istio จะเห็นว่า Istio มีหน้าที่คุมทราฟฟิกแบบ End-to-End ภายใน Mesh Boundary ซึ่ง Istio แนะนำให้คุมทราฟฟิกเข้าสู่ Mesh ทาง Ingress Gateway ส่วนทางออกจะเป็นทาง Egress Gateway หรือจะวิ่งตรงก็ได้

การสั่งคอนฟิก Istio จะใช้ Resource บน Kubernetes ที่เป็น Custom Resource Definition (CRD) ของ Istio เอง หลักๆ ได้แก่

• Virtual Service กำหนดว่า Request จะ Route ไปยังปลายทางอย่างไร ตามค่าต่างๆ เช่น Header, Host เป็นต้น
• Destination Rule กำหนดว่า Request จะเกิดอะไรขึ้นเมื่อ Route ไปยังปลายทาง เช่น TLS, Load Balance, Circuit Breaker และอื่นๆ
• Gateway จัดการทราฟฟิกที่วิ่งเข้าและออก Istio เช่น กำหนด TLS และให้ Virtual Service มาเชื่อมเข้ากับ Gateway เพื่อกำหนดทางเส้นทางในการ Route
• Service Entry กำหนดเซอร์วิสไว้ใน Registry เพื่อให้ Envoy มองเห็นและส่งทราฟฟิกได้ราวกับว่าเซอร์วิสนั้นอยู่ใน Mesh เดียวกัน

ทั้งหมดนี้คือเบื้องต้นของ Istio ซึ่งจริงๆ แล้วยังมีอีกหลายส่วน แต่เราเพิ่งลองเล่นอยู่ก็จะเริ่มต้นที่ส่วนประกอบพื้นฐานก่อน ถ้าใครยังมองภาพไม่ออกว่าจะเซ็ทอย่างไร Istio ก็เตรียมของเล่นไว้ให้แล้ว คือ Bookinfo Application ที่จะเป็นคอนเซ็ปต์ของแอปแบบไมโครเซอร์วิสเบื้องต้นให้เราเล่นกันได้ง่ายๆ

รายละเอียดพร้อมวิธีติดตั้ง Bookinfo ไปอ่านได้ที่เว็บไซต์ Istio ถ้าติดตั้งจนเสร็จแล้ว ลองเรียกหน้า Bookinfo ก็จะเห็นแอปพลิเคชันหน้าตาประมาณนี้

หน้านี้คือหน้าจำลองระบบรีวิวหนังสือ เราจะมีไมโครเซอร์วิสหลายเวอร์ชันภายใต้ระบบนี้ ดังนั้นถ้ากดโหลดหน้าเว็บเพจก็อาจจะเห็นหน้าตาเว็บไซต์ที่ต่างออกไปบ้าง แสดงว่า Istio มีการ Load Balance ระหว่างเซอร์วิส

ในตัว Bookinfo เป็นแอปที่มีอุปกรณ์เบื้องต้นมาให้ค่อนข้างครบ หากอยากจะลองเล่นอะไรเพิ่มเติม เช่น ใส่ Fault Injection, Circuit Breaker ก็สามารถทำได้เช่นกันเราจะ Generate Load ให้ตัว Istio ด้วยการกด F5 เพื่อรีเฟรชหน้ารัวๆ กดจนกว่าจะพอใจ

เมื่อกด F5 เพื่อ Generate Load สักระยะ เปิดหน้า Kiali ขึ้นมาก็จะเห็นว่า Istio วาดกราฟให้เราเรียบร้อยแล้ว สามารถปรับแต่งการแสดงโหนด และสั่งให้วาดเป็นแอนิเมชันราวกับว่ามีทราฟฟิกกำลังวิ่งอยู่จริงๆ ก็ได้

ตรงส่วน Kiali นี้ เราจะเห็นภาพกว้างๆ ของทราฟฟิกที่วิ่งอยู่ใน Service Mesh ว่ามีส่วนไหนเรียกถึงส่วนไหนบ้าง แต่ละส่วนติดต่อกันด้วย Protocol ใด ถ้าเป็น HTTP เราจะเห็นไปถึงขั้นว่าตอบ Response Code อะไรกลับมา

ถัดมา ก็จะเป็น Jaeger ระบบ Tracing ที่จะคอยตรวจจับแต่ละ Request แสดงเป็นข้อมูลให้เราเห็นแบบชัดๆ ว่า Request เรียกจากไหนไปไหน ระยะเวลาตั้งแต่ Request จนถึง Response เป็นเท่าไร มีการตอบ Response Code เป็นอะไร และมีรายละเอียดชัดๆ เพื่อนำไปสืบหาปัญหาต่อไป

ตัว Jaeger ค่าเริ่มต้นจะเป็นการเก็บข้อมูลในเมมโมรีของตัวเอง แต่ถ้าต้องการเก็บข้อมูลที่อื่นก็สามารถเซ็ทอัพได้ โดยตอนนี้ Jaeger จะรองรับ Cassandra, Elasticsearch และ Kafka

เมื่อเปิดไปที่ Grafana เราก็จะเห็นเมตริกต่างๆ ที่เกี่ยวกับตัวเซอร์วิส ว่าตอนนี้เซอร์วิสบน Istio เป็นอย่างไรบ้าง เป็นเทรนด์ในรูปแบบกราฟที่ทำให้เราเห็นภาพรวมของเซอร์วิสชัดเจนขึ้น

โดยรวมแล้ว Bookinfo เป็นแอปพลิเคชันตัวอย่างของ Istio ที่ให้ความรู้ความเข้าใจในการทำงานของ Istio กับรูปแบบของไมโครเซอร์วิสจริงๆ ได้ชัดเจนมาก ซึ่งผมแนะนำให้ผู้ที่สนใจเรียนรู้ Istio เริ่มเล่นแอปพลิเคชันนี้ก่อนที่จะทดลองกับระบบจริงที่อาจจะซับซ้อนกว่า

ไม่ใช่ทุกคนที่เหมาะกับ Istio

เมื่อลองเล่นสักพักหนึ่ง จะพบว่า Istio สามารถช่วยให้การจัดการ Service Mesh บน Kubernetes ง่ายขึ้นจริงๆ แต่ก็ตั้งอยู่บนเงื่อนไขว่าเซอร์วิสบน Kubernetes จะต้องซับซ้อนเพียงพอที่จะใช้ Istio ด้วย

เหตุผลที่ต้องระบุแบบนี้เนื่องจากว่า Istio เปรียบเสมือนอีกเลเยอร์หนึ่ง ทำให้เน็ตเวิร์คต้องมี Hop เพิ่มขึ้นซึ่งก็คือ Sidecar แถมยังต้องดีพลอยและดูแล Istio เพิ่มเติมจากที่ดูแลแอปพลิเคชันอีก (เพราะถ้า ​Istio ร่วงก็เป็นไปได้ว่าระบบอาจจะทำงานผิดพลาด)

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

สุดท้ายนี้ การจะเลือกใช้ Istio หรือไม่ คงต้องลองพิจารณาจากลักษณะการใช้งานว่าภาระที่จะรับเข้ามาเพิ่มคือ Istio จะช่วยให้จัดการ Service Mesh ง่ายขึ้นจริงหรือไม่ เมื่อเทียบกับจัดการสิ่งเหล่านี้จากในแอปพลิเคชันโดยตรง และมากพอที่จะรับภาระในการดูแล Istio เพิ่มขึ้นรึเปล่าครับ

สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech