ネットワークの概要
OpenShift Container Platform の基本的なネットワーク概念と一般的なタスクを理解する
概要
第1章 ネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のネットワークの基礎を理解することで、クラスター内での効率的で安全な通信が確保されます。これは、効果的なネットワーク管理に不可欠です。環境内のネットワークに関する重要な要素には、Pod とサービスの通信方法、IP アドレスのロール、サービスディスカバリーのための DNS の使用などがあります。
1.1. OpenShift Container Platform のネットワーク リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、クラスター内のさまざまなコンポーネント間、および外部クライアントとクラスター間のシームレスな通信が確保されます。ネットワークは、次のコア概念とコンポーネントに依存します。
- Pod 間通信
- サービス
- DNS
- Ingress
- ネットワーク制御
- 負荷分散
1.1.1. ネットワークサービスの一般的な慣行 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、複数の Pod がサービスを提供している場合でも、サービスはクライアントが使用するための IP アドレスを 1 つ作成します。この抽象化により、クライアントに影響を与えることなく、シームレスなスケーリング、フォールトトレランス、ローリングアップグレードが可能になります。
ネットワークセキュリティーポリシーは、クラスター内のトラフィックを管理します。ネットワーク制御を行うことで、namespace 管理者は Pod の Ingress ルールと Egress ルールを定義できます。ネットワーク管理ポリシーを使用すると、クラスター管理者は namespace ポリシーを設定したり、namespace ポリシーをオーバーライドしたり、定義されていない場合にデフォルトのポリシーを設定したりできます。
Egress ファイアウォール設定は、Pod からの送信トラフィックを制御します。これらの設定により、許可された通信のみが実行されます。Ingress ノードファイアウォールは、着信トラフィックを制御することでノードを保護します。さらに、Universal Data Network はクラスター全体のデータトラフィックを管理します。
1.1.2. ネットワーク機能 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、いくつかのネットワーク機能と拡張機能を提供します。以下に、これらの機能と拡張機能をリストします。
- Ingress Operator と Route API: OpenShift Container Platform には、Ingress Controller API を実装する Ingress Operator が含まれています。このコンポーネントは、高度なルーティング設定と負荷分散をサポートする HAProxy ベースの Ingress Controller をデプロイおよび管理することで、クラスターサービスへの外部アクセスを可能にします。OpenShift Container Platform は、Route API を使用して、アップストリーム Ingress オブジェクトをルートオブジェクトに変換します。Route は OpenShift Container Platform のネットワーク固有のものですが、サードパーティーの Ingress Controller を使用することもできます。
セキュリティーの強化: OpenShift Container Platform は、Egress ファイアウォールや Ingress ノードファイアウォールなどの高度なネットワークセキュリティー機能を提供します。
- Egress ファイアウォール: Egress ファイアウォールは、クラスター内の Pod からの送信トラフィックを制御および制限します。Pod が通信できる外部ホストまたは IP 範囲を制限するルールを設定できます。
Ingress ノードファイアウォール: Ingress ノードファイアウォールは、Ingress Firewall Operator によって管理され、ノードレベルのファイアウォールルールを提供します。クラスター内の特定のノードにこのファイアウォールを設定して、着信トラフィックがこれらのノードに到達する前にフィルタリングすることで、ノードを脅威から保護できます。
注記OpenShift Container Platform は、Pod 間の通信を保護し、アクセス制御を適用するためのネットワークポリシー、管理ネットワークポリシー、Security Context Constraints (SCC) などのサービスも実装します。
- ロールベースのアクセス制御 (RBAC): OpenShift Container Platform は Kubernetes RBAC を拡張して、ネットワークリソースにアクセスして管理できるユーザーをより細かく制御できるようにします。RBAC は、クラスター内のセキュリティーとコンプライアンスの維持に役立ちます。
- マルチテナンシーサポート: OpenShift Container Platform は、複数のユーザーとチームがリソースを分離して安全に保ちながら同じクラスターを共有できるようにするマルチテナンシーサポートを提供します。
- ハイブリッドおよびマルチクラウド機能: OpenShift Container Platform は、オンプレミス環境、クラウド環境、マルチクラウド環境をまたいでシームレスに動作するように設計されています。この柔軟性により、組織はコンテナー化されたアプリケーションを、さまざまなインフラストラクチャーをまたいでデプロイおよび管理できます。
- 可観測性と監視: OpenShift Container Platform は、ネットワークの問題の管理とトラブルシューティングに役立つ、統合された可観測性および監視ツールを提供します。これらのツールには、ネットワークメトリクスとログへのロールベースのアクセスが含まれます。
- ユーザー定義ネットワーク (UDN): 管理者は、UDN を使用してネットワーク設定をカスタマイズできます。UDN は、ネットワーク分離と IP アドレス管理を強化します。
- Egress IP: Egress IP を使用すると、namespace 内の Pod から送信されるすべての Egress トラフィックに固定の送信元 IP アドレスを割り当てることができます。Egress IP は、外部サービスのソース IP アドレスの一貫性を確保することで、セキュリティーとアクセス制御を強化できます。たとえば、Pod が特定の IP アドレスからのトラフィックのみを許可する外部データベースにアクセスする必要がある場合、その Pod の Egress IP を設定してアクセス要件を満たすことができます。
- Egress ルーター: Egress ルーターは、クラスターと外部システム間のブリッジとして機能する Pod です。Egress ルーターを使用すると、Pod からのトラフィックを、他の目的で使用されていない特定の IP アドレス経由でルーティングできます。Egress ルーターを使用すると、アクセス制御を適用したり、特定のゲートウェイを経由してトラフィックをルーティングしたりできます。
1.2. ノード、クライアント、クラスターとのネットワーク リンクのコピーリンクがクリップボードにコピーされました!
ノードは、コントロールプレーンコンポーネント、ワークロードコンポーネント、またはその両方を実行できるクラスター内のマシンです。ノードは、物理サーバーまたは仮想マシンのいずれかです。クラスターは、コンテナー化されたアプリケーションを実行するノードのコレクションです。クライアントは、クラスターと対話するツールおよびユーザーです。
1.2.1. ノードとは リンクのコピーリンクがクリップボードにコピーされました!
ノードは、コンテナー化されたアプリケーションを実行する物理マシンまたは仮想マシンです。ノードは Pod をホストし、アプリケーションを実行するためのメモリーやストレージなどのリソースを提供します。ノードは Pod 間の通信を可能にします。各 Pod には IP アドレスが割り当てられます。同じノード内の Pod は、IP アドレスを使用して相互に通信できます。ノードは、Pod がクラスター内のサービスを検出して通信できるようにすることで、サービスディスカバリーを容易にします。ノードは、ネットワークトラフィックを Pod 間で分散し、効率的な負荷分散とアプリケーションの高可用性を確保するのに役立ちます。ノードは、内部クラスターネットワークと外部ネットワーク間のブリッジを提供し、外部クライアントがクラスター上で実行されているサービスにアクセスできるようにします。
1.2.2. クラスターとは リンクのコピーリンクがクリップボードにコピーされました!
クラスターは、コンテナー化されたアプリケーションを実行するために連携して動作するノードのコレクションです。ノードには、コントロールプレーンノードとコンピュートノードが含まれます。
1.2.3. 外部クライアントとは リンクのコピーリンクがクリップボードにコピーされました!
外部クライアントとは、クラスター内で実行されているサービスやアプリケーションと対話するクラスター外のエンティティーです。外部には、エンドユーザー、外部サービス、外部デバイスが含まれます。エンドユーザーとは、ブラウザーやモバイルデバイスを通じて、クラスター内でホストされている Web アプリケーションにアクセスするユーザーです。外部サービスとは、クラスター内のサービスと (多くの場合は API を介して) 対話する他のソフトウェアシステムまたはアプリケーションです。外部デバイスとは、Internet of Things (IoT) デバイスなど、クラスターサービスと通信する必要があるクラスターネットワーク外のハードウェアです。
1.3. ネットワークの概念とコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のネットワークでは、いくつかの主要なコンポーネントと概念が使用されます。
- Pod とサービスは Kubernetes でデプロイ可能な最小単位であり、サービスは Pod セットに安定した IP アドレスと DNS 名を提供します。クラスター内の各 Pod には、一意の IP アドレスが割り当てられます。Pod は、どのノード上にあるかに関係なく、IP アドレスを使用して他の Pod と直接通信します。Pod が破棄および作成されると、Pod の IP アドレスは変更されます。サービスには、一意の IP アドレスも割り当てられます。サービスは、サービスを提供できる Pod に関連付けられます。アクセスされると、サービス IP アドレスは、サービスをサポートする Pod の 1 つにトラフィックを送信することで、Pod に安定してアクセスする方法を提供します。
- Route API と Ingress API は、クラスター内のサービスに HTTP、HTTPS、および TLS トラフィックをルーティングするルールを定義します。OpenShift Container Platform は、デフォルトのインストールの一部として Route API と Ingress API の両方を提供しますが、サードパーティーの Ingress Controller をクラスターに追加することもできます。
- Container Network Interface (CNI) プラグインは、Pod ネットワークを管理して、Pod 間の通信を可能にします。
- Cluster Network Operator (CNO) CNO は、クラスターのネットワークプラグインコンポーネントを管理します。CNO を使用すると、Pod ネットワーク CIDR やサービスネットワーク CIDR などのネットワーク構成を設定できます。
- DNS Operator は、クラスター内の DNS サービスを管理して、DNS 名で確実にサービスにアクセスできるようにします。
- ネットワーク制御は、Pod 間、および Pod と他のネットワークエンドポイント間で許可される通信方法を定義します。これらのポリシーは、トラフィックフローを制御し、Pod 通信のルールを適用することで、クラスターを保護するために役立ちます。
- 負荷分散は、ネットワークトラフィックを複数のサーバーに分散し、信頼性とパフォーマンスを確保します。
- サービスディスカバリーは、クラスター内でサービスが相互に検出して通信するためのメカニズムです。
- Ingress Operator は、OpenShift Container Platform Route を使用してルーターを管理し、クラスターサービスへの外部アクセスを有効にします。
1.4. Pod の通信方法 リンクのコピーリンクがクリップボードにコピーされました!
Pod は、IP アドレスを使用して通信し、Dynamic Name System (DNS) を使用して Pod またはサービスの IP アドレスを検出します。クラスターは、どの通信を許可するかを制御するさまざまなポリシータイプを使用します。Pod は、Pod 間およびサービスと Pod 間の 2 つの方法で通信します。
1.4.1. Pod 間通信 リンクのコピーリンクがクリップボードにコピーされました!
Pod 間通信とは、クラスター内で Pod が相互に通信する機能です。これは、マイクロサービスと分散アプリケーションが動作するために不可欠な機能です。
クラスター内の各 Pod には、他の Pod と直接通信するために使用する一意の IP アドレスが割り当てられます。Pod 間通信は、Pod がデータを交換したり、共同でタスクを実行したりする必要があるクラスター内通信に役立ちます。たとえば、Pod A は Pod B の IP アドレスを使用して Pod B に要求を直接送信できます。Pod は、ネットワークアドレス変換 (NAT) なしでフラットネットワーク経由で通信できます。これにより、ノードをまたいだ Pod 間のシームレスな通信が可能になります。
1.4.1.1. 例: Pod 間通信の制御 リンクのコピーリンクがクリップボードにコピーされました!
複数の Pod を持つマイクロサービスベースのアプリケーションでは、フロントエンド Pod はバックエンド Pod と通信してデータを取得する必要があります。直接またはサービスを介して Pod 間通信を使用することで、これらの Pod は効率的に情報を交換できます。
Pod 間の通信を制御し、保護するために、ネットワーク制御を定義できます。そのような制御は、Pod が相互に対話する方法をラベルおよびセレクターに基づき指定することで、セキュリティーとコンプライアンスの要件を適用します。
1.4.2. サービスと Pod 間の通信 リンクのコピーリンクがクリップボードにコピーされました!
サービスと Pod 間の通信により、サービスがトラフィックを適切な Pod に確実にルーティングできるようになります。サービスは、Pod の論理セットを定義し、IP アドレスや DNS 名などの安定したエンドポイントを提供するオブジェクトです。Pod の IP アドレスは変更される可能性があります。サービスは Pod の IP アドレスを抽象化して、IP アドレスが変更された場合でもアプリケーションコンポーネントに一貫してアクセスできるようにします。
サービスと Pod 間の通信の主な概念は次のとおりです。
- エンドポイント: エンドポイントは、サービスに関連付けられている Pod の IP アドレスとポートを定義します。
- セレクター: セレクターは、キーと値のペアなどのラベルを使用して、サービスがターゲットとするオブジェクトセットを選択するための条件を定義します。
- サービス: サービスは、Pod セットに対して安定した IP アドレスと DNS 名を提供します。この抽象化により、他のコンポーネントは個々の Pod ではなくサービスと通信できるようになります。
- サービスディスカバリー: DNS によりサービスが検出可能になります。サービスが作成されると、DNS 名が割り当てられます。他の Pod はこの DNS 名を検出し、それを使用してサービスと通信します。
サービスタイプ: サービスタイプは、クラスター内外でサービスがどのように公開されるかを制御します。
- ClusterIP は、内部クラスター IP 上でサービスを公開します。これはデフォルトのサービスタイプであり、クラスター内からのみサービスにアクセスできるようになります。
- NodePort は、各ノードの IP のサービスを静的ポートで公開することにより、外部トラフィックがサービスにアクセスできるようにします。
- LoadBalancer は、クラウドプロバイダーのロードバランサーを使用してサービスを外部に公開します。
サービスはセレクターを使用して、トラフィックを受信する Pod を識別します。セレクターは Pod のラベルを照合して、どの Pod がサービスの一部であるかを決定します。例: セレクター app: myapp
を持つサービスは、ラベル app: myapp
を持つすべての Pod にトラフィックをルーティングします。
エンドポイントは、サービスセレクターに一致する Pod の現行 IP アドレスを反映するように動的に更新されます。{product-name} はこれらのエンドポイントを維持し、サービスがトラフィックを正しい Pod にルーティングするようにします。
通信フローとは、Kubernetes のサービスがトラフィックを適切な Pod にルーティングするときに発生する一連の手順とインタラクションを指します。サービスと Pod 間の通信の一般的な通信フローは次のとおりです。
サービスの作成: サービスの作成時に、サービスタイプ、サービスがリッスンするポート、およびセレクターラベルを定義します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
DNS 解決: 各 Pod には、他の Pod がサービスと通信するために使用できる DNS 名があります。たとえば、
my-app
namespace 内のmy-service
という名前のサービスの DNS 名はmy-service.my-app.svc.cluster.local
になります。 - トラフィックルーティング: Pod がサービスの DNS 名に要求を送信すると、OpenShift Container Platform はその名前をサービスの ClusterIP に解決します。次に、サービスはエンドポイントを使用して、セレクターに一致する Pod の 1 つにトラフィックをルーティングします。
- 負荷分散: サービスは基本的な負荷分散も提供します。着信トラフィックを、セレクターに一致するすべての Pod に分散します。これにより、1 つの Pod にトラフィックが過剰に集中して負荷がかかることがなくなります。
1.4.2.1. 例: サービスと Pod 間の通信を制御する リンクのコピーリンクがクリップボードにコピーされました!
クラスターは、フロントエンドおよびバックエンドの 2 つのコンポーネントを持つマイクロサービスベースのアプリケーションを実行しています。フロントエンドは、データを取得するためにバックエンドと通信する必要があります。
手順
バックエンドサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow バックエンド Pod を設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow フロントエンド通信を確立します。
これでフロントエンド Pod は、DNS 名
backend.default.svc.cluster.local
を使用してバックエンドサービスと通信できるようになりました。このサービスは、トラフィックが確実にバックエンド Pod の 1 つにルーティングされるようにします。
サービスと Pod 間の通信により、Pod IP の管理の複雑さが抽象化され、クラスター内で信頼性が高く効率的な通信が確保されます。
1.5. サポートされているロードバランサー リンクのコピーリンクがクリップボードにコピーされました!
負荷分散は、着信ネットワークトラフィックを複数のサーバーに分散し、1 つのサーバーに過度の負荷がかからないようにすることで、クラスターの健全性と効率を保ちます。ロードバランサーは負荷分散を実行するデバイスです。クライアントとサーバーの間の仲介として機能し、事前に定義されたルールに基づきトラフィックを管理および誘導します。
OpenShift Container Platform は、次のタイプのロードバランサーをサポートします。
- Classic Load Balancer (CLB)
- Elastic Load Balancing (ELB)
- Network Load Balancer (NLB)
- Application Load Balancer (ALB)
ELB は、AWS ルーターのデフォルトのロードバランサータイプです。CLB は、セルフマネージド環境のデフォルトです。NLB は、Red Hat OpenShift Service on AWS (ROSA) のデフォルトです。
ALB は、アプリケーションの前で使用しますが、ルーターの前では使用しないでください。ALB を使用するには、AWS Load Balancer Operator アドオンが必要です。この Operator は、すべての Amazon Web Services (AWS) リージョンまたはすべての OpenShift Container Platform プロファイルでサポートされているわけではありません。
1.5.1. ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール時に、デフォルトのロードバランサータイプを定義できます。インストール後、クラスターのインストール時に定義したグローバルプラットフォーム設定でカバーされていない特定の方法で動作するように、Ingress Controller を設定できます。
1.5.1.1. デフォルトのロードバランサータイプを定義する リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール時に、使用するロードバランサーのタイプを指定できます。クラスターのインストール時に選択したロードバランサーのタイプは、クラスター全体に適用されます。
この例では、AWS 上にデプロイされたクラスターのデフォルトのロードバランサータイプを定義する方法を示します。この手順は、サポートされている他のプラットフォームにも適用できます。
1.5.1.2. Ingress Controller のロードバランサーの動作を指定する リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールした後、Ingress Controller を設定して、サービスを外部ネットワークに公開する方法を指定できます。これにより、ロードバランサーの設定と動作をより適切に制御できるようになります。
Ingress Controller のロードバランサー設定を変更すると、インストール時に指定したロードバランサー設定がオーバーライドされる可能性があります。
1.6. Domain Name System (DNS) リンクのコピーリンクがクリップボードにコピーされました!
Domain Name System (DNS) は、www.example.com などの人間が理解しやすいドメイン名を、ネットワーク上のコンピューターを識別する IP アドレスに変換するために使用される、階層型かつ分散型の命名システムです。DNS は、サービスディスカバリーと名前解決において重要な役割を果たします。
OpenShift Container Platform は、確実に DNS 名でサービスにアクセスできるようにするため、組み込みの DNS を提供しています。これにより、基盤となる IP アドレスが変更された場合でも、安定した通信を維持できます。Pod を起動すると、サービス名、IP アドレス、ポートの環境変数が自動的に作成され、Pod は他のサービスと通信できるようになります。
1.6.1. 重要な DNS 用語 リンクのコピーリンクがクリップボードにコピーされました!
- CoreDNS: CoreDNS は DNS サーバーであり、サービスと Pod の名前解決を提供します。
-
DNS 名: サービスには、namespace と名前に基づいて DNS 名が割り当てられます。たとえば、
default
namespace にあるmy-service
という名前のサービスの DNS 名はmy-service.default.svc.cluster.local
になります。 -
ドメイン名: ドメイン名は、
example.com
など、Web サイトやサービスにアクセスするために使用されるわかりやすい名前です。 -
IP アドレス: IP アドレスは、通信に IP を使用するコンピューターネットワークに接続された各デバイスに割り当てられる数値ラベルです。IPv4 アドレスの例は
192.0.2.1
です。IPv6 アドレスの例は2001:0db8:85a3:0000:0000:8a2e:0370:7334
です。 - DNS サーバー: DNS サーバーは、DNS レコードの保存に特化されたサーバーです。これらのレコードは、ドメイン名を IP アドレスにマッピングします。ブラウザーにドメイン名を入力すると、コンピューターは DNS サーバーに接続して対応する IP アドレスを見つけます。
-
解決プロセス: DNS クエリーが DNS リゾルバーに送信されます。次に、DNS リゾルバーは一連の DNS サーバーに接続して、ドメイン名に関連付けられた IP アドレスを見つけます。リゾルバーは、
<namespace>.svc.cluster.local
、svc.cluster.local
、cluster.local
などの一連のドメインで、名前の使用を試みます。このプロセスは、最初に一致した時点で停止します。IP アドレスはブラウザーに返され、その IP アドレスを使用して Web サーバーに接続します。
1.6.2. 例: DNS のユースケース リンクのコピーリンクがクリップボードにコピーされました!
この例では、フロントエンドアプリケーションが 1 つの Pod セットで実行され、バックエンドサービスが別の Pod セットで実行されています。フロントエンドアプリケーションは、バックエンドサービスと通信する必要があります。バックエンド Pod に安定した IP アドレスと DNS 名を付与するサービスを作成します。フロントエンド Pod は、個々の Pod IP アドレスが変更されても、この DNS 名を使用してバックエンドサービスにアクセスします。
バックエンド Pod 用のサービスを作成することにより、フロントエンド Pod がバックエンドサービスと通信するために使用できる、安定した IP と DNS 名 (backend-service.default.svc.cluster.local
) が提供されます。この設定により、個々の Pod の IP アドレスが変更された場合でも、通信の一貫性と信頼性が維持されます。
次の手順は、DNS を使用してバックエンドサービスと通信するように、フロントエンド Pod を設定する方法の例を示しています。
バックエンドサービスを作成します。
バックエンド Pod をデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow バックエンド Pod を公開するサービスを定義します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
フロントエンド Pod を作成します。
フロントエンド Pod を定義します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod 定義をクラスターに適用します。
oc apply -f frontend-deployment.yaml
$ oc apply -f frontend-deployment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
フロントエンドをバックエンドと通信するように設定します。
フロントエンドアプリケーションコードでは、バックエンドサービスの DNS 名を使用して要求を送信します。たとえば、フロントエンドアプリケーションがバックエンド Pod からデータを取得する必要がある場合、アプリケーションには次のコードが含まれる可能性があります。
fetch('http://backend-service.default.svc.cluster.local/api/data') .then(response => response.json()) .then(data => console.log(data));
fetch('http://backend-service.default.svc.cluster.local/api/data') .then(response => response.json()) .then(data => console.log(data));
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7. ネットワーク制御 リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク制御は、Pod 間および Pod と他のネットワークエンドポイント間の通信を許可するためのルールを定義します。ネットワーク制御はネットワークレベルで実装され、許可されたトラフィックのみが Pod 間で流れるようにします。これにより、トラフィックフローを制限し、不正アクセスを防止することで、クラスターが保護されます。
- 管理ネットワークポリシー (ANP): ANP は、クラスターをスコープ指定したカスタムリソース定義 (CRD) です。クラスター管理者は、ANP を使用してクラスターレベルでネットワークポリシーを定義できます。通常のネットワークポリシーオブジェクトを使用してこれらのポリシーをオーバーライドすることはできません。これらのポリシーは、クラスター全体に厳格なネットワークセキュリティールールを適用します。管理者は、ANP で Ingress ルールと Egress ルールを指定して、クラスターに出入りするトラフィックを制御できます。
- Egress ファイアウォール: Egress ファイアウォールは、クラスターから出る Egress トラフィックを制限します。管理者は、このファイアウォールを使用して、クラスター内から Pod がアクセスできる外部ホストを制限できます。Egress ファイアウォールポリシーを設定して、特定の IP 範囲、DNS 名、または外部サービスへのトラフィックを許可または拒否できます。これにより、外部リソースへの不正アクセスを防ぎ、許可されたトラフィックのみがクラスターから出るようにできます。
- Ingress ノードファイアウォール: Ingress ノードファイアウォールは、クラスター内のノードへの Ingress トラフィックを制御します。管理者は、このファイアウォールを使用して、ノードへの接続を開始できる外部ホストを制限するルールを定義します。これにより、不正アクセスからノードを保護し、信頼できるトラフィックのみがクラスターに到達できるようになります。
1.8. ルートと Ingress リンクのコピーリンクがクリップボードにコピーされました!
ルートおよび Ingress は、どちらもアプリケーションを外部トラフィックに公開するために使用されます。ただし、その目的は若干異なり、機能も異なります。
1.8.1. ルート リンクのコピーリンクがクリップボードにコピーされました!
ルートは、外部クライアントが名前でサービスにアクセスできるように、ホスト名でサービスを公開する OpenShift Container Platform リソースに固有のものです。
ルートは、ホスト名をサービスにマッピングします。ルート名のマッピングにより、外部クライアントはホスト名を使用してサービスにアクセスできます。ルートは、サービスに向けられたトラフィックの負荷分散を行います。ルートで使用されるホスト名は、ルーターの IP アドレスに解決されます。その後、ルートはトラフィックを適切なサービスに転送します。ルートは、SSL/TLS を使用してクライアントとサービス間のトラフィックを暗号化することで保護することもできます。
1.8.2. Ingress リンクのコピーリンクがクリップボードにコピーされました!
Ingress は、負荷分散、SSL/TLS Termination、名前ベースの仮想ホスティングなどの高度なルーティング機能を提供するリソースです。Ingress に関する重要なポイントは次のとおりです。
- HTTP/HTTPS ルーティング: Ingress を使用して、クラスター内のサービスに HTTP および HTTPS トラフィックをルーティングするためのルールを定義できます。
- 負荷分散: NGINX や HAProxy などの Ingress Controller は、ユーザーが定義したルールに基づいてトラフィックルーティングと負荷分散を管理します。
- SSL/TLS Termination: SSL/TLS Termination は、着信 SSL/TLS トラフィックをバックエンドサービスに渡す前に復号するプロセスです。
- 複数のドメインとパス: Ingress は、複数のドメインとパスのトラフィックルーティングをサポートします。
1.8.3. ルートと Ingress の比較 リンクのコピーリンクがクリップボードにコピーされました!
ルートは、Ingress に比べて柔軟性が高く、高度な機能を提供します。そのため、ルートは複雑なルーティングシナリオに適しています。ルートは、特に基本的な外部アクセスのニーズの場合、簡単に設定および使用できます。Ingress は、よりシンプルで直接的な外部アクセスによく使用されます。ルートは、高度なルーティングと SSL/TLS Termination を必要とするより複雑なシナリオに使用されます。
1.8.4. 例: ウェブアプリケーションを公開するためのルートと Ingress の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスター上で Web アプリケーションが実行されています。外部ユーザーがアプリケーションにアクセスできるようにしたいと考えています。アプリケーションは特定のドメイン名を通じてアクセスできる必要があり、トラフィックは TLS を使用して安全に暗号化される必要があります。次の例は、ルートと Ingress の両方を設定して、Web アプリケーションを外部トラフィックに安全に公開する方法を示しています。
1.8.4.1. ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
新しいプロジェクトを作成する。
oc new-project webapp-project
$ oc new-project webapp-project
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web アプリケーションをデプロイします。
oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートを使用してサービスを公開します。
oc expose svc/webapp --hostname=webapp.example.com
$ oc expose svc/webapp --hostname=webapp.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS を使用してルートを保護します。
証明書と鍵を使用して TLS シークレットを作成します。
oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key
$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS シークレットを使用するようにルートを更新します。
oc patch route/webapp -p '{"spec":{"tls":{"termination":"edge","certificate":"path/to/tls.crt","key":"path/to/tls.key"}}}'
$ oc patch route/webapp -p '{"spec":{"tls":{"termination":"edge","certificate":"path/to/tls.crt","key":"path/to/tls.key"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.8.4.2. Ingress の設定 リンクのコピーリンクがクリップボードにコピーされました!
Ingress リソースを作成します。
Ingress Controller がクラスターにインストールされ、実行されていることを確認します。
Web アプリケーション用のサービスを作成します。まだ作成されていない場合は、アプリケーションをサービスとして公開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress リソースを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS を使用して Ingress を保護します。
証明書と鍵を使用して TLS シークレットを作成します。
oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n webapp-project
$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n webapp-project
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS シークレットを使用するように Ingress リソースを更新します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9. セキュリティーとトラフィック管理 リンクのコピーリンクがクリップボードにコピーされました!
管理者は、ClusterIP
、NodePort
、LoadBalaner
などのサービスタイプと、Ingress
や Route
などの API リソースを使用して、アプリケーションを外部トラフィックに公開し、ネットワーク接続を保護できます。Ingress Operator と Cluster Network Operator (CNO) は、これらのサービスとリソースの設定と管理に役立ちます。Ingress Operator は、1 つ以上の Ingress Controller をデプロイおよび管理します。これらのコントローラーは、外部の HTTP および HTTPS トラフィックをクラスター内のサービスにルーティングします。CNO は、Pod ネットワーク、サービスネットワーク、DNS などのクラスターネットワークコンポーネントをデプロイおよび管理します。
1.9.1. アプリケーションの公開 リンクのコピーリンクがクリップボードにコピーされました!
ClusterIP は、クラスター内の内部 IP でサービスを公開し、クラスター内の他のサービスのみがクラスターにアクセスできるようにします。NodePort サービスタイプは、各ノードの IP 上の静的ポートでサービスを公開します。このサービスタイプでは、外部トラフィックがサービスにアクセスできます。ロードバランサーは通常、MetalLB を使用するクラウドまたはベアメタル環境で使用されます。このサービスタイプは、外部トラフィックをサービスにルーティングする外部ロードバランサーをプロビジョニングします。ベアメタル環境では、MetalLB は VIP と ARP アナウンスメントまたは BGP アナウンスメントを使用します。
Ingress は、負荷分散、SSL/TLS Termination、名前ベースの仮想ホスティングなどのサービスへの外部アクセスを管理する API オブジェクトです。NGINX や HAProxy などの Ingress Controller は、Ingress API を実装し、ユーザーが定義したルールに基づいてトラフィックルーティングを処理します。
1.9.2. 接続のセキュリティー保護 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller は、SSL/TLS Termination を管理し、着信 SSL/TLS トラフィックをバックエンドサービスに渡す前に復号します。SSL/TLS Termination により、暗号化/復号プロセスがアプリケーション Pod からオフロードされます。TLS 証明書を使用して、クライアントとサービス間のトラフィックを暗号化できます。cert-manager
などのツールを使用して証明書を管理し、証明書の配布と更新を自動化できます。
SNI フィールドがある場合、ルートは TLS トラフィックを Pod に渡します。このプロセスにより、HTTP/HTTPS だけでなく TLS を使用して、TCP を実行するサービスを公開できるようになります。サイト管理者は証明書を一元管理でき、権限を持たないアプリケーション開発者による秘密鍵の読み取りを許可できます。
Route API を使用すると、クラスターが管理する証明書を使用してルーターから Pod へのトラフィックを暗号化できます。これにより、内部の通信区間の暗号化は維持されたまま、外部証明書が一元管理されます。アプリケーション開発者は、アプリケーション用の一意の秘密鍵を受け取ります。これらの鍵は Pod 内にシークレットとしてマウントできます。
ネットワーク制御は、Pod 間および Pod と他のネットワークエンドポイント間で通信する方法のルールを定義します。これにより、クラスター内のトラフィックフローが制御され、セキュリティーが強化されます。この制御はネットワークプラグインレベルで実装され、許可されたトラフィックのみが Pod 間で流れるようにします。
ロールベースのアクセス制御 (RBAC) は、権限を管理し、クラスター内のリソースにアクセスできるユーザーを制御します。サービスアカウントは、API にアクセスする Pod にアイデンティティーを提供します。RBAC を使用すると、各 Pod が実行できる操作を細かく制御できます。
1.9.3. 例: アプリケーションの公開と接続の保護 リンクのコピーリンクがクリップボードにコピーされました!
この例では、クラスター内で実行されている Web アプリケーションに外部ユーザーがアクセスする必要があります。
ニーズに合うサービスタイプを使用して、サービスを作成し、アプリケーションをサービスとして公開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow HTTP/HTTPS トラフィックを管理し、サービスにルーティングするための
Ingress
リソースを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress に TLS を設定して、安全で暗号化された接続を確保します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.9.4. サービスタイプと API リソースの選択 リンクのコピーリンクがクリップボードにコピーされました!
サービスタイプと API リソースには、アプリケーションの公開とネットワーク接続の保護に関連するさまざまな利点があります。適切なサービスタイプまたは API リソースを活用することで、アプリケーションの公開方法を効果的に管理し、内部クライアントと外部クライアントの両方に対して安全で信頼性の高いアクセスを確保できます。
OpenShift Container Platform は、次のサービスタイプと API リソースをサポートしています。
サービスタイプ
-
ClusterIP
は、内部のみの公開を目的としています。容易にセットアップでき、クラスター内のサービスにアクセスするための安定した内部 IP アドレスを提供します。ClusterIP
は、クラスター内のサービス間の通信に適しています。 -
NodePort
は、各ノードの IP 上のサービスを静的ポートで公開することで、外部アクセスを許可します。容易にセットアップでき、開発やテストに役立ちます。NodePort
は、クラウドプロバイダーのロードバランサーを必要としない単純な外部アクセスに適しています。 -
LoadBalancer
は、トラフィックを複数のノードに分散するために、外部ロードバランサーを自動的にプロビジョニングします。信頼性と可用性の高いアクセスを必要とする実稼働環境に最適です。 -
ExternalName
はサービスを外部 DNS 名にマッピングし、クラスター外のサービスに、DNS 名を使用してアクセスできるようにします。外部サービスやレガシーシステムをクラスターと統合する場合に適しています。 -
Headless サービスは、安定した
ClusterIP
を提供せずに Pod IP のリストを返す DNS 名です。これは、ステートフルアプリケーションや、個々の Pod IP への直接アクセスが必要なシナリオに最適です。
-
API リソース
-
Ingress
は、負荷分散、SSL/TLS Termination、名前ベースの仮想ホスティングをサポートし、HTTP および HTTPS トラフィックのルーティングを制御します。サービス単独よりも柔軟性が高く、複数のドメインとパスをサポートします。複雑なルーティングが必要な場合、Ingress
が最適です。 -
Route
はIngress
に似ていますが、さらに TLS 再暗号化やパススルーなどの追加機能を提供します。これを使用することで、サービスの外部公開プロセスが単純化されます。Route
は、統合された証明書管理などの高度な機能が必要な場合に最適です。
-
簡単にサービスを外部トラフィックに公開できる方法が必要な場合は、おそらく Route
または Ingress
が最適な選択肢です。これらのリソースは、namespace 管理者または開発者が管理できます。最も簡単な方法として、ルートを作成し、その外部 DNS 名を確認し、外部 DNS 名を指す CNAME を持つように DNS を設定できます。
HTTP/HTTPS/TLS の場合、Route
または Ingress
で十分です。それ以外の場合はより複雑で、クラスター管理者はポートがアクセス可能であることや MetalLB が設定されていることを確認する必要があります。クラウド環境または適切に設定されたベアメタル環境の場合、LoadBalancer
サービスも選択肢として検討できます。
第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 を実行できるようにするには、以下の手順を実行する必要があります。
手順
-
openshift-install
コマンドで作成される Virtual Private Cloud (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。 - インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。
パブリック 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 でキーを指定することができます。
Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。
注記直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、権限付き Pod を代わりに実行します。
-
oc get nodes
を実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名はip-10-0-1-163.ec2.internal
に類似したものになります。 Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。
ssh -i <ssh-key-path> core@<master-hostname>
$ ssh -i <ssh-key-path> core@<master-hostname>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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
を使用します。ユーザーはこれらの範囲も回避する必要があります。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。
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 フィールドで、個々のマシンにスケジュールされた Pod に割り当てられたサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。
例えば、ホスト接頭辞を /23
に設定した場合、各マシンには Pod CIDR アドレス範囲から /23
のサブネットが割り当てられます。デフォルトは /23
で、510 台のクラスターノードと、ノードごとに 510 個の Pod IP アドレスを許可します。
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.