阅读这篇博客的人，想必大都想弄清楚 Docker 和 Kubernetes 的区别。但有意思的是，简单将两者进行对比，不太合逻辑。尽管两个工具的功能有所不同，但总的来说，Kubernetes 是 Docker 的扩展。功能上，Kubernetes 在应用程序构建、部署和扩展中具有更高的互用性。
从这角度来看，Docker 与最初的容器技术一样，可以帮助稳定应用程序、简化部署流程，因此深得业界追捧。Docker 可跨操作系统运行，这一点更是让 Docker 在开发项目中站稳脚跟。
另一方面，Kubernetes 则有助于部署编排。将 Docker 添加到 Kubernetes 集群的编排活动中，可以实现真实场景所需的高端功能。对比 Kubernetes 和 Docker 在协调和扩展性能，你会发现 Kubernetes 优势明显。也正是得益于协调和扩展的突出性能，Kubernetes 成为同类软件开发的首选基础设施。
Docker 总览
使用 Docker 进行开发，意味着应用程序的整个生产流程已全部包含在部署包中的，这些程序都是标准化、自我服务的。用户可以定义底层操作系统，并为其设计的工作负载设置前提条件。Docker 可在多个操作系统上运行部署包，并高效生产应用程序，这也是其备受欢迎的一个重要原因。
编码基础设施
Dockerfiles 可与代码一起签入，大大提高了基础架构即代码（Infrastructure as Code, IaC）的能力。与此同时，这样，应用程序和创建底层基础架构所需的一切都得到了保护，并且可以像管理其他代码一样随时进行检查。由于指令不仅仅局限于本地开发，类似于“在我机器上运行得好好的！（Works on my machine!）”等兼容问题也减少了。
精明的团队还会在 CI/CD 进程中使用 Dockerfile，帮助动态创建开发和 QA资源。这样，每个发布版本都能有一个新的环境。此外，Docker 也能帮助调节云中的静态资源，为用户控制成本。这种一致性与可控性的结合，也是 Docker 吸引人的又一大因素。
容器“包罗万象”
开发人员因此得以运行容器，同时对本地开发环境施加足够的控制。 在Dockerfile 中明确说明需求，将所有需求都“包含”在最终结果中。然后将这些构建的容器存储，并分发到一个或多个环境中。
Docker 将包含最新更改的新容器分“层”，让自动化构建更为顺畅。其他已存在的层，则按需重复使用，除非特别指示不使用某些容器层。完成的 Docker 容器将发布到容器注册表中，以完成多个环境的部署。
mpleted Docker containers are published to a container registry where they can then be used to complete deployments to multiple environments.
Kubernetes 简介
Kubernetes，也叫做“K8s”，其背后的生产级编排系统技术已被广泛采用。尽管推出时间并不久，但 Kubernetes 的使用率稳步上升。
一项关于 IT 行业使用数据的研究显示，使用 Kubernetes 技术的公司大幅增加。2019 年，87% 的受访者使用 Kubernetes，而两年前只有 55%。
这么多团队选择集成 K8s，原因有很多。
自动部署
Docker 和 Kubernetes 的相似之处，在于两者都可以进行重复和一致的部署。Kubernetes 接受应用程序，全方面部署，最终实现所有需要的服务。使用几种配置，容器化应用程序即可根据设置的数量进行重复部署。这些副本进而借助 Kubernetes 控制平面的许多功能，指示节点如何联机。当实现大规模的编排级别时，这种方法的优势也就凸显出来了。
扩展性能
在 Kubernetes 中运行应用程序可以更好地使用云和混合云资源，这也更有利于控制成本。同样，基于自身内部反馈，调整应用程序，这也是 Kubernetes 的一大优势。这种可扩展性可灵活增加副本程序，提升访问共享卷、配置和安全性。
易于管理
这种环境的 DevOps 不仅仅是部署一个应用程序。Kubernetes 的管理层可以进行非常复杂的部署，并有监控和自我修复等功能帮助实现部署。例如，使用一系列探针，可以指示：
- 确定准备情况——Readiness 探针可在启动前进行检查准备情况，及其他探针状态。
- 验证状态——使用 Liveness 探针，编排系统可以确保容器通过不同类型验证，并处于运行状态。
- 暂停启动——Startup 探针可以为应用程序设置更长的启动时间。防止由于在应用程序启动之前执行 Liveness 探测，而导致应用程序失败。
如何选择 Docker 与 Kubernetes？——因时制宜，因地制宜
哪种解决方案最适合？这主要取决于你的团队在采用每种技术时所处的情形。那些刚刚踏入容器化世界的团队，可能会对 Docker 和 Kubernetes 的利弊感到难以取舍。
如果你的团队敏捷性够强，也有充裕的时间来试错，保持“前沿技术”也是个不错的选择。但对于大多数人来说，一个结构良好、有计划的策略将带来最好的结果。以下是你和团队在决策时需要考虑的几个问题：
- 我们的基础设施是否支持向容器转移？
- 工程师可能需要哪些额外培训？
- 生产部署的目的是什么？
- 服务需要有多大的可扩展性？
- 使用数据中心还是云？
- 我们的选择是否支持用新的工作流程改变 CI/CD 进程?
对比表 – Docker vs Kubernetes
以下是两种工具的简单对比：
| Docker | Kubernetes | |
| 容器支持 | 是 (Containerd) | 是 (Containerd + CRI) |
| 持久化存储 | 是，相对复杂 | 是 |
| 跨平台 | 否，仅限于基础镜像 | 是 |
| 99.99% 正常运行时间 | 否 | 是 |
| 启动复杂性 | 低 | 高 |
| 自动扩展 | 否 | 是 |
| 自我修复 | 否 | 是 |
| 负载均衡 | 否 | 是 |
| 社区 | 是 | 是 |
简单地说，如果你正考虑向容器解决方案转移，Kubernetes 是一种更复杂但更稳定的技术。虽然与 Docker 无法直接对比，但两者互相补充。如果你已经习惯用容器化软件交付，那么采用 Kubernetes 作为编排工具，也能对你的工作大有帮助。
Docker 不会就这样淘汰。那些已经在工作流程上建立了坚实基础的人，将通过Kubernetes 进一步提升性能。许多人发现，K8s 集群与现有的 Docker 技术可以完美配合，提升工作效率。
合作共赢
重申一下，我们应该更多地了解 Kubernetes 是如何扩展 Docker 容器技术的。这不仅仅是比较Docker和Kubernetes。K8s为那些已经使用 Docker 的用户提供了一种无缝过渡到 CRI（容器运行时接口）的方法。
但关键是， Kubernetes 最新版本中的Docker 支持已发生变更，根据 v1.20 发行说明中的声明：
“Kubelet 中的 Docker 功能现在已停用，并将在未来的版本中删除。Kubelet使用了‘dockershim’的模块，该模块实现了对 Docker 的 CRI 支持，但 Kubernetes 社区反馈了一些维护方面的问题。当迁移到容器运行时，我们建议您选择全面执行的 CRI（v1alpha1 或 v1 兼容），并进行适当评估。”
这个 API 是在 Kubernetes 上处理多个操作的运行时，包括启动和停止容器。“dockershim”已停用，所以开发团队需要在新的标准下，利用 Kubernetes 集群开发可靠的应用程序。
这个变更逐渐消除了开发者对内部Docker引擎运行时的依赖，该运行时包含许多已经由 Kubernetes 处理的额外函数。这意味着开发者仍然可以使用 Docker 来构建镜像。但是，管理员和 DevOps 人员可能需要做出调整，才能使用 Kubernetes Containerd 和内部 Docker 版本。
结论
很明显，了解 Docker 与 Kubernetes 的细节，就知道这不仅仅是产品对比那么简单。Kubernetes 扩展了已经广泛流行的 Docker 开发工作流，增强了自动化、稳定性和伸展性能。
任何一个应用程序都可以在本地开发环境中轻松完成。最明智的策略就是花时间评估这两种技术，看看你的工作流程适合什么。由于两者的使用门槛都很低，所以你更应该多考虑使用需求，而不是如何实现。
Incredibuild 和容器
Incredibuild 可充分调用内部网络中的数百个闲置内核，或者通过扩展到公共云中经济高效的计算实例，将容器转换为具有数百个内核的超级容器。这些内核资源可以帮助更快运行构建、测试，以及其他计算密集型进程。点击链接，可免费试用。
