Tổng quan và so sánh các bộ điều khiển Ingress cho Kubernetes

Tổng quan và so sánh các bộ điều khiển Ingress cho Kubernetes

Khi khởi chạy cụm Kubernetes cho một ứng dụng cụ thể, bạn cần hiểu bản thân ứng dụng, doanh nghiệp và nhà phát triển đặt ra những gì đối với tài nguyên này. Với thông tin này, bạn có thể bắt đầu đưa ra quyết định về kiến ​​trúc và đặc biệt là chọn một bộ điều khiển Ingress cụ thể, hiện đã có một số lượng lớn. Để có được ý tưởng cơ bản về các tùy chọn có sẵn mà không cần phải xem qua nhiều bài báo / tài liệu, v.v., chúng tôi đã chuẩn bị tổng quan này, bao gồm các bộ điều khiển Ingress chính (sẵn sàng sản xuất).

Chúng tôi hy vọng rằng nó sẽ giúp ích cho các đồng nghiệp trong việc lựa chọn giải pháp kiến ​​trúc - ít nhất nó sẽ trở thành điểm khởi đầu để có được thông tin chi tiết hơn và các thí nghiệm thực tế. Trước đây, chúng tôi đã nghiên cứu các tài liệu tương tự khác trên mạng và thật kỳ lạ, không tìm thấy một bài đánh giá nào ít nhiều đầy đủ và quan trọng nhất - có cấu trúc -. Vì vậy, hãy lấp đầy khoảng trống đó!

tiêu chí

Về nguyên tắc, để so sánh và nhận được bất kỳ kết quả hữu ích nào, bạn không chỉ cần hiểu lĩnh vực chủ đề mà còn phải có một danh sách cụ thể các tiêu chí sẽ thiết lập vectơ nghiên cứu. Không giả vờ phân tích tất cả các trường hợp có thể xảy ra khi sử dụng Ingress / Kubernetes, chúng tôi đã cố gắng làm nổi bật các yêu cầu chung nhất đối với bộ điều khiển - hãy chuẩn bị rằng trong mọi trường hợp, bạn sẽ phải nghiên cứu tất cả các chi tiết cụ thể và cụ thể của mình một cách riêng biệt.

Nhưng tôi sẽ bắt đầu với những đặc điểm đã trở nên quen thuộc đến mức chúng được triển khai trong tất cả các giải pháp và không được xem xét:

  • phát hiện động các dịch vụ (service Discovery);
  • chấm dứt SSL;
  • làm việc với websockets.

Bây giờ cho các điểm so sánh:

Các giao thức được hỗ trợ

Một trong những tiêu chí lựa chọn cơ bản. Phần mềm của bạn có thể không hoạt động trên HTTP tiêu chuẩn hoặc có thể yêu cầu hoạt động trên nhiều giao thức cùng một lúc. Nếu trường hợp của bạn không chuẩn, hãy nhớ tính đến yếu tố này để sau này bạn không phải cấu hình lại cụm. Đối với tất cả các bộ điều khiển, danh sách các giao thức được hỗ trợ sẽ khác nhau.

phần mềm cốt lõi

Có một số biến thể của ứng dụng mà bộ điều khiển dựa trên. Những cái phổ biến là nginx, traefik, haproxy, đặc sứ. Trong trường hợp chung, nó có thể không ảnh hưởng nhiều đến cách nhận và truyền lưu lượng, nhưng sẽ luôn hữu ích khi biết các sắc thái và tính năng tiềm ẩn của những gì “dưới mui xe”.

Định tuyến giao thông

Trên cơ sở những gì có thể đưa ra quyết định về hướng lưu lượng truy cập đến một dịch vụ cụ thể? Thông thường đây là máy chủ và đường dẫn, nhưng có những khả năng bổ sung.

Không gian tên trong một cụm

Không gian tên (namespace) - khả năng phân chia tài nguyên một cách hợp lý trong Kubernetes (ví dụ: trên sân khấu, sản xuất, v.v.). Có các bộ điều khiển Ingress phải được cài đặt riêng trong từng không gian tên (và sau đó nó có thể hướng lưu lượng truy cập chỉ vào các nhóm của không gian này). Và có những cái (và phần lớn rõ ràng của chúng) hoạt động trên toàn cầu cho toàn bộ cụm - trong đó lưu lượng truy cập được hướng đến bất kỳ nhóm nào của cụm, bất kể không gian tên.

Mẫu cho thượng nguồn

Lưu lượng truy cập hướng đến các phiên bản lành mạnh của ứng dụng, dịch vụ như thế nào? Có các tùy chọn với kiểm tra chủ động và thụ động, thử lại, ngắt mạch (Để biết thêm chi tiết, xem ví dụ, Bài viết về Istio), triển khai riêng các kiểm tra sức khỏe (kiểm tra sức khỏe tùy chỉnh), v.v. Một tham số rất quan trọng nếu bạn có yêu cầu cao về tính khả dụng và loại bỏ kịp thời các dịch vụ bị lỗi khỏi cân bằng.

Thuật toán cân bằng

Có nhiều lựa chọn: từ truyền thống vòng tròn đến kỳ lạ cookie thứ rdp, cũng như các tính năng riêng lẻ như phiên dính.

Xác thực

Bộ điều khiển hỗ trợ các lược đồ ủy quyền nào? Cơ bản, thông báo, oauth, xác thực bên ngoài - Tôi nghĩ những tùy chọn này nên quen thuộc. Đây là một tiêu chí quan trọng nếu có nhiều vòng lặp dành cho nhà phát triển (và/hoặc chỉ riêng tư) được truy cập thông qua Ingress.

phân phối lưu lượng truy cập

Bộ điều khiển có hỗ trợ các cơ chế phân bổ lưu lượng thường được sử dụng như triển khai canary (canary), thử nghiệm A/B, phản chiếu lưu lượng (mirroring/shadowing) không? Đây là một chủ đề thực sự nhức nhối đối với các ứng dụng yêu cầu quản lý lưu lượng chính xác và chính xác để thử nghiệm hiệu quả, gỡ lỗi sản phẩm ngoại tuyến (hoặc tổn thất tối thiểu), phân tích lưu lượng, v.v.

Đăng ký trả phí

Có tùy chọn trả phí nào cho bộ điều khiển, với chức năng nâng cao và/hoặc hỗ trợ kỹ thuật không?

Giao diện người dùng đồ họa (Web UI)

Có GUI nào để quản lý cấu hình bộ điều khiển không? Chủ yếu dành cho "sự khéo léo" và / hoặc cho những người cần thực hiện một số thay đổi đối với cấu hình Ingress'a, nhưng làm việc với các mẫu "thô" thì bất tiện. Nó có thể hữu ích nếu các nhà phát triển muốn tiến hành một số thử nghiệm với lưu lượng truy cập nhanh chóng.

xác thực JWT

Sự hiện diện của xác thực tích hợp mã thông báo web JSON để ủy quyền và xác thực người dùng cho ứng dụng cuối.

Khả năng tùy chỉnh cấu hình

Khả năng mở rộng mẫu theo nghĩa có các cơ chế cho phép bạn thêm các lệnh, cờ, v.v. của riêng mình vào các mẫu cấu hình tiêu chuẩn.

Cơ chế bảo vệ DDOS cơ bản

Các thuật toán giới hạn tỷ lệ đơn giản hoặc các tùy chọn lọc lưu lượng truy cập phức tạp hơn dựa trên địa chỉ, danh sách trắng, quốc gia, v.v.

yêu cầu dấu vết

Khả năng giám sát, theo dõi và gỡ lỗi các yêu cầu từ Truy cập đến các dịch vụ/nhóm cụ thể và lý tưởng nhất là giữa các dịch vụ/nhóm.

WAF

Hỗ trợ tường lửa ứng dụng.

Bộ điều khiển

Danh sách các bộ điều khiển được hình thành dựa trên tài liệu Kubernetes chính thức и cái bàn này. Chúng tôi đã loại trừ một số trong số chúng khỏi đánh giá do tính đặc hiệu hoặc tỷ lệ lưu hành thấp (giai đoạn phát triển ban đầu). Phần còn lại được thảo luận dưới đây. Hãy bắt đầu với một mô tả chung về các giải pháp và tiếp tục với một bảng tóm tắt.

Xâm nhập từ Kubernetes

Trang mạng: github.com/kubernetes/ingress-nginx
Giấy phép: Apache 2.0

Đây là bộ điều khiển chính thức cho Kubernetes và đang được phát triển bởi cộng đồng. Rõ ràng ngay từ cái tên, nó dựa trên nginx và được bổ sung bởi một bộ plugin Lua khác được sử dụng để triển khai các tính năng bổ sung. Do tính phổ biến của chính nginx và các sửa đổi tối thiểu đối với nó khi được sử dụng làm bộ điều khiển, tùy chọn này có thể là tùy chọn dễ dàng và dễ cấu hình nhất đối với kỹ sư trung bình (có kinh nghiệm web).

Sự xâm nhập của NGINX Inc.

Trang mạng: github.com/nginxinc/kubernetes-ingress
Giấy phép: Apache 2.0

Sản phẩm chính thức của các nhà phát triển nginx. Có phiên bản trả phí dựa trên NGINX Plus. Ý tưởng chính là mức độ ổn định cao, khả năng tương thích ngược liên tục, không có bất kỳ mô-đun ngoại lai nào và tốc độ tăng lên được tuyên bố (so với bộ điều khiển chính thức), đạt được nhờ sự từ chối của Lua.

Phiên bản miễn phí được giảm đáng kể, kể cả khi so sánh với bộ điều khiển chính thức (do thiếu các mô-đun Lua tương tự). Đồng thời, phiên bản trả phí có chức năng bổ sung khá rộng: số liệu thời gian thực, xác thực JWT, kiểm tra tình trạng hoạt động, v.v. Một lợi thế quan trọng so với NGINX Ingress là hỗ trợ đầy đủ cho lưu lượng TCP / UDP (và trong phiên bản cộng đồng nữa!). Dấu trừ - vắng mặt Tuy nhiên, tính năng phân phối lưu lượng truy cập “có ưu tiên cao nhất cho các nhà phát triển” nhưng cần có thời gian để triển khai.

Kong xâm nhập

Trang mạng: github.com/Kong/kubernetes-ingress-controller
Giấy phép: Apache 2.0

Sản phẩm được phát triển bởi Kong Inc. trong hai phiên bản: thương mại và miễn phí. Dựa trên nginx, đã được mở rộng với một số lượng lớn các mô-đun Lua.

Ban đầu, nó tập trung vào việc xử lý và định tuyến các yêu cầu API, tức là với tư cách là Cổng API, nhưng hiện tại, nó đã trở thành bộ điều khiển Ingress chính thức. Ưu điểm chính: nhiều mô-đun bổ sung (bao gồm cả những mô-đun từ các nhà phát triển bên thứ ba) dễ cài đặt và định cấu hình và với sự trợ giúp của một loạt các tính năng bổ sung được triển khai. Tuy nhiên, các chức năng tích hợp đã cung cấp nhiều khả năng. Cấu hình công việc được thực hiện bằng tài nguyên CRD.

Một tính năng quan trọng của sản phẩm - hoạt động trong cùng một đường viền (thay vì đặt tên chéo) là một chủ đề gây tranh cãi: đối với một số người, điều này có vẻ như là một bất lợi (bạn phải tạo các thực thể cho từng đường viền) và đối với một số người thì đó là một tính năng ( bоMức độ cô lập cao hơn, như nếu một bộ điều khiển bị hỏng, thì sự cố chỉ giới hạn ở mạch).

traefik

Trang mạng: github.com/containous/traefik
Giấy phép: MIT

Một proxy ban đầu được tạo để hoạt động với định tuyến yêu cầu cho vi dịch vụ và môi trường động của chúng. Do đó, nhiều tính năng hữu ích: cập nhật cấu hình mà không cần khởi động lại, hỗ trợ nhiều phương pháp cân bằng, giao diện web, chuyển tiếp số liệu, hỗ trợ các giao thức khác nhau, API REST, bản phát hành canary, v.v. Một tính năng thú vị khác là hỗ trợ chứng chỉ Let's Encrypt ngay lập tức. Nhược điểm là để tổ chức tính sẵn sàng cao (HA), bộ điều khiển sẽ cần cài đặt và kết nối bộ lưu trữ KV của chính nó.

HAProxy

Trang mạng: github.com/jcmoraisjr/haproxy-ingress
Giấy phép: Apache 2.0

HAProxy từ lâu đã được biết đến như một công cụ cân bằng lưu lượng và proxy. Là một phần của cụm Kubernetes, nó cung cấp bản cập nhật cấu hình “mềm” (không mất lưu lượng), khám phá dịch vụ dựa trên DNS, cấu hình động bằng API. Có thể tùy chỉnh hoàn toàn mẫu cấu hình bằng cách thay thế CM, cũng như khả năng sử dụng các hàm thư viện Sprig trong đó. Nói chung, điểm nhấn chính của giải pháp là tốc độ cao, tối ưu hóa và hiệu quả của nó trong các tài nguyên tiêu thụ. Ưu điểm của bộ điều khiển là hỗ trợ số lượng kỷ lục các phương pháp cân bằng khác nhau.

Người đi du lịch bằng đường biển

Trang mạng: github.com/appscode/voyager
Giấy phép: Apache 2.0

Dựa trên bộ điều khiển HAproxy, được định vị là một giải pháp phổ quát hỗ trợ nhiều tính năng trên một số lượng lớn nhà cung cấp. Một cơ hội được cung cấp để cân bằng lưu lượng trên L7 và L4 và cân bằng toàn bộ lưu lượng TCP L4 có thể được gọi là một trong những tính năng chính của giải pháp.

Đường viền

Trang mạng: github.com/heptio/contour
Giấy phép: Apache 2.0

Giải pháp này không chỉ dựa trên Envoy: nó được phát triển bởi cùng nhau với các tác giả của proxy phổ biến này. Một tính năng quan trọng là khả năng tách quyền kiểm soát tài nguyên Ingress bằng cách sử dụng tài nguyên IngressRoute CRD. Đối với các tổ chức có nhiều nhóm phát triển sử dụng cùng một cụm, điều này giúp tối đa hóa tính bảo mật khi làm việc với lưu lượng truy cập trong các vòng lân cận và bảo vệ chúng khỏi lỗi khi thay đổi tài nguyên Ingress.

Nó cũng cung cấp một tập hợp các phương pháp cân bằng mở rộng (có phản chiếu yêu cầu, tự động lặp lại, giới hạn tỷ lệ yêu cầu, v.v.), giám sát chi tiết luồng lưu lượng và lỗi. Có lẽ đối với ai đó, đó sẽ là một nhược điểm đáng kể khi thiếu hỗ trợ cho các phiên cố định (mặc dù công việc đã được tiến hành).

Sự xâm nhập của Istio

Trang mạng: istio.io/docs/tasks/traffic-manager/ingress
Giấy phép: Apache 2.0

Một giải pháp lưới dịch vụ toàn diện không chỉ là bộ điều khiển Ingress quản lý lưu lượng đến từ bên ngoài mà còn kiểm soát tất cả lưu lượng trong cụm. Dưới mui xe, Envoy được sử dụng làm proxy sidecar cho mỗi dịch vụ. Về bản chất, đây là một sự kết hợp lớn “có thể làm bất cứ điều gì”, và ý tưởng chính của nó là khả năng quản lý, khả năng mở rộng, bảo mật và minh bạch tối đa. Với nó, bạn có thể tinh chỉnh định tuyến lưu lượng truy cập, ủy quyền truy cập giữa các dịch vụ, cân bằng, giám sát, phát hành canary, v.v. Đọc thêm về Istio trong loạt bài viết "Quay lại microservice với Istio'.

Đại sứ

Trang mạng: github.com/datawire/đại sứ
Giấy phép: Apache 2.0

Một giải pháp khác dựa trên Envoy. Nó có các phiên bản miễn phí và thương mại. Nó được định vị là "hoàn toàn có nguồn gốc từ Kubernetes", mang lại những lợi thế tương ứng (tích hợp chặt chẽ với các phương thức và thực thể của cụm K8s).

bảng so sánh

Vì vậy, đỉnh cao của bài viết là bảng lớn này:

Tổng quan và so sánh các bộ điều khiển Ingress cho Kubernetes

Có thể nhấp vào để xem kỹ hơn và cũng có sẵn ở định dạng Google Sheets.

để tóm tắt

Mục đích của bài viết này là cung cấp sự hiểu biết đầy đủ hơn (tuy nhiên, không có nghĩa là toàn diện!) về lựa chọn nên đưa ra trong trường hợp cụ thể của bạn. Như thường lệ, mỗi bộ điều khiển đều có những ưu điểm và nhược điểm riêng…

Ingress cổ điển từ Kubernetes tốt vì tính khả dụng và tính khả dụng của nó, đủ các tính năng phong phú - trong trường hợp chung, nó phải là “đủ dùng cho mắt”. Tuy nhiên, nếu có yêu cầu cao hơn về tính ổn định, mức độ tính năng và sự phát triển, bạn nên chú ý đến Ingress với NGINX Plus và đăng ký trả phí. Kong có bộ plugin phong phú nhất (và theo đó, các cơ hội mà chúng cung cấp) và trong phiên bản trả phí thậm chí còn có nhiều plugin hơn. Nó có nhiều cơ hội để hoạt động như một Cổng API, cấu hình động dựa trên tài nguyên CRD, cũng như các dịch vụ Kubernetes cơ bản.

Với các yêu cầu ngày càng tăng đối với các phương thức cân bằng và ủy quyền, hãy xem Traefik và HAProxy. Đây là những dự án Nguồn mở, đã được chứng minh qua nhiều năm, rất ổn định và đang phát triển tích cực. Contour đã ra mắt được vài năm, nhưng nó vẫn còn quá trẻ và chỉ có các tính năng cơ bản được thêm vào trên Envoy. Nếu có các yêu cầu về sự hiện diện / nhúng WAF trước ứng dụng, thì bạn nên chú ý đến cùng một Lối vào từ Kubernetes hoặc HAProxy.

Và phong phú nhất về tính năng là các sản phẩm được xây dựng dựa trên Envoy, đặc biệt là Istio. Nó dường như là một giải pháp toàn diện "có thể làm bất cứ điều gì", tuy nhiên, điều này cũng có nghĩa là ngưỡng đầu vào cho cấu hình/khởi chạy/quản trị cao hơn đáng kể so với các giải pháp khác.

Chúng tôi đã chọn và vẫn sử dụng Ingress từ Kubernetes làm bộ điều khiển tiêu chuẩn, đáp ứng 80-90% nhu cầu. Nó khá đáng tin cậy, dễ cấu hình và mở rộng. Nói chung, trong trường hợp không có yêu cầu cụ thể, nó sẽ phù hợp với hầu hết các cụm / ứng dụng. Trong số các sản phẩm tương đối phổ biến và tương đối đơn giản, Traefik và HAProxy có thể được khuyến nghị.

PS

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com

Thêm một lời nhận xét