この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

WindowsクラスターでKubernetesを起動する

カスタムクラスターのプロビジョニング時に、RancherはRKE2を使用して既存のノードにKubernetesをインストールします。

RancherでプロビジョニングされたWindowsクラスターには、LinuxノードとWindowsノードの両方が含まれている必要があります。KubernetesのコントロールプレーンはLinuxノードでのみ実行でき、Windowsノードはワーカー役割のみを持つことができます。Windowsノードはワークロードのデプロイにのみ使用できます。

WindowsでサポートされているKubernetes機能の概要については、 WindowsでKubernetesを使用するためのサポート機能と制限に関するKubernetesのドキュメントまたは KubernetesでWindowsコンテナをスケジュールするためのガイドを参照してください。

SUSE® Rancher Prime: RKE2 Windowsクラスターの機能

以下に、Windowsクラスターのプロビジョニングに関する主なRKE2機能を示します：

  • containerdで動作するRKE2を利用したWindowsコンテナ

  • Rancher UIから直接Windows RKE2カスタムクラスターのプロビジョニングが追加されました

  • Windows RKE2カスタムクラスター用のCalicoおよびFlannel CNI

  • Windows ServerのSACリリース（2004および20H2）が技術プレビューに含まれています

Rancherは、デフォルトでWindowsワークロードポッドをWindowsおよびLinuxワーカーノードの両方にデプロイできるようにします。RKE2で混合クラスターを作成する際は、ポッドを互換性のあるWindowsノードに配置するようにチャート内の`nodeSelector`を編集する必要があります。ポッドをノードに割り当てる方法についての詳細は、 Kubernetesのドキュメント`nodeSelector`を参照してください。

一般要件

Windowsノードの一般的なネットワークおよびオペレーティングシステム要件は、他のRancherインストールと同じです。

OS要件

Windows ServerおよびWindowsコンテナに対する当社のサポートは、LTSC（長期サービスチャネル）およびSAC（半期チャネル）のMicrosoft公式ライフサイクルに一致します。

Windows Serverのサポートライフサイクルの日付については、 Microsoft Documentation.を参照してください。

Kubernetesバージョン

Kubernetesコンポーネントのバージョンに関する詳細については、 RKE2バージョンのサポートマトリックスを参照してください。

ノード要件

クラスター内のホストは、少なくとも次の要件を満たす必要があります：

  • 2コアCPU

  • 5 GBのメモリ

  • 50 GBのディスク容量

ノードがこれらの要件を満たさない場合、Rancherはノードをプロビジョニングしません。

ネットワーク要件

新しいクラスターをプロビジョニングする前に、受信ネットワークトラフィックを受け入れるデバイスにRancherをすでにインストールしていることを確認してください。これは、クラスターのノードがRancherと通信するために必要です。まだRancherをインストールしていない場合は、このガイドを進める前にインストールドキュメントを参照してください。

Rancherは、CalicoとFlannelをネットワークプロバイダーとして使用してWindowsをサポートしています。

AWSの仮想プライベートクラウド用にDHCPオプションセットを構成している場合、`domain-name`オプションフィールドには、1つのドメイン名のみを指定できます。DHCPオプションに関する ドキュメント:によると、

一部のLinux配布パッケージは、スペースで区切られた複数のドメイン名を受け入れます。ただし、他のLinux配布パッケージやWindowsは、その値を単一のドメインとして扱い、予期しない動作を引き起こします。DHCPオプションセットが複数のオペレーティングシステムを持つインスタンスを持つVPCに関連付けられている場合は、1つのドメイン名のみを指定してください。

ESXi 6.7u2以上のVMware vSphere上のRancher

ESXi 6.7u2以降のVMware vSphere上でRancherを使用している場合、Red Hat Enterprise Linux 8.3、CentOS 8.3、またはSUSE Enterprise Linux 15 SP2以降を使用している場合は、vmxnet3`仮想ネットワークアダプタのハードウェアオフロード機能を無効にする必要があります。これを行わないと、異なるクラスターのノード間のポッド間のすべてのネットワーク接続がタイムアウトエラーで失敗します。WindowsポッドからLinuxノード上で実行されている重要なサービス、例えばCoreDNSへのすべての接続が失敗します。外部接続が失敗する可能性もあります。この問題は、Linux配布パッケージが`vmxnet3`でハードウェアオフロード機能を有効にし、ゲストオーバーレイトラフィックのパケットを破棄する`vmxnet3`ハードウェアオフロード機能のバグが原因です。この問題に対処するためには、`vmxnet3`ハードウェアオフロード機能を無効にする必要があります。この設定は再起動後に持続しないため、毎回のブート時に無効にする必要があります。推奨される対策は、ブート時に/etc/systemd/system/disable_hw_offloading.service`ハードウェアオフロード機能を無効にするsystemdユニットファイルを`vmxnet3`に作成することです。vmxnet3`ハードウェアオフロード機能を無効にするサンプルのsystemdユニットファイルは以下の通りです。<VM network interface>`はホスト`vmxnet3`ネットワークインタフェースに合わせてカスタマイズする必要があります。例えば、`ens192`のように：

[Unit]
Description=Disable vmxnet3 hardware offloading feature

[Service]
Type=oneshot
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-segmentation off
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-csum-segmentation off
StandardOutput=journal

[Install]
WantedBy=multi-user.target

次に、systemdユニットファイルに適切な権限を設定します。

chmod 0644 /etc/systemd/system/disable_hw_offloading.service

最後に、systemdサービスを有効にします。

systemctl enable disable_hw_offloading.service

アーキテクチャ要件

Kubernetesクラスター管理ノード（etcd`および`controlplane）はLinuxノード上で実行する必要があります。

ワークロードがデプロイされる`worker`ノードは通常Windowsノードですが、Rancherクラスターエージェント、DNS、メトリクスサーバー、Ingress関連のコンテナを実行するためには、少なくとも1つの`worker`ノードがLinux上で実行されている必要があります。

推奨アーキテクチャ

以下の表に示す最小三ノードアーキテクチャを推奨しますが、冗長性のためにクラスターをスケールアップする場合は、LinuxおよびWindowsワーカーを追加できます。

ノード オペレーティングシステム Kubernetesクラスターの役割 目的

ノード1

Linux（Ubuntu Server 18.04推奨）

コントロールプレーン、etcd、ワーカー

Kubernetesクラスターを管理する

ノード2

Linux（Ubuntu Server 18.04推奨）

ワーカー

クラスターのためにRancherクラスターエージェント、メトリクスサーバー、DNS、Ingressをサポートする

ノード3

Windows（Windows Serverコアバージョン1809以上が必要、2022バージョン推奨）

ワーカー

Windowsコンテナを実行する

コンテナ要件

Windowsでは、コンテナはデプロイされるWindows Serverの同じバージョンで構築される必要があります。したがって、コンテナはWindows Serverコアバージョン1809以上で構築される必要があります。以前のWindows Serverコアバージョン用に構築された既存のコンテナは、Windows Serverコアバージョン1809以上で再構築する必要があります。

クラウドプロバイダー特有の要件

クラスターにKubernetesクラウドプロバイダーを設定する場合、追加の手順が必要です。クラウドプロバイダーの機能を活用したい場合、たとえば、ストレージ、ロードバランサー、またはクラスターの他のインフラストラクチャを自動的にプロビジョニングするために、クラウドプロバイダーを設定することをお勧めします。前提条件を満たすノードのクラウドプロバイダーのクラスターを構成する方法については、このページを参照してください。

GCE（Google Compute Engine）クラウドプロバイダーを使用している場合、次のことを行う必要があります：

  • `cluster.yml`でGCEクラウドプロバイダーを有効にし、これらの手順に従ってください。

  • Rancherでクラスターをプロビジョニングする際は、Rancher UIでクラウドプロバイダーとして*カスタムクラウドプロバイダー*を選択してください。

チュートリアル:Windowsサポートを持つクラスターの作成方法

このチュートリアルでは、推奨アーキテクチャの3つのノードを持つRancherプロビジョニングクラスターの作成方法を説明します。

Windowsノードとコンテナをサポートするクラスターを設定するには、以下のタスクを完了する必要があります。

1.ホストをプロビジョニングする

Windowsサポートを持つ既存のノードでクラスターのプロビジョニングを開始するには、ホストを準備してください。

ホストは次のようになります：

  • クラウドホスト型VM

  • 仮想化クラスターからのVM

  • ベアメタルサーバー

3つのノードをプロビジョニングします：

  • Kubernetesコントロールプレーンを管理し、`etcd`のデータを保存し、必要に応じてワーカーノードとしても利用可能な1つのLinuxノード

  • 別のワーカーノードとなる2つ目のLinuxノード

  • Windowsコンテナをワーカーノードとして実行するWindowsノード

ノード オペレーティングシステム

ノード1

Linux（Ubuntu Server 18.04推奨）

ノード2

Linux（Ubuntu Server 18.04推奨）

ノード3

Windows（Windows Serverコアバージョン1809以上が必要、バージョン2022推奨）

ノードが*クラウドプロバイダー*によってホストされており、ロードバランサーや永続ストレージデバイスなどの自動化サポートを希望する場合、ノードには追加の設定要件があります。詳細については、クラウドプロバイダーの選択を参照してください。

2.既存のノードにクラスターを作成する

既存のノードにWindowsクラスターを作成するための手順は、一般的なカスタムクラスターを作成するための手順に非常に似ており、いくつかのWindows特有の要件があります。

  1. 左上隅で、*☰ > クラスター管理*をクリックします。

  2. *クラスター*ページで、*作成*をクリックします。

  3. *カスタム*をクリックします。

  4. *クラスター名*フィールドにクラスターの名前を入力します。

  5. *Kubernetesバージョン*のドロップダウンメニューから、サポートされているKubernetesバージョンを選択します。

  6. *コンテナネットワーク*フィールドで、*Calico*または*Flannel*のいずれかを選択します。

  7. ［作成］をクリックします。

3.クラスターにノードを追加する

このセクションでは、Linuxノードとワーカーノードをクラスターに登録する方法について説明します。各ノードでコマンドを実行し、rancher-system-agentをインストールしてRancherが各ノードを管理できるようにします。

Linuxマスターノードを追加する

このセクションでは、Rancher UIでフォームに記入して、LinuxマスターノードにRancherエージェントをインストールするためのカスタムコマンドを取得します。その後、コマンドをコピーしてLinuxマスターノードで実行し、ノードをクラスターに登録します。

クラスター内の最初のノードは、*コントロールプレーン*と*etcd*の両方の役割を持つLinuxホストである必要があります。このノードには、これらの両方の役割が有効でなければならず、Windowsホストを追加する前にこのノードをクラスターに追加する必要があります。

  1. クラスター作成後、*登録*タブに移動します。

  2. *ノードの役割*セクションの*ステップ1*で、3つの役割すべてを選択します。*etcd*と*コントロールプレーン*の役割のみを選択することもできますが、3つすべてを選択することをお勧めします。

  3. オプション:*詳細設定を表示*をクリックすると、IPアドレスの指定、ノードのホスト名の上書き、またはノードに ラベルや テイントを追加するなどの追加設定を構成できます。

  4. *ステップ2*の*登録*セクションで、画面に表示されたコマンドをクリップボードにコピーします。

  5. LinuxホストにSSH接続し、クリップボードにコピーしたコマンドを実行します。

結果:

クラスターが作成され、状態が*更新中*に割り当てられました。Rancherがクラスターを立ち上げています。

ノードが登録され、*マシン*タブに表示されるまでに数分かかる場合があります。

状態が*アクティブ*に変わると、クラスターにアクセスできるようになります。

Linuxワーカーノードを追加

このセクションでは、Linuxワーカーノードをクラスターに登録するためのコマンドを実行します。

クラスターの初期プロビジョニング後、クラスターには単一のLinuxホストのみがあります。次に、Linux`worker`ホストをもう1つ追加します。これは、クラスターの_Rancherクラスターエージェント_、メトリクスサーバー、DNS、および_Ingress_をサポートするために使用されます。

  1. クラスター作成後、*登録*タブに移動します。

  2. *ノードの役割*セクションの*ステップ1*で、*ワーカー*を選択します。

  3. オプション:*詳細設定を表示*をクリックすると、IPアドレスの指定、ノードのホスト名の上書き、またはノードに ラベルや テイントを追加するなどの追加設定を構成できます。

  4. *ステップ2*の*登録*セクションで、画面に表示されたコマンドをクリップボードにコピーします。

  5. LinuxホストにSSH接続し、クリップボードにコピーしたコマンドを実行します。

結果:

*ワーカー*の役割がLinuxホストにインストールされ、ノードがRancherに登録されます。ノードがクラスターに登録されるまでに数分かかる場合があります。

Linuxワーカーノードのテイント

クラスターに追加された各Linuxワーカーには、以下のテイントが追加されます。このテイントをLinuxワーカーに追加することで、Windowsクラスターに追加されたワークロードは自動的にWindowsワーカーにスケジュールされます。特にLinuxワーカーにワークロードをスケジュールしたい場合は、それらのワークロードに対してトレランスを追加する必要があります。

テイントキー テイント値 テイント効果

cattle.io/os

linux

NoSchedule

Windowsワーカーを追加する

このセクションでは、Windowsワーカーをクラスターに登録するためのコマンドを実行します。

Windowsワーカーを追加するための登録コマンドは、クラスターがLinux etcd、コントロールプレーン、およびワーカーで実行されているときにのみ表示されます。

  1. クラスター作成後、*登録*タブに移動します。

  2. *ノードの役割*セクションの*ステップ1*で、*ワーカー*を選択します。

  3. オプション:*詳細設定を表示*をクリックすると、IPアドレスの指定、ノードのホスト名の上書き、またはノードに ラベルや テイントを追加するなどの追加設定を構成できます。

  4. *ステップ2*の*登録*セクションで、画面に表示されたWindowsワーカー用のコマンドをクリップボードにコピーします。

  5. Microsoft Remote Desktopなどの好みのツールを使用して、Windowsホストにログインします。*PowerShellコンソール*でクリップボードにコピーしたコマンドを管理者として実行します。

  6. オプション:クラスターにさらにWindowsノードを追加したい場合は、これらの手順を繰り返してください。

結果:

*ワーカー*ロールがWindowsホストにインストールされ、ノードがRancherに登録されます。ノードがクラスターに登録されるまでに数分かかる場合があります。

これでWindows Kubernetesクラスターが構築されました。

オプションの次のステップ

クラスターを作成した後、Rancher UIを通じてアクセスできます。ベストプラクティスとして、クラスターにアクセスするためのこれらの代替方法を設定することをお勧めします：

  • kubectl CLIを使用してクラスターにアクセスする:これらの手順に従って、ワークステーションでkubectlを使用してクラスターにアクセスしてください。この場合、Rancherサーバーの認証プロキシを通じて認証され、その後Rancherがダウンストリームクラスターに接続します。この方法を使用すると、Rancher UIなしでクラスターを管理できます。

  • 認可されたクラスターエンドポイントを使用して、kubectl CLIでクラスターにアクセスします:これらの手順に従って、Rancherサーバーを介さずにkubectlでダウンストリームクラスターに直接アクセスします。Rancherに接続できない場合でもクラスターにアクセスできるように、この代替方法を設定することをお勧めします。

Azureにおけるストレージクラスの設定

ノードにAzure VMを使用している場合、クラスターのストレージクラスとして Azure filesを使用できます。詳しくは、このセクションを参照してください。