Tác tử AI và Kubernetes không thay thế nhau trong vòng điều khiển. Tác tử phù hợp với việc thu thập ngữ cảnh, phân tích tình huống bất định, đề xuất thay đổi và xác minh kết quả. Kubernetes cùng các bộ vận hành, công cụ chính sách và hệ thống tất định nên giữ quyền thực thi những thay đổi đã được phê duyệt.
Phân chia nội dung trong vòng điều khiển
Kubernetes vốn dựa vào các tác tử, nhưng không phải loại tác tử đang xuất hiện trong các cuộc thảo luận về trí tuệ nhân tạo. Một bộ điều khiển theo dõi trạng thái hiện tại, so sánh với trạng thái mong muốn đã khai báo rồi hành động để thu hẹp chênh lệch. Cơ chế này khiến tác tử AI và bộ vận hành Kubernetes có vẻ có thể thay thế nhau, nhưng chúng giải quyết hai phần khác nhau của vòng điều khiển.
Theo bài phân tích của The New Stack về tác tử AI và Kubernetes, trong 18 tháng qua, công cụ dành cho tác tử đã chuyển từ các dự án bên lề thành một phần của hệ sinh thái đám mây bản địa. Quỹ Điện toán Đám mây Bản địa đã tiếp nhận các khung tác tử vào nhóm dự án thử nghiệm. Nhóm ứng dụng Kubernetes cũng tiếp nhận Môi trường thử nghiệm tác tử làm dự án con nhằm vận hành khối lượng công việc tác tử an toàn hơn.
Các đội nền tảng đang phải xác định tác tử được phép thay đổi những gì trong cụm. Nếu mỗi yêu cầu hợp nhất mã lại đặt ra một ranh giới khác nhau, quyền suy luận và quyền thực thi sẽ được phân chia theo thói quen thay vì theo thiết kế.
Vai trò của bộ vận hành và tác tử
Bộ vận hành Kubernetes được xây dựng để có hành vi dự đoán được. Nó đối soát tài nguyên theo quy tắc đã mã hóa, thử lại thao tác thất bại và đưa hệ thống về trạng thái khai báo. Tác tử AI phù hợp với trường hợp mục tiêu đã rõ nhưng con đường đi đến mục tiêu chưa rõ. Nó có thể điều tra tình huống lạ, thu thập ngữ cảnh từ nhiều hệ thống, cân nhắc đánh đổi và đề xuất hành động.
Mô hình an toàn hơn là để tác tử cung cấp suy luận và ngữ cảnh, trong khi bộ vận hành, công cụ chính sách và các hệ thống tất định giữ quyền thực thi. Đây cũng là ranh giới cần lưu ý khi xây dựng lớp hạ tầng cho tác tử AI trên Kubernetes.
Lớp suy luận đặt phía trên Kubernetes
Lớp suy luận nên hoạt động phía trên Kubernetes thay vì thay thế vòng đối soát của nền tảng. Tác tử có thể đọc tài nguyên, nhật ký, sự kiện, chỉ số và tài liệu để chẩn đoán vấn đề. Những thao tác thay đổi cụm vẫn cần giới hạn quyền, chính sách và phê duyệt rõ ràng.
Dự án mã nguồn mở kagent thuộc nhóm dự án thử nghiệm của Quỹ Điện toán Đám mây Bản địa là một ví dụ. kagent chạy tác tử AI dưới dạng tài nguyên Kubernetes và kết nối chúng với Kubernetes, Helm, hệ thống quan sát cùng các công cụ tùy chỉnh. Tác tử có thể kiểm tra tài nguyên, lấy nhật ký và sự kiện, truy vấn chỉ số, tra cứu tài liệu rồi phối hợp với các tác tử chuyên biệt.
Khả năng truy cập công cụ không đồng nghĩa với quyền thực thi không giới hạn. Các thao tác đọc không nhạy cảm có thể chạy tự động. Những thay đổi như áp dụng, vá hoặc xóa tài nguyên nên yêu cầu phê duyệt rõ ràng. Cách phân quyền này cho phép tác tử điều tra trên phạm vi rộng mà không trao toàn quyền đối với cụm cho một quá trình suy luận còn bất định.
Vòng vận hành có kiểm soát
Vòng vận hành khi đó gồm sáu bước:
- Quan sát trạng thái hệ thống.
- Chẩn đoán nguyên nhân.
- Đề xuất thay đổi.
- Phê duyệt hành động.
- Đối soát trạng thái.
- Xác minh kết quả.
Ba bước đầu hưởng lợi từ khả năng suy luận của tác tử. Kubernetes cùng các bộ vận hành đảm nhiệm bước đối soát. Bước xác minh khép kín vòng điều khiển và tránh giả định rằng một thay đổi được hệ thống chấp nhận chắc chắn đã tạo ra kết quả mong muốn.
Karpenter cho thấy ranh giới khác biệt
Karpenter minh họa vì sao không nên giao toàn bộ vòng điều khiển cho mô hình ngôn ngữ. Karpenter tiếp tục cấp phát và đối soát tài nguyên bằng logic có thể dự đoán. Tác tử hoạt động phía trên, phân tích dữ liệu vận hành, tìm nguyên nhân và đề xuất một thay đổi có phạm vi hẹp.
Hãy xét một cụm nơi Karpenter cấp phát năng lực thành công nhưng đội nền tảng vẫn gặp nút ít được sử dụng, quá trình hợp nhất chậm, năng lực Spot biến động hoặc khối ứng dụng chờ lập lịch. Karpenter vốn là một bộ vận hành. Nó đánh giá các ràng buộc lập lịch rồi đối soát NodePool và NodeClaim. Thay logic này bằng một mô hình ngôn ngữ lớn sẽ khiến vòng điều khiển đáng tin cậy trở nên khó dự đoán hơn.
Tác tử điều tra phía trên Karpenter
Một tác tử vận hành dựa trên kagent nên hoạt động phía trên Karpenter. Nó có thể kiểm tra cấu hình NodePool và EC2NodeClass trong cụm EKS, các khối ứng dụng đang chờ, sự kiện Kubernetes, ngân sách gián đoạn khối ứng dụng, nhật ký Karpenter và chỉ số Prometheus liên quan. Từ các dữ liệu đó, tác tử tìm nguyên nhân khiến hành vi quan sát được khác với mục tiêu của đội vận hành.
Quá trình điều tra có thể phát hiện ngân sách gián đoạn khối ứng dụng đang chặn hợp nhất, chú thích cấm gián đoạn giữ một nút tại chỗ hoặc ngân sách gián đoạn ngăn việc di dời. Tác tử cũng có thể nhận ra thời gian chờ trước khi hợp nhất quá gắt với khối lượng công việc tăng giảm đột ngột, dẫn đến biến động không cần thiết. Một khả năng khác là các ràng buộc loại máy để lại quá ít lựa chọn cho Karpenter khi chọn năng lực Spot.
Đầu ra không nên là một đề nghị chung chung như tối ưu NodePool. Tác tử cần đưa ra bằng chứng, nêu rõ đánh đổi và tạo một bản vá cấu hình có phạm vi hẹp. Nếu sửa ngân sách gián đoạn của NodePool, đề xuất phải giải thích số nút tối đa có thể bị ảnh hưởng. Đề xuất thay đổi chính sách hợp nhất phải nêu khoảng thời gian theo dõi độ ổn định của khối lượng công việc. Khi mở rộng lựa chọn loại máy, bản vá vẫn phải giữ các ràng buộc về kiến trúc, vùng sẵn sàng và khối lượng công việc.
Bản vá sau đó đi qua cổng phê duyệt hoặc chính sách. Khi được chấp thuận, Karpenter dùng logic lập lịch và gián đoạn hiện có để đối soát. Tác tử theo dõi kết quả trong khoảng thời gian đã xác định, kiểm tra xem việc hợp nhất có cải thiện mà không làm tăng độ trễ của khối ứng dụng chờ hoặc gây gián đoạn có hại hay không. Nếu kết quả không đạt tiêu chí chấp nhận, hệ thống có thể đề xuất hoặc khởi tạo việc quay lui qua cùng một đường kiểm soát.
Argo CD thực thi nâng cấp, tác tử chuẩn bị căn cứ
Trong một đợt nâng cấp Helm, tác tử nên phân tích tác động và chuẩn bị căn cứ cho quyết định, còn Argo CD thực thi trạng thái đã được phê duyệt trong Git. Việc đồng bộ thành công chỉ xác nhận bản kê khai đã được áp dụng. Tác tử vẫn phải kiểm tra sức khỏe và các chỉ số của ứng dụng.
Với một đội nền tảng nâng cấp biểu đồ Helm do Argo CD quản lý, thay đổi phiên bản biểu đồ trong Git là phần đơn giản. Đánh giá tác động của thay đổi lên ứng dụng đang chạy mới là phần cần thêm suy luận. Argo CD hiển thị tài nguyên nào khác biệt, còn tác tử giải thích những khác biệt đó có ý nghĩa gì đối với khối lượng công việc.
Chuẩn bị thay đổi trước khi đồng bộ
Một phiên bản biểu đồ mới có thể đổi tên giá trị mà đội đang dùng để cấu hình phép kiểm tra trạng thái sẵn sàng. Tác tử so sánh ghi chú phát hành, giá trị hiện tại và bản kê khai đã kết xuất để xác định liệu bản nâng cấp có âm thầm quay về giá trị mặc định hay không. Kết quả cần trở thành một yêu cầu hợp nhất mã tập trung. Yêu cầu đó cập nhật phiên bản biểu đồ và các giá trị bị ảnh hưởng, giải thích rủi ro vận hành và xác định phép kiểm tra cần hoàn thành trước khi triển khai.
Sau khi yêu cầu được rà soát và hợp nhất, Argo CD kết xuất biểu đồ rồi đồng bộ bản kê khai theo chính sách của ứng dụng. Tác tử kiểm tra trạng thái đồng bộ, tình trạng sức khỏe của Argo CD và các chỉ số ứng dụng. Đồng bộ thành công chưa đủ để kết luận rằng độ trễ, tỷ lệ lỗi và tính sẵn sàng vẫn được duy trì.
Nếu phép kiểm tra thất bại, tác tử có thể đề xuất hoàn tác thay đổi trong Git hoặc lập kế hoạch khôi phục qua cùng quy trình phê duyệt. Kế hoạch này phải tính đến thay đổi dữ liệu hoặc lược đồ mà thao tác hoàn tác không thể đảo ngược. Trách nhiệm vẫn rõ ràng: tác tử điều tra, đề xuất và xác minh; Argo CD đối soát trạng thái mong muốn đã được phê duyệt.
Quyền tự chủ phải được mở rộng từng bước
Quyền tự chủ nên tăng theo bằng chứng vận hành, không tăng theo khả năng gọi công cụ. Đội nền tảng có thể bắt đầu bằng quyền đọc, sau đó cho phép tác tử tạo bản vá hoặc yêu cầu hợp nhất mã. Chỉ các hành động rủi ro thấp, có phạm vi rõ và có đường quay lui mới nên tiến tới tự động hóa.
Các giai đoạn mở rộng quyền
Đội vận hành có thể áp dụng mô hình này theo từng giai đoạn:
- Tác tử chỉ điều tra với quyền đọc.
- Ở giai đoạn tiếp theo, tác tử tạo bản vá hoặc yêu cầu hợp nhất mã để con người rà soát.
- Sau đó, tác tử thực hiện thay đổi rủi ro thấp đã được phê duyệt, với phạm vi và điều kiện quay lui rõ ràng.
- Những hành động đã được hiểu kỹ và có kết quả đo lường được mới chuyển sang tự động hoàn toàn.
Ranh giới quan trọng không nằm ở việc tác tử có thể gọi kubectl, Helm hay giao diện lập trình đám mây hay không. Mỗi hành động phải được cấp quyền, giới hạn phạm vi, quan sát được và có thể đảo ngược. Cách tiếp cận này phù hợp với câu hỏi rộng hơn về mức quyền nên trao cho AI trong vận hành bảo mật, nơi khả năng thực hiện hành động luôn phải đi cùng trách nhiệm kiểm soát.
Kubernetes có thể chạy các tác tử hỗ trợ quản lý chính Kubernetes, miễn là từng thành phần giữ đúng công việc phù hợp nhất. Tác tử suy luận về tình huống bất định. Bộ vận hành đối soát trạng thái khai báo. Chính sách đặt giới hạn cho cả hai. Con người vẫn chịu trách nhiệm về tốc độ hệ thống chuyển từ đề xuất sang tự chủ, đặc biệt khi tác tử bắt đầu tự chọn công cụ trong quy trình vận hành.
Hãy bắt đầu bằng một tác tử chỉ có quyền đọc, rồi mở rộng quyền khi đội của bạn đã đo được kết quả và kiểm soát được đường quay lui.
