在此我们不讲述如何部署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.ct99.cn
secretName: ct99.cn
rules:
- host: nginx-a.ct99.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 ct99.cn --cert=1592339__ct99.cn.pem --key=1592339__ct99.cn.key -n test
tls:
- hosts: #此为固定项,是一个列表,我们可以有另外的证书对应其它域名
- nginx-a.ct99.cn #此为列表,必须为一个域名,一个secret可以对多个域名
secretName: ct99.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.ct99.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.ct99.cn
secretName: ct99.cn
rules:
- host: nginx-a.ct99.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.ct99.cn
secretName: ct99.cn
rules:
- host: nginx-a.ct99.cn
http:
paths:
- path: /v1/tfs
backend:
serviceName: nginx-a
servicePort: 80
上面的方法也是官方的方法,使用“nginx.ingress.kubernetes.io/rewrite-target
”来定义。通过上面的的定义代表如果访问https://nginx-a.ct99.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.ct99.cn
secretName: ct99.cn
rules:
- host: nginx-a.ct99.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启动多少时候后开始执行健康检查,单位为秒