在零碎介绍了如何理论部署一个 K8S 我的项目后，作为本系列文章的最初一篇，咱们一起来看看 Kubernetes 集群内容总览，再对一些更深层次的性能进行总结。

Kubernetes 总览

下图是一个 k8s 的总览构造内容

能够看到图中提到的这些功能模块中，还有一些是在本文中并没有呈现的：

l  ConfigMap

用来存储用户配置文件定义的，通过其外部的 Volume 投射技术实现，其实也是 Volume 挂载的一种形式。这种形式不仅能够实现应用程序被的复用，而且还能够通过不同的配置实现更灵便的性能。在创立容器时，用户能够将应用程序打包为容器镜像后，通过环境变量或者外接挂载文件的形式进行配置注入。

l  Secret

Secret 对象类型用来保留敏感信息，例如明码、OAuth 令牌和 SSH 密钥。将这些信息放在 Secret 中比放在 Pod 的定义、容器镜像中、绝对于 ConfigMap 说更加平安和灵便。Secret 是规范的 k8s 资源对象，应用办法和 ConfigMap 十分相似。同时咱们能够对 Secret 进行访问控制，避免秘密数据被拜访

l  PV

PVC 是 Kubernetes 中长久化数据卷的实现形式，它是 StatefulSet 的外围性能，也是 Pod 长久化的必要伎俩，Kubernetes 通过 PV 和 PVC 拆分，从而达到性能点的解耦。

除了文中提到的内容之外，Kubernetes 集群的内容也远比咱们目前看到的简单的多，也还有很多内容期待着咱们摸索。

在这里，咱们对这些深层次的性能做一个总结，也是一个对深刻学习 Kubernetes 的梳理。

Kubernetes 组件

咱们平时做开发的过程中所应用的服务器（即宿主机），在 Kubernetes 集群中被称为 Node 节点。

同时在 Kubernetes 中存在一个或者多个 Master 节点管制多个宿主机实现集群，整个 Kubernetes 的外围调度性能根本都在 Master 节点上。

Kubernetes 的次要性能通过五个大组件组成：

1. kubelet：装置在 Node 节点上，用以管制 Node 节点中的容器实现 Kubernetes 的调度逻辑
2. ControllerManager：是咱们上述所讲的控制器模式的外围治理组件，治理了所有 Kubernetes 集群中的控制器逻辑
3. API Server：服务解决集群中的 api 申请，咱们始终写的 kubectl，其实就是发送给 API Server 的申请，申请会在其外部进行解决和转发
4. Scheduler：负责 Kubernetes 的服务调度，比方控制器只是管制 Pod 的编排，最初的调度逻辑是由 Scheduler 所实现并且发送申请给 kubelet 执行的
5. Etcd：这是一个分布式的数据库存储我的项目，由 CoreOS 开发，最终被 RedHat 收买成为 Kubernetes 的一部分，它外面保留了 Kubernetes 集群中的所有配置信息，比方所有集群对象的 name，IP，secret，configMap 等所有数据，其依附本人的一致性算法能够保障在零碎中疾速稳固的返回各种配置信息，因而这也是 Kubernetes 和心中的外围组件

定制化性能

除了各种弱小的组件性能之外，Kubernetes 也给用户提供了极高的自由度。

为了实现这种高度的自在，Kubernetes 给用户提供了三个公开的接口，别离是：

l  CNI（Container Networking Interface，容器网络接口）：其定义了 Kubernetes 集群所有网络的链接形式，整个集群的网络都通过这个接口实现。只有实现了这个接口内所有性能的网络插件，就能够作为 Kubernetes 集群的网络配置插件，其外部包含宿主机路由表配置、7 层网络发现、数据包转发等等都有各式各样的小插件，这些小插件还能够随便配合应用，用户能够依照本人的需要自在定制化这些性能

l  CSI（Container Storage Interface，容器存储接口）定义了集群长久化的一些标准，只有是实现这个接口的存储性能，就能够作为 Kubernetes 的长久化插件
l  CRI（Container Runtime Interface，容器运行时接口）：在 Kubernetes 的容器运行时，比方默认配置的 Docker 在这个集群的容器运行时，用户能够自由选择实现了这个接口的其余任意容器我的项目，比方之前提到过的 containerd 和 rkt

这里讲一个乏味的点：CRI。

Kubernetes 的默认容器是 Docker，然而因为我的项目初期的竞争关系，Docker 其实并不满足 Kubernetes 所定义的 CRI 标准，那怎么办呢？

为了解决这个问题，Kubernetes 专门为 Docker 编写了一个叫 DockerShim 的组件，即 Docker 垫片，用来把 CRI 申请标准，转换成为 Docker 操作 Linux 的 OCI 标准（对，就是第二局部提到的那个 OCI 基金会的那个标准）。然而这个性能始终是由 Kubernetes 我的项目保护的，只有 Docker 公布了新的性能 Kubernetes 就要保护这个 DockerShim 组件。

于是，这个近期的音讯——Kubernetes 将在明年的版本 v1.20 中删除删除 DockerShim 组件，意味着从明年的新版本开始，Kubernetes 将全面不反对 Docker 容器的更新了。

但其实这对咱们一般开发者来说可能并没有什么影响，最坏的后果就是咱们的镜像须要从 Docker 换成其余 Kubernetes 反对的容器镜像。

不过依据这这段时间各个云平台放出的音讯来看，这些平台都会提供对应的转换措施，比方咱们还是提供 Docker 镜像，平台在公布运维的时候会把这些镜像转换成其余镜像；又或者这些平台会自行保护一个 DockerShim 来反对 Docker，都是有解决方案的。

架构总览与总结

这一部分咱们来看看 Kubernetes 的架构图：

通过这一系列的学习，作为一个一般程序员，不得不赞叹 Google 对编码这件事得深厚与极致，框架中因为太多仅因为解耦而产生的组件，并且还提供了这么大的自由度，不得不说是咱们活字格开发团队学习过程中遇到的一个很有技术深度的框架。

但这种过高的自由度也有负面作用。

在部署过程中，Kubernetes 集群的复杂度十分高，部署一个满足生产环境需要的 Kubernetes 框架更是难上加难，网上还有专门卖 Kubernetes 生产环境集群部署的脚本程序，可见 Kubernetes 零碎的宏大。

在学习的过程中能够应用 kinD 或者 minikube 在本地以 Docker 的模式模仿一个 Kubernetes 集群，然而这种水平的学习间隔生产环境还是有肯定的差距。

总结

这个系列文章，具体的形容了咱们活字格开发团队入地过程中碰到的几个难啃的神仙。

从云平台的倒退到 k8s 的具体应用，一步一步抽丝剥茧地向大家解释了一个云平台，从最后的虚拟机，到 PaaS 雏形，到 Docker 容器化，再到最终 Kubernetes 的状态的适度和演变。

人的记忆是须要依赖于前驱节点的，仅仅通过一篇文章就想把 Kubernetes 中波及的那些技术点和各种难记的名词一一解释分明显然是不可能的，咱们的想法是让大家通过一步一步理解整个云生态的演化过程，从而最终了解整个我的项目。

最初想送给大家一句话：

纸上得来终觉浅，绝知此事要躬行。

在咱们开发组成员第一遍看完这些文档之后感觉本人曾经齐全把握了，然而在理论的文档撰写过程中，才发现自己两眼一抹黑，不晓得从何开始。

太多的知识点只停留在据说过，仅仅晓得是什么的阶段。在这里还是倡议大家动起手来，试试文中提到的实例，咱们置信在本人入手写过一遍之后，你会对这些内容不一样的了解。

尽管本系列文章曾经完结，但在后续的内容中咱们也会持续为大家讲述更多葡萄城中新老葡萄在工作过程中遇到的各种技术揭秘、分享。

感觉内容不错点个赞再走吧~

转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。