第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 への受信トラフィックに使用されるポートの詳細を示しています。

Expand
表14.1 共通 Ingress ポート
ポートプロトコルService説明コードリファレンス

6443

TCP

Kubernetes API サーバー

kubectl とクラスター通信のための主要 API サーバーポート

support/config/constants.go:35 - KASSVCPort = 6443

9090

TCP

ignition-server

ブートストラッププロセス中のコンピュートノードからのポート、NodePort または Route サービスの公開ストラテジー

-

サービス公開ストラテジーによって、追加ポートが決定されます。Ignition Proxy および Konnectivity サービスは、以下のいずれかのサービス公開ストラテジーを通じて公開されます。

ルート
これは、OpenShift Container Platform のデフォルト設定です。トラフィックはポート 443 を介して OpenShift ルーターを流れます。標準的な HTTPS 以外に、追加のファイアウォールルールは必要ありません。
NodePort
ポート 8091(Konnectivity) とポート 8443(Ignition Proxy) への直接アクセスが必要です。
LoadBalancer
クラウドロードバランサーを介してポート 8091(Konnectivity) に直接アクセスする必要があります。

以下の表は、各プラットフォーム固有の入力ポート設定の詳細を示しています。

Expand
表14.2 プラットフォーム固有の入力ポート設定
プラットフォームポートService説明コードリファレンス

エージェント

8443

イグニッションプロキシー

Ignition コンテンツ配信のための HTTPS プロキシー (NodePort パブリッシング)

hypershift-operator/controllers/hostedcluster/network_policies.go:390

エージェント

8081

エージェント CAPI ヘルスプローブ

エージェントプラットフォーム CAPI プロバイダーのヘルスチェックエンドポイント

hypershift-operator/controllers/hostedcluster/internal/platform/agent.go:96,105,115

エージェント

8080

エージェント CAPI メトリクス

エージェントプラットフォーム CAPI プロバイダーのメトリクスエンドポイント (localhost のみにバインド)

hypershift-operator/controllers/hostedcluster/internal/platform/agent/agent.go:97

AWS

1.47.4

CAPI ヘルスチェック

AWS CAPI プロバイダーのヘルスおよび準備状況プローブエンドポイント

hypershift-operator/controllers/hostedcluster/internal/platform/aws/aws.go:222-223

エージェントプラットフォームなしのベアメタル

8443

イグニッションプロキシー

Ignition コンテンツ配信のための HTTPS プロキシー (NodePort パブリッシング)

-

kubevirt

1.47.4

CAPI ヘルスチェック

健康状態と準備状況の調査エンドポイント

hypershift-operator/controllers/hostedcluster/internal/platform/kubevirt/kubevirt.go:140

RHOSP(テクノロジープレビュー)

1.47.4

CAPI ヘルスチェック

健康状態と準備状況の調査エンドポイント

hypershift-operator/controllers/hostedcluster/internal/platform/openstack/openstack.go:238

RHOSP(テクノロジープレビュー)

8081

ORC ヘルスチェック

OpenStack Resource Controller のヘルスおよび準備状況プローブエンドポイント

hypershift-operator/controllers/hostedcluster/internal/platform/openstack/openstack.go:294,311

次の表は、AWS などのプライベートクラスターにおけるイングレスポート設定の詳細を示しています。

Expand
表14.3 プライベートクラスターのイングレスポート設定
ポートService説明コードリファレンス

8080

プライベートルーター HTTP

プライベートルーターを経由する HTTP トラフィック

hypershift-operator/controllers/hostedcluster/network_policies.go:244

8443

プライベートルーター HTTPS

プライベートルーターを経由する HTTPS トラフィック

hypershift-operator/controllers/hostedcluster/network_policies.go:245

14.1.2. Hosted Control Plane の通信要件

出力ポートは、Hosted Control Plane からの送信トラフィックに関係します。管理クラスター、Hosted Control Plane コンポーネント、およびコンピュートノード間の通信に必要なポートが適切に開いていることを確認してください。

以下の表は、すべてのプラットフォームにおいて、Hosted Control Plane からの送信トラフィックにアクセス可能である必要があるポートの詳細を示しています。

Expand
表14.4 共通 Egress 口
ポートプロトコルService目的

443

TCP

HTTPS

OLM イメージ、Ignition コンテンツ、外部 HTTPS サービス

6443

TCP

Kubernetes API サーバー

管理クラスター API との通信

53

TCP および UDP

DNS

標準 DNS クエリー

コンピュートノードは、複数の Hosted Control Plane サービスへのアウトバウンドネットワークアクセスを必要とする。以下の表は、コンピュートノードの Egress 要件の詳細を示しています。

Expand
表14.5 コンピュートノードの Egress 要件
ポートプロトコルService目的必要になる場合

443

TCP

HTTPS

コンテナーレジストリー、Ignition または Konnectivity サービス (Route サービス公開ストラテジー経由)、外部 HTTPS サービス

Always

6443

TCP

Kubernetes API サーバー

クラスター管理と kubelet 通信

Always

1.47.4

TCP

konnectivity-server

操縦翼機アクセス用の逆トンネルを確立する

NodePort または LoadBalancer のみの公開

8443

TCP

イグニッションプロキシー

ブートストラップ設定を取得します

NodePort の 公開は、エージェントプラットフォームまたはベアメタルのみで行われます。

53

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.esexample という名前のホステッドクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

手順

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

  1. 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
  2. ファイルを metallb-operator-config.yaml として保存します。
  3. 以下のコマンドを入力して設定を適用します。

    $ oc apply -f metallb-operator-config.yaml
  4. Operator の実行後、MetalLB インスタンスを作成します。

    1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: MetalLB
      metadata:
        name: metallb
        namespace: metallb
    2. ファイルを metallb-instance-config.yaml として保存します。
    3. 次のコマンドを入力して、MetalLB インスタンスを作成します。

      $ oc apply -f metallb-instance-config.yaml
  5. 単一の IP アドレスを含む IPAddressPool リソースを作成します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    1. 以下の例のような内容で、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
      1
      IPAddressPool リソース名を指定します。
      2
      環境の IP アドレスを指定します。たとえば、192.168.122.23 です。
    2. 次のコマンドを入力して、IP アドレスプールの設定を適用します。

      $ oc apply -f ipaddresspool.yaml
  6. L2 アドバタイズメントを作成します。

    1. 以下の例のような内容で、l2advertisement.yaml などのファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: <l2_advertisement_name> 
      1
      
        namespace: metallb
      spec:
        ipAddressPools:
         - <ip_address_pool_name> 
      2
      1
      L2Advertisement リソース名を指定します。
      2
      IPAddressPool リソース名を指定します。
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f l2advertisement.yaml
  7. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

    1. 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
    2. metallb-loadbalancer-service.yaml ファイルを保存します。
    3. YAML 設定を適用するには、次のコマンドを入力します。

      $ oc apply -f metallb-loadbalancer-service.yaml
    4. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

      $ curl -kI https://console-openshift-console.apps.example.krnl.es

      出力例

      HTTP/1.1 200 OK

    5. clusterversionclusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。

      $ 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) に置き換えます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る