Tiếp nối series Tìm hiểu về Kubernetes bài hôm nay sẽ khái quát về kiến trúc của một cụm Kubernetes, một cái nhìn tổng quan, từ xa. Ở các bài tiếp theo trong series sẽ làm rõ hơn về từng thành phần được nhắc đến trong bài này.
Kiến trúc vật lý của Kubernetes cluster
Một cluster của Kubernetes có hai thành phần chính là: Control plane và Worker.
Control plane
Hay còn gọi là Master, là nơi quản lý trong toàn bộ cụm Kubernetes, gồm có các thành phần:
ETCD:
ETCD là database của Kubernetes, là nơi lưu trữ toàn bộ thông tin (node, pod, account, role, config, biding, secret…) trong cụm Kubernetes.
- Tất cả data được lưu dưới dạng key:value.
- Chứa tất cả các thông tin của worker và control plane để control plane có thể quản lý worker.
- Nhờ các thông tin được lưu giúp đảm giữa các control plane không bị conflict khi cùng quản lý trong một cụm Kubernetes.
- Tất cả các thông tin hiển thị trên CLI đều lấy từ ETCD.
- ETCD chỉ cập nhật data khi có dự thay đổi đã thực hiện thành công trong cụm Kubernetes.
Kube-apiserver:
Kube-apiserver thành phần tập trung, quản lý tất cả các API mà cụm Kubernetes có thể sử dụng, với các API này, kube-apiserver đảm nhiệm việc giao tiếp trong Kubernetes.
- Là front end của control plane.
- Các thành phần trong control plane giao tiếp với nhau thông qua kube-apiserver.
- Là nơi giao tiếp giữa control plane và worker.
Kube-scheduler:
Kube-scheduler là thành phần đảm nhiệm việc lựa chọn node thích hợp để chạy pod.
Container chạy trong pod đều có yêu cầu resource khác nhau và giữa chính các pod ấy cũng có các yêu cầu khác biệt nên cần phải chọn đúng node đáp ứng được việc chạy pod (feasible nodes), và đây là việc mà kube-scheduler đảm nhiệm.
Kube-scheduler chọn node cho pod với 2 bước
- Lọc (filter): kube-scheduler sẽ lướt qua tất cả các node để xem xét resource còn lại của từng node, rồi cho ra một danh sách các node có thể đáp ứng được việc chạy pod.
- Tính điểm: các node được liệt kê trong danh sách sẽ bắt đầu được gán điểm, node nào có số điểm cao nhất sẽ được chọn để chạy pod.
Kube-controller-manager:
Kube-controller-manager quản lý các quá trình điều khiển (controller process) như là node controller (thông báo và phản hồi các thông tin về node), endpoints controller (lựa chọn endpoint cho pod),…
Kube-controller-manager sẽ so sánh trạng thái hiện tại (current state) của Kubernetes với trạng thái mong muốn (desired state) mà người dùng khai báo trong file yaml (tính năng “vòng lặp đối chiếu” – Reconciliation loop, có thể tham khảo ở bài viết Giới thiệu về Kubernetes).
Cloud-controller-manager: 
Cloud-controller-manager sẽ được dùng khi các kubernetes cluster của các cloud provider. Tùy thuộc vào cloud provider mà tính năng của CCM (Cloud-controller-manager) sẽ có sự thay đổi.
Phần lớn tính năng của CCM đều giống với Kube-controller-manager, bao gồm:
- Node controller: khởi tạo một Node mới bằng cách thu thập thông tin (loại, kích cỡ, nhãn, địa chỉ mạng…) về những Node đang chạy trong cluster từ các cloud provider.
- Route controller: cấu hình định tuyến trong hệ thống cloud để các container trên các node khác nhau có thể giao tiếp với nhau.
- Service controller: tạo, cập nhật, xóa các service trên cloud, ngoài ra, tính năng load balancer cũng được thêm vào.
Worker
(hay còn gọi là Node) là nơi diễn ra các hoạt động liên quan đến tạo container trong cụm Kubernetes:
Kubelet: 
Kubelet sẽ là nơi đại diện, là “node agent” của từng node (worker) trong Kubernetes, thực hiện việc giám sát tạo, xóa, kiểm tra trạng thái để đảm bảo pod chạy đúng theo điều khiển của control plane.
- Nhận diện các thông tin ở trường PodSpec trong file yaml và tạo pod theo thông tin nhận được.
- Tải các secret từ kube-apiserver để tạo pod theo thông tin yêu cầu.
- Mount volume vào trong pod.
- Khởi tạo các container (thông qua container runtime).
- Báo cáo trạng thái của node và từng pod trong node với master.
Kube-proxy:
Kube-proxy cung cấp policy network cho các node trong cluster, là thành phần hỗ trợ cho Service (sẽ được nhắc đến ở bài sau).
Container runtime:
Là phần mềm được dùng để chạy các container, ban đầu chỉ định mặc định là Docker nhưng sau đã trở nên linh hoạt với nhiều phần mềm khác như ContainerD, CRI-O, Rocket…
💡 Nếu áp kiến trúc Kubernetes xuống phòng kỹ thuật của CADS thì chúng ta sẽ có mô hình như thế này
Control plane sẽ đóng vai trò trưởng phòng, để hoàn thành các công việc của một trưởng phòng, control plane sẽ sử dụng các thành phần trong kiến trúc theo cách như sau:
- Quản lý tài liệu, document, các quy trình để các project được thực hiện. Trong phòng kỹ thuật trong CADS sử dụng onedrive để lưu trữ. Còn trong K8s, ETCD là nơi đảm nhiệm lưu trữ data dưới dạng key:values.
- Là một văn phòng kỹ thuật với nhiều thành viên, văn phòng cần phải có mạng nội bộ với rất nhiều giao thức mạng để các nhân viên có thể làm việc chung với nhau. Trong môi trường thực tế, việc quản lý mạng local với các giao thức mạng là team system, còn trong cụm Kubernetes là kube-apiserver quản lý api, môi trường để các thành phần khác giao tiếp với nhau.
- Khi các project được giám đốc trung tâm yêu cầu thực hiện, trưởng phòng sẽ xem xét giữa các leader và lựa chọn ra một leader có các nhóm project phù hợp điều kiện để thực hiện yêu cầu giám đốc đề ra. Trong Kubernetes, kube-scheduler thực hiện lựa chọn các worker với resource phù hợp với yêu cầu của người dùng.
- Trường phòng có nhiều công việc cần phải quản lý trong trung tâm là: leader có đang thực hiện được công việc của mình hay không, các task riêng lẻ có được thực hiện hay chưa, thành viên nào có quyền tham gia vào project… Thành phần đảm nhiệm việc quản lý này là kube-control-manager với các tiến trình quản lý nhỏ. Tương ứng với các công việc vừa được liệt kê, chúng ta có: Node controler, Job controler và Service Account & Token controllers.
- Nếu như trung tâm có kết hợp với trung tâm ở ngoài, thì trưởng phòng sẽ có thêm việc quản lý đối với bên ngoài, cũng như K8s khi có sự tham gia của cloud. Lúc này thành phần Cloud-controller-manager sẽ đảm nhiệm việc quản lý cloud.
Các leader, những người trực tiếp tham gia vào project, sẽ là các worker trong cụm Kubernetes:
- Leader cần phải kiểm tra khả năng của từng thành viên, phân bố các nhiệm vụ trong project và theo dõi tiến độ của từng thành viên để đảm bảo project đáp ứng được nhu cầu được đưa xuống. Điều này cũng tương tự như cách mà Kubelet hoạt động.
- Do thuộc mạng nội bộ nên thường để truy cập vào các api/web được tạo ra cần phải add proxy để truy cập vào, điều này nhằm đảm bảo tính tính bảo mật, an toàn mạng. Trong cụm Kubernetes cũng vậy, để có thể giao tiếp đến pod thì cần phải đáp ứng được policy cảu kube-proxy.
- Container runtime cũng tương tự như các thành viên trong project, mỗi thành viên sẽ đảm nhiệm một nhiệm vụ khác nhau. Container runtime cũng sẽ tạo ra các container khác nhau.
