Docker、K8s 简介扫盲

物理服务器、VPS、ECS、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 容器，平时做做实验，部署博客，完全够用了。

这时候问题很多的小明就要问了，为什么不选择大厂商的云服务器？是用不起吗？喂喂喂，怎么说话呢？ 不是大厂云服务器用不起，而是小厂商的更有性价比。就以同样是香港 1 核 1g 的 ecs 为例，小厂商一个月只要 1 碗红烧牛肉面。大厂商则要 3 碗。

同样是 24 核物理服务器，小厂商千把块搞定，大厂商就是它的好几倍。

这时候问题很多的小明就又要问了，为什么要选 香港服务器？大陆的不是更便宜吗？

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

Docker 和 k8s 之间是什么关系？

作为一个程序员，如果你想安装一个 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 拉到自己的机器上。

github 仓库

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

容器是什么

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

容器是什么

Docker 和虚拟机的关系？

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

Docker 和虚拟机的区别

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

容器本质是一个特殊进程

Docker 的架构原理

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

Docker 是 C/S 软件架构

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

Docker daemon 内部架构

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

docker build

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

docker build 执行逻辑

docker pull/push

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

docker pull/push 执行逻辑

docker run

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

docker run 执行逻辑

Docker 到底是什么？

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

Docker 到底是什么

好了，到这里，我们就了解了 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 compose 原理

Docker Swarm 是什么？

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

Docker swarm 是什么

Docker 和 k8s 的关系是什么？

还记得之前的文章里提到的 k8s 吗？它会在多台 Node 服务器上调度 Pod，进行部署和扩缩容。

k8s 的 node 内部

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

pod 内部

是不是感觉 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 和 k8s

现在大家通了吗？

总结

• Docker 本质上就是一个将 程序和环境打包并运行 的工具软件，而 Docker 容器本质上只是个自带独立运行环境的 特殊进程，底层用的其实是 宿主机的操作系统内核。
• Docker 软件 通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。
• Docker 解决的是 一个容器 的部署问题，Docker Compose 解决的是 多个容器组成的一套服务 的部署问题，Docker Swarm 解决的是多个容器组成的 一套服务在多台服务器上的部署问题，k8s 则是 Docker Swarm 的竞品，在更高维度上 兼容 了 Docker 容器，实现了容器编排调度。

Docker 原理是什么

Docker 的核心原理其实就是“把程序和它的运行环境打包在一个独立的盒子里”。它不像传统的虚拟机那样去模拟完整的硬件和操作系统，而是直接利用宿主机（主要基于 Linux 内核）的底层能力来实现轻量级的运行环境。

简单来说，Docker 的“魔法”主要依靠以下三个核心技术：

1. Namespace（制造“平行宇宙”实现隔离） 这是用来做“视线隔离”的。Docker 会通过 Namespace 给每个容器分配独立的网络、进程树和文件系统挂载点等。在容器里面的程序看来，它以为自己独占了一台全新的电脑，完全看不到宿主机和其他容器的存在。

2. Cgroups（当“铁面管家”限制资源） 光看不见还不行，还得防止某个容器把机器资源耗尽。Cgroups（控制组）负责严格限制每个容器最多能用多少 CPU、内存和磁盘 I/O。如果一个容器里的程序出现 Bug 开始狂吃内存，它也只能在自己被分配的额度内折腾，绝不会拖垮整台服务器。

3. UnionFS（像“千层饼”一样分层与复用） 这是 Docker 镜像如此轻巧的秘密。Docker 的镜像是按层叠加的。多个只读层组合在一起，对应用来说就像一个完整的文件系统。当你运行容器时，Docker 只是在最顶层加了一层薄薄的“可写层”。这意味着不同的容器可以共享底层相同的数据（比如大家都用同一个 Ubuntu 基础镜像），极大节省了磁盘空间和启动时间。

总结一下： 传统虚拟机是“带地基建整套房子”，每台都需要独立的操作系统，笨重且启动慢；而 Docker 只是在现有的房子里“打隔断”，所有容器共享同一个底层内核。这就是为什么它极其轻量、能秒级启动、且性能损耗极低的原因。

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

你是一个程序员，你用代码写了一个博客应用服务，并将它部署在了云平台上。

但应用服务太过受欢迎，访问量太大，经常会挂。

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

后来你又上线了商城应用服务和语音应用服务，随着 应用服务变多，需求也千奇百怪。有的应用服务不希望被外网访问到，有的部署的时候要求内存得大于 xxGB 才能正常跑。

你每次都需要登录到各个服务器上，执行 手动 操作更新。不仅容易出错，还贼 浪费时间。

原本就没时间找女朋友的你，现在哭得更大声了。

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

这次我们要加的中间层，叫 Kubernetes。

Kubernetes 的位置

Kubernetes 是什么？

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

k8s 名称的由来

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

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

Kubernetes 架构原理

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

k8s 控制平面和 Node 的关系

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

控制平面内部组件

• 以前我们需要登录到每台服务器上，手动执行各种命令，现在我们只需要调用 k8s 的提供的 api 接口，就能操作这些服务资源，这些接口都由 API Server 组件提供。
• 以前我们需要到处看下哪台服务器 cpu 和内存资源充足，然后才能部署应用，现在这部分决策逻辑由 Scheduler（调度器）来完成。
• 找到服务器后，以前我们会手动创建，关闭服务，现在这部分功能由 Controller Manager（控制器管理器）来负责。
• 上面的功能都会产生一些数据，这些数据需要被保存起来，方便后续做逻辑，因此 k8s 还会需要一个 存储层，用来存放各种数据信息，目前是用的 etcd，这部分源码实现的很解耦，后续可能会扩展支持其他中间件。

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

k8s 控制平面组件

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

Node 内部组件

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

Node 可以是裸机服务器或虚拟机

在文章开头，我们聊到了部署多个应用服务的场景。以前我们需要上传代码到服务器，而用了 k8s 之后，我们只需要将服务代码打包成 Container Image(容器镜像)，就能一行命令将它部署。

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

将容器镜像粗略理解为压缩包

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

一个 pod 内有多个容器

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

所以说 Pod 是 k8s 中最小的调度单位。

Node 调度 Pod

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

控制平面和 Node 的组件

Cluster

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

生产和测试环境

kubectl 是什么

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

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 内应用服务的流程

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

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

总结

• k8s 是 G 家开源的神器，用于管理海量容器服务。
• k8s 集群内分为控制平面和 Node，控制平面是大脑，负责发指令，Node 是手脚，负责执行任务。
• 控制平面内有 API Server，Scheduler，Controller Manager 以及 etcd 等组件。Node 中含有 Pod，Kubelet, Container runtime, Kube Proxy 等组件。控制平面和 Node 共同构成一个 Cluster。
• 文章通过怎么部署服务和怎么调用服务两个例子将这些组件串联了起来，方便大家加深理解。