Nguyên lý Kiến trúc và Thiết kế Đối tượng trong Kubernetes

Nền tảng của Điện toán đám mây và Hệ thống Borg

Trong môi trường truyền thống, việc quản lý hạ tầng thường gặp khó khăn khi mở rộng quy mô. Giả sử một doanh nghiệp sở hữu 10 máy chủ vật lý cho 2 ứng dụng khác nhau, việc phân bổ thủ nhiên mỗi ứng dụng 5 máy có thể hoạt động ổn ở quy mô nhỏ. Tuy nhiên, khi xảy ra sự cố phần cứng, quy trình thay thế节点 và cấu hình lại hoàn toàn dựa vào thao tác thủ công của con người. Khi kiến trúc chuyển dịch sang mô hình vi dịch vụ với hàng nghìn instance, phương pháp quản lý này trở nên bất khả thi do rủi ro sai sót cao.

Điện toán đám mây ra đời để giải quyết vấn đề này thông qua việc trừu tượng hóa tài nguyên mạng và lưu trữ. Thay vì quan tâm đến từng máy vật lý, một lớp điều khiển (Control Plane) sẽ gom nhóm hàng nghìn máy chủ thành một cụm (cluster), ảo hóa tổng tài nguyên CPU và RAM thành một bể chứa lớn. Người dùng chỉ cần khai báo nhu cầu tài nguyên, hệ thống sẽ tự động chọn节点 phù hợp để triển khai ứng dụng.

Có hai hướng tiếp cận chính trong nền tảng đám mây:

Nền tảng ảo hóa: Điển hình là OpenStack, sử dụng máy ảo (VM) để cách ly ứng dụng trên cùng một phần cứng.
Nền tảng điều phối tiến trình: Điển hình là Google Borg, sử dụng container để tối ưu hóa mật độ triển khai.

Google Borg là tiền thân trực tiếp của Kubernetes. Hệ thống này quản lý hàng trăm nghìn máy chủ, hỗ trợ cả ứng dụng trực tuyến (Production) yêu cầu độ sẵn sàng cao và các tác vụ offline (Non-Production) để tận dụng tài nguyên nhàn rỗi. Borg đạt được hiệu suất cao nhờ cơ chế trộn tải (mixing workloads), cho phép các tác vụ offline chiếm dụng tài nguyên khi các dịch vụ online đang ở mức thấp và nhường lại ngay khi cần thiết.

Kiến trúc Tổng quan của Kubernetes

Kubernetes (K8s) kế thừa nhiều nguyên lý thiết kế từ Borg nhưng được mở rộng để trở thành tiêu chuẩn mở. Hệ thống này hoạt động theo mô hình khai báo (Declarative), nghĩa là người dùng định nghĩa trạng thái mong muốn (Spec), và hệ thống tự động làm việc để đưa trạng thái thực tế (Status) về khớp với mong muốn đó.

Kiến trúc K8s bao gồm hai phần chính:

Mặt phẳng điều khiển (Control Plane)

API Server: Là cổng giao tiếp duy nhất, xử lý xác thực, phân quyền và ghi dữ liệu vào kho lưu trữ.
etcd: Cơ sở dữ liệu phân tán nhất quán cao, lưu trữ toàn bộ trạng thái của cụm.
Scheduler: Theo dõi các Pod mới chưa được gán节点 và quyết định đặt chúng lên_node nào dựa trên tài nguyên và ràng buộc.
Controller Manager: Chạy các bộ điều khiển để đảm bảo trạng thái cụm luôn ổn định (ví dụ: nếu một Pod chết, nó sẽ tạo Pod mới).

Các节点 làm việc (Worker Nodes)

Kubelet: Agent chạy trên mỗi节点, đảm bảo các container trong Pod đang hoạt động đúng như khai báo.
Kube-Proxy: Duy trì các quy tắc mạng để hỗ trợ truyền thông nội bộ và bên ngoài vào các dịch vụ.

Các đối tượng cốt lõi trong K8s bao gồm Node (máy vật lý/ảo), Namespace (không gian tên để cô lập tài nguyên), Pod (đơn vị triển khai nhỏ nhất chứa container) và Service (cơ chế trừu tượng hóa truy cập mạng).

Cơ chế Hoạt động của Các Thành phần

1. etcd và Cơ chế Đồng thuận

etcd sử dụng giao thức Raft để đảm bảo tính nhất quán dữ liệu trong môi trường phân tán. Khác với cơ sở dữ liệu truyền thống chỉ trả về kết quả khi truy vấn, etcd hỗ trợ cơ chế Watch. Điều này cho phép các thành phần khác trong K8s đăng ký lắng nghe sự thay đổi của dữ liệu thay vì phải liên tục hỏi (polling), giúp giảm tải đáng kể cho hệ thống.

Dưới đây là ví dụ về cách truy vấn và theo dõi thay đổi trong etcd từ một节点 điều khiển:

# Thiết lập biến môi trường cho API version
export ETCDCTL_API=3

# Kết nối an toàn và liệt kê các key liên quan đến Pod
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  get --prefix /registry/pods/

# Thiết lập chế độ theo dõi thay đổi thời gian thực cho một namespace cụ thể
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  watch --prefix /registry/pods/default/

Khi có sự thay đổi, etcd sẽ thông báo ngay lập tức cho API Server, sau đó API Server chuyển tiếp sự kiện này đến các Controller thông qua cơ chế cache nội bộ.

2. API Server và Mô hình Aggregation

API Server không chỉ là cổng vào mà còn là trung tâm xác thực (Authentication), phân quyền (Authorization) và kiểm soát truy cập (Admission Control). Một tính năng quan trọng là Aggregated API Server, cho phép mở rộng chức năng của K8s bằng cách gắn thêm các API server phụ trợ.

Ví dụ, để hỗ trợ tính năng tự động co giãn (HPA) dựa trên metric, một Metrics Server có thể được đăng ký vào API Server chính. Khi đó, lệnh kubectl top có thể truy xuất dữ liệu sử dụng tài nguyên:

# Kiểm tra mức sử dụng tài nguyên của các节点
kubectl top nodes

# Kiểm tra mức sử dụng tài nguyên của Pod trong namespace mặc định
kubectl top pods --namespace=default

3. Controller Manager và Mô hình Informer

Các bộ điều khiển hoạt động dựa trên mô hình Producer-Consumer. Quy trình xử lý điển hình bao gồm:

Lister/Informer: Lấy toàn bộ dữ liệu từ API Server và lưu vào bộ nhớ đệm cục bộ (Local Cache).
Watch: Lắng nghe sự thay đổi và đưa các sự kiện vào hàng đợi (WorkQueue).
Worker: Các goroutine lấy key từ hàng đợi và thực hiện logic điều phối (Reconciliation) để đưa trạng thái thực tế về đúng mong muốn.

Quá trình này đảm bảo tính nhất quán cuối cùng (Eventual Consistency). Nếu một lần xử lý thất bại, sự kiện sẽ được đưa lại vào hàng đợi để thử sau một khoảng thời gian.

Ví dụ về luồng tạo một Deployment:

Người dùng gửi yêu cầu tạo Deployment đến API Server.
Deployment Controller phát hiện thay đổi, tạo ra đối tượng ReplicaSet tương ứng.
ReplicaSet Controller phát hiện ReplicaSet mới, tạo ra các đối tượng Pod.
Scheduler phát hiện Pod chưa có节点, tính toán và gán Pod vào một_node cụ thể.
Kubelet trên_node đó phát hiện Pod được gán, tiến hành khởi tạo container thông qua CRI (Container Runtime Interface).

4. Kubelet và Quản lý Vòng đời Pod

Kubelet là thành phần quan trọng nhất trên mỗi_node làm việc. Nó chịu trách nhiệm báo cáo trạng thái_node và Pod về API Server. Ngoài ra, Kubelet còn tích hợp nhiều trình quản lý phụ trợ:

PodWorker: Quản lý trạng thái khởi động/dừng của Pod.
ProbeManager: Thực hiện kiểm tra sức khỏe (Health Check) cho ứng dụng.
ImageGC & ContainerGC: Dọn dẹp các ảnh và container không còn sử dụng để giải phóng dung lượng.

Kubelet tương tác với hạ tầng thông qua các chuẩn mở: CRI cho container, CNI cho mạng và CSI cho lưu trữ, giúp K8s không bị phụ thuộc vào một nhà cung cấp cụ thể.

5. Tối ưu hóa Tài nguyên và Giới hạn

Để đảm bảo ổn định, K8s mặc định giới hạn số lượng Pod trên mỗi_node (thường là 110). Giới hạn này có thể điều chỉnh qua tham số --max-pods của Kubelet nếu hạ tầng mạng và cấu hình_node cho phép.

# Xem xét khả năng và giới hạn hiện tại của một_node
kubectl describe node worker-node-01 | grep -A 5 "Capacity"

Việc đặt giới hạn giúp giảm áp lực cho quá trình kiểm tra trạng thái (heartbeat) và quản lý mạng. Ngoài ra, cơ chế QoS (Quality of Service) của K8s dựa trên việc khai báo requests và limits giúp hệ thống quyết định ưu tiên tài nguyên hoặc loại bỏ Pod khi_node bị quá tải bộ nhớ (OOM).

Thẻ: kubernetes-architecture google-borg etcd-cluster apiserver Container-Orchestration

Đăng vào ngày 25 tháng 7 lúc 21:06

Thành phố Cuồng loạn