我创建了HELM图表，用于使用哨兵部署Redis，并使用端口转发通过服务访问它。将端口转发到6379之后，我可以设置或进入redis-cli。然而，当我从有状态集中删除Pod时，我再也无法访问redis-cli并得到提示例如。 ：
127.0.0.1:6379> get b
Error: Server closed the connection
基本哨兵应该进行通信并更改主窗格，并且连接仍应存在。但就我而言，它无法正常工作。
redis图表有很多问题，但是与此同时，端口转发也有很多问题，因此问题似乎变得很复杂。许多使用端口转发的人注意到，它明显比通过服务连接到Pod慢，并且命令在几分钟后就停止了。因此，我建议您不要将其用于生产系统。
我们可以在Kubernetes官方文档手册中阅读的删除窗格StatefulSet应该谨慎行事，因为它有可能违反StatefulSet固有的大多数语义。可以使用StatefulSets运行需要稳定的网络身份和稳定的存储。这些应用经常具有依赖于固定数量的集合的配置具有固定身份的成员。多个成员具有相同的身份可能造成灾难性的后果，并可能导致数据丢失（例如脑裂基于仲裁的系统中的场景）
[删除Pod Pods的序号，主机名，SRV记录和A记录名称未更改，但是与吊舱已更改。在本教程使用的集群中，它们具有。这就是为什么不要将其他应用程序配置为通过IP地址连接到StatefulSet中的Pod。
如果您需要查找并连接到StatefulSet，您应该查询无头服务的CNAME（nginx.default.svc.cluster.local）。与SRV相关的SRV记录CNAME将仅包含StatefulSet中正在运行的Pod并准备就绪。
如果您的应用程序已经实现了测试连接逻辑的您可以使用Pod的SRV记录（web-0.nginx.default.svc.cluster.local，web-1.nginx.default.svc.cluster.local），因为它们很稳定，而且您的应用程序将能够发现Pod的地址转换为正在运行并准备就绪。
您也可以使用代理代替端口转发，例如：
$ kubectl proxy --port=6379
如果使用kubectl代理，则可以按预期到达不同的容器。端口转发最初设计为连接到一个Pod，以进行调试和其他用途。引入了一项新功能，该功能可帮助发现服务，因此，如果您有多个合格的名称，而不必担心附加到哪个名称，则无需先查找容器名称。端口转发可启用http连接，目标是不应用程序级别的负载平衡并且不支持多个活动端点。如果活动吊舱终止，则有单独的功能请求重新连接。
您还可以默认构建端口转发，将以下行添加到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 Recovery之后简单地再次配置端口转发。
更多详细信息，请参见kubectl-port-forward。