Mẫu Operator trong Kubernetes (Kubernetes Operator Pattern)

1. Tổng quan

Định nghĩa: Kubernetes Operator là phần mềm mở rộng mã hóa tri thức mà người vận hành vẫn thực hiện thủ công — cài đặt, cấu hình, mở rộng, khôi phục, nâng cấp, sao lưu ứng dụng — thành Custom Resource và vòng lặp điều hòa (Reconciliation) của controller, rồi cung cấp chúng dưới dạng mô hình quản lý khai báo của Kubernetes API.

Chỉ với các tài nguyên cơ bản của Kubernetes, ta đã có thể triển khai một cách khai báo các ứng dụng phi trạng thái như Pod, Service, Deployment. Tuy nhiên, các hệ thống có trạng thái và quy trình vận hành phức tạp như cơ sở dữ liệu, message broker, bộ nhớ đệm phân tán không thể vận hành an toàn chỉ bằng cách giữ đúng số lượng Pod. Lý do là cần tri thức miền về thứ tự khởi tạo, bầu chọn leader, đồng bộ bản sao, chuyển đổi dự phòng (failover), thay đổi lược đồ, kiểm chứng bản sao lưu cho đến khả năng tương thích phiên bản.

Theo truyền thống, những tri thức này nằm trong tài liệu và các lệnh thủ công của người vận hành. Vận hành dựa trên tài liệu phụ thuộc vào người có kinh nghiệm, thứ tự thực thi dễ bị xáo trộn khi xảy ra sự cố ban đêm hoặc triển khai lặp lại, và khó áp dụng nhất quán cùng một quy trình cho nhiều cụm (cluster). Operator biến tri thức này thành trạng thái mong muốn của đối tượng API và hành động tự động của controller, qua đó tách biệt "muốn gì" khỏi "đạt được bằng cách nào".

Điểm cốt lõi của Operator là nó khác với Helm chart — thứ chỉ đóng gói một sản phẩm cụ thể vào Kubernetes. Chart chủ yếu sinh manifest từ template và chèn giá trị tại thời điểm cài đặt. Ngược lại, Operator vẫn tiếp tục theo dõi tài nguyên API sau khi cài đặt, tính toán chênh lệch giữa trạng thái hiện tại và trạng thái mong muốn, tạo hoặc thay đổi các tài nguyên con cần thiết, rồi ghi kết quả vào status. Do đó, Operator vừa là tự động hóa triển khai, vừa là tự động hóa vận hành liên tục.

Trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer), thay vì liệt kê CRD, Custom Resource, Controller, cần giải thích rằng API khai báo, theo dõi dựa trên sự kiện, điều hòa lũy đẳng (idempotent), khả năng quan sát trạng thái và nguyên tắc đặc quyền tối thiểu kết nối với nhau thành một hệ thống vận hành thống nhất. Ngoài ra, cần đánh giá cả việc Operator không phải là tự động hóa vạn năng mà là một phần mở rộng làm tăng độ phức tạp và bề mặt sự cố, thì bài làm mới cân bằng.

A. Bối cảnh ra đời và sự cần thiết

Thứ nhất, độ khó vận hành của ứng dụng có trạng thái đã tăng cao. Container rất mạnh trong việc đóng gói tiến trình, nhưng không tự động bảo đảm độ bền, sao chép, tính nhất quán và thời điểm khôi phục của dữ liệu. Ví dụ, một cụm PostgreSQL phải đồng thời quản lý vai trò của instance chính và instance dự phòng, lưu trữ WAL, failover, endpoint kết nối và chính sách sao lưu.

Thứ hai, khi số lượng cụm và tenant tăng lên, sai lệch do thao tác thủ công ngày càng lớn. Nếu mỗi môi trường phát triển, kiểm chứng, vận hành có 3 cụm và có 5 nhóm, thì cùng một quy trình vận hành ứng dụng sẽ bị nhân bản ra tối đa 15 môi trường. Operator cho phép dù áp dụng cùng một CR thì chỉ chính sách theo môi trường là biến số, còn logic điều hòa chung được tái sử dụng, nhờ đó giảm sai lệch cấu hình.

Thứ ba, GitOps và vận hành hạ tầng khai báo đã lan rộng. Git lưu trữ YAML biểu diễn trạng thái mong muốn, và công cụ đồng bộ áp dụng nó vào cụm. Khi Operator mô hình hóa cả trạng thái miền của ứng dụng thành đối tượng API, phạm vi quản lý của GitOps mở rộng từ mức Deployment lên mức chính sách sao lưu, khôi phục, nâng cấp.

B. Mục tiêu cốt lõi

Mục tiêu của Operator không phải là loại bỏ hoàn toàn con người. Mà là tự động hóa các công việc lặp đi lặp lại có quy tắc phán đoán rõ ràng, còn các quyết định mà con người phải chịu trách nhiệm như rủi ro mất dữ liệu hay phê duyệt nghiệp vụ thì được giữ lại dưới dạng chính sách và quy trình phê duyệt. Phân định rõ phạm vi tự động hóa giúp giảm rủi ro Operator thực hiện các hành động phá hủy ngoài dự kiến khi có sự cố.

Operator có năm mục tiêu sau. Thứ nhất, người dùng phải có thể khai báo trạng thái mong muốn trong spec của CR. Thứ hai, controller phải quan sát trạng thái hiện tại và thực thi vòng lặp điều hòa để thu hẹp chênh lệch. Thứ ba, kết quả điều hòa và nguyên nhân thất bại phải được giải thích qua status và event. Thứ tư, phải có tính lũy đẳng — xử lý cùng một đầu vào nhiều lần vẫn cho kết quả ổn định. Thứ năm, phải nêu rõ ranh giới của nâng cấp, xóa, khôi phục, đồng thời giới hạn quyền hạn và tài nguyên.

2. Cấu trúc tổng thể của Operator

Operator là sự kết hợp giữa Custom Resource được lưu trong Kubernetes API và Custom Controller xử lý nó. CRD (CustomResourceDefinition) định nghĩa group, version, Kind, lược đồ và phạm vi của một loại tài nguyên mới, còn Custom Resource (CR) chứa trạng thái mong muốn thực tế theo định nghĩa đó. Controller nhận sự kiện watch từ API server hoặc đọc trạng thái định kỳ để điều hòa các tài nguyên con.

flowchart LR
    U[Người vận hành·GitOps] -->|apply| CR[Custom Resource\nspec: desired state]
    CRD[CRD\nAPI schema/version] --> API[Kubernetes API Server]
    CR --> API
    API --> W[watch queue]
    W --> C[Operator Controller\nreconcile loop]
    C -->|create/update| K[Deployment\nStatefulSet\nService\nPVC\nSecret]
    K --> R[Runtime ứng dụng]
    R -->|observed state| C
    C -->|status/events| API
    C --> M[Metrics·Logs·Traces]

Người dùng chỉ khai báo tài nguyên cấp cao như PostgresCluster. Controller chuyển dịch khai báo đó thành các tài nguyên con như StatefulSet, Service, ConfigMap, Secret, PodDisruptionBudget, tác vụ sao lưu. Khi gắn owner reference để chỉ rõ Operator là chủ thể trực tiếp quản lý tài nguyên con, ta có thể kiểm soát quan hệ phụ thuộc và thu gom rác (garbage collection) khi CR cấp trên bị xóa.

API server đóng vai trò nguồn sự thật duy nhất (single source of truth) của Operator. Controller không được chỉ tin vào bộ nhớ cục bộ mà phải đọc lại trạng thái hiện tại từ API server. Bởi vì dù controller khởi động lại, chỉ cần spec và các tài nguyên con còn tồn tại thì việc điều hòa phải tiếp tục được. Đặc tính này là tiền đề cho mở rộng ngang và khôi phục sự cố, nhưng cũng đòi hỏi thiết kế có tính đến tải của API server và việc kết nối lại watch.

A. Khác biệt giữa mô hình khai báo và script mệnh lệnh

Script mệnh lệnh chỉ thị thứ tự thực thi như "bây giờ đổi Deployment thành 3 replica, sau đó chạy lệnh migration". Ngược lại, mô hình khai báo biểu đạt mục tiêu như "cụm cơ sở dữ liệu này phải có 3 bản sao và thời gian lưu giữ bản sao lưu cụ thể". Bộ điều hòa chọn hành động an toàn tiếp theo để đi từ trạng thái hiện tại đến trạng thái mục tiêu, bất kể đã thực thi đến bước nào.

Vì khác biệt này, trong điều hòa, sự ổn định có thể lặp lại quan trọng hơn một lần thực thi thành công. Dù không nhận được kết quả yêu cầu do timeout mạng rồi gửi lại cùng yêu cầu, cũng không được sinh ra tài nguyên trùng lặp hay bản sao lưu trùng lặp. Cách làm phổ biến là đặt tên tài nguyên một cách tất định, kiểm tra sự tồn tại trước khi tạo, và cập nhật bằng cách chỉ patch các trường mong muốn.

Hạng mục	Script vận hành mệnh lệnh	Vận hành khai báo của Operator
Biểu đạt	Lệnh thực thi và thứ tự	Trạng thái mong muốn và chính sách
Thời điểm thực thi	Chủ yếu 1 lần khi triển khai/tác vụ	Theo sự kiện và điều hòa lại định kỳ
Khôi phục sự cố	Cần xác định điểm dừng và chạy lại thủ công	Quan sát lại trạng thái hiện tại rồi tiếp tục
Vị trí tri thức	Tài liệu, kinh nghiệm người vận hành	Mã controller, lược đồ CR
Kiểm soát thay đổi	Quyền thực thi script	Chính sách API, RBAC, GitOps
Rủi ro	Trạng thái trung gian không rõ ràng	Logic điều hòa sai bị lặp lại tự động

Operator mang tính khai báo không có nghĩa là mọi bước đều không phụ thuộc thứ tự. Nâng cấp phiên bản cơ sở dữ liệu có quy trình tuần tự như xác nhận sao lưu, chuyển sang chế độ chỉ đọc, nâng cấp bản sao, chuyển đổi instance chính. Trong trường hợp này, cần đặt upgradePolicy và điều kiện phê duyệt trong spec, ghi lại giai đoạn và kết quả quan sát vào status, đồng thời hiện thực thành một máy trạng thái tường minh bên trong vòng lặp điều hòa.

B. Thiết kế Custom Resource

spec của CR chứa mục tiêu người dùng yêu cầu và các chính sách có thể lựa chọn. status chứa trạng thái thực tế mà controller quan sát được, các điều kiện (conditions), trạng thái sẵn sàng của tài nguyên con và lỗi gần nhất. Nếu đầu vào do người dùng quản lý và đầu ra do controller tính toán bị trộn lẫn, sẽ phát sinh vấn đề GitOps hoàn tác status hoặc người dùng tùy ý ghi đè kết quả quan sát, vì vậy phải tách biệt hai vùng này.

Một lược đồ CR tốt dùng thuật ngữ miền nhưng không phơi bày quá mức chi tiết cài đặt bên trong. Ví dụ, cho người dùng khai báo replicas, storage, backup.retentionDays, version, còn tên StatefulSet nội bộ hay danh sách container sidecar thì để controller quyết định. Có như vậy thì dù thay đổi cách cài đặt, hợp đồng của CR vẫn được duy trì.

Lược đồ cần ghi rõ kiểu, tính bắt buộc, giá trị mặc định, phạm vi cho phép, mô tả và quy tắc chuyển đổi phiên bản. Các chính sách như có cho phép số replica bằng 0 hay không, có thể đặt thời gian lưu giữ 0 ngày hay không, có cấm thu nhỏ dung lượng lưu trữ hay không phải tồn tại đồng thời trong tài liệu và mã nguồn. Lược đồ có cấu trúc (structural schema) và kiểm tra phía máy chủ từ chối sớm đầu vào sai, nhưng các điều kiện chỉ phán đoán được lúc runtime như dung lượng thực tế của cơ sở dữ liệu hay trạng thái kho lưu trữ sao lưu bên ngoài vẫn thuộc phần kiểm tra của controller.

stateDiagram-v2
    [*] --> Pending: Tạo CR
    Pending --> Provisioning: Qua kiểm tra spec
    Provisioning --> Ready: Tài nguyên con sẵn sàng
    Provisioning --> Degraded: Thất bại một phần
    Degraded --> Provisioning: Thử lại·backoff
    Ready --> Scaling: Thay đổi spec
    Scaling --> Ready: Hội tụ replica/storage
    Ready --> Upgrading: Đổi version + phê duyệt
    Upgrading --> Ready: Kiểm tra tương thích·sức khỏe
    Ready --> Deleting: Yêu cầu xóa
    Deleting --> [*]: Hoàn tất xử lý finalizer

Điều kiện nên được quản lý theo cấu trúc máy đọc được gồm type, status, reason, message, lastTransitionTime thay vì chuỗi thông báo đơn thuần. Phân biệt Ready=False với Degraded=True giúp dashboard và cảnh báo biểu đạt được trạng thái có ý nghĩa. Cũng cần phân biệt lỗi tạm thời với lỗi cấu hình vĩnh viễn và thể hiện trong status việc nên thử lại hay cần người dùng sửa.

C. Controller và Reconciliation

Controller đưa sự kiện của tài nguyên cụ thể vào hàng đợi, lấy khóa ra khỏi hàng đợi, đọc trạng thái mới nhất của đối tượng tương ứng rồi điều hòa. Lý do không thực thi nguyên payload của sự kiện cũ mà đọc lại đối tượng mới nhất là vì nhiều thay đổi có thể dồn lại trong thời gian ngắn. Hàm điều hòa so sánh trạng thái mong muốn với trạng thái quan sát được, thực hiện thay đổi tối thiểu cần thiết và trả về thời điểm điều hòa lại.

Logic điều hòa thường tuân theo thứ tự sau. Thứ nhất, kiểm tra CR đích có đang bị xóa hay không. Thứ hai, nếu đang bị xóa thì thực hiện quy trình sao lưu và dọn dẹp tài nguyên bên ngoài mà finalizer yêu cầu. Thứ ba, nếu là đối tượng bình thường thì kiểm tra đầu vào và tính giá trị mặc định. Thứ tư, kiểm tra sự tồn tại và chênh lệch của tài nguyên con bằng owner reference và tên tất định. Thứ năm, thực hiện tạo, patch, xóa và quan sát readiness của ứng dụng. Thứ sáu, cập nhật status conditions và event, rồi quyết định thời điểm điều hòa tiếp theo.

Tính lũy đẳng không phải là "không làm gì cả" mà là tính chất trả về thành công mà không có tác dụng phụ bổ sung nếu đã đạt được cùng mục tiêu. Nếu Deployment con đã tồn tại nhưng chỉ khác image, thì không xóa toàn bộ rồi tạo lại mà chỉ điều chỉnh trường đó mới giữ được tính sẵn sàng. Khi yêu cầu sao lưu tới API bên ngoài, dùng idempotency key cho yêu cầu, định danh tác vụ và truy vấn trạng thái hoàn tất để việc thử lại do mạng không sinh ra tác vụ trùng lặp.

Việc thử lại phải dùng exponential backoff và độ trễ tối đa. Khi API server tạm thời lỗi mà tất cả Operator đều thử lại vô hạn ngay lập tức, sự cố sẽ bị khuếch đại. Ngược lại, nếu liên tục thử lại những lỗi người dùng phải sửa như chứng chỉ hết hạn hay phiên bản sai, chỉ làm tăng log và tải API. Cần xác định phân loại lỗi, giới hạn số lần thử lại, rate limit, queue depth làm tiêu chuẩn vận hành.

3. Thành phần cài đặt Operator và quy trình phát triển

Operator có thể được cài đặt bằng controller-runtime/Kubebuilder dựa trên Go, Kopf dựa trên Python, v.v. Quan trọng hơn ngôn ngữ là việc nêu rõ tính nhất quán bộ nhớ đệm của Kubernetes API, sự kiện trùng lặp, bầu chọn leader, RBAC, tương thích phiên bản và chiến lược kiểm thử. Framework hỗ trợ watch, thử lại, đăng ký scheme nhưng không tự động bảo đảm tính an toàn của chuyển trạng thái miền.

A. Quy trình phát triển

Phỏng vấn người vận hành về các công việc lặp lại và quy tắc phán đoán để xác định phạm vi tự động hóa.
Lập tài liệu về API miền mà người dùng sẽ khai báo, đối tượng sử dụng và vòng đời được hỗ trợ.
Quyết định API group/version/kind và phạm vi namespaced hay cluster-scoped.
Thiết kế lược đồ CRD cùng chính sách validation, defaulting, conversion.
Định nghĩa status conditions biểu thị trạng thái bình thường, bất thường và thành công một phần.
Thiết kế các tài nguyên con cần điều hòa cùng quan hệ owner reference và finalizer.
Cài đặt bằng mã các tình huống hội tụ bình thường, xóa, failover, nâng cấp và lỗi phụ thuộc bên ngoài.
Thực hiện theo từng bước kiểm thử đơn vị, kiểm thử fake API, envtest và kiểm thử tích hợp trên cụm thực.
Thiết lập RBAC tối thiểu và yêu cầu/giới hạn tài nguyên, đồng thời kiểm chứng chuỗi cung ứng cho image và các phụ thuộc.
Chuẩn bị dashboard, cảnh báo, runbook rồi triển khai dần dần lên cụm vận hành.

Ở giai đoạn đầu phát triển, nên bắt đầu với một loại tài nguyên và một luồng vận hành. Ví dụ, nếu đưa cùng lúc việc tạo, mở rộng, sao lưu, khôi phục, nâng cấp cơ sở dữ liệu vào thì máy trạng thái và tổ hợp lỗi sẽ bùng nổ. Trước tiên hãy ổn định việc tạo và quan sát readiness, sau đó bổ sung sao lưu và nâng cấp dưới dạng feature flag riêng hoặc chính sách tường minh.

B. Tài nguyên con và quyền sở hữu

Nếu người dùng trực tiếp sửa Deployment, Service, Secret, PVC do Operator tạo, hai chủ thể điều hòa sẽ xung đột. Cần đánh dấu rõ các trường controller quản lý, và cung cấp điểm mở rộng cho người dùng dưới dạng hợp đồng có giới hạn như các trường được phép của podTemplate hoặc chính sách patch. Lập tài liệu ranh giới quản lý giúp giảm xung đột giữa tự động khôi phục và thao tác thủ công của người vận hành.

Owner reference cho biết quan hệ giữa các đối tượng Kubernetes, nhưng tài nguyên đám mây bên ngoài hay tài khoản SaaS nằm ngoài cụm. Với những tài nguyên này, lưu định danh bên ngoài vào status và thực thi chính sách xóa trong finalizer. Nếu không nêu rõ khi xóa thì xóa ngay tài nguyên bên ngoài, giữ lại, hay xóa sau khi phê duyệt, việc xóa CR có thể dẫn đến mất dữ liệu.

Finalizer tạo cơ hội dọn dẹp trước sự kiện xóa. Nếu controller không gỡ được finalizer, CR sẽ nằm lâu ở trạng thái Terminating. Vì vậy, cần cung cấp trạng thái thử lại, timeout và quy trình buộc giữ lại để người vận hành có thể khôi phục thủ công ngay cả khi hệ thống bên ngoài gặp sự cố kéo dài.

C. Bảo mật và kiểm soát vận hành

Operator thường có quyền hạn rộng trên API server, nên khi bị xâm nhập thì toàn bộ cụm có thể gặp nguy hiểm. RBAC chỉ cho phép API group, resource, verb cần thiết và thu hẹp phạm vi namespace hết mức có thể. Chức năng đọc Secret để gửi tới kho sao lưu bên ngoài cần được cô lập bằng ServiceAccount và network policy riêng, đồng thời không để lại thông tin xác thực hay dữ liệu gốc trong log.

Image và Helm chart của Operator phải được kiểm chứng chữ ký, hash, SBOM, và các bản vá lỗ hổng cũng như thay đổi quyền hạn phải được ghi trong release note. Các Pod do Operator tạo cũng phải áp dụng security context, seccomp, hệ thống tệp chỉ đọc và chạy không đặc quyền. Cần quản lý không chỉ chuỗi cung ứng của bản thân controller mà cả các giá trị mặc định bảo mật của workload mà nó tạo ra.

Chỉ xem điều hòa thành công hay không là chưa đủ cho khả năng quan sát. Cần đo số lần và độ trễ reconcile, tồn đọng hàng đợi, lỗi gọi API, tỷ lệ Degraded theo điều kiện, độ trễ tác vụ bên ngoài và thời gian finalizer tồn đọng. Ví dụ, nếu Ready=False kéo dài 5 phút hoặc cùng một lỗi lặp lại 10 lần thì có thể gửi cảnh báo tới người vận hành dịch vụ.

Lĩnh vực vận hành	Chỉ số cốt lõi	Ví dụ cảnh báo/kiểm tra
Điều hòa	reconcile latency, error count	Độ trễ p95 và tỷ lệ lỗi trong 5 phút
Hội tụ	Điều kiện Ready, quan sát generation	Hội tụ trong 10 phút sau khi đổi spec
Ổn định	queue depth, API throttling	Tồn đọng hàng đợi và gia tăng 429
Dữ liệu	Sao lưu thành công, kiểm chứng khôi phục	Thời điểm kiểm thử khôi phục gần nhất
Bảo mật	Thay đổi RBAC, lỗ hổng image	Mở rộng quyền hạn và kiểm chứng chữ ký
Xóa	Thời gian finalizer tồn đọng	Terminating vượt quá 30 phút

4. Phân loại và tình huống áp dụng

Operator có thể được chia thành nhiều loại tùy theo đối tượng quản lý và độ phức tạp của trạng thái. Add-on Operator quản lý các chức năng của cụm như giám sát, chứng chỉ, lưu trữ, còn Application Operator quản lý việc cài đặt và vận hành một sản phẩm cụ thể. Cloud Resource Operator liên kết CR với tài nguyên của các API bên ngoài như AWS, Azure, GCP.

Operator có trạng thái biết thứ tự của sao chép, sao lưu, khôi phục, nâng cấp nên mang lại giá trị lớn nhất nhưng cũng mang rủi ro lớn nhất. Operator phi trạng thái có thể quản lý các tài nguyên tương đối đơn giản như gói cấu hình, chính sách, định tuyến. Người vận hành cần chọn mức độ tự động hóa dựa trên khả năng bị phá hủy của trạng thái đích và tác dụng phụ bên ngoài.

A. Tình huống vận hành cơ sở dữ liệu

Giả sử một dịch vụ đặt hàng giả định vận hành bản sao PostgreSQL trên 3 vùng sẵn sàng (availability zone). Khi khai báo replicas: 3, storage: 500Gi, backup.retentionDays: 14 trong CR PostgresCluster, Operator tạo StatefulSet và PVC, rồi quan sát trạng thái sao chép và tác vụ sao lưu. Khi instance chính gặp sự cố, Operator thăng cấp một trong các instance dự phòng đã đồng bộ và cập nhật Service endpoint, đồng thời phải ghi vào status khả năng mất dữ liệu và thời điểm khôi phục.

Tăng dung lượng lưu trữ từ 500Gi lên 800Gi nhìn chung là hướng mở rộng nên có thể tự động hóa, nhưng giảm từ 500Gi xuống 200Gi thì an toàn hơn là từ chối vì rủi ro mất dữ liệu. Khi đổi phiên bản từ 14 lên 15, có thể yêu cầu kiểm tra tương thích trước và xác nhận sao lưu thành công, đồng thời đặt trường phê duyệt riêng để chỉ thay đổi trong Git không lập tức kích hoạt nâng cấp. Tình huống này cho thấy Operator không phải là bộ sinh tài nguyên đơn thuần mà là bên thực thi các quy tắc an toàn của miền.

B. Tình huống messaging và bộ nhớ đệm

Operator cho message broker có thể quản lý số broker, định nghĩa topic/queue, hệ số sao chép, thời gian lưu giữ và phân bổ lại partition. Ví dụ, khi mở rộng topic sự kiện đặt hàng từ 6 partition lên 12, controller kiểm tra khả năng tương thích của consumer hiện có và chỉ số thông lượng rồi bổ sung partition dần dần. Yêu cầu xóa topic có thể được thiết kế để không thực thi khi chưa phê duyệt, sau khi kiểm tra offset của consumer và chính sách lưu giữ.

Operator bộ nhớ đệm phải phân biệt dữ liệu có thể tái tạo được hay cần tính bền vững. Tự động tạo lại Pod bộ nhớ đệm giúp tăng tính sẵn sàng, nhưng trong hệ thống coi bộ nhớ đệm như dữ liệu gốc thì phải kiểm soát riêng giá trị cũ và mất dữ liệu ghi trong quá trình failover. Biểu đạt đặc tính nghiệp vụ thành chính sách CR để giá trị mặc định của Operator không bị áp dụng như nhau cho mọi sản phẩm.

C. Tình huống tài nguyên đám mây

Khi dùng Cloud Operator, có thể liên kết vùng, engine, kích thước, network policy của CR DatabaseInstance với RDS, Cloud SQL, Azure Database qua API đám mây. Nếu tự động tạo 5 instance trong môi trường phát triển rồi xóa CR khỏi Git thì tài nguyên bên ngoài có thể bị xóa theo, vì vậy phải phân biệt deletionPolicy: Retain và Delete. Thiết kế giới hạn yêu cầu, ID tác vụ bất đồng bộ và chu kỳ truy vấn trạng thái để sự cố API bên ngoài không làm tắc hàng đợi điều hòa của Kubernetes.

Cấu trúc này cũng hỗ trợ trừu tượng hóa đa đám mây, nhưng nếu san phẳng chức năng của mọi đám mây vào một CR chung duy nhất thì sẽ đánh mất những khác biệt quan trọng. Cần tách trường chung với trường mở rộng theo nhà cung cấp, và với chức năng thực tế không được hỗ trợ thì không lặng lẽ bỏ qua mà phải trả về tường minh trạng thái Unsupported.

5. So sánh và công nghệ liên quan

A. So sánh Operator với Helm và GitOps

Helm mạnh về template và quản lý gói, cài đặt ban đầu nhanh. Tuy nhiên, diễn giải trạng thái sao chép của cơ sở dữ liệu hay thực hiện quy trình failover sau khi cài đặt không phải là vai trò của Helm. GitOps đồng bộ trạng thái khai báo trong Git với cụm và lưu lại lịch sử thay đổi. Operator nhận CR mà GitOps đã áp dụng và làm hội tụ cả trạng thái miền của ứng dụng.

Chính xác hơn là xem ba công nghệ này theo quan hệ phân tầng thay vì quan hệ thay thế. Có thể dùng Helm để cài chính Operator, dùng GitOps để triển khai CR và chính sách, còn Operator vận hành các tài nguyên con và tài nguyên bên ngoài. Khi đó, cần tách trường sở hữu để GitOps không ghi đè status hay các manifest con do Operator sở hữu.

Hạng mục	Helm	GitOps	Operator
Mối quan tâm chính	Đóng gói, template	Đồng bộ desired state	Tự động hóa vận hành miền
Tính liên tục	Tại thời điểm cài đặt/cập nhật	So sánh, đồng bộ liên tục	Quan sát, điều hòa liên tục
Phán đoán sự cố phức tạp	Hạn chế	Hạn chế	Có thể nhờ logic miền
Đầu vào	values và manifest	Kho Git	CR và chính sách
Rủi ro tiêu biểu	Độ phức tạp template	Drift, lạm dụng quyền	Hành động tự động sai

B. So sánh Operator với controller thông thường

Mọi Operator đều là mẫu mở rộng của controller, nhưng không phải controller nào cũng là Operator. Cũng có những controller điều chỉnh trạng thái chung của tài nguyên cơ bản Kubernetes như Deployment controller. Operator đặc biệt chỉ trường hợp kết hợp tri thức vận hành một ứng dụng cụ thể mà con người từng thực hiện với Custom Resource API. Do đó, trong bài làm cần phân biệt controller pattern là khái niệm cấp trên và operator pattern là khái niệm ứng dụng.

C. So sánh điều hòa dựa trên sự kiện với tác vụ batch

Script batch dễ kiểm tra toàn bộ môi trường theo một thứ tự nhất định, nhưng tốn chi phí thực thi lặp lại ngay cả khi môi trường không thay đổi. Điều hòa dựa trên sự kiện phản ứng nhanh với thay đổi của CR hoặc tài nguyên con liên quan, nhưng phải giả định trước khả năng mất, trùng lặp và đảo thứ tự sự kiện. Kết hợp thêm điều hòa lại định kỳ giúp khôi phục eventual consistency ngay cả khi sự kiện bị bỏ sót.

6. Chuyên sâu: Đánh đổi trong thiết kế và định hướng vận hành mới

Đánh đổi thứ nhất khi áp dụng Operator là trao đổi giữa lợi ích tự động hóa và độ phức tạp của mặt phẳng điều khiển (control plane). Khi một Operator quản lý 10 CRD và hàng trăm tài nguyên con, người vận hành nhận được nhiều chức năng chỉ với một tệp YAML đơn giản, nhưng đường truy vết nguyên nhân sự cố cũng dài ra. Ngay từ đầu, cần liên kết trạng thái và sự kiện của CR, owner reference của tài nguyên con được tạo và log của controller để mang lại trải nghiệm vận hành có thể giải thích được.

Đánh đổi thứ hai là trao đổi giữa trừu tượng hóa và bảo toàn chức năng của nhà cung cấp. CR chung giảm chi phí học tập của nhóm và chuẩn hóa nền tảng, nhưng nếu che giấu chức năng đặc thù của đám mây hay sản phẩm cơ sở dữ liệu thì có thể không đáp ứng được yêu cầu về hiệu năng và khôi phục. Cách làm thực tế là giới hạn mô hình chung ở vòng đời cốt lõi ổn định, còn phần mở rộng thì cô lập bằng provider profile tường minh.

Đánh đổi thứ ba là trao đổi giữa tự động khôi phục và an toàn dữ liệu. Với dịch vụ phi trạng thái, tạo lại ngay lập tức hầu như là an toàn, nhưng dữ liệu lưu trữ và tài nguyên tính phí bên ngoài không được xóa hay thay thế theo cùng quy tắc. Cần đưa điểm khôi phục, phê duyệt, lưu giữ, dry-run, khung thời gian thay đổi vào chính sách CR và thiết kế để Operator từ chối các lệnh nguy hiểm.

Trong kỹ thuật nền tảng (platform engineering) gần đây, cách tiếp cận coi Operator là sản phẩm của nền tảng nhà phát triển nội bộ (internal developer platform) trở nên quan trọng. Nhóm nền tảng không chỉ triển khai CRD mà còn phải cung cấp kèm ví dụ, quy tắc kiểm tra, chính sách phiên bản, SLO, cảnh báo, khả năng hiển thị chi phí và kênh hỗ trợ. Nhà phát triển yêu cầu bằng ngôn ngữ nghiệp vụ như DatabaseCluster, còn nhóm nền tảng có thể thực thi nhất quán các rào chắn (guardrail) về bảo mật, mạng, sao lưu phía sau.

Phiên bản của Operator SDK và framework ảnh hưởng đến khả năng tương thích Kubernetes API, xác thực webhook, bầu chọn leader và hành vi bộ nhớ đệm. Thay vì cố định và ghi nhớ một số phiên bản cụ thể, quản lý phạm vi phiên bản Kubernetes được hỗ trợ, CRD conversion, API deprecation và phương án rollback bằng chính sách phát hành mới là cách hiệu quả cho cả bài làm Kỹ sư chuyên nghiệp lẫn thực tiễn.

7. Các lưu ý và hàm ý

A. API và vòng đời

CRD là API công khai cho người dùng nên không dễ dàng thay đổi tên và ý nghĩa của trường. Khi thăng cấp từ v1alpha1 lên v1beta1, v1, cần định nghĩa khả năng tương thích, chuyển đổi, giá trị mặc định, thời điểm loại bỏ, đồng thời kiểm thử đường sao lưu và khôi phục của các CR hiện có. Đặt chính sách xóa và chính sách nâng cấp thành các trường riêng để nêu rõ ý định của hành vi phá hủy.

B. Lũy đẳng, hội tụ, cô lập sự cố

Hàm điều hòa phải coi sự kiện trùng lặp và việc khởi động lại là đường đi bình thường. API bên ngoài dùng timeout, circuit breaker, rate limit, truy vấn trạng thái tác vụ, đồng thời cô lập hàng đợi và worker để thay đổi quy mô lớn của một tenant không làm "bỏ đói" việc điều hòa của namespace khác. Phân biệt bằng reason trong status giữa lỗi nên thử lại và lỗi cần con người sửa.

C. Bảo mật, quyền hạn, chuỗi cung ứng

Áp dụng RBAC tối thiểu cho ServiceAccount của Operator và kiểm toán riêng việc truy cập Secret cũng như gọi mạng ra bên ngoài. Áp dụng kiểm tra chữ ký, SBOM, lỗ hổng của container image, security context lúc runtime và network policy cho cả Operator lẫn workload nó tạo ra. Nếu có webhook hoặc token API bên ngoài, đưa việc xoay vòng, thu hồi và ứng phó khi bị lộ vào quy trình vận hành.

D. Bảo vệ và khôi phục dữ liệu

Operator cho ứng dụng có trạng thái phải phân biệt "Pod đang Running" với "dữ liệu có thể khôi phục". Quan sát không chỉ tỷ lệ sao lưu thành công mà cả thời gian diễn tập khôi phục, điểm khôi phục, độ trễ sao chép và kết quả kiểm chứng toàn vẹn dữ liệu. Trong tình huống failover tự động có thể vi phạm RPO, cần có khả năng chọn dừng một cách thận trọng và chờ người vận hành phê duyệt.

E. Khả năng quan sát và trải nghiệm người vận hành

Liên kết nhất quán các điều kiện Ready, Progressing, Degraded, Kubernetes Event, log có cấu trúc và tên tài nguyên trong metric. Người vận hành phải biết được vì sao không hội tụ chỉ với kubectl describe, và dashboard phải hiển thị generation mong muốn, generation đã quan sát và thời điểm điều hòa gần nhất. Cung cấp kèm runbook cho các ngoại lệ mà Operator không tự xử lý được cùng các lệnh khôi phục thủ công.

F. Chiến lược áp dụng và đo lường hiệu quả

Đo thời gian triển khai, số lần thao tác thủ công, thời gian khôi phục sự cố, sai lệch cấu hình, tỷ lệ thay đổi thất bại trước và sau khi áp dụng. Ví dụ, dù rút ngắn quy trình thủ công triển khai cơ sở dữ liệu trên 15 cụm từ trung bình 40 phút xuống dưới 10 phút bằng việc áp dụng CR, nếu tỷ lệ kiểm thử khôi phục thành công giảm xuống thì không được đánh giá là thành công. Phải lấy cả tỷ lệ tự động hóa lẫn tính an toàn vận hành làm chỉ số.

8. Dự đoán hướng ra đề và chiến lược xây dựng bài làm

Đề thi có thể có dạng "Hãy giải thích mẫu Operator và bàn về vai trò của CRD, controller, vòng lặp điều hòa, ưu nhược điểm và phương án áp dụng". Ở phần đầu bài làm, đưa ra định nghĩa về mã hóa tri thức vận hành của con người và API khai báo, sau đó dùng sơ đồ cấu trúc tổng thể để thể hiện quan hệ giữa CRD, CR, API server, controller và tài nguyên con.

Ở thân bài, giải thích kèm nguyên lý các nội dung: tách spec/status, watch và reconciliation, tính lũy đẳng, finalizer, owner reference, RBAC, khả năng quan sát. So sánh khác biệt với Helm và GitOps theo tiêu chí thời điểm cài đặt, đồng bộ liên tục, tự động hóa vận hành miền, và đưa ra tình huống cơ sở dữ liệu, tài nguyên đám mây để trình bày đồng thời lợi ích của tự động hóa và rủi ro khi xóa.

Ở kết luận, đề xuất quản lý CRD như API công khai, áp dụng từng bước, đặc quyền tối thiểu, kiểm chứng sao lưu/khôi phục, đo lường SLO và chi phí. Kết thúc bằng hàm ý "không phải tự động hóa thì không cần người vận hành, mà là mã hóa công việc lặp lại và kiểm soát các quyết định rủi ro cao bằng phê duyệt và rào chắn" sẽ giúp bài làm có được sự cân bằng theo góc nhìn Kỹ sư chuyên nghiệp.

Tài liệu tham khảo

Tóm tắt một câu: Operator là mẫu tự động hóa vận hành gốc Kubernetes, liên tục làm hội tụ trạng thái mục tiêu của ứng dụng được khai báo bằng CRD thông qua vòng lặp điều hòa của một controller lũy đẳng chứa tri thức miền.