What a Windows Container looks like ?

CloudNative Days Tokyo 2020 の資料です。

Transcript

1. What a Windows Container looks like ? Yutaka Ichikawa CloudNative Days Tokyo 2020.09.08 © 2020 AP Communications Co., Ltd.
2. Certification & Community CKA CKAD KCM100 2018 2019 Profile #CNDT2020 Name: Yutaka Ichikawa Twitter/GitHub/Qiita: cyberblack28 Hatena Blog: https://cyberblack28.hatenablog.com/ Slides: https://speakerdeck.com/cyberblack28 Job Educational Solution Architect Developer Advocate / Technical Evangelist Infrastructure Engineer / Frontend Engineer
3. AP Communications Co., Ltd Let’s Start Cloud Native
4. Agenda 1. Windows & Docker 2. Windows Container 3. Dockerfile & Image of Windows Container 4. Windows Container & Kubernetes 5. Verification of Windows Container 6. Future Investigation and Verification 7. Reference
5. Windows & Docker
6. Docker Support
7. Docker Support Windowsコンテナの誕生 • Windows Server 2016 & Windows10 x64 version1607からスタート • Windows Server 2016 Technical PreviewではWindows PowerShellベースによる 独自実装、GAではDocker Engineと管理機能を実装（Docker正式サポート） • Windowsコンテナのモードは、プロセス分離とHyper-V分離の2種類 • イメージは、Server CoreとNano Serverの2種類（現在は5種類）
8. Docker Support Docker Extends Collaboration with Microsoft Azure to Boost Developer Productivity Docker DesktopをMicrosoft AzureおよびVisual Studio製品ラインとより緊密に 統合するために、MicrosoftとDockerの間の新しいパートナーシップを発表 https://www.docker.com/press-release/Docker-Extends-Collab-Microsoft-Azure-Developer-Productivity
9. Windows Container
10. Windows Container Mode
11. Windows Container Mode プロセス分離モード（Windows Server Container） Hyper-V分離モード（Hyper-V Container） ホストOSのカーネルを共有しながら、ホストOSや他のコンテナーから分離されたユーザー モードプロセスの実行環境を提供。 Linux上のDocker + コンテナーと同様 Hyper-Vハイパーバイザーを利用して、隔離されたコンテナーごとの専用環境を提供。確 実なリソースと厳密なセキュリティ境界が特徴。 ホストOSのカーネルを共用することはない、Windows特有機能。
12. Windows Container Mode プロセス 分離モード（Windows Server Container） BareMetal or Virtual Machine Docker Client Windows Server Docker ホストOSのバージョン/ビルドと Windowsコンテナーのバージョン/ビル ドが同じ必要があります。 カーネル共有における制限 Windows Container Windows Container Windows Container Kernel Share
13. Windows Container Mode Hyper-V分離モード（Hyper-V Container） BareMetal or Hyper-V Virtual Machine Docker Client Docker UtilityVM Windows Server Utility VM (Windows Kernel) Windows Container Utility VM (Linux Kernel) Linux Container UtilityVMと呼ばれる仮想マシンがその 上で稼働するコンテナーにカーネルを 提供します。 Hyper-V分離モードのコンテナーは、ホ ストOSのカーネルを共有することはあ りません。 Kernel Share Kernel Share Linux Containers on Windows (LCOW) Hyper-V Container Hyper-V Hypervisor
14. Linux Containers on Windows(LCOW)
15. Linux Containers on Windows（LCOW） Windwosコンテナー向けのDockerホスト上で、WindowsコンテナーだけでなくLinuxコン テナーも実行できる機能です。 現時点（2020年9月）では、Experimental機能（試験段階）となっています。 以下Docker及びホストOS環境でプレビュー評価可能です。 • Docker Engine 19.03.1以降のDocker Enterprise/Docker Desktop • Windows Server 2019 • Windows Server version1809以降 • Windows10 version1809以降
16. Linux Containers on Windows（LCOW） LCOW on Docker Desktop for Windows BareMetal or Hyper-V Virtual Machine Docker Client Docker Desktop (Docker Engine) Utility VM (Windows Kernel) Windows Container Utility VM (Linux Kernel) Linux Container Docker Desktop for Windowsでの LCOWの仕組みは、Hyper-V分離モー ドで実現されます。 Kernel Share Kernel Share Linux Containers on Windows (LCOW) Hyper-V Container そもそも、Linuxコンテナーが稼 働する環境とは違うの？ Windows 10 Client Hyper-V
17. Linux Containers on Windows（LCOW） Linux Container on Docker Desktop for Windows BareMetal or Hyper-V Virtual Machine Docker Client Docker Desktop Moby Linux DockerDesktopVM（Hyper-V VM） Hyper-V仮想マシンとしてLinuxホスト （DockerDesktopVM）が稼働して、そ のLinuxカーネルを共有してLinuxコンテ ナーが稼働する仕組みです。 また、Dockerクライアントは、そのLinux ホスト内のDocker Engineに接続しま す。 Docker Engine Linux Container Linux Container Linux Container Windows 10 Client Hyper-V
18. Linux Containers on Windows（LCOW） Switch Environment Linux Container on Docker Desktop for Windows Windows Container & LCOW on Docker Desktop for Windows
19. Runtime of Windows Container
20. Runtime of Windows Container “Linux + Docker + Runtime”
21. Runtime of Windows Container Docker Docker Client containerd runC Linux cgroups Namespaces Union Filesystem Network Low-level Container Runtime High-level Container Runtime OCI(Open Container Initiative) CRI(Container Runtime Interface) kubelet
22. Runtime of Windows Container “Windows + Docker + Runtime”
23. Runtime of Windows Container BareMetal & Virtual Machine Docker Client Windows Server Docker Windows Container Windows Container Windows Container Kernel Share View the detail この部分を詳しく... プロセス分離モード（Windows Server Container）
24. Runtime of Windows Container Docker Docker Client Windows libcontainerd hcsshim HCS(Host Compute Service) HNS(Host Network Service) Job objects Namespaces Union like filesystem extensions WinNAT Windows Firewall vSwitch TCP/IP VPF libnetwork plugins Windows Container Windows Container
25. Runtime of Windows Container hcsshim Host Compute Service（HCS） Host Network Service（HNS） Host Compute Service（HCS）、Host Network Service（HNS）を使用してWindowsコンテ ナーの起動、管理するためのGolangインターフェイス。 Windowsでコンテナーを扱うためのAPI。Linuxにおけるcontainerdとruncにあたる機能を 提供。 Windowsでコンテナーのネットワークを扱うためのAPI。Windowsコンテナーのネットワー ク管理を担います。
26. Image & Dockerfile of Windows Container
27. Image & Dockerfile of Windows Container Windows Container Base Image イメージ種類 概要 Windows Server Core Windows Server API (.NET framework) のサブセットを含むWindows ServerのServer Coreベースイ メージ。.NETフレームワークアプリケーション向け。 Nano Server .NET Core APIと一部のサーバー ロールのサポートが含むWindows ServerのNano Serverイメー ジ。.NET CoreベースのWindowsアプリケーション向け。 Windows Windows 10 Enterpriseのベースイメージ。Windows APIとシステムサービス (サーバー ロールは除く) の完全セットのイメージ。Windows Server Coreで依存関係が解決できない場合に利用（サイズ大）。 Windows 10 IoT Core Windows IoT Coreのベースイメージ。Azure IoT Edgeデバイス用アプリケーション開発向け。 Windows Insider Windows Insider Programに参加して利用できる一般公開前のベースイメージ。Windows Insider Program向け。上記4種類のInsiderイメージがあります。 参照：https://docs.microsoft.com/ja-jp/virtualization/windowscontainers/manage-containers/container-base-images
28. Image & Dockerfile of Windows Container Framework & Image Windows Nano Server Windows Server Core Image Image .Net Frameworkは、servercoreイメージ、.Net Coreは、nanoserverイメージを利用しま す。 ※.NET Coreはクロスプラットフォーム対応のため、 Linuxのイメージも可能です。
29. Image & Dockerfile of Windows Container Image Registry Docker Hub/Docker Trusted Registry Azure Container Registry
30. Image & Dockerfile of Windows Container Windowsコンテナーイメージの格納場所 項目 Windows ルートディレクトリ C:￥ProgramData￥docker イメージ格納ディレクトリ C:￥ProgramData￥docker￥windowsfilter
31. プロセス分離モード
32. Image & Dockerfile of Windows Container Docker Enterprise on Windows Server 2019で プロセス分離モード で確認 >docker run -it --isolation=process --rm mcr.microsoft.com/windows/servercore:1809 cmd Microsoft Windows [Version 10.0.17763.1397] (c) 2018 Microsoft Corporation. All rights reserved. C:\>dir Volume in drive C has no label. Volume Serial Number is 5EE3-A54B Directory of C:\ 05/07/2020 04:48 AM 5,510 License.txt 08/06/2020 04:55 PM <DIR> Program Files 08/06/2020 04:53 PM <DIR> Program Files (x86) 08/06/2020 04:56 PM <DIR> Users 08/17/2020 02:29 AM <DIR> Windows 1 File(s) 5,510 bytes 4 Dir(s) 21,165,944,832 bytes free フォアグラウンドでコンテナを起動します。
33. Image & Dockerfile of Windows Container > docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 945985b000b5 mcr.microsoft.com/windows/servercore:1809 "cmd" 2 hours ago Up 2 hours stoic_nash 新規ウィンドウから稼働状況を確認します。 > docker inspect 945985b000b5 -f "{{.HostConfig.Isolation}}" process プロセス分離モードか確認します。 実際に格納されているか確認します。 servercoreのイメージは、 nanoserverよりもレイヤが多い
34. Image & Dockerfile of Windows Container C:￥ProgramData￥Docker￥windowsfilter ベースOSイメージフォルダ C:￥ProgramData￥docker￥windowsfilter￥75721d9e0e5ee2c9b7098684e678bbe458094b2065f82f29ed6f1326bf562473 イメージのルートファイルシステム コンテナーに仮想レジストリを提供し、ホ ストOSとのレジストリの差分を吸収。 blank-base.vhdxは容量可変タイプの空ディスクでコンテナーに対してデフォルトで20GBのC ドライブを提供。 blank.vhdxは、blank-base.vhdxを親とする差分ディスク
35. Image & Dockerfile of Windows Container C:￥ProgramData￥Docker￥windowsfilter C:￥ProgramData￥docker￥windowsfilter￥945985b000b599357720320faf794e80f8d6c4222e01dc65759d944d50e7d8e6 複数レイヤーで構成されるイメージやコンテナーの情報を格納してい るJSON形式のファイル。 blank.vhdxのコピーから作成された blank-base.vhdxを親とする差分 ディスク。コンテナーのファイルシステムやレジストリの変更が書き込 まれるため、ベースOSイメージには影響がない仕組みとなっていま す。 ベースOSイメージから作成した Windowsコンテナーフォルダ このフォルダは、docker container rmコマンドを実行すると削除されます。
36. Image & Dockerfile of Windows Container Host Kernel Virtual Filesystem Virtual Registry Process Mode プロセス分離モード Windowsコンテナー Write Read Read Write Read Host Filesystem C:￥ProgramData￥docker ￥windowsfilter￥ C:￥ProgramData￥docker￥windowsfilter ￥945985b000b599357720320faf794e80f8d6c4222e0 1dc65759d944d50e7d8e6 ベースイメージとしては、 プロセス分離モードでも UtilityVMは存在。
37. Hyper-V分離モード
38. Image & Dockerfile of Windows Container Docker Desktop for Windowsで Hyper-V分離モード で確認 >docker run -it --isolation=hyperv --rm mcr.microsoft.com/windows/nanoserver:1809 cmd C:\>dir Volume in drive C has no label. Volume Serial Number is F89E-63A5 Directory of C:\ 07/07/2020 11:12 PM 5,510 License.txt 07/27/2020 02:27 PM <DIR> Users 07/27/2020 02:27 PM <DIR> Windows 1 File(s) 5,510 bytes 2 Dir(s) 21,245,104,128 bytes free フォアグラウンドでコンテナを起動します。
39. Image & Dockerfile of Windows Container > docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9ba57047c4b2 mcr.microsoft.com/windows/nanoserver:1809 "c:\\windows\\system32…" 42 minutes ago Up 42 minutes vigilant_hodgkin 新規ウィンドウから稼働状況を確認します。 > docker inspect 9ba57047c4b2 -f "{{.HostConfig.Isolation}}" hyperv Hyper-vモードか確認します。 実際に格納されているか確認します。
40. Image & Dockerfile of Windows Container C:￥ProgramData￥Docker￥windowsfilter C:￥ProgramData￥Docker￥windowsfilter￥fd6f0ddff669d4792a46c4a1521e7a51c640cfea93070c63dd0151b4d10c8528 イメージのルートファイルシステム コンテナーに仮想レジストリを提 供し、ホストOSとのレジストリの 差分を吸収。 Hyper-V分離用の 仮想マシンデータ blank-base.vhdxは容量可変タイプの空ディスクでコンテナーに対してデフォルト で20GBのCドライブを提供。 blank.vhdxは、blank-base.vhdxを親とする差分ディスク ベースOSイメージフォルダ
41. Image & Dockerfile of Windows Container C:￥ProgramData￥Docker￥windowsfilter C:￥ProgramData￥Docker￥windowsfilter￥9ba57047c4b285ed8f7d803b53ac0541688fcbab062386ea461b99a49b2104d0 複数レイヤーで構成されるイメージやコンテナーの情報を格納してい るJSON形式のファイル。 blank.vhdxのコピーから作成された blank-base.vhdxを親とする差分 ディスク。コンテナーのファイルシステムやレジストリの変更が書き込 まれるため、ベースOSイメージには影響がない仕組みとなっていま す。 ベースOSイメージから作成した Windowsコンテナーフォルダ このフォルダは、docker container rmコマンドを実行すると削除されます。
42. Dockerfile
43. Image & Dockerfile of Windows Container Dockerfile 基本的には、LinuxのDockerfileと変わりませんが、以下Windowsの仕様に合わせる必 要があります。 COPY test1.txt /temp/ COPY test1.txt c:/temp/ ADD test1.txt /temp/ ADD test1.txt c:/temp/ WORKDIR c:\\windows # exec form CMD ["c:\\Apache24\\bin\\httpd.exe", "-w"] # shell form CMD c:\\Apache24\\bin\\httpd.exe -w • ADD、COPY命令でパスの指定がバックスラッシュ（￥）ではなくスラッシュにする必要があります。 • WORKDIR、CMD命令では、作業ディレクトリにバックスラッシュが含まれる場合、エスケープする必要があります。 エスケープ文字として使用できる 値は「 \」 と「`」 です。
44. Image & Dockerfile of Windows Container Docker Desktop for WindowsでHyper-v分離モードで確認 FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-1903 RUN powershell -NoProfile -Command Remove-Item -Recurse C:\inetpub\wwwroot\* WORKDIR /inetpub/wwwroot COPY index.html . Dockerfileを使って、IISをプロセス分離モードで起動するWindowsコンテナーを作成 Dockerfile index.html <!DOCTYPE html> <html> <head> <title>Windows Container</title> </head> <body> <p>Hello, Windows Container !!</p> </body> </html>
45. Image & Dockerfile of Windows Container >mkdir Dockerfile >cd Dockerfile >docker image build -t iis-site . Sending build context to Docker daemon 3.072kB Step 1/4 : FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-1903 windowsservercore-1903: Pulling from windows/servercore/iis 5b663e3b9104: Pull complete 0293a64b839c: Pull complete 0b8a8fb02793: Pull complete 24e6b7871272: Pull complete 15bc986a106e: Pull complete Digest: sha256:40b3fa895a25d2282ff245c7748a4d9ca9d239eee02657b86f695d0a86a86645 Status: Downloaded newer image for mcr.microsoft.com/windows/servercore/iis:windowsservercore-1903 ---> b64a7f793328 Step 2/4 : RUN powershell -NoProfile -Command Remove-Item -Recurse C:\inetpub\wwwroot\* ---> Running in 7c2fe3dcfc41 Removing intermediate container 7c2fe3dcfc41 ---> b0bc71ab9795 Step 3/4 : WORKDIR /inetpub/wwwroot ---> Running in beeb599e413b Removing intermediate container beeb599e413b ---> 4deeb2ca7ba8 Step 4/4 : COPY index.html . ---> a88fa59e4e9f Successfully built a88fa59e4e9f Successfully tagged iis-site:latest 専用フォルダを作成して、Dockerfileからビルドします。
46. Image & Dockerfile of Windows Container >docker run -d -p 8000:80 --name my-running-site iis-site 6987fbaa9a69ef740e292d1bd00134d6c6fdae22c764013eac73c0b73109516a ブラウザを起動して、http://localhost:8000/index.htmlにアクセス
47. Windows Container & Kubernetes
48. Runtime of Windows Container “Windows + Docker + Kubernetes + Runtime”
49. Runtime of Windows Container 2019.03 Kubernetes 1.14 Windows（Docker EE-basic 18.09+、Windows Server 2019/1809+）ノードをワーカー ノードとして追加し、Windowsコンテナーをスケジュールする機能をサポート。※Control PlaneはLinuxであることが制限事項 参考：Intro to Windows support in Kubernetes (https://kubernetes.io/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/) 2020年9月時点では、Kubernetesで対応するWindowsコンテナーは、 プロセス分離モード、Hyper-V分離モードはKubernetes1.20(containerd1.5)予定。 History
50. Runtime of Windows Container Docker Docker Client kubelet libcontainerd libnetwork plugins Windows HCS(Host Compute Service) HNS(Host Network Service) Job objects Namespaces Union like filesystem extensions WinNAT Windows Firewall TCP/IP vSwitch VPF dockershim hcsshim Windows Container Windows Container
51. kubelet Windows Runtime of Windows Container Docker Docker Client containerd containerd-shim(runhcs) libcontainerd libnetwork plugins HCS(Host Compute Service) HNS(Host Network Service) Job objects Namespaces Union like filesystem extensions WinNAT Windows Firewall TCP/IP vSwitch VPF hcsshim CRI(Container Runtime Interface) CRI API Windows Container Windows Container OCI(Open Container Initiative) OCI準拠のruncのフォーク
52. Runtime of Windows Container runhcs runhcsは、Open Container Initiative (OCI)仕様に準拠したruncのフォークです。 runc と runhcs の機能上の違い • runhcsはWindows上で動作します。 コンテナーを作成および管理するためにHost Compute Service（HCS）と通信します。 • runhcs では、さまざまな種類のコンテナーを実行できます。 WindowsとLinuxのHyper-Vによる分離 (KubernetesではHyper-V分離は未対応2020年9月時点) Windowsプロセスコンテナー (コンテナーイメージはコンテナーホストと一致する必要があります)
53. Runtime of Windows Container 2020.03 Kubernetes 1.18 Windows上のCRI-ContainerDのサポートを追加（Containerd1.3）。 参考：Intro to Windows support in Kubernetes (https://kubernetes.io/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/) • Enable CRI plugin #4076 • Add support for Windows containers process isolation cri#1264 • Build CRI Plugin on Windows and add presubmit cri#1258 Containerd GitHub上では、1.4で追加されました。（2020年8月時点）。 (https://github.com/containerd/containerd/releases)
55. Runtime of Windows Container Simplifying Windows runtime and deployment in Kubernetes - Muzz Imam, Microsoft & Michael Michael, VMware
56. kubelet Windows Runtime of Windows Container Docker Docker Client containerd containerd-shim (hcsshim) libcontainerd libnetwork plugins HCS(Host Compute Service) HNS(Host Network Service) Job objects Namespaces Union like filesystem extensions WinNAT Windows Firewall TCP/IP vSwitch VPF hcsshim CRI(Container Runtime Interface) CRI API Windows Container Windows Container
57. Runtime of Windows Container Simplifying Windows runtime and deployment in Kubernetes - Muzz Imam, Microsoft & Michael Michael, VMware
58. Runtime of Windows Container Simplifying Windows runtime and deployment in Kubernetes - Muzz Imam, Microsoft & Michael Michael, VMware Kubernetes 1.20 Containerd 1.5 に向けて
59. Runtime of Windows Container Simplifying Windows runtime and deployment in Kubernetes - Muzz Imam, Microsoft & Michael Michael, VMware
60. AKS & Windows Container
61. AKS & Windows Container AKS（Azure Kubernetes Service）では、Windows Containerをサポートしています。 InfoQ:https://www.infoq.com/jp/news/2020/06/windows-server-containers-aks-ga/ AKSでWindows Containerを稼働させる場合は、ノードプールとしてWindows Server ノードプルを追加する必要があります。以下の制約があります。 • AKSクラスターでは、最大で10のノードプールを作成できます。 • AKSクラスターでは、最大で100のノードを各ノードプールで作成できます。 • Windows Server ノードプール名は6文字に制限されています。
62. AKS & Windows Container Microsoft Official Tutrial (https://docs.microsoft.com/ja-jp/azure/aks/windows-container-cli) Linux NodePool Windows NodePool
63. AKS & Windows Container $ az group create --name myResourceGroup --location eastus 1.リソースグループを作成 $ PASSWORD_WIN="P@ssw0rd1234" $ az aks create \ --resource-group myResourceGroup \ --name myAKSCluster \ --node-count 2 \ --enable-addons monitoring \ --generate-ssh-keys \ --windows-admin-password $PASSWORD_WIN \ --windows-admin-username azureuser \ --vm-set-type VirtualMachineScaleSets \ --network-plugin azure 2.AKSクラスタの作成
64. AKS & Windows Container $ az aks nodepool add \ --resource-group myResourceGroup \ --cluster-name myAKSCluster \ --os-type Windows \ --name npwin \ --node-count 1 3.Windows Server ノードループ追加 $ az aks get-credentials --resource-group myResourceGroup --name myAKSCluster 4.クラスタに接続 $ kubectl get nodes NAME STATUS ROLES AGE VERSION aks-nodepool1-12345678-vmssfedcba Ready agent 13m v1.16.13 aksnpwin987654 Ready agent 108s v1.16.13
65. AKS & Windows Container apiVersion: apps/v1 kind: Deployment metadata: name: sample labels: app: sample spec: replicas: 1 template: metadata: name: sample labels: app: sample spec: nodeSelector: "beta.kubernetes.io/os": windows containers: - name: sample image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp resources: limits: cpu: 1 memory: 800M requests: cpu: .1 memory: 300M ports: - containerPort: 80 selector: matchLabels: app: sample --- apiVersion: v1 kind: Service metadata: name: sample spec: type: LoadBalancer ports: - protocol: TCP port: 80 selector: app: sample 5.sample.yamlの作成 nodeSelectorでwindowsノード プールにPodを配置します。 マニフェストファイルの書き方に 変化はありません。 補足：ingressなどLinuxノードで稼働 すべきものはlinuxノード向けの nodeSelectorを指定する必要があり ます。 （https://docs.microsoft.com/ja-jp/azure/aks/ingress-basic#creat e-an-ingress-controller）
66. AKS & Windows Container $ kubectl apply -f sample.yaml 6.アプリケーションデプロイ $ kubectl get service sample NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE sample LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 6s 7.接続IPアドレスの確認 8.ブラウザアクセス
67. Runtime of Windows Container Add Windows Node to Kubernetes Cluster （GA or Experiment） Enterprise
68. Investigatation & Verification of Windows Container
69. Investigatation & Verification of Windows Container Windowsコンテナの検証を始めることになったのか？ Windowsアプリケーションをベースとした業務システムが現在も稼働中であり、塩漬けと なったシステムもあるという話などをよく聞くことがありました。 モダナイズにおける一つの道筋として、Windowsベースでないと解決できないケースもあ るという見込みもあります。 それに向けてWindowsコンテナの領域にも携わって行く方針が立ち、始まりました。
70. Investigatation & Verification of Windows Container 会社のチームで以下の観点で調査及び検証を行いました。 • Memory Size Podのメモリサイズ割り当て • Image Size LinuxとWindowsにおけるイメージサイズの比較 • Application Build .Net Frameworkと.Net Coreのイメージビルド時間 • Logging ログ出力の確認とツール調査
71. Memory Size
72. Investigatation & Verification of Windows Container 1.メモリサイズの割り当て Kubernetes公式ドキュメントによると、Podへの過割り当てを避けるためホスト側の Windows、 Docker、Kubernetesのプロセス用に最低2GB確保することを推奨しています。 Kubernetes公式ドキュメント：https://kubernetes.io/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/ Docker/Kubernetes プロセス Windows Node Node用 メモリサイズ 約2GBを確保 アプリケーションPod 割り当て可能領域
73. Investigatation & Verification of Windows Container 2.メモリサイズの割り当て（AKS） AKS WindowsノードではKubernetes管理用Podのために約1GB消費するため、それを除いた分がア プリケーションで割り当て可能な領域となる。 AKS 管理用Pod AKS Windows Node Node用 メモリサイズ 約1GBを確保 アプリケーションPod 割り当て可能領域
74. Investigatation & Verification of Windows Container 3.メモリ初期割り当てサイズ プロセス分離モード（Kubernetes上）におけるASP.NETアプリケーション最小割り当てサイズと Hyper-V分離モード利用時は+100MB程度のメモリが必要になる。 Base Image OS Framework Memory Allocate Size servercore-2019lts ASP.Net Framework 4.8 158MB ～ 170MB nanoserver ASP.Net Core 2.1 48～50MB nanoserver ASP.Net Core 3.1 50～52MB debian:buster-slim nginx 3 MB Linuxベースイメージに比べるとメモリサイズは、大きいですが、 Windowsアプリケーションの特性によ るものと思われます。
75. Image Size
76. Investigatation & Verification of Windows Container 簡単なASP.NetアプリケーションをDockerビルドした場合の「docker image ls」コマンドで表示されるイ メージサイズ。 Base Image OS Application Target Framework Image Size servercore-2019lts .Net Framework 3.5 (Batch Program) 7.8 GB servercore-2019lts ASP.Net Framework 4.8 7.15 GB nanoserver ASP.Net Core 2.1 403 MB nanoserver ASP.Net Core 3.1 351 MB debian:buster-slim Nginx 130 MB Linuxベースイメージに比べると容量は特に servercoreが重いですが、nanoserverはそれに比べると 軽い印象です。
77. Investigatation & Verification of Windows Container AKSでの初回Pod起動時間 Base Image OS Framework AKS Pod起動時間（初回） servercore-2019lts .Net Framework 3.5 (Batch Program) 11分 servercore-1903 ASP.Net framework 4.8 15分 nanoserver ASP.Net Core 3.1 6分30秒 イメージのPull時間を加味するとPod起動まで時間を要する結果となります。
78. Application Build
79. Investigatation & Verification of Windows Container コンテナ作成イメージ検証 1 Windows Server 2012/2016/2019 .Net Framework 3/3.5/4.5 - 4.8 App Windows Server Core 2019 Base Image .Net Framework 4.8 App .Net Framework 3.5 最新Verコンテナ ＋ 最新の.Net Framework コピー or .Netのバージョンを変 更せずビルド .Netバージョンの後方互換性がない Virtual Machine Container
80. Investigatation & Verification of Windows Container コンテナ作成イメージ検証 2 App .Net Core 2系/3系 Windows Server Core 2019 Base Image .Net Core 3系 3.1 App .Net Core 2系 2.1 最新Verコンテナ ＋ 最新の.Net Core コピー or .Netバージョンを 変更せずビルド Virtual Machine Container Windows Server 2012/2016/2019 .Netバージョンの後方互換性がない
81. Investigatation & Verification of Windows Container Build実行方法 builder image App runtime image App Build COPY docker build & push実行 App runtime image App Build COPY docker push実行 docker build実行 Case1 Docker（マルチステージ）ビルド Case2 Docker（Azure DevOps）ビルド
82. Investigatation & Verification of Windows Container Base Image OS Verification case ビルド時間 servercore-2019lts / .Net Framework 3.5 Dockerでビルド（Multi stage build） 24～26分 Dockerでビルド （Multi stage buid --from-cache指定あり） 21分～24分 Azure DevOps上でビルド後、Docker Imageにビルド結果をコピー 10分~12分 servercore-2019lts / .Net Framework 4.8 Dockerでビルド （Multi stage buid） 8分～20分 Dockerでビルド （Multi stage buid --from-cache指定あり） 6分強 Azure DevOps上でビルド後、Docker Imageにビルド結果をコピー 2分強
83. Investigatation & Verification of Windows Container Base Image OS Verification case ビルド時間 nanoserver / .Net Core 3.1 Docker内でビルド （Multi stage buid） 6分前後 Docker内でビルド （Multi stage buid --from-cache指定あり） 5分～5分30秒程度 Azure DevOps上でビルド後、Docker Imageにビルド結果をコピー 2分30秒程度
84. Logging
85. Investigatation & Verification of Windows Container ログ出力の種類 概要 STDOUT/STDERR 標準出力と標準エラー出力 Log File アプリケーション・ミドルウェアのログ Windows Event Log Windowsシステムのイベントログ ロギングについて Container Application / Middleware Windows Event Log Log file Log file Log file STDOUT/STDERR Docker logs/Kubernetes logsとして取得可能 ツールでログをexportする必要あり Microsoft Log Monitor (https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)
86. Future Investigation and Verification
87. Future Investigation and Verification 今後チームとして取り組もうと検討している調査および検証です。 • CI/CD GitOps • マニフェストファイル管理（ Helmなど） • Observability（Prometheus,Grafanaなど） • Microservice（Windows Containerでの実装など） • Service Mesh（Windows Containerでの実装など） • Security（OpenPolicyAgentなど） • Storage (CSIなど) • Network (CNIなど)
88. Reference
89. Reference I referred to the good books and internet information.
90. Reference • Windows コンテナー プラットフォーム https://docs.microsoft.com/ja-jp/virtualization/windowscontainers/deploy-containers/containerd • Introducing the Host Compute Service (HCS) https://techcommunity.microsoft.com/t5/containers/introducing-the-host-compute-service-hcs/ba-p/382332 • Windows上のコンテナに関するドキュメント https://docs.microsoft.com/ja-jp/virtualization/windowscontainers/ • Kubernetesエコシステム-コンテナランタイム編 https://www.kaitoy.xyz/2019/06/15/k8s-ecosystem-container-runtimes/#containerd • Docker Desktop の復習と、Windows Container に入門: Windows Server Container 理論編 https://qiita.com/kikuchi_kentaro/items/2fb0171e18821d402761 • Intro to Windows support in Kubernetes（翻訳にコントリビュートしました） https://kubernetes.io/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/ • sig-windows https://github.com/kubernetes/enhancements/tree/master/keps/sig-windows
91. Very Thanks !! APC Technology Development Department Container Group Member
92. Thank you for your attention !!