Vai trò quản lý Istio Control Plane

Istio Control Plane có vai trò quản lý và điều phối toàn bộ hoạt động của Service Mesh, bao gồm việc kiểm soát lưu lượng mạng, bảo mật, và giám sát. Các chức năng chính của Istio Control Plane bao gồm:

Pilot: Đóng vai trò điều phối và quản lý lưu lượng giữa các microservices. Nó cung cấp cấu hình cho Envoy proxy để kiểm soát routing, cân bằng tải, retries, circuit breaking, và timeouts. Pilot cũng chịu trách nhiệm thực thi các chính sách giao tiếp giữa các dịch vụ dựa trên VirtualService và DestinationRule.
Galley (deprecated in newer versions): Quản lý cấu hình của Istio, xác nhận và phân phối cấu hình từ người dùng và Kubernetes đến các thành phần khác trong Control Plane. Galley giúp đảm bảo rằng các cấu hình này hợp lệ trước khi áp dụng.
Citadel (hiện được tích hợp vào Istiod): Đảm bảo bảo mật cho các dịch vụ bằng cách quản lý chứng chỉ và khóa cho các dịch vụ trong mesh. Nó tạo và quản lý chứng chỉ TLS để mã hóa và xác thực giao tiếp giữa các dịch vụ.
Mixer (deprecated in favor of Envoy native telemetry): Được sử dụng để quản lý các chính sách và thu thập telemetry. Mixer xử lý các yêu cầu policy như kiểm soát truy cập và kiểm soát tài nguyên, cũng như thu thập các số liệu và log từ các dịch vụ trong mesh.
Istiod: Tích hợp và thay thế các thành phần như Pilot, Citadel và Galley. Istiod đơn giản hóa Control Plane bằng cách gộp nhiều chức năng như cấu hình routing, bảo mật, và quản lý dịch vụ thành một dịch vụ duy nhất, giúp giảm độ phức tạp.
Injector: Tự động thêm Envoy proxy vào các pod của ứng dụng khi chúng được khởi tạo, dựa trên annotation trong Kubernetes. Injector giúp dễ dàng triển khai Envoy proxy mà không cần can thiệp thủ công.

Istio Pilot đóng vai trò quan trọng trong việc quản lý và phân phối cấu hình đến các Envoy proxies trong Istio Service Mesh. Pilot cung cấp cấu hình cho Envoy để thực hiện các chức năng như routing, cân bằng tải, retries, circuit breaking và bảo mật. Cách thức hoạt động của Pilot và quá trình cung cấp cấu hình tới Envoy diễn ra qua các bước chính sau:

1. Thu thập thông tin từ Kubernetes và người dùng

Pilot lấy thông tin từ hai nguồn chính:

Kubernetes API Server: Pilot giám sát các tài nguyên của Kubernetes như Service, Pod, và Endpoint để lấy thông tin về các dịch vụ và endpoint trong cluster. Nó cũng giám sát các tài nguyên Istio như VirtualService, DestinationRule, và Gateway.
Cấu hình của người dùng: Cấu hình của người dùng trong các manifest YAML được định nghĩa qua các tài nguyên của Istio (VD: VirtualService, DestinationRule). Các cấu hình này quy định chi tiết về routing, retries, circuit breaking, v.v.

2. Xử lý và tổng hợp cấu hình

Pilot tổng hợp thông tin từ Kubernetes và cấu hình của người dùng để xây dựng một bộ cấu hình thống nhất cho Envoy. Bộ cấu hình này bao gồm:

Routing: Chỉ định đường đi của các gói tin qua các dịch vụ (VirtualService).
Cân bằng tải (Load Balancing): Phân phối lưu lượng tới các backend (DestinationRule).
Circuit Breaking, Retries, Timeouts: Định nghĩa cách xử lý lỗi và kiểm soát lưu lượng.

3. Phân phối cấu hình tới Envoy thông qua xDS API

Pilot sử dụng giao thức xDS API (Discovery Service API) của Envoy để phân phối cấu hình tới tất cả các proxy Envoy trong mesh. Các phiên bản của xDS bao gồm:

LDS (Listener Discovery Service): Cung cấp thông tin về các Listener (điểm đầu vào mạng) mà Envoy cần tạo để lắng nghe kết nối.
RDS (Route Discovery Service): Cung cấp cấu hình về routing, cho biết lưu lượng cần được gửi đi đâu dựa trên đường dẫn và tiêu chí của yêu cầu.
CDS (Cluster Discovery Service): Cung cấp thông tin về các cluster (nhóm backend) mà Envoy có thể gửi lưu lượng tới.
EDS (Endpoint Discovery Service): Cung cấp danh sách endpoint (các IP và port của pod) mà Envoy có thể cân bằng tải tới.

Các cấu hình này được truyền tới Envoy qua cơ chế push khi có thay đổi, hoặc qua cơ chế pull khi Envoy proxy khởi động và yêu cầu cập nhật cấu hình từ Pilot.

4. Đảm bảo tính nhất quán và cập nhật liên tục

Pilot duy trì kết nối liên tục với các Envoy proxies để đảm bảo các cấu hình luôn được cập nhật khi có thay đổi. Mỗi khi có sự thay đổi về dịch vụ, endpoints, hoặc cấu hình người dùng (VD: thay đổi trong VirtualService hoặc DestinationRule), Pilot sẽ cập nhật cấu hình qua xDS API, đẩy bản cấu hình mới tới Envoy mà không làm gián đoạn lưu lượng đang xử lý.

5. Hỗ trợ cho Envoy dynamic configuration

Envoy có khả năng nạp lại cấu hình mà không cần khởi động lại thông qua xDS API. Pilot đảm bảo rằng Envoy luôn sử dụng cấu hình mới nhất mà không cần phải khởi động lại toàn bộ proxy, giúp tránh tình trạng downtime của các dịch vụ.

Sơ đồ tổng quát hoạt động của Pilot:

Pilot nhận thông tin từ Kubernetes và cấu hình người dùng.
Pilot xây dựng và tổng hợp cấu hình routing, policies, và endpoints.
Pilot phân phối cấu hình tới các Envoy proxies qua xDS API (LDS, RDS, CDS, EDS).
Envoy sử dụng cấu hình để điều phối lưu lượng theo các chính sách và quy tắc định nghĩa.

+--------------------+          +---------------------+           +---------------------+
|   Kubernetes API    |          |  User Configuration |           |      Istio Pilot     |
|    (Service, Pod,   |          |   (VirtualService,  |           |                     |
|     Endpoint, etc.) |          |    DestinationRule, |           |                     |
+--------------------+          |    Gateway, etc.)   |           +---------------------+
           |                                |                                 |
           |                                |                                 |
           +--------------------------------+---------------------------------+
                                        |
                                        |
                         1. Collect information from Kubernetes
                            and user-defined configurations.
                                        |
                                        V
                               +---------------------+
                               |    Istio Pilot      |
                               |    Processes info   |
                               |    and builds xDS   |
                               +---------------------+
                                        |
                                        |
                        2. Pilot sends configuration to Envoy via xDS API
                                        |
                                        V
                +----------------------------+  +----------------------------+
                |        Envoy Proxy 1        |  |        Envoy Proxy 2        |
                | (Sidecar Proxy for Service) |  | (Sidecar Proxy for Service) |
                +----------------------------+  +----------------------------+
                                        |
                        +--------------------------------------+
                        |           xDS API (LDS, RDS, CDS,    |
                        |               EDS)                   |
                        +--------------------------------------+

Flow of configuration update:

1. **Pilot gathers data**:
   - Pilot collects service, pod, and endpoint information from the **Kubernetes API**.
   - It also collects user-defined configurations such as **VirtualService**, **DestinationRule**, and **Gateway**.

2. **Pilot processes and builds config**:
   - Pilot processes this data and generates the routing and policy configuration.
   - The configuration is then formatted to be compatible with Envoy's xDS API (Listener Discovery Service, Route Discovery Service, Cluster Discovery Service, Endpoint Discovery Service).

3. **Pilot distributes configuration**:
   - Pilot uses xDS APIs to push the configuration to each **Envoy Proxy**. The main APIs include:
     - **LDS** (Listener Discovery Service): Configures how Envoy listens to incoming requests (IP, port).
     - **RDS** (Route Discovery Service): Defines how Envoy routes traffic to specific services.
     - **CDS** (Cluster Discovery Service): Defines the clusters (group of backends) that Envoy sends traffic to.
     - **EDS** (Endpoint Discovery Service): Provides the specific IP addresses and ports for each service (backend pods).

4. **Envoy Proxy updates dynamically**:
   - Envoy proxies receive this configuration from Pilot and apply the changes **dynamically** without restarting.
   - If new services are added, endpoints change, or routing rules are updated, Pilot sends the updated config to Envoy using the same xDS API.
   - Envoy applies the new configurations immediately, allowing for real-time updates in routing and policies without disrupting the existing traffic.

Cách thức cập nhật thông tin giữa Pilot và Envoy:

Real-time updates: Khi có thay đổi về dịch vụ, cấu hình routing, hoặc endpoint, Pilot sẽ gửi cấu hình mới đến Envoy mà không cần khởi động lại proxy.
Push-based mechanism: Pilot tự động đẩy cấu hình mới đến Envoy qua xDS APIs khi có thay đổi.
Continuous connection: Envoy luôn duy trì kết nối với Pilot để nhận các cấu hình mới nhất và đảm bảo hệ thống hoạt động liên tục.

Istio Control Plane validation:

Sau khi Kubernetes API Server lưu cấu hình hợp lệ, Istio Control Plane (Pilot, Galley trong phiên bản cũ, hoặc Istiod trong phiên bản mới) sẽ tiếp nhận và kiểm tra thêm các lỗi logic cụ thể liên quan đến Istio. Các bước kiểm tra gồm:

Validation sâu về routing và policies: Kiểm tra tính hợp lệ của các quy tắc routing, cấu hình DestinationRule, hay VirtualService có đúng logic không.
Kiểm tra sự nhất quán: Đảm bảo rằng các tài nguyên liên quan (như VirtualService và DestinationRule) không mâu thuẫn với nhau. Ví dụ, nếu VirtualService chỉ định một host không tồn tại, cấu hình có thể bị từ chối.

Nếu có lỗi logic, Istio sẽ không phân phối cấu hình đến các Envoy proxies, và bạn có thể xem các cảnh báo hoặc lỗi qua lệnh istioctl analyze hoặc trong logs của các thành phần Istio.

Nếu file YAML cấu hình sai:

Khi cấu hình sai (tùy mức độ), các kết quả sau có thể xảy ra:

a. Lỗi cú pháp hoặc thiếu trường quan trọng:

Nếu file YAML có cú pháp sai hoặc thiếu các trường bắt buộc, Kubernetes API Server sẽ từ chối cấu hình ngay lập tức và không lưu vào hệ thống. Bạn sẽ nhận được thông báo lỗi cụ thể và cần sửa cấu hình trước khi áp dụng lại.

b. Lỗi logic nhưng cấu hình được lưu:

Nếu cấu hình vượt qua các bước kiểm tra cơ bản nhưng có lỗi logic trong Istio (VD: cấu hình VirtualService trỏ tới host không tồn tại), Kubernetes vẫn lưu cấu hình, nhưng Istio Control Plane sẽ không phân phối cấu hình này tới Envoy proxies. Điều này có thể dẫn đến các lỗi như lưu lượng không được định tuyến đúng, hoặc các tính năng không hoạt động như mong đợi.

c. Sự cố về tính nhất quán:

Nếu các cấu hình khác nhau mâu thuẫn với nhau (VD: DestinationRule và VirtualService không tương thích), có thể gây ra lỗi trong việc điều phối lưu lượng. Các lỗi này thường có thể kiểm tra được qua logs của Pilot hoặc Istiod, và thông qua công cụ istioctl analyze.

Citadel trong Istio (bây giờ được gọi là Istio Agent hoặc là một phần của Istiod) là thành phần chịu trách nhiệm về bảo mật trong hệ thống mesh. Citadel giúp cung cấp và quản lý các chứng chỉ cho dịch vụ để thực hiện mã hóa TLS giữa các microservices và xác thực trong mesh.

1. Chức năng chính của Citadel

Citadel có các chức năng chính sau:

Cấp phát chứng chỉ (Certificate Authority): Citadel đóng vai trò như một CA (Certificate Authority) nội bộ trong hệ thống, cấp phát chứng chỉ X.509 cho các dịch vụ trong mesh.
Quản lý chứng chỉ: Citadel chịu trách nhiệm quản lý vòng đời của chứng chỉ, bao gồm gia hạn và thu hồi chứng chỉ.
Cung cấp TLS cho dịch vụ: Bằng cách cấp phát các chứng chỉ, Citadel cho phép các dịch vụ giao tiếp với nhau thông qua mTLS (mutual TLS), mã hóa lưu lượng truyền tải.
Xác thực và ủy quyền: Citadel hỗ trợ xác thực các dịch vụ, đảm bảo rằng các dịch vụ chỉ giao tiếp khi chúng đã được xác thực hợp lệ, và hỗ trợ RBAC (Role-Based Access Control) dựa trên chính sách bảo mật.

2. Cách Citadel hoạt động

a. Cấp phát chứng chỉ cho dịch vụ

Khi một pod khởi động: Mỗi khi một pod mới khởi chạy trong mesh, Envoy proxy trong pod sẽ yêu cầu chứng chỉ từ Citadel để thiết lập kết nối mTLS với các dịch vụ khác.
Gửi yêu cầu chứng chỉ: Envoy proxy gửi một yêu cầu chứng chỉ đến Citadel qua giao thức CSR (Certificate Signing Request).
Citadel cấp phát chứng chỉ: Citadel xác minh thông tin của pod, nếu hợp lệ, nó sẽ cấp phát một chứng chỉ X.509 và trả lại cho Envoy proxy. Chứng chỉ này được dùng để thực hiện giao tiếp bảo mật với các dịch vụ khác.
Lưu chứng chỉ: Envoy proxy lưu chứng chỉ này và sử dụng nó để mã hóa và xác thực khi giao tiếp với các dịch vụ khác.

b. Quản lý vòng đời của chứng chỉ

Gia hạn chứng chỉ: Chứng chỉ được cấp phát bởi Citadel có thời hạn (thường là 90 ngày). Citadel sẽ tự động theo dõi và gia hạn chứng chỉ khi gần hết hạn để đảm bảo dịch vụ không bị gián đoạn.
Thu hồi chứng chỉ: Trong trường hợp một dịch vụ không còn hợp lệ hoặc bị xóa, Citadel có thể thu hồi chứng chỉ của nó, ngăn không cho dịch vụ đó tiếp tục giao tiếp trong mesh.

c. Thiết lập mTLS giữa các dịch vụ

Envoy proxy thực hiện mTLS: Mỗi lần một dịch vụ gửi yêu cầu tới một dịch vụ khác trong mesh, Envoy proxy ở phía gửi sẽ bắt đầu một quá trình thiết lập kết nối mTLS với Envoy proxy ở phía nhận.
Kiểm tra chứng chỉ: Cả hai Envoy proxy đều sử dụng chứng chỉ do Citadel cấp để xác thực lẫn nhau. Nếu cả hai đều hợp lệ, phiên mTLS được thiết lập và dữ liệu sẽ được truyền tải một cách bảo mật.
Mã hóa dữ liệu: Tất cả các dữ liệu qua lại giữa các dịch vụ trong mesh sẽ được mã hóa bằng TLS, bảo vệ chống lại việc truy cập trái phép.

3. Tích hợp với các thành phần khác

Istiod: Trong các phiên bản Istio gần đây, Citadel đã được tích hợp vào Istiod, một thành phần trung tâm của Istio control plane. Istiod quản lý toàn bộ quy trình cấp phát và quản lý chứng chỉ thay cho Citadel.
Envoy Proxy: Envoy proxy ở mỗi pod làm việc trực tiếp với Citadel để lấy chứng chỉ và thiết lập kết nối mTLS với các proxy khác.
RBAC và Policy: Citadel làm việc chặt chẽ với hệ thống chính sách bảo mật của Istio để đảm bảo rằng chỉ các dịch vụ có quyền mới được phép giao tiếp với nhau.

4. Citadel với các hệ thống CA bên ngoài

Citadel có thể hoạt động như CA gốc nội bộ hoặc tích hợp với các hệ thống CA bên ngoài để cấp phát chứng chỉ. Ví dụ, Citadel có thể được cấu hình để sử dụng Let's Encrypt, Venafi, hoặc AWS Certificate Manager làm CA chính, thay vì tự cấp phát chứng chỉ nội bộ.

5. Lợi ích của Citadel trong Istio

Bảo mật mạnh mẽ với mTLS: Citadel cung cấp khả năng mã hóa tất cả lưu lượng giữa các dịch vụ trong mesh, bảo vệ dữ liệu và ngăn chặn các cuộc tấn công như man-in-the-middle.
Xác thực dịch vụ tự động: Mỗi dịch vụ trong mesh đều được xác thực tự động thông qua chứng chỉ mà Citadel cấp phát, giúp đảm bảo rằng chỉ các dịch vụ hợp lệ mới được phép giao tiếp với nhau.
Quản lý chứng chỉ tự động: Citadel tự động quản lý vòng đời của chứng chỉ, bao gồm cấp phát, gia hạn, và thu hồi chứng chỉ mà không cần sự can thiệp thủ công, giúp đơn giản hóa việc quản lý bảo mật trong mesh.

6. Ví dụ về quy trình mTLS với Citadel

Giả sử có hai dịch vụ A và B trong mesh:

Dịch vụ A gửi yêu cầu đến dịch vụ B.
Envoy proxy của dịch vụ A yêu cầu chứng chỉ từ Citadel.
Citadel cấp phát chứng chỉ X.509 cho Envoy proxy của dịch vụ A.
Envoy proxy của dịch vụ B cũng yêu cầu và nhận chứng chỉ từ Citadel.
Hai Envoy proxy thiết lập phiên mTLS bằng cách trao đổi chứng chỉ.
Nếu chứng chỉ hợp lệ, dịch vụ A và B sẽ bắt đầu trao đổi dữ liệu mã hóa qua kết nối bảo mật.

Vai trò quản lý của Istio Control Plane