Kubernetes có thể báo khỏe trong khi yêu cầu của người dùng vẫn bị nghẽn. Khi đó, hãy bắt đầu từ giao dịch bị ảnh hưởng và đúng khoảng thời gian xảy ra sự cố. Đối chiếu thời gian phản hồi với dữ liệu từ ứng dụng, pod, node, hạ tầng và dịch vụ bên ngoài. Trạng thái khỏe của cụm không chứng minh rằng yêu cầu đã hoàn tất trong thời gian mong muốn.
Phân tích này dựa trên bài viết của The New Stack về độ trễ ẩn trong Kubernetes. Bài viết ghi lại cuộc trao đổi với Mahesh Ramachandran, người phụ trách quản lý sản phẩm HPE OpsRamp Software. Trọng tâm là dữ liệu đo liên tục, khả năng xem lại lịch sử và vai trò hỗ trợ điều tra của trí tuệ nhân tạo.
Trạng thái khỏe của cụm có thể gây hiểu nhầm
Các phép kiểm tra của Kubernetes xác nhận những điều kiện đã cấu hình. Chúng không đo toàn bộ trải nghiệm của người dùng. Liveness probe và readiness probe có thể đều thành công trong khi một yêu cầu vẫn chậm. Nguyên nhân là ứng dụng, hạ tầng hoặc thành phần phụ thuộc chưa đạt mục tiêu thời gian phản hồi.
Liveness probe giúp xác định lúc cần khởi động lại bộ chứa, kể cả khi tiến trình vẫn chạy nhưng đã mắc kẹt. Readiness probe cho biết bộ chứa có thể nhận lưu lượng hay chưa.
Đội vận hành có thể bổ sung điều kiện liên quan đến ứng dụng hoặc thành phần phụ thuộc. Tuy vậy, một phép kiểm tra cơ bản thành công không có nghĩa yêu cầu hoàn chỉnh của người dùng đáp ứng mục tiêu thời gian phản hồi. Muốn biết dịch vụ có thực sự hoạt động tốt, đội ngũ vẫn cần dữ liệu đo hiệu năng ứng dụng.
Ramachandran nêu một tình huống tổng hợp từ các hệ thống doanh nghiệp: người dùng của ứng dụng phục vụ câu lệnh trí tuệ nhân tạo trên Kubernetes báo thời gian phản hồi thỉnh thoảng tăng mạnh. Đội kỹ thuật kiểm tra cụm, node và pod nhưng không thấy pod nào thất bại. Vì hiện tượng chỉ xuất hiện từng lúc, việc xác định nguồn gây chậm gần như không thể nếu thiếu dữ liệu lịch sử.
Nội dung cần kiểm tra ngoài trạng thái cụm
Kết quả kiểm tra thành công giúp thu hẹp phạm vi, nhưng chưa thể kết thúc cuộc điều tra. Ảnh chụp trạng thái ở thời điểm cụm đang khỏe có thể bỏ qua đợt suy giảm trước đó. Việc không có bộ chứa thất bại cũng không chứng minh ứng dụng và các thành phần phụ thuộc đang đạt hiệu năng cần thiết.
Bắt đầu từ giao dịch và thời điểm người dùng gặp chậm
Để tìm nguyên nhân yêu cầu bị nghẽn, trước tiên hãy xác định giao dịch và khoảng thời gian người dùng gặp chậm. Sau đó, so sánh thời gian phản hồi và lưu lượng truy vấn với trạng thái pod, node cùng các thành phần phụ thuộc trong cùng khoảng thời gian.
Đội kỹ thuật nên so sánh thời gian phản hồi truy vấn và số truy vấn mỗi giây với tình trạng cùng số lượng pod, sau đó tìm những biến động trùng với lúc người dùng gặp chậm.
Một mối tương quan chỉ tạo ra giả thuyết về nguyên nhân. Nó chưa đủ để chứng minh quan hệ nhân quả. Sau khi thay đổi cấu hình hoặc thành phần nghi vấn, đội ngũ cần đối chiếu lại cùng các chỉ số hướng tới người dùng với dữ liệu trước đó để kiểm tra hiệu năng có cải thiện hay không.
Cách làm này cũng phù hợp với bài toán vận hành hạ tầng trí tuệ nhân tạo, nơi một phản hồi có thể đi qua ứng dụng, bộ chứa, hạ tầng ảo hóa, phần cứng và dịch vụ mô hình bên ngoài. Mỗi lớp đều có thể khỏe khi đứng riêng nhưng tạo ra độ trễ khi tương tác với nhau.
Thu thập dữ liệu đo xuyên suốt ngăn xếp lai
Điều tra độ trễ thất thường cần dữ liệu đo liên tục từ ứng dụng đến hạ tầng và các dịch vụ phụ thuộc. Hồ sơ lịch sử giúp đội vận hành quay lại đúng thời điểm xảy ra sự cố, thay vì chỉ xem trạng thái hiện tại của Kubernetes sau khi hệ thống đã trở lại bình thường.
Kiến trúc đám mây hiện đại không hoạt động tách biệt. Một yêu cầu có thể phụ thuộc vào mã ứng dụng, môi trường chạy bộ chứa, hạ tầng ảo hóa hoặc máy vật lý và giao diện lập trình của đám mây công cộng. Vì vậy, chỉ số bề mặt của Kubernetes không đủ để xác định nguồn gây chậm.
Theo Ramachandran, HPE OpsRamp liên tục thu thập nhật ký, sự kiện và chỉ số từ node Kubernetes, pod, bộ điều khiển lưu lượng vào và dịch vụ. Hồ sơ liên tục cho phép đội vận hành quay lại đúng thời điểm người dùng báo lỗi rồi đối chiếu triệu chứng với tín hiệu thực tế.
Tìm tương quan trong dữ liệu lịch sử
Bằng chứng không phải lúc nào cũng xuất hiện dưới dạng một đỉnh bất thường rõ rệt. Hai tín hiệu có thể trông bình thường khi xem riêng, nhưng hành vi kết hợp của chúng lại tạo ra độ trễ. Vì thế, bảng điều khiển xanh chưa đủ để loại trừ vấn đề hiệu năng.
Phạm vi thu thập theo từng lớp
Phạm vi quan sát thực tế phụ thuộc vào tác tử thu thập, tích hợp, quyền truy cập và cách đội ngũ triển khai instrumentation cho ứng dụng:
- Ở lớp ứng dụng, hệ thống có thể thu thập dấu vết tương thích OpenTelemetry nếu ứng dụng đã được triển khai instrumentation và có đường thu thập phù hợp. Chỉ giám sát hạ tầng sẽ không tự tạo ra dấu vết ứng dụng.
- Tác tử Kubernetes thu thập dữ liệu của cụm và tải công việc. Muốn quan sát các thành phần như bộ điều khiển lưu lượng vào, đội vận hành cần cấu hình giám sát bổ sung.
- Dữ liệu kiểm kê và hiệu năng từ VMware, Nutanix hoặc HPE Morpheus VM Essentials Software hỗ trợ tìm điểm nghẽn trong lớp ảo hóa và hạ tầng siêu hội tụ.
- Với máy chủ vật lý được hỗ trợ, giao thức Redfish cung cấp dữ liệu đo khi hệ thống có quyền truy cập giao diện lập trình và kết nối cổng cần thiết.
Đo các thành phần nằm ngoài cụm như hộp đen
Khi không thể quan sát bên trong một dịch vụ phụ thuộc, hãy đo dịch vụ đó như một hộp đen. Giao dịch mô phỏng hoặc phép đo thời gian phản hồi tại ranh giới có thể cho biết độ trễ bên ngoài có trùng với lúc ứng dụng chậm hay không, nhưng không xác định được nguyên nhân nội bộ của nhà cung cấp.
Một yêu cầu bắt đầu trong cụm riêng có thể gọi điểm cuối phần mềm dịch vụ, cơ sở dữ liệu nằm ngoài lưới dịch vụ hoặc mô hình trí tuệ nhân tạo trên đám mây công cộng. Khi đó, khả năng quan sát dừng lại ở ranh giới mà đội kỹ thuật không trực tiếp kiểm soát.
Đối chiếu phép đo tại ranh giới dịch vụ
Ramachandran đề xuất định lượng hiệu năng của các thành phần này như một hộp đen. Giao dịch mô phỏng hoặc phép đo thời gian phản hồi khác có thể cho biết hành vi của dịch vụ bên ngoài có trùng với giai đoạn ứng dụng chậm hay không.
Phép đo phải phản ánh đúng đường đi của yêu cầu và tải công việc liên quan. Giao dịch mô phỏng chỉ cung cấp bằng chứng tại ranh giới dịch vụ. Nó không cho thấy nguyên nhân nội bộ của nhà cung cấp và cũng không tự động phân biệt mọi độ trễ bên ngoài với sự cố bên trong.
Đội ngũ nên xác định rõ người sở hữu từng thành phần phụ thuộc. Họ cũng cần biết ai có thể điều tra khi quyền truy cập hoặc instrumentation dừng ở ranh giới đó. Với tác tử trí tuệ nhân tạo chạy trên Kubernetes, việc xác định ranh giới càng quan trọng. Một tác vụ có thể gọi nhiều dịch vụ trước khi trả kết quả.
Dữ liệu đo cũng cần được kiểm soát
Dữ liệu đo phục vụ điều tra có thể chứa nội dung nhạy cảm, đặc biệt trong tải công việc trí tuệ nhân tạo. Đội vận hành cần xác định dữ liệu nào được ghi lại, nơi dữ liệu được chuyển đến và người có quyền truy cập trước khi mở rộng phạm vi thu thập.
Trong tải công việc trí tuệ nhân tạo, câu lệnh, phản hồi và tài liệu được truy xuất có thể xuất hiện trong nhật ký hoặc dấu vết. Khả năng quan sát xuyên nhiều lớp vì thế phải được thiết kế cùng chính sách truy cập và xử lý dữ liệu hiện có.
Thu thập thêm tín hiệu có thể giúp điều tra, nhưng không loại bỏ yêu cầu bảo vệ nội dung nhạy cảm. Cách phân quyền giữa dữ liệu và mô hình cũng là trọng tâm của bảo mật trí tuệ nhân tạo theo từng lớp truy cập.
Từ bảng điều khiển tĩnh đến trợ lý điều tra
Trợ lý trí tuệ nhân tạo có thể giúp đội vận hành truy vấn dữ liệu, liên kết bằng chứng và xác định bước điều tra tiếp theo. Công cụ này không thay thế việc xác thực của con người, vì kết quả phụ thuộc vào dữ liệu nền tảng nhận được và các tính năng đã bật trong từng hệ thống.
Khi số lớp hạ tầng tăng, con người khó diễn giải đồng thời dữ liệu từ nhiều bảng điều khiển. Việc chọn tín hiệu nào cần cảnh báo theo thời gian thực và tín hiệu nào chỉ cần theo dõi thụ động vẫn phụ thuộc vào kiến thức vận hành của từng hệ thống.
Chọn tín hiệu cần ưu tiên
Theo Ramachandran, nền tảng giám sát phải ghi nhận kiến thức và kinh nghiệm của đội vận hành. Nhờ đó, hệ thống có thể hiểu tín hiệu nào thực sự ảnh hưởng đến người dùng. Bảng điều khiển tuyển chọn vẫn hữu ích cho các góc nhìn đã định trước. Trợ lý trí tuệ nhân tạo bổ sung một cách khác để truy vấn dữ liệu vận hành bằng ngôn ngữ tự nhiên.
HPE mô tả trợ lý vận hành trong OpsRamp có thể hỗ trợ điều tra sự cố, liên kết bằng chứng và đề xuất bước tiếp theo. Khả năng này phụ thuộc vào dữ liệu mà nền tảng nhận được cùng các tính năng đã bật trong từng hệ thống triển khai.
Phân tích có trí tuệ nhân tạo hỗ trợ và tự động thay đổi hệ thống là hai quyết định khác nhau. Ramachandran lưu ý kết quả của trí tuệ nhân tạo có thể không tất định, tức có thể thay đổi giữa các lần chạy và không lặp lại nhất quán. Trong khi đó, vận hành công nghệ thông tin thường đòi hỏi hành vi lặp lại được. Vì vậy, đội ngũ cần duy trì giám sát của con người và xác thực chẩn đoán. Họ cũng phải kiểm tra tác động trước khi cho phép kết quả phân tích kích hoạt thay đổi.
Chỉ số hướng tới người dùng mới xác nhận dịch vụ khỏe
Chỉ số hướng tới người dùng mới xác nhận dịch vụ có thực sự khỏe hay không. Đội kỹ thuật cần đo thời gian phản hồi và kết quả của giao dịch, thiết lập đường cơ sở cho từng tải công việc rồi dùng cùng các chỉ số đó để kiểm tra tác động sau mỗi thay đổi.
Nền tảng của quá trình điều tra là instrumentation phù hợp. Đội kỹ thuật cần thu thập dữ liệu cần thiết, thiết lập đường cơ sở và ngưỡng riêng cho từng tải công việc, sau đó xác minh cải thiện bằng trải nghiệm thực tế của người dùng.
Đèn xanh trên bảng điều khiển Kubernetes là điểm bắt đầu hữu ích. Kết luận cuối cùng phải dựa vào thời gian phản hồi của ứng dụng và kết quả mà người dùng nhận được.
Hãy theo dõi Sine để tiếp tục cập nhật các cách vận hành Kubernetes và hạ tầng trí tuệ nhân tạo dựa trên bằng chứng.
