然后使用正确的用户名和密码测试：

1. ➜ curl -k http://192.168.31.31 -v -H 'Host: external-bauth.qikqiak.com' -u 'user:passwd'
2. * Trying 192.168.31.31...
3. * TCP_NODELAY set
4. * Connected to 192.168.31.31 (192.168.31.31) port 80 (#0)
5. * Server auth using Basic with user 'user'
6. > GET / HTTP/1.1
7. > Host: external-bauth.qikqiak.com
8. > Authorization: Basic dXNlcjpwYXNzd2Q=
9. > User-Agent: curl/7.64.1
10. > Accept: */*
11. >
12. < HTTP/1.1 200 OK
13. < Date: Thu, 16 Dec 2021 10:58:31 GMT
14. < Content-Type: text/html
15. < Content-Length: 615
16. < Connection: keep-alive
17. < Last-Modified: Tue, 02 Nov 2021 14:49:22 GMT
18. < ETag: "61814ff2-267"
19. < Accept-Ranges: bytes
20. <
21.  
22.  
23.  
24.  
26.  
27.  

28. Welcome to nginx!

29. If you see this page, the nginx web server is successfully installed and

30. working. Further configuration is required.

     

31.  

32. For online documentation and support please refer to

33. "http://nginx.org/">nginx.org.
34. Commercial support is available at
35. "http://nginx.com/">nginx.com.

     

36.  

37. Thank you for using nginx.

38.  
39.  
40. * Connection #0 to host 192.168.31.31 left intact
41. * Closing connection 0

如果用户名或者密码错误则同样会出现401的状态码：

1. ➜ curl -k http://192.168.31.31 -v -H 'Host: external-bauth.qikqiak.com' -u 'user:passwd123'
2. * Trying 192.168.31.31...
3. * TCP_NODELAY set
4. * Connected to 192.168.31.31 (192.168.31.31) port 80 (#0)
5. * Server auth using Basic with user 'user'
6. > GET / HTTP/1.1
7. > Host: external-bauth.qikqiak.com
8. > Authorization: Basic dXNlcjpwYXNzd2QxMjM=
9. > User-Agent: curl/7.64.1
10. > Accept: */*
11. >
12. < HTTP/1.1 401 Unauthorized
13. < Date: Thu, 16 Dec 2021 10:59:18 GMT
14. < Content-Type: text/html
15. < Content-Length: 172
16. < Connection: keep-alive
17. * Authentication problem. Ignoring this.
18. < WWW-Authenticate: Basic realm="Fake Realm"
19. <
20.  
21.  
22.  

23. 401 Authorization Required

24. ---

    nginx
25.  
26.  
27. * Connection #0 to host 192.168.31.31 left intact
28. * Closing connection 0

当然除了 Basic Auth 这一种简单的认证方式之外，ingress-nginx 还支持一些其他高级的认证，比如我们可以使用 GitHub OAuth 来认证 Kubernetes 的 Dashboard。

URL Rewrite

ingress-nginx 很多高级的用法可以通过 Ingress 对象的 annotation 进行配置，比如常用的 URL Rewrite 功能。很多时候我们会将 ingress-nginx 当成网关使用，比如对访问的服务加上 /app 这样的前缀，在 nginx 的配置里面我们知道有一个 proxy_pass 指令可以实现：

1. location /app/ {
2. proxy_pass http://127.0.0.1/remote/;
3. }

proxy_pass 后面加了 /remote 这个路径，此时会将匹配到该规则路径中的 /app 用 /remote 替换掉，相当于截掉路径中的 /app。同样的在 Kubernetes 中使用 ingress-nginx 又该如何来实现呢?我们可以使用 rewrite-target 的注解来实现这个需求，比如现在我们想要通过 rewrite.qikqiak.com/gateway/ 来访问到 Nginx 服务，则我们需要对访问的 URL 路径做一个 Rewrite，在 PATH 中添加一个 gateway 的前缀，关于 Rewrite 的操作在 ingress-nginx 官方文档中也给出对应的说明:

按照要求我们需要在 path 中匹配前缀 gateway，然后通过 rewrite-target 指定目标，Ingress 对象如下所示：

1. apiVersion: networking.k8s.io/v1
2. kind: Ingress
3. metadata:
4. name: rewrite
5. annotations:
6. nginx.ingress.kubernetes.io/rewrite-target: /$2
7. spec:
8. ingressClassName: nginx
9. rules:
10. - host: rewrite.qikqiak.com
11. http:
12. paths:
13. - path: /gateway(/|$)(.*)
14. pathType: Prefix
15. backend:
16. service:
17. name: my-nginx
18. port:
19. number: 80

更新后，我们可以预见到直接访问域名肯定是不行了，因为我们没有匹配 / 的 path 路径：

1. ➜ curl rewrite.qikqiak.com
2. default backend - 404

但是我们带上 gateway 的前缀再去访问:

我们可以看到已经可以访问到了，这是因为我们在 path 中通过正则表达式 /gateway(/|$)(.*) 将匹配的路径设置成了 rewrite-target 的目标路径了，所以我们访问 rewite.qikqiak.com/gateway/ 的时候实际上相当于访问的就是后端服务的 / 路径。

要解决我们访问主域名出现 404 的问题，我们可以给应用设置一个 app-root 的注解，这样当我们访问主域名的时候会自动跳转到我们指定的 app-root 目录下面，如下所示：

1. apiVersion: networking.k8s.io/v1
2. kind: Ingress
3. metadata:
4. name: rewrite
5. annotations:
6. nginx.ingress.kubernetes.io/app-root: /gateway/
7. nginx.ingress.kubernetes.io/rewrite-target: /$2
8. spec:
9. ingressClassName: nginx
10. rules:
11. - host: rewrite.qikqiak.com
12. http:
13. paths:
14. - path: /gateway(/|$)(.*)
15. pathType: Prefix
16. backend:
17. service:
18. name: my-nginx
19. port:
20. number: 80

这个时候我们更新应用后访问主域名 rewrite.qikqiak.com 就会自动跳转到 rewrite.qikqiak.com/gateway/ 路径下面去了。但是还有一个问题是我们的 path 路径其实也匹配了 /app 这样的路径，可能我们更加希望我们的应用在最后添加一个 / 这样的 slash，同样我们可以通过 configuration-snippet 配置来完成，如下 Ingress 对象：

1. apiVersion: networking.k8s.io/v1
2. kind: Ingress
3. metadata:
4. name: rewrite
5. annotations:
6. nginx.ingress.kubernetes.io/app-root: /gateway/
7. nginx.ingress.kubernetes.io/rewrite-target: /$2
8. nginx.ingress.kubernetes.io/configuration-snippet: |
9. rewrite ^(/gateway)$ $1/ redirect;
10. spec:
11. ingressClassName: nginx
12. rules:
13. - host: rewrite.qikqiak.com
14. http:
15. paths:
16. - path: /gateway(/|$)(.*)
17. pathType: Prefix
18. backend:
19. service:
20. name: my-nginx
21. port:
22. number: 80

更新后我们的应用就都会以 / 这样的 slash 结尾了。这样就完成了我们的需求，如果你原本对 nginx 的配置就非常熟悉的话应该可以很快就能理解这种配置方式了。

灰度发布

在日常工作中我们经常需要对服务进行版本更新升级，所以我们经常会使用到滚动升级、蓝绿发布、灰度发布等不同的发布操作。而 ingress-nginx 支持通过 Annotations 配置来实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。

ingress-nginx 的 Annotations 支持以下 4 种 Canary 规则：

• nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always 时，请求将会被一直发送到 Canary 版本;当 Request Header 设置为 never 时，请求不会被发送到 Canary 入口;对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
• nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (canary-by-header) 一起使用。
• nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求，权重为 100 意味着所有请求都将被发送到 Canary 入口。
• nginx.ingress.kubernetes.io/canary-by-cookie：基于 cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always 时，它将被路由到 Canary 入口;当 cookie 值设置为 never 时，请求不会被发送到 Canary 入口;对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

需要注意的是金丝雀规则按优先顺序进行排序：canary-by-header - > canary-by-cookie - > canary-weight

总的来说可以把以上的四个 annotation 规则划分为以下两类：

基于权重的 Canary 规则

基于用户请求的 Canary 规则

下面我们通过一个示例应用来对灰度发布功能进行说明。

第一步. 部署 Production 应用

首先创建一个 production 环境的应用资源清单：

1. # production.yaml
2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5. name: production
6. labels:
7. app: production
8. spec:
9. selector:
10. matchLabels:
11. app: production
12. template:
13. metadata:
14. labels:
15. app: production
16. spec:
17. containers:
18. - name: production
19. image: cnych/echoserver
20. ports:
21. - containerPort: 8080
22. env:
23. - name: NODE_NAME
24. valueFrom:
25. fieldRef:
26. fieldPath: spec.nodeName
27. - name: POD_NAME
28. valueFrom:
29. fieldRef:
30. fieldPath: metadata.name
31. - name: POD_NAMESPACE
32. valueFrom:
33. fieldRef:
34. fieldPath: metadata.namespace
35. - name: POD_IP
36. valueFrom:
37. fieldRef:
38. fieldPath: status.podIP
39. ---
40. apiVersion: v1
41. kind: Service
42. metadata:
43. name: production
44. labels:
45. app: production
46. spec:
47. ports:
48. - port: 80
49. targetPort: 8080
50. name: http
51. selector:
52. app: production

然后创建一个用于 production 环境访问的 Ingress 资源对象：

1. # production-ingress.yaml
2. apiVersion: networking.k8s.io/v1
3. kind: Ingress
4. metadata:
5. name: production
6. spec:
7. ingressClassName: nginx
8. rules:
9. - host: echo.qikqiak.com
10. http:
11. paths:
12. - path: /
13. pathType: Prefix
14. backend:
15. service:
16. name: production
17. port:
18. number: 80

直接创建上面的几个资源对象：

1. ➜ kubectl apply -f production.yaml
2. ➜ kubectl apply -f production-ingress.yaml
3. ➜ kubectl get pods -l app=production
4. NAME READY STATUS RESTARTS AGE
5. production-856d5fb99-d6bds 1/1 Running 0 2m50s
6. ➜ kubectl get ingress
7. NAME CLASS HOSTS ADDRESS PORTS AGE
8. production echo.qikqiak.com 10.151.30.11 80 90s

应用部署成功后，将域名 echo.qikqiak.com 映射到 master1 节点(ingress-nginx 所在的节点)的 IP即可正常访问应用：

1. ➜ curl http://echo.qikqiak.com
2.  
3. Hostname: production-856d5fb99-d6bds
4.  
5. Pod Information:
6. node name: node1
7. pod name: production-856d5fb99-d6bds
8. pod namespace: default
9. pod IP: 10.244.1.111
10.  
11. Server values:
12. server_version=nginx: 1.13.3 - lua: 10008
13.  
14. Request Information:
15. client_address=10.244.0.0
16. method=GET
17. real path=/
18. query=
19. request_version=1.1
20. request_scheme=http
21. request_uri=http://echo.qikqiak.com:8080/
22.  
23. Request Headers:
24. accept=*/*
25. host=echo.qikqiak.com
26. user-agent=curl/7.64.1
27. x-forwarded-for=171.223.99.184
28. x-forwarded-host=echo.qikqiak.com
29. x-forwarded-port=80
30. x-forwarded-proto=http
31. x-real-ip=171.223.99.184
32. x-request-id=e680453640169a7ea21afba8eba9e116
33. x-scheme=http
34.  
35. Request Body:
36. -no body in request-

第二步. 创建 Canary 版本

参考将上述 Production 版本的 production.yaml 文件，再创建一个 Canary 版本的应用。

1. # canary.yaml
2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5. name: canary
6. labels:
7. app: canary
8. spec:
9. selector:
10. matchLabels:
11. app: canary
12. template:
13. metadata:
14. labels:
15. app: canary
16. spec:
17. containers:
18. - name: canary
19. image: cnych/echoserver
20. ports:
21. - containerPort: 8080
22. env:
23. - name: NODE_NAME
24. valueFrom:
25. fieldRef:
26. fieldPath: spec.nodeName
27. - name: POD_NAME
28. valueFrom:
29. fieldRef:
30. fieldPath: metadata.name
31. - name: POD_NAMESPACE
32. valueFrom:
33. fieldRef:
34. fieldPath: metadata.namespace
35. - name: POD_IP
36. valueFrom:
37. fieldRef:
38. fieldPath: status.podIP
39. ---
40. apiVersion: v1
41. kind: Service
42. metadata:
43. name: canary
44. labels:
45. app: canary
46. spec:
47. ports:
48. - port: 80
49. targetPort: 8080
50. name: http
51. selector:
52. app: canary

接下来就可以通过配置 Annotation 规则进行流量切分了。

第三步. Annotation 规则配置

1. 基于权重：基于权重的流量切分的典型应用场景就是蓝绿部署，可通过将权重设置为 0 或 100 来实现。例如，可将 Green 版本设置为主要部分，并将 Blue 版本的入口配置为 Canary。最初，将权重设置为 0，因此不会将流量代理到 Blue 版本。一旦新版本测试和验证都成功后，即可将 Blue 版本的权重设置为 100，即所有流量从 Green 版本转向 Blue。

创建一个基于权重的 Canary 版本的应用路由 Ingress 对象。

1. # canary-ingress.yaml
2. apiVersion: networking.k8s.io/v1
3. kind: Ingress
4. metadata:
5. name: canary
6. annotations:
7. nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
8. nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
9. spec:
10. ingressClassName: nginx
11. rules:
12. - host: echo.qikqiak.com
13. http:
14. paths:
15. - path: /
16. pathType: Prefix
17. backend:
18. service:
19. name: canary
20. port:
21. number: 80

直接创建上面的资源对象即可：

1. ➜ kubectl apply -f canary.yaml
2. ➜ kubectl apply -f canary-ingress.yaml
3. ➜ kubectl get pods
4. NAME READY STATUS RESTARTS AGE
5. canary-66cb497b7f-48zx4 1/1 Running 0 7m48s
6. production-856d5fb99-d6bds 1/1 Running 0 21m
7. ......
8. ➜ kubectl get svc
9. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
10. canary ClusterIP 10.106.91.106 80/TCP 8m23s
11. production ClusterIP 10.105.182.15 80/TCP 22m
12. ......
13. ➜ kubectl get ingress
14. NAME CLASS HOSTS ADDRESS PORTS AGE
15. canary echo.qikqiak.com 10.151.30.11 80 108s
16. production echo.qikqiak.com 10.151.30.11 80 22m

Canary 版本应用创建成功后，接下来我们在命令行终端中来不断访问这个应用，观察 Hostname 变化：

1. ➜ for i in $(seq 1 10); do curl -s echo.qikqiak.com | grep "Hostname"; done
2. Hostname: production-856d5fb99-d6bds
3. Hostname: canary-66cb497b7f-48zx4
4. Hostname: production-856d5fb99-d6bds
5. Hostname: production-856d5fb99-d6bds
6. Hostname: production-856d5fb99-d6bds
7. Hostname: production-856d5fb99-d6bds
8. Hostname: production-856d5fb99-d6bds
9. Hostname: canary-66cb497b7f-48zx4
10. Hostname: canary-66cb497b7f-48zx4
11. Hostname: production-856d5fb99-d6bds

由于我们给 Canary 版本应用分配了 30% 左右权重的流量，所以上面我们访问10次有3次访问到了 Canary 版本的应用，符合我们的预期。

2. 基于 Request Header: 基于 Request Header 进行流量切分的典型应用场景即灰度发布或 A/B 测试场景。

在上面的 Canary 版本的 Ingress 对象中新增一条 annotation 配置 nginx.ingress.kubernetes.io/canary-by-header: canary(这里的 value 可以是任意值)，使当前的 Ingress 实现基于 Request Header 进行流量切分，由于 canary-by-header 的优先级大于 canary-weight，所以会忽略原有的 canary-weight 的规则。

1. annotations:
2. nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
3. nginx.ingress.kubernetes.io/canary-by-header: canary # 基于header的流量切分
4. nginx.ingress.kubernetes.io/canary-weight: "30" # 会被忽略，因为配置了 canary-by-headerCanary版本

更新上面的 Ingress 资源对象后，我们在请求中加入不同的 Header 值，再次访问应用的域名。

注意：当 Request Header 设置为 never 或 always 时，请求将不会或一直被发送到 Canary 版本，对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他 Canary 规则进行优先级的比较。

1. ➜ for i in $(seq 1 10); do curl -s -H "canary: never" echo.qikqiak.com | grep "Hostname"; done
2. Hostname: production-856d5fb99-d6bds
3. Hostname: production-856d5fb99-d6bds
4. Hostname: production-856d5fb99-d6bds
5. Hostname: production-856d5fb99-d6bds
6. Hostname: production-856d5fb99-d6bds
7. Hostname: production-856d5fb99-d6bds
8. Hostname: production-856d5fb99-d6bds
9. Hostname: production-856d5fb99-d6bds
10. Hostname: production-856d5fb99-d6bds
11. Hostname: production-856d5fb99-d6bds

这里我们在请求的时候设置了 canary: never 这个 Header 值，所以请求没有发送到 Canary 应用中去。如果设置为其他值呢：

1. ➜ for i in $(seq 1 10); do curl -s -H "canary: other-value" echo.qikqiak.com | grep "Hostname"; done
2. Hostname: production-856d5fb99-d6bds
3. Hostname: production-856d5fb99-d6bds
4. Hostname: canary-66cb497b7f-48zx4
5. Hostname: production-856d5fb99-d6bds
6. Hostname: production-856d5fb99-d6bds
7. Hostname: production-856d5fb99-d6bds
8. Hostname: production-856d5fb99-d6bds
9. Hostname: canary-66cb497b7f-48zx4
10. Hostname: production-856d5fb99-d6bds
11. Hostname: canary-66cb497b7f-48zx4

由于我们请求设置的 Header 值为 canary: other-value，所以 ingress-nginx 会通过优先级将请求与其他 Canary 规则进行优先级的比较，我们这里也就会进入 canary-weight: "30" 这个规则去。

这个时候我们可以在上一个 annotation (即 canary-by-header)的基础上添加一条 nginx.ingress.kubernetes.io/canary-by-header-value: user-value 这样的规则，就可以将请求路由到 Canary Ingress 中指定的服务了。

1. annotations:
2. nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
3. nginx.ingress.kubernetes.io/canary-by-header-value: user-value
4. nginx.ingress.kubernetes.io/canary-by-header: canary # 基于header的流量切分
5. nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本

同样更新 Ingress 对象后，重新访问应用，当 Request Header 满足 canary: user-value时，所有请求就会被路由到 Canary 版本：

1. ➜ for i in $(seq 1 10); do curl -s -H "canary: user-value" echo.qikqiak.com | grep "Hostname"; done
2. Hostname: canary-66cb497b7f-48zx4
3. Hostname: canary-66cb497b7f-48zx4
4. Hostname: canary-66cb497b7f-48zx4
5. Hostname: canary-66cb497b7f-48zx4
6. Hostname: canary-66cb497b7f-48zx4
7. Hostname: canary-66cb497b7f-48zx4
8. Hostname: canary-66cb497b7f-48zx4
9. Hostname: canary-66cb497b7f-48zx4
10. Hostname: canary-66cb497b7f-48zx4
11. Hostname: canary-66cb497b7f-48zx4

3. 基于 Cookie：与基于 Request Header 的 annotation 用法规则类似。例如在 A/B 测试场景下，需要让地域为北京的用户访问 Canary 版本。那么当 cookie 的 annotation 设置为 nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing"，此时后台可对登录的用户请求进行检查，如果该用户访问源来自北京则设置 cookie users_from_Beijing 的值为 always，这样就可以确保北京的用户仅访问 Canary 版本。

同样我们更新 Canary 版本的 Ingress 资源对象，采用基于 Cookie 来进行流量切分，

1. annotations:
2. nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制，首先需要启用 Canary
3. nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing" # 基于 cookie
4. nginx.ingress.kubernetes.io/canary-weight: "30" # 会被忽略，因为配置了 canary-by-cookie

更新上面的 Ingress 资源对象后，我们在请求中设置一个 users_from_Beijing=always 的 Cookie 值，再次访问应用的域名。

1. ➜ for i in $(seq 1 10); do curl -s -b "users_from_Beijing=always" echo.qikqiak.com | grep "Hostname"; done
2. Hostname: canary-66cb497b7f-48zx4
3. Hostname: canary-66cb497b7f-48zx4
4. Hostname: canary-66cb497b7f-48zx4
5. Hostname: canary-66cb497b7f-48zx4
6. Hostname: canary-66cb497b7f-48zx4
7. Hostname: canary-66cb497b7f-48zx4
8. Hostname: canary-66cb497b7f-48zx4
9. Hostname: canary-66cb497b7f-48zx4
10. Hostname: canary-66cb497b7f-48zx4
11. Hostname: canary-66cb497b7f-48zx4

我们可以看到应用都被路由到了 Canary 版本的应用中去了，如果我们将这个 Cookie 值设置为 never，则不会路由到 Canary 应用中。

HTTPS

如果我们需要用 HTTPS 来访问我们这个应用的话，就需要监听 443 端口了，同样用 HTTPS 访问应用必然就需要证书，这里我们用 openssl 来创建一个自签名的证书：

1. ➜ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com"

然后通过 Secret 对象来引用证书文件：

1. # 要注意证书文件名称必须是 tls.crt 和 tls.key
2. ➜ kubectl create secret tls foo-tls --cert=tls.crt --key=tls.key
3. secret/who-tls created

这个时候我们就可以创建一个 HTTPS 访问应用的：

1. apiVersion: networking.k8s.io/v1
2. kind: Ingress
3. metadata:
4. name: ingress-with-auth
5. annotations:
6. # 认证类型
7. nginx.ingress.kubernetes.io/auth-type: basic
8. # 包含 user/password 定义的 secret 对象名
9. nginx.ingress.kubernetes.io/auth-secret: basic-auth
10. # 要显示的带有适当上下文的消息，说明需要身份验证的原因
11. nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - foo'
12. spec:
13. ingressClassName: nginx
14. tls: # 配置 tls 证书
15. - hosts:
16. - foo.bar.com
17. secretName: foo-tls
18. rules:
19. - host: foo.bar.com
20. http:
21. paths:
22. - path: /
23. pathType: Prefix
24. backend:
25. service:
26. name: my-nginx
27. port:
28. number: 80

除了自签名证书或者购买正规机构的 CA 证书之外，我们还可以通过一些工具来自动生成合法的证书，cert-manager 是一个云原生证书管理开源项目，可以用于在 Kubernetes 集群中提供 HTTPS 证书并自动续期，支持 Let's Encrypt/HashiCorp/Vault 这些免费证书的签发。在 Kubernetes 中，可以通过 Kubernetes Ingress 和 Let's Encrypt 实现外部服务的自动化 HTTPS。

TCP与UDP

由于在 Ingress 资源对象中没有直接对 TCP 或 UDP 服务的支持，要在 ingress-nginx 中提供支持，需要在控制器启动参数中添加 --tcp-services-configmap 和 --udp-services-configmap 标志指向一个 ConfigMap，其中的 key 是要使用的外部端口，value 值是使用格式 ::[PROXY]:[PROXY] 暴露的服务，端口可以使用端口号或者端口名称，最后两个字段是可选的，用于配置 PROXY 代理。

比如现在我们要通过 ingress-nginx 来暴露一个 MongoDB 服务，首先创建如下的应用：

1. # mongo.yaml
2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5. name: mongo
6. labels:
7. app: mongo
8. spec:
9. selector:
10. matchLabels:
11. app: mongo
12. template:
13. metadata:
14. labels:
15. app: mongo
16. spec:
17. volumes:
18. - name: data
19. emptyDir: {}
20. containers:
21. - name: mongo
22. image: mongo:4.0
23. ports:
24. - containerPort: 27017
25. volumeMounts:
26. - name: data
27. mountPath: /data/db
28. ---
29. apiVersion: v1
30. kind: Service
31. metadata:
32. name: mongo
33. spec:
34. selector:
35. app: mongo
36. ports:
37. - port: 27017

直接创建上面的资源对象：

1. ➜ kubectl apply -f mongo.yaml
2. ➜ kubectl get svc
3. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
4. mongo ClusterIP 10.98.117.228 27017/TCP 2m26s
5. ➜ kubectl get pods -l app=mongo
6. NAME READY STATUS RESTARTS AGE
7. mongo-84c587f547-gd7pv 1/1 Running 0 2m5s

现在我们要通过 ingress-nginx 来暴露上面的 MongoDB 服务，我们需要创建一个如下所示的 ConfigMap：

1. apiVersion: v1
2. kind: ConfigMap
3. metadata:
4. name: tcp-services
5. namespace: ingress-nginx
6. data:
7. "27017": default/mongo:27017

然后在 ingress-nginx 的启动参数中添加 --tcp-services-configmap=$(POD_NAMESPACE)/ingress-nginx-tcp 这样的配置即可，由于我们这里使用的是 Helm Chart 进行安装的，我们只需要去覆盖 Values 值重新安装即可，修改 ci/daemonset-prod.yaml 文件：

1. # ci/daemonset-prod.yaml
2. # ...... 其他部分省略，和之前的保持一致
3.  
4. tcp: # 配置 tcp 服务
5. 27017: "default/mongo:27017" # 使用 27017 端口去映射 mongo 服务
6. # 9000: "default/test:8080" # 如果还需要暴露其他 TCP 服务，继续添加即可

配置完成后重新更新当前的 ingress-nginx：

1. ➜ helm upgrade --install ingress-nginx . -f ./ci/daemonset-prod.yaml --namespace ingress-nginx

重新部署完成后会自动生成一个名为 ingress-nginx-tcp 的 ConfigMap 对象，如下所示：

1. ➜ kubectl get configmap -n ingress-nginx ingress-nginx-tcp -o yaml
2. apiVersion: v1
3. data:
4. "27017": default/mongo:27017
5. kind: ConfigMap
6. metadata:
7. ......
8. name: ingress-nginx-tcp
9. namespace: ingress-nginx

在 ingress-nginx 的启动参数中也添加上 --tcp-services-configmap=$(POD_NAMESPACE)/ingress-nginx-tcp 这样的配置：

1. ➜ kubectl get pods -n ingress-nginx
2. NAME READY STATUS RESTARTS AGE
3. ingress-nginx-controller-gc582 1/1 Running 0 5m17s
4. ➜ kubectl get pod ingress-nginx-controller-gc582 -n ingress-nginx -o yaml
5. apiVersion: v1
6. kind: Pod
7. ......
8. containers:
9. - args:
10. - /nginx-ingress-controller
11. - --default-backend-service=$(POD_NAMESPACE)/ingress-nginx-defaultbackend
12. - --election-id=ingress-controller-leader
13. - --controller-class=k8s.io/ingress-nginx
14. - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
15. - --tcp-services-configmap=$(POD_NAMESPACE)/ingress-nginx-tcp # tcp 配置参数
16. - --validating-webhook=:8443
17. - --validating-webhook-certificate=/usr/local/certificates/cert
18. - --validating-webhook-key=/usr/local/certificates/key
19. ......
20. ports:
21. ......
22. - containerPort: 27017
23. hostPort: 27017
24. name: 27017-tcp
25. protocol: TCP
26. ......

现在我们就可以通过 ingress-nginx 暴露的 27017 端口去访问 Mongo 服务了：

1. ➜ mongo --host 192.168.31.31 --port 27017
2. MongoDB shell version v4.0.3
3. connecting to: mongodb://192.168.31.31:27017/
4. Implicit session: session { "id" : UUID("10f462eb-32b8-443b-ad85-99820db1aaa0") }
5. MongoDB server version: 4.0.27
6. ......
7.  
8. > show dbs
9. admin 0.000GB
10. config 0.000GB
11. local 0.000GB
12. >

同样的我们也可以去查看最终生成的 nginx.conf 配置文件：

1. ➜ kubectl exec -it ingress-nginx-controller-gc582 -n ingress-nginx -- cat /etc/nginx/nginx.conf
2. ......
3. stream {
4. ......
5. # TCP services
6. server {
7. preread_by_lua_block {
8. ngx.var.proxy_upstream_name="tcp-default-mongo-27017";
9. }
10. listen 27017;
11. listen [::]:27017;
12. proxy_timeout 600s;
13. proxy_next_upstream on;
14. proxy_next_upstream_timeout 600s;
15. proxy_next_upstream_tries 3;
16. proxy_pass upstream_balancer;
17. }
18. # UDP services
19. }

TCP 相关的配置位于 stream 配置块下面。从 Nginx 1.9.13 版本开始提供 UDP 负载均衡，同样我们也可以在 ingress-nginx 中来代理 UDP 服务，比如我们可以去暴露 kube-dns 的服务，同样需要创建一个如下所示的 ConfigMap：

1. apiVersion: v1
2. kind: ConfigMap
3. metadata:
4. name: udp-services
5. namespace: ingress-nginx
6. data:
7. 53: "kube-system/kube-dns:53"

然后需要在 ingress-nginx 参数中添加一个 - --udp-services-configmap=$(POD_NAMESPACE)/udp-services 这样的配置，当然我们这里只需要去修改 Values 文件值即可，修改 ci/daemonset-prod.yaml 文件：

1. # ci/daemonset-prod.yaml
2. # ...... 其他部分省略，和之前的保持一致
3.  
4. tcp: # 配置 tcp 服务
5. 27017: "default/mongo:27017" # 使用 27017 端口去映射 mongo 服务
6. # 9000: "default/test:8080" # 如果还需要暴露其他 TCP 服务，继续添加即可
7.  
8. udp: # 配置 udp 服务
9. 53: "kube-system/kube-dns:53"

然后重新更新即可。

全局配置

除了可以通过 annotations 对指定的 Ingress 进行定制之外，我们还可以配置 ingress-nginx 的全局配置，在控制器启动参数中通过标志 --configmap 指定了一个全局的 ConfigMap 对象，我们可以将全局的一些配置直接定义在该对象中即可：

1. containers:
2. - args:
3. - /nginx-ingress-controller
4. - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
5. ......

比如这里我们用于全局配置的 ConfigMap 名为 ingress-nginx-controller：

1. ➜ kubectl get configmap -n ingress-nginx
2. NAME DATA AGE
3. ingress-nginx-controller 1 5d2h

比如我们可以添加如下所示的一些常用配置：

1. ➜ kubectl edit configmap ingress-nginx-controller -n ingress-nginx
2. apiVersion: v1
3. data:
4. allow-snippet-annotations: "true"
5. client-header-buffer-size: 32k # 注意不是下划线
6. client-max-body-size: 5m
7. use-gzip: "true"
8. gzip-level: "7"
9. large-client-header-buffers: 4 32k
10. proxy-connect-timeout: 11s
11. proxy-read-timeout: 12s
12. keep-alive: "75" # 启用keep-alive，连接复用，提高QPS
13. keep-alive-requests: "100"
14. upstream-keepalive-connections: "10000"
15. upstream-keepalive-requests: "100"
16. upstream-keepalive-timeout: "60"
17. disable-ipv6: "true"
18. disable-ipv6-dns: "true"
19. max-worker-connections: "65535"
20. max-worker-open-files: "10240"
21. kind: ConfigMap
22. ......

修改完成后 Nginx 配置会自动重载生效，我们可以查看 nginx.conf 配置文件进行验证：

1. ➜ kubectl exec -it ingress-nginx-controller-gc582 -n ingress-nginx -- cat /etc/nginx/nginx.conf |grep large_client_header_buffers
2. large_client_header_buffers 4 32k;

由于我们这里是 Helm Chart 安装的，为了保证重新部署后配置还在，我们同样需要通过 Values 进行全局配置：

1. # ci/daemonset-prod.yaml
2. controller:
3. config:
4. allow-snippet-annotations: "true"
5. client-header-buffer-size: 32k # 注意不是下划线
6. client-max-body-size: 5m
7. use-gzip: "true"
8. gzip-level: "7"
9. large-client-header-buffers: 4 32k
10. proxy-connect-timeout: 11s
11. proxy-read-timeout: 12s
12. keep-alive: "75" # 启用keep-alive，连接复用，提高QPS
13. keep-alive-requests: "100"
14. upstream-keepalive-connections: "10000"
15. upstream-keepalive-requests: "100"
16. upstream-keepalive-timeout: "60"
17. disable-ipv6: "true"
18. disable-ipv6-dns: "true"
19. max-worker-connections: "65535"
20. max-worker-open-files: "10240"
21.  
22. # 其他省略

此外往往我们还需要对 ingress-nginx 部署的节点进行性能优化，修改一些内核参数，使得适配 Nginx 的使用场景，一般我们是直接去修改节点上的内核参数，为了能够统一管理，我们可以使用 initContainers 来进行配置：

1. initContainers:
2. - command:
3. - /bin/sh
4. - -c
5. - |
6. mount -o remount rw /proc/sys
7. sysctl -w net.core.somaxconn=65535 # 具体的配置视具体情况而定
8. sysctl -w net.ipv4.tcp_tw_reuse=1
9. sysctl -w net.ipv4.ip_local_port_range="1024 65535"
10. sysctl -w fs.file-max=1048576
11. sysctl -w fs.inotify.max_user_instances=16384
12. sysctl -w fs.inotify.max_user_watches=524288
13. sysctl -w fs.inotify.max_queued_events=16384
14. image: busybox
15. imagePullPolicy: IfNotPresent
16. name: init-sysctl
17. securityContext:
18. capabilities:
19. add:
20. - SYS_ADMIN
21. drop:
22. - ALL
23. ......

由于我们这里使用的是 Helm Chart 安装的 ingress-nginx，同样只需要去配置 Values 值即可，模板中提供了对 initContainers 的支持，配置如下所示：

1. controller:
2. # 其他省略，配置 initContainers
3. extraInitContainers:
4. - name: init-sysctl
5. image: busybox
6. securityContext:
7. capabilities:
8. add:
9. - SYS_ADMIN
10. drop:
11. - ALL
12. command:
13. - /bin/sh
14. - -c
15. - |
16. mount -o remount rw /proc/sys
17. sysctl -w net.core.somaxconn=65535 # socket监听的backlog上限
18. sysctl -w net.ipv4.tcp_tw_reuse=1 # 开启重用，允许将 TIME-WAIT sockets 重新用于新的TCP连接
19. sysctl -w net.ipv4.ip_local_port_range="1024 65535"
20. sysctl -w fs.file-max=1048576
21. sysctl -w fs.inotify.max_user_instances=16384
22. sysctl -w fs.inotify.max_user_watches=524288
23. sysctl -w fs.inotify.max_queued_events=16384

同样重新部署即可：

1. ➜ helm upgrade --install ingress-nginx . -f ./ci/daemonset-prod.yaml --namespace ingress-nginx

部署完成后通过 initContainers 就可以修改节点内核参数了，生产环境建议对节点内核参数进行相应的优化。

原文链接：https://mp.weixin.qq.com/s/XoUaW-vBtQFxwNM3UdD8QA