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

バージョン 3 から 4 への移行

OpenShift Container Platform 4.21

OpenShift Container Platform 4 への移行

概要

このドキュメントでは、OpenShift Container Platform クラスターをバージョン 3 からバージョン 4 に移行する方法を説明します。

第1章 OpenShift Container Platform 3 から 4 への移行について
リンクのコピー

OpenShift Container Platform 4 クラスターは OpenShift Container Platform 3 クラスターとは異なります。OpenShift Container Platform 4 クラスターには、自己管理型の柔軟で自動化されたクラスターを実現する新規のテクノロジーおよび機能が含まれています。OpenShift Container Platform 3 から 4 への移行の詳細は、OpenShift Container Platform 3 から 4 への移行について を参照してください。

1.1. OpenShift Container Platform 3 と 4 の相違点
リンクのコピー

OpenShift Container Platform 3 から 4 に移行する前に、OpenShift Container Platform 3 と 4 の違い を確認できます。次の情報を確認してください。

1.2. ネットワークの考慮事項の計画
リンクのコピー

OpenShift Container Platform 3 から 4 に移行する前に、OpenShift Container Platform 3 と 4 の違い を確認して、以下の領域を確認してください。

第2章 OpenShift Container Platform 3 から 4 への移行について
リンクのコピー

OpenShift Container Platform 4 には、自己管理型の柔軟で自動化されたクラスターを実現する新規のテクノロジーおよび機能が含まれています。OpenShift Container Platform 4 クラスターがデプロイされ、管理される方法は OpenShift Container Platform 3 とは大きく異なります。

OpenShift Container Platform 3 から 4 に移行する最も効果的な方法は、CI/CD パイプラインを使用して、アプリケーションライフサイクル管理 フレームワークでデプロイメントを自動化することができます。

Red Hat Advanced Cluster Management for Kubernetes を使用すると、OpenShift Container Platform 3 クラスターのインポートと管理、ポリシーの適用、およびアプリケーションの再デプロイを簡単に行うことができます。Red Hat Advanced Cluster Management の 無料のサブスクリプション を利用して、移行プロセスを簡略化できます。

OpenShift Container Platform 4 に正常に移行するには、以下の情報を確認してください。

OpenShift Container Platform 3 と 4 の相違点
  • アーキテクチャー
  • インストールおよびアップグレード
  • ストレージ、ネットワーク、ロギング、セキュリティー、およびモニタリングに関する考慮事項

第3章 OpenShift Container Platform 3 と 4 の相違点
リンクのコピー

OpenShift Container Platform 4.21 では、アーキテクチャーの変更と機能強化が導入されています。OpenShift Container Platform 3 クラスターの管理に使用していた手順は、OpenShift Container Platform 4 には適用されない場合があります。

OpenShift Container Platform 4 クラスターの設定は、OpenShift Container Platform ドキュメントの該当するセクションを参照してください。新機能やその他の注目すべき技術的変更点については、OpenShift Container Platform 4.21 のリリースノートを 参照してください。

既存の OpenShift Container Platform 3 クラスターを OpenShift Container Platform 4 にアップグレードすることはできません。新規の OpenShift Container Platform 4 インストールで開始する必要があります。コントロールプレーンの設定およびアプリケーションのワークロードの移行に役立つツールを使用できます。

3.1. アーキテクチャー
リンクのコピー

OpenShift Container Platform 3 では、管理者は Red Hat Enterprise Linux (RHEL) ホストを個別にデプロイし、その後に OpenShift Container Platform をこれらのホストにインストールし、クラスターを作成しました。管理者は、これらのホストを適切に設定し、更新を実行する必要があります。

OpenShift Container Platform 4 では、これまでとは大きく異なる方法で OpenShift Container Platform クラスターがデプロイされ、管理されるようになりました。OpenShift Container Platform 4 には、Operator、マシンセット、および Red Hat Enterprise Linux CoreOS (RHCOS) などの、クラスターの操作に対するコアとなる新たなテクノロジーおよび機能が含まれます。このテクノロジーの移行により、クラスターは管理者が以前に実行していた一部の機能を自己管理できるようになります。また、プラットフォームの安定性と一貫性を確保し、インストールおよびスケーリングを単純化することが可能です。

OpenShift Container Platform 4.13 以降、RHCOS は Red Hat Enterprise Linux (RHEL) 9.2 パッケージを使用するようになりました。今回の機能拡張により、最新の修正と機能に加えて、最新のハードウェアサポートとドライバーの更新が可能になりました。RHEL 9.2 へのアップグレードが、オプション設定、サービス、ドライバーおよびコンテナーのサポートに与える可能性のある影響の詳細は、OpenShift Container Platform 4.13 リリースノート の RHCOS で RHEL 9.2 の使用を開始 を参照してください。

詳細は、OpenShift Container Platform アーキテクチャー を参照してください。

3.1.1. イミュータブルなインフラストラクチャー
リンクのコピー

OpenShift Container Platform 4 は、コンテナー化されたアプリケーションを実行するために設計された Red Hat Enterprise Linux CoreOS (RHCOS) を使用し、効率的なインストール、Operator ベースの管理、および単純化されたアップグレードを可能にします。RHCOS は、RHEL のようなカスタマイズ可能なオペレーティングシステムではなく、イミュータブルなコンテナーホストです。RHCOS により、OpenShift Container Platform 4 は基礎となるコンテナーホストのデプロイメントを管理し、自動化できます。RHCOS は OpenShift Container Platform の一部です。これは、すべてがコンテナー内で実行され、OpenShift Container Platform を使用してデプロイされることを意味します。

OpenShift Container Platform 4 では、コントロールプレーンノードは RHCOS を実行する必要があるため、コントロールプレーンのフルスタック自動化が維持されます。これにより、OpenShift Container Platform 3 よりも簡単に更新がロールアウトされ、アップグレードが簡単になります。

詳細は、Red Hat Enterprise Linux CoreOS (RHCOS) を参照してください。

3.1.2. 演算子
リンクのコピー

Operator は、Kubernetes アプリケーションをパッケージ化し、デプロイし、管理する方法です。Operator は、ソフトウェアの他の部分を実行する際の運用上の複雑さを軽減します。Operator は環境を監視し、現在の状態を使用してリアルタイムの意思決定を行います。高度な Operator は、自動的にアップグレードし、障害に自動的に対応するように設計されています。

詳細は、Operator の理解を 参照してください。

3.2. インストールおよびアップグレード
リンクのコピー

3.2.1. インストールプロセス
リンクのコピー

OpenShift Container Platform 3.11 をインストールするには、Red Hat Enterprise Linux (RHEL) ホストを準備し、クラスターが必要とする設定値をすべて設定してから、Ansible Playbook を実行してクラスターをインストールし、セットアップする必要がありました。

OpenShift Container Platform 4.21 では、OpenShift インストールプログラムを使用して、クラスターに必要な最小限のリソースセットを作成します。クラスターの実行後に、Operator を使用してクラスターをさらに設定し、新規サービスをインストールできます。初回の起動後に、Red Hat Enterprise Linux CoreOS (RHCOS) システムは、OpenShift Container Platform クラスターで実行される Machine Config Operator (MCO) によって管理されます。

詳細は、インストール手順 を参照してください。

3.2.2. インフラストラクチャーオプション
リンクのコピー

OpenShift Container Platform 3.11 では、ユーザーが準備し、維持するインフラストラクチャーにクラスターをインストールする必要があります。OpenShift Container Platform 4 では、独自のインフラストラクチャーを提供するだけでなく、OpenShift Container Platform インストールプログラムがプロビジョニングし、クラスターが維持するインフラストラクチャーにクラスターをデプロイするオプションを提供します。

詳細は、OpenShift Container Platform のインストール概要を 参照してください。

3.2.3. クラスターのアップグレード
リンクのコピー

OpenShift Container Platform 3.11 では、Ansible Playbook を実行してクラスターをアップグレードします。OpenShift Container Platform 4.21 では、クラスターが独自のアップデートを管理し、クラスターノード上の Red Hat Enterprise Linux CoreOS(RHCOS) のアップデートも含まれます。Web コンソールまたは OpenShift CLI から oc adm upgrade コマンドを使用することでクラスターを容易にアップグレードでき、Operator は自動的にアップグレードされます。OpenShift Container Platform 4.21 クラスターに RHEL ワーカーマシンが含まれている場合は、それらのワーカーマシンをアップグレードするために Ansible Playbook を実行する必要があります。

詳細は、クラスターの更新を 参照してください。

3.3. 移行に関する考慮事項
リンクのコピー

OpenShift Container Platform 3.11 から OpenShift Container Platform 4 への移行に影響を与える可能性のある変更やその他の考慮事項を確認します。

3.3.1. ストレージに関する考慮事項
リンクのコピー

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.21 への移行時に考慮すべきストレージの変更点を以下に確認してください。

3.3.1.1. ローカルボリュームの永続ストレージ
リンクのコピー

ローカルストレージは、OpenShift Container Platform 4.21 の Local Storage Operator を使用した場合にのみサポートされます。OpenShift Container Platform 3.11 のローカルプロビジョナーメソッドの使用はサポートされません。

詳細は、ローカルボリュームを使用した永続ストレージ を参照してください。

3.3.1.2. FlexVolume 永続ストレージ
リンクのコピー

FlexVolume プラグインの場所が OpenShift Container Platform 3.11 で変更になりました。OpenShift Container Platform 4.21 の新しい場所は /etc/kubernetes/kubelet-plugins/volume/exec です。割り当て可能な FlexVolume プラグインはサポートされなくなりました。

詳細は、FlexVolume を使用した永続ストレージ を参照してください。

3.3.1.3. Container Storage Interface (CSI) 永続ストレージ
リンクのコピー

Container Storage Interface (CSI) を使用した永続ストレージは OpenShift Container Platform 3.11 では テクノロジープレビュー として利用可能でした。OpenShift Container Platform 4.21 には、いくつかの CSI ドライバー が含まれています。そのため、独自のドライバーをインストールできます。

詳細は、Container Storage Interface (CSI) を使用した永続ストレージ を参照してください。

3.3.1.4. Red Hat OpenShift Data Foundation
リンクのコピー

OpenShift Container Platform 3.11 で使用できる OpenShift Container Storage 3 は、バッキングストレージとして Red Hat Gluster Storage を使用します。

OpenShift Container Platform 4 で使用できる Red Hat OpenShift Data Foundation 4 は、バッキングストレージとして Red Hat Ceph Storage を使用します。

詳細は、Persistent storage using Red Hat OpenShift Data Foundation および interoperability matrix の記事を参照してください。

3.3.1.5. サポートされていない永続ストレージオプション
リンクのコピー

OpenShift Container Platform 4.21 では、OpenShift Container Platform 3.11 でサポートされていた以下の永続ストレージオプションのサポートが変更されました。

  • GlusterFS はサポート対象外になりました。
  • スタンドアロン製品としての CephFS がサポートされなくなりました。
  • スタンドアロン製品としての Ceph RBD がサポートされなくなりました。

OpenShift Container Platform 3.11 でこれらのいずれかを使用していた場合は、OpenShift Container Platform 4.21 で完全なサポートを受けるために、別の永続ストレージオプションを選択する必要があります。

詳細は、永続ストレージについてを 参照してください。

3.3.1.6. ツリー内ボリュームの CSI ドライバーへの移行
リンクのコピー

OpenShift Container Platform 4 は、対応する Container Storage Interface (CSI) に、ツリー内のボリュームプラグインを移行しています。OpenShift Container Platform 4.21 では、以下のツリー内ボリュームタイプにおいて、CSI ドライバーが新しいデフォルトドライバーとして使用されます。

  • Amazon Web Services (AWS) Elastic Block Storage (EBS)
  • Azure Disk
  • Azure File
  • Google Cloud Persistent Disk (GCP PD)
  • OpenStack Cinder

  • VMware vSphere

    注記

    OpenShift Container Platform 4.13 では、デフォルトで VMware vSphere は使用できません。ただし、VMware vSphere を選択することはできます。

作成、削除、マウント、アンマウントなど、ボリュームのライフサイクルのすべての側面は、CSI ドライバーによって処理されます。

詳細は、CSI 自動移行を参照してください。

3.3.2. ネットワークの考慮事項
リンクのコピー

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.21 への移行時に考慮すべき、以下のネットワーク変更点を確認してください。

3.3.2.1. ネットワーク分離モード
リンクのコピー

OpenShift Container Platform 3.11 では、ユーザーは ovn-multitenant を使用するように頻繁に切り替えましたが、デフォルトのネットワーク分離モードは ovs-subnet でした。OpenShift Container Platform 4.21 のデフォルトのネットワーク分離モードは、ネットワークポリシーによって制御されます。

OpenShift Container Platform 3.11 クラスターで ovs-subnet または ovs-multitenant モードを使用していた場合は、OpenShift Container Platform 4.21 クラスターでネットワークポリシーに切り替えることを推奨します。ネットワークポリシーはアップストリームでサポートされ、より柔軟であり、ovs-multitenant が実行する機能を提供します。OpenShift Container Platform 4.21 でネットワークポリシーを使用しながら ovs-multitenant の 動作を維持する場合は、ネットワークポリシーを使用したマルチテナント分離の設定 手順に従ってください。

詳細は、ネットワークポリシーについてを 参照してください。

3.3.2.2. Red Hat OpenShift Networking のデフォルトのネットワークプラグインとしての OVN-Kubernetes
リンクのコピー

OpenShift Container Platform 3.11 では、OpenShift SDN が Red Hat OpenShift Networking のデフォルトのネットワーキングプラグインでした。OpenShift Container Platform 4.21 では、OVN-Kubernetes がデフォルトのネットワークプラグインになりました。

OpenShift SDN ネットワークプラグインの削除と削除理由の詳細は、OCP 4.17 での OpenShiftSDN CNI の削除 を参照してください。

OpenShift SDN プラグインの機能に類似した OVN-Kubernetes の機能は、以下を参照してください。

警告

OpenShift SDN ネットワークプラグインを使用している場合は、クラスターを OpenShift Container Platform 4.17 以降にアップグレードできないため、OVN-Kubernetes ネットワークプラグインを使用して OpenShift Container Platform 4 をインストールする必要があります。

3.3.3. ロギングに関する考慮事項
リンクのコピー

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.21 への移行時に考慮すべき、以下のログ記録に関する変更点を確認してください。

3.3.3.1. OpenShift Logging のデプロイ
リンクのコピー

OpenShift Container Platform 4 は、クラスターロギングのカスタムリソース (Custom Resource) を使用して OpenShift Logging の単純なデプロイメントメカニズムを提供します。

3.3.3.2. 集計ロギングデータ
リンクのコピー

集計ロギングデータを OpenShift Container Platform 3.11 から新規の OpenShift Container Platform 4 クラスターに移行することはできません。

3.3.3.3. サポートされないロギング設定
リンクのコピー

OpenShift Container Platform 3.11 で利用可能だった一部のログ設定は、OpenShift Container Platform 4.21 ではサポートされなくなりました。

3.3.4. セキュリティーに関する考慮事項
リンクのコピー

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.21 への移行時に考慮すべき、以下のセキュリティー変更点を確認してください。

3.3.4.1. 検出エンドポイントへの認証されていないアクセス
リンクのコピー

OpenShift Container Platform 3.11 では、認証されていないユーザーは検出エンドポイント (例: /api/* および /apis/*) にアクセスできました。セキュリティー上の理由から、OpenShift Container Platform 4.21 では、認証されていない状態での検出エンドポイントへのアクセスは許可されなくなりました。認証されていないアクセスを許可する必要がある場合は、必要に応じて RBAC を設定できます。ただし、これにより内部クラスターコンポーネントが外部ネットワークに公開される可能性があるため、セキュリティー上の影響を考慮してください。

3.3.4.2. アイデンティティープロバイダー
リンクのコピー

アイデンティティープロバイダーの設定は、以下の主な変更点を含め、OpenShift Container Platform 4 で変更されています。

  • OpenShift Container Platform 4.21 のリクエストヘッダーアイデンティティープロバイダーは相互 TLS を必要としますが、OpenShift Container Platform 3.11 では必要としませんでした。
  • OpenShift Container Platform 4.21 では、OpenID Connect アイデンティティープロバイダーの設定が簡素化されました。OpenShift Container Platform 3.11 で以前に指定される必要のあったデータが、プロバイダーの /.well-known/openid-configuration エンドポイントから取得できるようになりました。

詳細は、アイデンティティープロバイダー設定の理解を 参照してください。

3.3.4.3. OAuth トークンストレージの形式
リンクのコピー

新規に作成された OAuth HTTP ベアラートークンは、OAuth アクセストークンオブジェクトの名前と一致しなくなりました。オブジェクト名はベアラートークンのハッシュとなり、機密性はなくなりました。これにより、機密情報が漏えいするリスクが軽減されます。

3.3.4.4. デフォルトの SCC (Security Context Constraints)
リンクのコピー

OpenShift Container Platform 4 の restricted セキュリティーコンテキスト制約 (SCC) には、OpenShift Container Platform 3.11 の restricted SCC として認証されたユーザーはアクセスできなくなりました。広範な認証アクセスが restricted-v2 SCC に付与され、以前の restricted SCC よりも限定されます。restricted SCC はまだ存在するので、この SCC を使用するユーザーには明示的にパーミッションを指定する必要があります。

詳細は、Security Context Constraints の管理を 参照してください。

3.3.5. モニタリングに関する考慮事項
リンクのコピー

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.21 への移行時に、以下の監視に関する変更点を確認してください。Hawkular の設定とメトリックを Prometheus に移行することはできません。

3.3.5.1. インフラストラクチャーの可用性に関するモニタリングアラート
リンクのコピー

モニタリング構造の可用性を確保するためにトリガーするデフォルトのアラートは OpenShift Container Platform 3.11 では DeadMansSwitch と呼ばれていました。この名前は OpenShift Container Platform 4 で Watchdog に変更されています。OpenShift Container Platform 3.11 で PagerDuty 統合をこのアラートでセットアップしている場合、OpenShift Container Platform 4 では Watchdog アラートについて PagerDuty 統合をセットアップする必要があります。

詳細は、デフォルトプラットフォームアラートのアラートルーティングの設定を 参照してください。

第4章 ネットワークの考慮事項
リンクのコピー

移行後にアプリケーションネットワークトラフィックをリダイレクトするための戦略を確認します。

4.1. DNS に関する考慮事項
リンクのコピー

ターゲットクラスターの DNS ドメインは、ソースクラスターのドメインとは異なります。デフォルトでは、アプリケーションは移行後にターゲットクラスターの FQDN を取得します。

移行したアプリケーションのソース DNS ドメインを保持するには、以下で説明する 2 つのオプションのいずれかを選択します。

4.1.1. クライアントからのターゲットクラスターの DNS ドメイン分離
リンクのコピー

ターゲットクラスターをクライアントに公開せずに、ソースクラスターの DNS ドメインに送信されるクライアントの要求がターゲットクラスターの DNS ドメインに到達するように許可できます。

手順

  1. クライアントとターゲットクラスターの間に、アプリケーションロードバランサーやリバースプロキシーなどの外部ネットワークコンポーネントを配置します。
  2. DNS サーバーのソースクラスターのアプリケーション FQDN を更新して、外部ネットワークコンポーネントの IP アドレスを返します。
  3. ソースドメインのアプリケーション用に受信された要求をターゲットクラスタードメインのロードバランサーに送信するようにネットワークコンポーネントを設定します。
  4. ソースクラスターのロードバランサーの IP アドレスを参照する *.apps.source.example.com ドメインのワイルドカード DNS レコードを作成します。
  5. ターゲットクラスターの前に、外部ネットワークコンポーネントの IP アドレスを参照する各アプリケーションに DNS レコードを作成します。特定の DNS レコードの優先順位はワイルドカードレコードよりも高くなるため、アプリケーションの FQDN の解決時に競合は発生しません。
注記
  • 外部ネットワークコンポーネントは、すべてのセキュアな TLS 接続を終了する必要があります。接続がターゲットクラスターロードバランサーに渡されると、ターゲットアプリケーションの FQDN がクライアントに公開され、証明書エラーが発生します。
  • アプリケーションは、ターゲットクラスタードメインを参照するリンクをクライアントに返すことはできません。そうしないと、アプリケーションの一部が正しくロードまたは機能しない可能性があります。

4.1.2. ソース DNS ドメインを受け入れるためのターゲットクラスターの設定
リンクのコピー

ソースクラスターの DNS ドメインで移行したアプリケーションの要求を受け入れるようにターゲットクラスターを設定できます。

手順

セキュアではない HTTP アクセスとセキュアな HTTPS アクセスの両方で、以下の手順を実行します。

  1. ソースクラスター内のアプリケーションの FQDN にアドレス指定された要求を受け入れるように設定されたターゲットクラスターのプロジェクトにルートを作成します。 

    $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
 -n <app1-namespace>

    この新規ルートが有効な場合には、サーバーはその FQDN の要求を受け入れて、対応するアプリケーション Pod に送信します。さらに、アプリケーションを移行すると、ターゲットクラスタードメインに別のルートが作成されます。要求は、これらのホスト名のいずれかを使用して、移行されたアプリケーションに到達します。

  2. ソースクラスター内のアプリケーションの FQDN がターゲットクラスターのデフォルトのロードバランサーの IP アドレスを指す DNS プロバイダーを使用して DNS レコードを作成します。これにより、トラフィックがソースクラスターからターゲットクラスターにリダイレクトされます。

    アプリケーションの FQDN は、ターゲットクラスターのロードバランサーに対して解決します。デフォルトの Ingress コントローラールーターは、そのホスト名のルートが公開されるため、対象となる FQDN の要求を受け入れます。

セキュアな HTTPS アクセスには、以下の追加手順を実行します。

  1. インストールプロセス中に作成されたデフォルトの Ingress コントローラーの x509 証明書をカスタム証明書に置き換えます。

  2. この証明書に、subjectAltName フィールドにソースおよびターゲットクラスター両方のワイルドカード DNS ドメインが含まれるように設定します。

    新しい証明書は、いずれかの DNS ドメインを使用して確立された接続を保護するために有効です。

4.2. ネットワークトラフィックリダイレクト戦略
リンクのコピー

移行が成功したら、ステートレスアプリケーションのネットワークトラフィックをソースクラスターからターゲットクラスターにリダイレクトする必要があります。

ネットワークトラフィックをリダイレクトするための戦略は、次の前提に基づいています。

  • アプリケーション Pod は、ソースクラスターとターゲットクラスターの両方で実行しています。
  • 各アプリケーションには、ソースクラスターのホスト名を含むルートがあります。
  • ソースクラスターのホスト名を持つルートには、CA 証明書が含まれています。
  • HTTPS の場合、ターゲットルーターの CA 証明書には、ソースクラスターのワイルドカード DNS レコードのサブジェクト代替名が含まれています。

次の戦略を検討し、目的に合った戦略を選択してください。

  • すべてのアプリケーションのすべてのネットワークトラフィックを同時にリダイレクトします。

    ソースクラスターのワイルドカード DNS レコードを変更して、ターゲットクラスタールーターの仮想 IP アドレス (VIP) を指すようにします。

    この戦略は、単純なアプリケーションまたは小規模な移行に適しています。

  • 個々のアプリケーションのネットワークトラフィックをリダイレクトする

    ソースクラスターのホスト名がターゲットクラスタールーターの VIP を指すように、アプリケーションごとに DNS レコードを作成します。この DNS レコードは、ソースクラスターのワイルドカード DNS レコードよりも優先されます。

  • 個々のアプリケーションのネットワークトラフィックを徐々にリダイレクトする

    1. アプリケーションごとに、ソースクラスタールーターの VIP とターゲットクラスタールーターの VIP の両方にトラフィックを転送できるプロキシーを作成します。
    2. ソースクラスターのホスト名がプロキシーを指すように、アプリケーションごとに DNS レコードを作成します。
    3. トラフィックの一部をターゲットクラスタールーターの VIP にルーティングし、残りのトラフィックをソースクラスタールーターの VIP にルーティングするように、アプリケーションのプロキシーエントリーを設定します。
    4. すべてのネットワークトラフィックがリダイレクトされるまで、ターゲットクラスタールーターの VIP にルーティングするトラフィックの割合を徐々に増やします。

  • 個々のアプリケーションのトラフィックのユーザーベースのリダイレクト

    この戦略を使用すると、ユーザー要求の TCP/IP ヘッダーをフィルタリングして、事前定義されたユーザーグループのネットワークトラフィックをリダイレクトできます。これにより、ネットワークトラフィック全体をリダイレクトする前に、特定のユーザー集団でリダイレクトプロセスをテストできます。

    1. アプリケーションごとに、ソースクラスタールーターの VIP とターゲットクラスタールーターの VIP の両方にトラフィックを転送できるプロキシーを作成します。
    2. ソースクラスターのホスト名がプロキシーを指すように、アプリケーションごとに DNS レコードを作成します。
    3. test customers など、特定のヘッダーパターンに一致するトラフィックをターゲットクラスタールーターの VIP にルーティングし、残りのトラフィックをソースクラスタールーターの VIP にルーティングするように、アプリケーションのプロキシーエントリーを設定します。
    4. すべてのトラフィックがターゲットクラスタールーターの VIP に到達するまで、トラフィックをターゲットクラスタールーターの VIP に段階的にリダイレクトします。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る