8图架构图，带大家穿透K8S，实现K8S自由（含视频）

说在前面：

现在拿到offer超级难，甚至连面试电话，一个都搞不到。

尼恩的技术社群（50+）中，很多小伙伴凭借 “左手云原生+右手大数据”的绝活，拿到了offer，并且是非常优质的offer，据说年终奖都足足18个月。

而云原生的核心组件是 K8S，但是 K8S 又很难。

市面上很多的pdf和视频，都是从技术角度来说的，讲的晦涩难懂。

在这里，尼恩从架构师视角出发，利用8张图+视频，对K8S的核心原理做一个宏观的介绍。

带大家穿透K8S，实现K8S自由，让大家不迷路。

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，点这里获取

本文K8S的学习视角：不是普通的视角

尼恩从架构师视角，带大家通过8个图，穿透K8S，实现K8S自由

图0：K8S 的宏观组件架构图

图1：K8S 业务架构图

图2：K8S 元数据架构图

图3：K8S 容器管理流程架构

图4：容器元数据的数据传输架构

图5：容器对外暴露架构图

图6：总的架构图

图7：master 上 APIServer 内部架构图

图8：worker上 kubelet 内部架构图

视频参见视频号： 40岁老架构师-尼恩2

K8S的核心价值：带领大家从 容器管理的石器时代，进入工业时代

首先，回顾一下， 在石器时代，我们是怎么管理容器的：

• docker 命令  （石器时代早期）
• docker 编排  （石器时代晚期期）

图0：K8S 的宏观组件架构图

K8S，是一个围绕容器打造的分布式系统，和其他的分布式系统比如rocketmq、kafka、elasticsearch，其实宏观上非常类似

两个大组件：

• master ：集群管理+元数据管理
• worker（node）：容器的生命周期管理

master上的主要组件是 api-server + 一大堆的控制器

node上主要的组件就是  kubelet （容器管理）+   kube-proxy（流量负载均衡）

具体介绍，请参见前面的视频。

图1：K8S 业务架构图

在尼恩的 3高架构知识宇宙中， 系统的架构，都是从业务架构开始的。

K8S 业务架构：

• 容器元数据管理    （管理镜像地址、资源信息、部署的副本数量、部署的节点信息，对外暴露的端口信息等等）
• 容器什么周期管理 （ 管死管生管过程）

具体如下：

具体介绍，请参见前面的视频。

图2：K8S 元数据架构图

包括：镜像地址、资源信息、部署的副本数量、部署的节点信息，对外暴露的端口信息等等

Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器Service：pod对外服务的统一入口，下面可以维护者同一类的多个podLabel：标签，用于对pod进行分类，同一类pod会拥有相同的标签

Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行

Replication Controller：

Replication Controller 保证了在所有时间内，都有特定数量的Pod副本正在运行，如果太多了，Replication Controller就杀死几个，如果太少了，Replication Controller会新建几个。

和直接创建的pod不同的是，Replication Controller会替换掉那些删除的或者被终止的pod，不管删除的原因是什么（维护阿，更新啊，Replication Controller都不关心）。

基于这个理由，我们建议即使是只创建一个pod，我们也要使用Replication Controller。

Replication Controller 就像一个进程管理器，监管着不同node上的多个pod,而不是单单监控一个node上的pod,Replication Controller 会委派本地容器来启动一些节点上服务（Kubelet ,Docker）。

ReplicaSet：

ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。

在使用时官方推荐ReplicaSet。

Deployment：

为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。

典型的应用场景包括：

• 定义Deployment来创建Pod和ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续Deployment

具体介绍，请参见前面的视频。

图3：K8S 容器管理流程架构

从容器管理的入口， 到最终容器的创建， 具体流程如下图所示：

第一步：用户向APIServer （数据总线）提交一份 部署文件，里边有用户视角的 容器元数据信息

第一步：APIServer 通知 一系列的控制器进行 部署文件处理， 得到最终的  元数据 对象，也就是 资源对象，持久化到 etcd，并且发布到 Node节点的 kubelet组件

第三部：Node节点的 kubelet组件判断是否属于自己管理的容器，如果是，则进行容器的创建

创建容器时，主要用到下面三个接口

(1)CRI（Container Runtime Interface）：

容器运行时接口，提供计算资源。

kubernetes1.5版本之后，kubernetes项目推出了自己的运行时接口api–CRI(container runtime interface)。

(2)CNI（Container Network Interface）：

容器网络接口，提供网络资源。

是和 CoreOS 主导制定的容器网络标准，它本身并不是实现或者代码，可以理解成一个协议。CNI旨在为容器平台提供网络的标准化。容器平台可以从CNI获取到满足网络互通条件的网络参数(如IP地址、网关、路由、DNS等)。

(3)CSI（Container Storage Interface）：

容器存储接口，提供存储资源。

由 kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。

kubernetes 1.9 版为alpha阶段-->kubernetes 1.10版为beta阶段-->kubernetes 1.13 GA。

具体介绍，请参见前面的视频。

图4：容器元数据的数据传输架构

内部的 api server 和 kublet 客户端 组件之间， 通过 长短链接 相结合的方式，完成高性能数据传输：

• 长连接：进行增量元数据 推送 ，  推模式
• 短连接：进行全量元数据 拉取 ，  推模式

具体介绍，请参见前面的视频。

图5：容器对外暴露架构图

两个阶段：

• 元数据对象创建的阶段：完成容器的选择， 容器清理的建立，以及端口的映射
• 流量路由阶段：由 kube-proxy组件 进行 流量的分发，和 pod 之间的负载均衡

具体介绍，请参见前面的视频。

图6：总的架构图

有了前面的基础之后，来一个总的架构图

K8S，是一个围绕容器打造的分布式系统，和其他的分布式系统比如rocketmq、kafka、elasticsearch，其实宏观上非常类似

两个大组件：

• master ：集群管理+元数据管理
• worker（node）：容器的生命周期管理

master上的主要组件是 api-server + 一大堆的控制器

node上主要的组件就是  kubelet （容器管理）+   kube-proxy（流量负载均衡）

另外通过etcd 进行元数据的持久化。

具体介绍，请参见前面的视频。

图7：master 上APIServer 内部架构图

Kube-APIServer是Kubernetes最重要的核心组件之一，主要提供以下功能：

• 提供集群管理的RESTAPI接口，包括∶认证Authentication、 授权Authorization、准入Admission（Mutating&Valiating）。

• 提供其他模块之间的数据交互和通信的枢纽（其他模块通过APIServer查询或修改数据，只有APIServer才直接操作etcd）。

• APIServer提供etcd数据缓存以减少集群对etcd的访问。

APIServer对请求的处理流程，采用了类似 责任链 模式的架构， 由很多的处理器组成：

（1）APIHandler：APIServer 本质上是一个 RestServer，那么就需要注册不同对象的Handler

（2）AuthN：认证，除了可以使用Kubernetes 自带的认证机制外，还可以使用 webhook自己定义一些认证机制。当配置了外部的认证机制后，认证请求就可以被转发到外部去，这样就可以去集成企业统一的认证平台

（3）Rate Limit：限流

（4）Auditing：审计，所有的操作都会生成一条日志记录

（5）AuthZ：认证，可以使用 k8s 自带的 RBAC（role-base access control），也可以使用 webhook 自定义

（6）Aggregator：

可以像 nginx 一样做路由配置，如果 APIServer 是标准的 K8S APIServer，就会走默认的 K8S APIServer，包括Mutating、Validation等；

如果是自定义的 APIServer，就会走Aggregated APIServer（自定义、独立部署的 APIServer），包括自定义的Mutating、Validation等。

（7）Mutating：变形，可以加一些属性

（8）Validating：验证，加完属性后再做一些验证

图8：worker上 kubelet内部架构图

Kubelet 将 容器运行时， 容器网络和   容器存储抽象成了CRI，CNI,CSI。

主要的工作为：

（1）Kubelet 是node上　Kubernetes的初始化系统（init system）

（2）Kubelet 从不同源获取Pod清单，并按需求启停Pod的核心组件：

• 可从本地文件目录获取Pod 清单

• 从给定的HTTPServer或Kube-APIServer等源头获取Pod 清单；

（3）Kubelet负责汇报当前节点的资源信息和健康状态；

（4）Kubelet负责Pod的健康检查和状态汇报。

有关K8S 技术自由，更多的内容请参见

• 《尼恩 K8S  学习圣经》
• 前面视频末尾，所提到到的 配套  pdf 电子书
• 尼恩Java 面试宝典里边 的 K8S 面试真题，含几个核心 的大厂真题

End

硬核文章推荐            

硬核电子书            

👍《尼恩Java面试宝典》（极致经典，不断升级）全网下载超过300万次

👍尼恩Java高并发三部曲：全网下载超过200万次

• 👍《Java高并发核心编程-卷1（加强版）》，不断升级

• 👍《Java高并发核心编程-卷2（加强版）》，不断升级

• 👍《Java高并发核心编程-卷3（加强版）》，不断升级

👍《顶级3高架构行业案例 + 尼恩架构笔记 》N 篇+，不断添加

👍100份简历模板