IBM Cloud 内の Ingress
Ingress は、アプリに要求を転送し、ネットワーク・トラフィック・ワークロードのバランスを取ることで、クラスター内のサービスをパブリック・ネットワークまたはプライベート・ネットワークに公開する Kubernetes サービス・ディスカバリー・メソッドです。 Ingress は、ユーザーが構成し、すべての着信トラフィックに適用される一連のルーティング・ルールに基づいて、サービスへの外部アクセスを管理します。
IBM Cloud Kubernetes Service クラスターをプロビジョンすると、 IBM は、Ingress を使用するために必要なすべてのコンポーネントを提供します。 次に、開始する準備ができたら、Ingress リソースを作成して、これらのコンポーネントの連携方法を指定します。
Kubernetes Ingress について詳しくは、 Kubernetes の資料を参照してください。
IBM提供の Ingress コンポーネント
クラスターの作成時に、Ingress を使用するために必要なすべてのコンポーネントが提供されます。 これらのコンポーネントは、Ingress リソースを作成するときに指定します。
- 入口ドメイン
- Ingress クラス
- アプリケーション・ロード・バランサー (ALB)
- TLS 証明書
IBM提供のコンポーネントを使用しない場合は、代わりに Ingress リソースで指定する カスタム・コンポーネントを作成 できます。
入口ドメイン
デフォルトの Ingress ドメインは、クラスター内のアプリごとに固有の URL を形成するために使用され、クラスター内の ALB の IP アドレスによって参照されるドメインです。 クラスターを作成すると、固有の Ingress サブドメインが自動的に作成され、デフォルト・ドメインとして登録されます。 クラスター内に存在する任意のドメインに デフォルト・ドメインを変更 できます。
また、 IBM Cloudの内部ドメイン・プロバイダーに登録されているか、外部プロバイダーに登録されているドメインに登録されている 独自のドメインを作成または追加 することもできます。 現在、 IBM Cloud は、 IBM Cloud Internet Services、Akamai、または Cloudflare に登録されている外部ドメインをサポートしています。
プライベート ALB は、 IBM提供の Ingress サブドメインを参照せず、代わりに カスタム・ドメイン を必要とします。
サブドメインは、以下の形式で登録されます。
<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud
以下の表では、サブドメインの各部分について説明します。
| サブドメインの構成要素 | 説明 |
|---|---|
* |
クラスターには、サブドメインのワイルドカードがデフォルトで登録されます。 |
<cluster_name> |
クラスターの名前。
|
<globally_unique_account_HASH> |
IBM Cloud アカウントにグローバルに一意のハッシュが作成されます。 アカウントのクラスター内で NLB に作成したすべてのサブドメインは、このグローバルに一意のハッシュを使用します。 |
0000 |
クラスター内に作成された各サブドメインのカウンターとして機能します。 |
<region> |
クラスターが作成されたリージョン。 |
containers.appdomain.cloud |
IBM Cloud Kubernetes Service のサブドメインのサブドメイン。 |
アプリごとに固有の URL を形成するために、アプリ・サービスへのパスがパブリック経路に付加されます。 例えば、以下のアプリの URLを参照してください。
mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1
Ingress クラス
Ingress クラスは、使用される Ingress コントローラーのタイプを決定します。 IBM には、パブリック (public-iks-k8s-nginx) とプライベート (private-iks-k8s-nginx) の 2 つの Ingress クラスが用意されています。 どちらのクラスも NGINX Ingress コントローラーを実装します。 Ingress リソースを作成するときに、指定した Ingress
クラスによって、アプリがパブリックに公開されるかプライベートに公開されるかが決まります。
独自の IngressClass リソースを作成することで、カスタム Ingress クラスを使用できます。
アプリケーション・ロード・バランサー (ALB)
ALB は、着信 HTTP、 HTTPS、または TCP サービス要求を listen してから、Ingress リソースで定義したルールに従って、それらの要求を適切なアプリ・ポッドに転送します。 クラシック・インフラストラクチャーまたは VPC インフラストラクチャーのいずれかを使用して標準クラスターを作成すると、ゾーンごとに 1 つのパブリック ALB と 1 つのプライベート ALB が自動的に作成されます。
クラシック・クラスター内の ALB
クラシック・クラスターを作成すると、各ゾーンに 1 つのパブリック ALB と 1 つのプライベート ALB が自動的に作成されます。 クラシック・クラスター内のパブリック ALB とプライベート ALB には、クラスターの存続期間中変更されない静的 IP アドレスが割り当てられます。
パブリック ALB は、クラスターのプロビジョン時に登録された同じ IBM提供の Ingress サブドメインを共有し、各パブリック ALB の個々の IP アドレスがこのサブドメインにリンクされます。 パブリック ALB の IP アドレスを見つけるには、 ibmcloud ks ingress alb ls を実行し、出力の ALB IP フィールドを確認します。
クラシック・クラスターのプライベート ALB は、 IBM提供の Ingress サブドメインを使用せず、自動的に有効になることもありません。 最初に CLI でプライベート ALB を有効にしてから、Ingress リソースで private-iks-k8s-nginx クラスを指定する必要があります。 プライベート ALB を有効にした後、 ibmcloud ks ingress alb ls を実行し、出力の ALB IP フィールドを確認することで、プライベート IP アドレスを見つけることができます。
パブリック ALB ポッドまたはプライベート ALB ポッドのスケジュールが変更された場合、同じ IP アドレスが保持されます。 ただし、ALB を使用してゾーンを削除したり、そのゾーン内の VLAN 上のすべてのワーカーを削除したりすると、その ALB の IP アドレスが削除されます。
VPC 内の ALB
VPC クラスターを作成すると、各ゾーンに 1 つのパブリック ALB と 1 つのプライベート ALB が自動的に作成されます。 さらに、VPC 内のクラスターの外部に 1 つのパブリック VPC ロード・バランサーが自動的に作成されます。 VPC クラスターでプライベート ALB を有効にすると、プライベート VPC ロード・バランサーも作成されます。
VPC クラスター内の ALB の IP アドレスは静的ではなく、時間の経過とともに変化する可能性があるため、VPC ロード・バランサーは、ALB のパブリック IP アドレスまたはプライベート IP アドレスを静的ホスト名の背後に配置します。 パブリック ALB またはプライベート ALB には別個のホスト名が適用されます。 ALB ホスト名は、クラスターの Ingress サブドメインとは別のものであることに注意してください。
VPC クラスター内の ALB のホスト名を見つけるには、 ibmcloud ks ingress alb ls を実行します。 プライベート・ホスト名は、プライベート ALB が有効になっている場合にのみリストされます。
ALB のワーカー・ノード要件
ALB が高可用性で機能し、定期的な更新を受け取るためには、クラスター内のゾーンごとに少なくとも 2 つのワーカー・ノードが必要です。 ALB ポッドのアンチアフィニティー・ルールにより、各ワーカー・ノードに 1 つのポッドのみがスケジュールされます。 ALB ポッドに自動更新が適用されると、ポッドが再ロードされます。 ワーカー・ノードが 1 つしかないために 1 つの ALB ポッドがある場合、トラフィックの中断を回避するためにポッドが自動的に更新されることはなく、ポッドを手動で削除して新しいポッドをスケジュール変更した場合にのみ更新が適用されます。 ゾーンごとに少なくとも 2 つのワーカー・ノードがあると、このシナリオは回避されます。
ゾーンで障害が発生した場合、そのゾーンの Ingress ALB に対する要求で断続的に障害が発生する可能性があることに注意してください。
デフォルトの TLS 証明書
クラスターを作成すると、 IBM提供の Ingress サブドメインで使用できるデフォルトの TLS 証明書が作成されます。 Ingress リソースで、デフォルトの TLS 証明書、または提供するカスタム証明書を指定できます。
Secrets Manager を使用して、Ingress サブドメイン証明書とその他のシークレットを一元的に管理し、自動的に更新することを検討してください。
TLS 証明書を使用して Ingress をセットアップするには、シークレットを作成またはインポートする必要があります。 IBM Cloud Ingress API を使用してこれらのステップを実行する場合は、デフォルトの Secrets Manager インスタンスが必要です。 それ以外の場合は、 kubectl コマンドを使用して証明書をコピーできます。
Ingress の概要
クラスターで Ingress を使用する準備ができたら、 Ingress リソースを作成 して、Ingress コンポーネントを構成し、要求をルーティングするためのルールを定義し、アプリ・サービスへのパスを指定します。 公開するアプリまたはサービスが含まれている名前空間ごとに、別個の Ingress リソースが必要です。