工作负载
在 Kubernetes 中,无论你的负载是由单个组件还是由多个一同工作的组件构成, 你都可以在一组 Pod 中运行它。 在 Kubernetes 中,Pod 代表的是集群上处于运行状态的一组 容器 的集合。
Kubernetes Pods 遵循预定义的生命周期。 例如,当在你的集群中运行了某个 Pod,但是 Pod 所在的 节点 出现致命错误时, 所有该节点上的 Pods 的状态都会变成失败。Kubernetes 将这类失败视为最终状态: 即使该节点后来恢复正常运行,你也需要创建新的 Pod 以恢复应用。
不过,为了减轻用户的使用负担,通常不需要用户直接管理每个 Pod。 而是使用负载资源来替用户管理一组 Pod。 这些负载资源通过配置 控制器 来确保正确类型的、处于运行状态的 Pod 个数是正确的,与用户所指定的状态相一致。
Kubernetes 提供若干种内置的工作负载资源:
- Deployment 和
ReplicaSet
(替换原来的资源 ReplicationController)。
Deployment
很适合用来管理你的集群上的无状态应用,Deployment
中的所有Pod
都是相互等价的,并且在需要的时候被替换。 - StatefulSet
让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。
例如,如果你的负载会将数据作持久存储,你可以运行一个
StatefulSet
,将每个Pod
与某个PersistentVolume
对应起来。你在StatefulSet
中各个Pod
内运行的代码可以将数据复制到同一StatefulSet
中的其它Pod
中以提高整体的服务可靠性。
- DaemonSet
定义提供节点本地支撑设施的
Pods
。这些 Pods 可能对于你的集群的运维是 非常重要的,例如作为网络链接的辅助工具或者作为网络 插件 的一部分等等。每次你向集群中添加一个新节点时,如果该节点与某DaemonSet
的规约匹配,则控制面会为该DaemonSet
调度一个Pod
到该新节点上运行。 - Job 和
CronJob。
定义一些一直运行到结束并停止的任务。
Job
用来表达的是一次性的任务,而CronJob
会根据其时间规划反复运行。
在庞大的 Kubernetes 生态系统中,你还可以找到一些提供额外操作的第三方工作负载相关的资源。
通过使用定制资源定义(CRD),
你可以添加第三方工作负载资源,以完成原本不是 Kubernetes 核心功能的工作。
例如,如果你希望运行一组 Pods
,但要求所有 Pods 都可用时才执行操作
(比如针对某种高吞吐量的分布式任务),你可以基于定制资源实现一个能够满足这一需求的扩展,
并将其安装到集群中运行。
接下来
除了阅读了解每类资源外,你还可以了解与这些资源相关的任务:
- 使用 Deployment 运行一个无状态的应用
- 以单实例或者多副本集合 的形式运行有状态的应用;
- 使用
CronJob
运行自动化的任务
要了解 Kubernetes 将代码与配置分离的实现机制,可参阅配置部分。
关于 Kubernetes 如何为应用管理 Pods,还有两个支撑概念能够提供相关背景信息:
- 垃圾收集机制负责在 对象的 属主资源 被删除时在集群中清理这些对象。
- Time-to-Live 控制器会在 Job 结束之后的指定时间间隔之后删除它们。
一旦你的应用处于运行状态,你就可能想要以
Service
的形式使之可在互联网上访问;或者对于 Web 应用而言,使用
Ingress
资源将其暴露到互联网上。