良好实践

What is “Reconciliation” in Operators?

当你使用 Kubebuilder 创建一个项目时，可以查看在 cmd/main.go 中生成的代码。这段代码初始化了一个 Manager，项目依赖于 controller-runtime 框架。这个 Manager 管理着 Controllers，提供了一种调整功能，用于在集群内同步资源直到达到所需状态。

调整是一个持续的循环，执行必要的操作以保持期望的状态，遵循Kubernetes的原则，如控制循环。有关更多信息，请查阅Kubernetes的Operator模式文档，以更好地理解这些概念。

为什么重调应该是幂等的？

在开发运算符时，控制器的对账循环需要是幂等的。通过遵循 运算符模式，我们创建 控制器，这些控制器提供一个对账函数，负责在集群上同步资源，直到达到期望状态。开发幂等的解决方案将允许对账器正确响应通用或意外事件，轻松处理应用程序的启动或升级。更多相关解释可以参考 这里。

根据特定事件编写调整逻辑，会违反 Operator 模式的建议，并且违背了controller-runtime的设计原则。这可能导致不可预见的后果，例如资源被卡住，需要人工干预。

理解 Kubernetes API 和遵循 API 约定

构建操作器通常涉及扩展 Kubernetes API 本身。了解自定义资源定义（CRDs）如何与 Kubernetes API 交互是很有帮助的。此外，关于分组、版本和种类的 Kubebuilder 文档 也可能有助于更好地理解这些与操作器相关的概念。

此外，我们建议您查看 Kubernetes 上的 Operator 模式 文档，以更好地理解使用 KubeBuilder 构建的标准解决方案的目的。

为什么您应该遵循 Kubernetes API 的约定和标准

遵循 Kubernetes API 规范和标准 对于最大化应用程序和部署的潜力至关重要。通过遵循这些既定实践，您可以在多个方面受益。

首先，遵循标准确保了Kubernetes生态系统内的无缝互操作性。遵循约定使您的应用程序能够与其他组件和谐工作，从而减少兼容性问题并促进一致的用户体验。

其次，遵循API标准可以提高应用程序的可维护性和故障排除能力。采用熟悉的模式和结构使得调试和支持您的部署变得更加容易，从而提高了运营效率和快速问题解决的能力。

此外，利用Kubernetes API的惯例可以让您充分发挥平台的全部功能。通过在定义的框架内工作，您可以利用Kubernetes提供的丰富特性和资源，从而实现可扩展性、性能优化和弹性。

最后，遵循这些标准可以使您的本土解决方案具备未来适应能力。通过与不断发展的Kubernetes生态系统保持一致，您可以确保与未来更新、新功能以及活跃的Kubernetes社区引入的增强功能保持兼容。

总之，通过遵循Kubernetes API的约定和标准，您可以实现无缝集成、简化维护、优化性能和为未来做好准备的潜力，这些都为您的应用程序和部署的成功做出了贡献。

Why should one avoid a system design where a single controller is responsible for managing multiple CRDs (Custom Resource Definitions)(for example, an ‘install_all_controller.go’)?

避免采用一种设计方案，其中同一个控制器对账多个 Kind。将多个 Kind（如 CRD）都由同一个控制器管理，通常与 controller-runtime 提出的设计相悖。此外，这可能会损害封装性、单一职责原则和内聚性等概念。损害这些概念可能会导致意想不到的副作用，并增加扩展、重用或维护操作器的难度。在一个操作器中，由一个控制器管理多个自定义资源（CRs）可能会导致几个问题：

• 复杂性：单个控制器管理多个自定义资源（CR）可能会增加代码的复杂性，从而使其更难理解、维护和调试。
• 可扩展性：每个控制器通常管理一种类型的自定义资源（CR）以实现可扩展性。如果一个控制器处理多个CR，它可能成为瓶颈，从而降低系统的整体效率和响应速度。
• 单一职责原则：遵循软件工程中的这一原则，理想情况下每个控制器应该只有一个职责。这种方法简化了开发和调试，并使系统更加健壮。
• 错误隔离：如果一个控制器管理多个自定义资源（CR），并且发生错误，可能会影响它管理的所有 CR。为每个 CR 配置一个单独的控制器可以确保一个控制器或 CR 的问题不会直接影响其他资源。
• 并发与同步：一个单一的控制器管理多个自定义资源（CR）可能导致竞争条件，并需要复杂的同步，特别是当这些CR之间存在相互依赖时。

总之，虽然让一个控制器管理多个CR看起来效率较高，但这通常会导致更高的复杂性、较低的可扩展性以及潜在的稳定性问题。通常遵循单一职责原则更为合适，每个CR由其自己的控制器管理。

为什么你应该采用状态条件

我们建议您使用状态条件（Status Conditionals）来管理您的解决方案，遵循K8s API 约定，因为：

• 标准化：条件提供了一种标准化的方式来表示操作员自定义资源的状态，使用户和工具更容易理解和解释资源的状态。
• 可读性：通过使用多个条件的组合，条件可以清晰地表达复杂的状态，使用户更容易理解资源的当前状态和进展。
• 可扩展性：当新的功能或状态被添加到您的 Operator 时，可以轻松扩展条件以表示这些新状态，而无需对现有的 API 或结构进行重大更改。
• 可观察性：集群管理员和外部监控工具可以监视和跟踪状态条件，从而更好地了解由操作员管理的自定义资源的状态。
• 兼容性：通过采用在 Kubernetes API 中使用条件的常见模式，Operator 作者确保他们的自定义资源与更广泛的生态系统保持一致，这有助于用户在与集群中的多个 Operator 和资源交互时获得一致的体验。