自訂ALB Ingress的轉寄規則 - Container Service for Kubernetes

ALB Ingress支援自訂轉寄規則。轉寄規則包含轉寄條件和轉寄動作。您可以自訂轉寄條件，指定請求的網域名稱、路徑、要求標頭、查詢字串、要求方法、Cookie、源IP等。您也可以自訂轉寄動作，配置固定響應、重新導向、插入要求標頭、刪除要求標頭、流量鏡像、轉寄至後端多伺服器組和重寫。本文介紹如何自訂ALB Ingress的轉寄規則。

前提條件

已安裝ALB Ingress Controller組件，且組件為v2.5.0及以上版本。具體操作，請參見管理組件。

轉寄條件

重要

轉寄規則的條件條目上限為10個，一旦達到規定數量上限，您將無法再添加更多的條件。
轉寄條件ResponseHeader和ResponseStatusCode僅在自訂回應程式向轉寄規則中有效。

轉寄條件介紹

ALB Ingress支援在alb.ingress.kubernetes.io/conditions.<Service的名稱>註解中配置轉寄條件。不同的路由規則塊是與的關係，同一個路由規則塊中的值是或的關係，例如，如果是兩個不同的Header規則塊，那這兩個規則塊是與的關係，但是同一個Header規則塊中設定的值是或的關係。詳細的路由規則說明如下。

轉寄條件	描述
網域名稱	匹配請求網域名稱，只有正確的網域名稱的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.host-example: \| [{ "type": "Host", "hostConfig": { "values": [ "anno.example.com" ] } }]` type：匹配類型。設定為Host，表示匹配網域名稱。 HostConfig：匹配的具體網域名稱。如果設定了多個網域名稱，則網域名稱之間是或的關係。
路徑	匹配請求路徑，只有正確的路徑的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.path-example: \| [{ "type": "Path", "pathConfig": { "values": [ "/pathvalue1", "/pathvalue2" ] } }]` type：匹配類型。設定為Path，表示匹配請求路徑。 pathConfig：匹配的具體路徑。如果設定了多個路徑，則路徑之間是或的關係。
Header	匹配請求Header，只有正確的Header的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.http-header-example: \| [{ "type": "Header", "headerConfig": { "key": "headername", "values": [ "headervalue1" "headervalue2" ] } }]` type：匹配類型。設定為Header，表示匹配要求標頭中的Header。 headerConfig：Header的索引值對。如果設定了多個Header值，則Header之間是或的關係。
查詢字串	匹配查詢字串，只有包含正確的查詢字串的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.query-string-example: \| [{ "type": "QueryString", "queryStringConfig": { "values": [ { "key":"querystringkey1", "value":"querystringvalue2" } ] } }]` type：匹配類型。設定為QueryString，表示匹配請求的查詢字串。 queryStringConfig：查詢字串的索引值對。鍵字元長度取值為[1,100]，值字元長度取值為[1,100]，支援小寫字母、可見字元和萬用字元星號（*）和英文半形問號（?），不支援空格和`#[]{}\\|<>&`。如果設定了多個查詢字串，則查詢字串之間是或的關係。
要求方法	匹配要求方法，只有正確的要求方法的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.http-method-example: \| [{ "type": "Method", "methodConfig": { "values": [ "GET", "HEAD" ] } }]` type：匹配類型。設定為Method，表示匹配要求方法。 methodConfig：具體的要求方法，支援GET、POST、PUT、DELETE、HEAD、OPTIONS和PATCH。如果設定了多個要求方法，則要求方法之間是或的關係。
Cookie	匹配Cookie，只有包含正確的Cookie的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.http-cookie-example: \| [{ "type": "Cookie", "cookieConfig": { "values": [ { "key":"cookiekey1", "value":"cookievalue2" } ] } }]` type：匹配類型。設定為Cookie，表示匹配Cookie。 cookieConfig：Cookie的索引值對。鍵字元長度取值為[1,100]，值字元長度取值為[1,100]，支援小寫字母、可見字元和萬用字元星號（*）和英文半形問號（?），不支援空格和`#[]{}\\|<>&`。如果設定了多個Cookie，則Cookie之間是或的關係。
SourceIP	匹配請求源IP，只有正確的源IP的請求才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.source-ip-example: \| [{ "type": "SourceIp", "sourceIpConfig": { "values": [ "192.168.0.0/16", "172.16.0.0/16" ] } }]` type：匹配類型。設定為SourceIP，表示匹配請求的源IP。 sourceIpConfig：請求的IP地址。如果設定了多個請求IP，則請求IP之間是或的關係。
ResponseHeader	匹配響應Header，只對攜帶正確Header的響應執行轉寄動作。樣本如下。 `alb.ingress.kubernetes.io/conditions.response-header-example: \| [{ "type": "ReponseHeader", "headerConfig": { "key": "headername", "values": [ "headervalue1" "headervalue2" ] } }]` type：匹配類型。設定為ResponseHeader，表示匹配回應標頭中的Header。 headerConfig：Header的索引值對。如果設定了多個Header值，則Header之間是或的關係。
ResponseStatusCode	匹配響應狀態代碼，只有返回正確的狀態代碼才能訪問服務。樣本如下。 `alb.ingress.kubernetes.io/conditions.response-code-example: \| [{ "type": "ResponseStatusCode", "responseStatusCodeConfig": { "values": [ "statuscode1", "statuscode2" ] } }]` type：匹配類型。設定為`ResponseStatusCode`，表示匹配響應狀態代碼。 responseStatusCodeConfig：具體的響應狀態代碼。如果設定了多個響應狀態代碼，則響應狀態代碼之間是或的關係。

情境一：基於SourceIP和Header實現流量分發

重要

同一條轉寄規則的自訂條件設定的SourceIp數量限制為5個。

以下代碼塊定義了僅當請求的IP、Header和路徑符合配置時，才能實現目標流量分發。

即當請求源IP為192.168.0.0/16或172.16.0.0/16中的IP地址，請求Header中包含gray-hello，值必須為value1或value2，請求路徑為/hello，請求才能路由到gray-hello服務，否則將路由到其他服務。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/order: "1"
   alb.ingress.kubernetes.io/conditions.gray-hello: |
     [{
       "type": "Header",
       "headerConfig": {
          "key":"gray-hello",
           "values": [
              "value1",
              "value2"
           ]
       }
      },
      {
         "type": "SourceIp",
         "sourceIpConfig": {
           "values": [
             "192.168.0.0/16",
             "172.16.0.0/16"
           ]
         }
     }]
  name: gray-hello
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /hello
        pathType: ImplementationSpecific
        backend:
          service:
            name: gray-hello
            port:
              number: 88

alb.ingress.kubernetes.io/order：標識Ingress的優先順序，數字越小，優先順序越高。

情境二：基於網域名稱、要求方法、Cookie實現流量分發

以下代碼塊定義了僅當請求的網域名稱、要求方法和Cookie符合配置時，才能實現目標流量分發。

即當要求方法為GET或HEAD，請求網域名稱為www.hostvalue1.edu或www.hostvalue2.edu，請求Cookie的鍵為cookiekey1，值為cookievalue1，請求路徑為/test，請求才能路由到service-a服務，否則將路由到service-b服務。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.service-a: |
     [{
       "type": "Cookie",
       "cookieConfig": {
         "values": [
           {
             "key":"cookiekey1",
             "value":"cookievalue1"
           }
        ]
       }
      },
      {
       "type": "Method",
       "methodConfig": {
         "values": [
           "GET",
           "HEAD"
         ]
       }
      },
     {
       "type": "Host",
       "hostConfig": {
           "values": [
              "www.hostvalue1.edu",
              "www.hostvalue2.edu"
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-a
            port:
              number: 88
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-b
            port:
              number: 88

情境三：基於查詢字串、多個Header、多個路徑實現流量分發

以下代碼塊定義了僅當請求的查詢字串、Header、路徑符合配置時，才能實現目標流量分發。

即當請求路徑是/pathvalue1、/pathvalue2或/test，查詢字串的鍵為querystringkey1，值為querystringvalue2，請求Header中必須包含headerkey1和headerkey2，請求Header中包含headerkey1，值必須為headervalue1或headervalue2，請求Header包含headerkey2，值必須為headervalue3或headervalue4，才能路由到service-a服務，否則將路由到service-b服務。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.service-a: |
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "/pathvalue1",
              "/pathvalue2"
           ]
       }
      },
      {
       "type": "QueryString",
       "queryStringConfig": {
         "values": [
           {
             "key":"querystringkey1",
             "value":"querystringvalue2"
           }
        ]
       }
      },
     {
       "type": "Header",
       "headerConfig": {
          "key":"headerkey1",
           "values": [
              "headervalue1",
              "headervalue2"
           ]
       }
     },
     {
       "type": "Header",
       "headerConfig": {
          "key":"headerkey2",
           "values": [
              "headervalue3",
              "headervalue4"
           ]
       }
     }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-a
            port:
              number: 88
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-b
            port:
              number: 88

轉寄動作

轉寄動作介紹

ALB Ingress支援使用alb.ingress.kubernetes.io/actions.<服務名稱>註解配置請求方向和回應程式向的轉寄動作。支援固定響應、重新導向、插入要求標頭、刪除要求標頭、流量鏡像、轉寄至後端多伺服器組和重寫。通過定義這些轉寄動作，您可以在ALB Ingress中靈活地管理請求和響應的轉寄規則。

重要

alb.ingress.kubernetes.io/actions.<服務名稱>註解中的服務名稱必須和rule欄位backend下的服務名稱一致。
在同一條轉寄規則中，重新導向、固定響應、轉寄至多伺服器組等終結類型的轉寄動作不能同時使用。

配置重新導向、固定響應、轉寄至多伺服器組時，rule欄位backend下的servicePort的名稱必須為use-annotation。

請求方向的轉寄動作

轉寄動作	描述
固定響應	設定通過ALB給用戶端返回固定響應內容，可以設定響應狀態代碼，本文內容和本文類型。樣本如下。 `alb.ingress.kubernetes.io/actions.response-503: \| [{ "type": "FixedResponse", "FixedResponseConfig": { "contentType": "text/plain", "httpCode": "503", "content": "503 error text" } }]` type：轉寄動作類型，設定為FixedResponse，表示配置固定響應。 contentType：響應本文類型。 httpCode：響應狀態代碼。 content：響應本文。
重新導向	通過HTTP 3xx狀態代碼，指導用戶端跳轉到其他地址訪問服務。樣本如下。重要除了httpCode，重新導向的其他參數不能都設定為預設值。 `alb.ingress.kubernetes.io/actions.redirect: \| [{ "type": "Redirect", "RedirectConfig": { "host": "${host}", "path": "${path}", "port": "${port}", "protocol": "${protocol}", "query": "${query}", "httpCode": "301" } }]` type：轉寄動作類型，設定為Redirect，表示配置重新導向。 host：跳轉的網域名稱 path：跳轉的路徑。 port：跳轉的連接埠 protocol：跳轉的協議 query：跳轉的查詢字串。 httpCode：狀態代碼。
流量鏡像	設定流量鏡像轉寄伺服器組ID，將複製請求轉寄至流量鏡像伺服器組。樣本如下。重要流量鏡像轉寄動作只能和轉寄、寫入Header、刪除Header、流量限速共存，不能和重寫、固定響應、重新導向共存。流量鏡像伺服器組只支援通過ServerGroupID掛載。 `alb.ingress.kubernetes.io/actions.traffic-mirror: \| [{ "type": "TrafficMirror", "TrafficMirrorConfig": { "TargetType" : "ForwardGroupMirror", "MirrorGroupConfig": { "ServerGroupTuples" : [{ "ServerGroupID": "sgp-2auud2fxj1r46*****" }] } } }]` type：轉寄動作類型，設定為TrafficMirror，表示配置流量鏡像功能。 TargetType：鏡像的目標類型，當前只支援ForwardGroupMirror類型，即鏡像請求至伺服器組。 ServerGroupID：流量鏡像伺服器組ID。
轉寄至後端多伺服器組	設定將ALB請求轉寄至後端多個伺服器組，可以通過ServerGroupID指定後端掛載的伺服器組，也可以通過ServiceName+ServicePort建立或掛載伺服器組。可以佈建要求轉寄至各後端伺服器組的權重。樣本如下。重要標準版ALB執行個體最多掛載5個伺服器組。如果同時通過ServerGroupID與ServiceName+ServicePort掛載伺服器組，優先根據ServerGroupID匹配後端伺服器組。 `alb.ingress.kubernetes.io/actions.forward: \| [{ "type": "ForwardGroup", "ForwardConfig": { "ServerGroups" : [{ "ServiceName": "tea-svc", "Weight": 30, "ServicePort": 80 }, { "ServiceName": "coffee-svc", "Weight": 20, "ServicePort": 80 }, { "ServerGroupID": "sgp-71aexb9y93ypo***", "Weight": 20 }, { "ServerGroupID": "sgp-slygpbvm2cydo***", "Weight": 30 }] } }]` type：轉寄動作類型，設定為ForwardGroup，表示配置轉寄至後端多伺服器組。 ForwardConfig：後端轉寄伺服器組具體參數。如果設定了多個伺服器組，請求按照權重轉寄至各伺服器組。 ServerGroupID：伺服器組ID。 ServiceName：服務的名稱。 ServicePort：服務的連接埠。 Weight：請求轉寄至各伺服器組權重。
重寫	設定ALB支援重寫，將覆蓋請求的網域名稱、路徑和字串。樣本如下。重要重寫轉寄動作與註解項`rewrite-target`衝突，不可以重複。重寫目前不可與固定響應和重新導向轉寄動作共用。 `alb.ingress.kubernetes.io/actions.rewrite: \| [{ "type": "Rewrite", "RewriteConfig": { "Host": "demo.domain.ingress.top", "Path": "/test", "Query": "querystring" } }]` type：轉寄動作類型，設定為Rewrite時，表示當前ALB支援Rewrite重寫。 RewriteConfig：重寫的具體參數。 Host：重寫匹配的具體網域名稱。 Path：重寫匹配的具體路徑。 Query：重寫匹配的具體字串。更多Rewrite重寫規則，請參見支援Rewrite重寫。
插入要求標頭	設定頭欄位名稱和頭欄位內容，將覆蓋請求中已有的頭變數。樣本如下。 `alb.ingress.kubernetes.io/actions.insert-header: \| [{ "type": "InsertHeader", "InsertHeaderConfig": { "key": "key", "value": "value", "valueType": "UserDefined" } }]` type：轉寄動作類型，設定為InsertHeader，表示配置插入要求標頭。 key：要求標頭的欄位名稱。 value：要求標頭的欄位內容。 valueType：實值型別。
刪除要求標頭	刪除頭欄位名稱和頭欄位內容。樣本如下。 `alb.ingress.kubernetes.io/actions.remove-header: \| [{ "type": "RemoveHeader", "RemoveHeaderConfig": { "key": "key" } }]` `type`：轉寄動作類型，設定為`RemoveHeader`，表示配置刪除要求標頭。 `key`：要求標頭的欄位名稱。

回應程式向的轉寄動作

轉寄動作

描述

插入要求標頭

設定頭欄位名稱和頭欄位內容，將覆蓋請求中已有的頭變數。樣本如下。

alb.ingress.kubernetes.io/actions.insert-header: |
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]

type：轉寄動作類型，設定為InsertHeader，表示配置插入要求標頭。
key：要求標頭的欄位名稱。
value：要求標頭的欄位內容。
valueType：實值型別。

刪除要求標頭

刪除頭欄位名稱和頭欄位內容。樣本如下。

alb.ingress.kubernetes.io/actions.remove-header: |
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

type：轉寄動作類型，設定為RemoveHeader，表示配置刪除要求標頭。

key：要求標頭的欄位名稱。

情境一：設定固定響應503狀態代碼和內容

以下代碼塊定義了請求服務時，將返回503狀態代碼和503 error text。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.response-503: |
      [{
          "type": "FixedResponse",
          "FixedResponseConfig": {
              "contentType": "text/plain",
              "httpCode": "503",
              "content": "503 error text"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: response-503
                port:
                  name: use-annotation

情境二：使用301重新導向到HTTPS連接埠

以下代碼塊定義了請求服務時，將重新導向到服務的HTTPS連接埠。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.redirect: |
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "${host}",
              "path": "${path}",
              "port": "${port}",
              "protocol": "https",
              "query": "${query}",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: redirect
                port:
                  name: use-annotation

情境三：插入source: alibaba要求標頭

以下代碼塊定義了請求服務時，將使用source: alibaba覆蓋原有要求標頭。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.insert-header: |
      [{
          "type": "InsertHeader",
          "InsertHeaderConfig": {
              "key": "source",
              "value": "alibaba",
              "valueType": "UserDefined"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: insert-header
                port:
                  number: 80

情境四：流量鏡像至伺服器組

以下代碼塊定義了請求服務時，將複製請求至流量鏡像伺服器組。

登入應用型負載平衡ALB控制台，在左側導覽列選擇應用型負載平衡 ALB > 伺服器組，在伺服器組頁面擷取伺服器組ID。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
   alb.ingress.kubernetes.io/actions.traffic-mirror: |
       [{
           "type": "TrafficMirror",
           "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
       }]
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: traffic-mirror
            port:
              number: 80

情境五：請求轉寄至多個後端伺服器組

以下代碼塊定義了請求服務時，將請求轉寄至叢集內多個服務。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.forward: |
       [{
           "type": "ForwardGroup",
           "ForwardConfig": {
             "ServerGroups" : [{
               "ServiceName": "tea-svc",
               "Weight": 80,
               "ServicePort": 80
             },
             {
               "ServiceName": "coffee-svc",
               "Weight": 20,
               "ServicePort": 80
             }]
           }
       }]
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /path
        pathType: Prefix
        backend:
          service:
            name: forward
            port:
              name: use-annotation

情境六：重寫請求配置資訊

以下代碼塊定義了請求服務時，重寫請求的網域名稱、路徑和字串。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.rewrite: |
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "Host": "demo.domain.ingress.top",
               "Path": "/test",
               "Query": "queryString"
           }
       }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /path
            pathType: Prefix
            backend:
              service:
                name: rewrite
                port:
                  port: 80

情境七：基於ResponseHeader對回應程式向的要求標頭進行修改

重要

自訂的ALB ingress轉寄規則在預設情況下為請求方向，如果您希望建立回應程式向的轉寄規則，則需要將註解項 alb.ingress.kubernetes.io/rule-direction.<Service的名稱> 配置為Response（該註解項預設配置為Request）。
當建立回應程式向的轉寄規則時，ingressSpec.rules.backend欄位下的servicePort的名稱必須為use-annotation。

以下代碼塊定義了當匹配到ResponseHeader時，即Header中包含response-hello，值必須為value1或value2，那麼將在Header中插入新的要求標頭source: alibaba。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/rule-direction.response-header: Response
   alb.ingress.kubernetes.io/conditions.response-header: |
     [{
         "type": "ResponseHeader",
         "responseHeaderConfig": {
            "key": "response-hello",
            "values": [
               "value1",
               "value2"
            ]
         }
     }]
   alb.ingress.kubernetes.io/actions.response-header: |
     [{
         "type": "InsertHeader",
         "InsertHeaderConfig": {
             "key": "source",
             "value": "alibaba",
             "valueType": "UserDefined"
         }
     }]
  name: response-header
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /
        pathType: ImplementationSpecific
        backend:
          service:
            name: response-header
            port:
              name: use-annotation

情境八：基於響應狀態代碼對回應程式向的要求標頭進行修改

重要

自訂的ALB ingress轉寄規則在預設情況為請求方向，如果您希望建立回應程式向的轉寄規則，則需要將註解項 alb.ingress.kubernetes.io/rule-direction.<Service的名稱> 配置為Response（該註解項預設配置為Request）。
當建立回應程式向的轉寄規則時，ingressSpec.rules.backend欄位下的servicePort的名稱必須為use-annotation。

以下代碼塊定義了僅當響應狀態代碼為200或300時，才會對要求標頭執行移除操作（將response-hello從請求Header中移除）。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/rule-direction.response-hello: Response
   alb.ingress.kubernetes.io/conditions.response-hello: |
     [{
       "type": "ResponseStatusCode",
       "responseStatusCodeConfig": {
         "values": [
             "200",
             "300"
         ]
       }
     }]
   alb.ingress.kubernetes.io/actions.response-hello: |
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "response-hello"
         }
     }]
  name: response-hello
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: response-hello
            port:
              name: use-annotation