アプリの公開サービスの選択
IBM Cloud® Kubernetes Service では、アプリをパブリックまたはプライベートに公開して、クラスターの内部ネットワークと外部ネットワークを管理できます。
アプリ・ネットワークを素早く開始するには、以下のデシジョン・ツリーに従ってオプションをクリックし、そのセットアップ資料を参照します。
Kubernetes サービス・ディスカバリーによるアプリのロード・バランシングについて
Kubernetes サービス・ディスカバリーでは、ネットワーク・サービスおよびローカル Kubernetes プロキシーを使用して、アプリにネットワーク接続を提供します。
ワーカー・ノードにデプロイされるすべてのポッドには、172.30.0.0/16 の範囲でプライベート IP アドレスが割り当てられ、ワーカー・ノード間でのみ転送されます。 競合を避けるために、ご使用のワーカー・ノードと通信するノードにはこの IP 範囲を使用しないでください。 ワーカー・ノードとポッドは、プライベート IP アドレスを使用してプライベート・ネットワーク上で安全に通信できます。 しかし、ポッドが異常終了した場合やワーカー・ノードを再作成する必要がある場合は、新しいプライベート IP アドレスが割り当てられます。
高可用性が必要とされるアプリの、変化するプライベート IP アドレスの追跡を試みる代わりに、組み込みの Kubernetes サービス・ディスカバリー機能を使用して、アプリをサービスとして公開できます。 Kubernetes サービスは、一連のポッドをグループ化し、これらのポッドへのネットワーク接続を提供します。 このサービスでは、ラベルを介してトラフィックをルーティングするターゲット・ポッドを選択します。
サービスは、各ポッドの実際のプライベート IP アドレスを公開することなく、アプリ・ポッドとクラスター内の他のサービスの間の接続を提供します。 サービスには、クラスター内部でのみアクセス可能なクラスター内 IP アドレス clusterIP
が割り当てられます。 この IP アドレスは、その存続期間中はサービスに関連付けられ、そのサービスが存在する間は変化しません。 サービスには、 172.21.0.0/16 の範囲の 65,000 個の IP の 1
つから IP が割り当てられます。
競合を避けるために、ご使用のワーカー・ノードと通信するノードにはこの IP 範囲を使用しないでください。 サービスのために DNS 参照エントリーも作成され、クラスターの kube-dns
コンポーネントに保管されます。 DNS エントリーには、サービスの名前、サービスが作成された名前空間、割り当てられたクラスター内 IP アドレスへのリンクが含まれています。
IBM Cloud または VPN サービスを介してクラスターをオンプレミスのネットワークに接続する場合は、ポッドのデフォルトの範囲 172.30.0.0/ 16 およびサービスのデフォルトの範囲 172.21.0.0/ 16 とサブネットが競合する可能性があります。 --pod-subnet
でポッド用のカスタム・サブネットCIDRを指定し、--service-subnet
オプションでサービス用のカスタム・サブネットCIDRを指定することで、
クラスタを作成する ときにサブネットの競合を回避できます。
サービスに対するすべての TCP および UDP ネットワーク・トラフィックの基本ロード・バランシングを提供するために、ローカル Kubernetes ネットワーク・プロキシー kube-proxy
は、kube-system
名前空間のワーカー・ノードごとにデーモンとして動作します。kube-proxy
は、lptables ルール (Linux カーネル機能) を使用して、ポッドのクラスター内 IP
アドレスおよびデプロイ先のワーカー・ノードに関係なく、要求をポッドに、サービスの背後で均等に送信します。
例えば、クラスター内部のアプリは、サービスのクラスター内 IP アドレスを使用するか、サービスの名前を使用して要求を送信して、クラスター・サービスのポッドにアクセスできます。 サービスの名前を使用した場合は、kube-proxy
がクラスター DNS プロバイダー内で名前を検索し、要求をサービスのクラスター内 IP アドレスにルーティングします。
内部クラスター IP アドレスおよび外部 IP アドレスの両方を提供するサービスを使用している場合は、クラスター外部のクライアントは、サービスの外部パブリック IP アドレスまたは外部プライベート IP アドレスに要求を送信できます。kube-proxy
は、サービスのクラスター内 IP アドレスに要求を転送し、サービスの背後でアプリ・ポッド間のロード・バランシングを行います。
Kubernetes サービス・タイプについて
Kubernetes は、4 つの基本タイプのネットワーク・サービス (ClusterIP
、NodePort
、LoadBalancer
、および Ingress
) をサポートします。ClusterIP
サービスは、アプリを内部的にアクセス可能にして、クラスター内のポッド間の通信のみ許可します。NodePort
サービス、LoadBalancer
サービス、および Ingress
サービスは、アプリをパブリック・インターネットまたはプライベート・ネットワークから外部的にアクセス可能にします。
以下の表は、各ネットワーク・サービス・タイプの機能を比較しています。
特性 | ClusterIP | NodePort | LoadBalancer (クラシック - NLB) | LoadBalancer (VPC ロード・バランサー) | Ingress |
---|---|---|---|---|---|
標準クラスター | ある | ある | ある | ある | ある |
外部アクセス可能 | ある | ある | ある | ある | |
外部ホスト名 | ある | ある | ある | ||
不変の外部 IP | ある | ある | |||
HTTP(S) ロード・バランシング | はい* | はい* | ある | ||
TLS 終端処理 | ある | ||||
カスタム・ルーティング・ルール | ある | ||||
1 つのサービスに対する複数のアプリ | ある |
*
HTTPS ロード・バランシング用の SSL 証明書は、ibmcloud ks nlb-dns
コマンドで提供します。 クラシック・クラスターでは、これらのコマンドはパブリック NLB でのみサポートされます。
ClusterIP
プライベート・ネットワークでは、アプリを ClusterIP
サービス としてのみ公開できます。 ClusterIP
サービスは、クラスター内部の他のポッドおよびサービスのみアクセス可能なクラスター内
IP アドレスを提供します。 アプリに外部 IP アドレスは作成されません。 クラスター・サービスのポッドにアクセスする場合、クラスター内の他のアプリは、サービスのクラスター内 IP アドレスを使用するか、サービスの名前を使用して要求を送信できます。 要求がサービスに到達すると、ポッドのクラスター内 IP アドレスやデプロイ先のワーカー・ノードに関係なく、要求がサービスによってポッドに均等に転送されます。 サービスのYAMLコンフィギュレーションファイルで type
を指定しない場合、ClusterIP
型はデフォルトで作成されることに注意してください。
NodePort
NodePort
でアプリを公開すると、30000~32767の範囲のNodePortと内部クラスタIPアドレスがサービスに割り当てられます。 クラスタ外からサービスにアクセスするには、任意のワーカーノードのパブリックまたはプライベートIPアドレスと、<IP_address>:<nodeport>
の形式でNodePortを使用します。 ただし、ワーカー・ノードのパブリックおよびプライベートの IP アドレスは不変ではありません。 ワーカー・ノードが削除されたり再作成されたりすると、新しいパブリック IP アドレスと新しいプライベート IP アドレスがワーカー・ノードに割り当てられます。
NodePort は、パブリックまたはプライベートのアクセスをテストしたり、短時間だけアクセスできるようにしたりする場合に適しています。 注: VPC クラスター内のワーカー・ノードはパブリック IP アドレスを持たないため、NodePort を介してアプリにアクセスできるのは、VPN 接続などを介してプライベート VPC ネットワークに接続している場合のみです。
LoadBalancer
LoadBalancer サービス・タイプの実装は、クラスターのインフラストラクチャー・プロバイダーによって異なります。
クラシック・クラスターの LoadBalancer
サービス
クラシック・インフラストラクチャー
ネットワーク・ロード・バランサー(NLB)。 どの標準クラスターにも 4 つのポータブル・パブリック IP アドレスと 4 つのポータブル・プライベート IP アドレスがプロビジョンされます。そのアドレスを使用して、アプリ用のレイヤー 4 の TCP/UDP ネットワーク・ロード・バランサー (NLB) を作成できます。 アプリで必要なすべてのポートを公開することによって NLB をカスタマイズすることも可能です。 NLB に割り当てられたポータブル・パブリック IP アドレスとポータブル・プライベート IP アドレスは永続的なアドレスであり、クラスター内でワーカー・ノードが再作成されても変更されません。 アプリにサブドメインを作成し、そのサブドメインで DNS エントリーにパブリック NLB の IP アドレスを登録できます。 また、各サブドメインの NLB IP に対するヘルス・チェック・モニターも有効にできます。
VPC クラスターの LoadBalancer
サービス
Virtual Private Cloud
Load Balancer for VPC。 クラスターでアプリ用に Kubernetes LoadBalancer サービスを作成すると、レイヤー 7 の VPC ロード・バランサーが VPC のクラスター外部に自動的に作成されます。 この VPC ロード・バランサーはマルチゾーン対応であり、ワーカー・ノードで自動的に開かれるプライベート NodePort を介してアプリに対する要求を転送します。 デフォルトでは、このロード・バランサーの作成と一緒に、アプリへのアクセスに使用できるホスト名も作成されます。
Ingress
Ingress アプリケーションロードバランサー(ALB)でルーティングを設定することで、クラスタ内の複数のアプリを公開できます。 ALB は、保護された固有のパブリック・エントリー・ポイントまたはプライベート・エントリー・エンドポイント、Ingress サブドメインを使用して、着信要求をアプリにルーティングします。 1 つのサブドメインを使用してクラスター内の複数のアプリをサービスとして公開できます。 Ingress は、以下の 3 つのコンポーネントで構成されています。
- Ingress リソースでは、アプリに対する着信要求のルーティングとロード・バランシングの方法に関するルールを定義します。
- ALB は、着信 HTTP、HTTPS、または TCP サービス要求を listen します。 これは、Ingress リソースで定義したルールに基づいて、アプリのポッド間で要求を転送します。
- クラシック・クラスター用の複数ゾーン・ロード・バランサー (MZLB) または VPC クラスター用の VPC ロード・バランサーは、アプリに対するすべての着信要求を処理し、さまざまなゾーンに存在する ALB の間で要求のロード・バランシングを行います。 パブリック Ingress IP アドレスのヘルス・チェックも可能にします。
パブリック外部ロード・バランシングの計画
クラスター内のアプリをインターネットに公開します。
クラシック・クラスターでは、ワーカー・ノードをパブリック VLAN に接続できます。 パブリック VLAN により、各ワーカー・ノードに割り当てられるパブリック IP アドレスが決まり、ワーカー・ノードにパブリック・ネットワーク・インターフェースが提供されます。 パブリック IP アドレスおよびオプションでパブリック URL を使用してアプリを提供すると、パブリック・ネットワーク・サービスがそのパブリック・ネットワーク・インターフェースに接続します。
VPC クラスターでは、ワーカー・ノードはプライベート VPC サブネットにのみ接続されます。 ただし、パブリック・ネットワーク・サービスを作成すると、VPC ロード・バランサーが自動的に作成されます。 VPC ロード・バランサーは、アプリにパブリック URL を与えて、パブリック要求をアプリに転送できるようにします。 公開したアプリのパブリック URL を知っていれば、だれでもアプリに要求を送信できます。
アプリをパブリックに公開すると、アプリにセットアップされたパブリック・サービス IP アドレスまたは URL を知っているだれもがアプリに要求を送信できるようになります。 このため、公開するアプリの数は、できるだけ少なくしてください。 外部の Web クライアントまたはユーザーからのトラフィックを受け入れる準備ができたアプリだけをパブリックに公開してください。
ワーカー・ノードのパブリック・ネットワーク・インターフェースは、クラスターの作成時にすべてのワーカー・ノードに構成される事前定義済み Calico ネットワーク・ポリシー設定によって保護されます。 デフォルトでは、すべてのワーカー・ノードに対して、すべてのアウトバウンド・ネットワーク・トラフィックが許可されます。 数個のポートを除いて、インバウンド・ネットワーク・トラフィックがブロックされます。 開かれているポートは、IBM がネットワーク・トラフィックをモニターし、Kubernetes マスターのセキュリティー更新を自動的にインストールするためのもの、および、NodePort、LoadBalancer、Ingress サービスへの接続を確立できるようにするためのものです。 ポリシーの変更方法を含め、これらのポリシーの詳細については、ネットワーク・ポリシーを参照してください。
クラシック・クラスターのデプロイメント・パターンの選択
クラシック・クラスター内のアプリをインターネットに公開するには、パブリック NodePort、LoadBalancer、または Ingress サービスを使用するロード・バランシング・デプロイメント・パターンを選択します。 以下の表で、使用できる各デプロイメント・パターン、使用する理由、セットアップ方法を説明します。 デプロイメント・パターンで使用されるネットワーク・サービスの基本情報は、Kubernetes サービス・タイプについてを参照してください。
NLB v1.0
- ロード・バランシング方式: IP アドレスまたはサブドメインを使用してアプリを公開する基本ロード・バランシング。
- ユース・ケース: IP アドレス、または SSL 終端をサポートするサブドメインを使用して、1 つのアプリを素早くパブリックに公開します。
- 実装:
- パブリックネットワークロードバランサー(NLB)1.0を シングル または マルチゾーンクラスター で作成します。
- オプションでサブドメインおよびヘルス・チェックを登録します。
NLB v2.0
Istio + NLB サブドメイン
- ロード・バランシング方式: サブドメインを使用してアプリを公開し、Istio ルーティング・ルールを使用する基本ロード・バランシング。
- ユース・ケース: Istio のルーティング後ルール (1 つのアプリ・マイクロサービスの異なるバージョンのルールなど) を実装し、パブリック・サブドメインを使用して Istio 管理アプリを公開します。
- 実装:
- マネージド Istio アドオンをインストールします。
- Istio サービス・メッシュにアプリを含めます。
- デフォルトの Istio ロード・バランサーをサブドメインに登録します。
Ingress ALB
- ロード・バランシング方式: サブドメインを使用してアプリを公開し、カスタム・ルーティング・ルールを使用する HTTPS ロード・バランシング。
- ユース・ケース: カスタム・ルーティング・ルールと SSL 終端を複数のアプリに対して実装します。
- 実装:
- パブリック ALB の Ingress サービスを作成します。
- アノテーションを使用して、ALB ルーティング・ルールをカスタマイズします。
VPC クラスターのデプロイメント・パターンの選択
VPC クラスター内のアプリをインターネットに公開するには、パブリック LoadBalancer
または Ingress
サービスを使用するロード・バランシング・デプロイメント・パターンを選択します。 以下の表で、使用できる各デプロイメント・パターン、使用する理由、セットアップ方法を説明します。 デプロイメント・パターンで使用されるネットワーク・サービスの基本情報は、Kubernetes サービス・タイプについてを参照してください。
VPC ロード・バランサー
- ロード・バランシング方式: ホスト名を使用してアプリを公開する基本ロード・バランシング
- ユース・ケース: VPC ロード・バランサー割り当てホスト名を使用して、1 つのアプリを素早くパブリックに公開します。
- 実装: クラスターにパブリック
LoadBalancer
サービスを作成します。 アプリのLoadBalancer
サービスにホスト名を割り当てる VPC ロード・バランサーが VPC に自動的に作成されます。
Istio
- ロード・バランシング方式: ホスト名を使用してアプリを公開し、Istio ルーティング・ルールを使用する基本ロード・バランシング
- ユース・ケース: Istio のルーティング後ルール (1 つのアプリ・マイクロサービスの異なるバージョンのルールなど) を実装し、パブリック・ホスト名を使用して Istio 管理アプリを公開します。
- 実装:
- マネージド Istio アドオンをインストールします。
- Istio サービス・メッシュにアプリを含めます。
- デフォルトの Istio ロード・バランサーをホスト名に登録します。
Ingress ALB
- ロード・バランシング方式: サブドメインを使用してアプリを公開し、カスタム・ルーティング・ルールを使用する HTTPS ロード・バランシング。
- ユース・ケース: カスタム・ルーティング・ルールと SSL 終端を複数のアプリに対して実装します。
- 実装:
- パブリック ALB の Ingress サービスを作成します。
- アノテーションを使用して、ALB ルーティング・ルールをカスタマイズします。
プライベート外部ロード・バランシングの計画
クラスター内のアプリをプライベート・ネットワークにのみ公開します。
IBM Cloud Kubernetes Service で Kubernetes クラスターにアプリをデプロイする場合は、そのクラスターと同じプライベート・ネットワーク上のユーザーとサービスのみがアプリを利用できるようにすることができます。 プライベート・ロード・バランシングは、アプリを一般的に公開することなく、クラスター外からの要求で使用できるようにする場合に理想的です。 プライベート・ロード・バランシングを使用して、アプリのアクセス、要求ルーティング、およびその他の構成をテストしてから、後でパブリック・ネットワーク・サービスを使用してアプリをパブリックに公開することもできます。
例えば、アプリ用にプライベート・ロード・バランサーを作成したとします。 このプライベート・ロード・バランサーには、以下がアクセスできます。
- 同じクラスター内のすべてのポッド。
- 同じ IBM Cloud アカウント内のクラスター内のポッド。
- IBM Cloud アカウントに含まれていないが、会社のファイアウォールの背後にある場合は、ロード・バランサー IP があるサブネットへの VPN 接続を介するすべてのシステム。
- 異なる IBM Cloud アカウントに含まれている場合は、ロード・バランサー IP があるサブネットへの VPN 接続を介するすべてのシステム。
- クラシック・クラスターの場合、VRF または VLAN スパンニングを有効にしていれば、同じ IBM Cloud アカウント内のプライベート VLAN に接続されているすべてのシステム。
- VPC クラスターの場合:
- VPC サブネット間のトラフィックを許可する場合は、同じ VPC に含まれる任意のシステム。
- VPC 間のトラフィックを許可する場合は、クラスターが属する VPC にアクセスできる任意のシステム。
クラシック・クラスターのデプロイメント・パターンの選択
クラシック・クラスター内のアプリをプライベート・ネットワークにのみ公開するには、クラスターの VLAN セットアップに基づいてロード・バランシングのデプロイメント・パターンを選択します。
パブリックおよびプライベートの VLAN セットアップでのプライベート・ロード・バランシングのセットアップ
ワーカー・ノードがパブリック VLAN とプライベート VLAN の両方に接続されている場合は、プライベートの NodePort、LoadBalancer、または Ingress サービスを作成して、プライベート・ネットワークからのみ、アプリにアクセスできるようにできます。 次に、サービスへのパブリック・トラフィックをブロックする Calico ポリシーを作成できます。
事前定義 Calico ネットワーク・ポリシー設定は、ワーカー・ノードのパブリック・ネットワーク・インターフェースを保護し、クラスター作成時に各ワーカー・ノード上で構成されます。 デフォルトでは、すべてのワーカー・ノードに対して、すべてのアウトバウンド・ネットワーク・トラフィックが許可されます。 数個のポートを除いて、インバウンド・ネットワーク・トラフィックがブロックされます。 IBM は当該ポートを使用して、ネットワーク・トラフィックをモニターし、Kubernetes マスターのセキュリティー更新を自動的にインストールできます。これにより、NodePort サービス、LoadBalancer サービス、および Ingress サービスへの接続を確立できます。
デフォルトの Calico ネットワーク・ポリシーでは、これらのサービスへのインバウンドのパブリック・トラフィックが許可されるので、これらのサービスへのすべてのパブリック・トラフィックをブロックするには、ユーザーが Calico ポリシーを作成する必要があります。 例えば、NodePort サービスは、ワーカー・ノードのプライベート IP アドレスとパブリック IP アドレスの両方に対して、ワーカー・ノード上のポートを開きます。 ポータブル・プライベート IP アドレスを持つ NLB サービスでは、すべてのワーカー・ノードでパブリック NodePort を開きます。 Calico preDNAT ネットワーク・ポリシーを作成してパブリック NodePort をブロックする必要があります。
プライベート・ネットワーキングのロード・バランシング・デプロイメント・パターンを確認してください。
- NodePort
- ロード・バランシング方式: ワーカーのプライベート IP アドレスでアプリを公開するワーカー・ノード上のポート
- ユース・ケース: 1 つのアプリへのプライベート・アクセスをテストするか、または短い時間だけアクセスを提供します。
- 実装: NodePort サービスを作成します。 NodePort サービスは、ワーカー・ノードのプライベート IP アドレスとパブリック IP アドレスの両方に対して、ワーカー・ノード上のポートを開きます。 Calico preDNAT ネットワーク・ポリシーを使用して、パブリック NodePort へのトラフィックをブロックする必要があります。
- NLB v1.0
- ロード・バランシング方式: プライベート IP アドレスを使用してアプリを公開する基本ロード・バランシング。
- ユース・ケース: プライベート IP アドレスを使用して 1 つのアプリをプライベート・ネットワークに素早く公開します。
- 実装:
- プライベート NLB サービスを作成します。 ポータブル・プライベート IP アドレスを使用する NLB は、すべてのワーカー・ノードでパブリック・ノード・ポートも開きます。
- パブリック NodePort へのトラフィックをブロックする Calico preDNAT ネットワーク・ポリシーを作成します。
- NLB v2.0
- ロード・バランシング方式: プライベート IP アドレスを使用してアプリを公開する DSR ロード・バランシング。
- ユース・ケース: IP アドレスを使用してプライベート・ネットワークへの高レベルのトラフィックを受信できるアプリを公開します。
- 実装:
- すべての前提条件を満たします。
- プライベート NLB 2.0 を単一ゾーンまたはマルチゾーンのクラスターに作成します。
- ポータブル・プライベート IP アドレスを使用する NLB は、すべてのワーカー・ノードでパブリック・ノード・ポートも開きます。 パブリック NodePort へのトラフィックをブロックする Calico preDNAT ネットワーク・ポリシーを作成します。
- Ingress ALB
- ロード・バランシング方式: サブドメインを使用してアプリを公開し、カスタム・ルーティング・ルールを使用する HTTPS ロード・バランシング。
- ユース・ケース: カスタム・ルーティング・ルールと SSL 終端を複数のアプリに対して実装します。
- 実装:
- パブリック ALB を無効にします。
- プライベート ALB を有効にし、Ingress リソースを作成します。
- アノテーションを使用して、ALB ルーティング・ルールをカスタマイズします。 4 ポータブル・プライベート IP アドレスを使用する NLB は、すべてのワーカー・ノードでパブリック・ノード・ポートも開きます。 パブリック NodePort へのトラフィックをブロックする Calico preDNAT ネットワーク・ポリシーを作成します。
プライベート VLAN のみを使用するセットアップのためのプライベート・ロード・バランシングのセットアップ
ワーカー・ノードがプライベート VLAN のみに接続されている場合は、プライベートの NodePort、LoadBalancer、または Ingress サービスを作成して、プライベート・ネットワークからのみ、アプリに外部からアクセスできるようにできます。
クラスターがプライベート VLAN にのみ接続されているときに、マスター・ノードとワーカー・ノードがプライベート専用サービス・エンドポイントを使用して通信できるようにする場合は、アプリをプライベート・ネットワークに自動的に公開することはできません。 VRA(Vyatta)などのゲートウェイアプライアンスをセットアップし、ファイアウォールとして機能させ、トラフィックをブロックまたは許可する必要があります。 ワーカー・ノードはパブリック VLAN に接続されていないため、パブリック・トラフィックは NodePort、LoadBalancer、または Ingress サービスにルーティングされません。 ただし、これらのサービスへのインバウンド・トラフィックを許可するために、ゲートウェイ・アプライアンス・ファイアウォールで必要なポートおよび IP アドレスを開く必要があります。
以下のプライベート・ネットワーキングのロード・バランシングのデプロイメント・パターンを確認してください。
- NodePort
- ロード・バランシング方式: ワーカーのプライベート IP アドレスでアプリを公開するワーカー・ノード上のポート
- ユース・ケース: 1 つのアプリへのプライベート・アクセスをテストするか、または短い時間だけアクセスを提供します。
- 実装:
- NodePort サービスを作成します。
- プライベート・ファイアウォールにおいて、すべてのワーカー・ノードでトラフィックの宛先として許可されるプライベート IP アドレスにサービスをデプロイしたときに構成したポートを開きます。 ポートを見つけるには、
kubectl get svc
を実行します。 このポートは30000-32767
範囲にあります。
- NLB v1.0
- ロード・バランシング方式: プライベート IP アドレスを使用してアプリを公開する基本ロード・バランシング。
- ユース・ケース: プライベート IP アドレスを使用して 1 つのアプリをプライベート・ネットワークに素早く公開します。
- 実装:
- プライベート NLB サービスを作成します。
- プライベート・ファイアウォールで、NLB のプライベート IP アドレスにサービスをデプロイしたときに構成したポートを開きます。
- NLB v2.0
- ロード・バランシング方式: プライベート IP アドレスを使用してアプリを公開する DSR ロード・バランシング。
- ユース・ケース: IP アドレスを使用してプライベート・ネットワークへの高レベルのトラフィックを受信できるアプリを公開します。
- 実装:
- プライベート NLB サービスを作成します。
- プライベート・ファイアウォールで、NLB のプライベート IP アドレスにサービスをデプロイしたときに構成したポートを開きます。
- Ingress ALB
- ロード・バランシング方式: サブドメインを使用してアプリを公開し、カスタム・ルーティング・ルールを使用する HTTPS ロード・バランシング。
- ユース・ケース: カスタム・ルーティング・ルールと SSL 終端を複数のアプリに対して実装します。
- 実装:
- プライベートネットワークで利用可能なDNSサービスを設定する。
- プライベート ALB を有効にし、Ingress リソースを作成します。
- プライベート・ファイアウォールで、HTTP 用のポート 80 または HTTPS 用のポート 443 を、プライベート ALB の IP アドレスに対して開きます。 4 アノテーションを使用して、ALB ルーティング・ルールをカスタマイズします。
VPC クラスターのデプロイメント・パターンの選択
プライベート NodePort、LoadBalancer、または Ingress サービスを作成して、プライベート・ネットワークからのみアプリにアクセスできるようにします。
VPC クラスター内のプライベート・アプリ・ネットワークについては、以下のロード・バランシング・デプロイメント・パターンを確認してください。
- NodePort
- ロード・バランシング方式: ワーカーのプライベート IP アドレスでアプリを公開するワーカー・ノード上のポート。
- ユース・ケース: 1 つのアプリへのプライベート・アクセスをテストするか、または短い時間だけアクセスを提供します。 注: NodePort を使用してアプリにアクセスできるのは、VPN 接続などを使用してプライベート VPC ネットワークに接続している場合だけです。
- 実装: プライベート NodePort サービスを作成します。
- VPC アプリケーション・ロード・バランサー
- ロード・バランシング方式: プライベート・ホスト名を使用してアプリを公開する基本ロード・バランシング。
- ユース・ケース: VPC アプリケーション・ロード・バランサーによって割り当てられたプライベート・ホスト名を使用して 1 つのアプリをプライベート・ネットワークに素早く公開します。
- 実装: クラスターにプライベート
LoadBalancer
サービスを作成します。 アプリのLoadBalancer
サービスにホスト名を割り当てる複数ゾーン VPC アプリケーション・ロード・バランサーが VPC に自動的に作成されます。 - Ingress ALB
- ロード・バランシング方式: ホスト名を使用してアプリを公開し、カスタム・ルーティング・ルールを使用する HTTPS ロード・バランシング。
- ユース・ケース: カスタム・ルーティング・ルールと SSL 終端を複数のアプリに対して実装します。
- 実装:
- プライベート ALB を有効にし、サブドメインを作成して ALB を DNS エントリーに登録して、Ingress リソースを作成します。
- アノテーションを使用して、ALB ルーティング・ルールをカスタマイズします。