アプリケーションロードバランサー (ALB) Ingress は、NGINX Ingress と互換性があり、ALB インスタンスに基づいてトラフィック転送機能を向上させます。ALB Ingress は、複雑な転送、自動証明書の検出、HTTP、HTTPS、および Quick UDP Internet Connections (QUIC) プロトコルをサポートしています。ALB Ingress は、クラウドネイティブアプリケーションの超高弾性とレイヤー 7 での大量トラフィック負荷の分散という要件を満たします。トラフィックを管理するために、Alibaba Cloud Container Service for Kubernetes (ACK) クラスタで ALB Ingress を構成できます。このトピックでは、サービスをデプロイし、ALB Ingress を使用してサービスにアクセスする方法について説明します。
背景情報
ALB Ingress に関連する用語:
ALB Ingress コントローラー: Ingress を管理する Kubernetes コンポーネント。ALB Ingress コントローラーは、クラスタのエントリポイントとして機能し、外部トラフィックを特定のサービスにルーティングします。ALB Ingress コントローラーは、変更が検出されると、API サーバーから Ingress および AlbConfig への変更を取得します。その後、ALB Ingress コントローラーは、ALB インスタンスの作成、リスナーの構成、Ingress ルールの作成、バックエンドサーバーグループの構成という操作を順番に実行します。
AlbConfig CRD: カスタムリソース定義 (CRD) は Kubernetes API を拡張し、カスタムリソースを作成できるようにします。AlbConfig は 1 つの ALB インスタンスに対応します。
IngressClass: IngressClass は、Ingress コントローラーのクラスまたは識別子を定義する Kubernetes Ingress の属性です。IngressClass を使用すると、クラスタ内で複数の Ingress コントローラーを使用し、Ingress ごとにコントローラーを指定できます。
Ingress: Ingress は、外部トラフィックの転送ルールとアクセスルールを定義する Kubernetes のリソースオブジェクトです。Ingress コントローラーは、Ingress に基づいてトラフィックを転送します。アノテーションを使用して、ALB Ingress で転送ルールを構成できます。構成が完了すると、転送ルールに基づいて、HTTP または HTTPS リクエストを対応するサービスに転送できます。
Service: Kubernetes では、Service は、同じ論理機能を持つ Pod のセットを定義する抽象リソースオブジェクトであり、固定仮想 IP アドレスとポートを使用して Pod にアクセスできます。
Service は、アプリケーションへの安定したアクセスを提供し、他のアプリケーションまたはサービスが Service の仮想 IP アドレスとポートにアクセスすることで、バックエンド Pod と通信できるようにします。これにより、特定の Pod の IP アドレスとポートを取得する必要がなくなります。Service は、複製された Pod のセット上で実行されるバックエンドアプリケーションの抽象化です。
次の図は、ALB インスタンスと ALB Ingress の関係を示しています。
制限事項
AlbConfig、名前空間、Ingress、および Service の名前は、aliyun で始めることはできません。
シナリオ
次の例では、NGINX サービスが 4 つの Pod にデプロイされています。このトピックでは、この例を使用して、同じドメイン名宛てであるが URL パスが異なるリクエストを転送するように ALB Ingress を構成する方法について説明します。
フロントエンドリクエスト | 宛先サービス |
|
|
|
|
前提条件
ACK クラスタが作成されており、クラスタの Kubernetes バージョンは 1.18 以降です。詳細については、「ACK クラスタの作成」を参照してください。
ALB Ingress コントローラーがクラスタにインストールされています。詳細については、「ALB Ingress コントローラーの管理」を参照してください。
クラスタが存在する仮想プライベートクラウド (VPC) の異なるゾーンに 2 つの vSwitch が作成されています。詳細については、「vSwitch の作成と管理」を参照してください。
ステップ 1: バックエンドサービスをデプロイする
ACK コンソール
ACK コンソール にログインします。左側のナビゲーションペインで、クラスタ をクリックします。
クラスタ ページで、管理するクラスタを見つけて、その ID をクリックします。クラスタ詳細ページの左側のナビゲーションペインで、
を選択します。デプロイメント ページの右上隅にある YAML から作成 をクリックします。
作成 ページに移動します。
サンプルテンプレート: ドロップダウンリストから カスタム を選択します。
テンプレート: 次のコードをコピーしてコードエディターに貼り付けます。YAML 構成ファイルは、
coffee
およびtea
という名前の 2 つのデプロイメントと、coffee-svc
およびtea-svc
という名前の 2 つのサービスをデプロイするために使用されます。
構成が完了したら、作成 をクリックします。作成済み メッセージが表示されます。
デプロイメントとサービスが作成されていることを確認します。
左側のナビゲーションペインで、ワークロード > デプロイメント を選択します。coffee および tea という名前のデプロイメントが表示されます。
左側のナビゲーションペインで、ネットワーク > サービス を選択します。coffee-svc および tea-svc という名前のサービスが表示されます。
kubectl
cafe-service.yaml という名前のファイルを作成します。次のコンテンツをコピーしてファイルに貼り付けます。このファイルは、
coffee
およびtea
という名前の 2 つのデプロイメントと、coffee-svc
およびtea-svc
という名前の 2 つのサービスをデプロイするために使用されます。次のコマンドを実行して、デプロイメントとサービスをデプロイします。
kubectl apply -f cafe-service.yaml
予期される出力:
deployment "coffee" created service "coffee-svc" created deployment "tea" created service "tea-svc" created
デプロイメントとサービスのステータスを表示します。
次のコマンドを実行して、デプロイメントのステータスを表示します。
kubectl get deployment
予期される出力:
NAME READY UP-TO-DATE AVAILABLE AGE coffee 1/2 2 1 2m26s tea 1/1 1 1 2m26s
次のコマンドを実行して、サービスのステータスを表示します。
kubectl get svc
予期される出力:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE coffee-svc NodePort 172.16.XX.XX <none> 80:32056/TCP 9m38s tea-svc NodePort 172.16.XX.XX <none> 80:31696/TCP 9m38s
ステップ 2: AlbConfig を作成する
ACK コンソール
ACK コンソール にログインします。左側のナビゲーションペインで、クラスタ をクリックします。
クラスタ ページで、管理するクラスタを見つけて、その ID をクリックします。クラスタ詳細ページの左側のナビゲーションペインで、ワークロード > カスタムリソース を選択します。
右上隅にある YAML から作成 をクリックします。
サンプルテンプレート: ドロップダウンリストから カスタム を選択します。
テンプレート: 次のコードをコピーしてコードエディターに貼り付けます。
次の表では、構成できるパラメーターについて説明します。
パラメーター
必須
説明
metadata.name
はい
AlbConfig の名前。
説明AlbConfig の名前は、クラスタ内で一意である必要があります。したがって、AlbConfig を作成するときは、名前の競合を防ぐために、AlbConfig 名が一意であることを確認してください。
spec.config.name
いいえ
ALB インスタンスの名前。
spec.config.addressType
いいえ
ALB インスタンスのネットワークタイプ。有効な値:
インターネット (デフォルト): インターネット向け。インターネット向け ALB インスタンスは、インターネットにサービスを提供し、インターネット経由でアクセスできます。
説明ALB インスタンスがインターネット向けサービスを提供できるようにするには、ALB インスタンスを Elastic IP アドレス (EIP) に関連付ける必要があります。インターネット向け ALB インスタンスを使用する場合、インスタンス料金と、EIP の帯域幅またはデータ転送料金が課金されます。詳細については、「従量課金制」を参照してください。
イントラネット: 内部向け。内部向け ALB インスタンスは、VPC 内でサービスを提供し、インターネット経由でアクセスすることはできません。
spec.config.zoneMappings
はい
ALB インスタンスに関連付けられている vSwitch の ID。vSwitch の作成方法の詳細については、「vSwitch の作成と管理」を参照してください。
説明指定された vSwitch は、ALB インスタンスでサポートされているゾーンにデプロイされ、クラスタと同じ VPC にデプロイされている必要があります。ALB でサポートされているリージョンとゾーンの詳細については、「ALB でサポートされているリージョンとゾーン」を参照してください。
ALB はマルチゾーンデプロイメントをサポートしています。現在のリージョンが 2 つ以上のゾーンをサポートしている場合は、高可用性を確保するために、少なくとも 2 つのゾーンの vSwitch を選択します。
spec.listeners
いいえ
ALB インスタンスのリスナーポートとプロトコル。この例では、ポート 80 を使用する HTTP リスナーが構成されています。
リスナーは、ALB がトラフィックを受信する方法を定義します。リスナー構成を保持することをお勧めします。保持しない場合は、ALB Ingress を使用する前にリスナーを作成する必要があります。
構成が完了したら、作成 をクリックします。作成済み メッセージが表示されます。
ALB インスタンスが作成されていることを確認します。
ALB コンソール にログインします。
上部のナビゲーションバーで、ALB インスタンスがデプロイされているリージョンを選択します。
インスタンス ページで、alb-test という名前の ALB インスタンスがインスタンスリストに表示されていることを確認します。
kubectl
alb-test.yaml という名前のファイルを作成し、次のコンテンツをファイルに追加します。このファイルは、AlbConfig を作成するために使用されます。
次の表では、構成できるパラメーターについて説明します。
パラメーター
必須
説明
metadata.name
はい
AlbConfig の名前。
説明AlbConfig の名前は、クラスタ内で一意である必要があります。したがって、AlbConfig を作成するときは、名前の競合を防ぐために、AlbConfig 名が一意であることを確認してください。
spec.config.name
いいえ
ALB インスタンスの名前。
spec.config.addressType
いいえ
ALB インスタンスのネットワークタイプ。有効な値:
インターネット (デフォルト): インターネット向け。インターネット向け ALB インスタンスは、インターネットにサービスを提供し、インターネット経由でアクセスできます。
説明ALB インスタンスがインターネット向けサービスを提供できるようにするには、ALB インスタンスを Elastic IP アドレス (EIP) に関連付ける必要があります。インターネット向け ALB インスタンスを使用する場合、インスタンス料金と、EIP の帯域幅またはデータ転送料金が課金されます。詳細については、「従量課金制」を参照してください。
イントラネット: 内部向け。内部向け ALB インスタンスは、VPC 内でサービスを提供し、インターネット経由でアクセスすることはできません。
spec.config.zoneMappings
はい
ALB インスタンスに関連付けられている vSwitch の ID。vSwitch の作成方法の詳細については、「vSwitch の作成と管理」を参照してください。
説明指定された vSwitch は、ALB インスタンスでサポートされているゾーンにデプロイされ、クラスタと同じ VPC にデプロイされている必要があります。ALB でサポートされているリージョンとゾーンの詳細については、「ALB でサポートされているリージョンとゾーン」を参照してください。
ALB はマルチゾーンデプロイメントをサポートしています。現在のリージョンが 2 つ以上のゾーンをサポートしている場合は、高可用性を確保するために、少なくとも 2 つのゾーンの vSwitch を選択します。
spec.listeners
いいえ
ALB インスタンスのリスナーポートとプロトコル。この例では、ポート 80 を使用する HTTP リスナーが構成されています。
リスナーは、ALB がトラフィックを受信する方法を定義します。リスナー構成を保持することをお勧めします。保持しない場合は、ALB Ingress を使用する前にリスナーを作成する必要があります。
次のコマンドを実行して、AlbConfig を作成します。
kubectl apply -f alb-test.yaml
予期される出力:
albconfig.alibabacloud.com/alb-demo created
ステップ 3: IngressClass を作成する
AlbConfig ごとに IngressClass を作成することをお勧めします。
ACK コンソール
ACK コンソール にログインします。左側のナビゲーションペインで、クラスタ をクリックします。
クラスタ ページで、管理するクラスタを見つけて、その ID をクリックします。クラスタ詳細ページの左側のナビゲーションペインで、ワークロード > カスタムリソース を選択します。
右上隅にある YAML から作成 をクリックします。
サンプルテンプレート: ドロップダウンリストから カスタム を選択します。
テンプレート: 次のコードをコピーしてコードエディターに貼り付けます。
次の表では、構成できるパラメーターについて説明します。
パラメーター
必須
説明
metadata.name
はい
IngressClass の名前。
説明IngressClass の名前は、クラスタ内で一意である必要があります。したがって、IngressClass を作成するときは、名前の競合を防ぐために、IngressClass 名が一意であることを確認してください。
spec.parameters.name
はい
関連付けられている AlbConfig の名前。
構成が完了したら、作成 をクリックします。作成済み メッセージが表示されます。
IngressClass が作成されていることを確認します。
左側のナビゲーションペインで、ワークロード > カスタムリソース を選択します。
リソースオブジェクト タブをクリックします。
API グループ 検索ボックスに、IngressClass と入力します。作成した IngressClass が表示されます。
kubectl
alb.yaml という名前のファイルを作成し、次のコンテンツをファイルに追加します。
次の表では、構成できるパラメーターについて説明します。
パラメーター
必須
説明
metadata.name
はい
IngressClass の名前。
説明IngressClass の名前は、クラスタ内で一意である必要があります。したがって、IngressClass を作成するときは、名前の競合を防ぐために、IngressClass 名が一意であることを確認してください。
spec.parameters.name
はい
関連付けられている AlbConfig の名前。
次のコマンドを実行して、IngressClass を作成します。
kubectl apply -f alb.yaml
予期される出力:
ingressclass.networking.k8s.io/alb created
ステップ 4: Ingress を作成する
ACK コンソール
ACK コンソール にログインします。左側のナビゲーションペインで、クラスタ をクリックします。
クラスタページで、管理するクラスタを見つけて、その名前をクリックします。左側のナビゲーションペインで、ネットワーク > Ingress を選択します。
Ingress ページで、Ingress の作成 をクリックします。Ingress の作成 ダイアログボックスで、パラメーターを構成します。
パラメーター
説明
例
ゲートウェイタイプ
ビジネス要件に基づいて、ALB または Nginx を選択できます。
ALB
名前
Ingress の名前を指定します。
cafe-ingress
Ingress クラス
Ingress のクラスを指定します。
alb
リスナー/ポート
AlbConfig で指定した ALB インスタンスのリスナーポートとプロトコル。リスナーとプロトコルは、ALB インスタンスがトラフィックを受信して処理する方法を定義します。
HTTP:80
ルール
+ ルールの追加 をクリックして、Ingress ルールを追加します。
ドメイン名: カスタムドメイン名を入力します。
マッピング: 次のパラメーターを指定します。
パス: バックエンドサービスの URL パスを入力します。この例では、ルートパス / が使用されています。
ルール: プレフィックス (プレフィックスベースの照合)、完全一致 (完全一致)、または Implementationspecific (デフォルト値) を選択できます。
サービス: バックエンドサービスを選択します。
ポート: 公開するサービスポートを指定します。
ドメイン名に複数のパスを構成できます。+ 追加 をクリックしてパスを追加します。
ドメイン名: demo.domain.ingress.top
マッピング:
パス: /tea
ルール: ImplementationSpecific。これはデフォルト値です。
サービス: tea-svc
ポート: 80
マッピング:
パス: /coffee
ルール: ImplementationSpecific。これはデフォルト値です。
サービス: coffee-svc
ポート: 80
TLS 設定
TLS 認証を有効にするかどうかを指定します。Ingress の TLS 認証を有効にできます。
ドメイン名: カスタムドメイン名。
シークレット: 使用するシークレットを選択します。
シークレットを作成するには、次の手順を実行します。
シークレット の右側にある 作成 をクリックします。
シークレットの作成 ダイアログボックスで、名前、証明書、および キー パラメーターを構成します。次に、OK をクリックします。
シークレット ドロップダウンリストから、作成したシークレットを選択します。
+ 追加 をクリックして、TLS 証明書を追加できます。
TLS 設定 をオフにします。この例では、TLS 証明書を構成する必要はありません。
詳細
カナリアリリース: カナリアリリースを有効にします。リクエストヘッダー、Cookie、および重み付けに基づいてカナリアリリースルールを構成できます。
説明リクエストヘッダー、Cookie、および重み付けのいずれか 1 つの要素のみに基づいてカナリアリリースルールを構成できます。また、リクエストヘッダー、Cookie、および重み付けに基づいて同時にカナリアリリースルールを構成することもできます。この場合、リクエストヘッダー、Cookie、および重み付けは優先順位の高い順に有効になります。
リクエストヘッダーに基づく:
nginx.ingress.kubernetes.io/canary-by-header
、nginx.ingress.kubernetes.io/canary-by-header-value
、またはnginx.ingress.kubernetes.io/canary-by-header-pattern
アノテーションを追加することで、リクエストヘッダーに基づいてトラフィックを分散します。Cookie に基づく:
nginx.ingress.kubernetes.io/canary-by-cookie
アノテーションを追加することで、Cookie に基づいてトラフィックを分散します。重み付けに基づく:
nginx.ingress.kubernetes.io/canary-weight
アノテーションを追加することで、サービスの重み付け (0 から 100 までの整数) に基づいてトラフィックを分散します。
プロトコル:
nginx.ingress.kubernetes.io/backend-protocol
アノテーションを追加することで、バックエンドサービスで使用されるプロトコルを選択します。HTTP、HTTPS、gRPC、および gRPCS がサポートされています。
パスの書き換え:
nginx.ingress.kubernetes.io/rewrite-target
アノテーションを追加して、リクエストがバックエンドサービスに転送される前に、クライアントリクエストのパスを書き換えます。
カナリアリリースをオフにします。プロトコルおよびパスの書き換えパラメーターのデフォルト値を使用します。この例では、これらのパラメーターを構成する必要はありません。
カスタム転送ルール
カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。
説明転送ルールには最大 10 個の条件を追加できます。
条件の追加 ドロップダウンリストでは、次の条件タイプを使用できます。
ドメイン名:
指定された 1 つ以上のドメイン名を含むリクエストのみがルーティングされます。複数のドメイン名の間の論理関係は OR です。ドメイン名を指定すると、システムは
alb.ingress.kubernetes.io/conditions.host-example
アノテーションを追加します。パス:
指定された 1 つ以上のパスを含むリクエストのみがルーティングされます。複数のパスの間の論理関係は OR です。パスを指定すると、システムは
alb.ingress.kubernetes.io/conditions.path-example
アノテーションを追加します。HTTP ヘッダー:
指定された 1 つ以上の HTTP ヘッダーを含むリクエストのみがルーティングされます。各 HTTP リクエストヘッダーはキーと値のペアです。たとえば、キー を
headername
に、値 をheadervalue1
に設定できます。複数のヘッダーの間の論理関係は OR です。ヘッダーを指定すると、システムはalb.ingress.kubernetes.io/conditions.http-header-example
アノテーションを追加します。
アクション ドロップダウンリストでは、次のアクションを使用できます。
転送先
受信トラフィックを複数のバックエンドサーバーグループに転送します。受信トラフィックを転送するには、次の操作を実行します。サービス ドロップダウンリストからアクセスするサービスを選択します。ポート ドロップダウンリストからサービスへの接続に使用するポートを選択します。各バックエンドサーバーグループのカスタム重みを指定します。
説明アクションドロップダウンリストから転送先を選択した場合は、ルールの マッピング パラメーターを構成する必要はありません。
固定レスポンスを返す
ALB Ingress を構成して、クライアントに固定コンテンツを返すことができます。クライアントに返されるステータスコード、コンテンツ、およびコンテンツのタイプを指定できます。ビジネス要件に基づいて、レスポンスステータスコード、レスポンスコンテンツタイプ (オプション)、および レスポンスコンテンツ (オプション) パラメーターを構成します。
レスポンスコンテンツタイプ パラメーターの有効な値:
text/plain: コンテンツがプレーンテキストであることを示します。
text/css: コンテンツが XML 形式であることを示します。
text/html: コンテンツが HTML 形式であることを示します。
application/javascript: コンテンツが JavaScript 形式であることを示します。
application/json: コンテンツが JSON 形式であることを示します。
カスタム転送ルールでは、複数の条件とアクションを指定できます。ドメイン名、パス、および HTTP リクエストヘッダーを転送条件として構成し、受信トラフィックをバックエンドサーバーグループに転送したり、クライアントに固定コンテンツを返すことができます。詳細については、「ALB Ingress のルーティングルールをカスタマイズする」を参照してください。
カスタム転送ルールをオフにします。この例では、カスタム転送ルールを構成する必要はありません。
アノテーション
カスタムアノテーション名と値を入力できます。ドロップダウンリストから名前でアノテーションを選択または検索することもできます。Ingress アノテーションの詳細については、「アノテーション」を参照してください。
+ アノテーションの追加 をクリックして、アノテーションを追加します。ACK は、追加できる Ingress アノテーションの数に制限を設けていません。
この例では、アノテーションを構成する必要はありません。
ラベル
Ingress の特性を記述するラベルを追加できます。
+ ラベルの追加 をクリックして、ラベルを追加します。追加できる Ingress ラベルの数に制限はありません。
この例では、ラベルを構成する必要はありません。
構成が完了したら、Ingress の作成 パネルの左下隅にある OK をクリックします。
Ingress が作成されていることを確認します。
左側のナビゲーションペインで、ネットワーク > Ingress を選択します。cafe-ingress という名前の Ingress が表示されます。
cafe-ingress の エンドポイント 列で、エンドポイントを表示します。
kubectl
cafe-ingress.yaml という名前のファイルを作成し、次のコンテンツをファイルに追加します。このファイルは、Ingress を作成するために使用されます。
次の表では、構成できるパラメーターについて説明します。
パラメーター
必須
説明
metadata.name
はい
Ingress の名前。
説明Ingress の名前は、クラスタ内で一意である必要があります。したがって、Ingress を作成するときは、名前の競合を防ぐために、Ingress 名が一意であることを確認してください。
spec.ingressClassName
はい
関連付けられている IngressClass の名前。
spec.rules.host
いいえ
HTTP ホストヘッダーのドメイン名。このパラメーターはカスタムドメイン名に設定する必要があります。
ブラウザで http://demo.domain.ingress.top などのドメイン名にアクセスすると、HTTP リクエストが送信されるときに、ブラウザは自動的に Host: demo.domain.ingress.top ヘッダーを追加します。これにより、サーバーはヘッダーに基づいて宛先ホストを識別します。Kubernetes では、Ingress ルールの host フィールドは、リクエストのホストヘッダーと照合するために使用されます。ホストヘッダーが一致すると、リクエストは対応するバックエンドサービスに送信されます。
説明カスタムドメイン名を指定する場合は、ドメイン名のインターネットコンテンツプロバイダー (ICP) ファイリングが完了していることを確認してください。完了していない場合、ドメイン名が解決できない可能性があります。詳細については、「ICP ファイリングの概要」を参照してください。
このパラメーターが構成されていない場合、Ingress ルールは、Ingress コントローラーに送信されるすべてのリクエストと一致します。
spec.rules.http.paths.path
はい
URL パス。
spec.rules.http.paths.pathType
はい
URL 照合ルール。詳細については、「URL パスに基づいてリクエストを転送する」を参照してください。
spec.rules.http.paths.backend.service.name
はい
作成したサービスの名前。
spec.rules.http.paths.backend.service.port.number
はい
作成したサービスのポート番号。
ポートは、リクエストをバックエンドサービスにルーティングするために使用されるため重要です。リクエストがバックエンドサービスにルーティングされ、予期したとおりに処理されるように、ポートが有効であることを確認してください。
次のコマンドを実行して、外部からアクセス可能なドメイン名と
coffee
およびtea
サービスのpath
を構成します。kubectl apply -f cafe-ingress.yaml
予期される出力:
ingress.networking.k8s.io/cafe-ingress created
(オプション) 次のコマンドを実行して、ALB インスタンスのドメイン名をクエリします。
kubectl get ingress
予期される出力:
NAME CLASS HOSTS ADDRESS PORTS AGE cafe-ingress alb demo.domain.ingress.top alb-m551oo2zn63yov****.cn-hangzhou.alb.aliyuncs.com 80 50s
ステップ 5: (オプション) ドメイン名解決を構成する
Ingress を作成するときに spec.rules.host
パラメーターをカスタムドメイン名に設定した場合は、CNAME レコードを追加して、ドメイン名を ALB インスタンスのドメイン名にマッピングする必要があります。その後、カスタムドメイン名を使用してサービスにアクセスできます。
ACK コンソール にログインします。
クラスタ名をクリックして、クラスタ詳細ページに移動します。
左側のナビゲーションペインで、ネットワーク > Ingress を選択します。
cafe-ingress の エンドポイント 列で、ドメイン名をコピーします。
次の手順を実行して、CNAME レコードを作成します。
Alibaba Cloud DNS コンソール にログインします。
ドメイン名解決 ページで、ドメイン名の追加 をクリックします。
ドメイン名の追加 ダイアログボックスで、ホストのドメイン名を入力し、OK をクリックします。
重要CNAME レコードを作成する前に、TXT レコードを使用してドメイン名の所有権を確認する必要があります。
管理するドメイン名を見つけて、アクション 列の DNS 設定 をクリックします。
DNS 設定 ページで、DNS レコードの追加 をクリックします。
DNS レコードの追加 パネルで、パラメーターを構成し、OK をクリックします。次の表にパラメーターを示します。
パラメーター
説明
レコードタイプ
ドロップダウンリストから CNAME を選択します。
ホスト名
ドメイン名のプレフィックス (
www
など) を入力します。DNS リクエストソース
デフォルトを選択します。
レコード値
CNAME。CNAME はコピーしたドメイン名です。
TTL
CNAME レコードが DNS サーバーにキャッシュされる生存時間 (TTL) 値を選択します。この例では、デフォルト値が使用されています。
ステップ 6: トラフィック転送をテストする
ブラウザのアドレスバーに「テストドメイン名 + URL パス」と入力して、トラフィックが指定されたサービスに転送されるかどうかを確認します。
カスタムドメイン名を構成した場合、テストドメイン名はカスタムドメイン名です。
カスタムドメイン名を構成していない場合、テストドメイン名は cafe-ingress のエンドポイントです。
この例では、demo.domain.ingress.top
が使用されています。
ブラウザのアドレスバーに
demo.domain.ingress.top/coffee
と入力します。coffee-svc サービスのページが表示されます。ブラウザのアドレスバーに
demo.domain.ingress.top/tea
と入力します。tea-svc サービスのページが表示されます。
参考資料
カスタム ALB Ingress 転送ルール、転送条件、およびアクションの構成方法の詳細については、「ALB Ingress のルーティングルールをカスタマイズする」を参照してください。
ALB Ingress の問題のトラブルシューティング方法の詳細については、「ALB Ingress コントローラーのエラーのトラブルシューティング」および「ALB Ingress に関する FAQ」を参照してください。