GALAXY TECH
Chuyên gia Công nghệ
Thứ sáu, 25/01/2019 | 00:00 GMT+7

Giới thiệu về Lưới dịch vụ

Lưới dịch vụ là một lớp cơ sở hạ tầng cho phép bạn quản lý giao tiếp giữa các dịch vụ vi mô của ứng dụng. Khi nhiều nhà phát triển làm việc với microservices, các lưới dịch vụ đã phát triển để làm cho công việc đó dễ dàng và hiệu quả hơn bằng cách hợp nhất các việc quản lý và quản trị chung trong một cài đặt phân tán.

Thực hiện một cách tiếp cận microservice đối với kiến trúc ứng dụng liên quan đến việc chia ứng dụng của bạn thành một tập hợp các dịch vụ được kết hợp lỏng lẻo. Cách tiếp cận này mang lại những lợi ích nhất định: các group có thể lặp lại các thiết kế và mở rộng quy mô một cách nhanh chóng, sử dụng nhiều công cụ và ngôn ngữ hơn. Mặt khác, microservices đặt ra những thách thức mới về độ phức tạp trong hoạt động, tính nhất quán của dữ liệu và bảo mật.

Lưới dịch vụ được thiết kế để giải quyết một số thách thức này bằng cách cung cấp mức độ kiểm soát chi tiết về cách các dịch vụ giao tiếp với nhau. Cụ thể, họ cung cấp cho các nhà phát triển một cách để quản lý:

  • Khám phá dịch vụ
  • Định tuyến và cấu hình lưu lượng
  • Mã hóa và xác thực / ủy quyền
  • Số liệu và giám sát

Mặc dù có thể thực hiện các việc này một cách nguyên bản với các bộ điều phối containers như Kubernetes , nhưng cách tiếp cận này liên quan đến việc quản lý và ra quyết định trực tiếp nhiều hơn khi so sánh với những giải pháp lưới dịch vụ như Istio và Linkerd cung cấp. Theo nghĩa này, các lưới dịch vụ có thể hợp lý hóa và đơn giản hóa quá trình làm việc với các thành phần chung trong một kiến trúc microservice. Trong một số trường hợp, chúng thậm chí có thể mở rộng chức năng của các thành phần này.

Tại sao lại là lưới dịch vụ?

Lưới dịch vụ được thiết kế để giải quyết một số thách thức vốn có đối với kiến trúc ứng dụng phân tán.

Các kiến trúc này đã phát triển ra khỏi mô hình ứng dụng ba tầng, mô hình này đã chia các ứng dụng thành một tầng web, tầng ứng dụng và tầng database . Về quy mô, mô hình này đã tỏ ra thách thức đối với các tổ chức đang có tốc độ phát triển nhanh chóng. Các cơ sở mã ứng dụng nguyên khối có thể trở thành những “ tảng bùn lớn” khó sử dụng, đặt ra những thách thức cho việc phát triển và triển khai.

Để giải quyết vấn đề này, các tổ chức như Google, Netflix và Twitter đã phát triển các thư viện " ứng dụng client " nội bộ để chuẩn hóa các hoạt động thời gian chạy trên các dịch vụ. Các thư viện này cung cấp tính năng cân bằng tải, ngắt mạch, định tuyến và đo từ xa - tiền thân của các khả năng của lưới dịch vụ. Tuy nhiên, họ cũng áp đặt các giới hạn đối với ngôn ngữ mà nhà phát triển có thể sử dụng và yêu cầu thay đổi trên các dịch vụ khi bản thân chúng được cập nhật hoặc thay đổi.

Một thiết kế microservice tránh một số vấn đề này. Thay vì có một cơ sở mã ứng dụng lớn, tập trung, bạn có một tập hợp các dịch vụ được quản lý riêng biệt đại diện cho một tính năng của ứng dụng của bạn. Lợi ích của phương pháp tiếp cận microservice bao gồm:

  • Nhanh nhẹn hơn trong việc phát triển và triển khai, vì các group có thể làm việc và triển khai các tính năng ứng dụng khác nhau một cách độc lập.
  • Các tùy chọn tốt hơn cho CI / CD, vì các dịch vụ nhỏ riêng lẻ có thể được kiểm tra và triển khai lại một cách độc lập.
  • Nhiều tùy chọn hơn cho ngôn ngữ và công cụ. Các nhà phát triển có thể sử dụng các công cụ tốt nhất cho các nhiệm vụ hiện có, thay vì bị hạn chế trong một ngôn ngữ hoặc bộ công cụ nhất định.
  • Dễ dàng mở rộng quy mô.
  • Cải thiện về thời gian hoạt động, trải nghiệm user và độ ổn định.

Đồng thời, microservices cũng tạo ra những thách thức:

  • Hệ thống phân tán yêu cầu những cách suy nghĩ khác nhau về độ trễ, định tuyến, quy trình làm việc không đồng bộ và lỗi.
  • Cài đặt microservice không nhất thiết phải đáp ứng các yêu cầu tương tự về tính nhất quán dữ liệu như cài đặt nguyên khối.
  • Mức độ phân phối cao hơn đòi hỏi các thiết kế hoạt động phức tạp hơn, đặc biệt khi liên quan đến giao tiếp dịch vụ với dịch vụ.
  • Phân phối các dịch vụ làm tăng diện tích bề mặt cho các lỗ hổng bảo mật.

Lưới dịch vụ được thiết kế để giải quyết những vấn đề này bằng cách cung cấp kiểm soát chi tiết và phối hợp đối với cách các dịch vụ giao tiếp. Trong các phần tiếp theo, ta sẽ xem xét cách các lưới dịch vụ tạo điều kiện giao tiếp giữa dịch vụ với dịch vụ thông qua khám phá dịch vụ, định tuyến và cân bằng tải nội bộ, cấu hình lưu lượng, mã hóa, xác thực và ủy quyền cũng như các chỉ số và giám sát. Ta sẽ sử dụng ứng dụng mẫu Bookinfo của Istio - bốn dịch vụ nhỏ cùng hiển thị thông tin về những cuốn sách cụ thể - làm ví dụ cụ thể để minh họa cách thức hoạt động của lưới dịch vụ.

Khám phá dịch vụ

Trong một khuôn khổ phân tán, cần phải biết cách kết nối với các dịch vụ và liệu chúng có khả dụng hay không. Các vị trí bản sao dịch vụ được chỉ định động trên mạng và thông tin về chúng liên tục thay đổi khi các containers được tạo và phá hủy thông qua việc tự động thay đổi tỷ lệ, nâng cấp và lỗi.

Trong lịch sử, đã có một số công cụ để thực hiện khám phá dịch vụ trong khuôn khổ dịch vụ vi mô. Các cửa hàng key-value như etcd đã được ghép nối với các công cụ khác như Registrator để cung cấp các giải pháp khám phá dịch vụ. Các công cụ như Consul đã lặp lại điều này bằng cách kết hợp kho key-value với giao diện DNS cho phép user làm việc trực tiếp với server hoặc nút DNS của họ.

Theo cách tiếp cận tương tự, Kubernetes cung cấp tính năng khám phá dịch vụ dựa trên DNS theo mặc định. Với nó, bạn có thể tra cứu các dịch vụ và cổng dịch vụ cũng như tra cứu IP ngược bằng cách sử dụng các quy ước đặt tên DNS phổ biến. Nói chung, bản ghi A cho dịch vụ Kubernetes trùng với mẫu này: service . namespace .svc.cluster.local . Hãy xem cách này hoạt động trong ngữ cảnh của ứng dụng Bookinfo. Ví dụ: nếu bạn muốn thông tin về dịch vụ details từ ứng dụng Bookinfo, bạn có thể xem mục nhập có liên quan trong console Kubernetes:

Dịch vụ chi tiết trong Kubernetes Dash

Điều này sẽ cung cấp cho bạn thông tin liên quan về tên Dịch vụ, không gian tên và ClusterIP mà bạn có thể sử dụng để kết nối với Dịch vụ của bạn ngay cả khi các containers riêng lẻ bị phá hủy và tạo lại.

Một lưới dịch vụ như Istio cũng cung cấp khả năng khám phá dịch vụ. Để thực hiện khám phá dịch vụ, Istio dựa vào giao tiếp giữa API Kubernetes, mặt phẳng điều khiển riêng của Istio, được quản lý bởi thành phần quản lý lưu lượng Pilot và mặt phẳng dữ liệu của nó, được quản lý bởi proxy sidecar Envoy . Thí điểm diễn giải dữ liệu từ server Kubernetes API để đăng ký các thay đổi ở các vị trí Pod. Sau đó, nó dịch dữ liệu đó thành một biểu diễn Istio chính tắc và chuyển tiếp nó đến các proxy phụ.

Điều này nghĩa là khám phá dịch vụ trong Istio là bất khả tri của nền tảng, ta có thể thấy điều này bằng cách sử dụng tiện ích bổ sung Grafana của Istio để xem lại dịch vụ details trong console dịch vụ của Istio:

Chi tiết Dịch vụ Istio Dash

Ứng dụng của ta đang chạy trên cụm Kubernetes, vì vậy ta có thể thấy thông tin DNS liên quan về Dịch vụ details , cùng với dữ liệu hiệu suất khác.

Trong kiến trúc phân tán, điều quan trọng là phải có thông tin cập nhật, chính xác và dễ định vị về các dịch vụ. Cả Kubernetes và các mạng lưới dịch vụ như Istio đều cung cấp các cách lấy thông tin này bằng các quy ước DNS.

Định tuyến và cấu hình lưu lượng

Quản lý lưu lượng truy cập trong một khuôn khổ phân tán nghĩa là kiểm soát cách lưu lượng truy cập đến cụm của bạn và cách nó được dẫn đến các dịch vụ của bạn.Bạn càng có nhiều quyền kiểm soát và tính cụ thể trong việc cấu hình lưu lượng truy cập bên ngoài và nội bộ, thì bạn càng có thể thực hiện được nhiều việc với cài đặt của bạn . Ví dụ: trong trường hợp bạn đang làm việc với triển khai canary, di chuyển ứng dụng sang version mới hoặc kiểm tra căng thẳng các dịch vụ cụ thể thông qua chèn lỗi, thì khả năng quyết định lưu lượng truy cập mà dịch vụ của bạn đang nhận được và nó đến từ đâu sẽ là key cho thành công của các mục tiêu của bạn.

Kubernetes cung cấp các công cụ, đối tượng và dịch vụ khác nhau cho phép các nhà phát triển kiểm soát lưu lượng truy cập bên ngoài vào một cụm: kubectl proxy , NodePort , Load Balancers , Ingress Controllers and Resources . Cả kubectl proxy và NodePort cho phép bạn nhanh chóng hiển thị các dịch vụ của bạn với lưu lượng bên ngoài: kubectl proxy tạo ra một server proxy cho phép truy cập vào nội dung tĩnh bằng đường dẫn HTTP, trong khi NodePort hiển thị một cổng được gán ngẫu nhiên trên mỗi nút. Mặc dù điều này cung cấp khả năng truy cập nhanh chóng, nhưng các hạn chế bao gồm việc phải chạy kubectl với quyền user đã xác thực, trong trường hợp kubectl proxy và thiếu tính linh hoạt trong các cổng và IP nút, trong trường hợp NodePort . Và mặc dù Bộ cân bằng tải tối ưu hóa tính linh hoạt bằng cách gắn với một Dịch vụ cụ thể, mỗi Dịch vụ yêu cầu Bộ cân bằng tải riêng, điều này có thể tốn kém.

Tài nguyên Ingress và Bộ điều khiển Ingress cùng nhau cung cấp mức độ linh hoạt và khả năng cấu hình cao hơn so với các tùy chọn khác này. Sử dụng Bộ điều khiển Ingress với Tài nguyên Ingress cho phép bạn định tuyến lưu lượng truy cập bên ngoài đến Dịch vụ và cấu hình định tuyến nội bộ và cân bằng tải. Để sử dụng Tài nguyên Ingress, bạn cần cấu hình Dịch vụ của bạn , Bộ điều khiển Ingress và LoadBalancer , và chính Tài nguyên Ingress, sẽ chỉ định các tuyến mong muốn đến Dịch vụ của bạn. Hiện tại, Kubernetes hỗ trợ Bộ điều khiển Nginx của riêng mình, nhưng cũng có các tùy chọn khác mà bạn có thể chọn, được quản lý bởi Nginx , Kong và những người khác.

Istio lặp lại trên Kubernetes Controller / Resource pattern với Istio Gateways và VirtualServices . Giống như Bộ điều khiển Ingress, Gateway xác định cách xử lý lưu lượng đến, chỉ định các cổng và giao thức được tiếp xúc để sử dụng. Nó hoạt động cùng với một VirtualService, xác định các tuyến đến các Dịch vụ trong lưới. Cả hai tài nguyên này đều truyền đạt thông tin cho Pilot, sau đó sẽ chuyển tiếp thông tin đó đến proxy Envoy. Mặc dù chúng tương tự như Bộ điều khiển và Tài nguyên Ingress, Cổng và Thiết bị ảo cung cấp một cấp độ kiểm soát khác đối với lưu lượng truy cập: thay vì kết hợp các lớp và giao thức Kết nối Hệ thống Mở (OSI) , Cổng và Thiết bị Ảo cho phép bạn phân biệt giữa các lớp OSI trong cài đặt của bạn . Ví dụ: bằng cách sử dụng VirtualServices, các group làm việc với các thông số kỹ thuật lớp ứng dụng có thể tách biệt mối quan tâm với các group hoạt động bảo mật làm việc với các thông số kỹ thuật lớp khác nhau. VirtualServices giúp bạn có thể phân tách công việc trên các tính năng ứng dụng rời rạc hoặc trong các domain tin cậy khác nhau và được dùng cho những việc như thử nghiệm canary, triển khai dần dần, thử nghiệm A / B, v.v.

Để trực quan hóa mối quan hệ giữa các Dịch vụ, bạn có thể sử dụng tiện ích bổ sung Servicegraph của Istio, tiện ích này tạo ra một biểu diễn động về mối quan hệ giữa các Dịch vụ bằng cách sử dụng dữ liệu lưu lượng truy cập thời gian thực. Ứng dụng Bookinfo có thể trông như thế này mà không áp dụng bất kỳ định tuyến tùy chỉnh nào:

Biểu đồ dịch vụ Bookinfo

Tương tự, bạn có thể sử dụng công cụ trực quan hóa như Weave Scope để xem mối quan hệ giữa các Dịch vụ của bạn tại một thời điểm nhất định.Ứng dụng Bookinfo không có định tuyến nâng cao có thể trông như thế này:

Bản đồ dịch vụ phạm vi dệt

Khi cấu hình lưu lượng ứng dụng trong khung phân tán, có một số giải pháp khác nhau - từ các tùy chọn root Kubernetes đến các lưới dịch vụ như Istio - cung cấp các tùy chọn khác nhau để xác định cách lưu lượng bên ngoài sẽ tiếp cận tài nguyên ứng dụng của bạn và cách các tài nguyên này sẽ giao tiếp với một khác.

Mã hóa và xác thực / ủy quyền

Một khuôn khổ phân tán tạo cơ hội cho các lỗ hổng bảo mật. Thay vì giao tiếp thông qua các cuộc gọi nội bộ local , như chúng sẽ làm trong một cài đặt nguyên khối, các dịch vụ trong kiến trúc microservice truyền thông tin, bao gồm cả thông tin quyền , qua mạng. Nhìn chung, điều này tạo ra một diện tích bề mặt lớn hơn cho các cuộc tấn công.

Bảo mật các cụm Kubernetes bao gồm một loạt các thủ tục; ta sẽ tập trung vào xác thực, ủy quyền và mã hóa. Kubernetes cung cấp các phương pháp tiếp cận bản địa cho từng điều sau:

  • Xác thực : Yêu cầu API trong Kubernetes được gắn với account user hoặc account dịch vụ, cần được xác thực. Có một số cách khác nhau để quản lý thông tin đăng nhập cần thiết: Mã thông báo tĩnh, Mã thông báo Bootstrap, certificate ứng dụng client X509 và các công cụ bên ngoài như OpenID Connect .
  • Ủy quyền : Kubernetes có các module ủy quyền khác nhau cho phép bạn xác định quyền truy cập dựa trên những thứ như role , thuộc tính và các chức năng chuyên biệt khác. Vì tất cả các yêu cầu đến server API đều bị từ chối theo mặc định, nên mỗi phần của một yêu cầu API phải được xác định bởi policy ủy quyền.
  • Mã hóa : Điều này có thể đề cập đến bất kỳ yếu tố nào sau đây: kết nối giữa user cuối và dịch vụ, dữ liệu bí mật, điểm cuối trong mặt phẳng điều khiển Kubernetes và giao tiếp giữa các thành phần cụm công nhân và thành phần chính. Kubernetes có các giải pháp khác nhau cho từng giải pháp sau:

Việc cấu hình các policy và giao thức bảo mật riêng lẻ trong Kubernetes yêu cầu đầu tư quản trị. Một lưới dịch vụ như Istio có thể hợp nhất một số hoạt động này.

Istio được thiết kế để tự động hóa một số công việc đảm bảo các dịch vụ. Mặt phẳng điều khiển của nó bao gồm một số thành phần xử lý bảo mật:

  • Thành : quản lý khóa và certificate .
  • Thí điểm : giám sát các policy xác thực và đặt tên, đồng thời chia sẻ thông tin này với proxy Envoy.
  • Mixer : quản lý ủy quyền và kiểm toán.

Ví dụ: khi bạn tạo Dịch vụ, Citadel nhận thông tin đó từ kube-apiserver và tạo certificate SPIFFE và khóa cho Dịch vụ này. Sau đó, nó chuyển thông tin này đến các thanh phụ Pods và Envoy để tạo điều kiện giao tiếp giữa các Dịch vụ.

Bạn cũng có thể triển khai một số tính năng bảo mật bằng cách bật TLS lẫn nhau trong quá trình cài đặt Istio. Chúng bao gồm nhận dạng dịch vụ mạnh mẽ cho giao tiếp xuyên và liên cụm, giao tiếp dịch vụ với dịch vụ và user đến dịch vụ an toàn và hệ thống quản lý khóa có thể tự động hóa việc tạo, phân phối và luân chuyển khóa và certificate .

Bằng cách lặp lại cách Kubernetes xử lý xác thực, ủy quyền và mã hóa, các lưới dịch vụ như Istio có thể hợp nhất và mở rộng một số phương pháp hay nhất được đề xuất để chạy một cụm Kubernetes an toàn.

Số liệu và Giám sát

Môi trường phân tán đã thay đổi các yêu cầu về số liệu và giám sát. Các công cụ giám sát cần phải thích ứng, tính đến những thay đổi thường xuyên đối với dịch vụ và địa chỉ mạng, đồng thời toàn diện, cho phép lượng và loại thông tin truyền giữa các dịch vụ.

Kubernetes bao gồm một số công cụ giám sát nội bộ theo mặc định. Các tài nguyên này thuộc về đường ống đo lường tài nguyên của nó, đảm bảo cụm chạy như mong đợi. Thành phần cvisor thu thập số liệu thống kê sử dụng mạng, bộ nhớ và CPU từ các containers và nút riêng lẻ và chuyển thông tin đó đến kubelet; đến lượt kubelet hiển thị thông tin đó thông qua API REST. Server số liệu lấy thông tin này từ API và sau đó chuyển nó đến trình kube-aggregator để định dạng.

Bạn có thể mở rộng các công cụ nội bộ và khả năng giám sát này bằng một giải pháp đo lường đầy đủ. Sử dụng một dịch vụ như Prometheus làm công cụ tổng hợp số liệu cho phép bạn xây dựng trực tiếp trên đầu đường dẫn số liệu tài nguyên Kubernetes. Prometheus tích hợp trực tiếp với c Marams thông qua các đại lý của chính nó, nằm trên các node . Dịch vụ tổng hợp chính của nó thu thập và lưu trữ dữ liệu từ các node và hiển thị nó thông qua console và API. Các tùy chọn lưu trữ và hiển thị bổ sung cũng có sẵn nếu bạn chọn tích hợp dịch vụ tổng hợp chính của bạn với các công cụ lưu trữ, ghi log và trực quan hóa backend như InfluxDB , Grafana , ElasticSearch , Logstash , Kibana và các công cụ khác.

Trong lưới dịch vụ như Istio, cấu trúc của đường ống số liệu đầy đủ là một phần trong thiết kế của lưới. Các sidecar đặc phái viên hoạt động ở level Pod truyền đạt các chỉ số cho Mixer , nơi quản lý các policy và đo từ xa. Ngoài ra, các dịch vụ Prometheus và Grafana được bật theo mặc định (mặc dù nếu bạn đang cài đặt Istio bằng Helm, bạn cần chỉ định granafa.enabled=true trong khi cài đặt). Như trường hợp với toàn bộ số liệu, bạn cũng có thể cấu hình các dịch vụ và triển khai khác cho các tùy chọn ghi log và xem.

Với các công cụ đo lường và trực quan hóa này, bạn có thể truy cập thông tin hiện tại về các dịch vụ và dung lượng công việc ở một nơi trung tâm. Ví dụ: chế độ xem global của ứng dụng BookInfo có thể trông giống như thế này trong console Istio Grafana:

Dịch vụ bookinfo từ Grafana dash

Bằng cách tái tạo cấu trúc của một đường ống đo lường đầy đủ Kubernetes và đơn giản hóa quyền truy cập vào một số thành phần phổ biến của nó, các lưới dịch vụ như Istio hợp lý hóa quá trình thu thập và hiển thị dữ liệu khi làm việc với một cụm.

Kết luận

Kiến trúc microservice được thiết kế để giúp cho việc triển khai và phát triển ứng dụng trở nên nhanh chóng và tin cậy . Tuy nhiên, sự gia tăng thông tin liên lạc giữa các dịch vụ đã thay đổi các phương pháp tốt nhất cho một số nhiệm vụ hành chính. Bài viết này thảo luận về một số tác vụ đó, cách chúng được xử lý trong ngữ cảnh riêng của Kubernetes và cách chúng có thể được quản lý bằng cách sử dụng lưới dịch vụ - trong trường hợp này là Istio.

Để biết thêm thông tin về một số chủ đề Kubernetes được đề cập tại đây, vui lòng xem các tài nguyên sau:

Thêm vào đó, Kubernetes và Istio hub tài liệu là nơi tuyệt vời để tìm kiếm thông tin chi tiết về các chủ đề thảo luận ở đây.

Tags:

Các tin liên quan