AKS のリリースから 3 年後、Microsoft の Windows Server Containers が Azure Kubernetes Service で一般提供されるようになりました。
AKSは2017年に導入されましたが、これは前年にリリースされたAzure Container Service for Kubernetesの代替として導入されました。Windows Server ContainersはWindows Server 2016のリリース以降から存在していたにもかかわらず、これらのサービスはLinuxコンテナーのみを対象としていました。
Azure上でWindowsコンテナを実行する方法は他にもあります。Azure Container InstancesやWeb App for Containers、あるいは大規模アプリケーション向けのService Fabricなどが挙げられます。Service FabricはMicrosoftが独自に開発したマイクロサービスプラットフォームで、Azureに深く組み込まれており、Azure Active Directoryなどの基盤サービスを実行します。
Kubernetesは業界標準ですが、元々はGoogleによって開発され、Linux向けに設計されています。KubernetesはGoogleのBorgクラスタマネージャーから派生したもので、Service FabricがMicrosoftで解決したのと同様の問題をGoogleで解決することを目的としていました。Borgの起源を説明した2015年の論文[PDF]では、コンテナを使用する理由について次のように述べられています。
Microsoft のライセンスプランは Kafka っぽいと思ったことはありませんか？Azure Functions の Kafka 拡張機能はいかがでしょうか？
続きを読む
「Borgのワークロードの大部分は仮想マシン（VM）内では実行されません。仮想化のコストを払いたくないからです。また、このシステムは、ハードウェアに仮想化サポートがないにもかかわらず、プロセッサに多額の投資を行っていた時期に設計されました。」
Windows企業として、Microsoftはコンテナ、そしてKubernetesの登場に2つの方法で対応しました。Windows側では、Windowsコンテナの導入に取り組み、その後、Linux上で稼働するKubernetesにWindowsノードを追加できるようKubernetesプロジェクトに貢献しました。ドキュメントには、「Windows専用のKubernetesクラスターを提供する予定はありません」と記載されています。
2 番目に、Microsoft は Windows 企業というよりクラウド企業となり、Azure 上で Linux をサポートし、.NET および SQL Server テクノロジを Linux に移植し、Azure 上で Linux コンテナーと Linux Kubernetes の両方をサポートしました。
MicrosoftのLinux実行への取り組みは成功を収めています。2018年後半には、Azure上のLinux VMがWindows VMを上回っていることを同社は認めており、現在ではその割合は大幅に高まっているはずです。
しかし、今回の新たな発表は、Microsoftのコンテナ導入におけるもう一つの側面、つまりWindows上でのコンテナ技術の活用をカバーしています。「WindowsアプリケーションとLinuxアプリケーションを単一のAKSクラスターで並行して実行することで、より幅広いアプリケーションの運用プロセスを近代化すると同時に、アプリケーション環境の密度を高め（ひいてはコストを削減）ることができます」と、Microsoftのコーポレートバイスプレジデント、ブレンダン・バーンズ氏は述べています。
Linux アプリケーションにとってコンテナーが有利になるのと同じことが、Windows アプリケーションにも当てはまり、Burns 氏が指摘するように、オンプレミスのアプリケーションを「リフト アンド シフト」したい企業は、そのアプリケーションを Windows 上で実行し続ける必要がある。
MicrosoftはWindowsコンテナのサポートを一般提供開始と発表しましたが、注意点もあります。Kubernetesは多くの要素で構成されており、詳細を掘り下げてみると、すべてがサポートされているわけではなく、一部のコンポーネントは最新バージョンのKubernetes 1.18でもアルファ版であることがわかります。例えば、CSI（Container Storage Interface）ドライバーを使用したストレージ操作を可能にするCSI Proxy for Windowsなどがその例です。これはAKS上のWindowsコンテナの信頼性が低いことを意味するものではありませんが、一部の機能の使用には注意が必要です。
追いつく
Windows on Kubernetesは現在も進行中のプロジェクトであり、長期にわたるものであり、Linux実装よりやや遅れているのも当然です。Microsoftは大きな進歩を遂げており、Windows Group Managed Service Accounts (GSMA)、コンテナ内でアプリケーションを別のユーザーで実行するためのRunAsUserName、CPUリソース制限の尊重といった機能をサポートしています。Kubernetes 1.19では、Hyper-Vコンテナを使用した分離機能が提供されます。
しかし、一般的に Linux コンテナーは AKS と Kubernetes で実行するのに適していると言えるでしょう。Microsoft がどのようにして完全な同等性を実現できるのかは分かりません。
Microsoftの一般提供開始発表は、AWSが2019年10月にElastic Kubernetes Service上でWindowsコンテナの完全サポートを発表したのに遅れています。ただし、これは魔法のようなものではなく、ドキュメントにも制限事項が記載されています。GSMAなどの一部の機能はAmazon EKSではサポートされていないため、Windowsコンテナに関してはAWSがAzureより優れているわけではありません。Google Cloud PlatformもKubernetes上のWindowsコンテナをサポートしていますが、まだ一般提供されていません。
Microsoftは、AKS（Windowsコンテナだけでなく）上のプライベートクラスターも発表しました。これは、インターネットではなくプライベートネットワーク空間内で管理されたKubernetesクラスターを意味し、セキュリティとコンプライアンスの面で役立ちます。また、AKSではマネージドIDが新たにサポートされ、資格情報を入力する必要がなく、信頼されたインスタンスを介してAzure ADユーザーとしてアプリケーションを実行できるようになります。®
