Giới thiệu
Chúng tôi đang trong bắt đầu triển khai Istio như một mạng lưới dịch vụ. Về nguyên tắc thì mọi thứ đều ổn, ngoại trừ một điều: Nó đắt.
В đối với Istio nó nói:
Với Istio 1.1, proxy tiêu thụ khoảng 0,6 vCPU (lõi ảo) trên 1000 yêu cầu mỗi giây.
Đối với khu vực đầu tiên trong lưới dịch vụ (2 proxy ở mỗi bên của kết nối), chúng tôi sẽ có 1200 lõi chỉ dành cho proxy, với tốc độ một triệu yêu cầu mỗi giây. Theo công cụ tính chi phí của Google, chi phí cho cấu hình là khoảng 40 USD/tháng/lõi n1-standard-64, tức là chỉ riêng khu vực này thôi chúng tôi đã tiêu tốn hơn 50 nghìn đô la mỗi tháng cho 1 triệu yêu cầu mỗi giây.
Ivan Sim () sự chậm trễ của lưới dịch vụ vào năm ngoái và hứa hẹn điều tương tự cho bộ nhớ và bộ xử lý, nhưng không thành công:
Rõ ràng, value-istio-test.yaml sẽ làm tăng nghiêm trọng các yêu cầu CPU. Nếu tôi tính toán chính xác, bạn cần khoảng 24 lõi CPU cho bảng điều khiển và 0,5 CPU cho mỗi proxy. Tôi không có nhiều như vậy. Tôi sẽ lặp lại các bài kiểm tra khi có nhiều tài nguyên hơn được phân bổ cho tôi.
Tôi muốn tự mình xem hiệu suất của Istio tương tự như thế nào với một lưới dịch vụ nguồn mở khác: .
Lắp đặt lưới dịch vụ
Trước hết, tôi đã cài đặt nó trong một cụm :
$ 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!Tôi đã sử dụng SuperGloo vì nó giúp việc khởi động lưới dịch vụ dễ dàng hơn nhiều. Tôi không phải làm gì nhiều. Chúng tôi không sử dụng SuperGloo trong sản xuất nhưng nó rất lý tưởng cho nhiệm vụ như vậy. Tôi đã phải sử dụng một vài lệnh cho mỗi lưới dịch vụ. Tôi đã sử dụng hai cụm để cách ly - mỗi cụm dành cho Istio và Linkerd.
Thử nghiệm được thực hiện trên Google Kubernetes Engine. Tôi đã sử dụng Kubernetes 1.12.7-gke.7 và một nhóm các nút n1-standard-4 với quy mô nút tự động (tối thiểu 4, tối đa 16).
Sau đó tôi cài đặt cả hai lưới dịch vụ từ dòng lệnh.
Liên kết đầu tiên:
$ 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 |
+---------+--------------+---------+---------------------------+Sau đó là Istio:
$ 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 |
+---------+------------+---------+---------------------------+Vòng lặp sự cố mất vài phút và sau đó bảng điều khiển ổn định.
(Lưu ý: SuperGloo hiện chỉ hỗ trợ Istio 1.0.x. Tôi đã lặp lại thử nghiệm với Istio 1.1.3 nhưng không nhận thấy bất kỳ sự khác biệt đáng chú ý nào.)
Thiết lập triển khai tự động Istio
Để khiến Istio cài đặt Envoy sidecar, chúng tôi sử dụng bộ phun sidecar − MutatingAdmissionWebhook. Chúng tôi sẽ không nói về nó trong bài viết này. Hãy để tôi nói rằng đây là bộ điều khiển giám sát quyền truy cập của tất cả các nhóm mới và tự động thêm sidecar và initContainer, chịu trách nhiệm thực hiện các tác vụ iptables.
Tại Shopify, chúng tôi đã viết bộ điều khiển truy cập của riêng mình để triển khai sidecar, nhưng đối với điểm chuẩn này, tôi đã sử dụng bộ điều khiển đi kèm với Istio. Bộ điều khiển sẽ chèn sidecar theo mặc định khi có lối tắt trong không gian tên 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 labeledThiết lập triển khai Linkerd tự động
Để thiết lập nhúng sidecar Linkerd, chúng tôi sử dụng các chú thích (tôi đã thêm chúng theo cách thủ công thông qua 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: ActiveTrình mô phỏng dung sai lỗi Istio
Chúng tôi đã xây dựng một trình mô phỏng khả năng chịu lỗi có tên Istio để thử nghiệm lưu lượng truy cập dành riêng cho Shopify. Chúng tôi cần một công cụ để tạo cấu trúc liên kết tùy chỉnh đại diện cho một phần cụ thể trong biểu đồ dịch vụ của chúng tôi, được định cấu hình động để lập mô hình khối lượng công việc cụ thể.
Cơ sở hạ tầng của Shopify phải chịu tải nặng trong thời gian flash sale. Đồng thời, Shopify . Những khách hàng lớn đôi khi cảnh báo về đợt giảm giá chớp nhoáng đã được lên kế hoạch. Những người khác thực hiện chúng một cách bất ngờ cho chúng ta bất cứ lúc nào, ngày hay đêm.
Chúng tôi muốn trình mô phỏng khả năng phục hồi của mình mô hình hóa quy trình công việc phù hợp với cấu trúc liên kết và khối lượng công việc đã làm quá tải cơ sở hạ tầng của Shopify trong quá khứ. Mục đích chính của việc sử dụng lưới dịch vụ là chúng tôi cần độ tin cậy và khả năng chịu lỗi ở cấp độ mạng và điều quan trọng đối với chúng tôi là lưới dịch vụ có thể đối phó hiệu quả với tải mà các dịch vụ trước đây đã bị gián đoạn.
Trọng tâm của trình mô phỏng khả năng chịu lỗi là nút công nhân, hoạt động như một nút lưới dịch vụ. Nút công nhân có thể được cấu hình tĩnh khi khởi động hoặc động thông qua API REST. Chúng tôi sử dụng cấu hình động của các nút công nhân để tạo quy trình công việc dưới dạng kiểm tra hồi quy.
Đây là một ví dụ về một quá trình như vậy:
- Chúng tôi ra mắt 10 máy chủ như
bardịch vụ trả về phản hồi200/OKsau 100 mili giây. - Chúng tôi khởi chạy 10 ứng dụng khách - mỗi ứng dụng gửi 100 yêu cầu mỗi giây tới
bar. - Cứ sau 10 giây chúng tôi xóa 1 máy chủ và theo dõi lỗi
5xxtrên máy khách.
Khi kết thúc quy trình làm việc, chúng tôi kiểm tra nhật ký và số liệu cũng như kiểm tra xem thử nghiệm có vượt qua hay không. Bằng cách này, chúng tôi tìm hiểu về hiệu suất của lưới dịch vụ của mình và chạy thử nghiệm hồi quy để kiểm tra các giả định của chúng tôi về khả năng chịu lỗi.
(Lưu ý: Chúng tôi đang nghĩ đến việc tìm nguồn mở cho trình mô phỏng khả năng chịu lỗi Istio nhưng chưa sẵn sàng thực hiện điều đó.)
Trình mô phỏng khả năng chịu lỗi Istio cho điểm chuẩn lưới dịch vụ
Chúng tôi thiết lập một số nút làm việc của trình mô phỏng:
irs-client-loadgen: 3 bản sao gửi 100 yêu cầu mỗi giây mỗi lầnirs-client.irs-client: 3 bản sao nhận được yêu cầu, đợi 100ms và chuyển tiếp yêu cầu tớiirs-server.irs-server: 3 bản sao trả về200/OKsau 100 mili giây.
Với cấu hình này, chúng ta có thể đo lưu lượng truy cập ổn định giữa 9 điểm cuối. Xe sidecar ở irs-client-loadgen и irs-server nhận được 100 yêu cầu mỗi giây và irs-client — 200 (đến và đi).
Chúng tôi theo dõi việc sử dụng tài nguyên thông qua bởi vì chúng tôi không có cụm Prometheus.
Những phát hiện
Bảng điều khiển
Đầu tiên, chúng tôi kiểm tra mức tiêu thụ CPU.
Bảng điều khiển Linkerd ~22 millicore
Bảng điều khiển Istio: ~750 millicore
Bảng điều khiển Istio sử dụng khoảng Tài nguyên CPU nhiều hơn 35 lầnhơn Linkerd. Tất nhiên, mọi thứ đều được cài đặt theo mặc định và phép đo từ xa istio tiêu tốn rất nhiều tài nguyên bộ xử lý ở đây (nó có thể bị vô hiệu hóa bằng cách tắt một số chức năng). Nếu loại bỏ thành phần này, chúng ta vẫn nhận được hơn 100 millicores, tức là Gấp 4 lầnhơn Linkerd.
Proxy phụ
Sau đó chúng tôi đã thử nghiệm việc sử dụng proxy. Cần có một mối quan hệ tuyến tính với số lượng yêu cầu, nhưng đối với mỗi sidecar sẽ có một số chi phí hoạt động ảnh hưởng đến đường cong.
Linkerd: ~100 millicores cho irs-client, ~50 millicores cho irs-client-loadgen
Kết quả có vẻ hợp lý vì proxy máy khách nhận được lưu lượng truy cập gấp đôi so với proxy tải: đối với mỗi yêu cầu gửi đi từ tải, máy khách có một yêu cầu đến và một yêu cầu gửi đi.
Istio/Envoy: ~155 millicores cho irs-client, ~75 millicores cho irs-client-loadgen
Chúng tôi thấy kết quả tương tự đối với xe sidecar Istio.
Nhưng nhìn chung, proxy của Istio/Envoy tiêu thụ thêm khoảng 50% tài nguyên CPUhơn Linkerd.
Chúng tôi thấy sơ đồ tương tự ở phía máy chủ:
Linkerd: ~50 millicore cho máy chủ irs
Istio/Envoy: ~80 millicore cho máy chủ irs
Về phía máy chủ, sidecar Istio/Envoy tiêu thụ thêm khoảng 60% tài nguyên CPUhơn Linkerd.
Kết luận
Proxy Istio Envoy tiêu thụ CPU nhiều hơn 50% so với Linkerd trên khối lượng công việc mô phỏng của chúng tôi. Bảng điều khiển Linkerd tiêu thụ ít tài nguyên hơn Istio, đặc biệt là đối với các thành phần cốt lõi.
Chúng tôi vẫn đang suy nghĩ về cách giảm những chi phí này. Nếu bạn có ý tưởng, xin vui lòng chia sẻ!
Nguồn: www.habr.com