Red Hat Summit第16章 RHCOS イメージのレイヤー化
Red Hat Enterprise Linux CoreOS (RHCOS) イメージのレイヤー化を使用すると、ベースイメージの上に追加のイメージを 重ねる ことで、ベース RHCOS イメージの機能を簡単に拡張できます。このレイヤー化は、RHCOS のベースイメージを変更するものではありません。代わりに、すべての RHCOS 機能を含む カスタムレイヤーイメージ を作成し、クラスター内の特定のノードに追加機能を追加します。
Containerfile を使用してカスタムレイヤーイメージを作成し、それを MachineConfig オブジェクトを使用してノードに適用します。Machine Config Operator は、関連付けられたマシン設定の osImageURL 値で指定されているように、RHCOS の基本イメージをオーバーライドし、新しいイメージを起動します。マシン設定を削除することにより、カスタムレイヤーイメージを削除できます。MCO は、ノードを再起動して RHCOS の基本イメージに戻します。
RHCOS イメージのレイヤー化を使用すると、RPM を基本イメージにインストールでき、カスタムコンテンツが RHCOS と一緒に起動されます。Machine Config Operator (MCO) は、デフォルトの RHCOS イメージの場合と同じ方法で、これらのカスタムレイヤーイメージをロールアウトし、これらのカスタムコンテナーを監視できます。RHCOS イメージのレイヤー化により、RHCOS ノードの管理方法がより柔軟になります。
リアルタイムカーネルと拡張機能の RPM をカスタムレイヤードコンテンツとしてインストールすることは推奨しません。これは、これらの RPM が、マシン設定を使用してインストールされた RPM と競合する可能性があるためです。競合がある場合、MCO がマシン設定 RPM をインストールしようとすると、degraded 状態になります。続行する前に、競合する拡張機能をマシン設定から削除する必要があります。
カスタムレイヤーイメージをクラスターに適用するとすぐに、カスタムレイヤーイメージとそれらのノードの 所有権 を効率的に取得できます。Red Hat は引き続き標準ノード上の RHCOS の基本イメージの維持と更新を担当しますが、カスタムレイヤーイメージを使用するノードのイメージの維持と更新はお客様の責任となります。カスタムレイヤーイメージで適用したパッケージと、パッケージで発生する可能性のある問題については、お客様が責任を負うものとします。
カスタムレイヤー化イメージを適用するには、適用する OpenShift Container Platform イメージと RPM を参照する Containerfile を作成します。次に、結果のカスタムレイヤー化イメージをイメージレジストリーにプッシュします。非実稼働環境の OpenShift Container Platform クラスターで、新しいイメージを指すターゲットノードプールの MachineConfig オブジェクトを作成します。
クラスターの残りの部分にインストールされている同じ基本 RHCOS イメージを使用します。oc adm release info --image-for rhel-coreos コマンドを使用して、クラスターで使用される基本イメージを取得します。
RHCOS イメージのレイヤー化により、次のタイプのイメージを使用して、カスタムレイヤー化イメージを作成できます。
OpenShift Container Platform ホットフィックス。Customer Experience and Engagement (CEE) を使用して、ホットフィックスパッケージ を取得し、RHCOS イメージに適用することができます。場合によっては、公式の OpenShift Container Platform リリースに含まれる前に、バグ修正または機能強化が必要になることがあります。RHCOS イメージのレイヤー化により、公式にリリースされる前にホットフィックスを簡単に追加し、基になる RHCOS イメージに修正が組み込まれたときにホットフィックスを削除できます。
重要一部のホットフィックスは Red Hat Support Exception を必要とし、OpenShift Container Platform のサポート範囲またはライフサイクルポリシーの通常の範囲外です。
ホットフィックスが必要な場合は、Red Hat ホットフィックスポリシー に基づいて提供されます。それを基本イメージ上に適用し、その新しいカスタムレイヤーイメージを非実稼働環境でテストします。カスタムレイヤーイメージが実稼働環境で安全に使用できることを確認したら、独自のスケジュールで特定のノードプールにロールアウトできます。何らかの理由で、カスタムレイヤーイメージを簡単にロールバックして、デフォルトの RHCOS の使用に戻すことができます。
ホットフィックスを適用する Containerfile の例
# Using a 4.12.0 image FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256... #Install hotfix rpm RUN rpm-ostree override replace https://example.com/myrepo/haproxy-1.0.16-5.el8.src.rpm && \ rpm-ostree cleanup -m && \ ostree container commitRHEL パッケージ。chrony、firewalld、iputils などの Red Hat Enterprise Linux (RHEL) パッケージは、Red Hat Customer Portal からダウンロードできます。
firewalld ユーティリティーを適用する Containerfile の例
FROM quay.io/openshift-release-dev/ocp-release@sha256... ADD configure-firewall-playbook.yml . RUN rpm-ostree install firewalld ansible && \ ansible-playbook configure-firewall-playbook.yml && \ rpm -e ansible && \ ostree container commitlibreswan ユーティリティーを適用する Containerfile の例
# Get RHCOS base image of target cluster `oc adm release info --image-for rhel-coreos` # hadolint ignore=DL3006 FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256... # Install our config file COPY my-host-to-host.conf /etc/ipsec.d/ # RHEL entitled host is needed here to access RHEL packages # Install libreswan as extra RHEL package RUN rpm-ostree install libreswan && \ systemctl enable ipsec && \ ostree container commitlibreswan には追加の RHEL パッケージが必要なため、イメージは資格のある RHEL ホスト上に構築する必要があります。
サードパーティーのパッケージ。次のタイプのパッケージなど、サードパーティーから RPM をダウンロードおよびインストールできます。
- 最先端のドライバーとカーネルの強化により、パフォーマンスを向上させたり、機能を追加したりします。
- 侵入の可能性と実際の侵入を調査するためのフォレンジッククライアントツール。
- セキュリティーエージェント。
- クラスター全体の一貫性のあるビューを提供するインベントリーエージェント。
- SSH キー管理パッケージ。
EPEL からサードパーティーパッケージを適用する Containerfile の例
# Get RHCOS base image of target cluster `oc adm release info --image-for rhel-coreos` # hadolint ignore=DL3006 FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256... # Install our config file COPY my-host-to-host.conf /etc/ipsec.d/ # RHEL entitled host is needed here to access RHEL packages # Install libreswan as extra RHEL package RUN rpm-ostree install libreswan && \ systemctl enable ipsec && \ ostree container commitRHEL 依存関係のあるサードパーティーパッケージを適用するための Containerfile の例
# Get RHCOS base image of target cluster `oc adm release info --image-for rhel-coreos` # hadolint ignore=DL3006 FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256... # Install our config file COPY my-host-to-host.conf /etc/ipsec.d/ # RHEL entitled host is needed here to access RHEL packages # Install libreswan as extra RHEL package RUN rpm-ostree install libreswan && \ systemctl enable ipsec && \ ostree container commitこの Containerfile は、Linux fish プログラムをインストールします。fish には追加の RHEL パッケージが必要なため、イメージはエンタイトルメントのある RHEL ホストでビルドする必要があります。
マシン設定を作成した後、Machine Config Operator (MCO) は次の手順を実行します。
- 指定された 1 つ以上のプールの新しいマシン設定をレンダリングします。
- 1 つ以上のプール内のノードに対して、スケジューリング対象から外す操作とドレイン操作を実行します。
- 残りのマシン設定パラメーターをノードに書き込みます。
- カスタムレイヤーイメージをノードに適用します。
- 新しいイメージを使用してノードを再起動します。
クラスターにロールアウトする前に、実稼働環境の外でイメージをテストすることを強く推奨します。
16.1. RHCOS カスタムレイヤーイメージの適用
特定のマシン設定プール内のノードで、Red Hat Enterprise Linux CoreOS (RHCOS) イメージのレイヤー化を簡単に設定できます。Machine Config Operator (MCO) は、ベースの Red Hat Enterprise Linux CoreOS (RHCOS) イメージを上書きして、新しいカスタムレイヤーイメージでこれらのノードを再起動します。
カスタムレイヤーイメージをクラスターに適用するには、クラスターがアクセスできるリポジトリーにカスタムレイヤーイメージが必要です。次に、カスタムレイヤーイメージを指す MachineConfig オブジェクトを作成します。設定するマシン設定プールごとに個別の MachineConfig オブジェクトが必要です。
カスタムレイヤーイメージを設定すると、OpenShift Container Platform は、カスタムレイヤーイメージを使用するノードを自動的に更新しなくなりました。必要に応じてノードを手動で更新する必要があります。カスタムレイヤーをロールバックすると、OpenShift Container Platform は再びノードを自動的に更新します。カスタムレイヤーイメージを使用するノードの更新に関する重要な情報は、以下の追加リソースセクションを参照してください。
前提条件
タグではなく、OpenShift Container Platform イメージダイジェストに基づくカスタムレイヤーイメージを作成する必要があります。
注記クラスターの残りの部分にインストールされているのと同じ RHCOS の基本イメージを使用する必要があります。
oc adm release info --image-for rhel-coreosコマンドを使用して、クラスターで使用されている基本イメージを取得します。たとえば、次の Containerfile は、OpenShift Container Platform 4.13 イメージからカスタムのレイヤードイメージを作成し、カーネルパッケージを CentOS 9 Stream のイメージでオーバーライドします。
カスタムレイヤーイメージの Containerfile の例
# Using a 4.13.0 image FROM quay.io/openshift-release/ocp-release@sha256... 1 #Install hotfix rpm RUN rpm-ostree cliwrap install-to-root / && \ 2 rpm-ostree override replace http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/Packages/kernel-{,core-,modules-,modules-core-,modules-extra-}5.14.0-295.el9.x86_64.rpm && \ 3 rpm-ostree cleanup -m && \ ostree container commit
注記Containerfile の作成方法は、このドキュメントの範囲外です。
-
カスタムレイヤーイメージをビルドするプロセスはクラスターの外部で実行されるため、Podman または Buildah で
--authfile/path/to/pull-secretオプションを使用する必要があります。あるいは、これらのツールでプルシークレットを自動的に読み取るようにするには、デフォルトのファイルの場所のいずれかに追加できます。~/.docker/config.json、$XDG_RUNTIME_DIR/containers/auth.json、~/.docker/config.json、または~/.dockercfg。詳細は、containers-auth.jsonのマニュアルページを参照してください。 - カスタムレイヤーイメージを、クラスターがアクセスできるリポジトリーにプッシュする必要があります。
手順
マシン設定プールを作成します。
以下のような YAML ファイルを作成します。
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker 1 name: os-layer-custom spec: osImageURL: quay.io/my-registry/custom-image@sha256... 2MachineConfigオブジェクトを作成します。$ oc create -f <file_name>.yaml
重要クラスターにロールアウトする前に、実稼働環境の外でイメージをテストすることを強く推奨します。
検証
次のチェックのいずれかを実行することで、カスタムレイヤーイメージが適用されていることを確認できます。
ワーカーマシン設定プールが新しいマシン設定でロールアウトされていることを確認します。
新しいマシン設定が作成されたことを確認します。
$ oc get mc
出力例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 00-worker 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 01-master-container-runtime 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 01-master-kubelet 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 01-worker-container-runtime 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 01-worker-kubelet 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 99-master-generated-registries 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 99-master-ssh 3.2.0 98m 99-worker-generated-registries 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m 99-worker-ssh 3.2.0 98m os-layer-custom 10s 1 rendered-master-15961f1da260f7be141006404d17d39b 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m rendered-worker-5aff604cb1381a4fe07feaf1595a797e 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 95m rendered-worker-5de4837625b1cbc237de6b22bc0bc873 5bdb57489b720096ef912f738b46330a8f577803 3.2.0 4s 2
新しいマシン設定の
osImageURL値が予測されるイメージを指していることを確認します。$ oc describe mc rendered-worker-5de4837625b1cbc237de6b22bc0bc873
出力例
Name: rendered-worker-5de4837625b1cbc237de6b22bc0bc873 Namespace: Labels: <none> Annotations: machineconfiguration.openshift.io/generated-by-controller-version: 5bdb57489b720096ef912f738b46330a8f577803 machineconfiguration.openshift.io/release-image-version: {product-version}.0-ec.3 API Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig ... Os Image URL: quay.io/my-registry/custom-image@sha256...関連するマシン設定プールが新しいマシン設定で更新されていることを確認します。
$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-15961f1da260f7be141006404d17d39b True False False 3 3 3 0 39m worker rendered-worker-5de4837625b1cbc237de6b22bc0bc873 True False False 3 0 0 0 39m 1- 1
UPDATINGフィールドがTrueの場合、マシン設定プールは新しいマシン設定で更新されます。この場合、新しいマシン設定は出力にリストされません。フィールドがFalseになると、ワーカーマシン設定プールが新しいマシン設定にロールアウトされます。
ノードをチェックして、ノードのスケジューリングが無効になっていることを確認します。これは、変更が適用されていることを示しています。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-148-79.us-west-1.compute.internal Ready worker 32m v1.26.0 ip-10-0-155-125.us-west-1.compute.internal Ready,SchedulingDisabled worker 35m v1.26.0 ip-10-0-170-47.us-west-1.compute.internal Ready control-plane,master 42m v1.26.0 ip-10-0-174-77.us-west-1.compute.internal Ready control-plane,master 42m v1.26.0 ip-10-0-211-49.us-west-1.compute.internal Ready control-plane,master 42m v1.26.0 ip-10-0-218-151.us-west-1.compute.internal Ready worker 31m v1.26.0
ノードが
Ready状態に戻ったら、ノードがカスタムレイヤーイメージを使用していることを確認します。ノードへの
oc debugセッションを開きます。以下に例を示します。$ oc debug node/ip-10-0-155-125.us-west-1.compute.internal
/hostをデバッグシェル内のルートディレクトリーとして設定します。sh-4.4# chroot /host
rpm-ostree statusコマンドを実行して、カスタムレイヤーイメージが使用されていることを確認します。sh-4.4# sudo rpm-ostree status
出力例
State: idle Deployments: * ostree-unverified-registry:quay.io/my-registry/... Digest: sha256:...
