Windows container 一個大家可能聽過但沒什麼見過的技術，筆者從 2019/7 開始 Windows container 專案到現在最大的體會到的優缺點如下：
筆者會接觸 Windows container 的世界，也是因為下述美好的優點：
- Service High Availability and Traffic LoadBalancing
- Service AutoHealing
- 一致的環境
- 服務的容器化
- gMSA
在筆者開始使用 Windows Container 之前因為使用了一陣子 Kubernetes，這當中體會到很多過去 Linux VM 所沒有的優點，而這些優點在 Kubernetes for Windows 也可以體驗到。其中第一個感受到的就是 Service HA 的實現，透過一個 Replicas 數字就可以把一個 single pod 變成 multiple pods，你的 Service 也可以馬上擁有 HA 的能力，這對 Windows 環境的開發者來說，是一個非常棒的體驗。而當你的 service HA 設定完成，再透過 Kubernetes Service 達到 traffic load balancing，過去在機房需要的昂貴的 Layer 4 or Layer 7 LoadBalancer 在這可以都可以快速的實現。
Service AutoHealing，由於 Windows Container 的特性是監控 Pod 裡服務 Process 的狀態，如果回應的狀態為 running，這個 Pod 就會一直 running 下去，如果狀態改變這個 Pod 就會自動重啟，如此就可以解決以前人工重啟服務的工作。進一步，在 Kubernetes 中可以使用 Liveness 做到 Pod 的 healthcheck，這也可以讓服務團隊不用一直花心思在 Service status check and restart。
一致的環境，一個服務從 Dev, QA, Beta, Stage 到 Production，這當中有許的設定與環境的不一致性，而透過 Windows Container 是可以達最大程度的一致性。
服務的容器化，這也為什麼筆者會走入 Windows Container 最大的原因，因為有些舊服務不想要整個重寫成 Linux 平台的 code，但又希望得到上述的好處，這時候 Windows Container 就是一個還不錯的選擇，如果把資源控制洽當，透過最小程度的改 code 與套用 Kubernetes 的設定與 CI/CD，Windows Container 還是可以享受到許多優點，筆者是報著跑得好好的服務為什麼要重寫呢？時間應該浪費在追求更好的商業機會。
gMSA，這個大概是除了不想改 code 外最大可能用 Windows Container 的原因了，在部份案例中帳號密碼的管理一定要透過 Windows ActiveDirectory 服務，並要求要隨時更換密碼，如果使用 gMSA，服務團隊就不用再花心思變更密碼，所有的密碼都交由 ActiveDirectory 服務管理，這個在安全上會增加非常多。至於要怎麼做到 gMSA for your Windows Container，筆者會專門做一篇來介紹。
看完前面美好的世界，現在來講缺點：
- Windows OS size 太大
- Windows Node autoscaling 速度太慢
- Windows Pod image size 太大
- Windows Pod autoscaling 速度太慢
- 可能的高效資源使用率
- No build-in Prometheus Exporter
Windows OS size 太大與 Windows Node AutoScaling 速度太慢。一個 Windows OS，即使是用 Windows Server Core，但要維持良好運作需要 40GB 的磁碟空間，這大大的影响到 Windows Node 的 AutoScaling，在筆者的實際的使用體驗，一個 Windows Node 從 AutoScalor trigger Node Scaling 到 Node Ready，往往需要六分鐘起跳的時間，而相同的操作在 Linux Node 就只要一分鐘左右即可以完成，這大大的影響到 Kubernetes 優點。
Windows Pod image size 太大與 Windows Pod autoscaling 速度太慢。類似與 Windows Node 的問題在 Windows Pod 也是同樣出現，一般來說如果使用 Windows Server core + IIS + .Net Framework 4.5+，一個 image 太小是 5GB 起跳，所以 image pulling 的時間就是一個挑戰，筆者的建議要把 container registry 服務儘量的與你 Production 環境接近，因為這非常的影響你的 Service 是不是可以快速的反應。這個問題我相信微軟自己也有注意到，最近也漸漸看到小於 1GB 的服務可能性出現，相信未來 Windows Container 還是有他的市場，尤其是加上 gMSA 後。
可能的高效資源使用率，這明明應該是優點，但筆者為什麼把他放缺點？因為在 Container 的世界理應可以透過資源需求的衡量達到最大程度的高效資源使用率，但其實在現實的世界又取決於 Windows 平台的資源使用率，所以常常服務團隊擔心資源不夠一直加 Pod 的資源需求，這就造成資源的可能浪費，不過如果透不斷的觀察與檢討，資源其實還是可以省下來的。
No build-in Prometheus Exporter，有用過 Prometheus operator 都對於一個 command 就佈署好 Prometheus 感到非常的滿意，但是 Prometheus 的 Node exporter 目前是沒有 Windows Node 版本，所以筆者是透過另一個 open source 專案 Windows Exporter 抓到 metrics。至於怎麼實做，會有另一個專門篇幅介紹囉 :D。
講了那麼多的 Windows Container，筆者對於這個冷門的技術一直抱著它可能不會大流行，但在某個情境下它是可以派上用場的看法，所以只要確保團隊已經對 Windows Container 做了通盤優缺點評估，它可以是成為服務團隊的即戰力。而下述是筆者幾個小建議，做好下述幾樣，Windows Container 的不適感還是可以降低不少。
- 最佳化 Docker image 下載速度。
- 指定一個 Base image
- 佈署或打包 Windows Node 時就下載好 Base image
- Don’t always pull image for your Pod
上述幾項建議是筆者在專案的進行中有所感的，做好上述幾項還是可以享受到 Windows Container 的便利哦。
至於 Kubernetes for Windows 實做，筆者會專門寫一篇文章介紹。
