Docker 和 Kubernetes：容器化时代的崛起与演变_kubernetes容器运行时演进(1)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

Docker 的出现，不仅推动了开发和运维（DevOps）文化的发展，而且催生了一系列基于容器的工具和服务。

根据 2021 年的 Sysdig 报告，93% 的容器化实例运行在 Docker 上，这显示了 Docker 在容器运行时的主导地位。

案例研究：

Netflix 是容器化技术的早期采用者，他们使用容器来支持其全球流媒体服务的快速部署和伸缩需求。
Netflix 的经验表明，容器化可以帮助企业在全球范围内快速扩展服务。

Kubernetes 的诞生

Google 有着丰富的容器管理经验，它内部的 Borg 系统可以说是 Kubernetes 的前身。
Borg 系统极大地影响了 Kubernetes 的设计，特别是在大规模集群管理、自动修复和部署方面。

2014 年，Google 发布了 Kubernetes，一个开源的容器编排平台，旨在解决在生产环境中自动部署、扩展和操作容器化应用的问题。
随着 2015 年 Kubernetes 1.0 版本的发布，它很快成为了业界领先的容器编排平台。

Docker 和 Kubernetes 的结合

初期的 Kubernetes 是围绕 Docker 构建的，因为当时 Docker 已经成为了业界容器格式和平台的事实标准。

早期版本的 Kubernetes 直接调用 Docker 作为其容器运行时，依赖 Docker 来创建、启动和停止容器等。
这种深度集成确保了 Kubernetes 能够利用 Docker 提供的强大能力，如镜像管理和容器生命周期管理，同时也使得在 Kubernetes 上部署基于 Docker 的应用变得简单方便。

互补关系：

• Docker 提供了一个方便的容器格式和运行时，而 Kubernetes 提供了容器编排。两者配合，能够提供一个完整的解决方案来管理容器化应用。

转折点：

• Kubernetes 的一个关键转折点是在 1.2 版本引入的 Deployment 对象，它简化了滚动更新和回滚策略的实施。

Kubernetes 的发展和对多运行时的支持

技术转变：

• CRI 的引入使得 Kubernetes 能够支持多种容器运行时，这包括 Docker、containerd、CRI-O 等。

随着 Kubernetes 的不断成熟和社区的迅速壮大，它开始支持更多的容器运行时，不再仅限于 Docker。

这种变化始于 Kubernetes 1.5 版本，其中引入了多个关键特性，增强了系统的可扩展性和灵活性。
Kubernetes 开始支持如 rkt 这样的其他容器运行时，这是通过新增的容器运行时接口（Container Runtime Interface, CRI）实现的。
CRI 定义了一个标准的接口，使得 Kubernetes 可以插拔式地支持不同的容器运行时。

CRI 的引入是一个重要的转折点，因为它标志着 Kubernetes 从一个只支持 Docker 到支持多种容器运行时的过渡。
这个新的架构抽象允许 Kubernetes 不必知道底层容器是如何运行的，而只需要与符合 CRI 的运行时进行交互。
这不仅为 Kubernetes 的未来发展打开了新的可能性，也为整个容器生态系统的多样性铺平了道路。

Kubernetes 引入 CRI 后，持续吸引了更多的贡献者，体现了其不断增长的社区活力，GitHub 上 Kubernetes 相关项目的 Star 数量也在稳步上升，这表明了社区的活跃度和项目的流行度。

Kubernetes 弃用 Docker 的真相

进入 1.20 版本后，Kubernetes 宣布弃用对 Docker 的支持，这引发了广泛的关注和讨论。需要强调的是，Kubernetes 并没有弃用容器本身，而是弃用了 Docker 作为容器运行时的中间层，即 Docker shim。

这一决定背后有多方面的原因，首先是 Docker shim 在设计上存在局限性，它不直接实现 CRI，而是通过另一个适配层与 Kubernetes 通信，这增加了额外的复杂性和维护成本。此外，其他如 containerd 和 CRI-O 这样的容器运行时更为轻量级，更直接地实现了 CRI，它们被视为更适合 Kubernetes 的选择。

Kubernetes 社区对于去除 Docker shim 的反应是复杂的。一方面，这被视为 Kubernetes 向更高效、更标准化的未来迈进的必要步骤；另一方面，也引发了对 Docker 已被“抛弃”误解的担忧。然而，实际上 Docker 依旧是开发者构建和分享容器镜像的首选工具，只是在运行容器的时候，Kubernetes 选择使用其他更适合其架构的运行时。

代码示例：

如果你是 Kubernetes 集群的管理员，您可能需要切换到使用 containerd 作为容器运行时，以下是一个配置 Kubernetes 使用 containerd 的简单示例：

# 以下命令在 Kubernetes 节点上执行
# 安装 containerd
sudo apt-get update
sudo apt-get install -y containerd

# 配置 Kubernetes 使用 containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 重启 containerd
sudo systemctl restart containerd

# 告诉 kubelet 使用 containerd
sudo kubeadm init --cri-socket /run/containerd/containerd.sock

Docker 的挑战与机遇

面对 Kubernetes 的这一决定，Docker 遇到了新的挑战与机遇。

挑战在于，Docker 不再是 Kubernetes 集群中的容器运行时的唯一选择，这可能会影响其在容器运行时市场的地位。
然而，机遇也同样明显，Docker 可以集中精力优化自身的核心优势：作为容器镜像的创建和分发的平台。
通过专注于开发者体验和集成 CI/CD 工具链，Docker 有机会继续在容器化生态系统中扮演关键角色。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取