第5章 Red Hat Enterprise Linux CoreOS (RHCOS)
5.1. RHCOS について
Red Hat Enterprise LinuxにCoreOS (RHCOS) は、次世代の専用コンテナーオペレーティングシステムテクノロジーの代表格です。Red Hat Enterprise Linux Atomic Host と CoreOS Container Linux を開発した同じチームによって開発された RHCOS は、Red Hat Enterprise Linux (RHEL) の品質基準と Container Linux の自動化されたリモートアップグレード機能を兼ね備えています。
RHCOS は、すべての OpenShift Container Platform マシンの１つの OpenShift Container Platform 4.1 コンポーネントとしてのみサポートされます。RHCOS は、OpenShift Container Platform のコントロールプレーンまたはマスターマシン向けに唯一サポートされるオペレーティングシステムです。RHCOS はすべてのクラスターマシンのデフォルトオペレーティングシステムですが、 RHEL をオペレーティングシステムとして使用するコンピュートマシン (ワーカーマシンとしても知られる) を作成することもできます。
クラスターがプロビジョニングするインフラストラクチャーにクラスターをインストールする場合は、インストール時に RHCOS イメージがターゲットのプラットフォームにダウンロードされ、RHCOS 設定を制御する適切な Ignition 設定ファイルがマシンをデプロイするために使用されます。クラスターを独自に管理するインフラストラクチャーにインストールする場合、インストールについてのドキュメントを参照して RHCOS イメージの取得や、Ignition 設定ファイルの生成、および設定ファイルの使用によるマシンのプロビジョニングを行ってください。
5.1.1. RHCOS の主な機能
以下は、RHCOS オペレーティングシステムの主要な機能について説明しています。
基礎となるオペレーティングシステムは、主に RHEL のコンポーネントで構成されます。RHEL をサポートする品質、セキュリティーおよび管理基準が RHCOS にも同様に適用されます。たとえば、RHCOS ソフトウェアは RPM パッケージにあり、各 RHCOS システムは、RHEL カーネル、および systemd init システムで管理される一連のサービスと共に起動します。
RHCOS には、RHEL コンポーネントが含まれているものの、RHCOS はデフォルトの RHEL インストールの場合よりも厳密に管理されるように設計されています。これは OpenShift Container Platform クラスターからリモートで管理されます。RHCOS マシンをセットアップする際には、いくつかのシステム設定のみを変更するだけで対応することが可能です。RHCOS のこの管理機能および不変性により、OpenShift Container Platform では RHCOS システムの最新の状態をクラスターに保存し、最新の RHCOS 設定に基づいて追加のマシンの作成や更新を実行することができます。
RHCOS には Docker で必要な OCI および libcontainer 形式のコンテナーを実行する機能が含まれていますが、Docker コンテナーエンジンではなく CRI-O コンテナーエンジンが組み込まれています。OpenShift Container Platform などの、Kubernetes プラットフォームが必要とする機能に重点が置かれている CRI-O では、複数の異なる Kubernetes バージョンとの特定の互換性が提供されます。また、CRI-O は、大規模な機能セットを提供するコンテナーエンジンの場合よりもフットプリントや攻撃領域を縮小できます。現時点で、 CRI-O は OpenShift Container Platform クラスター内で利用可能な唯一のコンテナーエンジンです。
ビルド、コピーまたはコンテナーの管理などのタスクに備え、RHCOS では Docker CLI ツールが互換性のあるコンテナーツールセットに置き換えられます。Podman CLI ツールは、コンテナーおよびコンテナーイメージの実行、起動、停止、一覧表示および削除などの数多くのコンテナーランタイム機能をサポートします。skopeo CLI ツールは、イメージのコピー、認証およびイメージへの署名を実行できます。crictl CLI ツールを使用すると、CRI-O コンテナーエンジンからコンテナーおよび Pod を使用できます。これらのツールを RHCOS 内で直接使用することは推奨されていませんが、デバッグの目的で使用することは可能です。
RHCOS は、rpm-ostree システムを使用したトランザクション型のアップグレードを特長としています。更新はコンテナーイメージ経由で提供され、OpenShift 更新プロセスの一部となっています。コンテナーイメージはデプロイされると、プルされ、展開されてディスクに書き込まれます。その後にブートローダーが新規バージョンで起動するように変更されます。 マシンはローリング方式で更新に対して再起動し、クラスターの容量への影響が最小限に抑えられます。
RHCOS システムの場合、rpm-ostree ファイルシステムのレイアウトには、以下の特徴があります。
-
/usr: オペレーティングシステムのバイナリーとライブラリーが保管される場所で、読み取り専用です。これを変更することはサポートされていません。 -
/etc、/boot、/var: システム上で書き込み可能ですが、Machine Config Operator によってのみ変更されることが意図されています。 -
/var/lib/containers: コンテナーイメージを保管するためのグラフストレージの場所です。
OpenShift Container Platform では、Machine Config Operator がオペレーティングシステムのアップグレードを処理します。yum で実行される場合のように個々のパッケージをアップグレードする代わりに、rpm-ostree は OS のアップグレードを atomic 単位として提供します。新規の OS デプロイメントはアップグレード時に段階が設定され、次回の再起動時に実行されます。アップグレードに不具合が生じた場合は、単一ロールバックおよび再起動によってシステムが以前の状態に戻ります。OpenShift Container Platform での RHCOS アップグレードは、クラスターの更新時に実行されます。
5.1.2. OpenShift Container Platform での RHCOS の設定
OpenShift Container Platform では、RHCOS イメージは最初に Ignition と呼ばれる機能でセットアップされます。これは、システムの初回起動時にのみ実行されます。初回の起動後に、RHCOS システムは、OpenShift Container Platform クラスターで実行される Machine Config Operator (MCO) によって管理されます。
OpenShift Container Platform の RHCOS システム は OpenShift Container Platform クラスターから完全に管理されるように設計されているため、RHCOS マシンに直接ログインすることは推奨されていません。OpenShift Container Platform クラスターでの RHCOS マシンへの限定的な直接アクセスは、デバッグの目的で実行できます。
5.1.3. Ignition について
Ignition は、初回設定時にディスクを操作するために RHCOS によって使用されるユーティリティーです。これにより、ディスクのパーティション設定やパーティションのフォーマット、ファイル作成、ユーザー設定などの一般的なディスク関連のタスクが実行されます。初回起動時に、Ignition はインストールメディアや指定した場所からその設定を読み込み、その設定をマシンに適用します。
クラスターをインストールする場合かマシンをクラスターに追加する場合かを問わず、Ignition は常に OpenShift Container Platform クラスターマシンの初期設定を実行します。実際のシステム設定のほとんどは、各マシン自体で行われます。各マシンで、Ignition は、RHCOS イメージを取得し、RHCOS カーネルを起動します。カーネルコマンドラインのオプションで、デプロイメントのタイプや Ignition で有効にされた初期 RAM ディスク (initramfs) の場所を特定します。
OpenShift Container Platform は、Ignition のバージョン 2 および Ignition 設定バージョン 2.3 を使用します。
5.1.3.1. Ignition の仕組み
Ignition を使用してマシンを作成するには、Ignition 設定ファイルが必要です。OpenShift Container Platform のインストレーションプログラムは、クラスターを作成するのに必要な Ignition 設定ファイルを作成します。これらのファイルは、インストレーションプログラムに直接指定するか、または install-config.yaml ファイルを通じて提供される情報に基づくものです。
Ignition がマシンを設定する方法は、cloud-init や Linux Anacondakickstart などのツールがシステムを設定する方法に似ていますが、以下のような重要な違いがあります。
- 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 はこれを見つけ、システムを正しく設定することができます。
5.1.3.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 プロセスを開始し、システムの起動時に実行されるマシン上の他のすべてのサービスを開始します。
マシンはクラスターに参加できる状態になります。再起動は不要dです。
