Kubernetes Ingress

Ingress

FEATURE STATE: Kubernetes v1.19 [stable]

Ingress 是對集群中服務(wù)的外部訪問進(jìn)行管理的 API 對象，典型的訪問方式是 HTTP。

Ingress 可以提供負(fù)載均衡、SSL 終結(jié)和基于名稱的虛擬托管。

術(shù)語

為了表達(dá)更加清晰，本指南定義了以下術(shù)語：

• 節(jié)點(diǎn)（Node）: Kubernetes 集群中的一臺(tái)工作機(jī)器，是集群的一部分。
• 集群（Cluster）: 一組運(yùn)行由 Kubernetes 管理的容器化應(yīng)用程序的節(jié)點(diǎn)。 在此示例和在大多數(shù)常見的 Kubernetes 部署環(huán)境中，集群中的節(jié)點(diǎn)都不在公共網(wǎng)絡(luò)中。
• 邊緣路由器（Edge Router）: 在集群中強(qiáng)制執(zhí)行防火墻策略的路由器?？梢允怯稍铺峁┥坦芾淼木W(wǎng)關(guān)，也可以是物理硬件。
• 集群網(wǎng)絡(luò)（Cluster Network）: 一組邏輯的或物理的連接，根據(jù) Kubernetes 網(wǎng)絡(luò)模型在集群內(nèi)實(shí)現(xiàn)通信。
• 服務(wù)（Service）：Kubernetes 服務(wù)（Service）， 使用標(biāo)簽選擇器（selectors）辨認(rèn)一組 Pod。 除非另有說明，否則假定服務(wù)只具有在集群網(wǎng)絡(luò)中可路由的虛擬 IP。

Ingress 是什么？

Ingress 公開了從集群外部到集群內(nèi)服務(wù)的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 資源上定義的規(guī)則控制。

下面是一個(gè)將所有流量都發(fā)送到同一 Service 的簡單 Ingress 示例：

Ingress 可為 Service 提供外部可訪問的 URL、負(fù)載均衡流量、終止 SSL/TLS，以及基于名稱的虛擬托管。 Ingress 控制器 通常負(fù)責(zé)通過負(fù)載均衡器來實(shí)現(xiàn) Ingress，盡管它也可以配置邊緣路由器或其他前端來幫助處理流量。

Ingress 不會(huì)公開任意端口或協(xié)議。 將 HTTP 和 HTTPS 以外的服務(wù)公開到 Internet 時(shí)，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 類型的 Service。

環(huán)境準(zhǔn)備

你必須擁有一個(gè) Ingress 控制器 才能滿足 Ingress 的要求。 僅創(chuàng)建 Ingress 資源本身沒有任何效果。

你可能需要部署 Ingress 控制器，例如 ingress-nginx。 你可以從許多 Ingress 控制器 中進(jìn)行選擇。

理想情況下，所有 Ingress 控制器都應(yīng)符合參考規(guī)范。但實(shí)際上，不同的 Ingress 控制器操作略有不同。

確保你查看了 Ingress 控制器的文檔，以了解選擇它的注意事項(xiàng)。

Ingress 資源 

一個(gè)最小的 Ingress 資源示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Ingress 需要指定 ?apiVersion?、?kind?、 ?metadata?和 ?spec ?字段。 Ingress 對象的命名必須是合法的 DNS 子域名名稱。 關(guān)于如何使用配置文件，請參見部署應(yīng)用、 配置容器、 管理資源。 Ingress 經(jīng)常使用注解（annotations）來配置一些選項(xiàng)，具體取決于 Ingress 控制器，例如 重寫目標(biāo)注解。 不同的 Ingress 控制器支持不同的注解。 查看你所選的 Ingress 控制器的文檔，以了解其支持哪些注解。

Ingress 規(guī)約 提供了配置負(fù)載均衡器或者代理服務(wù)器所需的所有信息。 最重要的是，其中包含與所有傳入請求匹配的規(guī)則列表。 Ingress 資源僅支持用于轉(zhuǎn)發(fā) HTTP(S) 流量的規(guī)則。

如果 ?ingressClassName ?被省略，那么你應(yīng)該定義一個(gè)默認(rèn) Ingress 類。

有一些 Ingress 控制器不需要定義默認(rèn)的 ?IngressClass?。比如：Ingress-NGINX 控制器可以通過參數(shù) ?--watch-ingress-without-class? 來配置。 不過仍然 推薦 按下文所示來設(shè)置默認(rèn)的 ?IngressClass?。

Ingress 規(guī)則 

每個(gè) HTTP 規(guī)則都包含以下信息：

• 可選的 ?host?。在此示例中，未指定 ?host?，因此該規(guī)則適用于通過指定 IP 地址的所有入站 HTTP 通信。 如果提供了 ?host?（例如 foo.bar.com），則 ?rules ?適用于該 ?host?。
• 路徑列表 paths（例如，?/testpath?）,每個(gè)路徑都有一個(gè)由 ?serviceName ?和 ?servicePort ?定義的關(guān)聯(lián)后端。 在負(fù)載均衡器將流量定向到引用的服務(wù)之前，主機(jī)和路徑都必須匹配傳入請求的內(nèi)容。
• ?backend?（后端）是 Service 文檔中所述的服務(wù)和端口名稱的組合。 與規(guī)則的 ?host ?和 ?path ?匹配的對 Ingress 的 HTTP（和 HTTPS ）請求將發(fā)送到列出的 ?backend?。

通常在 Ingress 控制器中會(huì)配置 ?defaultBackend?（默認(rèn)后端），以服務(wù)于無法與規(guī)約中 ?path ?匹配的所有請求。

默認(rèn)后端 

沒有設(shè)置規(guī)則的 Ingress 將所有流量發(fā)送到同一個(gè)默認(rèn)后端，而 ?.spec.defaultBackend? 則是在這種情況下處理請求的那個(gè)默認(rèn)后端。 ?defaultBackend ?通常是 Ingress 控制器的配置選項(xiàng)，而非在 Ingress 資源中指定。 如果未設(shè)置任何的 ?.spec.rules?，那么必須指定 ?.spec.defaultBackend?。 如果未設(shè)置 ?defaultBackend?，那么如何處理所有與規(guī)則不匹配的流量將交由 Ingress 控制器決定（請參考你的 Ingress 控制器的文檔以了解它是如何處理那些流量的）。

如果沒有 ?hosts ?或 ?paths ?與 Ingress 對象中的 HTTP 請求匹配，則流量將被路由到默認(rèn)后端。

資源后端 

?Resource ?后端是一個(gè)引用，指向同一命名空間中的另一個(gè) Kubernetes 資源，將其作為 Ingress 對象。 ?Resource ?后端與 Service 后端是互斥的，在二者均被設(shè)置時(shí)會(huì)無法通過合法性檢查。 ?Resource ?后端的一種常見用法是將所有入站數(shù)據(jù)導(dǎo)向帶有靜態(tài)資產(chǎn)的對象存儲(chǔ)后端。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: k8s.example.com
      kind: StorageBucket
      name: static-assets
  rules:
    - http:
        paths:
          - path: /icons
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: k8s.example.com
                kind: StorageBucket
                name: icon-assets


    

創(chuàng)建了如上的 Ingress 之后，你可以使用下面的命令查看它：

kubectl describe ingress ingress-resource-backend

Name:             ingress-resource-backend
Namespace:        default
Address:
Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations:  <none>
Events:       <none>

路徑類型 

Ingress 中的每個(gè)路徑都需要有對應(yīng)的路徑類型（Path Type）。未明確設(shè)置 ?pathType ?的路徑無法通過合法性檢查。當(dāng)前支持的路徑類型有三種：

• ?ImplementationSpecific?：對于這種路徑類型，匹配方法取決于 IngressClass。 具體實(shí)現(xiàn)可以將其作為單獨(dú)的 ?pathType ?處理或者與 ?Prefix ?或 ?Exact ?類型作相同處理。
• ?Exact?：精確匹配 URL 路徑，且區(qū)分大小寫。
• ?Prefix?：基于以 ?/? 分隔的 URL 路徑前綴匹配。匹配區(qū)分大小寫，并且對路徑中的元素逐個(gè)完成。 路徑元素指的是由 ?/? 分隔符分隔的路徑中的標(biāo)簽列表。 如果每個(gè) p 都是請求路徑 p 的元素前綴，則請求與路徑 p 匹配。

如果路徑的最后一個(gè)元素是請求路徑中最后一個(gè)元素的子字符串，則不會(huì)匹配 （例如：?/foo/bar? 匹配 ?/foo/bar/baz?, 但不匹配 ?/foo/barbaz?）。

示例

多重匹配 

在某些情況下，Ingress 中的多條路徑會(huì)匹配同一個(gè)請求。 這種情況下最長的匹配路徑優(yōu)先。 如果仍然有兩條同等的匹配路徑，則精確路徑類型優(yōu)先于前綴路徑類型。

主機(jī)名通配符 

主機(jī)名可以是精確匹配（例如“?foo.bar.com?”）或者使用通配符來匹配 （例如“?*.foo.com?”）。 精確匹配要求 HTTP ?host ?頭部字段與 ?host ?字段值完全匹配。 通配符匹配則要求 HTTP ?host ?頭部字段與通配符規(guī)則中的后綴部分相同。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

Ingress 類 

Ingress 可以由不同的控制器實(shí)現(xiàn)，通常使用不同的配置。 每個(gè) Ingress 應(yīng)當(dāng)指定一個(gè)類，也就是一個(gè)對 IngressClass 資源的引用。 IngressClass 資源包含額外的配置，其中包括應(yīng)當(dāng)實(shí)現(xiàn)該類的控制器名稱。

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: external-lb

IngressClass 中的 ?.spec.parameters? 字段可用于引用其他資源以提供額外的相關(guān)配置。

參數(shù)（?parameters?）的具體類型取決于你在 ?.spec.controller? 字段中指定的 Ingress 控制器。

IngressClass 的作用域

取決于你的 Ingress 控制器，你可能可以使用集群范圍設(shè)置的參數(shù)或某個(gè)名字空間范圍的參數(shù)。

• 集群作用域

IngressClass 的參數(shù)默認(rèn)是集群范圍的。

如果你設(shè)置了 .spec.parameters 字段且未設(shè)置 .spec.parameters.scope 字段，或是將 .spec.parameters.scope 字段設(shè)為了 Cluster，那么該 IngressClass 所指代的即是一個(gè)集群作用域的資源。 參數(shù)的 kind（和 apiGroup 一起）指向一個(gè)集群作用域的 API（可能是一個(gè)定制資源（Custom Resource）），而它的 name 則為此 API 確定了一個(gè)具體的集群作用域的資源。

示例：

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # 此 IngressClass 的配置定義在一個(gè)名為 “external-config-1” 的
    # ClusterIngressParameter（API 組為 k8s.example.net）資源中。
    # 這項(xiàng)定義告訴 Kubernetes 去尋找一個(gè)集群作用域的參數(shù)資源。
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

• 命名空間作用域

FEATURE STATE: Kubernetes v1.23 [stable]

如果你設(shè)置了 ?.spec.parameters? 字段且將 ?.spec.parameters.scope? 字段設(shè)為了 ?Namespace?，那么該 IngressClass 將會(huì)引用一個(gè)命名空間作用域的資源。 ?.spec.parameters.namespace? 必須和此資源所處的命名空間相同。

參數(shù)的 ?kind?（和 ?apiGroup ?一起）指向一個(gè)命名空間作用域的 API（例如：ConfigMap），而它的 ?name ?則確定了一個(gè)位于你指定的命名空間中的具體的資源。

命名空間作用域的參數(shù)幫助集群操作者將控制細(xì)分到用于工作負(fù)載的各種配置中（比如：負(fù)載均衡設(shè)置、API 網(wǎng)關(guān)定義）。如果你使用集群作用域的參數(shù)，那么你必須從以下兩項(xiàng)中選擇一項(xiàng)執(zhí)行：

• 每次修改配置，集群操作團(tuán)隊(duì)需要批準(zhǔn)其他團(tuán)隊(duì)的修改。
• 集群操作團(tuán)隊(duì)定義具體的準(zhǔn)入控制，比如 RBAC 角色與角色綁定，以使得應(yīng)用程序團(tuán)隊(duì)可以修改集群作用域的配置參數(shù)資源。

IngressClass API 本身是集群作用域的。

這里是一個(gè)引用命名空間作用域的配置參數(shù)的 IngressClass 的示例：

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # 此 IngressClass 的配置定義在一個(gè)名為 “external-config” 的
    # IngressParameter（API 組為 k8s.example.com）資源中，
    # 該資源位于 “external-configuration” 命名空間中。
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

廢棄的注解 

在 Kubernetes 1.18 版本引入 IngressClass 資源和 ?ingressClassName ?字段之前，Ingress 類是通過 Ingress 中的一個(gè) ?kubernetes.io/ingress.class? 注解來指定的。 這個(gè)注解從未被正式定義過，但是得到了 Ingress 控制器的廣泛支持。

Ingress 中新的 ?ingressClassName ?字段是該注解的替代品，但并非完全等價(jià)。 該注解通常用于引用實(shí)現(xiàn)該 Ingress 的控制器的名稱，而這個(gè)新的字段則是對一個(gè)包含額外 Ingress 配置的 IngressClass 資源的引用，包括 Ingress 控制器的名稱。

默認(rèn) Ingress 類 

你可以將一個(gè)特定的 IngressClass 標(biāo)記為集群默認(rèn) Ingress 類。 將一個(gè) IngressClass 資源的 ?ingressclass.kubernetes.io/is-default-class? 注解設(shè)置為 ?true ?將確保新的未指定 ?ingressClassName ?字段的 Ingress 能夠分配為這個(gè)默認(rèn)的 IngressClass.

如果集群中有多個(gè) IngressClass 被標(biāo)記為默認(rèn)，準(zhǔn)入控制器將阻止創(chuàng)建新的未指定 ?ingressClassName ?的 Ingress 對象。 解決這個(gè)問題只需確保集群中最多只能有一個(gè) IngressClass 被標(biāo)記為默認(rèn)。

有一些 Ingress 控制器不需要定義默認(rèn)的 ?IngressClass?。比如：Ingress-NGINX 控制器可以通過參數(shù) ?--watch-ingress-without-class? 來配置。 不過仍然推薦 設(shè)置默認(rèn)的 ?IngressClass?。

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

Ingress 類型 

由單個(gè) Service 來完成的 Ingress 

現(xiàn)有的 Kubernetes 概念允許你暴露單個(gè) Service。 你也可以通過指定無規(guī)則的 默認(rèn)后端 來對 Ingress 進(jìn)行此操作。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: test
      port:
        number: 80

如果使用 ?kubectl apply -f? 創(chuàng)建此 Ingress，則應(yīng)該能夠查看剛剛添加的 Ingress 的狀態(tài)：

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。

入口控制器和負(fù)載平衡器可能需要一兩分鐘才能分配 IP 地址。 在此之前，你通常會(huì)看到地址字段的值被設(shè)定為 ? <pending>?。

簡單扇出 

一個(gè)扇出（fanout）配置根據(jù)請求的 HTTP URI 將來自同一 IP 地址的流量路由到多個(gè) Service。 Ingress 允許你將負(fù)載均衡器的數(shù)量降至最低。例如，這樣的設(shè)置：

將需要一個(gè)如下所示的 Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 4200
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 8080

當(dāng)你使用 ?kubectl apply -f? 創(chuàng)建 Ingress 時(shí)：

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:4200 (10.8.0.90:4200)
               /bar   service2:8080 (10.8.0.91:8080)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     22s                loadbalancer-controller  default/test

Ingress 控制器將提供實(shí)現(xiàn)特定的負(fù)載均衡器來滿足 Ingress， 只要 Service (?service1?，?service2?) 存在。 當(dāng)它這樣做時(shí)，你會(huì)在 Address 字段看到負(fù)載均衡器的地址。

取決于你所使用的 Ingress 控制器， 你可能需要?jiǎng)?chuàng)建默認(rèn) HTTP 后端服務(wù)。

基于名稱的虛擬托管 

基于名稱的虛擬主機(jī)支持將針對多個(gè)主機(jī)名的 HTTP 流量路由到同一 IP 地址上。

以下 Ingress 讓后臺(tái)負(fù)載均衡器基于host 頭部字段 來路由請求。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80

如果你創(chuàng)建的 Ingress 資源沒有在 ?rules ?中定義的任何 ?hosts?，則可以匹配指向 Ingress 控制器 IP 地址的任何網(wǎng)絡(luò)流量，而無需基于名稱的虛擬主機(jī)。

例如，以下 Ingress 會(huì)將請求 ?first.bar.com? 的流量路由到 ?service1?，將請求 ?second.bar.com? 的流量路由到 ?service2?，而所有其他流量都會(huì)被路由到 ?service3?。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress-no-third-host
spec:
  rules:
  - host: first.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: second.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service3
            port:
              number: 80

TLS

你可以通過設(shè)定包含 TLS 私鑰和證書的Secret 來保護(hù) Ingress。 Ingress 只支持單個(gè) TLS 端口 443，并假定 TLS 連接終止于 Ingress 節(jié)點(diǎn)（與 Service 及其 Pod 之間的流量都以明文傳輸）。 如果 Ingress 中的 TLS 配置部分指定了不同的主機(jī)，那么它們將根據(jù)通過 SNI TLS 擴(kuò)展指定的主機(jī)名（如果 Ingress 控制器支持 SNI）在同一端口上進(jìn)行復(fù)用。 TLS Secret 的數(shù)據(jù)中必須包含用于 TLS 的以鍵名 ?tls.crt? 保存的證書和以鍵名 ?tls.key? 保存的私鑰。 例如：

apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: default
data:
  tls.crt: base64 編碼的證書
  tls.key: base64 編碼的私鑰
type: kubernetes.io/tls

在 Ingress 中引用此 Secret 將會(huì)告訴 Ingress 控制器使用 TLS 加密從客戶端到負(fù)載均衡器的通道。 你需要確保創(chuàng)建的 TLS Secret 創(chuàng)建自包含 ?https-example.foo.com? 的公用名稱（CN）的證書。 這里的公共名稱也被稱為全限定域名（FQDN）。

注意，默認(rèn)規(guī)則上無法使用 TLS，因?yàn)樾枰獮樗锌赡艿淖佑蛎l(fā)放證書。 因此，?tls ?字段中的 ?hosts ?的取值需要與 ?rules ?字段中的 ?host ?完全匹配。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
      - https-example.foo.com
    secretName: testsecret-tls
  rules:
  - host: https-example.foo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80

各種 Ingress 控制器所支持的 TLS 功能之間存在差異。請參閱有關(guān) nginx、 GCE 或者任何其他平臺(tái)特定的 Ingress 控制器的文檔，以了解 TLS 如何在你的環(huán)境中工作。

負(fù)載均衡 

Ingress 控制器啟動(dòng)引導(dǎo)時(shí)使用一些適用于所有 Ingress 的負(fù)載均衡策略設(shè)置，例如負(fù)載均衡算法、后端權(quán)重方案等。 更高級的負(fù)載均衡概念（例如持久會(huì)話、動(dòng)態(tài)權(quán)重）尚未通過 Ingress 公開。 你可以通過用于服務(wù)的負(fù)載均衡器來獲取這些功能。

值得注意的是，盡管健康檢查不是通過 Ingress 直接暴露的，在 Kubernetes 中存在并行的概念，比如 就緒檢查， 允許你實(shí)現(xiàn)相同的目的。 請檢查特定控制器的說明文檔（nginx、 GCE）以了解它們是怎樣處理健康檢查的。

更新 Ingress 

要更新現(xiàn)有的 Ingress 以添加新的 Host，可以通過編輯資源來對其進(jìn)行更新：

kubectl describe ingress test

Name:             test
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)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     35s                loadbalancer-controller  default/test

kubectl edit ingress test

這一命令將打開編輯器，允許你以 YAML 格式編輯現(xiàn)有配置。 修改它來增加新的主機(jī)：

spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /foo
        pathType: Prefix
  - host: bar.baz.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: 80
        path: /foo
        pathType: Prefix
..

保存更改后，kubectl 將更新 API 服務(wù)器中的資源，該資源將告訴 Ingress 控制器重新配置負(fù)載均衡器。

驗(yàn)證：

kubectl describe ingress test

Name:             test
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.baz.com
               /foo   service2:80 (10.8.0.91:80)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     45s                loadbalancer-controller  default/test

你也可以通過 ?kubectl replace -f? 命令調(diào)用修改后的 Ingress yaml 文件來獲得同樣的結(jié)果。

跨可用區(qū)失敗 

不同的云廠商使用不同的技術(shù)來實(shí)現(xiàn)跨故障域的流量分布。

替代方案 

不直接使用 Ingress 資源，也有多種方法暴露 Service：

• 使用 Service.Type=LoadBalancer
• 使用 Service.Type=NodePort