In-depth Demystification of Alibaba Cloud Serverless Kubernetes

Docker から始まる物語

物語は Docker から始まりますが、IaaS（Infrastructure as a Service）の先駆者たちが困難を乗り越えてきた努力や、クラウドコンピューティングのリーダーたちによって既に定められていたクラウドコンピューティング開発計画を見逃すことはできません。

10 年以上前、先駆者たちはユーザーの使用方法（クラウドプラットフォームが提供する機能）の単位に基づいて、クラウドを 3 つの層に分割しました。

⢠IaaS：Infrastructure as a Service。仮想マシンやその他の基本リソースをサービスとしてユーザーに提供します。

⢠PaaS：Platform as a Service。プラットフォームをサービスとしてユーザーに提供します。たとえば、プラットフォーム上のさまざまなミドルウェアサービスへのオンデマンドアクセスなどです。

⢠SaaS：Software as a Service。アプリケーションをサービスとしてユーザーに提供します。メールサービスなどです。

下の図に示すように、IaaS から PaaS へ進むにつれて、ユーザー（開発者や運用保守担当者）は基本リソースを認識する度合いが低くなり、ビジネスにより注力するようになります。

専門的なことは専門家に任せて、全体の効率を最大化します。たとえば、スタートアップのインターネット食料品会社は、自らコンピュータルームを構築し、ハードウェアを購入し、ネットワークストレージを設定し、オペレーティングシステムをインストールする必要はありません。むしろ、ビジネス開発と運用に注力すべきです。

10 年以上の発展を経て、IaaS は比較的成熟し、ECS、VPC、EBS などのさまざまな基本リソースが人々の心に深く根付いていますが、PaaS の発展は非常に遅れています。

早くも 2008 年、Google は App Engine サービスを立ち上げ、開発者がビジネスコードを記述して App Engine 上で実行できる開発プラットフォームを作成しました。このアイデアは開発者にとって非常に先進的で、完全に受け入れられるには至りませんでした。パブリッククラウドに加えて、オープンソースコミュニティの PaaS プラットフォームも左から右へ移行していました。その中でも、IBM の Cloud Foundry と Redhat の OpenShift が最も有名です。両者ともアプリケーションの迅速なリリースを実現するプラットフォームを提供することを望んでいましたが、どちらも冴えず、さまざまな互換性の問題により使いにくくなっていました。

2013 年に Docker が誕生するまで、開発者に完全に優しい形で、1 つのコマンドでサービスを立ち上げられる非常にシンプルな操作方法により、Docker はコミュニティで最も人気のあるオープンソースプロジェクトの 1 つとなりました。

Docker の利点は主に以下の点に表れています。Docker イメージは、依存すべき環境とアプリケーションを圧縮ファイルにパッケージ化し、Docker がインストールされている任意のマシンで直接実行できます。開発、テスト、本番までのアプリケーションのデプロイ問題を解決し、環境の一貫性を保証します。

Docker の成功は、技術革新ではなく究極のシンプルさにあります。cgroup や Namespace などの技術は既にカーネル機能に取り込まれていました。そのため、Cloud Foundry は以前は Docker を競合とは見なしていませんでした。これらの技術は既に Cloud Foundry で使用されていたからです。それどころか、Docker イメージの思いがけない機能により、Docker は真に「Build once, Run anywhere」を実現しました。

Kubernetes が江湖の地位を決定する

オリジナルの Docker はスタンドアロン版であり、OpenStack が仮想マシンを管理するのと同様に、大規模なデプロイシナリオ用の管理プラットフォームが必要でした。

初期の頃、コンテナ管理プラットフォームは百家中争われており、Mesos や Swarm などもありました。しかし、それらはいずれも IaaS の固有の思考から逸脱せず、コンテナを仮想マシンとして管理することに焦点を当てていました。Kubernetes の出現まで、真に江湖を統一し始めたのです。Google の後押しと Borg から派生した成熟したアーキテクチャに加えて、より重要なのは、Kubernetes は誕生当初からコンテナの管理方法（Replica Set）と外部へのサービス提供方法（Service）を既に明確にしていたことです。

その中でも最も残念なのは、Docker 自身の管理システムである Swarm です。当時、Docker は既に台頭していましたが、Docker 社自体はまだ収益化を達成していませんでした。そこで、同社は Swarm Enterprise Edition を立ち上げました。Swarm も後期には Kubernetes の概念を多く導入しましたが、時既に遅く、クラウドネイティブエコシステムは Kubernetes の周りで繁栄していました。

Google が主導しているにもかかわらず、Kubernetes は十分な開放性を維持し、コンテナランタイム用の CRI、ネットワーク用の CNI、ストレージ用の CSI、デバイス管理用の Device Plugin、さまざまなアクセス制御、CRD など、リソース管理からインターフェース仕様までを抽象化しています。Kubernetes は徐々にクラウドオペレーティングシステムへと進化しており、さまざまなクラウドネイティブコンポーネントはこのオペレーティングシステム上で実行されるシステムコンポーネントです。

パブリッククラウドが Kubernetes をホスティング

Kubernetes はそのリーダーシップを確立しましたが、その運用保守はそれほど簡単ではありません。この背景から、パブリッククラウドはクラウド Kubernetes ホスティングサービスの立ち上げを試みており、たとえば Alibaba Cloud のホスティングマスターソリューションである ACK は 2017 年に提供開始されました。

ACK（Alibaba Cloud Container Service for Kubernetes）では、Kubernetes 管理コンポーネントのインストールと運用保守がパブリッククラウドにホストされ、ECS またはベアメタルが Kubernetes のコンピューティングノードとして使用されます。これにより、Kubernetes ユーザーのコストが大幅に削減されます。ユーザーは、クラウドプラットフォームから kubeconfig ファイルを取得することで、kubectl コマンドラインまたは RESTful API を通じてクラスターを直接管理できます。

クラスターの容量を拡張する必要がある場合は、ECS の数を調整するだけでよく、新規作成された ECS は自動的に Kubernetes マスターに登録されます。それだけでなく、ACK はクラスターバージョンのワンクリックアップグレードやさまざまなプラグインもサポートしています。ACK は複雑な運用保守作業をクラウドに移譲し、クラウドの柔軟性により、分単位のレベルでリソースの拡張を実現できます。

無制限の柔軟性を実現する

パブリッククラウドはプライベートクラウドよりもコストに注意を払います。プライベートクラウドでは、ユーザーのインフラコストは基本的に固定されており、オフラインになったサービスのためにユーザーがコンピュータルームにサーバーを駐車しに行くことはできないからです。対照的に、パブリッククラウドは従量課金モデルを提供します。

クラスターで実行されているタスクの大部分が長時間実行され、リソース要件が固定されている場合、ACK を使用しても問題ありません。しかし、大量のジョブタイプタスクがある場合や突発的なトラフィックがある場合、仮想マシン上でコンテナを起動するための一時的な拡張スキームである ACK は、柔軟性に欠けます。

たとえば、オンライン教育会社は、毎晩 7 時から 9 時の授業ラッシュ時に数万个の Pod を一時的に拡張する必要があります。ACK を使用する場合、事前にこれらの Pod の容量を評価し、それを ECS のコンピューティング能力に変換し、事前に対応する数のコンピューティングノードを購入して Kubernetes に追加し、さらに 9 時以降にこれらの ECS を解放する必要があり、非常に煩雑です。

そこで、Kubernetes の使用方法と互換性があり、かつ Pod を秒単位で起動でき、Pod 単位で課金できるソリューション（ACK はノード単位で課金）はあるでしょうか？

AWS が最初に Fargate を提案しました。これは、実際のノードなしに Pod 単位として Kubernetes クラスターに追加できます。Alibaba Cloud も 2018 年に ECI（Elastic Container Instance）という類似の製品を立ち上げました。各 ECI は Pod ですが、この Pod はクラウド上でホストされています。

Kubernetes は ECI を 2 つの方法で使用します。ASK（Alibaba Serverless Kubernetes）と ACK+Virtual Node です。ASK では、コンピューティングノードは完全に Virtual Node になります。Virtual Node は ECI のライフサイクル管理を担当する仮想の無限容量コンピューティングノードです。Virtual Node は Kubernetes に登録され、Kubernetes にとっては通常のノードです。ユーザーはネイティブの Kubernetes YAML を送信して Pod を作成するだけでよく、Kubernetes の使用と完全に互換性があります。

Virtual Node は通常の ACK ノードと混合することもできます。ユーザーは長時間実行タスクを ECS ノードにスケジュールして実行し、ECI の迅速な起動（10 秒以内のコンテナ起動）を利用して、バーストや短周期タスクを ECI にスケジュールすることで、最適なコストを実現できます。

現在、ECI は多くのインターネット企業や人工知能企業に採用されています。今後の記事では、ECI の移行時に典型的なユーザーが遭遇した技術的な問題や課題を徐々に共有していく予定です。

まとめると、今日は技術発展の観点からコンテナと k8s の発展を振り返りました。パブリックテクノロジーが徐々にボトムレイヤーに沈降していることがわかります。k8s も ServiceMesh も、それぞれサービス管理とトラフィック管理をインフラストラクチャに沈降させようとしています。しかし、これらのコンポーネント自体にも管理コストがあるため、クラウドホスティングへと進化してきました。今後、技術が沈降するにつれて、クラウドコンピューティングが提供する機能はさらに上方に移動し、より包括的で豊富な機能を提供することで、開発者がビジネスに注力できるようにします。