在零碎介绍了如何理论部署一个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中波及的那些技术点和各种难记的名词一一解释分明显然是不可能的，咱们的想法是让大家通过一步一步理解整个云生态的演化过程，从而最终了解整个我的项目。

最初想送给大家一句话：

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

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

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

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

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

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