Satellite のロケーションとクラスターでのネットワーク・セットアップのカスタマイズ

Satellite Red Hat CoreOS

Satellite ネットワーク・セットアップをカスタマイズするために使用できる機能がいくつかあります。これにより、ロケーションで実行されているサービスとワークロードの分離とセグメント化が向上します。 詳細については、以下のセクションをご確認ください。

これらのカスタマイズは、 Red Hat CoreOS-enabled。

適用するネットワーキングのカスタマイズに応じて、ロケーションの作成時、クラスターの作成時、またはロケーションとクラスターのセットアップ後に、CLI で特定のオプションを指定する必要がある場合があります。 以下のタグは、カスタマイズをいつ適用するかを示します。

  • ロケーション作成時: これらのカスタマイズは、ロケーション作成時に CLI から適用する必要があります。
  • クラスター作成時: これらのカスタマイズは、クラスター作成時に CLI から適用できます。
  • ロケーションとクラスターの作成後: これらのカスタマイズは、ロケーションとクラスターの作成後に適用できます。

ロケーション作成時のカスタム・サブネットの定義

ロケーション作成中

CLI でロケーションを作成するときに、以下のパラメーターを定義して、ロケーションでのネットワーキングをカスタマイズできます。 詳しくは、「 ibmcloud sat location create コマンド・リファレンス」を参照してください。

--pod-subnet オプションを指定して、ポッドのプライベート IP アドレスを提供するカスタム・サブネット CIDR を指定できます。 このオプションは、 --coreos-enabled フラグを使用して Red Hat CoreOS も有効にしている場合にのみ使用できます。 サブネットは、少なくとも /23 以上のサイズでなければなりません。 デフォルト値は 172.16.0.0/16です。

また、 --service-subnet オプションを指定して、サービスのプライベート IP アドレスを提供するカスタム・サブネット CIDR を指定することもできます。 このオプションは、 --coreos-enabled フラグを使用して Red Hat CoreOS も有効にしている場合にのみ使用できます。 サブネットは、少なくとも /24 以上のサイズでなければなりません。 デフォルト値は 172.20.0.0/16です。

ロケーション作成時のポッド・ネットワーク・インターフェースの定義

ロケーション作成中

CLI でロケーションを作成するときに、 --pod-network-interface を定義してポッド・ネットワーク・インターフェースを設定できます。 使用可能なメソッドは、 can-reach および interface です。

  • 直接 URL またはIPアドレスを提供するには、 can-reach=<url> または can-reach=<ip_address> を指定します。 ネットワーク・インターフェイスが提供された URL またはIPアドレスに到達できる場合、このオプションが使用される。 例えば、 URL を指定する場合は can-reach=www.exampleurl.com を、IPアドレスを指定する場合は can-reach=172.19.0.0 を使用する。
  • 正規表現ストリングを使用するインターフェースを選択するには、 interface=<regex_string> を指定します (例: interface=eth.*)。

詳しくは、「 ibmcloud sat location create コマンド・リファレンス」を参照してください。

クラスター作成時のポッド・ネットワーク・インターフェースの定義

クラスタ作成時

CLI でクラスターを作成するときに、 --pod-network-interface を定義してポッド・ネットワーク・インターフェースを設定できます。 使用可能なメソッドは、 can-reach および interface です。

  • 直接 URL またはIPアドレスを提供するには、 can-reach=<url> または can-reach=<ip_address> を指定します。 ネットワーク・インターフェイスが提供された URL またはIPアドレスに到達できる場合、このオプションが使用される。 例えば、 URL を指定する場合は can-reach=www.exampleurl.com を、IPアドレスを指定する場合は can-reach=172.19.0.0 を使用する。
  • 正規表現ストリングを使用するインターフェースを選択するには、 interface=<regex_string> を指定します (例: interface=eth.*)。

詳しくは、「 ibmcloud oc cluster create satellite コマンド・リファレンス」を参照してください。

Satellite クラスターへのアクセスの制限

ロケーションとクラスタ作成後

ロケーションとクラスターを作成した後、 ibmcloud ks cluster master satellite-service-endpoint allowlist add コマンドを使用して、 Satellite クラスターのサービス・エンドポイント許可リストにサブネットを追加できます。 そのサブネットから発信された、クラスタマスターへの認証済みリクエストは、 Satellite サービスエンドポイントを通じて許可されます。 制限を適用するには、許可リストを 有効 にする必要があります。

Calico ホスト・エンドポイントを使用したネットワーク・ポリシーの作成

ロケーションとクラスタ作成後

Satellite クラスター (バージョン 4.12 以降) を作成する場合、ワーカー・ノードのネットワーク・インターフェースごとに、クラスターに Calico Hostendpoint インスタンスがデプロイされます。

これらの Hostendpoint インスタンスを使用すると、各 Hostendpoint インスタンスに追加される “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” ラベルを利用して、グローバル・ネットワーク・ポリシーを定義できます。

このラベルに加えて、すべてのワーカー・ノードのラベルが追加のカスタマイズ・オプション用に追加されます。

これらの Hostendpoints は “projectcalico-default-allow" プロファイルを持っています。つまり、これらの Hostendpoints は、 4.12 にアップデートしたときに、それまで期待されていた動作を変更する可能性があります。

4.12に更新する前に、以前に予期されていたすべてのネットワーキング・ルール、ポリシー、 Hostendpoints も更新後に同じように機能することを確認してください。

詳しくは、 Calico の資料を参照してください。

NodePort サービス・アクセスの制限

ロケーションとクラスタ作成後

デフォルトでは、 NodePort サービスは、クラスターで使用可能なすべてのネットワーク・インターフェース ( 0.0.0.0 など) でアクセス可能です。

ただし、ホストが複数のネットワークを使用できる Satellite のロケーションでは、サービスで使用可能なネットワーク・インターフェースを制限できます。

範囲を制限するには、 NodePort サービスのリスニング・アドレスをクラスター・レベルで制限します。 この制限により、クラスター管理者は、許可されるリスニング・アドレス範囲として IP サブネットを使用して、特定のネットワーク・インターフェースへのアクセスを制限できます。 以下のステップを実行して、 NodePort サービスの listen アドレス範囲を制限するように kube-proxy コンポーネントを再構成します。

node-port-addresses を正しく構成しないと、サービスが有効なソースから分離される可能性があります。 IBM Cloud、クラスタを管理するためにサブネットにアクセスする必要はありません。

  1. Red Hat OpenShift クラスターにアクセスします。

  2. NodePort サービスへのアクセスを許可する予定のソース・サブネット CIDR リストを準備します。

  3. 以下のコマンドを実行して network.operator.openshift.io 構成を取得し、変更を元に戻す必要がある場合に備えてコピーを保存します。

    kubectl get network.operator.openshift.io cluster -o yaml

  4. network.operator.openshift.io 構成を編集し、 spec セクションの下のサブネット・リストを設定して、 NodePort サービスに必要なサブネットを含めます。

    spec:
  kubeProxyConfig:
    proxyArguments:
      node-port-addresses:
      - 192.0.2.0/24
      - 198.51.100.0/24

  5. 変更を保存してクラスターに適用します。

    oc apply -f updated-network-config.yaml

  6. クラスター・バージョン 4.10.x 以前の場合、クラスター・ネットワーク・オペレーターの管理状態を Unmanaged に設定します。

     oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Unmanaged"}}'

  7. 変更を反映させるには、 kube-proxy （ DaemonSet ）を再起動してください。 この作業は業務に支障をきたすものではありません。

    oc rollout restart ds -n openshift-kube-proxy openshift-kube-proxy

  8. すべての kube-proxy ポッドが再始動するまで待ちます。 次のコマンドを実行して、ステータスを確認してください。

    oc get po -n openshift-kube-proxy --selector app=kube-proxy

  9. 4.10.x 以前のクラスター・バージョンの場合は、クラスター・ネットワーク・オペレーターの管理状態を Managed にリセットします。 このアクションによってプロキシー・ポッドが再始動される可能性があることに注意してください。

     oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Managed"}}'

すべてのポッドが再始動されると、クラスターは制限付きサブネットを使用して構成されます。 これらのステップを繰り返して、必要に応じてサブネット・リストを更新または削除することができます。

NetworkPolicies を使用して、サービスごとにトラフィックをさらに制限することができます。