如何快速理解Kubernetes的核心概念？

Kubernetes 是一个非常复杂的平台，网上的资料文档很多，但是很杂。Kubernetes.io 上面有官方的文档，但是很多学员看了官方文档会犯晕，因为文档内容多，而且密度很大，很难一下子抓住关键概念，但是只有理解了这个 Kubernetes 的核心的概念，并且在大脑里头呢建立起这个 Kubernetes 平台的这个概念模型，才能运用好这个 Kubernetes。

为此，我把这个 Kubernetes 最基本的核心概念给梳理出来，下面依次给大家来讲解。

Kubernetes 集群（Cluster）

Kubernetes 第一个核心概念叫集群。这个集群呢有很多的节点组成，而且可以按需添加更多的节点，这个节点可以是物理机，也可以是虚拟机，每个节点都有一定数量的这个 CPU 和内存容量。

整个这个 Kubernetes 集群可以抽象看作是一个超大计算机，它的 CPU 和内存容量是所有节点的这个 CPU 和内存容量的总和。而且可以按需给这台超大计算机添加更多的 CPU 和内存。

容器 Container

Kubernetes 是一个容器调度平台，所以容器是 Kubernetes 平台的一个基本概念。理解容器并不难，关键是两点，一个是打包机制，背后是有容器镜像，Image机制来实现的。另外一个呢是隔离，背后是有 Linux Namespace，还有 CGroups这些机制来实现的。

容器经常被翻译比喻成这个集装箱，这个比喻很形象，集装箱是用来打包和运输货物的，而且可以相互隔离。

在我的大脑里头，我经常把这个容器和家里的这个货物贵联系起来，货物柜里头可以装各种东西，而且一个个货物贵隔离摆放。软件容器是用来打包和运行应用的，里头可以跑各种语言栈的应用，容器之间通过轻量级的机制，也就是 Linux 的 Namespace ，然后 CGroups 进行隔离。

从这个宿主机操作系统的视角来看，容器其实是一个一个的进程。那么从容器内部视角来看，他感觉自己就是一个完整的操作系统，有自己的这个文件系统、网络，还有CPU、Memory 这些资源，容器是镜像的运行时的实例。

镜像它是 OS文件系统，加上应用文件，加上依赖的一个打包。镜像可以认为是容器的模板，这是第二个概念容器。

POD

我们再来看第三个概念 POD， Kubernetes 并没有直接调度容器，而是在外面在封装了一个概念叫 POD。POD 是 Kubernetes 的基本调度单位，POD 在英文当中是豌豆夹的意思，一个POD 在里头可以跑一个或者是多个容器，它们共享这个 POD 的文件系统和网络，每个 POD 的有独立的 IP，POD 中的容器共享这个 IP 和端口空间，并且可以通过这个 localhost 相互访问。

大部分场景下，一个 POD 的里头一般只跑一个应用容器，Kubernetes 并没有直接调度Docker 容器，而是增加了这个 POD 的封装。一个原因是考虑一些需要辅助容器的场景。比方说有些需要这个 sidecar 的这个场景。另外一个原因是考虑可以替换使用不同的容器技术。

副本集 ReplicaSet

那么下面我们再来看另外一个概念，叫副本集。 一个应用发布的时候，一般不会只发一个 POD 的实例，而是会发多个 POD 的实力，这样才能实现这个高可用。副本集 Replicaset 就是和一个应用的一组 POD 的相对应的一个概念。

它可以通过模板，一般是这个 YAML 或者是 JSON 文件规范的模板，来规范某个应用的这个容器的镜像、端口、副本数量、点火和健康检查机制、环境变量、volume 挂载等等的一些信息。

运行的时候 ReplicaSet 会监控和维护 POD 的数量，如果 POD 的多了，他会下线一些 POD 的，如果 POD 的少了，他又会启动一些 POD 的。

那么值得提一下的是 Kubernetes 之前还有一个叫 ReplicationController 的一个类似的概念，但是这个概念已经被逐步的废气，被这个 Rebeccaset 所替代。这是副本集replica set。

服务 Service

那么下面有一个重要概念叫服务service，POD 的在这个 Kubernetes 中是一个 ephemeral 的这个概念，英文叫 ephemeral ，中文意思就是说它是不固定的，这个 POD 的有可能随时会挂或者是重启，有可能是预期的或者是非预期的。

那么相应的 IP 就会随着变，如果一个服务实例的 IP 不固定，随时可能会变。那么服务的消费方如何寻址呢？Kubernetes 中，通过引入这个 Service 的抽象来解决这个问题。

简单讲，Service 是屏蔽的应用的 IP 寻址和负载均衡这些细节，消费方可以通过无名访问目标服务，Kubernetes 的 Service 底层机制会做寻址和负载均衡。即使这个应用的 POD 的 IP 发生了变更，Service 时也会屏蔽这种变更，让消费方无感知 Service。为是是这个 Kubernetes 中非常重要的一个概念。

发布 Deplment

副本集可以认为是一种基本的发布机制。通过这个 ReplicaSet 副本集，可以实现基本的应用发布，也可以实现高级的发布功能，比方说可以做出这个金丝雀、蓝绿和滚动发布。但是通过这个 ReplicaSet 做这些高级功能呢，操作起来比较繁琐。为了简化这些高级的发布，在 ReplicaSet 的基础上，Kubernetes 又引入了这个 Deployment 这个概念。

简单讲，Deployment 是用来管理这个ReplicaSet，实现蓝绿和滚动这些高级发布机制的。下图给出了一个通过 Deployment 调度实现滚动发布的一个样例。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aMRMHpBo-1618158836181)(img/image-20210210163227106.png)]

假设应用 1.0绿色的版本已经发布了，对应的 ReplicaSet 是 V1.0。然后我们可以通过这个Deployment 进行升级发布应用的 V1.1版本。Deployment 就会创建 ReplicaSet V1.1，之后Deployment 会依次调度，不断的这个拉入这个蓝色版本的，拉出绿色版本，直到所有的蓝色 POD 的全部上线，绿色 POD 的全部下线为止。这个过程中，Service 这个抽象会屏蔽应用地址的变更，让消费方 Client 无感知。如果在滚动发布过程当中，蓝色的 POD 的有问题。点火健康检查不通过，那么 Deployment 会自动终止啊并回退发布，即使发布成功完成，后续根据需要发布人员仍然可以通过这个Deployment 回退到之前的某个版本。所以 Deployment 是一种更灵活的发布机制。

特别要强调一下，Deployment 和 Service 适合这个应用发布相关的两个最重要的概念。也是发布过程当中，经常要使用的这两个概念。

我们发布应用的时候，所要书写的这个发布描述文件里头主要就是 Deployment 和 Service 的规范。所以这两个概念必须完全理解。

下面我再总结一下这两个重要概念。Deployment 是基于ReplicaSet 之上的一个概念，发布应用的时候，Deployment 会创建 ReplicaSet 。ReplicaSet 根据规范创建应用的 POD 的实例，并且维护和保证实力数量，升级的时候，Deployment 会创建新的 ReplicaSe，调度实现滚动发布，也是可以实现这个发布回退这些功能。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LMl1s5RO-1618158836185)(img/image-20210210164607677.png)]

上图给出了两个应用 A 和 B 的发布，分别有两组 Deployment 、ReplicaSe 来管理和控制。Service 是服务间相互路由寻址的概念，首先 Kubernetes 集群内部的企业 Client，通过 Service 间接访问目标应用 POD 的。其次，Kubernetes 集群外部的这些 Client ，如果要访问集群内部应用 POD 的的话，也是通过这个 Service 间接的访问。

ConfigMap VS Secret

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8fu0Eq56-1618158836188)(img/image-20210210165130541.png)]

微服务在上线的时候，常常需要设置一些可变配置，这些配置针对不同的环境对应的配置值可能还是不同的。这些配置有些是在启动期一次性配置好的，比如说数据库连接字符串，还有一些配置可以在运行期动态的调整，比方说这个缓存的过期时间 TTL 值，业务的促销的商品限购数量等等。

所以微服需要配置中心的支持，实现这个针对不同环境的灵活的动态配置。Kubernetes 平台是内置支持微服配置的，对应的概念叫 ConfigMap。开发人员将配置写在这个 ConfigMap 当中。Kubernetes 支持将这个 ConfigMap 当中的配置，以环境变量的形式注入到这个 POD 的当中。这样 POD 的当中的应用就可以以环境变量形式去访问这些配置。

ConfigMap 也支持以存储卷 Volume 的形式挂载到这个 POD 的当中，这样 POD 的中的应用就可以以本地配置文件形式去访问这些配置，有些配置是涉及敏感数据的，比方说这个用户名、密码、安全证书等等。Kubernetes 通过这个 Secret 的概念支持敏感数据的配置。Secret 可以认为是一种特殊的 config，它提供更安全的配置存储和访问机制。

DaemonSet

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5NXdDA4S-1618158836193)(img/image-20210210170226008.png)]

有一种这种场景是微服当中经常会碰到的，就是需要在每个节点上常驻一个守护进程，daemon进程。比方说监控场景，需要在每个机器上部署一个 fluentd 日志采集进程，或者是 prometheus 的 exporter 进程。针对这种场景，Kubernetes 支持一个叫 DaemonSet 的发布概念，可以在每个 Woker 节点上部署一个守护进程 POD 的，并且保证每个节点上有，且仅有一个这样的 POD，这是 DaemonSet 介绍。

那么前面介绍的都是 Kubernetes 中最基础和重要的概念。如果掌握了前面的这些概念，那么Kubernetes 的基本应用应该可以说不成问题的，基本上可以覆盖大部分的这个 Kubernetes 的应用场景。除了上面的这些核心概念，Kubernetes 还有其他的一些概念作为参考，我把他们一起列出来。

其他概念

Volume 存储卷抽象，简单可以理解为磁盘文件存储，可以是节点本地文件存储，也可以是远程存储，挂在 Mount 之后， Volume 成为这个POD 的一部分，POD 销毁，Volume 也销毁，但是支持 Volume 的背后的存储可以还是存在的。

PersistentVolume 持久卷，如果 Volume 只用节点本地文件存储，那么下次应用启动 POD 的时候，可能换了一个节点，相应的这个文件存储就不存在了。那么持久卷简称 PV，是一种高级的存储资源的抽象，它可以对接各种云存储，一般有集群管理员统一配置。如果把 Kubernetes 集群看作一个超大计算机，那么 PV 就可以看作是可以灵活插到这台超大计算机上的超大磁盘。如果使用 PV 挂载了这个 Volume 以后，那么应用 POD 即使重启了 Volume 上的数据不丢继续存在，

PersistentVolumeClaims是应用申请 PV 的时候，需要填写的规范，包括磁盘大小类型等等。
啊，简称 PVC。应用通过这个 PVC 去申请这个 PV 资源。然后以 Volume 的形式挂载到 POD 的当中。PV 的引入使得 Volume 和具体的物理存储可以进一步的解耦。

StatefulSet 顾名思义是支持有状态应用的一种发布机制。比方说 MySQL 数据库或者是 Redis 缓存的发布。它是跟这个 ReplicaSet 相对的一个概念，StatefulSet 是有状态的发布，那么ReplicaSet 是支持无状态应用的发布。

Job 很简单，它是支持跑一次就结束的任务。

CronJob 是支持周期性跑的任务。

总结

Cluster 集群，简单可以理解为超大计算机抽象由节点所组成。

Container 容器应用居住和运行在容器当中。

POD 它是 Kubernetes 基本的调度单位。

ReplicaSet 它是创建和管理 POD 的，支持无状态应用的发布。

Service 是它是应用 POD 的访问点啊，屏蔽 IP 寻址和负载均衡的。

Deployment 管理 ReplicaSet 支持滚动这些高级发布机制。

ConfigMap VS Secrets，ConfigMap 是普通配置，Secrets 是敏感数据配置。

DaemonSet 保证每个节点上有且仅有一个这样的 POD 的，常用于监控。

StatefulSet 类似 ReplicaSet ，但是支持有状态应用。

Job 运行一次就结束的任务。

CronJob 周期性运行的任务。

Volume 可装载的磁盘文件存储。
PrsistentVolume/PersistentVolumeClaims 超大磁盘存储的一个抽象以及相应的分配机制。