访问方式与 TLS

在高层 Valkey 资源上的 spec.access 下配置访问方式。

Service 类型

`serviceType`	用途
`ClusterIP`	运行在 Kubernetes 集群内的客户端。这是默认值。
`NodePort`	能够访问 Kubernetes 节点地址的外部客户端。Operator 会创建每个 Pod 所需的 Service，用于拓扑通告。
`LoadBalancer`	通过负载均衡器实现访问的外部客户端。Operator 会在需要直接拓扑地址的场景下为每个 Pod 创建 Service。

对于 Cluster 架构，同名的 bootstrap Service 仍然是 ClusterIP；请求的外部类型会用于生成的每个 Pod 的 Service。对于 Failover 和 Replica，读写和只读角色 Service 使用请求的类型，外部访问也可以创建每个 Pod 的 Service。请始终检查生成的 Service，而不要假设它们都具有统一的 Service 形态。

对于 2.0.0 中的 NodePort，除非交付版本文档说明了已验证的格式，否则请不要设置 spec.access.ports。此时 Kubernetes 会分配端口。源码基线中固定分配的 schema 和运行时格式存在冲突。

使用 merge patch 切换访问类型：

kubectl -n default patch valkey valkey-cluster --type=merge \
  -p '{"spec":{"access":{"serviceType":"LoadBalancer"}}}'
kubectl -n default get service -l buf.red/name=valkey-cluster -w

在更新客户端之前，请等待所有外部地址以及 Valkey phase 就绪。

集群内 Service 名称

对于 Cluster 架构，请使用与 Valkey 资源同名的 Service，并配合支持 Cluster 的客户端：

valkey-cli -c -h valkey-cluster.default.svc -p 6379 PING

对于 Failover 和 Replica 架构，请使用读写或只读 Service：

valkey-cli -h rfr-valkey-failover-readwrite.default.svc -p 6379 PING
valkey-cli -h rfr-valkey-failover-readonly.default.svc -p 6379 GET app:key

读写 Service 会选择当前 primary。发生 failover 后，应用必须重新连接。只读 Service 会选择 Replica，并且可能返回过期数据。

请不要在自动化中通过拼接名称来推断，而要发现实际的 Service：

kubectl -n default get service -l buf.red/name=valkey-failover -o wide

IP 协议族

将 spec.access.ipFamilyPrefer 设置为 Internet Protocol（IP）版本 4（IPv4）或版本 6（IPv6）。生成的 Service 使用单栈 IP family policy。在更改现有实例之前，请确保集群、节点、负载均衡器、DNS 和客户端都支持所选的 family。

启用 TLS

TLS 需要 cert-manager 以及现有的 Issuer 或 ClusterIssuer。Operator 会创建一个 cert-manager Certificate，并将签发后的材料存储在 <instance-name>-tls 中。

kubectl -n default patch valkey valkey-cluster --type=merge -p '
{
  "spec": {
    "access": {
      "enableTLS": true,
      "certIssuer": "valkey-ca",
      "certIssuerType": "ClusterIssuer"
    }
  }
}'

验证证书签发和滚动更新：

kubectl -n default get certificate valkey-cluster-cert
kubectl -n default describe certificate valkey-cluster-cert
kubectl -n default get secret valkey-cluster-tls
kubectl -n default get valkey valkey-cluster -w

生成的 Valkey 参数保留了上游的客户端证书认证。因此，TLS 客户端需要受信任的证书颁发机构（CA）、受信任的客户端证书以及其私钥。实例 Secret 必须包含 ca.crt、tls.crt 和 tls.key；请确认所选的 cert-manager issuer 会填充这三个键。

请使用由同一受信任 CA 签发的客户端身份。以下形式避免了在命令行中放置访问控制列表（ACL）密码，但它只会检查 Cluster bootstrap 连接：

valkey-cli -c --tls \
  --cacert <ca-file> --cert <client-certificate-file> --key <client-key-file> \
  -h valkey-cluster.default -p 6379 --user <username> --askpass PING

在此示例中，valkey-cluster.default 存在于 Operator 生成的 Cluster 证书中；valkey-cluster.default.svc 不存在。请检查 Certificate.spec.dnsNames 并使用列表中精确的名称。生成的 Secret 包含 Operator 内部使用的服务器身份；不要将其私钥作为通用客户端凭证分发给应用。请通过经过批准的证书流程签发并分发专用客户端证书。

生成的证书不包含任意的 NodePort 或 LoadBalancer 地址。对于 Cluster，它还会省略为重定向通告的每个 Pod 的 Service 名称或地址。因此，成功的 bootstrap PING 并不能证明支持 Cluster 的客户端能够验证重定向连接。在生产环境中使用 Cluster TLS 之前，请求交付版本确保每个通告的 endpoint 都与证书的 subject alternative name 对齐。不要使用 --insecure 作为变通方法。

关于端到端的 endpoint 发现、认证、TLS 和客户端行为，请参见：

有关服务端和客户端证书行为，请参阅官方 Valkey TLS 文档。

#访问方式与 TLS

#目录

#Service 类型

#集群内 Service 名称

#IP 协议族

#启用 TLS

访问方式与 TLS

目录

Service 类型

集群内 Service 名称

IP 协议族

启用 TLS