2018年はKubernetesにとって飛躍の年
コンテナのオーケストレーション・ツールの歴史を振り返ると、ここ1、2年で大きく状況が変わりました。2017年の初頭はまだ、コンテナのオーケストレーション・ツールの製品において、デファクトと呼べる製品は存在せず、Mesosphere DC/OS、Docker SwarmやCloud Foundryも含めさまざまな選択肢がありました。とくに筆者は、当時、Cloud Foundryに関しては注目しており、海外でも多くのユーザに導入されているのを見てきました。
しかし、2017年中盤にかけ一気に情勢はKubernetesに傾き、DC/OS、Docker Swarm、Cloud Foundry なども相次いでKubernetesのサポートを表明し、さらには、パブリッククラウドベンダも相次いでKubernetesへの対応を表明していったことで、流れは一気に加速しました。さらに、開発支援ツールやCI/CD、運用、監視、バックアップツール、セキュリティチェックツールなど次々に登場し、さらに2017年の後半になるとサービスメッシュ技術 (Istioなど) も注目を浴び、Kubernetesを取り巻くエコシステムも急速に拡大していきました。
ただ、日本ではまだ本番環境に適用する事例は少なく、多くの企業やエンジニアが情報を蓄え検証し準備していた時期でした。実際に、2016~2017年ごろのテクニカルセミナーでは、「 Kubernetesのこの機能ではこのようなことができます」「 こういった新機能があります」といった発表や記事が多かったように記憶しています。
2018年になると、こうした準備を終えた企業やエンジニアが段階的に本番環境へ適用を行い始め、本番環境への適用も徐々に始まった年と言えます。
2018年、Kubernetesはいよいよ本番環境へ
2018年、筆者もさまざまなテクニカルカンファレンスに参加し、Kubernetesに関連する内容を発表しましたが、印象的だったのは2018年12月に開催された「JAPAN CONTAINER DAYS V18.12 」でした。このイベントは大盛況で、基調講演はもちろん、いずれのセッションも盛り上がったイベントでした。
セッション内容も、「 Kubernetesでこのようなことができます」といった基本的な話ではなく、「 本番環境ではこのように考えます・実践します」といった内容も数多く見受けられました。
さらに、その直後、アメリカ・シアトルで開催された「2018/12/10-12/13 : KubeCon + CloudNativeCon North America 2018」は、1ヵ月前にチケットが売り切れ満員御礼となり、IT業界の名だたる企業もスポンサーをするなど世界中の企業や技術者がKubernetesに注目をするイベントになっていました。
Kubernetesの世界において、2018年を一言で言い表すならば「飛躍」の年だったのではないかと思います。
2019年コンテナオーケストレーションの世界にもサーバレスが現実的になってくる
Kubernetesの世界において、今、サーバレスの波が訪れています。1つはpodレベルでのサーバレスを実現するKnativeやOpenFaaS、Kubeless、Osiris。そしてもう1つはノードレベルでのサーバレスを実現するVirtual Kubeletです。
podのオートスケール機能はもともと、Kubernetes標準機能として提供され、指定した最小レプリカ数から最大レプリカ数まで水平方向にオートスケール(Horizontl Pod Autoscaler)が可能でした。しかし、この機能には1つ課題がありました。具体的には、リクエストがない状態や低負荷の状態でも、最小レプリカ数で指定したpod数を起動しておかなければならず、資源の無駄使いが一部で発生するという点です。
一方、Knativeなどはリクエストがない状態では、pod数を0に保ち、リクエストが発生した時点、もしくはリソース(CPU、メモリ容量)の使用状況や、リクエスト数の増減に応じてpod数を増減させる事ができます。負荷の無い状態では起動せず、負荷に応じてpod数の増減ができると言う点で、podレベルでのサーバレスを実現しています。
しかし、podレベルでオートスケール設定しておけば高負荷に耐えられるのか?安全なのか?というと決してそうではなく、高負荷時にpodを増加させるために必要なノードが十分に存在しているか、もしくはノードを柔軟に増やすことができるかを理解しておくことがとても重要です。
実際に、ノード数が十分に存在していなければ、急なリクエストの増加に対してpodを増やすことはできません。十分なCPUリソースが足りない場合は、podの起動時のステータスがPendingとなり下記のようなメッセージが表示されるでしょう。
Insufficient cpu.
これに対応するために、Kubernetesのノードも状況に応じて柔軟にスケールする仕組みが必要です。
そのため各クラウドプロバイダでは、Cluster Autoscalerの機能を実装し、ノードを自動的に増減する機能を提供しています。しかし、ここにも1つ課題があります。ノードは通常、仮想マシンを利用して構築しますが、仮想マシン(ノード) を新規追加するためには時間を要します。場合によっては数分ほど時間がかかる場合もあるでしょう。仮想マシンを構築し、さらにKubernetesのノードとして利用できるようになるためにはさらに時間を要します。
そのため、仮想マシンを利用してノードを追加する場合は、最低でも数分以上がかかることが予想されます。
各社のサーバレス・コンテナ・プラットフォームへの取り組み
一方で、仮想マシンを使わずコンテナを動かすための取り組み(サーバレス・コンテナ・プラットフォーム)が各社で始まっています。
この分野で一番最初に提供を開始したのは、Microsoft Azureの「Azure Container Instances(ACI) 」です。ACIの場合、秒単位の課金で数十秒でコンテナを起動することができました。
その後、この分野ではAWSの「Fargate」 、GCPの「Serverless containers」が提供されています。これらの機能を利用すると、サーバレスという名のとおり、仮想マシンの存在を意識せず、必要なときに必要なタイミングでコンテナを動かすことができるようになります。これを正しく利用することで、メンテナンスコストを大幅に削減することもできます。
Microsoftは2017年12月、このサーバレス・コンテナ・プラットフォーム(ACI)をKubernetesから利用するためのOSSプロジェクト、Virtual Kubelet を立ち上げ公開しました。この技術は Azure のプラットフォームだけではなく、次のような、他のプロバイダでも利用できるようになっています。
Alibaba Cloud ECI Provider
Azure Container Instances Provider
Azure Batch GPU Provider
AWS Fargate Provider
Hyper.sh Provider
Service Fabric Mesh Provider
Adding a New Provider via the Provider Interface
この技術が公開された当初は、まだKubernetesとつなげられるというレベルに過ぎず、Kubernetesの世界に完全統合まではできていませんでした。しかし、Microsoftは、その1年後の2018年12月、この技術をさらに発展させ、サーバレス・コンテナ・プラットフォーム(ACI)をKubernetesの仮想的なノードとして扱えるように、仮想ノード(Virtual Nodeパブリック・プレビュー版)を発表しました。
これにより、既存のYAMLマニュフェストファイルに対して、数行の追加設定を行うだけで、podをサーバレス・コンテナ・プラットフォーム(ACI)上で動作させることができるようになりました。起動時に、コンテナイメージをダウンロードするため、コンテナレジストリまでの距離や、ダウンロードするイメージのサイズに応じて起動時間は変わりますが、筆者の環境では、同一リージョンにあるコンテナレジストリから180Mバイトのイメージを入手し起動するまで、1podあたり30秒程で起動できるのを確認しています。
また、急激なリクエスト増加や高負荷に対応するために、一時的にpodを増加させたい場合、仮想マシンのキャパシティを気にすることなく、下記のようにpod数を手動で増やすこともできます。
$ kubectl scale --replicas=100 deployment/service-name
この例では手動で、100podを起動させていますが、通常であれば100台のpodを動かすために、仮想マシンのノードを何十台も用意しなければなりませんでした。しかし、仮想ノードを利用することで物理的な仮想マシン(ノード)の数は気にすることなく、仮想ノードの構築可能な上限値いっぱいまでスケールをさせることができます。また、手動でのスケールだけでなく、オートスケール(HPA)による増減も可能です。
最後に
Knaitveをはじめとするpodレベルでのサーバレス技術、さらには、Virtual KubeletのようにVirtual Nodeで実現するサーバレスを実現する技術、それぞれ機能改善や品質改善が必要な点はまだまだあり、Kubernetesにおけるサーバレスは始まったばかりと言えます。
それをふまえても、2019年はKubernetesにおけるサーバレスに対する各社の取り組みが、さらに活発になり実際に本番環境で使えるようになることが期待できる1年になるのではないかと筆者は考えています。
願わくば、近い将来、双方の技術が組み合わさった真のサーバレスが実現できるようになることを期待しています。