View a markdown version of this page

異種ワークロードの実行 - Amazon EKS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

異種ワークロードの実行

Kubernetes は、同じクラスターに Linux ノードと Windows ノードを混在させることができる異種クラスターをサポートしています。そのクラスター内では、Linux で実行される Pod と Windows で実行される Pod を混在させることができます。同じクラスターで複数のバージョンの Windows を実行することもできます。ただし、この決定を行う際に考慮する必要があるいくつかの要因 (以下で説明) があります。

ノードへの PODs の割り当てのベストプラクティス

Linux および Windows ワークロードをそれぞれの OS 固有のノードに保持するには、ノードセレクタとテイント/許容範囲の組み合わせを使用する必要があります。異種環境でワークロードをスケジュールする主な目標は、既存の Linux ワークロードとの互換性が損なわれないようにすることです。

OS 固有のワークロードを適切なコンテナホストに配置する

ユーザーは、nodeSelectors を使用して Windows コンテナを適切なホストでスケジュールできます。現在、すべての Kubernetes ノードには次のデフォルトラベルがあります。

kubernetes.io/os = [windows|linux] kubernetes.io/arch = [amd64|arm64|...]

Pod 仕様に のような nodeSelector が含まれていない場合"kubernetes.io/os": windows、Pod は任意のホスト、Windows、Linux でスケジュールできます。Windows コンテナは Windows でのみ実行でき、Linux コンテナは Linux でのみ実行できるため、これは問題になる可能性があります。

エンタープライズ環境では、Linux コンテナの既存のデプロイが多数あることも、Helm チャートなどのoff-the-shelf設定のエコシステムがあることも珍しくありません。このような状況では、デプロイの nodeSelectors を変更するのをためらうことがあります。代わりに、テイントを使用します。

例: --register-with-taints='os=windows:NoSchedule'

EKS を使用している場合、eksctl は clusterConfig を通じてテイントを適用する方法を提供します。

NodeGroups: - name: windows-ng amiFamily: WindowsServer2022FullContainer ... labels: nodeclass: windows2022 taints: os: "windows:NoSchedule"

すべての Windows ノードにテイントを追加すると、スケジューラはテイントを許容しない限り、それらのノードでポッドをスケジュールしません。ポッドマニフェストの例:

nodeSelector: kubernetes.io/os: windows tolerations: - key: "os" operator: "Equal" value: "windows" effect: "NoSchedule"

同じクラスター内の複数の Windows ビルドの処理

各ポッドで使用される Windows コンテナベースイメージは、ノードと同じカーネルビルドバージョンと一致する必要があります。同じクラスターで複数の Windows Server ビルドを使用する場合は、追加のノードラベル、nodeSelectors を設定するか、Windows-build というラベルを活用する必要があります。

Kubernetes 1.17 は、 という新しいラベルを自動的に追加node.kubernetes.io/windows-buildし、同じクラスター内の複数の Windows ビルドの管理を簡素化します。古いバージョンを実行している場合は、このラベルを手動で Windows ノードに追加することをお勧めします。

このラベルには、互換性のために一致する必要がある Windows メジャー、マイナー、ビルド番号が反映されています。以下は、Windows Server の各バージョンで現在使用されている値です。

Windows Server は、プライマリリリースチャネルとして長期サービスチャネル (LTSC) に移行していることに注意してください。Windows Server 半期チャネル (SAC) は 2022 年 8 月 9 日に廃止されました。Windows Server の今後の SAC リリースはありません。

[Product Name] (製品名) ビルド番号 (複数可)

サーバーフル 2022 LTSC

10.0.20348

サーバーコア 2019 LTSC

10.0.17763

次のコマンドを使用して OS ビルドバージョンを確認できます。

kubectl get nodes -o wide

KERNEL-VERSION 出力は Windows OS ビルドバージョンと一致します。

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME ip-10-10-2-235.ec2.internal Ready <none> 23m v1.24.7-eks-fb459a0 10.10.2.235 3.236.30.157 Windows Server 2022 Datacenter 10.0.20348.1607 containerd://1.6.6 ip-10-10-31-27.ec2.internal Ready <none> 23m v1.24.7-eks-fb459a0 10.10.31.27 44.204.218.24 Windows Server 2019 Datacenter 10.0.17763.4131 containerd://1.6.6 ip-10-10-7-54.ec2.internal Ready <none> 31m v1.24.11-eks-a59e1f0 10.10.7.54 3.227.8.172 Amazon Linux 2 5.10.173-154.642.amzn2.x86_64 containerd://1.6.19

以下の例では、異なる Windows ノードグループ OS バージョンを実行するときに正しい Windows ビルドバージョンと一致するように、追加の nodeSelector をポッドマニフェストに適用します。

nodeSelector: kubernetes.io/os: windows node.kubernetes.io/windows-build: '10.0.20348' tolerations: - key: "os" operator: "Equal" value: "windows" effect: "NoSchedule"

RuntimeClass を使用して Pod マニフェストの NodeSelector と許容範囲を簡素化する

RuntimeClass を使用して、テイントと許容範囲を使用するプロセスを簡素化することもできます。これは、これらのテイントと許容値をカプセル化するために使用する RuntimeClass オブジェクトを作成することで実現できます。

次のマニフェストを実行して RuntimeClass を作成します。

apiVersion: node.k8s.io/v1beta1 kind: RuntimeClass metadata: name: windows-2022 handler: 'docker' scheduling: nodeSelector: kubernetes.io/os: 'windows' kubernetes.io/arch: 'amd64' node.kubernetes.io/windows-build: '10.0.20348' tolerations: - effect: NoSchedule key: os operator: Equal value: "windows"

Runtimeclass が作成されたら、 を Pod マニフェストの仕様として使用して割り当てます。

apiVersion: apps/v1 kind: Deployment metadata: name: iis-2022 labels: app: iis-2022 spec: replicas: 1 template: metadata: name: iis-2022 labels: app: iis-2022 spec: runtimeClassName: windows-2022 containers: - name: iis

マネージド型ノードグループのサポート

お客様が Windows アプリケーションをより合理化された方法で実行できるように、AWS は 2022 年 12 月 15 日に Windows コンテナの Amazon EKS Managed Node Group (MNG) サポートを開始しました。運用チームの調整に役立つように、Windows MNGsは Linux MNGs。Windows Server 2019 および 2022 の完全およびコア AMI (Amazon マシンイメージ) ファミリーバージョンがサポートされています。

Managed Node Groups (MNG) では、以下の AMI ファミリーがサポートされています。

AMI ファミリー

WINDOWS_CORE_2019_x86_64

WINDOWS_FULL_2019_x86_64

WINDOWS_CORE_2022_x86_64

WINDOWS_FULL_2022_x86_64

その他のドキュメント

AWS 公式ドキュメント: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html

Pod Networking (CNI) の仕組みを理解するには、次のリンクを確認してください。https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html

AWS Blog on Deploying Managed Node Group for Windows on EKS: https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/