Question

我们有两个用于不同环境的AKS集群。两者都使用Nginx服务器作为自定义入口。我的意思是说，它的作用就像一个入口，但这只是服务背后的常规Nginx部署。进行该设置有几个很好的理由，主要原因是我们开始时AKS中不存在入口。

服务的定义如下：

apiVersion: v1
kind: Service
metadata:
  name: <our name>
  namespace: <our namespace>
spec:
  ports:
  - port: 443
    targetPort: 443
  selector:
    app: <our app>
  loadBalancerIP: <our ip>
  type: LoadBalancer
  externalTrafficPolicy: Local

我们已经使用如下所示的实际ip模块配置了Nginx：

real_ip_header X-Original-Forwarded-For;
set_real_ip_from 10.0.0.0/8; # or whatever ip is correct

一种环境使用旧的基本网络networkPlugin = kubenet。 Nginx在那里将真实的客户端IP地址记录在日志中，并将其用于访问控制。另一个使用高级网络，即networkPlugin = azure。 Nginx记录了其中一个节点的IP地址，这是没有用的。 X-Original-Forwarded-For标头和标准X-Forwarded-For标头均为空，当然，源IP来自节点，而不是来自客户端。

有没有解决的办法？如果可能的话，我们想避免定义一个“真实的”入口，因为我们自己的Nginx服务器包含自定义配置，而在这种设置中很难复制该自定义配置，而且还不清楚标准入口是否会有所帮助？

Answer 1

Microsoft现在应该已经针对实际入侵解决了此问题。但是，显然，此修复程序无法解决我们的情况，即Nginx作为具有高级网络服务的后台运行的Pod运行。有人告诉我们使用denniszielke在https://github.com/Azure/AKS/issues/607中发布的解决方法，其中所有节点的iptables都会定期更新。在我看来，这很脏，但是可以。

我们仍然具有如上定义的“ externalTrafficPolicy：本地”服务，并且已经从链接安装了ConfigMap和DaemonSet。我更改了脚本以减少日志记录，并将两者都移至另一个名称空间。

通过高级网络无法在AKS中获得真正的远程IP

1 个答案: