22、管理状态和有状态应用

管理状态和有状态应用

1. 容器编排与状态管理的演变

早期容器编排主要针对无状态应用，这些应用在需要时借助外部系统存储状态。当时认为容器是临时的，对用于保持状态一致性的后端存储进行编排颇具挑战。然而，随着时间推移，基于容器且需保持状态的工作负载需求成为现实，在某些特定情况下，这种需求可能会带来更高的性能。

随着更多组织转向云计算，Kubernetes 成为应用的事实标准容器运行时，数据量及对数据的高效访问（即“数据引力”）成为阻碍因素。经过多次迭代，Kubernetes 不仅允许将存储卷挂载到 Pod 中，还能直接管理这些卷，这在对需要存储的工作负载进行编排时是一个重要组件。

2. 卷和卷挂载

并非所有需要维护状态的工作负载都必须是复杂的数据库或高吞吐量的数据队列服务。很多迁移到容器化工作负载的应用期望特定目录存在，并能对这些目录进行读写操作。虽然第 4 章介绍了向 Pod 中可被容器读取的卷注入数据的方法，但从 ConfigMaps 或 Secrets 挂载的数据通常是只读的，本节重点关注为容器提供可写卷，使其能在容器甚至 Pod 故障时仍保留数据。

主要的容器运行时（如 Docker、rkt、CRI - O 和 Singularity）都支持将卷挂载到映射到外部存储系统的容器中。外部存储可以是内存位置、容器主机上的路径，或者是 NFS、Glusterfs、CIFS 或 Ceph 等外部文件系统。

例如，一个遗留应用将特定于应用的信息记录到本地文件系统。可以通过更新应用代码，将日志输出到边车容器的 stdout 或 stderr，通过共享 Pod 卷将日志数据流式传输到外部源；也可以采用基于主机的日志记录工具，使用 Kuber