Lời chào hỏi! Đây là bài viết ngắn trả lời các câu hỏi: “sứ giả là gì?”, “tại sao lại cần thiết?” và "bắt đầu từ đâu?".
Cái này là gì
Envoy là bộ cân bằng L4-L7 được viết bằng C++, tập trung vào hiệu suất cao và tính khả dụng. Một mặt, đây là một dạng tương tự của nginx và haproxy, có hiệu suất tương đương với chúng. Mặt khác, nó thiên về kiến trúc microservice nhiều hơn và có chức năng không thua kém gì các bộ cân bằng java và go, chẳng hạn như zuul hoặc traefik.
Bảng so sánh haproxy/nginx/envoy, nó không khẳng định là sự thật tuyệt đối mà đưa ra một bức tranh tổng quát.
nginx
haproxy
gởi
traefik
sao trên github
11.2k/gương
1.1k/gương
12.4k
27.6k
viết vào
C
C
C + +
go
API
không
chỉ ổ cắm/đẩy
mặt phẳng dữ liệu/kéo
kéo
kiểm tra sức khỏe tích cực
không
vâng
vâng
vâng
Truy tìm mở
plugin bên ngoài
không
vâng
vâng
J.W.T.
plugin bên ngoài
không
vâng
không
sự mở rộng
Lua/C
Lua/C
Lua/C++
không
Tại sao
Đây là một dự án còn non trẻ, còn nhiều thứ còn thiếu, một số ở giai đoạn đầu alpha. Nhưng gởi, cũng do tuổi trẻ nên đang phát triển nhanh chóng và đã có nhiều tính năng thú vị: cấu hình động, nhiều bộ lọc làm sẵn, giao diện đơn giản để viết bộ lọc của riêng bạn.
Các lĩnh vực ứng dụng tiếp nối điều này, nhưng trước tiên có 2 phản mẫu:
- Độ giật tĩnh.
Thực tế là vào thời điểm hiện tại ở gởi không hỗ trợ bộ nhớ đệm. Các nhân viên Google đang thử điều này
Hiện tại, hãy sử dụng nginx cho số liệu thống kê.
- Cấu hình tĩnh.
Bạn có thể sử dụng nó, nhưng gởi Đó không phải là mục đích nó được tạo ra. Các tính năng trong cấu hình tĩnh sẽ không bị lộ. Có rất nhiều khoảnh khắc:
Khi chỉnh sửa cấu hình trong yaml, bạn sẽ nhầm lẫn, mắng các nhà phát triển vì tính dài dòng và cho rằng cấu hình nginx/haproxy tuy ít cấu trúc hơn nhưng lại ngắn gọn hơn. Đó là điểm. Cấu hình của Nginx và Haproxy được tạo để chỉnh sửa bằng tay và gởi để tạo từ mã. Toàn bộ cấu hình được mô tả trong
Các kịch bản triển khai Canary, b/g và nhiều kịch bản khác thường chỉ được triển khai trong cấu hình động. Tôi không nói rằng điều này không thể được thực hiện một cách tĩnh tại, tất cả chúng ta đều làm điều đó. Nhưng để làm được điều này, bạn cần phải chống nạng vào bất kỳ thiết bị giữ thăng bằng nào, ở gởi kể cả.
Nhiệm vụ không thể thiếu của Đặc sứ:
- Cân bằng lưu lượng trong các hệ thống phức tạp và năng động. Điều này bao gồm lưới dịch vụ, nhưng nó không nhất thiết phải là lưới duy nhất.
- Nhu cầu về chức năng theo dõi phân tán, ủy quyền phức tạp hoặc chức năng khác có sẵn trong gởi sẵn có hoặc được triển khai một cách thuận tiện, nhưng trong nginx/haproxy, bạn cần được bao quanh bởi các plugin lua và đáng ngờ.
Cả hai, nếu cần thiết, đều mang lại hiệu suất cao.
Làm thế nào nó hoạt động
Envoy chỉ được phân phối ở dạng nhị phân dưới dạng hình ảnh docker. Hình ảnh đã chứa ví dụ về cấu hình tĩnh. Nhưng chúng tôi quan tâm đến nó chỉ để hiểu cấu trúc.
cấu hình tĩnh envoy.yaml
static_resources:
listeners:
- name: listener_0
address:
socket_address:
protocol: TCP
address: 0.0.0.0
port_value: 10000
filter_chains:
- filters:
- name: envoy.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match:
prefix: "/"
route:
host_rewrite: www.google.com
cluster: service_google
http_filters:
- name: envoy.router
clusters:
- name: service_google
connect_timeout: 0.25s
type: LOGICAL_DNS
# Comment out the following line to test on v6 networks
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: service_google
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: www.google.com
port_value: 443
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
sni: www.google.com
Cấu hình động
Chúng ta đang tìm kiếm giải pháp cho vấn đề gì? Bạn không thể tải lại cấu hình cân bằng tải khi đang tải; các vấn đề “nhỏ” sẽ phát sinh:
- Xác thực cấu hình.
Cấu hình có thể lớn, có thể rất lớn, nếu chúng ta quá tải tất cả cùng một lúc thì khả năng xảy ra lỗi ở đâu đó sẽ tăng lên.
- Kết nối lâu dài.
Khi khởi tạo một trình nghe mới, bạn cần quan tâm đến các kết nối đang chạy trên trình nghe cũ; nếu các thay đổi xảy ra thường xuyên và có các kết nối tồn tại lâu dài, bạn sẽ phải tìm cách thỏa hiệp. Xin chào, kubernetes xâm nhập vào nginx.
- Tích cực kiểm tra sức khỏe.
Nếu chúng tôi thực hiện kiểm tra tình trạng hoạt động, chúng tôi cần kiểm tra kỹ tất cả chúng trong cấu hình mới trước khi gửi lưu lượng truy cập. Nếu có nhiều thượng nguồn thì việc này sẽ mất thời gian. Xin chào haproxy.
Điều này được giải quyết như thế nào trong gởiBằng cách tải config động, theo mô hình pool, bạn có thể chia nó thành các phần riêng biệt và không khởi tạo lại phần chưa thay đổi. Ví dụ: một trình nghe, việc khởi tạo lại rất tốn kém và hiếm khi thay đổi.
Cấu hình gởi (từ tệp trên) có các thực thể sau:
- người nghe — trình nghe treo trên một ip/cổng cụ thể
- Máy chủ ảo - máy chủ ảo theo tên miền
- tuyến đường - Quy luật cân bằng
- cụm — một nhóm thượng nguồn với các thông số cân bằng
- thiết bị đầu cuối — địa chỉ phiên bản ngược dòng
Mỗi thực thể này cùng với một số thực thể khác có thể được điền động; đối với điều này, cấu hình chỉ định địa chỉ của dịch vụ nơi cấu hình sẽ được nhận. Dịch vụ có thể là REST hoặc gRPC, ưu tiên gRPC.
Các dịch vụ được đặt tên lần lượt là: LDS, VHDS, RDS, CDS và EDS. Bạn có thể kết hợp cấu hình tĩnh và động, với hạn chế là tài nguyên động không thể được chỉ định trong tài nguyên tĩnh.
Đối với hầu hết các tác vụ, việc triển khai ba dịch vụ cuối cùng là đủ, chúng được gọi là ADS (Dịch vụ khám phá tổng hợp), dành cho
Cấu hình có dạng sau:
cấu hình động envoy.yaml
dynamic_resources:
ads_config:
api_type: GRPC
grpc_services:
envoy_grpc:
cluster_name: xds_clr
cds_config:
ads: {}
static_resources:
listeners:
- name: listener_0
address:
socket_address:
protocol: TCP
address: 0.0.0.0
port_value: 10000
filter_chains:
- filters:
- name: envoy.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
stat_prefix: ingress_http
rds:
route_config_name: local_route
config_source:
ads: {}
http_filters:
- name: envoy.router
clusters:
- name: xds_clr
connect_timeout: 0.25s
type: LOGICAL_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: xds_clr
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: xds
port_value: 6565
Khi chạy gởi với cấu hình này, nó sẽ kết nối với mặt phẳng điều khiển và cố gắng yêu cầu cấu hình RDS, CDS và EDS. Quá trình tương tác xảy ra như thế nào được mô tả
Nói ngắn gọn, gởi gửi yêu cầu cho biết loại tài nguyên được yêu cầu, phiên bản và tham số của nút. Đáp lại, nó nhận được một tài nguyên và một phiên bản; nếu phiên bản trên mặt phẳng điều khiển không thay đổi, nó sẽ không phản hồi.
Có 4 lựa chọn tương tác:
- Một luồng gRPC cho tất cả các loại tài nguyên, trạng thái đầy đủ của tài nguyên sẽ được gửi.
- Luồng riêng biệt, tình trạng đầy đủ.
- Một luồng, trạng thái gia tăng.
- Các luồng riêng biệt, trạng thái gia tăng.
XDS tăng dần cho phép bạn giảm lưu lượng giữa mặt phẳng điều khiển và gởi, điều này phù hợp với các cấu hình lớn. Nhưng nó làm phức tạp sự tương tác; yêu cầu chứa danh sách các tài nguyên để hủy đăng ký và đăng ký.
Ví dụ của chúng tôi sử dụng ADS - một luồng cho RDS, CDS, EDS và chế độ không tăng dần. Để bật chế độ tăng dần, bạn cần chỉ định api_type: DELTA_GRPC
Vì yêu cầu chứa các tham số nút nên chúng tôi có thể gửi các tài nguyên khác nhau đến mặt phẳng điều khiển cho các phiên bản khác nhau gởi, điều này thuận tiện cho việc xây dựng lưới dịch vụ.
Ấm lên
Trên gởi khi khởi động hoặc khi nhận được cấu hình mới từ mặt phẳng điều khiển, quy trình khởi động tài nguyên sẽ được khởi chạy. Nó được chia thành khởi động người nghe và khởi động cụm. Cái đầu tiên được khởi chạy khi có những thay đổi trong RDS/LDS, cái thứ hai khi có CDS/EDS. Điều này có nghĩa là nếu chỉ ngược dòng thay đổi thì trình nghe sẽ không được tạo lại.
Trong quá trình khởi động, các nguồn lực phụ thuộc sẽ được yêu cầu từ mặt phẳng điều khiển trong thời gian chờ. Nếu hết thời gian chờ, quá trình khởi tạo sẽ không thành công và trình nghe mới sẽ không bắt đầu nghe trên cổng.
Thứ tự khởi tạo: EDS, CDS, active health check, RDS, LDS. Khi bật kiểm tra tình trạng hoạt động, lưu lượng truy cập sẽ chỉ ngược dòng sau một lần kiểm tra tình trạng thành công.
Nếu trình nghe được tạo lại, trình nghe cũ sẽ chuyển sang trạng thái DRAIN và sẽ bị xóa sau khi tất cả các kết nối bị đóng hoặc hết thời gian chờ --drain-time-s
, mặc định là 10 phút.
Tiếp tục.
Nguồn: www.habr.com