广告

Kubernetes上的有状态工作负载迎来转折点

  • 浏览(237)
  • 评论(0)
  • 译者:k8s

Kubernetes正在成为行业标准——Cockroach Labs和红帽发现,94%接受调查的组织在Kubernetes上部署服务和应用程序。标准化意味着在任何环境中为任何工作负载运行任何堆栈,包括有状态的工作负载。

在Kubernetes上运行有状态工作负载过去是不可行的,但Data on Kubernetes 2021 Report中的数据发现,90%的受调查公司认为Kubernetes已准备好应付有状态工作负载。更令人惊讶的是,他们中的大多数(70%)正在生产中运行。因此,在Kubernetes上运行数据是绝对可能的,转折点是operators。

2016年引入的Kubernetes operators是可编程扩展,用于执行Kubernetes原生无法处理的操作。operators通过扩展Kubernetes API的功能,提供智能、动态的管理能力。当一些人,例如Docker的创始人,将其视为可编程微平台时,它们对运行有状态工作负载的影响最大。

Day2操作

为什么?虽然Kubernetes现在为运行面向数据的工作负载提供了坚实的基础,但一些特定于应用程序的任务(更具体地说是Day2的操作)无法原生处理。以数据库为例,Day2的操作包括执行备份、拍摄快照、执行故障切换、应用补丁或索引列。因为每个数据库的处理方式都略有不同,所以Kubernetes很难以原生方式处理这种特定于应用程序的操作方式。

这就是为什么在Kubernetes上运行一个有状态的应用程序肯定是可能的,但它的好坏在很大程度上取决于operators的好坏。Kubernetes社区的数据发现,42%的operator用户抱怨其参差不齐的质量。理解应用程序的细节可能是一项具有挑战性的任务,更不用说将它们封装在一个高度分布式和动态的环境中,即Kubernetes中。

虽然Operator Framework提供了一套可靠的开发工具和Kubernetes组件,但对于复杂用例(如多集群),仍有改进的空间,正如KubeCon EU的DataStax产品经理Christopher Bradford强调的那样。

对于终端用户来说,从250多个operator中选择合适的可能是一项艰巨的任务。不同程度的质量可以通过以下事实来解释:它们是由广泛的组织构建的,例如服务公司、供应商、开源软件社区和个人。虽然有一些最佳实践可以遵循,但对于如何构建它们并没有强有力的指导,显然也没有监督。最后,由于执行相同操作的有效方式可能不同,operator可能会采取不同的技术方法,这必须由用户权衡。

Operator Framework提供了一个“功能级别”图,可以帮助最终用户了解operator的成熟度水平。它分为五个级别:

级别1——基本安装:自动化应用程序配置和配置管理。

级别2——无缝升级:支持补丁和小版本升级。

级别3——全生命周期:应用程序生命周期、存储生命周期(备份、故障恢复)。

级别4——深入了解:指标、警报、日志处理和工作负载分析。

级别5——自动化:水平/垂直缩放、自动配置、调优、异常检测、调度调优。

解决operator质量问题的另一个有希望的方法是回到Kubernetes成功使用的方法:社区领导的管理方法,更具体地说,是CNCF。PostgreSQL专家EDB最近决定开放其PostgreSQL operator CloudNativePG的源代码,并将其提交给CNCF,目标是毕业。

CNCF项目的三个阶段是沙箱、孵化和毕业。为了向上发展,每个项目都需要证明它是可信的、可持续的、被广泛采用的、具有健康的变化率,并且是由多个组织的贡献者开发的。该过程需要数年时间,但它将确保通过该过程的operator生产就绪。

Kelsey Hightower)在宣布Oracle数据库operator时表示,“我们已经正式跨越了鸿沟”,他指的是在Kubernetes上运行有状态的工作负载。现在,这种做法不再只限于早期采用者,而是该行业提高标准和稳健性的时候了。

原文链接:

https://thenewstack.io/stateful-workloads-on-kubernetes-are-a-thing-but-there-is-a-twist/

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头