我们目前在 Amazon EC2 机器上以软件即服务的形式提供我们的软件。我们的软件是基于微服务的应用程序，具有大约 20 种不同的服务。 对于较大的客户，我们会在一组专用 VM 上使用专用安装，VM 的数量(以及微服务的实例数量)取决于客户的要求。任何大客户的共同要求是，我们的软件需要访问客户的数据中心(例如，用于LDAP访问)。到目前为止，我们使用亚马逊的虚拟私有网关功能解决了这个问题。
现在我们想把我们的 SaaS 部署转移到 Kubernetes。当然，我们可以在单个客户的虚拟机上创建一个 Kubernetes 集群(例如，使用 kops)，但这不会带来什么好处。 相反，从角度来看，我们希望运行一个大型 Kubernetes 集群，我们将各个客户的安装部署到专用命名空间中，与我们目前向客户固定分配机器相比，这样就可以提高资源利用率并降低成本。 从 Kubernetes 方面来看，我们的软件已经运行良好，我们可以将多个安装部署到一个集群中。然而，一个开放的话题是VPN访问。我们需要的是一种允许客户命名空间中的所有 Pod访问客户 VPN 的方法，但不允许访问任何其他客户的 VPN。
在谷歌搜索该主题时，我发现了将VPN客户端添加到单个容器的方法(例如，https://caveofcode.com/2017/06/how-to-setup-a-vpn-connection-from-inside-a-pod-in-kubernetes/)，这显然不是一种选择)。 其他方法似乎描述了在K8s中运行VPN服务器(这也不是我们所需要的)。 同样，其他人(如"Strongswan IPSec VPN服务"，https://www.ibm.com/blogs/bluemix/2017/12/connecting-kubernetes-cluster-premises-resources/)使用DaemonSets来"在每个工作节点上配置路由"。这似乎也不是我们可以接受的解决方案，因为这将允许工作节点上的所有 pod(无论它们位于哪个命名空间)访问相应的 VPN...如果我们有数十个客户安装，每个客户都需要在群集上设置自己的 VPN，那么也不会很好地工作。
是否有任何方法或解决方案可以提供我们需要的东西，即仅对特定命名空间中的 pod 进行 VPN 访问？ 或者是否有任何其他方法仍然可以满足我们的需求(由于 Kubernetes 工作节点在客户之间共享而降低了成本)？
对于 LDAP 访问，一种选择可能是设置一种 LDAP 代理，以便只有此代理需要对客户网络具有 VPN 访问权限(方法是在每个客户的小型专用 VM 上运行此代理，然后将代理配置为应用程序的 LDAP 终结点)。但是，LDAP 访问只是我们的应用程序根据用例所需的连接性众多方面之一。
如果您的 IPSec 集中器支持 VTI，则可以使用防火墙规则路由流量。例如，PFSense 支持它：https://www.netgate.com/docs/pfsense/vpn/ipsec/ipsec-routed.html。
使用 VTI，您可以使用某种策略路由来引导流量：https://www.netgate.com/docs/pfsense/routing/directing-traffic-with-policy-routing.html
但是，我在这里可以看到两个大问题：
-
不能有两个与冲突网络的 IPSEC 隧道。例如，您的 kube 网络是 192.168.0.0/24，您有两个客户：A (172.12.0.0/24) 和 B (172.12.0.0/12)。不幸的是，这可能会发生(除非您的客户能够对这些网络进行 NAT )。
-
找到规则匹配的理想条件(以允许路由)，因为源网络始终相同。使用标记包(使用 iptables mangle 甚至通过应用程序)可能是一种选择，但您仍然会卡在第一个问题上。
类似的方案基于 WSO2(API 网关提供程序)体系结构。他们在每个网络中使用反向代理解决了这个问题(悲伤但真实)https://docs.wso2.com/display/APICloud/Expose+your+On-Premises+Backend+Services+to+the+API+Cloud#ExposeyourOn-PremisesBackendServicestotheAPICloud-ExposeyourservicesusingaVPN
问候
更新：
我不知道你是否使用GKE。如果是，也许可以使用别名 IP 是一种选择：https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips。容器 IP 可从 VPC 路由。因此，您可以根据其 CIDR 应用某种路由策略。