Question

表格 K8s 关键术语

名词	释义	设计理念
API 对象	K8s 集群中的管理操作单元。K8s 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，支持对该功能的管理操作。	K8s 中所有的配置都是通过 API 对象的 spec 去设置的。即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。
Pod	微服务，也称实例。K8s 集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod 是 K8s 集群中所有业务类型的基础，可以看作运行在 K8s 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。	支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
复制控制器 RC（Replication Controller）	RC 是 K8s 集群中最早的保证 Pod 高可用的 API 对象。	通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本（1~多个）。
副本集 RS（Replica Set）	新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。	副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。
部署(Deployment)	部署表示用户对 K8s 集群的一次更新操作。部署是一个比 RS 应用模式更广的 API 对象，可以是创建/更新/滚动升级新服务
服务（Service）	在 K8s 集群中，客户端需要访问的服务就是 Service 对象。在 K8s 集群中微服务的负载均衡是由 Kube-proxy 实现的。Servcie Type 目前有四种。	每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。
任务（Job）	Job 是 K8s 用来控制批处理型任务的 API 对象。	Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。
后台支撑服务集（DaemonSet）	后台支撑型服务的核心关注点在 K8s 集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类 Pod 运行。
有状态服务集（PetSet）	PetSet 用来控制有状态服务，PetSet 中的每个 Pod 的名字都是事先确定的，不能更改。	适合于 PetSet 的业务包括数据库服务 MySQL 和 PostgreSQL，集群化管理服务 Zookeeper、etcd 等有状态服务。
集群联邦（Federation）	为提供跨 Region 跨服务商 K8s 集群服务而设计的。
存储卷（Volume）	K8s 的存储卷的生命周期和作用范围是一个 Pod。
PV & PVC	持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）
节点（Node）	K8s 集群中的计算能力由 Node 提供。 Node 可以是物理机也可以是虚拟机。	K8s 集群中的 Node 也就等同于 Mesos 集群中的 Slave 节点，是所有 Pod 运行所在的工作主机。
名字空间（Namespace）	名字空间为 K8s 集群提供虚拟的隔离作用，K8s 集群初始有四个名字空间：* default 默认名字空间，* kube-system 系统名字空间，* kube-public 公共、所有人都可以访问 , * kube-node-lease 内部使用。	管理员可以可以创建新的名字空间满足需要。
RBAC 访问授权	基于角色的访问控制（Role-based Access Control，RBAC）的授权模式。RBAC 主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。	RBAC 中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联

备注：其它常用术语还有密钥对象（Secret）、用户帐户（User Account）和服务帐户（Service Account）。从 K8s 的系统架构、技术概念和设计理念，我们可以看到 K8s 系统最核心的两个设计理念：一个是容错性，一个是易扩展性。容错性实际是 保证 K8s 系统稳定性和安全性的基础，易扩展性是保证 K8s 对变更友好，可以快速迭代增加新功能的基础。

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

   • 元数据是用来标识 API 对象的，每个对象都至少有 3 个元数据：namespace，name 和 uid；除此以外还有各种各样的标签 labels 用来 标识和匹配不同的对象，例如用户可以用标签 env 来标识区分不同的服务部署环境，分别用 env=dev、env=testing、 env=production 来标识开发、测试、生产的不同服务。

   • 规范描述了用户期望 K8s 集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器 Replication Controller 设置期望的 Pod 副本数为 3；

   • 状态描述了系统实际当前达到的状态（Status），例如系统当前实际的 Pod 副本数为 2；那么复制控制器当前的程序逻辑就是自动启动新的 Pod，争取达到副本数为 3。

2. Pod: Pod 是 Kubernetes 创建或部署的最小单位。

   • 一个 Pod 封装一个或多个容器（container）、存储资源（volume）、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。

   • 目前 K8s 中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有 状态应用型（stateful application）；分别对应的小机器人控制器为 Deployment、Job、DaemonSet 和 PetSet。

3. RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题。Service 解决服务访问的问题。RC 和 RS 主要是控制提供无状态服务的，其所控制的 Pod 的名字是随机设置的，名字不重要，重要的是 Pod 总数。

4. 在云计算环境中，服务的作用距离范围从近到远一般可以有：同主机（Host，Node）、跨主机同可用区（Available Zone）、跨可用区同地区（Region）、跨地区同服务商（Cloud Service Provider）、跨云平台。K8s 的设计定位是单一集群在同一个地域内，因为同一个地区的网络性能才能满足 K8s 的调度和计算存储连接要求。而联合集 群服务就是为提供跨 Region 跨服务商 K8s 集群服务而设计的。

5. Service 的四种 type: K8S 通过 Service 对外暴露服务。

   • ClusterIP（默认） - 在集群中内部 IP 上暴露服务。此类型使 Service 只能从集群中访问。
   • NodePort - 通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 <NodeIP>:<NodePort> ，可以从集群的外部访问一个 NodePort 服务。
   • LoadBalancer - 使用云提供商的负载均衡器（如果支持），可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
   • ExternalName - 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容，没有任何类型代理被创建。这种类型需要 v1.7 版本或更高版本 kube-dnsc 才支持。

图 K8S 基本对象

对象说明：K8S 对象就是一个资源。

• Service

  Service 是用来解决 Pod 访问问题的。Service 有一个固定 IP 地址，Service 将访问流量转发给 Pod，而且 Service 可以给这些 Pod 做负载均衡。

• Ingress

  Service 是基于四层 TCP 和 UDP 协议转发的，Ingress 可以基于七层的 HTTP 和 HTTPS 协议转发，可以通过域名和路径做到更细粒度 的划分。ConfigMapConfigMap 是一种用于存储应用所需配置信息的资源类型，用于保存配置数据的键值对。通过 ConfigMap 可以方便的 做到配置解耦，使得不同环境有不同的配置。

• Secret

  Secret 是一种加密存储的资源对象，您可以将认证信息、证书、私钥等保存在 Secret 中，而不需要把这些敏感数据暴露到镜像或者 Pod 定义中，从而更加安全和灵活。

• PersistentVolume（PV）

  PV 指持久化数据存储卷，主要定义的是一个持久化存储在宿主机上的目录，比如一个 NFS 的挂载目录。

• PersistentVolumeClaim（PVC）

  Kubernetes 提供 PVC 专门用于持久化存储的申请，PVC 可以让您无需关心底层存储资源如何创建、释放等动作，而只需要申明您需要何种类型的存储资源、多大的存储空间。