备注：整理自 《Kubernetes 权威指南（第4版）》
目录
1、Master
Kubernetes 里的 Master 指的是集群的控制节点，负责整个集群的管理和控制。
在 Master 上运行中以下关键进程：
- Kubernetes API Server（kube-apiserver）：提供了 HTTP Rest 接口的关键服务进程，是 Kubernetes 里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程
- Kubernetes Controller Manager（kube-controller-manager）：Kubernetes 里所有资源对象的自动化控制中心
- Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod 调度）的进程
此外在 Master 上通常还需要不是 etcd 服务，因为 Kubernetes 里的所有资源对象的数据都被保存在 etcd 中。
2、Node
Node 是 Kubernetes 集群中的工作负载的节点，每个 Node 都会被 Master 分配一些工作负载（docker 容器）。
在 Node 上运行着以下关键进程：
- kubelet：负责 Pod 对应的容器的创建、启停等任务，同时与 Master 密切协助，实现集群管理的基本功能
- kube-proxy：实现 Kubernetes Service 的通信与负载均衡机制的重要组件
- Docker Engine（Docker）：Docker 引擎，负责本机的容器创建和管理工作
3、Pod
每个 Pod 都有一个特殊的被称为“根容器”的 Pause 容器，除了 Pause 容器，每个 Pod 还包含一个或多个紧密相关的用户业务容器。
Kubernetes 为每个 Pod 都分配了一个唯一的 IP 地址，称之为 Pod IP，一个 Pod 里的多个容器共享 Pod IP 地址。
在 Kubernetes 里，一个 Pod 里的容器与另外主机上的 Pod 里的容器能够直接通信。
为什么要有一个 Pause 容器？
1.引入业务无关的且不易死亡的 Pause 容器作为 Pod 的根容器，以它的状态代表整个容器组的状态。
2.Pod 里的多个业务容器共享 Pause 容器的 IP，共享 Pause 容器挂载的 Volume，简化了密切关联的业务容器之间的通信问题，也解决了他们之间的文件共享问题。
4、Label
Label（标签）是 Kubernetes 系统中另外一个核心概念。一个 Label 是一个 key=value 的键值对，其中 key 与 value 由用户自己指定。Label 可以被附加到各种资源对象上，例如 Node、Pod、Service、RC 等，一个资源对象可以定义任意数量的 Label ，同一个 Label 也可以被添加到任意数量的资源对象上。Label 通常在资源对象定义的时确定，也可以在对象创建后动态的添加或者删除。
5、Replication Controller
RC 的定义包括以下几个部分：
- Pod 期待的副本数量
- 用于筛选目标 Pod 的 Label Selector
- 当 Pod 的副本数量小于预期数量时，用于创建新 Pod 的 Pod 模板（template）
Replica Set 与 Deployment 这两个重要的资源对象逐步替代了之前 RC 的作用。
RC(Replica Set)的一些特性与作用：- 在大多数的情况下，我们通过定义一个 RC 实现 Pod 的创建及副本数量的自动控制
- 在 RC 里包括完成的 Pod 定义模板
- RC 通过 Label Selector 机制实现对 Pod 副本的自动控制
- 通过改变 RC 里的 Pod 副本数量，可以实现 Pod 的扩容和缩容
- 通过改变 RC 里 Pod 模板中的镜像版本，可以实现 Pod 的滚动升级
6、Deployment
Deployment 内部使用了 Replica Set 来实现目的。
Deployment 的典型使用场景有以下几个：
- 创建一个 Deployment 对象来生成对应的 Replica Set 并完成 Pod 副本的创建
- 检查 Deployment 的状态来看部署动作是否完成（Pod 副本数量是否达到预期的值）
- 更新 Deployment 以创建新的 Pod（比如镜像升级）
- 如果当前 Deployment 不稳定，则回滚到一个早先的 Deployment 版本
- 暂停 Deployment 以便于一次性修改多个 PodTemplateSpec 的配置项，之后在恢复 Deployment ，进行先得发布
- 扩展 Deployment 以应对高负载
- 查看 Deployment 的状态，以此作为发布是否成功的指标
- 清理不再需要的旧版本 ReplicaSets
7、Horizontal Pod Autoscaler
Horizontal Pod Autoscaler（Pod 横向自动扩容，HPA）通过追踪分析指定 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要有针对性的调整目标 Pod 的副本数量。
HPA 有以下两种方式作为 Pod 负载的度量指标：
- CPUUtilizationPercenta
- 应用程序自定义的度量指标，比如服务在每秒内的请求数（TPS 或 QPS)
8、StatefulSet
在 Kubernetes 系统中，Pod 的管理对象 RC、Deployment、DaemonSet 和 Job 都面向无状态的服务。
StatefulSet 从本质上来说，可以看作 Deployment/RC 的一个特殊变种，它有如下特性：
- StatefulSet 里的每个 Pod 都有稳定、唯一的网络标识，可以用来发现集群内的其他成员
- StatefulSet 控制的 Pod 副本启停顺序是受控的，操作第 n 个 Pod 时，前 n-1 个 Pod 已经是运行且准备好的状态
- StatefulSet 里的 Pod 采用稳定的持久化存储卷，通过 PV 或 PVC 来实现，删除 Pod 时默认不会删除与 StatefulSet 相关的存储卷。
9、Service
Kubernetes 的 Service 定义了一个服务的访问入口地址，每个 Service 都有唯一的 Cluster IP 及唯一的名称。
Kubernetes 里的 3 种 IP:
- Node IP: Node 的 IP 地址
- Pod IP: Pod 的 IP 地址
- Cluster IP: Service 的 IP 地址
10、Job
Job 控制一组 Pod 容器，Job 也是一种特殊的 Pod 副本自动控制器。Job 控制 Pod 副本与 RC 等控制器的工作机制有以下区别：
- Job 所控制的 Pod 副本是短暂运行的，可以将其视为一组 Docker 容器，其中每个 Docker 容器都仅运行一次。当 Job 控制的所有 Pod 副本都运行结束时，对应的 Job 也就结束了。Job 在实现方式上与 RC 等副本控制器不同，Job 生成的 Pod 副本是不能自动重启的，对应 Pod 副本的 RestartPolicy 都被设置为 Never.
- Job 所控制的 Pod 副本的工作模式能够多实例并行计算。
11、Volume
Volume 是 Pod 中能够被多个容器访问的共享目录。
Kubernetes 提供了以下的 Volume 类型：
- emptyDir
一个 emptyDir Volume 是在 Pod 分配到 Node 的时创建的。他的初始内容为空，并且无需指定宿主机上对应的目录文件。Kubernetes 自动分配一个目录，当 Pod 从 Node 上面移除时， emptyDir 中的数据也会被永久删除。emptyDir 的一些用途如下：
- 临时空间，例如某些程序运行时所需的临时目录
- 长时间任务的中间过程 CheckPoint 的临时保存目录
- 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）
- hostPath
hostPath 为在 Pod 上挂载宿主机上的文件或目录，通常用于以下几个方面：
- 容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统进行存储
- 需要访问宿主机上 Docker 引擎内部数据结构的容器应用时，可以通过定义 hostPath 为宿主机 /var/lib/docker 目录，使容器内部应用可以直接访问 Docker 的文件系统
在使用 hostpath 时，需要注意以下几点：- 在不同的 Node 上具有相同配置的 Pod，可能会因为宿主机上的目录和文件不同而导致 Volume 上目录和文件的访问结果不一致
- 如果使用了资源配额管理，则 Kubernetes 无法将 hostPath 在宿主机上使用的资源纳入管理
gcePersistentDisk
使用谷歌云提供永久磁盘，当 Pod 被删除时，PD 只是被卸载，不会被删除。需要在谷歌云环境中使用。awsElasticBlockStore
使用 AWS 提供的 EBS Volume 存储数据，需要在 AWS 环境中使用。NFS
使用 NFS 网络文件系统提供共享目录存储数据。其他类型的 Volume
- iscsi: 使用 iSCSI 存储设备上的目录挂载到 Pod 中
- flocker: 使用 Flocker 管理存储卷
- glusterfs: 使用开源 GlusterFS 网络文件系统的目录挂载到 Pod 中
- rbd: 使用 Ceph 块设备共享存储挂载到 Pod 中
- gitRepo: 通过挂载一个空目录，并从 Git 库 clone 一个git repository 供 Pod 使用
- secret: 一个 Secret Volume 用于为 Pod 提供加密的信息，可以将定义在 Kubernetes 中的 Secret 直接挂载为文件让 Pod 访问。
12、Persistent Volume
PV 可以被理解成 Kubernetes 集群中的某个网络存储对应的一块存储，它与 Volume 类似，但有以下区别。
- PV 只能是网络存储，不属于任何 Node,但可以在每个 Node *问
- Pv 并不是定义在 Pod 上，而是独立于 Pod 之外定义的
- PV 目前支持的类型包括: gcePersistentDisk、awsElasticBlockStore、AzureFile、AzureDisk、FC、Flocker、NFC、iSCSI、RBD、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes 和 hostPath（仅供单机测试）
PV 的 accessModes 属性：
- ReadWriteOnce: 读写权限，并且只能被单个 Node 挂载
- ReadOnlyMany: 只读权限，允许被多个 Node 挂载
- ReadWriteMany: 读写权限，允许被多个 Node 挂载
PV 的状态：
- Available：空闲状态
- Bound: 已经绑定到某个 PVC 上面
- Released: 对应的 PVC 已经被删除，但是资源还没有被集群回收
- Failed: PV 自动回收失败
13、Namespace
Namespace 在很多情况下用于实现多租户的资源隔离，可以给每个租户创建一个 Namespace 来实现多租户的资源隔离。
14、Annotation
Annotation 与 Label 类似，也使用 key/value 键值对的形式进行定义。不同的是 Label 就有严格的命名规则，它定义的是 Kubernetes 对象的元数据，并且用于 Label Selector。Annotation 则是用户任意定义的附加信息，以便于外部工具查找。Kubernetes 的模块自身会通过 Annotation 标记资源对象的一些特殊信息。
通常来说，用 Annotation 来记录的信息如下：
- build 信息、release 信息、Docker 镜像信息等，例如书简戳、release id 号、PR 号、镜像 Hash 值、Docker registry 地址等
- 日志库、监控库、分析库等资源库的信息
- 程序调试工具信息，例如工具名称、版本号等
- 团队的联系信息，例如电话号码、负责人名称、网址等
15、ConfigMap
首先，把所有的配置项都当作 key-value 字符串，这些配置项可以作为 Map 表中的一个项，整个 Map 的数据可以被持久化存储在 Kubernetes 的 Etcd 数据库中，然后提供 API 以方便 Kubernetes 相关组件或客户应用 CRUD 操作这些数据，上述专门用于保存配置参数的 Map 就是 Kubernetes ConfigMap 资源对象。
接下来，Kubernetes 提供了一种内建机制，将存储在 etcd 中的 ConfigMap 通过 Volume 映射的方式变成目标 Pod 内的配置文件，不管 Pod 被调度到哪台服务器上，都会完成自动映射。进一步地，如果 ConfigMap 中的 key-value 数据被修改，则映射到 Pod 中的“配置文件”也会随之更新。