示例 {examples}-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00761/article/details/148548726

示例 {#examples}

website Kubernetes website and documentation repo: 项目地址: https://gitcode.com/gh_mirrors/webs/website

| 类型 | 路径（Path） | 请求路径（Request path） | 是否匹配？ | |---------|---------------------------------|-----------------------------|------------------------------------| | Prefix | / | （所有路径） | 是 | | Exact | /foo | /foo | 是 | | Exact | /foo | /bar | 否 | | Exact | /foo | /foo/ | 否 | | Exact | /foo/ | /foo | 否 | | Prefix | /foo | /foo, /foo/ | 是 | | Prefix | /foo/ | /foo, /foo/ | 是 | | Prefix | /aaa/bb | /aaa/bbb | 否 | | Prefix | /aaa/bbb | /aaa/bbb | 是 | | Prefix | /aaa/bbb/ | /aaa/bbb | 是，忽略尾部斜线 | | Prefix | /aaa/bbb | /aaa/bbb/ | 是，匹配尾部斜线 | | Prefix | /aaa/bbb | /aaa/bbb/ccc | 是，匹配子路径 | | Prefix | /aaa/bbb | /aaa/bbbxyz | 否，不匹配字符串前缀 | | Prefix | /, /aaa | /aaa/ccc | 是，匹配 /aaa 前缀 | | Prefix | /, /aaa, /aaa/bbb | /aaa/bbb | 是，匹配 /aaa/bbb 前缀 | | Prefix | /, /aaa, /aaa/bbb | /ccc | 是，匹配 / 前缀 | | Prefix | /aaa | /ccc | 否，使用默认后端 | | 混合 | /foo (Prefix), /bar (Exact) | /foo, /bar | 是 |

多重匹配 {#multiple-matches}

在某些情况下，Ingress 中的多条路径会匹配同一个请求。这种情况下最长的匹配路径优先。如果仍然有两条同等的匹配路径，则精确路径类型优先于前缀路径类型。

主机名通配符 {#hostname-wildcards}

主机名可以是精确匹配（例如“foo.bar.com”）或者使用通配符来匹配（例如“*.foo.com”）。精确匹配要求 HTTP host 头部字段与 host 字段值完全匹配。通配符匹配则要求 HTTP host 头部字段与通配符规则中的后缀部分相同。

| 主机（Host） | host 头部 | 是否匹配？ | |-------------|---------------------|---------------------------------------------| | *.foo.com | bar.foo.com | 基于相同的后缀匹配 | | *.foo.com | baz.bar.foo.com | 不匹配，通配符仅覆盖了一个 DNS 标签 | | *.foo.com | foo.com | 不匹配，通配符仅覆盖了一个 DNS 标签 |

Ingress 类 {#ingress-class}

Ingress 可以由不同的控制器实现，通常使用不同的配置。每个 Ingress 应当指定一个类，也就是一个对 IngressClass 资源的引用。 IngressClass 资源包含额外的配置，其中包括应当实现该类的控制器名称。

IngressClass 资源的 .spec.parameters 字段可用于引用其他资源以提供额外的相关配置。

参数（parameters）的具体类型取决于你在 IngressClass 的 .spec.controller 字段中指定的 Ingress 控制器。

IngressClass 的作用域 {#ingressclass-scope}

取决于你的 Ingress 控制器，你可能可以使用集群范围或特定名字空间的参数资源。

IngressClass 参数的默认作用域是集群范围的。

如果你设置了 .spec.parameters 字段且未设置 .spec.parameters.scope 字段，或是将 .spec.parameters.scope 字段设为 Cluster，那么该 IngressClass 引用的是集群作用域的资源。参数的 kind（与 apiGroup 组合一起）指向某集群作用域的 API （可能是一个定制资源（Custom Resource）），而它的 name 则确定了某个具体的集群作用域的资源。

如果你使用了较旧版本的 Kubernetes，那么 IngressClass 相关的行为可能看起来有所不同。在 Kubernetes 1.18 版本引入 IngressClass 资源和 ingressClassName 字段之前， Ingress 类是通过 Ingress 中的一个 kubernetes.io/ingress.class 注解来指定的。这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。

Ingress 中新的 .spec.ingressClassName 字段是该注解的替代品，但并非完全等价。该注解通常用于引用实现该 Ingress 的控制器的名称，而这个新的字段则是对一个包含额外 Ingress 配置的 IngressClass 资源的引用，包括 Ingress 控制器的名称。 {{< /note >}}

默认 Ingress 类 {#default-ingress-class}

你可以将一个特定的 IngressClass 标记为集群默认 Ingress 类。将一个 IngressClass 资源的 ingressclass.kubernetes.io/is-default-class 注解设置为 true 将确保新的未指定 ingressClassName 字段的 Ingress 能够分配为这个默认的 IngressClass.

如果集群中有多个 IngressClass 被标记为默认，准入控制器将阻止创建新的未指定 ingressClassName 的 Ingress 对象。解决这个问题只需确保集群中最多只能有一个 IngressClass 被标记为默认。 {{< /caution >}}

Ingress 类型 {#types-of-ingress}

单服务 Ingress {#ingress-backed-by-a-single-service}

现有的 Kubernetes 概念允许你暴露单个 Service（参见替代方案）。你也可以通过指定无规则的默认后端来对 Ingress 进行此操作。

如果使用 kubectl apply -f 创建此 Ingress，则应该能够查看刚刚添加的 Ingress 的状态：

kubectl get ingress test-ingress

NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
test-ingress   external-lb   *       203.0.113.123   80      59s

其中 203.0.113.123 是由 Ingress 控制器分配以满足该 Ingress 的 IP。

Ingress 控制器和负载均衡器可能需要一两分钟才能分配 IP 地址。在此之前，你通常会看到地址字段的值被设定为 <pending>。 {{< /note >}}

基于名称的虚拟托管 {#simple-fanout}

基于名称的虚拟托管支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上。

{{% code_sample file="service/networking/simple-fanout-example.yaml" %}}

当你使用 kubectl apply -f 创建 Ingress 时，你将看到：

kubectl describe ingress simple-fanout-example

Name:             simple-fanout-example
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
  bar.foo.com
               /bar   service2:80 (10.8.0.91:80)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     22s                loadbalancer-controller  default/test

Ingress 控制器会提供特定于实现的负载均衡器来满足 Ingress，只要 Service（service1、service2）存在。当它这样做时，你会在 Address 字段看到负载均衡器的地址。

取决于你所使用的 Ingress 控制器，你可能需要创建默认 HTTP 后端 Service。 {{< /note >}}

基于名称的虚拟托管 {#name-based-virtual-hosting}

基于名称的虚拟托管支持将针对多个主机名的 HTTP 流量路由到同一 IP 地址上。

{{% code_sample file="service/networking/name-virtual-host-ingress.yaml" %}}

如果你创建的 Ingress 资源没有在 rules 中定义任何主机，则可以匹配指向 Ingress 控制器 IP 地址的所有网络流量，而无需基于名称的虚拟主机。

例如，以下 Ingress 会将请求 first.bar.com 的流量路由到 service1，将 second.foo.com 的流量路由到 service2，而所有其他流量都会被路由到 service3。

{{% code_sample file="service/networking/name-virtual-host-ingress-no-third-host.yaml" %}}

TLS {#tls}

你可以通过设定包含 TLS 私钥和证书的Secret 来保护 Ingress。 Ingress 只支持单个 TLS 端口 443，并假定 TLS 连接终止于 Ingress 节点（与 Service 及其 Pod 之间的流量都以明文传输）。如果 Ingress 中的 TLS 配置部分指定了不同的主机，那么它们将根据通过 SNI TLS 扩展指定的主机名（如果 Ingress 控制器支持 SNI）在同一端口上进行复用。 TLS Secret 的数据中必须包含键名为 tls.crt 的证书和键名为 tls.key 的私钥，才能用于 TLS 目的。例如：

{{% code_sample file="service/networking/tls-example-ingress.yaml" %}}

当你创建包含证书和私钥的 Secret 时，请确保使用这两个键名。

各种 Ingress 控制器所支持的 TLS 功能之间存在差距。请参阅有关 nginx、 GCE 或者任何其他特定平台的 Ingress 控制器的文档，以了解 TLS 如何在你的环境中工作。