operator白皮书
摘要
维护应用程序基础结构需要许多重复性的人为操作,而这些重复性操作通常没有太大的意义。
计算机是执行精确任务的首选方法,可以验证对象的状态,从而使基础设施需求能够被编码。operator
提供了一种方法来封装应用程序所需的活动、检查和语句管理。
在Kubernetes
中,operator
通过扩展API
的功能来提供智能的动态管理功能。
这些operator
组件允许通用流程的自动化以及响应式应用程序不断适应其环境。这反过来促进应用更快速的开发,减少故障点,更低的平均恢复时间,并增加了工程自治权。
鉴于operator
模式越来越受欢迎,白皮书的制定已成为当务之急,以此来帮助新手和专家学习社区认可的最佳实践,以实现他们的目标。
在本文档中,我们不仅概述了operator
的分类,还介绍了operator
应用程序管理系统的推荐配置、实现和用例。
简介
该白皮书在比Kubernetes
更广泛的背景下定义了operator
。白皮书描述了operator
的特征和组件,概述了目前正在使用的常见模式,并解释了它们与Kubernetes
控制器的区别。
白皮书还深入研究了operator
的功能,如备份、恢复和自动配置调优,深入了解了当前正在使用的框架、生命周期管理、安全风险和用例。
本文包括最佳实践,包括可观察性和安全性、技术实现和CNCF
维护的代码样本。
文档目标
本文的目标是在Kubernetes
和其他容器协调器的上下文中为云原生应用程序提供operator
的定义。
文档目标受众/最低经验水平
本文档面向应用程序开发人员、Kubernetes
集群运营商和服务提供商(内部或外部)——他们希望了解运营商及其可以解决的问题。
它还可以帮助已经关注运营商的团队了解何时何地使用它们以达到最佳效果。白皮书假设使用者了解基本的Kubernetes
知识,如熟悉Pods
和deployment
。
基本原理
Kubernetes
和其他容器协调器的成功,一直归功于他们对容器的主要功能的关注。尽管部分企业开启了云原生路线,但与更具体的用例(微服务、无状态应用程序)合作更有意义。
随着Kubernetes
和其他容器协调器的声誉和可扩展性的增长,需求变得更加雄心勃勃。使用协调器的完整生命周期功能的愿望也转移到了高度分布式的数据存储上
operator
模式可以解决状态管理问题。通过利用Kubernetes
内置的功能,如自愈、协调和扩展应用程序特定的复杂性;
可以将任何应用程序的生命周期、操作自动化,并将其转化为功能强大的产品。
operator
与Kubernetes
不应是绑定的,管理完全自动化的应用程序的思想可以导出到其他平台。本文的目的是把operator
这个概念带到一个比Kubernetes
本身更高的层次。
Operator设计模式
本节用高级概念描述operator
模式。下一节Kubernetes operator
定义将根据Kubernetes
对象和概念描述operator
模式的实现。
operator
设计模式定义了如何使用领域特定的知识和声明性状态,来管理应用程序和基础设施资源。
operator
模式的目标是通过在代码中捕获领域特定的知识并使用声明性API
公开它,
从而减少保持应用程序处于健康和良好维护状态所需的手动强制性工作(如何备份、扩展、升级……)
通过使用operator
模式,可以在代码中获取关于如何调整和维护资源的知识,通常也可以在单个服务(也称为控制器)中获取。