Pods là các Worker, không phải Agent: Suy nghĩ lại về đơn vị triển khai cho AI Agent trên Kubernetes

Trang chủ InfoQ Tin tức Pods là Worker, không phải Agent: Suy nghĩ lại về đơn vị triển khai cho AI Agent trên Kubernetes DevOps Pods là Worker, không phải Agent: Suy nghĩ lại về đơn vị triển khai cho AI Agent trên Kubernetes Ngày 06/8/2026 3 phút đọc Bởi Mark Silvester Theo dõi chúng tôi trên Youtube 232K người theo dõi Linkedin 26K người theo dõi Instagram Mới RSS 19K người đọc X 57,1K người theo dõi Facebook 21K lượt thích Bluesky Mới Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường 1.25x 1.5x Thích Danh sách đọc Trong một bài đăng trên blog của CNCF, Lin Sun đã dựa trên công việc trong dự án kagent để lập luận rằng Pod có thể là đơn vị thực thi phù hợp cho một tác nhân (agent), nhưng không còn là đơn vị triển khai, nhận dạng hoặc vòng đời phù hợp. Những câu hỏi nảy sinh khi số lượng tác nhân tăng lên là những vấn đề quen thuộc: làm thế nào để cô lập một tác nhân khỏi tác nhân khác, làm thế nào để mỗi tác nhân có nhận dạng riêng, làm thế nào để thực thi các chính sách truy cập và mạng, làm thế nào để xem một tác nhân cá nhân đang làm gì và ai sở hữu một tác nhân cho đa thuê bao. Đây là những câu hỏi về nền tảng tác nhân chứ không phải câu hỏi về Kubernetes, mặc dù Kubernetes là nơi các câu trả lời phải được thể hiện. Một cách tiếp cận đơn giản là biến mỗi tác nhân thành một khối lượng công việc Kubernetes hạng nhất với Pod, Service và ServiceAccount riêng. Đây là cách tiếp cận mà kagent đã áp dụng sau khi ban đầu chạy nhiều tác nhân trong một thời gian chạy duy nhất. Cách tiếp cận này cung cấp sự cô lập quy trình và container, một nhận dạng ServiceAccount tích hợp vào xác thực và ủy quyền hiện có, khả năng áp dụng các cơ chế chính sách mạng và kiểm soát truy cập của Kubernetes, phân bổ nhật ký, số liệu và dấu vết cho từng tác nhân, cũng như lập lịch và quản lý tài nguyên gốc Kubernetes. kagent sau đó đã bổ sung hỗ trợ cách ly mạnh mẽ hơn thông qua dự án Kubernetes Agent Sandbox. Khó khăn là các tác nhân không hoạt động giống như các vi dịch vụ mà các trừu tượng này được thiết kế. Không giống như các dịch vụ được mong đợi luôn sẵn sàng, một tác nhân có thể chỉ thức dậy khi được giao một nhiệm vụ, chạy trong vài giây hoặc vài phút, sau đó ngồi không, khiến một Pod chuyên dụng cho mỗi tác nhân tiềm năng trở nên lãng phí. Các tác nhân cũng có thể tạo ra các tác nhân phụ để chạy các tác vụ phụ song song, hành động thay mặt người dùng và tạm dừng vô thời hạn trong khi chờ sự chấp thuận của con người. Pod là môi trường thực thi tuyệt vời, nhưng điều đó không khiến chúng trở thành trừu tượng vòng đời phù hợp cho công việc ngắn hạn, bùng nổ có hình dạng này. Một cách tiếp cận khác là ngừng coi mỗi tác nhân là một khối lượng công việc Kubernetes và thay vào đó giới thiệu một mặt phẳng điều khiển bên trên Kubernetes. Agent Substrate, được Google giới thiệu cùng với Agent Sandbox trong thông báo về Agent Sandbox và Agent Substrate, áp dụng cách tiếp cận này. kagent hỗ trợ cách tiếp cận này, như được mô tả trong hướng dẫn tích hợp Agent Substrate của kagent. Agent Sandbox cung cấp một môi trường thực thi biệt lập, trong khi Agent Substrate quản lý cách các tác nhân logic được đặt và di chuyển giữa các worker. Kubernetes tiếp tục quản lý Pod, Service, mạng, lưu trữ và tính toán, trong khi lớp bên trên quản lý vòng đời và vị trí của các tác nhân AI trên các worker thực thi. Các trừu tượng của nó phản ánh các khái niệm mà các kỹ sư nền tảng đã biết: một WorkerPool tương tự như một NodePool, Workers tương tự như Nodes và một ActorTemplate tương tự như đặc tả khai báo của một Pod. Kubernetes chỉ nhận biết WorkerPools và ActorTemplates; Workers và Actors tồn tại trong CLI và API riêng của Agent Substrate, với mỗi Worker được ánh xạ tới một Pod duy nhất. Một Actor, thực thể "hoạt động như" một tác nhân AI, là một đơn vị logic được lập lịch trên một Worker khi công việc đến và bị tạm dừng, tiếp tục hoặc loại bỏ theo yêu cầu của vòng đời. Điều này cho phép một nhóm Pod cố định, tồn tại lâu dài hỗ trợ nhiều tác nhân logic hơn so với việc sử dụng một Pod chuyên dụng, chạy liên tục cho mỗi tác nhân. Pod trở thành các worker thực thi, chứ không phải mô hình triển khai cho các tác nhân. Hậu quả vượt ra ngoài hiệu quả lập lịch. Sun lập luận rằng nếu một Actor có thể chạy trên bất kỳ Worker nào, thì nhận dạng có thể thuộc về ActorTemplate, không gian tên, người thuê và phiên bản chứ không phải t. một Pod hoặc Dịch vụ. Kiểm soát truy cập, chính sách mạng và quyền truy cập trong thời gian chạy cũng có thể cần được thể hiện ở cấp mẫu với các quyền ghi đè cho từng Actor. Quyền sở hữu, hạn ngạch và thanh toán trở nên khó hiểu hơn khi việc thực thi không còn là một-một với các Pod, và khả năng quan sát phải tuân theo tác nhân logic, liên kết nhật ký, dấu vết và bản ghi kiểm tra với Actor bất kể nó được lên lịch ở đâu. Tất cả những điều này không làm thay đổi vị thế của Kubernetes, vốn vẫn là nền tảng tiêu chuẩn công nghiệp cho các dịch vụ vi mô và khối lượng công việc suy luận ở quy mô lớn. Câu hỏi mở hẹp hơn: liệu Pod, đã chứng tỏ mình là một môi trường thực thi, có nên tiếp tục là đơn vị triển khai, nhận dạng và vòng đời cho các tác nhân AI hay không. Đó là điều mà Agent Substrate đang khám phá thông qua kagent. Podcast Kubernetes từ Google sau đó đã giới thiệu bài đăng của Sun trong bản tin tổng hợp hàng tuần của mình. Về tác giả Mark Silvester Đánh giá bài viết này Mức độ tiếp nhận Phong cách Đã liên hệ tác giả Nội dung này thuộc chủ đề DevOps Các chủ đề liên quan: Phát triển Kiến trúc & Thiết kế DevOps AI, ML & Kỹ thuật dữ liệu Điện toán đám mây