サービス・エンドポイントまたは 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
```
一度に使用不可にできるクラスター内のワーカー・ノードの最大数を制御する構成マップを作成します。この構成マップによって、ワーカー・ノードを更新するときに、使用可能なワーカー・ノードに順番にアプリが再スケジュールされるので、アプリのダウン時間の発生を回避できます。
クラスター内のすべてのワーカー・ノードを更新して、パブリック・クラウド・サービス・エンドポイント構成を削除します。
```
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
```

オプション: プライベート・クラウド・サービス・エンドポイントのみを使用するには、次のようにします。

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

    ibmcloud ks cluster master public-service-endpoint disable --cluster CLUSTER_NAME_OR_ID
    ```
2. [プライベート・クラウド・サービス・エンドポイント上のマスターへのアクセスをセットアップします](/docs/containers?topic=containers-access-private-classic)。

ワーカー・ノードの 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 が対応しているものがあるか確認します。

出力中の**「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 をワーカー・プールに設定することはできません。
```sh {: screen}
    ID        Name   Number   Type      Router         Supports Virtual Workers
    229xxxx          1234     private   bcr01a.dal12   true
    229xxxx          5678     public    fcr01a.dal12   true
    ```
3. ゾーンに新しいパブリックまたはプライベート VLAN を注文する必要がある場合は、[IBM Cloud コンソール](/docs/vlans?topic=vlans-ordering-premium-vlans#ordering-premium-vlans)または以下のコマンドを使用して注文できます。 前の手順で示したように、プライベート VLAN とパブリック VLAN は、同じ **Router** のポッド ID を持つ、対応した VLAN でなければならないことを忘れないでください。 新しいパブリック VLAN とプライベート VLAN をペアにする場合は、それらの VLAN が対応していなければなりません。
```sh {: pre}
    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 を有効にしたアカウントで複数のサービス・エンドポイントを使用している場合](/docs/account?topic=account-vrf-service-endpoint)に、パブリックとプライベートの両方の VLAN からプライベートのみの VLAN に変更する場合など)

```sh {: pre}
    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
```

オプション: 前のネットワーク・メタデータを使用しているワーカー・ノードをワーカー・プールから削除します。

前の手順の出力から、ワーカー・プールから削除するワーカー・ノードの ID をメモします。
ワーカー・ノードを削除します。

    ibmcloud ks worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_NAME_OR_ID
    ```
3. ワーカー・ノードが削除されたことを確認します。
```sh {: pre}
    ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
    ```
4. ワーカー・プールのバランスを再調整します。
```sh {: pre}
    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 上のサブネットが不要になった場合は、それらを削除できます。