サポートコンソール開発者トライアルの開始お問い合わせ

1.2. マシン設定の概要

Machine Config Operator (MCO) は systemd、CRI-O、Kubelet、カーネル、ネットワークマネージャーその他のシステム機能への更新を管理します。また、これはホストに設定ファイルを書き込むことができる MachineConfig CRD を提供します (machine-config-operator を参照)。MCO の機能や、これが他のコンポーネントとどのように対話するかを理解することは、詳細なシステムレベルの変更を OpenShift Container Platform クラスターに加える上で重要です。以下は、MCO、マシン設定、およびそれらの使用方法について知っておく必要のある点です。

  • マシン設定は、名前のアルファベット順、辞書編集上の昇順に処理されます。レンダーコントローラーは、リストの最初のマシン設定をベースとして使用し、残りをベースマシン設定に追加します。
  • マシン設定は、OpenShift Container Platform ノードのプールを表す各システムのオペレーティングシステムのファイルまたはサービスに特定の変更を加えることができます。

  • MCO はマシンのプールのオペレーティングシステムに変更を適用します。すべての OpenShift Container Platform クラスターについては、ワーカーおよびコントロールプレーンノードプールから始まります。ロールラベルを追加することで、ノードのカスタムプールを設定できます。たとえば、アプリケーションが必要とする特定のハードウェア機能が含まれるワーカーノードのカスタムプールを設定できます。ただし、このセクションの例では、デフォルトのプールタイプの変更に重点を置いています。

    重要

    ノードには、master または worker などの複数のラベルを適用できますが、ノードを 単一 のマシン設定プールのメンバーにすることもできます。

  • Machine Config Operator(MCO) は topology.kubernetes.io/zone ラベルに基づいて、ゾーンによってアルファベット順に影響を受けるノードを更新するようになりました。ゾーンに複数のノードがある場合、最も古いノードが最初に更新されます。ベアメタルデプロイメントなど、ゾーンを使用しないノードの場合、ノードは年齢別にアップグレードされ、最も古いノードが最初に更新されます。MCO は、マシン設定プールの maxUnavailable フィールドで指定されたノード数を一度に更新します。
  • 一部のマシン設定は、OpenShift Container Platform がディスクにインストールされる前に行われる必要があります。ほとんどの場合、これは、インストール後のマシン設定として実行されるのではなく、OpenShift Container Platform インストーラープロセスに直接挿入されるマシン設定を作成して実行できます。他の場合に、ノードごとの個別 IP アドレスの設定や高度なディスクのパーティション設定などを行うには、OpenShift Container Platform インストーラーの起動時にカーネル引数を渡すベアメタルのインストールを実行する必要がある場合があります。
  • MCO はマシン設定で設定される項目を管理します。MCO が競合するファイルを管理することを明示的に指示されない限り、システムに手動で行う変更は MCO によって上書きされることはありません。つまり、MCO は要求される特定の更新のみを行い、ノード全体に対する制御を要求しません。
  • ノードの手動による変更は推奨されません。ノードの使用を中止して新規ノードを起動する必要がある場合は、それらの直接的な変更は失われます。
  • MCO は、/etc および /var ディレクトリーのファイルに書き込みを行う場合にのみサポートされます。ただし、これらの領域のいずれかにシンボリックリンクを指定して書き込み可能になるディレクトリーへのシンボリックリンクもあります。/opt および /usr/local ディレクトリーが例になります。
  • Ignition は MachineConfig で使用される設定形式です。詳細は、Ignition 設定仕様 v3.2.0 を参照してください。
  • Ignition 設定は OpenShift Container Platform のインストール時に直接提供でき、MCO が Ignition 設定を提供するのと同じ方法でフォーマットできますが、MCO では元の Ignition 設定を確認する方法がありません。そのため、それらをデプロイする前に Ignition 設定をマシン設定にラップする必要があります。
  • MCO で管理されるファイルが MCO 外で変更されると、Machine Config Daemon (MCD) はノードを degraded として設定します。これは問題のあるファイルを上書きしませんが、継続して degraded 状態で動作します。
  • マシン設定を使用する主な理由として、これは OpenShift Container Platform クラスターのプールに対して新規ノードを起動する際に適用されます。machine-api-operator は新規マシンをプロビジョニングし、MCO がこれを設定します。

MCO は Ignition を設定形式として使用します。OpenShift Container Platform バージョン 4.6 では、Ignition 設定仕様のバージョン 2 から 3 に移行しています。

1.2.1. マシン設定で変更できる設定

MCO で変更できるコンポーネントの種類には、以下が含まれます。

  • config: Ignition 設定オブジェクト (Ignition 設定仕様 を参照してください) を作成し、以下を含む OpenShift Container Platform マシン上でのファイル、systemd サービスおよびその他の機能の変更などを実行できます。

    • Configuration files: /var または /etc ディレクトリーでファイルを作成するか、上書きします。
    • systemd units: systemd サービスを作成し、そのステータスを設定するか、追加設定により既存の systemd サービスに追加します。

    • users and groups: インストール後に passwd セクションで SSH キーを変更します。

      重要
      • マシン設定を使用した SSH キーの変更は、core ユーザーにのみサポートされています。
      • マシン設定を使用した新しいユーザーの追加はサポートされていません。
  • kernelArguments: OpenShift Container Platform ノードの起動時に、引数をカーネルコマンドラインに追加します。
  • kernelType: オプションで、標準カーネルの代わりに使用する標準以外のカーネルを特定します。(RAN の) RT カーネルを使用するには、realtime を使用します。これは一部のプラットフォームでのみサポートされます。64k-pages パラメーターを使用して、64k ページサイズのカーネルを有効にします。この設定は、64 ビット ARM アーキテクチャーを使用するマシンに限定されます。

  • fips: FIPS モードを有効にします。FIPS は、インストール後の手順ではなく、インストール時に設定する必要があります。

    重要

    クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

    FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

  • extensions: 事前にパッケージ化されたソフトウェアを追加して RHCOS 機能を拡張します。この機能には、利用可能な拡張機能には usbguard およびカーネルモジュールが含まれます。
  • カスタムリソース (ContainerRuntime および Kubelet 用): マシン設定外で、MCO は CRI-O コンテナーランタイムの設定 (ContainerRuntime CR) および Kubelet サービス (Kubelet CR) を変更するために 2 つの特殊なカスタムリソースを管理します。

MCO は、OpenShift Container Platform ノードでオペレーティングシステムコンポーネントを変更できる唯一の Operator という訳ではありません。他の Operator もオペレーティングシステムレベルの機能を変更できます。1 つの例として、Node Tuning Operator を使用して、Tuned デーモンプロファイルを使用したノードレベルのチューニングを実行できます。

インストール後に実行できる MCO 設定のタスクは、次の手順に記載されています。OpenShift Container Platform のインストール時またはインストール前に実行する必要のあるシステム設定タスクには、RHCOS ベアメタルのインストールに関する説明を参照してください。デフォルトでは、MCO で行う多くの変更には再起動が必要です。

以下の変更は、ノードの再起動をトリガーしません。

  • MCO が以下の変更のいずれかを検出すると、ノードのドレインまたは再起動を行わずに更新を適用します。

    • マシン設定の spec.config.passwd.users.sshAuthorizedKeys パラメーターの SSH キーの変更。
    • openshift-config namespace でのグローバルプルシークレットまたはプルシークレットへの変更
    • Kubernetes API Server Operator による /etc/kubernetes/kubelet-ca.crt 認証局 (CA) の自動ローテーション。

  • MCO は、/etc/containers/registries.conf ファイルへの変更 (ImageDigestMirrorSet、ImageTagMirrorSet、または ImageContentSourcePolicy オブジェクトの追加や編集など) を検出すると、対応するノードをドレインし、変更を適用し、ノードの分離を解除します。次の変更ではノードドレインは発生しません。

    • pull-from-mirror = "digest-only" パラメーターがミラーごとに設定されたレジストリーの追加。
    • pull-from-mirror = "digest-only" パラメーターがレジストリーに設定されたミラーの追加。
    • unqualified-search-registries へのアイテムの追加。

その他のケースでは、ノード停止ポリシー を使用することで、MCO が変更を加えたときにワークロードの停止を軽減できます。詳細は、マシン設定の変更後のノード再起動動作について を参照してください。

ノードの設定が、現在適用されている machine config で指定されているものと完全に一致しない場合があります。この状態は 設定ドリフト と呼ばれます。Machine Config Daemon (MCD) は、ノードの設定ドラフトを定期的にチェックします。MCD が設定のドリフトを検出した場合、管理者がノード設定を修正するまで、MCO はノードを degraded とマークします。degraded 状態のノードは、オンラインであり動作中ですが、更新することはできません。設定ドリフトの詳細は、Understanding configuration drift detection を参照してください。

1.2.2. machine config pool を使用したノード設定管理

コントロールプレーンのコンポーネントまたはユーザーワークロードを実行するマシンは、それらが処理するリソースタイプに基づいてグループに分類されます。マシンのこれらのグループは machine config pool (MCP) と呼ばれます。それぞれの MCP はノードのセットおよびその対応する machine config を管理します。ノードのロールは、これが所属する MCP を判別します。MCP は割り当てられたノードロールラベルに基づいてノードを制御します。MCP のノードには同じ設定があります。つまり、ワークロードの増減に応じてノードのスケールアップおよび破棄が可能です。

デフォルトで、クラスターのインストール時にクラスターによって作成される 2 つの MCP ( master および worker) があります。それぞれのデフォルト MCP には、Machine Config Operator (MCO) によって適用される定義済みの設定があり、これは MCP を管理し、MCP 更新を容易にするために使用されます。

ワーカーノードの場合、追加の MCP またはカスタムプールを作成して、デフォルトのノードタイプの範囲を超えるカスタムユースケースを持つノードを管理できます。コントロールプレーンノードのカスタム MCP はサポートされていません。

カスタムプールは、ワーカープールから設定を継承するプールです。これらはワーカープールのターゲット設定を使用しますが、カスタムプールのみをターゲットに設定する変更をデプロイする機能を追加します。カスタムプールはワーカープールから設定を継承するため、ワーカープールへの変更もカスタムプールに適用されます。ワーカープールから設定を継承しないカスタムプールは MCO ではサポートされません。

注記

ノードは 1 つの MCP にのみ含めることができます。ノードにいくつかの MCP に対応するラベルがある場合 (worker,infra など)、これはワーカープールではなく infra カスタムプールによって管理されます。カスタムプールは、ノードラベルに基づいて管理するノードの選択を優先します。カスタムプールに属さないノードはワーカープールによって管理されます。

クラスターで管理するすべてのノードロールについてカスタムプールを使用することが推奨されます。たとえば、infra ワークロードを処理するために infra ノードを作成する場合、それらのノードをまとめるためにカスタム infra MCP を作成することが推奨されます。infra ロールラベルをワーカーノードに適用し、これが worker,infra の二重ラベルを持つようにするものの、カスタム infra MCP がない場合、MCO はこれをワーカーノードと見なします。ノードから worker ラベルを削除して、これをカスタムプールで分類せずに infra ラベルを適用する場合、ノードは MCO によって認識されず、クラスターによって管理されません。

重要

infra ワークロードのみを実行する infra ロールのラベルが付いたノードは、サブスクリプションの合計数にカウントされません。infra ノードを管理する MCP は、クラスターでサブスクリプション料金を決定する方法と相互に排他的です。適切な infra ロールを持つノードにテイントを付け、テイントを使用してユーザーのワークロードがそのノードにスケジュールされないようにすることが、infra ワークロードのサブスクリプション料金を防ぐための唯一の要件になります。

MCO はプールの更新を個別に適用します。たとえば、すべてのプールに影響を与える更新がある場合、各プールのノードは相互に並行して更新されます。カスタムプールを追加する場合、そのプールのノードはマスターおよびワーカーノードとの同時更新を試みます。

ノードの設定が、現在適用されている machine config で指定されているものと完全に一致しない場合があります。この状態は 設定ドリフト と呼ばれます。Machine Config Daemon (MCD) は、ノードの設定ドラフトを定期的にチェックします。MCD が設定のドリフトを検出した場合、管理者がノード設定を修正するまで、MCO はノードを degraded とマークします。degraded 状態のノードは、オンラインであり動作中ですが、更新することはできません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.