Hiểu về EnvoyFilter Contexts trong Istio: SIDECAR_INBOUND, SIDECAR_OUTBOUND, GATEWAY và ANY

KiloKilo
7 min read

Khi triển khai Istio trên Kubernetes, một trong những tính năng mạnh mẽ mà nó cung cấp là khả năng tùy chỉnh Envoy proxy thông qua EnvoyFilter. Với EnvoyFilter, bạn có thể can thiệp vào cách lưu lượng được xử lý, từ việc thêm bộ lọc bảo mật, điều chỉnh cách lưu lượng được định tuyến cho đến cấu hình bộ nhớ đệm. Tuy nhiên, để hiểu rõ khi nào và tại sao nên sử dụng một số cấu hình nhất định, chúng ta cần nắm rõ khái niệm về context của EnvoyFilter.

+------------------------------------------------+
|                POD A (Ứng dụng A)              |
|    +---------------------------------------+   |
|    |        Envoy (SIDECAR_OUTBOUND)       |   |
|    +---------------------------------------+   |
|    |                                       |   |
|    |    Lưu lượng ra (Outbound Traffic)    |   |
|    |             (Tới Pod B)               |   |
|    +---------------------------------------+   |
+------------------------------------------------+
                    | 
                    | (Lưu lượng giữa các pods)
                    v 
+------------------------------------------------+
|                POD B (Ứng dụng B)              |
|    +---------------------------------------+   |
|    |        Envoy (SIDECAR_INBOUND)        |   |
|    +---------------------------------------+   |
|    |                                       |   |
|    |   Lưu lượng vào (Inbound Traffic)     |   |
|    |            (Từ Pod A)                 |   |
|    +---------------------------------------+   |
+------------------------------------------------+

EnvoyFilter là gì?

EnvoyFilter là một tài nguyên trong Istio cho phép bạn thêm hoặc sửa đổi cấu hình mặc định của Envoy proxy. Mặc dù Envoy đi kèm với một bộ cấu hình mạnh mẽ, việc sử dụng EnvoyFilter giúp bạn điều chỉnh chi tiết cách mà các yêu cầu HTTP và gRPC được xử lý trong mesh.

Ví dụ, bạn có thể chèn bộ lọc mới vào pipeline xử lý của Envoy hoặc thay đổi các bộ lọc đã tồn tại để tương tác với dữ liệu theo cách cụ thể hơn. Điều này cho phép bạn kiểm soát và tối ưu hóa việc xử lý lưu lượng ở mức proxy.

Tuy nhiên, điều quan trọng là phải hiểu khi nào và ở đâu các bộ lọc này sẽ áp dụng. Đó là lúc các ngữ cảnh (context) của EnvoyFilter trở nên quan trọng.

Hiểu về Context trong EnvoyFilter

Trong cấu hình EnvoyFilter của Istio, trường context được sử dụng để xác định phạm vi hoặc hướng của lưu lượng mà bộ lọc sẽ áp dụng. Dưới đây là những ngữ cảnh chính mà bạn sẽ gặp:

1. SIDECAR_INBOUND

  • Ý nghĩa: SIDECAR_INBOUND là ngữ cảnh áp dụng cho các lưu lượng đến (inbound) một pod trong mesh thông qua Envoy sidecar.

  • Khi nào sử dụng:

    • Bạn sử dụng SIDECAR_INBOUND khi muốn kiểm soát lưu lượng đi vào một pod cụ thể.

    • Ví dụ, nếu bạn có một dịch vụ cung cấp API và muốn kiểm tra, lọc hoặc thậm chí từ chối các yêu cầu đến dựa trên một số điều kiện, thì đây là ngữ cảnh phù hợp.

Ví dụ:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-inbound-filter
spec:
  workloadSelector:
    labels:
      app: my-app
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: INSERT_BEFORE
      value: 
        name: envoy.filters.http.jwt_authn
        typed_config:
          # cấu hình cụ thể cho bộ lọc JWT

Trong ví dụ này, bộ lọc kiểm tra JWT sẽ được chèn vào pipeline xử lý cho lưu lượng inbound của my-app

2. SIDECAR_OUTBOUND

  • Ý nghĩa: SIDECAR_OUTBOUND là ngữ cảnh áp dụng cho lưu lượng đi ra (outbound) từ một pod trong mesh.

  • Khi nào sử dụng:

    • Bạn sử dụng SIDECAR_OUTBOUND khi cần kiểm soát lưu lượng mà một pod gửi ra ngoài.

    • Điều này có thể hữu ích khi bạn cần điều chỉnh lưu lượng ra ngoài hoặc thực hiện các hoạt động như retrys, timeout, hoặc thêm xác thực cho các dịch vụ bên ngoài.

Ví dụ:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-outbound-filter
spec:
  workloadSelector:
    labels:
      app: my-app
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_OUTBOUND
    patch:
      operation: INSERT_BEFORE
      value: 
        name: envoy.filters.http.router
        typed_config:
          # cấu hình cho bộ lọc xử lý outbound
  • Bộ lọc này sẽ áp dụng khi lưu lượng rời khỏi my-app đi đến các dịch vụ khác trong mesh.

3. GATEWAY

  • Ý nghĩa: GATEWAY được áp dụng cho các lưu lượng đi qua Istio Gateway. Đây là lưu lượng từ bên ngoài vào cluster hoặc từ cluster ra ngoài thông qua Gateway.

  • Khi nào sử dụng:

    • Bạn sử dụng GATEWAY khi muốn can thiệp vào lưu lượng giữa bên ngoài và bên trong cluster.

    • Ví dụ: bạn có thể áp dụng các bộ lọc bảo mật cho các API công khai hoặc thiết lập caching cho các tài nguyên tĩnh.

Ví dụ:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-gateway-filter
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
    patch:
      operation: INSERT_BEFORE
      value: 
        name: envoy.filters.http.ratelimit
        typed_config:
          # cấu hình rate limiting cho Gateway
  • Bộ lọc rate limiting này sẽ áp dụng cho tất cả các yêu cầu đi qua Istio Gateway.

4. ANY

  • Ý nghĩa: ANY áp dụng cho tất cả các ngữ cảnh, bao gồm cả SIDECAR_INBOUND, SIDECAR_OUTBOUND, và GATEWAY.

  • Khi nào sử dụng:

    • Bạn sử dụng ANY khi muốn áp dụng cùng một cấu hình cho tất cả các hướng lưu lượng, bất kể lưu lượng đó đi vào hay đi ra, hoặc đi qua Gateway.

    • Điều này hữu ích khi bộ lọc cần áp dụng một cách tổng quát cho mọi lưu lượng.

Ví dụ:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-any-filter
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: ANY
    patch:
      operation: INSERT_BEFORE
      value: 
        name: envoy.filters.http.ext_authz
        typed_config:
          # cấu hình authz cho tất cả các lưu lượng
  • Bộ lọc này sẽ áp dụng cho tất cả lưu lượng inbound, outbound và qua Gateway mà không phân biệt nguồn gốc.

Khi nào nên sử dụng từng context?

  • SIDECAR_INBOUND: Khi bạn cần điều chỉnh hoặc kiểm tra lưu lượng đến (inbound) một pod từ các dịch vụ hoặc pod khác.

  • SIDECAR_OUTBOUND: Khi bạn muốn kiểm soát lưu lượng đi ra (outbound) từ một pod đến các dịch vụ khác.

  • GATEWAY: Khi bạn cần kiểm soát lưu lượng qua Gateway giữa bên ngoài và bên trong cluster.

  • ANY: Khi cấu hình cần áp dụng cho tất cả các hướng lưu lượng mà không phân biệt vị trí hoặc vai trò của nó.

Mô hình: SIDECAR_OUTBOUND với ServiceEntry

+------------------------------------------------+
|                POD A (Ứng dụng A)              |
|    +---------------------------------------+   |
|    |        Envoy (SIDECAR_OUTBOUND)       |   |
|    +---------------------------------------+   |
|    |                                       |   |
|    |    Lưu lượng ra (Outbound Traffic)    |   |
|    |          (Tới Dịch vụ bên ngoài)      |   |
|    +---------------------------------------+   |
+------------------------------------------------+
                    |
                    v
            Lưu lượng đi ra (Outbound)
                    |
                    v
   +----------------------------------------------------+
   |               Istio ServiceEntry                   |
   | (Định nghĩa kết nối với dịch vụ bên ngoài)         |
   |                                                    |
   |  Tên dịch vụ ngoài: external-service.com           |
   |  Địa chỉ IP dịch vụ: 203.0.113.5                   |
   +----------------------------------------------------+
                    |
                    v
   +------------------------------------------------+
   |        Dịch vụ bên ngoài (external-service)     |
   | (Dịch vụ nằm ngoài Istio mesh, ví dụ: API, DB)  |
   +------------------------------------------------+

Giải thích mô hình:

  1. POD A:

    • Ứng dụng A là dịch vụ phát sinh lưu lượng outbound cần gửi đến một dịch vụ bên ngoài mesh.

    • Trước khi lưu lượng rời khỏi POD A, nó sẽ đi qua Envoy Sidecar của POD A, nơi có ngữ cảnh SIDECAR_OUTBOUND áp dụng. Các bộ lọc có thể được sử dụng để điều chỉnh, kiểm tra hoặc thay đổi lưu lượng outbound trước khi gửi đi.

  2. Lưu lượng đi ra (Outbound Traffic):

    • Sau khi được xử lý bởi Envoy Sidecar tại ngữ cảnh SIDECAR_OUTBOUND, lưu lượng được gửi ra ngoài mesh.

  3. ServiceEntry:

    • ServiceEntry trong Istio là một tài nguyên cho phép bạn thêm các dịch vụ bên ngoài vào mesh, giúp các pod trong mesh có thể kết nối với các dịch vụ bên ngoài.

    • Ví dụ: Bạn có thể định nghĩa một ServiceEntry để trỏ đến dịch vụ có địa chỉ external-service.com với IP 203.0.113.5.

    • Lưu lượng từ POD A sẽ đi qua ServiceEntry, nơi xác định dịch vụ bên ngoài mà nó muốn kết nối.

  4. Dịch vụ bên ngoài:

    • Dịch vụ này có thể là một API, cơ sở dữ liệu, hoặc bất kỳ hệ thống nào nằm bên ngoài Istio mesh.

    • ServiceEntry đảm bảo rằng lưu lượng outbound từ POD A có thể kết nối đến dịch vụ này.

Luồng lưu lượng chi tiết:

  1. POD A (Ứng dụng A) phát sinh một yêu cầu HTTP hoặc gRPC cần gửi tới một dịch vụ bên ngoài mesh (ví dụ: external-service.com).

  2. Lưu lượng này sẽ đi qua Envoy Sidecar của POD A, nơi SIDECAR_OUTBOUND được áp dụng.

    • Tại đây, bạn có thể thêm các bộ lọc để thực hiện các hành động như xác thực, ghi log, hoặc thay đổi các thông số của lưu lượng outbound.

  3. Sau khi đi qua Envoy, lưu lượng được chuyển qua ServiceEntry, nơi nó được định tuyến đến dịch vụ bên ngoài dựa trên định nghĩa trong tài nguyên ServiceEntry.

  4. ServiceEntry chuyển lưu lượng đến đúng địa chỉ hoặc tên miền của dịch vụ bên ngoài (external-service.com).

  5. Cuối cùng, lưu lượng đến được dịch vụ bên ngoài nằm ngoài Istio mesh.

Ngữ cảnh sử dụng:

  • SIDECAR_OUTBOUND: Được sử dụng để kiểm soát hoặc điều chỉnh lưu lượng rời khỏi pod khi kết nối đến các dịch vụ bên ngoài thông qua ServiceEntry.
0
Subscribe to my newsletter

Read articles from Kilo directly inside your inbox. Subscribe to the newsletter, and don't miss out.

#istio#ServiceMesh

Written by

Kilo
Kilo