Kubernetes Operators🦄 简单解释

了解什么是 Kubernetes Operator、为什么会出现这个 Operator 概念以及何时应该使用它们

概述：
为了让您有个大致的了解，Operator 主要用于有状态应用程序。因此，我首先比较一下 Kubernetes 如何管理无状态和有状态应用程序。然后，我会比较不使用 Operator 和使用 Kubernetes Operator 部署和管理有状态应用程序的优劣。

• 1. Kubernetes 上的无状态应用程序
• 2. 无需 Operator 的有状态应用程序
• 3. 有状态应用程序与 Operator 🦄

► 观看完整视频🎬：Kubernetes Operators 讲解

1. Kubernetes 上的无状态应用程序

Kubernetes 可以以全自动的方式管理无状态应用程序的完整生命周期，因为这些应用程序没有部署的业务逻辑。

这意味着 K8s 不需要知道任何特定于应用程序的业务逻辑即可自动创建、更新和删除它们。🔝

所以基本上，一旦部署了应用程序，您就无需亲自控制它是否正常运行。而且，当您进行诸如更新或扩展之类的小改动时，它几乎可以毫无问题地运行。

太棒了！😎

2. 无 Operator 的有状态应用程序

对于有状态应用程序（例如数据库），整个过程并不那么简单。
它们需要在整个生命周期中提供更多的“指导”，因为有状态应用程序的副本并不完全相同。

每个实例都有其状态和身份。这意味着，它们需要按照特定的顺序启动、更新和销毁。这些细节甚至会因应用程序而异：Mysql 有其特定的执行方式，Postgres 和 Elasticsearch 有其他执行方式，等等。🙄

因此，Kubernetes 本身/内部并不具备自动化部署每个有状态应用程序所需的所有知识🤷🏻‍♂️。

这就是为什么这类应用程序需要人工干预——需要那些“操作”这些应用程序的人。👩🏻‍💻

3. 使用 Operator 实现有状态应用程序

操作员解决了这个问题，基本上用“软件”操作员取代了这个“人类”操作员。

DevOps 团队需要执行的所有手动任务现在都被打包到一个程序中，该程序具有关于如何部署特定应用程序的知识和智能，例如 Postgres 或 Prometheus。💡

那么 Operator 是如何做到这一点的呢？🤔

其核心具有与 k8s 相同的控制循环机制，用于监视应用程序状态的变化。

它还使用 CRD，它基本上是一个扩展 Kubernetes API 的自定义 K8s 组件。

因此，它以基本的 Kubernetes 资源及其控制器概念为基础，并在此基础上包含领域或特定于应用程序的知识，以自动化其“操作”的应用程序的整个生命周期：

更多详情请见此处的视频👩🏻‍💻

Kubernetes 101 ►紧凑易读的电子书包 🚀
这是一种快速查找某些内容或在工作中刷新知识的便捷方法，可用作备忘单 😎

喜欢、分享并关注我😍以获取更多内容：

• 私人 Facebook 群组
• 叽叽喳喳
• YouTube
• Instagram
• LinkedIn