Kubernetes là gì? Kiến trúc, cách hoạt động và ứng dụng thực tế

Kubernetes là nền tảng mã nguồn mở dùng để tự động triển khai, mở rộng và quản lý các ứng dụng chạy trong container trên một cụm máy chủ. Nền tảng này giúp duy trì trạng thái mong muốn của ứng dụng, phân bổ workload và hỗ trợ phục hồi khi một số thành phần gặp sự cố. Kubernetes thường được gọi tắt là K8s và được sử dụng rộng rãi trong các hệ thống ứng dụng hiện đại.

Kubernetes là gì?

Kubernetes là nền tảng điều phối container (container orchestration), cho phép quản lý vòng đời của các ứng dụng container trên một hoặc nhiều máy chủ. Thay vì phải thao tác thủ công trên từng máy, người vận hành có thể khai báo trạng thái mong muốn của hệ thống để Kubernetes tự động thực hiện và liên tục đối chiếu trạng thái thực tế với cấu hình đã khai báo.

Kubernetes thường được sử dụng để triển khai ứng dụng, duy trì số lượng bản sao, phân bổ workload, cung cấp cơ chế khám phá dịch vụ và hỗ trợ mở rộng hệ thống. Nền tảng này đặc biệt hữu ích khi ứng dụng được chia thành nhiều dịch vụ hoặc cần vận hành trên nhiều máy chủ.

K8s là viết tắt của gì?

K8s là cách viết tắt của Kubernetes, trong đó chữ K và chữ s là hai ký tự đầu cuối, còn số 8 đại diện cho tám ký tự nằm giữa chúng. Đây là cách rút gọn phổ biến trong tài liệu kỹ thuật, cộng đồng phát triển phần mềm và các công cụ liên quan đến Kubernetes.

Kubernetes có nguồn gốc từ kinh nghiệm phát triển hệ thống điều phối workload Borg của Google. Dự án Kubernetes được công bố mã nguồn mở vào năm 2014 và sau đó được đóng góp cho Cloud Native Computing Foundation (CNCF) vào năm 2016. Tên Kubernetes bắt nguồn từ tiếng Hy Lạp, mang nghĩa người điều khiển hoặc hoa tiêu, phù hợp với vai trò điều phối các container trong hệ thống.

Vì sao cần Kubernetes khi đã có Docker?

Docker giúp đóng gói ứng dụng cùng các thư viện và thành phần phụ thuộc thành container để có thể triển khai nhất quán giữa các môi trường. Tuy nhiên, khi số lượng container và máy chủ tăng lên, việc quản lý toàn bộ hệ thống sẽ phức tạp hơn nhiều so với việc chạy một vài container riêng lẻ.

Chẳng hạn, một ứng dụng thương mại điện tử có thể gồm dịch vụ giao diện, API, xử lý đơn hàng, thanh toán và quản lý dữ liệu. Khi lưu lượng truy cập tăng, đội kỹ thuật có thể cần thêm bản sao của một số dịch vụ, phân phối yêu cầu giữa chúng và thay thế các thành phần gặp lỗi. Nếu thực hiện hoàn toàn thủ công, quá trình này tốn thời gian và dễ phát sinh sai sót.

Kubernetes giải quyết bài toán điều phối bằng cách cung cấp các cơ chế:

• Lập lịch workload: lựa chọn node phù hợp để chạy Pod dựa trên tài nguyên và các ràng buộc đã cấu hình.
• Duy trì trạng thái mong muốn: tạo thêm hoặc thay thế Pod khi số lượng thực tế không khớp với cấu hình.
• Khám phá dịch vụ và phân phối lưu lượng: cung cấp địa chỉ truy cập ổn định thông qua Service và các cơ chế mạng liên quan.
• Mở rộng ứng dụng: tăng hoặc giảm số lượng bản sao khi được cấu hình phù hợp.
• Hỗ trợ triển khai phiên bản: cập nhật ứng dụng theo chiến lược triển khai và cho phép khôi phục phiên bản trước trong những điều kiện phù hợp.

Có thể hình dung Docker như công cụ giúp chuẩn bị và vận hành từng phương tiện, còn Kubernetes giống hệ thống điều phối đội xe, theo dõi tình trạng hoạt động và phân công nhiệm vụ trên toàn đội. Đây chỉ là phép so sánh để dễ hình dung; trên thực tế, Docker cũng có các công cụ quản lý container riêng.

Hai công nghệ không loại trừ nhau. Kubernetes có thể sử dụng các container runtime tương thích với Container Runtime Interface (CRI), chẳng hạn containerd hoặc CRI-O, để chạy container. Vì vậy, Kubernetes không bắt buộc phải sử dụng Docker Engine làm runtime.

Kiến trúc Kubernetes gồm những thành phần nào?

Một hệ thống Kubernetes thường được tổ chức thành cluster, bao gồm Control Plane và một hoặc nhiều node chạy workload. Mỗi thành phần đảm nhiệm một vai trò riêng, phối hợp để triển khai ứng dụng và duy trì trạng thái hoạt động theo cấu hình.

Cluster, Node và Pod

Ba khái niệm nền tảng trong kiến trúc Kubernetes gồm:

• Cluster: toàn bộ cụm Kubernetes, bao gồm các thành phần điều khiển và những node cung cấp tài nguyên chạy ứng dụng.
• Node: máy chủ vật lý hoặc máy ảo tham gia cluster. Node cung cấp CPU, RAM, mạng và các tài nguyên cần thiết để chạy workload.
• Pod: đơn vị triển khai nhỏ nhất mà Kubernetes quản lý trực tiếp. Một Pod có thể chứa một hoặc nhiều container cần chia sẻ tài nguyên mạng và một số tài nguyên lưu trữ theo cấu hình.

Trong phần lớn ứng dụng thông thường, mỗi Pod chứa một container chính. Tuy nhiên, khi các container cần hoạt động sát nhau, chẳng hạn container ứng dụng và container hỗ trợ, chúng có thể được đặt trong cùng một Pod.

Pod có thể được tạo mới hoặc thay thế trong quá trình vận hành. Vì vậy, không nên mặc định rằng một Pod sẽ luôn giữ nguyên danh tính hoặc địa chỉ IP. Các ứng dụng cần giao tiếp ổn định thường sử dụng Service thay vì phụ thuộc trực tiếp vào địa chỉ của từng Pod.

Control Plane gồm những thành phần nào?

Control Plane chịu trách nhiệm điều khiển cluster, tiếp nhận yêu cầu và điều phối trạng thái của các workload. Các thành phần chính gồm:

• API Server: cổng giao tiếp trung tâm của Kubernetes. Các công cụ quản trị và thành phần hệ thống tương tác với cluster thông qua API Server.
• etcd: kho dữ liệu dạng key-value lưu trữ trạng thái và cấu hình quan trọng của cluster.
• Scheduler: lựa chọn node phù hợp cho các Pod chưa được gán node, dựa trên tài nguyên khả dụng, yêu cầu tài nguyên và các ràng buộc lập lịch.
• Controller Manager: chạy các controller để theo dõi và đưa trạng thái thực tế tiến gần đến trạng thái mong muốn, chẳng hạn duy trì số lượng bản sao được khai báo.

Trong môi trường sản xuất, Control Plane cần được bảo vệ và giám sát cẩn thận. Việc sao lưu dữ liệu etcd, kiểm soát quyền truy cập và thiết kế tính sẵn sàng là những yếu tố quan trọng để hạn chế rủi ro khi xảy ra sự cố.

Worker Node gồm những thành phần nào?

Worker Node là nơi các ứng dụng container thực sự được chạy. Những thành phần thường gặp gồm:

• kubelet: tác nhân trên node, tiếp nhận yêu cầu liên quan đến Pod và phối hợp với container runtime để bảo đảm workload được vận hành theo cấu hình.
• Container runtime: chịu trách nhiệm chạy container, chẳng hạn containerd hoặc CRI-O.
• kube-proxy: thành phần thường được sử dụng để thực hiện các chức năng mạng liên quan đến Service. Một số triển khai có thể thay thế chức năng này bằng giải pháp mạng khác.

Ngoài ra, cluster thường cần plugin mạng CNI để thiết lập kết nối mạng cho Pod. Tùy ứng dụng, hệ thống cũng có thể cần plugin lưu trữ để kết nối workload với các loại storage phù hợp.

Deployment, ReplicaSet và Service có vai trò gì?

Bên cạnh các thành phần hạ tầng, Kubernetes cung cấp những đối tượng giúp người vận hành quản lý ứng dụng thuận tiện hơn.

• Deployment cho phép khai báo cách triển khai ứng dụng, phiên bản container và số lượng bản sao mong muốn. Deployment quản lý ReplicaSet, còn ReplicaSet giúp duy trì số lượng Pod theo cấu hình.

Ví dụ, nếu một ứng dụng cần chạy ba bản sao, Deployment có thể khai báo ba replica. Kubernetes sẽ cố gắng duy trì số lượng Pod tương ứng, đồng thời xử lý việc thay thế Pod khi có sự cố trong phạm vi các cơ chế đã cấu hình.

• Service cung cấp một điểm truy cập ổn định cho nhóm Pod được lựa chọn thông qua nhãn. Nhờ đó, ứng dụng không cần theo dõi thủ công địa chỉ IP có thể thay đổi của từng Pod.

Các thành phần này phối hợp với nhau để hình thành quy trình triển khai và vận hành ứng dụng. Có thể minh họa kiến trúc tổng quan như sau:

Người dùng hoặc công cụ quản trị → API Server → Control Plane điều phối → Worker Node → Pod chạy container.

Trong quá trình ứng dụng hoạt động, Service và các thành phần mạng hỗ trợ việc giao tiếp giữa các workload hoặc cung cấp điểm truy cập từ bên ngoài, tùy theo cấu hình triển khai.

Kubernetes hoạt động như thế nào?

Kubernetes vận hành dựa trên mô hình khai báo trạng thái mong muốn. Người vận hành xác định ứng dụng cần chạy như thế nào, còn các thành phần điều khiển liên tục theo dõi và thực hiện những hành động cần thiết để đưa hệ thống về trạng thái đó.

Quy trình cơ bản gồm năm bước:

• Bước 1: Khai báo trạng thái mong muốn: Người vận hành tạo manifest, thường sử dụng định dạng YAML, để mô tả ứng dụng, image container, số lượng bản sao, tài nguyên và các thông số liên quan. Cấu hình được gửi đến Kubernetes thông qua API.
• Bước 2: API Server tiếp nhận và lưu trạng thái: API Server kiểm tra yêu cầu theo các quy tắc và cơ chế kiểm soát được cấu hình. Trạng thái của các đối tượng được lưu trong etcd để các thành phần điều khiển có thể theo dõi.
• Bước 3: Scheduler lựa chọn node: Với các Pod chưa được gán node, Scheduler đánh giá tài nguyên, yêu cầu và những ràng buộc liên quan để chọn vị trí chạy phù hợp. Sau đó, kubelet trên node được giao nhiệm vụ sẽ phối hợp với container runtime để khởi chạy workload.
• Bước 4: Các controller duy trì trạng thái: Kubernetes liên tục đối chiếu trạng thái thực tế với trạng thái mong muốn. Nếu một Pod do Deployment quản lý bị mất và số lượng bản sao thấp hơn cấu hình, hệ thống có thể tạo Pod thay thế. Việc phục hồi phụ thuộc vào loại sự cố, trạng thái node và tài nguyên còn khả dụng.
• Bước 5: Cung cấp kết nối và mở rộng khi cần: Service giúp các thành phần giao tiếp qua một điểm truy cập ổn định. Khi đã cấu hình Horizontal Pod Autoscaler và các chỉ số cần thiết, Kubernetes có thể điều chỉnh số lượng Pod theo tải. Việc mở rộng node có thể cần thêm cơ chế hoặc công cụ riêng.

Cần lưu ý rằng Kubernetes không tự động bảo đảm mọi ứng dụng luôn hoạt động liên tục. Khả năng phục hồi và hạn chế gián đoạn còn phụ thuộc vào số lượng bản sao, phân bố workload, cấu hình kiểm tra tình trạng, tài nguyên, lưu trữ và cách thiết kế ứng dụng.

Lợi ích của Kubernetes đối với doanh nghiệp

Kubernetes mang lại giá trị rõ rệt khi ứng dụng có nhiều thành phần, cần triển khai thường xuyên hoặc phải vận hành trên nhiều máy chủ. Những lợi ích chính bao gồm:

• Tăng khả năng phục hồi ứng dụng: Kubernetes có thể tạo hoặc thay thế Pod khi phát hiện trạng thái không còn phù hợp với cấu hình mong muốn. Điều này giảm một phần thao tác thủ công khi xử lý sự cố, nhưng không thay thế yêu cầu thiết kế dự phòng cho cơ sở dữ liệu, lưu trữ và các dịch vụ phụ thuộc.
• Mở rộng linh hoạt theo nhu cầu: Doanh nghiệp có thể tăng số lượng bản sao của dịch vụ khi tải tăng. Khi được tích hợp với các cơ chế autoscaling phù hợp, hệ thống có thể điều chỉnh tài nguyên theo nhu cầu thay vì phải duy trì mọi workload ở mức cố định.
• Hỗ trợ cập nhật và quay lại phiên bản trước: Deployment hỗ trợ các chiến lược cập nhật như rolling update. Khi phát hiện vấn đề, người vận hành có thể sử dụng cơ chế rollback trong những trường hợp phù hợp. Tuy nhiên, để hạn chế gián đoạn, cần thiết kế readiness probe, cấu hình số lượng bản sao và xử lý tương thích dữ liệu đúng cách.
• Tăng tính nhất quán giữa các môi trường: Ứng dụng được đóng gói thành container và triển khai thông qua cấu hình khai báo giúp giảm khác biệt giữa môi trường phát triển, thử nghiệm và sản xuất. Điều này hỗ trợ quy trình CI/CD và giúp đội kỹ thuật quản lý thay đổi rõ ràng hơn.
• Linh hoạt trong lựa chọn hạ tầng: Kubernetes có thể chạy trên máy chủ vật lý, máy ảo, Cloud Server hoặc các nền tảng Kubernetes được quản lý. Doanh nghiệp có thêm lựa chọn về cách xây dựng và vận hành hệ thống, nhưng mức độ linh hoạt thực tế vẫn phụ thuộc vào cấu hình mạng, lưu trữ và các dịch vụ đi kèm.

Dù vậy, Kubernetes không mặc định giúp doanh nghiệp tiết kiệm chi phí trong mọi trường hợp. Lợi ích về hiệu quả tài nguyên và tự động hóa cần được cân đối với chi phí hạ tầng, nhân sự, giám sát, bảo mật và vận hành cluster.

Hạn chế của Kubernetes và khi nào nên sử dụng?

Những hạn chế cần biết

Kubernetes có nhiều khả năng nhưng cũng đi kèm những yêu cầu vận hành đáng kể.

• Độ phức tạp triển khai cao hơn so với chạy ứng dụng đơn lẻ. Đội kỹ thuật cần hiểu về cluster, Pod, Service, tài nguyên, mạng, lưu trữ và cơ chế phân quyền. Việc cấu hình sai có thể khiến ứng dụng không khởi chạy, khó truy cập hoặc sử dụng tài nguyên kém hiệu quả.
• Chi phí vận hành không chỉ nằm ở máy chủ. Hệ thống còn cần giám sát, ghi log, cập nhật phiên bản, kiểm soát bảo mật, sao lưu và xử lý sự cố. Nếu tự quản lý Control Plane, doanh nghiệp còn phải có phương án bảo vệ và duy trì tính sẵn sàng cho các thành phần điều khiển.
• Không phải ứng dụng nào cũng cần Kubernetes. Một website nhỏ, một API đơn giản hoặc ứng dụng chỉ chạy trên một máy chủ có thể vận hành hiệu quả bằng máy chủ thông thường, Docker Compose hoặc nền tảng quản lý đơn giản hơn. Áp dụng Kubernetes quá sớm có thể làm tăng công sức mà chưa tạo ra giá trị tương xứng.

Khi nào nên dùng Kubernetes, khi nào chưa cần dùng?

Việc lựa chọn nên dựa trên mức độ phức tạp của hệ thống, yêu cầu sẵn sàng, tốc độ thay đổi và năng lực của đội ngũ kỹ thuật, thay vì chỉ dựa vào số lượng người dùng hoặc container.

Hai công nghệ có thể bổ trợ cho nhau trong cùng quy trình phát triển. Đội ngũ có thể dùng Docker để xây dựng image, sau đó triển khai image lên Kubernetes thông qua container registry và cấu hình workload phù hợp. Kubernetes không phải phiên bản thay thế hoàn toàn cho Docker, mà giải quyết bài toán ở một lớp khác của hệ thống.

Cần hạ tầng nào để triển khai Kubernetes?

Kubernetes cần tài nguyên tính toán, kết nối mạng và lưu trữ phù hợp để chạy các thành phần điều khiển cùng ứng dụng. Hạ tầng có thể là máy chủ vật lý, máy ảo, Cloud Server hoặc nền tảng Kubernetes được quản lý. Phương án phù hợp phụ thuộc vào mục đích triển khai, mức độ sẵn sàng mong muốn và khả năng vận hành của đội kỹ thuật.

Tự triển khai cluster trên máy chủ riêng hoặc Cloud Server

Với phương án tự triển khai, doanh nghiệp chủ động lựa chọn hệ điều hành, cấu hình node, mạng, lưu trữ và cách quản trị Kubernetes. Cloud Server là một lựa chọn để cung cấp các máy ảo độc lập, linh hoạt điều chỉnh tài nguyên và thuận tiện bổ sung node khi nhu cầu tăng.

Trước khi triển khai, cần cân nhắc các yếu tố sau:

• CPU và RAM: cần đủ tài nguyên cho các thành phần Kubernetes và workload. Mức yêu cầu thực tế phụ thuộc vào phiên bản, cấu hình cluster và ứng dụng; không nên áp dụng một cấu hình cố định cho mọi hệ thống.
• Mạng: các node cần kết nối được với nhau theo yêu cầu của Kubernetes, đồng thời cấu hình firewall và các cổng cần thiết đúng cách.
• Lưu trữ: dữ liệu cần được đặt trên loại storage phù hợp với yêu cầu về hiệu năng, độ bền và khả năng gắn kết vào workload.
• Tính sẵn sàng: hệ thống sản xuất cần xem xét việc phân bố node, dự phòng Control Plane, cơ chế phục hồi và phương án xử lý khi hạ tầng gặp sự cố.
• Bảo mật và giám sát: cần quản lý quyền truy cập, bảo vệ thông tin xác thực, cập nhật phần mềm, thu thập log và theo dõi tài nguyên.

Đối với môi trường thử nghiệm hoặc học tập, một máy chủ có thể đủ để làm quen với Kubernetes thông qua cluster một node hoặc các công cụ triển khai phù hợp. Tuy nhiên, mô hình một node không mang lại mức dự phòng tương đương cluster nhiều node. Với hệ thống sản xuất, kiến trúc cần được thiết kế theo yêu cầu sẵn sàng thực tế.

Nếu doanh nghiệp cần xây dựng hạ tầng để triển khai Kubernetes, Cloud Server của LANIT có thể là phương án để cân nhắc khi lựa chọn máy ảo cho các node. Bạn có thể tham khảo dịch vụ thuê Cloud Server tại LANIT và trao đổi với đội ngũ kỹ thuật để lựa chọn cấu hình CPU, RAM, lưu trữ và mạng theo workload dự kiến. Việc thuê Cloud Server cung cấp tài nguyên hạ tầng; quá trình cài đặt và vận hành Kubernetes vẫn cần được thực hiện hoặc sử dụng dịch vụ quản lý phù hợp.

Sử dụng dịch vụ Kubernetes được quản lý

Nếu không muốn tự vận hành toàn bộ Control Plane, doanh nghiệp có thể lựa chọn dịch vụ Kubernetes được quản lý từ nhà cung cấp đám mây. Tùy dịch vụ, nhà cung cấp có thể đảm nhiệm một phần công việc như triển khai, nâng cấp và duy trì tính sẵn sàng của Control Plane.

Mô hình này giúp đội kỹ thuật tập trung hơn vào ứng dụng, nhưng không có nghĩa là mọi nhiệm vụ vận hành đều được chuyển giao. Doanh nghiệp vẫn cần quan tâm đến cấu hình workload, quyền truy cập, mạng, lưu trữ, chi phí tài nguyên và bảo mật ứng dụng. Phạm vi trách nhiệm cụ thể phải được xác định theo từng dịch vụ.

Khi lựa chọn giữa tự quản lý cluster và Kubernetes được quản lý, nên so sánh tổng chi phí, mức độ kiểm soát, yêu cầu tuân thủ, năng lực nhân sự và trách nhiệm xử lý sự cố. Không nên chỉ so sánh giá máy chủ mà bỏ qua công sức vận hành lâu dài.

Câu hỏi thường gặp về Kubernetes

Kubernetes có miễn phí không?

Kubernetes là phần mềm mã nguồn mở, có thể sử dụng mà không phải trả phí bản quyền cho phần mềm cốt lõi. Tuy nhiên, doanh nghiệp vẫn cần chi trả cho hạ tầng, lưu trữ, mạng, giám sát và nhân sự vận hành. Nếu sử dụng dịch vụ Kubernetes được quản lý, chi phí còn phụ thuộc vào chính sách giá của nhà cung cấp.

Kubernetes có bắt buộc phải dùng Docker không?

Không. Kubernetes không bắt buộc phải dùng Docker Engine làm container runtime. Nền tảng này giao tiếp với runtime thông qua Container Runtime Interface (CRI), với các lựa chọn phổ biến như containerd và CRI-O. Docker vẫn có thể được sử dụng trong quy trình xây dựng và đóng gói image container.

Có thể chạy Kubernetes trên một máy chủ không?

Có. Người dùng có thể tạo cluster một node để học tập, thử nghiệm hoặc phục vụ một số nhu cầu giới hạn. Tuy nhiên, nếu máy chủ đó gặp sự cố, toàn bộ workload có thể bị ảnh hưởng. Hệ thống sản xuất cần đánh giá yêu cầu sẵn sàng và thiết kế số lượng node phù hợp.

Kubernetes có phù hợp với doanh nghiệp nhỏ không?

Kubernetes có thể phù hợp với doanh nghiệp nhỏ nếu ứng dụng có nhiều dịch vụ, cần tự động hóa triển khai hoặc có kế hoạch mở rộng rõ ràng. Ngược lại, với website hoặc ứng dụng đơn giản, một máy chủ, Docker Compose hay nền tảng PaaS có thể tiết kiệm chi phí và công sức hơn. Quyết định nên dựa trên nhu cầu thực tế thay vì chạy theo công nghệ.

Cần biết gì trước khi học Kubernetes?

Người mới nên nắm các kiến thức cơ bản về Linux, dòng lệnh, mạng máy tính, Docker hoặc khái niệm container, YAML và cách ứng dụng giao tiếp qua mạng. Sau đó, có thể học lần lượt Pod, Deployment, Service, ConfigMap, Secret, volume và các cơ chế quản lý tài nguyên. Thực hành trên cluster thử nghiệm sẽ giúp hiểu rõ hơn cách Kubernetes triển khai và duy trì ứng dụng.

Kết luận

Kubernetes là nền tảng điều phối container giúp tự động hóa triển khai, mở rộng và quản lý ứng dụng trên một cụm máy chủ. Công nghệ này đặc biệt hữu ích với hệ thống có nhiều dịch vụ, nhu cầu triển khai thường xuyên hoặc yêu cầu quản lý workload linh hoạt. Tuy nhiên, Kubernetes cũng đòi hỏi kiến thức kỹ thuật và nguồn lực vận hành tương xứng.

Trước khi lựa chọn, doanh nghiệp nên đánh giá kiến trúc ứng dụng, yêu cầu sẵn sàng, chi phí và năng lực đội ngũ để xác định có thực sự cần Kubernetes hay không. Nếu cần chuẩn bị hạ tầng cho các node Kubernetes, bạn có thể tham khảo Cloud Server của LANIT để tìm hiểu các phương án tài nguyên phù hợp với nhu cầu triển khai.