做外贸常用网站电子商务平台(网站)建设方式

当前位置： 首页 > news >正文

做外贸常用网站,电子商务平台(网站)建设方式,page wordpress,网站建设好后给领导作介绍一段时间以来#xff0c;当人们想到容器时#xff0c;似乎都会想到Docker和Kubernetes。在构建和运行容器方面#xff0c;Docker 一直是大名鼎鼎的品牌#xff0c;而在管理和编排容器方面#xff0c;Kubernetes 一直是大名鼎鼎的品牌。听到 Kubernetes 从 1.20 版开始不再… 一段时间以来当人们想到容器时似乎都会想到Docker和Kubernetes。在构建和运行容器方面Docker 一直是大名鼎鼎的品牌而在管理和编排容器方面Kubernetes 一直是大名鼎鼎的品牌。听到 Kubernetes 从 1.20 版开始不再支持 Docker 作为容器运行时这可能有点令人震惊。 因此我想借此机会谈谈这一变化的真正含义以及 Kubernetes 用户需要做些什么。 一、Docker 有何变化 Kubernetes 弃用 Docker 实际上并不像听起来那么重要所以让我们来谈谈这到底发生了什么。 Kubernetes 正在取消对 Docker 作为容器运行时的支持。Kubernetes 实际上并不处理在机器上运行容器的过程。相反它依赖于另一个称为容器运行时的软件。 容器运行时在主机上运行容器而 Kubernetes 会告诉每个主机上的容器运行时要做什么。在运行 Kubernetes 时您可以选择多种软件作为容器运行时。到目前为止一个相当流行的选择是使用 Docker 作为容器运行时。 然而将来这将不再是一个选项。您仍然可以以与 Kubernetes 相关的其他方式使用 Docker稍后会详细介绍但您将无法将 Docker 用作 Kubernetes 下的容器运行时。 二、Kubernetes 为什么弃用 Docker 两年前 K8s 发布“弃用 Docker”的消息时确实在 K8s 社区引起了“轩然大波”影响甚至蔓延到了社区之外K8s 不得不写好几篇博客来重复解释原因。 两年过去了虽然 K8s 1.24 已经实现了“弃用 Docker”的目标但很多人似乎对这一点还是没有太清晰的认识。所以今天我们就来聊聊这个话题。 到目前为止Kubernetes 已经支持使用 Docker 容器运行时那么为什么他们选择停止支持它呢 1. CRI容器运行时接口   要理解K8s为何“弃用Docker”这个问题我们必须回顾K8s的发展历史。 2014 年Docker 正处于鼎盛时期K8s 刚刚诞生。虽然它得到了 Google 和 Borg 的支持但它仍然比较新没有很大的社区。 因此K8s理所当然地选择运行在Docker上毕竟“大树背荫好”同时也能借机“养精蓄锐”逐步发展壮大自己。 快进到2016年CNCF已经成立一年了K8s也发布了1.0版本可以正式在生产环境使用了这些都标志着K8s已经成长起来了。 于是它宣布加入CNCF成为首个CNCF托管项目想借助基金会的力量联合其他厂商“打倒”Docker。 在2016年底的1.5版本中K8s引入了新的接口标准CRIContainer Runtime Interface。 CRI 使用ProtoBuffer和gPRC来指定应该如何kubelet调用容器运行时来管理容器和镜像但这是一组新的接口与以前的 Docker 调用完全不兼容。 显然它不想再与Docker绑定而允许底层接入其他容器技术例如rkt、kata等并且可以随时“踢掉”Docker。 但此时Docker已经非常成熟而且市场的惯性也非常强各大云厂商不可能一下子把Docker全部替换掉​​。 因此K8s只能同时提供一个“折中”的方案在kubelet和Docker之间增加一个“适配器”将Docker的接口转换成符合CRI的接口 因为这个“适配器”是夹在Linuxkubelet和Docker之间的所以被形象地称为“shim”也就是“垫片”。 有了CRI和shimK8s虽然依然使用Docker作为底层运行但是也具备了与Docker解耦的条件由此拉开了“弃用Docker”大戏的序幕。 2. 容器化 面对挑战Docker采取“断臂求生”的策略推进自身重构将原来单一架构的Docker Engine拆分成多个模块其中Docker daemon部分捐献给CNCFcontainerd成立了Docker daemon基金会。 作为CNCF的托管项目containerd必须遵守CRI标准。但是由于多种原因Docker只是containerd在Docker Engine内进行调用对外接口保持不变也就是说无法兼容CRI。 由于Docker的“固执”导致此时K8s中存在两条调用链 使用CRI接口调用dockershim然后dockershim调用DockerDocker再去containerd操作容器。使用CRI接口直接调用containerd来操作容器。     显然由于containerd用来管理容器这两种调用链最终的效果是完全一样的但是第二种方式省去了dockershim和 Docker Engine 两个环节更加简洁清晰性能也更佳。 2018年Kubernetes 1.10发布时containerd也更新到了1.1版本正式与Kubernetes进行集成并发表了一篇博文https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/展示了一些性能测试数据 从这些数据可以看出相比当时的Docker 18.03containerd1.1降低了Pod启动延迟约20%CPU使用率降低了68%内存使用率降低了12%这是一个相当大的性能提升对于云厂商来说非常有诱惑力。 3. 官方弃用 Docker 两年后也就是2020年K8s 1.20终于正式向Docker“宣战”将kubelet不再支持Docker并且在未来的版本中彻底删除。 但由于 Docker 几乎已经成为容器技术的代名词而且 K8s 多年来也一直在使用 Docker因此该公告在传播过程中很快就“散发出恶臭”“kubelet 将弃用 Docker 支持”被简化为更吸引眼球的“K8s 将弃用 Docker”。 这自然引起了IT界的恐慌“不明真相的群众”纷纷表示震惊用了这么久的Docker突然不能用了。K8s为何如此对待Docker之前对Docker的投资会化为零吗大量的现有镜像该如何处理 其实如果你了解上面提到的两个项目CRI和containerdKubernetes就会知道K8s的这一举动并不令人意外一切都很“自然”它其实只是“弃用dockershim ”也就是搬出dockershim来而已kubelet并不是“弃用Docker”的软件产品。 因此“弃用Docker”对K8s和Docker不会有太大影响因为它们都已经将底层改为开源containerd原有的Docker镜像和容器依然可以正常运行。唯一的变化是K8s绕过了Docker直接containerd在Docker内部调用。 但是会有一些影响如果containerd直接使用 K8s 来操作容器那么它和 Docker 就是一个独立的工作环境双方都无法访问对方管理的容器和镜像也就是说使用命令docker ps是看不到 K8s 中正在运行的容器的。 这对于某些人来说可能需要一点时间来适应和使用新工具crictl但用于查看容器和图像的子命令仍然相同例如psimages等适应起来并不困难但如果我们一直使用 kubectl 来管理 K8s 的话这就没什么影响了。 K8s 原本计划用一年时间完成“淘汰 Docker”的工作但确实低估了 Docker 的基础dockershim在 1.23 版本依然未能淘汰不得不推迟了半年最终在今年 5 月份发布的 1.24 版本才将代码dockershim从kubelet. 从此Kubernetes 与 Docker 彻底“分道扬镳”。 Kubernetes 可与所有实现容器运行时接口 (CRI)标准的容器运行时配合使用。这本质上是 Kubernetes 与容器运行时之间通信的标准方式任何支持此标准的运行时都可以自动与 Kubernetes 配合使用。 Docker 未实现容器运行时接口 (CRI)。过去容器运行时没有太多好的选择而 Kubernetes 实现了 Docker shim这是一个额外的层用作 Kubernetes 和 Docker 之间的接口。然而现在有很多运行时可以实现 CRIKubernetes 不再有必要为 Docker 提供特殊支持。 三、Docker 未来将扮演什么角色 那么Docker 的未来会怎样在云原生时代它是否已经没有立足之地答案显然是否定的。 作为容器技术的鼻祖Docker的历史地位无人可以质疑虽然K8s默认已经不再与Docker绑定但是Docker依然可以以其他形式与K8s共存。 首先因为容器镜像格式已经标准化OCI规范开放容器计划Docker镜像在K8s中还是可以正常使用的原有的开发测试、CI/CD流程不需要改变我们仍然可以pull Docker Hub或者写一个Dockerfile来打包应用。 其次Docker是一个完整的软件产品线不仅如此containerd它还包括镜像构建、分发、测试等诸多服务甚至将K8s内置到了Docker Desktop中。 就容器开发的便捷性而言Docker暂时还难以被取代广大云原生开发者可以继续在这个熟悉的环境中工作使用Docker开发运行在K8s中的应用。 再次虽然 K8s 不再包含dockershim但是 Docker 接管了这部分代码并建立了一个项目叫cri-dockerdhttps://github.com/mirantis/cri-dockerd它的工作原理也是类似的将 Docker Engine 适配成 CRI 接口这样kubelet就又可以通过它来操作 Docker就好像这件事从来没有发生过一样。它在 Kubernetes 生态系统和您的工作流程中仍然发挥着作用。 整体来看Docker 虽然在容器编排大战中落败被 K8s 挤到了墙角但它依然拥有强大的生命力多年积累的众多忠实用户和大量应用镜像是它最大的资本和后盾足以支撑它走上另一条不与 K8s 硬碰硬的道路。 对于初学者来说Docker 简单易用、工具链齐全、界面友好市面上很难找到与之媲美的软件应该说是入门学习容器技术和云原生的“最佳选择”。 Docker 仍然是开发和构建容器镜像以及在本地运行容器镜像的工具。Kubernetes 仍然可以运行使用 Docker 的开放容器计划 (OCI)镜像格式构建的容器这意味着您仍然可以使用 Dockerfile 并使用 Docker 构建容器镜像。 Kubernetes 还将继续能够从 Docker 注册表例如 Docker hub中提取数据。这意味着 Docker 在管理构建好的镜像方面仍将是一个强大的竞争者。 总而言之即使您不需要它在生产中在 Kubernetes 下运行容器Docker 仍将继续成为您开发工作流程和持续集成CI系统中的一个有用工具。