ingress-annotatons

作者: 窥识 | 来源:发表于2019-11-26 04:04 被阅读0次

ingress-annotatons

名词解析：上游服务器-----提供给外面服务的服务器集群（如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

网友评论

本文标题：ingress-annotatons

本文链接：https://www.haomeiwen.com/subject/oiadwctx.html

延伸阅读

深度阅读

您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！

ingress-annotatons

相关文章