すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:ACKコンソールで、またはアノテーションを設定して、ALB Ingressのルーティングルールをカスタマイズする

最終更新日:Dec 14, 2024

Application Load Balancer (ALB) Ingressを使用すると、カスタムルーティングルールを設定できます。 ルーティングルールは、ルーティング条件とアクションで構成されます。 ドメイン名、パス、リクエストヘッダー、クエリ文字列、リクエストメソッド、Cookie、またはリクエストの送信元IPアドレスに一致するルーティング条件を追加できます。 ルーティングアクションを追加して、固定応答の返信、リクエストのリダイレクト、リクエストヘッダーの挿入、リクエストヘッダーの削除、トラフィックのミラーリング、複数のバックエンドサーバーグループへのリクエストの転送、またはリクエストの書き換えを行うこともできます。 Container Service for Kubernetes (ACK) コンソールで、またはIngressでAnnotationsパラメーターを設定することで、ALB Ingressのルーティングルールをカスタマイズできます。

目次

カスタムルール

シナリオ

ルーティング条件

ルーティングアクション

ルーティング条件とアクションの設定方法

シナリオ1: ドメイン名ベースのルーティング条件とアクションを設定して、トラフィックを特定のサービスにルーティングする

前提条件

ALB Ingressコントローラー2.5.0以降がクラスターにインストールされています。 詳細については、「コンポーネントの管理」をご参照ください。

ルーティング条件

重要
  • 1つのルーティングルールに最大10のルーティング条件を追加できます。

  • ルーティング条件ResponseHeaderおよびResponseStatusCodeは、カスタム送信ルーティングルールでのみ有効です。

ルーティング条件の概要

ALB ingressでは、alb.ingress.kubernetes.io/conditions.<Service name> アノテーションでルーティング条件を設定できます。 異なるルールブロック間の論理関係はANDである。 ルールブロックに複数の値を指定した場合, 値の論理関係はORです。 たとえば、2つのヘッダールールブロックを設定した場合、2つのヘッダールールブロック間の論理関係はANDです。 ヘッダールールブロックで複数のヘッダーを設定した場合、ヘッダー間の論理的な関係はORです。 次の表に、ALB Ingressに対して作成できるルーティングルールを示します。

ルーティング条件

説明

ドメイン名

この条件を追加して、指定したドメイン名宛てのリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.host-example: |
  [{
      "type": "Host",
      "hostConfig": {
        "values": [
          "anno.example.com"
        ]
      }
  }]
  • type: ルーティング条件のタイプ。 ドメイン名に基づいてリクエストを照合するには、値をHostに設定します。

  • HostConfig: リクエストの照合に使用されるドメイン名。 複数のドメイン名を指定した場合, ドメイン名の論理関係はORになります。

パス

この条件を追加して、指定したパスに送信されたリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.path-example: |
  [{
    "type": "Path",
    "pathConfig": {
      "values": [
        "/pathvalue1",
        "/pathvalue2"
      ]
    }
  }]
  • type: ルーティング条件のタイプ。 パスに基づいてリクエストを照合するには、値をPathに設定します。

  • pathConfig: リクエストの照合に使用されるパス。 複数のパスを指定した場合, パス間の論理関係はORとなります。

ヘッダー

この条件を追加して、指定したヘッダーを含むリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.http-header-example: |
  [{
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]
  • type: ルーティング条件のタイプ。 ヘッダーに基づいてリクエストを照合するには、値をヘッダーに設定します。

  • headerConfig: リクエストの照合に使用されるキーと値のペア。 複数のヘッダー間の論理関係はORです。

クエリ文字列

この条件を追加して、指定したクエリ文字列を含むリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.query-string-example: |
  [{
    "type": "QueryString",
    "queryStringConfig": {
      "values": [
        {
           "key":"querystringkey1",
           "value":"querystringvalue2"
        }
      ]
    }
  }]
  • type: ルーティング条件のタイプ。 クエリ文字列に基づいてリクエストを照合するには、値をQueryStringに設定します。

  • queryStringConfig: リクエストの照合に使用されるキーと値のペア。 キーと値の長さは1 ~ 100文字で、小文字、表示文字、アスタリスク (*) 、および疑問符 (?) を使用できます。 キーと値には、スペース文字や# [] {} \ | <> & の特殊文字を含めることはできません。 複数のクエリ文字列を指定した場合、クエリ文字列間の論理関係はORになります。

リクエストメソッド

この条件を追加して、指定したリクエストメソッドを使用するリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.http-method-example: |
  [{
    "type": "Method",
    "methodConfig": {
      "values": [
        "GET",
        "HEAD"
      ]
    }
  }]
  • type: ルーティング条件のタイプ。 リクエストメソッドに基づいてリクエストを照合するには、値をMethodに設定します。

  • methodConfig: リクエストの照合に使用されるリクエストメソッド。 サポートされるメソッドは、GET、POST、PUT、DELETE、HEAD、OPTIONS、およびPATCHです。 複数のリクエストメソッドを指定した場合, リクエストメソッド間の論理関係はORです。

Cookie

この条件を追加して、指定したCookieを含むリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.http-cookie-example: |
  [{
    "type": "Cookie",
    "cookieConfig": {
      "values": [
        {
           "key":"cookiekey1",
           "value":"cookievalue2"
        }
      ]
     }
  }]
  • type: ルーティング条件のタイプ。 Cookieに基づいてリクエストを照合するには、値をCookieに設定します。

  • cookieConfig: リクエストの照合に使用されるキーと値のペア。 キーと値の長さは1 ~ 100文字で、小文字、表示文字、アスタリスク (*) 、および疑問符 (?) を使用できます。 キーと値には、スペース文字や# [] {} \ | <> & の特殊文字を含めることはできません。 複数のCookieを指定した場合, Cookie間の論理関係はORになります。

SourceIP

この条件を追加して、指定した送信元IPアドレスからのリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.source-ip-example: |
  [{
    "type": "SourceIp",
    "sourceIpConfig": {
      "values": [
        "192.168.0.0/16",
        "172.16.0.0/16"
      ]
    }
  }]
  • type: ルーティング条件のタイプ。 送信元IPアドレスに基づいてリクエストを照合するには、値をSourceIPに設定します。

  • sourceIpConfig: リクエストの照合に使用される送信元IPアドレス。 複数の送信元IPアドレスを指定した場合、送信元IPアドレス間の論理関係はORになります。

ResponseHeader

この条件を追加して、指定したレスポンスヘッダーを含むレスポンスのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.response-header-example: |
  [{
    "type": "ResponseHeader",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]
  • type: ルーティング条件のタイプ。 レスポンスヘッダーに基づいてレスポンスを照合するには、値をResponseHeaderに設定します。

  • headerConfig: レスポンスの照合に使用されるキーと値のペア。 複数のヘッダー間の論理関係はORです。

ResponseStatusCode

この条件を追加して、指定したステータスコードを返すリクエストのみをルーティングできます。 サンプルコード:

alb.ingress.kubernetes.io/conditions.response-code-example: |
  [{
    "type": "ResponseStatusCode",
    "responseStatusCodeConfig": {
      "values": [
        "statuscode1",
        "statuscode2"
      ]
    }
  }]
  • type: ルーティング条件のタイプ。 応答ステータスコードに基づいてリクエストを照合するには、値をResponseStatusCodeに設定します。

  • responseStatusCodeConfig: 指定された応答ステータスコード。 レスポンスステータスコードを複数指定した場合, コード間の論理関係はORになります。

シナリオ1: 送信元IPアドレスとリクエストヘッダーに基づいてトラフィックをルーティングする

重要

1つのルーティングルールに対して、最大5つのソースIPアドレスをカスタム条件に追加できます。

次のコードブロックは、送信元IPアドレス、リクエストヘッダー、およびパスに基づいてパケットをルーティングするために使用されます。

次のコードブロックでは、ソースIPアドレスは192.168.0.0/16および172.16.0.0/16に設定され、ヘッダーキーはgray-helloに設定され、ヘッダー値はvalue1およびvalue2に設定され、パスは /helloに設定されます。 送信元IPアドレス、ヘッダー、およびパスが上記のすべての条件と一致するリクエストのみが、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の優先順位。 数字が小さいほど、優先度が高くなります。

シナリオ2: ドメイン名、リクエストメソッド、およびCookieに基づいてトラフィックをルーティングする

次のコードブロックは、ドメイン名、リクエストメソッド、およびCookieに基づいてパケットをルーティングするために使用されます。

次のコードブロックでは、リクエストメソッドはGETHEADに設定され、ドメイン名はexample.com*.eduに設定され、cookieのキーはcookiekey1に設定され、cookieの値はcookievalue1に設定され、パスは /testに設定されます。 ドメイン名、リクエストメソッド、Cookie、およびパスが上記のすべての条件と一致するリクエストのみが、gray-helloサービスにルーティングされます。 その他のリクエストは、サービス-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": [
              "example.com",
              "*.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

シナリオ3: クエリ文字列、複数のリクエストヘッダー、および複数のパスに基づいてトラフィックをルーティングする

次のコードブロックは、クエリ文字列、複数のリクエストヘッダー、および複数のパスに基づいてパケットをルーティングするために使用されます。

次のコードブロックでは、パスは /pathvalue1/pathvalue2、および /testに設定され、クエリ文字列キーはquerystringkey1に設定され、クエリ文字列値はquerystringvalue2に設定されます。 さらに、コードブロックは、リクエストにheaderkey1headerkey2を含める必要があることを指定します。 headerkey1のヘッダー値はheadervalue1またはheadervalue2で、headervalue2のヘッダー値はheadervalue3またはheadervalue4である必要があります。 クエリ文字列、リクエストヘッダー、およびパスが上記のすべての条件と一致するリクエストのみが、サービス-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.<Service name> アノテーションで、インバウンドおよびアウトバウンドルーティングルールのルーティングアクションを設定できます。 ルーティングアクションを追加して、固定応答の返信、リクエストのリダイレクト、リクエストヘッダーの挿入、リクエストヘッダーの削除、トラフィックのミラーリング、複数のバックエンドサーバーグループへのリクエストの転送、またはリクエストの書き換えを行うことができます。 ALB Ingressでは、要求と応答をオンデマンドで処理するためのさまざまなルーティングアクションを定義できます。

重要
  • alb.ingress.kubernetes.io/actions.<Service name> アノテーションのサービス名は、ルールフィールドのバックエンドで指定されたサービス名と同じである必要があります。

  • 同じルーティングルールでは、複数の終了アクションを同時に追加することはできません。 たとえば、ルーティングアクションを追加して、固定応答を返す、リクエストをリダイレクトする、または複数のバックエンドサーバーグループにリクエストを同時に転送することはできません。

  • ルーティングアクションを追加して、固定応答を返す、リクエストをリダイレクトする、またはリクエストを複数のバックエンドサーバーグループに転送する場合、ルールフィールドのバックエンドに指定されたサービスポートの名前はuse-annotationである必要があります。

受信ルーティングルールのルーティングアクション

ルーティングアクション

説明

固定レスポンスを返す

固定コンテンツをクライアントに返すようにALB Ingressを設定できます。 クライアントに返されるステータスコード、コンテンツ、およびコンテンツの種類を指定できます。 サンプルコード:

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": "443",
          "protocol": "${protocol}",
          "query": "${query}",
          "httpCode": "301"
      }
  }]
  • type: ルーティングアクションのタイプ。 リクエストをリダイレクトするには、値をredirectに設定します。

  • host: リクエストのリダイレクト先のドメイン名。

  • path: リクエストのリダイレクト先のパス。

  • port: リクエストのリダイレクト先のポート。

  • protocol: リダイレクトされたリクエストのプロトコル。

  • query: リダイレクトされたリクエストのクエリ文字列。

  • httpCode: リダイレクトされたリクエストのステータスコード。

ミラートラフィック

サーバーグループのIDを指定して、指定したサーバーグループにトラフィックをミラーリングできます。 サンプルコード:

重要
  • トラフィックミラーリングアクションは、要求の転送、ヘッダーの書き込み、ヘッダーの削除、トラフィックのスロットルに使用されるアクションと一緒にのみ使用できます。 このアクションは、要求の書き換え、固定応答の返信、および要求のリダイレクトに使用されるアクションと相互に排他的です。

  • ServerGroupIDパラメーターのみを使用して、トラフィックがミラーリングされるサーバーグループを指定できます。

alb.ingress.kubernetes.io/actions.traffic-mirror: |
      [{
          "type": "TrafficMirror",
          "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
      }]
  • type: アクションのタイプ。 トラフィックをミラーリングするには、値をTrafficMirrorに設定します。

  • TargetType: トラフィックがミラーリングされる宛先のタイプ。 指定したサーバーグループにトラフィックをミラーリングするには、値をForwardGroupMirrorに設定します。

  • ServerGroupID: トラフィックがミラーリングされるサーバーグループのID。

複数のバックエンドサーバーグループにリクエストを転送する

リクエストを複数のバックエンドサーバーグループに転送するには、ServerGroupIDフィールドを設定してサーバーグループIDを指定するか、ServiceNameとServicePortフィールドを設定してサーバーグループを作成または関連付ける必要があります。 各バックエンドサーバーグループの重みを指定し、サーバーグループのセッション維持を有効にすることもできます。

重要
  • 最大5つのバックエンドサーバーグループを標準ALBインスタンスに関連付けることができます。

  • バックエンドサーバーグループを関連付けるためにServerGroupIDServiceName、およびServicePortフィールドを同時に設定した場合、ServerGroupIDフィールドが優先されます。

  • セッション維持を有効にすると、ALB Ingressは同じセッションに属するリクエストを同じバックエンドサーバーグループに転送します。

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
             }]
             "ServerGroupStickySession": {
              "Enabled": true,
              "Timeout": 80
             }
           }
       }]
  • type: アクションのタイプ。 リクエストを複数のバックエンドサーバーグループに転送するには、値をForwardGroupに設定します。

  • ForwardConfig: バックエンドサーバーグループの設定。 リクエストは、重みに基づいて複数のサーバーグループに転送されます。

  • ServerGroupId: サーバーグループのID。

  • ServiceName: ALBインスタンスを使用して公開されるサービスの名前。

  • ServicePort: サービスポート。

  • Weight: サーバーグループの重み。

  • Enabled: サーバーグループのセッション維持を有効にします。

  • タイムアウト: セッション維持のタイムアウト期間。

書き換えリクエスト

ALBインスタンスの書き換えルールを設定すると、リクエストのドメイン名、パス、およびクエリ文字列が書き換えられます。 サンプルコード:

重要
  • 書き換えアクションは、書き換え対象のアノテーションと競合します。 書き換えアクションの設定時に、書き換え対象のアノテーションを指定しないでください。

  • ルーティングアクションを追加して、書き換え要求と固定応答を同時に返すことはできません。 書き換え要求とリダイレクト要求にルーティングアクションを同時に追加することはできません。

alb.ingress.kubernetes.io/actions.rewrite: |
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "Host": "demo.domain.ingress.top",
               "Path": "/test",
               "Query": "querystring"
           }
       }]
  • type: アクションのタイプ。 リクエストを書き換えるには、値を書き換えに設定します。

  • RewriteConfig: 書き換えルールの設定。

  • ホスト: 一致したドメイン名を書き換えます。

  • パス: 一致したパスを書き換えます。

  • Query: 一致したクエリ文字列を書き換えます。

書き換えルールの詳細については、「書き換えルールの設定」をご参照ください。

リクエストヘッダーの挿入

ヘッダーフィールドの名前と値を指定して、リクエスト内の既存のヘッダー変数を上書きできます。 サンプルコード:

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: 削除するヘッダーフィールドの名前。

QPSスロットル

ALBインスタンスの転送ルールを設定する場合、クライアントIPアドレスに基づいてグローバルリクエストレート制限とリクエストレート制限を設定できます。

サンプルコード:

重要
  • 1秒あたりのクエリ (QPS) スロットリングアクションは、リクエストをサーバーグループに転送するアクションとともに使用する必要があります。

  • X-Forwarded-Forヘッダーに、X-Forwarded-For: <client-IP-address> 、<proxy1> 、<proxy2> 、... などの複数のipアドレスが含まれている場合、左端のアドレスはクライアントIPアドレスです。 クライアントIPアドレスに基づいてリクエストレート制限を設定する場合は、リスナーの詳細ページでクライアントIPアドレスを取得するためのスイッチをオンにする必要があります。 この方法では、X-Forwarded-Forヘッダーを使用してクライアントIPアドレスを保持できます。 詳細については、「XForwardedForConfig」をご参照ください。

 annotations:
    alb.ingress.kubernetes.io/actions.traffic-limit: |
      [{
          "type": "TrafficLimit",
          "TrafficLimitConfig": {
              "QPS": "1000",
              "QPSPerIp": "100"
          }
      }]
  • type: ルーティングアクションのタイプ。 この例では、値はTrafficLimitに設定され、レート制限を示します。

  • QPS: グローバルリクエストレートの制限。1秒あたりに処理できるリクエストの最大数を示します。 有効な値: 1 ~ 1000000 リクエストレートが指定された値を超えると、新しい接続リクエストは拒否され、クライアントはHTTPステータスコード503を受け取ります。

  • QPSPerIp: クライアントIPアドレスに基づくリクエストレートの制限。 有効な値: 1 ~ 1000000 QPS (グローバルレート制限) とQPSPerIp (クライアントIPアドレスに基づくレート制限) の両方が設定されている場合、QPSPerIpの値はQPSの値より小さくなければなりません。 リクエストレートが指定された値を超えると、新しい接続リクエストは拒否され、クライアントはHTTPステータスコード503を受け取ります。

アウトバウンドルーティング規則のルーティングアクション

ルーティングアクション

説明

リクエストヘッダーの挿入

ヘッダーフィールドの名前と値を指定して、リクエスト内の既存のヘッダー変数を上書きできます。 サンプルコード:

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: 削除するヘッダーフィールドの名前。

シナリオ1: ステータスコード503と固定コンテンツを返す

ACKコンソールの使用

  1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ネットワーク] > [Ingress] を選択します。

  3. [Ingress] ページで、[Ingressの作成] をクリックします。 [Ingressの作成] ダイアログボックスで、パラメーターを設定します。

    パラメーター

    説明

    ゲートウェイタイプ

    要件に基づいて、ALBMSE Cloud-native Gateway、またはNginxを選択できます。

    3つのゲートウェイタイプの違いの詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。

    ALB

    名前

    Ingressの名前を指定します。

    Ingress

    Ingressクラス

    Ingressに関連付けられたIngressClassを指定します。

    alb

    ルール

    [+ ルールの追加] をクリックして、Ingressルールを追加します。

    • ドメイン名: カスタムドメイン名を指定します。

    • マッピング: 次のパラメーターを指定します。

      • パス: バックエンドサービスのURLパスを指定します。 この例では、ルートパス /が使用されます。

      • ルール: [プレフィックス (プレフィックスベースの一致)][完全一致] 、または [ImplementationSpecific (デフォルト値)] を選択できます。

      • サービス: バックエンドサービスを選択します。

      • ポート: 公開するサービスポートを指定します。

    • ドメイン名に複数のパスを設定できます。 [+ 追加] をクリックしてパスを追加します。

    • ドメイン名: このパラメーターは空のままにします。

    • マッピング:

      • パス: /。

      • ルール: デフォルトではプレフィックス (プレフィックスベースの一致) が選択されています。

      • サービス: 応答503。

      • ポート: 80。

    TLS設定

    TLS認証を有効にするかどうかを指定します。 IngressのTLS認証を有効にできます。

    • ドメイン名: カスタムドメイン名。

    • シークレット: 使用するシークレットを選択します。

      シークレットを作成するには、次の手順を実行します。

      1. Secretフィールドの右側にある [作成] をクリックします。

      2. [シークレットの作成] ダイアログボックスで、[名前][証明書] 、および [キー] パラメーターを設定します。 [OK] をクリックします。

      3. [シークレット] ドロップダウンリストから作成したシークレットを選択します。

    [+ 追加] をクリックすると、さらにTLS証明書を追加できます。

    Ingress設定の詳細については、「高度なNGINX Ingress設定」をご参照ください。

    TLS設定をオフにします。 この例では、TLS証明書を設定する必要はありません。

    その他

    • カナリアリリース: カナリアリリースを有効にします。 リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースルールを設定できます。

      説明

      カナリアリリースルールは、リクエストヘッダー、Cookie、および重みのいずれかの要素のみに基づいて設定できます。 リクエストヘッダー、Cookie、および重みに基づいて、カナリアリリースルールを同時に設定することもできます。 この場合、リクエストヘッダー、Cookie、および重みは、優先順位の高い順に有効になります。

      • [リクエストヘッダーに基づく]: nginx.ingress.kubernetes.io/canary-by-Headernginx.ingress.kubernetes.io/canary-by-header-value、またはnginx.ingress.kubernetes.io/canary-by-header-pattern注釈を追加して、リクエストヘッダーに基づいてトラフィックを分散します。

      • Cookieに基づく: nginx.ingress.kubernetes.io/canary-by-cookie注釈を追加して、Cookieに基づいてトラフィックを配布します。

      • [重みに基づく]: nginx.ingress.kubernetes.io/canary-Weightアノテーションを追加して、サービスの重み (0〜100の整数) に基づいてトラフィックを分散します。

    • プロトコル: nginx.ingress.kubernetes.io/backend-Protocolアノテーションを追加して、バックエンドサービスで使用されるプロトコルを選択します。

      HTTP、HTTPS、gRPC、およびgRPCSがサポートされています。

    • パスの書き換え: nginx.ingress.kubernetes.io /Rewrite-targetアノテーションを追加して、リクエストがバックエンドサービスに転送される前にクライアントリクエストのパスを書き換えます。

    カナリアリリースをオフにします。 ProtocolおよびRewrite Pathパラメーターのデフォルト値を使用します。 この例では、これらのパラメーターを設定する必要はありません。

    カスタム転送ルール

    カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。

    説明

    転送ルールには最大10の条件を追加できます。

    • [条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。

      • ドメイン名:

        指定されたドメイン名を含むリクエストのみがルーティングされるように指定します。 複数のドメイン名の論理関係はORです。 ドメイン名を指定すると、alb.ingress.kubernetes.io/conditions.host-exampleアノテーションが追加されます。

      • パス:

        指定された1つ以上のパスを含むリクエストのみがルーティングされるように指定します。 複数のパスはOR関係で扱われます。 パスを指定すると、alb.ingress.kubernetes.io/conditions.path-exampleアノテーションが追加されます。

      • HTTPヘッダー:

        指定されたHTTPヘッダーを含むリクエストのみがルーティングされるように指定します。 各HTTPリクエストヘッダーはキーと値のペアです。 たとえば、keyheadernameに設定し、valueheadervalue1に設定できます。 複数のヘッダー値を指定した場合, ヘッダー値の論理関係はORになります。 ヘッダーを指定すると、alb.ingress.kubernetes.io/conditions.http-header-exampleアノテーションが追加されます。

    • [アクション] ドロップダウンリストでは、次のアクションを使用できます。

      リターン固定レスポンス

      ALBインスタンスによって固定コンテンツがクライアントに返されることを指定します。 クライアントに返されるステータスコード、コンテンツ、およびコンテンツの種類を指定できます。 ビジネス要件に基づいて、応答ステータスコード応答コンテンツタイプ (オプション) 、および応答コンテンツ (オプション) パラメーターを設定します。

      応答コンテンツタイプパラメーターの有効な値:

      • text/plain: コンテンツがプレーンテキストであることを示します。

      • text/css: コンテンツがXML形式であることを示します。

      • text/html: コンテンツがHTML形式であることを示します。

      • application/javascript: コンテンツがJavaScript形式であることを示します。

      • application/json: コンテンツがJSON形式であることを示します。

    • [条件の追加] ドロップダウンリストで、デフォルトで [パス] が選択されています。

    • [アクション] ドロップダウンリストで、[固定応答を返す] が選択されています。

      • 応答ステータスコード: 503。

      • 応答コンテンツタイプ (オプション): text/plain

      • 応答内容 (オプション): エラー。

    注釈

    カスタム注釈の名前と値を入力できます。 ドロップダウンリストから名前で注釈を選択または検索することもできます。 Ingressアノテーションの詳細については、「ALB Ingress GlobalConfigurationディクショナリ」をご参照ください。

    [+ 注釈の追加] をクリックして注釈を追加します。 ACKは、追加できるIngressアノテーションの数を制限しません。

    この例では、注釈を設定する必要はありません。

    ラベル

    Ingressの特性を表すラベルを追加できます。

    [+ ラベルの追加] をクリックしてラベルを追加します。 ACKは、追加できるIngressラベルの数を制限しません。

    この例では、ラベルを設定する必要はありません。

  4. 設定が完了したら、をクリックします。OK.

kubectl

次のコードブロックは、ステータスコード503と503エラーテキストを返すために使用されます。

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 # The name of the Service port must be use-annotation.

シナリオ2: 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": "443",
              "protocol": "https",
              "query": "${query}",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: redirect
                port:
                  name: use-annotation # The name of the Service port must be use-annotation.

シナリオ3: リクエストにsource: alibabaヘッダーを挿入する

次のコードブロックは、リクエスト内の既存のヘッダーをソースalibabaヘッダーで上書きするために使用されます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
  # The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in the backend parameter of the rule field. 
    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

シナリオ4: サーバーグループへのトラフィックのミラーリング

次のコードブロックは、トラフィックを指定されたサーバーグループにミラーリングするために使用されます。

Server Load Balancer (SLB) コンソールにログインします。 左側のナビゲーションウィンドウで、ALB > サーバーグループを選択します。 [サーバーグループ] ページで、サーバーグループのIDを表示できます。服务器组

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
  # mirror-svc must be one of the backend services specified below.
  # ALB Ingress will mirror the traffic forwarded to mirror-svc to the backend server specified in the ServerGroupID field.
  # If multiple Services need to configure traffic mirroring, add an annotation for each Service.
   alb.ingress.kubernetes.io/actions.mirror-svc: |
       [{
           "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: mirror-svc
            port:
              number: 80

シナリオ5: 複数のバックエンドサーバーグループにリクエストを転送する

ACKコンソールの使用

  1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ネットワーク] > [Ingress] を選択します。

  3. [Ingress] ページで、[Ingressの作成] をクリックします。 [Ingressの作成] ダイアログボックスで、パラメーターを設定します。

    パラメーター

    説明

    ゲートウェイタイプ

    要件に基づいて、ALBMSE Cloud-native Gateway、またはNginxを選択できます。

    3つのゲートウェイタイプの違いの詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。

    ALB

    名前

    Ingressの名前を指定します。

    forward-ingress

    Ingressクラス

    Ingressに関連付けられたIngressClassを指定します。

    alb

    ルール

    [+ ルールの追加] をクリックして、Ingressルールを追加します。

    • ドメイン名: カスタムドメイン名を指定します。

    • マッピング: 次のパラメーターを指定します。

      • パス: バックエンドサービスのURLパスを指定します。 この例では、ルートパス /が使用されます。

      • ルール: [プレフィックス (プレフィックスベースの一致)][完全一致] 、または [ImplementationSpecific (デフォルト値)] を選択できます。

      • サービス: バックエンドサービスを選択します。

      • ポート: 公開するサービスポートを指定します。

    • ドメイン名に複数のパスを設定できます。 [+ 追加] をクリックしてパスを追加します。

    • ドメイン名: demo. Domain. ingress.top

    • マッピング:

      • パス: /Path。

      • ルール: デフォルトではプレフィックス (プレフィックスベースの一致) が選択されています。

      • サービス: forward。

      • ポート: 80。

    TLS設定

    TLS認証を有効にするかどうかを指定します。 IngressのTLS認証を有効にできます。

    • ドメイン名: カスタムドメイン名。

    • シークレット: 使用するシークレットを選択します。 シークレットを作成するには、次の手順を実行します。

    1. Secretフィールドの右側にある [作成] をクリックします。

    2. [シークレットの作成] ダイアログボックスで、[名前][証明書] 、および [キー] パラメーターを設定します。 [OK] をクリックします。

    3. [シークレット] ドロップダウンリストから作成したシークレットを選択します。

    TLS設定をオフにします。 この例では、TLS証明書を設定する必要はありません。

    その他

    • カナリアリリース: カナリアリリースを有効にします。 リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースルールを設定できます。

      説明

      カナリアリリースルールは、リクエストヘッダー、Cookie、および重みのいずれかの要素のみに基づいて設定できます。 リクエストヘッダー、Cookie、および重みに基づいて、カナリアリリースルールを同時に設定することもできます。 この場合、リクエストヘッダー、Cookie、および重みは、優先順位の高い順に有効になります。

      • [リクエストヘッダーに基づく]: nginx.ingress.kubernetes.io/canary-by-Headernginx.ingress.kubernetes.io/canary-by-header-value、またはnginx.ingress.kubernetes.io/canary-by-header-pattern注釈を追加して、リクエストヘッダーに基づいてトラフィックを分散します。

      • Cookieに基づく: nginx.ingress.kubernetes.io/canary-by-cookie注釈を追加して、Cookieに基づいてトラフィックを配布します。

      • [重みに基づく]: nginx.ingress.kubernetes.io/canary-Weightアノテーションを追加して、サービスの重み (0〜100の整数) に基づいてトラフィックを分散します。

    • プロトコル: nginx.ingress.kubernetes.io/backend-Protocolアノテーションを追加して、バックエンドサービスで使用されるプロトコルを選択します。

      HTTP、HTTPS、gRPC、およびgRPCSがサポートされています。

    • パスの書き換え: nginx.ingress.kubernetes.io /Rewrite-targetアノテーションを追加して、リクエストがバックエンドサービスに転送される前にクライアントリクエストのパスを書き換えます。

    カナリアリリースをオフにします。 ProtocolおよびRewrite Pathパラメーターのデフォルト値を使用します。 この例では、これらのパラメーターを設定する必要はありません。

    カスタム転送ルール

    カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。

    説明

    転送ルールには最大10の条件を追加できます。

    • [条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。

      • ドメイン名:

        指定されたドメイン名を含むリクエストのみがルーティングされるように指定します。 複数のドメイン名の論理関係はORです。 ドメイン名を指定すると、alb.ingress.kubernetes.io/conditions.host-exampleアノテーションが追加されます。

      • パス:

        指定された1つ以上のパスを含むリクエストのみがルーティングされるように指定します。 複数のパスはOR関係で扱われます。 パスを指定すると、alb.ingress.kubernetes.io/conditions.path-exampleアノテーションが追加されます。

      • HTTPヘッダー:

        指定されたHTTPヘッダーを含むリクエストのみがルーティングされるように指定します。 各HTTPリクエストヘッダーはキーと値のペアです。 たとえば、keyheadernameに設定し、valueheadervalue1に設定できます。 複数のヘッダー値を指定した場合, ヘッダー値の論理関係はORになります。 ヘッダーを指定すると、alb.ingress.kubernetes.io/conditions.http-header-exampleアノテーションが追加されます。

    • [アクション] ドロップダウンリストでは、次のアクションを使用できます。

      転送先

      受信トラフィックを複数のバックエンドサーバーグループに転送します。 [サービス名] ドロップダウンリストからアクセスするサービスを選択します。 [ポート] ドロップダウンリストから、サービスへの接続に使用するポートを選択します。 各バックエンドサーバーグループのカスタム重みを指定します。

      説明
      • クラスターがFlannelコンポーネントを使用する場合、ClusterIPサービスはサポートされません。

      • [アクション] ドロップダウンリストから [転送] を選択した場合、ルールの [マッピング] パラメーターを設定する必要はありません。

    • [条件の追加] ドロップダウンリストで、[ドメイン名] が選択されます。 ドメイン名: demo. Domain. ingress.top

    • [操作] ドロップダウンリストで、[転送先] が選択されます。

      • サービス: tea-svc.

      • ポート: 80。

      • 重量: 80。

    • サービスの追加

      • サービス: coffee-svc.

      • ポート: 80。

      • 重量: 20。

    注釈

    カスタム注釈の名前と値を入力できます。 ドロップダウンリストから名前で注釈を選択または検索することもできます。 Ingressアノテーションの詳細については、「ALB Ingress GlobalConfigurationディクショナリ」をご参照ください。

    [+ 注釈の追加] をクリックして注釈を追加します。 ACKは、追加できるIngressアノテーションの数を制限しません。

    この例では、注釈を設定する必要はありません。

    ラベル

    Ingressの特性を表すラベルを追加できます。

    [+ ラベルの追加] をクリックしてラベルを追加します。 ACKは、追加できるIngressラベルの数を制限しません。

    この例では、ラベルを設定する必要はありません。

  4. 設定が完了したら、[Ingressの作成] パネルの左下隅にある [OK] をクリックします。

kubectl

次のコードブロックは、クラスター内の複数のサービスにリクエストを転送するIngressを定義します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
  # The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in backend of the rule field. 
    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 # The name of the Service port must be use-annotation.

シナリオ6: リクエストの書き換え

次のコードブロックは、ドメイン名、パス、およびリクエストのクエリ文字列を書き換えるIngressを定義します。

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

シナリオ7: ResponseHeaderに基づいて応答ヘッダーを変更する

重要
  • デフォルトでは、カスタムルーティングルールはインバウンド方向で有効になります。 カスタムルーティングルールをアウトバウンド方向で有効にするには、アノテーションalb.ingress.kubernetes.io/rule-direction.<Service name> をResponseに設定します。 アノテーションはデフォルトでリクエストに設定されています。

  • カスタム送信ルーティングルールを作成する場合、ingressSpec.ru les.backendフィールドのサービスポートの名前はuse-annotationである必要があります。

次のコードブロックでは、レスポンスヘッダーが一致すると (ヘッダーにresponse-helloが含まれ、値はvalue1またはvalue2である必要があります) 、新しいリクエストヘッダー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 # The name of the Service port must be use-annotation.

シナリオ8: 応答ステータスコードに基づいて応答ヘッダーを変更する

重要
  • デフォルトでは、カスタムルーティングルールはインバウンド方向で有効になります。 カスタムルーティングルールをアウトバウンド方向で有効にするには、アノテーションalb.ingress.kubernetes.io/rule-direction.<Service name> をResponseに設定します。 アノテーションはデフォルトでリクエストに設定されています。

  • カスタム送信ルーティングルールを作成する場合、ingressSpec.ru les.backendフィールドのサービスポートの名前はuse-annotationである必要があります。

次のコードブロックは、応答ステータスコードが200または300の場合にのみ、リクエストヘッダーが削除される (response-helloがリクエストヘッダーから削除される) ことを定義しています。

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 # The name of the Service port must be use-annotation.

ルーティング条件とアクションの設定方法

シナリオ1: ドメイン名ベースのルーティング条件とアクションを設定して、トラフィックを特定のサービスにルーティングする

このセクションでは、ACKコンソールでドメイン名ベースのルーティング条件とアクションを設定して、トラフィックを特定のサービスにルーティングする方法について説明します。

説明

ALB Ingressを作成する前に、次の手順を実行してバックエンドサービスをデプロイし、AlbConfigとIngressClassを作成します。

  1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ネットワーク] > [Ingress] を選択します。

  3. [Ingress] ページで、[Ingressの作成] をクリックします。 [Ingressの作成] ダイアログボックスで、パラメーターを設定します。

    パラメーター

    説明

    ゲートウェイタイプ

    要件に基づいて、ALBMSE Cloud-native Gateway、またはNginxを選択できます。

    3つのゲートウェイタイプの違いの詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。

    ALB

    名前

    Ingressの名前。

    alb_ingress

    Ingressクラス

    Ingressに関連付けられたIngressClassを指定します。

    alb

    ルール

    [+ ルールの追加] をクリックして、Ingressルールを追加します。

    • ドメイン名: カスタムドメイン名を指定します。

    • マッピング: 次のパラメーターを指定します。

      • パス: バックエンドサービスのURLパスを指定します。 この例では、ルートパス /が使用されます。

      • ルール: [プレフィックス (プレフィックスベースの一致)][完全一致] 、または [ImplementationSpecific (デフォルト値)] を選択できます。

      • サービス: バックエンドサービスを選択します。

      • ポート: 公開するサービスポートを指定します。

    • ドメイン名に複数のパスを設定できます。 [+ 追加] をクリックしてパスを追加します。

    • ドメイン名: * .example.com

    • マッピング:

      • パス: /tes

      • ルール: ImplementationSpecific。 デフォルト値です。

      • サービス: tea-svc.

      • ポート: 80。

    TLS設定

    TLS認証を有効にするかどうかを指定します。 IngressのTLS認証を有効にできます。

    • ドメイン名: カスタムドメイン名。

    • シークレット: 使用するシークレットを選択します。

      シークレットを作成するには、次の手順を実行します。

      1. Secretフィールドの右側にある [作成] をクリックします。

      2. [シークレットの作成] ダイアログボックスで、[名前][証明書] 、および [キー] パラメーターを設定します。 [OK] をクリックします。

      3. [シークレット] ドロップダウンリストから作成したシークレットを選択します。

    [+ 追加] をクリックすると、さらにTLS証明書を追加できます。

    詳細については、「ALB Ingressを使用したHTTPSリスナーの証明書の設定」をご参照ください。

    TLS設定をオフにします。 この例では、TLS証明書を設定する必要はありません。

    その他

    • カナリアリリース: カナリアリリースを有効にします。 リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースルールを設定できます。

      説明

      カナリアリリースルールは、リクエストヘッダー、Cookie、および重みのいずれかの要素のみに基づいて設定できます。 リクエストヘッダー、Cookie、および重みに基づいて、カナリアリリースルールを同時に設定することもできます。 この場合、リクエストヘッダー、Cookie、および重みは、優先順位の高い順に有効になります。

      • [リクエストヘッダーに基づく]: nginx.ingress.kubernetes.io/canary-by-Headernginx.ingress.kubernetes.io/canary-by-header-value、またはnginx.ingress.kubernetes.io/canary-by-header-pattern注釈を追加して、リクエストヘッダーに基づいてトラフィックを分散します。

      • Cookieに基づく: nginx.ingress.kubernetes.io/canary-by-cookie注釈を追加して、Cookieに基づいてトラフィックを配布します。

      • [重みに基づく]: nginx.ingress.kubernetes.io/canary-Weightアノテーションを追加して、サービスの重み (0〜100の整数) に基づいてトラフィックを分散します。

    • プロトコル: nginx.ingress.kubernetes.io/backend-Protocolアノテーションを追加して、バックエンドサービスで使用されるプロトコルを選択します。

      HTTP、HTTPS、gRPC、およびgRPCSがサポートされています。

    • パスの書き換え: nginx.ingress.kubernetes.io /Rewrite-targetアノテーションを追加して、リクエストがバックエンドサービスに転送される前にクライアントリクエストのパスを書き換えます。

    カナリアリリースをオフにします。 ProtocolおよびRewrite Pathパラメーターのデフォルト値を使用します。 この例では、これらのパラメーターを設定する必要はありません。

    カスタム転送ルール

    カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。

    説明

    転送ルールには最大10の条件を追加できます。

    • [条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。

      • ドメイン名:

        指定されたドメイン名を含むリクエストのみがルーティングされるように指定します。 複数のドメイン名の論理関係はORです。 ドメイン名を指定すると、alb.ingress.kubernetes.io/conditions.host-exampleアノテーションが追加されます。

      • パス:

        指定された1つ以上のパスを含むリクエストのみがルーティングされるように指定します。 複数のパスはOR関係で扱われます。 パスを指定すると、alb.ingress.kubernetes.io/conditions.path-exampleアノテーションが追加されます。

        重要

        転送条件を設定すると、Ingressはパス /created-by-<ALB-ID> の転送ルールを自動的に追加します。

      • HTTPヘッダー:

        指定されたHTTPヘッダーを含むリクエストのみがルーティングされるように指定します。 各HTTPリクエストヘッダーはキーと値のペアです。 たとえば、keyheadernameに設定し、valueheadervalue1に設定できます。 複数のヘッダー値を指定した場合, ヘッダー値の論理関係はORになります。 ヘッダーを指定すると、alb.ingress.kubernetes.io/conditions.http-header-exampleアノテーションが追加されます。

    • [アクション] ドロップダウンリストでは、次のアクションを使用できます。

      • 転送先

        受信トラフィックを複数のバックエンドサーバーグループに転送します。 [サービス名] ドロップダウンリストからアクセスするサービスを選択します。 [ポート] ドロップダウンリストから、サービスへの接続に使用するポートを選択します。 各バックエンドサーバーグループのカスタム重みを指定します。

        説明
        • クラスターにFlannelコンポーネントを使用する場合、ClusterIPサービスはサポートされません。

        • [アクション] ドロップダウンリストから [転送] を選択した場合、ルールの [マッピング] パラメーターを設定する必要はありません。

    • [条件の追加] ドロップダウンリストで、[ドメイン名][パス] 、および [HTTPヘッダー] が選択されます。

      • ドメイン名: example.com [+ ホストの追加] をクリックすると、s test.comなどのドメイン名を追加できます。

    • [操作] ドロップダウンリストで、[転送先] が選択されます。

      • サービス: tea-svc.

      • ポート: 80。

      • 重量: 100。

    注釈

    カスタム注釈の名前と値を入力できます。 ドロップダウンリストから名前で注釈を選択または検索することもできます。 Ingressアノテーションの詳細については、「アノテーション」をご参照ください。

    [+ 注釈の追加] をクリックして注釈を追加します。 ACKは、追加できるIngressアノテーションの数を制限しません。

    この例では、注釈を設定する必要はありません。

    ラベル

    Ingressの特性を表すラベルを追加できます。

    [+ ラベルの追加] をクリックしてラベルを追加します。 ACKは、追加できるIngressラベルの数を制限しません。

    この例では、ラベルを設定する必要はありません。

  4. 設定が完了したら、[Ingressの作成] パネルの左下隅にある [OK] をクリックします。

  5. Ingressが作成されたことを確認します。

    1. 左側のウィンドウで、[ネットワーク]> [Ingress] を選択します。 Ingressのページには、cafe-ingressという名前のIngressが表示されます。

    2. cafe-ingressの [エンドポイント] 列で、エンドポイントを表示します。