设计

Kubernetes 有很多技术概念，同时对应很多 API 对象，最重要的也是最基础的是 Pod

Pod 是在 Kubernetes 集群中 运行部署应用或服务的最小单元

• Pod 的设计理念：支持 多个容器 在一个 Pod 中 共享 网络地址 和 文件系统 ，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务

Pod 对多容器的支持是 K8 最基础的设计理念

比如运行一个操作系统发行版的软件仓库，一个 Nginx 容器用来发布软件，另一个容器专门用来从源仓库做同步

这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务

这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务

• Pod 是 Kubernetes 集群中 所有业务类型的基础

Pod 可以看作运行在 Kubernetes 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行

目前 Kubernetes 中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）

分别对应的小机器人控制器为 Deployment、Job、DaemonSet 和 StatefulSet

RC 是 Kubernetes 集群中最早的保证 Pod 高可用的 API 对象。通过 监控 运行中的 Pod 来保证 集群中运行指定数目的 Pod 副本 ，指定的数目可以是多个也可以是 1 个

• 少于指定数目，RC 就会启动运行新的 Pod 副本
• 多于指定数目，RC 就会杀死多余的 Pod 副本
• 即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 Pod 在运行

RC 是 Kubernetes 较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的 Web 服务

RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能 支持更多种类的匹配模式

副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用

部署表示用户对 Kubernetes 集群的一次 更新操作 。部署是一个比 RS 应用模式更广的 API 对象：

• 可以是创建一个新的服务
• 更新一个新的服务
• 也可以是滚动升级一个服务

滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作

这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述

以 Kubernetes 的发展方向，未来对所有长期伺服型的的业务的管理，都会通过 Deployment 来管理

RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题

一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的 IP 和端口号提供服务

要稳定地提供服务需要 服务发现 和 负载均衡 能力：

• 服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在 K8 集群中，客户端需要访问的服务就是 Service 对象 ：
  • 每个 Service 会对应一个 集群内部 有效的 虚拟 IP ，集群内部通过虚拟 IP 访问一个服务
• 在 Kubernetes 集群中微服务的负载均衡是由 Kube-proxy 实现的
  • Kube-proxy 是 Kubernetes 集群内部的负载均衡器

  • 它是一个 分布式代理服务器 ，在 Kubernetes 的每个节点上都有一个

    这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多，高可用节点也随之增多
    
    与之相比，平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题
    

Job 是 Kubernetes 用来控制 批处理型任务 的 API 对象

批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行

Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同

• 单 Pod 型 任务有一个 Pod 成功就标志完成
• 定数成功型 任务保证有 N 个任务全部成功
• 工作队列型 任务根据应用确认的全局成功而标志成功

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的 Pod，有些节点上又没有这类 Pod 运行

后台支撑型服务的核心关注点在 Kubernetes 集群中的节点（物理机或虚拟机），要保证 每个节点 上都有一个 此类 Pod 运行。节点可能是所有集群节点也可能是通过 nodeSelector 选定的一些特定节点

典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持 Kubernetes 集群运行的服务

Kubernetes 在 1.3 版本里发布了 Alpha 版的 PetSet 功能，在 1.5 版本里将 PetSet 功能升级到了 Beta 版本，并重新命名为 StatefulSet，最终在 1.9 版本里成为正式 GA 版本

在云原生应用的体系里，有下面两组近义词
第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）
第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）

RC 和 RS 主要是控制提供无状态服务的，其所控制的 Pod 的名字是随机设置的，一个 Pod 出故障了就被丢弃掉，在另一个地方重启一个新的 Pod，名字变了。名字和启动在哪儿都不重要，重要的只是 Pod 总数

而 StatefulSet 是用来控制有状态服务，StatefulSet 中的每个 Pod 的名字都是事先确定的，不能更改。StatefulSet 中 Pod 的名字的作用：关联与该 Pod 对应的状态 

• 对于 RC 和 RS 中的 Pod，一般不挂载存储或者挂载共享存储，保存的是所有 Pod 共享的状态，Pod 像牲畜一样没有分别（这似乎也确实意味着失去了人性特征）
• 对于 StatefulSet 中的 Pod，每个 Pod 挂载自己独立的存储，如果一个 Pod 出现故障，从其他节点启动一个同样名字的 Pod，要挂载上原来 Pod 的存储继续以它的状态提供服务

适合于 StatefulSet 的业务包括数据库服务 MySQL 和 PostgreSQL，集群化管理服务 ZooKeeper、etcd 等有状态服务

StatefulSet 的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制

传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它

容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的

使用 StatefulSet，Pod 仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性

StatefulSet 做的只是将确定的 Pod 与确定的存储关联起来保证状态的连续性

Kubernetes 在 1.3 版本里发布了 beta 版的 Federation 功能

在云计算环境中，服务的作用距离范围从近到远一般可以有：

• 同主机（Host，Node）
• 跨主机同可用区（Available Zone）
• 跨可用区同地区（Region）
• 跨地区同服务商（Cloud Service Provider）
• 跨云平台

Kubernetes 的设计定位是单一集群在同一个地域内，因为同一个地区的网络性能才能满足 Kubernetes 的调度和计算存储连接要求

联合集群 服务就是为提供跨 Region 跨服务商 Kubernetes 集群服务而设计的：

• 每个 Kubernetes Federation 有自己的分布式存储、API Server 和 Controller Manager
• 用户可以通过 Federation 的 API Server 注册该 Federation 的成员 Kubernetes Cluster
• 当用户通过 Federation 的 API Server 创建、更改 API 对象时，Federation API Server 会在自己所有注册的子 Kubernetes Cluster 都创建一份对应的 API 对象
• 在提供业务请求服务时：
  • Kubernetes Federation 会先在自己的各个子 Cluster 之间做负载均衡
  • 对于发送到某个具体 Kubernetes Cluster 的业务请求，会依照这个 Kubernetes Cluster 独立提供服务时一样的调度模式去做 Kubernetes Cluster 内部的负载均衡
  • Cluster 之间的负载均衡是通过域名服务的负载均衡来实现的

Federation V1 的设计是尽量不影响 Kubernetes Cluster 现有的工作机制，这样对于每个子 Kubernetes 集群来说，并不需要更外层的有一个 Kubernetes Federation，也就是意味着所有现有的 Kubernetes 代码和机制不需要因为 Federation 功能有任何变化。

目前正在开发的 Federation V2，在保留现有 Kubernetes API 的同时，会开发新的 Federation 专用的 API 接口

Kubernetes 集群中的 存储卷 跟 Docker 的存储卷有些类似：

• Docker 的存储卷作用范围为一个容器，而 Kubernetes 的存储卷的生命周期和作用范围是一个 Pod
  • 每个 Pod 中声明的存储卷由 Pod 中的所有容器共享
• Kubernetes 支持非常多的存储卷类型，特别的：
  • 支持多种公有云平台的存储，包括 AWS，Google 和 Azure 云
  • 支持多种分布式存储包括 GlusterFS 和 Ceph
  • 支持较容易使用的主机本地目录 emptyDir, hostPath 和 NFS

Kubernetes 集群中的 计算能力 由 Node 提供

最初 Node 称为服务节点 Minion，后来改名为 Node

Kubernetes 集群中的 Node 也就等同于 Mesos 集群中的 Slave 节点，是所有 Pod 运行所在的工作主机，可以是物理机也可以是虚拟机

不论是物理机还是虚拟机，工作主机的统一特征是上面要运行 kubelet 管理节点上运行的容器

Secret 是用来 保存 和 传递 密码 、 密钥 、 认证凭证 这些敏感信息的对象。使用 Secret 的好处是可以避免把敏感信息明文写在配置文件里

在 Kubernetes 集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能，例如访问 AWS 存储的用户名密码

为了避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个 Secret 对象，而在配置文件中通过 Secret 对象引用这些敏感信息

这样可以意图明确，避免重复，减少暴漏机会

命名空间为 Kubernetes 集群提供 虚拟的隔离 作用，Kubernetes 集群初始有两个命名空间，分别是：

• 默认命名空间 default
• 系统命名空间 kube-system

除此以外，管理员可以可以创建新的命名空间满足需要

用户帐户和服务帐户的一个区别是作用范围

用户帐户对应的是人的身份，人的身份与服务的 namespace 无关，所以用户账户是跨 namespace 的

而服务帐户对应的是一个运行中程序的身份，与特定 namespace 是相关的

Kubernetes 在 1.3 版本中发布了 alpha 版的基于角色的访问控制（Role-based Access Control，RBAC）的授权模式

相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC 主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念

• 在 ABAC 中，Kubernetes 集群中的访问策略只能跟用户直接关联
• 在 RBAC 中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联

RBAC 像其他新功能一样，每次引入新功能，都会引入新的 API 对象，从而引入新的概念抽象

而这一新的概念抽象一定会使集群服务管理和使用更容易扩展和重用