Kubernetes中，有状态正在崛起

2017年1月，笔者认为Kubernetes存储的问题将在18个月内解决。事后看来，这有点乐观。到现在已经五年了，笔者为研究云原生存储问题而制定的框架（在奥斯汀的KubeCon上介绍）仍然非常流行，许多组织仍在努力解决如何在Kubernetes中提供持久性。

笔者在Ondat担任咨询委员会成员。吸引笔者来到Ondat的是这样一个愿景：用户可以利用容器和Kubernete为无状态应用程序提供好处，并为有状态工作负载实现所有这些好处。鉴于有状态应用程序在大多数业务解决方案中的核心作用，这些可靠性、可扩展性、自动化和更敏捷的开发方面的改进意义重大。对笔者来说，这曾经是，现在仍然是，一个巨大的机会。

有状态的Kubernetes

Kubernetes和容器基于无状态工作负载的思想，因此运行任何有状态的东西都会打破一个基本的基本假设。在谷歌，持久性存储是一个已解决的问题。他们不担心在云原生环境中运行存储。

但谷歌大多不使用传统的SQL存储——他们大多使用自己的分布式数据库和键值存储。相比之下，大多数运行有状态应用程序的公司将使用标准的关系数据库。要考虑一个新的平台，如面向有状态应用程序的Kubernetes，这些用户需要大规模运行流行的数据库，如PASGRESs或MySQL，并保证高可用性。

在笔者最近担任CNCF生态系统副总裁期间，每天都与Kubernetes终端用户交谈，很明显，持久性存储对他们中的许多人来说仍然是一个问题。当组织使用关系数据库支持在Kubernetes上运行的有状态应用程序时，很大一部分仍然依赖于托管数据库服务，如Amazon的RDS，或者完全在Kubernetes之外运行数据库。

即使是CSI驱动程序的生产版本，用户也可能对在Kubernetes中部署关键应用程序犹豫不决。这些解决方案未能获得真正的Kubernetes原生有状态开发的许多好处和潜力。用户并没有有效地设计一种安全的方式让数据生活在短暂的节点和容器中，而是将存储从Kubernetes之外拉回来。这分离并重复了确保计算和数据恢复能力的任务，给数据库和应用程序性能设置了主要上限。也许最重要的是，它限制了Kubernetes（特别是调度器）围绕工作负载效率和高可用性有效提供核心计算功能的能力。连接外部存储的节点变成了“宠物”而不是“牛”。

FinOps

特别是对于托管数据库，采取安全、简便的方式交付有状态的应用程序会带来更大的影响。成本显然是最明显的。FinOps的崛起不出意外，云成本管理的重要性比笔者预期的要大。

FinOps最基本的功能是管理和降低云成本，这使得RDS等托管数据库服务成为一个明显的目标。尽管FinOps正在超越这一点，但领先的FinOps实践者正在越来越多地探索如何更有效地利用云原生环境来优化总体IT成本，存储成为关键要素之一。

组织需要保持对其存储的完全控制。在Kubernetes中安装一个新的数据库现在很简单，但是Day 2的运维还不清楚。对正在运行的数据库和存储维护、升级、回滚等都可能非常复杂。看似直截了当的架构决策会极大地影响成本、弹性和可扩展性。

在许多情况下，云存储服务和托管数据库服务是一个合适的解决方案，但需要考虑对存储控制和预先锁定的权衡和影响。

展望应用程序的可移植性

笔者的另一个预测是交叉云和云可移植性的成熟，这是笔者最近与IBM的Mo Haghighi深入探讨的一个问题。应用程序可移植性对于任何组织与云提供商都至关重要，对FinOps也至关重要。存储锁定，尤其是托管数据库服务，严重影响组织在云之间移动应用程序的能力。虽然与笔者交谈过的许多最终用户都渴望运行多云以实现弹性并使用特定于云的服务，但多云存储仍然是一个挑战。

你可以交付多云有状态应用程序，可以提供在Kubernetes中安全驻留和运行的存储。业界迫切需要改进更好的工具，尤其是最佳实践——解决方案是Kubernetes原生数据层，让你能够控制存储。

原文链接：

https://thenewstack.io/the-growth-of-state-in-kubernetes/