翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Windows ネットワーキング ## Windows コンテナネットワークの概要 Windows コンテナは Linux コンテナとは根本的に異なります。Linux コンテナは、名前空間、ユニオンファイルシステム、cgroup などの Linux コンストラクトを使用します。Windows では、これらのコンストラクトは [Host Compute Service (HCS)](https://github.com/microsoft/hcsshim) によってコンテナから抽象化されます。HCS は、Windows でのコンテナ実装の上にある API レイヤーとして機能します。Windows コンテナは、ノードのネットワークトポロジを定義するホストネットワークサービス (HNS) も活用します。 ![Windows ネットワーク](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/windows/windows-networking.png) ネットワークの観点からは、HCS と HNS は Windows コンテナを仮想マシンのように機能させます。たとえば、各コンテナには、上の図に示すように Hyper-V 仮想スイッチ (vSwitch) に接続されている仮想ネットワークアダプタ (vNIC) があります。 ## IP アドレス管理 Amazon EKS のノードは、そのノードの Elastic Network Interface (ENI) を使用して AWS VPC ネットワークに接続します。現在、**Windows ワーカーノードごとに 1 つの ENI のみがサポートされています**。Windows ノードの IP アドレス管理は、コントロールプレーンで実行される [VPC Resource Controller](https://github.com/aws/amazon-vpc-resource-controller-k8s) によって実行されます。Windows ノードの IP アドレス管理のワークフローの詳細については、[こちら](https://github.com/aws/amazon-vpc-resource-controller-k8s#windows-ipv4-address-management)を参照してください。 Windows ワーカーノードがサポートできるポッドの数は、ノードのサイズと使用可能な IPv4 アドレスの数によって決まります。ノードで使用できる IPv4 アドレスは、次のように計算できます。 + デフォルトでは、セカンダリ IPv4 アドレスのみが ENI に割り当てられます。このような場合: ``` Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1 ``` 1 つの IPv4 アドレスが ENI のプライマリアドレスとして使用されるため、ポッドに割り当てることができないため、合計数から 1 つを減算します。 + [プレフィックス委任機能](prefix-mode-win.md)を有効にして、クラスターがポッド密度が高いように設定されている場合、 ``` Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16 ``` ここでは、セカンダリ IPv4 アドレスを割り当てる代わりに、VPC Resource Controller が割り当て`/28 prefixes`るため、使用可能な IPv4 アドレスの総数は 16 回増加します。 上記の式を使用して、次のように m5.large インスタンスに基づいてノード化された Windows ワーカーの最大ポッド数を計算できます。 + デフォルトでは、セカンダリ IP モードで実行する場合 - ``` 10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses ``` + を使用する場合 `prefix delegation`- ``` (10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses ``` インスタンスタイプがサポートできる IP アドレスの数の詳細については、[「インスタンスタイプごとのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)」を参照してください。 もう 1 つの重要な考慮事項は、ネットワークトラフィックの流れです。Windows では、100 を超えるサービスを持つノードでポートが枯渇するリスクがあります。この条件が発生すると、ノードは次のメッセージでエラーのスローを開始します。 **「ポリシーの作成に失敗しました: hcnCreateLoadBalancer failed in Win32: The specified port already exists**」 この問題に対処するために、Direct Server Return (DSR) を活用します。DSR は、非対称ネットワーク負荷分散の実装です。つまり、リクエストトラフィックとレスポンストラフィックは異なるネットワークパスを使用します。この機能は、ポッド間の通信を高速化し、ポートが枯渇するリスクを軽減します。したがって、Windows ノードで DSR を有効にすることをお勧めします。 Windows Server SAC EKS 最適化 AMIs。Windows Server 2019 LTSC EKS Optimized AMIs の場合、以下のスクリプトを使用し、`eksctl`nodeGroup で Windows Server 2019 Full または Core を amiFamily として使用して、インスタンスのプロビジョニング中に有効にする必要があります。詳細については、[「eksctl custom AMI](https://eksctl.io/usage/custom-ami-support/)」を参照してください。 ``` nodeGroups: - name: windows-ng instanceType: c5.xlarge minSize: 1 volumeSize: 50 amiFamily: WindowsServer2019CoreContainer ssh: allow: false ``` Windows Server 2019 以降で DSR を使用するには、インスタンスの起動時に次の [https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services) フラグを指定する必要があります。これを行うには、[セルフマネージド型ノードグループの起動テンプレート](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html)に関連付けられたユーザーデータスクリプトを調整します。 ``` [string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS" [string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1' [string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName" (Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile & $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://" -Base64ClusterCA "" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1 ``` DSR の有効化は、[Microsoft Networking ブログ](https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710)と [AWS Lab の Windows コンテナ](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module1-eks/lab3-handling-mixed-clusters)の指示に従って検証できます。 ![dsr](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/windows/dsr.png) サブネットで使用可能な IPv4 アドレスを保持し、無駄を最小限に抑えることが重要な場合は、Windows のプレフィックスモード [- 避けるタイミングで説明されているように、プレフィックス委任モード](prefix-mode-win.md#windows-prefix-avoid)を使用しないことをお勧めします。引き続きプレフィックス委任を使用する場合は、サブネットの IPv4 アドレス使用率を最適化する手順を実行できます。IPv4 アドレスのリクエストと割り当てプロセスを微調整する方法の詳細については、[「プレフィックス委任のパラメータの設定](prefix-mode-win.md#windows-network-conserve)」を参照してください。これらの設定を調整すると、IPv4 アドレスの節約とプレフィックス委任によるポッド密度の利点のバランスを取ることができます。 セカンダリ IPv4 アドレスを割り当てるというデフォルト設定を使用する場合、現在、VPC Resource Controller が IPv4 アドレスをリクエストして割り当てる方法を操作するためのサポートされている設定はありません。具体的には、 `minimum-ip-target`と `warm-ip-target`はプレフィックス委任モードでのみサポートされています。また、セカンダリ IP モードでは、インターフェイスで使用可能な IP アドレスに応じて、VPC リソースコントローラーは通常、ポッドの起動時間を短縮するためにウォーム IP を維持するために、ユーザーに代わってノードに 3 つの未使用の IPv4 IPsます。未使用のウォーム IP アドレスの IP 無駄を最小限に抑える場合は、ENI の IP アドレス容量をできるだけ多く使用できるように、特定の Windows ノードでより多くのポッドをスケジュールすることを目指します。より明示的には、ENI 上のすべての IPs アドレスがノードと実行中のポッドで既に使用されている場合、ウォーム未使用 IP を避けることができます。サブネット内の IP アドレスの可用性に関する制約を解決するためのもう 1 つの回避策は、[サブネットサイズを増やす](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html)か、Windows ノードを独自の専用サブネットに分離することです (複数可）。 さらに、現時点では IPv6 は Windows ノードではサポートされていないことに注意してください。 ## コンテナネットワークインターフェイス (CNI) オプション AWSVPC CNI は、Windows および Linux ワーカーノード用の事実上の CNI プラグインです。AWSVPC CNI は多くのお客様のニーズを満たす一方で、IP の枯渇を避けるためにオーバーレイネットワークなどの代替案を検討する必要がある場合があります。このような場合、Calico CNI を AWSVPC CNI の代わりに使用できます。[Project Calico](https://www.projectcalico.org/) は、[Tigera](https://www.tigera.io/) によって開発されたオープンソースソフトウェアです。このソフトウェアには、EKS で動作する CNI が含まれています。Calico CNI を EKS にインストールする手順は、[Project Calico EKS のインストール](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks)ページにあります。 ## ネットワークポリシー ベストプラクティスとして、Kubernetes クラスター上のポッド間のオープン通信のデフォルトモードから、ネットワークポリシーに基づくアクセスの制限に変更します。オープンソースの [Project Calico](https://www.tigera.io/tigera-products/calico/) は、Linux ノードと Windows ノードの両方で動作するネットワークポリシーを強力にサポートしています。この機能は分離されており、Calico CNI の使用には依存しません。したがって、Calico をインストールし、ネットワークポリシー管理に使用することをお勧めします。 Calico を EKS にインストールする手順については、[Amazon EKS の「Calico のインストール](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)」ページを参照してください。 さらに、「Amazon [EKS Best Practices Guide for Security - Network Section](https://docs.aws.amazon.com/eks/latest/best-practices/network-security.html)」に記載されているアドバイスは、Windows ワーカーノードを持つ EKS クラスターにも等しく適用されますが、現時点では「Security Groups for Pods」などの一部の機能は Windows ではサポートされていません。