Kubernetes功能简介

什么是Kubernetes

Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。通过Kubernetes你可以：
 快速部署应用
 快速扩展应用
 无缝对接新的应用功能
 节省资源，优化硬件资源的使用
注：K8s是将Kubernetes的8个字母“ubernete”替换为“8”的缩写。

Kubernetes 特点

 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
 可扩展: 模块化, 插件化, 可挂载, 可组合
 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展
Kubernetes是Google 2014年创建管理的，是Google 10多年大规模容器管理技术Borg的开源版本。
为什么选择容器?
为什么要使用容器？通过以下两个图对比：

传统的应用部署方式：
1、 通过插件或脚本来安装应用；
2、 应用的运行、配置、管理、所有生存周期与当前操作系统绑定；
3、 不利于应用的升级更新/回滚等操作；
4、 也可以通过创建虚机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。
容器方式部署应用：
• 每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源；
• 相对于物理机和虚拟机，容器能快速部署；
• 由于容器与底层设施、机器文件系统解耦，所以它能在不同云、不同版本操作系统间进行迁移。
• 容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系
• 使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。
• 类似地，容器比虚机轻量、更“透明”，这更便于监控和管理。
容器优势总结：
 快速创建/部署应用：与VM虚拟机相比，容器镜像的创建更加容易。
 持续开发、集成和部署：提供可靠且频繁的容器镜像构建/部署，并使用快速和简单的回滚(由于镜像不可变性)。
 开发和运行相分离：在build或者release阶段创建容器镜像，使得应用和基础设施解耦。
 开发，测试和生产环境一致性：在本地或外网（生产环境）运行的一致性。
 云平台或其他操作系统：可以在 Ubuntu、RHEL、 CoreOS、on-prem、Google Container Engine或其它任何环境中运行。
 Loosely coupled，分布式，弹性，微服务化：应用程序分为更小的、独立的部件，可以动态部署和管理。
 资源隔离
 资源利用：更高效

使用Kubernetes能做什么？

可以在物理或虚拟机的Kubernetes集群上运行容器化应用，Kubernetes能提供一个以“容器为中心的基础架构”，满足在生产环境中运行应用的一些常见需求，如：
 多个进程（作为容器运行）协同工作。（Pod）
 存储系统挂载
 分发敏感文件
 应用健康检测
 应用实例的复制
 Pod自动伸缩/扩展
 服务发现
 负载均衡
 滚动更新
 资源监控
 日志访问
 调试应用程序
 提供认证和授权

Kubernetes不是什么？

Kubernetes并不是传统的PaaS（平台即服务）系统。
 Kubernetes不限制支持应用的类型，不限制应用框架。Kubernetes支持不同负载应用，包括有状态、无状态、数据处理类型的应用。只要这个应用可以在容器里运行，那么就能很好的运行在Kubernetes上。
 Kubernetes不提供中间件（如message buses）、数据处理框架（如Spark）、数据库(如Mysql)或者集群存储系统(如Ceph)作为内置服务。但这些应用都可以运行在Kubernetes上面。
 Kubernetes不部署源码不编译应用。持续集成的 (CI)工作流方面，不同的用户有不同的需求和偏好的区域，因此，我们提供分层的 CI工作流，但并不定义它应该如何工作。
 Kubernetes允许用户选择自己的日志、监控和报警系统。
 Kubernetes不提供或授权一个全面的应用程序配置 语言/系统（例如，jsonnet）。
 Kubernetes不提供任何机器配置、维护、管理或者自修复系统。
 另一方面，大量的Paas系统都可以运行在Kubernetes上，比如Openshift、Deis、Gondor。可以构建自己的Paas平台，与自己选择的CI系统集成。

Kubernetes架构

Kubernetes主要由以下几个核心组件组成：
 etcd：保存了整个集群的状态；
 apiserver：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
 controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
 scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
 kubelet：负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
 Container runtime：负责镜像管理以及Pod和容器的真正运行（CRI）；
 kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡；
除了核心组件，还有一些推荐的Add-ons：
 kube-dns：负责为整个集群提供DNS服务
 Ingress Controller：为服务提供外网入口
 Heapster：提供资源监控
 Dashboard：提供GUI
 Federation：集群联邦提供跨可用区的集群
 Fluentd-elasticsearch：提供集群日志采集、存储与查询

Kubernetes 设计理念

API设计原则

K8s系统API的设计有以下几条原则：
 所有API应该是声明式的。
 API对象是彼此互补而且可组合的。
 高层API以操作意图为基础设计。
 低层API根据高层API的控制需要设计。
 尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。
 API操作复杂度与对象数量成正比。
 API对象状态不能依赖于网络连接状态。
 尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

控制机制设计原则

 控制逻辑应该只依赖于当前状态。
 假设任何错误的可能，并做容错处理。
 尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。
 假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。
 每个模块都可以在出错后自动恢复。
 每个模块都可以在必要时优雅地降级服务。

Kubernetes的核心技术概念和API对象

API对象

每个API对象都有3大类属性：元数据metadata、规范spec和状态status。

1. 元数据metadata：是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象。
2. 规范spec：描述了用户期望K8s集群中的分布式系统达到的理想状态。
3. 状态status：描述了系统实际当前达到的状态。
   K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。

Pod

Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
Pod是K8s集群中所有业务类型的基础。目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的pod控制器为Deployment、Job、DaemonSet和PetSet。

复制控制器（Replication Controller，RC）

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型。

副本集（Replica Set，RS）

RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用。

部署(Deployment)

Deployment表示用户对K8s集群的一次更新操作。Deployment是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。

服务（Service）

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。

任务（Job）

Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

后台支撑服务集（DaemonSet）

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持K8s集群运行的服务。

有状态服务集（PetSet）

RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而PetSet是用来控制有状态服务，PetSet中的每个Pod的名字都是事先确定的，不能更改。PetSet中Pod的名字的作用是关联与该Pod对应的状态。
对于RC和RS中的Pod，一般不挂载存储或者挂载共享存储，保存的是所有Pod共享的状态；对于PetSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。
适合于PetSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务。PetSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。

集群联邦（Federation）

集群联邦服务就是为提供跨Region跨服务商K8s集群服务而设计的。每个K8s Federation有自己的分布式存储、API Server和Controller Manager。用户可以通过Federation的API Server注册该Federation的成员K8s Cluster。在提供业务请求服务时，K8s Federation会先在自己的各个子Cluster之间做负载均衡，而对于发送到某个具体K8s Cluster的业务请求，会依照这个K8s Cluster独立提供服务时一样的调度模式去做K8s Cluster内部的负载均衡。而Cluster之间的负载均衡是通过域名服务的负载均衡来实现的。

存储卷（Volume）

K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。K8s支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如AWS，Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。
持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）
PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，有K8s集群的使用者即服务的管理员来配置。

节点（Node）

K8s集群中的计算能力由Node提供，是所有Pod运行所在的工作主机，可以是物理机也可以是虚拟机。不论是物理机还是虚拟机，工作主机的统一特征是上面要运行kubelet管理节点上运行的容器。

密钥对象（Secret）

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好处是可以避免把敏感信息明文写在配置文件里。在K8s集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能。为了避免将敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个Secret对象，而在配置文件中通过Secret对象引用这些敏感信息。这种方式的好处包括：意图明确，避免重复，减少暴露机会。

用户帐户（User Account）和服务帐户（Service Account）

顾名思义，用户帐户为人提供账户标识，而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。

名字空间（Namespace）

名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。

RBAC访问授权

相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略可以跟某个角色关联，具体的用户再跟一个或多个角色相关联。显然，RBAC像其他新功能一样，每次引入新功能，都会引入新的API对象，从而引入新的概念抽象，而这一新的概念抽象一定会使集群服务管理和使用更容易扩展和重用。

参考文献

http://docs.kubernetes.org.cn/