概要

2018年12月10日から13日にかけてシアトルで開催された Kubernetes Contributors Summit と KubeCon + CloudNativeCon North America 2018 に参加したのでその様子を報告する。

 

会場はダウンタウンにある Washington State Convention Center で、カンファレンスの定員 8,000人が早々に売り切れになったことからも分かる様に大盛況だった。

シアトルは北緯 48度にあり、思ったよりコンパクトな街であった。東京よりちょっと寒く、ほとんど毎日雨が降っていたが雪が降ることは稀だそうである。スターバックスの発祥地だそうで、会場のコーヒーにもロゴがついていた。

Kubernetes Contributor Summit

前日にパーティがあったのだが、日本人参加者が 10人以上いて、前回に比べて急に増えた様に感じた。パーティの総参加者数は 358人だそうで、これも前回のおよそ倍である。

 

 午前中は、新しい Contributor 用のトレーニングコースの他はメイントラックの 1本で、午後は 4つくらいのトラックに分かれていた。

午後の Unconference セッションは、提案を会場の壁にカードに書いて貼り出して得票  (「・」の数) で選ぶというアドホックな感じが良かった。

当日のスケジュールは https://kcs2018.sched.org/ に、セッションの録画は

https://www.youtube.com/playlist?list=PL69nYSiGNLP0kaZWKZc9KizriafE4pzh0 にある。

 

Technical Vision for Kubernetes

Google の Brian Grant氏が、SIG Architecture の Co-chair の肩書で話すセッションである。

コードの品質が大事だとか、リリース管理をしっかりやる (中途半端な機能をつっこんだりしない) のが大事だといった話から始まった。成熟したプロジェクトとして、どの辺に課題があってどう直していくべきかといった話を総合的にしていた。Kubernetes の革命的アイデアは API 設計だと (宣言的であるといったこと) 言っていて、Kubernetes のアーキテクトに言われるとまあそうかなという気もした。

具体的な課題は多岐にわたって述べられており、以下のようなものがあった。

  • サービスメッシュが提供する機能 (サービスディスカバリやロードバランサ) は Kubernetes も提供しており、混乱の元である
  • Endpoints (Kubernetes のリソース) はスケーラビリティ等の観点から作り直す必要がある
  • Service と Ingress にはいくつもの問題 (ポータブルでないとか、Ingress はデフォルトに含まれてないしGAでもない等) がある

また、インフラオーケストレーションの話があり、ノードを意識しないでクラスタを使えるようにするのが目標で、SIG cluster lifecycle でやっていると言っていた。

 最後に SIG Architecture の紹介があり、Kubernetes の信頼性を高めてリリースも定期的にしていく旨を話していた。

なお、SIG の Charter は https://github.com/kubernetes/community/blob/master/sig-architecture/charter.md にある。

 質疑では、コピペされたコードがたくさんあって直したほうがいいと思うんだけどどうなの？という質問があり、ぜひ直してくれという回答があった。

 

Security Through the Ages

Google Cloud を担当しているエンジニアによる発表である。まず、セキュリティは複数の SIG にまたがる問題であるという説明があった。Kubernetes 1.2 (2016年3月) の頃のセキュリティ機能 (あまりない) の説明をした後、最近のリリースである 1.12 では機能が大分充実してマルチテナントも実現しつつあると説明していた。

次に、過去にどんな CVE があったかという話があり、先週話題になった CVE-2018-1002105 の話もあった。重大な脆弱性という意味では初めてではないが、報道の注目を集めたのは初めてであるといっていた。

 セキュリティの新機能として Enhanced Service Account というものが紹介されていて、token に期限を設けたりして Service Account よりよくなっていると言っていた。Kubernetes のリソースとしては TokenRequest 等になり、 1.12 で Beta だったり、1.13 で Alpha として入ったリソースもあるといった説明をしていた。

 また、gVisor や Kata Containers 等の Sandbox でセキュリティを強化することもでき、Kubernetes 側でも RuntimeClass 等のサポートがあると説明していた。

 また、ノードアイソレーションの強化として、ノードの label や taint を書きかえられなくしてノードによるマルチテナントの分離を確実にしていくといった話があった。

 Kubernetes の依存するサードパーティコードは 100万行以上あって、必ずしも アップストリームのフィックスに追従できていないという話もあった。

 

State of Networking

 Tim Hockin 氏 (Google) から各種ネットワークの機能についての現状の説明があった。

1.12 で Traffic shaping 機能が CNI に追加され (kubenet に以前からあったもの)、kubenet の deprecation も少しずつ進んでいるようである。 

Ingress に関しては、Controller 毎に設定に互換性がないことなどが 2017 年の KubeCon のホットトピックであったが、あまり進展がないと言っていた。また、IPv6 とデュアルスタックについては (これも長期間かかっている話題である)、デュアルスタックの KEP はほぼできたが、 API 変更を伴う大きな変更が必要なので手伝ってほしいといった説明があった。

 数年前から  node-local services  と呼ばれて議論されていたものは、最近議論に進展があり、一部の機能が alpha として 1.14 に入るのではないかと言っていた (参考: PR #640 https://github.com/kubernetes/enhancements/pull/640 )。

 他にマルチネットワークや ネットワークサービスメッシュ (サービスメッシュに似ているが L2/L3 が対象) の話もあった。

また、DNS に関しては、Kubernetes は DNS を濫用しているが、互換性の問題があるから変えるのが大変でさあどうしたらいいかといった問題提起があった。

オープニング

オープニングで、Kubernetes がどれだけ人気があるかという話をするのも恒例という印象があるが、今回は kubernetes.io のアクセス数をシアトルの NFL チームやスターバックスのサイトアクセス数と比較していた。

 続いて CNCF プロジェクトの最近の動向の紹介があった。 

  • Helm が インキュベータープロジェクトとして加わった。この手の YAML を生成するツールはいくつかあるが、これを機に Helm に収斂していくのかが気になった
  • Envoy はインキュベーションを卒業してマイルストーン達成したと言っていた
  • RedHat が etcd を CNCF に寄贈した

その他

Knative という最近公開された FaaS (function-as-a-service) があるが、GCP ではワンクリックで使えると宣伝していた。今回はあまり目玉となるような新しい製品やプロジェクトの発表がなく、また、大規模ユーザの話はあったものの、YAML 生成の話や監視データストアの話といったこじんまりしたものであった。

 Borgの頃の昔話や Kubernetes の絵本の朗読をキーノートでやっていたりして、話としては面白いが技術ネタがあまりなかったのかなという印象を受けざるを得なかった。

スポンサーブース

  • 小規模スポンサーの数が前回の 6 倍くらいに増えた
  • Rancher など人が絶えないブースがいくつかあった
  • CNCF プロジェクトのロゴのついた衣類を CNCF が売っていた。売れ行き好調の様だった

一般セッション

CRDs Aren’t Just for Add-Ons Anymore

Tim Hockin 氏 (Google) によるライトニングトークでの発表である。

 CRD (CustomResourceDefinition) は元々 Kubernetes API をユーザにちょっと利用できるようにするといったものだったが、Kubernetes Operator が作られるようになって、Webhook で検証もできるようになり、Kubernetes のネイティブ API と区別があまりつかないように進化した (しかも Kubernetes のコードを変更しないで API を追加できる) といった話をしていた。

 どの程度本気で言っているのかよく分からなかったが、将来は Pod や Service  などほとんどのリソースを CRD として実装できるのではないかと話していた。

    

Real-time Vision Processing on Kubernetes

Google によるかなり実験的なプロジェクトの話である。まず、発表者は Computer Vision のプロではないため、このセッションでは主に Kubernetes の話をすると説明があった。

 リアルタイムの視覚処理は Kubernetes の普通のワークロードではないから、どのくらい上手くいくか調べるために敢えてやってみたという趣旨の発表だった。実効応答時間が 30ミリ秒以下である必要があるようだ。 USB 接続のアクセラレータのついた ARM のボードで構成したクラスタを使っている。入力データ (画像) が巨大なので Pod 間で共有メモリを使ってデータを共有させるとか、big-little ARM を Kubernetes がうまく扱えないから Container の Core Affinity を使っているといった、あまり汎用性のなさそうな話をしていた。

 

Using Kubernetes to Offer Scalable Deep Learning on Alibaba Cloud

タイトルの通り Alibaba Cloud でやっていることの説明で、Alibaba Cloud では Kubeflow と arena を使っていて、ヘテロジニアスな計算資源 (CPU, GPU など種々の計算資源) を効率的に管理するのが難しいと言っていた。

arena (https://github.com/kubeflow/arena) というのは Alibaba Cloud がオープンソースにしたツールで Kubeflow をベースにしているが、Kubernetes を隠蔽することでデータサイエンティストから扱いやすくしたとのことである。複数ノードを使った学習が CLI から簡単に実行でき、ノードや GPU の利用状況も簡単に確認できるといったデモを行っていた。

Pod 間での GPU 共有も実装済で、近々オープンソースにするといった話もしていた。

実際の例として、weibo で使っているとか、最適化することで native TensorFlow より 45% 速くなったといった例を挙げていた。

 

Deep Dive: Network Service Mesh BoF

2017年の KubeCon ではサービスメッシュがホットトピックだったが、今回はネットワークサービスメッシュと言っている人達がいた。公式サイトにも “Inspired by Istio” とあるように、サービスメッシュを意識して付けられたネーミングのようである。サービスメッシュは L7 レイヤであるが、 ネットワークサービスメッシュは L2/L3 レイヤのものである。

https://networkservicemesh.io/ にここでの資料および Intro セッションの資料がある。

ネットワークサービスメッシュが何のためのものかといった話は既に Intro セッションで説明されたようだ。本セッションは Deep Dive セッションなので、どのような Kubernetes リソースを使って ネットワークサービスメッシュが実現されているかについての説明がメインであった。

 NetworkServiceManager は Kubernetes では daemonset として動いていて、ネットワークサービスの情報は NetworkServiceRegistry (Kubernetes では CRD として実装) に集められ、NetworkServiceManager がそれを元にネットワークサービスの接続 (トンネリングプロトコルであればトンネルの設定も) を行う。

Pod 間の通信は NetworkServiceClient (NSC) と NetworkServiceEndpoint (NSE) というものに抽象化されるといった話をしていた。

他に Monitoring 機能もあるといったことや、ネットワークサービスメッシュに属さないサービスに接続するための proxy NSM といったものもあるという話をしていた。

 

Container Security and Multi-Tenancy Tales from Kata and Nabla

Ricard Aravena 氏と James Bottomley 氏による発表である。James を最初に見たのは 15年くらい前の Linux Symposium だが、今でも最近流行りの low level stuff をやっているというのが感慨深い。

コンテナ環境ではセキュリティが問題になるが、カーネルの脆弱性の影響を回避するために seccomp や capabilities を使ってコンテナからアクセスできるカーネルの機能を制限する (kernel footprint を減らす) という方法があると話していた。一方でちゃんと設定するのがとても難しいという話もしていた。

個々の実装についての話題では、先ず、Kata Containers の最近の変更点として shim が v2 になり、Container 単位ではなく Pod 単位で用意すればよくなったという話があった。

 Nabla containers についての説明もあった。Nabla containers は 7つの標準的な syscall しか使用しないため、Linux だけではなく、Windows や AIX の上でも動くと言っていた。Nabla containers の中身は Solo5 unikernel とその上で動く rumprun library OS で構成されている。

Solo5 は tender というものを持っていて、qemu などいろいろな環境の上で動かすことができるが、ここでは nabla tender (ややこしい名前である) という POSIX syscall の上で動かすためのものを使っていて、仮想化は必要ないようである。

rumprun は NetBSD を基にした library OS というもので、mmap() や fork() が動かないなどのいくつかな重大な制約がある。

 ここで HAP – horizontal attack profile という指標を持ち出して、各コンテナのセキュリティを評価していた。これはカーネルコードの行数あたりのバグ密度と実行される行数を掛けたもののようだが、発表では ftrace で実行されたカーネル関数を数えて代用していたようである。gVisor はこの指標では Docker 並みあるいは悪い数字になってしまうと、会場の笑いをとっていた。Nabla containers はこの metric にあわせてチューニングしてあるから一番いい成績とのことであった。

 Nabla containers の将来の展開として、kernel address space を分割してセキュリティを強化できないかなどと話していた。