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

:高度なALBイングレス構成

最終更新日:Dec 27, 2024

アプリケーションロードバランサー(ALB)イングレスは、Kubernetesクラスター内のサービスへの外部アクセスを管理するためのレイヤー7ロードバランシングを提供するAPIオブジェクトです。このトピックでは、Alibaba Cloud Container Service(ACS)クラスターでALBイングレスを使用して、ドメイン名とURLパスに基づいてバックエンドサーバーグループにリクエストを転送する方法、HTTPリクエストをHTTPSにリダイレクトする方法、カナリアリリースを実装する方法について説明します。

前提条件

  • ACSクラスターが作成されていること。詳細については、ACSクラスターの作成を参照してください。

  • AlbConfigオブジェクトが作成されていること。詳細については、ALBイングレスの概要を参照してください。

ドメイン名に基づいてリクエストを転送する

次の手順を実行して、ドメイン名を持つイングレスとドメイン名を持たないイングレスを作成し、イングレスを使用してリクエストを転送します。

ドメイン名を持つイングレスを作成する

  1. 次のテンプレートを使用して、デプロイメント、サービス、およびイングレスを作成します。イングレスのドメイン名へのリクエストは、サービスに転送されます。

    apiVersion: v1
    kind: Service
    metadata:
      name: demo-service
      namespace: default
    spec:
      ports:
        - name: port1
          port: 80
          protocol: TCP
          targetPort: 8080
      selector:
        app: demo
      sessionAffinity: None
      type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: demo
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: demo
      template:
        metadata:
          labels:
            app: demo
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
              imagePullPolicy: IfNotPresent
              name: demo
              ports:
                - containerPort: 8080
                  protocol: TCP
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - host: demo.domain.ingress.top
          http:
            paths:
              - backend:
                  service:
                    name: demo-service
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific
  2. 次のコマンドを実行して、指定されたドメイン名を使用してアプリケーションにアクセスします。

    ADDRESSは、関連するALBインスタンスのIPアドレスに置き換えます。kubectl get ingコマンドを実行することで、IPアドレスを照会できます。

    curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

ドメイン名を持たないイングレスを作成する

  1. 次のテンプレートは、イングレスの構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - host: ""
          http:
            paths:
              - backend:
                  service:
                    name: demo-service
                    port: 
                      number: 80
                path: /hello
  2. 次のコマンドを実行して、ドメイン名を使用してアプリケーションにアクセスします。

    ADDRESSは、関連するALBインスタンスのIPアドレスに置き換えます。kubectl get ingコマンドを実行することで、IPアドレスを照会できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

URLパスに基づいてリクエストを転送する

ALBイングレスは、URLパスに基づいてリクエストを転送できます。pathTypeパラメーターを使用して、異なるURL一致ポリシーを構成できます。pathTypeの有効な値は、ExactImplementationSpecific、およびPrefixです。

説明

URL一致ポリシーは互いに競合する可能性があります。競合するURL一致ポリシーが存在する場合、リクエストはポリシーの優先順位の降順でこれらのポリシーと照合されます。詳細については、転送ルール優先順位の設定を参照してください。

一致モード

ルール

URLパス

URLパスがルールと一致するかどうか

Prefix

/

(すべてのパス)

はい

Prefix

/foo

  • /foo

  • /foo/

はい

Prefix

/foo/

  • /foo

  • /foo/

はい

Prefix

/aaa/bb

/aaa/bbb

いいえ

Prefix

/aaa/bbb

/aaa/bbb

はい

Prefix

/aaa/bbb/

/aaa/bbb

はい。URLパスはルールの末尾のスラッシュ(/)を無視します。

Prefix

/aaa/bbb

/aaa/bbb/

はい。ルールはURLパスの末尾のスラッシュ(/)と一致します。

Prefix

/aaa/bbb

/aaa/bbb/ccc

はい。ルールはURLパスのサブパスと一致します。

Prefix

同時に2つのルールを構成する:

  • /

  • /aaa

/aaa/ccc

はい。URLパスは/ルールと一致します。

Prefix

同時に2つのルールを構成する:

  • /aaa

  • /

/aaa/ccc

はい。URLパスは/aaaルールと一致します。

Prefix

同時に2つのルールを構成する:

  • /aaa

  • /

/ccc

はい。URLパスは/ルールと一致します。

Prefix

/aaa

/ccc

いいえ

ExactまたはImplementationSpecific

/foo

/foo

はい

ExactまたはImplementationSpecific

/foo

/bar

いいえ

ExactまたはImplementationSpecific

/foo

/foo/

いいえ

ExactまたはImplementationSpecific

/foo/

/foo

いいえ

次の手順を実行して、異なるURL一致ポリシーを構成できます。

Exact

  1. 次のテンプレートは、イングレスの構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo-path
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
            - path: /hello
              backend:
                service:
                  name: demo-service
                  port: 
                    number: 80
              pathType: Exact
  2. 次のコマンドを実行して、アプリケーションにアクセスします。

    ADDRESSは、関連するALBインスタンスのIPアドレスに置き換えます。kubectl get ingコマンドを実行することで、IPアドレスを照会できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

ImplementationSpecific:デフォルトの一致ポリシー

ALBイングレスの構成は、Exact一致ポリシーの場合と同じです。

  1. 次のテンプレートは、イングレスの構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo-path
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
            - path: /hello
              backend:
                service:
                  name: demo-service
                  port:
                    number: 80
              pathType: ImplementationSpecific
  2. 次のコマンドを実行して、アプリケーションにアクセスします。

    ADDRESSは、関連するALBインスタンスのIPアドレスに置き換えます。kubectl get ingコマンドを実行することで、IPアドレスを照会できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

Prefix

指定されたプレフィックスをURLパスと照合します。URLパスの要素はスラッシュ(/)で区切られます。プレフィックスは大文字と小文字が区別され、パスの各要素と照合されます。

  1. 次のテンプレートは、イングレスの構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo-path-prefix
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
            - path: /
              backend:
                service:
                  name: demo-service
                  port:
                    number: 80
              pathType: Prefix
  2. 次のコマンドを実行して、アプリケーションにアクセスします。

    ADDRESSは、関連するALBインスタンスのIPアドレスに置き換えます。kubectl get ingコマンドを実行することで、IPアドレスを照会できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

ヘルスチェックを設定する

次のアノテーションを使用して、ALBイングレスのヘルスチェックを設定できます。次のYAMLテンプレートは、ヘルスチェックが有効になっているイングレスを作成する方法の例を示しています。

次のYAMLテンプレートは、ヘルスチェックが有効になっているイングレスを作成する方法の例を示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # コンテキストパスを設定します。
      - path: /tea
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      # コンテキストパスを設定します。
      - path: /coffee
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

次の表は、YAMLテンプレートのパラメーターについて説明しています。

パラメーター

説明

alb.ingress.kubernetes.io/healthcheck-enabled

オプション。ヘルスチェックを有効にするかどうかを指定します。デフォルト値:true

alb.ingress.kubernetes.io/healthcheck-path

オプション。ヘルスチェックを実行するURLパス。デフォルト値:/

  • ヘルスチェックを実行するWebページのURLを入力します。静的WebページのURLを入力することをお勧めします。URLは1~80文字で、文字、数字、ハイフン(-)、スラッシュ(/)、ピリオド(.)、パーセント記号(%)、疑問符(?)、番号記号(#)、アンパサンド(&)を含めることができます。URLには、次の拡張文字を含めることもできます:_ ; ~ ! ( ) * [ ] @ $ ^ : ' , +。URLはスラッシュ(/)で始まる必要があります。

  • デフォルトでは、ALBインスタンスはバックエンドElastic Compute Service(ECS)インスタンスに設定されているデフォルトのアプリケーションホームページにHTTP HEADリクエストを送信してヘルスチェックを実行します。ALBインスタンスは、ECSインスタンスのプライベートIPアドレスにリクエストを送信します。デフォルトのアプリケーションホームページをヘルスチェックに使用したくない場合は、URLパスを指定する必要があります。

alb.ingress.kubernetes.io/healthcheck-protocol

オプション。ヘルスチェックに使用されるプロトコル。

  • HTTP:ALBインスタンスは、ブラウザーからのアクセスをシミュレートし、バックエンドサーバーが正常かどうかを確認するために、バックエンドサーバーにHEADまたはGETリクエストを送信します。これはデフォルトのプロトコルです。

  • TCP:ALBインスタンスは、バックエンドサーバーのポートがリクエストを受信できるかどうかを確認するために、バックエンドサーバーにTCP SYNパケットを送信します。

alb.ingress.kubernetes.io/healthcheck-method

オプション。ヘルスチェックに使用されるリクエストメソッド。

  • HEAD:デフォルトでは、ALBインスタンスはバックエンドサーバーにHEADリクエストを送信してHTTPヘルスチェックを実行します。バックエンドサーバーがHEADリクエストをサポートしていることを確認してください。バックエンドサーバーがHEADメソッドをサポートしていないか、HEADメソッドが無効になっている場合、ヘルスチェックが失敗する可能性があります。この場合、GETメソッドを使用できます。

  • GET:レスポンスのサイズが8 KBを超える場合、レスポンスは断片化されます。これはヘルスチェックの結果には影響しません。

alb.ingress.kubernetes.io/healthcheck-httpcode

バックエンドサーバーがヘルスチェックに合格したときに返されるステータスコード。

有効な値:http_2xx(デフォルト)、http_3xxhttp_4xx、およびhttp_5xx

alb.ingress.kubernetes.io/healthcheck-timeout-seconds

ヘルスチェックのタイムアウト期間。バックエンドサーバーが指定されたタイムアウト期間内に応答しない場合、サーバーはヘルスチェックに失敗します。有効な値:1~300。デフォルト値:5。単位:秒。

alb.ingress.kubernetes.io/healthcheck-interval-seconds

2つの連続したヘルスチェックの間隔。単位:秒。有効な値:1~50。デフォルト値:2。単位:秒。

alb.ingress.kubernetes.io/healthy-threshold-count

異常なバックエンドサーバーが正常と見なされる前に、連続してヘルスチェックに合格する必要がある回数。有効な値:2~10。デフォルト値:3。

alb.ingress.kubernetes.io/unhealthy-threshold-count

正常なバックエンドサーバーが異常と見なされる前に、連続してヘルスチェックに失敗する必要がある回数。有効な値:2~10。デフォルト値:3。

HTTPリクエストからHTTPSリクエストへのリダイレクトを設定する

alb.ingress.kubernetes.io/ssl-redirect: "true"アノテーションを追加することで、HTTPリクエストをHTTPSポート443にリダイレクトするようにALBイングレスを設定できます。

重要

ALBイングレスを使用してリスナーを作成することはできません。ALBイングレスが期待どおりに動作することを確実にするには、AlbConfigでリスナーのポートとプロトコルを指定し、リスナーをALBイングレスのサービスに関連付ける必要があります。ALBリスナーの作成方法の詳細については、AlbConfigを使用してALBリスナーを構成するを参照してください。

例:

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service-ssl
                port: 
                  number: 80
            path: /
            pathType: Prefix

バックエンドプロトコルとしてHTTPSまたはgRPCを設定する

ALBイングレスは、バックエンドプロトコルとしてHTTPSまたはgRPCをサポートしています。HTTPSまたはgRPCを設定するには、alb.ingress.kubernetes.io/backend-protocol: "grpc"またはalb.ingress.kubernetes.io/backend-protocol: "https"アノテーションを追加します。イングレスを使用してgRPCサービスにリクエストを配信する場合は、gRPCサービスのSSL証明書を設定し、TLSプロトコルを使用してgRPCサービスと通信する必要があります。例:

説明

バックエンドプロトコルを変更することはできません。プロトコルを変更する必要がある場合は、イングレスを削除して再構築してください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: lxd-grpc-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:  
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grpc-demo-svc
            port:
              number: 9080

正規表現を設定する

pathフィールドにルーティング条件として正規表現を指定できます。例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true" # pathフィールドで正規表現をサポートします。
   alb.ingress.kubernetes.io/conditions.service-a: | # アノテーションで指定されたサービスは、クラスター内の既存のサービスでなければならず、サービス名はruleフィールドのbackendのサービス名と同じである必要があります。
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*^/pathvalue1", # 正規表現は正規表現フラグ~ *に従う必要があります。
              "/pathvalue2" # 完全一致の場合は、パスの前に~ *を追加する必要はありません。
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: service-a
            port:
              number: 88

書き換えルールを設定する

ALBイングレスは書き換えルールをサポートしています。書き換えルールを設定するには、アノテーションalb.ingress.kubernetes.io/rewrite-target: /path/${2}を追加します。次のルールが適用されます。

  • rewrite-target アノテーションでは、pathType フィールドを、${number} タイプの変数に対して Prefix に設定する必要があります。

  • デフォルトでは、pathパラメーターは、アスタリスク(*)や疑問符(?)などの正規表現でサポートされている文字をサポートしていません。pathパラメーターで正規表現で使用される文字を指定するには、rewrite-targetアノテーションを追加する必要があります。

  • pathパラメーターの値は、スラッシュ(/)で始まる必要があります。

説明

書き換えルールで正規表現を指定する場合は、次の項目に注意してください。

  • ALBイングレスのpathフィールドに1つ以上の正規表現を指定し、括弧()で囲むことができます。ただし、${1}${2}${3}の最大3つの変数をrewrite-targetアノテーションで使用して、元のパスを上書きするパスを形成できます。

  • 正規表現に一致する変数は連結され、元のパスを上書きするパスが形成されます。

  • 元のパスは、次の要件が満たされた場合にのみ、正規表現に一致する変数によって上書きされます。括弧()で囲まれた複数の正規表現が指定され、rewrite-targetアノテーションが次の変数の1つ以上に設定されている必要があります。${1}${2}${3}

ALBイングレスのpathパラメーターが/sys/(.*)/(.*)/aaaに設定され、rewrite-targetアノテーションが/${1}/${2}に設定されているとします。クライアントが/sys/ccc/bbb/aaapathにリクエストを送信すると、リクエストは正規表現/sys/(.*)/(.*)/aaaと一致します。rewrite-targetアノテーションが有効になり、${1}cccに、${2}bbbに置き換えられます。その結果、リクエストは/ccc/bbbにリダイレクトされます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # pathフィールドで正規表現をサポートします。
    alb.ingress.kubernetes.io/rewrite-target: /path/${2} # 正規表現に一致する変数は連結され、元のパスを上書きするパスが形成されます。
  name: rewrite-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

カスタムリスニングポートを設定する

ALBイングレスでは、カスタムリスニングポートを設定できます。これにより、ポート80と443を介して同時にサービスを公開できます。

重要

ALBイングレスを使用してリスナーを作成することはできません。ALBイングレスが期待どおりに動作することを確実にするには、AlbConfigでリスナーのポートとプロトコルを指定し、リスナーをALBイングレスのサービスに関連付ける必要があります。ALBリスナーの作成方法の詳細については、AlbConfigを使用してALBリスナーを構成するを参照してください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

転送ルール優先順位を設定する

デフォルトでは、転送ルールは次のルールに基づいて優先順位が付けられます。

  • 異なるALBイングレスの転送ルールは、namespace/nameパラメーターの値の辞書順で優先順位が付けられます。namespace/nameの値が辞書順ですべての転送ルールの中で最初に表示される転送ルールは、最も高い優先順位を持ちます。

  • ALBイングレスの転送ルールは、ruleパラメーターで優先順位の降順で表示されます。

ALBイングレスのnamespace/nameパラメーターを使用して転送ルールの優先順位を付けたくない場合は、代わりに次のアノテーションを使用できます。

説明

リスナー内の各転送ルールの優先順位は一意である必要があります。アノテーションalb.ingress.kubernetes.io/orderを使用して、ALBイングレスの転送ルールの優先順位を指定できます。有効な値:1~1000。値が小さいほど優先順位が高くなります。デフォルト値は10です。より高い優先順位を指定する場合は、値をより小さい数値に設定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/order: "2"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

アノテーションを使用して段階的リリースを実行する

ALBでは、複雑なトラフィックルーティングを処理するために、リクエストヘッダー、Cookie、および重み付けに基づいてカナリアリリースを設定できます。アノテーションalb.ingress.kubernetes.io/canary: "true"を追加して、カナリアリリース機能を有効にできます。その後、次のアノテーションを使用して、さまざまなカナリアリリースルールを設定できます。

説明
  • 異なるルールを使用するカナリアリリースは、次の順序で有効になります:ヘッダーベース>Cookieベース>重みベース。

  • カナリアリリースを実行して新しいアプリケーションバージョンをテストする場合、元のイングレスルールを変更しないでください。そうしないと、アプリケーションへのアクセスが中断される可能性があります。新しいアプリケーションバージョンがテストに合格したら、以前のアプリケーションバージョンで使用されていたバックエンドサービスを、新しいアプリケーションバージョンで使用されているバックエンドサービスに置き換えます。次に、カナリアリリースを実装するためのイングレスルールを削除します。

  • alb.ingress.kubernetes.io/canary-by-headerおよびalb.ingress.kubernetes.io/canary-by-header-value:このルールは、リクエストのヘッダーとヘッダー値と一致します。このルールを使用する場合は、両方のアノテーションを追加する必要があります。

    • リクエストのheaderheader valueがルールと一致する場合、リクエストは新しいアプリケーションバージョンにルーティングされます。

    • リクエストのheaderheaderベースのルールと一致しない場合、リクエストはルールの優先順位に基づいて他のタイプのルールと照合されます。

    alb.ingress.kubernetes.io/canary-by-headerアノテーションをlocation: hzに設定すると、ルールと一致するリクエストは新しいアプリケーションバージョンにルーティングされます。ルールと一致しないリクエストは、重みベースのルールに基づいてルーティングされます。例:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        alb.ingress.kubernetes.io/order: "1"
        alb.ingress.kubernetes.io/canary: "true"
        alb.ingress.kubernetes.io/canary-by-header: "location"
        alb.ingress.kubernetes.io/canary-by-header-value: "hz"
      name: demo-canary
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: demo-service-hello
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific
  • alb.ingress.kubernetes.io/canary-by-cookie:このルールは、リクエストのCookieと一致します。

    • cookiealwaysに設定すると、ルールと一致するリクエストは新しいアプリケーションバージョンにルーティングされます。

    • cookieneverに設定すると、ルールと一致するリクエストは古いアプリケーションバージョンにルーティングされます。

    説明

    Cookieベースのカナリアリリースルールは、他の設定をサポートしていません。Cookie値はalwaysまたはneverである必要があります。

    demo=alwaysCookieを含むリクエストは、新しいアプリケーションバージョンにルーティングされます。例:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        alb.ingress.kubernetes.io/order: "2"
        alb.ingress.kubernetes.io/canary: "true"
        alb.ingress.kubernetes.io/canary-by-cookie: "demo"
      name: demo-canary-cookie
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: demo-service-hello
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific
  • alb.ingress.kubernetes.io/canary-weight:このルールでは、指定されたサービスに送信されるリクエストの割合を設定できます。0~100の整数を入力できます。

    次の例では、新しいアプリケーションバージョンにルーティングされるリクエストの割合は50%に設定されています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        alb.ingress.kubernetes.io/order: "3"
        alb.ingress.kubernetes.io/canary: "true"
        alb.ingress.kubernetes.io/canary-weight: "50"
      name: demo-canary-weight
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: demo-service-hello
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific

アノテーションを使用してセッション永続性を設定する

ALBイングレスでは、次のアノテーションを使用してセッション永続性を設定できます。

  • alb.ingress.kubernetes.io/sticky-session:セッション永続性を有効にするかどうかを指定します。有効な値:trueおよびfalse。デフォルト値:false

  • alb.ingress.kubernetes.io/sticky-session-type:Cookieの処理方法。有効な値:InsertおよびServer。デフォルト値:Insert

    • Insert:Cookieを挿入します。ALBは、クライアントに送信される最初のHTTPまたはHTTPSレスポンスパケットにCookie(SERVERID)を挿入します。クライアントからの次のリクエストにはこのCookieが含まれ、リスナーはこのリクエストを記録されたバックエンドサーバーに配信します。

    • Server:Cookieを書き換えます。ALBは、ユーザー定義のCookieを検出すると、元のCookieをユーザー定義のCookieで上書きします。クライアントからの次のリクエストには、ユーザー定義のCookieが含まれ、リスナーはこのリクエストを記録されたバックエンドサーバーに配信します。

    説明

    このパラメーターは、サーバーグループのStickySessionEnabledパラメーターがtrueに設定されている場合に有効になります。

  • alb.ingress.kubernetes.io/cookie-timeout:Cookieのタイムアウト期間を指定します。有効な値:1~86400。デフォルト値:1000。単位:秒。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # コンテキストパスを設定します。
      - path: /tea2
        backend:
          service:
            name: tea-svc
            port: 
             number: 80
      # コンテキストパスを設定します。
       - path: /coffee2
         backend:
           service:
              name: coffee-svc
              port: 
               number: 80

バックエンドサーバーグループのロードバランシングアルゴリズムを指定する

ALBイングレスでは、アノテーションalb.ingress.kubernetes.io/backend-schedulerを使用して、バックエンドサーバーグループのロードバランシングアルゴリズムを指定できます。クラスターのKubernetesバージョンは、デフォルトで1.19以降です。例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # ビジネス要件に基づいて、uchをwrr、sch、またはwlcに置き換えます。
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # このパラメーターは、ロードバランシングアルゴリズムがuchの場合にのみ必要です。スケジューリングアルゴリズムがwrr、sch、またはwlcの場合は、このパラメーターを設定する必要はありません。
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

次の説明に基づいて、アノテーションalb.ingress.kubernetes.io/backend-schedulerを設定します。

  • wrr:重み付けの高いバックエンドサーバーは、重み付けの低いバックエンドサーバーよりも多くのリクエストを受信します。これはデフォルト値です。

  • wlc:リクエストは、各バックエンドサーバーの重み付けと負荷に基づいて配信されます。負荷とは、バックエンドサーバーへの接続数を指します。複数のバックエンドサーバーの重み付けが同じ場合、リクエストは接続数が最も少ないバックエンドサーバーに転送されます。

  • sch:送信元IPアドレスに基づくコンシステントハッシュ。

  • uch:URLパラメーターに基づくコンシステントハッシュ。バックエンドサーバーグループのロードバランシングアルゴリズムがuchの場合、アノテーションalb.ingress.kubernetes.io/backend-scheduler-uch-valueをALBイングレスに追加して、コンシステントハッシュのURLパラメーターを指定できます。

CORSを設定する

次のコードブロックは、ALBイングレスでサポートされているクロスオリジンリソースシェアリング(CORS)構成のサンプルを示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-cors: "true"
    alb.ingress.kubernetes.io/cors-expose-headers: ""
    alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    alb.ingress.kubernetes.io/cors-allow-credentials: "true"
    alb.ingress.kubernetes.io/cors-max-age: "600"

spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

パラメーター

説明

alb.ingress.kubernetes.io/cors-allow-origin

ブラウザーを使用してオリジンサーバー上のリソースにアクセスするために使用できるURL。複数のURLはコンマ(,)で区切ります。各URLはhttp://またはhttps://で始まり、有効なドメイン名またはトップレベルのワイルドカードドメイン名を含める必要があります。

デフォルト値:*。例:alb.ingress.kubernetes.io/cors-allow-origin: "https://example.com:4443, http://aliyundoc.com, https://example.org:1199"

alb.ingress.kubernetes.io/cors-allow-methods

許可されるHTTPメソッド。値は大文字と小文字が区別されません。複数のHTTPメソッドはコンマ(,)で区切ります。

デフォルト値:GET, PUT, POST, DELETE, PATCH, OPTIONS。例:alb.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"

alb.ingress.kubernetes.io/cors-allow-headers

許可されるリクエストヘッダー。リクエストヘッダーには、文字、数字、アンダースコア(_)、ハイフン(-)を含めることができます。複数のリクエストヘッダーはコンマ(,)で区切ります。

デフォルト値:DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization。例:alb.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For, X-app123-XPTO"

alb.ingress.kubernetes.io/cors-expose-headers

公開できるヘッダー。ヘッダーには、文字、数字、アンダースコア(_)、ハイフン(-)、アスタリスク(*)を含めることができます。複数のヘッダーはコンマ(,)で区切ります。

デフォルト値:empty。例:alb.ingress.kubernetes.io/cors-expose-headers: "*, X-CustomResponseHeader"

alb.ingress.kubernetes.io/cors-allow-credentials

CORSリクエストに資格情報を含めるかどうかを指定します。

デフォルト値:true。例:alb.ingress.kubernetes.io/cors-allow-credentials: "false"

alb.ingress.kubernetes.io/cors-max-age

OPTIONSメソッドを使用するプリフライトリクエストをキャッシュできる最大期間。複雑なリクエストの場合は、このパラメーターを設定します。有効な値:-1~172800。単位:秒。

デフォルト値:172800

持続的接続を設定する

従来のロードバランサーは、短期間の接続を介してバックエンドサーバーにアクセスします。従来のロードバランサーは、リクエストをバックエンドサーバーに転送するたびに接続を作成して接続を閉じる必要があります。その結果、ネットワーク接続がパフォーマンスのボトルネックになります。ネットワーク接続の確立に使用されるリソースの量を削減し、転送パフォーマンスを向上させるために、持続的TCP接続機能を使用できます。alb.ingress.kubernetes.io/backend-keepaliveアノテーションをALBイングレスに追加して、持続的TCP接続機能を有効にできます。例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

QPSスロットリングを設定する

ALBは、転送ルールに基づいてQPSスロットリングをサポートしています。QPSは1~100000の範囲に制限できます。alb.ingress.kubernetes.io/traffic-limit-qpsアノテーションをALBイングレスに追加して、QPSスロットリング機能を有効にできます。例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80