デフォルトでは、Container Service for Kubernetes (ACK) クラスター内の Service は外部ネットワークから分離されています。これらの Service をユーザーに公開するには、ALB Ingress を使用できます。これは、Application Load Balancer (ALB) をエントリポイントとして活用し、インバウンドトラフィックを管理します。ALB は、ドメインベースのルーティング、セキュリティ保護、および高可用性を提供します。
仕組み
|
Service タイプの制限
Flannel ネットワークプラグインを使用する場合、ALB Ingress のバックエンドサービスは NodePort および LoadBalancer タイプのみをサポートします。
ステップ 1: ALB Ingress Controller のインストール
クラスター作成時
ACK コンソールにログインし、[Kubernetes クラスターの作成] をクリックします。
[コンポーネント設定] ステップで、[Ingress] セクションを見つけ、[ALB Ingress] を選択します。
新しい ALB インスタンスを作成するオプションを選択し、画面の指示に従ってクラスターを作成します。
ALB インスタンス
説明
新規
ALB インスタンス、
AlbConfig、およびIngressClassを自動的に作成します。ALB インスタンス: 従量課金制の標準 ALB インスタンス (パブリックまたはプライベート) がクラスターの Virtual Private Cloud (VPC) 内に作成され、ポート 80 (HTTP) にデフォルトのリスナーが設定されます。
AlbConfig と IngressClass: 対応する
AlbConfigおよびIngressClassリソースがクラスター内に自動的に作成され、新しい ALB インスタンスに関連付けられます。
既存
このオプションは、クラスターネットワークに既存の VPC を選択した場合にのみ使用できます。
既存の ALB インスタンスを使用し、関連する
AlbConfigとIngressClassを自動的に作成します。選択した ALB インスタンスは、次の基準を満たす必要があります:エディション: 標準または WAF-enabled である。
ネットワーク: クラスターと同じ VPC 内にある。
関連付け: 他のクラスターに既に関連付けられていない。
今は作成しない
ALB Ingress Controller コンポーネントのみをインストールします。後で AlbConfig および IngressClass リソースを手動で作成する必要があります。このオプションは、ALB インスタンスの設定をカスタマイズする必要があるシナリオに適しています。
既存のクラスターの場合
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[アドオン] ページで、[ネットワーク] タブをクリックします。[ALB Ingress Controller] を見つけて、[インストール] をクリックします。
新しい ALB インスタンスを作成するオプションを選択し、[OK] をクリックします。
ALB インスタンス
説明
新規
ALB インスタンス、
AlbConfig、およびIngressClassを自動的に作成します。ALB インスタンス: 従量課金制の標準 ALB インスタンス (パブリックまたはプライベート) がクラスターの Virtual Private Cloud (VPC) 内に作成され、ポート 80 (HTTP) にデフォルトのリスナーが設定されます。
AlbConfig と IngressClass: 対応する
AlbConfigおよびIngressClassリソースがクラスター内に自動的に作成され、新しい ALB インスタンスに関連付けられます。
既存
既存の ALB インスタンスを使用し、関連する
AlbConfigとIngressClassを自動的に作成します。選択した ALB インスタンスは、次の基準を満たす必要があります:エディション: 標準または WAF-enabled である。
ネットワーク: クラスターと同じ VPC 内にある。
関連付け: 他のクラスターに既に関連付けられていない。
今は作成しない
ALB Ingress Controller コンポーネントのみをインストールします。後で AlbConfig および IngressClass リソースを手動で作成する必要があります。このオプションは、ALB インスタンスの構成をカスタマイズする必要があるシナリオに適しています。
ステップ 2: サンプルアプリケーションのデプロイ
この例では、coffee という名前のサンプル Nginx アプリケーションを Deployment としてデプロイし、coffee-svc という名前の Service でクラスター内部に公開します。
コンソール
[クラスター] ページで、管理したいクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[YAML から作成] をクリックします。[サンプルテンプレート] を [カスタム] に設定し、次の内容をテンプレートエディターにコピーして、[デプロイ] をクリックします。
表示されるダイアログボックスで、[表示] をクリックし、Pod のステータスが
Runningであることを確認します。
kubectl
coffee-deployment-service.yamlという名前のファイルを次の内容で作成します:アプリケーションをデプロイします。
kubectl apply -f coffee-deployment-service.yamlPod が実行中であることを確認します。
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
ステップ 3: ALB Ingress を作成する
ALB Ingress のドメイン名とパスマッピングを設定することで、ingress-demo.com/coffee へのリクエストをクラスター内の coffee-svc Service にルーティングできます。
ACK 専用クラスターで ALB Ingress を使用するには、まず ALB Ingress Controller にアクセス権限を付与してください。
コンソール
左側のナビゲーションウィンドウで、 を選択します。
default名前空間を選択し、[Ingress の作成] をクリックします。以下のように設定し、[OK] をクリックします。
名前:
coffee-ingressドメイン名:
ingress-demo.comマッピング
パス:
/coffeeルール:
Prefixサービス:
coffee-svcポート:
80マッチングルール(pathType)
説明
Prefix
URL パスのプレフィックスに基づいてマッチングします。例えば、パスが
/coffeeのルールは、/coffee/1や/coffee/buy/1のリクエストにマッチしますが、/cofや/coffeebuy/1にはマッチしません。Exact
URL パスに完全に一致します。パスが
/coffeeのルールの場合、/coffeeというパスへのリクエストのみがマッチします。ImplementationSpecific
マッチング動作は Ingress コントローラーに依存します。ALB Ingress controller の場合、このタイプは
Exactマッチと同等です。
[エンドポイント] を取得します。
ALB Ingress が有効になるまで約 10 秒かかります。更新ボタンをクリックしてエンドポイント情報を取得します。長時間経ってもエンドポイント情報が更新されない場合は、Ingress 名をクリックして [イベント] タブに移動し、トラブルシューティングを行ってください。

ドメイン名とエンドポイントをテストします。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というファイルを作成します。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
URL パスのプレフィックスに基づいてマッチングします。例えば、パスが
/coffeeのルールは、/coffee/1や/coffee/buy/1のリクエストにマッチしますが、/cofや/coffeebuy/1にはマッチしません。完全
URL パスに完全に一致します。パスが
/coffeeのルールの場合、/coffeeというパスへのリクエストのみがマッチします。ImplementationSpecific
マッチング動作は Ingress コントローラーに依存します。ALB Ingress controller の場合、このタイプは
Exactマッチと同等です。Ingress をデプロイします。
kubectl apply -f coffee-ingress.yamlADDRESSフィールドから Ingress のパブリックエンドポイントを取得します。アドレスが割り当てられるまで少し時間がかかる場合があります。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 Controller: これはマネージド ACK コンポーネントであり、料金は発生しません。
ALB インスタンス: 各
AlbConfigリソースオブジェクトは、対応する ALB インスタンスを作成します。ALB インスタンスは、従量課金ベースで課金されます。
本番環境に適用
DNS の設定: DNS プロバイダーで CNAME レコードを作成し、ビジネスドメインを ALB インスタンスのパブリックエンドポイントに向けます。これにより、ドメイン名が ALB インスタンスエンドポイントから分離され、サービスのエントリポイントの高可用性と柔軟な設定が保証されます。
HTTPS の有効化: Certificate Management Serviceを使用して証明書を管理し、Ingress リソースの
tlsセクションでそれらを参照して、Service を HTTPS で保護します。
クォータと制限
AlbConfig、Ingress、Service、および名前空間リソースの名前は
aliyunで始めることはできません。ALB Ingress のクォータ制限については、「ALB クォータの計算方法」をご参照ください。
ALB の可用性については、「ALB が利用可能なリージョンとゾーン」をご参照ください。
よくある質問
Ingress にアクセスすると 503、502、または 404 エラーが発生するのはなぜですか
原因
503 (Service Temporarily Unavailable) エラー
一致するルーティングルールがない: リクエストパスが Ingress で設定されたルーティングルールと一致しません。
正常なバックエンド Pod がない: Service に関連付けられているすべての Pod が準備できていないか、存在しません。これにより、Endpoints オブジェクトが空になります。
502 (Bad Gateway) エラー
HTTP または HTTPS リスナーがクライアント接続リクエストを受信します。ALB インスタンスがリクエストを Pod に転送できないか、Pod からのレスポンスを受信できない場合、インスタンスは HTTP 502 Bad Gateway ステータスコードをクライアントに送信します。
404 (Not Found) エラー
これは通常、リクエストが Ingress で定義されたルーティングルールに一致したが、Pod 内のアプリケーションによって提供される実際のサービス URL とは一致しないことを意味します。
その他の HTTP エラーコードについては、「ALB ステータスコード」をご参照ください。
解決策
Ingress のステータスの確認
コマンド
kubectl describe ingress <ingress-name> -n <namespace>を実行し、Eventsセクションでエラーメッセージを確認します。たとえば、listener is not exist in albのようなイベントが表示された場合、AlbConfigで Ingress リソースに必要な リスナーを作成する必要があります。... 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 ...バックエンドのエンドポイントの確認
コマンド
kubectl get endpoints <service-name> -n <namespace>を実行して、ENDPOINTSフィールドに少なくとも 1 つの正常な Pod の IP アドレスとポートが含まれていることを確認します。フィールドが空の場合は、Service のselectorが Pod のlabelsと一致していることを確認し、Pod がRunning状態であることを確認します。Pod のステータスとログの確認
まず、
kubectl get pod -l <app=your-app> -n <namespace>を実行してアプリケーション Pod のステータスを確認します。次に、コマンドkubectl logs <pod-name> -n <namespace>を実行して、特定の Pod のログを調べて、起動の失敗やリクエスト処理のエラーがないか確認します。ネットワーク接続のテスト
別の Pod 内から、またはノードから直接
curlを使用して、バックエンドサービスの ClusterIP または直接 Pod IP にアクセスします。これにより、クラスター内から Service に到達可能であることが確認されます。
Ingress に TLS を設定した後、HTTPS が機能しないのはなぜですか
原因
HTTPS リスナーが見つからない
Ingress で TLS を設定しましたが、基盤となる ALB インスタンスが
HTTPS:443でリッスンするように設定されていません。不正な Secret 設定
Ingress で参照されている Secret が
kubernetes.io/tlsまたはIngressTLSタイプではない、またはtls.crtとtls.keyのdataフィールドが無効または不一致です。証明書の更新が同期されていない
Certificate Management Service で証明書を更新しましたが、変更が ALB インスタンスに反映されていません。これは、
AlbConfigの証明書 ID が更新されていない場合、または自動検出と調整プロセスが完了していない場合に発生する可能性があります。ALB インスタンスは引き続き古い証明書を参照しています。
解決策
ALB リスナー設定の確認
AlbConfigリソースを調べて、ポート 443 の HTTPS リスナーが定義されていることを確認します。kubectl describe albconfig <alb-name> -n <namespace>spec.listeners.port: 443およびspec.listeners.protocol: HTTPSを持つリスナーエントリを探します。Ingress アノテーションの確認
Ingress リソースに次のアノテーションが含まれていることを確認して、HTTP と HTTPS の両方のリスナーに関連付けます。
alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]Secret 設定の検証
Ingress マニフェストの
spec.tlsセクションを確認して、secretNameフィールドが正しい Secret を参照していることを確認します。Secret 自体を調べて、そのタイプとデータの整合性を検証します:
kubectl get secret <secret-name> -n <namespace> -o yaml
タイプが
kubernetes.io/tlsであり、tls.crtおよびtls.keyフィールドに有効な base64 エンコードされたデータが含まれていることを確認します。
Ingress の DNS を設定するにはどうすればよいですか
DNS プロバイダーの管理コンソールで、目的のホスト名を Ingress エンドポイントアドレスに向ける CNAME レコードを追加します。
設定例:
レコードタイプ:
CNAMEホスト:
@(これは通常、ingress-demo.comなどのルートドメインを表します)値: Ingress のエンドポイントアドレス(例:ALB インスタンスのアドレス)
設定の確認
DNS レコードが伝播する時間をおいてから、Web ブラウザーを開き、ドメイン
http://ingress-demo.com/coffeeにアクセスします。ページが正常に読み込まれた場合、DNS 名前解決は機能しています。
検証には実際に登録したドメイン名を使用してください。ドメイン名の名前解決が失敗した場合は、「ドメイン名解決の失敗に関するクイックトラブルシューティング」をご参照ください。
Ingress に HTTPS を設定するにはどうすればよいですか
認証局 (CA) に申請を提出し、公式証明書を購入し、証明書が発行済みステータスであることを確認します。
この例では、
ingress-demo.comドメイン名の PEM 形式の証明書ファイルをダウンロードする方法を示します。サーバータイプはその他に設定されています。証明書用の Kubernetes Secret を作成します。Ingress コントローラーがアクセスできるように、証明書と秘密鍵を Kubernetes Secret に保存する必要があります。
[クラスター] ページで、変更したいクラスターの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[Secrets] ページで、
default名前空間を選択し、左上隅の [作成] をクリックします。 次の設定を追加し、[OK] をクリックします。名前:
ingress-tlsタイプ: TLS 証明書
証明書: 証明書ファイル (
.pem) の全内容を貼り付けます。キー: 秘密鍵ファイル (
.key) の全内容を貼り付けます。

AlbConfigに HTTPS リスナーを追加します。左側のナビゲーションウィンドウで、 を選択します。[リソースオブジェクト] タブで、
AlbConfigを検索してクリックします。ターゲットの
AlbConfigリソース (たとえばalb) を見つけます。[操作] 列で、[YAML の編集] をクリックします。spec.listenersセクションに、ポート 443 の HTTPS 用の新しいリスナーを追加します:
[OK] をクリックして変更を適用します。
Ingress を更新して TLS を有効にします。
左側のナビゲーションウィンドウで、 を選択します。ターゲット Ingress の [操作] 列で、[更新] をクリックします。
次の設定を追加し、[OK] をクリックします。
TLS 設定 をオンにします
ドメイン名:
ingress-demo.comSecret:
ingress-tls
アノテーション:
alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]
Web ブラウザーを開き、
https://ingress-demo.com/coffeeにアクセスします。接続は安全になり、HTTPS を使用するようになります。
検証にはご自身の登録ドメインを使用してください。
詳細については、「暗号化通信のための HTTPS 証明書の設定」をご参照ください。
AlbConfig と IngressClass を手動で作成するにはどうすればよいですか?
AlbConfig の作成
VPC コンソールにログインします。クラスターの VPC 内で、異なるゾーンにある少なくとも 2 つの vSwitch の ID を特定し、記録します。
選択した vSwitch のゾーンは、サポートされている リージョンとゾーンに含まれている必要があります。
以下で
albconfig.yamlという名前のファイルを作成します。プレースホルダーzoneMappings.vSwitchIdの値を、前の手順で記録した実際のIDに置き換えてください。apiVersion: alibabacloud.com/v1 kind: AlbConfig metadata: name: alb # 同じ名前(alb)で複数のAlbConfigリソースを作成しないでください spec: config: name: alb-test addressType: Internet zoneMappings: - vSwitchId: vsw-****cg2a9g71hx8go**** # 実際の vSwitch ID に置き換えてください - vSwitchId: vsw-****un9tql5t8nh15**** # 実際の vSwitch ID に置き換えてください listeners: - port: 80 protocol: HTTP次のコマンドを実行して、クラスターに
AlbConfigリソースを作成します。kubectl apply -f albconfig.yaml
詳細については、 AlbConfig による ALB インスタンスの設定をご参照ください。
IngressClass の作成
IngressClass リソースは、AlbConfig を Ingress リソースに関連付けます。Ingress マニフェストで ingressClassName: alb と設定することで、alb という名前の IngressClass で定義された設定を使用するようコントローラーに指示します。
以下で
ingressclass.yamlという名前のファイルを作成します。spec.parameters.nameフィールドは、AlbConfigリソースのmetadata.name(この場合はalb) と一致させる必要があります。apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: alb spec: controller: ingress.k8s.alibabacloud/alb parameters: apiGroup: alibabacloud.com kind: AlbConfig name: alb # AlbConfig リソースの名前と一致させる必要があります次のコマンドを実行して
IngressClassを作成します。kubectl apply -f ingressclass.yaml
詳細については、 IngressClass を使用して AlbConfig を Ingress に関連付けるをご参照ください。