コンテナインスタンスとマネージドKubernetesサービスの連携

　コンテナのパッケージ化は解決済みの問題だ。インスタンスとKubernetesクラスタ環境の両方で、同じイメージ形式とDockerの「Docker」ランタイムがサポートされる。今後、ユーザーはワークロードを一方から他方へとシームレスに移動できるようになる。AWS FargateではKubernetesをまだサポートしていない。だが、AWSはその2つを統合すると約束している。それが実現すれば、コンテナユーザーはEKSを使用してAWS Fargateでコンテナを起動できるようになる。それまでは、Amazon ECSコンテナをAWS Fargateに移行するのが比較的容易だ。AWS Fargateでは既存のAmazon ECS構成、APIに加え、AWSの「Amazon Virtual Private Cloud」や「AWS Identity and Access Management」（IAM）との統合もサポートしている。

　統合に関するロードマップはMicrosoft Azureの方が進んでいる。ACIでは既にKubernetesプラグインを用意している。これはACIインスタンスをKubernetesクラスタのNodeへと変える仮想kubeletノードエージェントだ。kubeletを使用すると、ユーザーは別のKubernetes NodeではなくACIインスタンス上にPod形式でKubernetesコンテナワークロードをスケジューリングできる。ユーザーはACIとKubernetesを比較的簡単なプロセスで組み合わせることが可能だ。つまり、いわゆる無制限のNode（簡単に拡張可能なACIインスタンス）が既存のKubernetesクラスタに追加される。このクラスタはオンプレミス上か、AKSを使用してクラウド内か、ことによるとAWSマネージドインスタンス上にさえ配置できる。

ライフサイクルの分割

　コンテナの導入では、マネージドインスタンスとKubernetesクラスタ管理サービスの統合が理想として追い求められているのは変わらない。それが実現するまでは、マネージドインスタンスとKubernetesクラスタ管理サービスをコンテナライフサイクルのさまざまなポイントで使用することが可能だ。また、そうするのが賢明といえる。

　コンテナライフサイクルにはコンテナ開発者と同じくらいの多様性があることは間違いない。だが、次のような単純なライフサイクルもある。

1. 構築済みのDockerイメージとカスタムコードを使用してコンテンツを取得する
2. カスタムコードをゼロから作成するか、既存のパッケージから作成する
3. アプリケーションをコンテナランタイムシステムに配信する。ここにテスト段階と統合段階を加える
4. 運用システムに導入し、更新を自動化する。この段階には、運用とβ／カナリアコード用の冗長な環境が含まれる。つまり、ブルーグリーンデプロイメントだ
5. アプリケーションを実行し、オーケストレーションを行って、拡張する
6. 問題をデバッグ／修正してアプリケーションを保守する

　ACIやAWS Fargateなど、インフラが自動的にプロビジョニングされるコンテナインスタンスは、ステップ1から3については理想的なプラットフォームだ。また、ワークロードが軽いものや、使用頻度が低いアプリケーションの場合はステップ4から6についても理想的といえるだろう。では、ワークロードが大きいものや、キャパシティー需要が非常に変わりやすく、分散型の自動拡張を必要とするアプリケーションではどうだろうか。その場合、ステップ4から6についてはKubernetesクラスタを使用すべきだ。

　AWSはこのような形で市場に出してはいないが、KubernetesとAmazon ECSがコンテナオーケストレーションソフトウェアの選択肢になるのと同様、AWS Fargateは代替的な実行環境になる。