Nếu bạn từng thắc mắc làm thế nào các ứng dụng có thể chạy ổn định dù nằm trên hàng trăm máy chủ khác nhau, câu trả lời nằm ở Kubernetes architecture. Đây là kiến trúc đứng sau khả năng tự động hóa, cân bằng tải và mở rộng linh hoạt của Kubernetes. Hiểu được cách Kubernetes được xây dựng chính là bước đầu tiên để bạn nắm vững cách hệ thống này vận hành trong thực tế.
Đọc bài viết sau để biết thêm về:
- Tổng quan về Kubernetes architecture
- Các thành phần chính trong Kubernetes architecture
- Cách Kubernetes architecture vận hành
- Bảo mật và phân quyền trong kiến trúc Kubernetes
- Ứng dụng thực tế của Kubernetes Architecture
Tổng quan về Kubernetes architecture
Kubernetes architecture là gì?
Kubernetes architecture đóng vai trò như “bộ khung”, xác định cách các thành phần trong hệ thống (Control Plane, Worker Nodes, Pods, Services, ConfigMaps, Secrets và API Server). Nó giúp các thành phần trong hệ thống Kubernetes phối hợp với nhau để triển khai, giám sát và duy trì ứng dụng container hoạt động tự động, ổn định và linh hoạt.
Hiểu rõ Kubernetes architecture giúp bạn nắm được cách các bộ phận cốt lõi như API Server, etcd, Scheduler, Kubelet, kube-proxy và các thành phần khác tương tác với nhau. Đây là nền tảng quan trọng để bạn tiếp tục khám phá cách Kubernetes mở rộng (scaling), cân bằng tải (load balancing), tự phục hồi (self-healing) và bảo mật hệ thống.
Đọc chi tiết: Kubernetes là gì: Toàn diện kiến thức Kubernetes nền tảng cần biết
Vai trò của Kubernetes architecture
Nhờ kiến trúc này, Kubernetes có thể xử lý nhiều máy chủ (nodes), đảm bảo nếu một node gặp sự cố, các ứng dụng vẫn tiếp tục chạy và được phục hồi nhanh chóng. Việc quản lý hàng trăm, thậm chí hàng nghìn container trở nên dễ dàng hơn.
Cụ thể vai trò của Kubernetes architecture là:
- Tự động điều phối tài nguyên, phân bổ container đến các node phù hợp trên các yêu cầu về tài nguyên (CPU, memory) và ràng buộc (constraints, affinity rules).
- Đảm bảo tính sẵn sàng cao (High Availability): Khi một node gặp sự cố, workload được tự động chuyển sang node khác thông qua cơ chế reschedule của Scheduler.
- Tự phục hồi (self-healing) khi ứng dụng bị lỗi hoặc pod bị mất kết nối bằng cách tự động restart pod, thay thế pod bị lỗi, hoặc kill các pod không phản hồi health check.
- Mở rộng linh hoạt (auto-scaling) tùy theo nhu cầu thực tế thông qua Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), và Cluster Autoscaler.
Nói cách khác, kiến trúc Kubernetes chính là nền tảng giúp người dùng vận hành hệ thống container ở quy mô lớn mà vẫn đảm bảo tính ổn định, hiệu suất và bảo mật cao.
Các thành phần chính trong Kubernetes architecture
Kubernetes có kiến trúc phân tầng (layered architecture) với hai phần chính: Control Plane (máy chủ điều khiển) và Worker Nodes (máy chủ thực thi). Mỗi phần chứa các thành phần riêng biệt đảm nhận các nhiệm vụ cụ thể để quản lý và vận hành container một cách hiệu quả.
Nguồn: Platform9
Control Plane (vùng điều khiển)
Control Plane là trung tâm quản lý logic của cluster – nơi ra quyết định, giám sát và điều phối trạng thái của hệ thống.
Các thành phần của Control Plane:
- API Server (kube-apiserver): Là cửa ngõ chính (entry-point) và frontend của Control Plane để nhận các yêu cầu từ người dùng (qua kubectl hoặc các công cụ khác), xác thực & phân phối chúng tới các thành phần khác trong cluster. Tất cả các thành phần khác đều giao tiếp qua API Server.
- etcd: Kho lưu trữ key-value phân tán có tính nhất quán cao (consistent) giữ trạng thái và cấu hình của cluster; mọi thay đổi trạng thái được ghi tại đây như là nguồn chân thực (source of truth). etcd sử dụng thuật toán Raft consensus để đảm bảo tính nhất quán dữ liệu. Chỉ API Server mới giao tiếp trực tiếp với etcd.
- Scheduler (kube-scheduler): Chịu trách nhiệm lựa chọn node phù hợp cho các Pod chưa được phân bổ, dựa trên tài nguyên khả dụng (CPU, memory), quy tắc affinity/anti-affinity ràng buộc, hạn chế, và chính sách đã định.
- Controller Manager (kube-controller-manager): Chạy các controller (ví dụ: Node Controller, Replication Controller, Deployment Controller,Service Controller, Endpoint Controller…) – những thành phần đảm bảo trạng thái thực tế của cluster khớp với trạng thái mong muốn (ví dụ: giữ số lượng Pod, quản lý node).
Ngoài ra còn có cloud-controller-manager (tuỳ chọn, nếu chạy trên môi trường cloud): Thực hiện các tác vụ tương tác với nhà cung cấp đám mây, chẳng hạn quản lý load balancer, gắn volume, hoặc kiểm tra tài nguyên cloud.
Control Plane vs Data Plane có gì khác nhau?
| Tiêu chí | Control Plane | Data Plan |
| Vai trò chính | Là “bộ não” trong Kubernetes architecture – quản lý, điều phối và duy trì trạng thái mong muốn của cluster | Là “cánh tay” thực thi – nơi các container và ứng dụng thực tế được chạy |
| Vị trí hoạt động | Chạy trên các Master Nodes hoặc các node chuyên biệt dành cho điều khiển | Chạy trên các Worker Nodes trong cluster |
| Nhiệm vụ chính | Ra quyết định, lập kế hoạch, giám sát và điều phối tài nguyên | Thực hiện lệnh từ Control Plane, chạy và giám sát các container |
| Thành phần tiêu biểu | – API Server – etcd – Controller Manager – Scheduler – Cloud Controller Manager | – Kubelet – Kube-proxy – Container Runtime – Pods |
| Mức độ tương tác | Nhận yêu cầu từ người dùng và giao tiếp với Data Plane để triển khai hoặc điều chỉnh ứng dụng | Gửi báo cáo trạng thái và phản hồi lại các lệnh từ Control Plane |
| Ảnh hưởng khi gặp sự cố | Nếu Control Plane ngừng hoạt động, cluster tạm thời không thể triển khai mới hoặc điều phối tài nguyên nhưng workload hiện tại vẫn tiếp tục chạy | Không thể triển khai mới hoặc điều phối tài nguyênNếu Data Plane gặp sự cố, các Pod trên node đó có thể bị mất, nhưng Control Plane sẽ tự khôi phục bằng cách tạo Pod mới |
| Mục tiêu thiết kế | Duy trì trạng thái mong muốn của hệ thống (declarative state management) | Đảm bảo workload chạy ổn định, hiệu suất cao |
Tóm lại: Control Plane giống như “trung tâm chỉ huy” của Kubernetes. Còn Data Plane giống như “các đội thi công” thực hiện nhiệm vụ do trung tâm giao xuống.
Worker Nodes (vùng dữ liệu / xử lý công việc)
Worker Nodes là nơi thực thi ứng dụng thực tế (workloads). Mỗi node trong lớp này cần có các thành phần sau:
- kubelet: Là agent chạy trên mỗi Worker Node. Kubelet nhận chỉ thị từ Control Plane thông qua API Server và đảm bảo rằng các container được chạy đúng theo định nghĩa Pod, báo cáo trạng thái node và Pod về API Server định kỳ.
- Pods: Mặc dù không hẳn là một thành phần “cơ sở hạ tầng của node”, Pod là đơn vị nhỏ nhất mà Kubernetes triển khai. Mỗi Pod có thể chứa một hoặc nhiều container cùng chia sẻ mạng namespace, storage volumes, và lifecycle.
- Container Runtime: Phần mềm chịu trách nhiệm khởi chạy, dừng và quản lý lifecycle của container theo chuẩn Container Runtime Interface (CRI) (ví dụ như Docker, containerd, CRI-O). Container Runtime giao tiếp với kubelet qua CRI (Container Runtime Interface). Docker đã bị ngừng hỗ trợ làm container runtime kể từ Kubernetes phiên bản 1.20, và bị loại bỏ hoàn toàn kể từ phiên bản 1.24.
- kube-proxy: Component mạng chạy trên mỗi node, Công cụ xử lý mạng, cung cấp dịch vụ routing và load balancing nội bộ cho các Pod. Kube-proxy theo dõi các service và tạo các quy tắc iptables hoặc sử dụng các công nghệ mạng khác để chuyển tiếp lưu lượng đúng đến các Pod backend.
Thành phần hỗ trợ khác:
- Namespaces: Phân vùng logic trong cluster giúp chia sẻ tài nguyên, cô lập giữa các nhóm hoặc môi trường khác nhau (dev, staging, production). Default namespaces bao gồm: default, kube-system, kube-public, kube-node-lease.
- Volumes / Storage: Cung cấp lưu trữ bền vững cho container thông qua các loại volume types (emptyDir, hostPath, PersistentVolume, etc.), giúp dữ liệu có thể tồn tại qua các phiên bản hoặc đời sống Pod. StorageClass cho phép dynamic provisioning của Persistent Volumes.
- Services: Cung cấp abstraction layer ổn định để kết nối, cân bằng tải giữa các Pod, đảm bảo các Pod được truy cập ổn định ngay cả khi IP của chúng thay đổi. Các loại Service: ClusterIP (default), NodePort, LoadBalancer, ExternalName.
Cách Kubernetes architecture vận hành
Kiến trúc Kubernetes vận hành dựa trên sự phối hợp giữa các thành phần Control Plane và Data Plane để triển khai, giám sát và duy trì các ứng dụng container.
Dưới đây là quy trình hoạt động chính:
Gửi yêu cầu tới API Server
Khi người dùng hoặc hệ thống gửi lệnh (qua kubectl hoặc giao diện API), yêu cầu được gửi tới API Server, thành phần trung tâm tiếp nhận và xử lý yêu cầu. API Server sẽ:
- Xác thực (Authentication) và phân quyền (Authorization) người dùng.
- Sau đó ghi nhận yêu cầu vào kho dữ liệu trung tâm etcd.
Lưu trạng thái mong muốn trong etcd
etcd là nơi lưu trữ “trạng thái mong muốn” (desired state) của cluster, chẳng hạn số lượng Pod cần chạy, cấu hình mạng, secrets, v.v. Tất cả các thay đổi từ API Server đều được ghi vào etcd một cách nhất quán và theo cơ chế giao dịch nguyên tử (atomic).
Controller Manager giám sát và điều chỉnh
Controller Manager (với các controller như Deployment Controller, ReplicationController, Node Controller…) liên tục so sánh trạng thái thực tế (actual state) với trạng thái mong muốn trong etcd thông qua cơ chế quan sát.
Nếu phát hiện sai lệch (ví dụ: một Pod bị crash hoặc bị xóa), nó sẽ kích hoạt quy trình đồng bộ (reconciliation) để đưa hệ thống về trạng thái mong muốn.
Scheduler phân công Pod vào Node
Scheduler (bộ lập lịch) sẽ chọn Node phù hợp để chạy các Pod mới, dựa trên:
- Nguồn lực sẵn có (CPU, RAM)
- Chất lượng dịch vụ (QoS classes)
- Các giới hạn (taints, tolerations)
- Quy tắc ràng buộc (affinity, anti-affinity)
Scheduler sử dụng thuật toán lọc và chấm điểm (filtering & scoring algorithm) để tìm ra node tối ưu nhất. Khi quyết định được đưa ra, Scheduler sẽ ghi thông tin gán kết (binding) giữa Pod và Node vào API Server.
Kubelet và Container Runtime triển khai Pod
Kubelet trên Worker Node nhận chỉ thị từ Control Plane thông qua watch API Server và chịu trách nhiệm khởi tạo Pod, theo định nghĩa từ file manifest.
Container Runtime (ví dụ: containerd, CRI-O) sẽ pull image thực thi container trong Pod đó. Kubelet giám sát tình trạng container thông qua health checks (liveness/readiness probes) và báo cáo lại cho API Server.
Mạng & truy cập dịch vụ (Service Discovery)
Kube-proxy trên mỗi Node chịu trách nhiệm định tuyến và cân bằng tải giữa các Pod dựa trên Service. Kube-proxy có thể hoạt động ở các mode: userspace, iptables, hoặc IPVS. Ngoài ra, hệ thống DNS nội bộ (ví dụ CoreDNS) giúp ánh xạ tên dịch vụ sang địa chỉ IP của Pod hoặc Service tương ứng thông qua DNS A/AAAA records và SRV records
Vòng lặp kiểm tra và tự phục hồi (Self-healing)
Kiến trúc Kubernetes liên tục kiểm tra trạng thái:
- Nếu một container hoặc Pod bị lỗi, Kubelet sẽ khởi động lại container dựa trên restartPolicy. Nếu Pod fail hoàn toàn, Control Plane sẽ phát hiện và tái khởi tạo Pod mới thông qua ReplicaSet/Deployment controller.
- Nếu Node bị lỗi, Scheduler sẽ chuyển workload sang node khác khỏe mạnh sau khi hết thời gian pod-eviction-timeout.
- etcd, Controller Manager, API Server cũng có thể được triển khai ở chế độ High Availability (HA) với nhiều bản sao (replicas) để tránh điểm lỗi đơn (Single Point of Failure – SPOF).
Bảo mật trong Kubernetes architecture: Authentication vs Authorization
Trong Kubernetes architecture, xác thực và phân quyền (authentication & authorization) đóng vai trò thiết yếu để bảo vệ hệ thống khỏi truy cập trái phép và đảm bảo rằng mọi người dùng hoặc thành phần chỉ làm được những hành động được phép.
Hiểu cách Kubernetes xử lý xác thực và phân quyền là bước không thể thiếu để nắm vững cách kiến trúc Kubernetes vận hành và bảo vệ tài nguyên trong cluster.
Xác thực (Authentication) – “Bạn là ai?”
Mọi yêu cầu gửi đến API Server đều phải qua bước xác thực để xác nhận danh tính người dùng hoặc thành phần gửi yêu cầu.
Kubernetes không duy trì hệ thống tài khoản nội bộ như các ứng dụng truyền thống. Thay vào đó, nó dựa vào nhiều phương thức xác thực khác nhau, bao gồm:
- Chứng chỉ khách hàng X.509 (X.509 Client Certificates)
- Mã thông báo (Bearer Tokens)
- Service Account Tokens
- OpenID Connect Tokens (OIDC – liên kết với hệ thống đăng nhập bên ngoài)
- Proxy xác thực (Authentication Proxy)
Ví dụ: người dùng dùng kubectl sẽ cung cấp chứng chỉ hoặc token từ kubeconfig file để gửi yêu cầu đến API Server, API Server sẽ kiểm tra hợp lệ rồi chấp nhận hoặc từ chối.
Phân quyền (Authorization) – “Bạn được làm gì?”
Sau khi xác thực thành công, hệ thống xác định xem người dùng có quyền thực hiện hành động cụ thể (như tạo Pod, PersistentVolume…) trên tài nguyên nào hay không.
Kubernetes có nhiều mô hình phân quyền:
- RBAC (Role-Based Access Control): cách phổ biến và được khuyến nghị — gán vai trò (Roles / ClusterRoles) cho người dùng hoặc service account để kiểm soát quyền theo namespace hoặc toàn cluster. RBAC sử dụng RoleBinding và ClusterRoleBinding để liên kết vai trò (roles) với chủ thể (subjects).
- ABAC (Attribute-Based Access Control): kiểm soát theo thuộc tính (user, group, namespace…) nhưng khó quản lý khi hệ thống lớn và yêu cầu restart API Server khi thay đổi policy.
- Node Authorizer / Webhook:
- Node Authorizer: xử lý quyền đặc biệt cho Kubelet, đảm bảo mỗi node chỉ có thể truy cập tài nguyên được phép.
- Webhook Authorizer: cho phép tích hợp hệ thống phân quyền bên ngoài, ví dụ gọi tới API tùy chỉnh để đưa ra quyết định truy cập.
API Server xử lý phân quyền nội bộ, tất cả các yêu cầu đều được áp dụng nguyên tắc “deny by default” – nếu không có quyền hợp lệ, yêu cầu sẽ bị từ chối.
Bảo mật các thành phần nội bộ
Trong Kubernetes architecture, không chỉ người dùng mà các thành phần nội bộ cũng cần được xác thực và phân quyền chặt chẽ. Nếu không, kẻ xấu có thể truy cập API nội bộ của node để thực hiện các hành động như exec vào container.
- etcd là nơi lưu trữ trạng thái cluster, bao gồm cả dữ liệu nhạy cảm như Secrets. Việc truy cập etcd đòi hỏi chứng chỉ và quyền truy cập chặt chẽ.
- Quy tắc về least privilege (quyền tối thiểu): Chỉ cấp cho người dùng và service account những quyền họ thật sự cần, giúp giảm rủi ro khi có lỗ hổng.
- Sử dụng các webhook admission controllers để kiểm tra sâu hơn các yêu cầu, áp dụng chính sách bổ sung trước khi tài nguyên được chấp nhận.
Các câu hỏi thường gặp về Kubernetes architecture
Kubernetes có thể chạy mà không cần Docker không?
Có, Kubernetes có thể chạy mà không cần Docker. Trong Kubernetes architecture, Docker chỉ là một trong nhiều container runtime được hỗ trợ, ngoài ra còn có containerd, CRI-O hay Podman. Miễn là runtime tuân thủ Container Runtime Interface (CRI), Kubernetes vẫn hoạt động ổn định và hiệu quả mà không phụ thuộc vào Docker.
Đọc chi tiết: Docker Container là gì? Cách sử dụng Docker Container hiệu quả
Control Plane trong Kubernetes architecture gồm những gì?
Trong Kubernetes architecture, Control Plane là trung tâm điều phối toàn bộ hoạt động của cluster. Nó bao gồm các thành phần chính như API Server, etcd, Controller Manager, Scheduler và trong môi trường cloud còn có Cloud Controller Manager. Các thành phần này phối hợp để quản lý trạng thái, triển khai workload và đảm bảo hệ thống Kubernetes vận hành ổn định.
Pod là gì trong Kubernetes? Pod khác Container như thế nào?
Trong Kubernetes architecture, Pod là đơn vị triển khai nhỏ nhất, chứa một hoặc nhiều container cùng chia sẻ tài nguyên mạng và lưu trữ. Khác với container đơn lẻ, Pod cho phép các container bên trong giao tiếp nội bộ dễ dàng và hoạt động như một thực thể thống nhất.
Mỗi Pod có vòng đời riêng (Pod lifecycle) và được xem là đơn vị nguyên tử trong quá trình lập lịch (atomic unit of scheduling), nghĩa là Kubernetes luôn tạo, quản lý và di chuyển Pod như một khối thống nhất. Nhờ cấu trúc này, Kubernetes có thể quản lý, mở rộng và phục hồi ứng dụng hiệu quả hơn.
Sự khác nhau giữa Node và Pod là gì?
Trong Kubernetes architecture, Node là máy chủ vật lý hoặc ảo nơi các ứng dụng được chạy, còn Pod là đơn vị triển khai nhỏ nhất chứa một hoặc nhiều container. Mỗi Node có thể chạy nhiều Pod cùng lúc, được quản lý bởi Control Plane.
Nói cách khác, Node có các thành phần hệ thống như kubelet, kube-proxy, container runtime. Pod là workload chạy bên trong Node, còn Node là môi trường hạ tầng để Pod hoạt động.
Tôi cần học gì trước khi tìm hiểu Kubernetes Architecture?
Trước khi tìm hiểu Kubernetes architecture, bạn nên nắm vững:
- Các khái niệm cơ bản về container, đặc biệt là Docker. Hiểu cách hoạt động của ứng dụng trong môi trường container sẽ giúp bạn dễ tiếp cận hơn với cơ chế orchestration của Kubernetes.
- Kiến thức về Linux và command line
- Kiến thức về mạng máy tính (networking): TCP/IP, DNS, load balancing,…
- Hiểu về YAML format, RESTful APIs
- Khái niệm hệ thống phân tán (distributed systems): Hiểu các nguyên tắc như scalability (khả năng mở rộng), fault tolerance (chịu lỗi), và consistency (tính nhất quán) để nắm được lý do tại sao Kubernetes architecture được thiết kế theo mô hình hiện tại.
Khi có nền tảng này, việc học và áp dụng Kubernetes architecture sẽ trở nên trực quan và hiệu quả hơn.
Tổng kết
Nhờ khả năng tự phục hồi, mở rộng linh hoạt và tích hợp dễ dàng với nhiều môi trường đám mây, Kubernetes đã trở thành tiêu chuẩn vàng trong triển khai ứng dụng hiện đại. Việc hiểu rõ Kubernetes architecture không chỉ giúp bạn làm chủ hạ tầng công nghệ mà còn mở ra cơ hội phát triển chuyên sâu trong lĩnh vực DevOps và điện toán đám mây.
