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

ロケーション作成中

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 を使用して、サービスごとにトラフィックをさらに制限することができます。