การเปรียบเทียบตาข่ายบริการ Kubernetes

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

อันที่จริง สถาปัตยกรรมไมโครเซอร์วิสและ Kubernetes (ซึ่งมักจะถูกเรียกว่า "K8") ได้กลายเป็นบรรทัดฐานสำหรับแอปที่ปรับขนาดได้อย่างรวดเร็ว ทำให้ปัญหาในการจัดการการสื่อสารระหว่างบริการกลายเป็นประเด็นร้อน และบริการเมชเป็นโซลูชันที่น่าสนใจ ตัวฉันเองเคยใช้บริการ Meshes ในการผลิต โดยเฉพาะ Linkerd, Istio และ Ambassador เวอร์ชันก่อนหน้า แต่ตาข่ายบริการทำอะไรกันแน่? อันไหนดีกว่าที่จะใช้? คุณรู้ได้อย่างไรว่าคุณควรใช้อย่างใดอย่างหนึ่งหรือไม่?

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

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

เพื่อให้สามารถสื่อสารระหว่างบริการได้ บริษัทเหล่านี้ได้พัฒนาห้องสมุดภายใน: Finagle ที่ Twitter, Hystrix ที่ Netflix และ Stubby ที่ Google (ซึ่งต่อมาได้กลายเป็น gRPC ในปี 2016) ไลบรารีเหล่านี้มีจุดมุ่งหมายเพื่อแก้ไขปัญหาที่เกิดจากสถาปัตยกรรมไมโครเซอร์วิส ได้แก่ ความปลอดภัยระหว่างบริการ เวลาแฝง การตรวจสอบ และการจัดสรรภาระงาน แต่การจัดการไลบรารีขนาดใหญ่เป็นการพึ่งพาอาศัยกันในหลายภาษานั้นซับซ้อนและใช้เวลานาน

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

ตาข่ายบริการคืออะไร?

โครงข่ายบริการเป็นเลเยอร์โครงสร้างพื้นฐานซอฟต์แวร์สำหรับควบคุมการสื่อสารระหว่างบริการ โดยทั่วไปประกอบด้วยสององค์ประกอบ:

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

เครือข่ายบริการมีเป้าหมายหลักสามประการเกี่ยวกับการสื่อสารระหว่างบริการ:

1. การเชื่อมต่อ
2. ความปลอดภัย
3. การสังเกต

การเชื่อมต่อ

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

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

สุดท้าย โครงข่ายบริการเสนอ การควบคุมการกำหนดเส้นทาง ในรูปแบบของการเปลี่ยนการจราจรและการมิเรอร์

ความปลอดภัย

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

นอกเหนือจากการปกป้องความเป็นส่วนตัวของข้อมูลลูกค้าซึ่งไม่มีการควบคุมฮาร์ดแวร์โดยตรงแล้ว การเข้ารหัสการรับส่งข้อมูลภายใน ยังเพิ่มชั้นการต้อนรับที่มีความซับซ้อนเป็นพิเศษในกรณีที่เกิดการละเมิดระบบ ดังนั้น บริการเมชทั้งหมดจึงใช้การเข้ารหัส TLS ร่วมกัน (mTLS) สำหรับการสื่อสารระหว่างบริการ กล่าวคือ การสื่อสารระหว่างพร็อกซีทั้งหมด

เมชบริการยังสามารถบังคับใช้ เมทริกซ์ที่ซับซ้อนของนโยบายการ อนุญาต อนุญาตหรือปฏิเสธการรับส่งข้อมูลตามนโยบายที่กำหนดเป้าหมายสภาพแวดล้อมและบริการเฉพาะ

การสังเกต

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

โดยปกติจะได้รับการสนับสนุนโดยเครื่องมือหรือปลั๊กอินของบริษัทอื่น เช่น Jaeger หรือ Zipkin การควบคุมดังกล่าวยังอนุญาตให้มีการติดตามโดยการ ฉีดส่วนหัวของการติดตาม HTTP

ประโยชน์ของตาข่ายบริการ

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

โดยเฉพาะอย่างยิ่ง ความสามารถในการสังเกตของ Service Mesh ช่วยให้สามารถแก้ไขจุดบกพร่องและปรับให้เหมาะสมได้หลากหลายวิธี ด้วยการมองเห็นที่ละเอียดและสมบูรณ์ในการแลกเปลี่ยนระหว่างบริการ วิศวกร—โดยเฉพาะอย่างยิ่ง SRE—สามารถ แก้ไข จุดบกพร่องที่อาจเกิดขึ้นและการกำหนดค่าระบบผิดพลาดได้รวดเร็วยิ่งขึ้น ด้วยการติดตามตาข่ายบริการ พวกเขาสามารถติดตามคำขอจากการเข้าสู่ระบบ (ที่โหลดบาลานเซอร์หรือพร็อกซีภายนอก) ไปจนถึงบริการส่วนตัวภายในสแต็ก พวกเขาสามารถใช้การบันทึกเพื่อแมปคำขอและบันทึกเวลาแฝงที่พบในแต่ละบริการ ผลลัพธ์สุดท้าย: ข้อมูลเชิงลึกโดยละเอียดเกี่ยวกับประสิทธิภาพของระบบ

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

1. เปลี่ยนเส้นทาง คำขอเล็กน้อย
2. ยิ่งไปกว่านั้น ให้ จำลอง คำขอการผลิตไปยังเวอร์ชันใหม่เพื่อทดสอบพฤติกรรมกับการรับส่งข้อมูลแบบเรียลไทม์
3. การทดสอบ A/B ของบริการใดๆ หรือการรวมกันของบริการ

เครือข่ายการบริการทำให้สถานการณ์ข้างต้นทั้งหมดคล่องตัวขึ้น ทำให้ง่ายต่อการหลีกเลี่ยงและ/หรือลดความประหลาดใจใดๆ ในการผลิต

การเปรียบเทียบตาข่ายบริการ Kubernetes

ในหลาย ๆ ด้าน service meshes เป็นชุดเครื่องมือที่ดีที่สุดสำหรับสถาปัตยกรรมไมโครเซอร์วิส หลายตัวทำงานบน Kubernetes หนึ่งในเครื่องมือจัดการคอนเทนเนอร์ชั้นนำ วันนี้เราเลือกเครือข่ายบริการหลักสามเครือข่ายที่ทำงานบน Kubernetes: Linkerd (v2), Istio และ Consul Connect เราจะหารือเกี่ยวกับบริการอื่นๆ เช่น Kuma, Traefik Mesh และ AWS App Mesh แม้ว่าจะไม่ค่อยโดดเด่นในแง่ของการใช้งานและชุมชน แต่ก็มีแนวโน้มมากพอที่จะทบทวนที่นี่และติดตามดูโดยทั่วไป

หมายเหตุสั้น ๆ เกี่ยวกับ Sidecar Proxies

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

มีข้อดีหลักสองประการสำหรับแนวทาง sidecar ในการให้บริการ mesh:

• พร็อกซี Sidecar เป็นอิสระจากรันไทม์และแม้แต่ภาษาการเขียนโปรแกรมของแอปพลิเคชัน
  • ซึ่งหมายความว่าง่ายต่อการเปิดใช้งานคุณสมบัติทั้งหมดของ Service Mesh ทุกที่ที่มีการใช้งาน ทั่วทั้งสแต็ก
• ไซด์คาร์มีสิทธิ์และเข้าถึงทรัพยากรในระดับเดียวกับแอปพลิเคชัน
  • ไซด์คาร์สามารถช่วยตรวจสอบทรัพยากรที่ใช้โดยแอปพลิเคชันหลัก โดยไม่จำเป็นต้องรวมการตรวจสอบเข้ากับฐานโค้ดของแอปพลิเคชันหลัก

แต่รถเทียมข้างเคียงเป็นพรที่หลากหลายเนื่องจากผลกระทบโดยตรงต่อแอปพลิเคชัน:

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

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

Linkerd รีวิว

Linkerd ซึ่งเปิดตัวในปี 2560 เป็นเครือข่ายบริการที่เก่าแก่ที่สุดในตลาด สร้างโดย Buoyant (บริษัทที่ก่อตั้งโดยอดีตวิศวกร Twitter สองคน) Linkerd v1 ใช้ Finagle และ Netty

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

ด้วยเหตุนี้ บัวยันต์จึงมีโอกาสทำงานกับรูปแบบการผลิตที่สมบูรณ์ ได้รับประสบการณ์จากมัน และใช้ปัญญานั้น ผลลัพธ์ที่ได้คือ Conduit ซึ่งเป็น Linkerd ฉบับสมบูรณ์ของบริษัทที่เผยแพร่ในปี 2018 และเปลี่ยนชื่อเป็น Linkerd v2 ในปีนั้น Linkerd v2 มาพร้อมกับการปรับปรุงที่น่าสนใจหลายประการ เนื่องจากการพัฒนา Linkerd v1 ของ Buoyant ได้หยุดลงนานแล้ว การกล่าวถึง “Linkerd” ของเราตลอดส่วนที่เหลือของบทความนี้จึงอ้างอิงถึง v2

Linkerd เป็นโอเพ่นซอร์สอย่างสมบูรณ์ ใช้พร็อกซีแบบโฮมเมดที่เขียนใน Rust สำหรับระนาบข้อมูลและบนซอร์สโค้ดที่เขียนใน Go สำหรับระนาบควบคุม

การเชื่อมต่อ

พร็อกซีของ Linkerd มีคุณสมบัติการลองใหม่และการหมดเวลา แต่ไม่มีการตัดวงจรหรือการฉีดล่าช้าในขณะที่เขียนนี้ การสนับสนุน Ingress นั้นกว้างขวาง Linkerd ภูมิใจนำเสนอการทำงานร่วมกับตัวควบคุมทางเข้าต่อไปนี้:

• Traefik
• Nginx
• GCE
• เอกอัครราชทูต
• Gloo
• คอนทัวร์
• ก้อง

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

ความปลอดภัย

การรองรับ mTLS ใน Linkerd นั้นสะดวกเพราะการตั้งค่าเริ่มต้นเป็นแบบอัตโนมัติ เช่นเดียวกับการหมุนปุ่มรายวันอัตโนมัติ

การสังเกต

นอกกรอบ สถิติและเส้นทางของ Linkerd สามารถสังเกตได้ผ่าน CLI ในด้าน GUI ตัวเลือกรวมถึงแดชบอร์ด Grafana ที่สร้างไว้ล่วงหน้าและแดชบอร์ด Linkerd ดั้งเดิม

Linkerd สามารถเสียบเข้ากับ Prometheus ได้

การติดตามสามารถเปิดใช้งานได้ผ่านทางส่วนเสริมที่มี OpenTelemetry (เดิมคือ OpenCensus) เป็นตัวรวบรวม และ Jaeger จะทำการติดตามเอง

การติดตั้ง

การติดตั้ง Linkerd ทำได้โดยการฉีด sidecar proxy ซึ่งทำได้โดยการเพิ่มคำอธิบายประกอบให้กับทรัพยากรของคุณใน Kubernetes มีสองวิธีในการดำเนินการนี้:

1. การใช้แผนภูมิ Helm (สำหรับหลายๆ คน Helm คือเครื่องมือจัดการการกำหนดค่าและเทมเพลตแบบ go-to สำหรับทรัพยากร Kubernetes)
2. การติดตั้ง Linkerd CLI จากนั้นใช้สิ่งนั้นเพื่อติดตั้ง Linkerd ลงในคลัสเตอร์

วิธีที่สองเริ่มต้นด้วยการดาวน์โหลดและเรียกใช้สคริปต์การติดตั้ง:

 curl -sL https://run.linkerd.io/install | sh

จากที่นั่น เครื่องมือ Linkerd CLI linkerd จัดเตรียมชุดเครื่องมือที่มีประโยชน์ซึ่งช่วยติดตั้งส่วนที่เหลือของ Linkerd และโต้ตอบกับคลัสเตอร์แอปและส่วนควบคุม

linkerd check --pre จะเรียกใช้การตรวจสอบเบื้องต้นทั้งหมดที่จำเป็นสำหรับการติดตั้ง Linkerd ของคุณ โดยให้บันทึกที่ชัดเจนและแม่นยำว่าเหตุใดการติดตั้ง Linkerd ที่เป็นไปได้จึงอาจยังไม่ทำงาน หากไม่มี --pre คำสั่งนี้สามารถใช้สำหรับการดีบักหลังการติดตั้ง

ขั้นตอนต่อไปคือการติดตั้ง Linkerd ในคลัสเตอร์โดยการรัน:

 linkerd install | kubectl apply -f -

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

• linkerd-controller ซึ่งจัดเตรียม API สาธารณะที่ CLI และแดชบอร์ดโต้ตอบ
• linkerd-identity ซึ่งให้ผู้ออกใบรับรองเพื่อใช้งาน mTLS
• linkerd-proxy-injector ซึ่งจัดการการฉีดพร็อกซีโดยเปลี่ยนการกำหนดค่าของพ็อด
• linkerd-web ซึ่งทำหน้าที่แดชบอร์ดที่ช่วยให้สามารถตรวจสอบการปรับใช้และพ็อดตลอดจนส่วนประกอบ Linkerd ภายใน

Linkerd ใช้การกำหนดค่าส่วนใหญ่บน CustomResourceDefinitions (CRD) นี่เป็นแนวทางปฏิบัติที่ดีที่สุดเมื่อพัฒนาซอฟต์แวร์เสริมของ Kubernetes ซึ่งเหมือนกับการติดตั้งปลั๊กอินในคลัสเตอร์ Kubernetes ที่คงทน

การเพิ่มการติดตามแบบกระจาย ซึ่งอาจจะใช่หรือไม่ใช่สิ่งที่ผู้ใช้ Linkerd ตามหา เนื่องจากตำนานทั่วไปบางอย่าง ต้องใช้ขั้นตอนอื่นกับ linkerd-collector และ linkerd-jaeger ก่อนอื่นเราจะสร้างไฟล์กำหนดค่า:

 cat >> config.yaml << EOF tracing: enabled: true EOF

ในการเปิดใช้งานการติดตาม เราจะเรียกใช้:

 linkerd upgrade --config config.yaml | kubectl apply -f -

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

คุณลักษณะการแยกการรับส่งข้อมูลของ Linkerd ซึ่งเปิดเผยผ่าน API ที่สอดคล้องกับ Service Mesh Interface (SMI) ได้อนุญาตให้เผยแพร่ Canary แล้ว แต่เพื่อให้เป็นระบบอัตโนมัติและการจัดการจราจร คุณจะต้องใช้เครื่องมือภายนอกเช่น Flagger

Flagger เป็นเครื่องมือแสดงโฆษณาแบบก้าวหน้าที่จะประเมินสิ่งที่ Linkerd เรียก ว่าเมตริก "ทอง" : "ปริมาณคำขอ อัตราความสำเร็จ และการกระจายเวลาแฝง" (เดิมที Google SRE ใช้คำว่า Golden Signal และรวมเอาความอิ่มตัวของสีที่สี่เข้าไปด้วย แต่ Linkerd ไม่ครอบคลุมเพราะต้องใช้เมตริกที่ไม่สามารถเข้าถึงได้โดยตรง เช่น การใช้ CPU และหน่วยความจำ) Flagger ติดตามสิ่งเหล่านี้ขณะแยกการรับส่งข้อมูล ใช้วงจรป้อนกลับ ดังนั้น คุณจึงใช้ Canary แบบอัตโนมัติและแบบรับรู้เมตริกได้

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

Linkerd Service สรุปตาข่าย

ข้อดี:

Linkerd ได้รับประโยชน์จากประสบการณ์ของผู้สร้าง ซึ่งเป็นอดีตวิศวกร Twitter สองคนที่เคยทำงานเกี่ยวกับเครื่องมือภายใน Finagle และได้เรียนรู้จาก Linkerd v1 ในภายหลัง ในฐานะที่เป็นหนึ่งในเครือข่ายบริการแรก Linkerd มีชุมชนที่เจริญรุ่งเรือง (Slack มีผู้ใช้มากกว่า 5,000 ราย รวมทั้งมีรายชื่อผู้รับจดหมายและเซิร์ฟเวอร์ Discord ที่ใช้งานอยู่) และชุดเอกสารและบทช่วยสอนมากมาย Linkerd เติบโตเต็มที่ด้วยการเปิดตัวเวอร์ชัน 2.9 ซึ่งเห็นได้จากการยอมรับของบริษัทใหญ่ๆ เช่น Nordstrom, eBay, Strava, Expedia และ Subspace การสนับสนุนระดับองค์กรแบบชำระเงินจาก Buoyant มีให้สำหรับ Linkerd

ข้อเสีย:

มีช่วงการเรียนรู้ที่ค่อนข้างแข็งแกร่งในการใช้บริการ Mesh ของ Linkerd อย่างเต็มศักยภาพ รองรับ Linkerd ภายในคอนเทนเนอร์ Kubernetes เท่านั้น (เช่น ไม่มีโหมด "สากล") บน VM พร็อกซี Sidecar ของ Linkerd ไม่ใช่ Envoy แม้ว่าจะอนุญาตให้ Buoyant ปรับแต่งตามที่เห็นสมควร แต่ก็ขจัดความสามารถในการขยายที่มีอยู่โดยธรรมชาติที่ Envoy เสนอให้ นอกจากนี้ยังหมายความว่า Linkerd ขาดการสนับสนุนสำหรับการตัดวงจร การหน่วงเวลาการฉีด และการจำกัดอัตรา ไม่มี API ใดเปิดเผยต่อการควบคุมระนาบการควบคุม Linkerd อย่างง่ายดาย (คุณสามารถค้นหาการเชื่อมโยง gRPC API ได้)

Linkerd มีความก้าวหน้าอย่างมากตั้งแต่ v1 ในด้านการใช้งานและความสะดวกในการติดตั้ง การขาด API ที่เปิดเผยอย่างเป็นทางการถือเป็นการละเลยที่เด่นชัด แต่ต้องขอบคุณเอกสารประกอบที่รอบคอบ ฟังก์ชันที่พร้อมใช้งานใน Linkerd นั้นง่ายต่อการทดสอบ

กงสุล Connect รีวิว

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

เพื่อให้แม่นยำยิ่งขึ้นเกี่ยวกับลักษณะไฮบริด:

ระนาบข้อมูล Consul Connect อิงตาม Envoy ซึ่งเขียนด้วย C++ ระนาบควบคุมของ Consul Connect เขียนเป็น Go นี่คือส่วนที่ได้รับการสนับสนุนจาก Consul KV ที่เก็บคีย์-ค่า

เช่นเดียวกับเครือข่ายบริการอื่น ๆ ส่วนใหญ่ Consul Connect ทำงานโดยการฉีดพร็อกซีไซด์คาร์ลงในพ็อดแอปพลิเคชันของคุณ ในแง่ของสถาปัตยกรรม Consul Connect มีพื้นฐานมาจาก ตัวแทน และ เซิร์ฟเวอร์ Consul Connect มีความพร้อมใช้งานสูง (HA) นอกกรอบ โดยใช้เซิร์ฟเวอร์สามหรือห้าเครื่องเป็น StatefulSet ที่ระบุ pod anti-affinity Pod anti-affinity เป็นแนวทางปฏิบัติเพื่อให้แน่ใจว่าพ็อดของระบบซอฟต์แวร์แบบกระจายจะไม่จบลงที่โหนดเดียวกัน (เซิร์ฟเวอร์) ดังนั้นจึงรับประกันความพร้อมใช้งานในกรณีที่โหนดเดียวล้มเหลว

การเชื่อมต่อ

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

ความปลอดภัย

เช่นเดียวกับตาข่ายบริการอื่นๆ Consul Connect ให้ความสามารถ mTLS พื้นฐาน นอกจากนี้ยังมีการผสานรวมแบบเนทีฟระหว่างกงสุลและห้องนิรภัย (รวมถึงโดย HashiCorp) ซึ่งสามารถใช้เป็นผู้ให้บริการ CA เพื่อจัดการและลงนามใบรับรองในคลัสเตอร์

การสังเกต

Consul Connect ใช้วิธีการสังเกตที่พบบ่อยที่สุดโดยการรวม Envoy เป็น sidecar proxy เพื่อมอบความสามารถเลเยอร์เจ็ด การกำหนดค่า UI ของ Consul Connect เพื่อดึงข้อมูลเมทริกนั้นเกี่ยวข้องกับการเปลี่ยนไฟล์คอนฟิกูเรชันในตัว และยังเปิดใช้งานผู้ให้บริการเมตริก เช่น Prometheus นอกจากนี้ยังสามารถกำหนดค่าแดชบอร์ด Grafana บางตัวเพื่อแสดงตัวชี้วัดเฉพาะบริการที่เกี่ยวข้อง

การติดตั้ง

Consul Connect ได้รับการติดตั้งในคลัสเตอร์ Kubernetes โดยใช้แผนภูมิ Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

คุณจะต้องแก้ไขค่าดีฟอลต์ values.yaml หากคุณต้องการเปิดใช้งาน UI หรือทำให้โมดูล Consul Connect ฉีด sidecar proxy:

 helm install -f consul-values.yml hashicorp hashicorp/consul

หากต้องการปรึกษาสมาชิกและตรวจสอบโหนดต่างๆ exec แนะนำให้ดำเนินการในคอนเทนเนอร์ใดคอนเทนเนอร์หนึ่งจากนั้นใช้เครื่องมือ consul CLI

หากต้องการให้บริการ UI เว็บสำเร็จรูปที่ Consul จัดเตรียมไว้ให้ ให้เรียกใช้ kubectl port-forward service/hashicorp-consul-ui 18500:80

สรุปตาข่ายบริการเชื่อมต่อกงสุล

ข้อดี:

• กงสุลได้รับการสนับสนุนจาก HashiCorp; ในฐานะผลิตภัณฑ์ freemium ยังมีเวอร์ชันสำหรับองค์กรพร้อมคุณสมบัติเพิ่มเติมที่ให้การสนับสนุนระดับองค์กร ในแง่ของประสบการณ์ทีมพัฒนา กงสุลเป็นหนึ่งในเครื่องมือที่เก่าแก่ที่สุดในตลาด
• กงสุลมีชุมชนองค์กรที่แข็งแกร่งและเป็นที่รู้จักในการทำงานบนโครงสร้างพื้นฐานที่มีโหนด 50,000 โหนด นอกจากนี้ยังมีมาตั้งแต่ปี 2014 ทำให้เป็นผลิตภัณฑ์สำหรับผู้ใหญ่เมื่อเทียบกับตลาด
• Consul Connect ทำงานได้ดีใน VM ด้วยการสนับสนุนแบบเนทีฟ
• ด้วย Consul Connect เป็นไปได้ที่จะบรรลุการผนวกรวมแอพให้ลึกที่สุดเท่าที่การใช้งาน pre-service-mesh ที่บริษัทเทคโนโลยีระดับบนสุด นี่เป็นเพราะการเปิดเผยของ API ระดับไลบรารีที่มีเอกสารครบถ้วน

ข้อเสีย:

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

Consul Connect อาจเป็นทางเลือกที่ดีสำหรับผู้ที่แสวงหาผลิตภัณฑ์ระดับองค์กร HashiCorp เป็นที่รู้จักในด้านคุณภาพของผลิตภัณฑ์ และ Consul Connect ก็ไม่มีข้อยกเว้น ฉันเห็นข้อดีที่แข็งแกร่งสองประการที่นี่ เมื่อเทียบกับเมชบริการอื่นๆ: การสนับสนุนที่แข็งแกร่งจากบริษัทด้วยเวอร์ชันสำหรับองค์กรและเครื่องมือที่พร้อมสำหรับสถาปัตยกรรมทุกประเภท (ไม่ใช่แค่ Kubernetes)

Istio รีวิว

ในเดือนพฤษภาคม 2017 Google, IBM และ Lyft ได้ประกาศ Istio เมื่อ Istio เข้าสู่การแข่งขันของ Service Mesh Tools ก็ได้รับความสนใจอย่างมากในด้านเทคโนโลยี ผู้เขียนได้เพิ่มคุณสมบัติตามความคิดเห็นของผู้ใช้จนถึงเวอร์ชัน 1.9

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

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

อย่างไรก็ตาม ระหว่างทาง Istio ได้รับความอื้อฉาวจากการมีปัญหา GitHub แบบเปิดปริมาณมากที่สุด ในการเขียนนี้ การนับมีจำนวนเปิดอยู่ประมาณ 800 ฉบับและปิดประมาณ 12,000 ฉบับ แม้ว่าจำนวนปัญหาจะหลอกลวงได้ ในกรณีนี้ สิ่งเหล่านี้แสดงถึงการปรับปรุงที่มีความหมายในแง่ของคุณลักษณะที่ไม่ทำงานก่อนหน้านี้และการใช้ทรัพยากรที่อยู่นอกการควบคุม

การเชื่อมต่อ

Istio ค่อนข้างแข็งแกร่งในด้านการจัดการจราจรเมื่อเทียบกับ Consul Connect และ Linkerd ต้องขอบคุณคุณสมบัติย่อยที่ครอบคลุม: การกำหนดเส้นทางคำขอ การฉีดข้อผิดพลาด การเปลี่ยนการรับส่งข้อมูล การหมดเวลาของคำขอ การตัดวงจร และการควบคุมการรับส่งข้อมูลขาเข้าและขาออกไปยังตาข่ายบริการ แนวคิดของบริการเสมือนและกฎปลายทางทำให้การจัดการการจราจรมีความสมบูรณ์มาก

อย่างไรก็ตาม ความเป็นไปได้ทั้งหมดนั้นมาพร้อมกับช่วงการเรียนรู้ บวกกับการจัดการทรัพยากรใหม่เหล่านั้นบนคลัสเตอร์ Kubernetes ของคุณ

ความปลอดภัย

Istio มีชุดเครื่องมือที่เกี่ยวข้องกับความปลอดภัยที่ครอบคลุม โดยมีแกนหลัก 2 แบบ ได้แก่ การตรวจสอบสิทธิ์และการอนุญาต Istio สามารถบังคับใช้นโยบายในระดับต่างๆ ในขอบเขตที่ต่างกันได้: เฉพาะภาระงาน, เนมสเปซไวด์ หรือเมชไวด์ ทรัพยากรความปลอดภัยดังกล่าวทั้งหมดได้รับการจัดการผ่าน Istio CRD เช่น AuthorizationPolicy หรือ PeerAuthentication

นอกเหนือจากการรองรับ mTLS มาตรฐานแล้ว Istio ยังสามารถกำหนดค่าให้ยอมรับหรือปฏิเสธการรับส่งข้อมูลที่ไม่ได้เข้ารหัสได้

การสังเกต

ที่นี่ Istio ค่อนข้างล้ำหน้าด้วยการวัดและส่งข้อมูลทางไกลหลายประเภทที่ให้ข้อมูลเชิงลึกที่ชัดเจนเกี่ยวกับตาข่ายบริการ เมตริกอิงจากสัญญาณทองสี่สัญญาณ (เวลาแฝง การรับส่งข้อมูล ข้อผิดพลาด และความอิ่มตัวในระดับหนึ่ง)

โดยเฉพาะอย่างยิ่ง Istio ให้ตัวชี้วัดสำหรับเครื่องบินควบคุมเอง นอกจากนี้ยังให้บริการการติดตามแบบกระจายและบันทึกการเข้าถึง ซึ่งมีความเข้ากันได้กับ Jaeger, Lightstep และ Zipkin อย่างชัดเจนเพื่อเปิดใช้งานการติดตาม

ไม่มีแดชบอร์ดดั้งเดิม แต่มีการสนับสนุนอย่างเป็นทางการสำหรับคอนโซลการจัดการ Kiali

การติดตั้ง

การติดตั้งนั้นตรงไปตรงมาตามขั้นตอนที่เป็นทางการ Istio ยังผสานรวมกับ GKE เป็นคุณลักษณะเบต้า แต่ GKE ใช้ Istio 1.4.X ซึ่งเป็นเวอร์ชันไมโครเซอร์วิสที่เก่ากว่าซึ่งต่างจากเวอร์ชันเสาหินล่าสุด

การติดตั้งแบบเนทีฟเริ่มต้นด้วยการดาวน์โหลดรีลีสล่าสุด:

 curl -L https://istio.io/downloadIstio | sh -

หลังจาก cd ลงในโฟลเดอร์ istio-* ที่สร้างขึ้นใหม่ คุณสามารถเพิ่มไปยังพาธของคุณ เพื่อให้คุณสามารถใช้เครื่องมือยูทิลิตี้ istioctl :

 export PATH=$PWD/bin:$PATH

จากที่นั่น คุณสามารถติดตั้ง Istio ลงในคลัสเตอร์ Kubernetes ผ่าน istioctl :

 istioctl install

การดำเนินการนี้จะติดตั้ง Istio ด้วยโปรไฟล์ default โปรไฟล์ istioctl ช่วยให้คุณสร้างการกำหนดค่าการติดตั้งที่แตกต่างกันและสลับไปมาระหว่างกันได้หากจำเป็น แต่แม้ในสถานการณ์ที่มีโปรไฟล์เดียว คุณสามารถปรับแต่งการติดตั้ง Istio ได้อย่างล้ำลึกโดยแก้ไข CRD บางรายการ

ทรัพยากรของ Istio จะจัดการได้ยากขึ้น เนื่องจากคุณจะต้องจัดการ CRD หลายประเภท เช่น VirtualService , DestinationRule และ Gateway เป็นอย่างน้อย เพื่อให้แน่ใจว่ามีการจัดการการรับส่งข้อมูล

• ทรัพยากร VirtualService คือการกำหนดค่าที่ประกาศบริการและกฎการกำหนดเส้นทางอื่นที่ใช้กับคำขอ
• ทรัพยากร DestinationRule ใช้เพื่อจัดกลุ่มและบังคับใช้นโยบายการรับส่งข้อมูลเฉพาะเป้าหมาย
• ทรัพยากร Gateway ถูกสร้างขึ้นเพื่อจัดการทราฟฟิกเมชของบริการขาเข้าและขาออก (เช่น พร็อกซี Envoy เพิ่มเติม แต่ทำงานที่ Edge แทนที่จะเป็นไซด์คาร์)

รายละเอียดเชิงความหมายอยู่นอกเหนือขอบเขตของบทวิจารณ์นี้ แต่มาดูตัวอย่างสั้นๆ ที่แสดงการทำงานร่วมกันเหล่านี้ สมมติว่าเรามีเว็บไซต์อีคอมเมิร์ซที่มีบริการที่เรียกว่า products VirtualService ของเราอาจมีลักษณะดังนี้:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

DestinationRule ที่เกี่ยวข้องอาจเป็น:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

สุดท้าย Gateway ของเรา:

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

เมื่อติดตั้งทั้งสามไฟล์นี้ การติดตั้ง Istio ก็พร้อมที่จะรองรับการรับส่งข้อมูลพื้นฐาน

สรุปตาข่ายบริการ Istio

ข้อดี:

• ในบรรดาเครือข่ายบริการต่างๆ Istio เป็นชุมชนออนไลน์ที่ใหญ่ที่สุด ณ ตอนนี้ ด้วยผลลัพธ์ของ Stack Overflow มากกว่า 10 เท่าในฐานะคู่แข่งหลักรายใดรายหนึ่งจึงเป็นบริการที่พูดถึงมากที่สุดบนเว็บ ผู้ร่วมให้ข้อมูล GitHub ของมันก็มีความสำคัญเหนือกว่า Linkerd เช่นเดียวกัน
• Istio รองรับทั้งโหมด Kubernetes และ VM; หลังอยู่ในเบต้าตั้งแต่เวอร์ชัน 1.9

ข้อเสีย:

• Istio ไม่ฟรี ในสองความหมาย:
  • ความต้องการสูงในแง่ของเวลาที่จำเป็นในการอ่านเอกสาร ตั้งค่า ทำให้ทำงานได้อย่างถูกต้อง และบำรุงรักษา ขึ้นอยู่กับขนาดโครงสร้างพื้นฐานและจำนวนบริการ Istio จะใช้เวลาหลายสัปดาห์ถึงหลายเดือนในการทำงานเต็มเวลาเพื่อให้ทำงานได้อย่างสมบูรณ์และรวมเข้ากับการผลิต
  • นอกจากนี้ยังเพิ่มค่าใช้จ่ายทรัพยากรจำนวนมาก: จะใช้ 350 มิลลิวินาที (mCPU) สำหรับคอนเทนเนอร์ Envoy ต่อ 1,000 คำขอต่อวินาที (RPS) แม้แต่เครื่องบินควบคุมเองก็สามารถสิ้นเปลืองทรัพยากรได้ (ก่อนหน้านี้ การใช้ทรัพยากรอาจคาดเดาได้ยาก แต่หลังจากพยายามแล้ว istiod ก็เสถียรโดยใช้ 1 vCPU และหน่วยความจำ 1.5 GB)
• ไม่มีแดชบอร์ดผู้ดูแลระบบดั้งเดิมซึ่งแตกต่างจาก Linkerd
• Istio ต้องใช้เกตเวย์ขาเข้าของตัวเอง
• เครื่องบินควบคุม Istio รองรับเฉพาะภายในคอนเทนเนอร์ Kubernetes (เช่น ไม่มีโหมด VM ต่างจากระนาบข้อมูลของ Istio)

Istio เป็นตัวอย่างที่ดีของยักษ์ใหญ่ด้านเทคโนโลยีที่มารวมตัวกันเพื่อสร้างโครงการโอเพนซอร์สเพื่อจัดการกับความท้าทายที่พวกเขาเผชิญอยู่ ต้องใช้เวลาพอสมควรสำหรับโปรเจ็กต์ Istio โดยรวมในการจัดโครงสร้าง (เรียกคืนการเปลี่ยนแปลงทางสถาปัตยกรรมแบบ microservices-to-monolith) และแก้ไขปัญหาเบื้องต้นจำนวนมาก วันนี้ Istio ทำทุกอย่างที่คาดหวังจากเครือข่ายบริการและสามารถขยายได้อย่างมาก แต่ความเป็นไปได้ทั้งหมดเหล่านี้มาพร้อมกับความต้องการที่สูงชันในแง่ของความรู้ ชั่วโมงการทำงาน และทรัพยากรการประมวลผลเพื่อรองรับการใช้งานในสภาพแวดล้อมการผลิต

Kuma Quick Review

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

รายการคุณลักษณะแนะนำว่าเป็นแบบโมดูลาร์มาก แนวคิดเบื้องหลัง Kuma คือการปรับให้เข้ากับแอปพลิเคชันที่ทำงานอยู่บน Kubernetes หรือโครงสร้างพื้นฐานอื่นๆ

• ในส่วนของ การจัดการจราจร Kuma นำเสนอคุณสมบัติทั่วไปของโครงข่ายบริการ เช่น การฉีดข้อผิดพลาดและการตัดวงจร
• นอกเหนือจากการเข้ารหัสระหว่างบริการ mTLS แล้ว การแลกเปลี่ยนระหว่างระนาบข้อมูลและระนาบการควบคุมยังได้รับการรักษาความปลอดภัยใน Kuma ผ่าน โทเค็นพร็อกซีระนาบข้อมูล
• ความสามารถในการ สังเกต ถูกกำหนดใน Kuma ผ่านนโยบายการรับส่งข้อมูลที่แตกต่างกันเกี่ยวกับตัววัด การติดตาม และการบันทึก
• การค้นพบบริการ พร้อมใช้งานผ่าน Kuma ด้วยตัวแก้ไข DNS ของตัวเองที่ทำงานบนพอร์ต 5653 ของระนาบควบคุม
• Kuma ให้ความสำคัญอย่างมากกับ ฟังก์ชันการทำงานแบบมัลติเมช : คุณสามารถรวมคลัสเตอร์ Kubernetes หรือสภาพแวดล้อม VM หลายรายการเข้ากับคลัสเตอร์ Kuma ทั่วไปที่มีประเภทการปรับใช้แบบหลายโซนได้อย่างง่ายดาย
• Kuma ผสานรวมกับ Kong Gateway สำหรับผู้ใช้ Kong ที่มีอยู่ได้อย่างง่ายดาย

Kuma เวอร์ชันสากล (ที่ไม่ใช่ Kubernetes) ต้องการ PostgreSQL เป็นการพึ่งพา และ CTO ของ Kong นั้นโดดเด่นในเรื่องการสนับสนุน SMI แต่คุมะได้รับการพัฒนาด้วยแนวคิดในการปรับใช้มัลติคลาวด์และมัลติคลัสเตอร์ตั้งแต่เริ่มต้น และแดชบอร์ดสะท้อนถึงสิ่งนี้

แม้ว่า Kuma ยังอายุน้อยในด้าน Service Mesh Space แต่มีการใช้งานจริงเพียงไม่กี่กรณีเท่านั้น ถือเป็นคู่แข่งที่น่าสนใจและมีแนวโน้มดี

Traefik Mesh รีวิวด่วน

เดิมชื่อ Maesh, Traefik Mesh (โดย Traefik Labs) เป็นผู้มาใหม่ในการแข่งขันเครื่องมือตาข่ายบริการ ภารกิจของโครงการคือการทำให้เครือข่ายบริการเป็นประชาธิปไตยโดยทำให้ใช้งานง่ายและกำหนดค่า ประสบการณ์ของนักพัฒนาซอฟต์แวร์เกี่ยวกับ Traefik Proxy ที่รอบคอบทำให้พวกเขาอยู่ในตำแหน่งสำคัญที่จะบรรลุเป้าหมายนั้น

• คุณลักษณะ การจัดการจราจร ใน Traefik Mesh รวมถึงการตัดวงจรและการจำกัดอัตรา
• ในแง่ของความสามารถในการ สังเกต Traefik Mesh นำเสนอ OpenTracing Support ดั้งเดิมและตัวชี้วัดแบบสำเร็จรูป (การติดตั้งมาตรฐานจะรวม Prometheus และ Grafana โดยอัตโนมัติ) ซึ่งช่วยประหยัดเวลาในการตั้งค่า
• เพื่อ ความปลอดภัย —นอกเหนือจาก mTLS— ข้อมูลจำเพาะเป็นไปตามมาตรฐาน SMI และ Traefik Mesh อนุญาตให้ปรับแต่งการอนุญาตการรับส่งข้อมูลผ่านการควบคุมการเข้าถึง

Traefik Mesh จำเป็นต้องติดตั้ง CoreDNS บนคลัสเตอร์ (ในขณะที่ Azure ใช้ CoreDNS เป็นค่าเริ่มต้นตั้งแต่ 1.12 GKE มีค่าเริ่มต้นเป็น kube-dns ณ การเขียนนี้ ซึ่งหมายความว่ามีขั้นตอนเพิ่มเติมที่สำคัญที่เกี่ยวข้องในกรณีนั้น) นอกจากนี้ยังขาดความสามารถแบบหลายคลัสเตอร์

ที่กล่าวว่า Traefik Mesh มีเอกลักษณ์เฉพาะในการเปรียบเทียบตาข่ายบริการของเราที่ไม่ใช้การฉีดด้านข้าง แต่มันถูกปรับใช้เป็น DaemonSet บนโหนดทั้งหมดเพื่อทำหน้าที่เป็นพร็อกซีระหว่างบริการ ทำให้ไม่รุกราน โดยรวมแล้ว Traefik Mesh นั้นง่ายต่อการติดตั้งและใช้งาน

การตรวจสอบอย่างรวดเร็วของ AWS App Mesh

ในโลกของผู้ให้บริการระบบคลาวด์ AWS เป็นผู้ให้บริการรายแรกที่ใช้ระบบเครือข่ายแบบเนทีฟที่เสียบได้กับ Kubernetes (หรือ EKS โดยเฉพาะ) แต่ยังรวมถึงบริการอื่นๆ ด้วย AWS App Mesh เปิดตัวในเดือนพฤศจิกายน 2018 และ AWS ก็เริ่มทำซ้ำตั้งแต่นั้นเป็นต้นมา ข้อได้เปรียบหลักของ AWS App Mesh คือระบบนิเวศของ AWS และตำแหน่งทางการตลาดที่มีอยู่ก่อน ชุมชนขนาดใหญ่ที่อยู่เบื้องหลัง AWS โดยรวมจะยังคงขับเคลื่อนการใช้งานและความสามารถในการใช้งาน

• การจัดการทราฟฟิก ใน AWS App Mesh รวมการตัดวงจรที่ด้านบนของคุณสมบัติทั่วไป
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

โครงสร้างพื้นฐาน

Traffic Management

การสังเกต

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

การปรับใช้

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.