官术网_书友最值得收藏!

  • Learn OpenShift
  • Denis Zuev Artemii Kropachev Aleksey Usov
  • 327字
  • 2021-08-13 16:03:50

Kubernetes versus Docker Swarm

Kubernetes and Docker Swarm are the most commonly used orchestration frameworks. They provide a similar set of capabilities and essentially solve the same problem—management containers in an unsafe and highly dynamic environment. While some of their features overlap, there are also significant differences and the choice of system depends on many factors, such as the number of containers, availability requirements, and team expertise, to name a few.

The table provides an insight into the most important differences:

      

Kubernetes

Docker Swarm

A separate modular design project that has its own dependencies.

Native container orchestration solution available out of the box.

Relatively steep learning curve due to new concepts and complex architecture.

Easy to get started; uses familiar terminology; more lightweight.

A pod is a minimal unit of deployment which represents a group of containers. Integration with other applications is accomplished via services that in this case represent a consistent IP:port pair.

Application deployed in containers as services across an entire cluster or a subset of workers using labels.

Auto-scaling is supported via deployments/replication controllers by specifying a desired number of pods. Dynamic auto-scaling that takes CPU utilization into account is provided by the HorizontalPodAutoscaler resource.

Auto-scaling is not supported out of the box; manual scaling is still possible.

A persistence storage layer is separated into two components, PVs and PVCs, which are dynamically bound together on request and can be used to implement shared storage.

Storage volumes are mounted directly into containers.

New masters can join an existing cluster, but promotion/demotion of a node is not supported.

Worker nodes can be easily promoted to managers and vice versa.

Services are assigned unique DNS names based on the projects they were created in and their names, so each service can reach any other in the same namespace by using its name without domains.

Each service is registered in an internal DNS with the name based solely on the name of the service itself.

主站蜘蛛池模板: 临澧县| 含山县| 宁波市| 扬中市| 沾益县| 昆山市| 清新县| 台中市| 阿拉善左旗| 高阳县| 陵川县| 南昌县| 昌宁县| 盐亭县| 石阡县| 宁海县| 宁安市| 茂名市| 平果县| 河池市| 建瓯市| 禹州市| 浮梁县| 互助| 延边| 内江市| 巴彦淖尔市| 洮南市| 井陉县| 搜索| 香河县| 西乡县| 天峨县| 吕梁市| 松桃| 巧家县| 沂水县| 肃宁县| 三明市| 若尔盖县| 龙岩市|