网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载Calico Operator 是 calico 仓库中负责管理 Calico 与 Calico Enterprise 安装全生命周期的 Kubernetes Operator它拥有operator.tigera.io这一组 CRD为每个组件渲染 Kubernetes 资源并通过 TigeraStatus API 持续上报各组件的健康状态。本文以 operator/DESIGN.md 为骨架结合仓库源码逐条拆解其架构设计与不可违背的设计不变量读者读完后将能理解该 Operator 的资源所有权模型、控制器实现范式、变体Variant扩展机制与版本发布约束并能在实际部署与排障中正确运用这些原则。架构总览Operator 拥有什么、渲染什么、报告什么Operator 的职责可以概括为三件事对应operator.tigera.io这一 API 组下的 CRD 生命周期拥有 CRDInstallation、APIServer、Compliance、Manager、Monitor、LogStorage、Whisker、Goldmane等组件 CRD 均由 Operator 定义与维护类型定义位于 operator/api/v1如installation_types.go、goldmane_types.go、whisker_types.go。渲染资源每个 CRD 对应一个控制器控制器读取当前集群状态后调用pkg/render包生成该组件所需的 Deployment、Service、RBAC、ConfigMap 等清单并应用到集群。报告状态所有控制器把组件健康度汇总到 TigeraStatus API用户通过kubectl get tigerastatus即可查看每个组件的 Available / Progressing / Degraded 状态。仓库层面的整体架构组件清单、Go module 结构参见根目录 DESIGN.mdCRD 类型的 Go/kubebuilder 编码约定单独维护在 operator/docs/api_design.md。构建、测试与调试的操作指引则见 operator/CLAUDE.md。尊重用户输入Operator 的第一原则DESIGN.md 将尊重用户输入列为横切一切的铁律共六条全部可以在源码中找到对应实现绝不覆盖用户显式设置的字段。用户在某资源上显式赋值后Operator 不得静默地用默认值或计算值替换它。这是 reconcile 循环中最基本的克制。绝不删除用户创建的资源。Secret、ConfigMap 等用户自建对象归属于用户Operator 不负责回收。对应实现可见 operator/pkg/controller/utils/component.go 中的mergeState更新时只合并 Operator 期望的标签、注解与 finalizer仅保留非tigera.io前缀的 finalizer其余外部改动一律保留。operator.tigera.io资源同样是用户输入。Operator 不得删除自己的 CR即使该 CR 是某个控制器正在协调的对象若某 CR 无法被当前安装支持例如在 Calico OSS 安装上出现 Goldmane CR应将该组件的 TigeraStatus 置为 Degraded 并在消息中指明资源名由用户自行删除。对不一致的输入报错而不是猜测。矛盾的配置应显式报错猜测意图会产生难以排查的隐性行为。CRD 层用 CELXValidation与 Enum/Minimum/Maximum 标记拦截跨资源校验则回落到pkg/common/validation与 reconcile 逻辑。跟踪共享资源上的字段归属。写入FelixConfiguration、BGPConfiguration等共享 API 时用注解记录 Operator 原始设置的字段绝不更新或删除非 Operator 写入的字段。若这些对象上的字段与operator.tigera.ioAPI 配置冲突显式报错。用户输入只复制、不改动。用户提供的自定义证书、ConfigMap、镜像拉取 Secret 等位于tigera-operator命名空间Operator 将其复制并调和到下游需要它们的命名空间但绝不编辑、更新或删除原件。一个值得注意的配套机制是unsupported.operator.tigera.io/ignore注解若用户在该注解上标注trueOperator 会跳过对该对象的更新仅通过 TigeraStatus 的 warning 通道提示该资源带有 ignore 注解Operator 不再管理它。该注解被注释明确为仅供开发与测试使用生产环境禁用见 operator/pkg/controller/utils/utils.go因为它会破坏升级流程。组件隔离默认calico-system一个 CRD 对应一个组件新组件默认放入calico-system命名空间。历史上每个组件拥有独立命名空间以便隔离 RBAC、NetworkPolicy 与资源清理但实践中这会显著增加集群资源占用。现代实践是统一放进calico-system仅当确有特殊需求如严格多租户隔离时才单独建命名空间。命名空间常量定义于 operator/pkg/common/common.goCalicoNamespace calico-systemcalico-typha、calico-node、calico-kube-controllers等核心工作负载名称也在此集中定义。一个 CRD 对应一个组件。每个组件拥有自己的 CRD、控制器与状态管理器控制器之间只通过 Kubernetes API 交互绝不互相直接调用。这保证了组件间的松耦合与独立可测试性。控制器设计Watch → Reconcile → Render → Apply → Report所有控制器遵循同一套五步模式这是新增控制器时必须复刻的模板Watch监听主 CRD 及其依赖资源如 operator/pkg/controller/apiserver/apiserver_controller.go 中通过AddTigeraStatusWatch监听 TigeraStatus 变化以触发重新协调。Read从 Kubernetes API 读取当前状态。Render调用pkg/render生成期望资源。Apply通过CreateOrUpdateOrDelete应用。Report通过 TigeraStatus API 上报状态。Apply 层的实现细节CreateOrUpdateOrDeleteCreateOrUpdateOrDelete是pkg/controller/utils包中ComponentHandler接口的核心方法见 operator/pkg/controller/utils/component.go 与 同一文件的实现其执行流程可以归纳为先应用 variant 扩展modify钩子检查组件Ready()组件级依赖检查钩子未就绪则跳过本次协调从component.Objects()拿到objsToCreate与objsToDelete两份清单对每个待创建对象调用createOrUpdateObject对象不存在则创建存在则先mergeState合并保留用户的外部标签/注解、Service 的 ClusterIP、Deployment 的副本数、ServiceAccount 的 token 与 ImagePullSecrets 等再决定更新或跳过不可原地更新的类型走删除重建路径Job镜像或注解变化、Secret类型变化、Service需要去掉 ClusterIP、RoleBinding / ClusterRoleBindingRoleRef 变化等重建前通过resetMetadataForCreate清空 resourceVersion / UID / creationTimestamp处理用户禁用策略管理policyManagementDisabled的场景不再创建 NetworkPolicy并主动删除此前已创建的冲突Conflict错误自动重试一次unsupported.operator.tigera.io/ignore注解的对象跳过并上报 warning成功后将 Deployment / DaemonSet / StatefulSet / CronJob 名单交给状态管理器监控最后调用status.ReadyToMonitor()。整个 apply 过程由一个全局去重缓存dCacheobjectCache支撑只有对象不在缓存、集群端 generation 更新、或期望状态与缓存不一致时才真正发起 Update从而把无关紧要的写操作压到最低见 component.go 的needsUpdate。createOrUpdateObject还会在应用前统一注入 Operator 级策略按installationSpec.ImagePullPolicy覆盖所有容器与 init 容器的镜像拉取策略未配置时回退到IfNotPresent见 setImagePullPolicy按installationSpec注入 TLS 环境变量TLS_CIPHER_SUITES、TLS_MIN_VERSION见 ensureTLSConfig为未显式设置的存活/就绪探针补齐超时与周期存活探针 timeout 5s / period 60s就绪探针 timeout 5s / period 30sfailureThreshold 3避免 Calico 组件因 Kubernetes 默认 1s 超时被过早重启见 setProbeTimeouts按组件的SupportedOSType()为 Pod 模板设置kubernetes.io/os节点选择器为所有对象打上标准 selector 与 Pod 标签。Render 包必须是纯函数pkg/render只负责从输入生成清单不允许发起 API 调用或产生副作用——这是控制器的职责。Component接口operator/pkg/render/component.go暴露四个方法约束了这一点ResolveImages解析镜像引用、Objects()返回待创建/待删除对象、Ready()就绪检查、SupportedOSType()声明支持的 OS供 handler 生成节点选择器。组件渲染实现集中于 operator/pkg/rendernode.go、typha.go、apiserver.go、kubecontrollers/、gatewayapi/、goldmane/、whisker/等纯函数性质使每个渲染器都能被独立单元测试如node_test.go、typha_test.go。状态消息是给用户看的不是给开发者看的TigeraStatus 的 condition 消息必须面向用户、可操作禁止透出内部错误字符串或堆栈。状态管理器实现在 operator/pkg/controller/status/status.goSetDegraded(reason, msg, err, log)记录用户可读的原因与消息status.go#L533-L548SetWarning/ClearWarning维护附加到 Available condition 上的警告列表。状态类型定义在 operator/api/v1/tigerastatus_types.goAvailable组件健康、Progressing正在安装/升级、Degraded未按预期运行且需要用户介入每个 condition 携带LastTransitionTime、Reason、Message与ObservedGenerationkubectl get tigerastatus通过 printcolumn 直接展示 Progressing / Degraded / Error 列。变体Variants核心代码对变体失明Operator 需要同时服务 Calico 与 Calico Enterprise 两个产品变体设计约束是核心代码不感知变体。pkg/enterprise之外的控制器与 render 包无论在代码还是注释中都不得提及任何变体名称单个变体所需的行为通过pkg/extensions注册进来。仅单个变体运行的控制器放在pkg/enterprise/controller其 render 代码放在pkg/enterprise/render并镜像它们来源的核心树结构。变体控制器通过ControllerOptions上的控制器列表贡献出来见 operator/pkg/extensions/options.go 的Controller结构而不是在AddToManager中具名注册因此无需自带变体检查。pkg/extensions是这个接缝的具体实现Extensions结构体为每个被扩展的控制器持有一个扩展接口InstallationExtension、WindowsExtension、APIServerExtension、ClusterConnectionExtension、TiersExtension、CSRExtension、IstioExtension、GoldmaneExtension、WhiskerExtension、GatewayAPIExtension、UIGatewayExtension外加启动钩子StartupExtension未设置项回落到 noop 实现保证访问器永不返回 nil见 operator/pkg/extensions/extensions.go。每个扩展接口覆盖两个阶段见 operator/pkg/extensions/doc.goExtendInputs控制器阶段拥有集群访问权限做 render 钩子无法做的带副作用工作——拒绝不支持的配置、创建证书、扩展信任 bundleModifyrender 阶段纯钩子接收组件与核心渲染器使用的同一份类型化配置返回变体调整后的组件由Decorate完成包装。ControllerOptionsoptions.go#L33-L59携带启动时检测到的选项DetectedProvider、解析后的Variant进程以其运行终身变更会导致重启、ClusterDomain、ManageCRDs、K8sClientset、UseV3CRDs使用crd.projectcalico.org/v1还是projectcalico.org/v3、APIDiscovery快照以及Extensions本体。组件版本与发布版本是构建输入不是源码这一节定义了 Operator 与它所部署组件版本之间的关键约束也是发布工程最容易踩坑的地方Operator 部署的组件版本是构建时 ldflags 注入的不是源码常量。CALICO_VERSION、CALICO_REGISTRY、CALICO_IMAGE_PATH以及 Operator 自身镜像的OPERATOR_IMAGE_REGISTRY、OPERATOR_IMAGE_PATH在链接期写入pkg/components。源码树中没有任何地方记录某次构建解析到的 tag因此组件列表永远不允许在镜像名旁边硬编码版本字面量。实现可见 operator/pkg/components/calico.goCalicoRelease等变量由 ldflags 填充与 operator/Makefile 的CALICO_LDFLAGS。Operator 作为 Calico 组件镜像发布以calico/operator名称随其他组件发布到同一批 registry、同一 Calico 版本流Calico 正式发布会直接构建它而不是把为另一组组件版本构建的镜像重打 tag。发布必须指明其部署的版本Operator 自身 tag 与它解析到的组件版本是两个独立输入。仅 Operator 的发布自带自己的 tag同时部署其所补丁patch发布对应的组件版本因此未设置CALICO_VERSION的发布会被拒绝而不是默认取值。Makefile 中对应检查可见 operator/Makefile#L337-L345发布必须设置CALICO_VERSION且不得等于分支镜像 tag除非显式传入ALLOW_BRANCH_IMAGE_TAGStrue。未指明版本的构建解析分支 tag开发构建与发布分支构建回退到 CI 为该分支发布的 tagBRANCH_IMAGE_TAG见 operator/Makefile#L70-L76保证从 checkout 构建的 Operator 所部署的镜像真实存在。安全组件间通信必须认证与加密Operator 管理的各组件之间的所有内部通信必须使用 mTLS 或 TLS token 认证。这一原则在实际代码中体现为createOrUpdateObject统一向 Deployment / DaemonSet 注入 TLS 环境变量TLS_CIPHER_SUITES、TLS_MIN_VERSION见 ensureTLSConfigpkg/tls提供证书管理工具Operator 还会统一为组件签发 Tigera CA 与 TLS 密钥对见 apiserver_controller.go 的证书创建路径确保每个组件的证书生命周期由 Operator 统一托管。资源所有权OwnerReferences 是判定依据资源归属是 Operator 区分自己管理的资源与用户提供的资源的根本手段Operator 创建的资源必须带 OwnerReferences这样删除父 CR 时级联清理会自动发生例外只有级联删除会造成灾难性后果的资源典型如 CRD。用户提供的资源绝不能带 OwnerReferences。它们可以被复制到其他命名空间副本上可以带 OwnerReferences但原件绝不能被认领。实现上createOrUpdateObject会先判断对象是否带operator.tigera.io/multipleOwners标签若带则调用SetOwnerReference多所有者场景合并而非覆盖否则调用SetControllerReference当属主是命名空间级资源而受控对象是集群级资源时跳过 owner 添加见 component.go#L241-L261 与 skipAddingOwnerReference。多所有者标签常量定义于 operator/pkg/common/common.go该机制使多个 CR 可以安全地共享同一底层对象例如网关 API 控制器合并 RBAC 属主见 gatewayapi_controller.go。扩展阅读API 变更与日常操作API/CRD 变更流程新增或修改api/v1下的 CRD 字段后必须先跑make gen-files重新生成 CRD 清单与zz_generated.deepcopy.go绝不手改生成文件随后运行make dirty-check确认生成产物已提交若新配置在manifest 版 Calico OSS → Operator迁移期间可设置还需同步更新pkg/controller/migration/convert。完整清单见 operator/docs/api_design.md。本地开发make kind-cluster-create创建 kind 双栈集群make create-tigera-operator-namespace建命名空间随后go run ./cmd/main.go --enable-leader-electionfalse前台运行 Operator构建与测试命令make build、make ut、make image见 operator/CLAUDE.md。小结Calico Operator 架构的精髓不在于某个具体的渲染逻辑而在于一组贯穿始终的设计不变量尊重用户输入不覆盖、不删除、不猜测、跟踪字段归属、组件隔离calico-system统一承载、一 CRD 一控制器、控制器范式Watch→Reconcile→Render→Apply→Reportrender 保持纯函数、状态消息面向用户、变体失明核心代码通过pkg/extensions接缝获得变体行为、版本即构建输入发布必须显式命名所部署版本与资源所有权OwnerReferences 区分归属。理解这六条不变量无论是部署排障、扩展新组件还是参与 Operator 开发都能做到有据可依。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐Calico Operator 深度指南基于 operator-sdk 管理 Calico/Calico Enterprise 全生命周期Calico Operator 深度指南基于 operator sdk 管理 Calico/Calico Enterprise 全生命周期 本指南以 oper网络云原生网络安全GreptimeDB 表引擎重构 RFC 解读从 TableEngine 到 RegionEngine 的架构演进GreptimeDB 表引擎重构 RFC 解读从 TableEngine 到 RegionEngine 的架构演进 导读 本文基于 GreptimeDB 官方网络云原生网络安全AMD ROCm快速上手指南解决您GPU计算的实际问题AMD ROCm快速上手指南解决您GPU计算的实际问题 您是否曾经为在Linux系统中配置AMD GPU计算环境而烦恼是否因为复杂的安装步骤和性能调优问题而开发工具高性能计算文档上一篇使用 figure 与 figcaption 构建图片与图注的语义关联——Front-End-Checklist 无障碍图片规则实战指南下一篇jedi-vim性能优化让你的代码补全飞起来的7个技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Calico Operator 架构深度解析：CRD 生命周期管理、用户输入保护与变体扩展设计
网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载Calico Operator 是 calico 仓库中负责管理 Calico 与 Calico Enterprise 安装全生命周期的 Kubernetes Operator它拥有operator.tigera.io这一组 CRD为每个组件渲染 Kubernetes 资源并通过 TigeraStatus API 持续上报各组件的健康状态。本文以 operator/DESIGN.md 为骨架结合仓库源码逐条拆解其架构设计与不可违背的设计不变量读者读完后将能理解该 Operator 的资源所有权模型、控制器实现范式、变体Variant扩展机制与版本发布约束并能在实际部署与排障中正确运用这些原则。架构总览Operator 拥有什么、渲染什么、报告什么Operator 的职责可以概括为三件事对应operator.tigera.io这一 API 组下的 CRD 生命周期拥有 CRDInstallation、APIServer、Compliance、Manager、Monitor、LogStorage、Whisker、Goldmane等组件 CRD 均由 Operator 定义与维护类型定义位于 operator/api/v1如installation_types.go、goldmane_types.go、whisker_types.go。渲染资源每个 CRD 对应一个控制器控制器读取当前集群状态后调用pkg/render包生成该组件所需的 Deployment、Service、RBAC、ConfigMap 等清单并应用到集群。报告状态所有控制器把组件健康度汇总到 TigeraStatus API用户通过kubectl get tigerastatus即可查看每个组件的 Available / Progressing / Degraded 状态。仓库层面的整体架构组件清单、Go module 结构参见根目录 DESIGN.mdCRD 类型的 Go/kubebuilder 编码约定单独维护在 operator/docs/api_design.md。构建、测试与调试的操作指引则见 operator/CLAUDE.md。尊重用户输入Operator 的第一原则DESIGN.md 将尊重用户输入列为横切一切的铁律共六条全部可以在源码中找到对应实现绝不覆盖用户显式设置的字段。用户在某资源上显式赋值后Operator 不得静默地用默认值或计算值替换它。这是 reconcile 循环中最基本的克制。绝不删除用户创建的资源。Secret、ConfigMap 等用户自建对象归属于用户Operator 不负责回收。对应实现可见 operator/pkg/controller/utils/component.go 中的mergeState更新时只合并 Operator 期望的标签、注解与 finalizer仅保留非tigera.io前缀的 finalizer其余外部改动一律保留。operator.tigera.io资源同样是用户输入。Operator 不得删除自己的 CR即使该 CR 是某个控制器正在协调的对象若某 CR 无法被当前安装支持例如在 Calico OSS 安装上出现 Goldmane CR应将该组件的 TigeraStatus 置为 Degraded 并在消息中指明资源名由用户自行删除。对不一致的输入报错而不是猜测。矛盾的配置应显式报错猜测意图会产生难以排查的隐性行为。CRD 层用 CELXValidation与 Enum/Minimum/Maximum 标记拦截跨资源校验则回落到pkg/common/validation与 reconcile 逻辑。跟踪共享资源上的字段归属。写入FelixConfiguration、BGPConfiguration等共享 API 时用注解记录 Operator 原始设置的字段绝不更新或删除非 Operator 写入的字段。若这些对象上的字段与operator.tigera.ioAPI 配置冲突显式报错。用户输入只复制、不改动。用户提供的自定义证书、ConfigMap、镜像拉取 Secret 等位于tigera-operator命名空间Operator 将其复制并调和到下游需要它们的命名空间但绝不编辑、更新或删除原件。一个值得注意的配套机制是unsupported.operator.tigera.io/ignore注解若用户在该注解上标注trueOperator 会跳过对该对象的更新仅通过 TigeraStatus 的 warning 通道提示该资源带有 ignore 注解Operator 不再管理它。该注解被注释明确为仅供开发与测试使用生产环境禁用见 operator/pkg/controller/utils/utils.go因为它会破坏升级流程。组件隔离默认calico-system一个 CRD 对应一个组件新组件默认放入calico-system命名空间。历史上每个组件拥有独立命名空间以便隔离 RBAC、NetworkPolicy 与资源清理但实践中这会显著增加集群资源占用。现代实践是统一放进calico-system仅当确有特殊需求如严格多租户隔离时才单独建命名空间。命名空间常量定义于 operator/pkg/common/common.goCalicoNamespace calico-systemcalico-typha、calico-node、calico-kube-controllers等核心工作负载名称也在此集中定义。一个 CRD 对应一个组件。每个组件拥有自己的 CRD、控制器与状态管理器控制器之间只通过 Kubernetes API 交互绝不互相直接调用。这保证了组件间的松耦合与独立可测试性。控制器设计Watch → Reconcile → Render → Apply → Report所有控制器遵循同一套五步模式这是新增控制器时必须复刻的模板Watch监听主 CRD 及其依赖资源如 operator/pkg/controller/apiserver/apiserver_controller.go 中通过AddTigeraStatusWatch监听 TigeraStatus 变化以触发重新协调。Read从 Kubernetes API 读取当前状态。Render调用pkg/render生成期望资源。Apply通过CreateOrUpdateOrDelete应用。Report通过 TigeraStatus API 上报状态。Apply 层的实现细节CreateOrUpdateOrDeleteCreateOrUpdateOrDelete是pkg/controller/utils包中ComponentHandler接口的核心方法见 operator/pkg/controller/utils/component.go 与 同一文件的实现其执行流程可以归纳为先应用 variant 扩展modify钩子检查组件Ready()组件级依赖检查钩子未就绪则跳过本次协调从component.Objects()拿到objsToCreate与objsToDelete两份清单对每个待创建对象调用createOrUpdateObject对象不存在则创建存在则先mergeState合并保留用户的外部标签/注解、Service 的 ClusterIP、Deployment 的副本数、ServiceAccount 的 token 与 ImagePullSecrets 等再决定更新或跳过不可原地更新的类型走删除重建路径Job镜像或注解变化、Secret类型变化、Service需要去掉 ClusterIP、RoleBinding / ClusterRoleBindingRoleRef 变化等重建前通过resetMetadataForCreate清空 resourceVersion / UID / creationTimestamp处理用户禁用策略管理policyManagementDisabled的场景不再创建 NetworkPolicy并主动删除此前已创建的冲突Conflict错误自动重试一次unsupported.operator.tigera.io/ignore注解的对象跳过并上报 warning成功后将 Deployment / DaemonSet / StatefulSet / CronJob 名单交给状态管理器监控最后调用status.ReadyToMonitor()。整个 apply 过程由一个全局去重缓存dCacheobjectCache支撑只有对象不在缓存、集群端 generation 更新、或期望状态与缓存不一致时才真正发起 Update从而把无关紧要的写操作压到最低见 component.go 的needsUpdate。createOrUpdateObject还会在应用前统一注入 Operator 级策略按installationSpec.ImagePullPolicy覆盖所有容器与 init 容器的镜像拉取策略未配置时回退到IfNotPresent见 setImagePullPolicy按installationSpec注入 TLS 环境变量TLS_CIPHER_SUITES、TLS_MIN_VERSION见 ensureTLSConfig为未显式设置的存活/就绪探针补齐超时与周期存活探针 timeout 5s / period 60s就绪探针 timeout 5s / period 30sfailureThreshold 3避免 Calico 组件因 Kubernetes 默认 1s 超时被过早重启见 setProbeTimeouts按组件的SupportedOSType()为 Pod 模板设置kubernetes.io/os节点选择器为所有对象打上标准 selector 与 Pod 标签。Render 包必须是纯函数pkg/render只负责从输入生成清单不允许发起 API 调用或产生副作用——这是控制器的职责。Component接口operator/pkg/render/component.go暴露四个方法约束了这一点ResolveImages解析镜像引用、Objects()返回待创建/待删除对象、Ready()就绪检查、SupportedOSType()声明支持的 OS供 handler 生成节点选择器。组件渲染实现集中于 operator/pkg/rendernode.go、typha.go、apiserver.go、kubecontrollers/、gatewayapi/、goldmane/、whisker/等纯函数性质使每个渲染器都能被独立单元测试如node_test.go、typha_test.go。状态消息是给用户看的不是给开发者看的TigeraStatus 的 condition 消息必须面向用户、可操作禁止透出内部错误字符串或堆栈。状态管理器实现在 operator/pkg/controller/status/status.goSetDegraded(reason, msg, err, log)记录用户可读的原因与消息status.go#L533-L548SetWarning/ClearWarning维护附加到 Available condition 上的警告列表。状态类型定义在 operator/api/v1/tigerastatus_types.goAvailable组件健康、Progressing正在安装/升级、Degraded未按预期运行且需要用户介入每个 condition 携带LastTransitionTime、Reason、Message与ObservedGenerationkubectl get tigerastatus通过 printcolumn 直接展示 Progressing / Degraded / Error 列。变体Variants核心代码对变体失明Operator 需要同时服务 Calico 与 Calico Enterprise 两个产品变体设计约束是核心代码不感知变体。pkg/enterprise之外的控制器与 render 包无论在代码还是注释中都不得提及任何变体名称单个变体所需的行为通过pkg/extensions注册进来。仅单个变体运行的控制器放在pkg/enterprise/controller其 render 代码放在pkg/enterprise/render并镜像它们来源的核心树结构。变体控制器通过ControllerOptions上的控制器列表贡献出来见 operator/pkg/extensions/options.go 的Controller结构而不是在AddToManager中具名注册因此无需自带变体检查。pkg/extensions是这个接缝的具体实现Extensions结构体为每个被扩展的控制器持有一个扩展接口InstallationExtension、WindowsExtension、APIServerExtension、ClusterConnectionExtension、TiersExtension、CSRExtension、IstioExtension、GoldmaneExtension、WhiskerExtension、GatewayAPIExtension、UIGatewayExtension外加启动钩子StartupExtension未设置项回落到 noop 实现保证访问器永不返回 nil见 operator/pkg/extensions/extensions.go。每个扩展接口覆盖两个阶段见 operator/pkg/extensions/doc.goExtendInputs控制器阶段拥有集群访问权限做 render 钩子无法做的带副作用工作——拒绝不支持的配置、创建证书、扩展信任 bundleModifyrender 阶段纯钩子接收组件与核心渲染器使用的同一份类型化配置返回变体调整后的组件由Decorate完成包装。ControllerOptionsoptions.go#L33-L59携带启动时检测到的选项DetectedProvider、解析后的Variant进程以其运行终身变更会导致重启、ClusterDomain、ManageCRDs、K8sClientset、UseV3CRDs使用crd.projectcalico.org/v1还是projectcalico.org/v3、APIDiscovery快照以及Extensions本体。组件版本与发布版本是构建输入不是源码这一节定义了 Operator 与它所部署组件版本之间的关键约束也是发布工程最容易踩坑的地方Operator 部署的组件版本是构建时 ldflags 注入的不是源码常量。CALICO_VERSION、CALICO_REGISTRY、CALICO_IMAGE_PATH以及 Operator 自身镜像的OPERATOR_IMAGE_REGISTRY、OPERATOR_IMAGE_PATH在链接期写入pkg/components。源码树中没有任何地方记录某次构建解析到的 tag因此组件列表永远不允许在镜像名旁边硬编码版本字面量。实现可见 operator/pkg/components/calico.goCalicoRelease等变量由 ldflags 填充与 operator/Makefile 的CALICO_LDFLAGS。Operator 作为 Calico 组件镜像发布以calico/operator名称随其他组件发布到同一批 registry、同一 Calico 版本流Calico 正式发布会直接构建它而不是把为另一组组件版本构建的镜像重打 tag。发布必须指明其部署的版本Operator 自身 tag 与它解析到的组件版本是两个独立输入。仅 Operator 的发布自带自己的 tag同时部署其所补丁patch发布对应的组件版本因此未设置CALICO_VERSION的发布会被拒绝而不是默认取值。Makefile 中对应检查可见 operator/Makefile#L337-L345发布必须设置CALICO_VERSION且不得等于分支镜像 tag除非显式传入ALLOW_BRANCH_IMAGE_TAGStrue。未指明版本的构建解析分支 tag开发构建与发布分支构建回退到 CI 为该分支发布的 tagBRANCH_IMAGE_TAG见 operator/Makefile#L70-L76保证从 checkout 构建的 Operator 所部署的镜像真实存在。安全组件间通信必须认证与加密Operator 管理的各组件之间的所有内部通信必须使用 mTLS 或 TLS token 认证。这一原则在实际代码中体现为createOrUpdateObject统一向 Deployment / DaemonSet 注入 TLS 环境变量TLS_CIPHER_SUITES、TLS_MIN_VERSION见 ensureTLSConfigpkg/tls提供证书管理工具Operator 还会统一为组件签发 Tigera CA 与 TLS 密钥对见 apiserver_controller.go 的证书创建路径确保每个组件的证书生命周期由 Operator 统一托管。资源所有权OwnerReferences 是判定依据资源归属是 Operator 区分自己管理的资源与用户提供的资源的根本手段Operator 创建的资源必须带 OwnerReferences这样删除父 CR 时级联清理会自动发生例外只有级联删除会造成灾难性后果的资源典型如 CRD。用户提供的资源绝不能带 OwnerReferences。它们可以被复制到其他命名空间副本上可以带 OwnerReferences但原件绝不能被认领。实现上createOrUpdateObject会先判断对象是否带operator.tigera.io/multipleOwners标签若带则调用SetOwnerReference多所有者场景合并而非覆盖否则调用SetControllerReference当属主是命名空间级资源而受控对象是集群级资源时跳过 owner 添加见 component.go#L241-L261 与 skipAddingOwnerReference。多所有者标签常量定义于 operator/pkg/common/common.go该机制使多个 CR 可以安全地共享同一底层对象例如网关 API 控制器合并 RBAC 属主见 gatewayapi_controller.go。扩展阅读API 变更与日常操作API/CRD 变更流程新增或修改api/v1下的 CRD 字段后必须先跑make gen-files重新生成 CRD 清单与zz_generated.deepcopy.go绝不手改生成文件随后运行make dirty-check确认生成产物已提交若新配置在manifest 版 Calico OSS → Operator迁移期间可设置还需同步更新pkg/controller/migration/convert。完整清单见 operator/docs/api_design.md。本地开发make kind-cluster-create创建 kind 双栈集群make create-tigera-operator-namespace建命名空间随后go run ./cmd/main.go --enable-leader-electionfalse前台运行 Operator构建与测试命令make build、make ut、make image见 operator/CLAUDE.md。小结Calico Operator 架构的精髓不在于某个具体的渲染逻辑而在于一组贯穿始终的设计不变量尊重用户输入不覆盖、不删除、不猜测、跟踪字段归属、组件隔离calico-system统一承载、一 CRD 一控制器、控制器范式Watch→Reconcile→Render→Apply→Reportrender 保持纯函数、状态消息面向用户、变体失明核心代码通过pkg/extensions接缝获得变体行为、版本即构建输入发布必须显式命名所部署版本与资源所有权OwnerReferences 区分归属。理解这六条不变量无论是部署排障、扩展新组件还是参与 Operator 开发都能做到有据可依。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐Calico Operator 深度指南基于 operator-sdk 管理 Calico/Calico Enterprise 全生命周期Calico Operator 深度指南基于 operator sdk 管理 Calico/Calico Enterprise 全生命周期 本指南以 oper网络云原生网络安全GreptimeDB 表引擎重构 RFC 解读从 TableEngine 到 RegionEngine 的架构演进GreptimeDB 表引擎重构 RFC 解读从 TableEngine 到 RegionEngine 的架构演进 导读 本文基于 GreptimeDB 官方网络云原生网络安全AMD ROCm快速上手指南解决您GPU计算的实际问题AMD ROCm快速上手指南解决您GPU计算的实际问题 您是否曾经为在Linux系统中配置AMD GPU计算环境而烦恼是否因为复杂的安装步骤和性能调优问题而开发工具高性能计算文档上一篇使用 figure 与 figcaption 构建图片与图注的语义关联——Front-End-Checklist 无障碍图片规则实战指南下一篇jedi-vim性能优化让你的代码补全飞起来的7个技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
