Kubernetes qua tài liệu kiến trúc: có nên dùng cho văn phòng công chứng nhỏ?
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Kubernetes: nền điều phối container, và câu hỏi có cần đến nó hay không
Kubernetes, viết tắt K8s, được README mô tả là hệ thống mã nguồn mở quản lý ứng dụng đóng gói container trên nhiều máy chủ, cung cấp các cơ chế cơ bản để triển khai, duy trì và mở rộng ứng dụng. Dự án do Cloud Native Computing Foundation (CNCF) lưu trữ và kế thừa kinh nghiệm vận hành hệ thống Borg của Google theo lời README. [1]
Đối tượng của bài này không phải người muốn học cách gõ kubectl, mà là người ra quyết định: đơn vị của bạn có nên gánh thêm một nền tảng điều phối hay không. Tài liệu kiến trúc cho thấy Kubernetes là một hệ thống phân tán với máy chủ API, bộ nhớ đệm theo dõi thay đổi, các controller và lớp giao tiếp với runtime. Mỗi lớp là một thứ phải hiểu, vá lỗi và giám sát. [3][4][9]
Khuyến nghị: chỉ cân nhắc Kubernetes khi có nhiều dịch vụ cần chạy đồng thời, cần tự phục hồi, cần mở rộng theo tải hoặc cần một API thống nhất cho đội vận hành. Nếu chỉ có vài ứng dụng nhỏ chạy trên một hoặc hai máy chủ, các lựa chọn đơn giản hơn thường đủ.
Khi vài chục dịch vụ không còn quản lý được bằng tay
Chạy một ứng dụng trên một máy chủ là việc đơn giản. Vấn đề bắt đầu khi có nhiều ứng dụng, nhiều bản sao, nhiều máy và nhu cầu thay phiên bản mà không gián đoạn. Câu mô tả trong README, gồm triển khai, duy trì và mở rộng, chính là ba việc đó. Kubernetes cho phép khai báo trạng thái mong muốn của ứng dụng như đối tượng trong API, rồi để hệ thống kéo thực tế về gần trạng thái đó. [1][6]
Ví dụ trong thư mục client-go minh họa vòng đời cơ bản: tạo một Deployment hai bản sao, cập nhật số bản sao và hình ảnh container, liệt kê, rồi xóa Deployment cùng ReplicaSet phụ thuộc. Điều đáng chú ý là ví dụ cũng nhắc người đọc xem vòng lặp thử lại khi xung đột, vì nhiều bên cùng sửa một đối tượng là tình huống bình thường trong hệ thống này. [6]
Kubernetes không giải quyết thay bạn việc thiết kế ứng dụng, sao lưu dữ liệu nghiệp vụ hay quản lý bí mật. README còn nói rõ việc dùng module k8s.io/kubernetes làm thư viện không được hỗ trợ; muốn viết mã tích hợp phải dùng các thành phần được công bố riêng.
Máy chủ API là chuỗi ba máy chủ, không phải một
Tài liệu kiến trúc của apiserver nhấn mạnh rằng kube-apiserver không phải một máy chủ đơn lẻ mà là chuỗi ba thực thể GenericAPIServer: tầng tổng hợp (aggregator), máy chủ Kubernetes lõi và máy chủ mở rộng API cho CRD. Yêu cầu đi vào tầng tổng hợp trước. Nếu có APIService nhận đường dẫn đó, yêu cầu được chuyển tiếp tới máy chủ mở rộng; nếu không, nó đi tiếp xuống máy chủ lõi, rồi tới máy chủ CRD, và cuối chuỗi trả về 404. [3]
Điều này giải thích vì sao CRD (CustomResourceDefinition, định nghĩa tài nguyên tùy biến) trở thành cách mở rộng phổ biến nhất: tài liệu mô tả khi CRD được tạo, máy chủ mở rộng tự dựng bộ xử lý lưu trữ mới và tài nguyên có hiệu lực ngay, lưu trong etcd mà không cần mã máy chủ riêng. Máy chủ tổng hợp dành cho trường hợp cần logic riêng hoặc kho lưu trữ khác. [3]
Ở phía client, kiến trúc client-go tách việc nạp cấu hình, lớp REST, client có kiểu và client động, sinh mã và hạ tầng controller. Hạ tầng controller thay mô hình truy vấn liên tục bằng mô hình hướng sự kiện có bộ nhớ đệm. Tầng thấp nhất, kubelet, nói chuyện với runtime container qua giao diện CRI dựa trên protocol buffers và gRPC. [4][9]
Phần mô tả scheduler framework plugins trong kho hiện chỉ là con trỏ chuyển tới kho community, nên bài viết không thể kết luận gì về cơ chế lập lịch. [8]
Theo một yêu cầu: từ HTTP, qua bốn cổng kiểm soát, tới bản ghi trong etcd
Mọi yêu cầu vào apiserver đi qua một chuỗi bộ lọc HTTP. Tài liệu nêu rõ thân yêu cầu chưa được giải mã cho tới khi qua xác thực và phân quyền. Thứ tự là: xác thực, phân quyền, Priority and Fairness (phân loại và xếp hàng để tránh quá tải), rồi kiểm soát đầu vào (admission), nơi đối tượng mới được giải mã và có thể bị chỉnh sửa hoặc từ chối trước khi tới bộ xử lý REST. [3]
Xác thực gồm nhiều bộ xác thực nối tiếp như chứng chỉ client, bearer token, OIDC; bộ đầu tiên nhận diện được người dùng quyết định danh tính. Phân quyền cũng là chuỗi các bộ như RBAC, Node, Webhook, mỗi bộ trả về cho phép, từ chối hoặc không ý kiến.
Với yêu cầu đọc, watch cache đóng vai trò đệm. Cacher khởi tạo bằng LIST rồi WATCH từ cùng ResourceVersion, phục vụ phần lớn yêu cầu liệt kê và theo dõi từ bộ nhớ, và chỉ quay về etcd khi bộ đệm không đáp ứng được. Với yêu cầu ghi, client phải gửi resourceVersion của bản đã đọc; nếu khác mod_revision hiện tại trong etcd, máy chủ trả 409 Conflict và client phải đọc lại. [3]
Server-Side Apply là hướng khai báo thay thế: máy chủ ghi managedFields để theo dõi bên nào sở hữu trường nào, cho phép nhiều controller cùng quản lý một đối tượng mà không ghi đè nhau. Ngoài ra, exec, attach và port-forward dùng websocket để nâng cấp kết nối HTTP. [3][4]
Những khả năng được tài liệu xác nhận
Về API, tài liệu apiserver xác nhận các điểm sau: chuỗi ba máy chủ cho API lõi, mở rộng và tổng hợp; CRD cho phép định nghĩa tài nguyên mới theo lược đồ; điểm cuối khám phá và đặc tả OpenAPI v2 và v3 sinh từ mã Go; kiểm toán theo chính sách; cấp và xác thực token cho ServiceAccount, trong đó apiserver đóng vai nhà cung cấp OIDC. [3]
Về controller, client-go mô tả chuỗi Reflector, DeltaFIFO, Indexer, bộ xử lý sự kiện và hàng đợi công việc. Informer chỉ đưa khóa đối tượng vào hàng đợi, nên controller có thể thử lại với backoff lũy tiến mà không chặn luồng theo dõi. Ví dụ workqueue minh họa cách ghép hàng đợi với bộ nhớ đệm thành controller hoàn chỉnh. [4][7]
Về mạng, kube-proxy có chế độ nftables dùng API nftables của nhân Linux. Tài liệu liệt kê bảy việc nó làm, gồm DNAT từ IP dịch vụ sang IP endpoint, SNAT để gói trả lời quay về đúng nút, chặn theo LoadBalancerSourceRanges, và từ chối gói tới dịch vụ không có endpoint. [11]
Về runtime, CRI là giao diện cắm cho phép kubelet dùng nhiều runtime container mà không phải biên dịch lại. Lịch sử thay đổi trong README của cri-api cho thấy phiên bản v1.36 thêm các RPC dạng stream cho thao tác liệt kê, theo KEP-5825.
Ai thực sự hưởng lợi từ một nền tảng điều phối
Nhóm hưởng lợi rõ nhất là tổ chức chạy nhiều dịch vụ độc lập, có đội vận hành riêng và cần chuẩn hóa cách triển khai. Kubernetes cung cấp một API thống nhất, nên cùng một cách khai báo có thể áp dụng cho nhiều ứng dụng, và công cụ bên ngoài tích hợp qua cùng API đó.
Nhóm thứ hai là đội xây dựng nền tảng nội bộ hoặc công cụ tự động hóa. Họ viết controller, dùng CRD và client-go, nên cần hiểu tài liệu kiến trúc client-go, phiên bản tương thích và mô hình thử lại. Tài liệu nói client-go v0.X.Y tương ứng Kubernetes v1.X.Y, và client cũ nói chuyện được với máy chủ mới hơn nhưng chiều ngược lại không được đảm bảo. [4]
Nhóm không phù hợp là đơn vị nhỏ, ít ứng dụng, không có người trực hệ thống. Họ phải trả chi phí học và vận hành của nền tảng nhưng không dùng đến khả năng mở rộng. Khi đó một dịch vụ Kubernetes do nhà cung cấp quản lý hoặc cách triển khai đơn giản hơn nên được so sánh trước, như phần so sánh sẽ bàn.
Giả định: văn phòng công chứng thử một cụm nhỏ cho hệ thống nội bộ
Đây là tình huống giả định, không phải trường hợp đã xảy ra. Hãy hình dung một văn phòng công chứng tại Thành phố Hồ Chí Minh có khoảng hai mươi nhân sự, chạy vài hệ thống nội bộ: cấp số thứ tự khách, quét và nhận dạng chữ trên hồ sơ, kho lưu bản quét, và cổng đặt lịch hẹn. Văn phòng chưa có đội hạ tầng, và hồ sơ công chứng chứa dữ liệu cá nhân nhạy cảm.
Câu hỏi nghiên cứu: có nên đưa các dịch vụ đó lên Kubernetes không? Câu trả lời sơ bộ của bài là chưa nên làm ngay. Lý do nằm ở chính tài liệu: apiserver, bộ nhớ đệm, controller, mạng và runtime đều là thành phần cần quản lý, còn quy mô văn phòng chưa chắc cần tự phục hồi hay mở rộng theo tải. Một đề xuất hợp lý là thử trong phòng thí nghiệm trước, với dữ liệu giả, chỉ để xem đội hiện có vận hành nổi hay không. [3][4]
Nếu thử, nên tách hai loại tải. Dịch vụ không trạng thái như cổng đặt lịch và dịch vụ cấp số có thể khai báo bằng Deployment. Kho bản quét và cơ sở dữ liệu hồ sơ nên giữ ngoài cụm hoặc ở dịch vụ lưu trữ có sao lưu riêng, vì Kubernetes không tự giải quyết sao lưu dữ liệu nghiệp vụ.
Về pháp lý, quy định lưu trữ, bảo mật hồ sơ công chứng và vị trí đặt dữ liệu do cơ quan và luật sư của văn phòng xác nhận; bài viết không nêu điều luật nào. Tiêu chí thành công của thử nghiệm không phải là cụm chạy được, mà là so sánh công sức vận hành với phương án đơn giản hơn.
Vận hành: phiên bản, nâng cấp và những nơi kubelet tự lưu trạng thái
SECURITY.md và các tài liệu liên quan chỉ dẫn người dùng tới trang chính sách phiên bản được hỗ trợ trên kubernetes.io. Nghĩa là câu hỏi mỗi phiên bản được vá trong bao lâu không có trả lời trong kho, và đội vận hành phải theo dõi nguồn đó. [5]
Việc nâng cấp liên quan tới hai điểm. Thứ nhất là version skew giữa client và máy chủ: client-go cũ chạy được với máy chủ mới, không chắc ngược lại. Thứ hai là CRI: README nói API này chỉ dành cho tương tác giữa kubelet và runtime, hoặc xử lý sự cố ở mức nút bằng công cụ như crictl, và có chính sách version skew riêng. [4][9]
Về dữ liệu cục bộ, tài liệu checkpoint manager cho biết SIG Node đồng thuận tránh thêm cơ chế checkpoint mới sau khi gặp lỗi khó gỡ trong môi trường sản xuất, dù một số module kubelet như device manager, cpu manager, memory manager, DRA vẫn dùng. Với người vận hành, điều này nhắc rằng nút chứa trạng thái cục bộ; thay đổi định dạng được coi là không tương thích. [10]
Một chỉ dẫn thực tế từ tài liệu nftables: thành phần khác không được sửa bảng của kube-proxy, mà nên tạo bảng riêng và đặt priority để chạy trước hoặc sau.
Bảo mật: các lớp kiểm soát có sẵn và những gì kho không hứa
Điểm mạnh về thiết kế là bảo mật nằm trong chuỗi xử lý: xác thực và phân quyền diễn ra trước khi giải mã thân yêu cầu, kiểm soát đầu vào áp chính sách tiếp đó, và kiểm toán ghi sự kiện theo chính sách. Tài liệu nêu Pod Security admission áp Pod Security Standards ở cấp không gian tên, và mTLS là cơ chế xác thực chính cho thành phần hệ thống. [3]
Priority and Fairness phân loại yêu cầu để tránh quá tải; phía client có QPS và Burst, và khi nhận 429 thì chờ theo Retry-After rồi thử lại.
Về báo lỗ hổng, SECURITY.md chỉ ghi nơi tìm hướng dẫn báo cáo và chính sách phiên bản trên trang web của dự án, không có quy trình chi tiết trong tệp. Với quyền riêng tư, tài liệu không bàn về mã hóa dữ liệu lưu trong etcd hay quản lý bí mật; đó là các hạng mục bài viết không đánh giá. Triển khai cho dữ liệu nhạy cảm cần đánh giá riêng. [5]
Giấy phép Apache 2.0 và những thứ nằm ngoài văn bản
Tệp LICENSE ở thư mục gốc là văn bản Apache License 2.0, kèm phần phụ lục mẫu chưa điền tên chủ sở hữu bản quyền. Văn bản cấp quyền sao chép, tạo tác phẩm phái sinh và quyền sáng chế theo điều kiện của giấy phép, yêu cầu giữ thông báo khi phân phối lại và nêu rõ không cấp quyền dùng nhãn hiệu. Đây là nội dung của văn bản, không phải tư vấn pháp lý. [2]
README ghi dự án được CNCF lưu trữ. Dữ liệu API GitHub trả về trường giấy phép Apache-2.0, nhưng bài viết dựa vào văn bản LICENSE thay vì chỉ dựa vào trường đó. Danh sách tệp tại commit cho thấy có thư mục LICENSES chứa giấy phép của mã vendor và mã sao chép từ bên thứ ba, điều này nghĩa là không thể suy ra mọi tệp trong cây đều chỉ thuộc một văn bản duy nhất. Bài viết chưa đọc các tệp đó. [1][2]
Phạm vi: giấy phép áp dụng cho mã tại commit này. Nó không bao gồm hình ảnh container do bên thứ ba dựng, bản phân phối thương mại, dịch vụ Kubernetes của nhà cung cấp đám mây, phần mềm tiện ích chạy trên cụm, hay các phụ thuộc có giấy phép riêng. README không nêu CLA hay chính sách nhãn hiệu, nên bài viết không kết luận về những điểm này. [1]
Chi phí: con người là hạng mục lớn nhất
Phần mềm không có phí giấy phép theo văn bản đã đọc, nhưng chi phí thực nằm ở nguồn lực. Các giả định dưới đây dành cho văn phòng giả định và không kèm giá hiện hành, vì bài viết không có nguồn giá.
Loại nguồn lực thứ nhất là nhân sự: ít nhất một người hiểu Linux, mạng, container và Kubernetes đủ sâu để xử lý sự cố, kèm người dự phòng. Tài liệu cho thấy số thành phần phải hiểu khá nhiều: chuỗi máy chủ API, etcd, controller, runtime và kube-proxy. Thời gian học và trực hệ thống thường là chi phí lớn hơn hạ tầng với đơn vị nhỏ, nhưng mức cụ thể phải đo trong thử nghiệm. [3][11]
Loại thứ hai là phần cứng hoặc thuê ngoài: nút điều khiển, nút chạy ứng dụng, lưu trữ có sao lưu, mạng nội bộ, và môi trường thử riêng cho nâng cấp. Loại thứ ba là thời gian định kỳ cho nâng cấp phiên bản, vá lỗi, kiểm tra tương thích client và rà soát phân quyền.
So sánh theo cách tiếp cận: từ một máy chủ tới cụm điều phối
Cách đơn giản nhất là chạy ứng dụng trực tiếp hoặc bằng container trên một vài máy chủ, quản lý bằng tập lệnh hoặc công cụ cấu hình. Ưu điểm là ít thành phần phải hiểu. Nhược điểm là tự phục hồi, cập nhật cuốn chiếu và mở rộng phải tự xây hoặc làm thủ công.
Cách thứ hai là một bộ điều phối nhẹ hơn, như chế độ swarm của Docker hoặc Nomad. Bài không có tài liệu về chúng nên không so sánh chi tiết; đây là hướng cần đánh giá riêng.
Cách thứ ba là dịch vụ Kubernetes do nhà cung cấp quản lý. Phần mặt phẳng điều khiển được vận hành thay bạn, đổi lại bạn phụ thuộc điều khoản và giá của nhà cung cấp. Cách thứ tư là nền tảng ứng dụng đóng gói sẵn che giấu hầu hết chi tiết điều phối, phù hợp với nhóm chỉ muốn đẩy mã lên.
Điểm chung: dùng Kubernetes tự vận hành nên là quyết định có chủ đích, dựa vào nhu cầu như số dịch vụ, yêu cầu phục hồi và đội ngũ, không phải vì nó phổ biến.
Hạn chế và những tình huống nên tránh
Hạn chế đầu tiên là độ phức tạp. Chuỗi máy chủ API, bộ nhớ đệm theo dõi, hạ tầng controller, CRI, kube-proxy và checkpoint kubelet là những lớp riêng, mỗi lớp có chế độ lỗi riêng. Tài liệu checkpoint thậm chí thừa nhận vấn đề khó gỡ lỗi từng xảy ra trong sản xuất và khuyến nghị tránh thêm cơ chế mới. [3][10]
Hạn chế thứ hai là khoảng trống tài liệu trong kho: phần scheduler plugins chỉ là con trỏ, SECURITY.md chỉ trỏ ra trang web, README chỉ dẫn cách dùng sang kubernetes.io. Người đọc phải theo dõi tài liệu ngoài kho cho các quyết định vận hành và bảo mật. [1][5][8]
Hạn chế thứ ba liên quan tới ranh giới sử dụng: module k8s.io/kubernetes không được hỗ trợ làm thư viện, và CRI chỉ dành cho kubelet và runtime, không phải API chung cho container. Không nên dùng Kubernetes khi chưa có người chịu trách nhiệm vận hành, khi chỉ có một hai ứng dụng đơn giản, hoặc khi dữ liệu nhạy cảm cần đánh giá bảo mật mà đơn vị chưa có năng lực thực hiện. [1][9]
Kế hoạch thử nghiệm bốn giai đoạn, dữ liệu giả
Giai đoạn một, hai tuần: dựng cụm thử trong môi trường cô lập, không chứa hồ sơ thật. Dùng hai dịch vụ giả lập cổng đặt lịch và cấp số, triển khai bằng Deployment. Tiêu chí: đội tự dựng lại cụm từ tài liệu mà không nhờ chuyên gia ngoài, và ghi lại số giờ thực tế. [6]
Giai đoạn hai, hai tuần: thử sự cố có chủ đích, như tắt một nút, xóa một Pod, đổi phiên bản ứng dụng. Tiêu chí đo được: thời gian ứng dụng trở lại phục vụ, số bước thủ công cần thiết, và việc đội có đọc đúng nhật ký kiểm toán hay không. Cần bài kiểm thử xung đột cập nhật theo mô hình resourceVersion để hiểu lỗi 409. [3]
Giai đoạn ba, một tuần: thử nâng cấp một phiên bản phụ trong môi trường thử, rồi kiểm tra tương thích công cụ client. Giai đoạn bốn, một tuần: áp Pod Security và phân quyền tối thiểu, rồi kiểm tra rằng tài khoản thường không đọc được không gian tên khác. [3][4]
Tiêu chí dừng: nếu tổng công sức vận hành vượt giới hạn đội đặt trước, hoặc nếu sau thử nghiệm phương án đơn giản hơn đáp ứng cùng yêu cầu phục hồi, nên dừng và ghi quyết định cùng lý do. Ngưỡng cụ thể do văn phòng tự đặt; bài viết không đưa con số.
Kết luận: hiểu Kubernetes trước, rồi mới quyết định dùng
Kubernetes là một hệ thống có kiến trúc rõ: chuỗi máy chủ API, chuỗi bộ lọc kiểm soát yêu cầu, bộ nhớ đệm theo dõi, hạ tầng controller và giao diện runtime. Các tài liệu kiến trúc trong kho cho phép nhìn thấy cả sức mạnh lẫn chi phí vận hành của nó. [3][4][9]
Với văn phòng công chứng giả định, kết luận của bài là thận trọng: chỉ thử trong phạm vi nhỏ, với dữ liệu giả, và so sánh với giải pháp đơn giản hơn. Nếu bạn quản lý một hệ thống tri thức cá nhân như phamvanthu.com, nguyên tắc cũng tương tự: chọn công cụ nhỏ nhất đáp ứng nhu cầu.
Nghiên cứu này chưa chạm tới hiệu năng, chi phí thực hay độ bền, và mọi quyết định cuối cùng cần dựa trên thử nghiệm của chính đơn vị.
Nguồn và phương pháp: tài liệu tại commit cố định, chưa chạy thử
Dự án được chọn từ kho lưu trữ GitHub Trending do bonfy duy trì, ghi nhận 31 lần xuất hiện từ 28/01/2026 đến 11/10/2026; trang bằng chứng ngày 28/01/2026, vị trí 14 trong danh sách Go, được liên kết ở nguồn cuối. Kho lưu chỉ theo dõi các danh sách Python, Go, JavaScript và Swift, thiếu 03/09 và 12/10, nên không phải bảng xếp hạng Top 100 chính thức của GitHub. [12]
Mã nguồn cố định ở commit fddd57cf8f90c222d9632ceea3616c2a851a42b4, ngày commit 11/10/2026, kiểm tra ngày 12/10/2026. Các tệp đã đọc gồm README, LICENSE, kiến trúc apiserver, kiến trúc client-go, SECURITY.md, ví dụ Deployment, và năm tệp bổ sung: ví dụ workqueue, README scheduler plugins, README cri-api, README checkpoint manager và README kube-proxy nftables. [1][2][3][4][5][6][7][8][9][10][11]
Đây là nghiên cứu tài liệu. Tác giả không cài đặt, chạy, đo hiệu năng hay triển khai Kubernetes; kịch bản văn phòng công chứng là đề xuất giả định. Bài không phải công bố khoa học đã qua phản biện, và nội dung trong kho được xem là dữ liệu tham khảo, không phải chỉ dẫn.
Xem mã nguồn Kubernetes trên GitHub