无法访问服务 IP 或服务名称，但可以访问 Pod IP?

答案:

K8s 集群中 kube-proxy 可能使用 ipvs 模式，因此 kubevpn 需要使用选项 --netstack gvisor。

例如：

• 连接模式
  • kubevpn connect --netstack gvisor
• 代理模式
  • kubevpn proxy deployment/authors --netstack gvisor
• 克隆模式
  • kubevpn clone deployment/authors --netstack gvisor
• 开发模式
  • kubevpn dev deployment/authors --netstack gvisor

原因：

ipvs 模式使得 iptables 的 SNAT 不起作用，但 kubevpn 依赖 iptables 的 SNAT 来访问服务 IP，因此如果 kube-proxy 开启了 ipvs 模式，那么将无法访问服务 IP (Pod IP 的访问不受影响)。

解决方案：

kubevpn 使用 gVisor 来访问服务 IP，不依赖于 iptables。

参考资料：

https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-modes

kube-proxy 以不同模式启动，这由其配置确定。 在 Linux 节点上，kube-proxy 的可用模式包括：

iptables

一种模式，其中 kube-proxy 使用 iptables 配置数据包转发规则。

在此模式下，kube-proxy 使用内核 netfilter 子系统的 iptables API 配置数据包转发规则。 对于每个端点，它安装 iptables 规则，默认情况下随机选择一个后端 Pod。

ipvs

一种模式，其中 kube-proxy 使用 ipvs 配置数据包转发规则。

在 ipvs 模式下，kube-proxy 使用内核 IPVS 和 iptables API 创建规则，将流量从服务 IP 重定向到 端点 IP。

IPVS 代理模式基于和 iptables 模式相似的 netfilter 钩子函数，但使用哈希表作为底层数据结构，并在内核空间中工作。这意味着 IPVS 模式下的 kube-proxy 重定向流量的延迟比 iptables 模式下低，当同步代理规则时性能更好。与 iptables 代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

nftables

一种模式，其中 kube-proxy 使用 nftables 配置数据包转发规则。

在此模式下，kube-proxy 使用内核 netfilter 子系统的 nftables API 配置数据包转发规则。 对于每个端点，它安装 nftables 规则，默认情况下随机选择一个后端 Pod。

nftables API 是 iptables API 的后继者，旨在提供比 iptables 更好的性能和可扩展性。nftables 代理模式能够比 iptables 模式更快、更高效地处理对服务端点的变更，并且还能在内核中更高效地处理数据包（尽管这只有在拥有数以万计的服务的集群中才会明显）。

架构

使用 gVisor 访问 k8s service-cidr 和 pod-cidr 网络

仍然将 inner-cidr 网络流量发送到 tun 设备