Chuyển đến nội dung chính
Bài viếtKhoá họcHL7Luyện thiRoadmapGameLĩnh vựcVề tôiMCPNEW
Chủ đề
Bảo mậtCơ sở dữ liệuDevOpsKiến trúc hệ thốngLập trìnhLinux

BÀI 1: TỔNG QUAN KIẾN TRÚC MICROSERVICES ON-PREMISES

So sánh on-premises vs cloud vs hybrid, các thành phần cốt lõi của một hệ thống microservices production (K8s, DB HA, Storage, Messaging, Observability, Security), lộ trình học tập và lab environment setup.

🔒 DevSecOps — Bài 1 BÀI 1: TỔNG QUAN KIẾN TRÚC MICROSERVICES ON-PREMISES

Deploy Microservices On-Premises với Kubernetes HA

Phần 1: Nền tảng & Thiết kế Hạ tầng On-Premises

xdev.asia

🎯 MỤC TIÊU BÀI HỌC

Sau khi hoàn thành bài học này, bạn sẽ:

  • ✅ Hiểu sự khác biệt giữa triển khai on-premises, cloud và hybrid cho microservices
  • ✅ Nắm được tổng quan kiến trúc và tất cả thành phần cốt lõi của hệ thống production
  • ✅ Hiểu lý do chọn từng công nghệ trong stack (Kubernetes, Ceph, Patroni, Istio, ArgoCD...)
  • ✅ Thiết lập được lab environment cho toàn bộ khóa học
  • ✅ Nắm được lộ trình 50 bài học và mối liên kết giữa các phần

PHẦN 1: TẠI SAO ON-PREMISES CHO MICROSERVICES?

1.1. Bối cảnh thực tế

Trong thời đại cloud-native, nhiều tổ chức vẫn chọn triển khai on-premises vì:

📊 Thống kê thực tế (2025-2026):

  • ~60% enterprise workloads vẫn chạy on-premises hoặc hybrid (Gartner)
  • Cloud cost tăng 30-40% mỗi năm khi scale → "cloud repatriation" trend
  • Các ngành regulated (tài chính, y tế, chính phủ) yêu cầu data sovereignty
  • Latency-sensitive applications cần proximity với users/devices

1.2. So sánh On-Premises vs Cloud vs Hybrid

Tiêu chí On-Premises Public Cloud Hybrid
Chi phí ban đầu (CapEx) Cao (mua phần cứng) Thấp (pay-as-you-go) Trung bình
Chi phí dài hạn (OpEx) Thấp hơn khi scale Cao và khó dự đoán Tùy workload
Data Sovereignty ✅ Toàn quyền kiểm soát ⚠️ Phụ thuộc region ✅ Phần lớn on-prem
Latency ✅ Thấp nhất Phụ thuộc region Tốt cho edge cases
Customization ✅ Không giới hạn Giới hạn bởi provider Linh hoạt
Ops Complexity ❌ Cao (tự quản lý) ✅ Thấp (managed) Cao nhất
Scaling Speed ❌ Chậm (mua hardware) ✅ Phút (auto-scale) Linh hoạt
Compliance ✅ Dễ đáp ứng nhất Cần shared responsibility Tốt
Vendor Lock-in ✅ Không ❌ Cao (AWS/GCP/Azure) Trung bình

1.3. Khi nào nên chọn On-Premises?

✅ Nên chọn On-Premises khi:

  • Workloads ổn định, predictable (không burst lên xuống liên tục)
  • Yêu cầu compliance cao (HIPAA, PCI-DSS, GDPR data residency)
  • Đã có đầu tư hạ tầng (data center, servers, networking)
  • Chi phí cloud monthly vượt threshold (~$50K-100K+/tháng)
  • Team DevOps/SRE có kinh nghiệm vận hành
  • Cần ultra-low latency (< 1ms giữa services)

❌ Không nên chọn On-Premises khi:

  • Startup early-stage cần speed to market
  • Workloads bursty, khó dự đoán
  • Team < 5 người, không có infra engineer
  • PoC/MVP cần deploy nhanh

PHẦN 2: KIẾN TRÚC TỔNG THỂ HỆ THỐNG

2.1. Sơ đồ kiến trúc tổng thể


graph TB
    subgraph EA["🌐 EXTERNAL ACCESS"]
        Users["👤 Users"] --> DNS["DNS"]
        DNS --> MetalLB["MetalLB VIP"]
        MetalLB --> NGINX["NGINX Ingress"]
        NGINX --> Gateway["Istio Gateway
+ cert-manager TLS"]
    end

    subgraph K8S["☸ KUBERNETES HA CLUSTER — 3 Control Plane + N Workers"]
        subgraph MESH["🔒 Service Mesh — Istio"]
            mTLS["mTLS"] ~~~ TM["Traffic Mgmt"] ~~~ CB["Circuit Breaker"] ~~~ CD["Canary Deploy"]
        end

        subgraph MS["📦 Microservices"]
            APIGW["API Gateway"]
            AuthSvc["Auth Service"]
            UserSvc["User Service"]
            OrderSvc["Order Service"]
            PaySvc["Payment Service"]
            NotifSvc["Notification Service"]
        end

        subgraph DL["💾 Data Layer"]
            PG["PostgreSQL HA
CloudNativePG + PgBouncer"]
            Redis["Redis HA
Sentinel / Cluster"]
            RMQ["RabbitMQ HA
Quorum Queues"]
            Kafka["Kafka
Strimzi KRaft"]
        end

        subgraph GO["🔄 GitOps & Secrets"]
            ArgoCD["ArgoCD HA"]
            Helm["Helm Charts"]
            Vault["Vault HA + ESO"]
            Kyverno["Kyverno Policies"]
        end

        subgraph OBS["📊 Observability"]
            Prom["Prometheus HA + Thanos"]
            Grafana["Grafana HA"]
            Loki["Loki + Alloy"]
            Tempo["Tempo + OTEL"]
        end

        subgraph SEC["🛡️ Security"]
            RBAC["RBAC + OIDC
Keycloak"]
            Falco["Falco Runtime"]
            Harbor["Trivy + Harbor"]
            NP["NetworkPolicy
Cilium"]
        end

        subgraph STOR["💿 Storage — Rook-Ceph"]
            RBD["RBD Block
→ Databases"]
            CephFS["CephFS Shared
→ Apps"]
            RGW["RGW / S3 Object
→ Backup"]
        end

        subgraph INFRA["⚙️ Infrastructure"]
            CiliumCNI["Cilium CNI eBPF"]
            MetalLBi["MetalLB"]
            CoreDNS["CoreDNS"]
            etcd["etcd HA"]
            HAVIP["keepalived + HAProxy
API Server VIP"]
        end
    end

    subgraph PHYS["🖥️ Physical Layer"]
        CP["3× Control Plane Nodes"] ~~~ WK["3-5× Worker Nodes"] ~~~ SN["3× Storage Nodes"]
        NET["Network: Mgmt + Cluster + Storage + External VLANs
OS: Ubuntu 24.04 LTS / RHEL 9"]
    end

    Gateway --> MESH
    MESH --> MS
    MS --> DL
    K8S --> PHYS

2.2. Các thành phần cốt lõi và vai trò

Layer 1: Infrastructure Foundation

Thành phần Công nghệ Vai trò Bài học
Container Runtime containerd 2.x Chạy containers theo CRI standard Bài 5
K8s Orchestration kubeadm (K8s 1.31+) HA control plane, scheduling, self-healing Bài 5-7
CNI Networking Cilium (eBPF) Pod networking, NetworkPolicy, Hubble observability Bài 8
Load Balancer MetalLB Cấp External IP cho Services trên bare-metal Bài 9
API Server HA keepalived + HAProxy Virtual IP cho K8s API endpoint Bài 4
Cluster State etcd (3 nodes) Distributed key-value store cho K8s Bài 10

Layer 2: Distributed Storage

Thành phần Công nghệ Vai trò Bài học
Storage Orchestrator Rook Operator Quản lý Ceph lifecycle trên K8s Bài 11-12
Block Storage Ceph RBD PV cho databases (PostgreSQL, etcd) Bài 13
Shared Storage CephFS ReadWriteMany cho microservices Bài 14
Object Storage Ceph RGW (S3) Backup, Loki logs, Thanos metrics Bài 15

Layer 3: Data Layer

Thành phần Công nghệ Vai trò Bài học
Primary Database PostgreSQL HA (CloudNativePG) ACID transactions, relational data Bài 16-17
Connection Pool PgBouncer Connection pooling, reduce DB load Bài 18
DB Backup pgBackRest Full/incremental backup, PITR Bài 19
Message Queue RabbitMQ HA Async messaging, task queues Bài 21
Event Streaming Kafka (Strimzi) Event sourcing, log aggregation Bài 22
Cache Redis HA Caching, session store, rate limiting Bài 23

Layer 4: Service Mesh & Networking

Thành phần Công nghệ Vai trò Bài học
Service Mesh Istio mTLS, traffic management, observability Bài 24-25
Ingress Controller NGINX Ingress HTTP/HTTPS routing vào cluster Bài 26
TLS Automation cert-manager Auto-issue/renew certificates Bài 26
Gateway API Istio + Gateway API Next-gen ingress, canary routing Bài 27

Layer 5: Platform Operations

Thành phần Công nghệ Vai trò Bài học
GitOps ArgoCD HA Declarative deployment from Git Bài 28, 30
Packaging Helm K8s manifest templating Bài 29
Secrets Vault HA + ESO Centralized secrets management Bài 31
Metrics Prometheus HA + Thanos Metrics collection, long-term storage Bài 32
Dashboards Grafana HA Visualization, alerting Bài 33
Logs Loki + Alloy Centralized log aggregation Bài 34
Traces Tempo + OpenTelemetry Distributed tracing Bài 35
Policy Kyverno Admission control, policy-as-code Bài 37
Runtime Security Falco Threat detection Bài 38
Image Security Trivy + Harbor Vulnerability scanning, private registry Bài 39
Backup Velero Cluster backup/restore Bài 44
Chaos Testing Chaos Mesh Resilience validation Bài 45

PHẦN 3: TẠI SAO CHỌN TỪNG CÔNG NGHỆ?

3.1. Kubernetes (kubeadm) — Tại sao không dùng managed K8s?

On-premises không có EKS/GKE/AKS. Các lựa chọn:

Tool Ưu điểm Nhược điểm Phù hợp
kubeadm Official K8s tool, flexible, production-grade Manual setup, cần hiểu sâu ✅ Production
k3s Nhẹ, dễ cài Bỏ features, dùng SQLite thay etcd Edge/IoT
RKE2 FIPS compliant, Rancher integration Vendor-specific Rancher users
Kubespray Ansible-based, reproducible Slow, Ansible complexity Large clusters

👉 Chọn kubeadm vì: official tool, production-grade, giúp hiểu K8s internals sâu nhất.

3.2. Cilium CNI — Tại sao không Calico hay Flannel?


Flannel:  Đơn giản → Không có NetworkPolicy → ❌ Production
Calico:   Tốt → iptables-based → Performance overhead khi scale
Cilium:   eBPF-based → Kernel-level networking → ✅ Best performance
          + Hubble observability + kube-proxy replacement
          + CNCF Graduated project (2024)

3.3. Rook-Ceph — Tại sao không Longhorn hay NFS?


NFS:      Single point of failure, no replication → ❌ HA
Longhorn: Đơn giản, tốt cho small clusters → Không có Object Storage
Rook-Ceph: Block + Shared + Object storage trong 1 platform
           Enterprise-grade, CNCF Graduated
           Performance tốt cho databases + S3 cho backup/logs
           → ✅ All-in-one storage solution

3.4. Istio — Tại sao không Linkerd?


Linkerd: Nhẹ hơn, dễ hơn → Ít features (không Gateway API, limited traffic mgmt)
Istio:   Feature-rich → mTLS, traffic mirroring, canary, circuit breaker
         Gateway API support, Kiali observability
         Industry standard cho enterprise → ✅ Production choice

PHẦN 4: THIẾT LẬP LAB ENVIRONMENT

4.1. Minimum Hardware cho Lab

Bạn cần tối thiểu các resources sau để thực hành toàn bộ khóa học:

Option A: VMs trên máy host mạnh (Khuyến nghị)


block-beta
    columns 3
    block:HOST["🖥️ Host Machine: 64GB RAM, 16 cores, 500GB SSD"]:3
        block:CP["Control Plane Nodes"]:1
            m1["master1
4 vCPU · 8GB RAM
50GB disk"]
            m2["master2
4 vCPU · 8GB RAM
50GB disk"]
            m3["master3
4 vCPU · 8GB RAM
50GB disk"]
        end
        block:WK["Worker Nodes"]:1
            w1["worker1
4 vCPU · 8GB RAM
50GB + 100GB raw"]
            w2["worker2
4 vCPU · 8GB RAM
50GB + 100GB raw"]
            w3["worker3
4 vCPU · 8GB RAM
50GB + 100GB raw"]
        end
        block:LB["Load Balancer"]:1
            lb["lb
2 vCPU · 2GB RAM
20GB disk
HAProxy + keepalived"]
        end
    end

    style CP fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0
    style WK fill:#1e3a5f,stroke:#10b981,color:#e2e8f0
    style LB fill:#1e3a5f,stroke:#f59e0b,color:#e2e8f0

Total: ~26 vCPU, 58GB RAM, 520GB disk

Option B: Cloud VMs (AWS/GCP/Hetzner)

7 VMs tương đương cấu hình bên trên
Estimated cost: ~$200-400/tháng (Hetzner rẻ nhất)
Khuyến nghị: Hetzner Dedicated hoặc Proxmox VE

Option C: Bare-metal (Production-like)

3× Dell PowerEdge R640 hoặc tương đương:
  - 2× 16-core Xeon, 128GB RAM, 2× 480GB SSD (OS) + 4× 2TB NVMe (Ceph)
  - 4× 25GbE NICs (bonding)

4.2. Network Layout cho Lab


graph TB
    subgraph MGMT["🌐 Management Network — 192.168.1.0/24"]
        direction LR
        lb["lb
192.168.1.10"]
        m1["master1
192.168.1.11"]
        m2["master2
192.168.1.12"]
        m3["master3
192.168.1.13"]
        w1["worker1
192.168.1.21"]
        w2["worker2
192.168.1.22"]
        w3["worker3
192.168.1.23"]
        VIP["🔷 VIP
192.168.1.100
K8s API Server"]
    end

    subgraph INTERNAL["🔒 Internal Networks"]
        POD["Pod Network
10.244.0.0/16
Cilium CNI"]
        SVC["Service Network
10.96.0.0/12
ClusterIP"]
        LB_POOL["MetalLB Pool
192.168.1.200–250
External Services"]
    end

    VIP --> m1 & m2 & m3
    lb --> VIP

    style VIP fill:#dc2626,stroke:#fca5a5,color:#fff
    style POD fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0
    style SVC fill:#1e3a5f,stroke:#10b981,color:#e2e8f0
    style LB_POOL fill:#1e3a5f,stroke:#f59e0b,color:#e2e8f0

4.3. Tạo VMs nhanh với Vagrant (Optional)

# Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/noble64"  # Ubuntu 24.04

Load Balancer


config.vm.define "lb" do |lb|
lb.vm.hostname = "lb"
lb.vm.network "private_network", ip: "192.168.1.10"
lb.vm.provider "virtualbox" do |v|
v.memory = 2048
v.cpus = 2
end
end


Control Plane nodes


(1..3).each do |i|
config.vm.define "master#{i}" do |master|
master.vm.hostname = "master#{i}"
master.vm.network "private_network", ip: "192.168.1.#{10 + i}"
master.vm.provider "virtualbox" do |v|
v.memory = 8192
v.cpus = 4
end
end
end


Worker nodes


(1..3).each do |i|
config.vm.define "worker#{i}" do |worker|
worker.vm.hostname = "worker#{i}"
worker.vm.network "private_network", ip: "192.168.1.#{20 + i}"
worker.vm.provider "virtualbox" do |v|
v.memory = 8192
v.cpus = 4
# Raw disk cho Ceph OSD
unless File.exist?("ceph-osd-worker#{i}.vdi")
v.customize ['createmedium', 'disk',
'--filename', "ceph-osd-worker#{i}.vdi",
'--size', 102400]
end
v.customize ['storageattach', :id,
'--storagectl', 'SCSI',
'--port', 2,
'--type', 'hdd',
'--medium', "ceph-osd-worker#{i}.vdi"]
end
end
end
end


# Khởi tạo toàn bộ lab
vagrant up

# SSH vào master1
vagrant ssh master1

# Kiểm tra connectivity
for i in 10 11 12 13 21 22 23; do
  ping -c 1 192.168.1.$i
done

4.4. Cấu hình SSH Keys cho tất cả nodes

# Trên máy workstation/jump host
ssh-keygen -t ed25519 -C "k8s-lab-admin" -f ~/.ssh/k8s-lab

Copy public key sang tất cả nodes


for host in lb master{1..3} worker{1..3}; do
ssh-copy-id -i ~/.ssh/k8s-lab.pub user@${host}
done


Tạo SSH config cho tiện


cat >> ~/.ssh/config << 'EOF'
Host lb
HostName 192.168.1.10
User root


Host master1
HostName 192.168.1.11
User root


Host master2
HostName 192.168.1.12
User root


Host master3
HostName 192.168.1.13
User root


Host worker1
HostName 192.168.1.21
User root


Host worker2
HostName 192.168.1.22
User root


Host worker3
HostName 192.168.1.23
User root


Host master* worker* lb
IdentityFile ~/.ssh/k8s-lab
StrictHostKeyChecking no
EOF

PHẦN 5: LỘ TRÌNH HỌC TẬP 50 BÀI

5.1. Dependency Graph giữa các phần


graph TD
    P1["📐 Phase 1: Foundation
Bài 1-4
Chuẩn bị hạ tầng cơ bản"]
    P2["☸ Phase 2: K8s HA
Bài 5-10
Dựng Kubernetes HA cluster"]
    P3["💿 Phase 3: Rook-Ceph
Bài 11-15
Distributed Storage"]
    P4["🐘 Phase 4: PostgreSQL HA
Bài 16-20"]
    P5["📨 Phase 5: MQ HA
Bài 21-23
RabbitMQ · Kafka · Redis"]
    P6["🔗 Phase 6: Istio
Bài 24-27
Service Mesh"]
    P7["🔄 Phase 7: GitOps
Bài 28-31
ArgoCD + Helm + Vault"]
    P8["📊 Phase 8: Observability
Bài 32-35"]
    P9["🛡️ Phase 9: Security
Bài 36-39"]
    P10["🚀 Phase 10: Deployment Patterns
Bài 40-43"]
    P11["💥 Phase 11: DR & Chaos
Bài 44-45"]
    P12["🏭 Phase 12: Operations + Capstone
Bài 46-50"]

    P1 --> P2
    P2 --> P3 & P5 & P6
    P3 --> P4
    P4 & P5 & P6 --> P7
    P7 --> P8 & P9
    P8 & P9 --> P10
    P10 --> P11
    P11 --> P12

    style P1 fill:#1e40af,stroke:#3b82f6,color:#fff
    style P2 fill:#1e40af,stroke:#3b82f6,color:#fff
    style P12 fill:#15803d,stroke:#22c55e,color:#fff

5.2. Thời gian dự kiến

Phần Số bài Giờ Timeline (2h/ngày)
Phần 1: Foundation 4 ~8h Tuần 1
Phần 2: K8s HA 6 ~14h Tuần 2-3
Phần 3: Rook-Ceph 5 ~11h Tuần 3-4
Phần 4: PostgreSQL 5 ~12h Tuần 5-6
Phần 5: MQ HA 3 ~8h Tuần 6-7
Phần 6: Istio 4 ~10h Tuần 7-8
Phần 7: GitOps 4 ~11h Tuần 9-10
Phần 8: Observability 4 ~10h Tuần 10-11
Phần 9: Security 4 ~10h Tuần 12-13
Phần 10: Deployment 4 ~9h Tuần 13-14
Phần 11: DR 2 ~5h Tuần 15
Phần 12: Operations 5 ~15h Tuần 15-18
TỔNG 50 ~123h ~18 tuần

PHẦN 6: CONVENTIONS VÀ QUY ƯỚC TRONG KHÓA HỌC

6.1. Naming Conventions

# Namespace naming
production:     prod-<service-name>     # prod-user-service
staging:        stg-<service-name>
infrastructure: infra-<component>       # infra-monitoring, infra-storage
platform:       platform-<component>    # platform-argocd, platform-vault

Helm release naming


<component>-<environment>              # postgresql-prod, redis-stg


Label standards


app.kubernetes.io/name: <service-name>
app.kubernetes.io/version: <version>
app.kubernetes.io/component: <component>
app.kubernetes.io/part-of: <system-name>
app.kubernetes.io/managed-by: helm

6.2. Ký hiệu trong bài học

  • 💡 Tip: Mẹo hữu ích, best practice
  • ⚠️ Warning: Cẩn thận, có thể gây lỗi
  • ❌ Danger: Tuyệt đối không làm trong production
  • 📋 Checklist: Danh sách cần kiểm tra
  • 🔬 Deep Dive: Giải thích chi tiết kỹ thuật
  • 🛠️ Lab: Bài thực hành

💡 KEY TAKEAWAYS

  1. On-premises microservices phù hợp cho tổ chức cần data sovereignty, predictable cost, và ultra-low latency
  2. Kubernetes HA là nền tảng orchestration, kết hợp với hệ sinh thái CNCF tools tạo thành production platform
  3. Stack đầy đủ gồm 6 layers: Infrastructure → Storage → Data → Networking → Platform → Security
  4. Mỗi công nghệ được chọn dựa trên tiêu chí: production-grade, CNCF backed, community active
  5. Lab environment cần tối thiểu 7 VMs (3 masters + 3 workers + 1 LB) với ~58GB RAM tổng

🎯 BÀI TẬP

Bài tập 1: Đánh giá yêu cầu hạ tầng

Cho kịch bản: Công ty fintech cần triển khai 20 microservices, xử lý 10,000 requests/giây, lưu trữ 500GB data, yêu cầu PCI-DSS compliance.

  • Tính toán số nodes cần thiết (control plane, workers, storage)
  • Ước tính tổng CPU, RAM, Storage
  • Vẽ network topology diagram
  • Liệt kê các components cần thiết từ stack trên

Bài tập 2: Setup Lab Environment

  • Tạo 7 VMs theo Option A hoặc Option B
  • Cấu hình networking giữa các VMs
  • Setup SSH key-based authentication
  • Verify ping connectivity giữa tất cả nodes
  • Ghi chép IP và hostname của từng VM

Bài tập 3: So sánh công nghệ

Nghiên cứu và so sánh chi tiết 2 cặp công nghệ:

  • Cilium vs Calico: Performance benchmarks, features, community
  • Rook-Ceph vs Longhorn: Scalability, features, operational complexity

📚 BÀI TIẾP THEO

Trong Bài 2: Lập kế hoạch phần cứng và Network Topology, chúng ta sẽ đi sâu vào việc tính toán sizing chi tiết cho CPU/RAM/Disk, thiết kế network topology với VLAN, bonding, và MTU cho production environment.