“Nguy hiểm là tên đệm của tôi,” Austin Powers, một người đàn ông bí ẩn quốc tế, thường nói. Nhưng những gì được các siêu đặc vụ và cơ quan tình báo đánh giá cao lại hoàn toàn không phù hợp với các dịch vụ máy tính, nơi mà sự nhàm chán còn tốt hơn nhiều so với nguy hiểm.
Và Istio, cùng với OpenShift và Kubernetes, khiến việc triển khai các vi dịch vụ trở nên thực sự nhàm chán và dễ đoán - và điều đó thật tuyệt. Chúng ta sẽ nói về điều này và nhiều điều khác trong bài thứ tư và cũng là bài cuối cùng trong loạt bài Istio.
Khi sự nhàm chán là đúng
Trong trường hợp của chúng tôi, sự nhàm chán chỉ xảy ra ở giai đoạn cuối, khi tất cả những gì còn lại là ngồi và xem quá trình. Nhưng để làm được điều này, trước tiên bạn cần phải cấu hình mọi thứ và rất nhiều điều thú vị đang chờ bạn ở đây.
Khi triển khai phiên bản mới của phần mềm, bạn nên xem xét tất cả các tùy chọn để giảm thiểu rủi ro. Chạy song song là một cách thử nghiệm rất hiệu quả và đã được chứng minh, đồng thời Istio cho phép bạn sử dụng “dịch vụ bí mật” (phiên bản ẩn của dịch vụ vi mô của bạn) để thực hiện việc này mà không can thiệp vào hệ thống sản xuất. Thậm chí còn có một thuật ngữ đặc biệt cho điều này - "Dark Launch", lần lượt được kích hoạt bởi một chức năng có tên gián điệp không kém là "phản ánh giao thông".
Xin lưu ý rằng câu đầu tiên của đoạn trước sử dụng thuật ngữ “triển khai” thay vì “giải phóng”. Bạn thực sự có thể triển khai—và tất nhiên, sử dụng—vi dịch vụ của mình bao nhiêu lần tùy thích. Dịch vụ này phải có khả năng nhận và xử lý lưu lượng truy cập, tạo ra kết quả cũng như ghi vào nhật ký và giám sát. Nhưng đồng thời, bản thân dịch vụ này không nhất thiết phải được đưa vào sản xuất. Việc triển khai và phát hành phần mềm không phải lúc nào cũng giống nhau. Bạn có thể triển khai bất cứ khi nào bạn muốn nhưng chỉ phát hành khi bạn đã sẵn sàng.
Tổ chức nhàm chán thật thú vị
Hãy xem quy tắc định tuyến Istio sau đây, quy tắc định tuyến tất cả các yêu cầu HTTP đến đề xuất microservice v1 (tất cả các ví dụ được lấy từ ), đồng thời phản chiếu chúng tới microservice v2 đề xuất:
Chú ý đến nhãn mirror: ở cuối màn hình - chính phần này sẽ thiết lập phản chiếu giao thông. Vâng, nó thật đơn giản!
Kết quả của quy tắc này sẽ là hệ thống sản xuất của bạn (v1) sẽ tiếp tục xử lý các yêu cầu đến, nhưng bản thân các yêu cầu đó sẽ được phản ánh không đồng bộ sang v2, nghĩa là các bản sao hoàn chỉnh của chúng sẽ ở đó. Bằng cách này, bạn có thể kiểm tra v2 trong điều kiện thực tế - trên dữ liệu và lưu lượng thực - mà không can thiệp vào hoạt động của hệ thống sản xuất dưới bất kỳ hình thức nào. Điều này có làm cho việc tổ chức kiểm tra trở nên nhàm chán? Vâng chắc chắn. Nhưng nó được thực hiện một cách thú vị.
Hãy thêm kịch tính
Xin lưu ý rằng trong mã v2 cần cung cấp các tình huống trong đó các yêu cầu gửi đến có thể dẫn đến thay đổi dữ liệu. Bản thân các yêu cầu được phản ánh một cách dễ dàng và minh bạch, nhưng việc lựa chọn phương pháp xử lý trong thử nghiệm là tùy thuộc vào bạn – và điều này hơi đáng lo ngại.
Hãy nhắc lại một điểm quan trọng
Khởi chạy bí mật với phản chiếu lưu lượng truy cập (Khởi chạy tối/Phản chiếu yêu cầu) có thể được thực hiện mà không ảnh hưởng đến mã dưới bất kỳ hình thức nào.
Thức ăn cho suy nghĩ
Điều gì sẽ xảy ra nếu nơi phản ánh các yêu cầu gửi một số yêu cầu đó không phải đến v1 mà tới v2? Ví dụ: một phần trăm của tất cả các yêu cầu hoặc chỉ các yêu cầu từ một nhóm người dùng nhất định. Và sau đó, đã xem cách v2 hoạt động, hãy chuyển dần tất cả các yêu cầu sang phiên bản mới. Hoặc ngược lại, trả lại mọi thứ về v1 nếu có vấn đề gì với v2. Tôi nghĩ nó được gọi là Triển khai Canary. và nếu nó có nguồn gốc từ Nga, nó có thể chứa tham chiếu đến ), và bây giờ chúng ta sẽ xem xét điều này chi tiết hơn.
Triển khai Canary ở Istio: đơn giản hóa việc vận hành
Cẩn thận và dần dần
Bản chất của mô hình triển khai Canary Deployment cực kỳ đơn giản: khi bạn khởi chạy một phiên bản phần mềm mới (trong trường hợp của chúng tôi là một vi dịch vụ), trước tiên bạn cấp quyền truy cập vào phiên bản đó cho một nhóm nhỏ người dùng. Nếu mọi việc suôn sẻ, bạn từ từ tăng nhóm này cho đến khi phiên bản mới bắt đầu hoạt động hoặc - nếu không - cuối cùng sẽ di chuyển tất cả người dùng sang nhóm đó. Bằng cách giới thiệu phiên bản mới một cách chu đáo và dần dần cũng như chuyển đổi người dùng sang phiên bản đó một cách có kiểm soát, bạn có thể giảm thiểu rủi ro và tối đa hóa phản hồi.
Tất nhiên, Istio đơn giản hóa việc triển khai Canary bằng cách cung cấp một số tùy chọn tốt để định tuyến yêu cầu thông minh. Và vâng, tất cả điều này có thể được thực hiện mà không cần chạm vào mã nguồn của bạn dưới bất kỳ hình thức nào.
Lọc trình duyệt
Một trong những tiêu chí định tuyến đơn giản nhất là chuyển hướng dựa trên trình duyệt. Giả sử bạn chỉ muốn các yêu cầu từ trình duyệt Safari chuyển sang v2. Đây là cách nó được thực hiện:
Hãy áp dụng quy tắc định tuyến này và sau đó sử dụng lệnh curl Chúng tôi sẽ mô phỏng các yêu cầu thực tế tới vi dịch vụ theo vòng lặp. Như bạn có thể thấy trong ảnh chụp màn hình, tất cả đều chuyển sang v1:
Lưu lượng truy cập trên v2 ở đâu? Vì trong ví dụ của chúng tôi, tất cả các yêu cầu chỉ đến từ dòng lệnh của chúng tôi nên đơn giản là nó không tồn tại. Nhưng hãy chú ý đến những dòng dưới cùng trong màn hình trên: đây là phản ứng đối với thực tế là chúng tôi đã thực hiện một yêu cầu từ trình duyệt Safari, từ đó tạo ra yêu cầu này:
Sức mạnh vô hạn
Chúng tôi đã viết rằng biểu thức chính quy cung cấp khả năng định tuyến rất mạnh mẽ cho các yêu cầu. Hãy xem ví dụ sau (chúng tôi nghĩ bạn sẽ hiểu nó làm gì):
Đến bây giờ có lẽ bạn đã biết biểu thức chính quy có thể làm được những gì.
hành động thông minh
Định tuyến thông minh, đặc biệt là xử lý tiêu đề gói bằng biểu thức thông thường, cho phép bạn điều khiển lưu lượng truy cập theo cách bạn muốn. Và điều này giúp đơn giản hóa đáng kể việc triển khai mã mới - nó đơn giản, không yêu cầu thay đổi mã và nếu cần, mọi thứ có thể nhanh chóng được trả về như cũ.
Quan tâm đến?
Bạn có muốn thử nghiệm Istio, Kubernetes và OpenShift trên máy tính của mình không? Đội đã chuẩn bị một cách xuất sắc về chủ đề này và công khai tất cả các tập tin đi kèm. Vì vậy, hãy tiếp tục và đừng phủ nhận bản thân bất cứ điều gì.
Istio Egress: đi ra qua cửa hàng lưu niệm
Bằng cách sử dụng Istio cùng với Red Hat OpenShift và Kubernetes, bạn có thể làm cho cuộc sống của mình với các dịch vụ vi mô trở nên dễ dàng hơn nhiều. Lưới dịch vụ của Istio được ẩn bên trong nhóm Kubernetes và mã của bạn chạy (hầu hết) một cách độc lập. Hiệu suất, dễ dàng thay đổi, truy tìm, v.v. – tất cả những điều này đều dễ sử dụng nhờ sử dụng thùng chứa sidecar. Nhưng điều gì sẽ xảy ra nếu microservice của bạn cần giao tiếp với các dịch vụ khác nằm bên ngoài hệ thống OpenShift-Kubernetes của bạn?
Đây là lúc Istio Egress đến giải cứu. Tóm lại, nó chỉ đơn giản cho phép bạn truy cập các tài nguyên (đọc: “dịch vụ”) không thuộc hệ thống nhóm Kubernetes của bạn. Nếu bạn không thực hiện cấu hình bổ sung thì trong môi trường Istio Egress, lưu lượng truy cập chỉ được định tuyến trong một cụm nhóm và giữa các cụm đó dựa trên bảng IP nội bộ. Và quá trình nhộng như vậy hoạt động tốt miễn là bạn không cần truy cập vào các dịch vụ từ bên ngoài.
Egress cho phép bạn bỏ qua các bảng IP trên, dựa trên quy tắc Egress hoặc trên một dải địa chỉ IP.
Giả sử chúng ta có một chương trình Java thực hiện yêu cầu GET tới httpbin.org/headers.
(httpbin.org chỉ là một tài nguyên thuận tiện để thử nghiệm các yêu cầu dịch vụ gửi đi.)
Nếu bạn nhập vào dòng lệnh curl http://httpbin.org/headers, chúng ta sẽ thấy như sau:
Hoặc bạn có thể mở cùng một địa chỉ trên trình duyệt:
Như bạn có thể thấy, dịch vụ ở đó chỉ trả về các tiêu đề được truyền cho nó.
Thay thế nhập khẩu trực tiếp
Bây giờ, hãy lấy mã Java của dịch vụ này, bên ngoài hệ thống của chúng tôi và tự chạy nó, ở đó, hãy nhớ lại, Istio đã được cài đặt. (Bạn có thể tự mình thực hiện việc này bằng cách liên hệ .) Sau khi đã xây dựng image phù hợp và khởi chạy nó trên nền tảng OpenShift, chúng ta sẽ gọi dịch vụ này bằng lệnh curl egresshttpbin-istioegress.$(minishift ip).nip.io, sau đó chúng ta sẽ thấy điều này trên màn hình:
Ối, chuyện gì đã xảy ra vậy? Mọi thứ chỉ hoạt động. Không tìm thấy nghĩa là gì? Chúng tôi chỉ làm điều đó cho anh ấy curl.
Mở rộng bảng IP ra toàn bộ Internet
Istio nên bị đổ lỗi (hoặc cảm ơn) vì điều này. Xét cho cùng, Istio chỉ là những thùng chứa sidecar chịu trách nhiệm phát hiện và định tuyến (và rất nhiều thứ khác mà chúng ta đã nói trước đó). Vì lý do này, bảng IP chỉ biết những gì bên trong hệ thống cụm của bạn. Và httpbin.org nằm ở bên ngoài nên không thể truy cập được. Và đây là lúc Istio Egress ra tay giải cứu - mà không cần có một chút thay đổi nào đối với mã nguồn của bạn.
Quy tắc Egress bên dưới buộc Istio phải tìm kiếm (nếu cần thì trên toàn bộ Internet) để tìm dịch vụ được yêu cầu, trong trường hợp này là httpbin.org. Như bạn có thể thấy từ tệp này (egress_httpbin.yml), chức năng ở đây khá đơn giản:
Tất cả những gì còn lại là áp dụng quy tắc này:
istioctl create -f egress_httpbin.yml -n istioegress
Bạn có thể xem quy tắc Đi ra bằng lệnh istioctl get egressrules:
Và cuối cùng chúng ta chạy lại lệnh quăn lại – và chúng tôi thấy rằng mọi thứ đều hoạt động:
Chúng tôi suy nghĩ cởi mở
Như bạn có thể thấy, Istio cho phép bạn tổ chức tương tác với thế giới bên ngoài. Nói cách khác, bạn vẫn có thể tạo các dịch vụ OpenShift và quản lý chúng thông qua Kubernetes, giữ mọi thứ trong các nhóm có thể tăng và giảm quy mô khi cần. Đồng thời, bạn có thể truy cập các dịch vụ bên ngoài môi trường của mình một cách an toàn. Và vâng, chúng tôi nhắc lại một lần nữa rằng tất cả điều này có thể được thực hiện mà không cần chạm vào mã của bạn dưới bất kỳ hình thức nào.
Đây là bài viết cuối cùng trong loạt bài về Istio. Hãy theo dõi - còn rất nhiều điều thú vị ở phía trước!
Nguồn: www.habr.com