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

Container Service for Kubernetes:ALB Ingress による Service の公開

最終更新日:Sep 10, 2026

デフォルトでは、ACK クラスター内の Service は外部ネットワークから分離されています。ALB Ingress は、Application Load Balancer (ALB) を外部トラフィックのエントリポイントとして使用し、これらの Service を公開します。ALB は、ドメインベースのルーティング、セキュリティ、高可用性を提供します。

仕組み

  1. リソースの関連付け

    AlbConfig オブジェクトは、機能エディションやリスナーなど、ALB インスタンスの具体的な構成を定義します。各 AlbConfig オブジェクトは、ALB インスタンスと 1 対 1 で対応します。Ingress で定義されたパスマッピングと関連付けられた Service は、自動的に ALB インスタンスのルーティングルールとサーバーグループに変換されます。

  2. 動的同期

    ALB Ingress コントローラーは、API サーバーで Ingress および AlbConfig リソースの変更を継続的に監視し、関連付けられた ALB インスタンスを動的に更新します。

  3. トラフィック転送

    ALB Ingress Controller は、Nginx Ingress Controller とは異なり、ALB インスタンスのコントロールプレーンとして機能するマネージドコンポーネントです。データプレーンのトラフィックを直接処理しません。ALB インスタンスがユーザー トラフィックを処理し、Service のバックエンド Pod に転送します。

image

Service タイプの制限

Flannel ネットワークプラグインを使用する場合、ALB イングレスのバックエンドサービスはNodePort とLoadBalancer タイプに制限されています。

ALB Ingress コントローラーのインストール

クラスター作成時

  1. ACK コンソールにログインし、Kubernetes クラスターの作成 をクリックします。

  2. コンポーネント設定 ステップの Ingress セクションで、ALB Ingress を選択します。

  3. この例では、[新規] オプションを使用します。画面の指示に従ってクラスターを作成します。

    [ALB Application Load Balancer インスタンス]

    説明

    [新しく作成する]

    ALB インスタンス、AlbConfig、および IngressClass を自動的に作成します。

    • ALB インスタンス:クラスターの Virtual Private Cloud (VPC) 内に、Standard、従量課金、パブリックまたはプライベートの ALB インスタンスを自動的に作成し、HTTP:80 リスナーを設定します。

    • AlbConfig および IngressClass:クラスター内に対応する AlbConfig および IngressClass リソースを自動的に作成し、ALB インスタンスに関連付けます。

    [既存を使用]

    このオプションは、クラスターが既存の Virtual Private Cloud (VPC) を使用するように設定されている場合にのみ使用できます。

    既存の ALB インスタンスを使用し、AlbConfig および IngressClass を自動的に作成します。指定する ALB インスタンスは、Standard または WAF-enhanced エディションである必要があり、クラスターと同じ VPC 内にあり、他のクラスターに関連付けられていない必要があります。

    [今は作成しない]

    ALB Ingress コントローラー コンポーネントのみをインストールします。後で AlbConfig および IngressClass を手動で作成する必要があります。これは、ALB インスタンスの設定をカスタマイズする必要があるシナリオに適しています。

既存のクラスターの場合

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

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。

  3. 検索ボックスを使用するか、ネットワーク タブをクリックしてコンポーネントを検索します。[ALB Ingress コントローラー] コンポーネントカードで、右下の インストール をクリックします。

  4. この例では、[新規] オプションを使用します。OK をクリックします。

    [ALB Application Load Balancer インスタンス]

    説明

    [新しく作成する]

    ALB インスタンス、AlbConfig、および IngressClass を自動的に作成します。

    • ALB インスタンス:クラスターの Virtual Private Cloud (VPC) 内に、Standard、従量課金、パブリックまたはプライベートの ALB インスタンスを自動的に作成し、HTTP:80 リスナーを設定します。

    • AlbConfig および IngressClass:クラスター内に対応する AlbConfig および IngressClass リソースを自動的に作成し、ALB インスタンスに関連付けます。

    [既存のものを使用する]

    既存の ALB インスタンスを使用し、AlbConfig および IngressClass を自動的に作成します。指定する ALB インスタンスは、Standard または WAF-enhanced エディションである必要があり、クラスターと同じ VPC 内にあり、他のクラスターに関連付けられていない必要があります。

    [今は作成しない]

    ALB Ingress コントローラー コンポーネントのみをインストールします。後で AlbConfig および IngressClass を手動で作成する必要があります。これは、ALB インスタンスの設定をカスタマイズする必要があるシナリオに適しています。

サンプルアプリケーションの作成

このサンプルアプリケーションは、coffee という名前の Deployment と、対応する coffee-svc という名前の Service をデプロイします。

コンソール

  1. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[ワークロード] > [デプロイ] を選択します。

  2. YAML のリソースの作成 をクリックします。カスタム ドロップダウンリストから サンプルテンプレート を選択します。次に、以下の内容をテンプレートエディターにコピーし、デプロイ をクリックします。

    サンプルアプリケーション YAML

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: coffee
      namespace: default
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: coffee
      template:
        metadata:
          labels:
            app: coffee
        spec:
          containers:
          - name: coffee
            image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
            ports:
            - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: coffee-svc
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: coffee
      type: ClusterIP  # Flannel ネットワークプラグインを使用する場合、ALB Ingress のバックエンド Service は NodePort および LoadBalancer タイプのみをサポートします。
  3. 確認ダイアログボックスで、ビュー をクリックし、Pod のステータスが Running であることを確認します。

kubectl

  1. kubectl を使用してクラスターに接続します。

  2. 次の内容を含む coffee-deployment-service.yaml という名前のファイルを作成します。

    サンプルアプリケーション YAML

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: coffee
      namespace: default
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: coffee
      template:
        metadata:
          labels:
            app: coffee
        spec:
          containers:
          - name: coffee
            image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
            ports:
            - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: coffee-svc
      namespace: default
    spec:
      ports:
      - port: 80
        targetPort: 80
        protocol: TCP
      selector:
        app: coffee
      type: ClusterIP  # Flannel ネットワークプラグインを使用する場合、ALB Ingress のバックエンド Service は NodePort および LoadBalancer タイプのみをサポートします。
  3. サンプルアプリケーションの Deployment および Service を作成します。

    kubectl apply -f coffee-deployment-service.yaml
  4. Pod のステータスが Running であることを確認します。

     kubectl get pod -l app=coffee

    期待される出力:

    NAME                      READY   STATUS    RESTARTS   AGE
    coffee-84bd6*****-*****   1/1     Running   0          4m22s
    coffee-84bd6*****-*****   1/1     Running   0          4m22s

ALB Ingress の作成

ALB Ingress のドメイン名とパスマッピングを設定して、ingress-demo.com/coffee へのリクエストをクラスター内の coffee-svc Service にルーティングします。

ACK 専用クラスターで ALB Ingress を使用するには、ALB Ingress コントローラーにアクセス権限を付与する必要があります。

コンソール

  1. 左側メニューで、ネットワーク > Ingress をクリックします。default 名前空間を選択し、Ingress の作成 をクリックします。

  2. 次の Ingress パラメータを指定し、OK をクリックします。

    • 名前:coffee-ingress

    • ドメイン名:ingress-demo.com

    • マッピング:パス:/coffee、一致ルール:Prefix、サービス名:coffee-svc、ポート:80。

      一致ルール (pathType)

      説明

      Prefix

      リクエストパスをプレフィックスに基づいて照合します。たとえば、/coffee/1 または /coffee/buy/1 へのリクエストは一致しますが、/cof または /coffeebuy/1 へのリクエストは一致しません。

      Exact

      リクエストパスを完全に照合します。/coffee へのリクエストのみが一致します。

      ImplementationSpecific

      一致動作は Ingress コントローラーの実装に依存します。ALB Ingress コントローラーの場合、このタイプは完全一致と同等です。

  3. エンドポイント アドレスを取得します。

    ALB Ingress が有効になるまでに約 10 秒かかります。更新ボタンをクリックしてエンドポイント情報を取得できます。長時間経過してもエンドポイントが更新されない場合は、Ingress 名をクリックして イベント タブに移動し、問題のトラブルシューティングを行ってください。

    Ingress リストの [エンドポイント] 列で、alb-<instance_id>.cn-wulanchabu.alb.aliyuncsslb.com のような形式の ALB エンドポイント アドレスを確認します。

  4. ドメインとエンドポイントへのアクセスをテストします。HTTP ステータスコード 200 が返されれば、ALB Ingress が正常に動作していることを示します。

    curl -H "Host:ingress-demo.com" http://<endpoint_address>/coffee -s -o /dev/null -w "%{http_code}\n"

kubectl

  1. 次の内容を含む coffee-ingress.yaml という名前のファイルを作成します。次に、kubectl apply -f coffee-ingress.yaml コマンドを実行して ALB Ingress を作成します。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: coffee-ingress
      namespace: default
    spec:
      ingressClassName: alb
      rules:
      - host: ingress-demo.com
        http:
          paths:
          - path: /coffee
            backend:
              service: 
                name: coffee-svc
                port:
                  number: 80
            pathType: Prefix

    一致ルール (pathType)

    説明

    Prefix

    リクエストパスをプレフィックスに基づいて照合します。たとえば、/coffee/1 または /coffee/buy/1 へのリクエストは一致しますが、/cof または /coffeebuy/1 へのリクエストは一致しません。

    Exact

    リクエストパスを完全に照合します。/coffee へのリクエストのみが一致します。

    ImplementationSpecific

    一致動作は Ingress コントローラーの実装に依存します。ALB Ingress コントローラーの場合、このタイプは完全一致と同等です。

  2. Ingress を表示し、ADDRESS フィールドからエンドポイント アドレスを取得します。

    kubectl get ingress coffee-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

    期待される出力:

    alb-******************.cn-wulanchabu.alb.aliyuncsslb.com
  3. ドメインとエンドポイントへのアクセスをテストします。HTTP ステータスコード 200 が返されれば、ALB Ingress が正常に動作していることを示します。

    curl -H "Host:ingress-demo.com" http://<endpoint_address>/coffee -s -o /dev/null -w "%{http_code}\n"

課金

  • ALB Ingress コントローラー:マネージド ACK コンポーネントであり、無料です。

  • ALB インスタンス:各 AlbConfig リソースオブジェクトは、対応する ALB インスタンスを作成します。ALB インスタンスには 従量課金が適用されます。

本番デプロイ

  • DNS の設定:CNAME レコードを作成し、サービスドメインを ALB インスタンスのパブリックエンドポイントにマッピングします。これにより、ドメインがインスタンスエンドポイントから分離され、高可用性かつ柔軟なサービスエントリポイントを確保できます。

  • HTTPS の有効化:証明書管理サービスを使用して証明書を一元管理し、Ingress リソースの tls フィールドで証明書を宣言的に参照することで、HTTPS でサービスのトラフィックを保護します。

クォータと制限

  • AlbConfig、 Ingress、 Service、および名前空間のリソース名は、aliyun で始めることはできません。

  • ALB Ingress のクォータ制限については、「ALB クォータの計算」をご参照ください。

  • ALB Ingress がサポートするリージョンとアベイラビリティーゾーンについては、「ALB がサポートするリージョンとゾーン」をご参照ください。

FAQ

Why does an Ingress return HTTP error codes?

Causes

  • 503 (Service Temporarily Unavailable) error

    • No matching routing rule: The request path does not match any routing rules configured in the Ingress.

    • No healthy backend pods: The associated Service has no ready pods, which results in an empty endpoints object.

  • 502 (Bad Gateway) error

    After an HTTP or HTTPS listener receives a client connection request, the ALB sends an HTTP 502 Bad Gateway status code to the client because it fails to forward the request to a Pod or receive a response from the Pod.

  • 404 (Not Found) error

    This typically occurs when a request matches an Ingress routing rule, but its URL does not match the service path of the application in the backend pod.

  • 400 (Bad Request) error

    This can occur for several reasons, such as sending an HTTP request to an HTTPS listener.

For more information about HTTP error codes, see ALB status codes.

Solution

  1. Check the Ingress status: Run the kubectl describe ingress <ingress-name> -n <namespace> command and inspect the Events section for error messages. If an event like listener is not exist in alb appears, add the required listener configuration to your AlbConfig.

    ...
    Events:
      Type     Reason                  Age     From     Message
      ----     ------                  ----    ----     -------
      Warning  FailedBuildModel        ****    ingress  listener is not exist in alb, port: 443, protocol: HTTPS
      Warning  FailedBuildModel        ****    ingress  listener not found for (443/HTTPS), with ingresses 1
    ...
  2. Check the backend endpoints: Run the kubectl get endpoints <service-name> -n <namespace> command to confirm that the ENDPOINTS field lists at least one healthy pod IP address and port. If it is empty, verify that the selector of the Service matches the labels of the pods, and that the pods are in the Running state.

  3. Check the pod status and logs: Run kubectl get pod -l <app=your-app> -n <namespace> to view the pod status. Then, use the pod name to run kubectl logs <pod-name> -n <namespace> and check the application logs for startup failures or request processing errors.

  4. Test network connectivity: From within a pod or from a node, use curl to access the backend Service's ClusterIP or a pod IP to verify that the service is reachable within the cluster.

Why is HTTPS inaccessible after TLS configuration?

Causes

  • The ALB instance is not listening on port 443: You have configured TLS for the Ingress, but the corresponding HTTPS:443 listener has not been created.

  • Incorrect certificate configuration: The Secret type is not kubernetes.io/tls or IngressTLS, or the content of tls.crt and tls.key in the data field is incorrect or does not match.

  • Stale certificate: The ALB instance may be using an old certificate. This happens if you update a certificate in Alibaba Cloud Certificate Management Service but do not update the certificate ID in your AlbConfig, or if automatic discovery and reconciliation fails to trigger.

Solution

  1. Check the listener port: Run the kubectl describe albconfig <alb-name> -n <namespace> command to verify that the spec.listeners.port: 443 and spec.listeners.protocol: HTTPS configurations are present.

  2. Check the Ingress configuration: Verify that the Ingress configuration includes the alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}] annotation. This annotation associates the Ingress with HTTP and HTTPS listeners.

  3. Check the Secret configuration: In the Ingress configuration, check the secretName field of spec.tls to confirm that the correct Secret is referenced. Run the kubectl get secret <secret-name> -n <namespace> -o yaml command to confirm the Secret type and data integrity.

How to configure Ingress domain resolution?

  1. Register a domain name.

  2. Add a CNAME record.

    For example, add a DNS record with the record type CNAME, the host record @ (which represents the root domain, such as ingress-demo.com), and the record value as the Ingress endpoint address.
  3. In a browser, go to http://ingress-demo.com/coffee to verify that the domain name resolution is working.

    After access is successful, an NGINX test page is returned, displaying information such as the Server address, Server name, Date, and URI (with the value /coffee) of the backend pod. This indicates that the Ingress has correctly routed the request to the backend pod.

    For verification, replace the example with your registered domain name. If the domain name resolution fails, see Quick troubleshooting for domain name resolution failures.

How do I configure HTTPS for an Ingress?

  1. Purchase an official certificate, and apply for a certificate. Make sure that the certificate you want to use is in the [発行済み] state.

  2. Download the SSL certificate.

    This example shows how to download the PEM-formatted certificate file for the ingress-demo.com domain, with the server type set to Other.
  3. Create a Secret to store the certificate file.

    1. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[設定] > [秘密] を選択します。

    2. On the [シークレット] page, select the default namespace and then click [作成する] on the left. Add the following configurations and click [OK].

      • [名前]: ingress-tls

      • [タイプ]: [TLS 証明書]

      • [証明書]: The full content of the downloaded and unzipped certificate file (.pem).

      • [キー]: The full content of the downloaded and unzipped private key file (.key).

  4. Update the AlbConfig to add an HTTPS:443 listener for the ALB instance.

    1. In the left-side navigation pane, choose ワークロード > カスタムリソース. On the [リソースオブジェクト] tab, search for AlbConfig, and then click the search result.

    2. In the list of AlbConfig resource objects, find the target resource alb and click [YAML の編集] in the [アクション] column.

    3. Add the spec.listeners.port: 443 and spec.listeners.protocol: HTTPS fields, and then click [OK].

      spec:
          config:
            addressAllocatedMode: Fixed
            addressType: Internet
            zoneMappings:
              - vSwitchId: vsw-xxx
              - vSwitchId: vsw-xxx
          listeners:
            - port: 80
              protocol: HTTP
            - port: 443
              protocol: HTTPS
  5. Update the Ingress to add a TLS configuration and associate it with the HTTPS:443 listener.

    1. In the left-side navigation pane, choose ネットワーク > Ingress. In the [アクション] column of the target Ingress, click [更新].

    2. Add the following configurations and click [OK].

      • [TLS 設定]: Enabled

      • [ドメイン名]: ingress-demo.com

      • [シークレット]: ingress-tls

      • [注釈]: alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]

  6. In a browser, go to https://ingress-demo.com/coffee to verify HTTPS access.

    The page displays the NGINX logo and server response information. The Server address, Server name, and URI (with the value /coffee) are returned as expected. This confirms that HTTPS is configured correctly and that the Ingress routes requests to the coffee backend pod.

    For verification, replace the example with your registered domain name.

For more information about how to configure HTTPS certificates, see Configure HTTPS certificates for encrypted communication.

How to manually create AlbConfig and IngressClass?

Create an AlbConfig

  1. Log on to the VPC console and record the IDs of at least two vSwitches that are in different availability zones within the VPC where the cluster is deployed.

    The availability zones of the configured vSwitches must be supported by ALB. For more information, see ALB regions and zones.
  2. Replace zoneMappings.vSwitchId in the following code with the vSwitch IDs that you obtained in the previous step. Save the content to a file named albconfig.yaml and run kubectl apply -f albconfig.yaml to create the AlbConfig.

    For more detailed steps, see Create an AlbConfig.
    apiVersion: alibabacloud.com/v1
    kind: AlbConfig
    metadata:
      name: alb # Do not create another AlbConfig resource with the same name.
    spec:
      config:
        name: alb-test
        addressType: Internet
        zoneMappings:
        - vSwitchId: vsw-****cg2a9g71hx8go**** # Replace with your actual vSwitch ID.
        - vSwitchId: vsw-****un9tql5t8nh15**** # Replace with your actual vSwitch ID.
      listeners:
        - port: 80
          protocol: HTTP

Create an IngressClass

The IngressClass resource associates an AlbConfig with Ingress resources. When you specify ingressClassName: alb in an Ingress, it uses the AlbConfig defined in the alb IngressClass.

Save the following content to a file named IngressClass.yaml, and then run kubectl apply -f IngressClass.yaml to create the IngressClass.

The spec.parameters.name field must be set to the name of the AlbConfig. The default AlbConfig created when you install the component is named alb. For more information, see Use IngressClass to associate an AlbConfig with an Ingress.
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
spec:
  controller: ingress.k8s.alibabacloud/alb
  parameters:
    apiGroup: alibabacloud.com
    kind: AlbConfig
    name: alb # This must match the name of the AlbConfig resource.

関連ドキュメント

ALB Ingress の高度な使用法

ALB Ingress 転送ルールのカスタマイズ

ALB Ingress によるカナリアリリースの実行