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のノードとして利用できるようになるためにはさらに時間を要します。

そのため，仮想マシンを利用してノードを追加する場合は，最低でも数分以上がかかることが予想されます。