kubernetes和Docker —— kubernetes实用随笔（一）

雨点打透心脏的1/2处 2022-05-22 08:06 135阅读 0赞

> 系列文章：     
> 
>  [kubernetes和Docker —— kubernetes实用随笔（一）][kubernetes_Docker _ kubernetes]
> 
> [最常用的kubectl命令(附带场景和截图) —— kubernetes实用随笔（二）][kubectl_ _ kubernetes]
> 
> [kubernetes核心对象 —— kubernetes实用随笔（三）][kubernetes_ _ kubernetes]

最近项目用到kubernetes（以下简称k8s，k和s之间有8个字母），虽然之前也有简单使用过，但最近发现k8s概念较多，命令也有些不够用了，故想借此机会写点东西，更全面认识并使用k8s。

本系列目的：让你更全面了解k8s概念，以及学到在工作中常用的操作。整体更偏向于原理和应用。在正式开始k8s之前，我们先看看k8s和Docker的关系，分别从虚拟化角度、部署方式角度叙述why use容器，话不多说，开干。

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

# **简要介绍：** #

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

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

# **与传统技术对比：** #

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

**一、从虚拟化角度：**

![70][]

图1

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

每个集群有多个节点，每个节点可，我们的kuberbete就是管理这些**应用程序所在的小运行环境（container）**而生。

**二、从部署角度**

![70 1][]

图2

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

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

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

[kubernetes_Docker _ kubernetes]: https://blog.csdn.net/whdxjbw/article/details/80739529
[kubectl_ _ kubernetes]: https://blog.csdn.net/whdxjbw/article/details/80815950
[kubernetes_ _ kubernetes]: https://blog.csdn.net/whdxjbw/article/details/80798996
[70]: /images/20220522/dcaaf4a3ec3b413291a51e6412a84b9b.png
[70 1]: /images/20220522/2882ccc07369451db24fef19cde28955.png