翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EKS 最適化 Windows AMI 管理
Windows Amazon EKS 最適化 AMI は Windows Server 2019 と Windows Server 2022 上に構築されています。Amazon EKS ノードのベースイメージとして機能するように構成されています。デフォルトでは、AMI には次のコンポーネントが含まれています。
+ [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)
+ [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
+ [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator)
+ [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)
+ [containerd](https://containerd.io/)
AWS Systems Manager Parameter Store API をクエリすることで、Amazon EKS 最適化 AMI の Amazon マシンイメージ (AMI) ID をプログラム的に取得できます。この API から提供されるパラメータにより、Amazon EKS 最適化 AMI ID を手動で検索する必要がなくなります。Systems Manager Parameter Store API の詳細については、[GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) を参照してください。ユーザーアカウントには、Amazon EKS 最適化 AMI メタデータを取得するための ssm:GetParameter IAM アクセス許可が必要です。
次の の例では、Windows Server 2019 LTSC Core 用の最新の Amazon EKS 最適化 AMI の AMI ID を取得します。AMI 名にリストされているバージョン番号は、準備されている対応する Kubernetes ビルドに関連しています。
```
aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-EKS_Optimized-1.21/image_id --region us-east-1 --query "Parameter.Value" --output text
```
出力の例:
```
ami-09770b3eec4552d4e
```
## 独自の Amazon EKS 最適化 Windows AMI の管理
本番環境への重要なステップは、Amazon EKS クラスター全体で同じ Amazon EKS 最適化 Windows AMI と kubelet バージョンを維持することです。
Amazon EKS クラスター全体で同じバージョンを使用すると、トラブルシューティングにかかる時間が短縮され、クラスターの一貫性が向上します。[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) は、Amazon EKS クラスターで使用するカスタム Amazon EKS 最適化 Windows AMIs の作成と維持に役立ちます。
Amazon EC2 Image Builder を使用して、Windows Server バージョン、AWS Windows Server AMI リリース日、OS ビルドバージョンのいずれかを選択します。ビルドコンポーネントのステップでは、既存の EKS 最適化 Windows アーティファクトと kubelet バージョンを選択できます。詳細については、https://docs.aws.amazon.com/eks/latest/userguide/eks-custom-ami-windows.html を参照してください。
**注:** ベースイメージを選択する前に、リリースチャネルの更新に関する重要な詳細については、[Windows Server のバージョンとライセンス](windows-licensing.md)のセクションを参照してください。
## カスタム EKS 最適化 AMIs の高速起動の設定
カスタム Windows Amazon EKS 最適化 AMI を使用する場合、高速起動機能を有効にすることで、Windows ワーカーノードの起動を最大 65% 高速化できます。この機能は、*Sysprep 専門分野*、*Windows Out of Box Experience (OOBE)* ステップ、および必要な再起動がすでに完了している事前プロビジョニングされたスナップショットのセットを維持します。その後、これらのスナップショットはその後の起動で使用され、ノードのスケールアウトまたは置き換えにかかる時間が短縮されます。高速起動は、EC2 コンソールまたは AWS CLI で*所有している* AMIs に対してのみ有効にでき、維持されているスナップショットの数は設定可能です。
**注:** Fast Launch は、Amazon が提供するデフォルトの EKS 最適化 AMI と互換性がありません。有効にする前に、上記のようにカスタム AMI を作成します。
詳細については、[AWS Windows AMIs - AMI を設定して起動を高速化してください](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-ami-version-history.html#win-ami-config-fast-launch)。
## カスタム AMIs での Windows ベースレイヤーのキャッシュ
Windows コンテナイメージは Linux コンテナイメージよりも大きくなっています。コンテナ化された .NET Framework ベースのアプリケーションを実行している場合、平均イメージサイズは約 8.24 GB です。ポッドのスケジューリング中、ポッドが実行中ステータスに達する前に、コンテナイメージを完全にプルしてディスクに抽出する必要があります。
このプロセス中、コンテナランタイム (コンテナ) はディスク内のコンテナイメージ全体をプルして抽出します。プルオペレーションは並列プロセスです。つまり、コンテナランタイムはコンテナイメージレイヤーを並列にプルします。対照的に、抽出オペレーションはシーケンシャルプロセスで行われ、I/O を大量に消費します。そのため、コンテナイメージが完全に抽出され、コンテナランタイム (コンテナ) で使用できるようになるまでに 8 分以上かかる場合があり、その結果、ポッドの起動に数分かかる場合があります。
**「Windows Server とコンテナのパッチ適用**」トピックで説明したように、EKS でカスタム AMI を構築するオプションがあります。AMI の準備中に、EC2 Image Builder コンポーネントを追加して、必要なすべての Windows コンテナイメージをローカルにプルし、AMI を生成できます。この戦略により、ポッドが**実行中**のステータスに達する時間が大幅に短縮されます。
Amazon EC2 Image Builder で、必要なイメージをダウンロードして Image recipe にアタッチする[コンポーネント](https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-components.html)を作成します。次の の例では、ECR リポジトリから特定のイメージをプルします。
```
name: ContainerdPull
description: This component pulls the necessary containers images for a cache strategy.
schemaVersion: 1.0
phases:
- name: build
steps:
- name: containerdpull
action: ExecutePowerShell
inputs:
commands:
- Set-ExecutionPolicy Unrestricted -Force
- (Get-ECRLoginCommand).Password | docker login --username AWS --password-stdin 111000111000.dkr.ecr.us-east-1.amazonaws.com
- ctr image pull mcr.microsoft.com/dotnet/framework/aspnet:latest
- ctr image pull 111000111000.dkr.ecr.us-east-1.amazonaws.com/myappcontainerimage:latest
```
次のコンポーネントが正常に動作することを確認するには、EC2 Image Builder (EC2InstanceProfileForImageBuilder) で使用される IAM ロールにポリシーがアタッチされているかどうかを確認します。
## ブログ記事
次のブログ記事では、カスタム Amazon EKS Windows AMIs のキャッシュ戦略を実装する方法を段階的に説明します。
[EC2 Image Builder とイメージキャッシュ戦略を使用して Windows コンテナの起動時間を短縮する](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)