2日目には、Kubernetesの最新情報を始めとする多くのトピックが紹介された。ここからは、Kubernetesの今とこれからを知ることになる。Sinha氏が挙げたのは3つのポイント、「Security」「Application」そして「Experience」だ。最初のSecurityはわかりやすく言えば、前日に発表となったgVisorの紹介を再度ここで行ったというものである。従来は、特権を持つカーネルのリソースをコンテナが分け合うことで思いもよらない脆弱性を招く可能性があった。それを防ぐため、gVisorはコンテナランタイムを仮想マシンのように分離したプロセスで実行(Googleはこれを「サンドボックス」と呼ぶ)しており、すでに多くの注目を集めている。Sinha氏が「gVisorはKubernetesと同じぐらい画期的なイノベーション」と語るように、セキュリティを高めることがエンタープライズにおいては重要視されるという事実を意識しての発言だと思われる。gVisorの概要2番目のApplicationは少し説明が必要だろう。Kubernetesでは主にステートレスなアプリケーションを想定して、Podの複製や起動/停止などが行われる。途中でPodが異常終了したとしても、再起動をかけてくれるのはKubernetesだ。ECサイトならフロントエンドのWebサーバーなどは常にクライアントからのリクエストを受け取って処理を続けるプロセスとして使われる。その裏側でリコメンドを出したり、会員のログインを処理したりといったプロセスは、永続的なストレージとの接続が必要となる。いわゆる「ペットと家畜」の例えで言えば、ペットに属するような扱いを要求するプロセスとなる。その意味でStatefulSetというWorkloadが用意されたのは正しい進化だろう。StatefulなアプリケーションをKubernetesで管理運用するのは難しい。そこで登場したのがOperatorだ。Operatorを使うことで、KubernetesのAPIやコマンドを利用することなくStatefulなアプリケーションを運用できる。Sparkのアプリケーションで、1つのマスターと2つのスレーブノードによってシェイクスピアの作品の単語数を数えるというサンプルアプリケーションを、Kubernetesで実行するものだ。Sparkのマスター、スレーブ、データストアとの接続など、いかにもStatefulなアプリケーションにありがちな面倒なことを、設定ファイル1つで完了する辺りは、派手さはないがStatefulなアプリケーションの運用に悩んでいるエンジニアには響いたのではないだろうか。Hat)が推進するKubernetesのアプリケーションフレームワークとして注目すべきだろう。Monitoringとして紹介された内容を再度言及したもので、Kubernetesだけではなくインフラストラクチャーのモニタリングも包括的に可視化が可能であるという内容だ。ポイントとしては、オンプレミスのPrometheusとの連携が可能になったということでオンプレミスのKubernetes、GKEのどちらからもメトリックスを取得してモニタリングが可能だという点だ。最後のポイントはExperience、これは特にデベロッパーに向けての開発の新機能という部分だ。Sinha氏がデモとして選んだのは、Googleが2018年3月に公開したSkaffoldというツールだ。これはデベロッパーがコードをローカルで編集しただけで自動的にビルドが実行されKubernetesのクラスターにデプロイがされるというツールだが、Sinha氏のライブデモではうまく行かずに失敗した。実際にコードを書くデベロッパーにとって、開発から実装までスムーズに行えるという部分でもエコシステムの拡大を実感させるデモとなった。Philips氏はOperatorの紹介だけを行った。TicketmasterではPrometheusの実行に利用されていることを紹介し、規模が大きくなるエンタープライズでの自動化の効果を訴求した形だ。Bankが失敗の事例を紹介したが、2日目は成功事例としてFTのコアビジネスであるWebサイト更新のシステムをKubernetesに移行したという話である。2016年に始まったという移行は、150以上のサービスとして実現されていたものを並行的にKubernetesに移行したという。アプリケーションのパッケージとしてHelmを全面的に利用しており、結果的にEC2のコストを80%も下げることができたそうだ。