Kubernetes và Docker – Điểm khác biệt là gì?
Ảo hóa phần cứng mang lại nhiều lợi ích như khả năng mở rộng, bảo mật, cách ly, v.v. thông qua việc sử dụng các trình ảo hóa (hypervisors) để chia sẻ phần cứng vật lý với các máy ảo (VMs). Hiện nay, máy ảo không phải là hình thức ảo hóa duy nhất, bởi vì các container cũng đã trở nên khá phổ biến. Trong khi các máy ảo chia sẻ phần cứng vật lý của các máy chủ cơ sở, các container lại chia sẻ nhân (kernel) của hệ điều hành cơ sở. Container không phải là các máy ảo nhẹ, mà là các gói thực thi được tiêu chuẩn hóa dùng để triển khai ứng dụng, bao gồm cả các ứng dụng được phát triển dựa trên kiến trúc phần mềm microservice, và chứa tất cả các thành phần cần thiết để chạy ứng dụng.
Docker Engine là nền tảng phổ biến nhất để chạy container. Kubernetes là thuật ngữ bạn có thể nghe thấy ngày càng nhiều trong lĩnh vực container hóa và điện toán đám mây. Nhưng cái nào tốt hơn – Docker hay Kubernetes? Đây là chủ đề tranh luận phổ biến, nhưng cách đặt câu hỏi như vậy về mặt kỹ thuật là không chính xác. Ví dụ, bạn không thể hỏi: “Cái nào tốt hơn – nóng hay lạnh?”
Docker là gì?
Docker là một ứng dụng nguồn mở độc lập hoạt động như một engine dùng để chạy các ứng dụng container. Nó được cài đặt trên hệ điều hành (OS) của bạn, tốt nhất là trên Linux, nhưng cũng có thể cài đặt trên Windows và macOS, vốn chạy trên máy vật lý hoặc máy ảo.
Một ứng dụng chạy trong container được cách ly khỏi phần còn lại của hệ thống và các container khác, nhưng tạo cảm giác như đang chạy trên một bản sao riêng của hệ điều hành. Nhiều container Docker có thể chạy đồng thời trên một hệ điều hành duy nhất; bạn có thể quản lý các container đó bằng Docker, và Docker có thể chạy mà không cần Kubernetes. Nếu bạn có nhiều máy chủ để chạy container, việc quản lý thủ công có thể khó khăn, và thường tốt hơn là chọn một công cụ quản lý tập trung hoặc giải pháp điều phối.
Docker Compose là một công cụ điều phối container cơ bản được sử dụng để chạy các ứng dụng Docker đa container. Bạn có thể cấu hình một tệp cấu hình Docker Compose định dạng YAML (yml) để định nghĩa các ứng dụng đa container thay vì phải cấu hình thủ công các tệp Dockerfile riêng biệt cho từng container. Sau khi cấu hình tệp YAML duy nhất này, bạn có thể chạy tất cả các container cần thiết chỉ với một lệnh duy nhất trên giao diện dòng lệnh Linux. Sử dụng Docker Compose là một cách để điều phối các container Docker của bạn, nhưng hiện có một giải pháp thay thế mạnh mẽ cho Docker Compose, đó là Kubernetes.
Kubernetes là gì?
Kubernetes là một giải pháp điều phối container mã nguồn mở được sử dụng để quản lý phần mềm và dịch vụ được đóng gói trong container với mức độ tự động hóa cao.
Kubernetes là một dự án của Google nhằm tự động hóa việc triển khai, mở rộng quy mô và đảm bảo tính sẵn sàng của các ứng dụng chạy trong container. Bạn có thể tăng số lượng máy chủ chạy container lên đến 11 máy chủ hoặc hơn. Hơn nữa, bạn có thể tạo một cụm container Docker bằng Kubernetes để đảm bảo tính sẵn sàng cao và cân bằng tải.
Các máy chủ được sử dụng trong cụm được gọi là node. Kiến trúc của Kubernetes là chủ-nô lệ – cụm bao gồm các node chủ và node làm việc. Số lượng node tối thiểu được khuyến nghị cho Kubernetes là bốn. Mặc dù bạn có thể xây dựng một cụm với một máy, nhưng để chạy tất cả các ví dụ và bài kiểm tra, bạn cần ít nhất bốn nút. Một cụm Kubernetes xử lý lưu lượng sản xuất nên có ít nhất ba nút làm việc. Sử dụng hai nút chủ giúp bảo vệ cụm của bạn khỏi sự cố của một nút chủ. Bạn có thể sử dụng nhiều hơn hai nút chủ nếu cần thiết.
Master nodesđược sử dụng để quản lý trạng thái của cụm, bao gồm việc chấp nhận yêu cầu từ khách hàng, lên lịch các hoạt động với container, chạy các vòng lặp điều khiển, v.v. Một bản sao của cơ sở dữ liệu etcd và cơ sở dữ liệu lưu trữ tất cả dữ liệu của cụm cần được chạy trên mỗi nút chủ. Nút chủ chạy bộ ba quy trình: kube-apiserver , kube-controller-manager và kube-scheduler .Working nodesđược sử dụng để thực thi các tác vụ ứng dụng bằng cách chạy các container. Hai quy trình Kubernetes chạy trên nút không phải là nút chủ: kubelet (để giao tiếp với các nút chủ) và kube-proxy (để phản ánh các dịch vụ mạng Kubernetes trên mỗi nút).Replication Controllerlà thành phần được sử dụng để đảm bảo rằng các bản sao Pod có số lượng được chỉ định luôn chạy tại bất kỳ thời điểm nào. Do đó, bạn có thể đảm bảo rằng các Pod luôn sẵn sàng bất cứ khi nào bạn cần.
Các CLI và API khác nhau được sử dụng để các dịch vụ giao tiếp với nhau nếu sử dụng Kubernetes. Ngoài ra, còn có các thuật ngữ cụ thể được sử dụng để đặt tên cho các đối tượng và tài nguyên của API RESTful, là các thành phần của cụm được xây dựng bằng Kubernetes.Podlà đơn vị lập lịch cơ bản trong Kubernetes. Đây là một nhóm tài nguyên trong đó nhiều container có thể hoạt động. Các container thuộc cùng một Pod có thể chạy trên cùng một máy chủ, sử dụng chung các tài nguyên và cùng một mạng cục bộ. Các container trong Pod được cách ly nhưng có thể giao tiếp với nhau một cách dễ dàng. Do đó, Pod thường được sử dụng trong Kubernetes, nhưng nếu bạn sử dụng ứng dụng Docker độc lập, chỉ có các nhóm container (container pools) là có sẵn. Nhóm container (Service) là tập hợp các container hoạt động cùng nhau để cung cấp, ví dụ như, chức năng của một ứng dụng nhiều tầng. Kubernetes hỗ trợ đặt tên động và cân bằng tải cho Pods thông qua các khái niệm trừu tượng. Phương pháp này đảm bảo kết nối minh bạch giữa các dịch vụ thông qua tên, đồng thời cho phép theo dõi trạng thái hiện tại của chúng.Labelslà các cặp khóa/giá trị được liên kết với Pods và các đối tượng hoặc dịch vụ khác, đồng thời cho phép nhóm chúng một cách dễ dàng và giao nhiệm vụ.Namespaceslà phương pháp cho phép chia tách logic cụm Kubernetes thống nhất thành nhiều cụm ảo. Mỗi cụm ảo có thể tồn tại trong một môi trường ảo bị giới hạn bởi các giới hạn (quotas) mà không ảnh hưởng đến các cụm ảo khác.
Kubernetes có thể được sử dụng với Docker, tuy nhiên Docker không phải là nền tảng container duy nhất mà Kubernetes có thể tương thích. Kubernetes cũng có thể hoạt động cùng với các container Windows, container Linux, rkt, v.v. K8s là tên gọi tắt của Kubernetes thường xuất hiện trong tài liệu kỹ thuật.
Kubernetes so với Docker: So sánh mạng
Hãy xem xét các tùy chọn mạng cho từng giải pháp.
Docker cung cấp ba chế độ mạng cho giao tiếp giữa các container.
Bridge. Chế độ này được sử dụng mặc định, tạo ra một cầu nối ảo lớp 3. Tên mạng trên máy chủ của bạn là docker0 cho mạng này. Docker tự động tạo một cầu nối mạng lớp 3 và cấu hình các quy tắc che giấu địa chỉ cho giao diện mạng bên ngoài, sử dụng nguyên tắc dịch địa chỉ mạng (NAT), cho phép các container giao tiếp với nhau và kết nối với các mạng bên ngoài. Bạn có thể cấu hình chuyển tiếp cổng (port forwarding) cho giao diện mạng của máy chủ nếu muốn kết nối với một container từ các máy chủ khác và mạng bên ngoài. Do đó, khi kết nối với cổng tương ứng trên máy chủ, bạn sẽ được chuyển tiếp đến cổng cần thiết của container Docker. Bạn có thể tạo nhiều hơn một giao diện mạng cho một container Docker nếu cần thiết. Chế độ kết nối trực tiếp (
Host). Trong chế độ này, trình điều khiển mạng của máy chủ đảm bảo rằng container không bị cách ly khỏi máy chủ Docker. Container sử dụng chung hệ thống mạng của máy chủ, và tên máy chủ của container trùng với tên máy chủ của hệ điều hành máy chủ. Nếu bạn chạy một container đang lắng nghe cổng TCP 8080, ứng dụng trong container sẽ có thể truy cập được qua cổng TCP 8080 của địa chỉ IP máy chủ. Trình điều khiển mạng máy chủ chỉ khả dụng cho các máy Linux.
None. Không có địa chỉ IP nào được cấu hình cho giao diện mạng của một container cụ thể, ngoại trừ địa chỉ 127.0.0.1 cho giao diện loopback. Không có quyền truy cập vào các mạng bên ngoài nếu chế độ mạng None được thiết lập.
Multi-host networking for Docker containers. Nếu các container đang chạy trên các máy chủ khác nhau, chúng có thể giao tiếp với nhau sau khi bạn cấu hình mạng overlay. Một dịch vụ lưu trữ khóa-giá trị hợp lệ ( Consul , Etcd , hoặc ZooKeeper ) phải được cấu hình để tạo các mạng này.
Kubernetes. Nếu bạn sử dụng các container Docker độc lập, mỗi container có thể được coi là một đơn vị cơ bản giao tiếp qua mạng bằng cách sử dụng giao diện mạng phù hợp. Nếu bạn sử dụng Kubernetes, Pods là các đơn vị cơ bản của cụm container. Mỗi pod có địa chỉ IP riêng và bao gồm ít nhất một container. Một Pod có thể bao gồm nhiều container được sử dụng cho các tác vụ liên quan. Các container trong cùng một Pod không thể mở cùng một cổng cùng lúc. Loại hạn chế này được áp dụng vì một Pod bao gồm nhiều container vẫn chỉ có một địa chỉ IP duy nhất.
Hơn nữa, Kubernetes tạo ra một container tạm dừng đặc biệt cho mỗi Pod. Container đặc biệt này được thiết kế để cung cấp giao diện mạng (cho giao tiếp nội bộ và ngoại vi) cho các container khác, và thường ở trạng thái tạm dừng (chế độ ngủ). Các container tạm dừng này sẽ thức dậy khi Kubernetes gửi tín hiệu “SIGTERM”.
Flannel thường được sử dụng làm cơ sở hạ tầng mạng để kết nối các container trong Kubernetes bằng cách áp dụng nguyên lý mạng overlay. Mạng overlay cho phép bạn chạy các container bằng cách giao tiếp qua mạng logic giữa các máy chủ vật lý khác nhau trong cụm (được gọi là các node). Kho lưu trữ khóa/giá trị mã nguồn mở etcd được sử dụng để lưu các bản đồ giữa các địa chỉ IP thực được gán cho các container bởi các máy chủ mà các container đang chạy, và các địa chỉ IP trong mạng overlay.
Mạng Kubernetes có thể được tích hợp với VMware NSX-T bằng cách sử dụng Plugin Container NSX. Tích hợp này cho phép bạn sử dụng cấu trúc mạng đa người dùng (multi-tenant) – tính năng không có sẵn ngay từ đầu trong Kubernetes.
Mô hình mạng của Kubernetes cung cấp các tính năng sau:
- Tất cả các container có thể giao tiếp với bất kỳ container nào khác trong cụm mà không cần NAT.
- Tất cả các nút trong cụm có thể giao tiếp với tất cả các container trong cụm mà không cần NAT. Ngược lại, tất cả các container cũng có thể giao tiếp với tất cả các nút trong cụm.
- Các container nhìn thấy địa chỉ IP của chính mình và các địa chỉ IP đó cũng được các thành phần khác của Kubernetes nhìn thấy.
Ingress là một đối tượng API của Kubernetes được sử dụng để quản lý quyền truy cập vào các dịch vụ trong cụm từ bên ngoài (chủ yếu là HTTP và HTTPS). Bạn có thể cấu hình Ingress để thực hiện truy cập từ bên ngoài vào các dịch vụ được container hóa, cho cân bằng tải, kết thúc SSL và hosting ảo dựa trên tên. Một bộ điều khiển Ingress phải được triển khai trên nút master để các quy tắc Ingress hoạt động.
Các trường hợp sử dụng
Sử dụng Docker như một phần mềm độc lập là tốt cho việc phát triển ứng dụng, vì các nhà phát triển có thể chạy ứng dụng của họ trong môi trường cách ly. Hơn nữa, các nhà kiểm thử cũng có thể sử dụng Docker để chạy ứng dụng trong môi trường sandbox. Nếu bạn muốn sử dụng Docker để chạy một số lượng lớn container trong môi trường sản xuất, bạn có thể gặp phải một số vấn đề phức tạp. Ví dụ, một số container có thể dễ dàng bị quá tải hoặc gặp sự cố. Bạn có thể khởi động lại container thủ công trên máy chủ tương ứng, nhưng việc quản lý thủ công có thể tốn rất nhiều thời gian và công sức quý báu của bạn.
Kubernetes cho phép bạn giải quyết những vấn đề này bằng cách cung cấp các tính năng quan trọng như tính sẵn sàng cao, cân bằng tải, công cụ điều phối container, v.v. Do đó, Kubernetes là lựa chọn phù hợp nhất cho các môi trường sản xuất có tải cao với số lượng lớn container Docker. Việc triển khai Kubernetes phức tạp hơn so với việc cài đặt một ứng dụng Docker độc lập, đó là lý do tại sao Kubernetes không phải lúc nào cũng được sử dụng cho phát triển và kiểm thử.
Kubernetes so với Docker Swarm
Docker Swarm là công cụ tạo cụm gốc cho Docker, có thể biến một nhóm máy chủ Docker thành một máy chủ ảo duy nhất. Docker Swarm được tích hợp hoàn toàn với Docker Engine và cho phép bạn sử dụng các API tiêu chuẩn và quy trình mạng; nó được thiết kế để triển khai, quản lý và mở rộng quy mô các container Docker.
Swarm là một cụm các máy chủ Docker được gọi là các nút (nodes). Trước khi so sánh việc triển khai cụm giữa Kubernetes và Docker Swarm, hãy xem xét các thành phần chính sau đây của một cụm khi bạn sử dụng Docker Swarm:
Manager nodes được sử dụng để thực hiện điều phối, quản lý cụm và phân phối tác vụ.
Worker nodes được sử dụng để chạy các container có tác vụ được giao bởi các nút Quản lý. Mỗi nút có thể được cấu hình làm nút Quản lý, nút Lao động hoặc cả hai để thực hiện cả chức năng của nút Quản lý và nút Lao động. Lưu ý rằng các nút Worker chạy các dịch vụ Swarm.
Services. Một dịch vụ trong Docker Swarm định nghĩa trạng thái tối ưu cần thiết cho mỗi dịch vụ được container hóa. Dịch vụ kiểm soát các thông số như số lượng bản sao, tài nguyên mạng có sẵn cho nó, các cổng phải được mở từ mạng bên ngoài, v.v. Cấu hình dịch vụ, chẳng hạn như cấu hình mạng, có thể được điều chỉnh và áp dụng cho container mà không cần khởi động lại dịch vụ cùng container một cách thủ công.
Tasks. Một tác vụ là một vị trí mà tại đó một container duy nhất đang chạy. Các tác vụ là các thành phần của một dịch vụ Swarm.
Do đó, Docker Swarm và Kubernetes là hai nền tảng khác nhau được sử dụng cho các mục đích tương tự. Bây giờ là lúc so sánh chúng trong một bộ danh mục phù hợp.
Triển khai cụm
Docker Swarm. Giao diện API Docker tiêu chuẩn cho phép bạn triển khai cụm với Swarm bằng cách sử dụng giao diện dòng lệnh Docker tiêu chuẩn (CLI), giúp việc triển khai dễ dàng hơn, đặc biệt khi sử dụng lần đầu. Sự dễ dàng trong việc triển khai Swarm so với Kubernetes cũng được đạt được nhờ khả năng của một máy chủ Docker duy nhất quyết định cách phân phối dịch vụ. Không có Pod nào được sử dụng trong Docker Swarm.
Kubernetes yêu cầu bạn sử dụng các lệnh cụ thể khác với các lệnh Docker tiêu chuẩn. Các API cụ thể được sử dụng trong Kubernetes, có nghĩa là ngay cả khi bạn biết các lệnh quản lý Docker, bạn cũng có thể cần phải học cách sử dụng một bộ công cụ bổ sung để triển khai Kubernetes. Các nút phải được định nghĩa thủ công trong cụm Kubernetes – bạn cần chọn nút chủ, định nghĩa bộ điều khiển, bộ lập lịch, v.v.
Khả năng mở rộng
Docker Swarm. Nhờ API đơn giản do Docker cung cấp, việc triển khai container và cập nhật dịch vụ trong các cụm lớn và nhỏ có thể được thực hiện nhanh hơn. Giao diện dòng lệnh (CLI) khá đơn giản và dễ hiểu. Do đó, Swarm có thể được coi là giải pháp có khả năng mở rộng hơn so với Kubernetes. Kubernetes cung cấp các API tương đối thống nhất, cùng với một số tính năng thường dẫn đến quá trình triển khai chậm hơn. Có ba loại thành phần cần được cấu hình: Pod, Deploy và Service. Khi nói đến tính năng tự động điều chỉnh quy mô, Kubernetes được ưa chuộng hơn nhờ khả năng phân tích tải máy chủ, đồng thời cho phép tự động mở rộng hoặc thu hẹp quy mô theo các yêu cầu cụ thể. Kubernetes là lựa chọn tối ưu cho các mạng phân tán quy mô lớn và các hệ thống phức tạp.
Khả năng sẵn sàng cao
Cả hai giải pháp đều có cơ chế sao chép dịch vụ và dự phòng tương tự, và trong cả hai trường hợp, hệ thống tự điều chỉnh mà không cần cấu hình lại thủ công sau khi một nút bị lỗi quay trở lại cụm.
Docker Swarm. Các nút quản lý (Manager nodes) quản lý tài nguyên của các nút làm việc (worker nodes) và toàn bộ cụm. Các nút trong cụm Swarm tham gia vào việc sao chép dịch vụ.
Kubernetes. Các nút không khỏe mạnh được phát hiện bởi dịch vụ cân bằng tải của Kubernetes và bị loại khỏi cụm. Tất cả các Pod được phân phối giữa các nút, từ đó đảm bảo tính sẵn sàng cao, ngay cả khi một nút đang chạy ứng dụng container bị lỗi.
Cân bằng tải
Docker Swarm. Cân bằng tải là tính năng tích hợp sẵn và có thể được thực hiện tự động bằng cách sử dụng mạng nội bộ Swarm. Tất cả các yêu cầu đến cụm đều được phân phối và chuyển hướng đến các nút trong cụm; bất kỳ nút nào cũng có thể kết nối với bất kỳ container nào. Một thành phần DNS được Docker Swarm sử dụng để phân phối các yêu cầu đến các tên dịch vụ.
Kubernetes. Các chính sách được định nghĩa trong Pods được sử dụng cho cân bằng tải trong Kubernetes. Trong trường hợp này, các Pod container phải được định nghĩa là dịch vụ. Bạn phải cấu hình cài đặt cân bằng tải thủ công, trong khi Ingress có thể được sử dụng cho cân bằng tải.
Tạo và chạy container
Docker Swarm. Hầu hết các lệnh có sẵn cho Docker CLI đều có thể được sử dụng khi sử dụng Docker Swarm, nhờ vào API tiêu chuẩn của Docker Swarm. Docker Compose định nghĩa việc làm việc với các khối lượng (volumes) và mạng được sử dụng, ngoài việc xác định các container nào phải được nhóm lại với nhau. Số lượng bản sao chính xác có thể được thiết lập bằng Docker Compose cho Docker Swarm.
Kubernetes. Kubernetes có API và client riêng, đồng thời yêu cầu các tệp YAML để cấu hình. Đây là một trong những điểm khác biệt chính, vì Docker Compose và Docker CLI không thể được sử dụng để triển khai container trong trường hợp này. Trong Kubernetes, hệ thống định nghĩa dịch vụ tuân theo nguyên lý hoạt động tương tự như Docker Compose, nhưng phức tạp hơn. Các chức năng của Docker Compose được thực hiện thông qua việc sử dụng Pods, Deployments và Services trong Kubernetes, trong đó mỗi thành phần được sử dụng cho mục đích cụ thể của riêng mình. Pods chịu trách nhiệm về tương tác giữa các container, trong khi Deployments đảm bảo tính sẵn sàng cao và mạng cho một node duy nhất trong cụm (giống như Docker Compose cho ứng dụng Docker độc lập không sử dụng Swarm), và các dịch vụ Kubernetes chịu trách nhiệm về cấu hình hoạt động của dịch vụ bên trong cụm, khả năng chịu lỗi, v.v.
Mạng
Docker Swarm. Có một mạng nội bộ mặc định để giao tiếp giữa các container trong cụm, và có thể thêm các mạng khác nếu cần thiết. Các mạng được bảo vệ bằng các chứng chỉ TLS được tạo tự động. Việc tạo chứng chỉ thủ công được hỗ trợ để mã hóa lưu lượng dữ liệu của container.
Kubernetes. Mô hình mạng của Kubernetes khá khác biệt và được triển khai thông qua các plugin, trong đó Flannel là tùy chọn phổ biến nhất. Các pod tương tác với nhau, và sự tương tác này có thể bị giới hạn bởi các chính sách. Có một mạng nội bộ được quản lý bởi dịch vụ etcd. Mã hóa TLS cũng có sẵn, nhưng cần được cấu hình thủ công. Mô hình mạng Kubernetes giả định việc cấu hình hai CIDR (Classless Inter-Domain Routing), còn được gọi là supernetting.
Giám sát
Docker Swarm. Không có công cụ tích hợp sẵn cho giám sát và ghi nhật ký, mặc dù bạn có thể thiết lập thủ công các công cụ giám sát của bên thứ ba. ELK hoặc Reimann có thể được sử dụng cho mục đích này.
Kubernetes. Kubernetes cung cấp các công cụ tích hợp sẵn cho ghi nhật ký và giám sát. Elasticsearch và Kibana (ELK) có thể được sử dụng để giám sát trạng thái toàn bộ cụm, trong khi Heapster, Grafana và Influx được hỗ trợ để giám sát các dịch vụ container.
Giao diện người dùng đồ họa (GUI)
Docker Swarm. Giao diện người dùng đồ họa (GUI) có thể được kích hoạt bằng các công cụ của bên thứ ba như Portainer.io, cung cấp giao diện web thân thiện với người dùng. Ngoài ra, bạn có thể sử dụng Phiên bản Doanh nghiệp của Docker, cung cấp giao diện đồ họa để quản lý cụm.
Kubernetes. Giao diện người dùng đồ họa (GUI) do Kubernetes cung cấp là một bảng điều khiển đáng tin cậy, có thể truy cập qua giao diện web, giúp bạn dễ dàng kiểm soát cụm của mình. Giao diện người dùng đồ họa (GUI) có thể là một công cụ vô cùng hữu ích cho những người dùng có ít kinh nghiệm trong việc quản lý Kubernetes bằng CLI.
Kết luận
Docker Swarm là một giải pháp gốc của Docker, chủ yếu sử dụng API và CLI của Docker. Ngược lại, Kubernetes là dự án của Google được sử dụng để triển khai một cụm máy chủ nơi các container chạy.
Cả Docker Swarm và Kubernetes đều cung cấp các tính năng như tính sẵn sàng cao, cân bằng tải, mạng overlay và khả năng mở rộng. Docker Swarm là giải pháp dễ triển khai hơn trong hai giải pháp này, vì hầu hết cấu hình tính năng của nó được tự động hóa và tiêu tốn ít tài nguyên phần cứng. Tuy nhiên, chức năng bị giới hạn bởi API Docker và thiếu các công cụ giám sát gốc.
Trong khi đó, Kubernetes là một giải pháp mô-đun với mức độ linh hoạt cao, đã được phần lớn các tập đoàn lớn hỗ trợ trong nhiều năm. Các công cụ tích hợp để giám sát dịch vụ và toàn bộ cụm đều có sẵn cho Kubernetes, mặc dù việc triển khai và cấu hình khó khăn hơn, khiến giải pháp này đòi hỏi nhiều nguồn lực hơn. Kubernetes không tương thích với Docker CLI và Docker Compose. Việc sử dụng Kubernetes được ưu tiên trong các môi trường quy mô lớn nơi các ứng dụng đa container có tải cao đang chạy.
