运维

Docker编排

Kubernetes vs. Docker Swarm：完整的比较指南 - 腾讯云开发者社区-腾讯云 (tencent.com)

Kubernetes vs. Docker Swarm：完整的比较指南

修改于2018-11-07 17:27:09阅读 23.4K0

在两个长期竞争对手的比较中，我们看看每个应该使用的时间以及它们如何一起工作。

有无数的辩论和讨论谈论Kubernetes和Docker。如果你没有深入研究，你会认为这两种开源技术都在争夺集装箱至上。让我们明确指出，Kubernetes和Docker Swarm不是竞争对手！两者都各有利弊，可根据您的应用要求使用。

在本文中，有关这些问题的更多信息：

• Kubernetes和Docker如何改变软件开发的时代？
• 它如何彻底改变了DevOps咨询的方式？
• 虽然它们不同，但它们如何统一开发和整合的过程？
• 该方案有哪些限制？

如果您希望开发现代云基础架构或寻找DevOps实现，那么必须了解Kubernetes和Docker的完整概念。这篇全面的文章将带您从头开始探讨Kubernetes与Docker Swarm的历程，并将帮助您回答每个重要问题。

容器，集装箱化和集装箱编排 - 快速入门

容器是包含应用程序代码，配置和依赖关系的软件包，可提供运营效率和生产力。在这里，您可以确切地知道它将如何运行，这意味着它是可预测的，可重复的和不可变的。容器的兴起是DevOps即服务的一个巨大推动因素，可以克服当今面临的最大安全障碍。

容器化通过在操作系统级别进行虚拟化来使应用程序可移植，从而创建基于内核的隔离的封装系统。容器化的应用程序可以放在任何地方，无需依赖项运行或需要整个VM，从而消除了依赖关系。

但是如果有多个容器怎么办？

这里需要容器编排！

容器编排是通常可以部署多个容器以通过自动化实现应用程序的过程。像Kubernetes和Docker Swarm这样的平台是容器管理和容器编排引擎，使用户能够指导容器部署并自动执行更新，运行状况监视和故障转移过程。

这一切听起来都很不错，但你如何实际使用工具和构建容器？

让我们从Docker开始吧。

搬运工人

“构建，运送和运行任何应用程序”

Docker是一种容器管理服务，可帮助开发人员设计应用程序，并通过使用容器更轻松地创建，部署和运行应用程序。Docker具有用于群集容器的内置机制，称为“群集模式”。使用群集模式，您可以使用Docker Engine在多台计算机上启动应用程序。

Docker Swarm - 管理Docker容器的工具

Docker Swarm是Docker自己的Docker容器本地集群解决方案，具有与Docker生态系统紧密集成并使用自己的API的优势。它监视跨服务器群集的容器数量，是在没有其他硬件的情况下创建群集docker应用程序的最便捷方式。它为Dockerized应用程序提供了一个小规模但有用的编排系统。

使用Docker Swarm的优点

• 以更快的速度运行：当您使用虚拟环境时，您可能已经意识到它需要很长时间，并且包括启动和启动您要运行的应用程序的繁琐程序。使用Docker Swarm，这不再是一个问题。Docker Swarm消除了启动完整虚拟机的需要，使应用程序能够快速在虚拟和软件定义的环境中运行，并有助于DevOps实施。
• 文档提供了所有信息： Docker团队在文档方面脱颖而出！Docker正在迅速发展，并为整个平台赢得了热烈的掌声。当版本在很短的时间间隔内发布时，某些平台不会维护文档。但是Docker Swarm从未与它妥协。如果该信息仅适用于Docker Swarm的某些版本，则文档会确保更新所有信息。
• 提供简单快速的配置： Docker Swarm的一个主要优点是它简化了问题。Docker Swarm使用户可以自己配置，将其放入代码中并轻松部署。由于Docker Swarm可以在各种环境中使用，因此需求不受应用程序环境的约束。
• 确保应用程序是孤立的：Docker Swarm注意每个容器与其他容器隔离并拥有自己的资源。可以部署各种容器以在不同堆栈中运行单独的应用程序。除此之外，当每个应用程序在自己的容器上运行时，Docker Swarm会清除应用程序删除。如果不再需要该应用程序，则可以删除其容器。它不会在您的主机操作系统上留下任何临时或配置文件。
• 版本控制和组件重用：使用Docker Swarm，您可以跟踪容器的连续版本，检查差异或回滚到先前版本。容器重复使用前面层中的组件，这使得它们显着轻量级。

使用Docker Swarm的缺点

• Docker依赖于平台：Docker Swarm是一个Linux激动人心的平台。虽然Docker支持Windows和Mac OS X，但它利用虚拟机在非Linux平台上运行。设计为在Windows上的Docker容器中运行的应用程序无法在Linux上运行，反之亦然。
• 不提供存储选项：Docker Swarm不提供将容器连接到存储的无障碍方式，这是主要缺点之一。其数据量需要在主机和手动配置上进行大量即兴创作。如果您期望Docker Swarm解决存储问题，可能会以高效且用户友好的方式完成。
• 监控不良：Docker Swarm提供有关容器的基本信息，如果您正在寻找基本的监控解决方案，那么Stats命令就足够了。如果您正在寻找高级监控，那么Docker Swarm永远不是一个选择。虽然有像CAdvisor这样的第三方工具可以提供更多监控，但使用Docker本身实时收集有关容器的更多数据是不可行的。

为了避免这些不足，可以使用Kubernetes

自动化容器部署，扩展和管理平台

当在多台机器上的多个容器中使用不同组件开发应用程序时，需要该工具来管理和协调容器。这只有在Kubernetes的帮助下才可行。

Kubernetes是一个用于管理集群环境中的容器化应用程序的开源系统。以正确的方式使用Kubernetes可帮助DevOps即服务团队自动扩展应用程序并以零停机时间进行更新。

使用Kubernetes的优点

• 它的速度很快：在不停机的情况下持续部署新功能时，Kubernetes是一个完美的选择。Kubernetes的目标是以恒定的正常运行时间更新应用程序。它的速度通过您每小时可以运送的许多功能来衡量，同时保持可用的服务。

• 遵循不可变基础架构的原则：以传统方式，如果多个更新出现任何问题，您就没有任何记录显示您部署了多少更新以及发生了哪个错误。在不可变基础结构中，如果您希望更新任何应用程序，则需要使用新标记构建容器映像并进行部署，从而使用旧映像版本终止旧容器。通过这种方式，您将获得一份记录，并了解您所做的事情以及是否有任何错误; 您可以轻松回滚到上一个图像。

• 提供声明性配置：用户可以知道系统应该处于什么状态以避免错误。作为传统工具的源代码控制，单元测试等不能与命令式配置一起使用，但可以与声明性配置一起使用。

• 大规模部署和更新软件

  ：由于Kubernetes具有不可变的声明性，因此扩展很容易。Kubernetes提供了一些用于扩展目的的有用功能：

  • 水平基础架构缩放：在单个服务器级别执行操作以应用水平缩放。可以毫不费力地添加或分离atest服务器。
  • 自动扩展：根据CPU资源或其他应用程序指标的使用情况，您可以更改正在运行的容器数
  • 手动缩放：您可以通过命令或界面手动缩放正在运行的容器的数量
  • 复制控制器：复制控制器确保群集在运行条件下具有指定数量的等效窗格。如果存在太多pod，则复制控制器可以删除额外的pod，反之亦然。

• 处理应用程序的可用性：Kubernetes检查节点和容器的运行状况，并在由于错误导致的盒中崩溃时提供自我修复和自动替换。此外，它在多个pod之间分配负载，以便在意外流量期间快速平衡资源。

• 存储卷：在Kubernetes中，数据在容器之间共享，但如果pod被杀死，则会自动删除卷。此外，数据是远程存储的，因此如果将pod移动到另一个节点，数据将保留，直到用户删除为止。

使用Kubernetes的缺点

• 初始过程需要时间：创建新进程时，您必须等待应用程序开始，然后才能供用户使用。如果要迁移到Kubernetes，则需要对代码库进行修改，以使启动过程更有效，这样用户就不会有糟糕的体验。
• 迁移到无状态需要付出很多努力：如果您的应用程序是群集或无状态的，则不会配置额外的pod，并且必须在应用程序中重新配置。
• 安装过程繁琐：如果您不使用Azure，Google或Amazon等任何云提供商，则很难在群集上设置Kubernetes。

Kubernetes vs. Docker Swarm：快速摘要

	Docker Swarm	Kubernetes
由开发	Docker公司	谷歌
发布年份	2013	2014
公司使用	Bugsnag，Bluestem Brands，Hammerhead，Code Picnic，Dial once等。	Asana，Buffer，CircleCI，Evernote，Harvest，Intel，Starbucks，Shopify等
调节器	Manager	Master
存储	Volumes	Persistent and Ephermal
公共云服务提供商	Google，Azure，AWS，OTC	Azure
兼容性	不那么广泛和可定制	更广泛和高度可定制
安装	易于设置	需要时间安装
容差率	低容错性	高容错性
大集群	速度被认为是强群集状态	即使在大型集群中也提供容器部署和扩展，而不考虑速度
负载均衡	当容器中的pod定义为服务时提供负载平衡	通过群集中的任何节点提供自动内部负载平衡
部署单位	任务	荚
端口	发布的端口	端点
网络	覆盖	平面网络空间
社区	活跃的用户群，定期更新各种应用程序的图像	获得开源社区和谷歌，亚马逊，微软和IBM等大公司的大力支持
弱点	没有供应商的认证计划。大多数组织需要商业认证版本	倾向于开发人员而不是中央IT
优势	主要由可以决定产品方向的单一供应商控制	明确的市场领导者 最大的采用和兴趣
奴隶	工人	节点
容器设置	功能由Docker API提供并受其限制	客户端API和YAML在Kubernetes中是唯一的
可扩展性	即使在大型容器中也可以快速部署容器	以牺牲速度为代价为群集状态提供强有力的保证

Docker和Kubernetes是不同的，但不是竞争对手

如前所述，Kubernetes和Docker都在不同的级别工作，但两者可以一起使用。Kubernetes可以与Docker引擎集成，以执行Docker容器的调度和执行。由于Docker和Kubernetes都是容器协调器，因此它们都可以帮助管理数字容器并帮助实现DevOps。两者都可以自动执行运行容器化基础架构所涉及的大多数任务，并且是由Apache License 2.0管理的开源软件项目。除此之外，两者都使用YAML格式的文件来管理工具如何编排容器集群。当两者一起使用时，Docker和Kubernetes都是部署现代云架构的最佳工具。随着Docker Swarm的豁免，Kubernetes和Docker都相互补充。

Kubernetes使用Docker作为主要的容器引擎解决方案，Docker最近宣布它可以支持Kubernetes作为其企业版的编排层。除此之外，Docker还批准了经过认证的Kubernetes程序，该程序可确保所有Kubernetes API按预期运行。Kubernetes使用Docker Enterprise的功能，如安全映像管理，其中Docker EE提供图像扫描，以确保容器中使用的映像是否存在问题。另一个是安全自动化，其中组织可以消除低效率，例如扫描图像是否存在漏洞。

Kubernetes或Docker：哪个是完美的选择？

如果使用Kubernetes：

• 您正在寻找成熟的部署和监控选项
• 您正在寻找快速可靠的响应时间
• 您正在寻求开发复杂的应用程序，并且需要高资源计算而不受限制
• 你有一个非常大的集群

如果，使用Docker，

• 您希望在不花费太多时间进行配置和安装的情况下启动工具;
• 您正在寻找开发一个基本和标准的应用程序，它足够使用默认的docker镜像;
• 在不同的操作系统上测试和运行相同的应用程序对您来说不是问题;
• 您需要zdocker API经验和兼容性。

最后的想法：Kubernetes和Docker是朋友

无论您选择Kubernetes还是Docker，两者都被认为是最好的并且具有相当大的差异。决定两者之间的最佳方法可能是考虑哪一个你已经知道更好，哪一个适合你现有的软件堆栈。如果您需要开发复杂的应用程序，请使用Kubernetes，如果您希望开发小型应用程序，请使用Docker Swarm。此外，选择合适的任务是一项非常全面的任务，完全取决于您的项目要求和目标受众。

原文标题《Kubernetes vs. Docker Swarm: A Complete Comparison Guide》

作者：Ankit Kumar

译者：Sonia

不代表云加社区观点，更多详情请查看原文链接

应用部署

容器部署

什么是容器技术？有哪些？与虚拟化技术区别-三个皮匠报告 (sgpjbg.com)

docker部署 无状态 和 有状态应用

有状态（Stateful）应用的容器化 - 腾讯云开发者社区-腾讯云 (tencent.com)

docker

docker 最好只部署无状态应用， 比如你的web服务，或者 api服务，有状态应应用如数据库、消息队列等，不是不可以，但是运维很麻烦，虽然这类应用在 k8s 中用 statefulset 或者 operator 可以实现自动运维， 但目前也只有少数公司在使用，更加不建议直接使用 docker 部署数据库或者中间件

安装前

yum remove docker  docker-common docker-selinux docker-engine

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo（阿里仓库）

yum list docker-ce --showduplicates | sort -r

选择版本
yum -y install docker-ce-18.03.1.ce 
systemctl start docker
开机自启
systemctl enable docker

Docker入门笔记02：docker的版本，你真的搞清楚了吗 - 知乎 (zhihu.com)

命名历程：

docker.io -> docker-engine -> docker -> docker-ce / docker-ee

docker compose

Docker Compose 来轻松高效的管理容器i。定义运行多个容器。

docker config

docker部署

docker-compose.yml 挂载点必须设置

DevOps

• devops是什么

• devops概念提出

• • 单体架构+瀑布模式
  • 分布式架构+敏捷开发模式
  • 微服务架构+DEVOPS

• devops深度理解

• devops实现相关工具

• • devops平台搭建工具

devops是什么

❝ DevOps维基百科定义 DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
❞

这里先给出维基百科的定义，没指望你一下子看懂，先有个概念了解一下。

devops概念提出

单体架构+瀑布模式

以电商系统为例，单体应用架构为 LNMP，这个时候只有 DEV 没有 OPS，DEV 就是全栈，就跟我们上大学玩的 demo 一样，项目开发好，找台服务器安装好环境，把 jar 包 scp 到远程服务器，放上去开启服务就可以。

这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，部署简单，通常开发就可以完成运维的工作，不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可。

分布式架构+敏捷开发模式

随着业务体量发展越来越大，一台机器扛不住，那么就加机器，单机变多机，业务架构也开始加入了 nginx,cdn,缓存等通用基础服务，业务变多肯定会招人，就涉及到多人协同开发，多人多机器模式。

多人协同开发问题:

先说说多人协同开发问题，人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分，有点包干到户的感觉，敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。。另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，QA的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。这样开发产品的可控性也更强，遇到了sb甲方的时候，阶段性的让他检验一下项目成果，防止画鸡成鸭。

多机器问题:

再说说多机器问题，之前机器很少架构简单的时候，开发就可以干运维的活，就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，”我要上线了，大家先别上线哈“，可想而知这样效率也很低下。

公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。但是这个时候也不是 DEVOPS，而是 DEV+OPS，这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。

开发和运维角色的天生对立问题：

加入运维，就要协调人员配合，运维的宿命就是维稳，他们是很讨厌变动的；开发的天职确是不断地推代码上线，进行代码变动，更替迭代，这两个工种天生就是对立的。

很多大公司有那种，开发人员想要上线，需要提交各种审批，层层签字画押，多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。所以，敏捷开发解决了协同开发和多机器部署开发问题，但是没有解决内部人员的矛盾，留着这个矛盾在公司，开发和运维随时都可能约‘生死架’。

微服务架构+DEVOPS

❝ wiki定义微服务: 微服务（英语：Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。
❞

上面是我摘自wiki对微服务的定义，注意几个关键词：软件架构风格，小型功能区块，模块化，语言无关。

第一，公司发展到BAT这种体量，会招很多人，JAVA，PHP，GO 技术栈都会有，需要协调技术栈；第二，项目到后期往往会变得很大，全部都兑到一个项目里，最直接的后果就是项目变得很大，上线项目启动时间变长，一个BUG可能导致整个业务全线崩溃，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构，牵一发而动全身。

所以，拆分解耦是最终的出路，将项目拆成一个个小的服务单独部署，以电商项目为例如图，将整个项目拆分为用户服务，商品服务，订单服务，积分服务……每个服务单独部署，之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’。

拆分部署催生出DEVOPS 再看看这种架构下的开发模式DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。

那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DEVOPS开发模式诞生了，开发也是运维。

devops深度理解

我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：产品规划、开发编码、构建、QA测试、发布、部署和维护。

最初大家说到DEVOPS，都是指的‘开发运维一体化’，如下图:

现在大家说的 DevOps 已经是扩大到“端到端”的概念了，如下图：

DevOps 的三大支柱之中，即人（People）、流程（Process）和平台（Platform）。即

DevOps = 人 + 流程 + 平台

人 + 流程 = 文化

流程 + 平台 = 工具

平台 + 人 = 赋能

devops实现相关工具

人自然不用多说，开发前后中涉及到的所有人，流程前期是产品出原型，UI出设计，然后前后端代码开发，QA测试，最终部署上线，下图是部分流程图：

这里重点来看看devops平台搭建工具，工具很多，组件很多，百家争鸣,这里我列举的大多数是我公司用的，也是大部分公司都在用的。

devops平台搭建工具

项目管理（PM）：jira。运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；

代码管理：gitlab。jenkins或者K8S都可以集成gitlab，进行代码管理，上线，回滚等；

持续集成CI（Continuous Integration）：[gitlab ci](https://www.zhihu.com/search?q=gitlab ci&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={“sourceType”%3A”answer”%2C”sourceId”%3A1755254160})。开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

持续交付CD（Continuous Delivery）：[gitlab cd](https://www.zhihu.com/search?q=gitlab cd&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={“sourceType”%3A”answer”%2C”sourceId”%3A1755254160})。完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

镜像仓库：VMware Harbor，私服nexus。

容器：Docker。

编排：K8S。

服务治理：Consul。

脚本语言：Python。

日志管理：Cat+Sentry，还有种常用的是ELK。

系统监控：Prometheus。

负载均衡：Nginx。

网关：Kong，zuul。

链路追踪：Zipkin。

产品和UI图：蓝湖。

公司内部文档：Confluence。

报警：推送到工作群。

有了这一套完整的流程工具，整个开发流程涉及到人员都可以无阻碍的进行协调工作了，开发每天到公司，先看看jira,看看线上日志，出了问题看看监控日志，运营同学反馈问题不着急的去JIRA，着急的群里吆喝，产品和UI的图直接蓝湖看，运维关注监控着大盘，改革春风开满地，互联网人民真高兴~