Kubernetes có kiến trúc thế nào?

Nếu bạn cần kiến thức cơ bản về Kubernetes - Công cụ quản trị container phổ biến nhất thế giới hiện nay thì bài viết này là dành cho bạn iu đó :D. Bài viết này tóm tắt cơ bản toàn bộ các thành phần và cách hoạt động của từng thành phần trong một cụm Kubernetes. Do sự đồ sộ và phức tạp của Kubernetes nên bài viết cũng không phải là ngắn tuy nhiên bài viết sẽ đảm bảo cover toàn bộ thành phần cần phải biết của bất kỳ cụm Kubernetes nào trên đời này nên là các bạn hãy chịu khó đọc hoặc chia ra để đọc trọn vẹn nhé. Thank you! Now let's begin...

Thứ đầu tiên và quan trọng nhất mà bạn cần nắm về Kubernetes đó là: Kubernetes là một hệ thống phân tán (distributed system). Tức là nó chứa nhiều thành phần trải rộng trong khắp các server khác nhau trên một mạng. Các server này có thể là các máy ảo (VM) hay các server vật lý. Ta gọi nó là một cụm Kubernetes.

Một cụm Kubernetes bao gồm nhiều node điều khiển (control plane) và nhiều node làm việc (worker). Giờ hãy tìm hiểu một chút về 2 loại node này.

Control Plane

Control plane chịu trách nhiệm cho việc tổ chức các container và duy trì trạng thái mong muốn của cụm. Nó bao gồm các thành phần sau:

1. kube-apiserver

2. etcd

3. kube-scheduler

4. kube-controller-manager

5. cloud-controller-manager

Worker Node

Worker node chịu trách nhiệm chạy các ứng dụng container hóa (containerized). Nó bao gồm các thành phần sau:

1. kubelet

2. kube-proxy

3. Container runtime

Các thành phần của Kubernetes Control Plane

Đầu tiên hãy xem qua các thành phần của control plane và các kiến thức quan trọng để nắm được cách hoạt động của chúng nhé.

1. kube-apiserver

kube-api server là một trung tâm tập trung của cụm Kubernetes, nó công khai các Kubernetes API.

Người dùng cuối (end users) và các thành phần khác của cụm giao tiếp với cụm thông qua API server. Rất ít khi các hệ thống quản lý và các dịch vụ bên thứ ba cần giao tiếp với API server để tương tác với cụm.

Vì vậy khi sử dụng kubectl để quản lý cụm, tại backend bạn đang thực ra là giao tiếp với API server thông qua HTTP REST APIs. Tuy nhiên, các thành phần nội bộ của cụm như là scheduler, controller, etcd giao tiếp với API server lại sử dụng gRPC.

API là gì?

Việc giao tiếp giữa API server và các thành phần khác của cụm được xử lý thông qua giao thức TLS để ngăn chặn các truy cập không được xác thực tới cụm.

Kubernetes api-server chịu trách nhiệm:

1. Quản lý API: Công khai API endpoint của cụm và xử lý tất cả các API requests.

2. Authentication (Sử dụng client certificates, bearer tokens, và HTTP Basic Authentication) và Authorization (ABAC và RBAC evaluation)

3. Xử lý các API request và xác thực dữ liệu cho API objects như pods, services, ... (Validation và Mutation Admission controllers)

4. Thành phần duy nhất giao tiếp với etcd.

5. api-server điều khiển mọi quá trình (process) giữa control plane và worker node.

6. api-server có một thành phần proxy sẵn có gọi là bastion api-server proxy. Mục đích chính của nó là cho phép truy cập tới các service ClusterIP từ ngoài cụm, kể cả các service đó chỉ có thể được truy cập từ bên trong cụm mà thôi.

2. etcd

Kubernetes là một hệ thống phân tán và nó cần có một database như etcd để hỗ trợ việc phân tán của nó. etcd đóng vai trò vừa là một backend service discovery và vừa là một database. Có thể coi nó như là bộ não của cụm Kubernetes.

etcd là một hệ thống khóa-giá trị (key-value) phân tán có tính nhất quán cao. Nghĩa là sao?

1. Nhất quán cao: Nếu một node được cập nhật, tính nhất quán cao đảm bảo nó sẽ được cập nhật tới tất cả các node khác trong cụm một cách tức thì. Thêm vào đó, nếu bạn nhìn vào mô hình CAP (CAP theorem), việc đảm bảo tính sẵn sàng 100% với tính nhất quán cao và tính chịu chia rẽ là bất khả thi.

CAP theorem là gì?

1. Phân tán: etcd được thiết kế để chạy trên nhiều node như một cụm mà không phải đánh đổi tính nhất quán.

2. Key-Value: Một nonrelational database chúa dữ liệu như các khóa và các giá trị. Nó cũng công khai một API khóa-giá trị. Một datastore xây dựng dựa trên BboltDB - một nhánh của BoltDB.

etcd sử dụng thuật toán raft consensus để đảm bảo tính nhất quán cáo và tính sẵn sàng. Nó hoạt động theo kiểu leader-member cho tính sẵn sàng cao và sẵn sàng cho việc node bị fail.

Vậy etcd hoạt động với Kubernetes như thế nào?

Để đơn giản hóa vấn đề, khi bạn dùng kubectl để lấy thông tin về các Kubernetes objects, bạn đang lấy chúng từ etcd. Thêm nữa, khi bạn deploy một object như pod chẳng hạn, etcd sẽ tạo một entry trong nó.

Cơ bản thì những thứ bạn cần hiểu về etcd là:

1. etcd lưu trữ mọi cấu hình, trạng thái, và metadata của Kubernetes objects (pods, secrets, daemonsets, deployments, configmaps, statefulsets, ...)

2. etcd cho phép người dùng đăng ký tới các events dùng watch() API. Kubernetes api-server dùng watch() của etcd để theo dõi thay đổi trạng thái của một object.

3. etcd công khai API khóa-giá trị dùng gRPC. gRPC gateway là một RESTful proxy sẽ chịu trách nhiệm chuyển các HTTP API call sang thông điệp gRPC. Đây là một điều lý tưởng để kết hợp etcd với Kubernetes do api-server dùng gRPC để giao tiếp với các thành phần khác trong cụm.

4. etcd lưu trữ các object dưới thư mục /registry ở dạng khóa-giá trị. Ví dụ thông tin của một pod tên là Nginx trong namespace default có thể được tìm thấy tại đường dẫn /registry/pods/default/nginx.

3. kube-scheduler

kube-scheduler chịu trách nhiệm cho việc lập lịch (schedule) các Kubernetes pods trên các node worker.

Khi bạn deploy một pod, bạn đưa ra các yêu cầu cho pod như là CPU, memory, affinity, taints or tolerations, priority, persistent volumes (PV), ...Từ đó công việc của scheduler là nhận biết request đó của bạn và chọn node lý tưởng nhất đáp ứng các nhu cầu của bạn để tạo pod đó.

Trong một cụm Kubernetes sẽ thường có nhiều hơn 1 node worker. Vậy thì làm sao scheduler có thể chọn node phù hợp trong các node worker đó?

1. Để chọn node tốt nhất, scheduler dùng filtering and scoring.

2. Filtering: scheduler tìm node phù hợp nhất mà pod có thể được lập lịch lên. Ví dụ nếu có 5 node worker với đầy đủ tài nguyên để chạy pod, nó sẽ chọn cả 5 thằng này. Nếu không có node nào thì pod sẽ không thể được lập lịch và được đưa vào hàng chờ scheduling. Nếu cụm này to hơn, giả dụ như có 100 node worker thì scheduler sẽ không duyệt trên tất cả các node, có một parameter trong scheduler gọi là percentageOfNodesToScore mặc định là 50% tức là nó sẽ thử duyệt trong 50% tất cả các node (50/100 node) dùng round-robin, nếu các node này trải rộng khắp các vùng (zone) khác nhau thì scheduler sẽ duyệt trên các node trong các vùng khác nhau. Trong các cụm cực kì lớn thì giá trị của parameter này thường là 5%.

3. Scoring: scheduler đánh giá các node bằng cách cho điểm các node đã được filter. scheduler cho điểm bằng cách gọi các scheduling plugins. Cuối dùng node worker với điểm cao nhất sẽ được chọn để lập lịch. Nếu có nhiều node cùng điểm, node được chọn sẽ là random trong các node đó.

4. Khi node đã được chọn, scheduler sẽ tạo binding event tới api-server để cho biết rằng nó đã chọn node này cho object này.

Tóm gọn lại thì đây là những gì bạn cần biết về scheduler:

1. Nó là một controller listen tới pod creation events trong api-server.

2. Scheduler có 2 giai đoạn. Scheduling cycle và Binding cycle. Scheduling cycle chọn 1 node worker và Binding cycle apply thay đổi tới cụm.

3. Scheduler luôn đặt các pod có thứ tự ưu tiên cao hơn trước các pod có thứ tự ưu tiên thấp hơn. Hơn nữa, trong vài trường hợp, sau khi pod chạy trên node đã được chọn, pod có thể bị xóa hoặc chuyển tới các node khác. Để hiểu thêm mời bạn đọc tham khảo Kubernetes pod priority guide dưới nha.

   Pod priority guide

4. Bạn có thể tùy chỉnh scheduler và chạy nhiều scheduler trong một cụm cùng với scheduler sẵn có. Khi deploy pod bạn có thể chọn scheduler muốn dùng trong pod manifest.

5. Scheduler có một pluggable scheduling framework - tức là bạn có thể thêm plugin tùy chỉnh của bạn vào quy trình lập lịch.

4. Kube Controller Manager

Controller là các chương trình (programs) chạy các vòng lặp điều khiển vô hạn. Tức là nó chạy liên tục và theo dõi trạng thái thực và trạng thái mong muốn của object. Nếu có sự khác biệt giữa trạng thái thực và mong muốn, nó đảm bảo các tài nguyên của cụm được đạt tới trạng thái mong muốn.

Như trong official document của Kubernetes:

Trong Kubernetes, các controller là các vòng lặp điều khiển theo dõi cụm của bạn, sau đó tạo hoặc request các thay đổi cần thiết. Mỗi controller sẽ cố gắng đưa trạng thái cụm hiện tại tới gần nhất với trạng thái mong muốn.

Ví dụ bạn muốn tạo một deployment, bạn phải đưa ra trạng thái mong muốn trong manifest YAML của pod. Ví dụ 2 replicas, 1 volume mount, configmap, ...Deployment controller sẽ đảm bảo deployment duy trì ở trạng thái mong muốn đó mọi lúc. Nếu một người dùng cập nhật deployment với 5 replicas thì controller sẽ nhận ra điều đó và đảm bảo trạng thái mong muốn là 5 replicas.

Kube-controller manager là thành phần quản lý tất cả các Kubernetes controller. Kubernetes pods, namespaces, jobs, replicaset được quản lý bởi các controller tương ứng. Hơn nữa, kube-scheduler cũng là một controller được quản lý bởi kube-controller manager.

Các controller quan trọng trong Kubernetes:

1. Deployment controller

2. Replicaset controller

3. DaemonSet controller

4. Job Controller (Kubernetes Jobs)

5. CronJob Controller

6. endpoints controller

7. namespace controller

8. service accounts controller.

9. Node controller

Những gì bạn cần biết về controller:

1. Nó quản lý tất cả các controller và các controller sẽ cố gắng giữ cụm luôn ở trạng thái mong muốn.

2. Bạn có thể mở rộng Kubernetes với các controller tùy chỉnh thông qua một định nghĩa tài nguyên tùy chỉnh (custom resource definition).

5. Cloud Controller Manager (CCM)

Khi Kubernetes được deploy lên môi trường cloud, cloud controller manager đóng vai trò như cầu nối giữa các API của nền tảng cloud và cụm Kubernetes

Cách tiếp cận này giúp các thành phần chính của Kubernetes có thể làm việc độc lập và cho phép các nhà cung cấp cloud kết hợp với Kubernetes qua các plugins.

Cloud controller integration cho phép cụm Kubernetes quản lý các tài nguyên cloud như instances (nodes), load balancers (services), storage volumes (persistent volumes).

CCM gồm nhiều các controller đảm bảo trạng thái mong muốn của các thành phần của cloud như nodes, load balancers, storages, ... Ba controller quan trọng nhất:

1. Node controller: Controller này cập nhật thông tin liên quan đến node thông qua việc giao tiếp với API của cloud. Ví dụ tên node, hostname, CPU, memory, health status, ...

2. Route controller: Chịu trách nhiệm cấu hình các route của mạng trên cloud.

3. Service controller: Chịu trách nhiệm deploy các load balancer cho các Kubernetes service, chỉ định địa chỉ IP, ...

   💡

   CCM không phải thành phần bắt buộc phải biết với tất cả các developers hay devops engineers nếu các hệ thống bạn làm việc không sử dụng cloud. Tuy nhiên với xu hướng Cloud hóa như hiện nay, việc sử dụng Cloud chỉ là chuyện thời gian vậy nên hãy quay lại để tìm hiểu về nó nhé :D

Các thành phần của Kubernetes Worker Node

Giờ hãy tìm hiểu các thành phần của worker node nhé.

1. Kubelet

Kubelet là một thành phần agent chạy trên mọi node của cụm. Nó không chạy như là một container mà chạy như một daemon được quản lý bởi systemd.

Nó chịu trách nhiệm đăng ký các node worker với api-server và làm việc với podSpec (YAML hay JSON) từ api-server. podSpec định nghĩa các container chạy trong pod, tài nguyên của chúng (CPU, memory limits, .. ) và các cài đặt khác như là các biến môi trường, volumes, labels.

Nó đưa podSpec tới trạng thái mong muốn bằng cách tạo các containers.

Để dễ hiểu thì Kubelet chịu trách nhiệm sau:

1. Tạo, chỉnh sửa, xóa các containers trong pod.

2. Quản lý liveliness, readiness và startup probes.

3. Mount các volume bằng cách đọc cấu hình pod và tạo các thư mục tương ứng trên host cho volume mount.

4. Thu thập và báo cáo trạng thái của node và pod thông qua API call tới api-server với các triển khai như cAdvisor và CRI.

Kubelet is also a controller that watches for pod changes and utilizes the node’s container runtime to pull images, run containers, etc.

Kubelet cũng là một controller theo dõi thay đổi của pod và tận dụng container runtime của node (Docker, containerd, podman, ...) để pull images, chạy containers, ...

Ngoài các podSpec từ api-server, kubelet có thể chấp nhận các podSpec từ một file, HTTP endpoint và HTTP server. Một ví dụ về podSpec từ file là Kubernetes static pods.

Static pods được điều khiển bởi kubelet chứ không phải api-server.

Điều này chứng tỏ bạn có thể tạo các pod bằng cách cung cấp pod YAML tới kubelet, tuy nhiên static pod được tạo bởi kubelet sẽ không được quản lý bởi api-server.

Một ví dụ thực tế sử dụng static pod:

Khi khởi động (bootstrap) control plane, kubelet khởi động api-server, scheduler, controller manager như là các static pod từ các podSpec tại thư mục /etc/kubernetes/manifests do khi này các dịch vụ controller khác chưa hoạt động.

Các kiến thức chính:

1. Kubelet sử dụng CRI (Container Runtime Interface) gRPC API để giao tiếp với container runtime.

2. Nó cũng công khai một HTTP endpoint để chuyển các logs và cung cấp exec vào container tại pod của nó cho người dùng.

3. Sử dụng CSI (Container Storage Interface) gRPC API để cấu hình các block volume.

4. Sử dụng CNI (Container Network Interface) đã được cấu hình trong cụm để chỉ định địa chỉ IP của pod và set up các route cần thiết trong mạng cũng như các firewall rule cho pod.

2. Kube proxy

To understand Kube proxy, you need to have a basic knowledge of Kubernetes Service & endpoint objects.

Để hiểu kube-proxy, bạn cần phải có một chút kiến thức cơ bản về Kubernetes Service và các endpoint object.

Service trong Kubernetes là một cách để công khai một set các pod tới nội bộ cụm để các pod trong cùng cụm có thể kết nối tới set các pod đó hoặc công khai tới bên ngoài cụm luôn. Khi bạn tạo một service object, nó sẽ được gán một địa chỉ IP ảo. Nó được gọi lại ClusterIP. IP này cho phép các pod trong cùng cụm truy cập tới các pod có IP này.

Endpoint object chứa tất cả các địa chỉ IP và các port của các nhóm pod được gán trong một service object. Endpoint controller chịu trách nhiệm duy trì danh sách các pod IP. Service controller chịu trách nhiệm cấu hình các endpoint tới một service.

Chúng ta không thể ping ClusterIP vì nó chỉ có thể sử dụng cho service discovery, không như pod IP có thể ping được từ pod khác trong cùng cụm.

Giờ hãy quay lại với kube-proxy.

Kube-proxy là một quy trình chạy ngầm (daemon) chạy trên tất cả các node và được deploy như là một DaemonSet (DaemonSet yêu cầu mọi node trong cụm đều phải chạy nó - ở đây là chạy kube-proxy). Nó proxy UDP, TCP, SCTP và không proxy HTTP.

When you expose pods using a Service (ClusterIP), Kube-proxy creates network rules to send traffic to the backend pods (endpoints) grouped under the Service object. Meaning, all the load balancing, and service discovery are handled by the Kube proxy.

Khi bạn công khai các pod bằng Service (ClusterIP), kube-proxy tạo các network rules để chuyển traffic từ các pod khác trong cụm tới các pod IP trong ClusterIP đó.

Vậy kube-proxy hoạt động như nào?

Kube-proxy giao tiếp với api-server để lấy thông tin chi tiết về ClusterIP và các pod IP và port tương ứng. Nó cũng quản lý thay đổi trong service và các endpoint.

Kube-proxy sử dụng một trong các chế độ sau để tạo cũng như cập nhật các rules cho việc route traffic tới các pod trong Service:

1. IPTables: Đây là chế độ mặc định. Trong chế độ này, traffic được xử lý bởi các IPTables rules. Tức là với mỗi service, IPTables đều được tạo. Các rules nhận traffic route tới ClusterIP và chuyển chúng tới các pod trong service. Thêm vào đó, trong chế độ này, kube-proxy chọn pod một cách ngẫu nhiên cho load balancing. Một khi kết nối đã được khởi tạo, các request sẽ chuyển tới pod đó cho tới khi kết nối bị ngắt.

2. IPVS: Trong các cụm với số lượng service xấp xỉ 1000, IPVS đem lại hiệu quả về mặt hiệu năng. Nó hỗ trợ các thuật toán load balancing sau cho backend:

   1. rr: round-robin : Chế độ mặc định

   2. lc: least connection (số lượng kết nối mở (open connections) là ít nhất)

   3. dh: destination hashing

   4. sh: source hashing

   5. sed: shortest expected delay

   6. nq: never queue

3. Userspace (chế độ kế thừa (legacy) và không khuyến khích sử dụng)

4. Kernelspace: chỉ dùng cho các node chạy Windows

3. Container Runtime

You probably know about Java Runtime (JRE). It is the software required to run Java programs on a host. In the same way, container runtime is a software component that is required to run containers.

Bạn có thể đã biết về JRE (Java Runtime): phần mềm cần thiết để chạy các chương trình Java trên host. Tương tự thì container runtime là một thành phần phần mềm bắt buộc để có thể chạy container.

Container runtime chạy trên tất cả các node trong cụm Kubernetes. Nó chịu trách nhiệm pull image từ các registry, chạy các container, chỉ định và cô lập các tài nguyên cho các container và quản lý toàn bộ lifecycle của một container trên một host.

Để hiểu hơn ta cùng xem qua 2 kiến thức quan trọng sau:

1. Container Runtime Interface (CRI): Tập hợp các API cho phép Kubernetes tương tác với các container runtime khác nhau. Nó cho phép chuyển đổi sử dụng giữa các container runtime khác nhau một cách dễ dàng. CRI định nghĩa API cho việc tạo, khởi động, dừng, xóa các container cũng như quản lý các image và các mạng của container.

2. Open Container Initiative (OCI): Tập hợp các quy chuẩn cho định dạng container và các runtime.

Vậy Kubernetes sử dụng các container runtime đó như nào nhỉ?

Như chúng ta đã biết trong phần nói về kubelet, kubelet agent chịu trách nhiệm tương tác với các container runtime qua CRI gRPC API để quản lý vòng đời của một container. Nó cũng đọc thông tin của container từ container runtime và cung cấp nó tới cho control plane.

Hãy xem qua một ví dụ về CRI-O:

1. Khi một request về một pod mới được gửi tới từ api-server, kubelet giao tiếp với CRI-O daemon để chạy các container cần thiết thông qua Kubernetes CRI.

2. CRI-O kiểm tra và pull các image cần thiết từ registry đã được cấu hình thông qua thư viện containers/image

3. Sau đó CRI-O tạo OCI runtime specification dưới dạng JSON cho một container.

4. CRI-O chạy một runtime phù hợp với OCI (runc) để khởi chạy container theo runtime specification.

Các thành phần Kubernetes Cluster Addon

Ngoài các thành phần chính, cụm Kubernetes còn cần các addon để có thể hoạt động hết chức năng. Chọn addon phụ thuộc vào yêu cầu của dự án và các trường hợp sử dụng.

Các addon phổ biến:

1. CNI Plugin (Container Network Interface): Calico, Flannel, Cilium, ...

2. CoreDNS: CoreDNS đóng vai trò là một DNS server trong cụm Kubernetes. Khi bật addon này, bạn có thể bật service discovery dựa trên DNS.

3. Metrics Server: Hỗ trợ bạn trong việc thu thập dữ liệu về hiệu năng và tài nguyên của các node và pod trong cụm.

4. Web UI: Cho phép bạn quản lý object thông qua web UI của Kubernetes dashboard.

1. CNI Plugin

Vậy CNI là gì?

Nó là một kiến trúc dựa trên plugin với các thư viện có thể tạo các network interface cho các container.

Nó không chỉ sử dụng cho Kubernetes mà còn sử dụng cho các công cụ quản lý container khác như Mesos, CloudFoundry, Podman, Docker, ...

Khi nói tới container networking, các công ty khác nhau sẽ có các yêu cầu khác nhau về các vấn đề như network isolation, bảo mật, mã hóa, ... Với sự phát triển của công nghệ container, các nhà cung cấp network cũng tạo ra nhiều giải pháp container networking dựa trên CNI.

Nó cho phép người dùng chọn một giải pháp networking phù hợp nhất với nhu cầu của họ.

CNI plugin hoạt động với Kubernetes như thế nào?

1. The Kube-controller-manager is responsible for assigning pod CIDR to each node. Each pod gets a unique IP address from the pod CIDR.

2. Kube-controller manager chịu trách nhiệm chỉ định pod CIDR cho các node. Mỗi node này sẽ có một IP duy nhất từ pod CIDR.

3. Kubelet tương tác với container runtime để khởi chạy pod đã được lập lịch. CRI tương tác với CNI plugin để cấu hình pod network.

4. CNI plugin cho phép networking giữa các pod trải rộng trong cùng hoặc các node khác sử dụng overlay network.

Các chức năng chính của CNI:

1. Pod Networking

2. Pod network security & isolation sử dụng các Network Policy để điều khiển traffic flow giữa các pod và giữa các namespace

Kết luận

Nắm được kiến trúc của Kubernetes giúp bạn có thể phát triển và vận hành Kubernetes hàng ngày một cách hiệu quả.

Khi phát triển một cụm Kubernetes trong môi trường production, việc hiểu rõ các thành phần của Kubernetes sẽ giúp bạn có thể triển khai và khắc phục lỗi của các ứng dụng.

Hãy tham khảo thêm các bài viết chuyên sâu hơn trong blog để từng bước trở thành một nhà quản trị Kubernetes chuyên nghiệp nhé :D