インストール設定
インストール中のクラスター全体の設定
概要
第1章 ノードのカスタマイズ
OpenShift Container Platform は、Ignition を介してクラスター全体の設定とマシンごとの設定の両方をサポートしています。そのため、オペレーティングシステムに対する任意のパーティショニングとファイルコンテンツの変更が可能です。一般に、設定ファイルが Red Hat Enterprise Linux (RHEL) で文書化されている場合、Ignition を介した変更がサポートされます。
マシン設定の変更をデプロイするには 2 つの方法があります。
-
openshift-install
の実行時にクラスターを起動するためにマニフェストファイルに組み込まれるマシン設定を作成します。 - Machine Config Operator を使用して実行中の OpenShift Container Platform ノードに渡されるマシン設定を作成します。
さらに、ベアメタルノードのインストール時に coreos-installer
に渡される Ignition 設定などの参照設定を変更すると、マシンごとの設定が可能になります。現在、これらの変更はマシン設定オペレーターに表示されません。
以下のセクションでは、この方法でノード上で設定する必要が生じる可能性のある機能を説明します。
1.1. Butane でのマシン設定の作成
マシン設定は、ユーザーおよびファイルシステムの作成、ネットワークの設定、systemd ユニットのインストールなどを行う方法をマシンに指示することで、コントロールプレーンマシンおよびワーカーマシンを設定するために使用されます。
マシン設定の変更は困難である可能性があるため、Butane 設定を使用してマシン設定を作成することができます。これにより、ノードの設定がより容易になります。
1.1.1. Butane について
Butane は、OpenShift Container Platform が使用するコマンドラインユーティリティーで、マシン設定を作成するための便利で簡略化した構文を提供したり、マシン設定の追加検証を実行したりします。Butane が受け入れる Butane 設定ファイルの形式は、OpenShift Butane config spec で定義されています。
1.1.2. Butane のインストール
Butane ツール (butane
) をインストールして、コマンドラインインターフェイスから OpenShift Container Platform マシン設定を作成できます。対応するバイナリーファイルをダウンロードし、Linux、Windows、または macOS に butane
をインストールできます。
Butane リリースは、古いリリースと、Fedora CoreOS Config Transpiler (FCCT) との後方互換性があります。
手順
- Butane イメージのダウンロードページ (https://mirror.openshift.com/pub/openshift-v4/clients/butane/) に移動してください。
butane
バイナリーを取得します。最新バージョンの Butane の場合は、最新の
butane
イメージを現在のディレクトリーに保存します。$ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane --output butane
オプション: aarch64 や ppc64le など、Butane をインストールする特定のタイプのアーキテクチャーの場合は、適切な URL を指定してください。以下に例を示します。
$ curl https://mirror.openshift.com/pub/openshift-v4/clients/butane/latest/butane-aarch64 --output butane
ダウンロード済みのバイナリーファイルを実行可能にします。
$ chmod +x butane
butane
バイナリーファイルをPATH
にあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
検証手順
butane
コマンドを実行して、Butane ツールを使用できるようになりました。$ butane <butane_file>
1.1.3. Butane を使用した MachineConfig オブジェクトの作成
Butane を使用して MachineConfig
オブジェクトを作成できるため、インストール時に、または Machine Config Operator を使用して、ワーカーノードまたはコントロールプレーンノードを設定できます。
前提条件
-
butane
ユーティリティーをインストールした。
手順
Butane 設定ファイルを作成します。以下の例では、
99-worker-custom.bu
という名前のファイルを作成します。このファイルは、カーネルデバッグメッセージを表示するようにシステムコンソールを設定し、chrony タイムサービスのカスタム設定を指定します。variant: openshift version: 4.16.0 metadata: name: 99-worker-custom labels: machineconfiguration.openshift.io/role: worker openshift: kernel_arguments: - loglevel=7 storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | pool 0.rhel.pool.ntp.org iburst driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony
注記99-worker-custom.bu
ファイルは、ワーカーノードのマシン設定を作成するように設定されます。コントロールプレーンノードにデプロイするには、ロールをworker
からmaster
に変更します。どちらの方法でも、デプロイメントの種類ごとに異なるファイル名を使用して手順全体を繰り返すことができます。直前の手順で作成したファイルを Butane に指定して
MachineConfig
オブジェクトを作成します。$ butane 99-worker-custom.bu -o ./99-worker-custom.yaml
MachineConfig
オブジェクト YAML ファイルは、マシンの設定を終了するために作成されます。-
将来的に
MachineConfig
オブジェクトを更新する必要がある場合に備えて、Butane 設定を保存します。 クラスターがまだ起動していない場合は、マニフェストファイルを生成し、
MachineConfig
オブジェクト YAML ファイルをopenshift
ディレクトリーに追加します。クラスターがすでに実行中の場合は、ファイルを以下のように適用します。$ oc create -f 99-worker-custom.yaml
1.2. day-1 カーネル引数の追加
多くの場合、カーネル引数を day-2 アクティビティーとして変更することが推奨されますが、初期クラスターのインストール時にすべてのマスターまたはワーカーノードにカーネル引数を追加することができます。以下は、クラスターのインストール時にカーネル引数を追加して、システムの初回起動前に有効にする必要が生じる可能性のある理由です。
- システムの起動前に、低レベルのネットワーク設定を実行する必要がある場合。
SELinux などの機能を無効にし、初回起動時にシステムに影響を与えないようにする必要がある場合。
警告実稼働環境の RHCOS での SELinux の無効化はサポートされていません。ノード上で SELinux が無効になったら、再プロビジョニングしてから実稼働クラスターに再び追加する必要があります。
カーネル引数をマスターまたはワーカーノードに追加するには、MachineConfig
オブジェクトを作成し、そのオブジェクトをクラスターのセットアップ時に Ignition が使用するマニフェストファイルのセットに挿入することができます。
起動時に RHEL 8 カーネルに渡すことのできる引数のリストは、Kernel.org カーネルパラメーター を参照してください。カーネル引数が OpenShift Container Platform の初回インストールを完了するために必要な場合は、この手順でカーネル引数のみを追加することが推奨されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory>
- カーネル引数をワーカーまたコントロールプレーンノードに追加するかどうかを決定します。
openshift
ディレクトリーでファイル (例:99-openshift-machineconfig-master-kargs.yaml
) を作成し、カーネル設定を追加するためにMachineConfig
オブジェクトを定義します。この例では、loglevel=7
カーネル引数をコントロールプレーンノードに追加します。$ cat << EOF > 99-openshift-machineconfig-master-kargs.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-openshift-machineconfig-master-kargs spec: kernelArguments: - loglevel=7 EOF
カーネル引数をワーカーノードに追加する場合は、
master
をworker
に切り替えます。マスターおよびワーカーノードの両方に追加するために別々の YAML ファイルを作成します。
クラスターの作成を継続できます。
1.3. カーネルモジュールのノードへの追加
大半の一般的なハードウェアの場合、Linux カーネルには、コンピューターの起動時にそのハードウェアを使用するために必要となるデバイスドライバーモジュールが含まれます。ただし、一部のハードウェアの場合、Linux でモジュールを利用できません。したがって、各ホストコンピューターにこれらのモジュールを提供する方法を確保する必要があります。この手順では、OpenShift Container Platform クラスターのノードについてこれを実行する方法を説明します。
この手順に従ってカーネルモジュールを最初にデプロイする際、モジュールは現行のカーネルに対して利用可能になります。新規カーネルがインストールされると、kmods-via-containers ソフトウェアはモジュールを再ビルドし、デプロイしてそのモジュールの新規カーネルと互換性のあるバージョンが利用可能になるようにします。
この機能によって各ノードでモジュールが最新の状態に保てるようにするために、以下が実行されます。
- 新規カーネルがインストールされているかどうかを検出するために、システムの起動時に起動する各ノードに systemd サービスを追加します。
- 新規カーネルが検出されると、サービスはモジュールを再ビルドし、これをカーネルにインストールします。
この手順に必要なソフトウェアの詳細は、kmods-via-containers github サイトを参照してください。
以下の重要な点に留意してください。
- この手順はテクノロジープレビューです。
-
ソフトウェアのツールおよびサンプルは公式の RPM 形式で利用できず、現時点ではこの手順に記載されている非公式の
github.com
サイトからしか取得できません。 - この手順で追加する必要がある可能性のあるサードパーティーのカーネルモジュールについては Red Hat はサポートしません。
-
この手順では、カーネルモジュールのビルドに必要なソフトウェアは RHEL 8 コンテナーにデプロイされます。モジュールは、ノードが新規カーネルを取得する際に各ノードで自動的に再ビルドされることに注意してください。このため、各ノードには、モジュールの再ビルドに必要なカーネルと関連パッケージを含む
yum
リポジトリーへのアクセスが必要です。このコンテンツは、有効な RHEL サブスクリプションを使用して効果的に利用できます。
1.3.1. カーネルモジュールコンテナーのビルドおよびテスト
カーネルモジュールを OpenShift Container Platform クラスターにデプロイする前に、プロセスを別の RHEL システムでテストできます。カーネルモジュールのソースコード、KVC フレームワーク、および kmod-via-containers ソフトウェアを収集します。次にモジュールをビルドし、テストします。RHEL 8 システムでこれを行うには、以下を実行します。
手順
RHEL 8 システムを登録します。
# subscription-manager register
RHEL 8 システムにサブスクリプションを割り当てます。
# subscription-manager attach --auto
ソフトウェアとコンテナーのビルドに必要なソフトウェアをインストールします。
# yum install podman make git -y
kmod-via-containers
リポジトリーのクローンを作成します。リポジトリーのフォルダーを作成します。
$ mkdir kmods; cd kmods
リポジトリーのクローンを作成します。
$ git clone https://github.com/kmods-via-containers/kmods-via-containers
RHEL 8 ビルドホストに KVC フレームワークインスタンスをインストールし、モジュールをテストします。これにより、
kmods-via-container
systemd サービスが追加され、読み込まれます。kmod-via-containers
ディレクトリーに移動します。$ cd kmods-via-containers/
KVC フレームワークインスタンスをインストールします。
$ sudo make install
systemd マネージャー設定を再読み込みします。
$ sudo systemctl daemon-reload
カーネルモジュールのソースコードを取得します。ソースコードは、制御下になく、他から提供されるサードパーティーモジュールをビルドするために使用される可能性があります。システムに対してクローン作成できる以下の
kvc-simple-kmod
サンプルのコンテンツと同様のコンテンツが必要になります。$ cd .. ; git clone https://github.com/kmods-via-containers/kvc-simple-kmod
この例では、設定ファイル
simple-kmod.conf
を編集し、Dockerfile の名前をDockerfile.rhel
に変更します。kvc-simple-kmod
ディレクトリーに移動します。$ cd kvc-simple-kmod
Dockerfile の名前を変更します。
$ cat simple-kmod.conf
Dockerfile の例
KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git" KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel KMOD_SOFTWARE_VERSION=dd1a7d4 KMOD_NAMES="simple-kmod simple-procfs-kmod"
この例ではカーネルモジュール
simple-kmod
のkmods-via-containers@.service
のインスタンスを作成します。$ sudo make install
kmods-via-containers@.service
インスタンスを有効にします。$ sudo kmods-via-containers build simple-kmod $(uname -r)
systemd サービスを有効にし、起動します。
$ sudo systemctl enable kmods-via-containers@simple-kmod.service --now
サービスのステータスを確認します。
$ sudo systemctl status kmods-via-containers@simple-kmod.service
出力例
● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service; enabled; vendor preset: disabled) Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...
カーネルモジュールがロードされていることを確認するには、
lsmod
コマンドを使用してモジュールをリスト表示します。$ lsmod | grep simple_
出力例
simple_procfs_kmod 16384 0 simple_kmod 16384 0
オプション: 他の方法を使用して
simple-kmod
のサンプルが機能していることを確認します。dmesg
を使用してカーネルリングバッファーで "Hello world" メッセージを探します。$ dmesg | grep 'Hello world'
出力例
[ 6420.761332] Hello world from simple_kmod.
/proc
でsimple-procfs-kmod
の値を確認します。$ sudo cat /proc/simple-procfs-kmod
出力例
simple-procfs-kmod number = 0
spkut
コマンドを実行して、モジュールの詳細情報を取得します。$ sudo spkut 44
出力例
KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64 Running userspace wrapper using the kernel module container... + podman run -i --rm --privileged simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44 simple-procfs-kmod number = 0 simple-procfs-kmod number = 44
その後は、システムの起動時に、このサービスは新規カーネルが実行中であるかどうかをチェックします。新規カーネルがある場合は、サービスは新規バージョンのカーネルモジュールをビルドし、これをロードします。モジュールがすでにビルドされている場合は、これをロードします。
1.3.2. カーネルモジュールの OpenShift Container Platform へのプロビジョニング
OpenShift Container Platform クラスターの初回起動時にカーネルモジュールを有効にする必要があるかどうかに応じて、以下のいずれかの方法でデプロイするようにカーネルモジュールを設定できます。
-
クラスターインストール時のカーネルモジュールのプロビジョニング (day-1): コンテンツを
MachineConfig
として作成し、これをマニフェストファイルのセットと共に組み込み、これをopenshift-install
に提供できます。 - Machine Config Operator によるカーネルモジュールのプロビジョニング (day-2): カーネルモジュールを追加する際にクラスターが稼働するまで待機できる場合、Machine Config Operator (MCO) を使用してカーネルモジュールソフトウェアをデプロイできます。
いずれの場合も、各ノードは、新規カーネルの検出時にカーネルパッケージと関連ソフトウェアパッケージを取得できる必要があります。該当するコンテンツを取得できるように各ノードをセットアップする方法はいくつかあります。
- 各ノードに RHEL エンタイトルメントを提供します。
-
/etc/pki/entitlement
ディレクトリーから、既存 RHEL ホストの RHEL エンタイトルメントを取得し、それらを Ignition 設定の作成時に提供する他のファイルと同じ場所にコピーします。 -
Dockerfile 内で、カーネルおよびその他のパッケージを含む
yum
リポジトリーへのポインターを追加します。これには、新たにインストールされたカーネルと一致させる必要があるため、新規のカーネルパッケージが含まれている必要があります。
1.3.2.1. MachineConfig オブジェクトを介したカーネルモジュールのプロビジョニング
MachineConfig
オブジェクトでカーネルモジュールソフトウェアをパッケージ化することで、そのソフトウェアをインストール時に、または Machine Config Operator を使用して、ワーカーノードまたはコントロールプレーンノードに配信できます。
手順
RHEL 8 システムを登録します。
# subscription-manager register
RHEL 8 システムにサブスクリプションを割り当てます。
# subscription-manager attach --auto
ソフトウェアのビルドに必要なソフトウェアをインストールします。
# yum install podman make git -y
カーネルモジュールおよびツールをホストするディレクトリーを作成します。
$ mkdir kmods; cd kmods
kmods-via-containers
ソフトウェアを取得します。kmods-via-containers
リポジトリーのクローンを作成します。$ git clone https://github.com/kmods-via-containers/kmods-via-containers
kvc-simple-kmod
リポジトリーのクローンを作成します。$ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
-
モジュールソフトウェアを取得します。この例では、
kvc-simple-kmod
が使用されます。 fakeroot ディレクトリーを作成し、先にクローン作成したリポジトリーを使用して Ignition で配信するファイルを使用してこれを設定します。
ディレクトリーを作成します。
$ FAKEROOT=$(mktemp -d)
kmod-via-containers
ディレクトリーに移動します。$ cd kmods-via-containers
KVC フレームワークインスタンスをインストールします。
$ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
kvc-simple-kmod
ディレクトリーに移動します。$ cd ../kvc-simple-kmod
インスタンスを作成します。
$ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
fakeroot ディレクトリーのクローンを作成し、以下のコマンドを実行してシンボリックリンクをターゲットのコピーに置き換えます。
$ cd .. && rm -rf kmod-tree && cp -Lpr ${FAKEROOT} kmod-tree
カーネルモジュールツリーを埋め込む Butane 設定ファイル (
99-simple-kmod.bu
) を作成し、systemd サービスを有効にします。注記Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
variant: openshift version: 4.16.0 metadata: name: 99-simple-kmod labels: machineconfiguration.openshift.io/role: worker 1 storage: trees: - local: kmod-tree systemd: units: - name: kmods-via-containers@simple-kmod.service enabled: true
- 1
- コントロールプレーンノードでデプロイするには、
worker
をmaster
に変更します。コントロールプレーンおよびワーカーノードの両方にデプロイするには、それぞれのノードのタイプに対してこれらの残りの手順を 1 回ずつ実行します。
Butane を使用して、配信されるファイルおよび設定を含むマシン設定 YAML ファイルの
99-simple-kmod.yaml
を生成します。$ butane 99-simple-kmod.bu --files-dir . -o 99-simple-kmod.yaml
クラスターがまだ起動していない場合は、マニフェストファイルを生成し、そのファイルを
openshift
ディレクトリーに追加します。クラスターがすでに実行中の場合は、ファイルを以下のように適用します。$ oc create -f 99-simple-kmod.yaml
ノードは
kmods-via-containers@simple-kmod.service
サービスを起動し、カーネルモジュールがロードされます。カーネルモジュールがロードされていることを確認するには、ノードにログインすることができます (
oc debug node/<openshift-node>
を使用してからchroot /host
を使用します)。モジュールをリスト表示するには、lsmod
コマンドを使用します。$ lsmod | grep simple_
出力例
simple_procfs_kmod 16384 0 simple_kmod 16384 0
1.4. インストール時のディスクの暗号化およびミラーリング
OpenShift Container Platform のインストール時に、クラスターノードでブートディスクの暗号化およびミラーリングを有効にできます。
1.4.1. ディスクの暗号化について
インストール時に、コントロールプレーンおよびコンピュートノードのブートディスクの暗号化を有効できます。OpenShift Container Platform は Trusted Platform Module (TPM) v2 および Tang 暗号化モードをサポートします。
- TPM v2
- これは優先モードです。TPM v2 は、パスフレーズをサーバー上の安全な暗号プロセッサーに保存します。このモードを使用すると、ディスクがサーバーから取り外された場合に、クラスターノード上のブートディスクデータの暗号化が解除されないようにすることができます。
- Tang
- Tang および Clevis は、ネットワークバインドディスク暗号化 (NBDE) を有効にするサーバーおよびクライアントコンポーネントです。クラスターノードのブートディスクデータを 1 つまたは複数の Tang サーバーにバインドできます。これにより、ノードが Tang サーバーにアクセスできる安全なネットワーク上にない限り、データの復号化が防止されます。Clevis は、クライアント側の復号化の実装に使用される自動復号化フレームワークです。
Tang 暗号化モードを使用したディスクの暗号化は、user-provisioned infrastructure でのベアメタルおよび vSphere インストールでのみサポートされます。
以前のバージョンの Red Hat Enterprise Linux CoreOS (RHCOS) では、ディスク暗号化は Ignition 設定で /etc/clevis.json
を指定して設定されました。このファイルは、OpenShift Container Platform 4.7 以降で作成されたクラスターではサポートされていません。次の手順を使用して、ディスク暗号化を設定します。
TPM v2 または Tang 暗号化モードを有効にすると、RHCOS ブートディスクは LUKS2 形式を使用して暗号化されます。
この機能には以下の特徴があります。
- installer-provisioned infrastructure、user-provisioned infrastructure、および Assisted Installer のデプロイメントで利用可能
Assisted Installer のデプロイメントの場合:
- 各クラスターは、Tang または TPM の 1 つの暗号化方式のみを持つことができます
- 一部またはすべてのノードで暗号化を有効にできます
- Tang のしきい値はありません。すべてのサーバーが有効で動作している必要があります
- 暗号化はインストールディスクのみに適用され、ワークロードディスクには適用されません
- Red Hat Enterprise Linux CoreOS (RHCOS) システムのみでサポートされる。
- マニフェストのインストール段階でディスク暗号化を設定し、最初の起動以降、ディスクに書き込まれるすべてのデータを暗号化します
- パスフレーズを提供するのにユーザーの介入を必要としない。
- FIPS モードが有効な場合は、AES-256-XTS 暗号化、または AES-256-CBC を使用します。
1.4.1.1. 暗号化しきい値の設定
OpenShift Container Platform では、複数の Tang サーバーの要件を指定できます。TPM v2 と Tang 暗号化モードを同時に設定することもできます。これにより、TPM セキュア暗号プロセッサーが存在し、Tang サーバーがセキュアネットワーク経由でアクセスできる場合にのみ、ブートディスクデータの復号化が有効になります。
ブタン設定で threshold
属性を使用して、復号化が発生するために必要な TPM v2 および Tang 暗号化条件の最小数を定義できます。
宣言条件の組み合わせで指定値に到達した場合に、しきい値が満たされます。オフラインプロビジョニングの場合、オフラインサーバーは含まれているアドバタイズメントを使用してアクセスされ、オンラインサーバーの数が設定されたしきい値を満たさない場合にのみ、その提供されたアドバタイズメントを使用します。
たとえば、次の設定の threshold
2
は、オフラインサーバーをバックアップとして使用して 2 つの Tang サーバーにアクセスするか、TPM セキュア暗号プロセッサーといずれかの Tang サーバーにアクセスすることによって到達できます。
ディスク暗号化の Butane 設定例
variant: openshift version: 4.16.0 metadata: name: worker-storage labels: machineconfiguration.openshift.io/role: worker boot_device: layout: x86_64 1 luks: tpm2: true 2 tang: 3 - url: http://tang1.example.com:7500 thumbprint: jwGN5tRFK-kF6pIX89ssF3khxxX - url: http://tang2.example.com:7500 thumbprint: VCJsvZFjBSIHSldw78rOrq7h2ZF - url: http://tang3.example.com:7500 thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 advertisement: "{\"payload\": \"...\", \"protected\": \"...\", \"signature\": \"...\"}" 4 threshold: 2 5 openshift: fips: true
- 1
- このフィールドをクラスターノードの命令セットアーキテクチャーに設定します。いくつかの例には、
x86_64
、aarch64
、またはppc64le
が含まれます。 - 2
- Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。
- 3
- 1 台以上の Tang サーバーを使用する必要がある場合は、このセクションを追加してください。
- 4
- オプション: オフラインプロビジョニングにこのフィールドを含めます。Ignition は、実行時にサーバーからアドバタイズメントを取得するのではなく、Tang サーバーバインディングをプロビジョニングします。これにより、プロビジョニング時にサーバーが利用できなくなります。
- 5
- 復号化を行うために必要な TPM v2 および Tang 暗号化条件の最小数を指定します。
デフォルトの しきい値
は 1
です。設定に複数の暗号化条件を追加するにも拘らず、しきい値を指定しない場合は、条件のいずれかが満たされている場合に復号化を実行できます。
復号化に TPM v2 と Tang が必要な場合、threshold
属性の値は、指定された Tang サーバーの総数に 1 を加えた数に等しくなければなりません。threshold
が低い場合は、単一の暗号化モードを使用してしきい値に達する可能性があります。たとえば、tpm2
を true
に設定し、2 つの Tang サーバーを指定した場合、TPM セキュア暗号プロセッサーが利用できない場合でも、2 つの Tang サーバーにアクセスすることでしきい値 2
を満たすことができます。
1.4.2. ディスクのミラーリングについて
コントロールプレーンおよびワーカーノードでの OpenShift Container Platform のインストール時に、ブートおよびその他のディスクの 2 つ以上の冗長ストレージデバイスへのミラーリングを有効にできます。1 つのデバイスが使用可能なままであれば、ストレージデバイスの障害後もノードは機能し続けます。
ミラーリングは、障害の発生したディスクの置き換えをサポートしません。ノードを再プロビジョニングして、ミラーを本来の劣化していない状態に復元します。
user-provisioned infrastructure のデプロイメントの場合、ミラーリングは RHCOS システムのみで使用できます。ミラーリングのサポートは、BIOS または UEFI で起動された x86_64
ノードおよび ppc64le
ノードで利用できます。
1.4.3. ディスク暗号化およびミラーリングの設定
OpenShift Container Platform のインストール時に暗号化およびミラーリングを有効にし、設定することができます。
前提条件
- インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
インストールノードに Butane がインストールされている。
注記Butane は、OpenShift Container Platform が使用するコマンドラインユーティリティーであり、マシンの設定を記述および検証するための便利で簡潔な構文を提供します。詳細は、「Butane を使用したマシン設定の作成」を参照してください。
- Tang 交換キーのサムプリントの生成に使用できる Red Hat Enterprise Linux (RHEL) 8 マシンにアクセスできる。
手順
- TPM v2 を使用してクラスターを暗号化する必要がある場合、TPM v2 暗号化を各ノードのホストファームウェアで有効にする必要があるかどうかを確認します。これは、ほとんどの Dell システムで必要になります。特定のシステムのマニュアルを確認してください。
Tang を使用してクラスターを暗号化する必要がある場合は、以下の準備段階の手順に従います。
- Tang サーバーを設定するか、既存のサーバーにアクセスします。手順は、NBDE (Network-Bound Disk Encryption) を参照してください。
RHEL 8 マシンに
clevis
パッケージがインストールされていない場合はインストールします。$ sudo yum install clevis
RHEL 8 マシンで以下のコマンドを実行し、交換キーのサムプリントを生成します。
http://tang1.example.com:7500
を Tang サーバーの URL に置き換えます。$ clevis-encrypt-tang '{"url":"http://tang1.example.com:7500"}' < /dev/null > /dev/null 1
- 1
- この例では、
tangd.socket
は Tang サーバーのポート7500
でリッスンしています。
注記clevis-encrypt-tang
コマンドは、交換キーの拇印を生成します。このステップでは、データは暗号化コマンドに渡されません。/dev/null
は、プレーンテキストの代わりに入力としてここに存在します。この手順には必要ないため、暗号化された出力は/dev/null
に送信されます。出力例
The advertisement contains the following signing keys: PLjNyRdGw03zlRoGjQYMahSZGu9 1
- 1
- エクスチェンジキーのサムプリント。
Do you wish to trust these keys? [ynYN]
のプロンプトが表示されたら、Y
と入力します 。オプション: オフライン Tang プロビジョニングの場合は、以下を行います。
curl
コマンドを使用して、サーバーからアドバタイズメントを取得します。http://tang2.example.com:7500
を Tang サーバーの URL に置き換えます。$ curl -f http://tang2.example.com:7500/adv > adv.jws && cat adv.jws
予想される出力
{"payload": "eyJrZXlzIjogW3siYWxnIjogIkV", "protected": "eyJhbGciOiJFUzUxMiIsImN0eSI", "signature": "ADLgk7fZdE3Yt4FyYsm0pHiau7Q"}
暗号化のためにアドバタイズメントファイルを Clevis に提供します。
$ clevis-encrypt-tang '{"url":"http://tang2.example.com:7500","adv":"adv.jws"}' < /dev/null > /dev/null
ノードが静的 IP アドレス指定で設定されている場合は、RHCOS ノードをインストールするときに
coreos-installer iso customize --dest-karg-append
を実行するか、coreos-installer
--append-karg
オプションを使用して、インストール済みシステムの IP アドレスを設定します。ネットワークに必要なip=
およびその他の引数を追加します。重要一部の静的 IP の設定方法は、初回のブート後に initramfs に影響を与えず、Tang 暗号化では機能しない場合があります。これらには、
coreos-installer
--copy-network
オプション、coreos-installer iso customize
--network-keyfile
オプション、およびcoreos-installer pxe customize
--network-keyfile
オプションが含まれるほか、インストール中のライブ ISO または PXE イメージのカーネルコマンドラインにip=
引数が追加されます。静的 IP 設定が間違っていると、ノードの 2 回目のブートが失敗します。
インストールノードで、インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
は、インストールファイルを保存するディレクトリーへのパスに置き換えます。
ディスクの暗号化、ミラーリング、またはそれら両方を設定する Butane 設定を作成します。たとえば、コンピュートノードのストレージを設定するには、
$HOME/clusterconfig/worker-storage.bu
ファイルを作成します。起動デバイスの Butane 設定例
variant: openshift version: 4.16.0 metadata: name: worker-storage 1 labels: machineconfiguration.openshift.io/role: worker 2 boot_device: layout: x86_64 3 luks: 4 tpm2: true 5 tang: 6 - url: http://tang1.example.com:7500 7 thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 8 - url: http://tang2.example.com:7500 thumbprint: VCJsvZFjBSIHSldw78rOrq7h2ZF advertisement: "{"payload": "eyJrZXlzIjogW3siYWxnIjogIkV", "protected": "eyJhbGciOiJFUzUxMiIsImN0eSI", "signature": "ADLgk7fZdE3Yt4FyYsm0pHiau7Q"}" 9 threshold: 1 10 mirror: 11 devices: 12 - /dev/sda - /dev/sdb openshift: fips: true 13
- 1 2
- コントロールプレーンの設定は、これらの両方の場所で
worker
をmaster
に置き換えます。 - 3
- このフィールドをクラスターノードの命令セットアーキテクチャーに設定します。いくつかの例には、
x86_64
、aarch64
、またはppc64le
が含まれます。 - 4
- ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。詳細は、「ディスクの暗号化について」を参照してください。
- 5
- Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。
- 6
- 1 台以上の Tang サーバーを使用する必要がある場合は、このセクションを追加してください。
- 7
- Tang サーバーの URL を指定します。この例では、
tangd.socket
は Tang サーバーのポート7500
でリッスンしています。 - 8
- 前述のステップで生成された Exchange キーサムプリントを指定します。
- 9
- オプション: オフライン Tang サーバーのアドバタイズメントを有効な JSON 形式で指定します。
- 10
- 復号化に実行に必要な TPM v2 および Tang 暗号化条件の最小数を指定します。デフォルト値は
1
です。このトピックの詳細は、「暗号化しきい値の設定」を参照してください。 - 11
- ブートディスクをミラーリングする必要がある場合は、このセクションを追加してください。詳細は、「ディスクのミラーリングについて」を参照してください。
- 12
- RHCOS がインストールされるディスクを含む、ブートディスクミラーに含まれる必要があるすべてのディスクデバイスを一覧表示します。
- 13
- クラスターで FIPS モードを有効にするためにこのディレクティブを追加します。
重要クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。ノードをディスク暗号化とミラーリングの両方を使用するように設定する場合、両方の機能を同じ Butane 設定ファイルに設定する必要があります。FIPS モードが有効にされたノードでディスク暗号化を設定する場合は、FIPS モードが別のマニフェストで有効化されている場合でも、同じ Butane 設定ファイルに
fips
ディレクティブを追加する必要があります。対応する Butane 設定ファイルからコントロールプレーンまたはコンピュートノードのマニフェストを作成し、
<installation_directory>/openshift
ディレクトリーに保存します。たとえば、コンピュートノードのマニフェストを作成するには、以下のコマンドを実行します。$ butane $HOME/clusterconfig/worker-storage.bu -o <installation_directory>/openshift/99-worker-storage.yaml
ディスクの暗号化またはミラーリングを必要とするノード種別ごとに、この手順を繰り返します。
- 今後マニフェストを更新する必要がある場合には、Butane 設定ファイルを保存します。
残りの OpenShift Container Platform インストールを継続します。
ヒントインストール時に、ディスク暗号化またはミラーリングに関連するエラーメッセージがないか、RHCOS ノードでコンソールログをモニタリングできます。
重要追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。
検証
OpenShift Container Platform のインストール後に、ブートディスクの暗号化またはミラーリングがクラスターノードで有効にされているかどうかを確認できます。
インストールホストから、デバッグ Pod を使用してクラスターノードにアクセスします。
ノードのデバッグ Pod を開始します。次に例を示します。
$ oc debug node/compute-1
/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にノードのルートファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ノードの実行可能パスに含まれるバイナリーを実行できます。# chroot /host
注記Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、OpenShift Container Platform API が利用できない場合や、
kubelet
がターゲットノードで適切に機能しない場合、oc
操作がその影響を受けます。この場合は、代わりにssh core@<node>.<cluster_name>.<base_domain>
を使用してノードにアクセスできます。
ブートディスクの暗号化を設定している場合は、有効であるかどうかを確認します。
デバッグシェルで、ノードでのルートマッピングのステータスを確認します。
# cryptsetup status root
出力例
/dev/mapper/root is active and is in use. type: LUKS2 1 cipher: aes-xts-plain64 2 keysize: 512 bits key location: keyring device: /dev/sda4 3 sector size: 512 offset: 32768 sectors size: 15683456 sectors mode: read/write
暗号化されたデバイスにバインドされる Clevis プラグインを一覧表示します。
# clevis luks list -d /dev/sda4 1
- 1
- 前述のステップの出力の
device
フィールドに一覧表示されるデバイスを指定します。
出力例
1: sss '{"t":1,"pins":{"tang":[{"url":"http://tang.example.com:7500"}]}}' 1
- 1
- この出力例では、Tang プラグインは、
/dev/sda4
デバイスの Shamir の Secret Sharing (SSS) Clevis プラグインにより使用されます。
ミラーリングを設定している場合は、有効かどうかを確認します。
デバッグシェルから、ノードにあるソフトウェアの RAID デバイスのリストを表示します。
# cat /proc/mdstat
出力例
Personalities : [raid1] md126 : active raid1 sdb3[1] sda3[0] 1 393152 blocks super 1.0 [2/2] [UU] md127 : active raid1 sda4[0] sdb4[1] 2 51869632 blocks super 1.2 [2/2] [UU] unused devices: <none>
上記のコマンドの出力に記載されている各ソフトウェア RAID デバイスの詳細を確認してください。以下の例は、
/dev/md126
デバイスの詳細を示しています。# mdadm --detail /dev/md126
出力例
/dev/md126: Version : 1.0 Creation Time : Wed Jul 7 11:07:36 2021 Raid Level : raid1 1 Array Size : 393152 (383.94 MiB 402.59 MB) Used Dev Size : 393152 (383.94 MiB 402.59 MB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Wed Jul 7 11:18:24 2021 State : clean 2 Active Devices : 2 3 Working Devices : 2 4 Failed Devices : 0 5 Spare Devices : 0 Consistency Policy : resync Name : any:md-boot 6 UUID : ccfa3801:c520e0b5:2bee2755:69043055 Events : 19 Number Major Minor RaidDevice State 0 252 3 0 active sync /dev/sda3 7 1 252 19 1 active sync /dev/sdb3 8
ソフトウェア RAID デバイスにマウントされているファイルシステムを一覧表示します。
# mount | grep /dev/md
出力例
/dev/md127 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /etc type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /usr type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /sysroot type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var/lib/containers/storage/overlay type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/1 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/2 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/3 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/4 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md127 on /var/lib/kubelet/pods/e5054ed5-f882-4d14-b599-99c050d4e0c0/volume-subpaths/etc/tuned/5 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota) /dev/md126 on /boot type ext4 (rw,relatime,seclabel)
この出力例では、
/boot
ファイルシステムが/dev/md126
software RAID デバイスに、root ファイルシステムが/dev/md127
にマウントされ t ています。
- OpenShift Container Platform ノードタイプごとに検証手順を繰り返します。
関連情報
- TPM v2 および Tang 暗号化モードの詳細は、ポリシーベースの複号を使用して暗号化ボリュームの自動アンロックの設定 を参照してください。
1.4.4. RAID 対応のデータボリュームの設定
ソフトウェア RAID のパーティション設定を有効にして、外部データボリュームを提供できます。OpenShift Container Platform は、データ保護およびフォールトトレランスに対応するために RAID 0、RAID 1、RAID 4、RAID 5、RAID 6、および RAID 10 をサポートします。詳細は、「ディスクのミラーリングについて」を参照してください。
前提条件
- インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
インストールノードに Butane をインストールしている。
注記Butane は、OpenShift Container Platform が使用するコマンドラインユーティリティーで、マシン設定を作成するための便利で簡略化した構文を提供したり、マシン設定の追加検証を実行したりします。詳細は、Butane を使用したマシン設定の作成 セクションを参照してください。
手順
ソフトウェア RAID を使用してデータボリュームを設定する Butane 設定を作成します。
ミラーリングされた起動ディスクに使用されるのと同じディスク上に RAID 1 を使用してデータボリュームを設定するには、
$HOME/clusterconfig/raid1-storage.bu
ファイルを作成します。以下に例を示します。ミラーリングされた起動ディスク上の RAID 1
variant: openshift version: 4.16.0 metadata: name: raid1-storage labels: machineconfiguration.openshift.io/role: worker boot_device: mirror: devices: - /dev/disk/by-id/scsi-3600508b400105e210000900000490000 - /dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6 storage: disks: - device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000 partitions: - label: root-1 size_mib: 25000 1 - label: var-1 - device: /dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6 partitions: - label: root-2 size_mib: 25000 2 - label: var-2 raid: - name: md-var level: raid1 devices: - /dev/disk/by-partlabel/var-1 - /dev/disk/by-partlabel/var-2 filesystems: - device: /dev/md/md-var path: /var format: xfs wipe_filesystem: true with_mount_unit: true
セカンダリーディスク上に RAID 1 を使用してデータボリュームを設定するには、
$HOME/clusterconfig/raid1-alt-storage.bu
ファイルを作成します。以下に例を示します。セカンダリーディスク上の RAID 1
variant: openshift version: 4.16.0 metadata: name: raid1-alt-storage labels: machineconfiguration.openshift.io/role: worker storage: disks: - device: /dev/sdc wipe_table: true partitions: - label: data-1 - device: /dev/sdd wipe_table: true partitions: - label: data-2 raid: - name: md-var-lib-containers level: raid1 devices: - /dev/disk/by-partlabel/data-1 - /dev/disk/by-partlabel/data-2 filesystems: - device: /dev/md/md-var-lib-containers path: /var/lib/containers format: xfs wipe_filesystem: true with_mount_unit: true
前のステップで作成した Butane 設定から RAID マニフェストを作成し、それを
<installation_directory>/openshift
ディレクトリーに保存します。たとえば、コンピュートノードのマニフェストを作成するには、以下のコマンドを実行します。$ butane $HOME/clusterconfig/<butane_config>.bu -o <installation_directory>/openshift/<manifest_name>.yaml 1
- 1
<butane_config>
および<manifest_name>
を直前の手順のファイル名に置き換えます。たとえば、セカンダリーディスクの場合は、raid1-alt-storage.bu
およびraid1-alt-storage.yaml
になります。
- 今後マニフェストを更新する必要がある場合には、Butane 設定を保存します。
- 残りの OpenShift Container Platform インストールを継続します。
1.4.5. Intel® Virtual RAID on CPU (VROC) データボリュームの設定
Intel® VROC はハイブリッド RAID の一種で、メンテナンスの一部はハードウェアにオフロードされますが、オペレーティングシステムにはソフトウェア RAID として表示されます。
次の手順では、Intel® VROC 対応 RAID1 を設定します。
前提条件
- Intel® Volume Management Device (VMD) が有効になっているシステムがある。
手順
次のコマンドを実行して、Intel® Matrix Storage Manager (IMSM) RAID コンテナーを作成します。
$ mdadm -CR /dev/md/imsm0 -e \ imsm -n2 /dev/nvme0n1 /dev/nvme1n1 1
- 1
- RAID のデバイス名。この例では、2 つのデバイスがリストされています。2 つ以上のデバイス名を指定する場合は、
-n
フラグを調整する必要があります。たとえば、3 つのデバイスをリストするには、フラグ-n3
を使用します。
コンテナー内に RAID1 ストレージを作成します。
次のコマンドを実行して、実際の RAID1 ボリュームの前にダミーの RAID0 ボリュームを作成します。
$ mdadm -CR /dev/md/dummy -l0 -n2 /dev/imsm0 -z10m --assume-clean
次のコマンドを実行して、実際の RAID1 アレイを作成します。
$ mdadm -CR /dev/md/coreos -l1 -n2 /dev/imsm0
次のコマンドを使用して、RAID0 と RAID1 のメンバーアレイを停止し、ダミーの RAID0 アレイを削除します。
$ mdadm -S /dev/md/dummy \ mdadm -S /dev/md/coreos \ mdadm --kill-subarray=0 /dev/md/imsm0
次のコマンドを実行して RAID1 アレイを再起動します。
$ mdadm -A /dev/md/coreos /dev/md/imsm0
RAID1 デバイスに RHCOS をインストールします。
次のコマンドを実行して、IMSM コンテナーの UUID を取得します。
$ mdadm --details --export /dev/md/imsm0
次のコマンドを実行して、RHCOS をインストールし、
rd.md.uuid
カーネル引数を含めます。$ coreos-installer install /dev/md/coreos \ --append-karg rd.md.uuid=<md_UUID> 1 ...
- 1
- IMSM コンテナーの UUID。
RHCOS をインストールするために必要な追加の
coreos-installer
引数を含めます。
1.5. chrony タイムサービスの設定
chrony タイムサービス (chronyd
) で使用されるタイムサーバーおよび関連する設定は、chrony.conf
ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定できます。
手順
chrony.conf
ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu
ファイルを作成します。注記Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
variant: openshift version: 4.16.0 metadata: name: 99-worker-chrony 1 labels: machineconfiguration.openshift.io/role: worker 2 storage: files: - path: /etc/chrony.conf mode: 0644 3 overwrite: true contents: inline: | pool 0.rhel.pool.ntp.org iburst 4 driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony
- 1 2
- コントロールプレーンノードでは、これらの両方の場所で
worker
の代わりにmaster
を使用します。 - 3
- マシン設定ファイルの
mode
フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode
は 10 進数の値に変換されます。oc get mc <mc-name> -o yaml
コマンドで YAML ファイルを確認できます。 - 4
- DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。または、NTP サーバーの
1.rhel.pool.ntp.org
、2.rhel.pool.ntp.org
、または3.rhel.pool.ntp.org
のいずれかを指定できます。
Butane を使用して、ノードに配信される設定を含む
MachineConfig
オブジェクトファイル (99-worker-chrony.yaml
) を生成します。$ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
以下の 2 つの方法のいずれかで設定を適用します。
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
MachineConfig
オブジェクトファイルを<installation_directory>/openshift
ディレクトリーに追加してから、クラスターの作成を続行します。 クラスターがすでに実行中の場合は、ファイルを適用します。
$ oc apply -f ./99-worker-chrony.yaml
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
1.6. 関連情報
- Butane の詳細は、Butane を使用したマシン設定の作成 を参照してください。
- FIPS サポートの詳細は、FIPS 暗号のサポート を参照してください。
第2章 ファイアウォールの設定
ファイアウォールを使用する場合、OpenShift Container Platform が機能するために必要なサイトにアクセスできるように設定する必要があります。一部のサイトにはアクセスを常に付与し、クラスターをホストするために Red Hat Insights、Telemetry サービス、クラウドを使用したり、特定のビルドストラテジーをホストする場合に追加のアクセスを付与する必要があります。
2.1. OpenShift Container Platform のファイアウォールの設定
OpenShift Container Platform をインストールする前に、ファイアウォールを、OpenShift Container Platform が必要とするサイトへのアクセスを付与するように設定する必要があります。ファイアウォールを使用する場合は、OpenShift Container Platform が機能するために必要なサイトにアクセスできるように、ファイアウォールに追加の設定を行います。
ワーカーノードと比較して、コントローラーノードのみで実行されるサービスには、特別な設定上の考慮事項はありません。
ご使用の環境で OpenShift Container Platform クラスターの前に専用のロードバランサーがある場合は、ファイアウォールとロードバランサーの間の許可リストを確認して、クラスターに対する不要なネットワーク制限を回避してください。
手順
ファイアウォールの許可リストに次のレジストリー URL を設定します。
URL ポート 機能 registry.redhat.io
443
コアコンテナーイメージを指定します。
access.redhat.com
443
コンテナークライアントが
registry.access.redhat.com
から取得したイメージを検証するのに必要な署名ストアをホストします。ファイアウォール環境では、このリソースが許可リストに含まれていることを確認してください。registry.access.redhat.com
443
コアコンテナーイメージを含め、Red Hat Ecosystem Catalog に保存されているすべてのコンテナーイメージをホストします。
quay.io
443
コアコンテナーイメージを指定します。
cdn.quay.io
443
コアコンテナーイメージを指定します。
cdn01.quay.io
443
コアコンテナーイメージを指定します。
cdn02.quay.io
443
コアコンテナーイメージを指定します。
cdn03.quay.io
443
コアコンテナーイメージを指定します。
cdn04.quay.io
443
コアコンテナーイメージを指定します。
cdn05.quay.io
443
コアコンテナーイメージを指定します。
cdn06.quay.io
443
コアコンテナーイメージを指定します。
sso.redhat.com
443
https://console.redhat.com
サイトは、sso.redhat.com
からの認証を使用します。-
許可リストで
cdn.quay.io
とcdn0[1-6].quay.io
の代わりに、ワイルドカードの*.quay.io
と*.openshiftapps.com
を使用できます。 -
ワイルドカード
*.access.redhat.com
を使用すると、設定を簡素化し、registry.access.redhat.com
を含むすべてのサブドメインを許可できます。 -
quay.io
などのサイトを許可リストに追加するには、*.quay.io
などのワイルドカードエントリーを拒否リストに加えないでください。ほとんどの場合、イメージレジストリーはコンテンツ配信ネットワーク (CDN) を使用してイメージを提供します。ファイアウォールがアクセスをブロックすると、最初のダウンロード要求がcdn01.quay.io
などのホスト名にリダイレクトされるときに、イメージのダウンロードが拒否されます。
-
許可リストで
- ファイアウォールの許可リストを設定し、ビルドに必要な言語またはフレームワークのリソースを提供するサイトをリストに含めます。
Telemetry を無効にしていない場合は、以下の URL へのアクセスを許可して Red Hat Insights にアクセスできるようにする必要があります。
URL ポート 機能 cert-api.access.redhat.com
443
Telemetry で必須
api.access.redhat.com
443
Telemetry で必須
infogw.api.openshift.com
443
Telemetry で必須
console.redhat.com
443
Telemetry および
insights-operator
で必須Alibaba Cloud、Amazon Web Services (AWS)、Microsoft Azure、または Google Cloud Platform (GCP) を使用してクラスターをホストする場合、クラウドプロバイダー API およびそのクラウドの DNS を提供する URL へのアクセス権を付与する必要があります。
クラウド URL ポート 機能 Alibaba
*.aliyuncs.com
443
Alibaba Cloud のサービスとリソースにアクセスするために必要です。Alibaba の endpoints_config.go ファイル を参照して、使用するリージョンを許可する正確なエンドポイントを確認してください。
AWS
aws.amazon.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
*.amazonaws.com
または、AWS API にワイルドカードを使用しない場合、次の URL を許可リストに含める必要があります。
443
AWS サービスおよびリソースへのアクセスに必要です。AWS ドキュメントの AWS Service Endpoints を参照して、使用するリージョンを許可する正確なエンドポイントを確認してください。
ec2.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
events.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
iam.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
route53.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
*.s3.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
*.s3.<aws_region>.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
*.s3.dualstack.<aws_region>.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
sts.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
sts.<aws_region>.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
tagging.us-east-1.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。このエンドポイントは、クラスターがデプロイされているリージョンに関係なく、常に
us-east-1
です。ec2.<aws_region>.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
elasticloadbalancing.<aws_region>.amazonaws.com
443
AWS 環境でのクラスターのインストールおよび管理に使用されます。
servicequotas.<aws_region>.amazonaws.com
443
必須。サービスをデプロイするためのクォータを確認するのに使用されます。
tagging.<aws_region>.amazonaws.com
443
タグの形式で AWS リソースに関するメタデータを割り当てることができます。
*.cloudfront.net
443
CloudFront へのアクセスを提供するために使用されます。AWS Security Token Service (STS) およびプライベート S3 バケットを使用する場合は、CloudFront へのアクセスを提供する必要があります。
GCP
*.googleapis.com
443
GCP サービスおよびリソースへのアクセスに必要です。GCP ドキュメントの Cloud Endpoints を参照して、お使いの API を許可するエンドポイントを確認してください。
accounts.google.com
443
GCP アカウントへのアクセスに必要です。
Microsoft Azure
management.azure.com
443
Microsoft Azure のサービスとリソースにアクセスするために必要です。Microsoft Azure ドキュメントの Microsoft Azure REST API reference を参照して、お使いの API を許可するエンドポイントを確認してください。
*.blob.core.windows.net
443
Ignition ファイルのダウンロードに必要です。
login.microsoftonline.com
443
Microsoft Azure のサービスとリソースにアクセスするために必要です。Microsoft Azure ドキュメントの Azure REST API reference を参照して、お使いの API を許可するエンドポイントを確認してください。
以下の URL を許可リストに指定します。
URL ポート 機能 *.apps.<cluster_name>.<base_domain>
443
Ingress ワイルドカードをインストール時に設定しない限り、デフォルトのクラスタールートへのアクセスに必要。
api.openshift.com
443
クラスタートークンの両方が必要であり、クラスターに更新が利用可能かどうかを確認するために必要です。
console.redhat.com
443
クラスタートークンに必須
mirror.openshift.com
443
ミラーリングされたインストールのコンテンツおよびイメージへのアクセスに必要。Cluster Version Operator には単一の機能ソースのみが必要ですが、このサイトはリリースイメージ署名のソースでもあります。
quayio-production-s3.s3.amazonaws.com
443
AWS で Quay イメージコンテンツにアクセスするために必要。
rhcos.mirror.openshift.com
443
Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードするために必要。
sso.redhat.com
443
https://console.redhat.com
サイトは、sso.redhat.com
からの認証を使用します。storage.googleapis.com/openshift-release
443
リリースイメージ署名のソース (ただし、Cluster Version Operator には単一の機能ソースのみが必要)。
Operator にはヘルスチェックを実行するためのルートアクセスが必要です。具体的には、認証および Web コンソール Operator は 2 つのルートに接続し、ルートが機能することを確認します。クラスター管理者として操作を実行しており、
*.apps.<cluster_name>.<base_domain>
を許可しない場合は、これらのルートを許可します。-
oauth-openshift.apps.<cluster_name>.<base_domain>
-
canary-openshift-ingress-canary.apps.<cluster_name>.<base_domain>
-
console-openshift-console.apps.<cluster_name>.<base_domain>
、またはフィールドが空でない場合にconsoles.operator/cluster
オブジェクトのspec.route.hostname
フィールドに指定されるホスト名。
-
オプションのサードパーティーコンテンツに対する次の URL を許可リストに追加します。
URL ポート 機能 registry.connect.redhat.com
443
すべてのサードパーティーのイメージと認定 Operator に必要です。
rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com
443
registry.connect.redhat.com
でホストされているコンテナーイメージにアクセスできますoso-rhc4tp-docker-registry.s3-us-west-2.amazonaws.com
443
Sonatype Nexus、F5 Big IP Operator に必要です。
デフォルトの Red Hat Network Time Protocol (NTP) サーバーを使用する場合は、以下の URL を許可します。
-
1.rhel.pool.ntp.org
-
2.rhel.pool.ntp.org
-
3.rhel.pool.ntp.org
-
デフォルトの Red Hat NTP サーバーを使用しない場合は、プラットフォームの NTP サーバーを確認し、ファイアウォールでこれを許可します。
2.2. OpenShift Container Platform ネットワークフローマトリクス
ネットワークフローマトリクスは、OpenShift Container Platform サービスへの Ingress フローを記述します。マトリクス内のネットワーク情報は、ベアメタル環境とクラウド環境の両方に対して正確です。ネットワークフローマトリクスの情報を使用して、Ingress トラフィックを管理します。Ingress トラフィックを重要なフローに制限して、ネットワークセキュリティーを強化できます。
未処理の CSV コンテンツを表示またはダウンロードするには、このリソース を参照してください。
さらに、Ingress トラフィックを管理するときは、次の動的ポート範囲を考慮してください。
-
9000-9999
: ホストレベルのサービス -
30000-32767
: Kubernetes ノードポート -
49152-65535
: 動的ポートまたはプライベートポート
ネットワークフローマトリクスは、ベースの OpenShift Container Platform インストールの Ingress トラフィックフローを説明します。Red Hat Marketplace から入手できるオプションの Operator など、追加コンポーネントのネットワークフローは説明しません。このマトリクスは、Hosted-Control-Plane、MicroShift、スタンドアロンクラスターには適用されません。
方向 | プロトコル | ポート | namespace | サービス | Pod | コンテナー | ノードのロール | 任意 |
---|---|---|---|---|---|---|---|---|
Ingress | TCP | 22 | Host system service | sshd | master | TRUE | ||
Ingress | TCP | 53 | openshift-dns | dns-default | dnf-default | dns | master | FALSE |
Ingress | TCP | 80 | openshift-ingress | router-default | router-default | ルーター | master | FALSE |
Ingress | TCP | 111 | Host system service | rpcbind | master | TRUE | ||
Ingress | TCP | 443 | openshift-ingress | router-default | router-default | ルーター | master | FALSE |
Ingress | TCP | 1936 | openshift-ingress | router-default | router-default | ルーター | master | FALSE |
Ingress | TCP | 2379 | openshift-etcd | etcd | etcd | etcdctl | master | FALSE |
Ingress | TCP | 2380 | openshift-etcd | healthz | etcd | etcd | master | FALSE |
Ingress | TCP | 5050 | openshift-machine-api | ironic-proxy | ironic-proxy | master | FALSE | |
Ingress | TCP | 6080 | openshift-kube-apiserver | kube-apiserver | kube-apiserver-insecure-readyz | master | FALSE | |
Ingress | TCP | 6180 | openshift-machine-api | metal3-state | metal3 | metal3-httpd | master | FALSE |
Ingress | TCP | 6183 | openshift-machine-api | metal3-state | metal3 | metal3-httpd | master | FALSE |
Ingress | TCP | 6385 | openshift-machine-api | ironic-proxy | ironic-proxy | master | FALSE | |
Ingress | TCP | 6388 | openshift-machine-api | metal3-state | metal3 | metal3-httpd | master | FALSE |
Ingress | TCP | 6443 | openshift-kube-apiserver | apiserver | kube-apiserver | kube-apiserver | master | FALSE |
Ingress | TCP | 8080 | openshift-network-operator | network-operator | network-operator | master | FALSE | |
Ingress | TCP | 8798 | openshift-machine-config-operator | machine-config-daemon | machine-config-daemon | machine-config-daemon | master | FALSE |
Ingress | TCP | 9001 | openshift-machine-config-operator | machine-config-daemon | machine-config-daemon | kube-rbac-proxy | master | FALSE |
Ingress | TCP | 9099 | openshift-cluster-version | cluster-version-operator | cluster-version-operator | cluster-version-operator | master | FALSE |
Ingress | TCP | 9100 | openshift-monitoring | node-exporter | node-exporter | kube-rbac-proxy | master | FALSE |
Ingress | TCP | 9103 | openshift-ovn-kubernetes | ovn-kubernetes-node | ovnkube-node | kube-rbac-proxy-node | master | FALSE |
Ingress | TCP | 9104 | openshift-network-operator | metrics | network-operator | network-operator | master | FALSE |
Ingress | TCP | 9105 | openshift-ovn-kubernetes | ovn-kubernetes-node | ovnkube-node | kube-rbac-proxy-ovn-metrics | master | FALSE |
Ingress | TCP | 9107 | openshift-ovn-kubernetes | egressip-node-healthcheck | ovnkube-node | ovnkube-controller | master | FALSE |
Ingress | TCP | 9108 | openshift-ovn-kubernetes | ovn-kubernetes-control-plane | ovnkube-control-plane | kube-rbac-proxy | master | FALSE |
Ingress | TCP | 9192 | openshift-cluster-machine-approver | machine-approver | machine-approver | kube-rbac-proxy | master | FALSE |
Ingress | TCP | 9258 | openshift-cloud-controller-manager-operator | machine-approver | cluster-cloud-controller-manager | cluster-cloud-controller-manager | master | FALSE |
Ingress | TCP | 9444 | openshift-kni-infra | haproxy | haproxy | master | FALSE | |
Ingress | TCP | 9445 | openshift-kni-infra | haproxy | haproxy | master | FALSE | |
Ingress | TCP | 9447 | openshift-machine-api | metal3-baremetal-operator | master | FALSE | ||
Ingress | TCP | 9537 | Host system service | crio-metrics | master | FALSE | ||
Ingress | TCP | 9637 | openshift-machine-config-operator | kube-rbac-proxy-crio | kube-rbac-proxy-crio | kube-rbac-proxy-crio | master | FALSE |
Ingress | TCP | 9978 | openshift-etcd | etcd | etcd | etcd-metrics | master | FALSE |
Ingress | TCP | 9979 | openshift-etcd | etcd | etcd | etcd-metrics | master | FALSE |
Ingress | TCP | 9980 | openshift-etcd | etcd | etcd | etcd | master | FALSE |
Ingress | TCP | 10250 | Host system service | kubelet | master | FALSE | ||
Ingress | TCP | 10256 | openshift-ovn-kubernetes | ovnkube | ovnkube | ovnkube-controller | master | FALSE |
Ingress | TCP | 10257 | openshift-kube-controller-manager | kube-controller-manager | kube-controller-manager | kube-controller-manager | master | FALSE |
Ingress | TCP | 10258 | openshift-cloud-controller-manager-operator | cloud-controller | cloud-controller-manager | cloud-controller-manager | master | FALSE |
Ingress | TCP | 10259 | openshift-kube-scheduler | scheduler | openshift-kube-scheduler | kube-scheduler | master | FALSE |
Ingress | TCP | 10260 | openshift-cloud-controller-manager-operator | cloud-controller | cloud-controller-manager | cloud-controller-manager | master | FALSE |
Ingress | TCP | 10300 | openshift-cluster-csi-drivers | csi-livenessprobe | csi-driver-node | csi-driver | master | FALSE |
Ingress | TCP | 10309 | openshift-cluster-csi-drivers | csi-node-driver | csi-driver-node | csi-node-driver-registrar | master | FALSE |
Ingress | TCP | 10357 | openshift-kube-apiserver | openshift-kube-apiserver-healthz | kube-apiserver | kube-apiserver-check-endpoints | master | FALSE |
Ingress | TCP | 17697 | openshift-kube-apiserver | openshift-kube-apiserver-healthz | kube-apiserver | kube-apiserver-check-endpoints | master | FALSE |
Ingress | TCP | 18080 | openshift-kni-infra | coredns | coredns | master | FALSE | |
Ingress | TCP | 22623 | openshift-machine-config-operator | machine-config-server | machine-config-server | machine-config-server | master | FALSE |
Ingress | TCP | 22624 | openshift-machine-config-operator | machine-config-server | machine-config-server | machine-config-server | master | FALSE |
Ingress | UDP | 53 | openshift-dns | dns-default | dnf-default | dns | master | FALSE |
Ingress | UDP | 111 | Host system service | rpcbind | master | TRUE | ||
Ingress | UDP | 6081 | openshift-ovn-kubernetes | ovn-kubernetes geneve | master | FALSE | ||
Ingress | TCP | 22 | Host system service | sshd | worker | TRUE | ||
Ingress | TCP | 53 | openshift-dns | dns-default | dnf-default | dns | worker | FALSE |
Ingress | TCP | 80 | openshift-ingress | router-default | router-default | ルーター | worker | FALSE |
Ingress | TCP | 111 | Host system service | rpcbind | worker | TRUE | ||
Ingress | TCP | 443 | openshift-ingress | router-default | router-default | ルーター | worker | FALSE |
Ingress | TCP | 1936 | openshift-ingress | router-default | router-default | ルーター | worker | FALSE |
Ingress | TCP | 8798 | openshift-machine-config-operator | machine-config-daemon | machine-config-daemon | machine-config-daemon | worker | FALSE |
Ingress | TCP | 9001 | openshift-machine-config-operator | machine-config-daemon | machine-config-daemon | kube-rbac-proxy | worker | FALSE |
Ingress | TCP | 9100 | openshift-monitoring | node-exporter | node-exporter | kube-rbac-proxy | worker | FALSE |
Ingress | TCP | 9103 | openshift-ovn-kubernetes | ovn-kubernetes-node | ovnkube-node | kube-rbac-proxy-node | worker | FALSE |
Ingress | TCP | 9105 | openshift-ovn-kubernetes | ovn-kubernetes-node | ovnkube-node | kube-rbac-proxy-ovn-metrics | worker | FALSE |
Ingress | TCP | 9107 | openshift-ovn-kubernetes | egressip-node-healthcheck | ovnkube-node | ovnkube-controller | worker | FALSE |
Ingress | TCP | 9537 | Host system service | crio-metrics | worker | FALSE | ||
Ingress | TCP | 9637 | openshift-machine-config-operator | kube-rbac-proxy-crio | kube-rbac-proxy-crio | kube-rbac-proxy-crio | worker | FALSE |
Ingress | TCP | 10250 | Host system service | kubelet | worker | FALSE | ||
Ingress | TCP | 10256 | openshift-ovn-kubernetes | ovnkube | ovnkube | ovnkube-controller | worker | TRUE |
Ingress | TCP | 10300 | openshift-cluster-csi-drivers | csi-livenessprobe | csi-driver-node | csi-driver | worker | FALSE |
Ingress | TCP | 10309 | openshift-cluster-csi-drivers | csi-node-driver | csi-driver-node | csi-node-driver-registrar | worker | FALSE |
Ingress | TCP | 18080 | openshift-kni-infra | coredns | coredns | worker | FALSE | |
Ingress | UDP | 53 | openshift-dns | dns-default | dnf-default | dns | worker | FALSE |
Ingress | UDP | 111 | Host system service | rpcbind | worker | TRUE | ||
Ingress | UDP | 6081 | openshift-ovn-kubernetes | ovn-kubernetes geneve | worker | FALSE |
第3章 Linux Control Group バージョン 1 (cgroup v1) の有効化
OpenShift Container Platform 4.14 以降、OpenShift Container Platform はクラスター内で Linux コントロールグループバージョン 2 (cgroup v2) を使用します。OpenShift Container Platform 4.13 以前で cgroup v1 を使用している場合、OpenShift Container Platform 4.16 に移行しても、cgroup 設定はバージョン 2 に自動的に更新されません。OpenShift Container Platform 4.14 以降の新規インストールでは、デフォルトで cgroup v2 が使用されます。ただし、インストール時に Linux コントロールグループバージョン 1 (cgroup v1) を有効にできます。OpenShift Container Platform で cgroup v1 を有効にすると、クラスター内のすべての cgroup v2 コントローラーと階層が無効になります。
cgroup v1 は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。
cgroup v2 は、Linux cgroup API の現行バージョンです。cgroup v2 では、統一された階層、安全なサブツリー委譲、Pressure Stall Information 等の新機能、および強化されたリソース管理および分離など、cgroup v1 に対していくつかの改善が行われています。ただし、cgroup v2 には、cgroup v1 とは異なる CPU、メモリー、および I/O 管理特性があります。したがって、一部のワークロードでは、cgroup v2 を実行するクラスター上のメモリーまたは CPU 使用率にわずかな違いが発生する可能性があります。
必要に応じて、node.config
オブジェクトを編集することで、cgroup v1 と cgroup v2 を切り替えることができます。詳細は、このセクションの「その他のリソース」の「ノードでの Linux cgroup の設定」を参照してください。
3.1. インストール時の Linux cgroup v1 の有効化
インストールマニフェストを作成して、クラスターのインストール時に Linux Control Group バージョン 1 (cgroup v1) を有効化できます。
cgroup v1 は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。
手順
node.config
オブジェクトを作成または編集して、v1
cgroup を指定します。apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2"
- 通常通りにインストールを続行します。
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.