Kubernetes cơ bản bài 1 - Bài toán Scale và Tư duy Container Orchestration

K8s là một hệ thống điều phối (Container Orchestration) mã nguồn mở được Google thiết kế dựa trên kinh nghiệm vận hành hệ thống Borg của họ trong hàng chục năm

Kubernetes là gì và Bản chất của Declarative System

Nhiều người lầm tưởng Kubernetes đơn thuần là phiên bản nâng cấp của Docker Compose để chạy nhiều container hơn. Thực chất, K8s là một hệ thống điều phối (Container Orchestration) mã nguồn mở được Google thiết kế dựa trên kinh nghiệm vận hành hệ thống Borg của họ trong hàng chục năm.

Để hiểu K8s, bỏ qua các khái niệm rườm rà, bạn chỉ cần nắm vững một từ khóa cốt lõi: Declarative System (Hệ thống hướng khai báo).

Thay vì cấu hình theo kiểu Imperative (Mệnh lệnh) – tức là bạn phải chỉ định rõ từng bước Làm như thế nào (Ví dụ: 1. Tạo VM, 2. Cài Docker, 3. Chạy container A ở port 8080), K8s cho phép bạn tiếp cận theo kiểu Khai báo – tức là bạn chỉ cần mô tả Kết quả cuối cùng bạn muốn là gì.

Ví dụ: "Tôi muốn ứng dụng Web luôn có 5 bản sao hoạt động, sử dụng tối đa 1GB RAM mỗi bản, và nếu bản nào chết thì tự động thay thế ngay lập tức."

Phép màu đằng sau tư duy khai báo này nằm ở Reconciliation Loop (Vòng lặp đồng bộ). Hệ thống K8s liên tục quét và so sánh hai trạng thái:

Desired State (Trạng thái mong muốn): Những gì bạn khai báo trong file YAML.
Actual State (Trạng thái thực tế): Tình trạng đang chạy trên các server.

Nếu một container bị lỗi phần cứng và sập (Actual State = 4 bản sao), K8s ngay lập tức nhận ra sự sai lệch so với khai báo ban đầu (Desired State = 5 bản sao). Nó sẽ tự động tìm kiếm một server khác đang rảnh rỗi và khởi tạo một container mới để bù đắp, hoàn toàn không cần con người can thiệp.

Khoảng 15 năm trước, việc triển khai ứng dụng đơn giản là đẩy code lên một con server vật lý (Bare-metal), cấu hình Apache/Nginx, trỏ database và cầu nguyện cho nó không bị sập khi có traffic đột biến. Khi kiến trúc nguyên khối (Monolith) chạm ngưỡng giới hạn, chúng ta chuyển sang Microservices. Khi môi trường chạy xung đột, chúng ta có Docker.

Nhưng giải quyết được bài toán đóng gói không có nghĩa là giải quyết được bài toán vận hành. Đó là lúc Kubernetes (K8s) xuất hiện, không phải như một công cụ chạy container, mà là một hệ điều hành thực thụ cho trung tâm dữ liệu phân tán.

Tại sao kiến trúc truyền thống bế tắc khi Microservices phình to?

Trong giai đoạn đầu chia nhỏ hệ thống thành Microservices, Docker là một phép màu. Nó giải quyết triệt để câu chuyện muôn thuở của giới developer: "Code chạy ngon trên máy tôi, nhưng lên server thì lỗi".

Tuy nhiên, khi quy mô hệ thống không dừng lại ở 5-10 services mà phình to lên hàng trăm, hàng ngàn containers, những "nỗi đau" vận hành chí mạng bắt đầu xuất hiện:

Chết container đột ngột: Ai sẽ là người thức dậy lúc 3 giờ sáng để gõ lệnh docker restart khi một tiến trình bị crash do tràn RAM (OOM)?
Xung đột cổng (Port Mapping): Làm sao để chạy 50 bản sao của cùng một service web trên một vài máy chủ mà không bị trùng bọt (port conflict)?
Zero-Downtime Deployment: Cập nhật phiên bản mới đồng nghĩa với việc phải tắt container cũ, bật container mới, kéo theo vài giây đến vài phút gián đoạn dịch vụ.
Phân bổ tài nguyên thủ công: Việc quyết định container nào sẽ chạy trên server nào hoàn toàn dựa vào cảm tính hoặc các kịch bản script (Bash/Ansible) cứng nhắc, dẫn đến tình trạng server thì quá tải, server lại nằm chơi.

Khi hệ thống đạt đến quy mô này, sức người là không đủ. Chúng ta cần một "nhạc trưởng" để điều phối hàng ngàn nhạc công (containers) chơi cùng một bản nhạc một cách tự động và trơn tru.

Bộ não Control Plane và Worker Nodes phối hợp vận hành như thế nào?

Để duy trì vòng lặp kiểm soát liên tục đó, K8s thiết kế một kiến trúc phân tán mạnh mẽ, chia tách rõ ràng giữa nhóm quản lý và nhóm thực thi.

Control Plane (Bộ não điều khiển): Thường được đặt trên các Master Node, đây là trung tâm đầu não đưa ra mọi quyết định.

kube-apiserver: Cổng giao tiếp duy nhất của toàn bộ Cluster. Mọi yêu cầu từ người dùng (kubectl) hay giao tiếp nội bộ đều phải đi qua đây.
etcd: Trái tim lưu trữ của hệ thống. Đây là cơ sở dữ liệu Key-Value có tính nhất quán cao, lưu giữ toàn bộ thông tin cấu hình và trạng thái của Cluster (Desired & Actual State).
kube-scheduler: Kẻ phân phối tài nguyên. Khi có một ứng dụng mới cần chạy, Scheduler sẽ tính toán (CPU, RAM, chính sách phân phối) để chọn ra một Node phù hợp nhất để đặt ứng dụng đó lên.
kube-controller-manager: Nơi chứa các "Reconciliation Loops". Nó liên tục theo dõi hệ thống qua API Server và đưa ra hành động khắc phục khi có sự cố.

Worker Nodes (Nơi thực thi công việc): Các máy chủ (vật lý hoặc ảo) làm nhiệm vụ chạy khối lượng công việc (workloads).

Kubelet: Agent đại diện của K8s nằm trên từng Node. Nó nhận lệnh từ API Server, yêu cầu Container Runtime (containerd, CRI-O) khởi chạy container và báo cáo ngược lại tình trạng sức khỏe của Node.
Kube-proxy: Quản lý quy tắc mạng (network rules) trên Node, đảm bảo traffic từ bên ngoài hoặc giữa các ứng dụng được định tuyến đến đúng đích.

Rủi ro an ninh nằm ở đâu trong kiến trúc tổng quan của K8s?

Từ góc độ bảo mật, một hệ thống càng tự động hóa cao và có kiến trúc phân tán phức tạp thì bề mặt tấn công (attack surface) càng rộng. Kiến trúc của K8s tuyệt vời để scale, nhưng nếu không được thiết kế vùng cô lập (Isolation) đúng chuẩn ngay từ đầu, thảm họa là điều tất yếu.

Nhìn vào kiến trúc tổng quan, có hai "yết hầu" tử huyệt:

API Server phơi mình ra Internet: Vì API Server là cổng giao tiếp trung tâm, nhiều quản trị viên hệ thống thiếu kinh nghiệm thường để lộ cổng 6443 ra ngoài Internet để tiện cho việc dùng lệnh kubectl từ máy cá nhân. Nếu không có cơ chế xác thực mạnh (RBAC, OIDC) hoặc bị lộ Token, kẻ tấn công có thể dễ dàng gọi API để triển khai mã độc đào tiền ảo (Crypto-miner) lên toàn bộ hàng nghìn Node của bạn chỉ trong vài giây.
etcd - Kho báu không khóa: etcd lưu toàn bộ trạng thái hệ thống, bao gồm cả các thông tin cực kỳ nhạy cảm (Secrets, mật khẩu Database, API Keys). Mặc định, dữ liệu trong etcd không được mã hóa (chỉ được encode dạng Base64). Nếu kẻ tấn công xâm nhập được vào mạng nội bộ của Master Node và dump (trích xuất) được dữ liệu từ etcd, toàn bộ hệ thống Microservices của doanh nghiệp coi như sụp đổ.

Đó là lý do nguyên tắc bảo mật tối thượng khi thiết kế hạ tầng K8s là tách biệt hoàn toàn Control Plane khỏi khối lượng công việc của người dùng. Workloads (ứng dụng) không bao giờ được phép chạy chung trên Master Node, và mạng lưới giao tiếp với Control Plane phải được khóa chặt bằng tường lửa và thiết lập kết nối mã hóa (mTLS) khắt khe.

Thông tin tài liệu này

Kubernetes Thực Chiến – Từ Kiến Trúc Lõi Đến Vận Hành Tối Ưu. Mình là Lê Văn Phú đầy là bộ serries bài viết mình muốn chia sẻ tới các bạn như một cẩm nang xây dựng và bảo mật hệ thống Microservices quy mô lớn từ góc nhìn từ chuyên gia Cybersecurity & Systems như mình.

Hơn 15 năm trước, khi tôi chập chững bước những bước đầu tiên vào thế giới IT, việc vận hành hệ thống mang một hình hài hoàn toàn khác. Đó là những đêm dài thức trắng trong phòng máy chủ lạnh ngắt, tự tay bấm từng sợi dây cáp mạng, cấu hình từng con máy chủ vật lý (Bare-metal) và cầu nguyện cho nó không sập nguồn khi lượng người dùng đột ngột tăng cao.

Chúng ta đã đi một chặng đường rất dài. Từ máy chủ vật lý, chúng ta bước lên kỷ nguyên ảo hóa (Virtualization), rồi vỡ òa với sự tiện dụng của Docker và Container. Nhưng khi những hệ thống nguyên khối (Monolith) được đập bỏ để chuyển sang kiến trúc Microservices, một cơn ác mộng mới lại bắt đầu. Quản lý 10 container thì dễ, nhưng điều phối hàng ngàn container chạy chéo nhau, giao tiếp liên tục và không được phép gián đoạn lại là một bài toán vượt quá khả năng thao tác thủ công của con người.

Kubernetes ra đời để giải quyết bài toán đó. Nó không chỉ là một công cụ; nó là một hệ điều hành thực thụ cho trung tâm dữ liệu phân tán.

Tuy nhiên, có một sự thật phũ phàng trong thế giới kỹ thuật: Những tài liệu hướng dẫn (tutorial) trên mạng thường chỉ chỉ cho bạn "happy path" – con đường màu hồng nơi mọi thứ đều hoạt động trơn tru. Nhưng ở môi trường Production thực tế, hệ thống không chết vì bạn gõ sai một dòng lệnh, mà nó sụp đổ vì những thứ bạn không nhìn thấy. Nó sụp đổ vì một container bị rò rỉ bộ nhớ ăn hết tài nguyên của Node, vì dữ liệu cấu hình bị lộ trên etcd, hay vì một lỗ hổng trong mạng nội bộ cho phép kẻ tấn công đi thẳng từ Web Frontend vào Database tĩnh lặng.

Với tư cách là một kỹ sư hệ thống và một chuyên gia an toàn thông tin (Cybersecurity) đã trực tiếp triển khai, đập đi xây lại và vá lỗi cho vô số hệ thống quy mô lớn, tôi nhận ra một khoảng trống lớn trong cách chúng ta học về Kubernetes. Chúng ta học cách triển khai (deploy) rất nhanh, nhưng lại học cách bảo vệ (secure) và sống sót (operate) quá chậm – thường là sau khi đã phải trả giá bằng những sự cố downtime thảm khốc.

Đó là lý do bộ tài liệu này ra đời.

Cuốn sách này không được viết ra để liệt kê lại các câu lệnh kubectl mà bạn có thể dễ dàng tìm thấy trên trang chủ. Nó được đúc kết từ những bài học xương máu, từ việc tra cứu từng gói tin (packet) ở tầng mạng, phân tích từng rủi ro cạn kiệt tài nguyên ở tầng Kernel, cho đến việc thiết lập phòng thủ đa tầng theo chuẩn DevSecOps.

Dù bạn là một Fresher đang muốn xây dựng tư duy hệ thống chuẩn mực ngay từ đầu, hay một Senior/DevOps Engineer đang tìm kiếm lời giải cho bài toán chịu tải và bảo mật ở cấp độ Enterprise, tôi tin bạn sẽ tìm thấy giá trị trong những trang viết này.

Hệ thống tốt không tự nhiên sinh ra, nó được rèn giũa qua những lần vấp ngã và sự chuẩn bị kỹ lưỡng. Chào mừng bạn đến với thế giới của Kubernetes thực chiến.

Hướng dẫn cài đặt k8s

Để làm chủ Kubernetes, bạn không thể chỉ đọc lý thuyết. Bạn cần một môi trường sandbox cách ly để tự tay đánh sập hệ thống, thử nghiệm các chính sách bảo mật mạng theo mô hình Zero Trust và thực hành khôi phục dữ liệu mà không sợ ảnh hưởng đến môi trường thực tế (production) của doanh nghiệp.

Thay vì dùng các công cụ đóng gói sẵn như Minikube hay Docker Desktop vốn che giấu quá nhiều chi tiết tầng dưới, hướng dẫn này sẽ sử dụng kubeadm trên hệ điều hành Ubuntu. Đây là công cụ chuẩn mực nhất giúp bạn tự tay lắp ráp từng mảnh ghép và hiểu rõ quá trình giao tiếp giữa Control Plane và Worker Node đúng như kiến trúc chúng ta đã phân tích trong cuốn sách này.

Yêu cầu chuẩn bị tối thiểu là hai máy ảo (Virtual Machines) chạy Ubuntu 22.04 hoặc 24.04, bao gồm một Master Node và một Worker Node, mỗi máy có ít nhất 2 CPU và 4GB RAM.

Chuẩn bị môi trường hệ điều hành:

Thực hiện trên tất cả các Node.

Kubernetes yêu cầu tắt bộ nhớ ảo (Swap) hoàn toàn để Kubelet có thể tính toán và phân bổ tài nguyên chính xác. Đồng thời, bạn cần nạp các module Kernel phục vụ cho việc định tuyến gói tin mạng.

# Tắt swap tạm thời và vô hiệu hóa vĩnh viễn trong fstab
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# Nạp module overlay và br_netfilter cho mạng
cat <

Cài đặt Container Runtime:

Sử dụng containerd trên tất cả các Node.

Kubernetes hiện đại đã ngừng hỗ trợ Docker mặc định. Thay vào đó, chúng ta sẽ cài đặt containerd làm môi trường chạy vùng chứa ở tầng thấp.

sudo apt-get update
sudo apt-get install -y containerd

# Tạo file cấu hình mặc định cho containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# Bật SystemdCgroup (bắt buộc để Kubelet quản lý tài nguyên cgroups của Linux)
sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

Cài đặt kubeadm kubelet và kubectl:

Thực hiện trên tất cả các Node.

Đây là ba mảnh ghép cốt lõi. Trong đó kubeadm dùng để khởi tạo cụm, kubelet là tác nhân chạy trên từng node và kubectl là công cụ dòng lệnh để giao tiếp với API Server.

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

# Tải khóa GPG và thêm kho lưu trữ K8s (Ví dụ bản 1.30)
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

# Cài đặt và khóa phiên bản để tránh việc vô tình nâng cấp tự động gây lỗi
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Khởi tạo Control Plane:

Chỉ thực hiện trên Master Node.

Bước này sẽ tự động sinh ra các chứng chỉ bảo mật TLS, thiết lập cơ sở dữ liệu etcd và khởi chạy nhóm quản lý (API Server, Scheduler, Controller Manager).

sudo kubeadm init --pod-network-cidr=192.168.0.0/16

Sau khi lệnh chạy xong, hệ thống sẽ in ra một đoạn mã bắt đầu bằng kubeadm join. Hãy lưu lại đoạn mã này để dùng cho bước kết nối các Worker Node. Tiếp theo, cấp quyền cho tài khoản hiện tại để sử dụng dòng lệnh kubectl.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Triển khai CNI cung cấp giao tiếp mạng nội bộ:

Sử dụng Calico để kích hoạt Network Policies.

Lúc này nếu kiểm tra trạng thái Node, bạn sẽ thấy Master Node đang báo NotReady vì cụm chưa có hệ thống mạng. Chúng ta sẽ cài đặt Calico để định tuyến gói tin và kích hoạt tính năng Tường lửa nội bộ.

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml

Kết nối các Node vào cụm:

Chỉ thực hiện trên Worker Node.

Chuyển sang màn hình dòng lệnh của Worker Node, sử dụng lệnh kubeadm join mà bạn đã lưu lại ở bước khởi tạo Control Plane (cần quyền sudo).

# Ví dụ minh họa (bạn cần thay thế bằng token và hash thực tế của mình)
sudo kubeadm join 10.0.0.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:mã_hash_được_cấp_của_bạn

Sau vài phút, hãy quay lại Master Node và gõ lệnh kiểm tra. Khi trạng thái chuyển sang Ready, bạn đã chính thức sở hữu một cụm Kubernetes thực thụ và sẵn sàng cho các bài thực hành chuyên sâu.