Tác giả: Vikram Venkataraman, Sudheer Sangunni, và Shivkumar Rajendran
Ngày phát hành: 09 APR 2026
Chuyên mục: Amazon Elastic Kubernetes Service, Artificial Intelligence, DevOps, Learning Levels, Technical How-to

Khả năng quan sát hiện đại đã phát triển đáng kể với sự xuất hiện của AIOps, làm thay đổi cách các tổ chức giám sát và duy trì cơ sở hạ tầng đám mây của họ. Các tác nhân thông minh ngày nay có thể tích hợp liền mạch với các công cụ giám sát, cơ sở tri thức và hệ thống quản lý sự cố để phân loại vấn đề và đề xuất các bước giảm thiểu với tốc độ chưa từng có. Mặc dù có những tiến bộ này, việc giảm Thời gian trung bình để xác định (MTTI) và Thời gian trung bình để giải quyết (MTTR) trong các kiến trúc microservices phức tạp vẫn là một thách thức. Trong một cuộc trò chuyện gần đây với một khách hàng đang vận hành một nền tảng AIOps tinh vi cho các hoạt động Kubernetes, họ đã bày tỏ một mối lo ngại quen thuộc: mặc dù các công cụ của họ rất mạnh mẽ, việc xác định nguyên nhân gốc rễ thực sự của các sự cố vẫn cực kỳ khó khăn. Giao tiếp giữa các Pod tạo ra một cấu trúc liên kết mạng thay đổi liên tục, khó lập bản đồ và hiểu mà không cần dựa vào các nhà cung cấp bên thứ ba hoặc cấu hình eBPF. Điều này làm tăng chi phí vận hành và độ phức tạp cho một quy trình khắc phục sự cố vốn đã đòi hỏi nhiều công sức.

Đây là lúc AWS DevOps Agent thay đổi cuộc chơi. Nó không chỉ thu thập thông tin chi tiết từ các tín hiệu telemetry mà còn xây dựng các biểu đồ tri thức thông minh để lập bản đồ các mối quan hệ phức tạp giữa các tài nguyên Amazon Elastic Kubernetes Service (Amazon EKS) của bạn. AWS DevOps Agent hoạt động như một kỹ sư DevOps luôn sẵn sàng của bạn, tự động điều tra các sự cố và xác định các cải tiến vận hành bằng cách tìm hiểu các tài nguyên và mối quan hệ của chúng. Nó hoạt động với các công cụ quan sát hiện có của bạn, runbooks, kho lưu trữ mã và các pipeline tích hợp liên tục và phân phối liên tục (CI/CD), tương quan dữ liệu telemetry, mã và triển khai để hiểu cấu trúc liên kết thực sự của các ứng dụng của bạn—cho dù chúng chạy trong môi trường đám mây hay môi trường lai. Đối với Amazon EKS nói riêng, tác nhân này vượt ra ngoài khả năng hiển thị cấp cụm, phát triển sự hiểu biết sâu sắc về các đối tượng Kubernetes và sự phụ thuộc lẫn nhau của chúng, từ Services đến Pods. Điều này cho phép nó đi qua các chuỗi phụ thuộc và xác định đối tượng bị lỗi sâu nhất có khả năng gây ra sự cố của bạn.

Trong bài đăng này, chúng tôi trình bày cách AWS DevOps Agent hoạt động—từ việc tạo cảnh báo đến xác định cụm EKS bị ảnh hưởng, xây dựng biểu đồ tri thức và khắc phục sự cố ứng dụng hoặc cơ sở hạ tầng, cuối cùng là giảm MTTI và MTTR cho các hoạt động Kubernetes của bạn.

Điều kiện tiên quyết

Hoàn thành các điều kiện tiên quyết sau để tiếp tục với bài đăng này.

• AWS Command Line Interface (AWS CLI) phiên bản 2. Để biết hướng dẫn cài đặt, hãy xem Cài đặt hoặc cập nhật lên phiên bản AWS CLI mới nhất.
• helm
• Kubectl
• Một cụm EKS với nhật ký Control plane được bật
• Cài đặt Load Balancer Controller
• AWS DevOps Agent Agentspace. Để biết hướng dẫn cài đặt, hãy tham khảo Tạo Agent Space

Triển khai ứng dụng bán lẻ mẫu

Đối với bài đăng này, chúng tôi sử dụng Containers Retail Store Sample Application. Đây là một ứng dụng microservices được xây dựng có mục đích để minh họa các kiến trúc đám mây hiện đại và các mẫu điều phối container. Ứng dụng này mô phỏng một nền tảng thương mại điện tử đầy đủ chức năng với các thành phần phân tán thể hiện các thách thức vận hành trong thế giới thực. Ứng dụng bao gồm năm microservices: UI Service, Catalog Service, Cart Service, Orders Service, Checkout Service. Mỗi microservice được xây dựng với các ngăn xếp công nghệ khác nhau để đại diện cho các môi trường sản xuất không đồng nhất.

Hình 1: Các thành phần của ứng dụng mẫu.

Hãy tiếp tục và triển khai ứng dụng mẫu này trong cụm EKS mà bạn đã cấp phép:

kubectl apply -f https://github.com/aws-containers/retail-store-sample-app/releases/latest/download/kubernetes.yaml
kubectl wait --for=condition=available deployments --all --timeout=120s
kubectl annotate svc ui service.beta.kubernetes.io/aws-load-balancer-scheme=internet-facing --overwrite

Bật quyền truy cập AWS DevOps Agent cho cụm Amazon EKS

Giờ đây, khi chúng ta đã triển khai ứng dụng mẫu, hãy tích hợp cụm này với AWS DevOps Agent để khắc phục sự cố. Bạn có thể bật AWS DevOps Agent để mô tả các đối tượng cụm Kubernetes của bạn, truy xuất nhật ký Pod và các sự kiện cụm, cho các cụm Amazon EKS (chỉ có thể truy cập bằng VPC). Agent Space phải có quyền truy cập vào cụm EKS. Để cung cấp quyền truy cập, chúng ta phải lấy vai trò của Agent Space và sử dụng vai trò đó trong bảng điều khiển EKS để thêm một mục nhập truy cập vào cụm EKS.

Từ Agent Spaces, chọn Agent Space cần quyền truy cập vào cụm Amazon EKS và chọn nút View Details để mở chi tiết của Agent Space.

Mở tab Capabilities, và trong phần Cloud, chọn primary source và chọn Edit. Thao tác này sẽ mở nguồn tài khoản chính và ghi lại vai trò được hiển thị trong trường Role Name. Đây là vai trò cần quyền truy cập vào cụm Amazon EKS.

Trên bảng điều khiển EKS, chọn cụm mà bạn cần cung cấp quyền truy cập cho AWS DevOps agent và mở tab Access.

Trong danh sách IAM Access Entries, chọn nút create để tạo một mục nhập Access mới.

Đối với IAM Principal ARN, chọn vai trò từ Agent Space đã được ghi lại từ phần trước và chọn Next.

Trong Access Policies, chọn AmazonAIOpsAssistantPolicy và cung cấp phạm vi truy cập là Cluster. Sau đó chọn nút Add Policy để thêm chính sách đã chọn và chọn nút Next.

Màn hình Review and Create sẽ hiển thị các chi tiết sau. Chọn nút Create để thêm mục nhập truy cập.

Điều này hoàn tất việc thiết lập cụm EKS và mục nhập EKS này cung cấp quyền truy cập cho DevOps agent vào cụm. Trong môi trường có nhiều cụm, bạn có thể sử dụng CLI, Terraform hoặc GitOps để tạo các mục nhập truy cập trong các cụm.

Sau khi mục nhập truy cập được thêm, các đối tượng Kubernetes sẽ có sẵn cho DevOps agent Topology Sources.

Ngoài tổng quan về các tài nguyên được phát hiện, bạn cũng có thể xem sơ đồ bản đồ dịch vụ của các đối tượng Kubernetes khác nhau tương tác giữa các namespace bằng cách sử dụng tính năng Learned Topology của AWS DevOps agent.

Learned topology là một biểu đồ tri thức được tạo tự động, lập bản đồ các thực thể và mối quan hệ trong môi trường ứng dụng của bạn thông qua khám phá tài nguyên, phát hiện mối quan hệ, lập bản đồ mã/triển khai và lập bản đồ hành vi quan sát, liên tục phát triển khi tác nhân hoàn thành nhiều tác vụ hơn.

Để trực quan hóa các đối tượng EKS, hãy làm theo các bước dưới đây:

1. Điều hướng đến bảng điều khiển truy cập Operator của Agent Space của bạn và nhấp vào tab Topology.
2. Chọn bộ lọc chế độ xem ưa thích của bạn: Learned
3. Khám phá biểu đồ tri thức tương tác nơi các nút đại diện cho các đối tượng Kubernetes, các đường hiển thị các kết nối.

Giờ đây, khi chúng ta đã tìm hiểu cách DevOps Agent tích hợp với Amazon EKS và các khả năng mạnh mẽ mà nó mang lại cho các hoạt động cụm, hãy khám phá cách tích hợp này giải quyết các thách thức trong thế giới thực mà các nhóm nền tảng phải đối mặt hàng ngày.

Kịch bản 1 – Khắc phục sự cố khả dụng của ứng dụng Kubernetes bằng DevOps Agent

Trong kịch bản này, chúng tôi trình bày cách AWS DevOps Agent tự động điều tra sự cố khả dụng của ứng dụng Kubernetes. Bạn sẽ thấy cách tác nhân:

• Tự động kích hoạt các cuộc điều tra khi các kiểm tra sức khỏe bên ngoài phát hiện lỗi
• Xây dựng biểu đồ cấu trúc liên kết lập bản đồ các mối quan hệ giữa Amazon Route 53, Network Load Balancer, Kubernetes Services và Pods
• Tương quan telemetry đa lớp trên các chỉ số cơ sở hạ tầng AWS, các sự kiện Kubernetes và nhật ký container
• Đi qua các chuỗi phụ thuộc từ điểm cuối bên ngoài xuống đến Pod bị lỗi cụ thể
• Xác định nguyên nhân gốc rễ bằng cách phân tích trạng thái Pod, nhật ký container và các thay đổi triển khai gần đây
• Tạo các kế hoạch giảm thiểu có thể hành động với các bước khắc phục cụ thể

Để trải nghiệm quy trình khắc phục sự cố tự động này, chúng tôi thiết lập một môi trường mô phỏng. Khi thiết lập thành công, môi trường sẽ có các thành phần sau:

1. Kiểm tra sức khỏe Route 53 liên tục giám sát điểm cuối UI Network Load Balancer (HTTP/80) cứ sau 30 giây
2. Amazon CloudWatch Alarm – retail-store-ui-endpoint-down kích hoạt khi kiểm tra sức khỏe thất bại trong hai khoảng thời gian liên tiếp
3. Hàm AWS Lambda xử lý cảnh báo, tạo tải trọng webhook được ký HMAC và gọi DevOps Agent
4. DevOps Agent nhận webhook, khởi tạo một cuộc điều tra và truy vấn EKS API, Kubernetes API, CloudWatch Logs và CloudWatch Metrics

Bây giờ chúng ta hãy triển khai môi trường. Để tự động kích hoạt các cuộc điều tra của DevOps Agent, chúng ta sử dụng hàm lambda để gọi webhook của tác nhân. Để tìm nạp webhook, hãy hoàn thành các bước sau:

Bước 1: Lấy thông tin webhook của DevOps Agent

1. Điều hướng đến Agent Space của bạn trong bảng điều khiển AWS DevOps Agent.
2. Chuyển đến tab Capabilities.
3. Trong phần Webhook, chọn Configure.
4. Chọn Generate webhook để tạo thông tin xác thực HMAC.
5. Lưu URL và secret của webhook. Bạn sẽ cần chúng cho bước tiếp theo.

Bước 2: Triển khai

Giải nén tệp tar, cấu hình các biến môi trường và chạy tập lệnh triển khai để tạo tất cả các tài nguyên cần thiết.

git clone https://github.com/aws-samples/Amazon-prometheus-bedrock-agent-example.git
cd Amazon-prometheus-bedrock-agent-example/devops-agent
tar -xzf scenario-1-deployment.tar.gz
cd scenario-1-deployment
export PRIMARY_REGION="us-east-1"         
export ENVIRONMENT_NAME="retail-store"
export WEBHOOK_URL="https://event-ai.us-east-1.api.aws/webhook/generic/YOUR-ID"
export WEBHOOK_SECRET="YOUR-SECRET-KEY"
chmod +x deploy.sh
./deploy.sh

Bước 3: Kích hoạt một cuộc điều tra thử nghiệm

Để xác thực luồng end-to-end mà không cần chờ một lỗi thực sự, hãy tự động giảm số lượng bản sao ứng dụng UI xuống 0 để kích hoạt cảnh báo: kubectl scale deployment ui --replicas=0 Trong vòng vài phút, bạn sẽ thấy một cuộc điều tra mới xuất hiện trong ứng dụng web DevOps Agent Space của bạn.

Bạn có thể truy cập AWS DevOps Agent Operator Web App bằng cách hoàn thành các bước sau:

1. Điều hướng đến AWS DevOps Agent Console.
2. Chọn Agent Space cụ thể của bạn từ danh sách.
3. Trên trang đích Agent Space, chuyển đến tab Web app.
4. Chọn Operator access.

AWS DevOps agent khi được cấu hình với quyền truy cập phù hợp có thể tận dụng các lệnh kubectl để khám phá và tìm nạp thông tin từ cụm Amazon EKS của bạn.

Kịch bản 2 – Khắc phục sự cố phụ thuộc cơ sở hạ tầng và ứng dụng Kubernetes

Các lỗi ứng dụng không phải lúc nào cũng bắt nguồn từ khối lượng công việc của bạn. Trong môi trường Kubernetes sản xuất, các tiện ích bổ sung cụm quan trọng như CoreDNS, kube-proxy và plugin Amazon Virtual Private Cloud (Amazon VPC) Container Network Interface tạo thành nền tảng của các hoạt động cụm. Khi các thành phần này gặp sự cố, các triệu chứng có thể biểu hiện trên các ứng dụng dường như không liên quan, khiến việc xác định nguyên nhân gốc rễ trở nên khó khăn. Trong kịch bản này, chúng tôi trình bày cách AWS DevOps Agent tự động tương quan các triệu chứng cấp ứng dụng với các vấn đề cơ sở hạ tầng cơ bản, giảm đáng kể thời gian cần thiết để xác định và giải quyết các lỗi trong các tiện ích bổ sung Kubernetes quan trọng.

Chúng tôi cố ý giảm số lượng bản sao coredns:

kubectl scale deployment coredns --replicas=0

Hãy bắt đầu một cuộc điều tra:

AWS DevOps Agent sẽ xem xét các kube-events và nhật ký Pod của các đối tượng kubernetes của bạn để xác định nguyên nhân gốc rễ. Trong vòng vài phút, bạn sẽ thấy nguyên nhân gốc rễ của các cảnh báo ngừng hoạt động:

Bạn có thể cung cấp thêm ngữ cảnh và hướng dẫn khắc phục sự cố cho DevOps agent bằng cách thêm một runbook trong tab Skills. Một tài liệu khắc phục sự cố EKS chi tiết được cung cấp trong kho lưu trữ GitHub.

Kết luận

Trong bài đăng này, chúng tôi đã trình bày cách AWS DevOps Agent biến đổi các hoạt động của Amazon EKS bằng cách xây dựng các biểu đồ tri thức thông minh lập bản đồ các mối quan hệ phức tạp giữa các tài nguyên Kubernetes của bạn. Bằng cách tự động tương quan các tín hiệu telemetry trên các lớp cơ sở hạ tầng, ứng dụng và container, tác nhân này giảm đáng kể MTTI và MTTR cho các sự cố trong môi trường EKS của bạn.

Sức mạnh của AWS DevOps Agent nằm ở khả năng hiểu ngữ cảnh, không chỉ thu thập dữ liệu. Thay vì tương quan thủ công các nhật ký, chỉ số và sự kiện, tác nhân này tự động theo dõi các chuỗi phụ thuộc—từ các điểm cuối bên ngoài thông qua bộ cân bằng tải, dịch vụ và Pod—để xác định chính xác nguồn gốc của các lỗi. Cho dù khắc phục sự cố cấp ứng dụng hay các thành phần cơ sở hạ tầng quan trọng như CoreDNS, phương pháp biểu đồ tri thức của tác nhân loại bỏ việc phỏng đoán thường kéo dài thời gian giải quyết sự cố.

Khi môi trường Kubernetes tiếp tục phát triển về độ phức tạp với hàng nghìn nút và kiến trúc microservices phức tạp, nhu cầu về các hoạt động thông minh, tự động trở nên quan trọng. AWS DevOps Agent không chỉ cảnh báo bạn về các vấn đề—nó điều tra chúng, hiểu ngữ cảnh của chúng trong cơ sở hạ tầng rộng lớn hơn của bạn và cung cấp các bước khắc phục có thể hành động, hoạt động như một kỹ sư DevOps luôn sẵn sàng của bạn.

Đọc thêm

Để tìm hiểu thêm về AWS DevOps Agent, hãy tham khảo các tài nguyên sau:

• Từ nguyên mẫu tác nhân AI đến sản phẩm: Bài học từ việc xây dựng AWS DevOps Agent
• Các phương pháp hay nhất để triển khai AWS DevOps Agent trong môi trường sản xuất
• Giải quyết các vấn đề ứng dụng một cách tự động với AWS DevOps Agent và Dynatrace
• Workshop AWS DevOps Agent

Về tác giả

Vikram Venkataraman

Vikram Venkataraman là Kiến trúc sư Giải pháp Chuyên gia Chính tại Amazon Web Services (AWS). Ông giúp khách hàng hiện đại hóa, mở rộng quy mô và áp dụng các phương pháp hay nhất cho khối lượng công việc được container hóa của họ. Với sự xuất hiện của Generative AI, Vikram đã tích cực làm việc với khách hàng để tận dụng các dịch vụ AI/ML của AWS nhằm giải quyết các thách thức vận hành phức tạp, hợp lý hóa quy trình giám sát và nâng cao khả năng phản ứng sự cố thông qua tự động hóa thông minh.

Shivkumar

Shivkumar là Quản lý Tài khoản Kỹ thuật tại Amazon Web Services. Ông đóng vai trò là cố vấn đáng tin cậy và người ủng hộ khách hàng AWS, chủ động cung cấp hướng dẫn kỹ thuật và các phương pháp hay nhất về kiến trúc để giúp khách hàng xây dựng, vận hành và tối ưu hóa các giải pháp trên AWS nhằm đạt được mục tiêu kinh doanh của họ. Ông hợp tác chặt chẽ với khách hàng trong các bộ phận vận hành, phát triển và lãnh đạo để hiểu nhu cầu của họ và đảm bảo họ đang tận dụng các dịch vụ AWS một cách hiệu quả.

Greg Eppel

Greg Eppel là Chuyên gia Chính về DevOps Agent và đã dành nhiều năm qua tập trung vào Cloud Operations và giúp đỡ khách hàng AWS trong hành trình lên đám mây của họ.

Sudheer Sangunni

Sudheer Sangunni là Quản lý Tài khoản Kỹ thuật Cấp cao tại AWS Enterprise Support. Với chuyên môn sâu rộng về AWS Cloud và big data, Sudheer đóng vai trò then chốt trong việc hỗ trợ khách hàng nâng cao khả năng giám sát và quan sát trong các dịch vụ của AWS.