碼迷,mamicode.com
首頁 > 其他好文 > 詳細

【K8s概念】Ingress

時間:2021-07-28 21:37:25      閱讀:0      評論:0      收藏:0      [點我收藏+]

標簽:相關   --   端口   cluster   策略   會話   要求   設置   efi   

參考:https://kubernetes.io/zh/docs/concepts/services-networking/ingress/

FEATURE STATE: Kubernetes v1.19 [stable]

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

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

Ingress 是什么?

Ingress 公開了從集群外部到集群內服務的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 資源上定義的規則控制。

下面是一個將所有流量都發送到同一 Service 的簡單 Ingress 示例:
技術圖片

可以將 Ingress 配置為服務提供外部可訪問的 URL、負載均衡流量、終止 SSL/TLS,以及提供基于名稱的虛擬主機等能力。 Ingress 控制器 通常負責通過負載均衡器來實現 Ingress,盡管它也可以配置邊緣路由器或其他前端來幫助處理流量。

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

環境準備

你必須具有 Ingress 控制器 才能滿足 Ingress 的要求。 僅創建 Ingress 資源本身沒有任何效果。

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

理想情況下,所有 Ingress 控制器都應符合參考規范。但實際上,不同的 Ingress 控制器操作略有不同。

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

Ingress 資源

一個最小的 Ingress 資源示例:

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

Ingress 規則

每個 HTTP 規則都包含以下信息:

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

通常在 Ingress 控制器中會配置 defaultBackend(默認后端),以服務于任何不符合規約中 path 的請求。

DefaultBackend

沒有 rules 的 Ingress 將所有流量發送到同一個默認后端。 defaultBackend 通常是 Ingress 控制器 的配置選項,而非在 Ingress 資源中指定。

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

資源后端

Resource 后端是一個 ObjectRef,指向同一名字空間中的另一個 Kubernetes,將其作為 Ingress 對象。Resource 與 Service 配置是互斥的,在 二者均被設置時會無法通過合法性檢查。 Resource 后端的一種常見用法是將所有入站數據導向帶有靜態資產的對象存儲后端。

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

路徑類型

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

  • ImplementationSpecific:對于這種路徑類型,匹配方法取決于 IngressClass。 具體實現可以將其作為單獨的 pathType 處理或者與 Prefix 或 Exact 類型作相同處理。

  • Exact:精確匹配 URL 路徑,且區分大小寫。

  • Prefix:基于以 / 分隔的 URL 路徑前綴匹配。匹配區分大小寫,并且對路徑中的元素逐個完成。 路徑元素指的是由 / 分隔符分隔的路徑中的標簽列表。 如果每個 p 都是請求路徑 p 的元素前綴,則請求與路徑 p 匹配。

說明: 如果路徑的最后一個元素是請求路徑中最后一個元素的子字符串,則不會匹配 (例如:/foo/bar 匹配 /foo/bar/baz, 但不匹配 /foo/barbaz)。

示例

技術圖片

多重匹配

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

主機名通配符

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

技術圖片

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 可以由不同的控制器實現,通常使用不同的配置。 每個 Ingress 應當指定一個類,也就是一個對 IngressClass 資源的引用。 IngressClass 資源包含額外的配置,其中包括應當實現該類的控制器名稱。

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 資源包含一個可選的 parameters 字段,可用于為該類引用額外的、 特定于具體實現的配置。

名字空間域的參數

FEATURE STATE: Kubernetes v1.21 [alpha]

parameters 字段有一個 scope 和 namespace 字段,可用來引用特定 于名字空間的資源,對 Ingress 類進行配置。 scope 字段默認為 Cluster,表示默認是集群作用域的資源。 將 scope 設置為 Namespace 并設置 namespace 字段就可以引用某特定 名字空間中的參數資源。

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
    namespace: external-configuration
    scope: Namespace

廢棄的注解

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

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

默認 Ingress 類

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

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

Ingress 類型

由單個 Service 來完成的 Ingress

現有的 Kubernetes 概念允許你暴露單個 Service (參見替代方案)。 你也可以通過指定無規則的 默認后端 來對 Ingress 進行此操作。

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

如果使用 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。

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

簡單扇出

一個扇出(fanout)配置根據請求的 HTTP URI 將來自同一 IP 地址的流量路由到多個 Service。 Ingress 允許你將負載均衡器的數量降至最低。例如,這樣的設置:
技術圖片

將需要一個如下所示的 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 創建 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 控制器將提供實現特定的負載均衡器來滿足 Ingress, 只要 Service (service1,service2) 存在。 當它這樣做時,你會在 Address 字段看到負載均衡器的地址。

說明: 取決于你所使用的 Ingress 控制器, 你可能需要創建默認 HTTP 后端服務。

基于名稱的虛擬托管

基于名稱的虛擬主機支持將針對多個主機名的 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

如果你創建的 Ingress 資源沒有在 rules 中定義的任何 hosts,則可以匹配指向 Ingress 控制器 IP 地址的任何網絡流量,而無需基于名稱的虛擬主機。

例如,以下 Ingress 會將針對 first.bar.com 的請求流量路由到 service1, 將針對 second.bar.com 的請求流量路由到 service2, 而針對該 IP 地址的、沒有在請求中定義主機名的請求流量會被路由(即,不提供請求標頭) 到 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

你可以通過設定包含 TLS 私鑰和證書的Secret 來保護 Ingress。 Ingress 只支持單個 TLS 端口 443,并假定 TLS 連接終止于 Ingress 節點 (與 Service 及其 Pod 之間的流量都以明文傳輸)。 如果 Ingress 中的 TLS 配置部分指定了不同的主機,那么它們將根據通過 SNI TLS 擴展指定的主機名 (如果 Ingress 控制器支持 SNI)在同一端口上進行復用。 TLS Secret 必須包含名為 tls.crt 和 tls.key 的鍵名。 這些數據包含用于 TLS 的證書和私鑰。例如:

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

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

說明:
注意,默認規則上無法使用 TLS,因為需要為所有可能的子域名發放證書。 因此,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 功能之間存在差異。請參閱有關 nginx、 GCE 或者任何其他平臺特定的 Ingress 控制器的文檔,以了解 TLS 如何在你的環境中工作。

負載均衡

Ingress 控制器啟動引導時使用一些適用于所有 Ingress 的負載均衡策略設置, 例如負載均衡算法、后端權重方案和其他等。 更高級的負載均衡概念(例如持久會話、動態權重)尚未通過 Ingress 公開。 你可以通過用于服務的負載均衡器來獲取這些功能。

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

更新 Ingress

要更新現有的 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 格式編輯現有配置。 修改它來增加新的主機:

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 服務器中的資源,該資源將告訴 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 命令調用修改后的 Ingress yaml 文件來獲得同樣的結果。

跨可用區失敗

不同的云廠商使用不同的技術來實現跨故障域的流量分布。詳情請查閱相關 Ingress 控制器的文檔。 請查看相關 Ingress 控制器 的文檔以了解詳細信息。

替代方案

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

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

【K8s概念】Ingress

標簽:相關   --   端口   cluster   策略   會話   要求   設置   efi   

原文地址:https://www.cnblogs.com/varden/p/15070758.html

(0)
(0)
   
舉報
評論 一句話評論(0
登錄后才能評論!
? 2014 mamicode.com 版權所有  聯系我們:gaon5@hotmail.com
迷上了代碼!
4399在线看MV_久久99精品久久久久久久久久_成人又黄又爽又刺激视频_能收黄台的app不收费