我创建了 HELM 图表，用于使用 sentinel 部署 redis，并使用端口转发通过服务访问它。将端口转发到 6379 后，我可以设置或进入 redis-cli。然而， 当我从 statefulset 中删除 pod 时，我无法再访问 redis-cli 并得到提示。 ：
127.0.0.1:6379> get b
Error: Server closed the connection
基本上，sentinel 应该通信并更改主 pod，并且连接应该仍然存在。但就我而言，它无法正常工作。
【问题讨论】：
标签： docker kubernetes redis cloud kubernetes-helm
redis 图表有很多问题，但同时端口转发也有很多问题，所以问题似乎加倍复杂。 许多使用端口转发的人注意到它明显比通过服务连接到 Pod 慢，并且命令在几分钟后停止。所以我建议你不要将它用于生产系统。
我们可以在 Kubernetes 官方文档中看到手动强制 删除荚 StatefulSet应该 谨慎进行，因为它有可能违反 StatefulSet 所固有的大多数语义。可以使用 StatefulSet 运行需要的分布式和集群应用程序 稳定的网络身份和稳定的存储。这些应用程序经常 具有依赖于固定数量的集合的配置 具有固定身份的成员。有多个相同的成员 身份可能是灾难性的，并可能导致数据丢失（例如脑裂 基于仲裁的系统中的场景）
删除 pod Pod 的序号、主机名、SRV 记录和 A 记录名称未更改，但与关联的 IP 地址 豆荚变了。在本教程使用的集群中，他们有。 这就是为什么不要将其他应用程序配置为 通过 IP 地址连接到 StatefulSet 中的 Pod。
如果您需要查找并连接到某个活动的成员 StatefulSet，应该查询 Headless Service 的 CNAME （nginx.default.svc.cluster.local）。与 CNAME 将仅包含 StatefulSet 中正在运行的 Pod 并准备就绪。
如果您的应用程序已经实现了测试连接逻辑 liveness 和 readiness，你可以使用 Pod 的 SRV 记录（ web-0.nginx.default.svc.cluster.local, web-1.nginx.default.svc.cluster.local)，因为它们是稳定的，而您的 应用程序将能够发现 Pod 的地址 过渡到 Running 和 Ready。
你也可以使用代理代替端口转发，例如：
$ kubectl proxy --port=6379
如果您使用 kubectl 代理，则可以按预期访问不同的 pod。 端口转发最初设计为附加到一个 pod 以用于调试和其他目的。引入了有助于服务发现的新功能，因此如果您不关心附加到哪个 pod 名称（如果您有多个符合条件的名称），则无需先查找 pod 名称。端口转发启用 http 连接，目标是不应用应用程序级负载平衡并且不支持多个活动端点。如果活动 pod 终止，则会有一个单独的功能请求重新附加。
您也可以在 pod 配置文件中添加以下行来默认构建端口转发：
export YOURAPP_POD=$(kubectl get pods -n $NAMESPACE | grep your-app | awk '{print $1;}')
kubectl port-forward -n $YOUR_NAMESPACE $YOURAPP_POD 8080
或者你可以简单的在 pod 恢复后再次配置端口转发。
您可以在此处找到更多信息：kubectl-port-forward。
【讨论】：
如果它是基于 bitnami 的 redis sentinel 集群，则可能由于启动脚本中的竞争条件而没有进行哨兵选举。我遇到了这个评论：https://github.com/bitnami/charts/issues/6165#issuecomment-852905670 并应用了这个修复：https://github.com/bitnami/charts/issues/6165#issuecomment-857859224 在我的情况下有所帮助。
【讨论】：