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

ネットワークの概要

OpenShift Container Platform 4.21

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

概要

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

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

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

次の図は、Amazon Web Services (AWS) の外部クライアントがクラスター内の Pod に接続する際の、ネットワークコンポーネント間の外部および内部ネットワークトラフィックの流れを示しています。

図1.1 ネットワークコンポーネント間のトラフィックフローを示す図

ネットワークコンポーネント間のトラフィックフローを示す図

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

Red Hat OpenShift Networking は、Pod ネットワークとサービスネットワークという 2 つの基本的なレイヤーに基づいて構築されています。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 は、内部トラフィックを処理するために使用できる 2 つの主要なメカニズムを提供します。1 つは、シンプルな情報交換のための Pod 間の直接通信、もう 1 つは、信頼性の高い接続のための堅牢なサービスディスカバリーです。

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 および 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 のホストへのアクセス
リンクのコピー

OpenShift Container Platform インストーラーは、OpenShift Container Platform クラスターにプロビジョニングされる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパブリック IP アドレスを作成しません。Amazon EC2 インスタンスをプロビジョニングした後、SSH を使用して OpenShift Container Platform ホストにアクセスできます。

手順

  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 を使用する場合は、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. サービス Classless Inter-Domain Routing (CIDR)
リンクのコピー

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

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

4.3. Pod の Classless Inter-Domain Routing (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 に設定し、クラスターの完全なアドレス空間を定義することを考えてみましょう。これにより、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) サブネット範囲を使用してネットワーク環境を定義します。

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る