9.4. マウント namespace のカプセル化による CPU 使用率の最適化
マウント namespace のカプセル化を使用して kubelet および CRI-O プロセスにプライベート namespace を提供することで、OpenShift Container Platform クラスターでの CPU 使用率を最適化できます。これにより、機能に違いはなく、systemd が使用するクラスター CPU リソースが削減されます。
マウント namespace のカプセル化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
9.4.1. マウント namespace のカプセル化
マウント namespace は、異なる namespace のプロセスが互いのファイルを表示できないように、マウントポイントを分離するために使用されます。カプセル化は、Kubernetes マウント namespace を、ホストオペレーティングシステムによって常にスキャンされない別の場所に移動するプロセスです。
ホストオペレーティングシステムは systemd を使用して、すべてのマウント namespace (標準の Linux マウントと、Kubernetes が操作に使用する多数のマウントの両方) を常にスキャンします。kubelet と CRI-O の現在の実装はどちらも、すべてのコンテナーランタイムと kubelet マウントポイントに最上位の namespace を使用します。ただし、これらのコンテナー固有のマウントポイントをプライベート namespace にカプセル化すると、systemd のオーバーヘッドが削減され、機能に違いはありません。CRI-O と kubelet の両方に個別のマウント namespace を使用すると、systemd または他のホスト OS の相互作用からコンテナー固有のマウントをカプセル化できます。
CPU の大幅な最適化を潜在的に達成するこの機能は、すべての OpenShift Container Platform 管理者が利用できるようになりました。カプセル化は、Kubernetes 固有のマウントポイントを特権のないユーザーによる検査から安全な場所に保存することで、セキュリティーを向上させることもできます。
次の図は、カプセル化の前後の Kubernetes インストールを示しています。どちらのシナリオも、双方向、ホストからコンテナー、およびなしのマウント伝搬設定を持つコンテナーの例を示しています。
ここでは、systemd、ホストオペレーティングシステムプロセス、kubelet、およびコンテナーランタイムが単一のマウント namespace を共有していることがわかります。
- systemd、ホストオペレーティングシステムプロセス、kubelet、およびコンテナーランタイムはそれぞれ、すべてのマウントポイントにアクセスして可視化できます。
-
コンテナー 1 は、双方向のマウント伝達で設定され、systemd およびホストマウント、kubelet および CRI-O マウントにアクセスできます。
/run/a
などのコンテナー 1 で開始されたマウントは、systemd、ホスト OS プロセス、kubelet、コンテナーランタイム、およびホストからコンテナーへのまたは双方向のマウント伝達が設定されている他のコンテナー (コンテナー 2 のように) に表示されます。 -
ホストからコンテナーへのマウント伝達で設定されたコンテナー 2 は、systemd およびホストマウント、kubelet および CRI-O マウントにアクセスできます。
/run/b
などのコンテナー 2 で発生したマウントは、他のコンテキストからは見えません。 -
マウント伝達なしで設定されたコンテナー 3 には、外部マウントポイントが表示されません。
/run/c
などのコンテナー 3 で開始されたマウントは、他のコンテキストからは見えません。
次の図は、カプセル化後のシステム状態を示しています。
- メインの systemd プロセスは、Kubernetes 固有のマウントポイントの不要なスキャンに専念しなくなりました。systemd 固有のホストマウントポイントのみを監視します。
- ホストオペレーティングシステムプロセスは、systemd およびホストマウントポイントにのみアクセスできます。
- CRI-O と kubelet の両方に個別のマウント namespace を使用すると、すべてのコンテナー固有のマウントが systemd または他のホスト OS の対話から完全に分離されます。
-
コンテナー 1 の動作は変更されていませんが、
/run/a
などのコンテナーが作成するマウントが systemd またはホスト OS プロセスから認識されなくなります。kubelet、CRI-O、およびホストからコンテナーまたは双方向のマウント伝達が設定されている他のコンテナー (コンテナー 2 など) からは引き続き表示されます。 - コンテナー 2 とコンテナー 3 の動作は変更されていません。
9.4.2. マウント namespace のカプセル化の設定
クラスターがより少ないリソースオーバーヘッドで実行されるように、マウント namespace のカプセル化を設定できます。
マウント namespace のカプセル化はテクノロジープレビュー機能であり、デフォルトでは無効になっています。これを使用するには、機能を手動で有効にする必要があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
次の YAML を使用して、
mount_namespace_config.yaml
という名前のファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-kubens-master spec: config: ignition: version: 3.2.0 systemd: units: - enabled: true name: kubens.service --- apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-kubens-worker spec: config: ignition: version: 3.2.0 systemd: units: - enabled: true name: kubens.service
次のコマンドを実行して、マウント namespace
MachineConfig
CR を適用します。$ oc apply -f mount_namespace_config.yaml
出力例
machineconfig.machineconfiguration.openshift.io/99-kubens-master created machineconfig.machineconfiguration.openshift.io/99-kubens-worker created
MachineConfig
CR がクラスターに適用されるまで、最大 30 分かかる場合があります。次のコマンドを実行して、MachineConfig
CR のステータスをチェックできます。$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-03d4bc4befb0f4ed3566a2c8f7636751 False True False 3 0 0 0 45m worker rendered-worker-10577f6ab0117ed1825f8af2ac687ddf False True False 3 1 1
次のコマンドを実行した後、
MachineConfig
CR がすべてのコントロールプレーンとワーカーノードに正常に適用されるまで待ちます。$ oc wait --for=condition=Updated mcp --all --timeout=30m
出力例
machineconfigpool.machineconfiguration.openshift.io/master condition met machineconfigpool.machineconfiguration.openshift.io/worker condition met
検証
クラスターホストのカプセル化を確認するには、次のコマンドを実行します。
クラスターホストへのデバッグシェルを開きます。
$ oc debug node/<node_name>
chroot
セッションを開きます。sh-4.4# chroot /host
systemd マウント namespace を確認します。
sh-4.4# readlink /proc/1/ns/mnt
出力例
mnt:[4026531953]
kubelet マウント namespace をチェックします。
sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt
出力例
mnt:[4026531840]
CRI-O マウント namespace を確認します。
sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt
出力例
mnt:[4026531840]
これらのコマンドは、systemd、kubelet、およびコンテナーランタイムに関連付けられたマウント namespace を返します。OpenShift Container Platform では、コンテナーランタイムは CRI-O です。
上記の例のように、systemd が kubelet および CRI-O とは異なるマウント namespace にある場合、カプセル化が有効になります。3 つのプロセスすべてが同じマウント namespace にある場合、カプセル化は有効ではありません。
9.4.3. カプセル化された namespace の検査
Red Hat Enterprise Linux CoreOS (RHCOS) で利用可能な kubensenter
スクリプトを使用して、デバッグまたは監査の目的でクラスターホストオペレーティングシステムの Kubernetes 固有のマウントポイントを検査できます。
クラスターホストへの SSH シェルセッションは、デフォルトの namespace にあります。SSH シェルプロンプトで Kubernetes 固有のマウントポイントを検査するには、ルートとして kubensenter
スクリプトを実行する必要があります。kubensenter
スクリプトは、マウントカプセル化の状態を認識しており、カプセル化が有効になっていない場合でも安全に実行できます。
oc debug
リモートシェルセッションは、デフォルトで Kubernetes namespace 内で開始されます。oc debug
を使用する場合、マウントポイントを検査するために kubensenter
を実行する必要はありません。
カプセル化機能が有効になっていない場合、kubensenter findmnt
コマンドと findmnt
コマンドは、oc debug
セッションで実行されているか SSH シェルプロンプトで実行されているかに関係なく、同じ出力を返します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - クラスターホストへの SSH アクセスを設定しました。
手順
クラスターホストへのリモート SSH シェルを開きます。以下に例を示します。
$ ssh core@<node_name>
root ユーザーとして、提供された
kubensenter
スクリプトを使用してコマンドを実行します。Kubernetes namespace 内で単一のコマンドを実行するには、コマンドと任意の引数をkubensenter
スクリプトに提供します。たとえば、Kubernetes namespace 内でfindmnt
コマンドを実行するには、次のコマンドを実行します。[core@control-plane-1 ~]$ sudo kubensenter findmnt
出力例
kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt TARGET SOURCE FSTYPE OPTIONS / /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0] | xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota shm tmpfs ...
Kubernetes namespace 内で新しいインタラクティブシェルを開始するには、引数を指定せずに
kubensenter
スクリプトを実行します。[core@control-plane-1 ~]$ sudo kubensenter
出力例
kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
9.4.4. カプセル化された namespace で追加サービスを実行する
ホスト OS で実行する機能に依存し、kubelet、CRI-O、またはコンテナー自体によって作成されたマウントポイントを表示できる監視ツールは、これらのマウントポイントを表示するためにコンテナーマウント namespace に入る必要があります。OpenShift Container Platform に付属する kubensenter
スクリプトは、Kubernetes マウントポイント内で別のコマンドを実行し、既存のツールを適応させるために使用できます。
kubensenter
スクリプトは、マウントカプセル化機能の状態を認識しており、カプセル化が有効になっていない場合でも安全に実行できます。その場合、スクリプトはデフォルトのマウント namespace で提供されたコマンドを実行します。
たとえば、systemd サービスを新しい Kubernetes マウント namespace 内で実行する必要がある場合は、サービスファイルを編集し、kubensenter
で ExecStart=
コマンドラインを使用します。
[Unit] Description=Example service [Service] ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2