この記事はFIXER Advent Calendar 2019 (https://adventar.org/calendars/4579) 7日目の記事です。
前日は 前川 さんの「突撃！隣のキーボード　FIXER　2019」 です。
キーボードは人の好みが分かれるので面白いですね。

2019年3月25日にkubernetes 1.14リリースされ、Windowsコンテナが正式にサポートされました。現在では、2019年9月18日にkubernetes 1.16 がリリースされています。結局、KubernetesのWindowsサポートってどこまで何ができているのかがよく分からなくなるので、調べることにしました。

何が適切なのかちょと迷ったのですが、Kubernetesのサイトのはじめに>Windows in kubernetesに「Intro to Windows support in Kubernetes」という記事があったので訳してみました。Windows containers in KubernetesとSupported Functionality and Limitationsの部分です。
ちゃんと公式ドキュメントを読むのは大切ですね。
※結構、雑な訳です。随時読み返して気になるところは修正するする予定です。

Intro to Windows support in Kubernetes

Windows containers in Kubernetes

WindowsコンテナをオーケストレーティングするためにはLinuxクラスタの中にWindowsノードを追加する。KubernetesのPodに配置したWindowsコンテナはLinuxベースのコンテナと同じように利用できる。Windowsコンテナを実行するには、マルチOSのKubernetesクラスタを構成する必要があり、control planeノードはLinuxで稼働され、workerノードは利用する用途に合わせてWindowsやLinuxで構成する。Windows Server 2019は、サポートされている唯一のWindowsOSであり、WindowsでKubernetesノード（kubelet、コンテナランタイム、kube-proxyを含む）を稼働できる。

・マスターコンポーネントを含むKubernetes control planeは、必ずLinuxで起動する必要があるため、WindowsだけでKubernetesクラスタを構成することはできない。
・このドキュメントにおいて、Windowsコンテナはプロセス分離を対象とする。WindowsコンテナのHyper-V 分離は今後リリースが計画されている。

Supported Functionality and Limitations

Supported Functionality

APIやkubectlから、WindowsコンテナをLinuxコンテナと同じように操作することができる。ただし、主要な機能にいくつかの違いがあり、limitationのセクションで記載する。

サポートされているWindowsのOSバージョン

・Windows OSとアプリケーションの更新について
すべてのWindowsユーザーがアプリケーションのOSを頻繁に更新するとは限らない。アプリケーションの更新は、クラスターへの新しいノードの追加もしくはコンテナの更新を必要とする。Kubernetesで実行されているコンテナのオペレーティングシステムをアップグレードするための、新しいOSバージョンのサポートを追加するさいのガイダンスと段階的な手順を提供する。このガイダンスには、アプリケーションとクラスタノードを更新するための推奨更新手順が含まれている。 Windowノードは、Linuxノードと同じでKubernetesのバージョンスキューサポートポリシーが提供される。

・Windowsライセンスについて
WindowsサーバのホストOSには、Windowsサーバライセンスが適用される 　
Windowsコンテナイメージには、Windowsコンテナライセンスが適用される

・ホストOSとWindowsコンテナの互換性について
プロセス分離のWindowsコンテナは、厳格な互換ルールがある。つまり、ホストOSとコンテナのベースイメージOSバージョンが一致していなければならない。Hyper-V分離がKubernetesでサポートされるとこの制限や互換性ルールは変更される予定。

主要なKubernetesの機能はWindowsでもLinuxでも同じように動作する。主要なワークロードを可能にしている要素とWindowsでどのように適用されるか解説する

PodはKubernetesの基本的な構成要素であり、小さく、シンプルな構成やデプロイのためのKubernetesのオブジェクトモデルである。同じPodにWindowsとLinuxのコンテナを含めてデプロイすることはできない。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャーで構成されており同一ノード内に配置されるためである。

WindowsでサポートされるPod機能、プロパティ、イベントは以下の通り。
・プロセス分離、データ共有を持つ、単一もしくは複数のコンテナをPodに持つことができる
・Pod status fields
・Readiness and Liveness probes 　
・postStart & preStop container lifecycle events　
・ConfigMap, Secrets: as environment variables or volumes　
・emptyDir
・Named pipe host mounts
・resource limits

Kubernetesコントローラは、Podsがあるべき状態になっていることを制御する。
以下がWindowsコンテナでサポートされる。
・ReplicaSet　
・Replication Controller
・Deployments　
・StatefulSets　
・DaemonSet
・Job
・CronJob

Kubernetesサービスは、Podの論理セットとそれらにアクセスするためのポリシー（マイクロサービスとも呼ばれる）を定義するアブストラクト。OS間の接続を定義できる（You can use services for cross-operating system connectivity.）

Windowsでは、以下のタイプ、プロパティ、機能を利用できる
・Service Environment variables
・NodePort　
・ClusterIP　
・LoadBalancer
・ExternalName
・Headless services

Pods、Controllers、ServicesはKubernetesでWindowsワークロードを利用するための重要な要素です。
しかし、これだけではダイナミックなクラウドネイティブ環境においてWindowsワークロードを適切にライフサイクルを管理するには十分でないため、以下の機能が追加されている。
・Pod and container metrics
・Horizontal Pod Autoscaler support
・kubectl Exec　
・Resource Quotas
・Scheduler preemption

KubernetesのWindows Server 2019/1809ノードは、Docker EE-basic 18.09が必要となる。これは、kubeletに含まれるdockershimで動作する。Kubernetes以降のバージョンでは、CRI-ContainerDなどの追加のランタイムがサポートされる場合がある。

Kubernetesボリュームは、データの永続性やPodのデータの共有の要件を持つ複雑なアプリケーションをkubernetes上に展開できる。特定のストレージバックエンドやプロトコルに関連付けられた永続的なボリュームの管理には、データを保持する必要がある。ボリュームのプロビジョニングやプロビジョニング解除/サイズ変更、Kubernetesノードのボリュームの接続/切断、Pod内のコンテナに対してマウントやマウント解除などのアクションが含まれています。これらの特定のストレージバックエンドやプロトコルのためのボリューム管理機能は、Kubernetes volume pluginとして提供される。

以下がwindowsでサポートされている、Kubernetes volume pluginです。

In-tree Volume Pluginsは、コアKubernetesの一部として出荷されるため、追加のスクリプトのインストールやコンテナ化された他のプラグインコンポーネントをデプロイする必要はない。これらのプラグインは、kubernetesノードからのプロビジョニング/プロビジョニング解除、ストレージバックエンドのボリュームのリサイズ、アタッチ/アタッチ解除、Pod内のコンテナからマウント/マウント解除を処理する。
以下が、Windows Nodeでサポートされているin-tree Volume Pluginsです。
・awsElasticBlockStore
・azureDisk
・azureFile
・gcePersistendDisk
・vsphereVolume

FlexVolume Pluginsは、コアkubernetesとは別にホストに直接展開する必要がある。FlexVolume Pluginsは、Kubernetesノードに対して、ボリュームのアタッチ/アタッチ解除、Pod内のコンテナへマウント/マウント解除の操作ができる。FlexVolume Pluginsを利用した、永続性ボリュームのプロビジョニングやプロビジョニング解除は、FlexVolume Pluginsとは切り離された外部のプロビジョニングツールを通して処理される。　　
FlexVolume PluginsはWindowsノードでPowershellスクリプトからデプロイすることでサポートされる。
・SMB
・iSCSI

CSI Pluginsは、コンテナイメージとして配布され、DaemonSetsやStatefulSetsなどのKubernetesコンストラクトを使用して展開されるツリー外スクリプトおよびバイナリとして出荷されます。CISプラグインはkubernetesのさまざまなボリューム管理を処理する。ボリュームのプロビジョニング/プロビジョニング解除/リサイズ、kubernetesノードのボリュームのアタッチ/アタッチ解除、Pod内のコンテナのボリュームのマウント/マウント解除、スナップショットやクローニングを利用した永続性データのバックアップやリストア。CSIプラグインはノードプラグイン(DaemonSetとして個々のノード上で実行される)やコントローラープラグインとして構成される 。
CSI Plugins（特に、ブロックデバイスとして、または共有ファイルシステムを介して公開される永続的なボリュームに関連するもの）は、ディスクデバイスのスキャン、ファイルシステムのマウントなどの、様々な特権操作を実行する必要があり、これらの操作は、ホストOSごとに異なる。
・Linuxワーカーノードの場合、通常はコンテナ化されてたCISノードプラグインが特権コンテナとして展開される
・Windowsワーカーノードの場合、コンテナ化されたCSIノードプラグインの特権操作は、個々のWindowsノードに前もってコミュニティが管理しているcsi-proxyインストールする必要のある。詳細については、展開するCSIプラグインの展開ガイドを参照する

Windowsコンテナのネットワーク機能は、CNIプラグインを通して提供される。Windowsコンテナは、仮想マシンと同様のネットワーク機構で動作する。コンテナは、Hyper-Vの仮想スイッチ(vSwitch)と接続された仮想NIC(vNIC)を持つ。Host Network Service(HNS)とHost Compute Service(HCS)が、連携してコンテナの作成し、コンテナのvNICをネットワークに接続する。HCSはコンテナの管理を担当し、HNSはネットワークリソースの管理を担当する。
利用できるネットワークリソース一覧
・Virtual networks(including creation of vSwitches)
・Endpoints/vNICs
・Namespaces
・ Policies(Packet encapsulations, Load-balancing rules, ACLs, NAT'ing rules, etc)

以下のService Spec Typeをサポートする
・NodePort
・ClusterIP
・LoadBalancer
・ExternalName

Windowsは５つの異なるネットワークドライバー/モードをサポートする。
L2bridge, L2tunnel, Overlay, Transparent, NAT
WindowsおよびLinuxワーカーノードを持つクラスターを構成するためには、WindowsとLinuxの両方で互換性のあるネットワークソリューションが必要になる。
WindowsでサポートされているCNIをどのような時に利用するのかの推奨事項を以下にまとめる。

上記で説明した通り、Flannel CNI meta pluginは、VXLANネットワークバックエンド（alpha support ; delegates to win-overlay)、およびhost-gateway network backend（stable support; delegates to win-bridge）を介してWindowsでもサポートされる。このプラグインは、参照CNIプラグイン（win-overlay、win-bridge）のいずれかへの委任をサポートし、自動的にノードへサブネットリースを割り当て、およびHNSネットワーク作成のためにWindows上のFlannelデーモン（Flanneld）と連動する。このプラグインは、独自の構成ファイル（cni.conf）を読み取り、FlannelDが生成したsubnet.envファイルの環境変数と統合する。次に、ネットワーク配管の参照CNIプラグインの1つに委任し、ノードに割り当てられたサブネットを含む正しい構成をIPAMプラグイン（e.g. host-local）に送信する。

Node、Pod、ServiceObjectsに対して、以下のTCP/UDPのネットワークフローがサポートされる
・Pod -> Pod (IP)
・Pod -> Pod (Name)
・Pod -> Service (Cluster IP)
・Pod -> Service (PQDN, but only if there are no “.”)
・Pod -> Service (FQDN)
・Pod -> External (IP)
・Pod -> External (DNS)
・Node -> Pod
・Pod -> Node

Windowsでは以下のIPAMオプションがサポートされる
・Host-local
・HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set)
・Azure-vnet-ipam (for azure-cni only)

Limitations

Windowsは、Kubernetesアーキテクチャ、コンポーネントマトリックスの中で、ワーカーノードとしてのみサポートされる。つまり、Kubernetesクラスターには、常にLinuxのマスターノード、0個以上のLinuxワーカーノード、および0個以上のWindowsワーカーノードを含める必要がある。

Linux cgroupは、Linuxのリソース制御のポッド境界として使用される。コンテナはネットワーク、プロセス、ファイルシステム分離のために、その境界内に作成される。cgroups apiで、cpu / io / memory 統計が収集できる。一方、Windowsはシステム名前空間フィルターを備えたコンテナーにJobObjectを作成する。それにコンテナのすべてのプロセスを格納し、ホストから論理的に分離する。これにより、システム権限はホストのコンテキストでアサートできないため、Windowsでは権限のあるコンテナが利用できない。セキュリティアカウントマネージャー（SAM）は独立しているため、コンテナーはホストからIDを引き受られない。

Windowsには厳密な互換性ルールがあり、ホストOSのバージョンはコンテナのベースイメージOSのバージョンと一致する必要がある。Windows Server 2019のコンテナオペレーティングシステムを持つWindowsコンテナのみがサポートされる。コンテナのHyper-V分離は、WindowsコンテナイメージのOSバージョンの下位互換性を可能する。これは、将来のリリースとして計画されている

・TerminationGracePeriod：実装されていない
・Single file mapping：CRI-ContainerDで実装される
・Termination message：CRI-ContainerDで実装される
・Privileged Containers：Windowsコンテナでは現在サポートされていない
・HugePages：Windowsコンテナーでは現在サポートされていない
・既存のノード問題検出機能： Linux専用であり、特権コンテナが必要となる。Windowsで特権コンテナはサポートされていないため、使用できません。
・共有名前空間のすべての機能がサポートされていない（詳細についてはAPIセクションをご覧ください）
参考　CRI-ContainerD https://kubernetes.io/ja/docs/setup/production-environment/container-ru…

Windowsには、Linuxのメモリ不足のプロセスキラーは実装されていない。Windowsはすべてのユーザモードのメモリ割り当てを常に仮想メモリとして扱い、ページファイルが必須となる。Windowsは、Linuxのメモリ不足状態にならずメモリ不足(OOM)による強制終了とならず、ページをディスクに書き込む。これにより、メモリが過剰にプロビジョニングされ、すべての物理メモリが使い果たされるとページングによりパフォーマンスが低下する。

2つの対策でメモリ使用量を適切な範囲に抑えることができる。　
　1. kubelet parameterの""--kubelet-reserve"" と ""--system-reserve""を使用して、ノード(コンテナの外のメモリ)のメモリ使用量を制限する。これはノードのメモリ使用量を削減する。　
　2. ワークロードを展開するときに、コンテナのリソース制限(must set only limits or limits must equal requests)を利用する。これは、NodeAllocatableから減算し、ノードがいっぱいになるとスケジューラがPodを追加できなくなる。

オーバープロビジョニングを回避するためのベストプラクティスは、Windows、Docker、およびKubernetesプロセスで利用するために、少なくとも2GBのシステム予約メモリでkubeletを構成する。
以下の通り 、各flagはLinuxと異なった動作をする　
・--kubelet-reserve, --system-reserve , and --eviction-hard flags は、ノードのリソースを確保できる量に更新される。
・Eviction by using --enforce-node-allocable は実装されていない
・Eviction by using --eviction-hard and --eviction-soft は実装されていない
・MemoryPressure Condition は実装されていない
・kubeletによる、OOM eviction actionは提供されていない
・Windowsノードで実行されているKubeletにはメモリ制限はない。 --kubelet-reserveおよび--system-reserveは、ホストで実行されているkubeletまたはプロセスに制限を設定できない。このことにより、ホスト上のkubeletまたはプロセスが、ノード割り当て可能およびスケジューラーの外部でメモリリソース不足を引き起こす可能性がある。

Windowsは、コンテナレイヤーをマウントし、NTFSに基づいてコピーファイルシステムを作成するためのレイヤードファイルシステムドライバーがある。コンテナ内のすべてのファイルパスは、そのコンテナのコンテキスト内でのみ解決できる
・ボリュームはコンテナのディレクトリにマウントできる。ファイルにマウントすることはできない。
・ボリュームマウントは、ファイルまたはディレクトリをホストファイルシステムに投影できない。
・読み取り専用ファイルシステムはサポートされない。Windows registryやSAMデータベースは常に書き込み権限を要求するため。ただし、読み取り専用ボリュームはサポートされている
・ボリュームユーザマスクや権限付与はサポートされていない。SAMはホストとコンテナの間で共有されないため、マッピングする方法はないため。すべての権限は、コンテナのコンテキストの中でのみ解決される。

結果としてWindowsノードでは以下のストレージ機能がサポートされない
・Volume subpath mounts. Windowsコンテナではボリューム全体のマウントのみできる
・シークレットのためのSubpath volume mount
・Host mount projection　
・Default Mode ( UID/GID依存のため）
・読み取り専用ルートファイルシステム。 マップされたボリュームは引き続き読み取り専用をサポートする
・Block device mapping
・Memory as the storage medium
・uui/guid,per-user Linux filesystem permissionsのような、ファイルシステム機能
・NFSベースのストレージ/ボリュームサポート
・マウント済みボリュームの拡張（resizefs)

Windowsコンテナネットワークはいくつかの重要な点でLinuxネットワーキングと異なる。マイクロソフトのコンテナネットワークのドキュメントに詳細と背景が記載されている。
https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture

Windowsホストのネットワークサービスと仮想スイッチは、ネームスペースを実装し、Podやコンテナの要求に応じて仮想NICを作成できる。しかしながら、多くのDNS、ルート、メトリックのような設定は、Linuxのように/etc/のファイルに格納されているのではなく、レジストリのデータベースに格納される。コンテナのWindowsレジストリはホストから隔離されているため、ホストからコンテナへ/etc/resolv.confをマッピングするようなコンセプトはLinuxで想定されているような動作はしない。WIndowsでは、個々のコンテナのコンテキストで実行されるWindows APIを使用して構成する必要がある。したがって、CNIの実装では、ファイルのマッピングする代わりにHNSを呼び出して、ネットワークの詳細設定をPodまたはコンテナーに渡す必要がある。

以下のネットワーク機能がWindowsノードでサポートされない
・Host networking modeはWindows Podでは利用できない
・Local NodePortへの自身のノードからのアクセスは失敗する(別のノードや外部クライアントからは動作する）
・ノードのVIPへのアクセスは、Windowsサーバの将来リリースでサポートされる
・kube-proxyのオーバーレイネットワークサポートは、アルファリリース。KB4482887が必要
・Local Traffic Policy and DSR mode
・l2bridge、l2tunnel、またはオーバーレイネットワークに接続されたWindowsコンテナは、IPv6スタックを介した通信をサポートしない。これらのネットワークドライバーがIPv6アドレスを使用できるようにするために必要な優れたWindowsプラットフォームの作業があり、kubernetesはkubelet、kube-proxy、およびCNIプラグインは動作する。
・win-overlay、win-bridge、およびAzure-CNIプラグインを介したICMPプロトコルを使用したアウトバウンド通信
　・同じネットワーク内の宛先（たとえば、pingを介したポッド間の通信）に向けられたICMPパケットは、制限なしで期待どおりに動作します
　・TCP / UDPパケットは期待どおりに機能し、制限なしで動作します
　・リモートネットワークを通過するように向けられたICMPパケット（pingを介したポッドから外部インターネット通信など）は変換できないため、送信元にルーティングされない
　・TCP / UDPパケットはトランスポーズできるため、ping <destination>をcurl <destination>に置き換えて、外部への接続をデバッグできる。

以下の機能は、kubernetes v1.15で追加された
　・kubectl port-forward

・Windows参照ネットワークプラグイン win-bridgeおよびwin-overlayは、「CHECK」実装が欠落しているため、現在CNI仕様v0.4.0を実装されていない
・Flannel VXLAN CNIには、Windowsで次の制限がある
　1. ノードとPodの接続は設計上不可能。Flannel PR 1096のローカルPodでのみ可能
　2. 仕様として4096およびUDPポート4789に制限されている。VMN制限は現在取り組んでおり将来リリースで解決される予定(open-source flannel changes)。これらのパラメーターの詳細については、公式のFlannel VXLANバックエンドドキュメントを参照してください。

・ClusterFirstWithHostNetは、DNSでサポートされない
・Windwosは、"".""を含むすべての名前をFQDNとして扱い、PQDN解決をスキップする。Linuxでは、PQDNを解決するときに使用される複数のDNSサフィックスリストがある。Windowsは、1つのDNSサフィックスしかない。これはPodの名前空間に関連付けられているDNSサフィックスです。（例、mydns.svc.cluster.local）Windowsは、FQDNとそのサフィックスで解決可能なサービスまたは名前を解決できる。たとえば、デフォルトのネームスペースで生成されたPodには、DNSサフィックスdefault.svc.cluster.localが設定される。 WindowsのPodは、kubernetes.default.svc.cluster.localとkubernetesの両方を解決できるが、kubernetes.defaultやkubernetes.default.svcのような中間的なものを解決できない。
・Windowsでは、利用できる複数のDNSリゾルバがある。これらにはわずかに異なる動作が伴うため、Resolve-DNSNameユーティリティを利用することを推奨する

シークレットは、ノードボリュームにクリアテキストで書かれます。
(Linuxでは、tmpfs/in-memory に書かれる)。
このために、２つ実施すべきことがある
・シークレットファイルを保護するために、ファイルACLを利用する
・BitLockerなどのボリュームレベルで暗号化を実施する

RunAsUserはWindowsではサポートされていない。回避策は、コンテナをパッケージ化する前にローカルアカウントを作成すること。RunAsUsername capabilityは将来リリースで追加が予定されている。
SELinux、AppArmor、Seccomp、POSIX機能などのLinux固有のPodセキュリティコンテキスト権限はサポートされていない。さらに、既に述べたように、特権コンテナはWindowsではサポートされていない

ほとんどのKubernetes APIがWindowsで動作する。 いくつかある違いは、OSとコンテナランタイムの違いに帰着する。特定の状況では、PodやコンテナのAPIの一部のプロパティは、Linuxで実装され、Windowsで実行すると失敗するいという前提で設計されている。

高レベルでは、これらのOSの概念は異なります。

・Identity - Linuxは、整数型として表されるuserID（UID）およびgroupID（GID）を使用します。 ユーザー名とグループ名は実体として利用されていない。これらは/etc/groupsまたは/etc/passwdのエイリアスで、UID + GIDが実際には利用される。Windowsでは、Windows Security Access Manager（SAM）データベースに格納されている、より大きなバイナリセキュリティ識別子（SID）を使用します。 このデータベースは、ホストとコンテナー間、またはコンテナー間で共有できない。

・File permissions - Windowsは、アクセス許可とUID + GIDのビットマスクではなく、SIDに基づいたアクセス制御リストを使用する

・File paths - Windowsでは、""/""の代わりに""\"を使用します。通常、Go IOライブラリは両方を受け入れて動作させるだけですが、コンテナ内で解釈されるパスまたはコマンドラインを設定する場合は、""\"が必要になる場合がある。

・Signals - Windowsインタラクティブアプリは終了を異なる方法で処理し、以下の1つ以上を実装できます。
　・UIスレッドは、WM_CLOSEを含む明確に定義されたメッセージを処理する
　・コンソールアプリは、コントロールハンドラーを使用してctrl-cまたはctrl-breakを処理する
　・サービスは、SERVICE_CONTROL_STOP制御コードを受け入れることができるサービス制御ハンドラー関数を登録する
　・終了コードは、0が成功、0以外が失敗の場合と同じ規則に従う。 特定のエラーコードは、WindowsとLinuxで異なる場合がある。 ただし、Kubernetesコンポーネント（kubelet、kube-proxy）から渡される終了コードは変更されていない。

V1.Container
・V1.Container.ResourceRequirements.limits.cpuおよびV1.Container.ResourceRequirements.limits.memory-WindowsはCPU割り当てにハード制限を使用しない。 代わりに、共有システムが使用する。milicoresに基づく既存のフィールドは、Windowsスケジューラーによって追跡される相対共有にスケーリングされる。
　see: kuberuntime/helpers_windows.go
　see: resource controls in Microsoft docs
・Huge pagesはWindowsコンテナランタイムでは実装されていないため、利用できない。コンテナに対して設定できないユーザ権限をアサートする必要がある。
・V1.Container.ResourceRequirements.requests.cpu、およびV1.Container.ResourceRequirements.requests.memory
リクエストはノードの利用可能なリソースから確保されるため、ノードのオーバープロビジョニングを回避するために使用できる。 ただし、オーバープロビジョニングされたノードのリソースを制御するために使用することはできない。 オペレーターが完全に過剰なプロビジョニングを避けたい場合は、ベストプラクティスとしてすべてのコンテナーにこれらのパラメータを設定する必要がある。
・V1.Container.SecurityContext.allowPrivilegeEscalation： Windowsでは利用できない。何も設定されない
・V1.Container.SecurityContext.Capabilities： POSIX機能はWindowsでは実装されていない
・V1.Container.SecurityContext.privileged： Windowsでは特権コンテナはサポートされていない
・V1.Container.SecurityContext.procMount： Windowsは/procファイルシステムを持っていない
・V1.Container.SecurityContext.readOnlyRootFilesystem：Windowsでは利用できない。レジストリおよびシステムプロセスがコンテナ内で実行するには書き込みアクセスが必要なため
・V1.Container.SecurityContext.runAsGroup： Windowsでは利用できない。GIDをサポートしていないため
・V1.Container.SecurityContext.runAsNonRoot： Windowsはrootユーザを持っていない。最も近いものはContainerAdministratorだが、このIDはノードに存在しない。
・V1.Container.SecurityContext.runAsUser： Windowsでは利用できない。intとしてUIDがサポートされていないため
・V1.Container.SecurityContext.seLinuxOptions： Windowsでは利用できない。SELinuxはLinux固有機能のため
・V1.Container.terminationMessagePath： 単一ファイルマッピングをサポートしないWindowsでは制限がある。デフォルトでは、 /dev/termination-log となっており、デフォルトでWindowsでは存在しないため動作する。

V1.Pod
・V1.Pod.hostIPC, v1.pod.hostpid:　Host namespace sharingはWindowsでは利用できない
・V1.Pod.hostNetwork： Host network共有は、WindowsOSがサポートしていない
・V1.Pod.dnsPolicy： ClusterFirstWithHostNetは、サポートされていない。Host NetworkingがWindowsではサポートされていないため
・V1.Pod.podSecurityContext： V1.PodSecurityContextを参照
・V1.Pod.shareProcessNamespace： これはベータ機能であり、Windowsに実装されていないLinux名前空間に依存している。 Windowsは、プロセスの名前空間またはコンテナのルートファイルシステムを共有できない。 共有できるのはネットワークのみ。
・V1.Pod.terminationGracePeriodSeconds： WindowsのDockerに完全には実装されていない。
　参考：現在の動作では、ENTRYPOINTプロセスにCTRL_SHUTDOWN_EVENTが送信され、Windowsはデフォルトで5秒待機し、最後に通常のWindowsシャットダウン動作を使用してすべてのプロセスをシャットダウンする。デフォルトの5秒の設定値は、コンテナ内のWindowsレジストリにあるためコンテナの構築時に上書きできる。
・V1.Pod.volumeDevices： ベータ機能でWindowsに実装されていない。WindowsはrawブロックデバイスをPodに接続できない
・V1.Pod.volumes EmptyDir, Secret, ConfigMap, HostPath：all work and have tests in TestGrid
・V1.emptyDirVolumeSource： NodeのデフォルトのメディアはWindowsディスクです。 WindowsにはRAMディスクが組み込まれていないため、メモリはサポートされていない。
・V1.VolumeMount.mountPropagation： mount propagation は、Windowsではサポートされていません

V1.PodSecurityContext
PodSecurityContextフィールドはWindowsでは動作しない。参照用に以下にリストする
・V1.PodSecurityContext.SELinuxOptions - SELinux は Windowsで利用できない　
・V1.PodSecurityContext.RunAsUser - UIDを提供する,Windowsで利用できない　
・V1.PodSecurityContext.RunAsGroup - GIDを提供する,Windowsで利用できない　
・V1.PodSecurityContext.RunAsNonRoot - Windowsはルートユーザを持っていない。最も近いものはContainerAdministratorです。これは、ノードに存在しないIDです。　
・V1.PodSecurityContext.SupplementalGroups - GIDを利用するため Windowsで利用できない　
・V1.PodSecurityContext.Sysctls -これらは、Linux sysctlインターフェースの一部です。 Windowsには同等のものはない。

まとめ

ざっと内容を訳しながら内容を確認してきました。まだ、言葉が適切でないところがあると思いますのでご注意ください。この内容とAzure上で動作させるときには、Azure Kubernetes Service のサポート ポリシーも確認が必要ですね。