除了管理部署在集群上的应用程序，我们看到 Kubernetes Operator 模式越来越多地用于其他地方。 非集群资源的 Operator 模式 可以利用自定义资源和在 Kubernetes 控制面板中实现的事件驱动调度机制，来管理与集群外部相关的活动。该技术建立在由 Kube 管理的云服务的思想之上，并将其扩展到其他活动中，例如持续部署或者及时响应外部存储库的变化。与专门构建的工具相比，这种技术的一个优势就是它开辟了一系列的工具，这些工具有的是 Kubernetes 自带的，有的则来自更广泛的生态社区。您可以使用 diff 、 dry-run 或 apply 等命令与 Operator 的自定义资源进行交互。Kube 的调度机制消除了以正确顺序编排活动的必要性，从而使开发更容易。如 Crossplane 、 Flux 和 Argo CD 等开源工具都利用了这项技术。随着时间的推移，我们希望看到更多这样的工具出现。我们还观察到的一个现象，虽然每个工具都有自己的适用场景，但它们不可避免的会被误用或过度使用。对此我们有个“老生常谈”：一项工具可以应用在某个场景，并不表示它就应当应用在这个场景。在确认简单的传统方法不适用之前，请不要创建自定义资源定义，因为这会导致额外的复杂性。
除了管理部署在集群上的应用程序，我们看到 Kubernetes Operator 模式越来越多地用于其他地方。非集群资源的 Operator 模式可以利用自定义资源和在 Kubernetes 控制面板中实现的事件驱动调度机制，来管理与集群外部相关的活动。该技术建立在由 Kube 管理的云服务的思想之上，并将其扩展到其他活动，例如持续部署或者及时响应外部存储库的变化。与专门构建的工具相比，这种技术的一个优势就是它开辟了一系列的工具，这些工具有的是 Kubernetes 自带的，有的则来自更广泛的生态社区。您可以使用 diff 、 dry-run 或 apply 等命令与 Operator 的自定义资源进行交互。Kube的调度机制消除了以正确顺序编排活动的必要性，从而使开发更容易。如 Crossplane 、 Flux和 ArgoCD 等开源工具都利用了这项技术。随着时间的推移，我们希望看到更多这样的工具出现。
