KubeCon2017感想: Kubernetes in 2018
先週12月6日から8日にかけてTexas Austinにて開催されたKubeCon + CloudNativeCon2017に参加してきた．具体的なセッションの内容などはMercariのTech blogに上がると思うのでここでは簡単に自分なりの感想と概観をざっくりと吐き出しておく．
KubeCon 2017の3日間と今後のKubernetesの（大きな）展望は2日目のClayton Coleman氏によるKeynoteのWhat’s Next? Getting Excited about Kubernetes in 2018が総括をしていると思う．自分の今取り組んでること，今後取り組みたいこと，も結局これに集約されていると思う．この発表の中で今後，特に直近の2018年に，k8sでフォーカスが当てられると述べられていたのは以下の7つの分野である．
- The year of service mesh (make microservices easier)
- Data for everyone (make data workload easy)
- Whither serverless (integrate serverless natively)
- Defining App (Improve app deployment and config easy)
- Extensible and secure workload identity
- Policy multi-tenancy integration
- Better containers
以下では特に上の4つについて具体的に取り上げる．
The year of service mesh
今回参加した人，もしくはセッションリストを眺めた人は分かると思うが今年のKubeConはSevice mesh，具体的なソフトウェアとしてIstio，が多くのセッションを占めていた（KubeCon帰りの人が口をそろえてIstioに興奮していたという話も聞いた）．
Service mesh（Istio）の素晴らしさ，期待感，はmicroservicesを真剣に取り組んでいるひとにはかなり響くと思う．Service meshはmicroservices間をいかにResilientに接続するか，いかに共通化をおこなうか，に対する現時点での最適な解になりうる．
microserviesには（BoundedContextが守られる限り）各サービスがそのサービスにおいて最適な技術，最適な言語を各チームが選択できるという利点があると言われる．が，実際にその利点を活かしてReliableなサービスを運用しようとするとそれは容易なことではないことが分かる．ネットワーク越しに各サービスが隔離されている場合には以下のことを考える必要がある．
- Load-balancing (HTTP, gRPC)
- リクエストが失敗した場合のRetry
- リクエストのRate limit
- Circuit breaker
- サービス間の認証/認可（Authz，Policy）
- Secure connection（TLS）
- 共通のTelemetry data（logging）
- …
Service mesh以前にこれらを実現するには，というか実際に私が現職でやろうと思っていたのは，各言語毎にSDK的なものを準備することだった．これだけではなくアプリケーションエンジニアにもある程度DevOps的な視点を要求する必要があり，SRE的なチームも注意深く各microserviceに目を配る必要があった．
Istioはこれらをネットワークレイヤーで解決する．具体的には以下の図のように各サービスにSidecarとしてProxyを置き全てのリクエストがそのProxy経由で行われるようにする．
Service AがService Bにリクエストを投げるときはService AのProxyを通りService BのProxyを通ってService Bに到達する．Proxyが全てのリクエストをインターセプトし上述した問題を担う（e.g., API Ratelimit）．各Proxyの振る舞いはControl PlaneであるPilotとMixerが中央管理する（Istioに関してはGCP podcastの#85 Istio with Varun Talwar and Sven Mawsonもわかりやすくて良い）．
このアーキテクチャの利点はアプリケーションのコードを変更する必要がないところである．アプリケーションは何も考えずに対象のサービスにリクエストを投げれば良い．つまりアプリケーションエンジニアにはアプリケーションのロジックそのものに集中してもらうことができる．またSREはControl Planeの中央管理機構を利用して容易にアプリケーションのResiliency/Reliabilityを助けることができる．
Istioはまだ登場したばかりのソフトウェアであり検証は必要だがmicroservicesを成功させるためには重要なキーとなりうるのは間違いない．これ以外にもmicroservices on k8sのためのソフトウェアは2018年も更に登場してくると思われる．
ちなみにIstioのProxyにはEnvoyが使われているが，これを開発したLyftがいかにEnvoyを使いつつmicroservicesアーキテクチャへと進化していったかというセッションThe mechanics of deploying Envoy at Lyftは相当面白かった（PHP monolithからGoやPythonを使ったmicroservicesって共感しかない）．
話はズレるけどNginxからEnvoyという流れも今後は増えると思う（開発の速度やオープンさ，CloudNativeAppとの親和性といった理由で．もしくはLyftでの実績もあるけど）．例えばOur Move to Envoyとか．私も次に機会があれば使いたい思っている．
Data for everyone
もう一つはk8s上でMachine Learning（ML）のworkload（trainingとserving）を走らせる方向．実務でもそちらの手伝いをしていて実際にMLのいくつかのサービスをk8s上で動かし始めている．
具体的にはメルカリの今年1年間の機械学習の取り組みとこれからに書かれているように
・ローカル環境のMeCabと本番環境のMeCabが違う問題
・誰かのデプロイによって、誰かのモデルがdegradeしちゃった問題
・開発環境の構築に時間がかかる問題
・大規模なモデルの管理とデプロイをどうするか問題
・毎朝稼動しているモデルの精度を気にしながら、別のモデルの実験に集中しないといけない
といった問題をk8s上でImmutableなDeployを実現すること（+SpinnakerによるCDを利用すること）で解決してきた．
これにより多くの問題を解決した一方でHot Dogs or Not” — At Scale with Kubernetesで触れられたように以下のような課題も生んでしまった…
つまり現状だとData ScientistにContainerとは何か，KubernetesのService/Persistent Volumeとは何かImmutable Deploymentとは何かといったMLの本質とは違う概念を理解してもらわないといけない．
k8sの上でその利点を最大限に活かしつつ今後さらにML workloadを発展させるためにはData scientistにはk8sを意識させない仕組みが必要になる．また現状はCPUしか使えていない．GPU k8sクラスタも今後は必要になる．
この方向としてKubeConではTensorflow on k8sを容易にするkubeflow や（Stream基盤として）Kafka on k8sの運用を容易にするための kafka-operator についての発表があった．
いずれにしても2018年はこの分野もさらに発展していくと感じた．
Whither serverless
次にServerless（FaaS）on k8sの方向．正直実務ではほとんどServerless on k8sは考えられていない．もちろんこの分野でOpenWhiskやOpenFaaS，Kubeless，Fissionという流れは知ってはいたが必要だと思ったことが少ない．S3あってこそのLambdaと言われるようにイベントの生態系あってこそのFaaSなのでまだその生態系が社内で整ってないとも言える．
Glue Codeのデプロイ先としてはしばらくはLambda/Cloud Functionsを利用するだけだと思う．
Defining App
もう一つがk8sのmanifestを簡単にしましょうという流れ．k8sでアプリケーションをデプロイしたことがあるひとはわかると思うが現状はとにかく大量のYAMLを書かないといけない（慣れれば余裕なんだけど）…
これを改善するための方法として一番ぶっ飛んでいたのが https://metaparticle.io/ というプロジェクト．Dockerfileとk8sのmanifestをそれぞれ書くのではなく，全てをアプリケーションコードに書いてしまいましょうということをやろうとしている．
他だとHelmとかksonnetがこの流れの代表的なプロダクトだが今のところ私はあまりここには期待していない．SpinnakerによるContinuous Delivery に書いたように弊社ではk8sのデプロイを全てSpinnakerに集約している．Spinnakerによりmicroservices化を加速させることができたと思っているため今後もしばらくはSpinnakerをk8sのデプロイ中心においておきたい．
現状のSpinnaker課題はGUIでの設定値を管理していることなので，来年にはspinnaker/pipeline-templates を使いDeclarative Continuous Deliveryを推し進めていきたいと思っている．
Boring kubernetes
会議中にいくつかのセッションで語られていたのは「Boring kubernetes」というワードである．インフラのインフラになったk8sがいつまでもExctingであってはいけない．アプリケーションを支えるインフラはBoringでないといけない．Kubernetesの安定化も大きなテーマであったと思う．
会議中に紹介されていた bgrant0607 氏の書いた以下のk8sのsystem layerの図がとても良かった．
このレイヤーの下の部分がBoringになりつつあるからこそ，上のEcosystem，例えばmicroservicesやML，が盛り上がってきているのだと思う．今後のこのEcosystemにいかにのるか，もしくはこのEcosystemの上に自分たちのツールをちゃんと書けるかはますます非常に重要になってるくると思う．
まとめ
他にも OpenPolicyAgentによるPolicy管理やGrafeasによる安全なSoftware Supply Chain（CD）の構築やOpenCensusによるStats/Tracingの共通化など書ききれないほど多くのアイディアを得られることができた．とにかく学びしかない会議だった．来年も行きたい．
