k8s弃用docker（kubernetes和Docker关系简单说明）

本文目录

• kubernetes和Docker关系简单说明
• docker和k8s的关系
• 卸载清理k8s、docker
• Docker核心技术，利用K8S构建、打包和部署Docker容器
• k8s为啥不建议用docker了
• k8s和docker区别是什么
• Docker&k8s（一）
• k8s和docker区别
• 将Kubernetes的Runtime由Docker修改为containerd

kubernetes和Docker关系简单说明

最近项目用到kubernetes（以下简称k8s，k和s之间有8个字母)。虽然之前也有简单使用过，但最近发现k8s概念较多，命令也有些不够用了，故想借此机会写点东西，更全面认识并使用k8s。本篇文章目的：让你更全面了解k8s概念，以及学到在工作中常用的操作。整体更偏向于原理和应用。在正式开始k8s之前，我们先看看k8s和Docker的关系，分别从虚拟化角度、部署方式角度叙述why use容器，话不多说，开干。

目前发现并没有将kubernetes和Docker技术产生背景和需求进行比较的文章，本文从最纯正的官方定义角度出发并展开，阐述二者产生背景及与传统技术对比。

简要介绍：

官方定义1：Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。

官方定义2：k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

与传统技术对比：

接下来我们看两张经典的图：

一、从虚拟化角度：

图1

上图是Docker容器（可用k8s管理的玩意儿）与传统虚拟化方式的不同之处，传统的虚拟技术，在将物理硬件虚拟成多套硬件后，需要再每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。而Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。 每个集群有多个节点，每个节点可，我们的kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

二、从部署角度

图2

注意，大家别把这幅图与上面Docker的那张图混淆了，图1是从虚拟化角度，说明了为应用提供必要的运行环境所需要做的虚拟化操作（即：传统：虚拟出的虚拟机装操作系统、Docker：容器引擎管理下的容器）。

而图2是在这些具体运行环境上进行真实应用部署时的情况，传统方式是将所有应用直接部署在同一个物理机器节点上，这样每个App的依赖都是完全相同的，无法做到App之间隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式来将App部署到其中（就像图1上半部分那样），但这样太过繁重，故比虚拟机更轻便的Docker技术出现，现在我们通过部署Container容器的技术来部署应用，全部Container运行在容器引擎上即可。既然嫌弃虚拟机繁重，想用Docker，那好，你用吧，怎么用呢？手动一个一个创建？当然不，故kubernetes技术便出现了，以kubernetes为代表的容器集群管理系统，这时候就该上场表演了。

说白了，我们用kubernetes去管理Docker集群，即可以将Docker看成Kubernetes内部使用的低级别组件。另外，kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。希望我这篇文章中简单的描述能让你对两者有所理解和认识。

docker和k8s的关系

概念：
官方定义1： Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。
官方定义2： k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

docker一般是和传统的虚拟技术对比
传统的虚拟技术：将物理硬件虚拟成多套硬件后，需要在每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序，非常重。

docker：Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。

K8s:每个集群有多个节点，每个节点可创建多个容器，kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

在一般的认知中，Kubernetes 和 Docker 是互补关系：

Docker 源于 Linux Container，可以将一台机器的资源分成 N 份容器，做到资源的隔离，并将可运行的程序定义为标准的 docker image；Kubernetes 则可以把不同机器的每份容器进行编排、调度，组成分布式系统。

近几年，Kubernetes 已经成为自有机房、云上广泛使用的容器编排方案，最广泛的使用方式是 Kubernetes+Docker。从 DevOps 人员的角度，一面用 kubectl 命令、k8s API 来操作集群，一面在单机用 docker 命令来管理镜像、运行镜像。

单独用 docker 的情况，在一些公司的场景里面也是有的。一种场景是“只分不合”，把一台机器用 docker 做资源隔离，但是不需要将多容器“编排”。

***隐藏网址***
***隐藏网址***
***隐藏网址***
***隐藏网址***

卸载清理k8s、docker

kubeadm reset -f
modprobe -r ipip
l**od
rm -rf ~/.kube/
rm -rf /etc/kubernetes/
rm -rf /etc/systemd/system/kubelet.service.d
rm -rf /etc/systemd/system/kubelet.service
rm -rf /usr/bin/kube*
rm -rf /etc/cni
rm -rf /opt/cni
rm -rf /var/lib/etcd
rm -rf /var/etcd

yum remove docker
docker-client
docker-client-latest
docker-common
docker-latest
docker-latest-logrotate
docker-logrotate
docker-selinux
docker-engine-selinux
docker-engine

rm -rf /etc/systemd/system/docker.service.d
rm -rf /var/lib/docker
rm -rf /var/run/docker

Docker核心技术，利用K8S构建、打包和部署Docker容器

Docker这一容器化技术目前正处于新浪潮的中心，这一浪潮波及了应用的构建、打包和部署。它有可能影响计算机技术的方方面面，从应用程序的开发流程到应用程序如何部署以及跨大规模数据中心进行垂直和水平扩展。

尽管Docker非常流行，但它依然是一个非常新的项目，许多人并没有真正理解什么是Docker。 如果你也是其中一员，那么本书会帮你迈出第一步，并让你见识到容器化所承诺的巨大潜力。我的目标是通过本书引领你进入容器化的世界，这些目标可以概括为.以下几种方式：

随着阅读的深入，读者将看到运行、调查、停止和启动、保存以及管理容器的具体方法。开始创建容器时，我讨论了一些技巧，这些技巧将有助于读者创建高效地构建和运行的容器镜像。我还将带读者逐步研究其他人为了生成自己的容器而创建的构建文件(其被称为Dockerfile)。

对于刚开始使用Docker容器的人来说，本书要从头至尾地阅读。之后，它可以当作参考资料，提示你与Docker容器相关的不同选项和特性。本书内容分成5个部分。

第一部分开启容器之旅

在第一部分中,将学习开始使用Docker容器所需了解的知识。第1章将描述什么是容器，以及容器与非容器化应用的差别。在第2章中，将学习如何在通用Liunx系统( 如Fedora和Ubuntu)以及面向容器的特定Linux系统(如CoreOS和Project Atomic).上安装Docker。在第3章中，我们将展示如何通过配置私有Dockerregistry来保存自己的Docker镜像，以此来完成一个基本的容器设置。

第二部分玩转单个容器

这部分主要涉及通过docker命令直接使用单个容器。第4章中将展示如何运行你的第一个容器镜像。为了帮你查找并获取容器镜像，第5章会描述如何从Docker registry搜索容器镜像，然后拉取想要的镜像，将它保存到文件，并将该镜像加载到其他Docker系统中。

第6章中将学习如何为镜像添加标签，从而更好地识别镜像所包含的内容，并利用这些信息将镜像推送到regstry.第7章中将展示如何探查容器或容器镜像的内部，看一下容器或镜像工作方式的细节。第8章中将学习如何停止、启动和重启容器。第9章中将学习如何通过将宿主机的目录挂载到容器中来配置存储。为了学习如何配置容器的网络，第10章将描述如何配置Docker服务通常使用的默认网络(或不使用网络)，以及运行容器的人为单个容器配置网络接口的方法。

为了可能的重用，Docker缓存了大量数据。第11章将展示如何清理创建或者运行容器镜像时遗留下来的缓存数据。第12章将学习如何构建Docker容器，包括高效构建并运行的容器是如何创建的。

第三部分在云环境 上运行容器

第13章将描述如何运行所谓的超级特权容器( super privileged container, SPC)。为了阐述超级特权容器如何工作，我会展示怎样获取那些可以在RHELAtomic系统上完成不同管理任务的镜像。第14章将描述如何使用Cockpit (基于Web的容器管理工具)在云环境或者本地环境下跨多个宿主机管理容器。

第四部分管理多容器

在这一部分，我们将探究容器的编排。第15章将描述如何在一个系统中使用Kubernates的master和node服务，以便能够尝试Kubernetes。第16章我们将超越一体化Kubernetes系统，描述如何搭建Kubernetes集群。在Kubernetes集群就位后，可以通过master计算机将容器pod中的应用部署到不同的node计算机上进行管理。

第五部分开发容器.

在Docker出现的很短的一-段时间里,能够更加高效地构建容器的技术就已经被开发出来了。第17章将描述一些开发Docker容器的建议和技巧。最后，第18章通过展示我接触的一些Dockerfile文件阐述不同的人是如何克服障碍来构建他们自己的容器的。如果已经准备好了，马上开始阅读第1章吧。希望你喜欢这本书!

最后，需要免费领取这份docker学习文档的朋友，可以帮忙点赞评论一下文章，关注私信【资料】即可免费获取哦！

k8s为啥不建议用docker了

k8s不建议用docker的原因如下：

1、docker比k8s发布的早；

2、Docker 本身不兼容 CRI 接口，官方并没有实现 CRI 的打算，同时也不支持容器的一些新需求，社区想要摆脱Dockershim的高维护成本，。

3、k8s不能直接与docker通信，只能与 CRI 运行时通信，要与 Docker 通信，就必须使用桥接服务(dockershim)，k8s要与docker通信是通过节点代理Kubelet的Dockershim（k8s社区维护的）将请求转发给管理容器的 Docker 服务。

4、Dockershim 一直都是 Kubernetes 为了兼容 Docker 获得市场采取的临时方案（决定）。

5、k8s在过去因为 Docker 的热门而选择它，现在又因为高昂的维护成本而放弃它，我们能够从这个过程中体会到容器领域的发展和进步。

6、对于已经统治市场的k8s来说，Docker 的支持显得非常鸡肋，移除代码也就顺理成章。

7、在集群中运行的容器运行时往往不需要docker这么复杂的功能，k8s需要的只是 CRI 中定义的那些接口。

k8s和docker区别是什么

Kubernetes（k8s）是Google开源的容器集群管理系统（谷歌内部:Borg），它主要用于 容器编排 启动容器、自动化部署、扩展和管理容器应用和回收容器。k8s的目标是让部署容器化的应用简单并且高效，k8s提供了应用部署、规划、更新、维护的一种机制。

用kubernetes去管理Docker集群，既可以将Docker看成Kubernetes内部使用的低级别组件；另外，kubernetes不仅仅支持Docker还支持Rocket，这是另一种容器技术。

扩展资料：

从背景上说，Kubernetes是由Google与RedHat公司共同主导的开源“容器编排”项目，它起源于Google公司的Borg系统。

所以它在超大规模集群管理方面的经验要明显优于其他容器编排技术，加上Kubernetes在社区管理方面的民主化，使得它很快打败了Docker公司推出的容器编排解决方案(Compose+Swarm)，从而成为了容器编排领域事实上的标准。

而在功能上Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。

Docker&k8s（一）

​ 容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界” 。对于 Docker 等大多数 Linux 容器来说， Cgroups 技术 是用来制造约束的主要手段，而 Namespace 技术 则是用来修改进程视图的主要方法。

其实只是 Linux 创建新进程的一个可选参数。我们知道，在 Linux 系统中创建线程的系统调用是 clone()，比如：

​ 这个系统调用就会为我们创建一个新的进程，并且返回它的进程号 pid。而当我们用 clone() 系统调用创建一个新进程时，就可以在参数中指定 CLONE_NEWPID 参数，比如：

​ 这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1。之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的 PID 还是真实的数值，比如 100。

​ 而 除了 PID Namespace，Linux 操作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace，用来对各种不同的进程上下文进行“障眼法”操作。

​ 比如，Mount Namespace，用于让被隔离进程只看到当前 Namespace 里的挂载点信息；Network Namespace，用于让被隔离进程看到当前 Namespace 里的网络设备和配置。

​ 这，就是 Linux 容器最基本的实现原理了。所以说，容器，其实是一种特殊的进程而已。Namespace 技术实际上修改了应用进程看待整个计算机“视图”，即它的“视线”**作系统做了限制，只能“看到”某些指定的内容 。

优势：更加的轻量且没有损耗资源。弊端：隔离不彻底

Cgroups（Linux Control Group） 就是 Linux 内核中用来为进程设置资源限制的一个重要功能。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等

Cgroups 给用户暴露出来的操作接口是文件系统

比如，向 container 组里的 cfs_quota 文件写入 20 ms（20000 us）：

意味着在每 100 ms 的时间里，被该控制组限制的进程只能使用 20 ms 的 CPU 时间，也就是说这个进程只能使用到 20% 的 CPU 带宽。

把被限制的进程的 PID 写入 container 组里的 tasks 文件，上面的设置就会对该进程生效了：

除 CPU 子系统外，Cgroups 的每一项子系统都有其独有的资源限制能力，比如：

Linux Cgroups 的设计还是比较易用的，简单粗暴地理解呢，它就是一个子系统目录加上一组资源限制文件的组合。容器是一个“单进程”模型。

​ Mount Namespace 修改的，是容器进程对文件系统“挂载点”的认知。Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载操作（mount）才能生效。实际上，Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的，它也是 Linux 操作系统里的第一个 Namespace。

​ 而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。它还有一个更为专业的名字，叫作：rootfs（根文件系统）。

对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：

​ rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。

容器的 rootfs 由如下图所示的三部分组成：

第一部分，只读层 ：它是这个容器的 rootfs 最下面的五层，对应的正是 ubuntu:latest 镜像的五层，挂载方式都是只读的（ro+wh，即 readonly+whiteout）

这些层，都以增量的方式分别包含了 Ubuntu 操作系统的一部分

第二部分，可读写层。 (rw)

​ 在没有写入文件之前，这个目录是空的。而一旦在容器里做了写操作，你修改产生的内容就会以增量的方式出现在这个层中。如果要删除AuFS 会在可读写层创建一个 whiteout 文件，把只读层里的文件“遮挡”起来。

专门用来存放你修改 rootfs 后产生的增量，原先的只读层里的内容则不会有任何变化

第三部分，Init 层。

​ 有些文件本来属于只读的 Ubuntu 镜像的一部分，但是用户往往需要在启动容器时写入一些指定的值比如 hostname，所以就需要在可读写层对它们进行修改。可是，这些修改往往只对当前的容器有效，我们并不希望执行 docker commit 时，把这些信息连同可读写层一起提交掉。所以，Docker 做法是，在修改了这些文件之后，以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层，所以是不包含这些内容的。可以参考git ignore的思想。

Dockerfile ：

ENTRYPOINT：entrypoint才是正统地用于定义容器启动以后的执行体的，其实我们从名字也可以理解，这个是容器的“入口”。

CMD：cmd给出的是一个容器的默认的可执行体。也就是容器启动以后，默认的执行的命令。如果docker run没有指定任何的执行命令或者dockerfile里面也没有entrypoint，那么，就会使用cmd指定的默认的执行命令执行如果你不额外指定，那么就执行cmd的命令，否则呢？只要你指定了，那么就不会执行cmd，也就是cmd会被覆盖。

docker commit，实际上就是在容器运行起来后，把最上层的“可读写层”，加上原先容器镜像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，不会占用额外的空间。

而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会**作系统先复制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。

​ 一个进程的每种 Linux Namespace，都在它对应的 /proc//ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。

​ 这也就意味着：一个进程，可以选择加入到某个进程已有的 Namespace 当中，从而达到“进入”这个进程所在容器的目的，这正是 docker exec 的实现原理。

Volume 机制，允许你将宿主机上指定的目录或者文件，挂载到容器里面进行读取和修改操作。

​ 当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统。所以在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt//test）上，这个 Volume 的挂载工作就完成了。

​ 由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时 Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机上，是看不见容器内部的这个挂载点的。这就 保证了容器的隔离性不会被 Volume 打破 。

​ 而这里要使用到的挂载技术，就是 Linux 的 绑定挂载（bind mount）机制 。它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。绑定挂载实际上是一个 inode 替换的过程。在 Linux 操作系统中，inode 可以理解为存放文件内容的“对象”，而 dentry，也叫目录项，就是访问这个 inode 所使用的“指针”。

​ 所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目录或文件，不动声色地挂载到容器中。

k8s和docker区别

k8s和 docker的区别是： docker是一种开放源码应用容器引擎，开发人员可以将其应用打包，发布到流行的 liunx系统或实现虚拟化。

1.k8s是一种开放源码的容器集群管理系统，可实现自动化部署、扩展容量、维护等容器集群功能。Docker容器有别于传统虚拟化方法，传统的虚拟技术，在将物理硬件虚拟为多套硬件之后，需要在每套硬件上分别部署一个操作系统，然后在这些操作系统上运行相应的应用程序。docker-compose up- d是一个容器。dockerfilebuild是一个镜像。dockerfile是自己定义自己的镜像功能。

2.传统的方法是直接在同一个物理机器节点上部署所有应用，因此，每个 App的依赖性是完全相同的，不能实现 App之间的隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式将 App部署到其中，但是这样做过于繁琐，因此 Docker技术要比虚拟机更轻，现在我们通过部署 Container容器的技术来部署应用程序，让所有 Container运行在容器引擎上。容器集群管理系统以 kubernetes为代表，使用 kubernetes来管理 Docker集群，也就是说， Docker可以被看作是 Kubernetes内部使用的低级组件。此外， kubernetes不仅支持 Docker，也支持 Rocket，这是另一种容器技术。
3.而且 Docker容器中的应用程序进程直接运行在宿主机(真实的物理机)的内核上， Docker引擎将一些各自独立的应用程序打包，它们各自独立地独立地运行于未虚拟化的宿主硬件上，同时每个容器都没有自己的内核，显然比传统虚拟机更轻。

将Kubernetes的Runtime由Docker修改为containerd

Kubernetes 从 v1.20 开始弃用 Docker，并推荐用户切换到基于容器运行时接口（CRI）的容器引擎，如 containerd、cri-o 等。如果你使用了云服务商提供的托管 Kubernetes 服务，那你不用担心，像 GKE、AKS 等云服务商都已经在新版集群中把默认的运行时切换到 containerd 。如果是自管的集群则需要手动修改集群的Runtime，以下介绍集群Runtime的修改方法。

首先将需要修改的节点设置成不可调度

驱逐该节点上除了daem***et的pod

关闭docker、containerd 和 kubelet：

我们在使用docker-ce作为集群runtime时默认安装了containerd，先将其卸载。

安装containerd可参考我的文章： Containerd的安装和配置

/etc/containerd/config.toml 修改默认的 pause 镜像为国内的地址，替换 下面的 sandbox_image：

配置下镜像仓库的加速器地址：

修改 kubelet 配置，将容器运行时配置为 containerd，/etc/sysconfig/kubelet 文件，在该文件中可以添加kubelet 启动参数：

或者修改/etc/systemd/system/kubelet.service.d/10-kubeadm.conf文件

--container-runtime ：指定使用的容器运行时的，可选值为 docker 或者 remote，默认是 docker，除 docker 之外的容器运行时都应该指定为 remote。
--container-runtime-endpoint：是用来指定远程的运行时服务的 endpiont 地址的，在 Linux 系统中一般都是使用 unix 套接字的形式，unix:///run/containerd/containerd.sock。
--image-service-endpoint：指定远程 CRI 的镜像服务地址，如果没有指定则默认使用 --container-runtime-endpoint 的值了，因为 CRI 都会实现容器和镜像服务的。
配置完成后重启 containerd 和 kubelet 即可：

查看服务

允许调度