การแนะนำ
เราอยู่ใน เริ่มปรับใช้ Istio เป็น service mesh โดยหลักการแล้ว ทุกอย่างเรียบร้อยดี ยกเว้นสิ่งหนึ่ง: มันแพง.
В สำหรับ Istio มันพูดว่า:
ด้วย Istio 1.1 พร็อกซีจะใช้ vCPU ประมาณ 0,6 vCPU (คอร์เสมือน) ต่อคำขอ 1000 รายการต่อวินาที
สำหรับภูมิภาคแรกใน service mesh (พร็อกซี 2 ตัวในแต่ละด้านของการเชื่อมต่อ) เราจะมี 1200 คอร์สำหรับพร็อกซีเท่านั้น ในอัตราหนึ่งล้านคำขอต่อวินาที จากเครื่องคำนวณต้นทุนของ Google พบว่าจะอยู่ที่ประมาณ 40 เหรียญต่อเดือน/แกนสำหรับการกำหนดค่า n1-standard-64นั่นคือภูมิภาคนี้เพียงอย่างเดียวจะทำให้เราเสียค่าใช้จ่ายมากกว่า 50 ดอลลาร์ต่อเดือนสำหรับ 1 ล้านคำขอต่อวินาที
อีวาน ซิม () บริการตาข่ายล่าช้าในปีที่แล้วและสัญญาว่าจะเหมือนกันสำหรับหน่วยความจำและโปรเซสเซอร์ แต่ก็ไม่ได้ผล:
เห็นได้ชัดว่าvalue-istio-test.yamlจะเพิ่มคำขอ CPU อย่างจริงจัง หากฉันคำนวณถูกต้องแล้ว คุณต้องมีคอร์ CPU ประมาณ 24 คอร์สำหรับแผงควบคุมและ 0,5 CPU สำหรับแต่ละพร็อกซี ฉันไม่ได้มีมากขนาดนั้น ฉันจะทำการทดสอบซ้ำเมื่อมีการจัดสรรทรัพยากรให้ฉันมากขึ้น
ฉันอยากจะเห็นด้วยตัวเองว่าประสิทธิภาพของ Istio มีความคล้ายคลึงกับบริการโอเพ่นซอร์สอื่นอย่างไร: .
บริการติดตั้งตาข่าย
ก่อนอื่นเลย ฉันติดตั้งมันลงในคลัสเตอร์ :
$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!ฉันใช้ SuperGloo เพราะมันทำให้การบูตระบบตาข่ายบริการง่ายขึ้นมาก ฉันไม่ต้องทำอะไรมาก เราไม่ได้ใช้ SuperGloo ในการผลิต แต่เหมาะสำหรับงานดังกล่าว ฉันต้องใช้คำสั่งสองสามคำสั่งสำหรับแต่ละเซอร์วิสเมช ฉันใช้สองคลัสเตอร์เพื่อแยก - หนึ่งคลัสเตอร์สำหรับ Istio และ Linkerd
การทดลองดำเนินการบน Google Kubernetes Engine ฉันใช้ Kubernetes 1.12.7-gke.7 และกลุ่มโหนด n1-standard-4 พร้อมการปรับขนาดโหนดอัตโนมัติ (ขั้นต่ำ 4, สูงสุด 16)
จากนั้นฉันติดตั้ง service mesh ทั้งสองจากบรรทัดคำสั่ง
เชื่อมโยงครั้งแรก:
$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true |
| | | | version: stable-2.3.0 |
| | | | namespace: linkerd |
| | | | mtls enabled: true |
| | | | auto inject enabled: true |
+---------+--------------+---------+---------------------------+แล้วอิสติโอ:
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+------------+---------+---------------------------+
| istio | Istio Mesh | Pending | enabled: true |
| | | | version: 1.0.6 |
| | | | namespace: istio-system |
| | | | mtls enabled: true |
| | | | auto inject enabled: true |
| | | | grafana enabled: true |
| | | | prometheus enabled: true |
| | | | jaeger enabled: true |
+---------+------------+---------+---------------------------+Crash-loop ใช้เวลาสองสามนาที จากนั้นแผงควบคุมก็เสถียร
(หมายเหตุ: SuperGloo รองรับเฉพาะ Istio 1.0.x ในตอนนี้ ฉันทำการทดลองซ้ำกับ Istio 1.1.3 แล้ว แต่ไม่เห็นความแตกต่างที่เห็นได้ชัดเจน)
การตั้งค่าการทำให้ใช้งานได้อัตโนมัติของ Istio
เพื่อให้ Istio ติดตั้ง Sidecar Envoy เราใช้หัวฉีด Sidecar − MutatingAdmissionWebhook. เราจะไม่พูดถึงเรื่องนี้ในบทความนี้ ฉันขอบอกว่านี่คือคอนโทรลเลอร์ที่ตรวจสอบการเข้าถึงของพ็อดใหม่ทั้งหมดและเพิ่มไซด์คาร์และ initContainer แบบไดนามิกซึ่งรับผิดชอบงานต่างๆ iptables.
พวกเราที่ Shopify ได้เขียนตัวควบคุมการเข้าถึงของเราเองเพื่อใช้ไซด์คาร์ แต่สำหรับเกณฑ์มาตรฐานนี้ ฉันใช้ตัวควบคุมที่มาพร้อมกับ Istio คอนโทรลเลอร์จะแทรกไซด์คาร์ตามค่าเริ่มต้นเมื่อมีทางลัดในเนมสเปซ istio-injection: enabled:
$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled
$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeledการตั้งค่าการปรับใช้ Linkerd อัตโนมัติ
ในการตั้งค่าการฝังรถเทียมข้าง Linkerd เราใช้คำอธิบายประกอบ (ฉันเพิ่มด้วยตนเองผ่าน kubectl edit):
metadata:
annotations:
linkerd.io/inject: enabled$ k edit ns irs-server-dev
namespace/irs-server-dev edited
$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
linkerd.io/inject: enabled
name: irs-server-dev
spec:
finalizers:
- kubernetes
status:
phase: Activeเครื่องจำลองความทนทานต่อความผิดพลาดของ Istio
เราได้สร้างตัวจำลองความทนทานต่อข้อผิดพลาดที่เรียกว่า Istio เพื่อทดสอบการรับส่งข้อมูลเฉพาะของ Shopify เราต้องการเครื่องมือในการสร้างโทโพโลยีแบบกำหนดเองที่จะแสดงส่วนเฉพาะของกราฟบริการของเรา โดยมีการกำหนดค่าแบบไดนามิกเพื่อสร้างโมเดลปริมาณงานเฉพาะ
โครงสร้างพื้นฐานของ Shopify มีภาระงานหนักในช่วงการขายแฟลช ในขณะเดียวกัน Shopify . ลูกค้ารายใหญ่บางครั้งเตือนเกี่ยวกับแผนการลดราคาแฟลช คนอื่นทำสิ่งเหล่านั้นให้เราโดยไม่คาดคิดในเวลาใดก็ได้ทั้งกลางวันและกลางคืน
เราต้องการให้เครื่องจำลองความยืดหยุ่นของเราสร้างโมเดลเวิร์กโฟลว์ที่ตรงกับโทโพโลยีและปริมาณงานที่มีอยู่อย่างล้นหลามโครงสร้างพื้นฐานของ Shopify ในอดีต วัตถุประสงค์หลักของการใช้ Service Mesh คือเราต้องการความน่าเชื่อถือและความทนทานต่อข้อผิดพลาดในระดับเครือข่าย และเป็นสิ่งสำคัญสำหรับเราที่ Service Mesh จะสามารถรับมือกับโหลดที่บริการหยุดชะงักก่อนหน้านี้ได้อย่างมีประสิทธิภาพ
หัวใจสำคัญของโปรแกรมจำลองความทนทานต่อข้อผิดพลาดคือโหนดผู้ปฏิบัติงาน ซึ่งทำหน้าที่เป็นโหนดบริการแบบตาข่าย โหนดผู้ปฏิบัติงานสามารถกำหนดค่าแบบคงที่เมื่อเริ่มต้นหรือแบบไดนามิกผ่าน REST API เราใช้การกำหนดค่าแบบไดนามิกของโหนดผู้ปฏิบัติงานเพื่อสร้างเวิร์กโฟลว์ในรูปแบบของการทดสอบการถดถอย
นี่คือตัวอย่างของกระบวนการดังกล่าว:
- เราเปิดตัวเซิร์ฟเวอร์ 10 เครื่องเป็น
barบริการที่ตอบกลับ200/OKหลังจาก 100 มิลลิวินาที - เราเปิดตัวลูกค้า 10 ราย - แต่ละรายส่งคำขอ 100 รายการต่อวินาทีถึง
bar. - ทุก ๆ 10 วินาที เราจะลบเซิร์ฟเวอร์ 1 เครื่องและตรวจสอบข้อผิดพลาด
5xxบนไคลเอนต์
ในตอนท้ายของขั้นตอนการทำงาน เราจะตรวจสอบบันทึกและตัวชี้วัด และตรวจสอบว่าการทดสอบผ่านการทดสอบหรือไม่ วิธีนี้ทำให้เราเรียนรู้เกี่ยวกับประสิทธิภาพของ Service Mesh ของเรา และทำการทดสอบการถดถอยเพื่อทดสอบสมมติฐานของเราเกี่ยวกับความทนทานต่อข้อผิดพลาด
(หมายเหตุ: เรากำลังพิจารณาที่จะเปิดซอร์สโปรแกรมจำลองความทนทานต่อข้อผิดพลาดของ Istio แต่ยังไม่พร้อมที่จะดำเนินการ)
เครื่องจำลองความทนทานต่อข้อผิดพลาดของ Istio สำหรับการวัดประสิทธิภาพตาข่ายบริการ
เราตั้งค่าโหนดการทำงานหลายอย่างของเครื่องจำลอง:
irs-client-loadgen: 3 เรพลิกาที่ส่ง 100 คำขอต่อวินาทีต่อวินาทีirs-client.irs-client: 3 เรพลิกาที่ได้รับคำขอ รอ 100 มิลลิวินาที และส่งต่อคำขอไปที่irs-server.irs-server: 3 แบบจำลองที่ส่งคืน200/OKหลังจาก 100 มิลลิวินาที
ด้วยการกำหนดค่านี้ เราสามารถวัดกระแสการรับส่งข้อมูลที่เสถียรระหว่างจุดสิ้นสุด 9 จุดได้ รถไซด์คาร์เข้า. irs-client-loadgen и irs-server รับ 100 คำขอต่อวินาที และ irs-client — 200 (เข้าและออก)
เราติดตามการใช้ทรัพยากรผ่าน เพราะเราไม่มีกระจุกโพรมีธีอุส
ผลการวิจัย
แผงควบคุม
ขั้นแรก เราตรวจสอบปริมาณการใช้ CPU
แผงควบคุม Linkerd ~22 มิลลิคอร์
แผงควบคุม Istio: ~750 มิลลิคอร์
แผงควบคุม Istio ใช้งานโดยประมาณ ทรัพยากร CPU มากกว่า 35 เท่ากว่าลิงค์เกิร์ด แน่นอนว่าทุกอย่างได้รับการติดตั้งตามค่าเริ่มต้นและ istio-telemetry ใช้ทรัพยากรตัวประมวลผลจำนวนมากที่นี่ (สามารถปิดใช้งานได้โดยการปิดใช้งานฟังก์ชันบางอย่าง) ถ้าเราลบส่วนประกอบนี้ออก เราก็จะได้มากกว่า 100 มิลลิคอร์ นั่นก็คือ มากกว่า 4 เท่ากว่าลิงค์เกิร์ด
พร็อกซีรถไซด์คาร์
จากนั้นเราทดสอบการใช้พรอกซี ควรมีความสัมพันธ์เชิงเส้นตรงกับจำนวนคำขอ แต่สำหรับรถเทียมข้างรถจักรยานยนต์แต่ละคัน มีค่าใช้จ่ายบางส่วนที่ส่งผลต่อเส้นโค้ง
Linkerd: ~100 มิลลิคอร์สำหรับ irs-client, ~50 มิลลิคอร์สำหรับ irs-client-loadgen
ผลลัพธ์ดูสมเหตุสมผล เนื่องจากพร็อกซีไคลเอ็นต์ได้รับปริมาณข้อมูลเป็นสองเท่าของพร็อกซี loadgen: สำหรับทุกคำขอออกจาก loadgen ไคลเอ็นต์จะมีขาเข้าหนึ่งรายการและขาออกหนึ่งรายการ
Istio/Envoy: ~155 มิลลิคอร์สำหรับ irs-client, ~75 มิลลิคอร์สำหรับ irs-client-loadgen
เราเห็นผลลัพธ์ที่คล้ายกันสำหรับรถเทียมข้างรถจักรยานยนต์ Istio
แต่โดยทั่วไปแล้ว พร็อกซีของ Istio/Envoy จะใช้ ทรัพยากร CPU เพิ่มขึ้นประมาณ 50%กว่าลิงค์เกิร์ด
เราเห็นรูปแบบเดียวกันบนฝั่งเซิร์ฟเวอร์:
Linkerd: ~50 มิลลิคอร์สำหรับเซิร์ฟเวอร์ irs
Istio/Envoy: ~80 มิลลิคอร์สำหรับเซิร์ฟเวอร์ irs
ทางฝั่งเซิร์ฟเวอร์ ไซด์คาร์ Istio/Envoy ใช้งาน ทรัพยากร CPU เพิ่มขึ้นประมาณ 60%กว่าลิงค์เกิร์ด
ข้อสรุป
พร็อกซี Istio Envoy ใช้ CPU มากกว่า Linkerd 50+% บนปริมาณงานจำลองของเรา แผงควบคุม Linkerd ใช้ทรัพยากรน้อยกว่า Istio มาก โดยเฉพาะอย่างยิ่งสำหรับส่วนประกอบหลัก
เรายังคงคิดถึงวิธีลดต้นทุนเหล่านี้ หากคุณมีไอเดียโปรดแชร์!
ที่มา: will.com