在“《从零开始学容器》12.使用Docker Swarm编排容器”使用Docker Swarm编排了容器,并且实现了多副本容器的部署,那么为什么还要使用Kubernetes这种庞大的部署编排工具?
为什么需要容器编排平台
正是有了容器,开发者可实现开发环境与部署环境一致,选择自己喜欢的开发框架和语言进行开发并通过微服务的方式组合起来等。但是,正是不断的小容器划分,导致容器也逐渐变多和变得越来越复杂,不得不考虑容器的调度、部署、多个容器之间访问等等问题。
所以,一个容器编排平台需要什么能力才能较好的解决这些问题
能力 | 描述 |
---|---|
调度 | 自动化生成容器实例 |
亲和/反亲和 | 生成的容器可以相邻或相隔,帮助提高可用性和性能 |
健康检查 | 自动检测容器的健康状态 |
容错 | 自动在健康的节点上重新生成容器实例 |
可扩展 | 自动根据需要增加或删除容器实例 |
网络 | 允许容器之间互相通信 |
服务发现 | 允许容器之间互相发现 |
滚动升级 | 对容器进行滚动升级,避免影响业务 |
如表所示,首先容器调度平台可以自动生成容器实例,然后是生成的容器可以相邻或者相隔,帮助提高可用性和性能,还有健康检查、容错、可扩展、网络等功能,它几乎完美地解决了需求与资源的匹配编排问题。
Kubernetest的特性
名称 | 描述 |
---|---|
服务发现和负载均衡 | Kubernetes 可以通过 DNS 名称或 IP 地址暴露容器的访问方式。并且可以在同组容器内分发负载以实现负载均衡 |
存储编排 | Kubernetes可以自动挂载指定的存储系统,例如 local stroage/nfs/云存储等 |
自动发布和回滚 | 可以在 Kubernetes 中声明您期望应用程序容器应该达到的状态,Kubernetes将以合适的速率调整容器的实际状态,并逐步达到最终期望的结果 |
自愈 | 重启已经停机的容器、替换、kill 那些不满足自定义健康检查条件的容器、在容器就绪之前,避免调用者发现该容器 |
密钥及配置管理 | Kubernetes可以存储和管理敏感信息(例如,密码、OAuth token、ssh密钥等) |
Kubernetest边界
名称 | 描述 |
---|---|
不限制应用程序的类型 | Kubernetes的目标是广泛支持不同类型的工作负载,包括:有状态、无状态、数据处理等类型的应用。只要应用可以在容器中运行,就能够非常好地在 Kubernetes 上运行 |
不部署源码、不编译或构建应用程序 | 持续集成、分发、部署(CI/CD)的工作流极大程度上取决于组织的文化、偏好以及技术要求。Kubernetes可以作为部署平台参与到 CI/CD 流程,但是不涉及镜像构建和分发的过程 |
不提供应用程序级别的服务 | 如: 中间件(例如,消息总线)、数据处理框架(例如,Spark)、数据库(例如,mysql)、缓存(例如,Redis),或者分布式存储(例如,Ceph)。此类组件可以在 Kubernetes 上运行,或者可以被运行在 Kubernetes 上的应用程序访问 |
不限定日志、监控、报警的解决方案 | Kubernetes 提供一些样例展示如何与日志、监控、报警等组件集成,同时提供收集、导出监控度量(metrics)的一套机制。您可以根据自己的需要选择日志、监控、报警组件 |
不提供或者限定配置语言 | Kubernetes提供一组声明式的 API,您可以按照自己的方式定义部署信息。 |
不提供或限定任何机器的配置、维护、管理或自愈的系统。 | |
Kubernetes不是一个纯粹意义上的容器编排系统 | Kubernetes构建了一系列相互独立、可预排的控制过程,以持续不断地将系统从当前状态调整到声明的目标状态 |
Docker Swarm与Kubernetes区别
能力\平台 | Swarm | K8s |
---|---|---|
调度 | 支持 | 支持 |
亲和/反亲和 | 支持 | 支持 |
健康检查 | 支持 | 支持 |
容错 | 支持 | 支持 |
可扩展 | 可通过命令改变scale | 支持改变副本数量与基于Horizontal Pod Autoscaler实现自动扩容 |
网络 | 支持 | 支持 |
服务发现 | 支持 | 支持 |
滚动升级 | 支持 | 支持 |
安装简易度 | 简单 | 复杂 |
学习成本 | 简单 | 复杂 |
Docker Swarm与Kubernetes快速摘要
Docker Swarm | Kubernetes | |
---|---|---|
开发者 | Docker 公司 | 谷歌 |
发布年份 | 2013 | 2014 |
公司使用 | Bugsnag,Bluestem Brands,Hammerhead,Code Picnic,Dial once等。 | Asana,Buffer,CircleCI,Evernote,Harvest,Intel,Starbucks,Shopify等 |
Controller | Manager | Master |
Storage | Volumes | Persistent and Epherma |
兼容性 | 不那么广泛和可定制 | 更广泛和高度可定制 |
安装 | 易于设置 | 需要时间安装 |
容差率 | 低容错性 | 高容错性 |
大集群 | 对于强集群状态考虑速度 | 在不考虑速度的情况下,即使在大型集群中也提供容器部署和扩展 |
负载均衡(Loading Balancing) | 当容器中的pod定义为服务时,提供负载平衡 | 通过集群中的任何节点提供自动的内部负载平衡 |
部署单位 | Task | Pod |
Port | Published Port | Endpoint |
社区 | 活跃的用户群,定期更新各种应用程序的映像 | 获得开源社区和谷歌,亚马逊,微软和IBM等大公司的大力支持 |
弱点 | 没有供应商的认证计划。 | 大多数组织需要商业认证版本 倾向于开发人员而不是中央IT |
优势 | 主要由可以决定产品方向的单一供应商控制 | 明确的市场领导者 最高的采用率 |
Slave | Worker | Nodes |
容器设置 | 功能由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。此外,选择正确的项目是一项非常全面的任务,完全取决于您的项目需求和目标受众。