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

ネットワークの概要

OpenShift Container Platform 4.20

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

概要

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

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

OpenShift Container Platform で堅牢かつ安全なアプリケーションを構築するには、クラスターのネットワークインフラストラクチャーを設定します。信頼性の高い Pod 間通信とトラフィックルーティングルールを定義することで、すべてのアプリケーションコンポーネントが環境内で正しく機能することが保証されます。

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

OpenShift Container Platform で回復力のあるアプリケーションを構築および公開するには、Pod およびサービスのネットワーク層を設定します。これらの基盤となるレイヤーを定義することで、アプリケーションのワークロードが安全な環境で実行され、他のサービスから確実にアクセスできるようになります。

Pod ネットワーク

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

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

サービスネットワーク

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

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

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

OpenShift Container Platform 内のアプリケーション間の信頼性の高い通信を確保するには、Pod 間トラフィックとサービス検出メカニズムを設定します。これらのメカニズムを実装することで、クラスターワークロードは直接接続または堅牢な検出ルールを通じて効率的にデータを交換できるようになります。

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

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

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

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

OpenShift Container Platform クラスターへの外部アクセスを有効にし、トラフィックフローを安全に管理するには、Ingress および Egress メカニズムを設定します。これらのトラフィックルールを設定することで、外部ユーザーがアプリケーションに確実にアクセスできると同時に、外部サービスとの安全な通信を維持できるようになります。

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

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

  • Ingress: サービスへの外部アクセス (通常は HTTP および HTTPS トラフィック) を管理するための標準の Kubernetes リソース。
  • Route オブジェクト: Ingress と同じ機能を提供するリソースですが、より高度な TLS Termination オプションやトラフィック分割などの追加機能も含まれています。Route オブジェクトは OpenShift Container Platform に固有のものです。
ロードバランサーによるトラフィックの分散
ロードバランサーは、トラフィックをクラスターに振り分けるための、可用性の高い単一の IP アドレスを提供します。ロードバランサーは通常、クラウドプロバイダー上のクラスターの外部で実行されるか、ベアメタルインフラストラクチャー上で MetalLB を使用して、Ingress コントローラーを実行している複数のノードに受信リクエストを分散させることができます。これにより、単一ノードがボトルネックや障害点になることを防ぎ、アプリケーションへのアクセスが維持されます。
Egress 交通の制御

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

  • EgressIP: 特定のプロジェクトからのすべての送信トラフィックに、特定の予測可能な送信元 IP アドレスを割り当てることができます。ファイアウォールで特定の送信元 IP アドレスのみを許可する必要があるデータベースなどの外部サービスにアクセスする必要がある場合は、この設定を検討してください。
  • Egress ルーター: 送信トラフィックのゲートウェイとして機能する専用の Pod です。エグレスルーターを使用することで、接続を単一の制御された出口ポイント経由でルーティングできます。
  • Egress ファイアウォール: これは、すべての送信トラフィックに対するクラスターレベルのファイアウォールとして機能します。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) トラフィックの入り口が提供され、リモート管理を可能にしながらクラスターのセキュリティーが確保されます。

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

パブリック IP アドレスを持たない Amazon EC2 インスタンス上の OpenShift Container Platform ホストへの Secure Shell (SSH) アクセスを確立するには、踏み台ホストまたはセキュアゲートウェイを設定します。このアクセスパスを定義することで、インストーラーがプロビジョニングした環境内で、プライベートインフラストラクチャーを安全に管理およびトラブルシューティングできるようになります。

手順

  1. openshift-install コマンドラインインターフェイスによって作成される仮想プライベートクラウド (VPC) への SSH アクセスを許可するセキュリティーグループを作成します。
  2. インストールプログラムが作成したパブリックサブネットのいずれかに、Amazon EC2 インスタンスを作成します。

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

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

  4. Amazon EC2 インスタンスをプロビジョニングし、インスタンスに SSH 接続できるようになったら、OpenShift Container Platform のインストールに関連付けた SSH 鍵を追加します。このキーは、踏み台インスタンスのキーとは異なっていても構いませんが、これは厳密な要件ではありません。

    注記

    障害復旧時のみ、直接 SSH アクセスを使用してください。Kubernetes API が応答する場合、権限付き Pod を代わりに実行します。

  5. oc get nodes コマンドを実行し、出力結果を調べて、コントロールプレーンであるノードを 1 つ選択します。ホスト名は ip-10-0-1-163.ec2.internal に類似したものになります。

  6. Amazon EC2 に手動でデプロイした踏み台 SSH ホストから、次のコマンドを入力してそのコントロールプレーンホストに SSH 接続します。インストール時に指定した SSH 鍵と同じものを使用していることを確認してください。 

    $ ssh -i <ssh-key-path> core@<control_plane_hostname>

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

クラスター内のネットワークパフォーマンスを監視および分析するには、OpenShift Container Platform の Web コンソールでネットワークメトリクスを表示します。監視 → ダッシュボード からこれらのダッシュボードにアクセスすることで、トラフィックパターンを特定し、接続の問題をトラブルシューティングして、ワークロードの可用性を安定的に確保できます。

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

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

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

OVN-Kubernetes メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Infrastructure を選択します。OVN-Kubernetes では、ネットワーク設定、TCP レイテンシープローブ、コントロールプレーンリソース、ワーカーリソース といったメトリクスを表示できます。

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 を使用する OpenShift Container Platform クラスターで、安定した正確なネットワークルーティングを確保するには、重複しない Classless Inter-Domain Routing (CIDR) サブネット範囲を定義します。固有の IP アドレス範囲を設定することで、IP アドレスの競合を防ぎ、内部トラフィックが妨害されることなく目的の宛先に到達できるようになります。

重要

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
リンクのコピー

OpenShift Container Platform のクラスターノードのネットワーク範囲を設定するには、マシン Classless Inter-Domain Routing (CIDR) パラメーターに IP アドレス範囲を指定します。この範囲を定義することで、環境内のすべてのマシンが、内部クラスター通信のために有効でルーティング可能なアドレスを持つことが保証されます。

注記

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

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

4.2. Service CIDR
リンクのコピー

OpenShift Container Platform でクラスターサービスに IP アドレスを割り当てるには、サービス Classless Inter-Domain Routing (CIDR) パラメーターで IP アドレス範囲を指定します。この範囲を定義することで、内部サービスがノードや Pod のネットワークと重複することなく、信頼性の高い通信を行うための専用のアドレスブロックを確保できます。

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

4.3. Pod CIDR
リンクのコピー

OpenShift Container Platform のクラスターワークロードに内部ネットワークアドレスを割り当てるには、Pod の Classless Inter-Domain Routing (CIDR) フィールドに IP アドレス範囲を指定します。この範囲を定義することで、Pod 同士がノードやサービスネットワークと重複することなく、確実に通信できるようになります。

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

4.4. Host prefix
リンクのコピー

OpenShift Container Platform の各ノード上の Pod に専用の IP アドレスプールを割り当てるには、hostPrefix パラメーターでサブネットプレフィックスの長さを指定します。適切なプレフィックスを定義することで、各マシンがクラスターのネットワークリソースを枯渇させることなく、スケジュールされたワークロードをサポートするのに十分な一意のアドレスを確保できます。

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

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

65536 / 512 = 128

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

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

OpenShift Container Platform 上に Hosted Control Plane を正常にデプロイするには、特定の Classless Inter-Domain Routing (CIDR) サブネット範囲を使用してネットワーク環境を定義します。これらの重複しない範囲を設定することで、クラスターコンポーネント間の信頼性の高い通信が確保され、内部 IP アドレスの競合が防止されます。

以下の Classless Inter-Domain Routing (CIDR) サブネット範囲は、Hosted Control Plane のデフォルト設定です。

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

デフォルトのサブネット範囲のいずれかを使用することで、管理クラスターとの CIDR の重複を回避し、接続の問題を防ぐことができます。ただし、管理クラスターと重複しない限り、他の CIDR サブネット範囲を使用することもできます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る