KubeCon + CloudNativeCon Europe 2018

5月1日から4日にかけてコペンハーゲンで開催された Kubernetes Contributors Summit  と KubeCon + CloudNativeCon Europe 2018 に参加したので、その様子を報告する。

会場は、空港と市街地の間に位置する Bella Center で、市街中心から地下鉄で5駅ほどの距離であるが、併設された変わった形のホテル以外には特に目立つ建物がない郊外という印象であった。

コペンハーゲンはデンマークの首都で北緯 56度に位置する。季節としては春であるが、この頃暑くなってきた東京とは違って、日本の感覚でいうと冬に近い寒さであった。高緯度なので日没は 9時頃で、イベントが終わっても外はまだまだ明るいというのは不思議な感じがした。

Kubernetes Contributor Summit は、メインの KubeCon の前日に開催されたイベントで、会場では他にもたくさんの co-located イベントが開催されていた。このイベントにはざっと数えて 200人以上集まっていたようである。

最初に 10分くらいで全体の説明があった後、 Current Contributors Summit という今話題の議論をする場と、New Contributor Summit という新しい Contributor にコミュニティでのやり方を教える場に分かれた。

github kubernetes/community  などの情報によると、前者では、

• Steering Committee 関係
  ・ 今後は Incubation は使わず “Associated” プロジェクトにする
  ・ WG (ワーキンググループ) は SIG を水平に横断する一時的なもの
  ・ 新しい SIG の提案は charter を作ってプルリクエストでやる

• ネットワーク関係
  ・ Pod Ready++ が 1.11 で alpha になるかも
  ・ Ingress は Openshift の routes をモデルにしてポータブルなものを作ろうとしている
  ・ マルチネットワークは WG で PoC を設計中
  ・ ネットワークプラグインとデバイスプラグインが協調しないので困っている。 Resource WG と Networking SIG で議論している

• CRD (カスタムリソース定義)
  ・ pruning (定義されてないフィールドを消す) をどうするか決まらないと GA にできない
  ・ 他にも 1.11 でいくつか alpha 機能が計画されている
  ・ versioning について議論中

といったことが話し合われたようである (私は不参加)。

参考:
・ https://github.com/tpepper/community/commit/36a5a8e124141cf58cef2165d0bf7bfb8c661564
・ https://hackmd.io/s/BJ2_1MHaz#

New Contributor Summit

New Contributor Summit は今回が初開催ということで、午前の3時間を全部使って、「オープンソースとは」という話から、具体的な Contribution の手順までを一通り説明するというスケジュールであった。私はこちらに参加した。

最初に GitHub の利用経験について挙手で簡単にサーベイしていた。結果は、既に GitHub にプルリクエストをあげたことのある人は数人で、大半が仕事で使っている人であった。

オープンソースにようこそ、とか言ってコミュニケーションの重要性などを説明していた。また、Kubernetes 独特のものとして SIG や WG の説明があり、その他、Git のリポジトリにどういうものに分かれているかといった説明もあった。

次に具体的なワークフローの話があり、 GitHub の Issue にプロポーザルを書くときは適切なラベル (sig/ kind/ triage/ 等決まっている) を付けて、SIG Leads と関連するデベロッパに CC しろとか、 SIG Meeting 等で周知しろと言っていた。そこでなんとなく同意がとれたら (“lazy consensus” と言っていた)、プルリクエストを出す段階だそうである。

どんどん貢献してほしい、また Meeting に出るようにしてほしいと最後にまとめていた。

SIG updates

Contributor Summit の午後に行われた。1つのSIG あたり 5分以内で、他の SIG に影響があるものを話せと司会が言っていた。全 Contibutor に周知したいことを話す場といった感じであった。

キーノートセッションは、初日の朝一番と夕方の最後、そして2日目と3日目の朝一番の合計4回に分けて行われた。

How Good is Our Code?

CNCF の Dan Kohn 氏による Opening Remarks は上記のタイトルであった。まず今回のイベントについての各種案内があった。今回の参加者は 4,000 人強で、前回のオースティンよりちょっと増えたそうである。

CNCF が規模を拡大しているといった説明の後、Juicero の問題を暴く Bloomberg 動画が映しだされた。Juicero はフレッシュジュースを売りにしていたが、去年会社は閉鎖された。そしてフレッシュつながりで、”raw code” (CI テストされてないコード) は素晴らしいよねという冗談みたいなツイートを紹介してみんな大笑いしていた。こういった聴衆の気を引く小話がうまく用意されているなあと感心した。

その後は Linux や Kubernetes のコード行数や脆弱性の話になり、テストが大事だよということを言っていた。また、CNCF の Interactive Landscape (l.cncf.io) という Cloud Native ソフトウェアのカタログサイトを紹介していた。

CNCF Project Update

オープニングに続いて Aqua Security の Liz Rice 氏 (この後のキーノートでもしばしば司会として登壇した) による CNCF プロジェクトの最近の動向の紹介が行われた。前回の KubeCon では 17 プロジェクトと言っていたが、今回は 20 プロジェクトに増えていた。

1プロジェクトあたり1 枚のスライドで簡単に最近の動向を紹介するものであったが、NATS (メッセージング)、vitess (MySQL 水平スケーリングクラスタ) などは開発者を登壇させたりデモを行ったりして長めに解説していた。

CERN Experiences with Multi-Cloud Federated Kubernetes

OpenStack Summit でおなじみの CERN が KubeCon でも行われた。Large Hadron Collider や Anti Matter Factory の写真を出して巨大科学であることを伝えたり、実験で発生するデータレートで会場を脅かすのはいつもの通りだなあと思って聞いていた。センサー出力は PB/s クラスだが、ストレージに保存する前に前処理をして 1-10GB/s のレートまで減らし、それを raw data として扱っているとのことである。

32万コアの OpenStack クラスタを運用していて、その上に 210 個の Kubernetes クラスタがある。だがそれだけでは足りないので自前でない他のクラウド上の Kubernetes とフェデレーションして使っていると言っていた。Kubefed を使っているそうである。

Container-Native Dev-and-ops Experience: It’s Getting Easier、Fast.

Azure の担当者が Visual Studio から Container の中をリモートデバッグできるとデモしていた。全部オープンソースになっていると言っていた。

Azure/vscode-kubernetes-tools のことだと思われる (以下 URL 参照)。
https://github.com/Azure/vscode-kubernetes-tools/blob/master/debug-on-kubernetes.md

実用上、どの程度役に立つかはよく分からなかったが、ここまで作り込んでくる Azure (Microsoft) はさすがだなと思った。

gVisor

gVisor が発表され、GitHub でもコードが公開された。あちこちで話題になっているので詳細は省くが、go 言語で Linux システムコールを実装し直したコンテナランタイムである。Linux に存在する脆弱性である「Dirty Cow」が回避できていることをデモし
ていた。さすが Google というか、よくも作ったなあといった感じである。

事例紹介

• Monzo Bank の障害

Monzo はイギリスの銀行のスタートアップである。イギリスでは規制緩和でこの様な銀行が作れるようになったが、日本の常識からすると、この様な銀行があることも、また、銀行の障害事例がおおっぴらに語られることも不思議な感じがした。
オープンソースソフトウェアを利用した 500以上のマイクロサービスで構築されており、取引のたびにリアルタイムで通知がくるのが特徴だそうである。

障害発生の2週間前に etcd の更新を行ったのが最初の原因で、ledger を更新した後にその更新を roll back したのをきっかけに障害が発生して、設定の更新が必要なことに気付くまで 1時間 21分の障害であったという説明であった。

fallback を用意してあったので障害時でも支払いは大部分うまく処理できたとのことである。今後はモニタリングをもっと充実させる事や、コミュニティと協調してやっていく事を教訓としてまとめていた。

• Financial Times (FT)

FT  が Content System の 150以上のマイクロサービスを Kubernetes に移行した話である。”Switching Horses Midstream” という題で、インフラを Kubernetes に切り替える以外にも他の改善作業が並行して行われていたというのが話のポイントであった。

2015年には自前のコンテナ管理ツールで動かしていたが、Kubernetes が安定してきたので 2016年末に移行を決断した。移行中は、各マイクロサービスを新旧両方の環境に用意していたとのことである。

移行したらシステムが安定した。社内 Slack チャンネルでの文句 (System についての良い指標だとのこと) も減ったとのことである。

大小含めて多くの会社がブースを出しており、Kubernetes がビジネスとしても注目を集めていることを実感した。ちょっと変わったものとしては、Ballerina (ballerina.io) というクラウドネイティブなプログラム言語を出している所があり、緑色のシャツを着た人が大勢で説明をしていた。これで書けば簡単にマイクロサービス化できるそうである。

他に、サーバレスや FaaS (Function as a Service) と呼ばれるものも流行っていて、あちこちのブースで紹介していた。nuclio

(github.com/nuclio/nuclio) の担当者に伺ったところ、オープンソースですごく速いんだと宣伝していた。

Kubernetes on Supporting $8 Trillion Card Payments in China

CaiCloud が中国のオンライン決済システムを Kubernetes 化したという話である。まず CaiCloud (caicloud.io、 杭州才云科技有限公司) について、中国でのコミュニティ活動や、 TensorFlow、 Kubeflow もやっていると自己紹介していた。

中国唯一の Interbank Network が助けを求めてきたそうで、規模は年間決済額が 14.95 兆USドル (2017年) で、最近世界中の店頭でよく見かける UnionPay のロゴもこれに含まれる。

既存の OpenStack/VM based のシステムがあり、これを “brown-field” (北米の表現で、土壌汚染の疑い等の理由で再開発が進まない既開発地のこと) と表現していた。導入にあたって、素の Kubernetes にはない以下の機能が必要だったそうである。

• multi-cluster/zones
• multi-tenancy
• multi-networking-plane

2015年から Docker を使っていて 2017 年に管理者の負荷が急増したそうである。そこで、7月に Caicloud と共に、3ヶ月で分析と設計をやって、アルファ版を作りながら調整し、今年2月にステージング、3月から実運用で動いていると経緯の説明があった。UnionPay の決済も Kubernetes 上で動くようになっている。

メインの成果物として、シングルサインオン (一回ログインすれば Kubernetes も OpenStack も使える)、マルチテナント、HA、 ネットワークの各種機能、既存ストレージ (NAS, Swift) との統合を実現し、派生物として CI/CD の導入やマイクロサービス化のコンサルもやったそうである。

Kubernetes のマルチテナントは Austin でも議論されていたが、待ってられないので自分で作ったそうである。アドミンに複数種別があることや、OpenStack の Project と対応づけられていることを説明していた。

ネットワークは OpenStack kuryr-kubernetes にマルチテナントと group based policy を追加したものを使っていて、CNI で Pod を Neutron Port と対応づけている。また複数のネットワークプレーンに分離されていて、通常の Pod DNS サーバが使えないので作り込みをしたと説明していた。

教訓として、エンタープライズは複雑である (既存の IaaS 基盤があって、技術的じゃない判断が行われたり、各種規制に従う必要がある) ことと、連日の徹夜でメンバーが burn-out しないようにする必要があったといったことが語られていた。

Building a Kubernetes on Bare-Metal Cluster to Serve Wikipedia

Wikimedia 財団の運用の話である。Wikipedia の他にも Wiktionary 等、様々なサイトが含まれる。でも Wikileaks は違うよといって笑いをとっていた。

毎月 170億ページビューで、北米にプライマリのデータセンターが 2つ、キャッシュ用のデータセンターが北米とヨーロッパとアジアに 1つずつあるそうである。サービスの種類が増えてきたことや、Elastic にしたい (負荷に合わせてデプロイ台数を動的に変更したい) という理由で Kubernetes を活用することにしたそうだ。

ユーザープライバシーやコストの問題があり、既に自前の CDN のようなものを持っているのでパブリッククラウドは使わないとのことであった。また、他の小さなプロジェクト (編集用) では OpenStack 上で Kubernetes を動かしているが、OpenStack はそれ自体複雑だしベアメタル上で動かすのに比べて (今回の話題の production system では) いい事がないと言っていた。

いろいろ自家製のものでやっているそうで、Kubernetes の Ingress も自前の LVS ベースのもの (https://github.com/wikimedia/PyBal) を使っており、ほとんど静的コンテンツでトラフィックが送出側に偏ってるので DR (direct routing) が高効率とのことである。

また、オープンソースのものしか使っておらず、Docker Hub も使わずにコンテナイメージは全部自分でビルドしているそうである。発表では、他に監視やデプロイのやり方も説明していた。

Accelerating Envoy with the Linux Kernel

Cilium プロジェクト (https://cilium.io) で Envoy を使ったコンテナ間の通信を高速化する話である。
発表者は Thomas Graf 氏で、昔 iptables とか OVS をやっていた方である。

まずは Linux eBPF (最近は単に BPF と呼ばれるようである) が速いということが、ロードバランサが IPVS に比べてずっと速いという Facebook での例と、11.6Mpps の DDoS で iptables では全部のパケットを drop できず通常の処理がまともに行えないが、BPF/XDP では全 DDoS パケットを drop した上で通常のリクエストも処理できたという例を挙げて説明された。

サービスメッシュを Envoy (https://www.envoyproxy.io/) を使って構成すると、Pod 上のサービスからパケットが外に出ていくまで TCP/IP、 ethernet スタックを 3回通ることになる。これを eBPF を使ってバイパスすることで高速化するというのがこの発表の主なトピックであった。発表資料のグラフによると性能 (リクエスト/秒) は約2-3倍になっていた。 TCP ハンドシェークはそのままで、データだけを eBPF でバイパスして高速化するといった説明がされていた。cilium の現在のバージョンは 1.0.x で、この機能は 1.1 あるいは 1.2 から使えるとのことであった。

また、 kTLS (TLS の共通鍵暗号をカーネルで処理する機能) を使うことで、Envoy に TLS の証明書を入れなくてもよくなるといった話をしていた。

最後に、今日は Star Wars の日だということで、 GitHub に今 Star をつけた人から抽選で Star Wars の LEGO をプレゼントしていた。 Star の数を増やしたかったようである。

Panel: service mesh

サービスメッシュについてのパネルディスカッションである。 Lyft の Matt Klein 氏が Envoy はコストがかかるから無条件には勧められないと言っていた。Lyft には、Envoy 等を専門にやる人が数人いるとのことであった。設定はそんなに簡単じゃないとか、 Resource Overhead も少しだけどあるといった短所も率直に話していた。

サービス 3、4個でもサービスメッシュにしたほうがいいの? という質問には、そうしろという意見と、まあちょっと待ったらという意見に分かれていた。

他のパネル討論者はサービスメッシュの推進に積極的なふうに見えたが、Envoy は元々 Lyft 社内で開発されたもので、おそらく Lyft が一番多く知見を持っているので、Matt 氏が控え目なことを言うので引きずられてトーンダウンせざるをえないといった議論の雰囲気を感じてちょっと面白かった。

SRv6

SR とは Segment Routing のことで、去年オースティンの Kubecon の前日の FD.io で良く聞いたキーワードであった。Cisco とパリの Ecole Politechnique の人達である。Kubernetes は 1.12 で v4/v6 dual stack になるはずだと言っていた。

まず IPv6 の普及について、IPv6 によるアクセスの比率がベルギーでは 50% を越えたとか、ドイツやアメリカでは 30% 強まで増えてるといった話があった。また、Facebook はエッジで IPv6 に変換して内部の通信は殆ど IPv6 になっているとか、サーバ毎に /64 のアドレスが割り当てられていて、タスク毎に IPv6 アドレスが振られているといった説明があった。

L4 ロードバランサの比較対象として Google Maglev と SRv6LB の性能比較が本題である。
SRv6LB では、ロードバランサで選んだサーバの負荷が高すぎたときにフォワードする第 2選択肢を IPv6 Extension Header に指定することができ、Maglev より均等に負荷分散できるとのことである (Maglev は負荷をモニタリングしない)。

SRv6LB は FD.io の VPP を使って 2 つのプラグインで実装している。IPv6 アドレスのうち 8bit を CPU インデックスに使って帰り道のパケットも LB の同じ CPU を通してロックレスで実装できているとのことである。デモを示して、Maglev と比較していた。

WG multi-tenancy deep dive

この系統のセッション (開発者向けのもの) の中では一番人が集まってるように感じられた。いくつかの話題について、発表者が交代して話すスタイルであった。

まず Security Profile の話から始まった。前日の Policy Deep Dive で話していたのと同じ内容だったが、Kubernetes の Policy の設定は間違えやすいのでコミュニティでおすすめのセキュリティプロフィールを少数用意しておいて Admin にその中から選ばせようというものである。デモもやっていた。

他に Tenant Operator といって、CRD でテナント毎のリソース割り当て方法を表現して、Tenant Operator と TerantResourceQuota アドミッションコントローラでリソース制約を実装するという話があった。例として k8s-gitlab-integrator が挙げられていた。Tenant Controller のドキュメントを書いたので見てほしいと言っていた。ここで言う Tenant とは Namespace の集合のことだそうである。会場からは、マルチテナントなら Disk とか Network を分けられないと困ると意見があったが、Google の人はそういう要望には興味がなさそうであった。

最後に Huawei Cloud でのマルチテナント実装についての説明がされた。Kubernetes API をユーザに公開しているサービスで、中国だけで試験提供されているものである。テナント毎に1つの Namespace が割り当てられ、Network は Namespace 毎で L2 レベルで分離されている。また、API は Gateway 経由でアクセスさせてレートリミットがかけられているといった話をしていた。

Resource Management Deep Dive

Google の Vishnu Kannan 氏 (@vishh) が話していた。参加者は 30人程度。他におもしろそうなセッションがあるのに来てくれてありがとうと言っていた。最初の頃からリソースまわりをやっており、最近は Machine Learning もやっていると自己紹介していた。このワーキンググループを以下のように説明していた。

• cross SIG
• 30+ active contributors
• Zoom で隔週ミーティング
• Nvidia で F2F をした

続いて、ここまでできたよと説明があったが、ぱっと見たところ去年のオースチンでの説明から変わってなさそうであった。これからやる事として以下を話していた。

• Compute Resource Extensibility
  ・ extensible feature rich API
  ・ Developer と DevOps の欲しいものが違う
• Hardware Topology Awareness
• Monitoring
  ・ kubelet を monitoring から分離する
• Application Performance Benchmark
• CSI どうなったという質問
• PCIe-NVMe の様なものがあるけど User Request はないんだよねと返事

会場から CSI どうなったという質問があり、PCIe-NVMe みたいなものはあるけど User Request がないんだよねと返事をしていた。なんでもかんでも作ろうとするのではなく、Use Case 次第で本当に必要なものを作っていこうという基本姿勢に見受けられた。