Container Service for Kubernetes:ALB Ingress サービスの高度な機能

インデックス

ドメイン名に基づくリクエストの転送

シンプルな Ingress を作成して、指定したドメイン名または空のドメイン名に基づいてリクエストを転送できます。

URL パスに基づくリクエストの転送

以下のセクションでは、3 つのマッチタイプの例を示します：

ヘルスチェックの設定

ALB Ingress はヘルスチェックをサポートしています。次のアノテーションを設定することで、ヘルスチェックを設定できます。

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-httpversion: "HTTP1.1"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-code: "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

apiVersion: networking.k8s.io/v1beta1
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:
          serviceName: tea-svc
          servicePort: 80
      # コンテキストパスを設定します。
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

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-httpversion: "HTTP1.1"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-code: "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:
... ...

HTTP から HTTPS へのリダイレクトの設定

ALB Ingress は、次のアノテーションを使用して、HTTP リクエストを HTTPS ポート 443 にリダイレクトできます。

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

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: NodePort
---
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/v1beta1
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:
              serviceName: demo-service-ssl
              servicePort: 80
            path: /
            pathType: Prefix

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
 ... ...

バックエンドの HTTPS および gRPC プロトコルのサポート

ALB は、バックエンドプロトコルとして HTTPS と gRPC をサポートしています。これらを使用するには、Ingress に次のアノテーションを追加します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: demo-alb-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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: demo-alb-ingress
... ...

正規表現の設定

alb.ingress.kubernetes.io/use-regex: "true" アノテーションを使用して正規表現モードを有効にし、カスタム転送条件またはアクションで対応する正規表現を設定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true"  ## 正規表現の使用を許可します。
   alb.ingress.kubernetes.io/conditions.<YOUR-SVC-NAME>: | ## <YOUR-SVC-NAME> を実際のサービス名に置き換えます。これは、以下の backend.service.name と同じである必要があります。
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*/pathvalue1", ## 正規表現には、フラグとして ~* または ~ をプレフィックスとして付ける必要があります。~* または ~ の後の内容が有効な正規表現です。~* は大文字と小文字を区別する正規表現マッチを示し、~ は大文字と小文字を区別しない正規表現マッチを示します。
              "/pathvalue2"    ## 完全一致には ~* プレフィックスは不要です。
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test-path-for-alb
        pathType: Prefix
        backend:
          service:
            name: <YOUR-SVC-NAME> ## ここの <YOUR-SVC-NAME> は、関係を示すためにカスタム転送条件アノテーションで指定されたサービス名と同じである必要があります。
            port:
              number: 88

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true"  ## 正規表現の使用を許可します。
   alb.ingress.kubernetes.io/conditions.<YOUR-SVC-NAME>: | ## <YOUR-SVC-NAME> を実際のサービス名に置き換えます。これは、以下の backend.service.name と同じである必要があります。
     [{
       "type": "Path",         ## Host もサポートされています。
       "pathConfig": {
           "values": [
              "~*/pathvalue1", ## 正規表現には、フラグとして ~* または ~ をプレフィックスとして付ける必要があります。~* または ~ の後の内容が有効な正規表現です。~* は大文字と小文字を区別する正規表現マッチを示し、~ は大文字と小文字を区別しない正規表現マッチを示します。
              "/pathvalue2"    ## 完全一致には ~* プレフィックスは不要です。
           ]
       }
      }]
... ...

正規表現のマッチングルール：

再書き込みの設定

ALB Ingress は再書き込み機能をサポートしています。クライアントリクエストを受信した後、リクエストのパスを変更し、バックエンドサービスにリクエストを送信します。再書き込みは、次の 2 つのアノテーションを使用して実装されます：

• alb.ingress.kubernetes.io/rewrite-target: /<path>/${number}：再書き込みを有効にし、再書き込み後のパスを指定します。

  重要

  • 正規表現を介して元のパスから取得した変数を表すには、${number} 形式を使用します。${1}、${2}、${3} など、1 つ以上の変数を設定できます。元のパスから最大 3 つの変数を取得できます。

  • Ingress の pathType は Prefix に設定する必要があります。

• alb.ingress.kubernetes.io/use-regex：パスで正規表現を使用するかどうかを指定します。これは、rewrite-target が設定された後、デフォルトで有効になります。

  • "true"：正規表現を使用します。

  • "false"：正規表現を使用しません。パスに “%#;!()[]^,”\" などの特殊文字が含まれている場合、Ingress リソースの作成に失敗します。

設定例

シナリオ 1：プレフィックスの削除

次の YAML の例では、path: /something(/|$)(.*) は正規表現を使用して、クライアントリクエストパスを 3 つの部分に分割します：

• /something：削除するプレフィックスに一致します。

• (/|$)：最初のキャプチャグループ。/something の後の / またはパスの末尾 ($) に一致します。

• (.*): 2 番目のキャプチャグループです。/something/ の後のすべての内容に一致し、書き換え後のパスで ${2} として参照されます。

alb.ingress.kubernetes.io/rewrite-target アノテーションで設定された再書き込み後のパスは、/ (標準パスプレフィックス) + ${2} (2 番目のキャプチャグループのコンテンツ) です。次の表に、パスの再書き込み結果を示します：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # パスフィールドで正規表現の使用を許可します。
    alb.ingress.kubernetes.io/rewrite-target: /${2} # このアノテーションは正規表現の置換をサポートします。
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

シナリオ 2：複数の部分のキャプチャと再配置

次の例では、パス /items/(.*)/(.*)/(.*) の複数の部分をキャプチャして再配置します。再書き込み後のパスは、/ (標準パスプレフィックス) + ${2} (2 番目のキャプチャグループのコンテンツ) + ?code= + ${3} (3 番目のキャプチャグループのコンテンツ) です。次の表に、パスの再書き込み結果を示します：

この例では、パスに 4 つのセグメントが明示的に必要です。このメソッドでは、クライアントが固定のパス形式を使用する必要があります。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # パスフィールドで正規表現の使用を許可します。
    alb.ingress.kubernetes.io/rewrite-target: /${2}?code=${3} # このアノテーションは正規表現の置換をサポートします。
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /items/(.*)/(.*)/(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

シナリオ 3：複数のパスを単一のパスに再書き込み

次の例では、複数のパス (/app-a(/|$)(.*) と /app-b(/|$)(.*)) を正規表現で照合し、単一のパスに再書き込みします。再書き込み後のパスは、/app-c/ + ${2} (2 番目のキャプチャグループのコンテンツ) です。次の表に、パスの再書き込み結果を示します：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # パスフィールドで正規表現の使用を許可します。
    alb.ingress.kubernetes.io/rewrite-target: /app-c/${2} # このアノテーションは正規表現の置換をサポートします。
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /app-a(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080
      - path: /app-b(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

シナリオ 4：ドメイン名の再書き込み

alb.ingress.kubernetes.io/rewrite-target アノテーションは、パスの変更のみをサポートします。ドメイン名やパラメーターなど、URL の他の部分を変更するには、カスタム転送ルールを使用できます。

再書き込みルールのマッチングの検証

sed コマンドを使用して、クライアントが使用する特定のパスが `path` で設定された正規表現に一致するかどうかをテストし、新しい再書き込み後のパスを表示できます。

シナリオ 2：複数の部分のキャプチャと再配置 のキャプチャパス /items/(.*)/(.*)/(.*) と再書き込みルール /${2}?code=${3} を例として取り上げます：

1. 次のサンプルコマンドを path2.txt に保存します：

   /items/electronics/computers/554
   /items/produce/fruits/12
   /items/headphones/5
   /drinks/41

2. パスが一致するかどうかを確認し、再書き込み後のパスを表示します：

   次のコマンドは、例のパス正規表現 (/items/(.*)/(.*)/(.*)) と再書き込み後のパス (/${2}?code=${3}) を使用します。sed コマンドでは、特殊文字 / はバックスラッシュ \ でエスケープする必要があり、キャプチャグループのコンテンツの構文は ${2} から \2 に変更されます。

   sed -E 's#\/items\/(.*)\/(.*)\/(.*)#Matched: [&]  --->  Rewritten: [/\2?code=\3]#' path2.txt

   期待される出力は次のとおりです。最初の 2 つのパスは再書き込みルールに一致し、新しいパスに再書き込みされます。最後の 2 つのパスは一致せず、再書き込みされません。

   Matched: [/items/electronics/computers/554]  --->  Rewritten: [/computers?code=554]
   Matched: [/items/produce/fruits/12]  --->  Rewritten: [/fruits?code=12]
   /items/headphones/5
   /drinks/41

カスタムリスナーポートの設定

ALB Ingress は、アノテーションを介してカスタムリスナーポートをサポートします。これにより、サービスはポート 80 (HTTP) とポート 443 (HTTPS) の両方を同時に公開できます。

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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
... ...

転送ルールの優先度の設定

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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/order: "2"
spec:
... ...

アノテーションを使用した段階的リリースの実装

ALB は複雑なルーティングをサポートし、ヘッダー、Cookie、および重みに基づく段階的リリース機能を提供します。次のアノテーションを設定して、さまざまな段階的リリースポリシーを柔軟に実装できます。段階的リリースのベストプラクティスに関する詳細については、「ALB Ingress を使用した段階的リリースの実装」をご参照ください。

• 指定されたヘッダーに基づいて段階的リリースのトラフィックを分散する

  パラメーター	説明	サンプル YAML
  alb.ingress.kubernetes.io/canary-by-header	このルールでは、リクエストヘッダーとそれに対応する値をカスタマイズできます。両方のアノテーションを設定する必要があります。 リクエストの header と header-value が設定値と一致する場合、リクエストトラフィックは段階的リリースサービスのエンドポイントに分散されます。 その他の一致しないリクエストは、段階的リリースの優先度に従って、後続の段階的リリースサービスに分散されます。	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 spec: ... ...
  alb.ingress.kubernetes.io/canary-by-header-value

  リクエストヘッダーに location: hz が含まれている場合、トラフィックは段階的リリースサービスにルーティングされます。他のリクエストは、設定された重みポリシーに基づいてサービスに分散されます。以下は設定例です。

  完全なサンプル YAML の表示

  バージョン 1.19 以降のクラスターの場合

  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

  バージョン 1.19 より前のクラスターの場合

  apiVersion: networking.k8s.io/v1beta1
  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:
                serviceName: demo-service-hello
                servicePort: 80
              path: /hello
              pathType: ImplementationSpecific

• 指定された Cookie に基づいて段階的リリースのトラフィックを分散する

  パラメーター	Cookie の値	サンプル YAML
  alb.ingress.kubernetes.io/canary-by-cookie	always：すべてのリクエストトラフィックが段階的リリースサービスのエンドポイントに分散されます。 never：リクエストトラフィックは段階的リリースサービスのエンドポイントに分散されません。 Cookie ベースの段階的リリースはカスタム設定をサポートしておらず、always と never のみです。	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 ... ...

  リクエストヘッダーに Cookie: demo=always が含まれている場合、トラフィックは段階的リリースサービスにルーティングされます。リクエストヘッダーに Cookie: demo=never が含まれている場合、トラフィックは段階的リリースサービスにルーティングされません。以下は設定例です。

  完全なサンプル YAML の表示

  バージョン 1.19 以降のクラスターの場合

  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

  バージョン 1.19 より前のクラスターの場合

  apiVersion: networking.k8s.io/v1beta1
  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:
                serviceName: demo-service-hello
                servicePort: 80
              path: /hello
              pathType: ImplementationSpecific

• 重みによるトラフィックの分散

  パラメーター	説明	サンプル YAML
  alb.ingress.kubernetes.io/canary-weight	指定されたサービスに送信されるリクエストの割合を設定します。値は 0 から 100 までの整数でなければなりません。	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

  次の例では、段階的リリースサービスの重みを 50% に設定します：

  完全なサンプル YAML の表示

  バージョン 1.19 以降のクラスターの場合

  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

  バージョン 1.19 より前のクラスターの場合

  apiVersion: networking.k8s.io/v1beta1
  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:
                serviceName: demo-service-hello
                servicePort: 80
              path: /hello
              pathType: ImplementationSpecific

アノテーションを使用したセッション維持の実装

ALB Ingress は、次のアノテーションを介してセッション維持をサポートします。

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"   # カスタム Cookie がサポートされている場合、Cookie の挿入タイプは Server である必要があります。
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - backend:
          service:
            name: tea-svc
            port:
              number: 80
        path: /tea2
        pathType: ImplementationSpecific
      - backend:
          service:
            name: coffee-svc
            port:
              number: 80
        path: /coffee2
        pathType: ImplementationSpecific

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"  # カスタム Cookie がサポートされている場合、Cookie の挿入タイプは Server である必要があります。
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      #コンテキストパスを設定します。
      - path: /tea2
        pathType: ImplementationSpecific
        backend:
          serviceName: tea-svc
          servicePort: 80
      #コンテキストパスを設定します。
      - path: /coffee2
        pathType: ImplementationSpecific
        backend:
          serviceName: coffee-svc
          servicePort: 80

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"   # カスタム Cookie がサポートされている場合、Cookie の挿入タイプは Server である必要があります。
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
    alb.ingress.kubernetes.io/cookie: "test"
spec:
... ...

サーバーグループのロードバランシングアルゴリズムの指定

ALB Ingress で次のアノテーションを使用して、サーバーグループのロードバランシングアルゴリズムを指定できます。次の表に、有効な値を示します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # 必要に応じて wrr、sch、または wlc に設定できます。
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # このパラメーターは、ロードバランシングアルゴリズムが uch の場合にのみ必要です。wrr、sch、または wlc アルゴリズムでは不要です。
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "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:
          - backend:
              serviceName: tea-svc
              servicePort: 80
            path: /tea
            pathType: ImplementationSpecific

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # 必要に応じて wrr、sch、または wlc に設定できます。
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # このパラメーターは、ロードバランシングアルゴリズムが uch の場合にのみ必要です。wrr、sch、または wlc アルゴリズムでは不要です。
spec:
... ... 

クロスドメインアクセスの設定

ALB Ingress は、次のアノテーションパラメーターを介してクロスドメインの動作を制御できます。許可されたサイト、リクエストメソッド、リクエストおよびレスポンスヘッダー、認証情報ハンドリング、プリフライト (OPTIONS) のキャッシュ期間を指定して、さまざまなセキュリティおよびビジネスシナリオのクロスドメインアクセス要件を満たすことができます。

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"
    alb.ingress.kubernetes.io/cors-allow-origin: "許可されたクロスドメインのドメイン名"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

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"
    alb.ingress.kubernetes.io/cors-allow-origin: "許可されたクロスドメインのドメイン名"
spec:
... ...

バックエンドの持続的接続

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:

サーバーグループの IPv6 アタッチメントのサポート

IPv6 アタッチメントを有効にしたサーバーグループに IPv4 と IPv6 の両方の Pod をアタッチするには、まずクラスターのデュアルスタック機能を有効にする必要があります。詳細については、「ACK マネージドクラスターの作成」をご参照ください。

apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  annotations:
spec:
  # デュアルスタックを設定する場合、ipFamilies は IPv4 または IPv6 に設定し、ipFamilyPolicy は RequireDualStack または PreferDualStack に設定する必要があります。
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv4
  - IPv6
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-ipv6: "true"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

Service と ALB Ingress は、デュアルスタックをサポートするように設定する必要があります。デュアルスタックをサポートする ALB インスタンスを作成した後、IPv4 と IPv6 の両方のバックエンドサーバーをサーバーグループにアタッチできます。

apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  annotations:
spec:
  # デュアルスタックを設定する場合、ipFamilies は IPv4 または IPv6 に設定し、ipFamilyPolicy は RequireDualStack または PreferDualStack に設定する必要があります。
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv4
  - IPv6
... ...

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-ipv6: "true"
spec:
... ...

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
... ...

バックエンドのスロースタート

新しい Pod がサービスバックエンドに追加された後、ALB Ingress がすぐに新しい Pod にトラフィックを分散すると、CPU またはメモリ使用量の一時的な急増を引き起こし、アクセスエラーにつながる可能性があります。スロースタートを使用すると、ALB Ingress は徐々に新しい Pod にトラフィックを転送し、突然のトラフィックバーストの影響を軽減します。以下は設定例です：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/slow-start-enabled: "true"
    alb.ingress.kubernetes.io/slow-start-duration: "100"
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/slow-start-enabled: "true"
    alb.ingress.kubernetes.io/slow-start-duration: "100"
  name: alb-ingress
... ...

接続ドレイン

Pod が Terminating 状態に入ると、ALB Ingress はそれをバックエンドサーバーグループから削除します。ただし、ALB インスタンスから Pod への既存の接続はすぐには終了しません。これにより、Pod 内のサービスが正常にシャットダウンできなくなったり、リクエストエラーが発生したりする可能性があります。この問題を回避するために、ALB の接続ドレイン機能を使用できます。Pod が削除されたり、ヘルスチェックに失敗したりすると、ALB Ingress は指定されたタイムアウト期間内に既存のリクエストが完了するのを許可し、その後接続を閉じます。このプロセスにより、サービスがスムーズにオフラインになることが保証されます。詳細については、「ALB 接続ドレインによるスムーズなサービスシャットダウンの確保」をご参照ください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/connection-drain-enabled: "true"
    alb.ingress.kubernetes.io/connection-drain-timeout: "199"
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/connection-drain-enabled: "true"
    alb.ingress.kubernetes.io/connection-drain-timeout: "199"
  name: alb-ingress
... ...

クロスゾーンロードバランシングの無効化

デフォルトでは、ALB はクロスゾーンロードバランシングを有効にします。これは、トラフィックが同じリージョン内の異なるゾーンにあるバックエンドサービスに均等に分散されることを意味します。ALB サーバーグループのクロスゾーンロードバランシングを無効にすると、トラフィックは同じゾーン内のバックエンドサービス間でのみ分散されます。

次の例は、クロスゾーンロードバランシングを無効にする方法を示しています：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/cross-zone-enabled: "false"
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com
    http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  namespace: default
  annotations:
    alb.ingress.kubernetes.io/cross-zone-enabled: "false"
... ...