デフォルトでは、ACK クラスター内の Service は外部ネットワークから分離されています。ALB Ingress は、Application Load Balancer (ALB) を外部トラフィックのエントリポイントとして使用し、これらの Service を公開します。ALB は、ドメインベースのルーティング、セキュリティ、高可用性を提供します。
仕組み
|
|
Service タイプの制限
Flannel ネットワークプラグインを使用する場合、ALB イングレスのバックエンドサービスはNodePort とLoadBalancer タイプに制限されています。
ALB Ingress コントローラーのインストール
クラスター作成時
-
ACK コンソールにログインし、Kubernetes クラスターの作成 をクリックします。
-
コンポーネント設定 ステップの Ingress セクションで、ALB Ingress を選択します。
-
この例では、[新規] オプションを使用します。画面の指示に従ってクラスターを作成します。
[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 インスタンスの設定をカスタマイズする必要があるシナリオに適しています。
-
既存のクラスターの場合
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
-
検索ボックスを使用するか、ネットワーク タブをクリックしてコンポーネントを検索します。[ALB Ingress コントローラー] コンポーネントカードで、右下の インストール をクリックします。
-
この例では、[新規] オプションを使用します。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 をデプロイします。
コンソール
-
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
-
YAML のリソースの作成 をクリックします。カスタム ドロップダウンリストから サンプルテンプレート を選択します。次に、以下の内容をテンプレートエディターにコピーし、デプロイ をクリックします。
-
確認ダイアログボックスで、ビュー をクリックし、Pod のステータスが
Runningであることを確認します。
kubectl
-
次の内容を含む
coffee-deployment-service.yamlという名前のファイルを作成します。 -
サンプルアプリケーションの Deployment および Service を作成します。
kubectl apply -f coffee-deployment-service.yaml -
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 コントローラーにアクセス権限を付与する必要があります。
コンソール
-
左側メニューで、 をクリックします。
default名前空間を選択し、Ingress の作成 をクリックします。 -
次の 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 コントローラーの場合、このタイプは完全一致と同等です。
-
-
エンドポイント アドレスを取得します。
ALB Ingress が有効になるまでに約 10 秒かかります。更新ボタンをクリックしてエンドポイント情報を取得できます。長時間経過してもエンドポイントが更新されない場合は、Ingress 名をクリックして イベント タブに移動し、問題のトラブルシューティングを行ってください。
Ingress リストの [エンドポイント] 列で、
alb-<instance_id>.cn-wulanchabu.alb.aliyuncsslb.comのような形式の ALB エンドポイント アドレスを確認します。 -
ドメインとエンドポイントへのアクセスをテストします。HTTP ステータスコード
200が返されれば、ALB Ingress が正常に動作していることを示します。curl -H "Host:ingress-demo.com" http://<endpoint_address>/coffee -s -o /dev/null -w "%{http_code}\n"
kubectl
-
次の内容を含む
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 コントローラーの場合、このタイプは完全一致と同等です。
-
Ingress を表示し、
ADDRESSフィールドからエンドポイント アドレスを取得します。kubectl get ingress coffee-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'期待される出力:
alb-******************.cn-wulanchabu.alb.aliyuncsslb.com -
ドメインとエンドポイントへのアクセスをテストします。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
-
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 likelistener is not exist in albappears, 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 ... -
Check the backend endpoints: Run the
kubectl get endpoints <service-name> -n <namespace>command to confirm that theENDPOINTSfield lists at least one healthy pod IP address and port. If it is empty, verify that theselectorof the Service matches thelabelsof the pods, and that the pods are in theRunningstate. -
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 runkubectl logs <pod-name> -n <namespace>and check the application logs for startup failures or request processing errors. -
Test network connectivity: From within a pod or from a node, use
curlto 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:443listener has not been created. -
Incorrect certificate configuration: The Secret type is not
kubernetes.io/tlsorIngressTLS, or the content oftls.crtandtls.keyin thedatafield 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
-
Check the listener port: Run the
kubectl describe albconfig <alb-name> -n <namespace>command to verify that thespec.listeners.port: 443andspec.listeners.protocol: HTTPSconfigurations are present. -
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. -
Check the Secret configuration: In the Ingress configuration, check the
secretNamefield ofspec.tlsto confirm that the correct Secret is referenced. Run thekubectl get secret <secret-name> -n <namespace> -o yamlcommand to confirm the Secret type and data integrity.
How to configure Ingress domain resolution?
-
For example, add a DNS record with the record type
CNAME, the host record@(which represents the root domain, such asingress-demo.com), and the record value as the Ingress endpoint address. -
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?
-
Purchase an official certificate, and apply for a certificate. Make sure that the certificate you want to use is in the [発行済み] state.
-
This example shows how to download the PEM-formatted certificate file for the
ingress-demo.comdomain, with the server type set to Other. -
Create a Secret to store the certificate file.
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
-
On the [シークレット] page, select the
defaultnamespace 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).
-
-
Update the AlbConfig to add an
HTTPS:443listener for the ALB instance.-
In the left-side navigation pane, choose . On the [リソースオブジェクト] tab, search for AlbConfig, and then click the search result.
-
In the list of AlbConfig resource objects, find the target resource
alband click [YAML の編集] in the [アクション] column. -
Add the
spec.listeners.port: 443andspec.listeners.protocol: HTTPSfields, 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
-
-
Update the Ingress to add a TLS configuration and associate it with the
HTTPS:443listener.-
In the left-side navigation pane, choose . In the [アクション] column of the target Ingress, click [更新].
-
Add the following configurations and click [OK].
-
[TLS 設定]: Enabled
-
[ドメイン名]:
ingress-demo.com -
[シークレット]:
ingress-tls -
[注釈]:
alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]
-
-
-
In a browser, go to
https://ingress-demo.com/coffeeto 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
-
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.
-
Replace
zoneMappings.vSwitchIdin the following code with the vSwitch IDs that you obtained in the previous step. Save the content to a file named albconfig.yaml and runkubectl apply -f albconfig.yamlto 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.
Thespec.parameters.namefield must be set to the name of the AlbConfig. The default AlbConfig created when you install the component is namedalb. 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.