16.3. ネットワークが制限された環境での z/VM のあるクラスターの IBM Z および LinuxONE へのインストール


OpenShift Container Platform バージョン 4.11 では、制限されたネットワークでプロビジョニングする IBM Z および LinuxONE インフラストラクチャーにクラスターをインストールできます。

注記

本書は IBM Z のみを参照しますが、これに含まれるすべての情報は LinuxONE にも適用されます。

重要

ベアメタルプラットフォーム以外の場合には、追加の考慮点を検討する必要があります。OpenShift Container Platform クラスターをインストールする前に、guidelines for deploying OpenShift Container Platform on non-tested platforms にある情報を確認してください。

16.3.1. 前提条件

16.3.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.11 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。

クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェアまたは VMware vSphere へのインストールには、インターネットアクセスが必要になる場合があります。

ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。

重要

ユーザーによってプロビジョニングされるインストールの設定は複雑であるため、ユーザーによってプロビジョニングされるインフラストラクチャーを使用してネットワークが制限されたインストールを試行する前に、標準的なユーザーによってプロビジョニングされるインフラストラクチャーを実行することを検討してください。このテストが完了すると、ネットワークが制限されたインストール時に発生する可能性のある問題の切り分けやトラブルシューティングがより容易になります。

16.3.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

16.3.3. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.11 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

16.3.4. ユーザーによってプロビジョニングされるインフラストラクチャーを使用したクラスターの要件

ユーザーによってプロビジョニングされるインフラストラクチャーを含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。

このセクションでは、ユーザーによってプロビジョニングされるインフラストラクチャーに OpenShift Container Platform をデプロイする要件について説明します。

16.3.4.1. クラスターのインストールに必要なマシン

最小の OpenShift Container Platform クラスターでは以下のホストが必要です。

表16.19 最低限必要なホスト
ホスト説明

1 つの一時的なブートストラップマシン

クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。

3 つのコントロールプレーンマシン

コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。

少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。

OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。

重要

クラスターの高可用性を改善するには、2 つ以上の物理マシンの複数の異なる z/VM インスタンスにコントロールプレーンマシンを分散します。

ブートストラップ、コントロールプレーンおよびコンピュートマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。

RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。

16.3.4.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表16.20 最小リソース要件
マシンオペレーティングシステムvCPU [1]仮想 RAMストレージIOPS

ブートストラップ

RHCOS

4

16 GB

100 GB

該当なし

コントロールプレーン

RHCOS

4

16 GB

100 GB

該当なし

Compute

RHCOS

2

8 GB

100 GB

該当なし

  1. 1 つの物理コア (IFL) は、SMT-2 が有効な場合に 2 つの論理コア (スレッド) を提供します。ハイパーバイザーは、2 つ以上の vCPU を提供できます。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

16.3.4.3. 最小の IBM Z システム環境

OpenShift Container Platform バージョン 4.11 は、以下の IBM ハードウェアにインストールできます。

  • IBM z16 (全モデル)、IBM z15 (全モデル)、IBM z14 (全モデル)、IBM z13、および IBM z13s
  • LinuxONE(すべてのバージョン)
ハードウェア要件
  • クラスターごとに、SMT2 対応の 6 つの Integrated Facilities for Linux (IFL) に相当します。
  • 最低でもネットワーク接続 1 つ。これで、LoadBalancer サービスに接続するだけでなく、クラスター外のトラッフィクに関するデータを提供します。
注記

専用または共有 IFL を使用して、十分なコンピューティングリソースを割り当てることができます。リソース共有は IBM Z の重要な強みの 1 つです。ただし、各ハイパーバイザーレイヤーで容量を正しく調整し、すべての OpenShift Container Platform クラスターに十分なリソースを確保する必要があります。

重要

クラスターの全体的なパフォーマンスに影響を与える可能性があるため、OpenShift Container Platform クラスターの設定に使用される LPAR には十分なコンピューティング能力が必要です。このコンテキストでは、ハイパーバイザーレベルでの LPAR の加重管理、エンタイトルメント、および CPU 共有が重要なロールを果たします。

オペレーティングシステム要件
  • z/VM 7.2 以降の 1 インスタンス

z/VM インスタンスで、以下をセットアップします。

  • OpenShift Container Platform コントロールプレーンマシンの 3 ゲスト仮想マシン
  • OpenShift Container Platform コンピュートマシンの 2 ゲスト仮想マシン
  • 一時 OpenShift Container Platform ブートストラップマシンの 1 ゲスト仮想マシン
IBM Z ネットワーク接続の要件

IBM Z の z/VM でインストールするには、 レイヤー 2 モードの単一 z/VM 仮想 NIC が必要になります。以下も必要になります。

  • 直接接続された OSA または RoCE ネットワークアダプター
  • z/VM vSwitch のセットアップ。推奨されるセットアップでは、OSA リンクアグリゲーションを使用します。
z/VM ゲスト仮想マシンのディスクストレージ
  • FICON 接続のディスクストレージ (DASD)これらには z/VM ミニディスク、フルパックミニディスク、または専用の DASD を使用でき、これらすべてはデフォルトである CDL としてフォーマットする必要があります。Red Hat Enterprise Linux CoreOS (RHCOS) インストールに必要な最低限の DASD サイズに達するには、拡張アドレスボリューム (EAV) が必要です。利用可能な場合は、HyperPAV を使用して最適なパフォーマンスを確保します。
  • FCP 接続のディスクストレージ
ストレージ/メインメモリー
  • OpenShift Container Platform コントロールプレーンマシン用に 16 GB
  • OpenShift Container Platform コンピュートマシン用に 8 GB
  • 一時 OpenShift Container Platform ブートストラップマシン用に 16 GB

16.3.4.4. 推奨される IBM Z システム環境

ハードウェア要件
  • 6 つの IFL 相当がそれぞれ割り当てられた LPARS 3 つ (これは、各クラスターで、SMT2 が有効になっている)。
  • ネットワーク接続 2 つ。これで、LoadBalancer サービスに接続するだけでなく、クラスター外のトラッフィクに関するデータを提供します。
  • HiperSockets。ノードに直接割り当てられるか、z/VM ゲストに対して透過性を持たせるために z/VM VSWITCH でブリッジしてノードに割り当てられます。HiperSockets をノードに直接接続するには、RHEL 8 ゲスト経由で外部ネットワークにゲートウェイを設定し、Hipersockets ネットワークにブリッジする必要があります。
オペレーティングシステム要件
  • 高可用性を確保する場合は z/VM 7.2 以降の 2 または 3 インスタンス

z/VM インスタンスで、以下を設定します。

  • OpenShift Container Platform コントロールプレーンマシン用に 3 ゲスト仮想マシン (z/VM インスタンスごとに 1 つ)
  • OpenShift Container Platform コンピュートマシン用に 6 以上のゲスト仮想マシン (z/VM インスタンス全体に分散)
  • 一時 OpenShift Container Platform ブートストラップマシンの 1 ゲスト仮想マシン
  • オーバーコミット環境で必須コンポーネントの可用性を確保するには、CP コマンドの SET SHARE を使用してコントロールプレーンの優先度を引き上げます。インフラストラクチャーノードが存在する場合は、同じ操作を行います。IBM ドキュメントの SET SHARE を参照してください。
IBM Z ネットワーク接続の要件

IBM Z の z/VM でインストールするには、 レイヤー 2 モードの単一 z/VM 仮想 NIC が必要になります。以下も必要になります。

  • 直接接続された OSA または RoCE ネットワークアダプター
  • z/VM vSwitch のセットアップ。推奨されるセットアップでは、OSA リンクアグリゲーションを使用します。
z/VM ゲスト仮想マシンのディスクストレージ
  • FICON 接続のディスクストレージ (DASD)これらには z/VM ミニディスク、フルパックミニディスク、または専用の DASD を使用でき、これらすべてはデフォルトである CDL としてフォーマットする必要があります。Red Hat Enterprise Linux CoreOS (RHCOS) インストールに必要な最低限の DASD サイズに達するには、拡張アドレスボリューム (EAV) が必要です。利用可能な場合は、HyperPAV および High Performance FICON (zHPF) を使用して最適なパフォーマンスを確保します。
  • FCP 接続のディスクストレージ
ストレージ/メインメモリー
  • OpenShift Container Platform コントロールプレーンマシン用に 16 GB
  • OpenShift Container Platform コンピュートマシン用に 8 GB
  • 一時 OpenShift Container Platform ブートストラップマシン用に 16 GB

16.3.4.5. 証明書署名要求の管理

ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。

関連情報

16.3.4.6. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件

すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。

初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。

クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。

注記

DHCP サービスがユーザーによってプロビジョニングされるインフラストラクチャーで利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。

Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。

16.3.4.6.1. DHCP を使用したクラスターノードのホスト名の設定

Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。

また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。

16.3.4.6.2. ネットワーク接続の要件

OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。

本セクションでは、必要なポートの詳細を説明します。

表16.21 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコルポート説明

ICMP

該当なし

ネットワーク到達性のテスト

TCP

1936

メトリック

9000-9999

ホストレベルのサービス。 ポート 9100-9101 のノードエクスポーター、ポート 9099 の Cluster Version Operator が含まれます。

10250-10259

Kubernetes が予約するデフォルトポート

10256

openshift-sdn

UDP

4789

VXLAN

6081

Geneve

9000-9999

ポート 9100-9101 のノードエクスポーターを含む、ホストレベルのサービス。

500

IPsec IKE パケット

4500

IPsec NAT-T パケット

TCP/UDP

30000-32767

Kubernetes ノードポート

ESP

該当なし

IPsec Encapsulating Security Payload (ESP)

表16.22 すべてのマシンからコントロールプレーンへの通信に使用されるポート
プロトコルポート説明

TCP

6443

Kubernetes API

表16.23 コントロールプレーンマシンからコントロールプレーンマシンへの通信に使用されるポート
プロトコルポート説明

TCP

2379-2380

etcd サーバーおよびピアポート

ユーザーによってプロビジョニングされるインフラストラクチャーの NTP 設定

OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。

16.3.4.7. ユーザーによってプロビジョニングされる DNS 要件

OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。

  • The Kubernetes API
  • OpenShift Container Platform のアプリケーションワイルドカード
  • ブートストラップ、コントロールプレーンおよびコンピュートマシン

また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。

DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。

以下の DNS レコードは、ユーザーによってプロビジョニングされる OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name> はクラスター名で、<base_domain> は、install-config.yaml ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。

表16.24 必要な DNS レコード
コンポーネントレコード説明

Kubernetes API

api.<cluster_name>.<base_domain>.

API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

api-int.<cluster_name>.<base_domain>.

API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。

重要

API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。

ルート

*.apps.<cluster_name>.<base_domain>.

アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

たとえば、console-openshift-console.apps.<cluster_name>.<base_domain> は、OpenShift Container Platform コンソールへのワイルドカードルートとして使用されます。

ブートストラップマシン

bootstrap.<cluster_name>.<base_domain>.

ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。

コントロールプレーンマシン

<master><n>.<cluster_name>.<base_domain>.

ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。

コンピュートマシン

<worker><n>.<cluster_name>.<base_domain>.

ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。

注記

OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。

ヒント

dig コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーの DNS 解決の検証のセクションを参照してください。

16.3.4.7.1. ユーザーによってプロビジョニングされるクラスターの DNS 設定の例

このセクションでは、ユーザーによってプロビジョニングされるインフラストラクチャーに OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。

この例では、クラスター名は ocp4 で、ベースドメインは example.com です。

ユーザーによってプロビジョニングされるクラスターの DNS A レコードの設定例

BIND ゾーンファイルの以下の例は、ユーザーによってプロビジョニングされるクラスターの名前解決の A レコードの例を示しています。

例16.4 DNS ゾーンデータベースのサンプル

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 1
api-int.ocp4.example.com.	IN	A	192.168.1.5 2
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 3
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 4
;
master0.ocp4.example.com.	IN	A	192.168.1.97 5
master1.ocp4.example.com.	IN	A	192.168.1.98 6
master2.ocp4.example.com.	IN	A	192.168.1.99 7
;
worker0.ocp4.example.com.	IN	A	192.168.1.11 8
worker1.ocp4.example.com.	IN	A	192.168.1.7 9
;
;EOF
1
Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
2
Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
3
ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。
注記

この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

4
ブートストラップマシンの名前解決を提供します。
5 6 7
コントロールプレーンマシンの名前解決を提供します。
8 9
コンピュートマシンの名前解決を提供します。

ユーザーによってプロビジョニングされるクラスターの DNS PTR レコードの設定例

以下の BIND ゾーンファイルの例では、ユーザーによってプロビジョニングされるクラスターの逆引き名前解決の PTR レコードの例を示しています。

例16.5 逆引きレコードの DNS ゾーンデータベースの例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 1
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 2
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. 3
;
97.1.168.192.in-addr.arpa.	IN	PTR	master0.ocp4.example.com. 4
98.1.168.192.in-addr.arpa.	IN	PTR	master1.ocp4.example.com. 5
99.1.168.192.in-addr.arpa.	IN	PTR	master2.ocp4.example.com. 6
;
11.1.168.192.in-addr.arpa.	IN	PTR	worker0.ocp4.example.com. 7
7.1.168.192.in-addr.arpa.	IN	PTR	worker1.ocp4.example.com. 8
;
;EOF
1
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照します。
2
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照し、内部クラスター通信に使用されます。
3
ブートストラップマシンの逆引き DNS 解決を提供します。
4 5 6
コントロールプレーンマシンの逆引き DNS 解決を提供します。
7 8
コンピュートマシンの逆引き DNS 解決を提供します。
注記

PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。

16.3.4.8. ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件

OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

注記

Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。

負荷分散インフラストラクチャーは以下の要件を満たす必要があります。

  1. API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、API ルートの Server Name Indication (SNI) を有効にする必要があります。
    • ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
    重要

    API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表16.25 API ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    6443

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの /readyz エンドポイントを設定する必要があります。

    X

    X

    Kubernetes API サーバー

    22623

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。

    X

     

    マシン設定サーバー

    注記

    ロードバランサーは、API サーバーが /readyz エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。

  2. Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。

    以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、Ingress ルートの Server Name Indication (SNI) を有効にする必要があります。
    • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
    ヒント

    クライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表16.26 アプリケーション Ingress ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    443

    デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTPS トラフィック

    80

    デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。

    X

    X

    HTTP トラフィック

    注記

    ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。

16.3.4.8.1. ユーザーによってプロビジョニングされるクラスターのロードバランサーの設定例

このセクションでは、ユーザーによってプロビジョニングされるクラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg 設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。

この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

注記

HAProxy をロードバランサーとして使用し、SELinux が enforcing に設定されている場合は、setsebool -P haproxy_connect_any=1 を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。

例16.6 API およびアプリケーション Ingress ロードバランサーの設定例

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 1
  bind *:6443
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:6443 check inter 1s backup 2
  server master0 master0.ocp4.example.com:6443 check inter 1s
  server master1 master1.ocp4.example.com:6443 check inter 1s
  server master2 master2.ocp4.example.com:6443 check inter 1s
listen machine-config-server-22623 3
  bind *:22623
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 4
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen ingress-router-443 5
  bind *:443
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:443 check inter 1s
  server worker1 worker1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 6
  bind *:80
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:80 check inter 1s
  server worker1 worker1.ocp4.example.com:80 check inter 1s
1
ポート 6443 は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。
2 4
ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
3
ポート 22623 はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。
5
ポート 443 は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。
6
ポート 80 は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。
注記

ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。

ヒント

HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe を実行して、ポート 644322623443、および 80haproxy プロセスがリッスンしていることを確認することができます。

16.3.5. ユーザーによってプロビジョニングされるインフラストラクチャーの準備

ユーザーによってプロビジョニングされるインフラストラクチャーに OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。

このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要について説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続の設定、Ignition ファイルの Web サーバーの準備、ファイアウォール経由での必要なポートの有効化、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。

準備後、クラスターインフラストラクチャーは、ユーザーによってプロビジョニングされるインフラストラクチャーを使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。

前提条件

手順

  1. 静的 IP アドレスをセットアップします。
  2. HTTP または HTTPS サーバーを設定し、Ignition ファイルをクラスターノードに提供します。
  3. ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件のセクションを参照してください。
  4. OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件のセクションを参照してください。

    重要

    デフォルトで、ポート 1936 は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。

    Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。

  5. クラスターに必要な DNS インフラストラクチャーを設定します。

    1. Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
    2. Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。

      OpenShift Container Platform DNS 要件の詳細は、ユーザーによってプロビジョニングされる DNS 要件のセクションを参照してください。

  6. DNS 設定を検証します。

    1. インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
    2. インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。

      DNS 検証手順の詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーの DNS 解決の検証のセクションを参照してください。

  7. 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件のセクションを参照してください。
注記

一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。

16.3.6. ユーザーによってプロビジョニングされるインフラストラクチャーの DNS 解決の検証

OpenShift Container Platform をユーザーによってプロビジョニングされるインフラストラクチャーにインストールする前に、DNS 設定を検証できます。

重要

本セクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。

前提条件

  • ユーザーによってプロビジョニングされるインフラストラクチャーに必要な DNS レコードを設定している。

手順

  1. インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。

    1. Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain> 1
      1
      <nameserver_ip> をネームサーバーの IP アドレスに、<cluster_name> をクラスター名に、<base_domain> をベースドメイン名に置き換えます。

      出力例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5

    2. Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>

      出力例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5

    3. *.apps.<cluster_name>.<base_domain> DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>

      出力例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5

      注記

      出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

      random は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>

      出力例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5

    4. ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>

      出力例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96

    5. この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
  2. インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。

    1. API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5

      出力例

      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api-int.ocp4.example.com. 1
      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api.ocp4.example.com. 2

      1
      Kubernetes 内部 API のレコード名を指定します。
      2
      Kubernetes API のレコード名を指定します。
      注記

      PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。

    2. ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96

      出力例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.

    3. この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。

16.3.7. クラスターノードの SSH アクセス用のキーペアの生成

OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。

キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。

インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。 /openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを x86_64 アーキテクチャーにインストールする予定の場合は、ed25519 アルゴリズムを使用するキーは作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

16.3.8. インストール設定ファイルの手動作成

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

    注記

    一部のプラットフォームタイプでは、代わりに ./openshift-install create install-config --dir <installation_directory> を実行して install-config.yaml ファイルを生成することができます。プロンプト時にクラスター設定の詳細を指定できます。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

16.3.8.1. インストール設定パラメーター

OpenShift Container Platform クラスターをデプロイする前に、環境の詳細を記述するカスタマイズされた install-config.yaml インストール設定ファイルを指定します。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

16.3.8.1.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表16.27 必須パラメーター
パラメーター説明

apiVersion

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストーラーは、古い API バージョンをサポートすることもできます。

文字列

baseDomain

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain<metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata.name

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

dev などの小文字、ハイフン (-)、およびピリオド (.) が含まれる文字列。

platform

インストールを実行する特定のプラットフォームの設定: alibabacloudawsbaremetalazuregcpibmcloudnutanixopenstackovirtvsphere、または {}platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}
16.3.8.1.2. ネットワーク設定パラメーター

既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。

IPv4 アドレスのみがサポートされます。

注記

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

表16.28 ネットワークパラメーター
パラメーター説明

networking

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking.networkType

インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) クラスターネットワークプロバイダー。

OpenShiftSDN または OVNKubernetes のいずれか。OpenShiftSDN は、すべてが Linux のネットワーク用の CNI プロバイダーです。OVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プロバイダーです。デフォルト値は OpenShiftSDN です。

networking.clusterNetwork

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23

networking.clusterNetwork.cidr

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking.clusterNetwork.hostPrefix

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking.serviceNetwork

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OpenShift SDN および OVN-Kubernetes ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。

networking:
  serviceNetwork:
   - 172.30.0.0/16

networking.machineNetwork

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

複数の IP カーネル引数を指定する場合、machineNetwork.cidr の値はプライマリーネットワークの CIDR である必要があります。

オブジェクトの配列。以下に例を示します。

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16

networking.machineNetwork.cidr

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt 以外のすべてのプラットフォームでは、デフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

16.3.8.1.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表16.29 オプションのパラメーター
パラメーター説明

additionalTrustBundle

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。

文字列配列

capabilities.baselineCapabilitySet

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11、および vCurrent です。v4.11 では、baremetal Operator、marketplace Operator、および openshift-samples コンテンツが有効になります。vCurrent は、OpenShift Container Platform の現在のバージョンに推奨される一連の機能をインストールします。デフォルト値は vCurrent です。

文字列

capabilities.additionalEnabledCapabilities

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。有効な値は、baremetalmarketplace、および openshift-samples です。このパラメーターで複数の機能を指定できます。

文字列配列

cgroupsV2

クラスター内の特定のノードで Linux コントロールグループバージョン 2(cgroups v2) を有効にします。cgroups v2 を有効にするための OpenShift Container Platform プロセスは、すべての cgroup バージョン 1 コントローラーおよび階層を無効にします。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

true

compute

コンピュートノードを設定するマシンの設定。

MachinePool オブジェクトの配列。

compute.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は s390x (デフォルト) です。

文字列

compute.hyperthreading

コンピュートマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

compute.name

compute を使用する場合に必須です。マシンプールの名前。

worker

compute.platform

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

compute.replicas

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

controlPlane

コントロールプレーンを設定するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane.architecture

プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は s390x (デフォルト) です。

文字列

controlPlane.hyperthreading

コントロールプレーンマシンで同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。

重要

同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

Enabled または Disabled

controlPlane.name

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane.platform

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

alibabacloudawsazure, gcpibmcloudnutanixopenstackovirtvsphere、または {}

controlPlane.replicas

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3 のみです (これはデフォルト値です)。

credentialsMode

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンスCloud Credential Operator を参照してください。

注記

AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、credentialsMode パラメーターを MintPassthrough または Manual に設定する必要があります。

MintPassthroughManual、または空の文字列 ("")。

fips

FIPS モードを有効または無効にします。デフォルトは false (無効) です。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。

重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources.source

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources.mirrors

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このフィールドを Internal に設定することは、クラウド以外のプラットフォームおよび IBM Cloud ではサポートされていません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

16.3.8.2. IBM Z のサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、必要なパラメーターの値を変更することができます。

apiVersion: v1
baseDomain: example.com 1
compute: 2
- hyperthreading: Enabled 3
  name: worker
  replicas: 0 4
  architecture : s390x
controlPlane: 5
  hyperthreading: Enabled 6
  name: master
  replicas: 3 7
  architecture : s390x
metadata:
  name: test 8
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 9
    hostPrefix: 23 10
  networkType: OpenShiftSDN
  serviceNetwork: 11
  - 172.30.0.0/16
platform:
  none: {} 12
fips: false 13
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 14
sshKey: 'ssh-ed25519 AAAA...' 15
additionalTrustBundle: | 16
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: 17
- mirrors:
  - <local_repository>/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <local_repository>/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 5
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、 compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
3 6
同時マルチスレッド (SMT) またはハイパースレッディングを有効/無効にするかどうかを指定します。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を Disabled に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。
注記

同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が OpenShift Container Platform ノードで利用できない場合、hyperthreading パラメーターは影響を受けません。

重要

OpenShift Container Platform ノードまたは install-config.yaml ファイルであるかに関係なく hyperthreading を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。

4
OpenShift Container Platform をユーザーによってプロビジョニングされるインフラストラクチャーにインストールする場合は、この値を 0 に設定する必要があります。インストーラーでプロビジョニングされるインストールでは、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。ユーザーによってプロビジョニングされるインストールでは、クラスターのインストールの終了前にコンピュートマシンを手動でデプロイする必要があります。
注記

3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。

7
クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
8
DNS レコードに指定したクラスター名。
9
Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。
注記

クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。

10
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定されている場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
11
サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
12
プラットフォームを none に設定する必要があります。IBM Z インフラストラクチャー用に追加のプラットフォーム設定変数を指定できません。
重要

プラットフォームタイプ none でインストールされたクラスターは、Machine API を使用したコンピューティングマシンの管理など、一部の機能を使用できません。この制限は、クラスターに接続されている計算マシンが、通常はこの機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。

13
FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要

クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。プロセス暗号化ライブラリーでの FIPS 検証済みまたはモジュールの使用は、x86_64 アーキテクチャーでの OpenShift Container Platform デプロイメントでのみサポートされます。

14
<local_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000<credentials> について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。
15
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーの SSH 公開鍵。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

16
additionalTrustBundle パラメーターおよび値を追加します。この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
17
リポジトリーのミラーリングに使用するコマンドの出力の imageContentSources セクションを指定します。

16.3.8.3. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター egress トラフィック (クラスターをホストするクラウドについてのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.clusterNetwork[].cidr、および networking.serviceNetwork[] フィールドの値が設定されます。

    Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、Proxy オブジェクトの status.noProxy フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
    注記

    インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

    注記

    インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

    $ ./openshift-install wait-for install-complete --log-level debug
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

16.3.8.4. 3 ノードクラスターの設定

オプションで、3 台のコントロールプレーンマシンのみで設定される最小の 3 つのノードクラスターにゼロコンピューティングマシンをデプロイできます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。

3 ノードの OpenShift Container Platform 環境では、3 つのコントロールプレーンマシンがスケジュール対象となります。つまり、アプリケーションのワークロードがそれらで実行されるようにスケジュールされます。

前提条件

  • 既存の install-config.yaml ファイルがある。

手順

  • 以下の compute スタンザに示されるように、コンピュートレプリカの数が install-config.yaml ファイルで 0 に設定されることを確認します。

    compute:
    - name: worker
      platform: {}
      replicas: 0
    注記

    デプロイするコンピュートマシンの数にかかわらず、OpenShift Container Platform をユーザーによってプロビジョニングされるインフラストラクチャーにインストールする際に、コンピュートマシンの replicas パラメーターの値を 0 に設定する必要があります。インストーラーでプロビジョニングされるインストールでは、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。これは、コンピュートマシンが手動でデプロイされる、ユーザーによってプロビジョニングされるインストールには適用されません。

    注記

    コントロールプレーンノードの推奨リソースは 6 vCPU および 21 GB です。コントロールプレーンノードが 3 つの場合には、これは最小の 5 ノードクラスターと同等のメモリー + vCPU です。3 つのノードをバックする必要があります。それぞれに、SMT2 が有効な IFL が 3 つ含まれる 120 GB ディスクにインストールします。各コントロールプレーンノードのテスト済みの最小設定とは、120 GB ディスクに 3 つの vCPU および 10 GB が指定された設定です。

3 ノードのクラスターのインストールについては、以下の手順を実行します。

  • ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件のセクションを参照してください。
  • 以下の手順で Kubernetes マニフェストファイルを作成する際に、<installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルの mastersSchedulable パラメーターが true に設定されていることを確認します。これにより、アプリケーションのワークロードがコントロールプレーンノードで実行できます。
  • Red Hat Enterprise Linux CoreOS (RHCOS) マシンを作成する際にはコンピュートノードをデプロイしないでください。

16.3.9. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承し、これらのフィールドは変更できません。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
OpenShift SDN または OVN-Kubernetes などのクラスターネットワークプロバイダー。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプロバイダー設定を指定できます。

16.3.9.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表16.30 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表16.31 defaultNetwork オブジェクト
フィールド説明

type

string

OpenShiftSDN または OVNKubernetes のいずれか。クラスターネットワークプロバイダーはインストール時に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。

openshiftSDNConfig

object

このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。

ovnKubernetesConfig

object

このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。

OpenShift SDN CNI クラスターネットワークプロバイダーの設定

以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。

表16.32 openshiftSDNConfig オブジェクト
フィールド説明

mode

string

OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は NetworkPolicy です。

Multitenant および Subnet の値は、OpenShift Container Platform 3.x との後方互換性を維持するために利用できますが、その使用は推奨されていません。この値は、クラスターのインストール後は変更できません。

mtu

integer

VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 50 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1450 に設定する必要があります。

この値は、クラスターのインストール後は変更できません。

vxlanPort

integer

すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。この値は、クラスターのインストール後は変更できません。

別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。

Amazon Web Services (AWS) では、VXLAN にポート 9000 とポート 9999 間の代替ポートを選択できます。

OpenShift SDN 設定の例

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定

以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。

表16.33 ovnKubernetesConfig object
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 暗号化を有効にするために空のオブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

表16.34 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

destination

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表16.35 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを true に設定すると、egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}

kubeProxyConfig オブジェクト設定

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表16.36 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

16.3.10. Kubernetes マニフェストおよび Ignition 設定ファイルの作成

一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。

インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。

重要
  • OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
注記

マニフェストおよび Ignition ファイルを生成するインストールプログラムはアーキテクチャー固有であり、クライアントイメージミラー から取得できます。インストールプログラムの Linux バージョンは s390x でのみ実行されます。このインストーラープログラムは、Mac OS バージョンとしても利用できます。

前提条件

  • OpenShift Container Platform インストールプログラムを取得していること。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
  • install-config.yaml インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> については、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
    警告

    3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。

    重要

    コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。

  2. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。
  3. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> については、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

16.3.11. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform を独自にプロビジョニングする IBM Z インフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を z/VM ゲスト仮想マシンにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプについて OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS z/VM ゲスト仮想マシンの再起動後に自動的に開始されます。

マシンを作成するには、以下の手順を実行します。

前提条件

  • 作成するマシンがアクセスできるプロビジョニングマシンで稼働している HTTP または HTTPS サーバー。

手順

  1. プロビジョニングマシンで Linux にログインします。
  2. RHCOS イメージミラー から Red Hat Enterprise Linux CoreOS (RHCOS) カーネル、 initramfs および rootfs ファイルを取得します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な kernel、initramfs、および rootfs アーティファクトのみを使用します。

    ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。

    • kernel: rhcos-<version>-live-kernel-<architecture>
    • initramfs: rhcos-<version>-live-initramfs.<architecture>.img
    • rootfs: rhcos-<version>-live-rootfs.<architecture>.img

      注記

      rootfs イメージは FCP および DASD の場合と同じです。

  3. パラメーターファイルを作成します。以下のパラメーターは特定の仮想マシンに固有のものです。

    • ip= には、以下の 7 つのエントリーを指定します。

      1. マシンの IP アドレス。
      2. 空の文字列。
      3. ゲートウェイ。
      4. ネットマスク。
      5. hostname.domainname 形式のマシンホストおよびドメイン名。この値を省略して、RHCOS に決定させるようにします。
      6. ネットワークインターフェイス名。この値を省略して、RHCOS に決定させるようにします。
      7. 静的 IP アドレスを使用する場合、 none を指定します。
    • coreos.inst.ignition_url= の場合、マシンロールの Ignition ファイルを指定します。bootstrap.ignmaster.ign、または worker.ign を使用します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    • coreos.live.rootfs_url= の場合、起動しているカーネルおよび initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    • DASD タイプのディスクへのインストールには、以下のタスクを実行します。

      1. coreos.inst.install_dev= には、dasda を指定します。
      2. rd.dasd= を使用して、 RHCOS がインストールされる DASD を指定します。
      3. その他のパラメーターはすべて変更しません。

        ブートストラップマシンのパラメーターファイルのサンプル bootstrap-0.parm:

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=dasda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/bootstrap.ign \
        ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.dasd=0.0.3490

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

    • FCP タイプのディスクへのインストールには、以下のタスクを実行します。

      1. rd.zfcp=<adapter>,<wwpn>,<lun> を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップについてこのステップを繰り返します。

        注記

        複数のパスを使用してインストールする場合は、問題が発生する可能性があるため、後でではなくインストールの直後にマルチパスを有効にする必要があります。

      2. インストールデバイスを coreos.inst.install_dev=sda に設定します。

        注記

        追加の LUN が NPIV で設定される場合は、FCP に zfcp.allow_lun_scan=0 が必要です。CSI ドライバーを使用するために zfcp.allow_lun_scan=1 を有効にする必要がある場合などには、各ノードが別のノードのブートパーティションにアクセスできないように NPIV を設定する必要があります。

      3. その他のパラメーターはすべて変更しません。

        重要

        マルチパスを完全に有効にするには、インストール後の追加の手順が必要です。詳細は、インストール後のマシン設定タスク の RHCOS でのカーネル引数を使用したマルチパスの有効化を参照してください。

        以下は、マルチパスが設定されたワーカーノードのパラメーターファイルのサンプル worker-1.parm です。

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=sda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/worker.ign \
        ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

  4. FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを z/VM に転送します。FTP でファイルを転送し、仮想リーダーから起動する方法については、Z/VM 環境へのインストール を参照してください。
  5. ブートストラップノードになる z/VM ゲスト仮想マシンの仮想リーダーに対してファイルの punch を実行します。

    IBM ドキュメントの PUNCH を参照してください。

    ヒント

    CP PUNCH コマンドを使用するか、Linux を使用している場合は、vmur コマンドを使用して 2 つの z/VM ゲスト仮想マシン間でファイルを転送できます。

  6. ブートストラップマシンで CMS にログインします。
  7. リーダーからブートストラップマシンに対して IPL を実行します。

    $ ipl c

    IBM ドキュメントの IPL を参照してください。

  8. クラスター内の他のマシンについてこの手順を繰り返します。

16.3.11.1. 詳細の RHCOS インストールリファレンス

このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションについて説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。

16.3.11.1.1. ISO インストールのネットワークおよびボンディングのオプション

ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が指定されていない場合、RHCOS が Ignition 設定ファイルを取得するためにネットワークが必要であることを検知する際に、DHCP が initramfs でアクティベートされます。

重要

ネットワーク引数を手動で追加する場合は、rd.neednet=1 カーネル引数を追加して、ネットワークを initramfs で有効にする必要があります。

以下の情報は、ISO インストール用に RHCOS ノードでネットワークおよびボンディングを設定する例を示しています。この例では、ip=nameserver=、および bond= カーネル引数の使用方法について説明しています。

注記

順序は、カーネル引数の ip=nameserver=、および bond= を追加する場合に重要です。

ネットワークオプションは、システムの起動時に dracut ツールに渡されます。dracut でサポートされるネットワークオプションの詳細は、dracut.cmdline man ページ を参照してください。

次の例は、ISO インストールのネットワークオプションです。

DHCP または静的 IP アドレスの設定

IP アドレスを設定するには、DHCP (ip=dhcp) を使用するか、個別の静的 IP アドレス (ip=<host_ip>) を設定します。静的 IP を設定する場合、各ノードで DNS サーバー IP アドレス (nameserver=<dns_ip>) を特定する必要があります。次の例では、以下を設定します。

  • ノードの IP アドレス: 10.10.10.2
  • ゲートウェイアドレス: 10.10.10.254
  • ネットワーク: 255.255.255.0
  • ホスト名: core0.example.com
  • DNS サーバーアドレス: 4.4.4.41
  • auto-configuration の値を none に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41
注記

DHCP を使用して RHCOS マシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP ベースのデプロイメントの場合、DHCP サーバー設定を使用して RHCOS ノードが使用する DNS サーバーアドレスを定義できます。

静的ホスト名を使用しない IP アドレスの設定

静的ホスト名を割り当てずに IP アドレスを設定できます。静的ホスト名がユーザーによって設定されていない場合は、逆引き DNS ルックアップによって取得され、自動的に設定されます。静的ホスト名なしで IP アドレスを設定するには、次の例を参照してください。

  • ノードの IP アドレス: 10.10.10.2
  • ゲートウェイアドレス: 10.10.10.254
  • ネットワーク: 255.255.255.0
  • DNS サーバーアドレス: 4.4.4.41
  • auto-configuration の値を none に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41
複数のネットワークインターフェイスの指定

複数の ip= エントリーを設定することで、複数のネットワークインターフェイスを指定できます。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
デフォルトゲートウェイとルートの設定

オプション: rd.route= value を設定して、追加のネットワークへのルートを設定できます。

注記

1 つまたは複数のネットワークを設定する場合、1 つのデフォルトゲートウェイが必要です。追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。

  • 次のコマンドを実行して、デフォルトゲートウェイを設定します。

    ip=::10.10.10.254::::
  • 次のコマンドを入力して、追加ネットワークのルートを設定します。

    rd.route=20.20.20.0/24:20.20.20.254:enp2s0
単一インターフェイスでの DHCP の無効化

2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。この例では、enp1s0 インターフェイスには静的ネットワーク設定があり、DHCP は使用されない enp2s0 について無効にされます。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none
DHCP と静的 IP 設定の組み合わせ

以下のように、複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。

ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
個々のインターフェイスでの VLAN の設定

オプション: vlan= パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。

  • ネットワークインターフェイスで VLAN を設定し、静的 IP アドレスを使用するには、次のコマンドを実行します。

    ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
    vlan=enp2s0.100:enp2s0
  • ネットワークインターフェイスで VLAN を設定し、DHCP を使用するには、次のコマンドを実行します。

    ip=enp2s0.100:dhcp
    vlan=enp2s0.100:enp2s0
複数の DNS サーバーの指定

以下のように、各サーバーに nameserver= エントリーを追加して、複数の DNS サーバーを指定できます。

nameserver=1.1.1.1
nameserver=8.8.8.8
複数のネットワークインターフェイスの単一インターフェイスへのボンディング

オプション: bond= オプションを使用して、複数のネットワークインターフェイスを単一のインターフェイスにボンディングできます。次の例を参照してください。

  • ボンディングされたインターフェイスを設定する構文は bond=name[:network_interfaces][:options] です。

    name は、ボンディングデバイス名 (bond0) で、network_interfaces は物理 (イーサネット) インターフェイス (em1,em2) のコンマ区切りリストを表します。options はボンディングオプションのコンマ区切りのリストです。modinfo bonding を入力して、利用可能なオプションを表示します。

  • Bond= を使用してボンディングされたインターフェイスを作成する場合は、IP アドレスの割り当て方法とボンディングされたインターフェイスのその他の情報を指定する必要があります。
  • DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを dhcp に設定します。以下に例を示します。

    bond=bond0:em1,em2:mode=active-backup
    ip=bond0:dhcp
  • 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:em1,em2:mode=active-backup,fail_over_mac=1
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none

共有 OSA/RoCE カードが使用されている場合の問題を回避するために、常にアクティブバックアップモードでオプション fail_over_mac=1 を設定してください。

複数のネットワークインターフェイスの単一インターフェイスへのボンディング

任意: 以下のように、vlan= パラメーターを指定して、DHCP を使用して、ボンディングされたインターフェイスで VLAN を設定できます。

ip=bond0.100:dhcp
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0

次の例を使用して、VLAN でボンディングされたインターフェイスを設定し、静的 IP アドレスを使用します。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0.100:none
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0
ネットワークチーミングの使用

任意: team= パラメーターを指定して、ボンディングの代わりにネットワークチーミングを使用できます。

  • チームインターフェイス設定の構文は team= name [:network_interfaces] です。

    name はチームデバイス名 (team0)、network_interfacesは物理 (イーサネット) インターフェイス (em1、em2) のコンマ区切りリストを表します。

注記

RHCOS が次のバージョンの RHEL に切り替わると、チーミングは非推奨になる予定です。詳細は、Red Hat ナレッジベースアーティクル libvirt-lxc を使用した Linux コンテナー (廃止) を参照してください。

次の例を使用して、ネットワークチームを設定します。

team=team0:em1,em2
ip=team0:dhcp

16.3.12. ブートストラッププロセスの完了まで待機する

OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。

前提条件

  • クラスターの Ignition 設定ファイルを作成している。
  • 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。

手順

  1. ブートストラッププロセスをモニターします。

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
    INFO API v1.24.0 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。

16.3.13. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

16.3.14. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.24.0
    master-1  Ready     master  63m  v1.24.0
    master-2  Ready     master  64m  v1.24.0

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ oc get csr

    出力例

    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.24.0
    master-1  Ready     master  73m  v1.24.0
    master-2  Ready     master  74m  v1.24.0
    worker-0  Ready     worker  11m  v1.24.0
    worker-1  Ready     worker  11m  v1.24.0

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

16.3.15. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.11.0    True        False         False      19m
    baremetal                                  4.11.0    True        False         False      37m
    cloud-credential                           4.11.0    True        False         False      40m
    cluster-autoscaler                         4.11.0    True        False         False      37m
    config-operator                            4.11.0    True        False         False      38m
    console                                    4.11.0    True        False         False      26m
    csi-snapshot-controller                    4.11.0    True        False         False      37m
    dns                                        4.11.0    True        False         False      37m
    etcd                                       4.11.0    True        False         False      36m
    image-registry                             4.11.0    True        False         False      31m
    ingress                                    4.11.0    True        False         False      30m
    insights                                   4.11.0    True        False         False      31m
    kube-apiserver                             4.11.0    True        False         False      26m
    kube-controller-manager                    4.11.0    True        False         False      36m
    kube-scheduler                             4.11.0    True        False         False      36m
    kube-storage-version-migrator              4.11.0    True        False         False      37m
    machine-api                                4.11.0    True        False         False      29m
    machine-approver                           4.11.0    True        False         False      37m
    machine-config                             4.11.0    True        False         False      36m
    marketplace                                4.11.0    True        False         False      37m
    monitoring                                 4.11.0    True        False         False      29m
    network                                    4.11.0    True        False         False      38m
    node-tuning                                4.11.0    True        False         False      37m
    openshift-apiserver                        4.11.0    True        False         False      32m
    openshift-controller-manager               4.11.0    True        False         False      30m
    openshift-samples                          4.11.0    True        False         False      32m
    operator-lifecycle-manager                 4.11.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.11.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.11.0    True        False         False      32m
    service-ca                                 4.11.0    True        False         False      38m
    storage                                    4.11.0    True        False         False      37m

  2. 利用不可の Operator を設定します。

16.3.15.1. デフォルトの OperatorHub ソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。Administration Cluster Settings Configuration OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

16.3.15.2. イメージレジストリーストレージの設定

イメージレジストリー Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定についての手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

16.3.15.2.1. IBM Z の場合のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • IBM Z にクラスターがある。
  • Red Hat OpenShift Data Foundation などのクラスターのプロビジョニングされた永続ストレージがある。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • 100 Gi の容量がある。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim:

    claim フィールドを空のままにし、image-registry-storage PVC の自動作成を可能にします。

  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.11                 True        False         False      6h50m

  5. イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。

    • 以下を実行します。

      $ oc edit configs.imageregistry/cluster

      次に、行を変更します。

      managementState: Removed

      次のように変更してください。

      managementState: Managed
16.3.15.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

イメージレジストリー Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    イメージレジストリー Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

16.3.16. ユーザーによってプロビジョニングされるインフラストラクチャーでのインストールの完了

Operator 設定の完了後に、提供するインフラストラクチャーでのクラスターのインストールを終了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

  1. 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.11.0    True        False         False      19m
    baremetal                                  4.11.0    True        False         False      37m
    cloud-credential                           4.11.0    True        False         False      40m
    cluster-autoscaler                         4.11.0    True        False         False      37m
    config-operator                            4.11.0    True        False         False      38m
    console                                    4.11.0    True        False         False      26m
    csi-snapshot-controller                    4.11.0    True        False         False      37m
    dns                                        4.11.0    True        False         False      37m
    etcd                                       4.11.0    True        False         False      36m
    image-registry                             4.11.0    True        False         False      31m
    ingress                                    4.11.0    True        False         False      30m
    insights                                   4.11.0    True        False         False      31m
    kube-apiserver                             4.11.0    True        False         False      26m
    kube-controller-manager                    4.11.0    True        False         False      36m
    kube-scheduler                             4.11.0    True        False         False      36m
    kube-storage-version-migrator              4.11.0    True        False         False      37m
    machine-api                                4.11.0    True        False         False      29m
    machine-approver                           4.11.0    True        False         False      37m
    machine-config                             4.11.0    True        False         False      36m
    marketplace                                4.11.0    True        False         False      37m
    monitoring                                 4.11.0    True        False         False      29m
    network                                    4.11.0    True        False         False      38m
    node-tuning                                4.11.0    True        False         False      37m
    openshift-apiserver                        4.11.0    True        False         False      32m
    openshift-controller-manager               4.11.0    True        False         False      30m
    openshift-samples                          4.11.0    True        False         False      32m
    operator-lifecycle-manager                 4.11.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.11.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.11.0    True        False         False      32m
    service-ca                                 4.11.0    True        False         False      38m
    storage                                    4.11.0    True        False         False      37m

    あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
  2. Kubernetes API サーバーが Pod と通信していることを確認します。

    1. すべての Pod のリストを表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

    2. 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後のマシン設定タスク ドキュメントの RHCOS でのカーネル引数を使用したマルチパスの有効化を参照してください。

  4. Cluster registration ページでクラスターを登録します。

16.3.17. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.