云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载导读Operator 是部署在 Kubernetes 集群上的自定义控制器其生命周期管理能力存在明显的成熟度差异。Operator Framework 社区以Operator 能力等级模型Operator Capability Levels定义了从 Level 1Basic Install到 Level 5Auto Pilot的五级能力阶梯用于统一描述用户可以从一个 Operator 中获得的特性。本文以 Operator SDK 仓库官方文档为核心系统讲解每一能力等级的定义、能力清单、自检引导问题并结合仓库源码CSV 生成、relatedImages 收集、scorecard 描述符校验等实现说明如何在实际项目中验证和落地这些能力帮助你在设计、实现与打包 Operator 时形成清晰的可度量目标。核心概念与术语在讨论能力等级之前先明确文档使用的四组核心术语它们贯穿全文所有等级的描述Operator安装在 Kubernetes 集群上的自定义控制器承载领域运维知识。Operand由 Operator 以服务形式提供并管理的受管工作负载。Custom ResourceCROperator 提供的CustomResourceDefinition的一个实例它代表 Operand 本身或对 Operand 的一次操作也被称为主资源primary resources。Managed resourcesOperator 用来构成 Operand 的 Kubernetes 对象或集群外服务也被称为次级资源secondary resources。Custom Resource DefinitionCRDOperator 的 API为 CR 提供蓝图与校验规则。能力等级从 1 到 5 依次递进每一级代表一组独立的管理特性。不管理任何工作负载、或将工作委托给集群外编排服务的 Operator 停留在 Level 1 之下通常认为仍属于 Level 1 范畴。Level 1 - Basic Install自动化安装与配置Level 1 是最基础的能力等级核心要求是Operator 能够通过 CR 完整地供给一个应用并将所有安装配置细节收口到 CR 中。Operator 本身也应支持多种安装方式kubectl、OLM、Catalog source。凡是让 Operand 运行所必需的配置都应当尽量通过 CR 表达避免要求用户脱离 Kubernetes 去手工维护配置文件。工作负载的安装该等级下 Operator 应具备以下行为Operator 部署 Operand 或配置集群外资源Operator 等待受管资源达到健康状态Operator 借助 CR 的status块向用户传达应用或受管资源的就绪状态。示例一个数据库 Operator 通过创建Deployment、ServiceAccount、RoleBinding、ConfigMap、PersistentVolumeClaim和Secret来部署数据库初始化空数据库 schema并在数据库可以接受查询时通过状态块对外发出就绪信号。工作负载的配置Operator 通过 CR 的spec区段提供配置Operator 对配置及其变更进行调谐reconcile并与受管资源的状态保持同步。示例管理数据库的 Operator 在用户修改数据库 CR 实例后通过调整底层PersistentVolumeClaim的容量来实现数据库扩容。Level 1 自检引导问题哪些安装配置可以在 CR 中设置还有哪些安装配置可以补充加入 CR能否在 CR 中设置 Operand 配置如果可以每个 Operand 支持哪些配置能否通过 CR 或 Operator 部署的环境变量覆盖 Operand 镜像当 CR 配置变化时受管应用/工作负载是否以非破坏性方式更新CR 的status是否反映配置变更当前已被应用还有哪些 Operand 配置可以补充所有实例化的 CR 是否都包含status块如果是它是否给用户提供了足够的应用状态洞察所有 CR 是否都有列出合法取值与必填字段的文档如果 Operator 以 OLM 方式打包其 CSV 是否在spec.relatedImages下列出了 CSV 中使用的全部镜像源码佐证CSV 中的 capabilities 注解与 relatedImagesOperator SDK 在生成 ClusterServiceVersionCSV基础文件时会直接写入metadata.annotations.capabilities注解。在 internal/generate/clusterserviceversion/bases/clusterserviceversion.go 中可以看到当用户未显式指定时默认值即为Basic InstallLevel 1并在 newBase 中写入注解if b.Capabilities { b.Capabilities Basic Install } ... Annotations: map[string]string{ capabilities: b.Capabilities, alm-examples: [], },也就是说使用operator-sdk generate kustomize manifests等命令生成的 CSV 基座默认声明 Level 1 能力开发者应根据实际实现手动提升该注解的取值。关于该注解的合法取值可参见 website/content/en/docs/olm-integration/generation.md其中明确metadata.annotations.capabilities表示Operator 能力等级并链接到本文所依据的成熟度模型文档。针对自检问题 10 的spec.relatedImagesSDK 提供了自动化收集实现FindRelatedImages见 internal/cmd/operator-sdk/generate/internal/relatedimages.go会扫描控制器管理器的环境变量收集 Operator 使用的全部镜像并通过名称与镜像引用去重后生成RelatedImage列表避免 CSV 中镜像信息遗漏或重复。Level 2 - Seamless Upgrades无缝升级无缝升级意味着升级对用户尽可能无感。Operator 与 Operand 的升级通常相辅相成Operator 升级后应自动让每个 CR 实例化的资源进入新的期望状态从而完成 Operand 升级。升级可以有多种定义方式例如更新 Operand 软件、以及应用特有的内部变更如 schema 迁移。文档强调升级发生时什么会被升级、什么不会被升级必须非常清晰。受管工作负载的升级Operand 可以在升级 Operator 的过程中被升级Operand 也可以作为 CR 变更的一部分被升级Operator 需要理解如何升级旧版本 Operand——即先前由旧版本 Operator 管理的版本。Operator 的升级Operator 可以被无缝升级且能够继续管理旧版本 Operand 或将它们更新到新版本当 Operator 无法管理某个不受支持的 Operand 版本时必须在 CR 的status区段中传达这一事实。示例管理数据库的 Operator 可以在不丢失数据的前提下把现有数据库从旧版本更新到新版本——无论是作为配置变更的一部分还是作为 Operator 自身升级的一部分。Level 2 自检引导问题你的 Operator 能否升级 Operand你的 Operator 是否在自身升级过程中同步升级 Operand你的 Operator 能否管理旧版本的 OperandOperand 升级是否无中断如果升级期间存在停机Operator 是否在 CR 的status中传达这一点从实现角度看Level 2 要求 Operator 把旧版本兼容编码进调谐逻辑例如 Helm 类 Operator 依靠 watches.yaml 定义的版本映射与升级规则来驱动 release 升级而 Go 类 Operator 则需要通过版本化 API如v1alpha1、v1alpha2与转换逻辑来管理多版本 CR。Level 3 - Full Lifecycle完整生命周期Level 3 要求 Operator 自身提供备份与恢复能力除触发这些操作外无需任何额外人工干预。需要备份的是 Operand 管理的所有有状态数据CR 本身及 Operator 创建的 Kubernetes 资源无需备份——因为只要重新创建 CROperator 就应该把所有资源恢复到相同状态。此外若 Operator 尚未为 Operand 配置 Kubernetes 韧性最佳实践应在该等级补齐包括存活探针liveness probes、就绪探针readiness probes、多副本、滚动部署策略、PodDisruptionBudget、CPU 与内存的 requests/limits。生命周期特性Operator 提供创建 Operand 备份的能力Operator 能够从备份恢复 OperandOperator 编排 Operand 上的复杂重配置流程Operator 实现集群化 Operand 的故障切换fail-over与故障恢复fail-backOperator 支持向集群化 Operand 添加/移除成员Operator 支持应用感知的 Operand 伸缩。示例管理数据库的 Operator 通过刷新数据库日志并暂停对数据库文件的写活动创建应用一致性备份。Level 3 自检引导问题你的 Operator 是否支持备份 Operand你的 Operator 是否支持从备份恢复 Operand 并重新纳入管理你的 Operator 是否等待重配置工作按预期顺序完成如果存在集群仲裁cluster quorum你的 Operator 是否将其纳入考量你的 Operator 是否允许添加/移除 Operand 的只读从实例Operand 是否有存活探针Operand 是否有就绪探针该探针在 Operand 任何方面未就绪时例如数据库连接失败是否会失败Operand 是否使用滚动部署策略你的 Operator 是否为 Operand Pod 创建 PodDisruptionBudget 资源Operand 是否设置了 CPU requests 和 limitsLevel 4 - Deep Insights深度洞察Level 4 要求为 Operand 建立完整的监控与告警体系。当 Operand CR 被实例化时Prometheus 规则告警和 Grafana 仪表盘等所有资源都应由 Operator 自动创建。RED 方法是决定暴露哪些指标的良好起点Rate每秒请求数Errors这些请求中失败的数量Duration这些请求所花费的时间。告警设计上应遵循症状优先原则只对与终端用户痛苦相关的症状告警而非穷举一切可能引发痛苦的方式告警数量越少越好告警应链接到相关控制台便于快速定位故障组件。原生 Kubernetes 对象会为需要提醒用户或管理员的场景发出 Events 事件对象Operator 也应针对 Operand 相关的状态变化发出类似事件——这里的自定义指在部署方式本身已发出的事件之外额外发出 Operator/Operand 特有的事件。这与 CR 条件的状态描述符status descriptors结合能极大提升 Operator/Operand 行动的可见性Operator 本质上是编码化的领域知识最终用户不应为了看清资源现状而被迫掌握这些领域知识。事件与状态的处理应遵循 Kubernetes API 约定Events 与 Spec/Status 相关章节。监控Operator 暴露关于自身健康状况的指标Operator 暴露 Operand 的健康与性能指标。告警与事件Operand 发出有用的告警CR 发出自定义事件。示例数据库 Operator 持续解析数据库软件的日志输出理解值得关注的日志事件例如数据库文件磁盘空间耗尽并产生告警同时为数据库插桩暴露应用级指标例如每秒数据库查询数。Level 4 自检引导问题你的 Operator 是否暴露健康指标端点你的 Operator 是否暴露 Operand 告警每个告警是否有对应的标准操作流程SOP你的 Operator 是否在服务宕机时产生严重告警并对其他情况产生警告级告警你的 Operator 是否监视 Operand 以创建告警你的 Operator 是否发出自定义 Kubernetes 事件你的 Operator 是否暴露 Operand 性能指标源码佐证默认指标与描述符校验文档特别指出使用 Operator SDK或 KubebuilderCLI 构建的项目天然基于 controller-runtime而 controller-runtime 会默认导出一组参考指标controller_runtime_reconcile_total、workqueue 深度、rest_client 请求速率等可直接接入 Prometheus关于如何启用监控与添加自定义指标以及基于默认指标创建 Grafana 仪表盘的 JSON 清单可参考仓库内 website/content/en/docs/best-practices/observability-best-practices.md 与 SDK 生成的监控配置如 testdata/go/v4/monitoring/memcached-operator/config/prometheus/monitor.yaml 及其 metrics_service.yaml。在状态可见性方面SDK 的 scorecard 提供了专门校验SpecDescriptorsTest与StatusDescriptorsTest见 internal/scorecard/tests/olm.go分别验证 CSV 中所有spec字段与所有 CRD 是否都配置了对应描述符测试名称为olm-spec-descriptors与olm-status-descriptors。这意味着 Level 4 所要求的status 洞察 描述符可见性在 SDK 工具链中是可自动验证的硬性检查项而非仅停留在文档建议层面。Level 5 - Auto Pilot自动驾驶最高能力等级的目标是显著减少乃至消除 Operand 管理中剩余的人工干预Operator 应随负载上升自动伸缩 Operand理解应用级性能指标并判断其健康与运行状态主动修复不健康的 Operand并调优 Operand 性能例如把 Pod 调度到其他节点或修改 Operand 配置。自动伸缩Auto-scalingOperator 基于 Operand 指标在负载上升时向上扩容Operator 基于 Operand 指标在负载低于阈值时向下缩容。自动修复Auto-HealingOperator 能基于 Operand 指标/告警/日志自动修复不健康的 OperandOperator 能基于 Operand 指标阻止 Operand 进入不健康状态。自动调优Auto-tuningOperator 能针对特定工作负载模式自动调优 OperandOperator 能把工作负载动态迁移到最合适的节点。异常检测Abnormality detectionOperator 能判断偏离标准性能画像的情况。示例数据库 Operator 监控数据库查询负载自动伸缩额外的只读从副本检测到索引性能欠佳时在低负载时段自动重建索引理解数据库的正常性能画像对大量慢查询产生告警当慢查询与高磁盘延迟同时出现时自动把数据库文件迁移到更高性能等级的另一个PersistentVolume上。Level 5 自检引导问题你的 Operator 能否读取每秒请求数等相关指标并水平或垂直自动伸缩即增加 Pod 数量或 Pod 资源用量基于问题 1它能否缩减 Pod 数量或 Pod 占用的资源总量基于 Level 4 建立的深度洞察你的 Operator 能否判断 Operand 何时变得不健康并采取行动重新部署、修改配置、恢复备份等同样借助 Level 4 的深度洞察你的 Operator 能否动态学习性能基线并找到最佳配置从而调整配置以达到该状态它能否把工作负载迁移到更优的节点、存储或网络当任何东西低于已学习的性能基线且无法自动纠正时它能否检测并告警能力等级在 Operator SDK 工具链中的落地实践综合前文能力等级模型不仅是设计理念也已经渗透到 SDK 的代码生成与校验流程中建议按以下路径在项目里逐项落实声明能力等级在 CSV 基座的metadata.annotations.capabilities注解中按实际实现填写默认生成值为Basic Install见 internal/generate/clusterserviceversion/bases/clusterserviceversion.goCSV 其他字段的填写规范可参考 website/content/en/docs/olm-integration/generation.md。补齐镜像清单使用generate bundle/generate packagemanifests时SDK 通过 relatedimages.go 自动从控制器环境变量收集镜像确保 CSV 的spec.relatedImages完整对应 Level 1 自检问题 10。用 scorecard 自动校验运行operator-sdk scorecard时olm-spec-descriptors、olm-status-descriptorsinternal/scorecard/tests/olm.go等测试会检查 CSV/CRD 描述符完整性这正是 Level 4 可见性要求的自动化体现相关测试断言可参见 internal/scorecard/tests/bundle_test.go。以引导问题为验收清单将五个等级共 38 道引导问题转化为迭代验收项配合 testdata/go/v4/memcached-operator 这类示例项目其中 memcached-operator.clusterserviceversion.yaml 展示了包含capabilities注解与relatedImages的真实 CSV逐级提升。结语Operator 能力等级模型为我的 Operator 做到了什么程度提供了可沟通、可度量、可验收的统一语言Level 1 解决能不能自动装好Level 2 解决能不能平滑升级Level 3 解决数据与生命周期是否完整Level 4 解决状态是否可见可告警Level 5 则追求全自动的自我管理与自我优化。结合 Operator SDK 的 CSV 生成默认值、relatedImages 自动收集与 scorecard 描述符校验等源码级能力你可以把每一级的要求转化为具体的实现与验证动作稳步把一个基础安装型 Operator 打磨成具备完整生命周期与深度洞察的高能力 Operator。赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐CloudNativePG Operator Capability Levels 全景指南从 Basic Install 到 Auto Pilot 的五级能力体系CloudNativePG Operator Capability Levels 全景指南从 Basic Install 到 Auto Pilot 的五级能力云原生数据库高可用灾备容器编排使用 operator-sdk 构建 Go Operator 完整实战从项目初始化到部署运行 Memcached Operator使用 operator sdk 构建 Go Operator 完整实战从项目初始化到部署运行 Memcached Operator 本篇教程以 operato云原生后端开发工具微服务Operator-SDK 项目中的 Operator 作用域Scope配置从 Cluster 级到 Namespace 级的完整实战指南Operator SDK 项目中的 Operator 作用域Scope配置从 Cluster 级到 Namespace 级的完整实战指南 operator云原生后端开发工具微服务上一篇Windows风扇控制终极指南如何用FanControl实现完美散热下一篇ORB_SLAM2地图融合技术多机器人协同建图的实现思路创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考