成人黄色av网站,在线视频婷婷毛片激情开心

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

創(chuàng)新互聯(lián)kubernetes教程：KubernetesIngress

Ingress

FEATURE STATE: Kubernetes v1.19 [stable]

溧陽ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

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

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

術(shù)語

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

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

Ingress 是什么？

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

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

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

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

環(huán)境準備

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

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

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

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

Ingress 資源

一個最小的 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）來配置一些選項，具體取決于 Ingress 控制器，例如重寫目標注解。不同的 Ingress 控制器支持不同的注解。查看你所選的 Ingress 控制器的文檔，以了解其支持哪些注解。

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

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

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

Ingress 規(guī)則

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

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

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

默認后端

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

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

資源后端

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

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:  
Events:

路徑類型

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

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

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

示例

類型	路徑	請求路徑	匹配與否？
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), `/foo` (Exact)	`/foo`	是，優(yōu)選 Exact 類型

多重匹配

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

主機名通配符

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

主機	host 頭部	匹配與否？
`*.foo.com`	`bar.foo.com`	基于相同的后綴匹配
`*.foo.com`	`baz.bar.foo.com`	不匹配，通配符僅覆蓋了一個 DNS 標簽
`*.foo.com`	`foo.com`	不匹配，通配符僅覆蓋了一個 DNS 標簽

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 可以由不同的控制器實現(xiàn)，通常使用不同的配置。每個 Ingress 應(yīng)當指定一個類，也就是一個對 IngressClass 資源的引用。 IngressClass 資源包含額外的配置，其中包括應(yīng)當實現(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ù)或某個名字空間范圍的參數(shù)。

集群作用域

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

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

示例：

---
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 去尋找一個集群作用域的參數(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 將會引用一個命名空間作用域的資源。 ?.spec.parameters.namespace? 必須和此資源所處的命名空間相同。

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

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

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

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

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

---
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

廢棄的注解

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

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

默認 Ingress 類

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

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

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

由單個 Service 來完成的 Ingress

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

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。

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

簡單扇出

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

將需要一個如下所示的 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

當你使用 ?kubectl apply -f? 創(chuàng)建 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: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 控制器將提供實現(xiàn)特定的負載均衡器來滿足 Ingress，只要 Service (?service1?，?service2?) 存在。當它這樣做時，你會在 Address 字段看到負載均衡器的地址。

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

基于名稱的虛擬托管

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

以下 Ingress 讓后臺負載均衡器基于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ò)流量，而無需基于名稱的虛擬主機。

例如，以下 Ingress 會將請求 ?first.bar.com? 的流量路由到 ?service1?，將請求 ?second.bar.com? 的流量路由到 ?service2?，而所有其他流量都會被路由到 ?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 來保護 Ingress。 Ingress 只支持單個 TLS 端口 443，并假定 TLS 連接終止于 Ingress 節(jié)點（與 Service 及其 Pod 之間的流量都以明文傳輸）。如果 Ingress 中的 TLS 配置部分指定了不同的主機，那么它們將根據(jù)通過 SNI TLS 擴展指定的主機名（如果 Ingress 控制器支持 SNI）在同一端口上進行復(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 將會告訴 Ingress 控制器使用 TLS 加密從客戶端到負載均衡器的通道。你需要確保創(chuàng)建的 TLS Secret 創(chuàng)建自包含 ?https-example.foo.com? 的公用名稱（CN）的證書。這里的公共名稱也被稱為全限定域名（FQDN）。

注意，默認規(guī)則上無法使用 TLS，因為需要為所有可能的子域名發(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 或者任何其他平臺特定的 Ingress 控制器的文檔，以了解 TLS 如何在你的環(huán)境中工作。

負載均衡

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

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

更新 Ingress

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

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)有配置。修改它來增加新的主機：

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 控制器重新配置負載均衡器。

驗證：

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ù)來實現(xiàn)跨故障域的流量分布。

替代方案

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

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

網(wǎng)站標題：創(chuàng)新互聯(lián)kubernetes教程：KubernetesIngress
本文來源：http://m.5511xx.com/article/cdopjep.html

日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

新聞中心

Ingress

術(shù)語

Ingress 是什么？

環(huán)境準備

Ingress 資源

Ingress 規(guī)則

默認后端

資源后端

路徑類型

示例

多重匹配

主機名通配符

Ingress 類

IngressClass 的作用域

廢棄的注解

默認 Ingress 類

Ingress 類型

由單個 Service 來完成的 Ingress

簡單扇出

基于名稱的虛擬托管

TLS

負載均衡

更新 Ingress

跨可用區(qū)失敗

替代方案

其他資訊

新聞中心

Ingress

術(shù)語

Ingress 是什么？

環(huán)境準備

Ingress 資源

Ingress 規(guī)則

默認后端

資源后端

路徑類型

示例

多重匹配

主機名通配符

Ingress 類

IngressClass 的作用域

廢棄的注解

默認 Ingress 類

Ingress 類型

由單個 Service 來完成的 Ingress

簡單扇出

基于名稱的虛擬托管

TLS

負載均衡

更新 Ingress

跨可用區(qū)失敗

替代方案

其他資訊

Ingress 是什么？