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

Windows Container Support for OpenShift

OpenShift Container Platform 4.18

Red Hat OpenShift for Windows Containers ガイド

Red Hat OpenShift Documentation Team

概要

Red Hat OpenShift for Windows Containers は、OpenShift Container Platform で Microsoft Windows Server コンテナーを実行するための組み込みサポートを提供します。このガイドでは、すべての詳細情報を提供します。

第1章 Red Hat OpenShift support for Windows Containers の概要
リンクのコピー

Red Hat OpenShift support for Windows Containers は、OpenShift Container Platform クラスターで Windows コンピュートノードを実行する機能を提供します。これは、Red Hat Windows Machine Config Operator (WMCO) を使用して Windows ノードをインストールし、管理することで実行できます。Red Hat Subscription を使用すると、OpenShift Container Platform での Windows ワークロードの実行をサポートできます。WMCO によってデプロイされる Windows インスタンスは、containerd コンテナーランタイムで設定されます。詳細は、リリースノート を参照してください。

Windows ノードを追加するには、コンピュートマシンセット を作成するか、configuration map で既存の Bring-Your-Own-Host (BYOH) ウィンドウインスタンスを指定します。

注記

コンピュートマシンセットは、ベアメタルまたはプロバイダーに依存しないクラスターではサポートされていません。

Linux と Windows の両方を含むワークロードの場合、OpenShift Container Platform を使用すると、Windows Server コンテナーで実行される Windows ワークロードをデプロイすると同時に、Red Hat Enterprise Linux CoreOS (RHCOS) または Red Hat Enterprise Linux (RHEL) でホストされる従来の Linux ワークロードを提供できます。詳細は、Windows コンテナーワークロードのスタートガイド を参照してください。

クラスターで Windows ワークロードを実行するには、WMCO が必要です。WMCO は、クラスター上で Windows ワークロードをデプロイし、管理するプロセスをオーケストレーションします。詳細は、Windows コンテナーワークロードを有効にする方法 を参照してください。

Windows MachineSet オブジェクトを作成して、インフラストラクチャー Windows マシンセットおよび関連マシンを作成し、サポートされている Windows ワークロードを新しい Windows マシンに移動できます。複数のプラットフォームで Windows MachineSet オブジェクトを作成できます。

Windows コンピュートノードに Windows ワークロードをスケジュール できます。

Windows Machine Config Operator のアップグレードを実行 して、Windows ノードに最新の更新が適用されていることを確認できます。

特定のマシンを削除することで、Windows ノードを削除 できます。

Bring-Your-Own-Host (BYOH) Windows インスタンスを使用 して、Windows Server VM を再利用し、OpenShift Container Platform に移動できます。BYOH Windows インスタンスは、Windows サーバーがオフラインになった場合に大規模なサービス中断を軽減するのに役立ちます。BYOH Windows インスタンスは、OpenShift Container Platform 4.8 以降のバージョンのノードとして使用できます。

次の手順を実行して、Windows コンテナーのワークロードを無効化 できます。

  • Windows Machine Config Operator のアンインストール
  • Windows Machine Config Operator namespace の削除

第2章 リリースノート
リンクのコピー

2.1. Red Hat OpenShift support for Windows Containers リリースノート
リンクのコピー

2.1.1. Red Hat Windows Machine Config Operator 10.18.1 のリリースノート
リンクのコピー

発行日: 2025 年 5 月 27 日

Windows Machine Config Operator (WMCO) のこのリリースでは、OpenShift Container Platform クラスターで Windows コンピュートノードを実行するためのバグ修正が提供されます。WMCO 10.18.1 のコンポーネントは、RHSA-2025:8224 でリリースされています。

2.1.1.1. バグ修正
リンクのコピー
  • 以前は、ImageTagMirrorSet (ITMS) オブジェクトのソースに組織名または namespace が含まれている場合、Windows ノードがイメージミラーレジストリーからプルできませんでした。この修正により、ITMS オブジェクトに組織名または namespace を含めることができるようになります。この変更により、ミラーレジストリーの使用に関する追加のガイドラインと要件が OpenShift Container Platform ドキュメントに追記されました。(OCPBUGS-55787)

2.2. Windows Machine Config Operator の過去のリリースのリリースノート
リンクのコピー

次のリリースノートは、Windows Machine Config Operator (WMCO) の以前のバージョンに関するものです。

最新バージョンは、Red Hat OpenShift support for Windows Containers リリースノート を参照してください。

2.2.1. Red Hat Windows Machine Config Operator 10.18.0 のリリースノート
リンクのコピー

発行日: 2025 年 3 月 19 日

Windows Machine Config Operator (WMCO) のこのリリースでは、OpenShift Container Platform クラスターで Windows コンピュートノードを実行するためのバグ修正が提供されます。WMCO 10.18.0 のコンポーネントは RHBA-2025:3040 でリリースされました。

2.2.1.1. 新機能および改善点
リンクのコピー
2.2.1.1.1. Pod の水平自動スケーリングが Windows ワークロードで利用可能になる
リンクのコピー

Horizontal Pod Autoscaler (HPA) を使用して、CPU やメモリーのリソースメトリクスに基づいて Windows Pod をスケーリングできるようになりました。HPA の使用に関する詳細は、Horizontal Pod Autoscaler での Pod の自動スケーリング を参照してください。

2.2.1.1.2. コントロールプレーンのみの更新が Windows ノードで利用可能になる
リンクのコピー

コントロールプレーンのみの更新 (以前は EUS から EUS への更新 と呼ばれていました) を使用して、OpenShift Container Platform EUS バージョン間で Windows ノードを更新できるようになりました。詳細は、Windows Machine Config Operator のコントロールプレーンのみのアップグレード を参照してください。

2.2.1.1.3. WMCO のメトリクスエンドポイントが HTTPS になる
リンクのコピー

WMCO のメトリクスエンドポイントが HTTPS 経由で公開されるようになりました。以前は、WMCO の Pod メトリクスは HTTP 経由で提供されていました。この変更により、WMCO メトリクスエンドポイントのセキュリティー体制が強化されます。

2.2.1.1.4. WMCO がデフォルトで info レベルのロギングを使用するようになる
リンクのコピー

WMCO は、デフォルトで info ログレベルを使用するように設定されています。WMCO のサブスクリプションオブジェクトを編集することで、ログレベルを debug に変更できます。詳細は、Windows Machine Config Operator に debug レベルのロギングを設定する を参照してください。

2.2.1.1.5. Kubernetes のアップグレード
リンクのコピー

WMCO は現在 Kubernetes 1.31 を使用しています。

2.2.1.2. バグ修正
リンクのコピー
  • 以前は、WMCO をデフォルトの openshift-windows-machine-config-operator namespace にインストールし、WMCO を削除した場合、その後 WMCO をデフォルト以外の namespace にインストールすると失敗していました。これは、Windows Instance Config Daemon (WICD) のロールベースのアクセス制御 (RBAC) が常にデフォルトの namespace に関連付けられていたためです。この修正により、WMCO をデフォルト以外の namespace にインストールするときに、WICD の RBAC が正しく設定されるようになりました。(OCPBUGS-46473)
  • 以前は、OpenShift Container Platform のドキュメントに、installer-provisioned infrastructure および user-provisioned infrastructure インストール方式の WMCO のサポートに関する情報が不足していました。この修正により、installer-provisioned infrastructure 方式が推奨されるインストール方法であり、すべてのプラットフォームで使用できることがドキュメントに記載されるようになりました。user-provisioned infrastructure 方式は、特定のユースケースに限定されます。詳細は、WMCO でサポートされるインストール方式 を参照してください。(OCPBUGS-18898)

2.3. Windows Machine Config Operator の前提条件
リンクのコピー

以下では、Windows Machine Config Operator (WMCO) でサポートされるプラットフォームバージョン、Windows Server バージョン、およびネットワーク設定を詳しく説明します。対象のプラットフォームのみに関連する情報は、vSphere のドキュメントを参照してください。

2.3.1. WMCO でサポートされるインストール方式
リンクのコピー

WMCO は、installer-provisioned infrastructure クラスターへの Windows ノードのインストールを完全にサポートしています。これは、OpenShift Container Platform の推奨されるインストール方法です。

user-provisioned infrastructure (UPI) クラスターの場合、WMCO は、install-config.yaml ファイル (ベアメタルまたはプロバイダー非依存) で設定された platform: none フィールドを使用してインストールされた UPI クラスターへの Windows ノードのインストールのみをサポートし、BYOH (Bring Your Own Host) ユースケースでのみサポートします。他のプラットフォームで UPI はサポートされていません。

2.3.2. WMCO 10.18.0 でサポートされるプラットフォームと Windows Server バージョン
リンクのコピー

次の表は、WMCO 10.18.0 でサポートされる Windows Server のバージョン をプラットフォームに基づき示しています。リストにない Windows Server バージョンはサポート対象外で、使用しようとするとエラーが発生します。これらのエラーを防ぐには、プラットフォームに適したバージョンのみを使用してください。

Expand
プラットフォームサポート対象の Windows Server バージョン

Amazon Web Services (AWS)

  • Windows Server 2022、OS Build 20348.681 以降 [1]
  • Windows Server 2019、バージョン 1809

Microsoft Azure

  • Windows Server 2022、OS ビルド 20348.681 以降
  • Windows Server 2019、バージョン 1809

VMware vSphere

Windows Server 2022、OS ビルド 20348.681 以降

Google Cloud

Windows Server 2022、OS ビルド 20348.681 以降

Nutanix

Windows Server 2022、OS ビルド 20348.681 以降

ベアメタルまたはプロバイダーの指定なし

  • Windows Server 2022、OS ビルド 20348.681 以降
  • Windows Server 2019、バージョン 1809
  1. 非接続クラスターの場合、Windows AMI に EC2LaunchV2 エージェントバージョン 2.0.1643 以降がインストールされている必要があります。詳細は、AWS ドキュメントの Install the latest version of EC2Launch v2 を参照してください。

2.3.3. サポート対象のネットワーク
リンクのコピー

サポート対象のネットワーク設定は、OVN-Kubernetes を使用したハイブリッドネットワークのみです。この機能の詳細は、以下の追加リソースを参照してください。以下の表は、プラットフォームで使用するネットワーク設定の種類と Windows Server バージョンの概要を示しています。クラスターのインストール時にネットワーク設定を指定する必要があります。

注記
  • WMCO は、ハイブリッドネットワークまたは OpenShift SDN を使用しない OVN-Kubernetes をサポートしません。
  • デュアル NIC は、WMCO が管理する Windows インスタンスではサポートされていません。
Expand
表2.1 プラットフォームネットワーキングサポート
プラットフォームサポート対象のネットワーク

Amazon Web Services (AWS)

OVN-Kubernetes を使用したハイブリッドネットワーク

Microsoft Azure

OVN-Kubernetes を使用したハイブリッドネットワーク

VMware vSphere

カスタム VXLAN ポートを備えた OVN-Kubernetes でのハイブリッドネットワーク

Google Cloud

OVN-Kubernetes を使用したハイブリッドネットワーク

Nutanix

OVN-Kubernetes を使用したハイブリッドネットワーク

ベアメタルまたはプロバイダーの指定なし

OVN-Kubernetes を使用したハイブリッドネットワーク

Expand
表2.2 ハイブリッド OVN-Kubernetes Windows Server のサポート
OVN-Kubernetes を使用したハイブリッドネットワークサポート対象の Windows Server バージョン

デフォルトの VXLAN ポート

  • Windows Server 2022、OS ビルド 20348.681 以降
  • Windows Server 2019、バージョン 1809

カスタム VXLAN ポート

Windows Server 2022、OS ビルド 20348.681 以降

2.4. Windows Machine Config Operator の既知の制限
リンクのコピー

WMCO によって管理される Windows ノード (Windows ノード) を使用する場合は、次の制限に注意してください。

  • 以下の OpenShift Container Platform 機能は、Windows ノードではサポートされていません。

    • イメージビルド
    • OpenShift Pipelines
    • OpenShift Service Mesh
    • ユーザー定義プロジェクトの OpenShift モニタリング
    • OpenShift Serverless
    • Vertical Pod Autoscaling
    • Hosted Control Plane

  • 次の Red Hat 機能は、Windows ノードではサポートされていません。

  • デュアル NIC は、WMCO が管理する Windows インスタンスではサポートされていません。
  • Windows ノードは、デプロイ設定を使用して作成されたワークロードをサポートしていません。デプロイまたはその他の方法を使用して、ワークロードをデプロイできます。
  • Red Hat OpenShift による Windows コンテナーのサポートでは、トランクポートを介したクラスターへの Windows ノードの追加はサポートされていません。Windows ノードを追加するためにサポートされている唯一のネットワーク設定は、VLAN のトラフィックを伝送するアクセスポート経由です。
  • Red Hat OpenShift support for Windows Containers では、英語 (米国) 以外の Windows オペレーティングシステム言語はサポートされていません。
  • Windows オペレーティングシステム内の制限により、クラス E の clusterNetwork CIDR アドレス (240.0.0.0 など) は Windows ノードと互換性がありません。

  • Kubernetes は、次の ノード機能の制限 を特定しました。

    • Windows コンテナーでは Huge Page はサポートされていません。
    • 特権コンテナーは、Windows コンテナーではサポートされていません。
  • Kubernetes は、いくつかの API 互換性の問題 を特定しました。

第3章 サポートの利用
リンクのコピー

Windows Container Support for Red Hat OpenShift は、オプションでインストールできるコンポーネントとして提供されます。Windows Container Support for Red Hat OpenShift は、OpenShift Container Platform サブスクリプションに含まれていません。追加の Red Hat サブスクリプションが必要で、対象範囲 および サービスレベルアグリーメント に準じてサポートされます。

Windows Container Support for Red Hat OpenShift のサポートを受けるには、このサブスクリプションが別途必要です。この追加の Red Hat サブスクリプションがない場合、実稼働クラスターへの Windows コンテナーワークロードのデプロイはサポートされません。Red Hat カスタマーポータル からサポートをリクエストできます。

詳細は、Red Hat OpenShift support for Windows Containers の Red Hat OpenShift Container Platform ライフサイクルポリシーのドキュメントを参照してください。

この追加の Red Hat サブスクリプションがない場合は Community Windows Machine Config Operator を使用できますが、このディストリビューションに正式なサポートはありません。

第4章 Windows コンテナーワークロードについて
リンクのコピー

Red Hat OpenShift support for Windows Containers は、OpenShift Container Platform で Microsoft Windows Server コンテナーを実行するための組み込みサポートを提供します。Linux と Windows ワークロードの組み合わせを使用して異種環境を管理する場合、OpenShift Container Platform では、Windows Server コンテナーで実行されている Windows ワークロードをデプロイできますが、Red Hat Enterprise Linux CoreOS (RHCOS) または Red Hat Enterprise Linux (RHEL) でホストされる従来の Linux ワークロードも提供できます。

注記

Windows ノードを持つクラスターのマルチテナンシーはサポートされません。複数のワークロードが共有インフラストラクチャーおよびリソースで動作する場合、クラスターは マルチテナント とみなされます。インフラストラクチャーで実行されている 1 つ以上のワークロードを信頼できない場合、マルチテナント環境は 悪意がある と見なされます。

マルチテナントの悪意のあるクラスターは、すべての Kubernetes 環境にセキュリティー上の懸念をもたらします。Pod セキュリティーポリシー、またはノードのより詳細なロールベースアクセス制御 (RBAC) などの追加のセキュリティー機能により、環境の悪用がより困難になります。ただし、悪意のあるマルチテナントワークロードの実行を選択する場合、ハイパーバイザーは使用する必要のある唯一のセキュリティーオプションになります。Kubernetes のセキュリティードメインは、個別のノードではなく、クラスター全体に対応します。これらのタイプの悪意のあるマルチテナントワークロードには、物理的に分離されたクラスターを使用する必要があります。

Windows Server コンテナーは共有カーネルを使用してリソース分離を行いますが、悪意のあるマルチテナンシーのシナリオで使用することは意図されていません。

4.1. Windows ワークロード管理
リンクのコピー

クラスターで Windows ワークロードを実行するには、まず Windows Machine Config Operator (WMCO) をインストールする必要があります。WMCO は Linux ベースのコントロールプレーンおよびコンピュートノードで実行される Linux ベースの Operator です。WMCO は、クラスター上で Windows ワークロードをデプロイし、管理するプロセスをオーケストレーションします。

図4.1 WMCO の設計

WMCO ワークフロー

Windows ワークロードをデプロイする前に、Windows コンピュートノードを作成し、これをクラスターに参加させる必要があります。Windows ノードは、クラスター内の Windows ワークロードをホストし、他の Linux ベースのコンピュートノードと共に実行できます。Windows Server コンピュートマシンをホストする Windows マシンセットを作成して、Windows コンピュートノードを作成することができます。Windows OS イメージを指定するコンピュートマシンセットには、Windows 固有のラベルを適用する必要があります。

WMCO は Windows ラベルの付いたマシンを監視します。Windows コンピュートマシンセットを検出し、そのそれぞれのマシンがプロビジョニングされると、WMCO は基礎となる Windows 仮想マシン (VM) を設定し、それがコンピュートノードとしてクラスターに参加できるようにします。

図4.2 Windows および Linux ワークロードの組み合わせ

Windows および Linux ワークロードの組み合わせ

WMCO は、Windows インスタンスとの対話に使用されるプライベートキーが含まれる namespace に事前に決定されたシークレットがあることを想定します。WMCO は起動時にこのシークレットの有無を確認し、作成した Windows MachineSet オブジェクトで参照する必要のあるユーザーデータのシークレットを作成します。次に WMCO は、プライベートキーに対応するパブリックキーでユーザーデータのシークレットを設定します。このデータが適用されると、クラスターは SSH 接続を使用して Windows 仮想マシンに接続できます。

クラスターが Windows 仮想マシンとの接続を確立した後に、Linux ベースのノードの場合と同様の手法を使用して Windows ノードを管理できます。

注記

OpenShift Container Platform Web コンソールは、Linux ノードで利用可能な機能と同じモニタリング機能のほとんどを Windows ノードに提供します。ただし、現時点で Windows ノードで実行されている Pod のワークロードグラフを監視する機能は利用できません。

Windows ワークロードの Windows ノードへのスケジュールは、テイント、toleration、ノードセレクターなどの一般的な Pod スケジュールの手法を使用して実行できますが、RuntimeClass オブジェクトを使用して Windows ワークロードを Linux ワークロードおよび他の Windows 版のワークロードから区別できます。

4.2. Windows ノードサービス
リンクのコピー

以下の Windows 固有のサービスは、各 Windows ノードにインストールされます。

Expand
サービス説明

kubelet

Windows ノードを登録し、そのステータスを管理します。

Container Network Interface (CNI) プラグイン

Windows ノードの ネットワーク を公開します。

Windows インスタンス設定デーモン (WICD)

Windows インスタンスで実行されているすべてのサービスの状態を維持して、インスタンスがワーカーノードとして機能するようにします。

Windows Exporter

Windows ノードから Prometheus メトリクスをエクスポートします。

Kubernetes Cloud Controller Manager (CCM)

基礎となる Azure クラウドプラットフォームと対話します。

hybrid-overlay

OpenShift Container Platform Host Network Service (HNS) を作成します。

kube-proxy

外部との通信を許可するノードでネットワークルールを維持します。

containerd コンテナーランタイム

コンテナーのライフサイクル全体を管理します。

CSI プロキシー

CSI ドライバーがノード上でストレージ操作を実行できるようにします。これにより、コンテナー化された CSI ドライバーを Windows ノード上で実行できます。

第5章 Windows コンテナーワークロードの有効化
リンクのコピー

Windows ワークロードをクラスターに追加する前に、OpenShift Container Platform OperatorHub で利用可能な Windows Machine Config Operator (WMCO) をインストールする必要があります。WMCO は、クラスター上で Windows ワークロードをデプロイし、管理するプロセスをオーケストレーションします。

注記

デュアル NIC は、WMCO が管理する Windows インスタンスではサポートされていません。

5.1. 前提条件
リンクのコピー

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

  • 次のいずれかのインフラストラクチャーを使用してクラスターをインストールした。

    • 任意の installer-provisioned infrastructure
    • install-config.yaml ファイルに platform: none フィールドが設定された user-provisioned infrastructure
  • クラスターに OVN-Kubernetes を使用してハイブリッドネットワークを設定している。詳細は、ハイブリッドネットワークの設定 を参照してください。
  • OpenShift Container Platform クラスター (バージョン 4.6.8 以降) を実行している。
注記

WMCO によってデプロイされる Windows インスタンスは、containerd コンテナーランタイムで設定されます。WMCO がランタイムをインストールして管理するため、ノードに containerd を手動でインストールしないことを推奨します。

Windows Machine Config Operator の詳細な前提条件は、「Windows Machine Config Operator の前提条件」を参照してください。

5.2. Windows Machine Config Operator のインストール
リンクのコピー

Web コンソールまたは OpenShift CLI (oc) のいずれかを使用して Windows Machine Config Operator をインストールできます。

注記

Windows オペレーティングシステム内の制限により、クラス E の clusterNetwork CIDR アドレス (240.0.0.0 など) は Windows ノードと互換性がありません。

5.2.1. Web コンソールを使用した Windows Machine Config Operator のインストール
リンクのコピー

OpenShift Container Platform Web コンソールを使用して Windows Machine Config Operator (WMCO) をインストールすることができます。

注記

デュアル NIC は、WMCO が管理する Windows インスタンスではサポートされていません。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブから、Operators → OperatorHub ページに移動します。
  2. Filter by keyword ボックスを使用して、カタログで Windows Machine Config Operator を検索します。Windows Machine Config Operator タイルをクリックします。
  3. Operator に関する情報を確認してから、Install をクリックします。

  4. Install Operator ページで以下を行います。

    1. Update Channel として stable チャネルを選択します。stable チャネルを使用すると、WMCO の最新の安定したリリースをインストールできます。
    2. WMCO は単一の namespace でのみ利用できるようにする必要があるため、インストールモード は事前に設定されます。
    3. WMCO の Installed Namespace を選択します。デフォルトの Operator の推奨される namespace は openshift-windows-machine-config-operator です。
    4. Enable Operator recommended cluster monitoring on the Namespace チェックボックスをクリックし、WMCO においてクラスターのモニタリングを有効にします。

    5. Approval Strategy を選択します。

      • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
      • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。

  5. Install をクリックします。WMCO が Installed Operators ページにリスト表示されます。

    注記

    WMCO は、openshift-windows-machine-config-operator などのように、定義した namespace に自動的にインストールされます。

  6. Status に Succeeded が表示されていることを検証し、WMCO のインストールが正常に行われたことを確認します。

5.2.2. CLI を使用した Windows Machine Config Operator のインストール
リンクのコピー

OpenShift CLI (oc) を使用して、Windows Machine Config Operator (WMCO) をインストールできます。

注記

デュアル NIC は、WMCO が管理する Windows インスタンスではサポートされていません。

手順

  1. WMCO の namespace を作成します。

    1. WMCO の Namespace オブジェクト YAML ファイルを作成します。例: wmco-namespace.yaml 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-windows-machine-config-operator
      1 
      
  labels:
    openshift.io/cluster-monitoring: "true"
      2
      1
      WMCO を openshift-windows-machine-config-operator namespace にデプロイすることが推奨されます。
      2
      このラベルは、WMCO のクラスターモニタリングを有効にするために必要です。

    2. namespace を作成します。 

      $ oc create -f <file-name>.yaml

      以下に例を示します。 

      $ oc create -f wmco-namespace.yaml

  2. WMCO の Operator グループを作成します。

    1. OperatorGroup オブジェクト YAML ファイルを作成します。例: wmco-og.yaml 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: windows-machine-config-operator
  namespace: openshift-windows-machine-config-operator
spec:
  targetNamespaces:
  - openshift-windows-machine-config-operator

    2. Operator グループを作成します。 

      $ oc create -f <file-name>.yaml

      以下に例を示します。 

      $ oc create -f wmco-og.yaml

  3. namespace を WMCO にサブスクライブします。

    1. Subscription オブジェクト YAML ファイルを作成します。例: wmco-sub.yaml 

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: windows-machine-config-operator
  namespace: openshift-windows-machine-config-operator
spec:
  channel: "stable"
      1 
      
  installPlanApproval: "Automatic"
      2 
      
  name: "windows-machine-config-operator"
  source: "redhat-operators"
      3 
      
  sourceNamespace: "openshift-marketplace"
      4
      1
      stable をチャネルとして指定します。
      2
      承認ストラテジーを設定します。Automatic または Manual を設定できます。
      3
      windows-machine-config-operator パッケージマニフェストが含まれる、redhat-operators カタログソースを指定します。OpenShift Container Platform が、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator LifeCycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。
      4
      カタログソースの namespace。デフォルトの OperatorHub カタログソースには openshift-marketplace を使用します。

    2. サブスクリプションを作成します。 

      $ oc create -f <file-name>.yaml

      以下に例を示します。 

      $ oc create -f wmco-sub.yaml

      WMCO が openshift-windows-machine-config-operator にインストールされるようになりました。

  4. WMCO インストールを確認します。 

    $ oc get csv -n openshift-windows-machine-config-operator

    出力例

    NAME                                    DISPLAY                           VERSION   REPLACES   PHASE
windows-machine-config-operator.2.0.0   Windows Machine Config Operator   2.0.0                Succeeded

5.3. Windows Machine Config Operator のシークレットの設定
リンクのコピー

Windows Machine Config Operator (WMCO) を実行するには、プライベートキーを含む WMCO namespace でシークレットを作成する必要があります。これは、WMCO が Windows 仮想マシン (VM) と通信できるようにするために必要です。

前提条件

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。

  • ECDSA などの強力なアルゴリズムを使用して、秘密鍵を含む PEM エンコードファイルを作成している。

    Red Hat Enterprise Linux (RHEL) システムでキーペアを作成した場合、Windows システムで公開鍵を使用する前に、公開鍵が ASCII エンコードを使用して保存されていることを確認してください。たとえば、次の PowerShell コマンドは、公開鍵を ASCII 文字セットにエンコードしてコピーします。 

    C:\> echo "ssh-rsa <ssh_pub_key>" | Out-File <ssh_key_path> -Encoding ascii

    ここでは、以下のようになります。

    <ssh_pub_key>
    クラスターにアクセスするために使用する SSH 公開鍵を指定します。
    <ssh_key_path>
    SSH 公開鍵へのパスを指定します。

手順

  • Windows 仮想マシンへのアクセスに必要なシークレットを定義します。 

    $ oc create secret generic cloud-private-key --from-file=private-key.pem=${HOME}/.ssh/<key> \
    -n openshift-windows-machine-config-operator
    1
1
openshift-windows-machine-config-operator などの、WMCO namespace のプライベートキーを作成する必要があります。

クラスターのインストール時に使用されるものとは異なるプライベートキーを使用することが推奨されます。

5.4. Windows Machine Config Operator に debug レベルのロギングを設定する
リンクのコピー

デフォルトでは、Windows Machine Config Operator (WMCO) は、info ログレベルを使用するように設定されています。WMCO の Subscription オブジェクトを編集することで、ログレベルを debug に変更できます。

手順

  1. 次のコマンドを使用して、windows-machine-config-operator namespace の windows-machine-config-operator のサブスクリプションを編集します。 

    $ oc edit subscription windows-machine-config-operator -n openshift-windows-machine-config-operator

  2. .spec.config.env スタンザに次のパラメーターを追加します。 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
# ...
  name: windows-machine-config-operator
  namespace: openshift-windows-machine-config-operator
# ...
spec:
# ...
  config:
    env:
    - name: ARGS
    1 
    
      value: --debugLogging
    2
    1
    Pod 内のすべてのコンテナーに存在する必要がある環境変数のリストを定義します。
    2
    ログメッセージの詳細レベルとして debug を指定します。

追加した name および value パラメーターを削除することで、デフォルトの info ログレベルに戻すことができます。

5.5. プロキシー対応クラスターで Windows コンテナーを使用する
リンクのコピー

Windows Machine Config Operator (WMCO) は、クラスターの内部ネットワーク外で外部要求を行うときに、クラスター全体の Egress プロキシー設定を消費および使用できます。

これにより、プロキシー対応のクラスターに Windows ノードを追加してワークロードを実行できるようになり、Windows ノードはプロキシーサーバーの背後で保護されたレジストリーからイメージをプルしたり、クラスター外のサービスやカスタム公開鍵インフラストラクチャーを使用するサービスにリクエストを送信したりできるようになります。

注記

クラスター全体のプロキシーは、システムコンポーネントにのみ影響し、ユーザーのワークロードには影響しません。

プロキシー対応のクラスターでは、WMCO はクラスターに設定されている NO_PROXY、HTTP_PROXY、および HTTPS_PROXY の値を認識しています。WMCO は、プロキシー環境変数が変更されたかどうかを定期的にチェックします。不一致がある場合、WMCO は Windows インスタンス上のプロキシー環境変数を調整して更新します。

プロキシー対応クラスターの Windows ノードで作成された Windows ワークロードは、Linux ノードと同様に、デフォルトではノードからプロキシー設定を継承しません。また、デフォルトでは、PowerShell セッションはプロキシー対応クラスター内の Windows ノード上のプロキシー設定を継承しません。

5.6. ミラーレジストリーで Windows コンテナーを使用する
リンクのコピー

Windows Machine Config Operator (WMCO) は、ImageDigestMirrorSet (IDMS) または ImageTagMirrorSet (ITMS) オブジェクトを使用してクラスターを設定し、ミラーレジストリーからイメージをプルすることにより、パブリックレジストリーではなくレジストリーミラーからイメージをプルできます。

ミラーレジストリーには次の利点があります。

  • パブリックレジストリーの停止を回避
  • ノードと Pod の作成を高速化
  • 組織のファイアウォールの背後からイメージを取得します

ミラーレジストリーは、切断されたネットワークまたはエアギャップネットワーク内の OpenShift Container Platform クラスターでも使用できます。切断されたネットワーク は、直接インターネットに接続できない制限されたネットワークです。クラスターはインターネットにアクセスできないため、外部のコンテナーイメージを参照することはできません。

ミラーレジストリーを使用するには、次の一般的な手順が必要です。

  • Red Hat Quay などのツールを使用して、ミラーレジストリーを作成します。
  • コンテナーイメージレジストリー認証情報ファイルを作成します。
  • オンラインイメージリポジトリーからミラーレジストリーにイメージをコピーします。

これらの手順の詳細は、「切断されたインストールのミラーリングについて」を参照してください。

ミラーレジストリーを作成してイメージをミラーリングした後、ImageDigestMirrorSet (IDMS) または ImageTagMirrorSet (ITMS) オブジェクトを使用して、各 Pod 仕様を更新せずにミラーレジストリーからイメージをプルするようにクラスターを設定できます。IDMS および ITMS オブジェクトは、ソースイメージレジストリーのリポジトリーからイメージをプルする要求をリダイレクトし、代わりにミラーリポジトリーによって解決されるようにします。

IDMS または ITMS オブジェクトに変更が加えられた場合、WMCO は Windows ノード上の適切な hosts.toml ファイルを新しい情報で自動的に更新します。ミラー設定が変更になると、WMCO は各 Windows ノードを順番に更新することに注意してください。そのため、これらの更新に必要な時間は、クラスター内の Windows ノードの数に応じて増加します。

WMCO によって設定される Windows ノードは、containerd コンテナーランタイムに依存しています。そのため、WMCO は containerd の設定ファイルをレジストリーの設定で最新の状態に維持します。新しいノードの場合、これらのファイルは作成時にインスタンスにコピーされます。既存のノードの場合、レジストリーコントローラーが、ミラーレジストリーをアクティブ化した後、SSH を使用して各ノードにアクセスし、生成された設定ファイルをコピーして、既存のファイルを置き換えます。

マシンセットまたは Bring-Your-Own-Host (BYOH) Windows ノードでミラーレジストリーを使用できます。

IDMS または ITMS オブジェクトを使用して Windows ノード上のコンテナーイメージをミラーリングする場合は、次の動作が Linux ノードとは異なる点に注意してください。

  • Windows ノードでのミラーリングは、レジストリーレベルで機能します。Linux ノードのように、イメージレベルでは機能しません。そのため、IDMS または ITMS オブジェクトを使用してミラーリングされる Windows イメージには、特定の命名要件があります。

    namespace の最後の部分とミラーイメージのイメージ名は、ミラーリングされるイメージと一致する必要があります。たとえば、mcr.microsoft.com/oss/kubernetes/pause:3.9 イメージをミラーリングする場合、ミラーは $mirrorRegistry/<organization>/oss/kubernetes/pause:3.9 形式である必要があります。$org は、任意の組織名または namespace にすることも、完全に除外することもできます。有効な値は、$mirrorRegistry/oss/kubernetes/pause:3.9、$mirrorRegistry/custom/oss/kubernetes/pause:3.9、$mirrorRegistry/x/y/z/oss/kubernetes/pause:3.9 などです。

  • Windows ノードは、ITMS オブジェクトを取得し、それを使用してレジストリー全体のミラーを設定します。次の例では、quay.io/remote-org/image を quay.io/my-org/image にミラーリングするように設定します。その結果、Windows ノードはそのミラーを quay.io/remote-org のすべてのイメージに使用するようになります。そのため、quay.io/remote-org/image:tag は期待どおり quay.io/my-org/image:tag イメージを使用しますが、quay.io/remote-org/different-image:tag を使用する別のコンテナーも quay.io/remote-org/different-image:tag ミラーを使用しようとします。これを考慮しないと、意図しない動作が発生する可能性があります。

    このため、コンテナーイメージを指定するには、ITMS オブジェクトではなく、IDMS オブジェクトによるダイジェストを使用してください。ダイジェストを使用すると、コンテナーが指定するイメージとプルされるイメージのダイジェストが同じになるため、間違ったコンテナーイメージが使用されるのを防止できます。

5.6.1. イメージレジストリーリポジトリーのミラーリングについて
リンクのコピー

コンテナーレジストリーリポジトリーのミラーリングを設定すると、次のタスクを実行できます。

  • ソースイメージのレジストリーのリポジトリーからイメージをプルする要求をリダイレクトするように OpenShift Container Platform クラスターを設定し、これをミラーリングされたイメージレジストリーのリポジトリーで解決できるようにします。
  • 各ターゲットリポジトリーに対して複数のミラーリングされたリポジトリーを特定し、1 つのミラーがダウンした場合に別のミラーを使用できるようにします。

OpenShift Container Platform のリポジトリーミラーリングには、以下の属性が含まれます。

  • イメージプルには、レジストリーのダウンタイムに対する回復性があります。
  • 非接続環境のクラスターは、quay.io などの重要な場所からイメージをプルし、企業のファイアウォールの背後にあるレジストリーに要求されたイメージを提供させることができる。
  • イメージのプル要求時にレジストリーへの接続が特定の順序で試行され、通常は永続レジストリーが最後に試行される。
  • 入力したミラー情報は、OpenShift Container Platform クラスター内のすべての Windows ノード上の適切な hosts.toml containerd 設定ファイルに追加されます。
  • ノードがソースリポジトリーからイメージの要求を行うと、要求されたコンテンツを見つけるまで、ミラーリングされた各リポジトリーに対する接続を順番に試行する。すべてのミラーで障害が発生した場合、クラスターはソースリポジトリーに対して試行する。成功すると、イメージはノードにプルされる。

リポジトリーミラーリングのセットアップは次の方法で実行できます。

  • OpenShift Container Platform のインストール時:

    OpenShift Container Platform に必要なコンテナーイメージをプルし、それらのイメージを会社のファイアウォールの背後に配置することで、非接続環境にあるデータセンターに OpenShift Container Platform をインストールできます。

  • OpenShift Container Platform の新規インストール後:

    OpenShift Container Platform のインストール中にミラーリングを設定しなかった場合は、以下のカスタムリソース (CR) オブジェクトのいずれかを使用して、インストール後に設定できます。

    • ImageDigestMirrorSet (IDMS)。このオブジェクトを使用すると、ダイジェスト仕様を使用して、ミラーリングされたレジストリーからイメージを取得できます。IDMS CR を使用すると、イメージのプルが失敗した場合に、ソースレジストリーからのプルの継続的な試行を許可または停止するフォールバックポリシーを設定できます。
    • ImageTagMirrorSet (ITMS)。このオブジェクトを使用すると、イメージタグを使用して、ミラーリングされたレジストリーからイメージをプルできます。ITMS CR を使用すると、イメージのプルが失敗した場合に、ソースレジストリーからのプルの継続的な試行を許可または停止するフォールバックポリシーを設定できます。

これらのカスタムリソースオブジェクトはそれぞれ、次の情報を識別します。

  • ミラーリングするコンテナーイメージリポジトリーのソース
  • ソースリポジトリーから要求されたコンテンツを提供する各ミラーリポジトリーの個別のエントリー。

次のアクションと、それがノードの drain 動作にどのように影響するかに注意してください。

  • IDMS または ICSP CR オブジェクトを作成すると、MCO はノードの drain またはリブートを実行しません。
  • ITMS CR オブジェクトを作成すると、MCO はノードの drain とリブートを実行します。
  • ITMS、IDMS、または ICSP CR オブジェクトを削除すると、MCO はノードの drain とリブートを実行します。

  • ITMS、IDMS、または ICSP CR オブジェクトを変更すると、MCO はノードの drain とリブートを実行します。

    重要

    • MCO が以下の変更のいずれかを検出すると、ノードの drain (Pod の退避) の実行または再起動を行わずに更新を適用します。

      • マシン設定の 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 オブジェクトの編集など) を検出すると、対応するノードの drain (Pod の退避) を実行し、変更を適用して、ノードをスケジューリング対象に戻します。次の変更ではノードの drain (Pod の退避) の実行は発生しません。

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

Windows Machine Config Operator (WMCO) は、IDMS および ITMS リソースへの変更を監視し、それらの変更を含む hosts.toml containerd 設定ファイルのセットをソースレジストリーごとに 1 つずつ生成します。次に、WMCO は既存の Windows ノードを更新して、新しいレジストリー設定を使用します。

注記

ミラー化されたレジストリーを使用して Windows ノードを追加する前に、IDMS および ITMS オブジェクトを作成する必要があります。

5.6.2. イメージレジストリーのリポジトリーミラーリングの設定
リンクのコピー

インストール後のミラー設定カスタムリソース (CR) を作成して、ソースイメージレジストリーからミラーリングされたイメージレジストリーにイメージプル要求をリダイレクトできます。

重要

ImageDigestMirrorSet および ImageTagMirrorSet オブジェクトを通じてミラーリングされた Windows イメージには、特定の命名要件があります。これは「ミラーレジストリーで Windows コンテナーを使用する」で説明されています。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. ミラーリングされたリポジトリーを設定します。以下のいずれかを実行します。

    • Red Hat Quay でのレポジトリーのミラーリング で説明されているように、Red Hat Quay でミラーリングされたリポジトリーを設定します。Red Hat Quay を使用すると、あるリポジトリーから別のリポジトリーにイメージをコピーでき、これらのリポジトリーを一定期間繰り返し自動的に同期することもできます。

    • skopeo などのツールを使用して、ソースリポジトリーからミラーリングされたリポジトリーにイメージを手動でコピーします。

      たとえば、Red Hat Enterprise Linux (RHEL 7 または RHEL 8) システムに skopeo RPM パッケージをインストールした後、以下の例に示すように skopeo コマンドを使用します。 

      $ skopeo copy --all \
docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \
docker://example.io/example/ubi-minimal

      この例では、example.io いう名前のコンテナーイメージレジストリーと example という名前のイメージリポジトリーがあり、そこに registry.access.redhat.com から ubi9/ubi-minimal イメージをコピーします。ミラーリングされたレジストリーを作成した後、ソースリポジトリーに対する要求をミラーリングされたリポジトリーにリダイレクトするように OpenShift Container Platform クラスターを構成できます。

    重要

    mcr.microsoft.com/oss/kubernetes/pause:3.9 イメージをミラーリングする必要があります。たとえば、次の skopeo コマンドを使用してイメージをミラーリングできます。 

    $ skopeo copy \
docker://mcr.microsoft.com/oss/kubernetes/pause:3.9\
docker://example.io/oss/kubernetes/pause:3.9
  2. OpenShift Container Platform クラスターにログインします。

  3. 必要に応じて ImageDigestMirrorSet または ImageTagMirrorSet CR を作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。 

    apiVersion: config.openshift.io/v1
    1 
    
kind: ImageDigestMirrorSet
    2 
    
metadata:
  name: ubi9repo
spec:
  imageDigestMirrors:
    3 
    
  - mirrors:
    - example.io/example/ubi-minimal
    4 
    
    - example.com/example2/ubi-minimal
    5 
    
    source: registry.access.redhat.com/ubi9/ubi-minimal
    6 
    
    mirrorSourcePolicy: AllowContactingSource
    7 
    
  - mirrors:
    - mirror.example.com
    source: registry.redhat.io
    mirrorSourcePolicy: NeverContactSource
  - mirrors:
    - docker.io
    source: docker-mirror.internal
    mirrorSourcePolicy: AllowContactingSource
    1
    この CR で使用する API を示します。これは config.openshift.io/v1 である必要があります。
    2
    プルタイプに応じてオブジェクトの kind を示します。
    • ImageDigestMirrorSet: ダイジェスト参照イメージをプルします。
    • ImageTagMirrorSet: タグ参照イメージをプルします。
    3
    次のいずれかのイメージプルメソッドのタイプを示します。
    • imageDigestMirrors: ImageDigestMirrorSet CR に使用します。
    • imageTagMirrors: ImageTagMirrorSet CR に使用します。
    4
    ミラーリングされたイメージのレジストリーとリポジトリーの名前を示します。
    5
    オプション: 各ターゲットリポジトリーのセカンダリーミラーリポジトリーを示します。1 つのミラーがダウンした場合、ターゲットリポジトリーは別のミラーを使用できます。
    6
    イメージプル仕様で参照されるリポジトリーである、レジストリーおよびリポジトリーソースを示します。
    7
    オプション: イメージのプルが失敗した場合のフォールバックポリシーを示します。
    • AllowContactingSource: ソースリポジトリーからのイメージのプルの継続的な試行を許可します。これはデフォルトになります。
    • NeverContactSource: ソースリポジトリーからのイメージのプルの継続的な試行を防ぎます。

  4. 新規オブジェクトを作成します。 

    $ oc create -f registryrepomirror.yaml

  5. ミラーリングされた設定が適用されていることを確認するには、ノードのいずれかで以下を実行します。

    1. ノードの一覧を表示します。 

      $ oc get node

      出力例

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.31.3
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.31.3
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.31.3
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.31.3
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.31.3
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.31.3

    2. デバッグプロセスを開始し、ノードにアクセスします。 

      $ oc debug node/ip-10-0-147-35.ec2.internal

      出力例

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`

    3. ルートディレクトリーを /host に変更します。 

      sh-4.2# chroot /host

    4. WMCO が各 Windows インスタンスの各レジストリーに対して hosts.toml ファイルを生成したことを確認します。前述の IDMS オブジェクトの例の場合は、次のファイル構造に 3 つのファイルが存在するはずです。 

      $ tree $config_path

      出力例

      C:/k/containerd/registries/
|── registry.access.redhat.com
|   └── hosts.toml
|── mirror.example.com
|   └── hosts.toml
└── docker.io
    └── hosts.toml:

      次の出力は、前の例の IDMS オブジェクトが適用された hosts.toml containerd 設定ファイルを表しています。

      host.toml ファイルの例

      $ cat "$config_path"/registry.access.redhat.com/host.toml
server = "https://registry.access.redhat.com" # default fallback server since "AllowContactingSource" mirrorSourcePolicy is set

[host."https://example.io/example/ubi-minimal"]
 capabilities = ["pull"]

[host."https://example.com/example2/ubi-minimal"] # secondary mirror
 capabilities = ["pull"]


$ cat "$config_path"/registry.redhat.io/host.toml
# "server" omitted since "NeverContactSource" mirrorSourcePolicy is set

[host."https://mirror.example.com"]
 capabilities = ["pull"]


$ cat "$config_path"/docker.io/host.toml
server = "https://docker.io"

[host."https://docker-mirror.internal"]
 capabilities = ["pull", "resolve"] # resolve tags

    5. ソースからノードにイメージをプルし、ミラーによって解決されるかどうかを確認します。 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...

リポジトリーのミラーリングのトラブルシューティング

リポジトリーのミラーリング手順が説明どおりに機能しない場合は、リポジトリーミラーリングの動作方法に関する以下の情報を使用して、問題のトラブルシューティングを行うことができます。

  • 最初に機能するミラーは、プルされるイメージを指定するために使用されます。
  • メインレジストリーは、他のミラーが機能していない場合にのみ使用されます。
  • システムコンテキストによって、Insecure フラグがフォールバックとして使用されます。

5.7. ノードをグレースフルに再起動する
リンクのコピー

Windows Machine Config Operator (WMCO) は、可能な限りノードの再起動を最小限に抑えます。しかし、特定の操作および更新を行う際には、変更が正しくセキュアに適用されるように、再起動を実行する必要があります。Windows ノードを安全に再起動するには、グレースフル再起動プロセスを使用します。標準の OpenShift Container Platform ノードのグレースフル再起動を実行する方法は、「ノード」ドキュメントの「ノードのグレースフル再起動」を参照してください。

ノードを再起動する前に、ノードでのデータ損失を回避するために、etcd データをバックアップすることを推奨します。

注記

シングルノード OpenShift クラスターの場合、クラスターを管理するために kubeconfig ファイルに証明書を含めるのではなく、ユーザーが oc login コマンドを実行する必要があります。そのため、ノードをスケジューリング対象から除外して drain (Pod の退避) を実行した後、oc adm コマンドが使用できなくなる可能性があります。これは、スケジューリング対象から除外する操作が原因で、openshift-oauth-apiserver Pod が実行されなくなるためです。以下の手順で示したように、SSH を使用してノードにアクセスできます。

シングルノード OpenShift クラスターでは、スケジューリング対象からの除外時および drain (Pod の退避) の実行時に Pod を再スケジューリングすることはできません。しかし、そうすることで、Pod、特にワークロード Pod が適切に停止し、関連するリソースを解放する時間を得ることができます。

手順

ノードのグレースフル再起動を実行するには、次の手順を実行します。

  1. ノードをスケジューリング対象外としてマークします。 

    $ oc adm cordon <node1>

  2. ノードの drain (Pod の退避) を実行して、実行中のすべての Pod を削除します。 

    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

    カスタムの Pod Disruption Budget (PDB) に関連する Pod を退避できないというエラーが表示される場合があります。

    エラーの例

    error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

    この場合、drain コマンドを再度実行し、disable-eviction フラグを追加し、PDB チェックを省略します。 

    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction

  3. Windows ノードに SSH で接続し、次のコマンドを実行して PowerShell に入ります。 

    C:\> powershell

  4. 次のコマンドを実行してノードを再起動します。 

    C:\>  Restart-Computer -Force

  5. Amazon Web Services (AWS) 上の Windows ノードは、EC2 インスタンスのメタデータルートと Host Network Service (HNS) ネットワークとの不整合が原因で、グレースフル再起動後に READY 状態に戻りません。

    再起動後、AWS 上の任意の Windows ノードに SSH で接続し、シェルプロンプトで次のコマンドを実行してルートを追加します。 

    C:\> route add 169.254.169.254 mask 255.255.255.0 <gateway_ip>

    ここでは、以下のようになります。

    169.254.169.254
    EC2 インスタンスメタデータエンドポイントのアドレスを指定します。
    255.255.255.255
    EC2 インスタンスメタデータエンドポイントのネットワークマスクを指定します。
    <gateway_ip>

    Windows インスタンス内のゲートウェイに対応する IP アドレスを指定します。これは、次のコマンドを実行して見つけることができます。 

    C:\> ipconfig | findstr /C:"Default Gateway"

  6. 再起動が完了したら、以下のコマンドを実行して、ノードをスケジューリング可能な状態にします。 

    $ oc adm uncordon <node1>

  7. ノードの準備ができていることを確認します。 

    $ oc get node <node1>

    出力例

    NAME    STATUS  ROLES    AGE     VERSION
<node1> Ready   worker   6d22h   v1.18.3+b0068a8

第6章 Windows マシンセットの作成
リンクのコピー

6.1. AWS 上での Windows マシンセットの作成
リンクのコピー

Amazon Web Services (AWS) で OpenShift Container Platform クラスターの特定の機能を果たすように MachineSet オブジェクトを作成することができます。たとえば、インフラストラクチャー Windows マシンセットおよび関連マシンを作成して、サポートする Windows ワークロードを新規の Windows マシンに移動できます。

6.1.1. 前提条件
リンクのコピー

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。

  • サポートされている Windows Server をオペレーティングシステムイメージとして使用しています。

    以下に示すコマンドから、使用している Windows Server リリースに対応する aws コマンドを使用して有効な AMI イメージをクエリーします。

    Windows Server 2022 コマンドの例

    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2022*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    Windows Server 2019 コマンドの例

    $ aws ec2 describe-images --region <aws_region_name> --filters "Name=name,Values=Windows_Server-2019*English*Core*Base*" "Name=is-public,Values=true" --query "reverse(sort_by(Images, &CreationDate))[*].{name: Name, id: ImageId}" --output table

    ここでは、以下のようになります。

    <aws_region_name>
    AWS リージョンの名前を指定します。
  • 非接続クラスターの場合、Windows AMI に EC2LaunchV2 エージェントバージョン 2.0.1643 以降がインストールされている必要があります。詳細は、AWS ドキュメントの Install the latest version of EC2Launch v2 を参照してください。

6.1.2. Machine API の概要
リンクのコピー

Machine API は、プライマリーリソースの組み合わせたものであり、アップストリーム Cluster API プロジェクトとカスタム OpenShift Container Platform リソースをベースとしています。

OpenShift Container Platform 4.18 クラスターの場合、Machine API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングに対する管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.18 はパブリックまたはプライベートのクラウドインフラストラクチャーに加え、弾力的かつ動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

Machines
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec 仕様があります。たとえば、コンピュートノードのマシンタイプは、特定のマシンタイプと必要なメタデータを定義する場合があります。
マシンセット

MachineSet リソースは、計算マシンのグループです。コンピューティングマシンセットはコンピューティングマシン用であり、レプリカセットは Pod 用です。より多くのコンピューティングマシンが必要な場合、またはそれらを縮小する必要がある場合は、コンピューティングのニーズを満たすように MachineSet リソースの replicas フィールドを変更します。

警告

コントロールプレーンマシンは、コンピューティングマシンセットでは管理できません。

コントロールプレーンマシンセットは、サポートされているコントロールプレーンマシンに対して、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能を提供します。

詳細は、「コントロールプレーンマシンの管理」を参照してください。

以下のカスタムリソースは、クラスターに機能を追加します。

Machine Autoscaler

MachineAutoscaler リソースは、クラウド内のコンピューティングマシンを自動的にスケーリングします。指定したコンピューティングマシンセット内のノードの最小および最大スケーリング境界を設定でき Machine Autoscaler はそのノード範囲を維持します。

MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscaler および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator オブジェクトによって利用可能にされます。

Cluster Autoscaler

このリソースはアップストリームの Cluster Autoscaler プロジェクトに基づいています。OpenShift Container Platform の実装では、このリソースはコンピュートマシンセット API を拡張することで、Machine API と統合されます。クラスターオートスケーラーを使用して、次の方法でクラスターを管理できます。

  • コア、ノード、メモリー、GPU などのリソースに対してクラスター全体のスケーリング制限を設定
  • クラスターが Pod に優先順位を付け、重要度の低い Pod のために新しいノードがオンラインにならないように、優先順位を設定します。
  • ノードをスケールアップできるがスケールダウンできないようにスケーリングポリシーを設定
マシンのヘルスチェック
MachineHealthCheck リソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易にデプロイメントすることができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。各コンピュートマシンセットのスコープは 1 つのゾーンに限定されるため、インストールプログラムはユーザーに代わって複数のアベイラビリティゾーンにコンピューティングマシンセットを送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

6.1.3. AWS の Windows MachineSet オブジェクトのサンプル YAML
リンクのコピー

このサンプル YAML は、Windows Machine Config Operator (WMCO) が応答する Amazon Web Services (AWS) で実行される Windows MachineSet オブジェクトを定義します。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-windows-worker-<zone>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          ami:
            id: <windows_container_ami>
9 

          apiVersion: awsproviderconfig.openshift.io/v1beta1
          blockDevices:
            - ebs:
                iops: 0
                volumeSize: 120
                volumeType: gp2
          credentialsSecret:
            name: aws-cloud-credentials
          deviceIndex: 0
          iamInstanceProfile:
            id: <infrastructure_id>-worker-profile
10 

          instanceType: m5a.large
          kind: AWSMachineProviderConfig
          placement:
            availabilityZone: <zone>
11 

            region: <region>
12 

          securityGroups:
          - filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-node
13 

          - filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-lb
14 

          subnet:
            filters:
            - name: tag:Name
              values:
              - <infrastructure_id>-subnet-private-<zone>
15 

          tags:
            - name: kubernetes.io/cluster/<infrastructure_id>
16 

              value: owned
          userDataSecret:
            name: windows-user-data
17 

            namespace: openshift-machine-api
1 3 5 10 13 14 15 16
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
インフラストラクチャー ID、ワーカーラベル、およびゾーンを指定します。
7
コンピュートマシンセットを Windows マシンとして設定します。
8
Windows ノードをコンピュートマシンとして設定します。
9
コンテナーランタイムがインストールされている、サポートされている Windows イメージの AMI ID を指定します。
注記

非接続クラスターの場合、Windows AMI に EC2LaunchV2 エージェントバージョン 2.0.1643 以降がインストールされている必要があります。詳細は、AWS ドキュメントの Install the latest version of EC2Launch v2 を参照してください。

11
us-east-1a などの AWS ゾーンを指定します。
12
us-east-1 などの AWS リージョンを指定します。
17
最初の Windows マシンの設定時に WMCO によって作成されます。その後、windows-user-data は、後続のすべてのコンピュートマシンセットで使用できるようになります。

6.1.4. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。
  • 非接続環境では、MachineSet カスタムリソース (CR) で指定されたイメージに OpenSSH サーバー v0.0.1.0 がインストールされている 必要があります。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

  3. 次のコマンドを実行して MachineSet CR を作成します。 

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

6.2. Azure 上での Windows マシンセットの作成
リンクのコピー

Microsoft Azure 上の OpenShift Container Platform クラスターで特定の機能を果たすように Windows MachineSet オブジェクトを作成できます。たとえば、インフラストラクチャー Windows マシンセットおよび関連マシンを作成して、サポートする Windows ワークロードを新規の Windows マシンに移動できます。

6.2.1. 前提条件
リンクのコピー

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。
  • サポートされている Windows Server をオペレーティングシステムイメージとして使用しています。

6.2.2. Machine API の概要
リンクのコピー

Machine API は、プライマリーリソースの組み合わせたものであり、アップストリーム Cluster API プロジェクトとカスタム OpenShift Container Platform リソースをベースとしています。

OpenShift Container Platform 4.18 クラスターの場合、Machine API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングに対する管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.18 はパブリックまたはプライベートのクラウドインフラストラクチャーに加え、弾力的かつ動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

Machines
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec 仕様があります。たとえば、コンピュートノードのマシンタイプは、特定のマシンタイプと必要なメタデータを定義する場合があります。
マシンセット

MachineSet リソースは、計算マシンのグループです。コンピューティングマシンセットはコンピューティングマシン用であり、レプリカセットは Pod 用です。より多くのコンピューティングマシンが必要な場合、またはそれらを縮小する必要がある場合は、コンピューティングのニーズを満たすように MachineSet リソースの replicas フィールドを変更します。

警告

コントロールプレーンマシンは、コンピューティングマシンセットでは管理できません。

コントロールプレーンマシンセットは、サポートされているコントロールプレーンマシンに対して、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能を提供します。

詳細は、「コントロールプレーンマシンの管理」を参照してください。

以下のカスタムリソースは、クラスターに機能を追加します。

Machine Autoscaler

MachineAutoscaler リソースは、クラウド内のコンピューティングマシンを自動的にスケーリングします。指定したコンピューティングマシンセット内のノードの最小および最大スケーリング境界を設定でき Machine Autoscaler はそのノード範囲を維持します。

MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscaler および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator オブジェクトによって利用可能にされます。

Cluster Autoscaler

このリソースはアップストリームの Cluster Autoscaler プロジェクトに基づいています。OpenShift Container Platform の実装では、このリソースはコンピュートマシンセット API を拡張することで、Machine API と統合されます。クラスターオートスケーラーを使用して、次の方法でクラスターを管理できます。

  • コア、ノード、メモリー、GPU などのリソースに対してクラスター全体のスケーリング制限を設定
  • クラスターが Pod に優先順位を付け、重要度の低い Pod のために新しいノードがオンラインにならないように、優先順位を設定します。
  • ノードをスケールアップできるがスケールダウンできないようにスケーリングポリシーを設定
マシンのヘルスチェック
MachineHealthCheck リソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易にデプロイメントすることができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。各コンピュートマシンセットのスコープは 1 つのゾーンに限定されるため、インストールプログラムはユーザーに代わって複数のアベイラビリティゾーンにコンピューティングマシンセットを送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

6.2.3. Azure の Windows MachineSet オブジェクトのサンプル YAML
リンクのコピー

このサンプル YAML は、Windows Machine Config Operator (WMCO) が応答する Microsoft Azure で実行される Windows MachineSet オブジェクトを定義します。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <windows_machine_set_name>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: azureproviderconfig.openshift.io/v1beta1
          credentialsSecret:
            name: azure-cloud-credentials
            namespace: openshift-machine-api
          image:
9 

            offer: WindowsServer
            publisher: MicrosoftWindowsServer
            resourceID: ""
            sku: 2019-Datacenter-with-Containers
            version: latest
          kind: AzureMachineProviderSpec
          location: <location>
10 

          managedIdentity: <infrastructure_id>-identity
11 

          networkResourceGroup: <infrastructure_id>-rg
12 

          osDisk:
            diskSizeGB: 128
            managedDisk:
              storageAccountType: Premium_LRS
            osType: Windows
          publicIP: false
          resourceGroup: <infrastructure_id>-rg
13 

          subnet: <infrastructure_id>-worker-subnet
          userDataSecret:
            name: windows-user-data
14 

            namespace: openshift-machine-api
          vmSize: Standard_D2s_v3
          vnet: <infrastructure_id>-vnet
15 

          zone: "<zone>"
16
1 3 5 11 12 13 15
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
Windows コンピュートマシンセット名を指定します。Azure の Windows マシン名は 15 文字を超えることができません。そのため、マシン名の生成方法により、コンピュートマシンセット名は 9 文字を超えることができません。
7
コンピュートマシンセットを Windows マシンとして設定します。
8
Windows ノードをコンピュートマシンとして設定します。
9
2019-Datacenter-with-Containers SKU を定義する WindowsServer イメージオファリングを指定します。
10
centralus などの Azure リージョンを指定します。
14
最初の Windows マシンの設定時に WMCO によって作成されます。その後、windows-user-data は、後続のすべてのコンピュートマシンセットで使用できるようになります。
16
マシンを配置するリージョン内のゾーンを指定します。リージョンがゾーンをサポートすることを確認してください。

6.2.4. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。
  • 非接続環境では、MachineSet カスタムリソース (CR) で指定されたイメージに OpenSSH サーバー v0.0.1.0 がインストールされている 必要があります。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

  3. 次のコマンドを実行して MachineSet CR を作成します。 

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

6.3. Google Cloud 上に Windows マシンセットを作成する
リンクのコピー

Google Cloud 上の OpenShift Container Platform クラスターで特定の機能を果たすように Windows MachineSet オブジェクトを作成できます。たとえば、インフラストラクチャー Windows マシンセットおよび関連マシンを作成して、サポートする Windows ワークロードを新規の Windows マシンに移動できます。

6.3.1. 前提条件
リンクのコピー

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。
  • サポートされている Windows Server をオペレーティングシステムイメージとして使用しています。

6.3.2. Machine API の概要
リンクのコピー

Machine API は、プライマリーリソースの組み合わせたものであり、アップストリーム Cluster API プロジェクトとカスタム OpenShift Container Platform リソースをベースとしています。

OpenShift Container Platform 4.18 クラスターの場合、Machine API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングに対する管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.18 はパブリックまたはプライベートのクラウドインフラストラクチャーに加え、弾力的かつ動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

Machines
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec 仕様があります。たとえば、コンピュートノードのマシンタイプは、特定のマシンタイプと必要なメタデータを定義する場合があります。
マシンセット

MachineSet リソースは、計算マシンのグループです。コンピューティングマシンセットはコンピューティングマシン用であり、レプリカセットは Pod 用です。より多くのコンピューティングマシンが必要な場合、またはそれらを縮小する必要がある場合は、コンピューティングのニーズを満たすように MachineSet リソースの replicas フィールドを変更します。

警告

コントロールプレーンマシンは、コンピューティングマシンセットでは管理できません。

コントロールプレーンマシンセットは、サポートされているコントロールプレーンマシンに対して、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能を提供します。

詳細は、「コントロールプレーンマシンの管理」を参照してください。

以下のカスタムリソースは、クラスターに機能を追加します。

Machine Autoscaler

MachineAutoscaler リソースは、クラウド内のコンピューティングマシンを自動的にスケーリングします。指定したコンピューティングマシンセット内のノードの最小および最大スケーリング境界を設定でき Machine Autoscaler はそのノード範囲を維持します。

MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscaler および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator オブジェクトによって利用可能にされます。

Cluster Autoscaler

このリソースはアップストリームの Cluster Autoscaler プロジェクトに基づいています。OpenShift Container Platform の実装では、このリソースはコンピュートマシンセット API を拡張することで、Machine API と統合されます。クラスターオートスケーラーを使用して、次の方法でクラスターを管理できます。

  • コア、ノード、メモリー、GPU などのリソースに対してクラスター全体のスケーリング制限を設定
  • クラスターが Pod に優先順位を付け、重要度の低い Pod のために新しいノードがオンラインにならないように、優先順位を設定します。
  • ノードをスケールアップできるがスケールダウンできないようにスケーリングポリシーを設定
マシンのヘルスチェック
MachineHealthCheck リソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易にデプロイメントすることができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。各コンピュートマシンセットのスコープは 1 つのゾーンに限定されるため、インストールプログラムはユーザーに代わって複数のアベイラビリティゾーンにコンピューティングマシンセットを送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

6.3.3. Google Cloud 上の Windows MachineSet オブジェクトのサンプル YAML
リンクのコピー

このサンプル YAML ファイルは、Windows Machine Config Operator (WMCO) が使用できる Google Cloud で実行される Windows MachineSet オブジェクトを定義します。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-windows-worker-<zone_suffix>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone_suffix>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone_suffix>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1beta1
          canIPForward: false
          credentialsSecret:
            name: gcp-cloud-credentials
          deletionProtection: false
          disks:
          - autoDelete: true
            boot: true
            image: <windows_server_image>
9 

            sizeGb: 128
            type: pd-ssd
          kind: GCPMachineProviderSpec
          machineType: n1-standard-4
          networkInterfaces:
          - network: <infrastructure_id>-network
10 

            subnetwork: <infrastructure_id>-worker-subnet
          projectID: <project_id>
11 

          region: <region>
12 

          serviceAccounts:
          - email: <infrastructure_id>-w@<project_id>.iam.gserviceaccount.com
            scopes:
            - https://www.googleapis.com/auth/cloud-platform
          tags:
          - <infrastructure_id>-worker
          userDataSecret:
            name: windows-user-data
13 

          zone: <zone>
14
1 3 5 10
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
インフラストラクチャー ID、ワーカーラベル、およびゾーンさフィックス (a など) を指定します。
7
Windows マシンとしてマシンセットを設定します。
8
Windows ノードをコンピュートマシンとして設定します。
9
サポートされているバージョンの Windows Server のイメージへのフルパスを指定します。
11
このクラスターが作成された Google Cloud プロジェクトを指定します。
12
Google Cloud リージョン (us-central1 など) を指定します。
13
最初の Windows マシンの設定時に WMCO によって作成されます。その後、後続のすべてのマシンセットで windows-user-data を消費できるようになります。
14
選択したリージョン内のゾーン (us-central1-a など) を指定します。

6.3.4. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

  3. 次のコマンドを実行して MachineSet CR を作成します。 

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

6.4. Nutanix での Windows MachineSet オブジェクトの作成
リンクのコピー

Windows MachineSet オブジェクトを作成して、Nutanix 上の OpenShift Container Platform クラスターで特定の機能を果たすようにできます。たとえば、インフラストラクチャー Windows マシンセットおよび関連マシンを作成して、サポートする Windows ワークロードを新規の Windows マシンに移動できます。

6.4.1. 前提条件
リンクのコピー

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。
  • サポートされている Windows Server をオペレーティングシステムイメージとして使用しています。
  • 外部 API サーバー URL api.<cluster_name>.<base_domain> を指す内部 API サーバー URL api-int.<cluster_name>.<base_domain> の新しい DNS エントリーを追加しました。これには、CNAME または追加の A レコードを指定できます。

6.4.2. Machine API の概要
リンクのコピー

Machine API は、プライマリーリソースの組み合わせたものであり、アップストリーム Cluster API プロジェクトとカスタム OpenShift Container Platform リソースをベースとしています。

OpenShift Container Platform 4.18 クラスターの場合、Machine API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングに対する管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.18 はパブリックまたはプライベートのクラウドインフラストラクチャーに加え、弾力的かつ動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

Machines
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec 仕様があります。たとえば、コンピュートノードのマシンタイプは、特定のマシンタイプと必要なメタデータを定義する場合があります。
マシンセット

MachineSet リソースは、計算マシンのグループです。コンピューティングマシンセットはコンピューティングマシン用であり、レプリカセットは Pod 用です。より多くのコンピューティングマシンが必要な場合、またはそれらを縮小する必要がある場合は、コンピューティングのニーズを満たすように MachineSet リソースの replicas フィールドを変更します。

警告

コントロールプレーンマシンは、コンピューティングマシンセットでは管理できません。

コントロールプレーンマシンセットは、サポートされているコントロールプレーンマシンに対して、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能を提供します。

詳細は、「コントロールプレーンマシンの管理」を参照してください。

以下のカスタムリソースは、クラスターに機能を追加します。

Machine Autoscaler

MachineAutoscaler リソースは、クラウド内のコンピューティングマシンを自動的にスケーリングします。指定したコンピューティングマシンセット内のノードの最小および最大スケーリング境界を設定でき Machine Autoscaler はそのノード範囲を維持します。

MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscaler および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator オブジェクトによって利用可能にされます。

Cluster Autoscaler

このリソースはアップストリームの Cluster Autoscaler プロジェクトに基づいています。OpenShift Container Platform の実装では、このリソースはコンピュートマシンセット API を拡張することで、Machine API と統合されます。クラスターオートスケーラーを使用して、次の方法でクラスターを管理できます。

  • コア、ノード、メモリー、GPU などのリソースに対してクラスター全体のスケーリング制限を設定
  • クラスターが Pod に優先順位を付け、重要度の低い Pod のために新しいノードがオンラインにならないように、優先順位を設定します。
  • ノードをスケールアップできるがスケールダウンできないようにスケーリングポリシーを設定
マシンのヘルスチェック
MachineHealthCheck リソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易にデプロイメントすることができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。各コンピュートマシンセットのスコープは 1 つのゾーンに限定されるため、インストールプログラムはユーザーに代わって複数のアベイラビリティゾーンにコンピューティングマシンセットを送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

6.4.3. Nutanix の Windows MachineSet オブジェクトのサンプル YAML
リンクのコピー

このサンプル YAML は、Windows Machine Config Operator (WMCO) が応答する Nutanix で実行される Windows MachineSet オブジェクトを定義します。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <infrastructure_id>-windows-worker-<zone>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: machine.openshift.io/v1
          bootType: ""
9 

          categories: null
          cluster:
10 

            type: uuid
            uuid: <cluster_uuid>
          credentialsSecret:
            name: nutanix-credentials
11 

          image:
12 

            name: <image_id>
            type: name
          kind: NutanixMachineProviderConfig
13 

          memorySize: 16Gi
14 

          project:
            type: ""
          subnets:
15 

          - type: uuid
            uuid: <subnet_uuid>
          systemDiskSize: 120Gi
16 

          userDataSecret:
            name: windows-user-data
17 

          vcpuSockets: 4
18 

          vcpusPerSocket: 1
19
1 3 5
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
インフラストラクチャー ID、ワーカーラベル、およびゾーンを指定します。
7
コンピュートマシンセットを Windows マシンとして設定します。
8
Windows ノードをコンピュートマシンとして設定します。
9
コンピュートマシンが使用するブートタイプを指定します。ブートタイプの詳細は、仮想化環境内の UEFI、セキュアブート、および TPM について を参照してください。有効な値は、Legacy、SecureBoot、または UEFI です。デフォルトは、Legacy です。
注記

OpenShift Container Platform 4.18 では、Legacy ブートタイプを使用する必要があります。

10
Nutanix Prism Element のクラスター設定を指定します。この例のクラスタータイプは uuid であるため、uuid スタンザがあります。
11
クラスターのシークレット名を指定します。この値は変更しないでください。
12
使用するイメージを指定します。クラスターに設定されている既存のコンピュートデフォルトマシンのイメージを使用します。
13
クラウドプロバイダープラットフォームのタイプを指定します。この値は変更しないでください。
14
クラスターのメモリー量を Gi 単位で指定します。
15
サブネット設定を指定します。この例では、サブネットタイプは uuid であるため、uuid スタンザがあります。
16
システムディスクのサイズを Gi 単位で指定します。
17
openshift-machine-api namespace にあるユーザーデータ YAML ファイルで、シークレットの名前を指定します。インストールプログラムがデフォルトのコンピュートマシンセットに入力する値を使用します。
18
vCPU ソケットの数を指定します。
19
ソケットごとの vCPU 数を指定します。

6.4.4. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

  3. 次のコマンドを実行して MachineSet CR を作成します。 

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

6.5. vSphere 上での Windows マシンセットの作成
リンクのコピー

VMware vSphere 上の OpenShift Container Platform クラスターで特定の機能を果たすように Windows MachineSet オブジェクトを作成できます。たとえば、インフラストラクチャー Windows マシンセットおよび関連マシンを作成して、サポートする Windows ワークロードを新規の Windows マシンに移動できます。

6.5.1. 前提条件
リンクのコピー

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。
  • サポートされている Windows Server をオペレーティングシステムイメージとして使用しています。

6.5.2. Machine API の概要
リンクのコピー

Machine API は、プライマリーリソースの組み合わせたものであり、アップストリーム Cluster API プロジェクトとカスタム OpenShift Container Platform リソースをベースとしています。

OpenShift Container Platform 4.18 クラスターの場合、Machine API はクラスターインストールの終了後にすべてのノードホストのプロビジョニングに対する管理アクションを実行します。このシステムにより、OpenShift Container Platform 4.18 はパブリックまたはプライベートのクラウドインフラストラクチャーに加え、弾力的かつ動的なプロビジョニング方法を提供します。

以下の 2 つのリソースは重要なリソースになります。

Machines
ノードのホストを記述する基本的なユニットです。マシンには、複数の異なるクラウドプラットフォーム用に提供されるコンピュートノードのタイプを記述する providerSpec 仕様があります。たとえば、コンピュートノードのマシンタイプは、特定のマシンタイプと必要なメタデータを定義する場合があります。
マシンセット

MachineSet リソースは、計算マシンのグループです。コンピューティングマシンセットはコンピューティングマシン用であり、レプリカセットは Pod 用です。より多くのコンピューティングマシンが必要な場合、またはそれらを縮小する必要がある場合は、コンピューティングのニーズを満たすように MachineSet リソースの replicas フィールドを変更します。

警告

コントロールプレーンマシンは、コンピューティングマシンセットでは管理できません。

コントロールプレーンマシンセットは、サポートされているコントロールプレーンマシンに対して、コンピュートマシンセットがコンピュートマシンに提供するものと同様の管理機能を提供します。

詳細は、「コントロールプレーンマシンの管理」を参照してください。

以下のカスタムリソースは、クラスターに機能を追加します。

Machine Autoscaler

MachineAutoscaler リソースは、クラウド内のコンピューティングマシンを自動的にスケーリングします。指定したコンピューティングマシンセット内のノードの最小および最大スケーリング境界を設定でき Machine Autoscaler はそのノード範囲を維持します。

MachineAutoscaler オブジェクトは ClusterAutoscaler オブジェクトの設定後に有効になります。ClusterAutoscaler および MachineAutoscaler リソースは、どちらも ClusterAutoscalerOperator オブジェクトによって利用可能にされます。

Cluster Autoscaler

このリソースはアップストリームの Cluster Autoscaler プロジェクトに基づいています。OpenShift Container Platform の実装では、このリソースはコンピュートマシンセット API を拡張することで、Machine API と統合されます。クラスターオートスケーラーを使用して、次の方法でクラスターを管理できます。

  • コア、ノード、メモリー、GPU などのリソースに対してクラスター全体のスケーリング制限を設定
  • クラスターが Pod に優先順位を付け、重要度の低い Pod のために新しいノードがオンラインにならないように、優先順位を設定します。
  • ノードをスケールアップできるがスケールダウンできないようにスケーリングポリシーを設定
マシンのヘルスチェック
MachineHealthCheck リソースはマシンの正常でない状態を検知し、マシンを削除し、サポートされているプラットフォームでは新規マシンを作成します。

OpenShift Container Platform バージョン 3.11 では、クラスターでマシンのプロビジョニングが管理されないためにマルチゾーンアーキテクチャーを容易にデプロイメントすることができませんでした。しかし、OpenShift Container Platform バージョン 4.1 以降、このプロセスはより簡単になりました。各コンピュートマシンセットのスコープは 1 つのゾーンに限定されるため、インストールプログラムはユーザーに代わって複数のアベイラビリティゾーンにコンピューティングマシンセットを送信します。さらに、コンピューティングは動的に展開されるため、ゾーンに障害が発生した場合の、マシンのリバランスが必要な場合に使用するゾーンを常に確保できます。複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンでは、アベイラビリティーセットを使用して高可用性を確保できます。Autoscaler はクラスターの有効期間中にベストエフォートでバランシングを提供します。

6.5.3. Windows コンテナーワークロード用の vSphere 環境の準備
リンクのコピー

vSphere Windows 仮想マシンのゴールドイメージを作成し、WMCO の内部 API サーバーとの通信を有効にして、Windows コンテナーのワークロード用に vSphere 環境を準備する必要があります。

6.5.3.1. vSphere Windows 仮想マシンのゴールドイメージの作成
リンクのコピー

vSphere Windows 仮想マシン (VM) のゴールドイメージを作成します。

前提条件

  • OpenSSH サーバーで鍵ベースの認証を設定するのに使用する、秘密鍵/公開鍵ペアを作成している。Windows Machine Config Operator (WMCO) が Windows 仮想マシンと通信できるように、秘密鍵を WMCO namespace で設定する必要があります。

    Red Hat Enterprise Linux (RHEL) システムでキーペアを作成した場合、Windows システムで公開鍵を使用する前に、公開鍵が ASCII エンコードを使用して保存されていることを確認してください。たとえば、次の PowerShell コマンドは、公開鍵を ASCII 文字セットにエンコードしてコピーします。 

    C:\> echo "ssh-rsa <ssh_pub_key>" | Out-File <ssh_key_path> -Encoding ascii

    ここでは、以下のようになります。

    <ssh_pub_key>
    クラスターにアクセスするために使用する SSH 公開鍵を指定します。
    <ssh_key_path>
    SSH 公開鍵へのパスを指定します。

    詳細は、「Windows Machine Config Operator のシークレットの設定」セクションを参照してください。

注記

Windows 仮想マシンを作成する際には、複数のケースで Microsoft PowerShell コマンドを使用する必要があります。このガイドの PowerShell コマンドは、PS C:\> 接頭辞によって区別されます。

手順

  1. 互換性のある Windows Server バージョンを選択します。現在、Windows Machine Config Operator (WMCO) の安定版は、OS レベルのコンテナーネットワークパッチ KB5012637 を適用した Windows Server 2022 Long-Term Servicing Channel をサポートしています。

  2. 互換性のある Windows Server バージョンの VM ゴールデンイメージを使用して、vSphere クライアントに新しい VM を作成します。互換性のあるバージョンの詳細は、「Red Hat OpenShift support for Windows Containers リリースノート」の「Windows Machine Config Operator の前提条件」セクションを参照してください。

    重要

    VM の仮想ハードウェアバージョンは、OpenShift Container Platform のインフラストラクチャー要件を満たしている必要があります。詳細は、OpenShift Container Platform ドキュメントの「VMware vSphere インフラストラクチャーの要件」セクションを参照してください。また、仮想マシンのハードウェアバージョン に関する VMware のドキュメントを参照することもできます。

  3. Windows 仮想マシンに VMware Tools バージョン 11.0.6 以降をインストールし、設定します。詳細は、VMware Tools のドキュメント を参照してください。

  4. Windows 仮想マシンに VMware Tools をインストールした後、以下を確認します。

    1. C:\ProgramData\VMware\VMware Tools\tools.conf ファイルが、以下のエントリーとともに存在します。 

      exclude-nics=

      tools.conf ファイルが存在しない場合は、exclude-nics オプションでコメント解除した状態でこれを作成し、空の値に設定します。

      このエントリーにより、ハイブリッドオーバーレイで Windows 仮想マシンで生成され、クローン作成された vNIC は無視されないようにします。

    2. Windows 仮想マシンには、vCenter で有効な IP アドレスがあります。 

      C:\> ipconfig

    3. VMTools Windows サービスが実行中である。 

      PS C:\> Get-Service -Name VMTools | Select Status, StartType
  5. Windows 仮想マシンに OpenSSH Server をインストールし、設定します。詳細は、Microsoft ドキュメントの Installing OpenSSH を参照してください。

  6. 管理ユーザーの SSH アクセスを設定します。そのためには、Microsoft のドキュメント Administrative user を参照してください。

    重要

    命令に使用されるパブリックキーは、シークレットを保持する WMCO namespace で後に作成するプライベートキーに対応している必要があります。詳細は、「Windows Machine Config Operator のシークレットの設定」セクションを参照してください。

  7. コンテナーログの受信接続を可能にする新しいファイアウォールルールを Windows 仮想マシンに作成する必要があります。以下の PowerShell コマンドを実行して、TCP ポート 10250 にファイアウォールルールを作成します。 

    PS C:\> New-NetFirewallRule -DisplayName "ContainerLogsPort" -LocalPort 10250 -Enabled True -Direction Inbound -Protocol TCP -Action Allow -EdgeTraversalPolicy Allow
  8. Windows 仮想マシンのクローンを作成し、再利用可能なイメージにします。詳細は、VMware ドキュメントで 既存の仮想マシンのクローンを作成 する方法を参照してください。

  9. クローン作成した Windows 仮想マシンで、Windows Sysprep ツール を実行します。 

    C:\> C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:<path_to_unattend.xml>
    1
    1
    unattend.xml ファイルへのパスを指定します。
    注記

    Windows イメージで sysprep コマンドを実行することができる回数に制限があります。詳細は、Microsoft の ドキュメント を参照してください。

    サンプルの unattend.xml が提供され、これは WMCO で必要なすべての変更を維持します。この例では変更する必要があります。直接使用することはできません。

    例6.1 サンプル unattend.xml

    <?xml version="1.0" encoding="UTF-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
   <settings pass="specialize">
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <InputLocale>0409:00000409</InputLocale>
         <SystemLocale>en-US</SystemLocale>
         <UILanguage>en-US</UILanguage>
         <UILanguageFallback>en-US</UILanguageFallback>
         <UserLocale>en-US</UserLocale>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <SkipAutoActivation>true</SkipAutoActivation>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-SQMApi" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <CEIPEnabled>0</CEIPEnabled>
      </component>
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <ComputerName>winhost</ComputerName>
    1 
    
      </component>
   </settings>
   <settings pass="oobeSystem">
      <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
         <AutoLogon>
            <Enabled>false</Enabled>
    2 
    
         </AutoLogon>
         <OOBE>
            <HideEULAPage>true</HideEULAPage>
            <HideLocalAccountScreen>true</HideLocalAccountScreen>
            <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
            <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
            <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
            <NetworkLocation>Work</NetworkLocation>
            <ProtectYourPC>1</ProtectYourPC>
            <SkipMachineOOBE>true</SkipMachineOOBE>
            <SkipUserOOBE>true</SkipUserOOBE>
         </OOBE>
         <RegisteredOrganization>Organization</RegisteredOrganization>
         <RegisteredOwner>Owner</RegisteredOwner>
         <DisableAutoDaylightTimeSet>false</DisableAutoDaylightTimeSet>
         <TimeZone>Eastern Standard Time</TimeZone>
         <UserAccounts>
            <AdministratorPassword>
               <Value>MyPassword</Value>
    3 
    
               <PlainText>true</PlainText>
            </AdministratorPassword>
         </UserAccounts>
      </component>
   </settings>
</unattend>
    1
    Kubernetes の名前の仕様 に従いなければならない ComputerName を指定します。これらの仕様は、新規仮想マシンの作成時に作成されるテンプレートで実行されるゲスト OS のカスタマイズにも適用されます。
    2
    自動ログオンを無効にして、起動時に管理者権限で開いているターミナルをそのまま残すセキュリティーの問題を回避します。これはデフォルト値であるため、変更しないでください。
    3
    MyPassword プレースホルダーを Administrator アカウントのパスワードに置き換えます。これにより、組み込みの Administrator アカウントはデフォルトで空のパスワードを持つことを防ぎます。Microsoft の パスワードを選択するベストプラクティス に従ってください。

    Sysprep ツールが完了すると、Windows 仮想マシンの電源がオフになります。この仮想マシンで使用または電源は使用しないでください。

  10. Windows 仮想マシンを vCenter のテンプレート に変換します。
6.5.3.2. vSphere での WMCO に関する内部 API サーバーとの通信の有効化
リンクのコピー

Windows Machine Config Operator (WMCO) は Ignition 設定ファイルを内部 API サーバーエンドポイントからダウンロードします。Windows 仮想マシン (VM) が Ignition 設定ファイルをダウンロードできるように、また設定された仮想マシンが kubelet が内部 API サーバーとのみ通信できるように内部 API サーバーとの通信を有効にする必要があります。

前提条件

  • クラスターを vSphere にインストールしている。

手順

  • 外部 API サーバー URL api.<cluster_name>.<base_domain> を参照する api-int.<cluster_name>.<base_domain> の新規 DNS エントリー追加します。これには、CNAME または追加の A レコードを指定できます。
注記

外部 API エンドポイントは、vSphere への初期クラスターインストールの一部としてすでに作成されています。

6.5.4. vSphere での Windows の MachineSet オブジェクトのサンプル YAML
リンクのコピー

このサンプル YAML は、Windows Machine Config Operator (WMCO) が応答する VMware vSphere で実行される Windows MachineSet オブジェクトを定義します。 

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
1 

  name: <windows_machine_set_name>
2 

  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
3 

      machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
4 

  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
5 

        machine.openshift.io/cluster-api-machine-role: worker
        machine.openshift.io/cluster-api-machine-type: worker
        machine.openshift.io/cluster-api-machineset: <windows_machine_set_name>
6 

        machine.openshift.io/os-id: Windows
7 

    spec:
      metadata:
        labels:
          node-role.kubernetes.io/worker: ""
8 

      providerSpec:
        value:
          apiVersion: vsphereprovider.openshift.io/v1beta1
          credentialsSecret:
            name: vsphere-cloud-credentials
          diskGiB: 128
9 

          kind: VSphereMachineProviderSpec
          memoryMiB: 16384
          network:
            devices:
            - networkName: "<vm_network_name>"
10 

          numCPUs: 4
          numCoresPerSocket: 1
          snapshot: ""
          template: <windows_vm_template_name>
11 

          userDataSecret:
            name: windows-user-data
12 

          workspace:
             datacenter: <vcenter_data_center_name>
13 

             datastore: <vcenter_datastore_name>
14 

             folder: <vcenter_vm_folder_path>
15 

             resourcePool: <vsphere_resource_pool>
16 

             server: <vcenter_server_ip>
17
1 3 5
クラスターのプロビジョニング時に設定したクラスター ID を基にするインフラストラクチャー ID を指定します。以下のコマンドを実行してインフラストラクチャー ID を取得できます。 
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
2 4 6
Windows コンピュートマシンセット名を指定します。コンピュートマシンセットの名前は、マシン名が vSphere で生成される方法により、9 文字を超えることができません。
7
コンピュートマシンセットを Windows マシンとして設定します。
8
Windows ノードをコンピュートマシンとして設定します。
9
vSphere 仮想マシンディスク (VMDK) のサイズを指定します。
注記

このパラメーターは、Windows パーティションのサイズを設定しません。unattend.xml ファイルを使用するか、必要なディスクサイズで vSphere Windows 仮想マシン (VM) ゴールデンイメージを作成することにより、Windows パーティションのサイズを変更できます。

10
コンピュートマシンセットをデプロイする vSphere 仮想マシンネットワークを指定します。この仮想マシンネットワークは、他の Linux コンピューティングマシンがクラスター内に存在する場所である必要があります。
11
golden-images/windows-server-template などの、使用する Windows vSphere 仮想マシンテンプレートの完全パスを指定します。名前は一意である必要があります。
重要

元の仮想マシンテンプレートは指定しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規の Windows マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

12
windows-user-data は、最初の Windows マシンの設定時に WMCO によって作成されます。その後、windows-user-data は、後続のすべてのコンピュートマシンセットで使用できるようになります。
13
コンピュートマシンセットをデプロイする vCenter データセンターを指定します。
14
コンピュートマシンセットをデプロイする vCenter データストアを指定します。
15
/dc1/vm/user-inst-5ddjd などの vCenter の vSphere 仮想マシンフォルダーへのパスを指定します。
16
オプション: Windows 仮想マシンの vSphere リソースプールを指定します。
17
vCenter サーバーの IP または完全修飾ドメイン名を指定します。

6.5.5. コンピュートマシンセットの作成
リンクのコピー

インストールプログラムによって作成されるコンピュートセットセットに加えて、独自のマシンセットを作成して、選択した特定のワークロードのマシンコンピューティングリソースを動的に管理できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。
  • 非接続環境では、MachineSet カスタムリソース (CR) で指定されたイメージに OpenSSH サーバー v0.0.1.0 がインストールされている 必要があります。

手順

  1. コンピュートマシンセットのカスタムリソース (CR) サンプルを含む新しい YAML ファイルを作成し、<file_name>.yaml という名前を付けます。

    <clusterID> および <role> パラメーターの値を設定していることを確認します。

  2. オプション: 特定のフィールドに設定する値がわからない場合は、クラスターから既存のコンピュートマシンセットを確認できます。

    1. クラスター内のコンピュートマシンセットをリスト表示するには、次のコマンドを実行します。 

      $ oc get machinesets -n openshift-machine-api

      出力例

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d   0         0                             55m
agl030519-vplxk-worker-us-east-1e   0         0                             55m
agl030519-vplxk-worker-us-east-1f   0         0                             55m

    2. 特定のコンピュートマシンセットカスタムリソース (CR) 値を表示するには、以下のコマンドを実行します。 

      $ oc get machineset <machineset_name> \
  -n openshift-machine-api -o yaml

      出力例

      apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      1 
      
  name: <infrastructure_id>-<role>
      2 
      
  namespace: openshift-machine-api
spec:
  replicas: 1
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
  template:
    metadata:
      labels:
        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
        machine.openshift.io/cluster-api-machine-role: <role>
        machine.openshift.io/cluster-api-machine-type: <role>
        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
    spec:
      providerSpec:
      3 
      
        ...

      1
      クラスターインフラストラクチャー ID。
      2
      デフォルトのノードラベル。
      注記

      user-provisioned infrastructure を持つクラスターの場合、コンピュートマシンセットは worker および infra タイプのマシンのみを作成できます。

      3
      コンピュートマシンセット CR の <providerSpec> セクションの値は、プラットフォーム固有です。CR の <providerSpec> パラメーターの詳細は、プロバイダーのサンプルコンピュートマシンセット CR 設定を参照してください。

  3. 次のコマンドを実行して MachineSet CR を作成します。 

    $ oc create -f <file_name>.yaml

検証

  • 次のコマンドを実行して、コンピュートマシンセットのリストを表示します。 

    $ oc get machineset -n openshift-machine-api

    出力例

    NAME                                       DESIRED   CURRENT   READY   AVAILABLE   AGE
agl030519-vplxk-windows-worker-us-east-1a  1         1         1       1           11m
agl030519-vplxk-worker-us-east-1a          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1b          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1c          1         1         1       1           55m
agl030519-vplxk-worker-us-east-1d          0         0                             55m
agl030519-vplxk-worker-us-east-1e          0         0                             55m
agl030519-vplxk-worker-us-east-1f          0         0                             55m

    新しいコンピュートマシンセットが利用可能になると、DESIRED と CURRENT の値が一致します。コンピュートマシンセットが使用できない場合は、数分待ってからコマンドを再実行してください。

第7章 Windows コンテナーワークロードのスケジューリング
リンクのコピー

Windows ワークロードを Windows コンピュートノードにスケジュールすることができます。

7.1. 前提条件
リンクのコピー

  • Operator Lifecycle Manager (OLM) を使用して Windows Machine Config Operator (WMCO) をインストールしている。
  • OS イメージとして Windows コンテナーを使用しています。
  • Windows コンピュートマシンセットを作成しました。

7.2. Windows Pod の配置
リンクのコピー

Windows ワークロードをクラスターにデプロイする前に、Pod が適切に割り当てられるように Windows ノードのスケジューリングを設定する必要があります。Windows ノードをホストするマシンがあるので、これは Linux ベースのノードと同じように管理できます。同様に、テイント、toleration およびノードセレクターなどのメカニズムを使用して、Windows Pod の適切な Windows ノードへのスケジュールも同様に実行されます。

複数のオペレーティングシステム、および同じクラスターで複数の Windows OS バリアントを実行する機能で、RuntimeClass オブジェクトを使用して Windows Pod をベース Windows OS バリアントにマップする必要があります。たとえば、複数の Windows ノードが複数の Windows Server コンテナーのバージョンで実行されている場合、クラスターは Windows Pod を互換性のない Windows OS バリアントにスケジュールする可能性があります。クラスター上の Windows OS バリアントごとに RuntimeClass オブジェクトを設定する必要があります。クラスターで 1 つの Windows OS バリアントのみが利用可能である場合、RuntimeClass オブジェクトを使用することも推奨されます。

詳細は、ホストとコンテナーのバージョンの互換性 を参照してください。

ワークロード Pod で spec.os.name.windows パラメーターを設定することも推奨されます。Windows Machine Config Operator (WMCO) は、このフィールドを使用して検証のために Pod オペレーティングシステムを正式に識別し、Windows 固有の Pod セキュリティーコンテキスト制約 (SCC) を強制するために使用されます。現在、このパラメーターは Pod のスケジュールには影響しません。このパラメーターの詳細は、Kubernetes Pod のドキュメント を参照してください。

重要

コンテナーの基本イメージは、コンテナーがスケジュールされるノードで実行されているものと同じ Windows OS バージョンおよびビルド番号である必要があります。

また、Windows ノードをあるバージョンから別のバージョンにアップグレードする場合 (たとえば、20H2 から 2022 に移行する場合)、新しいバージョンに一致するようにコンテナーの基本イメージをアップグレードする必要があります。詳細は、Windows コンテナーのバージョンの互換性 を参照してください。

7.3. スケジューリングメカニズムをカプセル化するための RuntimeClass オブジェクトの作成
リンクのコピー

RuntimeClass オブジェクトを使用することにより、テイントおよび toleration などのスケジュールの仕組みの使用を単純化できます。テイントおよび toleration をカプセル化するランタイムクラスをデプロイしてから、これを Pod に適用して Pod を適切なノードにスケジュールできるようにします。ランタイムクラスの作成は、複数のオペレーティングシステムのバリアントをサポートするクラスターでも必要になります。

手順

  1. RuntimeClass オブジェクト YAML ファイルを作成します。例: runtime-class.yaml 

    apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: windows2019
    1 
    
handler: 'runhcs-wcow-process'
scheduling:
  nodeSelector:
    2 
    
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.17763'
  tolerations:
    3 
    
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "windows"
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "Windows"
    1
    このランタイムクラスで管理する必要のある Pod で定義される RuntimeClass オブジェクト名を指定します。
    2
    このランタイムクラスをサポートするノードに存在する必要があるラベルを指定します。このランタイムクラスを使用する Pod は、このセレクターに一致するノードにのみスケジュールできます。ランタイムクラスのノードセレクターは Pod の既存のノードセレクターとマージされます。競合が発生した場合は、Pod をノードにスケジュールできなくなります。
    • Windows 2019 の場合は、node.kubernetes.io/windows-build: '10.0.17763' ラベルを指定します。
    • Windows 2022 の場合は、node.kubernetes.io/windows-build: '10.0.20348' ラベルを指定します。
    3
    Pod に追加する toleration を指定します。ただし、受付時にこのランタイムクラスで実行される重複を除きます。これによって、Pod によって許容されるノードのセットとランタイムクラスが組み合わされます。

  2. RuntimeClass オブジェクトを作成します。 

    $ oc create -f <file-name>.yaml

    以下に例を示します。 

    $ oc create -f runtime-class.yaml

  3. RuntimeClass オブジェクトを Pod に適用し、これが適切なオペレーティングシステムバリアントにスケジュールされていることを確認します。 

    apiVersion: v1
kind: Pod
metadata:
  name: my-windows-pod
spec:
  runtimeClassName: windows2019
    1 
    
# ...
    1
    Pod のスケジュールを管理するためにランタイムクラスを指定します。

7.4. Windows コンテナーワークロードのデプロイメント例
リンクのコピー

Windows コンピュートノードが利用可能になる時点で、Windows コンテナーワークロードをクラスターにデプロイできます。

注記

このサンプルデプロイメントは参照用にのみ提供されます。

Service オブジェクトの例

apiVersion: v1
kind: Service
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  ports:
    # the port that this service should serve on
  - port: 80
    targetPort: 80
  selector:
    app: win-webserver
  type: LoadBalancer

Deployment オブジェクトの例

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver
  name: win-webserver
spec:
  selector:
    matchLabels:
      app: win-webserver
  replicas: 1
  template:
    metadata:
      labels:
        app: win-webserver
      name: win-webserver
    spec:
      containers:
      - name: windowswebserver
        image: mcr.microsoft.com/windows/servercore:ltsc2019
1 

        imagePullPolicy: IfNotPresent
        command:
        - powershell.exe
2 

        - -command
        - $listener = New-Object System.Net.HttpListener; $listener.Prefixes.Add('http://*:80/'); $listener.Start();Write-Host('Listening at http://*:80/'); while ($listener.IsListening) { $context = $listener.GetContext(); $response = $context.Response; $content='<html><body><H1>Red Hat OpenShift + Windows Container Workloads</H1></body></html>'; $buffer = [System.Text.Encoding]::UTF8.GetBytes($content); $response.ContentLength64 = $buffer.Length; $response.OutputStream.Write($buffer, 0, $buffer.Length); $response.Close(); };
        securityContext:
          runAsNonRoot: false
          windowsOptions:
            runAsUserName: "ContainerAdministrator"
      os:
        name: "windows"
      runtimeClassName: windows2019
3

1
使用するコンテナーイメージを指定します: mcr.microsoft.com/powershell:<tag> または mcr.microsoft.com/windows/servercore:<tag>。コンテナーイメージは、ノードで実行されている Windows バージョンと一致する必要があります。
  • Windows 2019 の場合は、ltsc2019 タグを使用します。
  • Windows 2022 の場合は、ltsc2022 タグを使用します。
2
コンテナーで実行するコマンドを指定します。
  • mcr.microsoft.com/powershell:<tag> コンテナーイメージの場合は、コマンドを pwsh.exe と定義する必要があります。
  • mcr.microsoft.com/windows/servercore:<tag> コンテナーイメージの場合は、コマンドを powershell.exe と定義する必要があります。
3
クラスターの Windows オペレーティングシステムバリアント用に作成したランタイムクラスを指定します。

7.5. Windows CSI ドライバーのサポート
リンクのコピー

Windows コンテナーに対する Red Hat OpenShift サポートは、クラスター内のすべての Windows ノードに CSI Proxy をインストールします。CSI Proxy は、CSI ドライバーがノード上でストレージ操作を実行できるようにするプラグインです。

Windows ワークロードで永続ストレージを使用するには、ストレージプロバイダーのドキュメントに記載されているように、特定の Windows CSI ドライバーデーモンセットをデプロイする必要があります。デフォルトでは、WMCO は Windows CSI ドライバーデーモンセットを自動的に作成しません。Kubernetes CSI Developer Documentation の 製品ドライバー のリストを参照してください。

注記

Red Hat は、Kubernetes CSI Developer Documentation に記載されているサードパーティーの製品ドライバーのサポートを提供していません。

7.6. コンピュートマシンセットの手動スケーリング
リンクのコピー

コンピュートマシンセットのマシンのインスタンスを追加したり、削除したりする必要がある場合、コンピュートマシンセットを手動でスケーリングできます。

このガイダンスは、完全に自動化された installer-provisioned infrastructure のインストールに関連します。user-provisioned infrastructure のカスタマイズされたインストールにはコンピュートマシンセットがありません。

前提条件

  • OpenShift Container Platform クラスターおよび oc コマンドラインをインストールすること。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. 次のコマンドを実行して、クラスター内のコンピュートマシンセットを表示します。 

    $ oc get machinesets.machine.openshift.io -n openshift-machine-api

    コンピュートマシンセットは <clusterid>-worker-<aws-region-az> の形式で一覧表示されます。

  2. 次のコマンドを実行して、クラスター内のコンピュートマシンを表示します。 

    $ oc get machines.machine.openshift.io -n openshift-machine-api

  3. 次のコマンドを実行して、削除するコンピュートマシンに注釈を設定します。 

    $ oc annotate machines.machine.openshift.io/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"

  4. 次のいずれかのコマンドを実行して、コンピュートマシンセットをスケーリングします。 

    $ oc scale --replicas=2 machinesets.machine.openshift.io <machineset> -n openshift-machine-api

    または、以下を実行します。 

    $ oc edit machinesets.machine.openshift.io <machineset> -n openshift-machine-api
    ヒント

    または、以下の YAML を適用してコンピュートマシンセットをスケーリングすることもできます。 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2

    コンピュートマシンセットをスケールアップまたはスケールダウンできます。新規マシンが利用可能になるまで数分の時間がかかります。

    重要

    デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードを drain しようとします。場合によっては、drain 操作が成功しない可能性があります。たとえば、Pod Disruption Budget が間違っている場合などです。drain 操作が失敗した場合、マシンコントローラーはマシンの削除を続行できません。

    特定のマシンの machine.openshift.io/exclude-node-draining にアノテーションを付けると、ノードの drain を省略できます。

検証

  • 次のコマンドを実行して、目的のマシンが削除されたことを確認します。 

    $ oc get machines.machine.openshift.io

第8章 Windows ノードの更新
リンクのコピー

Windows Machine Config Operator (WMCO) を更新することで、Windows ノードに最新の更新を確実に適用できます。

WMCO は次のいずれか場合に更新できます。

  • 現在のバージョン内での更新。たとえば、<10.y.z> から <10.y.z+1> に更新できます。
  • 連続する新しいバージョンへの更新。たとえば、<10.y> から <10.y+1> に更新できます。
  • コントロールプレーンのみの更新を使用した、ある EUS バージョンから別の EUS バージョンへの更新。たとえば、<10.y> から <10.y+2> に更新できます。

8.1. Windows Machine Config Operator の更新
リンクのコピー

現在のクラスターバージョンと互換性のある Windows Machine Config Operator (WMCO) の新しいバージョンがリリースされると、Operator Lifecycle Manager (OLM) の使用時にインストールされた更新チャネルとサブスクリプション承認ストラテジーに基づいて Operator が更新されます。WMCO が更新されると、Windows マシンの Kubernetes コンポーネントも更新されます。

注記

新しいバージョンの WMCO に更新し、クラスターモニタリングを使用する必要がある場合は、WMCO の namespace に openshift.io/cluster-monitoring=true ラベルが存在している必要があります。ラベルを既存の WMCO namespace に追加し、すでに Windows ノードが設定されている場合は、WMCO Pod を再起動してモニタリンググラフを表示できるようにします。

WMCO は、無停止で更新するために、以前のバージョンの WMCO によって設定された Windows マシンを終了し、現在のバージョンを使用して再作成します。これは、Machine オブジェクトを削除して実行されます。これにより、Windows ノードの drain (Pod の退避) および削除が実行されます。WMCO は、更新を容易にするために、設定されたすべてのノードにバージョンアノテーションを追加します。更新中にバージョンアノテーションが一致しない場合、Windows マシンが削除され、再作成されます。更新中のサービス中断を最小限に抑えるために、WMCO は一度に 1 台の Windows マシンのみを更新します。

更新後、ワークロード Pod で spec.os.name.windows パラメーターを設定することが推奨されます。WMCO は、このフィールドを使用して検証のために Pod オペレーティングシステムを正式に識別し、Windows 固有の Pod セキュリティーコンテキスト制約 (SCC) を強制するために使用されます。

重要

WMCO は Kubernetes コンポーネントの更新のみを行い、Windows オペレーティングシステムの更新は行いません。仮想マシンの作成時に Windows イメージを指定できるため、更新されたイメージを指定できます。MachineSet 仕様でイメージ設定を変更して、更新された Windows イメージを指定できます。

8.2. Windows Machine Config Operator のコントロールプレーンのみの更新
リンクのコピー

OpenShift Container Platform および Windows Machine Config Operator (WMCO) は、コントロールプレーンのみの更新 と呼ばれるプロセスで、OpenShift Container Platform のある EUS バージョンから別の EUS バージョンへの更新をサポートしています。クラスターをアップグレードすると、Windows ノードが開始時の EUS バージョンから新しい EUS バージョンに更新されます。その間、Windows ワークロードは中断することなく正常な状態に保たれます。

重要

この更新は、以前は EUS から EUS への更新 と呼ばれていましたが、現在は コントロールプレーンのみの更新 と呼ばれています。この更新は、OpenShift Container Platform の 偶数番号のマイナーバージョン 間でのみ実行可能です。

8.2.1. Web コンソールを使用した WMCO のコントロールプレーンのみの更新
リンクのコピー

OpenShift Container Platform Web コンソールを使用して、Windows Machine Config Operator (WMCO) のコントロールプレーンのみの更新を実行できます。

前提条件

  • サポートされている OpenShift Container Platform の EUS バージョンでクラスターが実行されている。
  • すべての Windows ノードが正常な状態である。
  • すべての Windows ノードが、同じバージョンの WMCO で実行されている。
  • コントロールプレーンのみの更新の前提条件がすべて満たされている。「コントロールプレーンのみの更新を実行する」の説明を参照してください。

手順

  1. 以下の手順に従って WMCO Operator をアンインストールします。

    重要

    Operator のみを削除してください。Windows の namespace や Windows ワークロードは削除しないでください。

    1. OpenShift Container Platform Web コンソールにログインします。
    2. Operators → OperatorHub に移動します。
    3. Filter by keyword ボックスを使用して、Red Hat Windows Machine Config Operator を検索します。
    4. Red Hat Windows Machine Config Operator タイルをクリックします。Operator タイルはこれがインストールされていることを示します。
    5. Windows Machine Config Operator 記述子ページで、Uninstall をクリックします。
  2. 「コントロールプレーンのみの更新を実行する」の手順に従って、OpenShift Container Platform を更新します。
  3. 「Web コンソールを使用した Windows Machine Config Operator のインストール」の手順に従って、新しい WMCO バージョンをインストールします。

8.2.2. CLI を使用した WMCO のコントロールプレーンのみの更新
リンクのコピー

OpenShift CLI (oc) を使用して、Windows Machine Config Operator (WMCO) のコントロールプレーンのみの更新を実行できます。

前提条件

  • サポートされている OpenShift Container Platform の EUS バージョンでクラスターが実行されている。
  • すべての Windows ノードが正常な状態である。
  • すべての Windows ノードが、同じバージョンの WMCO で実行されている。
  • コントロールプレーンのみの更新の前提条件がすべて満たされている。「コントロールプレーンのみの更新を実行する」の説明を参照してください。

手順

  1. 「CLI の使用によるクラスターからの Operator の削除」の手順に従って、クラスターから WMCO Operator をアンインストールします。

    重要

    Operator のみを削除してください。Windows の namespace や Windows ワークロードは削除しないでください。

  2. 「コントロールプレーンのみの更新を実行する」の手順に従って、OpenShift Container Platform を更新します。
  3. 「CLI を使用した Windows Machine Config Operator のインストール」手順に従って、新しい WMCO バージョンをインストールします。

検証

  • Status に Succeeded と表示されていることを確認して、WMCO が正常にインストールされたことを確認します。

第9章 BYOH (Bring-Your-Own-Host) Windows インスタンスをノードとして使用
リンクのコピー

BYOH (Bring-Your-Own-Host) を使用すると、ユーザーは Windows Server 仮想マシンを再利用して、OpenShift Container Platform に移動できます。BYOH Windows インスタンスは、Windows Server がオフラインになった場合に大規模なサービス中断を軽減するのに役立ちます。

9.1. BYOH Windows インスタンスの設定
リンクのコピー

BYOH Windows インスタンスを作成するには、Windows Machine Config Operator (WMCO) namespace に Config Map を作成する必要があります。

前提条件

ノードとしてクラスターに割り当てられる Windows インスタンスはすべて、以下の要件を満たす必要がある。

  • インスタンスは、クラスターの Linux ワーカーノードと同じネットワーク上にある必要があります。
  • ポート 22 が開いていて、SSH サーバーを実行している必要があります。
  • SSH サーバーのデフォルトシェルは、Windows コマンドシェル または cmd.exe である必要があります。
  • ログコレクションに対してポート 10250 を開く必要があります。
  • 管理者ユーザーは、認可された SSH キーとしてシークレットセットで使用される秘密鍵 (Microsoft ドキュメント) を所有しています。
  • インストーラーによってプロビジョニングされたインフラストラクチャー (IPI) AWS クラスター用に BYOH Windows インスタンスを作成する場合は、ワーカーノード用のコンピュートマシンセットの spec.template.spec.value.tag 値と一致する AWS インスタンスにタグを追加する必要があります。たとえば、kubernetes.io/cluster/<cluster_id>: owned または kubernetes.io/cluster/<cluster_id>: shared です。
  • vSphere で BYOH Windows インスタンスを作成する場合は、内部 API サーバーとの通信を有効にする必要があります。

  • インスタンスのホスト名は、以下の標準を含む RFC 1123 DNS ラベルの要件に従う必要があります。

    • 小文字の英数字またはハイフン ('-') のみが含まれます。
    • 英数字から始まります。
    • 英数字の文字で終わります。
注記

WMCO によってデプロイされる Windows インスタンスは、containerd コンテナーランタイムで設定されます。WMCO がランタイムをインストールして管理するため、ノードに containerd を手動でインストールしないことを推奨します。

手順

  1. 追加する Windows インスタンスを記述する WMCO namespace に windows-instances という名前の ConfigMap を作成します。

    注記

    値を username=<username> としてフォーマットし、アドレスをキーとして使用し、設定マップの data セクションの各エントリーをフォーマットします。

    設定マップの例

    kind: ConfigMap
apiVersion: v1
metadata:
  name: windows-instances
  namespace: openshift-windows-machine-config-operator
data:
  10.1.42.1: |-
    1 
    
    username=Administrator
    2 
    
  instance.example.com: |-
    username=core

    1
    WMCO が SSH 経由でインスタンスに到達するために使用するアドレス (DNS 名または IPv4 アドレス)。このアドレスの DNS PTR レコードが存在する必要があります。組織が DHCP を使用して IP アドレスを割り当てる場合は、BYOH インスタンスで DNS 名を使用することを推奨します。そうでない場合は、インスタンスに新しい IP アドレスが割り当てられるたびに、windows-instances ConfigMap を更新する必要があります。
    2
    前提条件で作成した管理者ユーザーの名前。

9.2. BYOH Windows インスタンスの削除
リンクのコピー

設定マップでインスタンスのエントリーを削除して、クラスターに割り当てられた BYOH インスタンスを削除できます。インスタンスを削除すると、クラスターに追加する前にそのインスタンスがその状態に戻ります。ログおよびコンテナーランタイムアーティファクトは、これらのインスタンスには追加されません。

インスタンスを正常に削除するには、WMCO に提供される現在のプライベートキーを使用してアクセスできる必要があります。たとえば、直前の例から 10.1.42.1 インスタンスを削除するには、設定マップを以下に変更します。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: windows-instances
  namespace: openshift-windows-machine-config-operator
data:
  instance.example.com: |-
    username=core

windows-instances を削除すると、ノードとして追加されるすべての Windows インスタンスを分解する要求として表示されます。

第10章 Windows ノードの削除
リンクのコピー

ホスト Windows マシンを削除して、Windows ノードを削除できます。

10.1. 特定マシンの削除
リンクのコピー

特定のマシンを削除できます。

重要

クラスターがコントロールプレーンマシンセットを使用していない限り、コントロールプレーンマシンを削除しないでください。

前提条件

  • OpenShift Container Platform クラスターをインストールします。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin パーミッションを持つユーザーとして、oc にログインする。

手順

  1. 次のコマンドを実行して、クラスター内のマシンを表示します。 

    $ oc get machine -n openshift-machine-api

    コマンド出力には、<clusterid>-<role>-<cloud_region> 形式のマシンのリストが含まれます。

  2. 削除するマシンを特定します。

  3. 次のコマンドを実行してマシンを削除します。 

    $ oc delete machine <machine> -n openshift-machine-api
    重要

    デフォルトでは、マシンコントローラーは、成功するまでマシンによってサポートされるノードを drain しようとします。場合によっては、drain 操作が成功しない可能性があります。たとえば、Pod Disruption Budget が間違っている場合などです。drain 操作が失敗した場合、マシンコントローラーはマシンの削除を続行できません。

    特定のマシンの machine.openshift.io/exclude-node-draining にアノテーションを付けると、ノードの drain を省略できます。

    削除するマシンがマシンセットに属している場合は、指定された数のレプリカを満たす新しいマシンがすぐに作成されます。

第11章 Windows コンテナーワークロードの無効化
リンクのコピー

Windows コンテナーワークロードを実行する機能を無効にするには、Windows Machine Config Operator (WMCO) をアンインストールし、WMCO のインストール時にデフォルトで追加された namespace を削除します。

11.1. Windows Machine Config Operator のアンインストール
リンクのコピー

クラスターから Windows Machine Config Operator (WMCO) をアンインストールできます。

前提条件

  • Windows ワークロードをホストする Windows Machine オブジェクトを削除します。

手順

  1. Operators → OperatorHub ページから、Filter by keyword ボックスを使用して、Red Hat Windows Machine Config Operator を検索します。
  2. Red Hat Windows Machine Config Operator タイルをクリックします。Operator タイルはこれがインストールされていることを示します。
  3. Windows Machine Config Operator 記述子ページで、Uninstall をクリックします。

11.2. Windows Machine Config Operator namespace の削除
リンクのコピー

デフォルトで Windows Machine Config Operator (WMCO) 用に生成された namespace を削除できます。

前提条件

  • WMCO がクラスターから削除される。

手順

  1. openshift-windows-machine-config-operator namespace で作成されたすべての Windows ワークロードを削除します。 

    $ oc delete --all pods --namespace=openshift-windows-machine-config-operator

  2. openshift-windows-machine-config-operator namespace のすべての Pod が削除されているか、終了状態を報告していることを確認します。 

    $ oc get pods --namespace openshift-windows-machine-config-operator

  3. openshift-windows-machine-config-operator namespace を削除します。 

    $ oc delete namespace openshift-windows-machine-config-operator

Legal Notice
リンクのコピー

Copyright © Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of the OpenJS Foundation.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る