前言

最近在做标准产品在不同云平台中的部署验证，有幸体验了一下微软的Azure。负责采购的运维部门这次采用了Application Gateway来搭配AKS(Azure Kubernetes Service)对外暴露服务，正好借着这个机会来体验一下Application Gateway。

应用场景

1. 域名api.demo.com指向Application Gateway的IP地址
2. 在AKS内部2个Service, gateway-service和backend-service分别需要通过Application Gateway对外暴露。
3. /gateway/指向gateway-service, 然后/backend/指向backend-service。而且两个Service都没有context-path，所以需要做一个Rewrite重写URI到Service的根目录上。

定义重写集

打开AKS对应的应用程序网关设置 > 重写。选择添加重写集。在1. 名称和关联这个Tab上只需要填写名称这项即可(名称后面在做ingress时需要使用), 关联的传递规则不需要选择。2. 重写规则配置里添加一个重写规则，然后填上重写规则的名称，并添加条件(默认新建重写规则时，只会生成操作，不会生成条件)

条件做如下设置

• 要检查的变量类型 : 服务器变量
• 服务器变量: request_uri
• 区分大小写: 否
• 运算符: 等号(=)
• 要匹配的模式: /(gateway|backend)/?(.*)

操作做如下设置

• 重写类型: URL
• 操作类型: 设置
• 组件: URL路径和URL查询字符串
• URL路径值: /{var_request_uri_2}
• 重新计算路径映射: 不选中
• URL查询字符串值: 留空不设值

特殊说明

操作里的URL路径值不能使用正则表达式GROUP替换组，例如$1和$2之类的。Azure自己定义了一套对应的替换组命名规则。具体可以参考这个网页使用应用程序网关重写 HTTP 标头和 URL。

另外一个需要注意一点，如果在条件里选择了服务器变量的request_uri的时候，注意这个request_uri是完整的原始请求URI(携带了查询参数)。例如: 在请求http://api.demo.com/gateway/search?foo=bar&hello=world中，request_uri的值将为/gateway/search?foo=bar&hello=world。由于request_uri里包含了查询参数，所以在操作的组件中建议勾选URL路径和URL查询字符串。如果只选择URL路径的情况下可能出现无法预期的错误。以我们上述的配置来说明。

对象URL: http://api.demo.com/gateway/search?foo=bar&hello=world

ACK的Ingress设置

当选择了Application Gateway作为对外暴露Service的方式时，Kubernetes集群里(kube-system命名空间里)多一个Application Gateway Ingress Controller(Azure工单时通常会简称为agic)的Deployment,所以对外暴露服务时可以像传统nginx ingress controller一样添加一个Ingress对象即可(甚至配置也和ngic大致相同，只是多了2个annotations)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # 这里指定重写规则集(不是重写规则的名字)
    appgw.ingress.kubernetes.io/rewrite-rule-set: rule-backend
    # 指定说明你这里ingress的类型是agic
    kubernetes.io/ingress.class: azure/application-gateway
  name: backend-ingress
  namespace: default
spec:
  rules:
  - host: api.demo.com
    http:
      paths:
      - backend:
          service:
            name: gateway-service
            port:
              number: 8080
        path: /gateway/
        pathType: Prefix
      - backend:
          service:
            name: backend-service
            port:
              number: 8080
        path: /backend/
        pathType: Prefix

总结

由于微软云这块文档有部分缺失，导致在配置这块花了一点时间去排查，甚至开了工单。总结下来Ingress的配置主要是根据请求路径路由到对应的Service，重写规则集才是实际负责根据正则来进行匹配重写。

1
2

Update:
2020-04-08 增加istio-ingressgateway高可用的设置

最近公司因为项目需要，在阿里云上部署了一个Kubernetes集群。虽然阿里云的文档说的还算细致，但是还是有些没有明确说明的细节。

1. 购买篇

申请项目预算的时候，只考虑到Worker节点，1个SLB节点以及域名和证书的预算。但是实际购买的时候发现还有许多额外的开销。

1.1 SNAT

这个和EIP一并购买，可以方便通过公网使用kubectl访问集群。关于SNAT网关至今不是很明白需要购买这个服务的意义何在，只是为了一个EIP来访问集群吗？

1.2 Ingress

这个选上了后，阿里云会给你买个SLB而且还是带公网访问的，如果你后期考虑使用Istio的话，建议你集群创建后，直接停止这个SLB，以免产生额外的费用。

1.3 日志服务

通过阿里云的日志服务来收集应用的的日志，挺好用的。但是另外收费，如果有能力的自建日志服务的可不购买。

2. Istio

阿里云的Kubernetes集群完美集成了Istio，根据向导就能很简单的部署成功。

2.1 额外的SLB

Istio的Gateway 需要绑定一个新的SLB，和Ingress的SLB不能是同一个，又是一笔额外的开销

2.2 集群外访问

这个在阿里云的Istio FAQ中有提到，按照指导很容易解决

2.2 SLB的443监听

为了方便443端口的证书绑定，我们直接删除了SLB上原有的443监听(TCP协议), 重新建了一个443监听(HTTPS协议)，指向和80端口同样的虚拟服务器组。但是设置健康检查时一直出错，经过排查发现SLB健康检查发送的请求协议是HTTP 1.0的，Istio的envoy直接反悔了426(Upgrade Required)这个状态码，所以我们无奈只能把健康检查的检查返回状态改为http_4xx，这样就能通过SLB的健康检查了。

2.3 istio-ingressgateway的高可用

istio-ingressgateway要达成高可用，只需要增加通过伸缩POD就可以实现，于istio-ingressgateway对应的SLB中的虚拟服务器组也会自动增加，完全不需要进行额外的手动设定。

由于istio-ingressgateway中挂载了HPAHorizontalPodAutoscaler(简称HPA)，通常三节点的集群中最小POD数只有1台，在3节点的集群中，要实现高可用，需要手动修改HPA，增加最小POD数。

基本上现在遇到了这些坑，再有在总结吧。