包含dockerkubernetes的词条

本篇文章给大家谈谈dockerkubernetes，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、kubernetes和docker区别
• 2、kubernetes和Docker关系简单说明
• 3、从Docker到Kubernetes

kubernetes和docker区别

1、技术原理不同

docker是容器化技术，K8S是一套自动化部署工具，可全生命周期管理docker容器。K8S是谷歌开发的容器集群管理系统。在docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性庆睁脊。

2、平台不同

K8S是一个完备的分布式系统支撑平台，具备完善的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、内建智能负载均衡器、强大的故障发现誉渗和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。

docker是一个开源的应用容器引擎，让开发者可以打包它们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows机器上，也可以实早耐现虚拟化。

3、架构模式不同

Docker使用客户端一一服务器架构模式，使用远程API来管理和创建Docker容器。Docker容器通过Docker镜像来创建，容器与镜像的关系类似于面向对象编程中的对象与类。

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，这是另一种容器技术。希望我这篇文章中简单的描述能让你对两者有所理解和认识。

[img]

从Docker到Kubernetes

2013 年，随着PaaS发展壮大，这个领域的从业者们发现了 PaaS 中最为棘手也最亟待解决的一个问题：究竟如何给应用打包？无论是 Cloud Foundry、OpenShift，还是 Clodify，面对这个问题都没能给出一个完美的答案。一个并不引人瞩目的 PaaS 创业公司 dotCloud，却选择了开源自家的一个容器项目 Docker，正好提供了一种非常便利的打包机制，然后就一发不可收拾，围绕着 Docker 项目进行集成与创新涌现出来，包括Mesosphere公司的Mesos项目等等，Docker 公司也顺势推出了Docker Compose、Swarm 和 Machine“三件套”，docker生态圈很快发展起来了，开启了一个新的容器时代。

2014年6月，谷歌公司正式宣告了Kubernetes项目的诞生。这个时候容器出现多样化，包括google公司lmctfy容器，coreos的rkt容器。Google公司提出和Docker合作，与Docker公司共同推进一个中立的容器运行时库作为Docker项目的核心依赖。此时Docker并不担心，因为它维护的 Docker 社区也足够庞大，Docker项目已是容器生态的标准。于是，2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范，这就是OCI。明显OCI的成立容器玩家们出于自身利益进行干涉的一个妥协结果，所以尽管Docker 是 OCI 的发起者和创始成员，但并没有很积极的去推动，Docker注重是它商业价值。

2015年12月11日，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金，主要是以kubernetes项目为基础打造一个平台级生态。由于Kubernates项目焕然一新的设计理念和号召力，2016年以后kubernates社区得到了空前的发展。

2016年6月，Docker v.1.12发布，直接内置Docker Swarm（多主机多容器的编排解决方案）

2016年12月， Kubernetes 发布 CRI （Container Runtime Interface， 容器运袭橡滑行时接口）

2017年，Docker 分拆了 Containerd，支持CNI，将这个组件分解为一个单独的项目，使得 Docker 将容器的管理功能移出 Docker 引擎，并移入一个单独的守护进程中，即 Containerd，并将其捐赠给了CNCF社区。同时Docker公司宣布将Docker项目改名为Moby，交给社区自行维护。

2017年10月，Docker公司将自己的主打产品Docker EE 内置Kubernetes项目，预示着Kubernetes的胜出，成为容器编排的标准。

2017年11月 ，K8s支持containerd

2018年 k8s集成containerd，正式GA，把CRI plugin嵌入 containerd中拍腊

2019年 rkt 终止使命被CNCF归档

2019 年 Mirantis 收购 Docker 的企业服务

OCI 代表 开放容器标准 ， 它标准化了容器工具和底层实现（technologies）之间的大量接口。 他们维护了打包容器镜像（OCI image-spec）和运行容器（OCI runtime-spec）的标准规范。 他们还以 runc 的形式维护了一个 runtime-spec 的真实实现， 这也是 containerd 和 CRI-O 依赖的默认运行时。 CRI 建立在这些底层规范之上，为管理容器提供端到端的标准

全称Container Runtime Interface，（容器运行时接口）是一个用来扩展容器运行时的接口，能让 kubelet 无需如仔重新编译就可以广泛使用各种容器运行时的插件接口。CRI 由 protocol buffers 和 gRPC API 还有 streaming 库 构成。用户不需要关心内部通信逻辑，而只需要实现定义的接口就可以，包括 RuntimeService 和 ImageService。

其实准确来讲，Docker和容器不是一回事，但Docker普及了Linux容器这种技术模式，并在开发底层技术方面发挥了重要作用。 容器的生态相比于单纯的 Docker，已经进化到了一个更宽广的领域

2020年 Kubernates 宣布移除dockershim，现在1.20版本以后，能使用但是kubelet会打印警告日志。最新消息dockershim 计划在 Kubernetes 1.24 版被移除， 请参阅 移除 Kubernetes 增强方案 Dockershim

主流的容器运行时有 containerd，docker engine，cri-o，Mirantis Container Runtime（商业版）

Containerd是一个工业标准的容器运行时，它强调简单性、健壮性和可移植性。它可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等，是目前适用最广泛。

Containerd 的配置文件默认为 /etc/containerd/config.toml[^ssh-copy-id]

containerd 将容器相关的数据持久化在 /var/lib/containerd/中（docker 默认在 /var/lib/docker/）

containerd 提供ctr CLI。

containerd 相比docker, 多了 namespace 概念, 每个image和container 都会在各自的namespace下可见, 目前k8s会使用k8s.io 作为命名空间。

容器时依赖task，task 管理容器，删除容器，得先终止task

CRI Tools是社区针对 CRI 接口开发的CLI及验证工具。

它包括两个工具：crictl 和 critest。crictl 是一个容器运行时命令行接口，适用所有CRI兼容的容器运行时，与Docker cli类似功能，但是docker cli只适用于Docker运行时。由于Kubernetes 是支持所有CRI兼容的容器运行时，所以推荐crictl用于 Kubernetes 节点上 pod、容器以及镜像的除错工具。

针对pod操作如下：

critest 则是一个容器运行时的验证测试工具，用于验证容器运行时是否符合 Kubelet CRI 的要求。除了验证测试，critest 还提供了 CRI 接口的性能测试，比如 critest -benchmark

根据上文内容知道Docker也是依赖Containerd，因此安装Docker同时也安装Containerd，那么切Containerd就可以不用再安装，当然你也可以将 Docker 和 containerd 完全卸载掉，然后重新安装。

Containerd 中默认已经实现了 CRI，但是是以 plugin 的形式配置的，之前 Docker 中自带的 containerd 默认是将 CRI 这个插件禁用掉了的（使用配置 disabled_plugins = ["cri"]），所以这里我们重新生成默认的配置文件来覆盖掉, 具体查看上面Containerd 配置

接下来配置kubelet，修改/etc/sysconfig/kubelet，container-runtime指定容器运行时，默认值是docker， --container-runtime-endpoint指定运行时套接字地址，containerd套接字unix:///run/containerd/containerd.sock

配置完成后启动containerd和kubelet

重启完成后查看节点状态

关于dockerkubernetes和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。