4. Logging & Monitoring
Mục lục
- 1. Giới thiệu phần Logging và Monitoring
- 2. Giám sát cluster Kubernetes (Monitoring)
- 3. Logging trong Kubernetes
1. Giới thiệu phần Logging và Monitoring
Phần này bàn về các tùy chọn logging và monitoring khác nhau hiện có. Trước tiên xem cách giám sát (monitor) các cluster component của Kubernetes, cũng như các application được host trên đó. Sau đó xem cách xem và quản lý log cho các cluster component, cũng như cho application.
Thực hành những gì đã học qua một loạt bài tập thú vị và có tính thử thách.
2. Giám sát cluster Kubernetes (Monitoring)
Làm sao để giám sát mức tiêu thụ tài nguyên (resource consumption) trên Kubernetes? Hay quan trọng hơn, cần giám sát những gì?
Cần biết các metric ở cấp độ node (node-level metrics), như số lượng node trong cluster, bao nhiêu trong số đó đang khỏe mạnh (healthy), cũng như các performance metric như CPU, memory, network, và disk utilization. Cũng cần các metric ở cấp độ pod (pod-level metrics), như số lượng pod và performance metric của từng pod như mức tiêu thụ CPU và memory trên chúng.
Vì vậy cần một giải pháp để giám sát các metric này, lưu trữ (store) chúng, và cung cấp khả năng phân tích (analytics) xung quanh dữ liệu này. Tại thời điểm khóa học gốc được biên soạn, Kubernetes không đi kèm sẵn một giải pháp monitoring đầy đủ tính năng (full-featured) — điều này vẫn còn đúng cho tới nay (xem mục Nguồn tham khảo).
Tuy nhiên, hiện có một số giải pháp mã nguồn mở (open-source), như Metrics Server, Prometheus, Elastic Stack, và các giải pháp độc quyền (proprietary) như Datadog và Dynatrace.
Heapster từng là một trong những dự án đầu tiên hiện thực khả năng monitoring và phân tích cho Kubernetes. Sẽ thấy rất nhiều tài liệu tham khảo trực tuyến khi tìm kiếm reference architecture về việc monitor Kubernetes. Tuy nhiên, Heapster hiện đã deprecated, và một phiên bản rút gọn (slimmed down) được hình thành, được biết đến là Metrics Server.
Có thể có một Metrics Server cho mỗi Kubernetes cluster. Metrics Server truy xuất (retrieve) metric từ từng Kubernetes node và pod, tổng hợp (aggregate) chúng, và lưu trong bộ nhớ (in memory). Lưu ý Metrics Server chỉ là một giải pháp monitoring in-memory và không lưu metric trên disk. Do đó, không thể xem dữ liệu hiệu năng lịch sử (historical performance data). Muốn có dữ liệu đó, phải dùng một trong các giải pháp monitoring nâng cao đã đề cập ở trên.
Vậy metric cho các pod trên các node này được sinh ra như thế nào? Kubernetes chạy một agent trên mỗi node, được biết đến là kubelet, chịu trách nhiệm nhận chỉ thị (instructions) từ Kubernetes API server và chạy pod trên các node. Kubelet cũng chứa một subcomponent gọi là cAdvisor, hay container advisor. cAdvisor chịu trách nhiệm truy xuất performance metric từ pod và expose chúng qua kubelet API, để các metric có sẵn cho Metrics Server sử dụng.
💡 Hình dung: cAdvisor giống một nhân viên đứng cạnh từng cỗ máy trong xưởng, liên tục đọc đồng hồ đo (CPU, memory) của máy đó và ghi vào sổ tay cục bộ. Kubelet là quản đốc của xưởng (node) — gom sổ tay của mọi máy trong xưởng mình phụ trách rồi sẵn sàng báo cáo khi có người hỏi. Metrics Server là phòng điều hành trung tâm: liên tục xin số liệu mới nhất từ mọi quản đốc, cập nhật lên một bảng theo dõi hiện tại (in-memory) rồi bỏ số liệu cũ đi ngay — không lưu sổ sách. Muốn xem lại biểu đồ tuần trước, phải có thêm một bộ phận lưu trữ dài hạn riêng (Prometheus, Elastic Stack,...), phòng điều hành trung tâm này không làm việc đó.
Triển khai Metrics Server. Nếu dùng Minikube cho cluster local, chạy lệnh:
minikube addons enable metrics-server
Với các môi trường khác, deploy Metrics Server bằng cách clone các deployment file của Metrics Server từ GitHub repository, sau đó deploy các component cần thiết bằng lệnh kubectl create. Lệnh này deploy một tập hợp pods, services, và roles để cho phép Metrics Server poll các performance metric từ các node trong cluster.
Sau khi deploy, cho Metrics Server một khoảng thời gian để thu thập và xử lý dữ liệu. Sau khi đã xử lý, có thể xem hiệu năng cluster bằng lệnh kubectl top node. Lệnh này cung cấp mức tiêu thụ CPU và memory của từng node. Ví dụ, 8% CPU trên master node đang được tiêu thụ, tương đương khoảng 166m.
Đơn vị m ở đây là millicore (millicpu) — Kubernetes chia một CPU core thành 1000 phần, nên 166m nghĩa là 166/1000, tức khoảng 0,166 core. Cách chia nhỏ này giúp cấp phát CPU chính xác hơn cho các pod nhỏ, thay vì chỉ tính theo đơn vị nguyên 1 core.
kubectl top node
# Output minh họa
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master 166m 8% 820Mi 21%
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Dùng lệnh kubectl top pod để xem performance metric của các pod trong Kubernetes.
Lab: Thực hành Monitoring Cluster Components
Làm quen với việc giám sát các cluster component.
Kiểm tra các pod đang chạy. Đã deploy một vài pod chạy workload. Dùng kubectl get pods — thấy có ba pod: elephant, lion, và rabbit, tất cả đều ở trạng thái Running.
kubectl get pods
# Output minh họa
NAME READY STATUS RESTARTS AGE
elephant 1/1 Running 0 4m12s
lion 1/1 Running 0 4m12s
rabbit 1/1 Running 0 4m12s
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Giám sát tài nguyên tiêu thụ bởi từng pod. Cần deploy Metrics Server. Có sẵn một Git repo chứa cấu hình (settings) cho Metrics Server phù hợp với môi trường lab này.
⚠️ Lưu ý: không dùng cấu hình này cho môi trường production, vì có những thay đổi trong đó chỉ nhằm mục đích giúp nó hoạt động với riêng bài lab này và để việc deploy được dễ dàng hơn. Luôn tham khảo tài liệu chính thức về Metrics Server để deploy trong môi trường thật.
Chờ Metrics Server. Repo đã được clone, chứa toàn bộ các file cần thiết để deploy Metrics Server. Bước tiếp theo là deploy Metrics Server bằng cách tạo các component của nó:
kubectl create -f .
Lệnh này tạo tất cả các object cần thiết để deploy Metrics Server. Đôi khi việc này có thể mất vài phút để Metrics Server bắt đầu thu thập và báo cáo dữ liệu.
Kiểm tra bằng kubectl top node — nếu đã hoạt động, có thể tiếp tục.
Xác định node tiêu thụ CPU nhiều nhất. Xem mức tiêu thụ CPU của hai node: node01 tiêu thụ 57 millicores, controlplane tiêu thụ khoảng 470 millicores. Tỷ lệ phần trăm chỉ là 1%, nhưng vẫn có sự chênh lệch giữa hai node — vì control plane có tất cả các control plane component đang chạy trên đó. Trả lời: control plane node.
Xác định node tiêu thụ memory nhiều nhất. Xem mức tiêu thụ memory — control plane tiêu thụ nhiều memory nhất. Trả lời: control plane.
Xác định pod tiêu thụ memory nhiều nhất, và pod tiêu thụ CPU ít nhất. Dùng lệnh kubectl top pod — xem mức tiêu thụ memory và CPU của cả ba pod cùng lúc.
kubectl top pod
# Output minh họa
NAME CPU(cores) MEMORY(bytes)
elephant 3m 45Mi
lion 1m 30Mi
rabbit 2m 210Mi
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Pod rabbit tiêu thụ nhiều memory nhất — trả lời: rabbit (rabbitmq). Mỗi pod chỉ tiêu thụ khoảng 1 millicore CPU trở lên, thấp nhất là lion — trả lời: lion.
3. Logging trong Kubernetes
Phần này bàn về các cơ chế logging (logging mechanisms) khác nhau trong Kubernetes.
Logging trong Docker. Chạy một Docker container tên event-simulator. Tất cả những gì nó làm là sinh ra các sự kiện (event) ngẫu nhiên mô phỏng một web server. Các sự kiện này được stream tới standard output của application.
Nếu chạy Docker container ở chế độ nền (background), tức chế độ detached, bằng option -d, sẽ không thấy log. Muốn xem log, dùng lệnh docker logs theo sau là container ID. Option -f giúp xem live log trail (theo dõi log trực tiếp).
Quay lại Kubernetes, tạo một Pod dùng cùng Docker image đó qua pod definition file. Sau khi pod đang chạy, có thể xem log bằng lệnh kubectl logs với tên pod, dùng option -f để stream log trực tiếp — tương tự lệnh Docker.
Các log này gắn với (specific to) container đang chạy bên trong pod. Như đã biết, Kubernetes pod có thể có nhiều Docker container bên trong. Ví dụ, chỉnh sửa pod definition file để thêm một container khác tên image-processor.
Nếu chạy lệnh kubectl logs lúc này với tên pod, log của container nào sẽ được hiển thị? Nếu có nhiều container bên trong một pod, phải chỉ định rõ tên container trong câu lệnh. Nếu không, lệnh sẽ thất bại (fail), yêu cầu chỉ định tên.
💡 Hình dung: một pod nhiều container giống một căn hộ có nhiều phòng, mỗi phòng tự ghi nhật ký hoạt động riêng. Gõ
kubectl logs <tên-pod>cũng giống như gõ cửa căn hộ mà không nói rõ muốn gặp phòng nào — nếu căn hộ chỉ có một phòng thì không sao, nhưng nếu có nhiều phòng, hệ thống sẽ hỏi lại "phòng nào?" (tên container) chứ không tự đoán giúp.
kubectl logs event-simulator-pod
# Output minh họa
error: a container name must be specified for pod event-simulator-pod, choose one of: [event-simulator image-processor]
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, tên pod/container chỉ mang tính ví dụ.)
Ví dụ, chỉ định tên của container đầu tiên, event-simulator, lệnh sẽ in ra các log message tương ứng:
kubectl logs event-simulator-pod -c event-simulator
Đó chính là chức năng logging đơn giản được hiện thực trong Kubernetes. Đó cũng là tất cả những gì một application developer thực sự cần biết để bắt đầu với Kubernetes, và tất cả những gì thực sự cần biết trong phạm vi chương trình chứng chỉ (certification program).
(Console log gốc còn đề cập lecture kế tiếp sẽ có thêm cấu hình logging nâng cao, hỗ trợ từ bên thứ ba (third-party) cho logging trong Kubernetes, và một demo về cách một logging framework phổ biến được tích hợp với Kubernetes — nội dung chi tiết của phần đó không nằm trong console log này.)
Lab: Thực hành Quản lý Application Logs
Ôn lại một vài application, cách xem log của các application đó, và lấy thông tin hữu ích từ đó.
Kiểm tra Pod. Đã deploy một Pod host một application. Dùng kubectl get pods — pod đang ở trạng thái Running.
User5 gặp vấn đề khi truy cập application, xác định nguyên nhân. Xem log của application này. Log cho thấy có nhắc tới user5, và nguyên nhân là: người dùng đăng nhập thất bại vì tài khoản bị khóa do quá nhiều lần thử thất bại ("the user failed to log in as the account is locked due to too many failed attempts"). Trả lời: account locked due to too many failed attempts.
Một application mới được deploy. Xác định user và nguyên nhân của vấn đề — một user báo cáo gặp vấn đề khi mua một item, kiểm tra log của web app. Xem log — lệnh báo lỗi: "a container name must be specified for the pod webapp2". Lý do là web application này có hai container đang chạy: một web app đơn giản và một DB. Vì có hai container, phải chỉ định rõ container nào cần xem log — chỉ định webapp.
Xem log — phần lớn là các sự kiện bình thường (normal events), nhưng có một số warning. Trong các warning: một dòng ghi user5 failed to log in — không phải vấn đề đang tìm. Một dòng khác ghi: "user 30 order failed as item is out of stock" — đây chính là nguyên nhân. Trả lời: user 30, nguyên nhân item out of stock.
Nguồn tham khảo
Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — phần "Logging & Monitoring" (giám sát cluster bằng Metrics Server; logging cho container và pod bằng kubectl logs), nền tảng KodeKloud. Giảng viên: Mumshad Mannambeth.
Repo ghi chú, link tài liệu, và đáp án các practice question của toàn bộ khóa học: kodekloudhub/certified-kubernetes-administrator-course.
Fact-check:
- Heapster đã đi hết vòng đời deprecation: đánh dấu deprecated từ Kubernetes v1.11, gỡ khỏi setup script từ v1.12, và migrate sang tổ chức
kubernetes-retired(ngừng nhận code mới) từ v1.13; repo chính thức archived từ 1/12/2018 — 2026-09-09, kubernetes-retired/heapster: deprecation.md - Kubernetes vẫn không đi kèm sẵn một giải pháp monitoring đầy đủ tính năng — tài liệu chính thức hiện tại xác nhận resource metrics pipeline (Metrics Server, phục vụ
kubectl topvà Horizontal Pod Autoscaler) chỉ là một tập metric giới hạn, không lưu trữ dài hạn; muốn có full metrics pipeline (custom/external metrics, dài hạn) phải tự chọn giải pháp riêng (Prometheus và hệ sinh thái OpenMetrics) — 2026-09-09, Kubernetes: Tools for Monitoring Resources - Cách deploy Metrics Server được khuyến nghị chính thức hiện nay là
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml, khác với cách clone Git repo rồikubectl create -f .dùng riêng cho bài lab này (bài lab đã tự lưu ý không dùng cách đó cho môi trường production) — 2026-09-09, kubernetes-sigs/metrics-server