第14章 Hosted Control Plane のネットワーク
ネットワーク設定を設定することで、Hosted Control Plane の最適なパフォーマンスを確保できます。これらの設定には、内部サブネット、制御プレーンワークロード、コンピュートノード、管理クラスター、およびホステッドクラスターのプロキシーサポートが含まれます。
14.1. Hosted Control Plane のイングレスおよび Egress 要件 リンクのコピーリンクがクリップボードにコピーされました!
管理クラスター、Hosted Control Plane コンポーネント、およびコンピュートノード間の通信には、特定のネットワークポートを開放しておく必要があります。ポートは、Hosted Control Plane への受信トラフィックを扱うイングレスポートと、Hosted Control Plane からの送信トラフィックを扱う Egress ポートに分類されます。
14.1.1. Hosted Control Plane のイングレス要件 リンクのコピーリンクがクリップボードにコピーされました!
イングレスポートは、Hosted Control Plane への受信トラフィックに関係します。管理クラスター、Hosted Control Plane コンポーネント、およびコンピュートノード間の通信に必要なポートが適切に開いていることを確認してください。
以下の表は、すべてのプラットフォームにおける Hosted Control Plane への受信トラフィックに使用されるポートの詳細を示しています。
| ポート | プロトコル | Service | 説明 | コードリファレンス |
|---|---|---|---|---|
|
| TCP | Kubernetes API サーバー |
|
|
|
| TCP | ignition-server |
ブートストラッププロセス中のコンピュートノードからのポート、 | - |
サービス公開ストラテジーによって、追加ポートが決定されます。Ignition Proxy および Konnectivity サービスは、以下のいずれかのサービス公開ストラテジーを通じて公開されます。
ルート- これは、OpenShift Container Platform のデフォルト設定です。トラフィックはポート 443 を介して OpenShift ルーターを流れます。標準的な HTTPS 以外に、追加のファイアウォールルールは必要ありません。
NodePort- ポート 8091(Konnectivity) とポート 8443(Ignition Proxy) への直接アクセスが必要です。
LoadBalancer- クラウドロードバランサーを介してポート 8091(Konnectivity) に直接アクセスする必要があります。
以下の表は、各プラットフォーム固有の入力ポート設定の詳細を示しています。
| プラットフォーム | ポート | Service | 説明 | コードリファレンス |
|---|---|---|---|---|
| エージェント |
| イグニッションプロキシー |
Ignition コンテンツ配信のための HTTPS プロキシー ( |
|
| エージェント |
| エージェント CAPI ヘルスプローブ | エージェントプラットフォーム CAPI プロバイダーのヘルスチェックエンドポイント |
|
| エージェント |
| エージェント CAPI メトリクス | エージェントプラットフォーム CAPI プロバイダーのメトリクスエンドポイント (localhost のみにバインド) |
|
| AWS | 1.47.4 | CAPI ヘルスチェック | AWS CAPI プロバイダーのヘルスおよび準備状況プローブエンドポイント |
|
| エージェントプラットフォームなしのベアメタル |
| イグニッションプロキシー |
Ignition コンテンツ配信のための HTTPS プロキシー ( | - |
| kubevirt | 1.47.4 | CAPI ヘルスチェック | 健康状態と準備状況の調査エンドポイント |
|
| RHOSP(テクノロジープレビュー) | 1.47.4 | CAPI ヘルスチェック | 健康状態と準備状況の調査エンドポイント |
|
| RHOSP(テクノロジープレビュー) |
| ORC ヘルスチェック | OpenStack Resource Controller のヘルスおよび準備状況プローブエンドポイント |
|
次の表は、AWS などのプライベートクラスターにおけるイングレスポート設定の詳細を示しています。
| ポート | Service | 説明 | コードリファレンス |
|---|---|---|---|
|
| プライベートルーター HTTP | プライベートルーターを経由する HTTP トラフィック |
|
|
| プライベートルーター HTTPS | プライベートルーターを経由する HTTPS トラフィック |
|
14.1.2. Hosted Control Plane の通信要件 リンクのコピーリンクがクリップボードにコピーされました!
出力ポートは、Hosted Control Plane からの送信トラフィックに関係します。管理クラスター、Hosted Control Plane コンポーネント、およびコンピュートノード間の通信に必要なポートが適切に開いていることを確認してください。
以下の表は、すべてのプラットフォームにおいて、Hosted Control Plane からの送信トラフィックにアクセス可能である必要があるポートの詳細を示しています。
| ポート | プロトコル | Service | 目的 |
|---|---|---|---|
|
| TCP | HTTPS |
OLM イメージ、 |
|
| TCP | Kubernetes API サーバー | 管理クラスター API との通信 |
|
| TCP および UDP | DNS | 標準 DNS クエリー |
コンピュートノードは、複数の Hosted Control Plane サービスへのアウトバウンドネットワークアクセスを必要とする。以下の表は、コンピュートノードの Egress 要件の詳細を示しています。
| ポート | プロトコル | Service | 目的 | 必要になる場合 |
|---|---|---|---|---|
|
| TCP | HTTPS |
コンテナーレジストリー、 | Always |
|
| TCP | Kubernetes API サーバー | クラスター管理と kubelet 通信 | Always |
| 1.47.4 | TCP | konnectivity-server | 操縦翼機アクセス用の逆トンネルを確立する |
|
|
| TCP | イグニッションプロキシー | ブートストラップ設定を取得します |
|
|
| TCP および UDP | DNS | 名前解決 | Always |
14.1.3. ファイアウォール設定例 リンクのコピーリンクがクリップボードにコピーされました!
Route サービスパブリッシングを使用する AWS デプロイメント上の一般的な Hosted Control Plane におけるファイアウォール設定の例を確認してください。
- Ingress のルール
-
ポート
6443/TCP: Kubernetes API サーバー (コンピュートノードおよび外部クライアントからアクセス可能) -
ポート
443/TCP: コンピュートノードからの Ignition または Konnectivity ルート用の OpenShift ルーター
-
ポート
- <egress_rules>
-
ポート
443/TCP: HTTPS、コンテナーレジストリー、ルート、および外部サービスへの接続 -
ポート
6443/TCP: 管理クラスター API、管理クラスターへ -
ポート
53/TCP および UDP: DNS、DNS サーバーへ
-
ポート
Route サービス公開の代わりに NodePort または LoadBalancer サービス公開を使用する場合は、以下のルールが適用されます。
-
ポート
8091/TCP: Konnectivity サーバー (コンピュートノードから) -
ポート
8443/TCP: Ignition プロキシー、ブートストラッププロセス中のコンピュートノードから、NodePort公開ストラテジーのみ -
ポート
9090/TCP: Ignition サーバー、ブートストラッププロセス中のコンピュートノードから、NodePort公開ストラテジーのみ
14.1.4. ベアメタル上のホステッドクラスターでの Ingress の処理 リンクのコピーリンクがクリップボードにコピーされました!
すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.es で example という名前のホステッドクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。
手順
*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。
MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。
apiVersion: v1 kind: Namespace metadata: name: metallb labels: openshift.io/cluster-monitoring: "true" annotations: workload.openshift.io/allowed: management --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator-operatorgroup namespace: metallb --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator namespace: metallb spec: channel: "stable" name: metallb-operator source: redhat-operators sourceNamespace: openshift-marketplace-
ファイルを
metallb-operator-config.yamlとして保存します。 以下のコマンドを入力して設定を適用します。
$ oc apply -f metallb-operator-config.yamlOperator の実行後、MetalLB インスタンスを作成します。
MetalLB インスタンスの設定を含む YAML ファイルを作成します。
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-
ファイルを
metallb-instance-config.yamlとして保存します。 次のコマンドを入力して、MetalLB インスタンスを作成します。
$ oc apply -f metallb-instance-config.yaml
単一の IP アドレスを含む
IPAddressPoolリソースを作成します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: namespace: metallb name: <ip_address_pool_name>1 spec: addresses: - <ingress_ip>-<ingress_ip>2 autoAssign: false次のコマンドを入力して、IP アドレスプールの設定を適用します。
$ oc apply -f ipaddresspool.yaml
L2 アドバタイズメントを作成します。
以下の例のような内容で、
l2advertisement.yamlなどのファイルを作成します。apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: <l2_advertisement_name>1 namespace: metallb spec: ipAddressPools: - <ip_address_pool_name>2 次のコマンドを入力して設定を適用します。
$ oc apply -f l2advertisement.yaml
LoadBalancerタイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。metallb-loadbalancer-service.yamlという名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。kind: Service apiVersion: v1 metadata: annotations: metallb.io/address-pool: ingress-public-ip name: metallb-ingress namespace: openshift-ingress spec: ports: - name: http protocol: TCP port: 80 targetPort: 80 - name: https protocol: TCP port: 443 targetPort: 443 selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default type: LoadBalancer-
metallb-loadbalancer-service.yamlファイルを保存します。 YAML 設定を適用するには、次のコマンドを入力します。
$ oc apply -f metallb-loadbalancer-service.yaml次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。
$ curl -kI https://console-openshift-console.apps.example.krnl.es出力例
HTTP/1.1 200 OKclusterversionとclusteroperatorの値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.x.y True False 3m32s Cluster version is 4.x.y NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.x.y True False False 3m50s clusteroperator.config.openshift.io/ingress 4.x.y True False False 53m<4.x.y>は、使用するサポート対象の OpenShift Container Platform バージョン (例:4.20.0-multi) に置き換えます。