Kubernetes 中状态管理与有状态应用的实践指南
1. 状态管理的背景与需求
在容器编排的早期,目标工作负载通常是无状态应用,它们在需要时使用外部系统来存储状态。当时认为容器是临时的,并且协调用于保持状态一致性的后端存储非常困难。但随着时间的推移,基于容器且需要保持状态的工作负载成为现实,在某些情况下,这种需求可能更具性能优势。
随着更多组织转向云获取计算能力,Kubernetes 成为应用程序的事实容器运行时,数据量和对数据的高性能访问(有时称为“数据引力”)成为阻碍因素。Kubernetes 经过多次迭代进行了适应,现在它不仅允许将存储卷挂载到 Pod 中,还允许直接管理这些卷,这是编排需要存储的工作负载的重要组成部分。
2. 卷和卷挂载
并非每个需要维护状态的工作负载都必须是复杂的数据库或高吞吐量的数据队列服务。通常,迁移到容器化工作负载的应用程序期望某些目录存在,并能够向这些目录读写相关信息。
每个主要的容器运行时,如 Docker、rkt、CRI - O 甚至 Singularity,都允许将卷挂载到映射到外部存储系统的容器中。外部存储可以是内存位置、容器主机上的路径或外部文件系统,如 NFS、Glusterfs、CIFS 或 Ceph。
例如,一个遗留应用程序将特定于应用程序的信息记录到本地文件系统。可以通过更新应用程序代码将日志输出到边车容器的 stdout 或 stderr,通过共享 Pod 卷将日志数据流式传输到外部源。也可以采用基于主机的日志记录工具,使用 Kubernetes 的 hostPath 挂载来读取主机日志和容器应用程序日志,示例代码如下:
超级会员免费看
订阅专栏 解锁全文
1319

被折叠的 条评论
为什么被折叠?



