#安装

使用为你的 Alauda Container Platform 环境提供的基于 CLI 的安装工作流，安装 Alauda Cache Service E2 version 2.0.0 产品包。确切的 registry、namespace 和 package 命令取决于发行版，并未由 Valkey Operator repository 定义。

#前提条件

• 受支持的 Kubernetes 集群，以及允许安装 chart 的集群范围自定义资源定义（CRDs）、admission webhooks 和基于角色的访问控制资源的 kubectl context；
• 可访问 Alauda Cache Service E2 version 2.0.0 images；
• 默认 StorageClass，或用于持久化实例的显式 class；
• 用于默认 webhook-certificate 安装路径的 cert-manager；当启用实例 TLS 时，还需要 Issuer 或 ClusterIssuer；
• 如果要收集 exporter-sidecar metrics，则需要一个兼容 Prometheus 的 scraper。

在生产环境安装之前，请先获取与该 release 相关的平台兼容性矩阵。本文档基线未定义受支持的 Alauda Container Platform 版本、registry 地址、package namespace、channel 或升级审批策略。

#预检查

在运行提供的 package 命令之前，确认连通性、权限、存储以及可选依赖项：

kubectl version
kubectl auth can-i create customresourcedefinitions.apiextensions.k8s.io
kubectl auth can-i create validatingwebhookconfigurations.admissionregistration.k8s.io
kubectl get nodes -o wide
kubectl get storageclass
kubectl get crd certificates.cert-manager.io

默认 Operator chart 会启用 admission webhooks 和 cert-manager 集成。某些 release 也可能提供由外部管理的 webhook 证书和证书颁发机构（CA）bundle，但这必须作为显式的 package 配置；不要在没有替代方案的情况下禁用证书集成。实例 TLS 仍然使用 cert-manager。只有在每个持久化实例都指定了有效 class 时，缺少默认 StorageClass 才是可接受的。

#安装产品

使用 Alauda Cache Service E2 version 2.0.0 release 提供的 CLI package 安装工作流。记录所选的 package version、image registry、目标 namespace、scope 和审批策略。不要复制 Redis 产品中的命令、channel 或组件名称并直接替换使用；这两个产品具有不同的 API 和能力集。

#验证安装

确认 API resources 已注册：

kubectl api-resources --api-group=rds.valkey.buf.red
kubectl api-resources --api-group=valkey.buf.red

预期的 resources 包括 valkeys、clusters、failovers、sentinels 和 users。确认所有 CRDs 都已建立：

kubectl get crd \
  valkeys.rds.valkey.buf.red \
  clusters.valkey.buf.red \
  failovers.valkey.buf.red \
  sentinels.valkey.buf.red \
  users.valkey.buf.red

检查的 2.0.0 source 包含两个生成的 CRD 副本，它们在 version enum 上不一致：API source 和 config/crd/bases 包含 9.1，而 Helm Chart CRD 副本已过时。支持 9.1 的 release package 必须安装一个其 enum 包含 7.2、8.1 和 9.1 的 CRD。在创建实例之前，请验证已安装的 schema：

kubectl explain valkey.spec.version
kubectl get crd valkeys.rds.valkey.buf.red \
  -o jsonpath='{range .spec.versions[?(@.name=="v1alpha1")].schema.openAPIV3Schema.properties.spec.properties.version.enum[*]}{.}{"\n"}{end}'

将缺少 9.1 enum 视为打包缺陷；不要绕过 admission，也不要临时编辑 CRD。

定位 Operator Deployment 并验证其可用性：

kubectl get deployment -A -l app.kubernetes.io/name=valkey-operator
kubectl get pods -A -l app.kubernetes.io/name=valkey-operator

确认该 Deployment 报告其期望副本均可用，并记录已安装的 image：

kubectl get deployment -A -l app.kubernetes.io/name=valkey-operator \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,DESIRED:.spec.replicas,AVAILABLE:.status.availableReplicas,IMAGE:.spec.template.spec.containers[*].image'

如果启用了 validating 或 mutating webhooks，请验证其配置以及 webhook 使用的 cert-manager 证书：

kubectl get validatingwebhookconfiguration,mutatingwebhookconfiguration \
  | grep valkey
kubectl get certificate -A | grep valkey

确认 API server 可以在不进行实时 mutation 的情况下执行 admission：

kubectl apply --dry-run=server -f valkey-smoke-test.yaml

使用 创建实例 中的 manifest，并保持名称唯一。server-side dry-run 可验证 API discovery 和 admission；它不能证明 images、storage、scheduling、Services、certificates 或 Valkey topology 能够成功 reconcile。

在这些检查全部通过后，按照 创建实例 指南创建一个测试实例。