微服务 Istio / SpringCloud日益被越来越多的客户关注，Istio提供了各种酷炫的流量控制功能，但Istio距离生产部署可用仍然还有差距。条件路由是否可以在已有的Kubernetes Ingress架构中实现，以最小的代价实现应用的微服务化迁移。答案是肯定的，通过对ingress自定义location/server块的定义，以及upsteam自动生产的规则，可以实现复杂条件路由的支持，类似istio, match。




[不满足] 1. 尝试一， 修改Ingress的server-snippet/location-snippet属性来重定向请求到后台服务, 不能按期望跳转

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/load-balance: ip_hash
    nginx.ingress.kubernetes.io/server-snippet: |
      set $agentflag 0;


      if ($http_user_agent ~* "(Mobile)" ){
        set $agentflag 1;
      }


     if ( $agentflag = 1 ) {
      .  return 301 http://default-cardinfo-homepage-80;
     }
    nginx.ingress.kubernetes.io/upstream-hash-by: ip_hash
    nginx.ingress.kubernetes.io//location-snippet: |
                  if ( $agentflag = 1 ) {
                     proxy_pass http://default-cardinfo-homepage-80;
                  }
  creationTimestamp: 2018-08-27T12:06:32Z
  generation: 2
  name: nginx-test
  namespace: default
  resourceVersion: "43290755"
  selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/nginx-test
  uid: a310ca06-a9f1-11e8-a613-00163e0c87f1
spec:
  rules:
  - host: stickyingress.example.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
  - host: mobile.example.com
    http:
      paths:
      - backend:
          serviceName: cardinfo-homepage
          servicePort: 80
        path: /
status:
  loadBalancer:
    ingress:
    - {}

检查ingressController自动生成的nginx server定义, 仅仅依靠server-snippet 以及location-snippet是不能完成请求的自动跳转。server-snippet at ingress level does not work for reverse proxy server-snippet spec

[不满足] 尝试二, 使用IngressController级别的定义 location-snippet， location-snippet会传播到所有的location-block, 不满足期望。

location-snippet of ingress controller is applied to all location block, it does not work as expected


location-snippet



apiVersion: v1
data:
  location-snippet: |
    if ( $agentflag = 1 ) {
                     proxy_pass http://default-cardinfo-homepage-80;
     }
  proxy-body-size: 20m
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"proxy-body-size":"20m"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"ingress-nginx"},"name":"nginx-configuration","namespace":"kube-system"}}
  creationTimestamp: 2018-02-07T09:06:33Z
  labels:
    app: ingress-nginx
  name: nginx-configuration
  namespace: kube-system
  resourceVersion: "43308775"
  selfLink: /api/v1/namespaces/kube-system/configmaps/nginx-configuration
  uid: 312dd92f-0be6-11e8-856b-00163e0c87f1

[解决] 尝试三， 使用configuration-snippet + server-snippet + upstream default name 来实现路由跳转到不同的kubernetes service服务。

configuration-snippet is alternative of location snippet, combination configuration-snippet and server-snippet to parse header, set global variable, then proxy specific backend service with upstream name created by IngressController. e.g. default-cardinfo-homepage-80

metadata:
  annotations:
     nginx.ingress.kubernetes.io/server-snippet: |
      set $agentflag 0;

      if ($http_user_agent ~* "(Mobile)" ){
        set $agentflag 1;
      }
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ( $agentflag = 1 ) {
         proxy_pass http://default-cardinfo-homepage-80;
      }

Put everything together

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/load-balance: ip_hash
    nginx.ingress.kubernetes.io/server-snippet: |
      set $agentflag 0;

      if ($http_user_agent ~* "(Mobile)" ){
        set $agentflag 1;
      }
    nginx.ingress.kubernetes.io/upstream-hash-by: ip_hash
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ( $agentflag = 1 ) {
         proxy_pass http://default-cardinfo-homepage-80;
      }
  name: nginx-condition
  namespace: default
spec:
  rules:
  - host: stickyingress.example.com
    http:
      paths:
      - backend:
          serviceName: cardinfo-recommendation
          servicePort: 80
        path: /
  - host: mobile.example.com
    http:
      paths:
      - backend:
          serviceName: cardinfo-homepage
          servicePort: 80
        path: /
status:
  loadBalancer:
    ingress:
    - {}

测试

使用不同的Header 模拟不同用户浏览器请求，用户请求根据浏览器的类型被重定向到不同的后台服务和入口。以stickyingress.example.com为入口的用户使用"user-agent: (Mobile)"的用户，自动跳转到后台服务cardinfo-homepage，其他用户仍然进入cardinfo-recommendation。

curl stickyingress.example.com:32619 -v
* Rebuilt URL to: stickyingress.example.com:32619/
* Hostname was NOT found in DNS cache
*   Trying 192.168.33.239...
* Connected to stickyingress.example.com (192.168.33.239) port 32619 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.37.0
> Host: stickyingress.example.com:32619
> Accept: */*
>
< HTTP/1.1 200
* Server nginx/1.13.7 is not blacklisted
< Server: nginx/1.13.7
< Date: Wed, 14 Nov 2018 04:46:19 GMT
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 17
< Connection: keep-alive
<
* Connection #0 to host stickyingress.example.com left intact
recommendation v2

dns:~ # curl stickyingress.example.com:32619 -v -H "user-agent: (Mobile)"

* Rebuilt URL to: stickyingress.example.com:32619/
* Hostname was NOT found in DNS cache
*   Trying 192.168.33.239...
* Connected to stickyingress.example.com (192.168.33.239) port 32619 (#0)
> GET / HTTP/1.1
> Host: stickyingress.example.com:32619
> Accept: */*
> user-agent: (Mobile)
>
< HTTP/1.1 200
* Server nginx/1.13.7 is not blacklisted
< Server: nginx/1.13.7
< Date: Wed, 14 Nov 2018 04:46:31 GMT
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 26
< Connection: keep-alive
< Vary: Accept-Encoding
<
* Connection #0 to host stickyingress.example.com left intact
OK. Vist /cardinfo please.

Conclusion 总结

使用Ingress的自定义location/server block，以及upstream的隐含定义，依然可以实现类似Istio的自动流量路由功能，后台Pod出现更新升级并不会影响到条件跳转。 用户可以使用最小的代价通过Kubernetes Ingress实现ABTest，灰度，流量路由，并且享受到Kubernetes服务发现，和滚动更新带来的优势。