Kubernetes通常是从无状态系统的角度来处理的。无状态应用程序易于容器化、分发和扩展，因为它不需要在其环境之外存储任何数据。容器是否停止或移动到不同的主机都没有关系 - 新实例可以替换旧实例而不会产生任何影响。
但大多数实际应用程序并非如此。除了最简单的系统之外，所有系统都拥有通常存储在数据库或持久文件系统中的状态。配置您的服务或由用户创建的数据必须保留并可供您的所有容器访问，无论它们位于何处。
大多数使用容器、编排和云原生工作实践的组织都会遇到跨瞬态环境维护状态的挑战。Kubernetes 可以容纳有状态的工作负载，但也存在外部替代方案。在本文中，您将了解使 Kubernetes 与有状态应用程序一起工作的一些方法。
国家的问题
术语“状态”描述了在特定时间点与应用程序关联的数据。它是长期存在的信息，例如数据库内容和用户帐户，需要在系统的整个生命周期中检索。当您的服务在使用时，状态会随着数据的创建和修改而不断变化。
正确的应用程序功能取决于能够访问持久状态的每个实例。如果您将一个组件的四个副本分布在两台物理主机上，那么这两台机器都需要访问您的数据存储。这意味着应用程序实例具有无法自动替换的相互关联的依赖关系。
有状态服务的约束与 Kubernetes 的可随时更换的临时容器模型相冲突。当您使用有状态应用程序时，您需要进行特殊准备，以便容器能够可靠地访问它们所需的状态。这需要额外的配置来提供可靠的数据持久性，并在应用程序扩展时保持稳定。
在 Kubernetes 中运行有状态服务
在社区兴趣增加的支持下，Kubernetes 对有状态系统的支持在过去几年中不断