kubernetes和Docker关系简单说明

Posted 2023-04-11

参考技术A 最近项目用到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 入门（二）：docker 和 沙盒、虚拟机以及 Kubernetes 的关系

参考技术A

做开发的基本都听说过沙盒 (Sandbox) 和虚拟机 (Virtual Machine，简称 VM) ，如今容器技术很火，其中以 docker 最受大家欢迎。作为一种集群管理工具，K8s 最近也是火的不要不要的。 我们经常会讲 docker 和 K8s 联系起来，那么两者之间又存在什么关联呢？

首先 Sandbox 和 VM 都是属于 虚拟技术 ，用来虚拟软件运行环境并具有资源隔离的功能。Sandbox 比较“轻”（只需要虚拟出一个小的环境）且一旦退出就释放之前占用的资源；VM 则比较重（虚拟出整个操作系统，相当于子电脑）。关于 Sandbox 和 VM 的区别可以参考博客： https://www.jianshu.com/p/6acdfd60b014 。
容器是属于 Sandbox 的一种。 顾名思义，沙盒就是能够像一个集装箱一样，把你的应用“装”起来的技术。这样，应用与应用之间，就因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去。 容器技术的核心功能 ，就是通过 约束和修改进程的动态表现 ，从而为其 创造出一个“边界” 。正是因为这个边界才会让容器里面的程序看不到宿主机上其他的程序从而给程序一种它就是在一个独立的操作系统上的假象。容器具有如下几个优点：

Docker 是一种 轻量级的虚拟化 技术，即容器技术。随着 Docker 的开源，docker 凭借其“轻”的特点得到迅速的普及。

这三个优点恰是 VM 的缺点。

Docker 原意是指处理码头集装箱的工人。 首先需要注意的是， Docker 本身不是容器 ，而是一个 开源的应用容器引擎 。Docker 让开发者可以以统一的方式 打包 他们的 应用以及依赖包 到一个 可移植的容器 中，然后 发布 到任何 安装了docker引擎的服务器上 （包括流行的Linux机器、windows机器），也可以实现虚拟化。从这个描述可以看出 Docker 的几种常用任务：

Docker 的两句口号很准确地描述了其功能：

1. Build, ship and run
顾名思义，创建、运输和运行。
举个例子来理解：比如说我在 A 地建好了一个厂区，该厂区主要的是车间，其次还有一些配套的生活设施（比如食堂、超市、宿舍、水电等）。现在我要将厂迁到 B 地，按照常规思路就是把 A 地的车间拆了运到 B 地重新组装、并在 B 地建好配套的生活设施，工程量明显很大。假设现在有一种魔法能够在A地将车间及其配套的生活设施 复制一份并打包成一个镜像 image（文件） ，然后将该镜像迁移到 B 地，这样在B地马上就能够投入使用，省去了拆机、重装以及搭建配套生活设施的工作，非常方便快捷。
现在我们将 车间类比成一个application ，将 配套的生活设施类比成依赖 ，那么 docker 就是这种魔法 。

2. Build once, run anywhere
顾名思义，一次创建、随地运行。
我们知道 车间是用于工业生产的 ，即一个application。在这个世界，还存在很多其他的application，比如学校、医院、写字楼、商场、体育场等，它们各自负责不同的用途。假设这些 application 都是能够共享的，那么这个效率将会很高，比如国家A需要用到体育馆，可以从国家B复制一个过来；国家B需要用到学校，可以从国家A复制一个过来。Docker 使用的就是这种理念，Docker 中包含三个核心部分：

镜像仓库（Repository）可以是私有的（比如本地机器的 Docker repository），也可以是公有的（比如 Docker 官方提供的Docker Hub、第三方的 Hub）。 负责管理镜像仓库（Repository）的是 Docker Registry 服务 （就像是图书馆管理员）。Docker 官方提供的 Docker Hub 对于镜像来源有着严格的把控，有很多高质量的 application 镜像，也是开发人员用的最多的public registry 服务。

那么为什么需要 Kubernetes 呢？就在 Docker 容器技术被炒得热火朝天之时，大家发现，如果想要将 Docker 应用于具体的业务实现（当 容器和服务器的数量达到一定规模 的时候，就会碰到管理的
问题，即 如何有效管理大量的服务器和容器 ，保证 应用的稳定运行、方便升级和故障的快速解决 ），是存在困难的—— 编排、管理和调度等各个方面都不容易 。于是就迫切 需要一套容器编排工具 ，能够对 Docker 和容器进行 更高级、灵活的管理 。容器编排工具提供图形化界面或者命令行来管理容器和服务器集群，提供容器配置、任务发布、服务发现、负载均衡、系统监控和故障恢复、声明式系统配置以及有关容器部署和性能的规则和约束定义机制等。
就在这个时候， Google开发的 Kubernetes 从众多编排工具中脱颖而出 ，赢下了容器编排工具大战。Kubernetes 是一种 基于容器的集群管理平台 。Kubernetes 是希腊语，意为“舵手、领航员”，大家都习惯将 Kubernetes 简称为K8s（ubernete 包含8个字母）。K8s 最初由 Google 创建而后加入 openstack 基金会并发布了 K8s V1.0。

Docker 公司自己有一款名为 Docker Swarm的产品，它是一个容器集群和调度工具，功能类似于Kubernetes。相比 Kubernetes，Swarm在集群搭建和使用上要相对简单一些，学习和部署成本相对低一些。较新版本的Docker已经集成了Swarm。Swarm支持跨多个主机进行编排，管理较小规模的容器集群也绰绰有余，对于初学者也可以很快的部署和运行。

笔者水平有限，如有错误，敬请指正！

参考：
https://www.cnblogs.com/misswangxing/p/10669444.html
https://blog.csdn.net/fly910905/article/details/98962455