ในที่สุด เราดูองค์ประกอบพื้นฐานของ Service Mesh Istio ทำความคุ้นเคยกับระบบและตอบคำถามหลักที่มักเกิดขึ้นเมื่อเริ่มทำงานกับ Istio ในส่วนนี้เราจะดูวิธีการจัดระเบียบการรวบรวมข้อมูลการติดตามผ่านเครือข่าย
สิ่งแรกที่นักพัฒนาและผู้ดูแลระบบหลายคนนึกถึงเมื่อได้ยินคำว่า Service Mesh กำลังติดตาม แท้จริงแล้ว เราได้เพิ่มพร็อกซีเซิร์ฟเวอร์พิเศษให้กับแต่ละโหนดเครือข่ายที่การรับส่งข้อมูล TCP ทั้งหมดผ่าน ดูเหมือนว่าขณะนี้สามารถส่งข้อมูลเกี่ยวกับการโต้ตอบของเครือข่ายทั้งหมดบนเครือข่ายได้อย่างง่ายดาย น่าเสียดายที่ในความเป็นจริงมีความแตกต่างมากมายที่ต้องนำมาพิจารณา มาดูพวกเขากันดีกว่า
ความเข้าใจผิดข้อที่หนึ่ง: เราสามารถรับข้อมูลการเดินป่าออนไลน์ได้ฟรี
ในความเป็นจริง ที่ค่อนข้างฟรี เราสามารถเชื่อมต่อโหนดของระบบของเราด้วยลูกศรและอัตราข้อมูลที่ส่งผ่านระหว่างบริการต่างๆ เท่านั้น (อันที่จริงมีเพียงจำนวนไบต์ต่อหน่วยเวลาเท่านั้น) อย่างไรก็ตาม ในกรณีส่วนใหญ่ บริการของเราจะสื่อสารผ่านโปรโตคอลชั้นแอปพลิเคชันบางประเภท เช่น HTTP, gRPC, Redis และอื่นๆ และแน่นอนว่า เราต้องการดูข้อมูลการติดตามสำหรับโปรโตคอลเหล่านี้โดยเฉพาะ เราต้องการดูอัตราคำขอ ไม่ใช่อัตราข้อมูล เราต้องการทำความเข้าใจเวลาแฝงของคำขอโดยใช้โปรโตคอลของเรา สุดท้ายนี้ เราต้องการดูเส้นทางแบบเต็มที่คำขอใช้ตั้งแต่การเข้าสู่ระบบของเราไปจนถึงการรับการตอบกลับจากผู้ใช้ ปัญหานี้ไม่ใช่เรื่องง่ายที่จะแก้ไขอีกต่อไป
ก่อนอื่น มาดูกันว่าการส่งช่วงการติดตามจะเป็นอย่างไรจากมุมมองทางสถาปัตยกรรมใน Istio ดังที่เราจำได้จากส่วนแรก Istio มีส่วนประกอบแยกต่างหากที่เรียกว่า Mixer สำหรับรวบรวมการวัดและส่งข้อมูลทางไกล อย่างไรก็ตาม ในเวอร์ชันปัจจุบัน 1.0.* การส่งจะดำเนินการโดยตรงจากพร็อกซีเซิร์ฟเวอร์ กล่าวคือ จากพร็อกซีทูต พร็อกซีทูตรองรับการส่งช่วงการติดตามโดยใช้โปรโตคอล zipkin ทันที คุณสามารถเชื่อมต่อโปรโตคอลอื่นได้ แต่ต้องผ่านปลั๊กอินเท่านั้น ด้วย Istio เราจะได้รับพร็อกซีทูตที่ประกอบและกำหนดค่าทันที ซึ่งรองรับเฉพาะโปรโตคอล zipkin เท่านั้น ตัวอย่างเช่น หากเราต้องการใช้โปรโตคอล Jaeger และส่งช่วงการติดตามผ่าน UDP เราจะต้องสร้างอิมเมจ istio-proxy ของเราเอง มีการรองรับปลั๊กอินแบบกำหนดเองสำหรับ istio-proxy แต่ยังอยู่ในเวอร์ชันอัลฟ่า ดังนั้น หากเราต้องการดำเนินการโดยไม่มีการตั้งค่าแบบกำหนดเองจำนวนมาก ช่วงของเทคโนโลยีที่ใช้สำหรับการจัดเก็บและรับช่วงการติดตามจะลดลง จากระบบหลัก ที่จริงแล้ว ตอนนี้คุณสามารถใช้ Zipkin เองหรือ Jaeger ได้ แต่ส่งทุกอย่างไปที่นั่นโดยใช้โปรโตคอลที่เข้ากันได้กับ zipkin (ซึ่งมีประสิทธิภาพน้อยกว่ามาก) โปรโตคอล zipkin นั้นเกี่ยวข้องกับการส่งข้อมูลการติดตามทั้งหมดไปยังนักสะสมผ่านโปรโตคอล HTTP ซึ่งค่อนข้างแพง
ดังที่ได้กล่าวไปแล้ว เราต้องการติดตามโปรโตคอลระดับแอปพลิเคชัน ซึ่งหมายความว่าพร็อกซีเซิร์ฟเวอร์ที่อยู่ถัดจากแต่ละบริการจะต้องเข้าใจว่าการโต้ตอบประเภทใดที่เกิดขึ้นในขณะนี้ ตามค่าเริ่มต้น Istio จะกำหนดค่าพอร์ตทั้งหมดให้เป็น TCP ธรรมดา ซึ่งหมายความว่าจะไม่มีการส่งการติดตาม หากต้องการส่งการติดตาม ขั้นแรกคุณต้องเปิดใช้งานตัวเลือกนี้ในการกำหนดค่า Mesh หลัก และสิ่งที่สำคัญมากคือตั้งชื่อพอร์ตทั้งหมดของเอนทิตีบริการ kubernetes ตามโปรโตคอลที่ใช้ในบริการ นั่นคือเช่นนี้:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxคุณยังสามารถใช้ชื่อผสม เช่น http-magic (Istio จะเห็น http และรับรู้พอร์ตนั้นเป็นจุดปลาย http) รูปแบบคือ: proto-extra
เพื่อไม่ให้แพตช์การกำหนดค่าจำนวนมากเพื่อกำหนดโปรโตคอล คุณสามารถใช้วิธีแก้ปัญหาที่สกปรกได้: แพตช์ส่วนประกอบนำร่องในขณะที่เป็นเพียง . แน่นอนว่าท้ายที่สุดแล้ว จำเป็นต้องเปลี่ยนตรรกะนี้เป็นมาตรฐานและสลับไปใช้แบบแผนการตั้งชื่อสำหรับพอร์ตทั้งหมด
เพื่อที่จะเข้าใจว่าโปรโตคอลถูกกำหนดไว้อย่างถูกต้องหรือไม่ คุณต้องเข้าไปในคอนเทนเนอร์ไซด์คาร์ใดๆ ที่มีพร็อกซีเอนวอย และส่งคำขอไปยังพอร์ตผู้ดูแลระบบของอินเทอร์เฟซของเอนวอยที่มีตำแหน่ง /config_dump ในการกำหนดค่าผลลัพธ์ คุณต้องดูที่ฟิลด์การทำงานของบริการที่ต้องการ ใช้ใน Istio เป็นตัวระบุสถานที่ที่มีการร้องขอ ในการปรับแต่งค่าของพารามิเตอร์นี้ใน Istio (จากนั้นเราจะเห็นค่านั้นในระบบติดตามของเรา) จำเป็นต้องระบุแฟล็ก serviceCluster ในขั้นตอนของการเปิดใช้งานคอนเทนเนอร์เทียมข้าง ตัวอย่างเช่น สามารถคำนวณได้เช่นนี้จากตัวแปรที่ได้รับจาก kubernetes API ที่อยู่ด้านล่าง:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
ตัวอย่างที่ดีในการทำความเข้าใจว่าการติดตามทำงานอย่างไรในทูต .
จุดปลายทางสำหรับการส่งช่วงการติดตามต้องถูกระบุในแฟล็กการเปิดใช้พร็อกซีทูตด้วย ตัวอย่างเช่น: --zipkinAddress tracing-collector.tracing:9411
ความเข้าใจผิดประการที่สอง: เราสามารถรับการติดตามคำขอที่สมบูรณ์ผ่านระบบได้ทันทีในราคาไม่แพง
น่าเสียดายที่มันไม่ใช่ ความซับซ้อนของการนำไปใช้งานขึ้นอยู่กับว่าคุณได้นำการโต้ตอบของบริการไปใช้อย่างไร ทำไมเป็นเช่นนั้น?
ความจริงก็คือเพื่อให้ istio-proxy สามารถเข้าใจความสอดคล้องของคำขอขาเข้ากับบริการกับผู้ที่ออกจากบริการเดียวกันได้ การสกัดกั้นการรับส่งข้อมูลทั้งหมดนั้นไม่เพียงพอ คุณต้องมีตัวระบุการสื่อสารบางประเภท พร็อกซีทูต HTTP ใช้ส่วนหัวพิเศษ ซึ่งทูตเข้าใจว่าคำขอเฉพาะใดไปยังบริการที่สร้างคำขอเฉพาะไปยังบริการอื่น ๆ รายการส่วนหัวดังกล่าว:
- x-request-id
- x-b3-เทรซิด,
- x-b3-สแปนิด,
- x-b3-พาเรนต์สเปน,
- x-b3-สุ่มตัวอย่าง
- x-b3-แฟล็ก,
- x-ot-span-บริบท
หากคุณมีจุดเดียว เช่น ไคลเอนต์พื้นฐาน ซึ่งคุณสามารถเพิ่มตรรกะดังกล่าวได้ ทุกอย่างก็เรียบร้อยดี คุณเพียงแค่ต้องรอให้ไลบรารีนี้อัปเดตสำหรับไคลเอนต์ทั้งหมด แต่ถ้าคุณมีระบบที่ต่างกันมากและไม่มีการรวมกันเป็นหนึ่งเดียวในการย้ายจากบริการหนึ่งไปยังอีกบริการหนึ่งผ่านเครือข่าย นี่อาจเป็นปัญหาใหญ่ได้ หากไม่มีการเพิ่มตรรกะดังกล่าว ข้อมูลการติดตามทั้งหมดจะเป็น "ระดับเดียว" เท่านั้น นั่นคือเราจะได้รับการโต้ตอบระหว่างบริการทั้งหมด แต่จะไม่ติดอยู่ในห่วงโซ่เดียวผ่านเครือข่าย
ข้อสรุป
Istio มอบเครื่องมือที่สะดวกสำหรับการรวบรวมข้อมูลการติดตามผ่านเครือข่าย แต่คุณต้องเข้าใจว่าในการใช้งาน คุณจะต้องปรับระบบและคำนึงถึงฟีเจอร์ของการใช้งาน Istio เป็นผลให้ต้องแก้ไขประเด็นหลักสองประการ: การกำหนดโปรโตคอลระดับแอปพลิเคชัน (ซึ่งต้องได้รับการสนับสนุนจากพร็อกซีทูต) และการตั้งค่าการส่งต่อข้อมูลเกี่ยวกับการเชื่อมต่อคำขอไปยังบริการจากคำขอจากบริการ (โดยใช้ส่วนหัว ในกรณีของโปรโตคอล HTTP) เมื่อปัญหาเหล่านี้ได้รับการแก้ไข เรามีเครื่องมืออันทรงพลังที่ช่วยให้เราสามารถรวบรวมข้อมูลจากเครือข่ายได้อย่างโปร่งใส แม้ในระบบที่ต่างกันมากซึ่งเขียนด้วยภาษาและกรอบงานที่แตกต่างกันมากมาย
ในบทความถัดไปเกี่ยวกับ Service Mesh เราจะดูหนึ่งในปัญหาที่ใหญ่ที่สุดของ Istio นั่นคือการใช้ RAM จำนวนมากโดยแต่ละคอนเทนเนอร์พร็อกซีไซด์คาร์ และหารือเกี่ยวกับวิธีจัดการกับมัน
ที่มา: will.com