引言

虚拟化技术允许在单个物理服务器的CPU上运行多个虚拟机，同时应用程序在虚拟机之间隔离，提高了一定程度的安全。虚拟化技术具有伸缩性，更好地利用了物理服务器上的资源，可轻松地添加或更新应用程序，降低硬件成本等优点。

容器类似于轻量级虚拟机，但具有被放宽的隔离属性，可以在应用程序之间共享操作系统。自身也具有的文件系统、CPU、内存、进程空间等。由于其与基础架构分离，因此可以跨云和操作系统发行版本之间进行移植。

本论文查阅最新的Kubernetes文献、文档资料，梳理基础架构与技术实现原理，从Kubernetes是什么，为什么是Kubernetes角度对Kubernetes架构进行阐述。

第1章 概述

1.1 Kubernetes是什么

1.1.1构成

Pod是Kubernetes中最小的可互动单元。一个Pod可由多个容器组成，这些容器共同部署在单个节点上形成一个单元。一个Pod具有一个IP，该IP在其容器之间共享[[1]]。

Node（节点）是机器，是Kubernetes用于部署Pod的虚拟机。Node为Kubernetes提供可用的集群资源用于以保持数据、运行作业、维护工作负载、创建网络路由等^[1]。

Label（标签）是Kubernetes及其最终用户用于过滤系统中相似资源的方式，也是资源之间相互访问或关联，不论是监控、日志、调试或是测试，任何Kubernetes资源都应打上标签，以方便于后续查验^[1]。

Annotation（注释）与标签十分相似，但通常用字符串形式保存不同对象的元数据。

Deployment（部署）可持续地部署新软件，这是一组描述特定运行工作负载新需求的元数据。在Kubernetes中部署软件可使用替换或滚动升级策略。

DaemonSet（守护进程集）为Kubernetes创建工作负载，为了从各个节点收集日志，其代理需要运行在所有节点上，但每个节点只需要一个实例。

StatefulSet（有状态集）用于需要在整个生命周期内使用同一节点的应用程序的部署，以及负责管理Pod上连接的磁盘PersistentVolumeClaim。

Job（任务）的工作是生成容器来完成特定的工作，并在成功完成时销毁。

Secret（机密配置）与正常的配置条目类似，只是会进行加密以防类似密钥、密码、证书等敏感信息的泄漏。

Service Discovery（服务发现），所有Pod使用了一个自定义的DNS服务器，通过解析其他服务的名称以获取其IP地址和端口。

ConfigMap（配置映射）是一个环境变量键值列表，会被传递给正在运行的工作负载以确定不同的运行时行为。

Storage（存储），Kubernetes在存储之上添加了一层抽象。工作负载可以为不同任务请求特定存储，甚至可以管理超过Pod生命周期的持久化。

ReplicaSet（副本集）负责扩展和复制的层。该层以副本的数量表示系统的期望状态，并在任意给定时刻保持该系统的当前状态。

1.1.2 插件

插件使用Kubernetes资源，如DaemonSet、Deployment等，以实现和扩展集群功能，如网络和网络策略、服务发现、可视化管理、基础设施等所需求的功能。又因为这些插件提供集群级别的功能，插件中命名空间域的资源属于kube-system的命名空间。

1.1.3 API

Kubernetes控制平面的核心即是API Server。API Server负责提供HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

Kubernetes API可以查询和操纵Kubernetes API中对象，如Pod、Namespace、ConfigMap、Event的状态。

大部分操作都可以通过kubectl命令行接口或kubeadm命令行工具来执行，这些工具亦是通过调用API实现功能，也可以使用REST调用来访问这些API。

1.2 为什么是Kubernetes

1.2.1 Kubernetes优点

Kubernetes可以使用DNS名称或IP地址公开容器，也可以通过负载均衡分配网络流量，如CoreDNS是一种灵活的、可扩展的DNS服务器，可以安装该插件为集群内的Pod提供DNS服务。同时，Kubernetes允许自动挂载所选的存储系统上。

Kubernetes具备良好的鲁棒性，对于出现的故障容器，能够进行自我修复，同时报告给客户端。

在安全性问题上，无需在堆栈配置中暴露密钥，无需重建容器镜像的情景下完成部署和更新密钥和应用程序配置。

Docker的直译是“码头工人”，而Kubernetes源于希腊语，意为“舵手”。但是Kubernetes不仅可以进行自动部署和回滚，以及自动装箱计算。当Kubernetes把Pod调度到节点上，节点上的Kubelet会指示Docker启动特定的容器。接着，Kubelet会通过Docker持续地收集容器的信息，然后提交到Master节点上。Docker即可正常拉取容器镜像、启动或停止容器。不同点在于这是由自动化系统控制而非管理员在每个节点上手动操作的。

1.2.2 Kubernetes与PaaS区别

Kubernetes区别于PaaS：PaaS为平台即服务，其对资源的抽象层次更进一步，提供用户应用程序的运行环境，如Google App Engine。PaaS自身负责资源的动态扩展和容错管理，用户应用程序不必过多考虑节点间的配合问题。Kubernetes不仅提供了PaaS产品中部署、扩展、负载均衡、日志记录和监控等普适的功能，而且Kubernetes并非单体体系：

一、不限制支持的应用程序类型，Kubernetes旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载；

二、不提供应用程序级别的服务作为内置服务，如中间件、数据处理框架、数据库、缓存、集群存储系统。组件即可在Kubernetes上运行，并由运行在Kubernetes上的应用程序通过可移植机制来访问；

三、不要求日志记录、监视或警报解决方案，可通过插件方案解决；

四、支持DevOps，无需部署源代码和构建应用程序。也不要求提供配置语言或系统。相对的Google App Engine只允许使用Python和Java语言、基于Django的Web应用框架、调用Google App Engine SDK来开发在线应用服务[[2]]；

五、不提供也不采用任何全面的机器配置、维护、管理，如果在这过程中如果出现故障，借助镜像仓库的过往版本的镜像进行自我修复[[3]]；

六、Kubernetes不仅是一个编排系统，而且消除了编排的需要。编排的技术定义是执行已定义的工作流程，依次执行。相比之下，Kubernetes包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。执行过程的方式无关紧要，也无需集中控制，这使得系统更易于使用且功能更强大、系统更健壮、更为弹性，以及可扩展。

第2章 Kubernetes架构

2.1 组件

一个Kubernetes集群由一组被称作节点的机器组成。这些节点上运行Kubernetes所管理的容器化应用。

集群至少具有一个工作节点,工作节点托管作为应用负载的组件的Pod。控制平面管理集群中的工作节点和Pod。为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群也跨多个节点运行。

图2-1 Kubernetes集群中的组件构成

2.1.1 Control Plane Components（控制平面组件）

控制平面的组件，又称为Master组件。对集群做出全局决策，以及检测和响应集群事件。

控制平面组件可以在集群中的任何节点上运行，通常会在同一个计算机上通过设置脚本启动所有控制平面组件。如图1-1所示，其构成：

一、API server（接口服务器）是Kubernetes控制平面前端，该组件公开了Kubernetes API。主要实现验证并配置API对象的数据，包括了Pods、Services、Replication Controllers等。并为REST操作提供服务，以及为集群的共享状态提供前端，所有其他组件都通过该前端进行交互。其在设计上考虑了水平伸缩，可通过部署多个实例进行伸缩，通过运行API Server的多个实例，以平衡实例之间的流量。

二、Scheduler运行在Master节点，其核心功能是监听API Server来对每一个新创建的Pod或者是未被调度的Pod，会选择一个最优的Node去运行该Pod。

三、Etcd是兼具一致性和高可用性的键值数据库，可以作为保存Kubernetes所有集群数据的后台数据库。容器中的数据是非永久性保存的，由此，Kubernetes提供Persistent Volume（持久性存储）,不仅支持NFS等多种类型的网络文件系统，也同样对Azure、AWS等云存储支持，以解决数据的保存和恢复问题[[4]]。

四、Controller Manager（控制器），运行控制器进程的控制平面组件，从逻辑上讲，每个控制器都是一个单独的进程，但为降低复杂性，使用控制器都被编译到同一个可执行文件，并在一个进程中运行。其包括了：

（一）Node Controller（节点控制器）：其负责的工作，(1)在启动CIDR分配的情况下，为该节点分配一个CIDR区段。(2)保持节点控制器内的节点列表与云服务商所提供的可用机器列表同步。(3)负责在节点出现故障时进行通知和响应；

（二）Job Controller（任务控制器）：监测代表一次性任务的Job对象，然后创建Pods来运行这些任务直至完成；

（三）Endpoints Controller（端点控制器）：填充端点对象，即加入Service与Pod；

（四）Service Account（服务帐户）和Token Controllers（令牌控制器）：为新的Namespace（命名空间）创建默认帐户和API访问令牌。

五、Cloud Controller Manager（云控制器管理器）是指嵌入特定云的控制逻辑的控制平面组件。使用者的集群连接到云提供商的API之上，并将与该云平台交互的组件，同与使用者集群交互的组件分离开来。仅运行特定于云平台的控制回路。其所包括的控制器：

（一）Node Controller：Cloud Controller Manager同样有节点控制器，用于在节点终止响应后检查云提供商以确定节点是否已被删除；

（二）Route Controller（路由控制器）：用于在底层云基础架构中设置路由；

（三）Service Controller（服务控制器）：用于创建、更新和删除云提供商负载均衡器。

Cloud Controller Manager与Controller Manager具有共同之处，但前者并非必需的，不仅将若干逻辑上独立的控制回路组合到同一个可执行文件中，以同一进程的方式运行，也可以对其执行水平扩容以提升性能或者增强容错能力。

2.1.2 Node Components（节点组件）

节点组件在每个节点上运行，维护运行的Pod并提供Kubernetes运行环境。如图1-1所示，其构成：

一、Kubelet是一个在集群中每个节点上运行的代理，保证了容器都运行在Pod中。接收一组通过各类机制所提供的PodSpecs，并确保运行状态且正常。

二、Kube-proxy是集群中每个节点上运行的网络代理，实现Kubernetes服务概念的一部分。Kube-proxy维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与Pod进行网络通信。

三、CRI（容器运行时接口）是一个插件接口，使Kubelet能够使用各种容器运行时，而无需重新编译集群的组件。

2.2 GC（垃圾回收机制）

该机制对于失败的Pods、已完成的Jobs、没有使用者引用的对象、未使用的容器和镜像、节点租用对象等进行清理集群资源。

结论

近年来，云计算飞速发展，以Docker为代表的容器技术成为新兴事物，逐步占据市场，容器技术解决了一次构建，即可到处运行，又相对虚拟机又是更快的轻量级产品。

当前，中国联通通过Kubernetes将资源利用率提高了20至50%，降低了IT基础设施成本，部署从过去的几小时缩至5到10分钟；而华为已将30%的应用程序迁移到Kubernetes上运行；京东从2016年开始从OpenStack过渡到Kubernetes,现在运行着全球最大的Kubernetes集群。

Kubernetes是当今基于容器技术的分布式架构的领先方案，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

 

参考文献