本文目录

1. k8s真的要放弃docker自己做容器么
2. 为什么说docker是一种革命性的技术
3. 项目为什么用docker
4. docker可以用生产环境吗

k8s真的要放弃docker自己做容器么

先说结论，不是

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#changed

kubernetes1.20版本的changelog里面写到

Deprecation

Dockersupportinthekubeletisnowdeprecatedandwillberemovedinafuturerelease.Thekubeletusesamodulecalled"dockershim"whichimplementsCRIsupportforDockerandithasseenmaintenanceissuesintheKubernetescommunity.Weencourageyoutoevaluatemovingtoacontainerruntimethatisafull-fledgedimplementationofCRI(v1alpha1orv1compliant)astheybecomeavailable.(#94624,@dims)[SIGNode]

大意是，Kubelet中的Docker支持已经进入淘汰阶段，将在未来移除。原因是Kubelet中使用dockershim组件为Docker提供了CRI支持，Kubernetes认为维护这个组件是有问题的。建议用户评估并迁移到CRI支持更完善的运行时上。

其中引用了9月提出的PR#94624。其中提出，为了使用Docker，从moby进行了大量移植开发了dockershim嵌入到Kubelet之中。Kubelet和CRI的正确沟通方式是像containerd、cri-o这样。各自使用独自的进程，互相以gRPC进行对接。Docker目前仍然是主流，进行迁移需要广而告之并逐步推进。

通俗的说就是，Kubernetes是通过CRI来对接容器运行时的，而Docker本身是没有实现CRI的，所以Kubernetes内置了一个“为Docker提供CRI支持”的dockershim组件。现在Kubernetes宣布不再维护这个组件了，大概的意思就是：Docker虽然好用，但那是对人来说的，Kubernetes又不是人，不需要那些花里胡哨的东西！

Kubernetes这是话里有话，说白了就是：我特么以前为了兼容你，我集成在我自己这里，现在我就想自己单纯一点，要么你自己写CRI的接口要么就再见。

目前docker公司还没有回应。

那这个对我们开发、运维有什么影响呢？

目前来看没太大的影响，如果你在生产环境使用kubernetes，那你以后可能要逐渐迁移至containerd、cri-o这样的容器进行时，比如红帽公司开发的podman

为什么说docker是一种革命性的技术

一个非常好的问题，我是工作多年的Web应用架构师，来回答一下这个问题。欢迎关注我，了解更多IT专业知识。

Docker称不上革命性的技术，但可以称得上是一个革命性的解决方案和工具。

Docker基于Linux内核通过操作系统和虚拟容器调用CGroup,Namespace等系统接口完成资源的分配与相互隔离，依赖系统资源运行，使用的技术都是已有的。

Docker出现之前，有现在还在用的VMWare虚拟机，有Ghost，部分解决了服务器安装配置的琐碎工作，但是没有解决运行环境的问题。比如常见的环境不一致的问题：开发环境能运行，测试生产环境有bug？还有就是每次新服务器、新环境搭建时无穷无尽的问题。

那么Docker出现后，整个环境被打包起来，也就是将所有安装配置代码化自动化了，结合资源编排和云服务，可以秒启一个集群化的web服务系统，如果没有容器技术是做不到的。Docker是使用最普遍的容器技术，事实上的容器技术标准。

推荐看一个Docker秒启Web服务的视频：https://www.toutiao.com/i6801418770997838343/

项目为什么用docker

项目为什么要用docker，需要了解docker的优势，结合项目的实际情况来决定是否需要使用docker，千万不能“为了使用而使用”或者“跟风使用docker”。

和传统的虚拟机相比，docker具有所用的资源更少、性能更高、隔离级别更高、安全性方面也更强等特点，让我们看看下面几个场景，估计你会有更深的体会。

01.移植性更强

相信开发人员都会遇到这样的问题：代码在本地跑的好好的，但是一发布到测试环境怎么就有问题了呢？

通常我们的的代码包需要依赖于环境中的很多因素，比如配置文件、依赖库、中间件的配置等等，其中一项有问题可能都会导致我们代码出现问题；对于开发人员来说，最希望的就是我们的代码能够一次创建，在任意地方都能运行。

而使用docker之后，可以实现开发、测试、运维环境的标准化，镜像文件直接做为交付物，避免了因为环境不同导致的各种问题。

02.更容易扩展

docker容器可以在任意平台运行，不管是物理机还是虚拟机，不管是公有云还是私有云，甚至是个人电脑，所以我们的项目容易做迁移和扩展。

比如我们应用部署了两台机器，当我们想再扩展第三台机器的时候，我们需要先搭建好代码运行所需的环境，尽管虚拟机也有一些快速copy的技术，但是这个过程依然是很慢的，而且有些环境配置还容易出错，而有了docker，只需要构建镜像然后运行即可，非常方便快速。

因为docker快速的构建方式，也让我们的项目可以实现自动且快速的扩容和缩容。

03.更加轻量

在docker出现之前，通常会采用物理机上部署多台虚拟机，每个应用都部署在一个虚拟机中；但是虚拟机非常的重，虚拟机的构建速度通常都是按照分钟计算，占用的资源比较多。

而docker的速度很快，秒级，并且使用的资源更少，性能更高；同样一个物理机器，docker运行的镜像数量远多于虚拟机的数量。

docker的优点这么多，那是不是用了docker之后，我们的交付速度更快了呢？

我见过一个项目，他们号称已经微服务化了，当然他们确实也做到了：把一个项目拆成了数个服务，每个服务在生产环境上部署了多套，算下来就是N*M个应用包（七八十个），都做了容器化...

但是他们依然是人肉运维，也是就是他们每次提测和上线需要手动部署，没有自动化测试和发布；

生产环境发生问题的时候，需要手动去拿日志跟踪问题，开发和运维依然是两个团队，甚至是所属两个不同的部门，沟通的成本很高；

他们虽然实现了容器化，但其实并没有实现快速交付，甚至比传统的方式更慢了。

所以，不要为了docker而docker；如果你们的项目环境配置复杂，每来一个新人配置环境都需要一两天；每次提测和上线，经常问题都是运行环境的问题；开发人员的开发环境不统一；开发能力强，运维能力弱的时候，甚至公司比较穷，想实现资源使用的最大化，都可以考虑使用docker，不过像要做微服务化+容器化，当容器集群规模比较大的时候，还需要工具做容器的自动化管理和编排，自动化测试及部署等等。

docker可以用生产环境吗

可以

docker已经可以用于生产环境，paas平台建设、软件定义数据中心、容器即服务、持续集成和发布这些都是使用场景。docker技术需要和iaas管理平台、开发工具、网络和存储进行集成，国内传统企业对它的认知在不断加深，越来越多的企业开始内部自研尝试容器技术。

好了，文章到这里就结束啦，如果本次分享的docker可以用生产环境吗和生产不建议用docker问题对您有所帮助，还望关注下本站哦！