VLAN

クラスターを作成すると、クラスターの各ワーカー・ノードが 1 つの VLAN に自動的に接続されます。 VLAN では、ワーカー・ノードとポッドをまとめた 1 つのグループを、それらのワーカー・ノードとポッドが同じ物理ワイヤーに接続されているかのように構成し、それらのワーカーとポッド間の接続に 1 つのチャネルを提供します。

標準クラスター用の VLAN

標準クラスターでは、あるゾーンで初めてクラスターを作成したときに、そのゾーン内のパブリック VLAN とプライベート VLAN が IBM Cloud インフラストラクチャー・アカウントで自動的にプロビジョンされます。 それ以降、そのゾーンにクラスターを作成するたびに、そのゾーンで使用したい VLAN のペアを指定する必要があります。 VLAN は複数のクラスターで共有できるので、お客様用に作成された同一のパブリック VLAN とプライベート VLAN を何度も使用することができます。 ワーカー・ノードをパブリック VLAN とパブリック VLAN の両方に接続することも、プライベート VLAN だけに接続することもできます。 ワーカー・ノードをプライベート VLAN にのみ接続する場合は、既存のプライベート VLAN の ID を使用することもできますし、プライベート VLAN を作成し、クラスター作成時にその ID を使用することもできます。

アカウントの各ゾーンにプロビジョンされている VLAN を確認するには、ibmcloud ks vlan ls --zone <zone>. を実行します。1 つのクラスターがプロビジョンされている VLAN を確認するには、ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources を実行して、サブネット VLAN セクションを探します。

IBM Cloud インフラストラクチャーは、ゾーンに最初のクラスターを作成する際に自動的にプロビジョンされる VLAN を管理します。 VLAN からすべてのワーカー・ノードを削除した場合などのように、VLAN を未使用の状態にすると、IBM Cloud インフラストラクチャーは VLAN を再利用します。 その後、新規 VLAN が必要な場合は、IBM Cloud サポートにお問い合わせください。

VLANの決定は後で変更できますか？

クラスターのワーカー・プールを変更することで、VLAN セットアップを変更できます。 詳しくは、ワーカー・ノードの VLAN 接続を変更するを参照してください。

サブネットと IP アドレス

ワーカー・ノードとポッドに加えて、サブネットも VLAN に自動的にプロビジョンされます。 サブネットは、クラスター・コンポーネントに IP アドレスを割り当てることによって、クラスター・コンポーネントにネットワーク接続を提供します。

次の各サブネットが、デフォルトのパブリック VLAN とプライベート VLAN に自動的にプロビジョンされます。

アカウントでプロビジョンされているサブネットの確認

アカウントのすべてのリソース・グループにプロビジョンされているすべてのサブネットを表示するには、ibmcloud ks subnets --provider classic を実行します。 1 つのクラスターにバインドされているポータブル・パブリック・サブネットとポータブル・プライベート・サブネットを確認するには、ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources を実行して、サブネット VLAN セクションを探します。

IBM Cloud Kubernetes Service では、VLAN のサブネット数の上限は 40 です。 この制限に達したら、まず その VLAN 内にあるサブネットを再利用して新規クラスターを作成できるかどうかを確認します。 新規 VLAN が必要な場合、IBM Cloud サポートに連絡して注文してください。 その後、その新規 VLAN を使用するクラスターを作成します。

ワーカーノードのIPアドレスは変更されますか？

ワーカー・ノードには、クラスターで使用されるパブリック VLAN またはプライベート VLAN の IP アドレスが割り当てられます。 ワーカー・ノードがプロビジョンされた後は、ワーカー・ノードの IP アドレスは reboot 操作および update 操作を実行しても変わりませんが、replace 操作を実行すると変わります。 また、ほとんどの kubectl コマンドでは、ワーカー・ノードの ID にワーカー・ノードのプライベート IP アドレスが使用されます。 ワーカー・プールで使用されている VLAN を変更すると、そのプールでプロビジョンされた新しいワーカー・ノードはその IP アドレスに新しい VLAN を使用します。 既存のワーカー・ノードの IP アドレスは変更されませんが、古い VLAN を使用するワーカー・ノードを削除することができます。

クラスタ内のポッドやサービスにサブネットを指定することはできますか？

IBM Cloud Direct Link または VPN サービスを介してクラスターをオンプレミスのネットワークに接続する場合は、カスタムのサブネット CIDR を指定してポッドのプライベート IP アドレス、およびサービスのプライベート IP アドレスを提供することで、サブネットの競合を回避できます。

クラスタ作成時にカスタムのポッドおよびサービスサブネットを指定するには、 ibmcloud ks cluster create CLIコマンドで --pod-subnet および --service-subnet オプションを使用します。

ネットワーク・セグメンテーション

ネットワーク・セグメンテーションとは、1 つのネットワークを複数のサブネットワークに分割する方式を表すものです。 1 つのサブネットワーク内で実行されるアプリは、別のサブネットワーク内のアプリを表示することも、アクセスすることもできません。 ネットワーク・セグメンテーションのオプションおよび VLAN との関係について詳しくは、クラスターのセキュリティーに関するこちらのトピックを参照してください。

ただし、状況によっては、クラスターのコンポーネントに、複数のプライベート VLAN をまたぐ通信を許可しなければならない場合があります。 例えば、複数ゾーン・クラスターを作成する場合や、1 つのクラスターに複数の VLAN が存在する場合、同じ VLAN 上に複数のサブネットが存在する場合は、同じ VLAN 上にあってもサブネットが異なるワーカー・ノード、または異なる VLAN 上にあるワーカー・ノードは、そのままでは相互通信できません。 ユーザーが IBM Cloud インフラストラクチャー・アカウントで仮想ルーター機能 (VRF) または VLAN スパンニングを有効にする必要があります。

Virtual Routing and Forwarding (VRF)

VRF は、インフラストラクチャー・アカウント内のすべての VLAN とサブネットが相互に通信できるようにします。 また、プライベート・クラウド・サービス・エンドポイントを介してワーカーとマスターを通信させる場合も VRF が必要です。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にすることで、アカウントの VLAN スパンニングのオプションがなくなることに注意してください。これは、トラフィックを管理するゲートウェイ・アプライアンスを構成していない限り、すべての VLAN が通信できるようになるためです。

VLAN スパンニング

VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にしてください。 この操作を実行するには、**「ネットワーク」>「ネットワーク VLAN スパンニングの管理」**で設定するインフラストラクチャー権限が必要です。ない場合は、アカウント所有者に対応を依頼してください。 VLAN スパンニングが既に有効になっているかどうかを確認するには、ibmcloud ks vlan spanning get --region <region> コマンドを使用します。 VRF の代わりに VLAN スパンニングを有効にすることを選択した場合は、プライベート・クラウド・サービス・エンドポイントを有効にできないことに注意してください。

VRFまたはVLANスパニングは、ネットワークのセグメント化にどのような影響を与えますか？

VRF または VLAN スパンニングを有効にすると、同じ IBM Cloud アカウントのプライベート VLAN に接続されているすべてのシステムが、ワーカーと通信できるようになります。 Calico プライベート・ネットワーク・ポリシー を適用することにより、クラスターをプライベート・ネットワーク上の他のシステムから分離できます。 IBM Cloud Kubernetes Service は、すべての IBM Cloud インフラストラクチャー・ファイアウォール・オファリングと互換性があります。 仮想ルーター・アプライアンスなどのファイアウォールにカスタム・ネットワーク・ポリシーをセットアップして、標準クラスターのために専用のネットワーク・セキュリティーを装備し、ネットワーク侵入を検出して対処することができます。

使用可能なポータブル・パブリック IP アドレスの表示

クラスター内のすべてのポータブル IP アドレス (使用中と使用可能の両方) をリスト表示するには、以下のコマンドを実行します。

kubectl get cm ibm-cloud-provider-vlan-ip-config -n kube-system -o yaml

パブリック NLB または追加のパブリック ALB の作成に使用できるポータブル・パブリック IP アドレスだけをリスト表示するには、次の手順を使用できます。

開始前に

• ライター またはマネージャーの IAMサービスアクセスロールを持っていることを確認してください IBM Clouddefault 名前空間。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

使用可能なポータブル・パブリック IP アドレスをリスト表示するには、以下のようにします。

1. myservice.yaml という Kubernetes サービス構成ファイルを作成します。このファイルでは、ダミーの NLB IP アドレスを使用して LoadBalancer タイプのサービスを定義します。 以下の例では、NLB IP アドレスとして IP アドレス 1.1.1.1 を使用します。 <zone> を、使用可能な IP があるかどうかを確認するゾーンに置き換えてください。

   apiVersion: v1
   kind: Service
   metadata:
     labels:
       run: myservice
     name: myservice
     namespace: default
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
   spec:
     ports:
     - port: 80
       protocol: TCP
       targetPort: 80
     selector:
       run: myservice
     sessionAffinity: None
     type: LoadBalancer
     loadBalancerIP: 1.1.1.1
   

2. クラスター内にサービスを作成します。

   kubectl apply -f myservice.yaml
   

3. サービスを検査します。

   kubectl describe service myservice
   

   Kubernetes マスターが 指定された NLB IP アドレスを Kubernetes 構成マップで検出できないため、このサービスの作成は失敗します。 このコマンドを実行すると、エラー・メッセージと、クラスターで使用可能なパブリック IP アドレスのリストが表示されます。

   Error on cloud load balancer a8bfa26552e8511e7bee4324285f6a4a for service default/myservice with UID 8bfa2655-2e85-11e7-bee4-324285f6a4af: Requested cloud provider IP 1.1.1.1 is not available. The following cloud provider IP addresses are available: <list_of_IP_addresses>
   

使用されている IP アドレスの解放

ポータブル IP アドレスを使用しているネットワーク・ロード・バランサー (NLB) サービスを削除するか、Ingress アプリケーション・ロード・バランサー (ALB) を無効にすることによって、使用されているポータブル IP アドレスを解放できます。

開始前に

• ライター またはマネージャーの IAMサービスアクセスロールを持っていることを確認してください IBM Clouddefault 名前空間。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

NLB を削除する場合、または ALB を無効にする場合は、以下のようにします。

1. クラスターで使用可能なサービスをリスト表示します。

   kubectl get services | grep LoadBalancer
   

2. パブリック IP アドレスまたはプライベート IP アドレスを使用しているロード・バランサー・サービスを削除するか、ALB を無効にします。
   • NLB の削除 :

     kubectl delete service <service_name>
     

   • ALB の無効化 :

     ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
     

サブネットをさらにオーダーしてポータブル IP を追加する

NLB サービス用にさらにポータブル IP を取得できます。この取得は、IBM Cloud インフラストラクチャー・アカウントで新規サブネットを作成し、指定したクラスターでそのサブネットを使用できるようにすることで行います。

ポータブル・パブリック IP アドレスは、月単位で課金されます。 サブネットをプロビジョンした後にポータブル・パブリック IP アドレスを削除した場合、短時間しか使用していなくても月額料金を支払う必要があります。

開始前に

• クラスタに対して、 オペレータまたは管理者の IAMプラットフォームアクセス権限 を持っていることを確認してください。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

サブネットを注文するには、以下のようにします。

1. 新しいサブネットをプロビジョンします。

   ibmcloud ks cluster subnet create --cluster <cluster_name_or_id> --size <subnet_size> --vlan <VLAN_ID>
   

   サブネットのパラメータ

   パラメーター	説明
   <cluster_name_or_id>	クラスターの名前または ID を <cluster_name_or_id> に置き換えます。
   <subnet_size>	<subnet_size> を、ポータブル・サブネットで作成する IP アドレスの数に置き換えます。 受け入れられる値は 8、16、32、64 です。 サブネットのポータブル IP アドレスを追加する場合は、3 つの IP アドレスがクラスター内部のネットワークの確立のために使用されることに注意してください。 これら 3 つの IP アドレスを Ingress アプリケーション・ロード・バランサー (ALB) に使用したり、これらを使用してネットワーク・ロード・バランサー (NLB) サービスを作成したりすることはできません。 例えば、8 個のポータブル・パブリック IP アドレスを要求する場合は、そのうちの 5 個を、アプリをパブリックに公開するために使用できます。
   <VLAN_ID>	<VLAN_ID> を、ポータブル・パブリック IP アドレスまたはポータブル・プライベート IP アドレスを割り振るパブリック VLAN またはプライベート VLAN の ID に置き換えます。 既存のワーカー・ノードが接続されているパブリック VLAN またはプライベート VLAN を選択する必要があります。 ワーカー・ノードが接続されているパブリック VLAN またはプライベート VLAN を確認するには、ibmcloud ks cluster get --cluster <cluster> --show-resources を実行し、出力で サブネット VLAN セクションを探します。 サブネットは、VLAN が存在するゾーンにプロビジョンされます。

2. クラスターにサブネットが正常に作成されて追加されたことを確認します。 サブネットの CIDR は Subnet VLANs セクションにリストされます。

   ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
   

   次の例の出力では、2 番目のサブネットがパブリック VLAN の 2234945 に追加されています。

   Subnet VLANs
   VLAN ID   Subnet CIDR          Public   User-managed
   2234947   10.xxx.xx.xxx/29     false    false
   2234945   169.xx.xxx.xxx/29    true     false
   2234945   169.xx.xxx.xxx/29    true     false
   

3. 重要: 同じ VLAN 上の別のサブネットにあるワーカー間の通信を可能にするには、その同じ VLAN 上のサブネット間のルーティングを有効にする必要があります。

既存のサブネットをクラスターに追加してポータブル IP を追加する

IBM Cloud インフラストラクチャー・アカウント内の既存のサブネットをクラスターで使用できるようにすることによって、NLB サービス用にさらにポータブル IP を取得できます。

開始前に

• クラスタに対して、 オペレータまたは管理者の IAMプラットフォームアクセス権限 を持っていることを確認してください。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

サブネットをクラスターで使用できるようにするには、以下のようにします。

1. ポータブル・パブリック IP アドレスまたはポータブル・プライベート IP アドレスの割り振り先となるパブリックまたはプライベートの VLAN ID を確認します。 既存のワーカー・ノードが接続されているパブリック VLAN またはプライベート VLAN を選択する必要があります。

   ibmcloud ks cluster get --cluster <cluster_name_or_id> --show-resources
   

   出力の Subnet VLANs セクションで、VLAN ID を探します。

   Subnet VLANs
   VLAN ID   Subnet CIDR          Public   User-managed
   2234947   10.xxx.xx.xxx/29     false    false
   2234945   169.xx.xxx.xxx/29    true     false
   

2. 使用するサブネットの ID を取得します。 前のステップで見つけた VLAN ID のいずれかにサブネットがあること、またサブネットが既に別のクラスターにバインドされていないことを確かめます。

   ibmcloud ks subnets --provider classic
   

   次の出力例では、サブネット ID は 1602829 で、それが存在する VLAN ID は 2234945 です。

   GETting subnet list...
   OK
   ID        Network             Gateway          VLAN ID   Type      Bound Cluster
   1550165   10.xxx.xx.xxx/26    10.xxx.xx.xxx    2234947   private
   1602829   169.xx.xxx.xxx/28   169.xx.xxx.xxx   2234945   public
   

3. サブネットをクラスターで使用できるようにします。

   ibmcloud ks cluster subnet add --cluster <cluster_name_or_id> --subnet-id <subnet_ID>
   

4. クラスターにサブネットが正常に作成されて追加されたことを確認します。 サブネットの CIDR は Subnet VLANs セクションにリストされます。

   ibmcloud ks cluster get --cluster <cluster_name> --show-resources
   

   次の例の出力では、2 番目のサブネットがパブリック VLAN の 2234945 に追加されています。

   Subnet VLANs
   VLAN ID   Subnet CIDR          Public   User-managed
   2234947   10.xxx.xx.xxx/29     false    false
   2234945   169.xx.xxx.xxx/29    true     false
   2234945   169.xx.xxx.xxx/29    true     false
   

5. 重要: 同じ VLAN 上の別のサブネットにあるワーカー間の通信を可能にするには、その同じ VLAN 上のサブネット間のルーティングを有効にする必要があります。

同一 VLAN 上の 1 次サブネット間のルーティングを有効にする

クラスターを作成すると、プライマリーのパブリック・サブネットとプライベート・サブネットはパブリック VLAN とプライベート VLAN 上にプロビジョンされます。 プライマリー・パブリック・サブネットは /28 で終わり、14 個のワーカー・ノード用パブリック IP を提供します。 プライマリー・プライベート・サブネットは /26 で終わり、最大 62 個のワーカー・ノード用プライベート IP を提供します。

同じ VLAN 上の同じ場所に単一の大規模クラスターまたは複数の小規模クラスターを配置することで、ワーカー・ノード用に初期提供される 14 個のパブリック IP と 62 個のプライベート IP を超過する場合があります。 パブリック・サブネットまたはプライベート・サブネットがワーカー・ノードの上限数に達すると、同じ VLAN 内のもう 1 つのプライマリー・サブネットが注文されます。

同一 VLAN 上のこれらの 1 次サブネット内の各ワーカーが通信できるようにするには、VLAN スパンニングをオンにする必要があります。 手順については、VLAN スパンの有効化または無効化を参照してください。

VLAN スパンニングが既に有効になっているかどうかを確認するには、ibmcloud ks vlan spanning get --region <region> コマンドを使用します。

ゲートウェイ・アプライアンス用のサブネットのルーティングの管理

クラスターを作成すると、そのクラスターが接続されている VLAN 上にポータブル・パブリック・サブネットとポータブル・プライベート・サブネットがオーダーされます。 これらのサブネットは、Ingress アプリケーション・ロード・バランサー (ALB) およびネットワーク・ロード・バランサー (NLB) サービス用の IP アドレスを提供します。

ただし、Virtual Router Appliance (VRA) などの既存のルーター・アプライアンスが存在する場合は、そのクラスターが接続されている VLAN から新しく追加されたポータブル・サブネットはそのルーター上で構成されません。 NLB または Ingress ALB を使用するには、IBM Cloud インフラストラクチャー・アカウントに対して仮想ルーター機能 (VRF) を有効にすることにより、ネットワーク・デバイスが同じ VLAN 上の異なるサブネット間でルーティングできるようにする必要があります。 VRF を有効にするには、VRF の有効化を参照してください。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。