k8s为啥不建议用docker了？
Kubernetes社区不再建议使用Docker作为容器运行时的主要原因是Containerd已经足够成熟，可以承担其职责。
当ContainerRuntimeInterface(CRI)最初在Kubernetes中提出时，有人建议在Docker中实现它，但这并不遵循纯粹的容器运行时原则，因为Docker还额外包含非低级功能。
凭借早期的认可和快速的发展，Docker在2015年左右开始扩展其功能。
它不仅提供容器引擎服务，还推出了DockerCompose和DockerSwarm，分别用于单机和集群编排。
然而，Google推出的Kubernetes在2015年赢得了与DockerSwarm和ApacheMesos的编排战争，确立了Kubernetes在集群容器编排方面的主导地位，而Docker则回归了容器工具的角色。
因此，Kubernetes和Containerd的结合现在让Docker承诺为Kubernetes提供现代容器运行时，并且社区认为这种分离更加清晰和高效。
因此，Kubernetes不再建议使用Docker作为容器运行时，而是建议直接使用Containerd来管理Kubernetes集群中容器的生命周期。
听说docker被kubenetes抛弃了,怎么办?
在IT行业，关于Docker和Kubernetes关系的讨论非常火爆。首先我们要澄清一个关键点：Docker并没有被Kubernetes彻底抛弃。
在Kubernetes1.20版本中发布的公告中，不推荐使用Docker作为容器运行时。
从1.22版本开始，Kubernetes完全删除了对Docker的支持。
这背后的主要原因是Kubernetes致力于标准化容器运行时接口（CRI），而Docker并没有直接实现CRI。
对于开发者来说，这并不意味着天塌下来了。
Docker作为开发和测试工具的功能不受影响。
大多数开发者使用Docker进行本地开发，最终将应用部署到Kubernetes集群上，因此通常对实际应用没有直接影响。
对于运营和DevOps团队来说，更改容器的挑战相对较高，需要将集群从Docker迁移到支持CRI的运行时，例如Container或CRI-O。
幸运的是，Docker本身已经采用了容器作为其原生运行时，使得转换过程相对容易。
为了应对这种变化，第一步是安装容器。
通过Linux发行版的包管理器（例如APT或YUM）可以轻松完成安装。
接下来，配置容器，然后更改kubelet配置，以确保Kubernetes集群运行时进行切换。
重启kubelet使配置生效此时集群已经从docker迁移到容器了。
为了帮助读者更好地理解和实践Kubernetes，下面的免费实践专栏是一个有用的指南，涵盖了CICD自动化构建和部署简介：01.K8S实用：CICD简介和ECS服务商业计划02、K8S实践：采购阿里云ECS实例03、K8S练习：ci04、K8S练习：k8s集群环境搭建05、K8S实践：k8s应用部署演示06、K8S实践：部署部署对象07.K8S实践：Service服务介绍及使用08.K8S实践：简介及入口行及转发09.K8S实践：k8s列索引10.K8S实践：灰度发射介绍及应用十一、K8S实践：滚动发射介绍及应用12.K8S实践：引入服务诊断13.K8S
k8s启用docker后的使用
K8s1.24版本弃用了docker-shim，并简化了kubelet集成，使其与其他容器解决方案兼容。底层使用Containerd，优化了调用链，提升了K8s性能。
如果想继续在K8s上使用docker，则需要安装cri-docker适配器，这会导致性能下降。
替代方案是crictl、ctr和nerdctl。
crictl专门用于调试K8s集群，对其他容器没有影响。
ctr是容器化原生工具，不使用容器化加速器。
nerdctl是一个容器子项目客户端，它使用加速器配置来加速镜像下载，并匹配docker命令语法。
下载nerdctl，请访问github.com/containerd/nerdctl，它提供了简化的完整版安装包。
nerdctl并不是简单地复制docker功能，还实现了惰性池和图像加密（imgcrypt）等功能。
Containerd使用StargzSnapshotter进行延迟抓取，按需获取镜像文件。
当您使用nerdctl启动容器服务时，服务器会创建一个虚拟网卡。
容器网络防火墙规则优先于服务器设置。
即使打开防火墙，您也无法完全控制端口访问。
您可以使用类似Docker的主机网络模式（--net=host），但不支持端口映射。
nerdctl的安装步骤如下：支持通过下载并解压安装包、标记和推送镜像、安装构建套件来构建镜像。
buildkit可以在github.com/moby/buildkit找到，您可以在其中下载systemd启动文件配置。
Buildkit需要两个配置文件：/usr/lib/systemd/system/buildkit.socket和/usr/lib/systemd/system/buildkit.service。
安装后，如果不指定命名空间（-n），请确保nerdctl不会被crictl和kubelet识别。
镜像构建参数包括-t指定镜像名称，.指定当前目录Dockerfile，-f指定Dockerfile路径，--no-cache指定不使用缓存。
此过程的重点是正确配置启动文件、执行可靠的启动测试以及构建时了解关键参数。
K8s为什么要弃用Docker？
当我们谈到K8s放弃Docker的话题时，我们首先要回到K8s的早期发展，当时他们与Docker合作，共同探索容器化领域。2014年，K8s刚刚诞生，Docker正处于鼎盛时期。
K8开发人员意识到Docker的潜力，并将其作为容器的主要运行时，这在当时看来是明智的选择。
然而，随着K8s的发展和CNCF的加入，它的野心逐渐超出了单一容器运行时环境的范围。
2016年1.5版本，K8s引入了CRI（ContainerRuntimeInterface），标志着与Docker正式分离。
CRI为K8s提供了与Docker解耦的能力，让K8s可以支持其他容器技术，比如rkt、kata等。
尽管Docker在市场上的影响力很强，但K8s在1.24版本中还是实现了“弃用Docker”的目标。
这一转变的关键是引入了CRI和shim，它们作为中间层，保证K8s和Docker运行时之间的平滑过渡。
随后，Docker采取了重建策略，拆分为多个模块，containersd诞生了。
容器作为CNCF托管项目，遵循CRI标准，为K8s提供更加简洁高效的容器管理方法。
在性能测试中，containerd相对于Docker进行了显着改进，例如启动延迟降低了约20%、CPU使用率降低了68%、内存使用率降低了12%，这显着提高了云提供商的兴趣。
2020年，K8s正式宣布kubelet将放弃对Docker的支持，并在未来版本中彻底删除。
这一决定震惊了IT界。
一些人担心现有的Docker投资会被毁掉，大量镜像将无处存放。
然而事实上，K8s只是放弃了Dockershim，并没有完全放弃Docker。
它的底层已经被开源容器取代，原来的Docker镜像和容器仍然可以正常工作。
K8s和Docker的分离对双方的影响有限。
K8s直接在Docker中调用containerd，使得两者无法共享容器和镜像管理。
对于使用kubectl管理K8s的用户来说，这一变化并没有太大影响，但必须适应新的crictl工具来显示容器和镜像。
尽管K8s不再与Docker绑定，但Docker在云原生领域仍然发挥着重要作用。
作为容器技术的缔造者，Docker的镜像格式标准化（OCI规范）使其能够在不改变原有开发测试和CI/CD流程的情况下，在K8环境下保持兼容性。
Docker不仅仅是一个执行引擎，它还提供镜像构建、分发和测试等综合服务，甚至将K8功能集成到DockerDesktop中。
对于初学者来说，Docker因其简单易用、工具链完善、界面友好等特点，成为学习容器技术和云原生技术的最佳选择。
虽然与K8s的联动减少了，但Docker继续通过cri-dockerd项目将CRI接口适配到DockerEngine，允许K8用户实现无缝过渡，就好像什么都没有改变一样。
Docker的未来仍然充满活力。
多年来积累的用户基础和广泛的应用构成了其强大的支撑。
即使在与K8s分道扬镳之后，Docker仍然可以在容器开发领域发挥重要作用，为开发者提供便利。
