K8s Ingress Nginx use

Here we do not describe how to deploy ingress-controller, only demonstrate how to use nginx of ingress. It mainly demonstrates how to use ingress nginx to realize the diversified configuration of our nginx, so as to achieve the same convenience as using ingress nginx as manual deployment of nginx. Here are the following cases for explanation:

1. Case 1 (Basic forwarding, basic use of https configuration and annotations)

2. Case 2 (Personalized configuration of nginx through annotations)

3. Case 3 (Basic rewrite configuration through annotations)

4. Case 4 (Introduce how to use nginx.ingress.kubernetes.io/server-snippet)

5. Case 5 (Use configMap to do more personalized configuration)

Case 1 (the simplest basic configuration):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-a
          servicePort: 80
      - path: /.*.(txt|css|doc)
        backend:
          serviceName: nginx-b
          servicePort: 80
      - path: /(api|app)/
        backend:
          serviceName: nginx-c
          servicePort: 80
      - path: /api
        backend:
          serviceName: nginx-d
          servicePort: 80

We defined an ingress above and specified it to run in the test namespace (this namespace needs to be created by yourself). For the backend, we define four groups of services, namely: nginx-a, nginx-b, nginx-c and nginx-d, and specify the service port as 80 (these four groups of services also need to be defined by themselves).

Then in the main configuration of our ingress, we define the tls certificate, and specify the usable host and the secret to be used. We import the certificate into the secret first, and then directly quote the secret, the import method is as follows:

kubectl create secret tls gogen.cn --cert=1592339__gogen.cn.pem --key=1592339__gogen.cn.key -n test

tls:
- hosts:                        #此为固定项，是一个列表，我们可以有另外的证书对应其它域名
  - nginx-a.gogen.cn            #此为列表，必须为一个域名，一个secret可以对多个域名
  secretName: gogen.cn          #创建secret时指定的名称

annotations configuration: acting on the server

# 指定了我们使用后端ingress controller的类别，如果后端有多个ingress controller的时候很重要
kubernetes.io/ingress.class: "nginx"
 
# 指定我们的rules的path可以使用正则表达式，如果我们没有使用正则表达式，此项则可不使用
nginx.ingress.kubernetes.io/use-regex: "true"

Rules configuration: acting on location

rules:
- host: nginx-a.gogen.cn            #相当于定义了nginx的一个server_name
  http:
    paths:
    - path: /                       #一个path就相当于一个location，path的值必须为“/”。这里为匹配的规则，根表示默认请求转发规则
      backend:
        serviceName: nginx-a        #定义后端的service
        servicePort: 80             #定义后端service的访问端口，也就是service port指定的端口
    - path: /.*.(txt|css|doc)        #这里使用的正则（低版本不支持）,默认情况下都是不区分大小写，可以进入到ingress controller查看nginx的配置,这里相当于把结尾为txt,css,doc的url请求转发到nginx-b service
      backend:
        serviceName: nginx-b
        servicePort: 80
    - path: /(api|app)/              #这里相当于将api和app开头的目录语法转发至nginx-c service
      backend:
        serviceName: nginx-c
        servicePort: 80
    - path: /api                    #这里相当于将api开头的url（可以是一个文件，也可以是一个目录）的请求，转发到nginx-d
      backend:
        serviceName: nginx-d
        servicePort: 80

Note: All paths defined above to ingress controller will be converted into nginx location rules, so the priority of location is the same as nginx. After the path is converted to nginx, the longest path rule will be ranked first, and the shortest rule will be ranked last .

Case 2 (modify some parameters):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-a
          servicePort: 80
      - path: /.*.(txt|css|doc)
        backend:
          serviceName: nginx-b
          servicePort: 80
      - path: /(api|app)/
        backend:
          serviceName: nginx-c
          servicePort: 80
      - path: /api
        backend:
          serviceName: nginx-d
          servicePort: 80

On the basis of case 1, we have added some configurations of annotations

kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/use-regex: "true"
 
#连接超时时间，默认为5s
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
 
#后端服务器回转数据超时时间，默认为60s
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
 
#后端服务器响应超时时间，默认为60s
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
 
#客户端上传文件，最大大小，默认为20m
nginx.ingress.kubernetes.io/proxy-body-size: "10m"

Above we have customized four basic configurations, we can also define more basic configurations, please refer to nginx-configuration annotations related documents

Case 3 (rewrite rewrite one):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-rewrite-tfs
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: https://gogen-test.oss-cn-hangzhou.aliyuncs.com
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /v1/tfs
        backend:
          serviceName: nginx-a
          servicePort: 80

The above method is also the official method, using "nginx.ingress.kubernetes.io/rewrite-target" to define. The definition above means that if you visit https://nginx-a.gogen.cn/v1/tfs/(.*), it will be rewrite to https://gogen-test.oss-cn-hangzhou.aliyuncs.com /$1, if there are multiple paths, each will be rewrite, so if you only need to replace a single path (that is, location), use a single manifest to write. I personally feel that this should not be the case here. The research is not thorough. Please point out if there is a problem.

Case 3 (rewrite rewrite two):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/server-snippet: |
        if ($uri ~* "/v1/tfs/.*") {
    
    
            rewrite ^/v1/tfs/(.*)$ https://gogen-test.oss-cn-hangzhou.aliyuncs.com/$1 permanent;
        }
spec:
  tls:
  - hosts:
    - nginx-a.gogen.cn
    secretName: gogen.cn
  rules:
  - host: nginx-a.gogen.cn
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-a
          servicePort: 80
      - path: /.*.(txt|css|doc)
        backend:
          serviceName: nginx-b
          servicePort: 80
      - path: /(api|app)/
        backend:
          serviceName: nginx-c
          servicePort: 80
      - path: /api
        backend:
          serviceName: nginx-d
          servicePort: 80

Here directly use "nginx.ingress.kubernetes.io/server-snippet" to specify the configuration, here you can write the nginx configuration directly, through this you can not only achieve rewrite rewrite, but also achieve more functional requirements, as long as it is Can act on the server

Case 5 (using configMap):

Sometimes we cannot fully implement our nginx flexible and personalized configuration using annotations. At this time, we need to use configMap configuration. Official configMap use document , annotations and configMap comparison table

First create a configMap file as shown below:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration
  namespace: kube-system
data:
  use-http2: "false"
  ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2"
  ssl-ciphers: "HIGH:!RC4:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!EXP:+MEDIUM"

 For the content in data, please refer to the [Official configMap usage document] given above. The name and namespace in the metadata cannot be written at will. You need to refer to the configuration of the nginx-ingress-controller YAML configuration file.

 containers:
      - args:
        - /nginx-ingress-controller
        - --configmap=$(POD_NAMESPACE)/nginx-configuration
        - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
        - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
        - --annotations-prefix=nginx.ingress.kubernetes.io
        - --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb
        - --v=2

Refer to "- --configmap=$(POD_NAMESPACE)/nginx-configuration)", where the namespace of configmap needs to be in the same namespace as nginx-ingress-controller, and the name is the name after "/"

After completing the configuration, apply the configuration list. The configuration applied through configMap cannot take effect directly. You need to restart the pods. The easiest way is to use edit to edit the controller of nginx-ingress-controller and change the parameters that do not affect the operation of pods to trigger pods upgrade. So that our configuration takes effect, such as:

livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1

You can change "initialDelaySeconds" to 11 or other. The meaning of this value is how long the pod will start to perform the health check, in seconds

 

https://blog.51cto.com/270142877/2338348

Here we do not describe how to deploy ingress-controller, only demonstrate how to use nginx of ingress. It mainly demonstrates how to use ingress nginx to realize the diversified configuration of our nginx, so as to achieve the same convenience as using ingress nginx as manual deployment of nginx. Here are the following cases for explanation: