K8s Ingress Nginx使用

在此我们不讲述如何部署ingress-controller，只演示如何使用ingress之nginx使用。主要演示如何使用ingress nginx实现我们nginx的多样化配置，从而达到使用ingress nginx如同使用手动部署nginx同样的便利。在此使用以下几个案例作讲解：案例1（基本转发，https配置与annotat...

My_Way666

596人浏览 · 2020-09-09 15:43:38

My_Way666 · 2020-09-09 15:43:38 发布

在此我们不讲述如何部署ingress-controller，只演示如何使用ingress之nginx使用。主要演示如何使用ingress nginx实现我们nginx的多样化配置，从而达到使用ingress nginx如同使用手动部署nginx同样的便利。在此使用以下几个案例作讲解：

案例1（基本转发，https配置与annotations基础使用）
案例2（通过annotations对nginx做个性化配置）
案例3（通过annotations做rewrite基本配置）
案例4（介绍 nginx.ingress.kubernetes.io/server-snippet 使用方法）
案例5（使用configMap做更多个性化配置）

案例1（最简单基本配置）：

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

上面我们定义了一个ingress，并指定运行在test名称空间（此名名称空间需要自行创建）。后端我们定义了四组服务，分别为：nginx-a，nginx-b，nginx-c和nginx-d，并指定服务的port为80（这四组服务也需要自行定义）。

然后我们ingress的主要配置里面我们定义了tls证书，并指定可使用的host和需要使用的secret。我们是将证书先导入进secret，然后直接引用secret，导入方法如下：

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配置：作用于server

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

rules配置：作用于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

说明：上面定义的所有path到ingress controller都将会转换成nginx location规则，那么关于location的优先级与nginx一样。path转换到nginx后，会将path规则最长的排在最前面，最短的排在最后面。

案例2（修改某些参数）：

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

在案例1的基础上面我们增加了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"

上面我们自定义了四项基本配置，我们还可以定义更多的基本配置，可参考nginx-configuration annotations相关文档

案例3（rewrite重写一）：

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

上面的方法也是官方的方法，使用“nginx.ingress.kubernetes.io/rewrite-target”来定义。通过上面的的定义代表如果访问https://nginx-a.gogen.cn/v1/tfs/(.*)，则会rewrite为https://gogen-test.oss-cn-hangzhou.aliyuncs.com/$1，如果有多个path，每个都会被rewrite，所以如果只需要替换单个path（也就是location）的时候单独使用个manifests写。这里我个人感觉不应该如此，研究不透彻，如果有问题的地方还请指出

案例3（rewrite重写二）：

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

这里直接使用了“nginx.ingress.kubernetes.io/server-snippet”来指定配置，这里可以直接写nginx的配置，通过这里可以不止是实现rewrite重写，还可以实现更多的功能需求，只要是作用于server的都可以

案例5（configMap使用）：

有些时候我们使用annotations并不能全完实现我们nginx灵活个性化配置，这时候就需要使用借助configMap配置。官方configMap使用文档，annotations与configMap对照关系表

首先创建一个configMap文件，如下所示：

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"

data里面内容参考上面给出的【官方configMap使用文档】，metadata内的 name和namespace不可随意写，需要参考nginx-ingress-controller YAML配置文件的配置

 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

参考”- --configmap=$(POD_NAMESPACE)/nginx-configuration)“，其中configmap的名称空间需要与nginx-ingress-controller在同一个名称空间，名称为”/“后面的名称

完成配置后apply配置清单，通过configMap配置的配置apply无法直接生效，需要重启pods，最简单的方法使用edit编辑nginx-ingress-controller的controller，改个不影响pods运行的参数，来触发pods升级，从而让我们的配置生效，如：

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

可以将”initialDelaySeconds“改为11或者其它的，该值的含义为pod启动多少时候后开始执行健康检查，单位为秒

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

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub