第9章 Red Hat Enterprise Linux CoreOS (RHCOS)
9.1. RHCOS について
Red Hat Enterprise Linux CoreOS (RHCOS) は、自動化されたリモートアップグレード機能を備えた Red Hat Enterprise Linux (RHEL) の品質基準を提供することにより、次世代の単一目的コンテナーオペレーティングシステムテクノロジーを表しています。
RHCOS は、すべての OpenShift Container Platform マシンの 1 つの OpenShift Container Platform 4.14 コンポーネントとしてのみサポートされます。RHCOS は、OpenShift Container Platform のコントロールプレーンまたはマスターマシン向けに唯一サポートされるオペレーティングシステムです。RHCOS はすべてのクラスターマシンのデフォルトオペレーティングシステムですが、RHEL をオペレーティングシステムとして使用するコンピュートマシン (ワーカーマシンとしても知られる) を作成することもできます。RHCOS を OpenShift Container Platform 4.14 にデプロイするには、以下の 2 つの一般的な方法があります。
- インストールプログラムがプロビジョニングするインフラストラクチャーにクラスターをインストールする場合、RHCOS イメージはインストール中にターゲットプラットフォームにダウンロードされます。RHCOS 設定を制御する適切な Ignition 設定ファイルもダウンロードされ、マシンのデプロイに使用されます。
- クラスターを独自に管理するインフラストラクチャーにインストールする場合、インストールに関するドキュメントを参照して RHCOS イメージの取得や、Ignition 設定ファイルの生成、および設定ファイルの使用によるマシンのプロビジョニングを行ってください。
9.1.1. RHCOS の主な機能
以下は、RHCOS オペレーティングシステムの主要な機能を説明しています。
- Based on RHEL (RHEL ベース): この基礎となるオペレーティングシステムは、主に RHEL のコンポーネントで構成されます。RHEL をサポートする品質、セキュリティーおよび管理基準が RHCOS にも同様に適用されます。たとえば、RHCOS ソフトウェアは RPM パッケージにあり、各 RHCOS システムは、RHEL カーネル、および systemd init システムで管理される一連のサービスと共に起動します。
- Controlled immutability (不変性の制御): RHCOS には、RHEL コンポーネントが含まれているものの、RHCOS はデフォルトの RHEL インストールの場合よりも厳密に管理されるように設計されています。これは OpenShift Container Platform クラスターからリモートで管理されます。RHCOS マシンをセットアップする際には、いくつかのシステム設定のみを変更するだけで対応することが可能です。RHCOS のこの管理機能および不変性により、OpenShift Container Platform では RHCOS システムの最新の状態をクラスターに保存し、最新の RHCOS 設定に基づいて追加のマシンの作成や更新を実行することができます。
CRI-O container runtime (CRI-O コンテナーランタイム): RHCOS には Docker で必要な OCI および libcontainer 形式のコンテナーを実行する機能が含まれていますが、Docker コンテナーエンジンではなく CRI-O コンテナーエンジンが組み込まれています。OpenShift Container Platform などの、Kubernetes プラットフォームが必要とする機能に重点が置かれている CRI-O では、複数の異なる Kubernetes バージョンとの特定の互換性が提供されます。また CRI-O は、大規模な機能セットを提供するコンテナーエンジンの場合よりもフットプリントや攻撃領域を縮小できます。現時点で、CRI-O は OpenShift Container Platform クラスター内で利用可能な唯一のエンジンです。
CRI-O は、runC または crun コンテナーランタイムのいずれかを使用して、コンテナーを開始および管理できます。crun を有効にする方法は、
ContainerRuntimeConfigCR の作成に関するドキュメントを参照してください。-
Set of container tools (コンテナーツールのセット): ビルド、コピーまたはコンテナーの管理などのタスクに備え、RHCOS では Docker CLI ツールが互換性のあるコンテナーツールセットに置き換えられます。Podman CLI ツールは、コンテナーおよびコンテナーイメージの実行、起動、停止、リスト表示および削除などの数多くのコンテナーランタイム機能をサポートします。skopeo CLI ツールは、イメージのコピー、認証およびイメージへの署名を実行できます。
crictlCLI ツールを使用すると、CRI-O コンテナーエンジンからコンテナーおよび Pod を使用できます。これらのツールを RHCOS 内で直接使用することは推奨されていませんが、デバッグの目的で使用することは可能です。 -
rpm-ostree upgrades: RHCOS は、
rpm-ostreeシステムを使用したトランザクショナルアップグレードを特長としています。更新はコンテナーイメージ経由で提供され、OpenShift 更新プロセスの一部となっています。コンテナーイメージはデプロイされると、プルされ、デプロイメントされてディスクに書き込まれます。その後にブートローダーが新規バージョンで起動するように変更されます。 マシンはローリング方式で更新に対して再起動し、クラスターの容量への影響が最小限に抑えられます。 bootupd ファームウェアおよびブートローダー更新ツール: パッケージマネージャーおよび
rpm-ostreeなどのハイブリッドシステムはファームウェアやブートローダーを更新しません。bootupdを使用する RHCOS ユーザーは、x86_64、ppc64le、および aarch64 などの最新のアーキテクチャーで実行される UEFI およびレガシー BIOS ブートモードのファームウェアおよびブートの更新を管理するシステムに依存しない更新ツールにアクセスできます。bootupdのインストール方法の詳細は、bootupd を使用したブートローダーの更新に関するドキュメントを参照してください。-
Updated through the Machine Config Operator: OpenShift Container Platform では、Machine Config Operator がオペレーティングシステムのアップグレードを処理します。
yumで実行される場合のように個々のパッケージをアップグレードする代わりに、rpm-ostreeは OS のアップグレードを atomic 単位として提供します。新規の OS デプロイメントはアップグレード時に段階が設定され、次回の再起動時に実行されます。アップグレードに不具合が生じた場合は、単一ロールバックおよび再起動によってシステムが以前の状態に戻ります。OpenShift Container Platform での RHCOS アップグレードは、クラスターの更新時に実行されます。
RHCOS システムの場合、rpm-ostree ファイルシステムのレイアウトには、以下の特徴があります。
-
/usr: オペレーティングシステムのバイナリーとライブラリーが保管される場所で、読み取り専用です。これを変更することはサポートされていません。 -
/etc、/boot、/var: システム上で書き込み可能ですが、Machine Config Operator によってのみ変更されることが意図されています。 -
/var/lib/containers: コンテナーイメージを保管するためのグラフストレージの場所です。
9.1.2. RHCOS の設定方法の選択
RHCOS は、最低限のユーザー設定で OpenShift Container Platform クラスターにデプロイするように設計されています。これは最も基本的な形式であり、以下で構成されます。
- AWS など、プロビジョニングされたインフラストラクチャーの使用を開始するか、インフラストラクチャーを独自にプロビジョニングします。
-
openshift-installの実行時に、install-config.yamlファイルに認証情報およびクラスター名などの一部の情報を指定します。
OpenShift Container Platform の RHCOS システムは OpenShift Container Platform クラスターから完全に管理されるように設計されているため、RHCOS マシンに直接ログインすることは推奨されていません。RHCOS マシンクラスターへの直接のアクセスはデバッグ目的で制限的に実行できますが、RHCOS システムを直接設定することはできません。その代わりに、OpenShift Container Platform ノードに機能を追加または変更する必要がある場合は、以下の方法で変更を行うことを検討してください。
- Kubernetes ワークロードオブジェクト (DaemonSet や Deployment など): サービスや他のユーザーレベルの機能をクラスターに追加する必要がある場合、Kubernetes ワークロードオブジェクトとしてそれらを追加することを検討します。特定のノード設定以外にこれらの機能を保持することは、後続のアップグレードでクラスターを破損させるリスクを軽減する上での最も効果的な方法です。
- Day-2 カスタマイズ: 可能な場合は、クラスターノードをカスタマイズせずにクラスターを起動し、クラスターを起動してから必要なノードの変更を加えます。これらの変更は、後で追跡することが容易であり、更新に支障が及ぶ可能性がより低くなります。machine config の作成または Operator カスタムリソースの変更により、これらのカスタマイズを行うことができます。
-
Day-1 カスタマイズ: クラスターの初回起動時に実装する必要のあるカスタマイズの場合、初回起動時に変更が実装されるようにクラスターを変更する方法があります。Day-1 のカスタマイズは、
openshift-installの実行時に Ignition 設定およびマニフェストファイルを使用して実行することも、ユーザーがプロビジョニングする ISO インストール時に起動オプションを追加して実行することもできます。
以下は、Day-1 で実行できるカスタマイズの例です。
- カーネル引数: 特定のカーネル機能やチューニングがクラスターの初回起動時にノードで必要になる場合。
- ディスクの暗号化: セキュリティー上、FIPS サポートなど、ノード上のルートファイルシステムが暗号化されている必要がある場合。
- カーネルモジュール: ネットワークカードやビデオカードなど、特定のハードウェアデバイスに Linux カーネル内でデフォルトで使用可能なモジュールがない場合。
- Chronyd: タイムサーバーの場所など、特定のクロック設定をノードに指定する必要がある場合
これらのタスクを実行する上で、openshift-install プロセスを拡張して MachineConfig などの追加のオブジェクトを含めることができます。machine config を作成するこれらの手順は、クラスターの起動後に Machine Config Operator に渡すことができます。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
9.1.3. RHCOS のデプロイ方法の選択
OpenShift Container Platform の RHCOS インストールの相違点は、インストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーにデプロイするかどうかによって異なります。
- Installer-provisioned: 一部のクラウド環境は、最低限の設定で OpenShift Container Platform クラスターを起動することを可能にする事前に設定されたインフラストラクチャーを提供しています。このようなタイプのインストールでは、各ノードにコンテンツを配置する Ignition 設定を指定することができ、この場所でクラスターの初回時の起動が行われます。
- ユーザーによるプロビジョニング: 独自のインフラストラクチャーをプロビジョニングする場合、データを RHCOS ノードに追加する方法により柔軟性を持たせることができます。たとえば、RHCOS ISO インストーラーを起動して各システムをインストールする場合は、カーネル引数を追加できます。ただし、オペレーティングシステム自体で設定が必要となるほとんどの場合において、Ignition 設定で設定を指定する方法が最も適しています。
Ignition 機能は、RHCOS システムの初回セットアップ時にのみ実行されます。その後は、Ignition 設定はマシン設定を使用して指定できます。
9.1.4. Ignition について
Ignition は、初回設定時にディスクを操作するために RHCOS によって使用されるユーティリティーです。これにより、ディスクのパーティション設定やパーティションのフォーマット、ファイル作成、ユーザー設定などの一般的なディスク関連のタスクが実行されます。初回起動時に、Ignition はインストールメディアや指定した場所からその設定を読み込み、その設定をマシンに適用します。
クラスターをインストールする場合かマシンをクラスターに追加する場合かを問わず、Ignition は常に OpenShift Container Platform クラスターマシンの初期設定を実行します。実際のシステム設定のほとんどは、各マシン自体で行われます。各マシンで、Ignition は、RHCOS イメージを取得し、RHCOS カーネルを起動します。カーネルコマンドラインのオプションで、デプロイメントのタイプや Ignition で有効にされた初期 RAM ディスク (initramfs) の場所を特定します。
9.1.4.1. Ignition の仕組み
Ignition を使用してマシンを作成するには、Ignition 設定ファイルが必要です。OpenShift Container Platform のインストレーションプログラムは、クラスターを作成するのに必要な Ignition 設定ファイルを作成します。これらのファイルは、インストレーションプログラムに直接指定するか、install-config.yaml ファイルを通じて提供される情報に基づくものです。
Ignition がマシンを設定する方法は、cloud-init や Linux Anaconda kickstart などのツールがシステムを設定する方法に似ていますが、以下のような重要な違いがあります。
- Ignition はインストール先のシステムから分離され初期 RAM ディスクから実行されます。そのため、Ignition はディスクのパーティション設定を再度実行し、ファイルシステムをセットアップし、さらにマシンの永続ファイルシステムに他の変更を加える可能性があります。これとは対照的に、cloud-init はシステムの起動時にマシンの init システムの一部として実行されるため、ディスクパーティションなどへの基礎的な変更を簡単に行うことはできません。cloud-ini では、ノードの起動プロセスの実行中の起動プロセスの再設定は簡単に実行できません。
- Ignition は既存システムを変更することなく、システムを初期化することが意図されています。マシンが初期化され、インストールされたシステムからカーネルが実行された後に、OpenShift Container Platform クラスターの Machine Config Operator がその後のすべてのマシン設定を行います。
- 定義されたアクションセットを実行する代わりに、Ignition は宣言型の設定を実装します。これは新規マシンの起動前にすべてのパーティション、ファイル、サービスその他のアイテムがあることを検査します。また、新規マシンを指定された設定に一致させるために必要なファイルのディスクへのコピーなどの変更を行います。
- Ignition がマシンの設定を終了した後もカーネルは実行し続けますが、初期 RAM ディスクを破棄し、ディスクにインストールされたシステムにピボットします。システムを再起動しなくても、すべての新しいシステムサービスとその他の機能は起動します。
- Ignition は新しいマシンすべてが宣言型の設定に一致することを確認するため、部分的に設定されたマシンを含めることはできません。マシンのセットアップが失敗し、初期化プロセスが終了しない場合、Ignition は新しいマシンを起動しません。クラスターには部分的に設定されたマシンが含まれることはありません。Ignition が完了しない場合、マシンがクラスターに追加されることはありません。その場合、新しいマシンを各自で追加する必要があります。この動作は、失敗した設定タスクに依存するタスクが後で失敗するまで設定タスクに問題があることが認識されない場合などの、マシンのデバックが困難になる状況を防ぐことができます。
- マシンのセットアップの失敗を引き起こす問題が Ignition 設定にある場合、Ignition は他のマシンの設定に同じ設定を使用することを避けようとします。たとえば、失敗の原因は、同じファイルを作成しようとする親と子で構成される Ignition 設定にある場合があります。この場合、問題が解決されない限り、その Ignition 設定を使用して他のマシンをセットアップすることはできません。
- 複数の Ignition 設定ファイルがある場合、それらの設定の集合体を取得します。Ignition は宣言型であるため、これらの設定間で競合が生じると、Ignition はマシンのセットアップに失敗します。ここで、それらのファイルの情報の順序は問題にはなりません。Ignition はそれぞれの設定を最も妥当な仕方で並べ替え、実行します。たとえば、あるファイルが数レベル分深いレベルのディレクトリーを必要としており、他のファイルがそのパスにあるディレクトリーを必要とする場合、後者のファイルが先に作成されます。Ignition はすべてのファイル、ディレクトリーおよびリンクを深さに応じて作成します。
- Ignition は完全に空のハードディスクで起動できるので、cloud-init では実行できないことを行うことができます。これには、(PXE ブートなどの機能を使用して)、システムをベアメタルでゼロからセットアップすることが含まれます。ベアメタルの場合、Ignition 設定は起動パーティションに挿入されるので、Ignition はこれを見つけ、システムを正しく設定することができます。
9.1.4.2. Ignition の順序
OpenShift Container Platform クラスター内の RHCOS マシンの Ignition プロセスには、以下の手順が含まれます。
- マシンがその Ignition 設定ファイルを取得します。コントロールプレーンマシンはブートストラップマシンから Ignition 設定ファイルを取得し、ワーカーマシンはコントロールプレーンマシンから Ignition 設定ファイルを取得します。
- Ignition はマシン上でディスクパーティション、ファイルシステム、ディレクトリーおよびリンクを作成します。Ignition は RAID アレイをサポートしますが、LVM ボリュームはサポートしません。
-
Ignition は永続ファイルシステムのルートを initramfs 内の
/sysrootディレクトリーにマウントし、その/sysrootディレクトリーで機能し始めます。 - Ignition はすべての定義されたファイルシステムを設定し、それらをランタイム時に適切にマウントされるようセットアップします。
-
Ignition は
systemd一時ファイルを実行して、必要なファイルを/varディレクトリーに設定します。 - Ignition は Ignition 設定ファイルを実行し、ユーザー、systemd ユニットファイルその他の設定ファイルをセットアップします。
- Ignition は initramfs にマウントされた永続システムのコンポーネントをすべてアンマウントします。
- Ignition は新しいマシンの init プロセスを開始し、システムの起動時に実行されるマシン上の他のすべてのサービスを開始します。
このプロセスの最後で、マシンはクラスターに参加できる状態になります。再起動は不要です。
