diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index aca161b967..6f409182fd 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -29,9 +29,9 @@ Ingress 控制器不是随集群自动启动的。 基于此页面，你可选择最适合你的集群的 ingress 控制器实现。 Kubernetes 作为一个项目，目前支持和维护 -[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)， -[GCE](https://git.k8s.io/ingress-gce/README.md) -和 [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) Ingress 控制器。 +[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)、 +[GCE](https://git.k8s.io/ingress-gce/README.md) +和 [Nginx](https://git.k8s.io/ingress-nginx/README.md#readme) Ingress 控制器。 @@ -46,32 +46,37 @@ Kubernetes 作为一个项目，目前支持和维护 * [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress controller. +* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller. * [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/). -* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe) is a [BFE](https://www.bfe-networks.net)-based ingress controller. -* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with - Citrix Application Delivery Controller. -* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller. -* [EnRoute](https://getenroute.io/) is an [Envoy](https://www.envoyproxy.io) based API gateway that can run as an ingress controller. --> * [AKS 应用程序网关 Ingress 控制器](https://azure.github.io/application-gateway-kubernetes-ingress/) 是一个配置 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview) 的 Ingress 控制器。 * [Ambassador](https://www.getambassador.io/) API 网关是一个基于 - [Envoy](https://www.envoyproxy.io) 的 Ingress - 控制器。 + [Envoy](https://www.envoyproxy.io) 的 Ingress 控制器。 * [Apache APISIX Ingress 控制器](https://github.com/apache/apisix-ingress-controller) 是一个基于 [Apache APISIX 网关](https://github.com/apache/apisix) 的 Ingress 控制器。 * [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) 使用 [VMware NSX Advanced Load Balancer](https://avinetworks.com/) 提供第 4 到第 7 层的负载均衡。 -* [BFE Ingress 控制器](https://github.com/bfenetworks/ingress-bfe) 是一个基于 [BFE](https://www.bfe-networks.net) 的 Ingress 控制器。 + +* [BFE Ingress 控制器](https://github.com/bfenetworks/ingress-bfe)是一个基于 + [BFE](https://www.bfe-networks.net) 的 Ingress 控制器。 * [Citrix Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller#readme) 可以用来与 Citrix Application Delivery Controller 一起使用。 * [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器。 -* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) API 网关， - 可以作为 Ingress 控制器来执行。 -* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md) 是一个基于 [Easegress](https://megaease.com/easegress/) API 网关，可以作为 Ingress 控制器来执行。 +* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) + 的 API 网关，可以用作 Ingress 控制器。 +* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md) + 是一个基于 [Easegress](https://megaease.com/easegress/) 的 API 网关，可以用作 Ingress 控制器。 +* [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller#readme) + 是一个用来驱动 [Kong Gateway](https://konghq.com/kong/) 的 Ingress 控制器。 +* [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx-ingress-controller/) + 能够与 [NGINX](https://www.nginx.com/resources/glossary/nginx/) + 网页服务器（作为代理）一起使用。 +* [Pomerium Ingress 控制器](https://www.pomerium.com/docs/k8s/ingress.html) + 基于 [Pomerium](https://pomerium.com/)，能提供上下文感知的准入策略。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP + 路由器和反向代理可用于服务组装，支持包括 Kubernetes Ingress + 这类使用场景，是一个用以构造你自己的定制代理的库。 + -* [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller#readme) - 是一个用来驱动 [Kong Gateway](https://konghq.com/kong/) 的 Ingress 控制器。 -* [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx-ingress-controller/) - 能够与 [NGINX](https://www.nginx.com/resources/glossary/nginx/) Web 服务器（作为代理） - 一起使用。 -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP - 路由器和反向代理可用于服务组装，支持包括 Kubernetes Ingress 这类使用场景， - 设计用来作为构造你自己的定制代理的库。 * [Traefik Kubernetes Ingress 提供程序](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) 是一个用于 [Traefik](https://traefik.io/traefik/) 代理的 Ingress 控制器。 * [Tyk Operator](https://github.com/TykTechnologies/tyk-operator) @@ -130,23 +139,31 @@ Kubernetes 作为一个项目，目前支持和维护 ## 使用多个 Ingress 控制器 +你可以使用 +[Ingress 类](/zh/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的 +Ingress 控制器。 +请注意你的 Ingress 类资源的 `.metadata.name` 字段。 +当你创建 Ingress 时，你需要用此字段的值来设置 Ingress 对象的 `ingressClassName` 字段（请参考 +[IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec)）。 +`ingressClassName` +是之前的[注解](/zh/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。 -If you do not define a class, your cloud provider may use a default ingress controller. + - -你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。 -创建 ingress 时，应该使用适当的 -[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) -注解每个 Ingress 以表明在集群中如果有多个 Ingress 控制器时，应该使用哪个 Ingress 控制器。 - -如果不定义 `ingress.class`，云提供商可能使用默认的 Ingress 控制器。 +如果你不为 Ingress 指定一个 IngressClass，并且你的集群中只有一个 IngressClass 被标记为了集群默认，那么 +Kubernetes 会[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)此默认 +IngressClass。 +你可以通过将 +[`ingressclass.kubernetes.io/is-default-class` 注解](/zh/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) +的值设置为 `"true"` 来将一个 IngressClass 标记为集群默认。 理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。 diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md index c1ee7b6078..2a1548d654 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -31,15 +31,14 @@ For clarity, this guide defines the following terms: * Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes [networking model](/docs/concepts/cluster-administration/networking/). * Service: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network. --> -* 节点（Node）: Kubernetes 集群中其中一台工作机器，是集群的一部分。 +* 节点（Node）: Kubernetes 集群中的一台工作机器，是集群的一部分。 * 集群（Cluster）: 一组运行由 Kubernetes 管理的容器化应用程序的节点。 在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。 -* 边缘路由器（Edge router）: 在集群中强制执行防火墙策略的路由器（router）。 - 可以是由云提供商管理的网关，也可以是物理硬件。 -* 集群网络（Cluster network）: 一组逻辑的或物理的连接，根据 Kubernetes - [网络模型](/zh/docs/concepts/cluster-administration/networking/) 在集群内实现通信。 -* 服务（Service）：Kubernetes {{< glossary_tooltip text="服务" term_id="service" >}}使用 - {{< glossary_tooltip text="标签" term_id="label" >}}选择算符（selectors）标识的一组 Pod。 +* 边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关，也可以是物理硬件。 +* 集群网络（Cluster Network）: 一组逻辑的或物理的连接，根据 Kubernetes + [网络模型](/zh/docs/concepts/cluster-administration/networking/)在集群内实现通信。 +* 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}}， + 使用{{< glossary_tooltip text="标签" term_id="label" >}}选择器（selectors）辨认一组 Pod。 除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。 -可以将 Ingress 配置为服务提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及提供基于名称的虚拟主机等能力。 +Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。 Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 -[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport) +[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer) -类型的服务。 +类型的 Service。 ## 环境准备 -你必须具有 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 +你必须拥有一个 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。 - 与所有其他 Kubernetes 资源一样，Ingress 需要使用 `apiVersion`、`kind` 和 `metadata` 字段。 - Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 - 有关使用配置文件的一般信息，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 +与所有其他 Kubernetes 资源一样，Ingress 需要指定 `apiVersion`、`kind` 和 `metadata` 字段。 +Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +关于如何使用配置文件，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 [配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、 [管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。 - Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如 -[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 - 不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) -支持不同的注解。查看文档以供你选择 Ingress 控制器，以了解支持哪些注解。 +Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress +控制器，例如[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 +不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)支持不同的注解。 +查看你所选的 Ingress 控制器的文档，以了解其支持哪些注解。 Ingress [规约](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 提供了配置负载均衡器或者代理服务器所需的所有信息。 最重要的是，其中包含与所有传入请求匹配的规则列表。 -Ingress 资源仅支持用于转发 HTTP 流量的规则。 +Ingress 资源仅支持用于转发 HTTP(S) 流量的规则。 + + +如果 `ingressClassName` 被省略，那么你应该定义一个[默认 Ingress 类](#default-ingress-class)。 + +有一些 Ingress 控制器不需要定义默认的 `IngressClass`。比如：Ingress-NGINX +控制器可以通过[参数](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) +`--watch-ingress-without-class` 来配置。 +不过仍然[推荐](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) +按[下文](#default-ingress-class)所示来设置默认的 `IngressClass`。 -通常在 Ingress 控制器中会配置 `defaultBackend`（默认后端），以服务于任何不符合规约中 `path` 的请求。 +通常在 Ingress 控制器中会配置 `defaultBackend`（默认后端），以服务于无法与规约中 `path` 匹配的所有请求。 -### DefaultBackend {#default-backend} +An Ingress with no rules sends all traffic to a single default backend and `.spec.defaultBackend` +is the backend that should handle requests in that case. +The `defaultBackend` is conventionally a configuration option of the +[Ingress controller](/docs/concepts/services-networking/ingress-controllers) and +is not specified in your Ingress resources. +If no `.spec.rules` are specified, `.spec.defaultBackend` must be specified. +If `defaultBackend` is not set, the handling of requests that do not match any of the rules will be up to the +ingress controller (consult the documentation for your ingress controller to find out how it handles this case). -没有 `rules` 的 Ingress 将所有流量发送到同一个默认后端。 -`defaultBackend` 通常是 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) -的配置选项，而非在 Ingress 资源中指定。 - - -如果 `hosts` 或 `paths` 都没有与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到默认后端。 +### 默认后端 {#default-backend} + +没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而 +`.spec.defaultBackend` 则是在这种情况下处理请求的那个默认后端。 +`defaultBackend` 通常是 +[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的配置选项，而非在 +Ingress 资源中指定。 +如果未设置任何的 `.spec.rules`，那么必须指定 `.spec.defaultBackend`。 +如果未设置 `defaultBackend`，那么如何处理所有与规则不匹配的流量将交由 +Ingress 控制器决定（请参考你的 Ingress 控制器的文档以了解它是如何处理那些流量的）。 + +如果没有 `hosts` 或 `paths` 与 Ingress 对象中的 HTTP 请求匹配，则流量将被路由到默认后端。 ### 资源后端 {#resource-backend} -`Resource` 后端是一个 `ObjectRef`，指向同一名字空间中的另一个 -Kubernetes，将其作为 Ingress 对象。`Resource` 与 `Service` 配置是互斥的，在 -二者均被设置时会无法通过合法性检查。 +`Resource` 后端是一个引用，指向同一命名空间中的另一个 Kubernetes 资源，将其作为 Ingress 对象。 +`Resource` 后端与 Service 后端是互斥的，在二者均被设置时会无法通过合法性检查。 `Resource` 后端的一种常见用法是将所有入站数据导向带有静态资产的对象存储后端。 {{< codenew file="service/networking/ingress-resource-backend.yaml" >}} @@ -410,41 +437,140 @@ IngressClass 资源包含额外的配置，其中包括应当实现该类的控 {{< codenew file="service/networking/external-lb.yaml" >}} -IngressClass 资源包含一个可选的 `parameters` 字段，可用于为该类引用额外的、 -特定于具体实现的配置。 +IngressClass 中的 `.spec.parameters` 字段可用于引用其他资源以提供额外的相关配置。 + +参数（`parameters`）的具体类型取决于你在 `.spec.controller` 字段中指定的 Ingress 控制器。 -#### 名字空间域的参数 +### IngressClass scope -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +Depending on your ingress controller, you may be able to use parameters +that you set cluster-wide, or just for one namespace. +--> +### IngressClass 的作用域 + +取决于你的 Ingress 控制器，你可能可以使用集群范围设置的参数或某个名字空间范围的参数。 + +{{< tabs name="tabs_ingressclass_parameter_scope" >}} +{{% tab name="集群作用域" %}} + +IngressClass 的参数默认是集群范围的。 + +如果你设置了 `.spec.parameters` 字段且未设置 `.spec.parameters.scope` +字段，或是将 `.spec.parameters.scope` 字段设为了 `Cluster`，那么该 +IngressClass 所指代的即是一个集群作用域的资源。 +参数的 `kind`（和 `apiGroup` 一起）指向一个集群作用域的 +API（可能是一个定制资源（Custom Resource）），而它的 +`name` 则为此 API 确定了一个具体的集群作用域的资源。 + +示例： +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-1 +spec: + controller: example.com/ingress-controller + parameters: + # 此 IngressClass 的配置定义在一个名为 “external-config-1” 的 + # ClusterIngressParameter（API 组为 k8s.example.net）资源中。 + # 这项定义告诉 Kubernetes 去寻找一个集群作用域的参数资源。 + scope: Cluster + apiGroup: k8s.example.net + kind: ClusterIngressParameter + name: external-config-1 +``` +{{% /tab %}} +{{% tab name="命名空间作用域" %}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} -`parameters` 字段有一个 `scope` 和 `namespace` 字段，可用来引用特定 -于名字空间的资源，对 Ingress 类进行配置。 -`scope` 字段默认为 `Cluster`，表示默认是集群作用域的资源。 -将 `scope` 设置为 `Namespace` 并设置 `namespace` 字段就可以引用某特定 -名字空间中的参数资源。 +如果你设置了 `.spec.parameters` 字段且将 `.spec.parameters.scope` +字段设为了 `Namespace`，那么该 IngressClass 将会引用一个命名空间作用域的资源。 +`.spec.parameters.namespace` 必须和此资源所处的命名空间相同。 -有了名字空间域的参数，就不再需要为一个参数资源配置集群范围的 CustomResourceDefinition。 -除此之外，之前对访问集群范围的资源进行授权，需要用到 RBAC 相关的资源，现在也不再需要了。 +参数的 `kind`（和 `apiGroup` +一起）指向一个命名空间作用域的 API（例如：ConfigMap），而它的 +`name` 则确定了一个位于你指定的命名空间中的具体的资源。 -{{< codenew file="service/networking/namespaced-params.yaml" >}} + +命名空间作用域的参数帮助集群操作者将控制细分到用于工作负载的各种配置中（比如：负载均衡设置、API +网关定义）。如果你使用集群作用域的参数，那么你必须从以下两项中选择一项执行： + +- 每次修改配置，集群操作团队需要批准其他团队的修改。 +- 集群操作团队定义具体的准入控制，比如 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) + 角色与角色绑定，以使得应用程序团队可以修改集群作用域的配置参数资源。 + + +IngressClass API 本身是集群作用域的。 + +这里是一个引用命名空间作用域的配置参数的 IngressClass 的示例： +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-2 +spec: + controller: example.com/ingress-controller + parameters: + # 此 IngressClass 的配置定义在一个名为 “external-config” 的 + # IngressParameter（API 组为 k8s.example.com）资源中， + # 该资源位于 “external-configuration” 命名空间中。 + scope: Namespace + apiGroup: k8s.example.com + kind: IngressParameter + namespace: external-configuration + name: external-config +``` + +{{% /tab %}} +{{< /tabs >}} ### 废弃的注解 {#deprecated-annotation} -在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前， -Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。 +在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前，Ingress +类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。 这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。 Ingress 中新的 `ingressClassName` 字段是该注解的替代品，但并非完全等价。 -该注解通常用于引用实现该 Ingress 的控制器的名称， -而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用， -包括 Ingress 控制器的名称。 +该注解通常用于引用实现该 Ingress 的控制器的名称，而这个新的字段则是对一个包含额外 +Ingress 配置的 IngressClass 资源的引用，包括 Ingress 控制器的名称。 +有一些 Ingress 控制器不需要定义默认的 `IngressClass`。比如：Ingress-NGINX +控制器可以通过[参数](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) +`--watch-ingress-without-class` 来配置。 +不过仍然[推荐](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) +设置默认的 `IngressClass`。 + +{{< codenew file="service/networking/default-ingressclass.yaml" >}} + -例如，以下 Ingress 会将针对 `first.bar.com` 的请求流量路由到 `service1`， -将针对 `second.bar.com` 的请求流量路由到 `service2`， -而针对该 IP 地址的、没有在请求中定义主机名的请求流量会被路由（即，不提供请求标头） -到 `service3`。 +例如，以下 Ingress 会将请求 `first.bar.com` 的流量路由到 `service1`，将请求 +`second.bar.com` 的流量路由到 `service2`，而所有其他流量都会被路由到 `service3`。 {{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}} @@ -710,12 +846,12 @@ and private key to use for TLS. For example: 你可以通过设定包含 TLS 私钥和证书的{{< glossary_tooltip text="Secret" term_id="secret" >}} 来保护 Ingress。 -Ingress 只支持单个 TLS 端口 443，并假定 TLS 连接终止于 Ingress 节点 -（与 Service 及其 Pod 之间的流量都以明文传输）。 -如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名 -（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 -TLS Secret 必须包含名为 `tls.crt` 和 `tls.key` 的键名。 -这些数据包含用于 TLS 的证书和私钥。例如： +Ingress 只支持单个 TLS 端口 443，并假定 TLS 连接终止于 +Ingress 节点（与 Service 及其 Pod 之间的流量都以明文传输）。 +如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 +SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 +TLS Secret 的数据中必须包含用于 TLS 的以键名 `tls.crt` 保存的证书和以键名 `tls.key` 保存的私钥。 +例如： ```yaml apiVersion: v1 @@ -724,8 +860,8 @@ metadata: name: testsecret-tls namespace: default data: - tls.crt: base64 编码的 cert - tls.key: base64 编码的 key + tls.crt: base64 编码的证书 + tls.key: base64 编码的私钥 type: kubernetes.io/tls ``` @@ -747,8 +883,7 @@ certificates would have to be issued for all the possible sub-domains. Therefore section. --> 注意，默认规则上无法使用 TLS，因为需要为所有可能的子域名发放证书。 -因此，`tls` 节区的 `hosts` 的取值需要域 `rules` 节区的 `host` -完全匹配。 +因此，`tls` 字段中的 `hosts` 的取值需要与 `rules` 字段中的 `host` 完全匹配。 {{< /note >}} {{< codenew file="service/networking/tls-example-ingress.yaml" >}} @@ -779,8 +914,8 @@ a Service. --> ### 负载均衡 {#load-balancing} -Ingress 控制器启动引导时使用一些适用于所有 Ingress 的负载均衡策略设置， -例如负载均衡算法、后端权重方案和其他等。 +Ingress 控制器启动引导时使用一些适用于所有 Ingress +的负载均衡策略设置，例如负载均衡算法、后端权重方案等。 更高级的负载均衡概念（例如持久会话、动态权重）尚未通过 Ingress 公开。 你可以通过用于服务的负载均衡器来获取这些功能。 @@ -797,10 +932,8 @@ specific documentation to see how they handle health checks ( 中存在并行的概念，比如 [就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)， 允许你实现相同的目的。 -请检查特定控制器的说明文档（ -[nginx](https://git.k8s.io/ingress-nginx/README.md)， -[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)） -以了解它们是怎样处理健康检查的。 +请检查特定控制器的说明文档（[nginx](https://git.k8s.io/ingress-nginx/README.md)、 +[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）以了解它们是怎样处理健康检查的。 -* 进一步了解 [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) +* 进一步了解 [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API * 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) * [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/zh/examples/service/networking/default-ingressclass.yaml b/content/zh/examples/service/networking/default-ingressclass.yaml new file mode 100644 index 0000000000..0602ad8c9d --- /dev/null +++ b/content/zh/examples/service/networking/default-ingressclass.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + labels: + app.kubernetes.io/component: controller + name: nginx-example + annotations: + ingressclass.kubernetes.io/is-default-class: "true" +spec: + controller: k8s.io/ingress-nginx