Kubernetes 的基本概念和术语

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 中。

Node

Node 是 Kubernetes 集群中的工作负载的节点,每个 Node 都会被 Master 分配一些工作负载(docker 容器)。 在 Node 上运行着以下关键进程:

  • kubelet:负责 Pod 对应的容器的创建、启停等任务,同时与 Master 密切协助,实现集群管理的基本功能
  • kube-proxy:实现 Kubernetes Service 的通信与负载均衡机制的重要组件
  • Docker Engine(Docker):Docker 引擎,负责本机的容器创建和管理工作

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,简化了密切关联的业务容器之间的通信问题,也解决了他们之间的文件共享问题。

Label

Label(标签)是 Kubernetes 系统中另外一个核心概念。一个 Label 是一个 key=value 的键值对,其中 key 与 value 由用户自己指定。Label 可以被附加到各种资源对象上,例如 Node、Pod、Service、RC 等,一个资源对象可以定义任意数量的 Label ,同一个 Label 也可以被添加到任意数量的资源对象上。Label 通常在资源对象定义的时确定,也可以在对象创建后动态的添加或者删除。

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 的滚动升级

Deployment

Deployment 内部使用了 Replica Set 来实现目的。 Deployment 的典型使用场景有以下几个:

  • 创建一个 Deployment 对象来生成对应的 Replica Set 并完成 Pod 副本的创建
  • 检查 Deployment 的状态来看部署动作是否完成(Pod 副本数量是否达到预期的值)
  • 更新 Deployment 以创建新的 Pod(比如镜像升级)
  • 如果当前 Deployment 不稳定,则回滚到一个早先的 Deployment 版本
  • 暂停 Deployment 以便于一次性修改多个 PodTemplateSpec 的配置项,之后在恢复 Deployment ,进行先得发布
  • 扩展 Deployment 以应对高负载
  • 查看 Deployment 的状态,以此作为发布是否成功的指标
  • 清理不再需要的旧版本 ReplicaSets

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler(Pod 横向自动扩容,HPA)通过追踪分析指定 RC 控制的所有目标 Pod 的负载变化情况,来确定是否需要有针对性的调整目标 Pod 的副本数量。 HPA 有以下两种方式作为 Pod 负载的度量指标:

  • CPUUtilizationPercenta
  • 应用程序自定义的度量指标,比如服务在每秒内的请求数(TPS 或 QPS)

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 相关的存储卷。

Service

Kubernetes 的 Service 定义了一个服务的访问入口地址,每个 Service 都有唯一的 Cluster IP 及唯一的名称。 Kubernetes 里的 3 种 IP:

  • Node IP: Node 的 IP 地址
  • Pod IP: Pod 的 IP 地址
  • Cluster IP: Service 的 IP 地址

Job

Job 控制一组 Pod 容器,Job 也是一种特殊的 Pod 副本自动控制器。Job 控制 Pod 副本与 RC 等控制器的工作机制有以下区别:

  1. Job 所控制的 Pod 副本是短暂运行的,可以将其视为一组 Docker 容器,其中每个 Docker 容器都仅运行一次。当 Job 控制的所有 Pod 副本都运行结束时,对应的 Job 也就结束了。Job 在实现方式上与 RC 等副本控制器不同,Job 生成的 Pod 副本是不能自动重启的,对应 Pod 副本的 RestartPolicy 都被设置为 Never.
  2. Job 所控制的 Pod 副本的工作模式能够多实例并行计算。

Volume

Volume 是 Pod 中能够被多个容器访问的共享目录。 Kubernetes 提供了以下的 Volume 类型:

  1. emptyDir 一个 emptyDir Volume 是在 Pod 分配到 Node 的时创建的。他的初始内容为空,并且无需指定宿主机上对应的目录文件。Kubernetes 自动分配一个目录,当 Pod 从 Node 上面移除时, emptyDir 中的数据也会被永久删除。emptyDir 的一些用途如下:
  • 临时空间,例如某些程序运行时所需的临时目录
  • 长时间任务的中间过程 CheckPoint 的临时保存目录
  • 一个容器需要从另一个容器中获取数据的目录(多容器共享目录)
  1. hostPath hostPath 为在 Pod 上挂载宿主机上的文件或目录,通常用于以下几个方面:
  • 容器应用程序生成的日志文件需要永久保存时,可以使用宿主机的高速文件系统进行存储
  • 需要访问宿主机上 Docker 引擎内部数据结构的容器应用时,可以通过定义 hostPath 为宿主机 /var/lib/docker 目录,使容器内部应用可以直接访问 Docker 的文件系统 在使用 hostpath 时,需要注意以下几点:
  • 在不同的 Node 上具有相同配置的 Pod,可能会因为宿主机上的目录和文件不同而导致 Volume 上目录和文件的访问结果不一致
  • 如果使用了资源配额管理,则 Kubernetes 无法将 hostPath 在宿主机上使用的资源纳入管理
  1. gcePersistentDisk 使用谷歌云提供永久磁盘,当 Pod 被删除时,PD 只是被卸载,不会被删除。需要在谷歌云环境中使用。

  2. awsElasticBlockStore 使用 AWS 提供的 EBS Volume 存储数据,需要在 AWS 环境中使用。

  3. NFS 使用 NFS 网络文件系统提供共享目录存储数据。

  4. 其他类型的 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 访问。

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 自动回收失败

Namespace

Namespace 在很多情况下用于实现多租户的资源隔离,可以给每个租户创建一个 Namespace 来实现多租户的资源隔离。

Annotation

Annotation 与 Label 类似,也使用 key/value 键值对的形式进行定义。不同的是 Label 就有严格的命名规则,它定义的是 Kubernetes 对象的元数据,并且用于 Label Selector。Annotation 则是用户任意定义的附加信息,以便于外部工具查找。Kubernetes 的模块自身会通过 Annotation 标记资源对象的一些特殊信息。 通常来说,用 Annotation 来记录的信息如下:

  • build 信息、release 信息、Docker 镜像信息等,例如书简戳、release id 号、PR 号、镜像 Hash 值、Docker registry 地址等
  • 日志库、监控库、分析库等资源库的信息
  • 程序调试工具信息,例如工具名称、版本号等
  • 团队的联系信息,例如电话号码、负责人名称、网址等

ConfigMap

首先,把所有的配置项都当作 key-value 字符串,这些配置项可以作为 Map 表中的一个项,整个 Map 的数据可以被持久化存储在 Kubernetes 的 Etcd 数据库中,然后提供 API 以方便 Kubernetes 相关组件或客户应用 CRUD 操作这些数据,上述专门用于保存配置参数的 Map 就是 Kubernetes ConfigMap 资源对象。 接下来,Kubernetes 提供了一种内建机制,将存储在 etcd 中的 ConfigMap 通过 Volume 映射的方式变成目标 Pod 内的配置文件,不管 Pod 被调度到哪台服务器上,都会完成自动映射。进一步地,如果 ConfigMap 中的 key-value 数据被修改,则映射到 Pod 中的“配置文件”也会随之更新。


附录

整理自 《Kubernetes 权威指南(第4版)》

一个默默无闻的工程师的日常
Built with Hugo
主题 StackJimmy 设计