名词解析:上游服务器-----提供给外面服务的服务器集群(如nginx+tomcat,tomcat为上有服务器)
Ingress-nginx安装和部署参考网站:https://www.cnblogs.com/panwenbin-logs/p/9915927.html
待完善
实例1: session 有下面几种参数(测试了下面的yaml文件 ok)
1、nginx.ingress.kubernetes.io/affinity: “cookie” 设置关联项(nginx只支持cookie)
2、nginx.ingress.kubernetes.io/affinity-mode:"balanced or persistent" 需要扩展pod的时候需要启用,balanced(平衡)会重新分配某些会话,persistent(持久)能以最大程度保持会话粘性
3、nginx.ingress.kubernetes.io/session-cookie-name:“str”设置cookie的名称,默认INGRESSCOOKIE
4、nginx.ingress.kubernetes.io/session-cookie-path: “str”在cookie上设置路径(如果ingress位正则表达式的路径则必选该注释)
5、nginx.ingress.kubernetes.io/session-cookie-max-age: “number”设置cookie的过期时间
6、nginx.ingress.kubernetes.io/session-cookie-expires “number”设置cookie过期时间(为了与旧版浏览器兼容,和5可也同时设置)
7、nginx.ingress.kubernetes.io/session-cookie-change-on-failure: “true or false” 当访问cookie指向的服务失败时的处理方式。(true:指向另一个pod服务;false:还是原来的pod服务)
yaml文件
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-test
annotations:
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "route"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- backend:
serviceName: <service-name>
servicePort: <service-port>
path: /
通过 curl -I rewrite.bar.com 可也看到一个返回头中含有set-cookie: route=……(或者直接通过浏览器也能查看到)
实例2:给访问加认证(需要通过输入账号密码访问)(测试ok)
有下面几个参数:
nginx.ingress.kubernetes.io/auth-type: “basic or digest” 定义验证类型
nginx.ingress.kubernetes.io/auth-secret: secretname 包含用户名和密码的一个secret(还可也写成namespace/secretname)
nginx.ingress.kubernetes.io/auth-secret-type: [auth-file|auth-map] 包含用户名和密码的一个文件
nginx.ingress.kubernetes.io/auth-realm: "realm string"
1、创建用户密码,执行下面命令会生成一个存放用户和密码的auth文件(添加用户时不用加-c参数)
htpasswd -c auth user1
New password:
Re-type new password:
Adding password for user user1
htpasswd auth user2
New password:
Re-type new password:
Adding password for user user2
[root@swarm-worker1 ~]# htpasswd -c auth user1
New password:
Re-type new password:
Adding password for user user1
[root@swarm-worker1 ~]# htpasswd auth user2
New password:
Re-type new password:
Adding password for user user2
[root@swarm-worker1 ~]# cat auth
user1:$apr1$/uHEcNGg$/FoE85bQ/Uxntr1RYvw0Z1
user2:$apr1$SUl9Dquw$pvdxcHzXVM63yt/RgEjZF.
2、根据生成的auth文件生成 secret
kubectl create secret generic secret-auth --from-file=auth -n <namespace>
3、yaml文件----apply之后通过域名访问
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: auth-secret
annotations:
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: secret-auth
nginx.ingress.kubernetes.io/auth-realm: "Authentication Required - foo"
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service-port>
测试:通过浏览器测试,输入rewrite.bar.com会要求输入用户名和密码。
实例3:客户端证书验证
nginx.ingress.kubernetes.io/auth-tls-secret: "secretName" tls证书的secret名称(也可以写成namespace/secretname)
nginx.ingress.kubernetes.io/auth-tls-verify-depth:“number” 验证深度(提供的客户端证书和颁发证书机构链之间的深度---不是太懂这个意思)
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on or off" 启动客户端证书的验证
nginx.ingress.kubernetes.io/auth-tls-error-page: "url" 如果证书验证错误,重定向给用户的url
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true or false" 确定是否要把接受到的证书发送给上游服务器 (默认关闭)
生成证书的操作步骤:(CA证书必须包含受信任的证书颁发机构链,以验证客户端证书)
1、生成CA密钥和证书
openssl req -x509 -sha256 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 356 -nodes -subj '/CN=My Cert Authority'
2、生成服务器密钥和证书并使用CA证书进行签名:
openssl req -new -newkey rsa:4096 -keyout server.key -out server.csr -nodes -subj '/CN=mydomain.com' -----生成密钥
openssl x509 -req -sha256 -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt -----使用CA证书进行签名并生成证书
3、生成客户端密钥和证书并使用CA证书进行签名:
openssl req -new -newkey rsa:4096 -keyout client.key -out client.csr -nodes -subj '/CN=My Client' -----生成密钥
openssl x509 -req -sha256 -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt -----使用CA证书进行签名并生成证书
4、创建secret
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt ---使用CA证书创建secret
kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key ---使用经过CA签名的服务器证书创建secret
kubectl create secret generic ca-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key --from-file=ca.crt=ca.crt --创建包含CA证书和服务器证书的secret,该secret可同时用于TLS和客户端身份验证。
5、如果您还想启用证书吊销列表验证,则可以创建还包含PEM格式的CRL文件的secret:(不知道啥意思,没用到)
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt --from-file=ca.crl=ca.crl
需要有上面创建的一些证书才能完成下面的验证(测试不成功,后续再测试)
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "ca-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
name: nginx-test
namespace: default
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- backend:
serviceName: service-name
servicePort: service-port
path: /
tls:
- hosts:
- rewrite.bar.com
secretName: tls-secret
实例4: 外部认证 (只做记录,没去实验)
1、nginx.ingress.kubernetes.io/auth-url: "URL to the authentication service" 指定执行外部认证的url
2、nginx.ingress.kubernetes.io/auth-method: <Method> 指定http的方法(get,post,put…..)
3、ginx.ingress.kubernetes.io/auth-signin: <SignIn_URL> 指定错误页面的url
4、nginx.ingress.kubernetes.io/auth-response-headers: <Response_Header_1, ..., Response_Header_n>
5、nginx.ingress.kubernetes.io/auth-proxy-set-headers: <ConfigMap> 6、nginx.ingress.kubernetes.io/auth-request-redirect: <Request_Redirect_URL>
7、nginx.ingress.kubernetes.io/auth-cache-key: <Cache_Key>
8、nginx.ingress.kubernetes.io/auth-cache-duration: <Cache_duration>
9、nginx.ingress.kubernetes.io/auth-snippet: <Auth_Snippet>
实例5:设置全局外部认证:(待验证)
1、默认情况下,如果在NGINX ConfigMap中设置了global-auth-url,则控制器会将所有请求重定向到提供身份验证的现有服务。如果要为该入口禁用此行为,可以在NGINX ConfigMap中使用enable-global-auth:“ false”。
2、如果想要在某一个ingress规则上面不使用,则可也添加如下annotation:
nginx.ingress.kubernetes.io/enable-global-auth: “false” 默认为true
实例6:nginx----后端服务之间的协议设置(待验证)
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" 默认使用http,可使用的协议---
HTTP, HTTPS, GRPC, GRPCS and AJP
实例7:kubernetes基于nginx-ingress进行蓝绿部署/金丝雀发布(canary) (待测试)
使用场景:当你有两组服务时(service1、service2,两个不同的服务比如更新了某些功能)。之前你只需要访问service1,现在你需要将部分流量传入service2这时候便可也启用canary,他会根据你请求的header(key:value) cookie-name:value weight来决定流量转发到那个服务上
参考网站(http://idcsec.com/2019/09/12/kubernetes%E5%9F%BA%E4%BA%8Enginx-ingress%E8%BF%9B%E8%A1%8C%E8%93%9D%E7%BB%BF%E9%83%A8%E7%BD%B2-%E9%87%91%E4%B8%9D%E9%9B%80%E5%8F%91%E5%B8%83canary/)
1、nginx.ingress.kubernetes.io/canary: "true" 开启canary
2、nginx.ingress.kubernetes.io/canary-by-header: "str" 设置接收指定的header(key)
3、nginx.ingress.kubernetes.io/canary-by-header-value: "str" 设置接收指定header(value)
4、nginx.ingress.kubernetes.io/canary-by-cookie: "str" 设置接收指定cookie(key)
5、nginx.ingress.kubernetes.io/canary-weight: "number" 设置权重
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <appName>-canary
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "version"
nginx.ingress.kubernetes.io/canary-by-header-value: "canary"
nginx.ingress.kubernetes.io/canary-by-cookie: "canary-cookie"
nginx.ingress.kubernetes.io/canary-weight: <weight>
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /
backend:
serviceName: service-name
servicePort: service-port
带有 “version: canary” 头的请求都被发送到 canary 版本:curl -H "version: canary" -H "Host:rewrite.bar.com" rewrite.bar.com
不带有 “version: canary” 头的请求会根据权重转发到 canary 版本
cookie 的值为 always 转发给 canary, never不转发
示例:curl -v -b canary-cookie=always rewrite.bar.com # 访问金丝雀版本
示例:curl -v -b canary-cookie=never rewrite.bar.com # 访问非金丝雀版本
优先级:金丝雀规则按优先级进行评估。优先级如下:
canary-by-header-> cookie-by-canary-> canary-weight
限制:每个Ingress规则最多可以应用一个金丝雀入口。
实例7:设置客户端缓存区大小(待验证,不知道具体功能)
nginx.ingress.kubernetes.io/client-body-buffer-size: "1000" # 1000 bytes
nginx.ingress.kubernetes.io/client-body-buffer-size: 1k # 1 kilobyte
nginx.ingress.kubernetes.io/client-body-buffer-size: 1K # 1 kilobyte
nginx.ingress.kubernetes.io/client-body-buffer-size: 1m # 1 megabyte
nginx.ingress.kubernetes.io/client-body-buffer-size: 1M # 1 megabyte
实例8:cors(跨域资源共享)(待验证,不知道具体功能)
nginx.ingress.kubernetes.io/enable-cors: "true" 开启cors
nginx.ingress.kubernetes.io/cors-allow-methods: "method" 允许访问cors的方法(get post put….)
nginx.ingress.kubernetes.io/cors-allow-headers: "str" 允许访问cors的请求头
nginx.ingress.kubernetes.io/cors-allow-origin: "url" 限制需要用到的cors的url(也就是提供cors服务的地址,默认为所有,理解不对)
nginx.ingress.kubernetes.io/cors-allow-credentials: "true or false" 控制在CORS操作期间是否可以传递凭据 (默认true)
nginx.ingress.kubernetes.io/cors-max-age: "number" 控制可以将预检请求缓存多长时间
实例9:https访问
如果集群启动了TLS,则可也启动ssl-passthrough来启动TLS(当然也可也在应用中启动,也可也通过ingress-controller来启动)
1、通过 ssl-passthrough来启动(前提是集群开启了TLS),(该方法不能在后面写路径--待测试)
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <ingress-name>
annotations:
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
tls:
- hosts:
- <yourchoice>.<cluster-id>.k8s.gigantic.io
rules:
- host: <yourchoice>.<cluster-id>.k8s.gigantic.io
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service-port>
2、通过ingress-controller添加tls证书(测试ok)
. 首先需要创建证书和私钥
openssh req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt
--执行该命令后需要填写参数,common name 需要填写你想添加证书的域名,其他随便填(假设域名为tls.bar.com)
. 根据证书和私钥创建ingress的yaml文件锁需要的secret
kubectl create secret tls tls-secret --key tls.key --cert tls.crt -n namespace
创建ingress---(添加解析后直接通过浏览器访问https://tls.bar.com,或者curl -k https:tls.bar.com, -k必须参数表示信任自签名证书,不加报错)
yaml文件
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: tls-test
spec:
tls:
- hosts:
- tls.bar.com
secretName: tls-secret
rules:
- host: tls.bar.com
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service-port>
3、http访问会强制转成https访问方式(测试可也转,但是后端访问不了,报错)
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <ingress-name>
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service-port>
4、如果ingress开启了TLS(表明要用https访问),这时我们访问http://rewrite.bar.com会重定向到308code(308 permanet redirect),这时候如果不想重定向到308,则可也使用ssl-redirect关闭,关闭后访问https://rewrite.bar.com和http://rewrite.bar.com是一样的效果。(测试ok,开启之后http也能访问)
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <ingress-name>
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
tls:
- hosts:
- rewrite.bar.com
secretName: tls-secret
rules:
- host: rewrite.bar.com
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service-port>
实例10:rate limiting (未验证)
Rate limiting:下面这些注释定义了对连接和传输速率的限制。这些可以用来减轻DDoS攻击
nginx.ingress.kubernetes.io/limit-connections: 一个IP地址允许的并发连接数。超出此限制时,将返回503错误。
nginx.ingress.kubernetes.io/limit-rps:每秒从给定IP接受的请求数。突发限制设置为限制的5倍。当客户端超过此限制时,将返回limit-req-status-code默认值:503。
nginx.ingress.kubernetes.io/limit-rpm:每分钟从给定IP接受的请求数。突发限制设置为限制的5倍。当客户端超过此限制时,将返回limit-req-status-code默认值:503
nginx.ingress.kubernetes.io/limit-rate-after:初始字节数限制为千字节,以后连接的响应传输速率将会被限制。
nginx.ingress.kubernetes.io/limit-rate:每秒允许给连接发送 千字节/秒的速率,零值不允许速率限制。
如果在一个Ingress规则中指定多个批注,限制则会按顺序应用限制
实例11:Temporal Redirect(时间重定向,使用场景待考究,已测试)
使用方法:加以下注释-----此注释使您可以返回时间重定向(返回代码302),而不是将数据发送到上游(必须写完整的网址---加https和http否则不生效----验证可也返回302)
nginx.ingress.kubernetes.io/temporal-redirect: https://www.google.com
实例12:使用配置configmap可以为与上游服务器的连接设置默认的全局超时。在某些情况下,要求具有不同的值。为此,我们提供了允许进行自定义的注释-----(待验证)
nginx.ingress.kubernetes.io/proxy-connect-timeout: "600" ---#连接超时时间,默认为5s
nginx.ingress.kubernetes.io/proxy-send-timeout: "600" ---#后端服务器回转数据超时时间,默认为60s
nginx.ingress.kubernetes.io/proxy-read-timeout: "600" ---#后端服务器响应超时时间,默认为60s
nginx.ingress.kubernetes.io/proxy-body-size: "10m" ---#客户端上传文件,最大大小,默认为20m
nginx.ingress.kubernetes.io/proxy-next-upstream:
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout:
nginx.ingress.kubernetes.io/proxy-next-upstream-tries:
nginx.ingress.kubernetes.io/proxy-request-buffering:
实例13:ip限制----白名单(地址以逗号隔开)(测试结果ok)
nginx.ingress.kubernetes.io/whitelist-source-range
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <ingress-name>
annotations:
nginx.ingress.kubernetes.io/whitelist-source-range:
10.0.0.0/24,172.10.0.1
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service1port>
实例14:永久重定向到一个其他地址(测试ok)
nginx.ingress.kubernetes.io/permanent-redirect: www.baidu.com
访问这个ingress的地址rewrite.bar.com将会重定向到百度
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <ingress-name>
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: www.baidu.com
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /
backend:
serviceName: <service-name>
servicePort: <service1port>
实例15:(待验证,验证看不出效果)
nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
将www.domain.com重定向为domain.com,如果在某个时候通过ingress创建了一个新的domain.com则上面的注释自动失效。
实例16:域名路径重写:适用于在某些情况下,后端服务中公开的URL与ingress规则中指定的路径不同。如果不重写的话任何请求都将返回404,为了避免这个情况可也将实际路径写在nginx.ingress.kubernetes.io/rewrite-target 后面 (测试ok)
1、第一种用法,重写路径为/
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: <ingress-name>
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /foo
backend:
serviceName: <service-name>
servicePort: <service1port>
2、第二种用法:是用正则表达式来匹配输入的path,占位符$1,(可也使用nginx.ingress.kubernetes.io/use-regex: "true"来开启不区分大小写的正则表达式,默认关闭)
yaml文件:
[root@swarm-manager ingress]# cat rewrite-target.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$1
name: rewrite
namespace: default
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- path: /foo/(.+)
backend:
serviceName: <service-name>
servicePort: <service1port>
- path: /foo/bar
backend:
serviceName: <service-name>
servicePort: <service1port>
- path: /foo/bar/
backend:
serviceName: <service-name>
servicePort: <service1port>
这时候ingress-controller规则里面将会写入3个规则,三个规则将会降序排列,访问http://rewrite.bar.com/foo/bar/str将会匹配第一个,http://rewrite.bar.com/foo/bar/将会匹配第二个,http://rewrite.bar.com/foo/bar将会匹配第三个。
location ~* "^/foo/bar/.+" {
...
}
location ~* "^/foo/bar/" {
...
}
location ~* "^/foo/bar" {
...
}
3、第三种用法: 使用正则表达式来匹配输入的path,占位符 $2 (测试ok)
yaml文件:
[root@swarm-manager ingress]# cat rewrite-target.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
name: rewrite
namespace: default
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- backend:
serviceName:<service-name>
servicePort: <service-port>
path: /something(/|$)(.*)
这个时候如果你有如下访问将会被被重定向((/|$)(.*)为一个正则表达式,会匹配something后面的所有字符并传递给--$2--占位符):
rewrite.bar.com/something 重定向为 rewrite.bar.com
rewrite.bar.com/something/ 重定向为rewrite.bar.com/
rewrite.bar.com/something/new 重定向为 rewrite.bar.com/new
第四种用法:app-root,如果访问路径的根目录暴露在了其他路径,可也使用app-root来重定向
假设用户程序的根目录在app1而不是/,
yaml文件:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/app-root: /app1
name: rewrite
namespace: default
spec:
rules:
- host: rewrite.bar.com
http:
paths:
- backend:
serviceName: <service-name>
servicePort: <service-port>
path: /
实例17:
同一个域名根据不同的path访问不同的服务:foo.bar.com/foo 访问service1 ; foo.bar.com/bar 访问service2
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
/ bar service2:8080
配置文件:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: simple-fanout-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: / #必须加该annotation否则访问出错
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
serviceName: service1
servicePort: 4200
- path: /bar
backend:
serviceName: service2
servicePort: 8080
实例18:
根据不同的域名访问不同的服务,同一个ingress
foo.bar.com --| |-> foo.bar.com s1:80
| 178.91.123.132 |
bar.foo.com --| |-> bar.foo.com s2:80
yaml文件:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: service1
servicePort: 80
- host: bar.foo.com
http:
paths:
- backend:
serviceName: service2
servicePort: 80
实例19:创建一个ingress-controller的configmap的配置文件(该配置文件为全局配置文件,可与annotation配合使用。configmap设定全局默认值,annotation针对某些ingress需要的特殊功能做定制)
yaml文件:
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"
官方使用方法:https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/configmap.md
configmap和annotation对照表:https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/configmap-and-annotations.md (https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/)
-----待完善
参考网站:
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#service-upstream
名词解析:上游服务器-----提供给外面服务的服务器集群(如nginx+tomcat,tomcat为上有服务器)
Ingress-nginx安装和部署参考网站:https://www.cnblogs.com/panwenbin-logs/p/9915927.html