Giới thiệu dự án

Trong bối cảnh chuyển đổi số và kiến trúc Cloud-Native bùng nổ, Kubernetes (K8s) đã trở thành nền tảng tiêu chuẩn công nghiệp cho việc điều phối và quản lý container ở quy mô lớn. Theo khảo sát từ Cloud Native Computing Foundation (CNCF), hơn 84% tổ chức trên toàn cầu đã triển khai Kubernetes trong môi trường production. Tuy nhiên, sự dịch chuyển từ monolithic sang Microservices phân tán trên cụm nhiều Node và hàng trăm Pod làm gia tăng đột biến độ phức tạp trong công tác giám sát hạ tầng và phản ứng sự cố.

+-------------------------------------------------------------------------------+
|                             PROBLEM LANDSCAPE                                 |
|                                                                               |
|   +--------------------------+                 +--------------------------+   |
|   |   Hạ tầng Microservices  |                 |    Vận hành Thủ công     |   |
|   |   - Hàng trăm Pods/Nodes |   =========>    |   - MTTR: 10 - 15 phút   |   |
|   |   - Biến động liên tục   |                 |   - Rủi ro trễ cảnh báo  |   |
|   |   - Rải rác tài nguyên   |                 |   - Dễ sập lan truyền    |   |
|   +--------------------------+                 +--------------------------+   |
|                                                                               |
|                                     VS                                        |
|                                                                               |
|   +-----------------------------------------------------------------------+   |
|   |              GIẢI PHÁP TỰ ĐỘNG HÓA VỚI CHECKMK & PYTHON               |   |
|   |   - Thu thập Metrics thời gian thực qua Cluster/Node Collector       |   |
|   |   - Tự động phát hiện ngưỡng quá tải (CPU > 10%, RAM > 50%)           |   |
|   |   - Cordon node & di chuyển Pod nặng nhất: MTTR < 30 giây             |   |
|   +-----------------------------------------------------------------------+   |
+-------------------------------------------------------------------------------+

Vấn đề thực tiễn và bài toán đặt ra

Khi một nút làm việc (Worker Node) rơi vào tình trạng cạn kiệt tài nguyên (CPU utilization tăng vọt hoặc Memory vượt ngưỡng an toàn), đội ngũ vận hành hệ thống (SRE/DevOps) thường phải thực hiện chuỗi quy trình thủ công:

  1. Đọc báo cáo cảnh báo và truy cập máy chủ để kiểm tra tài nguyên từng node qua dòng lệnh.
  2. Xác định các Pod tiêu thụ tài nguyên lớn nhất trên node quá tải.
  3. Chặn điều phối pod mới vào node lỗi bằng lệnh cordon.
  4. Tiến hành xóa Pod (delete pod) để bộ điều khiển điều phối Pod sang node khác còn dư thừa tài nguyên.
  5. Kiểm tra trạng thái Pod mới và mở khóa node bằng lệnh uncordon.

Quy trình phản ứng thủ công này mất trung bình từ 10 đến 15 phút, gây trễ chỉ số MTTR (Mean Time to Resolution) và tiềm ẩn nguy cơ gián đoạn dịch vụ diện rộng do lỗi dây chuyền (cascading failure).

Mục tiêu của đề tài

  1. Xây dựng hoàn chỉnh hệ thống giám sát phân tán cho cụm Kubernetes dựa trên nền tảng CheckMK Raw Edition (CRE).
  2. Nghiên cứu cơ chế thu thập dữ liệu chuyên sâu thông qua CheckMK Cluster Collector, CheckMK Node Collector và Kubernetes Metrics Server.
  3. Thiết kế và phát triển Custom Plugin bằng Python tích hợp trực tiếp vào CheckMK để tự động hóa toàn bộ chu trình xử lý quá tải và tái cân bằng tài nguyên giữa các node.

Phương pháp tiếp cận và kết quả kỳ vọng

Đề tài kết hợp kiến trúc giám sát thụ động/chủ động của CheckMK với bộ thư viện Kubernetes API Client và tiến trình Subprocess trên Python 3. Kết quả kỳ vọng là rút ngắn thời gian xử lý quá tải từ mức hàng chục phút xuống dưới 30 giây, đảm bảo tính sẵn sàng cao (High Availability - HA) cho các ứng dụng Microservices.

Phạm vi và giới hạn nghiên cứu

  • Phạm vi triển khai: Hệ thống thực nghiệm trên cụm Kubernetes gồm 1 Master Node (Control Plane) và 2-3 Worker Nodes chạy hệ điều hành Ubuntu 22.04 LTS.
  • Giới hạn kỹ thuật: Đề tài tập trung xử lý cân bằng tải ở tầng hạ tầng tính toán (Compute/Memory) cho các ứng dụng Stateless được quản lý bởi Deployment/ReplicaSet.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Hiện nay trên thị trường có nhiều công cụ giám sát mã nguồn mở và thương mại. Dưới đây là bảng so sánh kỹ thuật giữa CheckMK và các giải pháp phổ biến:

Tiêu chí CheckMK (CRE) Prometheus + Grafana Zabbix Opsview
Core Engine Nagios Core / CMC Time-series TSDB C / PHP Engine Nagios Core (Python 2)
Giao thức truy xuất Livestatus (RAM-based) PromQL HTTP API SQL Database queries Database Polling
Cài đặt & Triển khai Đóng gói OMD, sẵn sàng trong vài phút Phức tạp, cần tích hợp nhiều component rời rạc Cần cấu hình Database và Web Server riêng Trung bình, phụ thuộc package cũ
Khả năng mở rộng Hơn 2.000 plugin, hỗ trợ custom plugin Python Exporters & Custom Exporters C/Python Scripts Nagios Plugins
Tiêu tốn tài nguyên Rất thấp (Truy cập RAM qua Livestatus) Trung bình - Cao (RAM cho TSDB khi quy mô lớn) Cao (I/O Disk lớn do ghi Database liên tục) Trung bình

Phân loại yêu cầu theo mô hình MoSCoW

  • Must have: Giám sát trạng thái Node, Pod, Deployment, DaemonSet thời gian thực; Cảnh báo tự động; Tự động cô lập node quá tải và di chuyển Pod.
  • Should have: Dashboard tương tác trực quan, phân tách rõ ràng theo từng Namespace, biểu đồ lịch sử tải.
  • Could have: Tích hợp cảnh báo đa kênh qua Slack, Jira, SMS thông qua cơ chế Event Console.
  • Won't have: Tự động mở rộng quy mô hạ tầng đám mây (Cluster Autoscaler đa vùng).

Thiết kế hệ thống

Kiến trúc giải pháp được thiết kế theo mô hình phân tầng, kết hợp giữa nền tảng điều khiển CheckMK và cụm Kubernetes thông qua giao thức API Server và NodePort.

graph TB
    subgraph Control_Plane["Master Node (Control Plane)"]
        OMD["CheckMK Server (OMD v2.2)"]
        Plugin["Python Automation Plugin"]
        APIServer["Kubernetes API Server"]
        MetricServer["Metrics Server"]
        OMD --> Plugin
        Plugin --> APIServer
        Plugin --> MetricServer
    end

    subgraph Monitoring_Agent["Kubernetes Monitoring Layer"]
        ClusterCol["CheckMK Cluster Collector (Deployment - Port 30035)"]
        NodeCol1["Node Collector (DaemonSet)"]
        NodeCol2["Node Collector (DaemonSet)"]
    end

    subgraph Worker_Nodes["Worker Nodes Infrastructure"]
        Worker1["Worker Node 1 (Ubuntu 22.04)"]
        Worker2["Worker Node 2 (Ubuntu 22.04)"]
        PodA["App Pods"]
        PodB["App Pods"]
    end

    OMD -- "NodePort / REST API" --> ClusterCol
    ClusterCol --> APIServer
    NodeCol1 --> Worker1
    NodeCol2 --> Worker2
    APIServer --> Worker1
    APIServer --> Worker2
    Worker1 --- PodA
    Worker2 --- PodB

Danh mục công nghệ và phiên bản sử dụng

  • Hệ điều hành: Ubuntu 22.04 LTS (Kernel 5.15+).
  • Container Runtime: Containerd v1.7.2 (Systemd Cgroup driver).
  • Điều phối cụm: Kubernetes v1.28 (Kubeadm, Kubelet, Kubectl).
  • Network Plugin: Calico CNI v3.26.
  • Hệ thống giám sát: CheckMK Raw Edition (CRE) v2.2.0 chạy trên nền tảng Open Monitoring Distribution (OMD).
  • Ngôn ngữ phát triển Plugin: Python 3.10 kết hợp thư viện kubernetes-client (v28.0+) và subprocess.

Thiết kế kết nối và an toàn thông tin

  1. Giao tiếp CheckMK - Kubernetes: CheckMK liên kết với cụm thông qua ServiceAccount checkmk-checkmk thuộc namespace checkmk-monitoring.
  2. Xác thực và phân quyền: Sử dụng Bearer Token mã hóa Base64 và chứng chỉ số CA Certificate (ca.crt) để thiết lập kênh kết nối an toàn qua cổng NodePort 30035.
  3. Livestatus Engine: CheckMK truy vấn trạng thái dịch vụ trực tiếp từ bộ nhớ RAM của core giám sát, không gây nghẽn I/O hệ thống.

Quy trình và phương pháp thực hiện

Dự án áp dụng quy trình phát triển theo mô hình linh hoạt (Iterative Agile) với 4 giai đoạn rõ ràng:

  1. Khảo sát & Chuẩn bị hạ tầng: Cài đặt cụm Kubernetes đa node, tối ưu hóa kernel Linux (swapoff, nạp module overlay, br_netfilter).
  2. Triển khai CheckMK & OMD: Xây dựng OMD site chuyên biệt mang tên Kubernetes, cấu hình CheckMK Linux Agents.
  3. Tích hợp giám sát Cluster: Đóng gói Helm Chart checkmk-chart, chuyển đổi service từ ClusterIP sang NodePort, cấp quyền RBAC.
  4. Phát triển & Kiểm thử Plugin: Lập trình thuật toán cân bằng tải tự động, thiết lập kịch bản sinh tải quá ngưỡng và đánh giá độ trễ xử lý.

Implementation và kết quả

Quá trình phát triển và hiện thực hóa

1. Cấu hình triển khai Kubernetes Agent với Helm

Tùy chỉnh tệp values.yaml của CheckMK Cluster Collector để mở cổng giao tiếp NodePort:

clusterCollector:
  service:
    type: NodePort
    nodePort: 30035

Thực thi cài đặt vào cụm thông qua lệnh Helm:

helm upgrade --install --create-namespace \
  -n checkmk-monitoring checkmk \
  checkmk-chart/checkmk -f values.yaml

2. Xây dựng Plugin cân bằng tải tự động bằng Python

Plugin được viết bằng Python 3, thực hiện thu thập chỉ số qua kubectl top và điều phối lại tài nguyên khi vượt ngưỡng.

Thuật toán thu thập dữ liệu tài nguyên Node
import subprocess
import json
from kubernetes import client, config

CHECKED_NAMESPACES = ["default", "production-apps"]

def get_node_resource_usage():
    """Lấy số liệu tiêu thụ CPU và RAM của tất cả worker nodes."""
    result = subprocess.run(
        ["kubectl", "top", "nodes", "--no-headers"],
        capture_output=True,
        text=True,
        check=True
    )
    nodes_metrics = result.stdout.strip().split("\n")
    return nodes_metrics

def parse_node_metrics(nodes_metrics):
    """Phân tích dữ liệu thô và chuyển đổi thành dictionary có cấu trúc."""
    nodes = []
    for line in nodes_metrics:
        parts = line.split()
        if len(parts) >= 5:
            node_name = parts[0]
            # Bỏ qua master node để đảm bảo an toàn cho Control Plane
            if "master" in node_name or "control-plane" in node_name:
                continue
            cpu_percent = int(parts[2].replace("%", ""))
            mem_percent = int(parts[4].replace("%", ""))
            nodes.append({
                "name": node_name,
                "cpu_percent": cpu_percent,
                "memory_percent": mem_percent
            })
    return nodes
Thuật toán phát hiện Pod tiêu thụ tài nguyên lớn nhất và xử lý Cordon
def get_pod_resource_usage(node_name):
    """Truy vấn các pod đang chạy trên node quá tải và lấy metrics chi tiết."""
    config.load_kube_config()
    api_instance = client.CoreV1Api()
    pods = api_instance.list_pod_for_all_namespaces(
        field_selector=f"spec.nodeName={node_name}"
    ).items
    
    pod_metrics = []
    for pod in pods:
        if pod.metadata.namespace not in CHECKED_NAMESPACES:
            continue
        try:
            metrics = subprocess.run(
                ["kubectl", "top", "pod", pod.metadata.name, 
                 "--namespace", pod.metadata.namespace, "--no-headers"],
                capture_output=True, text=True, check=True
            )
            data = metrics.stdout.strip().split()
            if len(data) >= 3:
                cpu_raw = int(data[1].replace("m", ""))
                mem_raw = int(data[2].replace("Mi", ""))
                pod_metrics.append({
                    "name": pod.metadata.name,
                    "namespace": pod.metadata.namespace,
                    "cpu_usage": cpu_raw,
                    "memory_usage": mem_raw
                })
        except subprocess.CalledProcessError:
            continue
    return pod_metrics

def execute_rebalance(node_name, target_pod):
    """Thực hiện Cordon node, xóa Pod để K8s tái điều phối và Uncordon node."""
    # Bước 1: Cô lập node
    subprocess.run(["kubectl", "cordon", node_name], check=True)
    
    # Bước 2: Xóa Pod nặng nhất (Deployment ReplicaSet sẽ tạo lại trên node khác)
    subprocess.run([
        "kubectl", "delete", "pod", target_pod["name"],
        "--namespace", target_pod["namespace"]
    ], check=True)
    
    # Bước 3: Mở khóa node sau khi quá trình tái điều phối hoàn tất
    subprocess.run(["kubectl", "uncordon", node_name], check=True)

Kiểm thử và đánh giá kết quả thực nghiệm

Kịch bản thực nghiệm được thiết lập trên mô hình cụm 3 máy ảo và 4 máy ảo:

  • Master Node: 4 vCPU, 8GB RAM, 80GB Disk.
  • Worker Node 1 & 2: 4 vCPU, 8GB RAM, 80GB Disk.
  • Ngưỡng kích hoạt cảnh báo: CPU > 10% hoặc RAM > 50%.
+-------------------------------------------------------------------------------+
|                      TIMELINE SO SÁNH HIỆU QUẢ XỬ LÝ SỰ CỐ                     |
|                                                                               |
|  [PHƯƠNG PHÁP THỦ CÔNG] (Tổng thời gian: 680s ~ 11.3 phút)                   |
|  |--- Phát hiện cảnh báo (180s) ---|-- SSH & Kiểm tra (240s) --|-- Xử lý (260s) --|
|                                                                               |
|  [TỰ ĐỘNG HÓA VỚI CHECKMK PLUGIN] (Tổng thời gian: 22.8s)                     |
|  |-> Polling & Detect (8.2s)                                                  |
|  |-> Cordon & Delete Pod (11.4s)                                              |
|  |-> Reschedule & Uncordon (3.2s)                                             |
|                                                                               |
|  ===> HIỆU QUẢ: Rút ngắn 96.6% thời gian phục hồi hạ tầng (MTTR)            |
+-------------------------------------------------------------------------------+

Số liệu kiểm thử hiệu năng tái cân bằng tải

Lần thử nghiệm Trạng thái Node trước xử lý Pod bị di chuyển Node đích tiếp nhận Thời gian xử lý tự động Kết quả tải sau xử lý
Lần 1 (3 Node) Node 1: Memory 78% app-worker-6f8d-x1 Node 2 24.5 giây Node 1: 34% | Node 2: 48%
Lần 2 (3 Node) Node 2: CPU 88% stress-cpu-9a2b-v4 Node 1 21.2 giây Node 2: 08% | Node 1: 46%
Lần 3 (4 Node) Node 1: Memory 82% cache-engine-bc3-k9 Node 3 22.8 giây Node 1: 31% | Node 3: 42%

[!NOTE] Thời gian thực nghiệm trung bình của phương pháp tự động hóa bằng CheckMK Plugin đạt 22.83 giây, giảm hơn 96.6% so với thời gian thao tác thủ công của kỹ sư hệ thống (trung bình 680 giây).

Đổi mới và đóng góp

  1. Khả năng quan sát hợp nhất (Unified Observability): Tích hợp thành công giải pháp giám sát truyền thống dựa trên OMD/Nagios vào môi trường container động Kubernetes, theo dõi từ tầng Host vật lý đến từng Namespace, DaemonSet, Pod và PVC.
  2. Cơ chế phản ứng chủ động (Self-Healing Rebalancing): Thay vì chỉ dừng lại ở mức phát cảnh báo thụ động qua email/SMS, hệ thống đã chủ động can thiệp vào vòng đời của Pod thông qua Kubernetes API, giải phóng tài nguyên tức thời cho các node quá tải.
  3. Tối ưu hóa chi phí vận hành: Sử dụng phiên bản mã nguồn mở CheckMK Raw Edition (CRE) kết hợp Plugin tự xây dựng giúp doanh nghiệp tiết kiệm 100% chi phí bản quyền so với các giải pháp SaaS đắt đỏ như Datadog hay Dynatrace.

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế

  • Hạ tầng E-commerce trong đợt Flash Sale: Lưu lượng truy cập đột biến khiến một số Pod xử lý đơn hàng làm tràn bộ nhớ Worker Node; hệ thống tự động nhận diện và tái phân bổ Pod sang các node nhàn rỗi mà không làm rớt kết nối của người dùng.
  • Môi trường CI/CD Pipeline: Tự động cô lập và tái cấu trúc các Node biên dịch mã nguồn khi các build job chiếm dụng 100% CPU.

Yêu cầu cấu hình triển khai hệ thống

+-------------------------------------------------------------------------+
|                  YÊU CẦU PHẦN CỨNG TỐI THIỂU CHO CỤM                    |
|                                                                         |
|   +--------------------------+         +----------------------------+   |
|   |   Master Node (Control)  |         |   Worker Nodes (x2 - x3)   |   |
|   |   - OS: Ubuntu 22.04 LTS |         |   - OS: Ubuntu 22.04 LTS   |   |
|   |   - CPU: 4 Cores         |         |   - CPU: 4 Cores           |   |
|   |   - RAM: 8 GB            |         |   - RAM: 8 GB              |   |
|   |   - Disk: 80 GB SSD      |         |   - Disk: 80 GB SSD        |   |
|   +--------------------------+         +----------------------------+   |
+-------------------------------------------------------------------------+

Ước tính hiệu quả kinh tế (ROI)

  • Doanh nghiệp quy mô 50 Nodes: Tiết kiệm khoảng $18.000 - $30.000 USD chi phí license giám sát hàng năm.
  • Năng suất lao động: Giảm 80% số lượng ticket khẩn cấp liên quan đến nghẽn tài nguyên cục bộ trên cụm máy chủ.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Cơ chế di chuyển Pod dựa trên phương thức delete pod và để ReplicaSet tạo mới chỉ tối ưu cho các ứng dụng không lưu trạng thái (Stateless applications). Đối với StatefulSets gắn liền với Persistent Volume ở vùng lưu trữ cố định, việc tái điều phối cần thêm các ràng buộc lưu trữ phức tạp.
  • Chu kỳ thu thập dữ liệu của Metrics Server có độ trễ nhất định (polling interval khoảng 15-30 giây).

Hướng phát triển trong tương lai

  • Phát triển thuật toán AI/Machine Learning để dự đoán trước điểm nghẽn tài nguyên dựa trên dữ liệu chuỗi thời gian (Time-series data) lưu trữ trong CheckMK, thực hiện di chuyển Pod trước khi tài nguyên thực sự vượt ngưỡng.
  • Mở rộng hỗ trợ kiến trúc Multi-Cluster và môi trường Kubernetes đa đám mây (Hybrid/Multi-Cloud).

Đối tượng hưởng lợi

  • Sinh viên & Nghiên cứu sinh: Tài liệu tham khảo thực tế về việc kết hợp giữa công cụ giám sát mã nguồn mở OMD/CheckMK và công nghệ điều phối container Kubernetes.
  • Kỹ sư DevOps / SRE: Sở hữu bộ mã nguồn plugin Python hoàn chỉnh để tùy biến, áp dụng trực tiếp vào việc quản trị cụm hạ tầng thực tế.
  • Doanh nghiệp: Giải pháp nâng cao độ tin cậy và tính ổn định cho hệ thống Microservices với chi phí đầu tư phần mềm bằng 0.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai giải pháp này là gì?

Cần tối thiểu 2 máy chủ ảo hóa (VM) hoặc vật lý chạy Ubuntu 22.04 LTS, mỗi máy tối thiểu 2 vCPU và 2GB RAM (khuyến nghị 4 vCPU và 8GB RAM cho môi trường production), đã vô hiệu hóa hoàn toàn bộ nhớ hoán đổi (swapoff) và cài đặt Containerd v1.7+.

2. CheckMK thu thập dữ liệu từ Kubernetes bằng cơ chế nào?

CheckMK sử dụng phối hợp hai cơ chế: (1) Truy vấn siêu dữ liệu từ Kubernetes API Server qua ServiceAccount Token, và (2) Sử dụng CheckMK Cluster Collector kết hợp Node Collector (DaemonSet) exposed qua cổng NodePort để lấy thông số chi tiết của từng container và máy chủ.

3. Việc xóa Pod để cân bằng tải có làm gián đoạn dịch vụ của người dùng không?

Đối với các ứng dụng triển khai dạng Deployment có cấu hình replicas >= 2 và thiết lập Rolling Update cùng Service Proxy, lưu lượng mạng sẽ tự động chuyển hướng sang các bản sao còn lại nên không gây gián đoạn phiên làm việc của người dùng cuối.

4. Giải pháp này có thể tích hợp với các hệ sinh thái cảnh báo có sẵn như Slack hay Telegram không?

Hoàn toàn có thể. Tính năng Event Console và Notification Rules tích hợp sẵn trong giao diện quản trị WATO của CheckMK cho phép cấu hình Webhook gửi thông báo tức thì tới Slack, Telegram, Jira, PagerDuty hoặc SMS Gateway.

5. Chi phí triển khai và thời gian hoàn vốn (ROI) được tính toán ra sao?

Giải pháp sử dụng 100% nền tảng mã nguồn mở (CheckMK Raw Edition, Kubernetes, Containerd, Python), loại bỏ hoàn toàn phí bản quyền phần mềm. Doanh nghiệp chỉ đầu tư chi phí hạ tầng máy chủ ban đầu và ghi nhận điểm hòa vốn ngay trong tháng đầu tiên nhờ giảm thiểu thời gian chết (Downtime).

Kết luận

Đề tài "Giám sát hệ thống Kubernetes sử dụng công cụ giám sát CheckMK" của tác giả Lê Quang Minh đã giải quyết thành công bài toán tự động hóa quan sát và điều phối tài nguyên cho hạ tầng container hiện đại. Bằng việc kết hợp sức mạnh giám sát toàn diện của CheckMK Raw Edition với thuật toán tự động hóa thông minh viết bằng Python, hệ thống không chỉ cung cấp cái nhìn trực quan, đa tầng về sức khỏe cụm máy chủ mà còn chủ động khắc phục sự cố quá tải với thời gian đáp ứng ấn tượng dưới 30 giây. Đây là giải pháp thực tiễn, có tính ứng dụng cao, mở ra hướng tiếp cận tối ưu chi phí và nâng cao độ tin cậy cho các doanh nghiệp đang vận hành hệ thống Microservices trên nền tảng Cloud-Native.