サービス・エンドポイントまたは VLAN 接続の変更

クラスターの作成時に、最初にネットワークをセットアップした後、クラスター・マスターがアクセス可能なサービス・エンドポイントを変更したり、ワーカー・ノード用の VLAN 接続を変更したりできます。

このページの内容は、クラシック・クラスター専用です。 VPC クラスターについて詳しくは、 VPC クラスターのネットワーキングを参照してください。

プライベート・クラウド・サービス・エンドポイントのセットアップ

クラスターのプライベート・クラウド・サービス・エンドポイントを有効にします。

プライベート・クラウド・サービス・エンドポイントがあれば、Kubernetes マスターにプライベートからアクセスできます。ワーカー・ノードと許可されたクラスター・ユーザーは、プライベート・ネットワーク経由で Kubernetes マスターと通信できます。プライベート・クラウド・サービス・エンドポイントを有効にできるかどうかを判別するには、ワーカーとマスターおよびユーザーとマスターの間の通信を参照してください。プライベート・クラウド・サービス・エンドポイントは、有効にした後は無効にできないことに注意してください。

VRF およびサービス・エンドポイントのアカウントを有効にする前に、プライベート・クラウド・サービス・エンドポイントのみを含むクラスターを作成しましたか? パブリック・クラウド・サービス・エンドポイントのセットアップを試行して、サポート Case が処理されてアカウントが更新されるまで、クラスターを使用できるようにします。

ご使用の IBM Cloud インフラストラクチャー・アカウントで VRF を有効にします。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。
IBM Cloud アカウントでサービス・エンドポイントを使用できるようにします。
プライベート・クラウド・サービス・エンドポイントを有効にします。
```
ibmcloud ks cluster master private-service-endpoint enable --cluster <cluster_name_or_ID>
```
プライベート・クラウド・サービス・エンドポイントを使用するには、Kubernetes マスター API サーバーをリフレッシュします。 CLI のプロンプトに従うか、または以下のコマンドを手動で実行します。マスターがリフレッシュされるまで数分かかることがあります。
```
ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
```
一度に使用不可にできるクラスター内のワーカー・ノードの最大数を制御する構成マップを作成します。この構成マップによって、ワーカー・ノードを更新するときに、使用可能なワーカー・ノードに順番にアプリが再スケジュールされるので、アプリのダウン時間の発生を回避できます。
クラスター内のすべてのワーカー・ノードを更新して、プライベート・クラウド・サービス・エンドポイント構成を反映させます。

update コマンドを発行することで、ワーカー・ノードが再ロードされてサービス・エンドポイント構成が反映されます。ワーカーを更新できない場合は、手動でワーカー・ノードを再ロードする必要があります。再ロードする場合は、一度に使用不可にできるワーカー・ノードの最大数を制御するために、ワーカー・ノードの閉鎖、排出、順番の管理を確実に行ってください。
```
ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker1,worker2>
```
クラスターがファイアウォールの内側の環境にある場合:
- 許可されたクラスター・ユーザーに対して、kubectl コマンドの実行を許可し、プライベート・クラウド・サービス・エンドポイントを介してマスターにアクセスできるようにします。
- 使用する予定のインフラストラクチャー・リソースや IBM Cloud サービスのプライベート IP へのアウトバウンド・ネットワーク・トラフィックを許可します。
オプション: プライベート・クラウド・サービス・エンドポイントのみを使用するには、次のようにします。
1. パブリック・クラウド・サービス・エンドポイントを無効にします。
2. プライベート・クラウド・サービス・エンドポイント上のマスターへのアクセスをセットアップします。

パブリック・クラウド・サービス・エンドポイントのセットアップ

クラスターのパブリック・クラウド・サービス・エンドポイントを有効または無効にします。

パブリック・クラウド・サービス・エンドポイントがあれば、Kubernetes マスターにパブリックからアクセスできます。ワーカー・ノードと許可されたクラスター・ユーザーは、パブリック・ネットワークを介して Kubernetes マスターと安全に通信できます。詳しくは、ワーカーとマスターおよびユーザーとマスターの間の通信を参照してください。

パブリック・クラウド・サービス・エンドポイントを有効にする手順

パブリック・エンドポイントを無効にした場合は、後で再び有効にすることができます。

パブリック・クラウド・サービス・エンドポイントを有効にします。
```
ibmcloud ks cluster master public-service-endpoint enable --cluster <cluster_name_or_ID>
```
パブリック・クラウド・サービス・エンドポイントを使用するには、Kubernetes マスター API サーバーをリフレッシュします。 CLI のプロンプトに従うか、または以下のコマンドを手動で実行します。マスターがリフレッシュされるまで数分かかることがあります。
```
ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
```
一度に使用不可にできるクラスター内のワーカー・ノードの最大数を制御する構成マップを作成します。この構成マップによって、ワーカー・ノードを更新するときに、使用可能なワーカー・ノードに順番にアプリが再スケジュールされるので、アプリのダウン時間の発生を回避できます。
クラスター内のすべてのワーカー・ノードを更新して、パブリック・クラウド・サービス・エンドポイント構成を削除します。
```
ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker1,worker2>
```
update コマンドを発行することで、ワーカー・ノードが再ロードされてサービス・エンドポイント構成が反映されます。ワーカーを更新できない場合は、ibmcloud ks worker reload コマンドを使用してワーカー・ノードを手動で再ロードする必要があります。再ロードする場合は、一度に使用不可にできるワーカー・ノードの最大数を制御するために、ワーカー・ノードの閉鎖、排出、順番の管理を確実に行ってください。

パブリック・クラウド・サービス・エンドポイントを無効にする手順

パブリック・クラウド・サービス・エンドポイントを無効にするには、まず、ワーカー・ノードが Kubernetes マスターと通信できるように、プライベート・クラウド・サービス・エンドポイントを有効にする必要があります。

プライベート・クラウド・サービス・エンドポイントを有効にします。

パブリック・クラウド・サービス・エンドポイントを無効にします。

ibmcloud ks cluster master public-service-endpoint disable --cluster <cluster_name_or_ID>

パブリック・クラウド・サービス・エンドポイントを削除するには、CLI プロンプトに従うか、または以下のコマンドを手動で実行して、Kubernetes マスター API サーバーをリフレッシュします。マスターがリフレッシュされるまで数分かかることがあります。
```
ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
```
一度に使用不可にできるクラスター内のワーカー・ノードの最大数を制御する構成マップを作成します。この構成マップによって、ワーカー・ノードを更新するときに、使用可能なワーカー・ノードに順番にアプリが再スケジュールされるので、アプリのダウン時間の発生を回避できます。
クラスター内のすべてのワーカー・ノードを更新して、パブリック・クラウド・サービス・エンドポイント構成を削除します。 update コマンドを発行することで、ワーカー・ノードが再ロードされてサービス・エンドポイント構成が反映されます。ワーカーを更新できない場合は、ibmcloud ks worker reload コマンドを使用してワーカー・ノードを手動で再ロードする必要があります。再ロードする場合は、一度に使用不可にできるワーカー・ノードの最大数を制御するために、ワーカー・ノードの閉鎖、排出、順番の管理を確実に行ってください。
```
ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker1,worker2>
```
update コマンドを発行することで、ワーカー・ノードが再ロードされてサービス・エンドポイント構成が反映されます。ワーカーを更新できない場合は、ibmcloud ks worker reload コマンドを使用してワーカー・ノードを手動で再ロードする必要があります。再ロードする場合は、一度に使用不可にできるワーカー・ノードの最大数を制御するために、ワーカー・ノードの閉鎖、排出、順番の管理を確実に行ってください。

パブリック・クラウド・サービス・エンドポイントからプライベート・クラウド・サービス・エンドポイントへの切り替え

プライベート・クラウド・サービス・エンドポイントを有効化することによって、ワーカー・ノードがパブリック・ネットワークではなくプライベート・ネットワーク経由でマスターと通信できるようにします。

パブリック VLAN およびプライベート VLAN に接続しているすべてのクラスターは、デフォルトでは、パブリック・クラウド・サービス・エンドポイントを使用します。ワーカー・ノードと許可されたクラスター・ユーザーは、パブリック・ネットワークを介して Kubernetes マスターと安全に通信できます。ワーカー・ノードにパブリック・ネットワークではなくプライベート・ネットワーク経由で Kubernetes マスターと通信させるには、プライベート・クラウド・サービス・エンドポイントを有効にします。その後に、任意でパブリック・クラウド・サービス・エンドポイントを無効にできます。

プライベート・クラウド・サービス・エンドポイントを有効にし、パブリック・クラウド・サービス・エンドポイントも有効にしたままの場合、ワーカーは常にプライベート・ネットワーク経由でマスターと通信します。一方、ユーザーはパブリックとプライベートのどちらのネットワーク経由でもマスターと通信できます。
プライベート・クラウド・サービス・エンドポイントを有効にし、パブリック・クラウド・サービス・エンドポイントを無効にした場合、ワーカーとユーザーはプライベート・ネットワーク経由でマスターと通信しなければなりません。

プライベート・クラウド・サービス・エンドポイントは、有効にした後は無効にできないことに注意してください。

ご使用の IBM Cloud インフラストラクチャー・アカウントで VRF を有効にします。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。
IBM Cloud アカウントでサービス・エンドポイントを使用できるようにします。
プライベート・クラウド・サービス・エンドポイントを有効にします。
```
ibmcloud ks cluster master private-service-endpoint enable --cluster <cluster_name_or_ID>
```
プライベート・クラウド・サービス・エンドポイントを使用するには、CLI プロンプトに従うか、または以下のコマンドを手動で実行して、Kubernetes マスター API サーバーをリフレッシュします。マスターがリフレッシュされるまで数分かかることがあります。
```
ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
```
一度に使用不可にできるクラスター内のワーカー・ノードの最大数を制御する構成マップを作成します。この構成マップによって、ワーカー・ノードを更新するときに、使用可能なワーカー・ノードに順番にアプリが再スケジュールされるので、アプリのダウン時間の発生を回避できます。
クラスター内のすべてのワーカー・ノードを更新して、プライベート・クラウド・サービス・エンドポイント構成を反映させます。

update コマンドを発行することで、ワーカー・ノードが再ロードされてサービス・エンドポイント構成が反映されます。ワーカーを更新できない場合は、手動でワーカー・ノードを再ロードする必要があります。再ロードする場合は、一度に使用不可にできるワーカー・ノードの最大数を制御するために、ワーカー・ノードの閉鎖、排出、順番の管理を確実に行ってください。
```
ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker1,worker2>
```
オプション: プライベート・クラウド・サービス・エンドポイントのみを使用するには、次のようにします。
1. パブリック・クラウド・サービス・エンドポイントを無効にします。
```
ibmcloud ks cluster master public-service-endpoint disable --cluster <cluster_name_or_ID>
```
2. プライベート・クラウド・サービス・エンドポイント上のマスターへのアクセスをセットアップします。

ワーカー・ノードの VLAN 接続を変更する

クラスター作成時に、ワーカー・ノードをプライベート VLAN とパブリック VLAN に接続するか、それともプライベート VLAN にのみ接続するかを選択します。ワーカー・ノードはワーカー・プールの一部であり、ワーカー・プールには、そのプールで将来のワーカー・ノードをプロビジョンするときに使用する VLAN などのネットワーク・メタデータが保管されます。以下のようなケースでは、クラスターの VLAN 接続セットアップを後から変更しなければなりません。

ゾーンのワーカー・プールの VLAN が不足してきたので、クラスター・ワーカー・ノード用に新しい VLAN をプロビジョンする必要がある。
クラスターのワーカー・ノードがパブリック VLAN とプライベート VLAN の両方に接続しているが、プライベート専用クラスターに変更したい。
プライベート専用クラスターであるが、パブリック VLAN に接続したエッジ・ノードのワーカー・プールなど、一部のワーカー・ノードでアプリをインターネットに公開したい。

代わりに、マスター対ワーカーの通信用のサービス・エンドポイントを変更できませんか? パブリック・サービス・エンドポイントとプライベート・サービス・エンドポイントをセットアップするトピックを確認してください。

VLAN からすべてのワーカーを削除すると、VLAN のゾーン内の Ingress ALB の IP アドレスが削除されます。

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。

ワーカー・ノードをプロビジョンするときにワーカー・プールが使用する VLAN を変更するには、以下の手順を実行します。

クラスター内のワーカー・プールの名前をリストします。
```
ibmcloud ks worker-pool ls --cluster <cluster_name_or_ID>
```
いずれかのワーカー・プールのゾーンを調べます。出力中の**「Zones」**フィールドを探します。
```
ibmcloud ks worker-pool get --cluster <cluster_name_or_ID> --worker-pool <pool_name>
```
前の手順で確認した各ゾーンについて、パブリック VLAN とプライベート VLAN が対応しているものがあるか確認します。
1. 出力中の**「Type」**の下にリストされているパブリック VLAN とプライベート VLAN を確認します。
```
ibmcloud ks vlan ls --zone <zone>
```
2. ゾーンのパブリック VLAN とプライベート VLAN が対応していることを確認します。対応している VLAN は、Router のポッド ID が同じです。この出力例では、Router のポッド ID は 01a と 01a であり、一致しています。どちらかのポッド ID が 01a で、もう一方が 02a であれば、これらのパブリック VLAN ID とプライベート VLAN ID をワーカー・プールに設定することはできません。
```
ID        Name   Number   Type      Router         Supports Virtual Workers
229xxxx          1234     private   bcr01a.dal12   true
229xxxx          5678     public    fcr01a.dal12   true
```
3. ゾーンに新しいパブリックまたはプライベート VLAN を注文する必要がある場合は、IBM Cloud コンソールまたは以下のコマンドを使用して注文できます。前の手順で示したように、プライベート VLAN とパブリック VLAN は、同じ Router のポッド ID を持つ、対応した VLAN でなければならないことを忘れないでください。新しいパブリック VLAN とプライベート VLAN をペアにする場合は、それらの VLAN が対応していなければなりません。
```
ibmcloud sl vlan create -t [public|private] -d <zone> -r <compatible_router>
```
4. 対応している VLAN の ID をメモします。
ゾーンごとに、新しい VLAN ネットワーク・メタデータをワーカー・プールにセットアップします。ワーカー・プールを新規作成することも、既存のワーカー・プールを変更することもできます。
- ワーカープールを作成する: 新しいワーカープールを作成してワーカーノードを追加するを参照してください。
- 既存のワーカー・プールを変更する: ゾーンごとに特定の VLAN を使用するようにワーカー・プールのネットワーク・メタデータを設定します。プール内に既に作成されているワーカー・ノードは前の VLAN を使用し続けますが、プール内の新しいワーカー・ノードは、設定した新しい VLAN メタデータを使用します。
- パブリック VLAN とプライベート VLAN の両方を追加する例 (プライベートのみの環境からプライベートとパブリックの両方の環境に変更する場合など)
```
ibmcloud ks zone network-set --zone <zone> --cluster <cluster_name_or_ID> --worker-pool <pool_name> --private-vlan <private_vlan_id> --public-vlan <public_vlan_id>
```
- プライベート VLAN のみを追加する例 (VRF を有効にしたアカウントで複数のサービス・エンドポイントを使用している場合に、パブリックとプライベートの両方の VLAN からプライベートのみの VLAN に変更する場合など)
```
ibmcloud ks zone network-set --zone <zone> --cluster <cluster_name_or_ID> --worker-pool <pool_name> --private-vlan <private_vlan_id> --private-only
```
プールのサイズを変更して、ワーカー・ノードをワーカー・プールに追加します。
```
ibmcloud ks worker-pool resize --cluster <cluster_name_or_ID> --worker-pool <pool_name> --size-per-zone <number_of_workers_per_zone>
```
前のネットワーク・メタデータを使用するワーカー・ノードを削除するには、ゾーンごとのワーカー数を変更して、前のゾーンごとのワーカー数の 2 倍になるようにします。この手順の後半に、前のワーカー・ノードを閉鎖、排出、そして削除できます。
出力で、適切な パブリック IP アドレスと プライベート IP アドレスを持つ新しいワーカー・ノードが作成されていることを確認します。例えば、パブリックとプライベートの両方の VLAN からプライベートのみの VLAN にワーカー・プールを変更した場合は、新しいワーカー・ノードはプライベート IP のみを持ちます。ワーカー・プールをプライベートのみの VLAN からパブリックとプライベートの両方の VLAN に変更した場合は、新しいワーカー・ノードはパブリック IP とプライベート IP の両方を持ちます。
```
ibmcloud ks worker ls --cluster <cluster_name_or_ID> --worker-pool <pool_name>
```
オプション: 前のネットワーク・メタデータを使用しているワーカー・ノードをワーカー・プールから削除します。
1. 前の手順の出力から、ワーカー・プールから削除するワーカー・ノードの ID をメモします。
2. ワーカー・ノードを削除します。
```
ibmcloud ks worker rm --cluster <cluster_name_or_ID> --worker <worker_name_or_ID>
```
3. ワーカー・ノードが削除されたことを確認します。
```
ibmcloud ks worker ls --cluster <cluster_name_or_ID> --worker-pool <pool_name>
```
4. ワーカー・プールのバランスを再調整します。
```
ibmcloud ks worker-pool rebalance --cluster <cluster_name_or_ID> --worker-pool <pool_name>
```
オプション: クラスター内の各ワーカー・プールについて、手順 2 から 7 までを繰り返すことができます。これらの手順が完了すると、クラスター内のすべてのワーカー・ノードに新しい VLAN がセットアップされます。
クラスター内のデフォルトの ALB は、古い VLAN のサブネットから IP アドレスを割り当てられているので、古い VLAN に結び付けられたままです。 VLAN 間で ALB を移動することはできません。代わりに、新しい VLAN 上に ALB を作成し、古い VLAN 上の ALB を無効にすることができます。
オプション: 古い VLAN 上のサブネットが不要になった場合は、それらを削除できます。