使用Operator更新K8S自定义资源(CR)的最优方案

场景背景 #

我开发了一个Operator监控自研自定义资源MyCustomResource1，其spec包含以下配置字段：

elastic_configuration:
    cpu: 2
    memory: 4Gi

调和循环中，该Operator会通过ECK Operator创建Elasticsearch集群，集群Pod的CPU、内存配置由上述字段决定。需求是：当用户修改MyCustomResource1的配置后，我的Operator能自动识别变更并更新ECK对应的Elasticsearch CR字段。

可选方案分析 #

方案1：使用Unstructured对象 #

• 适用场景：不想依赖ECK的具体版本，或者需要适配多种CRD版本
• 弊端：必须手动处理嵌套的map[string]interface{}结构，比如要定位到spec.nodeSets[*].podTemplate.spec.containers[0].resources这类层级路径，需要大量类型断言和遍历代码，繁琐且容易出错，维护成本高。

方案2：复用ECK官方结构体（推荐最优方案） #

该方案完全可行，是更高效、易维护的选择，具体实现步骤如下：

1. 引入ECK依赖
   在Go项目的go.mod中添加ECK 2.13.0版本的依赖：

require github.com/elastic/cloud-on-k8s/v2 v2.13.0

2. 整合K8s客户端
   借助controller-runtime的client或者client-go，结合ECK定义的Elasticsearch结构体，可以直接对Elasticsearch CR进行序列化/反序列化操作，无需手动处理非结构化数据。

3. 调和循环中的更新逻辑
   核心流程是：获取现有Elasticsearch CR → 基于MyCustomResource1的配置更新结构体字段 → 提交更新到集群。推荐使用Server-Side Apply方式提交，避免更新冲突。

代码示例片段

import (
    "context"
    elasticv1 "github.com/elastic/cloud-on-k8s/v2/pkg/apis/elasticsearch/v1"
    "k8s.io/apimachinery/pkg/api/resource"
    "sigs.k8s.io/controller-runtime/pkg/client"
)

// ElasticConfiguration 对应MyCustomResource1中的elastic_configuration字段结构体
type ElasticConfiguration struct {
    CPU    string `json:"cpu"`
    Memory string `json:"memory"`
}

func syncElasticsearchResources(ctx context.Context, k8sClient client.Client, elasticCfg ElasticConfiguration, esCRName, namespace string) error {
    // 获取集群中当前的Elasticsearch CR实例
    esCR := &elasticv1.Elasticsearch{}
    if err := k8sClient.Get(ctx, client.ObjectKey{Name: esCRName, Namespace: namespace}, esCR); err != nil {
        return err
    }

    // 将配置字符串解析为K8s资源Quantity对象
    cpuQty, err := resource.ParseQuantity(elasticCfg.CPU)
    if err != nil {
        return err
    }
    memoryQty, err := resource.ParseQuantity(elasticCfg.Memory)
    if err != nil {
        return err
    }

    // 更新所有节点组的资源请求和限制（可根据需求指定特定节点组）
    for idx := range esCR.Spec.NodeSets {
        // 假设第一个容器为Elasticsearch主容器
        container := &esCR.Spec.NodeSets[idx].PodTemplate.Spec.Containers[0]
        container.Resources.Requests = map[resource.ResourceName]resource.Quantity{
            "cpu":    cpuQty,
            "memory": memoryQty,
        }
        container.Resources.Limits = map[resource.ResourceName]resource.Quantity{
            "cpu":    cpuQty,
            "memory": memoryQty,
        }
    }

    // 使用Server-Side Apply提交更新，指定当前Operator为字段所有者
    applyOpts := []client.PatchOption{client.ForceOwnership, client.FieldOwner("my-custom-resource-operator")}
    return k8sClient.Patch(ctx, esCR, client.Apply, applyOpts...)
}

关键注意事项

• 确保项目依赖的ECK版本与集群中部署的ECK Operator版本完全一致（2.13.0），避免结构体字段不匹配导致的序列化失败
• 使用FieldOwner标识更新来源，防止其他控制器覆盖你的配置变更
• 优先选择Apply而非Update：Update会替换整个CR对象，容易引发并发更新冲突；Apply仅更新你修改的字段，更安全可靠。

内容的提问来源于stack exchange，提问作者Dhiwakar Ravikumar