@@ -4,7 +4,7 @@ content_type: concept
4
4
description : >-
5
5
使用一种能感知协议配置的机制来理解 URI、主机名称、路径和更多 Web 概念,使得 HTTP(或 HTTPS)网络服务可用。
6
6
Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同的后端。
7
- weight : 20
7
+ weight : 30
8
8
---
9
9
<!--
10
10
reviewers:
@@ -16,7 +16,7 @@ description: >-
16
16
mechanism, that understands web concepts like URIs, hostnames, paths, and more.
17
17
The Ingress concept lets you map traffic to different backends based on rules you define
18
18
via the Kubernetes API.
19
- weight: 20
19
+ weight: 30
20
20
-->
21
21
22
22
<!-- overview -->
@@ -199,7 +199,7 @@ Each HTTP rule contains the following information:
199
199
load balancer directs traffic to the referenced Service.
200
200
* A backend is a combination of Service and port names as described in the
201
201
[Service doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
202
- Ingress that matches the host and path of the rule are sent to the listed backend.
202
+ Ingress that match the host and path of the rule are sent to the listed backend.
203
203
-->
204
204
* 可选的 ` host ` 。在此示例中,未指定 ` host ` ,因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。
205
205
如果提供了 ` host ` (例如 foo.bar.com),则 ` rules ` 适用于该 ` host ` 。
@@ -234,8 +234,8 @@ routed to your default backend.
234
234
没有设置规则的 Ingress 将所有流量发送到同一个默认后端,而
235
235
` .spec.defaultBackend ` 则是在这种情况下处理请求的那个默认后端。
236
236
` defaultBackend ` 通常是
237
- [ Ingress 控制器] ( /zh-cn/docs/concepts/services-networking/ingress-controllers ) 的配置选项,而非在
238
- Ingress 资源中指定。
237
+ [ Ingress 控制器] ( /zh-cn/docs/concepts/services-networking/ingress-controllers ) 的配置选项,
238
+ 而非在 Ingress 资源中指定。
239
239
如果未设置任何的 ` .spec.rules ` ,那么必须指定 ` .spec.defaultBackend ` 。
240
240
如果未设置 ` defaultBackend ` ,那么如何处理所有与规则不匹配的流量将交由
241
241
Ingress 控制器决定(请参考你的 Ingress 控制器的文档以了解它是如何处理那些流量的)。
@@ -318,7 +318,7 @@ Ingress 中的每个路径都需要有对应的路径类型(Path Type)。未
318
318
319
319
* ` Prefix ` :基于以 ` / ` 分隔的 URL 路径前缀匹配。匹配区分大小写,并且对路径中的元素逐个完成。
320
320
路径元素指的是由 ` / ` 分隔符分隔的路径中的标签列表。
321
- 如果每个 _ p _ 都是请求路径 _ p _ 的元素前缀,则请求与路径 _ p _ 匹配。
321
+ 如果每个 ** p ** 都是请求路径 ** p ** 的元素前缀,则请求与路径 ** p ** 匹配。
322
322
323
323
{{< note >}}
324
324
如果路径的最后一个元素是请求路径中最后一个元素的子字符串,则不会匹配
@@ -396,8 +396,8 @@ equal to the suffix of the wildcard rule.
396
396
-->
397
397
## 主机名通配符 {#hostname-wildcards}
398
398
399
- 主机名可以是精确匹配(例如“` foo.bar.com ` ”)或者使用通配符来匹配
400
- (例如“` *.foo.com ` ”)。
399
+ 主机名可以是精确匹配(例如 “` foo.bar.com ` ”)或者使用通配符来匹配
400
+ (例如 “` *.foo.com ` ”)。
401
401
精确匹配要求 HTTP ` host ` 头部字段与 ` host ` 字段值完全匹配。
402
402
通配符匹配则要求 HTTP ` host ` 头部字段与通配符规则中的后缀部分相同。
403
403
@@ -471,8 +471,8 @@ For example:
471
471
IngressClass 的参数默认是集群范围的。
472
472
473
473
如果你设置了 ` .spec.parameters ` 字段且未设置 ` .spec.parameters.scope `
474
- 字段,或是将 ` .spec.parameters.scope ` 字段设为了 ` Cluster ` ,那么该
475
- IngressClass 所指代的即是一个集群作用域的资源。
474
+ 字段,或是将 ` .spec.parameters.scope ` 字段设为了 ` Cluster ` ,
475
+ 那么该 IngressClass 所指代的即是一个集群作用域的资源。
476
476
参数的 ` kind ` (和 ` apiGroup ` 一起)指向一个集群作用域的
477
477
API(可能是一个定制资源(Custom Resource)),而它的
478
478
` name ` 则为此 API 确定了一个具体的集群作用域的资源。
@@ -578,8 +578,8 @@ never formally defined, but was widely supported by Ingress controllers.
578
578
-->
579
579
# ## 废弃的注解 {#deprecated-annotation}
580
580
581
- 在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前,Ingress
582
- 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。
581
+ 在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前,
582
+ Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。
583
583
这个注解从未被正式定义过,但是得到了 Ingress 控制器的广泛支持。
584
584
585
585
<!--
@@ -649,7 +649,7 @@ There are existing Kubernetes concepts that allow you to expose a single Service
649
649
# ## 由单个 Service 来完成的 Ingress {#single-service-ingress}
650
650
651
651
现有的 Kubernetes 概念允许你暴露单个 Service (参见[替代方案](#alternatives))。
652
- 你也可以通过指定无规则的 * 默认后端* 来对 Ingress 进行此操作。
652
+ 你也可以通过指定无规则的** 默认后端** 来对 Ingress 进行此操作。
653
653
654
654
{{< codenew file="service/networking/test-ingress.yaml" >}}
655
655
@@ -767,7 +767,7 @@ Name-based virtual hosts support routing HTTP traffic to multiple host names at
767
767
The following Ingress tells the backing load balancer to route requests based on
768
768
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
769
769
-->
770
- 以下 Ingress 让后台负载均衡器基于[ host 头部字段] ( https://tools.ietf.org/html/rfc7230#section-5.4 )
770
+ 以下 Ingress 让后台负载均衡器基于 [ host 头部字段] ( https://tools.ietf.org/html/rfc7230#section-5.4 )
771
771
来路由请求。
772
772
773
773
{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
@@ -1034,7 +1034,7 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
1034
1034
* Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
1035
1035
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
1036
1036
-->
1037
- * 进一步了解 [ Ingress] ( /docs/reference/kubernetes-api/service-resources/ingress-v1/ ) API
1037
+ * 进一步了解 [ Ingress] ( /zh-cn/ docs/reference/kubernetes-api/service-resources/ingress-v1/ ) API
1038
1038
* 进一步了解 [ Ingress 控制器] ( /zh-cn/docs/concepts/services-networking/ingress-controllers/ )
1039
1039
* [ 使用 NGINX 控制器在 Minikube 上安装 Ingress] ( /zh-cn/docs/tasks/access-application-cluster/ingress-minikube/ )
1040
1040
0 commit comments