容器在打包和保存所有应用程序代码、依赖项、库和必要配置方面非常出色，您可以轻松地在任何地方运行它。但问题是容器本身不能做这样的事情：负载平衡、配置主机、跨多个服务器分发容器、扩展和缩小集群等。因此容器化平台的概念出现了。
1.谷歌Kubernetes：
Kubernetes 是 Google 的开源、可移植和可扩展的容器编排系统，用于管理和处理容器化工作负载，促进声明式配置和自动化。 Kubernetes 于 2014 年作为 Google 的一个开源项目出现。 Kubernetes 考虑了 Google 在大规模运行生产负载方面超过 15 年的经验，以及来自社区的最佳创意和实践。
2. Docker Swarm ：
Docker Swarm 是一组物理/虚拟机，用于运行 Docker 应用程序，并已配置为连接在一起形成集群的观点。 Docker Swarm 是 Docker 的原生集群工具，自 1.12 版以来一直是核心的一部分。它允许您管理和组织 Docker 节点集群，并允许您像单个系统一样与它们交互。它通过安排容器在 aptest 主机上运行，平衡工作负载以确保在有足够资源的地方加载/启动容器，从而为您的 IT 资源提供优化。所有这些都是在保持您定义的性能标准的同时完成的。
Kubernetes 和 Swarm Docker 之间的差异：
| S.No. | Kubernetes | Docker Swarm |
|---|---|---|
| 1. | It was developed by Google in 2014. | It was developed by Docker, Inc. in 2013. |
| 2. | Installation of Kubernetes requires a series of manual steps and configurations to tie together its components such as etcd, flannel and docker engine. | Docker installation is easy as any application which is available on package manager system on OS you are using. Docker just accounts for one-liner command on Linux platforms like Debian, Ubuntu and CentOS for it’s installation. |
| 3. | It uses its own unique client, API and YAML definitions each differing from that of standard Docker equivalents. | Swarm API provides much of familiar/known functionalities from Docker, but functionalities provided are limited and so it does not fully encompass all of it’s constituting commands. |
| 4. | Its complexity stems offer a unified set of APIs and facilitate strong guarantees to cluster states but at expense of speed, due to which, container deployment and scaling is slower. | On other hand, provides faster container deployment even in very large clusters and due to this high cluster fill stages support faster reaction times to scaling on demand. |
| 5. | It enables/facilitates load balancing through manual service configuration, ie. containers pods need to be defined as services for load balancing. | It provides built-in/automated internal load balancing through connections between any node and container in cluster. |
| 6. | It handles updates progressively. Each container is updated one by one(one at a time) to make sure availability of service is at all times. If something goes wrong during updation, a working version will be rolled back automatically. | In the case of Docker, it can apply updates to nodes incrementally. If anything goes wrong, you can easily roll back to previous working version of service. |
| 7. | It volumes serves as an abstraction to allow containers (volumes) to be created and removed together with pod they are enclosed in. Containers share data within the same pod. | Its data volumes are basically created separately or together with containers, so that they can be shared between multiple containers. |
| 8. | It supports multiple types of logging/monitoring services like Elasticsearch/Kibana (ELK) logs within container, Heapster/Grafana/Influx, Sysdig cloud integration and Node health. | It mainly supports monitoring services with third-party tools such as Reimann. |
| 9. | It mainly uses flannel to setup it’s container networking. TLS authentication requires manual configuration for security purposes. | It facilitates multi-host ingress network overlay for container networking, running on all cluster nodes. TLS authentication is automatically configured. |
| 10. | It relies on etcd and containers that are manually defined as services for discovery. A DNS server is a strongly recommended add-on to watch Kubernetes API. | It makes service discovery relatively easier. By default, containers are given their own unique IPs, which allows them to communicate through virtual private IP addresses in cluster-specific ingress network. |
| 11. | It supports a more complex, flexible architecture with stronger service guarantees due to which performance slows down. | On other hand, supports a simpler architecture, so in terms of sheer speed, it always has an added advantage. |