[Part 1] Kiến trúc Kubernetes Cluster và chuẩn bị môi trường

Trước khi bắt đầu cài đặt Kubernetes, điều quan trọng là phải hiểu một Kubernetes cluster thực chất được tổ chức như thế nào.

Ở mức tổng thể, Kubernetes được thiết kế theo mô hình control plane – worker node, trong đó control plane chịu trách nhiệm quản lý trạng thái của hệ thống, còn worker node cung cấp tài nguyên để chạy các workload.

Trong bài viết này, chúng ta sẽ:

• Tìm hiểu kiến trúc cơ bản của Kubernetes cluster
• Hiểu vai trò của từng thành phần trong control plane
• Chuẩn bị hạ tầng và môi trường lab cho các bước cài đặt ở những phần tiếp theo

Kiến trúc tổng thể của Kubernetes Cluster

Một Kubernetes cluster thường có kiến trúc như sau:

Một Kubernetes cluster thực chất là một hệ thống phân tán gồm nhiều node phối hợp với nhau để chạy containerized workloads. Các thành phần trong cluster được chia thành hai nhóm chính:

• Control Plane – quản lý và điều phối toàn bộ cluster
• Worker Nodes – nơi các ứng dụng container thực sự chạy

Control Plane đóng vai trò như “bộ não” của hệ thống. Nó nhận các yêu cầu từ người dùng hoặc hệ thống tự động (CI/CD, controllers), sau đó quyết định ứng dụng nên chạy ở đâu, trạng thái mong muốn của cluster là gì, và làm thế nào để duy trì trạng thái đó.

Worker Nodes, ngược lại, là các máy chủ chịu trách nhiệm chạy workload thực tế. Mỗi worker node sẽ chạy các Pod, trong đó Pod chứa một hoặc nhiều container của ứng dụng.

Control Plane Components

Control Plane bao gồm một số thành phần cốt lõi phối hợp với nhau để quản lý cluster.

👉 kube-apiserver: API Server là trung tâm giao tiếp của Kubernetes.

• Mọi thao tác với cluster: từ kubectl, các controller, cho đến các hệ thống tự động hóa, đều đi qua API Server.
• API Server cung cấp RESTful API, cho phép các thành phần khác đọc và ghi trạng thái của cluster. Tất cả dữ liệu cấu hình, trạng thái Pod, Node, Deployment… đều được truy cập thông qua lớp API này.

👉 etcd: cơ sở dữ liệu distributed key-value store lưu trữ toàn bộ trạng thái của cluster. Các thông tin được lưu trong etcd:

• Cấu hình cluster
• Thông tin Node
• Trạng thái Pod
• Secret và config…
• Control Plane sẽ liên tục đọc và ghi dữ liệu vào etcd để đảm bảo trạng thái thực tế của hệ thống khớp với trạng thái mong muốn (desired state).

👉 kube-scheduler: chịu trách nhiệm quyết định Pod sẽ được chạy trên Node nào. Khi một Pod mới được tạo ra nhưng chưa được gán Node, Scheduler sẽ:

• Lấy danh sách các Node khả dụng
• Áp dụng các chính sách scheduling (resource, affinity, taints…)
• Chọn Node phù hợp nhất cho Pod
• Sau đó thông tin này sẽ được ghi lại thông qua API Server.

👉 kube-controller-manager: chạy nhiều control loop khác nhau để đảm bảo trạng thái cluster luôn đúng với cấu hình mong muốn. Một số controller phổ biến:

• Node Controller
• Replication Controller
• Deployment Controller
• Endpoint Controller …
• Các controller này liên tục theo dõi trạng thái cluster và thực hiện các hành động cần thiết. Ví dụ: nếu một Pod bị mất, controller sẽ tạo Pod mới để đảm bảo số replica đúng như khai báo.

Worker Node Components

Worker Node là nơi các workload thực sự được chạy. Mỗi Worker Node thường bao gồm hai thành phần chính.

👉 kubelet là agent chạy trên mỗi node. Nó chịu trách nhiệm:

• Nhận thông tin Pod từ API Server
• Khởi chạy container thông qua container runtime
• Giám sát trạng thái Pod
• Báo cáo trạng thái node và pod về Control Plane
• Có thể xem kubelet như cầu nối giữa Control Plane và máy chủ thực tế.

👉 kube-proxy: chịu trách nhiệm thiết lập các quy tắc mạng trên node để hỗ trợ Kubernetes Service.

• Quản lý các rule (thường thông qua iptables hoặc IPVS) để đảm bảo lưu lượng mạng được chuyển đúng đến Pod phía sau một Service.
• Nhờ kube-proxy, các Pod có thể được truy cập thông qua một endpoint ổn định, ngay cả khi Pod phía sau thay đổi.

Từ góc nhìn kiến trúc, Kubernetes được tổ chức theo mô hình phân tách rõ ràng giữa Control Plane và Worker Nodes.

• Control Plane chịu trách nhiệm quản lý toàn bộ cluster và quyết định trạng thái mong muốn (desired state) của hệ thống, trong khi các Worker Nodes sẽ thực thi workload dựa trên trạng thái đó.
• Mọi tương tác với cluster đều đi qua API Server, đóng vai trò là trung tâm giao tiếp giữa người dùng, các thành phần trong hệ thống và các công cụ tự động hóa. 
• Toàn bộ trạng thái và cấu hình của cluster được lưu trữ trong etcd, một cơ sở dữ liệu key-value phân tán.
• Bên cạnh đó, Scheduler và các Controllers liên tục theo dõi trạng thái thực tế của hệ thống và thực hiện các điều chỉnh cần thiết để đảm bảo cluster luôn duy trì đúng trạng thái đã được định nghĩa.

Nhờ cơ chế theo dõi trạng thái liên tục giữa Control Plane và các Worker Nodes, Kubernetes có thể tự động điều chỉnh hệ thống khi có sự thay đổi hoặc sự cố xảy ra. Điều này giúp cluster duy trì trạng thái ổn định và đảm bảo workload luôn được vận hành đúng như mong muốn.

Chuẩn bị môi trường lab

Trước khi bắt đầu xây dựng Kubernetes cluster, chúng ta cần chuẩn bị một môi trường hạ tầng tối thiểu để thực hiện các bước bootstrap hệ thống.

Trong thực tế, Kubernetes có thể chạy trên nhiều loại hạ tầng khác nhau: từ máy vật lý (bare-metal), máy ảo trong datacenter, cho tới các môi trường cloud. Tuy nhiên để phục vụ mục tiêu học tập và hiểu rõ các thành phần bên trong Kubernetes, chúng ta sẽ triển khai một cluster nhỏ với cấu trúc tối giản nhưng đầy đủ các thành phần cốt lõi.

Tùy vào mục đích sử dụng, Kubernetes có thể được triển khai theo nhiều mô hình khác nhau.

Mô hình tối giản (Single Node)

Đây là mô hình đơn giản nhất, trong đó Control Plane và Worker chạy trên cùng một node. Mô hình này thường được sử dụng cho:

• Môi trường local development

• các công cụ như minikube, kind, hoặc k3s
• Ưu điểm là triển khai rất nhanh, tuy nhiên không phản ánh đúng kiến trúc thực tế của Kubernetes cluster.

Mô hình tách Control Plane và Worker

Đây là mô hình phổ biến hơn trong các cluster nhỏ hoặc môi trường lab.  trong mô hình này Control Plane và Worker Nodes được tách riêng và chạy trên các máy chủ hoặc máy ảo khác nhau. Việc tách biệt này giúp hệ thống dễ dàng mở rộng, đồng thời đảm bảo tính ổn định khi cluster vận hành workload ở quy mô lớn.

Kiến trúc triển khai

Trong các môi trường production, Control Plane thường được triển khai theo mô hình high availability (HA) với tối thiểu 3 node control plane. Cấu hình này giúp cluster vẫn có thể tiếp tục hoạt động ngay cả khi một node control plane gặp sự cố.

Tuy nhiên, đối với mục tiêu học tập hoặc môi trường thử nghiệm, việc triển khai đầy đủ mô hình HA là không thực sự cần thiết và cũng tiêu tốn nhiều tài nguyên hơn. Vì vậy, trong phạm vi của series này chúng ta sẽ sử dụng một cấu hình tối thiểu của mô hình phân tách, trong đó:

• 1 node Control Plane
• 1–2 Worker Nodes

Cấu hình này đủ để chúng ta hiểu rõ cách các thành phần của Kubernetes được bootstrap và cách cluster vận hành trong thực tế. Cụ thể, lab trong hướng dẫn sẽ sử dụng 4 máy với cấu hình như sau:

Jumpbox

Jumpbox là máy quản trị trung tâm được sử dụng để thực hiện toàn bộ các thao tác cấu hình và bootstrap cluster. Thay vì thao tác trực tiếp trên từng node, chúng ta sẽ sử dụng jumpbox như một điểm truy cập quản trị duy nhất.

Trong quá trình xây dựng cluster, jumpbox sẽ được sử dụng để:

• chạy các script cấu hình hệ thống
• tạo certificate và thiết lập hạ tầng TLS cho Kubernetes
• tạo các file kubeconfig phục vụ việc xác thực
• điều khiển cluster thông qua công cụ kubectl

Cách tiếp cận này khá phổ biến trong nhiều môi trường production, nơi các node trong cluster thường được truy cập thông qua một administration host hoặc bastion host thay vì truy cập trực tiếp từ bên ngoài.

Control Plane (server)

Node này chạy các thành phần quan trọng của Kubernetes:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• etcd

Control Plane chịu trách nhiệm:

• quản lý trạng thái cluster
• tiếp nhận API request
• lập lịch Pod
• đảm bảo hệ thống luôn đạt trạng thái mong muốn

Worker Nodes (node-0, node-1)

Các Worker Node là nơi thực sự chạy workload của hệ thống.

Trên mỗi worker node sẽ có các thành phần:

• kubelet – agent quản lý Pod trên node
• kube-proxy – thiết lập các rule mạng cho service
• container runtime – chạy container

Các Pod và container của ứng dụng sẽ được scheduler phân phối xuống các worker node này.

Yêu cầu về hệ điều hành 

Tất cả các máy trong lab cần chạy:

Debian 12 (bookworm)

Bạn có thể kiểm tra phiên bản hệ điều hành bằng lệnh:

cat /etc/os-release

Kết quả mong đợi:

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

NAME="Debian GNU/Linux"

VERSION_ID="12"

VERSION="12 (bookworm)"

VERSION_CODENAME=bookworm

ID=debian

Kubernetes được thực hiện nhất quán. Việc sử dụng cùng một phiên bản hệ điều hành giúp đảm bảo các bước cài đặt và cấu hình 

Sau khi đã hiểu kiến trúc của Kubernetes và chuẩn bị xong môi trường hạ tầng, chúng ta đã sẵn sàng bước vào phần quan trọng nhất: bắt đầu xây dựng cluster từ những thành phần đầu tiên.

Trong Part 2, chúng ta sẽ thiết lập jumpbox – điểm quản trị trung tâm của cluster – và chuẩn bị các công cụ cần thiết cho quá trình bootstrap Kubernetes.