Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

ネットワークの概要

OpenShift Container Platform 4.20

OpenShift Container Platform の基本的なネットワーク概念と一般的なタスクを理解する

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform 内のコアネットワーク概念、基本アーキテクチャー、および一般的なネットワークタスクを紹介します。

第1章 ネットワークについて
リンクのコピー

OpenShift Container Platform において、回復性、安全性、スケーラビリティーの高いアプリケーションを構築するためには、ネートワークについて理解することが必要不可欠です。基本的な Pod 間通信から複雑なトラフィックルーティングやセキュリティールールまで、アプリケーションのあらゆるコンポーネントは、正常に機能するためにネットワークに依存しています。

1.1. コアネットワーク層とコンポーネント
リンクのコピー

Red Hat OpenShift Networking は、pod network と service network という基本的な 2 つの層の上に構築されます。Pod ネットワークは、アプリケーションが存在する場所です。サービスネットワークは、アプリケーションへのアクセスを確実なものにするために必要です。

1.1.1. Pod ネットワーク
リンクのコピー

Pod ネットワークは、クラスター内のすべての Pod が一意の IP アドレスを受け取るフラットなネットワーク領域です。このネットワークは、Container Network Interface (CNI) プラグインによって管理されます。CNI プラグインは、各 Pod をクラスターネットワークに接続する役割を担います。

この設計により、Pod はどのノードで実行されているかにかかわらず、IP アドレスを使用して互いに直接通信できるようになります。ただし、これらの Pod IP は一時的なものです。つまり、Pod が破棄されると IP も破棄され、新しい Pod の作成時に新しい IP アドレスが割り当てられます。そのため、長時間の通信では Pod の IP アドレスに直接依存しないでください。

1.1.2. サービスネットワーク
リンクのコピー

サービスは、ClusterIP と呼ばれる単一の安定した仮想 IP アドレスと、Pod の論理グループの DNS 名を提供するネットワークオブジェクトです。

リクエストがサービスの ClusterIP に送信されると、OpenShift Container Platform は、そのサービスをサポートする正常な Pod の 1 つにトラフィックを自動的に負荷分散します。そのとき、Kubernetes ラベルとセレクターを使用して、どの Pod がどのサービスに属しているかを追跡します。この抽象化により、Pod にアクセスしようとするアプリケーションに影響を与えることなく、個々の Pod を作成または破棄できるため、アプリケーションの耐障害性が向上します。

1.2. クラスター内のトラフィックの管理
リンクのコピー

アプリケーションはクラスター内で相互に通信する必要があります。OpenShift Container Platform は、内部トラフィックに対して、シンプルな交換のための Pod 間の直接通信と、信頼性の高い接続のための堅牢なサービス検出という、2 つの主要なメカニズムを提供します。

1.2.1. Pod 間通信
リンクのコピー

Pod は、Pod ネットワークによって割り当てられた一意の IP アドレスを使用して直接通信します。あるノード上の Pod は、ネットワークアドレス変換 (NAT) なしで、別のノード上の Pod にトラフィックを直接送信できます。この直接通信モデルは、データを迅速に交換する必要があるサービスにおいて効率的です。アプリケーションは、別の Pod の IP アドレスをターゲットにするだけで接続を確立できます。

1.2.2. DNS によるサービス検出
リンクのコピー

Pod の IP アドレスは一時的なものであるため、Pod は互いを見つけるための信頼できる方法を必要とします。OpenShift Container Platform は、組み込み DNS サーバーである CoreDNS を使用して、このサービス検出を提供します。

作成するすべてのサービスには、安定した DNS 名が自動的に割り当てられます。Pod はこの DNS 名を使用してサービスに接続できます。DNS システムは、名前をサービスの安定した ClusterIP アドレスに解決します。このプロセスにより、個々の Pod IP が変更された場合でも、信頼性の高い通信を確保できます。

1.3. クラスターに出入りするトラフィックの管理
リンクのコピー

外部ユーザーがアプリケーションにアクセスし、アプリケーションが外部サービスに安全にアクセスするための方法が必要です。OpenShift Container Platform は、クラスターに出入りするトラフィックフローを管理するためのツールをいくつか提供します。

1.3.1. Ingress および Route オブジェクトを使用してアプリケーションを公開する
リンクのコピー

外部トラフィックによるクラスター内のサービスへのアクセスを許可するためには、Ingress コントローラーを使用します。このコンポーネントは、受信したリクエストを適切なアプリケーションに転送する玄関口として機能します。トラフィックルールは、次の 2 つのプライマリーリソースのいずれかを使用して定義します。

  • Ingress: サービスへの外部アクセス (通常は HTTP および HTTPS トラフィック) を管理するための標準の Kubernetes リソース。
  • Route オブジェクト: Ingress と同じ機能を提供するリソースですが、より高度な TLS Termination オプションやトラフィック分割などの追加機能も含まれています。Route オブジェクトは OpenShift Container Platform に固有のものです。

1.3.2. ロードバランサーによるトラフィックの分散
リンクのコピー

ロードバランサーは、トラフィックをクラスターに誘導するための単一の高可用性 IP アドレスを提供します。これは通常、クラウドプロバイダー上のクラスターの外で実行されるか、ベアメタルインフラストラクチャー上の MetalLB を使用して実行され、Ingress コントローラーを実行している複数のノードに受信リクエストを分散します。

これにより、単一ノードがボトルネックや障害点になることを防ぎ、アプリケーションへのアクセスが維持されます。

1.3.3. Egress トラフィックの制御
リンクのコピー

Egress は、クラスター内の Pod から発信され、外部システムを宛先とする送信トラフィックを指します。OpenShift Container Platform は、これを管理するためのいくつかのメカニズムを提供します。

  • EgressIP: 特定のプロジェクトからのすべての送信トラフィックに、特定の予測可能な送信元 IP アドレスを割り当てることができます。これは、特定の送信元 IP を許可するように要求するファイアウォールを備えたデータベースなどの外部サービスにアクセスする必要がある場合に便利です。
  • Egress ルーター: 送信トラフィックのゲートウェイとして機能する専用の Pod です。単一の制御された出口ポイントを介して接続をルーティングできます。
  • Egress ファイアウォール: これは、すべての送信トラフィックに対するクラスターレベルのファイアウォールとして機能します。Pod から特定の外部宛先への接続を明示的に許可または拒否するルールを作成できため、セキュリティー体制が強化されます。

1.4. ネットワークトラフィックの保護
リンクのコピー

OpenShift Container Platform は、通信可能なコンポーネントを制御するルールを作成してネットワークを保護するツールを提供します。これは主に、ネットワークポリシーと管理ネットワークポリシーという 2 種類のポリシーリソースを通じて管理されます。

1.4.1. ネットワークポリシー
リンクのコピー

ネットワークポリシーは、IP アドレスまたはポートレベルでトラフィックフローを制御できるリソースです。これらのポリシーは、namespace (プロジェクト) レベルで動作します。つまり、通常は開発者またはプロジェクト管理者が特定のアプリケーションを保護するためにこれらを管理します。

デフォルトでは、プロジェクト内のすべての Pod は相互に自由に通信できます。しかし、NetworkPolicy を Pod に適用すると、"default-deny" スタンスが採用されます。これは、ポリシールールによって明示的に許可されていない接続がすべて拒否されることを意味します。ラベルとセレクターを使用して、ポリシーが適用される Pod と、許可される Ingress トラフィックおよび Egress トラフィックを定義します。

1.4.2. 管理ネットワークポリシー
リンクのコピー

AdminNetworkPolicy オブジェクトは、NetworkPolicy オブジェクトのより強力なバージョンで、クラスターをスコープとしています。クラスター管理者のみが作成および管理できます。

管理ネットワークポリシーは、標準の NetworkPolicy オブジェクトよりも優先されます。これにより、管理者は、ユーザーが自分のプロジェクトでオーバーライドできない、クラスター全体のセキュリティールールを適用できます。たとえば、管理者は AdminNetworkPolicy を使用して、開発 namespace と実稼働 namespace 間のすべてのトラフィックをブロックしたり、クラスター全体にベースラインセキュリティールールを適用したりできます。

第2章 ホストへのアクセス
リンクのコピー

OpenShift Container Platform インスタンスにアクセスして、セキュアシェル (SSH) アクセスでコントロールプレーンノードにアクセスするために bastion ホストを作成する方法を学びます。

2.1. installer-provisioned infrastructure クラスターでの Amazon Web Services のホストへのアクセス
リンクのコピー

OpenShift Container Platform インストーラーは、OpenShift Container Platform クラスターにプロビジョニングされる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパブリック IP アドレスを作成しません。OpenShift Container Platform ホストに対して SSH を実行できるようにするには、以下の手順を実行する必要があります。

手順

  1. openshift-install コマンドで作成される Virtual Private Cloud (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。
  2. インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。

  3. パブリック IP アドレスを、作成した Amazon EC2 インスタンスに関連付けます。

    OpenShift Container Platform のインストールとは異なり、作成した Amazon EC2 インスタンスを SSH キーペアに関連付ける必要があります。これにはインターネットを OpenShift Container Platform クラスターの VPC にブリッジ接続するための SSH bastion としてのみの単純な機能しかないため、このインスタンスにどのオペレーティングシステムを選択しても問題ありません。どの Amazon Machine Image (AMI) を使用するかは、注意が必要です。たとえば、Red Hat Enterprise Linux CoreOS (RHCOS) では、インストーラーと同様に Ignition 経由でキーを提供できます。

  4. Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。

    注記

    直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、権限付き Pod を代わりに実行します。

  5. oc get nodes を実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名は ip-10-0-1-163.ec2.internal に類似したものになります。

  6. Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。 

    $ ssh -i <ssh-key-path> core@<master-hostname>
    Copy to Clipboard Toggle word wrap

第3章 ネットワークダッシュボード
リンクのコピー

ネットワークメトリクスは、OpenShift Container Platform Web コンソール内のダッシュボードから、Observe → Dashboards で表示できます。

3.1. Network Observability Operator
リンクのコピー

Network Observability Operator がインストールされている場合は、Dashboards ドロップダウンリストから Netobserv ダッシュボードを選択すると、ネットワークトラフィックメトリクスダッシュボードが表示されます。この ダッシュボード で利用できるメトリクスの詳細は、ネットワーク可観測性メトリクスのダッシュボード を参照してください。

3.2. ネットワーキングと OVN-Kubernetes ダッシュボード
リンクのコピー

このダッシュボードからは、一般的なネットワークメトリクスと OVN-Kubernetes メトリクスの両方を表示できます。

一般的なネットワークメトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Linux Subsystem Stats を選択します。ダッシュボードから表示できるネットワークメトリクスは、Network Utilisation、Network Saturation、Network Errors です。

OVN-Kubernetes メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Infrastructure を選択します。表示できる OVN-Kuberenetes メトリクスは、Networking Configuration、TCP Latency Probes、Control Plane Resources、Worker Resources です。

3.3. Ingress Operator ダッシュボード
リンクのコピー

Ingress Operator によって処理されるネットワークメトリクスをダッシュボードから表示できます。これには、次のようなメトリクスが含まれます。

  • 受信および送信の帯域幅
  • HTTP エラーレート
  • HTTP サーバーの応答遅延

これらの Ingress メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Ingress を選択します。Top 10 Per Route、Top 10 Per Namespace、Top 10 Per Shard のカテゴリーの Ingress メトリクスを表示できます。

第4章 CIDR 範囲の定義
リンクのコピー

クラスターで OVN-Kubernetes を使用する場合は、Classless Inter-Domain Routing (CIDR) サブネット範囲に重複しない範囲を指定する必要があります。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして、IPv4 の場合は 169.254.0.0/17、IPv6 の場合は fd69::/112 を使用します。ユーザーはこれらの範囲を避ける必要があります。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

ヒント

クラスターの作成中に CIDR 範囲を設定する前に、Red Hat OpenShift Network Calculator を使用してネットワーク要件を判断できます。

calculator を使用するには、Red Hat アカウントが必要です。

OVN-Kubernetes を使用するクラスターでは、次のサブネットタイプが必須です。

  • Join: 結合スイッチを使用して、ゲートウェイルーターを分散ルーターに接続します。結合スイッチは、分散ルーターの IP アドレスの数を削減します。OVN-Kubernetes プラグインを使用するクラスターの場合、結合スイッチに接続されるすべての論理ポートに専用サブネットの IP アドレスが割り当てられます。
  • Masquerade: ロードバランサーがルーティングを決定した後、同じノードにヘアピントラフィックとして送信される同一の送信元および宛先 IP アドレスの競合を防止します。
  • Transit: トランジットスイッチは、クラスター内のすべてのノードにまたがる分散スイッチの一種です。トランジットスイッチは、異なるゾーン間でトラフィックをルーティングします。OVN-Kubernetes プラグインを使用するクラスターの場合、トランジットスイッチに接続するすべての論理ポートに専用サブネットの IP アドレスが割り当てられます。
注記

インストール後のタスクとして、クラスターの結合、マスカレード、およびトランジット CIDR 範囲を変更できます。

OpenShift Container Platform 4.14 以降のバージョンのデフォルトネットワークプロバイダーである OVN-Kubernetes は、内部的に次の IP アドレスサブネット範囲を使用します。

  • V4JoinSubnet: 100.64.0.0/16
  • V6JoinSubnet: fd98::/64
  • V4TransitSwitchSubnet: 100.88.0.0/16
  • V6TransitSwitchSubnet: fd97::/64
  • defaultV4MasqueradeSubnet: 169.254.0.0/17
  • defaultV6MasqueradeSubnet: fd69::/112
重要

以前のリストには、参加、トランジット、マスカレード IPv4 および IPv6 アドレスサブネットが含まれています。クラスターで OVN-Kubernetes を使用する場合は、クラスターまたはインフラストラクチャー内の他の CIDR 定義にこれらの IP アドレスサブネット範囲を含めないでください。

4.1. Machine CIDR
リンクのコピー

マシンの Classless Inter-Domain Routing (CIDR) フィールドでは、マシンまたはクラスターノードの IP アドレス範囲を指定する必要があります。

注記

クラスターを作成した後は、マシン CIDR 範囲を変更できません。

デフォルトは 10.0.0.0/16 です。この範囲は、接続されているネットワークと競合しないようにする必要があります。

4.2. Service CIDR
リンクのコピー

Service CIDR フィールドで、サービスの IP アドレス範囲を指定する必要があります。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16 です。

4.3. Pod CIDR
リンクのコピー

Pod CIDR フィールドで、Pod の IP アドレス範囲を指定する必要があります。

Pod CIDR は、clusterNetwork CIDR およびクラスター CIDR と同じです。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14 です。クラスターをインストールした後に、範囲を拡張できます。

4.4. Host prefix
リンクのコピー

hostPrefix パラメーターでは、個々のマシンにスケジュールされた Pod に割り当てられるサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。

例えば、ホスト接頭辞を /23 に設定した場合、各マシンには Pod CIDR アドレス範囲から /23 のサブネットが割り当てられます。デフォルトは /23 で、510 台のクラスターノードと、ノードごとに 510 個の Pod IP アドレスを許可します。

別の例として、clusterNetwork.cidr パラメーターを 10.128.0.0/16 に設定し、クラスターの完全なアドレス空間を定義することを考えてみましょう。これにより、65536 個の IP アドレスのプールがクラスターに割り当てられます。次に、hostPrefix パラメーターを /23 に設定すると、クラスター内の各ノードにサブネットスライスが定義され、/23 スライスが /16 サブネットネットワークのサブネットになります。これにより、各ノードに 512 個の IP アドレスが割り当てられ、そのうち 2 個の IP アドレスはネットワークとブロードキャストの目的で予約されます。次の計算例では、これらの IP アドレスの数値を使用して、クラスターに作成できるノードの最大数を決定します。 

65536 / 512 = 128
Copy to Clipboard Toggle word wrap

Red Hat OpenShift Network Calculator を使用して、クラスターの最大ノード数を計算できます。

4.5. Hosted Control Plane の CIDR 範囲
リンクのコピー

OpenShift Container Platform に Hosted Control Plane をデプロイするには、次の必須の Classless Inter-Domain Routing (CIDR) サブネット範囲を使用してください。

  • v4InternalSubnet: 100.65.0.0/16 (OVN-Kubernetes)
  • clusterNetwork: 10.132.0.0/14 (Pod ネットワーク)
  • serviceNetwork: 172.31.0.0/16

OpenShift Container Platform の CIDR 範囲の定義に関する詳細は、「CIDR 範囲の定義」を参照してください。

Legal Notice
リンクのコピー

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

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

会社概要

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

Theme

© 2025 Red Hat