etcd-operator 项目已经捐赠给 Cozystack，同时发布了一个从零实现的新版本，并引入新的 v1alpha2 API。对 Kubernetes 平台团队来说，这件事的重点不只是“项目换了归属”，而是 etcd 集群的声明式生命周期管理有了一个新的演进起点。
为什么这个变化值得关注
etcd 是 Kubernetes 控制面的关键依赖，也常被业务系统用作强一致元数据存储。它的部署看似只是几个 Pod，但真正麻烦的是后续运维：成员扩缩容、滚动升级、证书、备份、故障恢复、版本兼容和 quorum 保护。
Operator 的价值就在这里：把“我想要一个怎样的 etcd 集群”写成 Kubernetes 资源，然后由控制器持续对齐实际状态。etcd-operator 加入 Cozystack 后，项目有了新的治理归属；新的 v1alpha2 API 则意味着使用者需要重新审视资源定义、迁移路径和自动化脚本。
需要注意的是，摘要只说明新实现已经发布并带有 v1alpha2 API，并没有展开完整字段细节。下面的示例以常见 Operator 设计为基础，作为可以改造的实践模板；实际落地时应以当前 CRD schema 为准。
v1alpha2 API 带来的现实影响
API 版本变化通常不只是字符串变化。对平台工程来说，至少要检查三类内容：
- 资源字段是否重命名，例如副本数、镜像、存储、TLS、备份配置。
- 状态字段是否变化，例如 ready 成员数、集群健康状态、条件类型。
- 自动化工具是否依赖旧 API，例如 GitOps 模板、告警规则、准入策略和备份脚本。
如果你已经在使用旧版 etcd-operator，不建议直接把所有环境一次性切到 v1alpha2。更稳妥的方式是先在测试集群安装新 CRD，创建一套独立的 etcd 集群，验证扩缩容、滚动重启和故障恢复，再规划生产迁移。
可以这样实践：用 GitOps 管理一个 etcd 集群
下面是一个可复制改造的最小化 YAML 模板。请把 apiVersion、kind 和字段名与当前安装的 v1alpha2 CRD 对齐；如果 CRD 中字段不同，使用 kubectl explain 查询实际 schema。
apiVersion: etcd.cozystack.io/v1alpha2
kind: EtcdCluster
metadata:
name: metadata-store
namespace: platform-system
spec:
replicas: 3
version: "3.5.15"
storage:
size: 20Gi
storageClassName: fast-ssd
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2"
memory: "4Gi"
可以把它保存为 etcd-cluster.yaml，然后按下面的方式验证和应用：
kubectl create namespace platform-system
kubectl apply --server-side --dry-run=server -f etcd-cluster.yaml
kubectl apply -f etcd-cluster.yaml
kubectl get etcdcluster -n platform-system
kubectl get pods -n platform-system -l app.kubernetes.io/name=etcd
如果不确定 CRD 的字段，可以先查询：
kubectl api-resources | grep -i etcd
kubectl explain etcdcluster.spec --api-version=etcd.cozystack.io/v1alpha2
这两个命令很适合放进迁移检查清单里：前者确认资源是否已注册，后者确认 Git 仓库里的 YAML 是否还符合新 API。
运维上不要只看“能创建”
etcd 集群创建成功只是第一步。真正要验证的是异常路径：
- 删除一个 etcd Pod，观察 Operator 是否能恢复成员并保持 quorum。
- 修改镜像版本或资源配置，观察是否按预期滚动更新。
- 模拟节点不可用，确认 Pod 反亲和、PVC 绑定和调度策略不会把风险集中到一个节点。
- 检查备份和恢复流程，避免只备份 Kubernetes YAML，却没有可用的 etcd 数据快照。
可以用下面的命令做一个基础健康巡检：
kubectl get pods -n platform-system -o wide
kubectl describe etcdcluster metadata-store -n platform-system
kubectl get events -n platform-system --sort-by=.lastTimestamp | tail -n 30
如果 Operator 暴露了状态条件，建议把 Ready、Progressing、Degraded 这类条件接入告警，而不是只监控 Pod 数量。Pod 都在运行，不代表 etcd 成员都健康。
采用建议：先把边界画清楚
这次捐赠和新 API 发布给 etcd-operator 带来了新的起点，但生产采用仍要谨慎。建议按下面的顺序推进：
- 在非生产集群安装新版本 Operator 和 CRD。
- 用
kubectl explain固化v1alpha2资源模板。 - 验证创建、扩容、缩容、滚动升级、Pod 删除和节点故障场景。
- 明确备份恢复方案，不要把 Operator 当成备份系统。
- 再考虑把模板纳入 GitOps，并为 API 版本变化留出迁移窗口。
对平台团队来说，etcd-operator 加入 Cozystack 的最大意义，是让一个关键基础设施组件进入新的维护轨道。v1alpha2 API 则提醒我们：声明式运维不是“一次写完”，而是要把 API、控制器行为和故障演练一起纳入工程实践。