k8s笔记——helm chat与k8s Operator区别

k8s Operator

Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。你可以使用 Kubernetes 自动化部署和运行工作负载，甚至可以自动化 Kubernetes 自身。

Kubernetes 的 Operator 模式 概念允许你在不修改 Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联控制器来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当自定义资源的控制器。

自定义资源

Kubernetes 中的自定义资源是对 Kubernetes API 的扩展，它使向 Kubernetes 集群添加默认情况下不可用的功能成为可能。您可以通过创建自定义资源定义(CRD)来实现这一点。

如果要使用 Kubernetes Operator 来安装或管理应用程序，您可以创建实现该应用程序所需功能的 CRD。如果您随后将 CRD 与 Operator 的控制器组合，Kubernetes 控制器例程将检测并部署它。

Operator示例

想要更详细的了解 Operator？下面是一个示例：

有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。
一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
Operator 代码的容器镜像。
控制器代码，负责查询控制平面以找出已配置的 SampleDB 资源。
Operator 的核心是告诉 API 服务器，如何使现实与代码里配置的资源匹配。
- 如果添加新的 SampleDB，Operator 将设置 PersistentVolumeClaims 以提供持久化的数据库存储，设置 StatefulSet 以运行 SampleDB，并设置 Job 来处理初始配置。
- 如果你删除它，Operator 将建立快照，然后确保 StatefulSet 和 Volume 已被删除。
Operator 也可以管理常规数据库的备份。对于每个 SampleDB 资源，Operator 会确定何时创建（可以连接到数据库并进行备份的）Pod。这些 Pod 将依赖于 ConfigMap 和/或具有数据库连接详细信息和凭据的 Secret。
由于 Operator 旨在为其管理的资源提供强大的自动化功能，因此它还需要一些额外的支持性代码。在这个示例中，代码将检查数据库是否正运行在旧版本上，如果是，则创建 Job 对象为你升级数据库。

部署 Operator

部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到你的集群中。跟运行容器化应用一样，控制器通常会运行在控制平面之外。例如，你可以在集群中将控制器作为 Deployment 运行。

使用 Operator

部署 Operator 后，你可以对 Operator 所使用的资源执行添加、修改或删除操作。按照上面的示例，你将为 Operator 本身建立一个 Deployment，然后：

shell 复制代码

kubectl get SampleDB                   # 查找所配置的数据库

kubectl edit SampleDB/example-database # 手动修改某些配置

可以了！Operator 会负责应用所作的更改并保持现有服务处于良好的状态。

编写你自己的 Operator

如果生态系统中没有可以实现你目标的 Operator，你可以自己编写代码。

你还可以使用任何支持 Kubernetes API 客户端的语言或运行时来实现 Operator（即控制器）。

以下是一些库和工具，你可用于编写自己的云原生 Operator。

Charmed Operator Framework
Java Operator SDK
Kopf (Kubernetes Operator Pythonic Framework)
kube-rs (Rust)
kubebuilder ★
KubeOps (.NET operator SDK)
Mast
Metacontroller，可与 Webhook 结合使用，以实现自己的功能。
Operator Framework ★
shell-operator

现成的Operator

在 OperatorHub.io 上找到现成的、适合你的 Operator

OperatorHub.io is a new home for the Kubernetes community to share Operators. Find an existing Operator or list your own today.

Kubernetes Operator与Helm的11个关键区别

如果您已经阅读到这里，那么您知道 Kubernetes Operator 和 Helm Chart 都可实现相同的目标: 安装和管理应用程序。两者也都可用于部署帮助 Kubernetes 故障排除和监控的工具。

但是 Kubernetes Operator 和 Helm Chart 通过稍微不同的方式实现这些目标。以下是 Operator 和 Helm Chart 的主要区别。

1. 范围和功能

总体来说，Helm Chart 范围更窄。Helm Chart 的主要目的是安装标准应用程序，也就是那些可以根据现有容器镜像运行的应用程序。如果您需要运行依赖特殊 Kubernetes API 扩展的自定义应用程序，那么 Helm 就不是一个好的解决方案，不过您可以为此目的使用 Operator。

类似地，在配置方面 Helm 提供的灵活性更少。您可以在安装 Chart 时向 Helm 传递参数以配置应用程序，但只有在 Chart 被设计为支持这些参数时才行。

相比之下，使用 Kubernetes Operator，在定制应用程序方面，天空------或者更确切地说，您编写的代码------就是极限。

2. 复杂性和灵活性

与 Helm 相比，Operator 增加的灵活性所带来的代价是 Operator 也更复杂。创建 Operator 需要编写 CRD，而您可以根据一些相对简单的 YAML 代码创建 Helm Chart。

此外，从安装的角度来看，Helm 不太复杂，因为您可以用一个命令就安装它。安装 Operator 通常需要运行长的 kubectl 命令。

3. 定制化

如前所述，Operator 提供了更大的定制化空间，因为您可以实现 CRD 支持的任何功能。 Helm Chart 的某些配置方面是可以定制的，但仅当创建 Helm Chart 的开发人员在构建 Chart 时实现了配置选项。

这里的区别有点像从源代码构建标准应用程序和使用包安装应用程序之间的区别。当您从源代码构建时，您可以修改源代码以自定义应用程序。但如果您使用包进行安装，则只能修改包管理系统和环境支持的配置选项。

4. 云成本考量

因为 Chart 的定制性通常不如 Operator，所以它们更容易给您的环境带来冗余。 Helm Chart 可能会安装和运行您严格意义上不需要的应用程序特性，除非您重写整个 Chart，否则可能没有办法关闭这些特性。相比之下，使用 Operator，您可以精确控制哪些特性需要运行。

因此，使用 Chart 安装的应用程序更有可能消耗更多资源，从而增加云成本。总体来说，与内存泄漏或浪费 CPU 的有缺陷代码等问题相比，这对您的云端总支出的影响要小得多，但如果您想优化成本，这仍值得考虑。

5. 学习曲线

可以肯定，几乎每个人都会觉得学习使用 Helm 比学习 Operator 更简单。Chart 的工作方式与任何类型的软件包非常相似，所以如果您在其他上下文中使用过软件包，应该可以很快掌握 Helm。

相比之下，Operator 基于 Kubernetes 的独有概念。在您完全理解像控制器和 CRD 这样的关键 Kubernetes 概念之前，您不应该期望理解 Operator 的工作原理，更不用说创建或修改 Operator 了。

6. 自动化

Operator 和 Chart 都可以帮助自动执行您否则必须手动执行的应用程序安装和管理任务。但是，由于 Helm 的范围仅限于管理标准应用程序，所以它不提供太多自动化功能。

您可以使用 Helm 根据容器镜像自动安装或更新应用程序，但您无法自动执行超出 Helm 原生功能范围的定制应用程序配置更改。但是，使用 Operator，您可以自动执行 Kubernetes API 和控制器支持的任何操作。

7. 生命周期管理

Operator 和 Chart 在支持应用程序生命周期管理方面有共同之处，那就是您可以使用它们来安装、更新和删除应用程序。但是，使用 Helm 进行的生命周期管理有点过于简单粗暴，调整不太细致。

要使用 Helm 管理应用程序生命周期，您只能使用内置的命令，如 install、upgrade 和 uninstall。您可以使用新版本替换旧版本的应用程序，或者完全删除应用程序。但是，如果不升级整个应用程序，您就无法对现有应用程序进行细微修改，而通过修改应用程序的 Operator 就可以做到这一点。

8. 维护

同样，在应用程序维护方面，Operator 提供了更大的灵活性和控制能力。如果您只是想升级或删除应用程序，可以使用 Helm 来完成。但是如果您想执行其他应用程序维护任务，如修改应用程序的存储配置，除非您创建一个新的 Helm Chart 并使用它重新安装应用程序，否则 Helm 并无益处。不过，使用 Operator 就可以进行更细粒度的维护更改。

9. 使用案例

总的来说，Operator 支持的使用案例比 Helm 更广泛。后者只擅长应用程序的安装、升级和删除。Operator 可以做到这些，但它们还支持应用程序备份等使用案例。

10. 适合 GitOps

GitOps 意味着使用存储在 Git 仓库中的代码来管理对应用程序部署和基础设施的更改。如果您在 Git 中存储应用程序和基础设施的配置数据，就可以从那里自动将配置推送到生产环境。您还可以根据 Git 中的代码版本历史记录跟踪对资源的更改。

由于您可以在 Git 中存储 Operator 和 Chart 的代码，两种解决方案都与 GitOps 方法论兼容。也就是说，可以认为当与 Operator 一起使用时，GitOps 提供更多好处，因为您可以对 Operator 进行的更改范围更广。从这个意义上说，能够以细粒度方式跟踪更改更有价值。使用 GitOps，对 Operator 中的一行代码的更改就很容易跟踪 - 如果您更改了 Operator，某些事情发生故障，并且您想找出触发问题的更改，那么这可能很有用。

11. 社区和生态系统

Operator 和 Helm 都拥有强大的社区和生态系统。在 OperatorHub.io 和 Artifact Hub 等网站上可以轻松找到公开可用的 Operator 和 Helm Chart。两种解决方案的丰富文档也可以免费获得。

也就是说，就社区参与而言，Operator 和 Helm 之间的一个重要区别在于，Helm 是一个开源项目，拥有自己的一套官方资源，而 Operator 没有专门的项目(尽管 Kubernetes 项目维护着其文档)。从这个意义上说，Helm 有一个特定的"官方"社区，但 Operator 没有。

Kubernetes Operator与Helm: 该选择哪一个？

对于"应该选择 Operator 还是 Helm？"这个问题，有两种方法。它们取决于您是要将应用程序分发给其他用户，还是仅仅想安装一个应用程序。

应用分发

考虑因素	选择什么
无状态应用程序	Helm Chart
需要定制的应用程序	Operator
用户的 Kubernetes 经验有限	Helm Chart
需要支持复杂的维护	Operator

如果您正在分发一个应用程序，当以下条件满足时，请选择 Helm Chart:

您的应用程序很简单。
配置相对简单(或者您不需要在安装时支持太多配置选项)。
您希望为用户提供尽可能简单的安装体验。
您的应用程序是无状态的，并且不需要特殊配置。

如果满足以下条件，Operator 是一个更好的选择:

您的应用程序需要特殊的功能或配置(如复杂的有状态存储)，这些功能或配置若不使用 CRD 就难以或无法实现。
您想要自动化除应用安装或生命周期管理之外的其他流程(如应用备份)。

应用安装

考虑因素	选择什么
没有可用的 Helm Chart	Operator
简单安装是首要任务	Helm Chart
您的 Kubernetes 经验有限	Helm Chart
您想要定制该应用	Operator

如果您作为用户要在 Kubernetes 上安装一个应用程序，您应该首先检查该应用程序是否存在 Operator 和/或 Helm Chart。许多项目同时提供两者，但如果只有其中一个可用，那么如何安装该应用程序的问题就解决了:使用任何存在的东西。

如果您同时找到了 Operator 和 Chart，如果满足以下条件，请选择 Helm:

您想要简单的安装体验。
您不需要定制该应用。

如果您已经熟悉 Operator，并且/或者您需要以 Helm 无法实现的方式定制该应用，则 Kubernetes Operator 更具优势。

总结

有时，使用 Operator 而不是 Helm 并没有明确的优势，反之亦然。毕竟，两种解决方案支持大多数相同的用例。

但在底层，Operator 更复杂和可定制化，这对于高级应用程序安装或维护任务来说是一个优势。对于更简单的需求，Helm Chart 通常是更好的解决方案。

参考资料

kubernetes-operator-vs-helm