讨论Docker swarm VS k8s

头像
甜豆
121阅读8评论

期待有经验的兄弟们,可以讨论下。
我自己用的最多的是 docker swarm, 没用过K8S,docker swarm管理10几台服务器不在话下,使用起来也简单方便,没遇到过满足不了的需求。

以下内容是我问AI的:

Docker Swarm和Kubernetes(通常简称为K8s)都是用于容器编排和管理的工具,它们具有一些共同的特性,但也有一些重要的区别。下面是对它们进行比较的一些关键方面:

  1. 架构和规模:

    • Docker Swarm:Docker Swarm是Docker官方提供的原生容器编排工具,它使用了Docker原生API,并采用了较为简单的架构。Swarm适用于小型和中型规模的集群,相对于Kubernetes而言,它的学习曲线较为平缓。
    • Kubernetes:Kubernetes是由Google开源的容器编排和管理平台,具有高度可扩展性。Kubernetes的架构相对复杂,它由多个组件组成,如Master节点、Worker节点和ETCD集群。Kubernetes适用于大规模和复杂的应用部署场景。
  2. 社区支持和生态系统:

    • Docker Swarm:虽然Docker Swarm有一定的社区支持,但相对于Kubernetes而言,其生态系统较小。Docker Swarm在一些特定场景下更适合,例如简单的应用部署和容器化的单机环境。
    • Kubernetes:Kubernetes拥有庞大的社区和广泛的生态系统,因为它是当前最受欢迎和广泛采用的容器编排工具之一。有许多第三方工具和插件可以与Kubernetes集成,提供额外的功能和扩展。
  3. 功能和特性:

    • Docker Swarm:Docker Swarm提供了基本的容器编排功能,可以轻松地创建、部署和扩展容器化应用。它的API和命令行工具相对简单易用,适合初学者和小型项目。
    • Kubernetes:Kubernetes提供了更丰富的功能和特性,包括自动扩展、负载均衡、服务发现、存储管理、滚动更新等。Kubernetes还支持声明式配置,可以定义应用的期望状态,由Kubernetes自动管理和维护。
  4. 可用性和容错性:

    • Docker Swarm:Docker Swarm具有较好的可用性和容错性,它可以在各种环境中运行,包括本地环境、云环境和混合环境。Swarm采用Raft一致性算法来保证高可用性。
    • Kubernetes:Kubernetes是为大规模和复杂环境设计的,具有强大的可用性和容错性。Kubernetes支持多个Master节点的高可用部署,使用ETCD来保证集群状态的一致性。

总体来说,Docker Swarm适合简单的应用部署和小规模集群,而Kubernetes适合复杂的应用场景和大规模集群。选择哪种工具取决于你的具体需求、技术经验和团队规模。

讨论话题:
工作&职场
收藏
举报
加载中…
精选评论
头像
等级1

k8s编排能力更强,适用于大规模集群做服务治理。而且swarm官方已经不维护了。

Current versions of Docker include Swarm mode for natively managing a cluster of Docker Engines called a swarm. Use the Docker CLI to create a swarm, deploy application services to a swarm, and manage swarm behavior.

Docker Swarm mode is built into the Docker Engine. Do not confuse Docker Swarm mode with Docker Classic Swarm which is no longer actively developed.

官网复制的,现在swarm功能已经集成到docker引擎里面了,原生支持哈,还是算是维护的。

好久没关注了,我们以前用的是classic swarm,后面都转k8s了。docker公司抛弃了classic swarm转了Docker SwarmKit or Docker Swarm Mode。

头像
等级5

k8s感觉最大的优势是可扩展性,算力不够的时候直接修改yam文件添加相关设备进行扩容,还有镜像版本回滚,这些都比较方便,用传统运维也可以手动操作,能自动,谁也不想手动,另外k8s是真的复杂,光一个service对象,把外部流量引入内部都很复杂,要生产上基本上必须用云厂商的负载均衡,后边在接各种ingress 或者gataway,就一个字,复杂。另外要实现高可用性,k8s需要最少3台服务器,复杂与便捷都是相对的,高可用,高便捷必然复杂,资源消耗多。另外k8s上的一些微服务治理与微服务框架貌似都在争夺管控权,负载均衡,服务注册,可观测性,k8s也都有相关实现,但是我更倾向框架去实现,因为项目初始阶段是不会上k8s的,经常几台服务器搞定,甚至单机跑微服务。

docker swarm我看了眼文档就直接上手用了,学习k8s我看了半天楞是没搞明白那些概念咋回事(确实感觉更复杂一点)。

头像
等级2

对于我的岗位(运维)来说,一九年接触的docker、k8s,当然也学习了swarm,容器化这块的学习成本确实还是很大的,参加工作之后,没有一家公司用过swarm,岗位要求也很少有swarm的,包括已经有很多cncf的项目都是围绕k8s做的周边应用,市场趋势也确实是,作者提到的swarm,单论找工作来说是没有什么竞争力的。
岗位方面,运维目前高薪,甚至低薪是必学k8s的,开发同学就没必要学习太深,最多学习到dockerfile就可以了,应用编排交给运维去出helm或者yaml都可以。
可能作者所在的公司环境确实还用不到k8s,公司环境改革也是有很长路要走的。

感谢您的认真回答,我在猪厂时,公司用的是K8S, 不过我不是容器服务团队的,所以只是把程序部署上去。哈哈

头像
等级1

适合自己的就是对的.

管理小规模的,都是自己说了算,不存在说服,公司只要你的结果,一知半解是大忌.
管理大规模的,不是一个人的事, 系统的光环方便说服大家统一规范很重要,已经使用了最强系统,出问题只证明系统的局限性,不是个人能撑起的.
软件总是在发展的, 总有更好的出来替代老的, 经验只是暂时的, k8s也发展出了k3s呢.