我有一个程序员朋友，他每年情人节都要送女朋友一台服务器。

他说：“谁不想在过节当天收到一台 4核8g 的服务器呢？”

“万一对方不要，我还能留着自己用。” 给他一次过节的机会，他能把浪漫玩的明明白白。
所以今年情人节，他自己一个人过。
太痛了，是那种布洛芬都不知道他哪里痛的痛。

虽然人跑了，但起码还有服务器陪着他，但屏幕前依然单身的你呢？ 你连服务器都没有。那么问题就来了，你买过服务器吗？看着云厂商各种产品是不是有点懵。
你知道 ecs，vps，docker 容器 是什么吗？它们有啥区别呢？

物理服务器是什么？

我的柜子里有一台大学时候用的废弃电脑，自带 cpu、 内存等硬件和操作系统，根据一些教程视频，是可以做成服务器的。

像这样一台看得见摸得着的机器，其实就是云厂商页面里提到的物理服务器或物理机。不同厂商叫法不同，有的厂商叫它独立服务器。

跟家里电脑不一样的是，云厂商的机器性能更好，核数更高，还有专业的机房和空调伺候着。那既然这样，是不是就不需要买云厂商的服务器呢？

糊涂啊，一台家用电脑跑起来 50 瓦，一年下来电费都好几百，还得花精力伺候着不让它关机，还真不如买别人家的划算。

但问题又来了，云厂商的物理服务器一般都是核数较高，很多时候我们根本不需要这么高配的机器。怎么办呢？这一点云厂商当然也考虑到了。

vps 和 ecs 是什么

云厂商一般会将一台物理服务器分割成多个虚拟机。它跟我们在 windows 用 VMware, VirtualBox 建的虚拟机其实是一回事。每个虚拟机都拥有独立的操作系统、资源（比如 CPU、内存、存储空间）和公网 IP 地址。然后对外出售，这样的虚拟机就是所谓的 VPS（Virtual Private Server，虚拟专用服务器）。

但传统 VPS 有个缺点，不支持用户自主升降级，它的资源是预先分配的，不易动态调整。举个例子，假设你买了 1c1g 的服务器，想在页面上点点两下升级成 2c2g，这在传统 VPS 里是不支持的。如果给 VPS 加入自主升降级的功能，那它就成了 ECS（Elastic Compute Service，弹性计算服务）

用户可以根据需要随时调整 CPU、内存、磁盘和带宽，主打一个弹性。我们可以利用 ecs 学习 linux 命令，部署个人博客，做私人云盘存储，甚至可以将自己做的游戏部署到 ecs 上邀请朋友来玩。

docker 容器 是什么

买了 ecs 后，我们一般会开始部署自己的软件应用。机器少的时候手动部署问题不大，机器多了后各种问题就来了，其中最明显的就是，ecs 之间，如果底层操作系统不同，比如有些是 ubuntu，有些是 centos，部署应用的时候就会有各种环境问题。如果能让软件带着操作系统环境一起去部署就好了，最简单的方案是将软件和操作系统一起打包成虚拟机部署在 ecs 中。但这样就成了在 ECS（也就是虚拟机）中再运行一个完整的虚拟机，太重了。有解法吗？

有。既然多加一个操作系统太重，那我就只打包软件和系统依赖库加配置就好了。然后将这部分系统文件挂到 ecs 的操作系统下，利用一个叫 Namespace 的能力让它看起来就像是一个独立操作系统一样。再利用一个叫 Cgroup 的能力限制它能使用的计算资源。这就省掉了一层笨重的操作系统，同时还让软件轻松跑在各类操作系统上。这就是我们常说的 Docker 容器技术。

总的来说就是，物理服务器上跑 ecs，ecs 跑 Docker 容器。多个 Docker 容器共享一个 ecs 实例 操作系统内核。

服务器怎么选

现在我们了解完他们的区别了，但服务器款式那么多，我们怎么选？如果你是小公司老板或个体创业者，想要好一点的物理机又不想自建机房，那可以考虑买独立服务器。

如果你是像我一样的个人开发者，或者是学生，那无脑冲云服务器 ecs。有了它，我们可以很方便的在上面部署 docker 容器，平时做做实验，部署博客，完全够用了。

那是因为香港服务器没有备案的烦恼，而且大陆也能轻松访问，有时候一些热点技术一出来，比如时下火热的 ai 技术，网站越快上线就能越早拿到搜索引擎排名，备案得等个把月，这一等就白白错失了很多成为下一个马总的机会。

作为一个程序员，如果你想安装一个 vim 编辑器文本，在不同环境里你得执行不同的命令。在 ubuntu，你需要执行 apt-get install vim，在 centos 里，你需要执行 yum install vim.

装个小软件尚且如此，要是你想将自己写的代码部署到各个不同操作系统的服务器上，那依赖的软件和配置就更多了，需要针对每个环境单独写一套部署脚本。
难受，太难受了。

那么问题就来了，有没有更好的解决方案？
当然有，没有什么是加一层中间层不能解决的，如果有，那就再加一层，这次我们要加的中间层是 Docker。

哦不，准确来说是 Docker容器。

Docker 是什么？

我们经常能听到程序员说"这个程序在我环境里明明是好的啊，怎么到你这就不行了呢"？注意这里的关键词，程序和环境。程序是跑在操作系统上的，而操作系统上又装了各种不同版本的依赖库和配置，这些被程序所依赖的信息，我们统称为"环境"。

程序依赖环境，环境不同，程序就可能跑不起来。如果我们能将环境和程序一起打包，给到对方运行，那问题不就解决了吗。Docker 就是这样一款可以将程序和环境打包并运行的工具软件。我们来看下它是怎么做的？

基础镜像是什么

既然上面提到环境不同，会导致程序运行结果不同，那么我们首先要做的最重要的事情，就是统一环境。而环境中，最最重要的就是操作系统。比如 centos 还是 ubuntu，我们得选一个，让所有程序都跑在同一个操作系统上。并且我们知道操作系统分为用户空间和内核空间，应用程序运行在用户空间。因此，我们可以阉割操作系统，只需要利用操作系统的用户空间部分，就能构建出应用所需的环境。其次就是统一程序语言依赖，比如要跑 python 应用，你得装个 python 解释器，要跑个 java 应用，得装个 JVM，要跑 go 应用，那就。。什么都不需要装。选中一个基础操作系统和语言后，我们将它们对应的文件系统，依赖库，配置等放一起打包成一个类似压缩包的文件，这就是所谓的基础镜像(Base Image)。

Dockerfile 是什么

有了基础镜像之后还不够，我们经常还需要安装一些依赖，比如yum install gcc，甚至还要创建一些文件夹。最后才是运行我们的目标应用程序。我们知道 linux 中，所有工作都可以通过命令行完成，所以我们可以将要做的事情以命令行的形式一行行列出来。就像一份 todo list。意思是要求在基础镜像的基础上按着 todo list 挨个执行命令。这份 todo list 长下面这样。

# 指定基础镜像
FROM python:3.9

# 设置工作目录
WORKDIR /app

# 复制依赖文件到容器中
COPY requirements.txt .

RUN yum install gcc
# 安装依赖
RUN pip install --no-cache-dir -r requirements.txt

# 将当前目录下的所有文件复制到容器的 /app 目录下
COPY . /app

# 设置容器启动时执行的命令
CMD ["python", "app.py"]

具体含义是，基于一个装了 python3.9 解释器的操作系统（基础镜像），再执行 pip install 等命令安装其他依赖，从而构建出一个适合程序运行的环境，最后用 python app.py 运行我们的目标应用程序。像这样一份列清楚了，从操作系统到应用服务启动，需要做哪些事情的清单文件（todo list），就是所谓的 Dockerfile。

容器镜像 是什么

注意 Dockerfile 只是描述了要做哪些事情，并没有真正开始做。当我们用命令行执行 docker build 的时候，Docker 软件就会按着 Dockerfile 的说明，一行行构建环境+应用程序。最终将这个环境+程序，打包成一个类似"压缩包"的东西，我们叫它容器镜像(container image)。

只要将容器镜像传到任意一台服务器上，对这个"压缩包"执行"解压缩"，我们就能同时运行环境和程序。太完美了！但是现在还有个问题，怎么将容器镜像传到那么多服务器上呢？

Registry 是什么

服务器那么多，挨个将容器镜像传过去也不是不行，就是将压力全给到发送方的网络带宽了。有没有更好的解决方案？有。可以参考 github 代码仓库 的做法，我们通常会使用 git push 将代码传到 github，有需要的人自己通过 git pull 的方式将代码从 github 拉到自己的机器上。

那 Docker 也一样，弄一个镜像仓库，通过 docker push 将镜像推到仓库，有需要的时候再通过 docker pull 将镜像拉到机器上。这个负责管理镜像仓库推拉能力的服务，就叫 Docker Registry。基于 Docker Registry 的能力，我们可以搭建各种官方或私人镜像仓库，比如官方的叫 DockerHub，非官方的有清华大学的 Tuna 等等，一般公司内部也会有自己的镜像仓库。

容器是什么

现在，我们解决了服务器间传输容器镜像的问题。我们可以跑到目的服务器上，执行 docker pull 拿到容器镜像。然后执行 docker run 命令，将这个类似"压缩包"的容器镜像给"解压缩"，获得一个独立的环境和应用程序并运行起来。这样一个独立的环境和应用程序，就是所谓的容器(container)。我们可以在一个操作系统上同时跑多个容器。且这些容器之间都是互相独立，互相隔离的。

Docker 和虚拟机的关系？

眼熟不，这个容器是不是很像我们用 vmware 或 kvm 整出来的传统虚拟机？但不同的是，传统虚拟机自带一个完整操作系统，而容器本身不带完整操作系统，容器的基础镜像实际上只包含了操作系统的核心依赖库和配置文件等必要组件。它 利用一个叫 Namespace 的能力让它看起来就像是一个独立操作系统一样。再利用一个叫 Cgroup 的能力限制它能使用的计算资源。

所以说，容器本质上只是个自带独立运行环境的特殊进程，底层用的其实是宿主机的操作系统内核。

Docker 的架构原理

现在，我们回到日常使用场景中，聊聊 Docker 的架构原理。它是经典的 Client/Server 架构。Client 对应 Docker-cli， Server 对应 Docker daemon。我们在命令行里敲 Docker 命令，使用的就是 Docker-cli.

Docker-cli 会解析我们输入的 cmd 命令，然后调用 Docker daemon 守护进程提供的 RESTful API，守护进程收到命令后，会根据指令创建和管理各个容器。再具体点，Docker Daemon 内部分为 Docker Server、Engine 两层。Docker Server 本质上就是个 HTTP 服务，负责对外提供操作容器和镜像的 api 接口，接收到 API 请求后，会分发任务给 Engine 层，Engine 层负责创建 Job，由 Job 实际执行各种工作。

不同的 Docker 命令会执行不同类型的 Job 任务。

docker build

如果你执行的是 docker build 命令，Job 则会根据 Dockerfile 指令，像包洋葱皮似的一层层构建容器镜像文件。

docker push/pull

如果你执行的是 docker push 或 pull 之类的镜像推拉操作，Job 则会跟外部的 Docker Registry 交互，将镜像上传或下载。

docker run

如果你执行的是 docker run 命令，Job 就会基于镜像文件调用 containerd 组件，驱使 runC 组件创建和运行容器。

Docker 到底是什么？

现在我们再回过头来看这句话，Docker 本质上就是一个将程序和环境打包并运行的工具软件。具体点来说就是，它通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。

好了，到这里，我们就了解了 Docker 的架构和基本运行原理了。接下来，我们再来聊聊跟 Docker 相关的几个周边。

Docker Compose 是什么？

我们现在知道了 Docker 容器 本身只是一个特殊进程，但如果我想要部署多个容器，且对这些容器的顺序有一定要求呢？比如一个博客系统，当然是先启动数据库，再启动身份验证服务，最后才能启动博客 web 服务。按理说挨个执行 docker run 命令当然是没问题的，但有没有更优雅的解决方案？有。我们可以通过一个 YAML 文件写清楚要部署的容器有哪些，部署顺序是怎么样的，以及这些容器占用的 cpu 和内存等信息。

version: "3.8"

services:
  A:
    image: "some-image-for-a"
    deploy:
      resources:
        limits:
          cpus: "0.50" # 限制 CPU 使用率为 50%
          memory: 256M # 限制内存使用量为 256MB

  B:
    image: "some-image-for-b"
    depends_on:
      - A

  C:
    image: "some-image-for-c"
    depends_on:
      - B

然后，通过一行Docker-compose up命令，开始解析 YAML 文件，将容器们一键按顺序部署，就完成一整套服务的部署。这其实就是 Docker Compose 干的事情。

Docker Swarm 是什么？

Docker 解决的是一个容器的部署。Docker Compose 解决的是多个容器组成的一整套服务的部署。那 Docker Swarm 就更高维度了，它解决的其实是这一整套服务在多台服务器上的集群部署问题。比如在 A 服务器坏了，就将服务在 B 服务器上重新部署一套，实现迁移，还能根据需要对服务做扩缩容。

k8s 到底是什么，架构是怎么样的？

用代码写了一个博客应用服务，并将它部署在了云平台上。
但应用服务太过受欢迎，访问量太大，经常会挂。

所以你用了一些工具自动重启挂掉的应用服务，并且将应用服务部署在了好几个服务器上，总算抗住了。

后来你又上线了商城应用服务和语音应用服务，随着应用服务变多，需求也千奇百怪。有的应用服务不希望被外网访问到，有的部署的时候要求内存得大于 xxGB 才能正常跑。
你每次都需要登录到各个服务器上，执行手动操作更新。不仅容易出错，还贼浪费时间。

那么问题就来了，有没有一个办法，可以解决上面的问题？当然有，没有什么是加一个中间层不能解决的，如果有，那就再加一层。
这次我们要加的中间层，叫 Kubernetes。

Kubernetes 是什么？

Kubernetes，它是 G 家开源的神器，因为单词太长，所以我们习惯省略中间 8 个字母，简称它为 k8s。

它介于应用服务和服务器之间，能够通过策略，协调和管理多个应用服务，只需要一个 yaml 文件配置，定义应用的部署顺序等信息，就能自动部署应用到各个服务器上，还能让它们挂了自动重启，自动扩缩容。

听起来有些厉害，它是怎么实现这些功能的呢？

Kubernetes 架构原理

为了实现上面的功能，Kubernetes 会将我们的服务器划为两部分，一部分叫控制平面（control plane，以前叫master），另一部分叫工作节点，也就是 Node。简单来说它们的关系就是老板和打工人， 用现在流行的说法就是训练师和帕鲁。控制平面负责控制和管理各个 Node，而 Node 则负责实际运行各个应用服务。

我们依次看下这两者的内部架构。

控制平面内部组件

• 以前我们需要登录到每台服务器上，手动执行各种命令，现在我们只需要调用 k8s 的提供的 api 接口，就能操作这些服务资源，这些接口都由 API Server 组件提供。

• 以前我们需要到处看下哪台服务器 cpu 和内存资源充足，然后才能部署应用，现在这部分决策逻辑由 Scheduler（调度器）来完成。

• 找到服务器后，以前我们会手动创建，关闭服务，现在这部分功能由 Controller Manager（控制器管理器）来负责。

• 上面的功能都会产生一些数据，这些数据需要被保存起来，方便后续做逻辑，因此 k8s 还会需要一个存储层，用来存放各种数据信息，目前是用的 etcd，这部分源码实现的很解耦，后续可能会扩展支持其他中间件。

以上就是控制平面内部的组件。

我们接下来再看看 Node 里有哪些组件。

Node 内部组件

Node 是实际的工作节点，它既可以是裸机服务器，也可以是虚拟机。它会负责实际运行各个应用服务。多个应用服务共享一台 Node 上的内存和 CPU 等计算资源。

以前我们需要上传代码到服务器，而用了 k8s 之后，我们只需要将服务代码打包成Container Image(容器镜像)，就能一行命令将它部署。

如果你不了解容器镜像的含义，你可以简单理解为它其实就是将应用代码和依赖的系统环境打了个压缩包，在任意一台机器上解压这个压缩包，就能正常运行服务。为了下载和部署镜像，Node 中会有一个 Container runtime 组件。

每个应用服务都可以认为是一个 Container（容器）, 并且大多数时候，我们还会为应用服务搭配一个日志收集器 Container 或监控收集器 Container，多个 Container 共同组成一个一个 Pod，它运行在 Node 上。

k8s 可以将 pod 从某个 Node 调度到另一个 Node，还能以 pod 为单位去做重启和动态扩缩容的操作。
所以说 Pod 是 k8s 中最小的调度单位。

另外，前面提到控制平面会用 Controller Manager （通过API Server）控制 Node 创建和关闭服务，那 Node 也得有个组件能接收到这个命令才能去做这些动作，这个组件叫 kubelet，它主要负责管理和监控 Pod。最后，Node 中还有个 Kube Proxy ，它负责 Node 的网络通信功能，有了它，外部请求就能被转发到 Pod 内。

Cluster

控制平面和Node 共同构成了一个 Cluster，也就是集群。在公司里，我们一般会构建多个集群, 比如测试环境用一个集群，生产环境用另外一个集群。同时，为了将集群内部的服务暴露给外部用户使用，我们一般还会部署一个入口控制器，比如 Ingress 控制器（比如Nginx），它可以提供一个入口让外部用户访问集群内部服务。

kubectl 是什么

上面提到说我们可以使用 k8s 提供的 API 去创建服务，但问题就来了，这是需要我们自己写代码去调用这些 API 吗？答案是不需要，k8s 为我们准备了一个命令行工具 kubectl，我们只需要执行命令，它内部就会调用 k8s 的 API。

接下来我们以部署服务为例子，看下 k8s 是怎么工作的。

怎么部署服务？

首先我们需要编写 YAML 文件，在里面定义 Pod 里用到了哪些镜像，占用多少内存和 CPU 等信息。然后使用 kubectl 命令行工具执行 kubectl apply -f xx.yaml ，此时 kubectl 会读取和解析 YAML 文件，将解析后的对象通过 API 请求发送给 Kubernetes 控制平面内 的 API Server。API Server 会根据要求，驱使 Scheduler 通过 etcd 提供的数据寻找合适的 Node， Controller Manager 会通过 API Server 控制 Node 创建服务，Node 内部的 kubelet 在收到命令后会开始基于 Container runtime 组件去拉取镜像创建容器，最终完成 Pod 的创建。

至此服务完成创建。

整个过程下来，我们只需要写一遍 yaml 文件，和执行一次 kubectl 命令，比以前省心太多了！部署完服务后，我们来看下服务是怎么被调用的。

怎么调用服务？

以前外部用户小明，直接在浏览器上发送 http 请求，就能打到我们服务器上的 Nginx，然后转发到部署的服务内。用了 k8s 之后，外部请求会先到达 Kubernetes 集群的 Ingress 控制器，然后请求会被转发到 Kubernetes 内部的某个 Node 的 Kube Proxy 上，再找到对应的 pod，然后才是转发到内部容器服务中，处理结果原路返回，到这就完成了一次服务调用。

到这里我们就大概了解了 k8s 的工作原理啦，它本质上就是应用服务和服务器之间的中间层，通过暴露一系列 API 能力让我们简化服务的部署运维流程。

并且，不少中大厂基于这些 API 能力搭了自己的服务管理平台，程序员不再需要敲 kubectl 命令，直接在界面上点点几下，就能完成服务的部署和扩容等操作

总结

• k8s 是 G 家开源的神器，用于管理海量容器服务。

• k8s 集群内分为控制平面和 Node，控制平面是大脑，负责发指令，Node 是手脚，负责执行任务。

• 控制平面内有 API Server，Scheduler，Controller Manager 以及 etcd 等组件。Node 中含有 Pod，Kubelet,Container runtime, Kube Proxy 等组件。控制平面和 Node 共同构成一个 Cluster。

Docker 和 k8s 的关系是什么？

k8s 它会在多台 Node 服务器上调度 Pod，进行部署和扩缩容。

每个 Pod 内部可以含有多个 container，每个 container 本质上就是一个服务进程。

是不是感觉k8s跟 Docker Swarm 做的事情很像？没错，其实 Docker Swarm 是 k8s 的竞品，既然是竞品，那它们做的事情其实区别就不大了。现在回过头来看 Docker 容器和 k8s 之间的关系，思路就清晰了。Docker 部署的容器，其实就是 k8s 调度的 Pod 里的 container，它们都叫容器，其实是一回事。只不过 k8s 除了支持 Docker 的容器外，还支持别人家的容器。Docker Compose 基于多个 container 创建的一整套服务，其实就是 k8s 里的 pod。而 Docker Swarm 做的事情和 k8s 一样，本质上就是在调度 pod。回过头来看下 k8s 的官方定义，叫容器编排引擎，将它理解为，以 API 编程的方式管理安排各个容器的引擎，是不是就特别精辟。

现在，我们再回过头来看下 Docker 的图标，是一个个集装箱，放在一艘船上，这一个个集装箱指的就是互相隔离的容器，而 k8s 的图标，则是一个轮船上的方向盘，意思是 k8s 控制着轮船的航向，其实指的就是调度容器。这波联想就非常形象了。

总结

• Docker 本质上就是一个将程序和环境打包并运行的工具软件，而 Docker 容器本质上只是个自带独立运行环境的特殊进程，底层用的其实是宿主机的操作系统内核。

• Docker 软件 通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。

• Docker 解决的是一个容器的部署问题，Docker Compose 解决的是多个容器组成的一套服务的部署问题，Docker Swarm 解决的是多个容器组成的一套服务在多台服务器上的部署问题，k8s 则是 Docker Swarm 的竞品，在更高维度上兼容了 Docker 容器，实现了容器编排调度。

之后我会持续更新，如果喜欢我的文章，请记得一键三连哦，点赞关注收藏，你的每一个赞每一份关注每一次收藏都将是我前进路上的无限动力 ！！！↖(▔▽▔)↗感谢支持！