Giới thiệu dự án

Trong bối cảnh chuyển đổi số toàn cầu, ngành công nghiệp phần mềm đóng vai trò then chốt trong việc thúc đẩy tăng trưởng kinh tế. Theo số liệu từ Sách trắng Công nghệ thông tin và Truyền thông Việt Nam, Việt Nam đứng thứ 6 trên thế giới về xuất khẩu phần mềm. Số lượng doanh nghiệp công nghệ số tăng trưởng nhanh chóng từ 7.433 doanh nghiệp (năm 2016) lên hơn 13.544 doanh nghiệp (năm 2020), bình quân mỗi năm có khoảng 1.500 doanh nghiệp mới ra đời. Báo cáo từ MarketLine cũng chỉ ra rằng thị trường phần mềm toàn cầu duy trì tốc độ tăng trưởng kép (CAGR) đạt 11,3%, chạm mốc 969 tỷ USD vào năm 2024. Sự bùng nổ này biến khả năng bàn giao sản phẩm nhanh chóng, tối ưu hóa chi phí hạ tầng và đảm bảo an toàn vận hành trở thành năng lực cạnh tranh sống còn của các công ty công nghệ.

Tuy nhiên, báo cáo An ninh mạng Việt Nam năm 2023 của NCS ghi nhận số lượng cuộc tấn công mạng vào các hệ thống tại Việt Nam tăng 9,5%, trong đó 27,4% các sự cố bắt nguồn từ lỗ hổng trên các nền tảng và dịch vụ cài đặt trực tiếp trên máy chủ. Thực trạng này đặt ra bài toán cấp bách về việc hiện đại hóa quy trình triển khai và vận hành hệ thống.

Công ty Cổ phần Công nghệ Proton (ProtonTech) là đơn vị đã cung cấp gần 120 giải pháp phần mềm cho hơn 20 đối tác trong lĩnh vực Công nghệ Thông tin và Công nghệ Tài chính (Fintech). Mặc dù sở hữu quy mô hơn 90 nhân sự với 10 kỹ sư vận hành chuyên trách, công ty vẫn duy trì quy trình triển khai thủ công truyền thống:

  • Cài đặt trực tiếp môi trường Java Development Kit (JDK) và SQL Server trên hệ điều hành máy chủ vật lý.
  • Chuyển giao mã nguồn qua giao thức File Transfer Protocol (FTP).
  • Triển khai phiên bản mới bằng cách dừng ứng dụng, nén tệp sao lưu, ghi đè mã nguồn và khởi động lại.
  • Giám sát thụ động qua việc kiểm tra thủ công các tệp nhật ký (log files) và tài nguyên máy chủ.

Quy trình này gây ra hàng loạt hạn chế nghiêm trọng: thời gian gián đoạn dịch vụ (downtime) kéo dài 15–30 phút cho mỗi lần phát hành, rủi ro xung đột môi trường runtime, chi phí đầu tư phần cứng máy chủ vượt 300 triệu đồng trong năm 2023 do thiếu cơ chế chia sẻ tài nguyên động, và thời gian khắc phục sự cố (MTTR) bị kéo dài.

Nhằm giải quyết triệt để các hạn chế trên, đề tài khóa luận tập trung nghiên cứu giải pháp Container hóa kết hợp nền tảng điều phối Kubernetes (K8s), xây dựng quy trình Tích hợp và Triển khai liên tục (CI/CD) tự động hóa, tích hợp hệ thống giám sát thời gian thực Prometheus và Grafana, ứng dụng trực tiếp trên "Hệ thống quản lý sân bóng Đại Dương" tại ProtonTech.

+-------------------------------------------------------------------------+
|                  MỤC TIÊU VÀ PHẠM VI DỰ ÁN TẠI PROTONTECH               |
+-------------------------------------------------------------------------+
|  1. Đóng gói ứng dụng chuẩn hóa với Docker Engine (Multi-stage build)   |
|  2. Thiết lập cụm Kubernetes Cluster (Master/Worker) tự phục hồi        |
|  3. Xây dựng Pipeline CI/CD tự động (GitLab -> Jenkins -> Harbor -> K8s)|
|  4. Triển khai hệ thống giám sát chỉ số tập trung (Prometheus & Grafana) |
|  5. Triển khai thực nghiệm trên Hệ thống quản lý sân bóng Đại Dương      |
+-------------------------------------------------------------------------+

Dự án xác lập các mục tiêu đo lường cụ thể:

  1. Triệt tiêu thời gian downtime khi cập nhật ứng dụng xuống 0 giây thông qua cơ chế Rolling Update.
  2. Rút ngắn thời gian build và deploy từ 45 phút xuống dưới 5 phút (giảm ~89%).
  3. Tăng hiệu suất tận dụng tài nguyên CPU/RAM máy chủ thêm ít nhất 40%.
  4. Giảm thời gian phát hiện và tự động khôi phục lỗi dịch vụ (Self-healing) xuống dưới 10 giây.

Phạm vi nghiên cứu tập trung vào việc chuyển đổi hệ thống backend Spring Boot và cơ sở dữ liệu của ProtonTech sang mô hình Cloud-native, áp dụng thực nghiệm từ tháng 04/2024 đến tháng 05/2024 tại môi trường On-premises của công ty.

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

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

Phương thức triển khai phần mềm đã trải qua ba giai đoạn tiến hóa chính: Triển khai truyền thống (Traditional Deployment), Triển khai ảo hóa (Virtualized Deployment), và Triển khai Container hóa (Containerized Deployment).

Tiêu chí Triển khai truyền thống (Bare-metal) Triển khai ảo hóa (Hypervisor / VM) Triển khai Container hóa (Docker & Kubernetes)
Kiến trúc hệ điều hành Một OS duy nhất chạy trực tiếp trên phần cứng Chạy đầy đủ Guest OS trên từng máy ảo qua Hypervisor Dùng chung Host OS Kernel, cô lập tầng User-space
Mức tiêu hao tài nguyên Rất cao; lãng phí tài nguyên khi ứng dụng nhàn rỗi Cao; tốn CPU/RAM tĩnh cho từng Guest OS riêng biệt Rất thấp; cấp phát tài nguyên động và chia sẻ kernel
Thời gian khởi động Vài phút đến hàng chục phút 1–3 phút Vài trăm mili-giây đến vài giây
Khả năng đóng gói & di động Kém; phụ thuộc tuyệt đối vào môi trường máy chủ Khá; kích thước image máy ảo lớn (vài GB đến vài chục GB) Xuất sắc; image gọn nhẹ (vài chục đến vài trăm MB)
Khả năng tự động mở rộng Không có; phải bổ sung phần cứng thủ công Chậm; phải nhân bản và khởi động toàn bộ VM Tức thì; tự động co giãn theo số lượng Pod (HPA)
Khả năng tự phục hồi Phải can thiệp thủ công bằng kỹ sư Chậm qua cơ chế VM Failover Tự động tái tạo Pod bị lỗi trong vài giây

Khi lựa chọn nền tảng điều phối Container, hai giải pháp tiêu biểu được cân nhắc là Docker Swarm và Kubernetes:

  • Docker Swarm: Cấu hình đơn giản, tích hợp sẵn trong Docker Engine, phù hợp với các hệ thống quy mô nhỏ nhưng thiếu hụt các tính năng nâng cao như cơ chế Auto-scaling chi tiết, quản trị lưu trữ phân tán phức tạp và hệ sinh thái công cụ mở rộng hạn chế.
  • Kubernetes (K8s): Tiêu chuẩn công nghiệp trên thị trường, cung cấp khả năng quản trị hàng nghìn Pods phân tán, hỗ trợ Service Discovery, Ingress Controller, Rolling Updates, Self-healing, và tích hợp toàn diện với các hệ thống giám sát như Prometheus. Do đó, Kubernetes là lựa chọn tối ưu cho định hướng dài hạn của ProtonTech.

Mô hình phân loại yêu cầu hệ thống theo kỹ thuật MoSCoW:

  • Must have (Bắt buộc): Đóng gói Container bằng Dockerfile; cụm K8s Master-Worker hoạt động ổn định; Pipeline tự động build/push image vào Harbor Registry; triển khai không gián đoạn (Rolling Update); thu thập số liệu CPU/RAM/Network bằng Prometheus.
  • Should have (Nên có): Tự động co giãn theo tải (Horizontal Pod Autoscaler - HPA); phân quyền truy cập Role-Based Access Control (RBAC); cấu hình PersistentVolumeClaim cho dữ liệu cơ sở dữ liệu.
  • Could have (Có thể có): Quản lý cấu hình tập trung qua Helm Chart; cảnh báo sự cố tự động qua Telegram/Slack Alertmanager.
  • Won't have (Chưa thực hiện ở giai đoạn này): Multi-region Cluster Failover phân tán xuyên lục địa.

Thiết kế hệ thống

Kiến trúc giải pháp được xây dựng theo mô hình phân tầng Master-Worker của Kubernetes, kết hợp hạ tầng CI/CD và Monitoring tập trung:

[ Developer ] --( Git Push )--> [ GitLab Repository ]
                                        |
                                  ( Webhook Trigger )
                                        v
                               [ Jenkins CI Server ]
                                        |
                 +----------------------+----------------------+
                 | (1. Maven Build)     | (2. Docker Build)    | (3. Push Image)
                 v                      v                      v
        [ Target Jar File ] ---> [ Docker Image ] ---> [ Harbor Registry ]
                                                               |
                                                   (4. Apply Manifests)
                                                               v
                                                  [ Kubernetes Master Node ]
                                                  (kube-apiserver, etcd)
                                                               |
                                     +-------------------------+-------------------------+
                                     |                                                   |
                                     v                                                   v
                         [ Worker Node 01 ]                                  [ Worker Node 02 ]
                  +-------------------------------+                   +-------------------------------+
                  |  kubelet  |  kube-proxy       |                   |  kubelet  |  kube-proxy       |
                  |  +-------------------------+  |                   |  +-------------------------+  |
                  |  | Pod (App Spring Boot)   |  |                   |  | Pod (App Spring Boot)   |  |
                  |  +-------------------------+  |                   |  +-------------------------+  |
                  |  | Pod (Node Exporter)     |  |                   |  | Pod (MySQL StatefulSet) |  |
                  |  +-------------------------+  |                   |  +-------------------------+  |
                  +-------------------------------+                   +-------------------------------+
                                     ^                                                   ^
                                     |                     (Scrape Metrics)              |
                                     +-----------------------------+---------------------+
                                                                   |
                                                      [ Prometheus & Grafana ]

Danh mục công nghệ và phiên bản chuẩn hóa sử dụng trong hệ thống:

  • Hệ điều hành máy chủ: Ubuntu Server 22.04 LTS (Kernel 5.15)
  • Container Runtime: Docker Engine v24.0.7 / containerd v1.7.0
  • Điều phối cụm: Kubernetes v1.28.2
  • Hệ thống CI/CD: Jenkins v2.426.1 LTS & GitLab Community Edition v16.5
  • Private Image Registry: Harbor v2.8.3 (tích hợp Trivy Scanner)
  • Hệ thống giám sát: Prometheus v2.45.0, Grafana v10.1.0, Node Exporter v1.6.1, cAdvisor v0.47.2
  • Nền tảng ứng dụng: OpenJDK 17, Spring Boot 3.1.5, MySQL 8.0.34, Nginx Ingress Controller v1.9.0

Thiết kế an toàn và lưu trữ:

  • Cơ chế lưu trữ: Sử dụng Kubernetes PersistentVolume (PV) và PersistentVolumeClaim (PVC) với chế độ truy cập ReadWriteOnce gắn kết trực tiếp vào ổ đĩa vật lý của máy chủ để bảo đảm dữ liệu cơ sở dữ liệu MySQL không bị thất thoát khi Pod tái khởi động.
  • Bảo mật hạ tầng: Sử dụng Secret để mã hóa chuỗi kết nối cơ sở dữ liệu và mật khẩu; cấu hình SecurityContext chạy tiến trình container dưới người dùng non-root (UID 1001); Harbor quét lỗ hổng bảo mật của Image trước khi cho phép kéo vào cụm K8s.

Methodology

Dự án áp dụng phương pháp luận phát triển phần mềm linh hoạt (Agile Scrum), chia lộ trình thực hiện thành 4 Sprint chính trong khoảng thời gian từ tháng 04/2024 đến tháng 05/2024:

+-----------------------------------------------------------------------------------+
|                            LỘ TRÌNH TRIỂN KHAI DỰ ÁN                              |
+-----------------------------------------------------------------------------------+
| Sprint 1: Phân tích hiện trạng, khảo sát hạ tầng và chuẩn hóa Dockerfile         |
| Sprint 2: Cài đặt, cấu hình cụm Kubernetes Master-Worker & Harbor Registry        |
| Sprint 3: Thiết lập Pipeline CI/CD tự động hóa Jenkins và GitLab Webhook          |
| Sprint 4: Triển khai Prometheus/Grafana, kiểm thử chịu tải và UAT thực tế         |
+-----------------------------------------------------------------------------------+

Chiến lược quản trị rủi ro kỹ thuật:

  • Rủi ro rò rỉ cấu hình: Toàn bộ thông tin nhạy cảm được chuyển thành Kubernetes Secrets, không lưu hardcode trên Git.
  • Rủi ro xung đột tài nguyên: Áp dụng chặt chẽ resources.requests và resources.limits cho từng Pod để ngăn chặn tình trạng một dịch vụ chiếm dụng toàn bộ tài nguyên máy chủ.
  • Rủi ro gián đoạn khi cập nhật: Sử dụng chiến lược RollingUpdate với cấu hình maxSurge: 1 và maxUnavailable: 0.

Implementation và kết quả

Development process

Quá trình hiện thực hóa giải pháp tập trung vào việc chuyển đổi toàn bộ quy trình cấu hình thủ công sang mã nguồn khai báo (Declarative Infrastructure as Code).

1. Đóng gói ứng dụng với Multi-Stage Dockerfile

Để tối ưu hóa dung lượng image và bảo mật mã nguồn, Dockerfile sử dụng kỹ thuật Multi-stage build nhằm tách biệt môi trường build (Maven) và môi trường runtime (JRE):

# Stage 1: Build source code
FROM maven:3.9.5-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests

# Stage 2: Runtime Image gọn nhẹ
FROM eclipse-temurin:17-jre-alpine
WORKDIR /opt/app
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
COPY --from=builder /app/target/football-management-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-XX:+UseG1GC", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]

2. Định nghĩa Manifest triển khai Kubernetes

Tệp manifest khai báo Deployment của ứng dụng quản lý sân bóng, tích hợp cấu hình tài nguyên và kiểm tra trạng thái hoạt động:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: football-app-deployment
  namespace: production
  labels:
    app: football-management
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: football-management
  template:
    metadata:
      labels:
        app: football-management
    spec:
      containers:
      - name: football-app
        image: harbor.protontech.internal/production/football-app:v1.2.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1024Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 40
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 5

3. Pipeline CI/CD tự động trên Jenkins

Pipeline được cấu hình qua Jenkinsfile để tự động hóa toàn bộ vòng đời phát hành phần mềm:

pipeline {
    agent any
    environment {
        HARBOR_CREDS = credentials('harbor-user-token')
        REGISTRY = 'harbor.protontech.internal/production'
        IMAGE_NAME = 'football-app'
        TAG = "${env.BUILD_NUMBER}"
    }
    stages {
        stage('Checkout Code') {
            steps {
                git branch: 'main', url: 'http://gitlab.protontech.internal/dev/football-management.git'
            }
        }
        stage('Build & Unit Test') {
            steps {
                sh 'mvn clean test'
            }
        }
        stage('Build Docker Image') {
            steps {
                sh "docker build -t ${REGISTRY}/${IMAGE_NAME}:${TAG} ."
            }
        }
        stage('Push to Harbor Registry') {
            steps {
                sh "echo ${HARBOR_CREDS_PSW} | docker login ${REGISTRY} -u ${HARBOR_CREDS_USR} --password-stdin"
                sh "docker push ${REGISTRY}/${IMAGE_NAME}:${TAG}"
            }
        }
        stage('Deploy to Kubernetes') {
            steps {
                sh """
                sed -i 's|image:.*|image: ${REGISTRY}/${IMAGE_NAME}:${TAG}|g' k8s/deployment.yaml
                kubectl apply -f k8s/deployment.yaml -n production
                kubectl rollout status deployment/football-app-deployment -n production
                """
            }
        }
    }
}

4. Cấu hình thu thập giám sát với Prometheus

Cấu hình thu thập metrics thời gian thực từ các Pod và máy chủ Worker:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)

Testing và validation

Hệ thống được kiểm thử toàn diện thông qua 3 kịch bản: kiểm thử tích hợp tự động, kiểm thử chịu tải bằng Apache JMeter, và kiểm thử tính sẵn sàng cao (High Availability).

+-------------------------------------------------------------------------------+
|                    KẾT QUẢ ĐO LƯỜNG TRƯỚC VÀ SAU CHUYỂN ĐỔI                  |
+-------------------------------------------------------------------------------+
| Chỉ số đo lường                 | Hạ tầng cũ (Truyền thống) | Hạ tầng K8s mới |
+---------------------------------+---------------------------+-----------------+
| Thời gian Deploy một bản vá     | 45 phút                   | 3,2 phút        |
| Thời gian Downtime dịch vụ      | 15 - 30 phút              | 0 giây          |
| Tốc độ khôi phục sự cố (MTTR)   | 20 - 45 phút              | 4,5 giây        |
| Mức sử dụng CPU trung bình      | 18% (lãng phí tĩnh)       | 54% (tối ưu hóa)|
| Dung lượng gói cài đặt runtime  | ~1,2 GB                   | 185 MB          |
| Khả năng chịu tải đồng thời     | ~250 users (nghẽn mạng)   | >1.200 users    |
+-------------------------------------------------------------------------------+

Kết quả kiểm thử cho thấy:

  • Độ sẵn sàng dịch vụ (Uptime): Đạt 99.98% trong suốt thời gian vận hành thử nghiệm.
  • Tốc độ phản hồi (Latency): Chỉ số p95 API response time duy trì ổn định ở mức 142ms dưới tải 1.000 requests/giây.
  • Tự phục hồi Pod: Khi chủ động gửi tín hiệu dừng tiến trình Java (SIGKILL), Kubernetes tự động phát hiện thông qua liveness probe và tái tạo Pod mới trong thời gian 4,5 giây mà không làm đứt gãy phiên người dùng.

Kết quả đạt được

Dự án đã hoàn thành toàn bộ các mục tiêu đặt ra với các kết quả cụ thể:

  1. Triển khai hoàn chỉnh hệ thống quản lý sân bóng Đại Dương lên cụm Kubernetes gồm 1 Master Node và 2 Worker Nodes.
  2. Tự động hóa 100% quy trình từ khâu commit code đến khi phần mềm vận hành trên môi trường live.
  3. Dashboard Grafana hiển thị trực quan các biểu đồ: Request Rate, HTTP Error Rate, CPU/Memory Usage, Pod Restarts và Disk I/O.
  4. Đội ngũ kỹ sư ProtonTech tiếp nhận và làm chủ quy trình phát hành sản phẩm mới mà không cần can thiệp SSH thủ công vào máy chủ.

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

Điểm mới về kỹ thuật và giải pháp

  • Xóa bỏ hoàn toàn quy trình thủ công: Chuyển đổi toàn diện từ thao tác FTP/SSH sang mô hình GitOps và CI/CD Pipeline chuẩn quốc tế.
  • Tối ưu hóa tài nguyên phần cứng bằng Container Density: Cho phép chạy đồng thời nhiều microservices độc lập trên cùng một máy chủ vật lý mà không xảy ra xung đột thư viện hay phiên bản Java.
  • Cơ chế phát hiện và xử lý lỗi chủ động: Thay thế việc đọc log thủ công bằng hệ sinh thái Prometheus/Grafana, tự động cảnh báo ngưỡng tài nguyên khi tiệm cận mức quá tải.

Đóng góp thực tiễn cho doanh nghiệp và ngành

  • Giúp ProtonTech tiết kiệm ước tính hơn 150 triệu đồng chi phí đầu tư máy chủ vật lý mới trong năm 2024 nhờ tối ưu hóa hiệu suất hạ tầng hiện có.
  • Cung cấp tài liệu quy chuẩn kỹ thuật (Technical Blueprint) về container hóa và triển khai Kubernetes, áp dụng làm khung chuẩn cho hơn 100 dự án phần mềm tiếp theo của công ty.

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

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

Giải pháp được ứng dụng trực tiếp vào quá trình vận hành sản phẩm "Hệ thống quản lý sân bóng Đại Dương". Hệ thống phục vụ nghiệp vụ đăng ký tài khoản, tra cứu lịch sân trống, đặt lịch, thanh toán trực tuyến và thống kê doanh thu theo thời gian thực.

Trong các khung giờ cao điểm (17h00 - 20h00 hàng ngày), lưu lượng truy cập đặt sân tăng đột biến gấp 5 lần so với bình thường. Cơ chế Horizontal Pod Autoscaler (HPA) của Kubernetes đã tự động mở rộng số lượng Pod từ 3 lên 8 Pods khi CPU vượt ngưỡng 70%, giúp hệ thống duy trì tốc độ phản hồi mượt mà và tự động thu hồi tài nguyên về 3 Pods khi lưu lượng hạ nhiệt.

Hướng dẫn triển khai hệ thống (Deployment Guide)

Bước 1: Khởi tạo cụm Kubernetes với Kubeadm

# Trên Master Node
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# Thiết lập cấu hình kubeconfig
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# Cài đặt Network Plugin (Flannel)
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Bước 2: Cài đặt hệ thống giám sát bằng Prometheus Helm Chart

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

Phân tích hiệu quả kinh tế (ROI)

  • Chi phí đầu tư ban đầu: 0 VNĐ cho chi phí bản quyền phần mềm (sử dụng 100% công nghệ mã nguồn mở chuẩn doanh nghiệp: Docker, K8s, Jenkins, Harbor, Prometheus).
  • Chi phí nhân sự vận hành: Giảm 120 giờ làm việc thủ công/tháng của đội ngũ quản trị hệ thống, tương đương tiết kiệm khoảng 45 triệu đồng chi phí vận hành mỗi tháng.
  • Thời gian hoàn vốn (ROI Breakeven): Đạt điểm hòa vốn chỉ sau 4,5 tháng vận hành chính thức.

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

Hạn chế kỹ thuật hiện tại

  • Cụm Kubernetes hiện tại mới được thiết lập trên môi trường hạ tầng máy chủ cục bộ (On-premises), chưa thiết lập cơ chế dự phòng đa đám mây (Multi-Cloud / Hybrid-Cloud).
  • Việc quản lý các cơ sở dữ liệu có trạng thái (StatefulSet) phức tạp hơn so với các ứng dụng phi trạng thái (Stateless).

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

  • Ứng dụng Service Mesh (Istio) để tăng cường mã hóa lưu lượng mạng nội bộ (mTLS), quản lý lưu lượng chi tiết và phân chia luồng thử nghiệm A/B Testing, Canary Deployment.
  • Ứng dụng công cụ ArgoCD để chuyển đổi hoàn toàn sang mô hình GitOps hiện đại, tự động đồng bộ trạng thái thực tế của cluster với repository Git.
  • Mở rộng hệ thống thu thập và phân tích log tập trung bằng giải pháp EFK Stack (Elasticsearch, Fluentd, Kibana) hoặc Loki & Promtail.

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

  • Sinh viên ngành CNTT & Hệ thống thông tin: Làm tài liệu tham khảo chi tiết, có tính ứng dụng thực tế cao về quy trình hiện đại hóa phần mềm và DevOps từ lý thuyết đến môi trường doanh nghiệp.
  • Kỹ sư phần mềm & Kỹ sư DevOps: Tiếp cận các mẫu cấu hình chuẩn hóa về Multi-stage Dockerfile, Kubernetes Manifests, Jenkins Pipeline và bộ dashboard giám sát mẫu.
  • Doanh nghiệp vừa và nhỏ (SMEs): Bản thiết kế kiến trúc mẫu giúp chuyển đổi số hạ tầng vận hành với chi phí bản quyền 0 đồng, nâng cao tính liên tục trong kinh doanh và tăng năng lực cạnh tranh.
  • Các nhà nghiên cứu: Dữ liệu thực nghiệm cụ thể về hiệu năng, độ trễ và khả năng tiết kiệm tài nguyên khi chuyển đổi từ mô hình ảo hóa truyền thống sang nền tảng điều phối Container.

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

1. Yêu cầu phần cứng tối thiểu để triển khai cụm Kubernetes phục vụ doanh nghiệp là gì?

Đối với môi trường thử nghiệm và sản xuất quy mô nhỏ:

  • Master Node: Tối thiểu 2 vCPU, 4GB RAM, 40GB SSD.
  • Worker Node (mỗi node): Tối thiểu 4 vCPU, 8GB RAM, 80GB SSD.
  • Hệ thống mạng: Tốc độ kết nối mạng nội bộ tối thiểu 1 Gbps và các cổng mạng giao tiếp nội bộ (6443, 2379-2380, 10250) phải được thông suốt.

2. Kubernetes xử lý việc mở rộng quy mô khi lượng người dùng tăng đột biến như thế nào?

Kubernetes sử dụng cơ chế Horizontal Pod Autoscaler (HPA). Dựa trên số liệu thu thập liên tục từ Metrics Server (như % CPU hoặc % RAM), khi vượt ngưỡng thiết lập (ví dụ > 75%), HPA sẽ tự động phát tín hiệu tăng số lượng Pod bản sao (Replicas) trong vài giây và tự động giảm số lượng Pod khi lưu lượng truy cập trở lại trạng thái bình thường.

3. Việc tích hợp hệ thống phần mềm cũ (Legacy Code) lên Docker và Kubernetes có phức tạp không?

Đối với các ứng dụng viết bằng Java, .NET hoặc PHP đời cũ, việc container hóa đòi hỏi tạo base image chứa đúng phiên bản runtime và các thư viện phụ thuộc. Nếu ứng dụng có lưu trữ file cục bộ trên ổ cứng, cần cấu hình chuyển đổi đường dẫn lưu trữ sang Kubernetes Persistent Volumes (PV/PVC) để bảo đảm tính toàn vẹn dữ liệu.

4. Chi phí duy trì và yêu cầu bảo trì hệ thống Kubernetes định kỳ gồm những gì?

Do sử dụng hoàn toàn các giải pháp mã nguồn mở hàng đầu, doanh nghiệp không mất phí bản quyền định kỳ. Hoạt động bảo trì định kỳ bao gồm: sao lưu cơ sở dữ liệu etcd của Master Node, cập nhật các bản vá bảo mật cho Node OS, kiểm tra dung lượng lưu trữ của Harbor Image Registry, và luân phiên cập nhật phiên bản Kubernetes (thực hiện 6 tháng/lần theo chu kỳ phát hành).

5. Lợi ích lớn nhất của việc áp dụng giải pháp này cho doanh nghiệp là gì?

Lợi ích lớn nhất là tính ổn định liên tục của hoạt động kinh doanh (Business Continuity). Doanh nghiệp có thể phát hành các tính năng mới hàng ngày mà khách hàng không nhận thấy bất kỳ sự gián đoạn dịch vụ nào, đồng thời giảm thiểu tối đa rủi ro từ lỗi con người trong các thao tác triển khai thủ công.

Kết luận

Đề tài khóa luận "Nghiên cứu giải pháp Container hoá và Kubernetes, ứng dụng triển khai, vận hành và giám sát phần mềm tại công ty cổ phần Công nghệ Proton" đã hoàn thành xuất sắc các mục tiêu nghiên cứu và thực nghiệm. Bằng việc thay thế toàn bộ quy trình phát hành truyền thống bằng kiến trúc Cloud-native hiện đại với Docker, Kubernetes, Jenkins, Harbor và Prometheus, dự án đã chứng minh tính khả thi vượt trội: triệt tiêu hoàn toàn downtime, cắt giảm 89% thời gian triển khai, tối ưu hóa hơn 40% hiệu suất phần cứng và nâng cao năng lực bảo mật cho toàn bộ hạ tầng của ProtonTech.

Kết quả của đề tài không chỉ giải quyết triệt để các bài toán vận hành cấp bách tại Công ty Cổ phần Công nghệ Proton mà còn mang lại mô hình tham chiếu chất lượng cao cho các doanh nghiệp phần mềm tại Việt Nam trong lộ trình chuẩn hóa quy trình DevOps và chuyển đổi số hạ tầng kỹ thuật.