使用 kube-proxy ipvs 时的 Nodeport SFTP / SSH 连接超时答案

【问题标题】：Nodeport SFTP / SSH connection timeout when using kube-proxy ipvs使用 kube-proxy ipvs 时的 Nodeport SFTP / SSH 连接超时
【发布时间】：2020-08-12 22:34:48
【问题描述】：

我们目前正在从 Docker Swarm 迁移到 k8s（裸机），我们无法访问 pod 中的 SFTP 服务。服务：

Name:                     mlflow-artifacts-store
Namespace:                mlflow
Labels:                   app.kubernetes.io/instance=mlflow-artifacts-store
                          app.kubernetes.io/managed-by=Helm
                          app.kubernetes.io/name=mlflow-artifacts-store
                          helm.sh/chart=mlflow-artifacts-store-0.1.0
Annotations:              meta.helm.sh/release-name: mlflow-artifacts-store
                          meta.helm.sh/release-namespace: mlflow
Selector:                 app.kubernetes.io/instance=mlflow-artifacts-store,app.kubernetes.io/name=mlflow-artifacts-store
Type:                     NodePort
IP:                       10.233.24.136
Port:                     ssh  80/TCP
TargetPort:               22/TCP
NodePort:                 ssh  30001/TCP
Endpoints:                10.233.93.77:22
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

但即使从同一台服务器我也无法访问它：（为演示添加了超时）

OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.233.24.136 [10.233.24.136] port 30001.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
Connection timed out during banner exchange
Couldn't read packet: Connection reset by peer

服务器本身可以从同一命名空间中的不同 pod 访问 - 因此我猜它可能与 NodePort 暴露本身或配置有关。

使用 hostPort 公开服务是可行的，但我不想像这样公开它。我错过了什么？

【问题讨论】：

我用官方的舵图“lamp”测试了同样的东西——结果是一样的。
SFTP服务是如何暴露的？只有特定的 pod 无法访问 SFTP 服务器？您是否启用了网络策略？
未启用网络策略。服务本身由服务文件 (nodePort) 公开。我刚刚注意到，当我使用 eth0 的 IP 时，我可以访问该服务，但不能从 kube-ipvs0 中的负载均衡器访问（与 sftp 服务相同的设备）。但我可以访问 Ingress 相关服务...
是的，它必须使用 nodePort 才能工作，但实际上 Loadbalancer 仅支持 HTTP/HTTPS 流量，并且 SFTP 默认运行在 TCP 端口 22 上。您可以使用 nginx-ingress 尝试一些解决方法，请参阅此 [link](shorturl.at/luxBS) 和 [this](shorturl.at/dpJMP)。但是，由于您使用的是裸机集群，因此您还需要安装 MetalLB 以使 nginx-ingress 正常工作。请提供您的 yaml 文件用于 SFTP 部署和服务，可以帮助您实现您想要的。

标签： kubernetes ssh sftp

【解决方案1】：

所以在 github 上讨论了整个事情之后，行为是有意的。将 kube-proxy 与 ipvs 一起使用时，ipvs0 接口无法访问该服务。 https://github.com/kubernetes/kubernetes/issues/93674#issuecomment-669200021

ipvs 默认关闭，只是一个没有流量的虚拟网络。在文档中它是这样写的

--nodeport-addresses 的默认值是一个空列表。这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。

但无法访问 ipvs0 - 这是有意的。所以答案是：你应该使用节点的真实地址。

【讨论】：