在Azure Traffic Manager上如何配置AKS Ingress终端节点

Question

我已在AKS集群上部署了多个微服务，并在nginx ingress控制器上公开了它。ingress指向静态IP，其DNS为blabla.eastus.azure.com。

应用程序在blabla.eastus.azure.com/application/和blabla.eastus.azure.com/application2/等路径下公开。

我已在Azure的blabla.trafficmanager.net中创建了Traffic Manager配置文件。如何配置AKS Ingress以使Traffic Manager将请求重定向到部署在AKS Ingress上的应用程序？

---Ingress.yaml configuration used
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: ns
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: blabla.eastus.azure.com
    http:
      paths:
      - backend:
          serviceName: application1
          servicePort: 80
        path: /application1(/|$)(.*)
      - backend:
          serviceName: application2
          servicePort: 80
        path: /application2(/|$)(.*)
      - backend:
          serviceName: aks-helloworld
          servicePort: 80
        path: /(.*)

当我使用curl命令访问http://blabla.trafficmanager.net时，返回的响应为默认后端-404。

当我更新主机到http://blabla.trafficmanager.net时，我可以通过http://blabla.trafficmanager.net\application1访问应用程序。

同样适用于任何自定义CNAME创建。我创建了一个cname作为custom.domain.com，并将其重定向到blabla.eastus.azure.com。因此，除非我直接将主机更新到custom.domain.com，否则无法通过自定义域名访问它。

- Sam

---

你真的需要一个流量管理器吗？Ingress可以进行基于路径的路由。 - P Ekambaram

我有类似的问题。你找到解决方案了吗？ - Rahul Mohan

Answer 1

实际请求永远不会通过Traffic Manager。Traffic Manager是Azure提供的基于DNS的负载均衡解决方案。

当您浏览Azure TM终结点时，它会解析并给您一个IP地址。然后您的浏览器请求该IP地址。

在您的情况下，您的AKS应该有一个公共终结点，TM可以解析DNS查询。此外，您需要创建一个CNAME记录，将TM FQDN映射到您的自定义域。如果没有完成这项操作，您将收到404错误。

上述自定义标头设置是针对探测的，但实际请求将从客户端浏览器发送到TM解析到的终结点/IP。

- msrini-MSIT

---

我在两个区域中拥有两个AKS集群，分别具有自定义域名aks1.xyz.com和aks2.xyz.com的ngnix ingress LB。我在每个集群上都有两个服务A和B，可以通过相对路径/srv-a和/srv-b在每个集群上通过ingress主机aks1.xyz.com和aks2.xyz.com单独访问。我将这些自定义域添加到Azure Traffic Manager中，并配置在端口443和路径/healthz上进行探测。端点在线，但我无法通过TM自定义域xyz.com映射到xyz.trafficmanager.net访问服务。请建议！ - Rahul Mohan

面对相同的问题。这个问题有解决方案吗？ - ctienshi

Answer 2

一种实现您需求的方法是严格控制每个地区公共DNS与入口控制器公共IP之间的流量，并将如何发布服务的灵活性委托给HTTP SNI协议：

为了简单起见，Ingress Controller没有任何A DNS记录分配给其公共IP。

因此，我们将按照图表从右到左实现架构。

流量管理器将有两个端点：每个区域一个。每个端点的值将是相应的Ingress公共IP。

DNS服务将为app.mydomain.com配置了一个CNAME（别名）作为mine-apps.trafficmanager.net。

这样，连接到app.mydomain.com的客户端将解析Traffic Manager（TM）服务，它是一个Geo DNS，并根据客户端的IP返回更接近A和B之间目标区域的客户端。

同样，您可以使用基于URL或路径的路由通过Ingres公开服务，并控制客户端如何连接到它们。只需确保您的DNS知道如何连接到Traffic Manager即可。其余部分将由Kubernetes中的TM和Ingress对象神奇地处理。

最后但并非最不重要的是，一旦所有集成都正确配置并满足您的主要需求，您可以开始扩展现有架构并适应您的实际需求；例如：摆脱Traffic Manager端点中的静态IP。

- andov

---

嗨Andov！我很好奇想更多了解这个设置。所以当用户/客户连接到app.domain.com时，它将解析到TM的URL，这一点很清楚。然后TM会根据地理位置返回给客户更接近的目标（A或B）。这部分也很明确。最终TM将向客户返回NGINX Ingress Controller的公共IP地址。那么用户就连接到这个公共IP对吗？然后当用户访问该公共IP时，会加载404页面或其他内容对吗？你能解释一下这部分吗？ - Container-Man

嗨@Container-Man，正确的是用户将透明地通过他的客户端连接到Ingress Controller负载均衡器的区域公共IP。希望用户通过Ingress Controller访问托管在Kubernetes中的Pod。如果最终用户遇到404错误，意味着：Ingress Controller中的HTTP Host头不匹配，TM和Ingress Controller的负载均衡器之间存在配置错误，最后但并非最不重要的是指向Kubernetes Pod的Ingress对象丢失。 - andov