2.1. Core Concepts - Cluster Architecture and Components
Mục lục
- 1. Giới thiệu phần Core Concepts
- 2. Kiến trúc Cluster Kubernetes ở mức tổng quan
- 3. Container Runtime: Docker, containerd và CRI
- 4. ETCD
- 5. Kube-apiserver
- 6. Kube-controller-manager
- 7. Kube-scheduler
- 8. Kubelet
- 9. Kube-proxy
1. Giới thiệu phần Core Concepts
Một Kubernetes cluster trông như thế nào ở bên trong, và những khái niệm nào — Pod, ReplicaSet, Deployment, Service — thực sự làm nên một ứng dụng chạy được trên đó? Đây là điểm khởi đầu của các khái niệm cốt lõi (core concepts) trong Kubernetes: kiến trúc cluster ở mức tổng quan trước, rồi tới các API primitive nền tảng — Pods, ReplicaSets, Deployments, tiếp theo là Services. Nếu đã học qua khóa dành cho người mới bắt đầu (beginners course) hoặc khóa chứng chỉ dành cho application developer, có thể bỏ qua một số chủ đề này, hoặc chỉ cần làm riêng phần practice test.
Bắt đầu với kiến trúc cluster.
2. Kiến trúc Cluster Kubernetes ở mức tổng quan
Một Kubernetes cluster gồm hàng loạt process chạy song song trên nhiều máy khác nhau, nhưng chỉ cần một câu hỏi để bắt đầu hiểu toàn bộ: ai đang làm gì, và chúng nói chuyện với nhau ra sao? Phần này trả lời câu hỏi đó ở mức tổng quan trước, rồi mới đi sâu vào vai trò, trách nhiệm và cách cấu hình của từng thành phần. Cuối cùng là một practice test, nơi xem xét một cluster có sẵn và được yêu cầu xác định các chi tiết khác nhau liên quan tới các thành phần trong cluster.
Phần này dùng một analogy về tàu thuyền (ships) để hiểu kiến trúc của Kubernetes.
Mục đích của Kubernetes là host ứng dụng dưới dạng container theo cách tự động hóa, để có thể dễ dàng deploy bao nhiêu instance của ứng dụng tùy ý, và dễ dàng cho phép giao tiếp giữa các service khác nhau trong ứng dụng. Có rất nhiều thành phần cùng phối hợp để làm được điều này.
💡 Hình dung: có 2 loại tàu trong analogy này — tàu chở hàng (cargo ships) làm công việc thực sự là chở container qua biển, và tàu điều khiển (control ships) chịu trách nhiệm giám sát và quản lý các tàu chở hàng.
Kubernetes cluster gồm một tập hợp các node (có thể là vật lý hoặc ảo, on-premise hoặc trên cloud) host ứng dụng dưới dạng container. Các node này tương ứng với tàu chở hàng trong analogy. Worker node trong cluster là những con tàu chạy container.
Nhưng ai đó cần load container lên tàu. Không chỉ load, mà còn phải lên kế hoạch load thế nào, xác định đúng tàu, lưu thông tin về các tàu, giám sát và theo dõi vị trí của container trên tàu, quản lý toàn bộ quy trình load, v.v. Việc này được thực hiện bởi các tàu điều khiển — nơi có các văn phòng, phòng ban khác nhau, thiết bị giám sát, thiết bị liên lạc, cần cẩu để di chuyển container giữa các tàu, v.v.
Tàu điều khiển tương ứng với master node trong Kubernetes cluster. Master node chịu trách nhiệm quản lý Kubernetes cluster: lưu thông tin về các node khác nhau, lên kế hoạch container nào đi đâu, giám sát các node và container trên chúng, v.v. Master node thực hiện tất cả việc này thông qua một tập hợp component gọi chung là control plane components.
etcd — kho lưu trữ key-value
Hằng ngày có rất nhiều container được load và unload khỏi tàu. Vì vậy cần duy trì thông tin về các tàu khác nhau — container nào ở trên tàu nào, được load lúc nào, v.v. Tất cả thông tin này được lưu trong một key-value store có tính sẵn sàng cao (highly available), gọi là etcd. etcd là một database lưu thông tin dưới dạng key-value.
kube-scheduler
Khi tàu cập bến, container được load lên bằng cần cẩu. Cần cẩu xác định container nào cần được đặt lên tàu nào, dựa trên kích thước tàu, khả năng chứa, số lượng container đã có trên tàu, và các điều kiện khác như điểm đến của tàu, loại container tàu được phép chở, v.v. Đó chính là scheduler trong Kubernetes cluster.
Một scheduler xác định đúng node để đặt một container lên, dựa trên resource requirement của container, khả năng của worker node, hoặc các policy/constraint khác như taints và tolerations (cơ chế đánh dấu node để hạn chế pod nào được phép đặt lên nó) hay node affinity rules (quy tắc ưu tiên đặt pod lên node có thuộc tính nhất định).
Controllers
Có nhiều văn phòng khác nhau trong bến tàu được giao các nhiệm vụ hoặc phòng ban đặc biệt. Ví dụ, đội vận hành (operations team) lo việc điều hướng tàu, kiểm soát giao thông, xử lý các vấn đề liên quan tới hư hỏng, tuyến đường mà các tàu khác nhau đi, v.v. Đội cargo lo việc container — khi container bị hư hỏng hoặc phá hủy, đội đảm bảo có container mới thay thế. Còn có văn phòng Service Accounts lo việc xác thực và giao tiếp giữa các tàu.
Tương tự, trong Kubernetes có các controller phụ trách các mảng khác nhau. Node controller lo việc quản lý node — chịu trách nhiệm onboarding node mới vào cluster, xử lý tình huống node không còn khả dụng hoặc bị hủy. Replication controller đảm bảo số lượng container mong muốn luôn đang chạy tại mọi thời điểm trong một replication group.
kube-apiserver
Đã thấy các thành phần khác nhau — các văn phòng, các tàu, kho dữ liệu, cần cẩu. Nhưng chúng giao tiếp với nhau ra sao? Node này reach tới node khác thế nào, và ai quản lý tất cả ở mức tổng quan?
kube-apiserver là management component chính của Kubernetes. kube-apiserver chịu trách nhiệm điều phối (orchestrate) mọi hoạt động bên trong cluster. Nó expose Kubernetes API, được dùng bởi người dùng bên ngoài để thực hiện các thao tác quản lý trên cluster, cũng như bởi các controller khác nhau để giám sát trạng thái của cluster và thực hiện thay đổi cần thiết, và bởi các worker node để giao tiếp với kube-apiserver.
Container runtime engine
Ở đây đang làm việc với container — container xuất hiện ở khắp nơi. Ứng dụng ở dạng container. Các component tạo nên toàn bộ hệ thống quản lý trên master node có thể được host dưới dạng container. DNS service và giải pháp networking cũng có thể được deploy dưới dạng container. Vì vậy cần phần mềm có khả năng chạy container — đó là container runtime engine, một trong những cái phổ biến là Docker.
Vì vậy cần cài Docker hoặc phần tương đương được hỗ trợ trên tất cả các node trong cluster, kể cả master node, nếu muốn host control plane component dưới dạng container. Không nhất thiết phải là Docker — Kubernetes hỗ trợ các runtime engine khác như containerd, rkt.
kubelet
Mỗi tàu đều có một thuyền trưởng (captain), chịu trách nhiệm quản lý toàn bộ hoạt động trên tàu. Thuyền trưởng chịu trách nhiệm liên lạc với tàu chủ (master ship) — bắt đầu bằng việc báo cho tàu chủ biết mình muốn gia nhập nhóm, nhận thông tin về các container cần load lên tàu và load đúng container theo yêu cầu, gửi báo cáo về cho master về trạng thái của tàu và container trên tàu, v.v.
Thuyền trưởng của tàu chính là kubelet trong Kubernetes. kubelet là một agent chạy trên mỗi node trong cluster. Nó lắng nghe hướng dẫn từ kube-apiserver và deploy hoặc destroy container trên các node khi cần. kube-apiserver định kỳ lấy status report từ kubelet để giám sát trạng thái của node và container trên chúng.
kube-proxy
kubelet giống thuyền trưởng quản lý container trên tàu. Nhưng các ứng dụng chạy trên worker node cần có khả năng giao tiếp với nhau. Ví dụ có thể có một web server chạy trong 1 container trên 1 node, và một database server chạy trong 1 container khác trên node khác. Làm sao web server reach tới database server trên node kia?
Giao tiếp giữa các worker node được kích hoạt bởi một component khác chạy trên worker node, gọi là kube-proxy service. kube-proxy service đảm bảo các rule cần thiết được thiết lập trên worker node, cho phép các container chạy trên chúng reach được tới nhau.
Tóm tắt kiến trúc
Vậy có master node và worker node.
Trên master, có etcd cluster lưu thông tin về cluster. Có kube-scheduler chịu trách nhiệm lên lịch ứng dụng hoặc container trên các node. Có các controller khác nhau lo các chức năng khác nhau như node controller, replication controller, v.v. Có kube-apiserver chịu trách nhiệm điều phối mọi hoạt động bên trong cluster.
Trên worker node, có kubelet lắng nghe hướng dẫn từ kube-apiserver và quản lý container, và kube-proxy giúp kích hoạt giao tiếp giữa các service trong cluster.
Đó là overview tổng quan về các component khác nhau. Các phần tiếp theo sẽ đi sâu vào từng component.
3. Container Runtime: Docker, containerd và CRI
Docker và containerd sẽ xuất hiện rất nhiều lần trong khóa học. Khi đọc blog hay trang tài liệu cũ, sẽ thấy Docker được nhắc tới cùng Kubernetes. Khi đọc blog mới hơn, sẽ thấy containerd, và có thể sẽ tự hỏi sự khác biệt giữa 2 cái này là gì. Ngoài ra còn có vài CLI tool như ctr, crictl hay nerdctl, và có thể sẽ tự hỏi các tool này là gì và nên dùng cái nào.
Lịch sử: từ Docker tới CRI
Quay lại thời điểm bắt đầu kỷ nguyên container: ban đầu chỉ có Docker, và có các tool khác như rkt, nhưng trải nghiệm người dùng của Docker khiến việc làm việc với container trở nên siêu đơn giản, và vì vậy Docker trở thành container tool thống trị nhất. Sau đó Kubernetes ra đời để orchestrate Docker — Kubernetes ban đầu được xây dựng để orchestrate cụ thể Docker. Vì vậy Docker và Kubernetes gắn chặt với nhau, và lúc đó Kubernetes chỉ hoạt động với Docker, không hỗ trợ giải pháp container nào khác.
Sau đó Kubernetes tăng độ phổ biến với vai trò container orchestrator, và các container runtime khác như rkt muốn tham gia. Người dùng Kubernetes cần nó hoạt động với các container runtime khác ngoài Docker. Vì vậy Kubernetes giới thiệu một interface gọi là Container Runtime Interface, hay CRI. CRI cho phép bất kỳ vendor nào hoạt động như một container runtime cho Kubernetes, miễn tuân thủ chuẩn OCI.
OCI là viết tắt của Open Container Initiative, gồm một image spec và một runtime spec. Image spec định nghĩa các tiêu chuẩn về cách một image cần được build. Runtime spec định nghĩa tiêu chuẩn về cách bất kỳ container runtime nào cần được phát triển. Theo các chuẩn này, bất kỳ ai cũng có thể build một container runtime để bất kỳ ai khác dùng cùng Kubernetes.
rkt và các container runtime khác tuân thủ chuẩn OCI được hỗ trợ làm container runtime cho Kubernetes thông qua CRI. Tuy nhiên, Docker không được xây dựng để hỗ trợ chuẩn CRI, vì Docker được xây dựng từ trước khi CRI ra đời, và Docker vẫn là container tool thống trị được đa số sử dụng. Vì vậy Kubernetes phải tiếp tục hỗ trợ Docker, và Kubernetes giới thiệu Dockershim — một cách hacky nhưng tạm thời để tiếp tục hỗ trợ Docker bên ngoài Container Runtime Interface. Trong khi hầu hết container runtime khác hoạt động qua CRI, Docker tiếp tục hoạt động mà không qua nó.
Docker thực chất gồm nhiều tool
Docker không chỉ đơn thuần là một container runtime. Docker gồm nhiều tool ghép lại: Docker CLI, Docker API, các build tool giúp build image, hỗ trợ volume, auth, security, và cuối cùng là container runtime tên runc, cùng daemon quản lý runc gọi là containerd. containerd tương thích CRI và có thể hoạt động trực tiếp với Kubernetes, như mọi runtime khác. containerd có thể được dùng làm runtime độc lập, tách biệt khỏi Docker.
Kubernetes tiếp tục duy trì hỗ trợ Docker Engine trực tiếp. Tuy nhiên, việc phải duy trì Dockershim là một nỗ lực không cần thiết và gây thêm phức tạp. Vì vậy, ở phiên bản Kubernetes 1.24, Dockershim đã bị loại bỏ hoàn toàn — hỗ trợ Docker bị gỡ bỏ. Nhưng mọi image được build trước khi Docker bị gỡ vẫn tiếp tục hoạt động, vì Docker tuân theo image spec của chuẩn OCI. Vì vậy mọi image được build bởi Docker tuân theo chuẩn, nên chúng tiếp tục hoạt động với containerd — chỉ có bản thân Docker bị gỡ khỏi danh sách runtime được hỗ trợ chính thức của Kubernetes.
containerd: một dự án CNCF độc lập
containerd, dù là một phần của Docker, giờ là một dự án độc lập, và là thành viên của CNCF với trạng thái graduated. Có thể cài containerd độc lập mà không cần cài Docker. Nếu không thực sự cần các tính năng khác của Docker, có thể chỉ cần cài containerd.
ctr — CLI debug đi kèm containerd
Trước đây, container được chạy bằng lệnh docker run khi có Docker. Nếu không cài Docker, làm sao chạy container chỉ với containerd? Khi cài containerd, nó đi kèm một CLI tool tên ctr — công cụ này chỉ dành riêng để debug containerd, không thân thiện với người dùng vì chỉ hỗ trợ một tập tính năng giới hạn.
Để pull image Redis:
ctr images pull docker.io/library/redis:latest
# Output minh họa
docker.io/library/redis:latest: resolved |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:1a2b3c...: done |++++++++++++++++++++++++++++++++++++++|
config-sha256:4d5e6f...: done |++++++++++++++++++++++++++++++++++++++|
layer-sha256:7g8h9i...: done |++++++++++++++++++++++++++++++++++++++|
elapsed: 3.2 s total: 16.2 Mi (5.1 MiB/s)
(Output minh họa — cấu trúc và định dạng progress bar đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Để chạy container:
ctr run docker.io/library/redis:latest redis-test
# Output minh họa (chạy foreground, không có output nếu container thoát bình thường)
(Lệnh ctr run mặc định chạy container ở foreground và gắn liền với terminal hiện tại — không có flag tương đương -d như docker run trừ khi thêm --detach.)
Tool này chỉ dành riêng để debug containerd, không thân thiện với người dùng, và không nên dùng để chạy hay quản lý container trên môi trường production.
nerdctl — Docker-like CLI cho containerd
Một lựa chọn thay thế tốt hơn được khuyến nghị là tool nerdctl — một Docker-like CLI cho containerd. Nó hỗ trợ hầu hết hoặc toàn bộ option mà Docker hỗ trợ. Thêm vào đó, nó có lợi ích là cho phép truy cập các tính năng mới nhất được triển khai trong containerd, ví dụ làm việc với encrypted container image (một tính năng khá mới, cuối cùng sẽ được triển khai vào các lệnh Docker thông thường trong tương lai). Nó cũng hỗ trợ lazy pulling of images, P2P image distribution, image signing và verifying, và namespaces trong Kubernetes — thứ không có sẵn trong Docker.
Thay vì dùng lệnh docker run để tạo container, có thể dùng lệnh nerdctl run. Tương tự, muốn dùng option cho port mapping hay expose port với option -p của lệnh docker run, cũng có thể làm y hệt với nerdctl — chỉ đơn giản thay docker bằng nerdctl.
crictl — CLI debug từ phía Kubernetes
Còn một command-line utility khác cần nói tới là crictl, hay CRI control. crictl là một command-line utility dùng để tương tác với container runtime tương thích CRI, như containerd, Rocket, và các runtime khác — đây là tương tác từ góc nhìn Kubernetes. Tool này được phát triển và duy trì bởi cộng đồng Kubernetes, và hoạt động trên tất cả các container runtime khác nhau. Khác với ctr và nerdctl vốn được xây dựng bởi cộng đồng containerd, dành riêng cho containerd, crictl là tool từ góc nhìn Kubernetes, hoạt động trên các container runtime khác nhau.
crictl phải được cài riêng, và dùng để inspect và debug container runtime. Đây không phải tool để tạo container như Docker hay nerdctl — đây lại là một debugging tool. Về mặt kỹ thuật có thể tạo container bằng crictl, nhưng không dễ, và chỉ nên dùng cho mục đích debug đặc biệt.
⚠️ Lưu ý:
crictlhoạt động cùng kubelet. kubelet chịu trách nhiệm đảm bảo đúng số lượng container hoặc pod luôn khả dụng trên một node tại một thời điểm. Nếu dùngcrictlđể tạo container, kubelet sẽ xóa chúng đi, vì kubelet không biết về những container/pod được tạo ngoài phạm vi quản lý của nó.
Một số ví dụ command line:
crictl ps
# Output minh họa
CONTAINER IMAGE CREATED STATE NAME POD ID
a1b2c3d4e5f6 nginx 2 minutes ago Running nginx f6e5d4c3b2a1
(Output minh họa — cấu trúc và tên cột đúng theo lệnh thật, ID/thời gian cụ thể chỉ mang tính ví dụ.)
Tương tự lệnh docker ps, dùng để list container. Để chạy một command bên trong container (tương tự docker exec):
crictl exec -i -t a1b2c3d4e5f6 sh
# Output minh họa — mở shell tương tác bên trong container
/ #
Để xem log:
crictl logs a1b2c3d4e5f6
# Output minh họa
2026-08-19T10:00:01Z [notice] nginx started
2026-08-19T10:00:01Z [notice] using the "epoll" event method
Điểm khác biệt lớn là crictl biết về pod, nên có thể list pod bằng:
crictl pods
# Output minh họa
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
f6e5d4c3b2a1 3 minutes ago Ready nginx-pod default 0
(Output minh họa — cấu trúc và tên cột đúng theo lệnh thật, ID/thời gian cụ thể chỉ mang tính ví dụ.)
Docker không biết về khái niệm pod. Trước đây khi làm việc với Kubernetes, lệnh Docker được dùng nhiều để troubleshoot container và xem log, đặc biệt trên worker node. Giờ đây, lệnh crictl được dùng để làm việc đó — cú pháp khá tương tự.
Bảng so sánh giữa Docker và crictl: các lệnh như attach, exec, images, info, inspect, logs, ps, stats, version hoạt động y hệt nhau. Một số lệnh để tạo, xóa, start và stop image cũng hoạt động tương tự.
Thay đổi default endpoint của crictl từ Kubernetes 1.24
Ở các phiên bản Kubernetes trước 1.24, tool crictl kết nối tới runtime endpoint theo thứ tự mặc định nhất định. Tuy nhiên, với việc phát hành Kubernetes 1.24, một thay đổi đáng kể đã được thực hiện: dockershim.sock được thay bằng cri-dockerd.sock. Kết quả là default endpoint cập nhật cho tool crictl đã thay đổi. Thay đổi này được thực hiện do việc deprecate các default setting trước đó. Giờ đây người dùng được khuyến khích tự set endpoint thủ công. Những thay đổi này được ghi lại trong repo GitHub cri-tools của Kubernetes, cụ thể tại pull request 869 và issue 868.
Tóm tắt
ctr— CLI đi kèm containerd, dùng cho mục đích debug, có tập tính năng rất hạn chế. Về cơ bản không nên dùng tool này.nerdctl— CLI từ cộng đồng containerd, là Docker-like CLI cho containerd, dùng cho mục đích thông thường để tạo container, hỗ trợ tính năng ngang bằng hoặc nhiều hơn Docker CLI.crictl— utility từ cộng đồng Kubernetes, chủ yếu dùng để tương tác với runtime tương thích CRI, không chỉ containerd — dùng được cho mọi runtime hỗ trợ CRI, chủ yếu dùng cho mục đích debug.
ctr và crictl chủ yếu dùng cho mục đích debug, còn nerdctl dùng cho mục đích thông thường. ctr và nerdctl đến từ cộng đồng containerd và làm việc với containerd, còn crictl đến từ cộng đồng Kubernetes và làm việc trên mọi runtime tương thích CRI.
Vì sao vẫn nói về Docker dù đã bị deprecate?
Một câu hỏi thường gặp: vì sao tài liệu vẫn nhắc tới Docker nếu nó đã bị deprecate khỏi Kubernetes? Docker vốn là container runtime gốc và duy nhất được Kubernetes hỗ trợ. Để mở Kubernetes cho các runtime khác, Container Runtime Interface đã được giới thiệu. Docker gồm nhiều tool ghép lại: Docker CLI, API, build tool giúp build image, hỗ trợ volume, auth, security, và cuối cùng là container runtime tên runc, cùng daemon quản lý runtime gọi là containerd. containerd tương thích CRI và là component có thể hoạt động trực tiếp với Kubernetes, như mọi runtime khác. containerd có thể dùng làm runtime độc lập, tách biệt khỏi Docker.
Một khi thay đổi này được thực hiện, Kubernetes không còn cần các tool khác mà Docker hỗ trợ nữa, như Docker CLI, API, hay build/volume — vì tất cả đã được chính Kubernetes tự đảm nhiệm, nên Kubernetes có thể deprecate hỗ trợ cho Docker.
⚠️ Không có nghĩa là Docker biến mất hoàn toàn. Docker vẫn là giải pháp container phổ biến nhất, vẫn được nhiều người dùng trong quy trình phát triển và build hằng ngày. Chỉ là Kubernetes không còn yêu cầu Docker làm runtime nữa.
Vì vậy, xuyên suốt tài liệu này, mỗi khi nói về container, ví dụ vẫn dùng Docker — hoàn toàn ổn, vì đôi khi cần học cách container hoạt động trước, rồi mới tới cách nó vận hành trong thế giới container orchestration của Kubernetes. Nếu không có Docker trên máy, hoặc chỉ dùng containerd, vẫn có thể làm việc với cùng các ví dụ bằng cách thay lệnh Docker bằng lệnh nerdctl trong hầu hết trường hợp.
4. ETCD
ETCD là gì?
Đây là phần giới thiệu nhanh về etcd cho người mới bắt đầu — nếu đã biết etcd, có thể bỏ qua. Phần này bàn về etcd là gì, key-value store là gì, và nó khác database truyền thống ra sao, cùng cách nhanh chóng bắt đầu với etcd và cách dùng client tool để thao tác với etcd. Phần sau của khóa học sẽ bàn về high availability — thế nào là một distributed system, etcd hoạt động ra sao ở chế độ cluster, Raft protocol là gì, và best practice xoay quanh số lượng node trong một etcd cluster.
etcd là một distributed, reliable key-value store — đơn giản, bảo mật, và nhanh.
Key-value store so với database truyền thống
Truyền thống, database ở dạng bảng (tabular) — SQL hay relational database — lưu dữ liệu dưới dạng hàng và cột. Mỗi hàng đại diện cho một cá nhân, mỗi cột đại diện cho loại thông tin được lưu. Muốn thêm thông tin mới (ví dụ salary), phải thêm một cột mới, và việc này ảnh hưởng toàn bộ bảng — nhiều ô sẽ trống nếu không phải mọi hàng đều có thông tin đó (ví dụ chỉ sinh viên mới có "grade").
Relational database có schema chặt chẽ, có thể thực hiện complex query bằng SQL, hiệu năng tốt, nhưng khá cứng nhắc về mặt linh hoạt, và phù hợp nhất với dữ liệu có cấu trúc (structured data).
Document store lưu thông tin dưới dạng document — mỗi cá nhân có một document riêng, mọi thông tin về cá nhân đó nằm trong file đó. Các file này có thể ở bất kỳ định dạng hay cấu trúc nào, và thay đổi trên một file không ảnh hưởng các file khác. Document store thường lưu dữ liệu ở định dạng JSON. So với relational database, document store thường không cần định nghĩa schema, có thể hạn chế khi thực hiện complex query bằng cách join nhiều bảng, hiệu năng tốt, rất linh hoạt nhờ cấu trúc document, phù hợp nhất với dữ liệu bán cấu trúc (semi-structured data).
Key-value store là loại lưu trữ thứ ba — siêu đơn giản, lưu một value ứng với một key. Ví dụ key là name, value là John; key khác là location, value là New York; key age, value 45; key salary, value 5000. Cũng có thể lưu dữ liệu phức tạp hơn — key có thể là user:John Doe, value có thể là một tập property hoặc cả một JSON document.
So với các mô hình lưu trữ khác, key-value store không nhất thiết có schema, không hỗ trợ complex query, nhưng hiệu năng cực nhanh và rất linh hoạt — có thể lưu gần như bất kỳ thứ gì mà không phá vỡ cấu trúc khác hay phải lo về data structure. Vì vậy nó phù hợp nhất cho các tra cứu (lookup) đơn giản, nhanh.
etcd là một key-value store thuộc loại này — distributed và reliable.
Cài đặt và dùng thử etcd
Cách cài đặt và bắt đầu với etcd: tải binary, giải nén, và chạy. Tải binary phù hợp với hệ điều hành từ trang GitHub Releases, giải nén, và chạy executable etcd. Khi chạy etcd, nó khởi động một service lắng nghe trên port 2379 theo mặc định — đó là etcd server. Đây là cách chạy etcd server đơn giản nhất; trong thực tế nên chạy nó như một system service hoặc như một pod trên Kubernetes cluster.
Client mặc định đi kèm etcd là etcd control client, hay etcdctl — một command-line client cho etcd. Dùng nó để lưu và truy xuất key-value pair.
Lưu một cặp key-value:
etcdctl put key1 value1
# Output minh họa
OK
Truy xuất dữ liệu đã lưu:
etcdctl get key1
# Output minh họa
key1
value1
(Output minh họa — etcdctl trả về key rồi tới value trên 2 dòng riêng, đúng hành vi thật của lệnh get.)
Xem thêm các option:
etcdctl
# Output minh họa (rút gọn)
NAME:
etcdctl - A simple command line client for etcd3.
USAGE:
etcdctl [flags]
COMMANDS:
get Gets the key or a range of keys
put Puts the given key into the store
del Removes the specified key or range of keys
...
(Output minh họa, rút gọn — danh sách lệnh đầy đủ dài hơn nhiều.)
Lịch sử phiên bản etcd
Có thể sẽ gặp các phiên bản command khác nhau khi tìm hiểu etcd và các bài viết liên quan trực tuyến, nên cần hiểu lịch sử các bản release của etcd để biết điều gì thay đổi khi nào.
- Phiên bản đầu tiên của etcd, v0.1, được release vào tháng 8/2013.
- Bản stable chính thức, v2.0, được release vào tháng 2/2015 — đây là lúc thuật toán đồng thuận Raft (Raft consensus algorithm) được thiết kế lại và hỗ trợ hơn 1.000 writes/giây.
- Vào tháng 1/2017, etcd release version 3 với nhiều tối ưu hóa và cải thiện hiệu năng hơn.
Điểm quan trọng cần lưu ý là thay đổi giữa version 2 và 3: API version thay đổi, nên lệnh etcdctl cũng thay đổi theo. API cũ (v2) dùng lệnh etcdctl set và etcdctl get thay vì etcdctl put và get; ở v2 dùng rm để xóa value, ở v3 dùng del. Và v2 không hỗ trợ transaction, còn v3 có hỗ trợ transaction.
- Vào tháng 11/2018, etcd trở thành CNCF incubating project — nghĩa là Cloud Native Computing Foundation tiếp quản việc quản trị và hỗ trợ dự án.
- Nhiều bản release tiếp theo cho tới tháng 11/2020, khi etcd trở thành CNCF graduated project.
- Vào tháng 6/2021, version 3.5 được release.
Có thể sẽ thấy blog, tài liệu online nói về API cũ dùng lệnh etcdctl set và get thay vì etcdctl put và get — đừng ngạc nhiên, vì chúng đang ở phiên bản cũ hơn. Có thể xem version bằng lệnh:
etcdctl version
# Output minh họa
etcdctl version: 3.5.9
API version: 3.5
(Output minh họa — số version cụ thể chỉ mang tính ví dụ, điểm cần chú ý là dòng "API version" cho biết đang ở version 2 hay 3.)
Nhìn vào API version, sẽ thấy đang ở version 2 hay 3. Phiên bản mới hơn dùng lệnh put, get, và delete thay vì set, get, và rm.
Vai trò của etcd trong Kubernetes
Datastore etcd lưu thông tin về cluster, như node, pod, config, secret, account, role, role binding, và nhiều thứ khác. Mọi thông tin thấy được khi chạy lệnh kubectl get đều đến từ etcd server. Mọi thay đổi thực hiện trên cluster — như thêm node mới, deploy pod hoặc ReplicaSet — đều được cập nhật vào etcd server. Chỉ khi được cập nhật vào etcd server thì thay đổi đó mới được xem là hoàn tất.
Tùy vào cách cluster được thiết lập, etcd được deploy khác nhau. Có 2 kiểu deploy Kubernetes: một là deploy from scratch, hai là dùng tool kubeadm. Môi trường practice test dùng tool kubeadm, còn phần sau của khóa học, khi tự setup cluster, sẽ setup from scratch — nên cần biết sự khác biệt giữa 2 cách.
Nếu setup cluster from scratch, etcd được deploy bằng cách tự tải etcd binary, cài đặt binary, và tự cấu hình etcd như một service trên master node. Có nhiều option truyền vào service — một số liên quan tới certificate (phần sau khóa học có hẳn một mục về TLS certificate). Các option khác dùng để cấu hình etcd như một cluster. Option cần chú ý ngay bây giờ là advertised client URL — đây là địa chỉ etcd lắng nghe, thường là IP của server và port 2379, port mặc định etcd lắng nghe. Đây là URL cần được cấu hình trên kube-apiserver khi nó cố gắng reach tới etcd server.
Nếu setup cluster bằng kubeadm, kubeadm deploy etcd server dưới dạng một pod trong namespace kube-system (namespace là cách Kubernetes nhóm và cô lập tài nguyên bên trong cùng một cluster — kube-system là namespace riêng Kubernetes dùng cho các component nội bộ của chính nó; phần Namespaces của tài liệu sẽ bàn chi tiết hơn). Có thể khám phá etcd database bằng utility etcdctl bên trong pod đó. Để list toàn bộ key được lưu bởi Kubernetes:
etcdctl get / --prefix --keys-only
# Output minh họa (rút gọn)
/registry/minions/node01
/registry/pods/default/nginx-pod
/registry/replicasets/default/myapp-rs
/registry/deployments/default/frontend-deployment
...
(Output minh họa, rút gọn — cấu trúc đường dẫn /registry/<loại resource>/... đúng theo thật, danh sách key đầy đủ dài hơn nhiều.)
Kubernetes lưu dữ liệu theo một cấu trúc thư mục cụ thể. Thư mục gốc là registry, và bên dưới đó là các construct khác nhau của Kubernetes như Minions hay nodes, pods, ReplicaSets, Deployments, v.v.
Trong môi trường high availability, sẽ có nhiều master node trong cluster, và tương ứng có nhiều instance etcd trải trên các master node. Trong trường hợp đó, phải đảm bảo các instance etcd biết về nhau bằng cách set đúng tham số trong cấu hình etcd service — option initial cluster là nơi chỉ định các instance khác nhau của etcd service.
ETCDCTL — Commands (tùy chọn)
ETCDCTL là CLI tool dùng để tương tác với ETCD. ETCDCTL có thể tương tác với ETCD Server dùng 2 phiên bản API — Version 2 và Version 3. Mặc định nó được set dùng Version 2. Mỗi version có tập lệnh khác nhau.
Ví dụ, ETCDCTL version 2 hỗ trợ các lệnh sau:
etcdctl backup
etcdctl cluster-health
etcdctl mk
etcdctl mkdir
etcdctl set
Trong khi các lệnh khác nhau ở version 3:
etcdctl snapshot save
etcdctl endpoint health
etcdctl get
etcdctl put
Để set đúng version API, set biến môi trường ETCDCTL_API:
export ETCDCTL_API=3
Khi API version không được set, nó được coi là version 2, và các lệnh version 3 liệt kê ở trên sẽ không hoạt động. Khi API version được set là version 3, các lệnh version 2 liệt kê ở trên sẽ không hoạt động.
Ngoài ra, phải chỉ định đường dẫn tới các file certificate để ETCDCTL có thể authenticate tới ETCD API Server. Các file certificate có sẵn trên etcd-master tại đường dẫn sau (phần security của khóa học sẽ bàn thêm về certificate):
--cacert /etc/kubernetes/pki/etcd/ca.crt
--cert /etc/kubernetes/pki/etcd/server.crt
--key /etc/kubernetes/pki/etcd/server.key
Vậy để các lệnh nói trên hoạt động, phải chỉ định version API của ETCDCTL và đường dẫn tới các file certificate. Dưới đây là dạng đầy đủ:
kubectl exec etcd-controlplane -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl get / \
--prefix --keys-only --limit=10 / \
--cacert /etc/kubernetes/pki/etcd/ca.crt \
--cert /etc/kubernetes/pki/etcd/server.crt \
--key /etc/kubernetes/pki/etcd/server.key"
# Output minh họa
/registry/apiregistration.k8s.io/apiservices/v1.
/registry/apiregistration.k8s.io/apiservices/v1.admissionregistration.k8s.io
/registry/apiregistration.k8s.io/apiservices/v1.apps
/registry/clusterrolebindings/cluster-admin
/registry/clusterroles/admin
/registry/controllerrevisions/kube-system/kube-proxy-...
/registry/daemonsets/kube-system/kube-proxy
/registry/deployments/kube-system/coredns
/registry/minions/controlplane
/registry/namespaces/default
/registry/pods/kube-system/etcd-controlplane
(Output minh họa, rút gọn theo --limit=10 — mỗi dòng là 1 key theo đường dẫn /registry/<loại resource>/..., giá trị thật của các key này không hiển thị vì dùng --keys-only.)
5. Kube-apiserver
Trước đó đã bàn rằng kube-apiserver là management component chính trong Kubernetes. Khi chạy một lệnh kubectl, thực chất kubectl đang reach tới kube-apiserver. kube-apiserver trước tiên authenticate request và validate nó, sau đó truy xuất dữ liệu từ etcd cluster và trả về thông tin được yêu cầu.
Không nhất thiết phải dùng command line kubectl — cũng có thể gọi API trực tiếp bằng cách gửi một POST request. Ví dụ tạo một Pod: request được authenticate trước, rồi validate. Trong trường hợp này, API server tạo một pod object mà chưa gán vào node nào, cập nhật thông tin trong etcd server, cập nhật cho user biết pod đã được tạo.
Scheduler liên tục giám sát kube-apiserver và nhận ra có một pod mới chưa được gán node. Scheduler xác định đúng node để đặt pod mới, và giao tiếp lại với kube-apiserver. API server sau đó cập nhật thông tin trong etcd cluster. API server sau đó chuyển thông tin đó tới kubelet trên worker node phù hợp. kubelet tạo Pod trên node và chỉ thị container runtime engine deploy application image. Xong việc, kubelet cập nhật status ngược lại cho API server, và API server cập nhật dữ liệu vào etcd cluster.
Pattern tương tự được lặp lại mỗi khi có yêu cầu thay đổi. kube-apiserver là trung tâm của mọi tác vụ cần thực hiện để tạo thay đổi trong cluster.
Tóm lại, kube-apiserver chịu trách nhiệm authenticate và validate request, cũng như truy xuất và cập nhật dữ liệu trong etcd data store. Thực tế, kube-apiserver là component duy nhất tương tác trực tiếp với etcd data store. Các component khác như scheduler, kube-controller-manager, và kubelet dùng kube-apiserver để thực hiện cập nhật trong cluster ở mảng tương ứng của chúng.
Cài đặt và xem cấu hình kube-apiserver
Nếu bootstrap cluster bằng tool kubeadm, không cần biết chi tiết này. Nhưng nếu setup theo cách thủ công (hard way), kube-apiserver có sẵn dưới dạng binary trên trang release của Kubernetes. Tải về và cấu hình để chạy như một service trên Kubernetes master node. kube-apiserver được chạy với rất nhiều tham số.
Kiến trúc Kubernetes gồm nhiều component khác nhau phối hợp với nhau, giao tiếp với nhau theo nhiều cách khác nhau. Vì vậy chúng cần biết vị trí của nhau. Có nhiều mode xác thực (authentication), phân quyền (authorization), mã hóa (encryption), và bảo mật khác nhau — đó là lý do có nhiều option như vậy. Nhiều option trong số đó là certificate dùng để bảo mật kết nối giữa các component khác nhau (mục SSL/TLS Certificates sau này của khóa học sẽ bàn chi tiết hơn — có hẳn một phần riêng cho nó).
Một option quan trọng cần biết là --etcd-servers — đây là nơi chỉ định vị trí của etcd server. Đây là cách kube-apiserver kết nối tới etcd server.
Cách xem option của kube-apiserver trên một cluster có sẵn phụ thuộc vào cách cluster được setup:
- Nếu setup bằng tool
kubeadm, kubeadm deploy kube-apiserver dưới dạng pod trong namespacekube-systemtrên master node — có thể xem option trong pod definition file tại thư mục/etc/kubernetes/manifests. - Trong setup không dùng kubeadm, có thể inspect option bằng cách xem kube-apiserver service tại
/etc/systemd/system, filekube-apiserver.service. Cũng có thể xem process đang chạy và các option hiệu lực bằng cách list process trên master node và tìmkube-apiserver.
6. Kube-controller-manager
kube-controller-manager quản lý các controller khác nhau trong Kubernetes.
💡 Hình dung: một controller giống như một văn phòng hay phòng ban bên trong con tàu chủ (master ship), có tập trách nhiệm riêng — ví dụ một văn phòng chịu trách nhiệm giám sát và hành động cần thiết về các tàu, mỗi khi có tàu mới tới hoặc tàu rời đi hay bị hủy. Một văn phòng khác quản lý container trên các tàu, lo việc container bị hư hỏng hoặc rơi khỏi tàu. Các văn phòng này, thứ nhất, liên tục theo dõi trạng thái của các tàu, và thứ hai, thực hiện hành động cần thiết để khắc phục tình huống.
Trong thuật ngữ Kubernetes, một controller là một process liên tục giám sát trạng thái của các component khác nhau trong hệ thống, và hoạt động để đưa toàn bộ hệ thống về trạng thái hoạt động mong muốn.
Node controller
Ví dụ, node controller chịu trách nhiệm giám sát trạng thái của các node và thực hiện hành động cần thiết để giữ ứng dụng tiếp tục chạy. Nó thực hiện việc này thông qua Kube API Server.
Node controller kiểm tra trạng thái của node mỗi 5 giây — nhờ vậy có thể giám sát sức khỏe của node. Nếu ngừng nhận heartbeat từ một node, node đó được đánh dấu là unreachable — nhưng nó chờ 40 giây trước khi đánh dấu như vậy. Sau khi một node bị đánh dấu unreachable, nó cho node đó 5 phút để quay trở lại hoạt động. Nếu không, nó gỡ các pod được gán cho node đó và cấp phát lại chúng trên các node khỏe mạnh, nếu các pod đó thuộc một ReplicaSet.
Replication controller
Controller tiếp theo là Replication Controller. Nó chịu trách nhiệm giám sát trạng thái của ReplicaSet và đảm bảo số lượng pod mong muốn luôn khả dụng tại mọi thời điểm trong tập đó. Nếu một pod chết, nó tạo pod khác.
Đó chỉ là 2 ví dụ về controller — còn nhiều controller khác có sẵn trong Kubernetes. Bất kỳ khái niệm nào đã thấy trong Kubernetes, như deployments, services, namespaces, hay persistent volumes, và bất kỳ trí tuệ (intelligence) nào được xây dựng vào các construct đó, đều được triển khai thông qua các controller này. Đây gần như là "bộ não" đứng sau rất nhiều thứ trong Kubernetes.
kube-controller-manager: cài đặt và cấu hình
Vậy làm sao thấy các controller này, và chúng nằm ở đâu trong cluster? Tất cả được đóng gói vào một process duy nhất gọi là kube-controller-manager. Khi cài Kubernetes controller manager, các controller khác nhau cũng được cài theo.
Cách cài và xem Kubernetes controller manager: tải kube-controller-manager từ trang release của Kubernetes, giải nén và chạy như một service. Khi chạy, có một danh sách option được cung cấp — đây là nơi cung cấp thêm option để tùy chỉnh controller. Một số setting mặc định của node-controller đã bàn ở trên, như node-monitor-period, grace period, và eviction timeout, đều đi vào đây dưới dạng option. Có thêm một option tên controllers để chỉ định controller nào được bật — mặc định tất cả được bật, nhưng có thể chọn chỉ bật một số. Nếu controller nào không hoạt động hoặc không tồn tại, đây là điểm bắt đầu tốt để kiểm tra.
Cách xem option của service kube-controller-manager: nếu setup bằng tool kubeadm, kubeadm deploy kube-controller-manager dưới dạng pod trong namespace kube-system trên master node — có thể xem option trong pod definition file tại thư mục /etc/kubernetes/manifests. Trong setup không dùng kubeadm, có thể inspect option bằng cách xem kube-controller-manager service tại thư mục services. Cũng có thể xem process đang chạy và option hiệu lực bằng cách list process trên master node và tìm kube-controller-manager.
7. Kube-scheduler
Trước đó đã bàn rằng Kubernetes scheduler chịu trách nhiệm lên lịch (schedule) Pod trên các node. Scheduler chỉ chịu trách nhiệm quyết định Pod nào đi lên node nào — nó không thực sự đặt Pod lên node. Đó là việc của kubelet. kubelet, hay thuyền trưởng trên tàu, mới là bên tạo pod trên tàu. Scheduler chỉ quyết định pod nào đi đâu.
Vì sao cần scheduler?
Khi có nhiều tàu và nhiều container, cần đảm bảo đúng container kết thúc trên đúng tàu. Ví dụ, có thể có các kích thước tàu và container khác nhau — cần đảm bảo tàu có đủ dung lượng chứa các container đó. Các tàu khác nhau có thể đi tới điểm đến khác nhau — cần đảm bảo container được đặt lên đúng tàu, để chúng đến đúng điểm đến.
Trong Kubernetes, scheduler quyết định Pod được đặt lên node nào dựa trên một số tiêu chí nhất định. Có thể có pod với resource requirement khác nhau, và có thể có node trong cluster dành riêng cho một số ứng dụng nhất định.
Scheduler hoạt động qua 2 giai đoạn
Scheduler nhìn vào từng pod và cố gắng tìm node tốt nhất cho nó. Ví dụ, lấy một trong các pod — pod màu xanh lớn — có một tập yêu cầu CPU và memory. Scheduler đi qua 2 giai đoạn để xác định node tốt nhất cho pod.
Giai đoạn 1 — Filter: scheduler cố gắng lọc ra các node không phù hợp với profile của Pod. Ví dụ, các node không có đủ tài nguyên CPU và memory mà pod yêu cầu — 2 node nhỏ đầu tiên bị lọc ra. Giờ còn lại 2 node có thể đặt pod lên.
Giai đoạn 2 — Rank: giờ làm sao scheduler chọn một trong 2 node còn lại? Scheduler xếp hạng các node để xác định node phù hợp nhất cho pod. Nó dùng một priority function để gán điểm cho các node theo thang từ 0 đến 10. Ví dụ, scheduler tính lượng tài nguyên còn trống trên các node sau khi đặt pod lên chúng. Trong trường hợp này, node bên phải sẽ có 6 CPU trống nếu pod được đặt lên nó, nhiều hơn 4 CPU so với node bên trái — nên nó được xếp hạng tốt hơn, và thắng.
Đó là cách scheduler hoạt động ở mức tổng quan. Tất nhiên, các bước này có thể tùy chỉnh, và cũng có thể tự viết scheduler riêng. Còn nhiều chủ đề khác cần tìm hiểu, như resource requirement, limit, taints và tolerations, node selector, affinity rule, v.v. — vì vậy khóa học có hẳn một mục riêng dành cho scheduling sẽ bàn chi tiết hơn về từng thứ này.
Cài đặt và cấu hình kube-scheduler
Cách cài kube-scheduler: tải binary kube-scheduler từ trang release của Kubernetes, giải nén và chạy như một service. Khi chạy như một service, chỉ định file cấu hình scheduler.
Cách xem option của service kube-scheduler: nếu setup bằng tool kubeadm, kubeadm deploy kube-scheduler dưới dạng pod trong namespace kube-system trên control plane node — có thể xem option trong pod definition file tại thư mục /etc/kubernetes/manifests. Cũng có thể xem process đang chạy và option hiệu lực bằng cách list process trên control plane node và tìm kube-scheduler.
8. Kubelet
Trước đó đã bàn rằng kubelet giống như thuyền trưởng trên tàu — dẫn dắt mọi hoạt động trên một tàu, là bên chịu trách nhiệm làm mọi thủ tục giấy tờ cần thiết để trở thành một phần của cluster. Họ là đầu mối liên lạc duy nhất từ tàu chủ, load hoặc unload container trên tàu theo chỉ thị của scheduler trên master. Họ cũng gửi báo cáo định kỳ về trạng thái của tàu và container trên tàu.
kubelet trên Kubernetes worker node đăng ký node đó với Kubernetes cluster. Khi nhận chỉ thị load một container hay pod lên node, nó yêu cầu container runtime engine (có thể là Docker) pull image cần thiết và chạy một instance. kubelet sau đó tiếp tục giám sát trạng thái của pod và các container trong nó, và báo cáo về kube-apiserver theo định kỳ.
Cài đặt kubelet
Nếu dùng tool kubeadm để deploy cluster, nó không tự động deploy kubelet — đây là điểm khác biệt so với các component khác. Luôn phải tự cài kubelet thủ công trên các worker node. Tải installer, giải nén, và chạy như một service.
Có thể xem process kubelet đang chạy và các option hiệu lực bằng cách list process trên worker node và tìm kubelet.
Phần sau của khóa học sẽ tìm hiểu sâu hơn về kubelet — cách cấu hình kubelet, generate certificate, và cách TLS bootstrap kubelet.
9. Kube-proxy
Bên trong một Kubernetes cluster, mọi pod đều có thể reach tới mọi pod khác. Điều này đạt được bằng cách deploy một giải pháp pod networking cho cluster. Pod network là một mạng ảo nội bộ trải trên toàn bộ node trong cluster, mà mọi pod kết nối vào. Thông qua mạng này, chúng có thể giao tiếp với nhau. Có nhiều giải pháp để deploy một mạng như vậy.
Ví dụ, có một web application deploy trên node đầu tiên và database application deploy trên node thứ hai. Web app có thể reach tới database bằng cách dùng IP của pod, nhưng không có gì đảm bảo IP của database pod sẽ luôn giữ nguyên. Cách tốt hơn để web application truy cập database là dùng một service — tạo một service để expose database application trên toàn cluster. Web application giờ có thể truy cập database bằng tên của service, ví dụ db. Service cũng được gán một địa chỉ IP. Bất cứ khi nào một pod cố reach tới service bằng IP hay tên của nó, nó forward traffic tới pod backend — trong trường hợp này là database.
Nhưng service này là gì, và nó lấy IP ở đâu? Service có gia nhập cùng pod network không? Service không thể gia nhập pod network, vì service không phải một "vật" thực sự — nó không phải một container như pod, nên không có interface hay process nào đang lắng nghe. Nó là một component ảo chỉ tồn tại trong bộ nhớ của Kubernetes. Nhưng cũng đã nói rằng service phải truy cập được từ mọi node trên toàn cluster. Vậy làm sao đạt được điều đó? Đó là lúc kube-proxy vào cuộc.
Kube-proxy hoạt động ra sao
Kube-proxy là một process chạy trên mỗi node trong Kubernetes cluster. Công việc của nó là tìm các service mới, và mỗi khi một service mới được tạo, nó tạo các rule phù hợp trên mỗi node để forward traffic tới các service đó, tới pod backend.
Một cách nó thực hiện việc này là dùng rule IP tables (iptables — cơ chế lọc gói tin và NAT tích hợp sẵn trong nhân Linux, cho phép định nghĩa rule chuyển hướng traffic dựa trên địa chỉ IP/port). Trong trường hợp này, nó tạo một IP tables rule trên mỗi node trong cluster, để forward traffic hướng tới IP của service — ví dụ 10.96.0.12 — tới IP của pod thực sự, ví dụ 10.32.0.15. Đó là cách kube-proxy cấu hình một service.
Phần sau của khóa học sẽ bàn thêm nhiều về networking, service, kube-proxy, và pod networking — có hẳn một mục lớn dành riêng cho networking. Đây chỉ là overview ở mức tổng quan.
Cài đặt kube-proxy
Cách cài kube-proxy: tải binary kube-proxy từ trang release của Kubernetes, giải nén, và chạy như một service. Tool kubeadm deploy kube-proxy dưới dạng pod trên mỗi node — thực tế nó được deploy như một DaemonSet, nên luôn có đúng một pod được deploy trên mỗi node trong cluster.
Vậy là đã có overview mức tổng quan về các component chính của Kubernetes, gồm cả control plane lẫn component ở cấp node như kube-proxy vừa nêu. Các component này sẽ được xem xét chi tiết hơn ở nhiều mục khác nhau trong khóa học.
Nguồn tham khảo
Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — phần "Core Concepts" (giới thiệu phần Core Concepts, kiến trúc cluster, container runtime Docker/containerd/CRI, ETCD, kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy), nền tảng KodeKloud. Giảng viên: Mumshad Mannambeth.
Repo ghi chú, link tài liệu, và đáp án các practice question của toàn bộ khóa học: kodekloudhub/certified-kubernetes-administrator-course.
Fact-check:
node-monitor-periodmặc định 5s,node-monitor-grace-periodmặc định 40s trên kube-controller-manager — 2026-08-19, Kubernetes — kube-controller-manager reference- Từ Kubernetes 1.18, cơ chế gỡ Pod khỏi node unreachable chuyển sang taint-based eviction — mặc định
tolerationSeconds=300(5 phút) cho taintnode.kubernetes.io/not-ready/unreachable, điều khiển qua--default-not-ready-toleration-seconds/--default-unreachable-toleration-secondstrên kube-apiserver — 2026-08-19, kubernetes/kubernetes#74651 - Kubernetes 1.24 gỡ Dockershim, đổi default socket từ
dockershim.socksangcri-dockerd.sock— 2026-08-19, cri-tools PR #869, issue #868 - NodePort range mặc định 30000–32767 (
--service-node-port-range) — 2026-08-19, Kubernetes — Service