KubeCon + CloudNativeCon Europe 2019: DAY 4 最終日

2019年5月20日から23日にかけてスペイン バルセロナで開催中の「KubeCon + CloudNativeCon Europe 2019」に当社からクラウド基盤エキスパート Certified Kubernetes Administrator の田が参加しています。

Kubernetes の最新情報および KubeCon 内で初日に開催された「FD.io Mini Summit」について速報ベースで報告していきます。

KubeCon 初日はいきなり Kubernetes から逸れまして、FD.io Mini Summit からのレポーティングとなります。

FD.io (https://fd.io/) の中心的 OSS “VPP” (VPP とは) は FD.io 傘下の各プロジェクトにおいて活用される形になっていますが、COTS (commercial off-the-shelf ) での限界性能の追求と多機能をここまで高い水準で作り込んできている OSS は、そう多くないのではないでしょうか。

一方で開発途上のプロジェクトも多いことや、そもそも VPP 本体が若干扱いづらかったり比較的ローレベルの知識を多く必要とすることから、ローレベルの OSS とユーザの橋渡し的な役割を担うビジネスを少なからず取り扱う当社としては、動向を注視する意味があるのではと個人的に認識しての参加です。

なお、FD.io Mini Summit においては、DMM (DMM とは)を大変楽しみにしておりましたが、登壇者 (at Huawei) はやむなく参加不可能になった事で急遽直前にスケジュール変更になりました。

Fd.io Mini-Summit は内輪感が非常に強く、合計で 25名程度会場に居ましたが、その殆どが登壇者と同企業の仲間エンジニアであり、私の認識では Ericsson から来ていた 1名と私を除いて完全に内輪の集まりでした。Intel か Cisco に所属する各プロジェクトのコアのエンジニアが大半でした。

KubeConの参加層とはどうにも離れている気がしますし、今後も KubeCon の一部として FD.io Mini Summit が開催されるかは考え直すタイミングにあるようです。

 先ず uCPE (Universal Customer Premises Equipment) の具体的な実装の紹介 (Atom C3000 Processor前提) のセッションから始まりましたが、こちらは資料以上でも以下でも無い為割愛します。

Apply VPP TLS stack to Nginx

Nginx に対して VPP 側から透過的な TLS 機能を提供するセッションにおいては、openssl 3.0.0 の async callback 群の活用を大きく取り上げていました。

• c.f. Commit 31dd6090e882 (Add Ipsec IKE support to openssl 3.0.0 master branch)

なお、TLS の透過的サポートと Nginx での実証に間しては、以下を確認するとよさそうです。

• Commit 7b74b073e4e3 (ldp: add option to eanble transparent TLS connections) 

VPP Host Stack

VPP Host Stack の現状ステータスの紹介がありました。SVM の実装手段としての shm は今後deprecated にするから memfd 一本化します、という、もはや memif プログラミングや vcl プログラミングを行う人以外にはささらなそうな話から、TCP stack における NewReno および Cubic の実装に触れることまでありました。

State of VPP in Network Service Mesh

Network Service Mesh (NSM) に関するセッションにおいては、VPP が平均的なユーザにとって難しすぎてその障壁を取り除く為の位置付けという発言が極めて印象的でした。どうも VPP そのものに関してユーザを新しく獲得しようとする努力（ドキュメンテーションの改善等）をすることは考えておらず、代わりに NSM を通じて裾野を広げようとしているようでした。

例えば libmemif を実際に使おうとするとディテールでの作り込みが途上であったり、ドキュメンテーション不足から結局ソースコードを読み込む作業は現状避けられないと感じます。NSM はその労力からユーザを解放してくれます。

DAY 1 まとめ

TRex  (TRex とは) や最後の NetGear CTO による TNSR に関するセッションに間しては、特に真新しい情報が無かったように伺えたため割愛します。

ところで VPP は少なからずカーネルコミュニティでも意識されているようです。

例えば Edward Cree 氏のパッチに対する David S. Miller 氏のコメントが印象的です：https://twitter.com/davem_dokebi/status/1014411603100352512

こちらは元々 2016年に netdev に投稿した RFC パッチシリーズ(http://patchwork.ozlabs.org/patch/612143/#1329165) が発端で、当初は一旦見送られる事となったものの Spectre を契機にコスト対効果が見直されて再度日の目を見ることとなったものです。

100Gbps 超で必要となる CPP (Cycle Per Packet) 制約は、特に高レイヤーのプロトコルスタックにパケット毎に渡していく場合、どうしても満たす事が出来なくなるとはいえ、まとめられる分だけまとめて VPP のようにinstruction cache ヒットを稼ぎましょうといったところでしょうか。

真に VPP のようなことを試みるにはプロトコルスタックを独立させて deterministic で vector 処理な形に変えることになる (ksoftirqd での SoftIRQ 処理をばらばらに分解) ことが思考実験的には考えられるかもしれませんが、汎用 OS として高度に複雑化したネットワークスタックにおいてそうした試みは有り得ないだろうと感じます。

KubeCon 2日目の報告になります。

Keynote

Keynote については動画がアップロードされると思いますし、
特にこの場で触れるような話も無い気がしますので省略します。

Kubernetes + Encrypted Memory = Security * Privacy

午前で印象的だったセッションは「Kubernetes + Encrypted Memory = Security * Privacy – Harshal Patil & Pradipta Banerjee, IBM」です。

スライドが早速アップロードされています: https://static.sched.com/hosted_files/kccnceu19/7e/Protected%20Memory.pdf

デモでは、同一 SVM (※1) 上で先ず暗号化されたデータを復号してから、そのデータを Ephemeral Storage を用いて複数コンテナ間で共有し活用する、という流れの中で、Ephemeral Storage の部分が本質になります。

つまり、スライドにあるデモの最初のステップで用いる復号キーは、SEV、MKTME 等の機構を用いて当該 SVM (つまり QEMU で動かしている VM) のプロセスのメモリ空間を暗号化する為にメモリコントローラにプログラムするキーとは関係が無い事に注意が必要です。急に「キー」が出て来ると、文脈が混在して私は少しの間混乱しました。

当デモは恐らく PEF (※2) 前提かと思われますが、いずれにせよ丁度今日、昨年の RFC パッチシリーズに紐づくパッチシリーズが投稿されていた (※3) レベルの状況ですので、最早あまり気にするところでは無いかと思います。

関連して、スライドを見ていただければ分かると思いますが、特に直近の各種実装の進行状況に関して細かく紹介していくようなセッションではなく、あくまで概要の説明とデモがメインでした。

その為以下で独自に実装進行状況や関連する議論の進行状況に関して、AMD SEV と Intel MKTME に絞って比較する形でポインタ的にまとめてみます。なお、当然ですが状況は幾分途上ですので、今年中に急速に変容するかもしれません。

Scale Kubernetes Service Endpoints 100x

さて、午後最初のセッションとしては 「Scale Kubernetes Service Endpoints 100x – Minhan Xia & Wojciech Tyczynski, Google」を拝聴しました。こちらもどうやら、早速スライドがアップロードされているようです。URL: https://static.sched.com/hosted_files/kccnceu19/f0/Scale%20Kubernetes%20Service%20Endpoints%20100x.pdf

スライドを見ていただければ分かるかと思いますが、10k+ nodes、10k+ endpoint pods 環境におけるスケール問題から、Endpoint の API 再設計に至るまでの流れを紹介するセッションでした。

提案されている新 API の認知度を上げ、より活発な議論を促す意図があるようです。

EndpointSlice の現ステータスについては、proposal 本体を参照ください: https://docs.google.com/document/d/1sLJfolOeEVzK5oOviRmtHOHmke8qtteljQPaDUEukxY/edit#heading=h.3v0n1vmx9wtr

なお、ボトルネックの解消は次なるボトルネックの表出化へとつながります。セッションで取り上げられていた、複数サブセットに 1 Endpoint が入るようにする事で不均衡を解消する、といった、EndpointSlice API をより優れたものにしましょうというスコープからは外れてより広範囲に考えてみますと、そもそもの etcd の RPS 等が挙げられそうですので少しだけ触れておきます。

RPS向上については着々と実装が進んでいるかと思いますが、現時点での “Fully Concurrent Read” の提案に至るまでの流れは、以下リンク先 proposal に全て記載されているように伺えます: https://docs.google.com/document/d/1V9UuL8BnpZF2xFpHhvE1lO2hWvtdiLml3Ukr-m4jcdI/edit#heading=h.wuzq924gzsh

Using eBPF to Bring Kubernetes-Aware Security to the Linux Kernel 

続いて「Using eBPF to Bring Kubernetes-Aware Security to the Linux Kernel – Dan Wendlandt, Isovalent」を拝聴しましたが、こちらは「Cilium の存在を何となく知っている人に対して、その魅力を伝えてコミュニティを盛り上げる」という意図だったかと思います。

聴衆のレベル要求を下げて動員数を増やし、eBPF、またCilium に関しても技術的な深堀りはせずに巧みに Cilium デモ (※公式ドキュメンテーションの内容の範囲だったかと思います) で締め括る形でした。

ほぼ満員で人気のセッションでしたが、観客の反応や質疑の内容から見て、「Cilium 自体に興味を持っているが使った事は無い」、という状態の人は意外にも多いのかもしれないという印象を持ちました。(正直なところ、もっと両極端かと思っていました。)

スライドはこちらも早速アップロードされているようです: https://static.sched.com/hosted_files/kccnceu19/d2/KubeCon-Europe-wendlandt-ebpf-2019.pdf

KubeCon 3日目の報告になります。

 本日も特にKeynoteには触れません。

また、「GPU Machine Learning From Laptop to Cloud – Mark Puddick, Pivotal」も拝聴しましたが、アップロードされているスライド以上の事は全く無かったのでこちらも省略します。進行が少しうまくいかなかった為に途中退出者が多く、残念でした。

Deep Dive: Network Service Mesh

「Deep Dive: Network Service Mesh (NSM) – Nikolay Nikolaev, VMware & Frederick Kautz, Doc.ai」は大盛況でした。立ち見が多く120%くらいの満員状態 (狭い部屋に 150名超だったかと思います) でしたが、果たしてこの中でどれだけの人が NSM SDK を用いた開発を必要としている状況に居るのか、少し疑問ではありました。

アップロードされたスライド (PDF) をご覧頂ければ分かるかと思いますが、NSM の SDK の最新のステータスと、利用方法を反映した実用的なプレゼンテーションです。

NSM をここ数ヶ月確認されていなかった方は、NSM SDK がそもそもかなり最新の物ですので SDK のドキュメントを一度確認される事をおすすめ致します。
(URL: https://github.com/networkservicemesh/networkservicemesh/tree/master/sdk)

つまり、本セッション終盤の client および endpoint の SDK を用いた実装において、そもそも Endpoint Composition は今年に入ってから本格的に整備されてきているものです。

但し、普及させようという努力が随所に垣間見れて、この短期間でここまで一般ユーザへの認知度を上げてきていることを考えると、今後短期間の内に、SDK を通したサンプル実装やドキュメンテーションの更なる充実化などが期待出来るかもしれないと感じます。

個人的には例えば Wired 802.1X 等が思い浮かびましたが、Kubernetes 環境において有用そうな新しいサンプルが今は思い浮かびません。 

なお、QA セッションを待たずともプレゼンテーションの最中質問も盛んに出ていました。スライド 3ページ目の “Orthogonal to CNI” で片付く話ではあったかと思いますが (※ 更に付け加えると、当然かと思われるかもしれませんが、例えば VPP を使う Contiv である必要などは無いですのでご安心下さい)、パフォーマンスに関しての質問も幾つかありました。

“Orthogonal to CNI” ですので、メッシュが確立された後のパフォーマンスの話に限れば、単に NS Endpoint をスケールアウトさせるという事が自然な考え方かと思いますし、実際そういった返答に落ち着いたかと思います。

KubeVirt users and contributors meetup

午後は KubeCon 会場を抜け出し、KubeVirt users and contributors meetup に参加して参りました。

• eventbrite: https://www.eventbrite.com/e/kubevirt-users-and-contributors-meetup-at-kubecon-eu-tickets-61441584433
• kubevirt-dev: https://groups.google.com/forum/#!topic/kubevirt-dev/gZ–3zS-UJw

具体的な議論で非常に面白かったです。当日の議論の記録がアップロードされていますのでご参照ください。後日、トピックスをまとめたいと思います。

• URL: https://github.com/kubevirt/community/blob/master/events/2019-kubecon-eu/minutes.md

また、是非 kubevirt-dev のメーリングリストを確認してみてください。

• メーリングリスト: https://groups.google.com/forum/#!forum/kubevirt-dev

なお、何にせよ実運用に関する報告や要望は、今よりももっとユーザ側から出て来た方が良さそうでしたので、もし使われている方がいらっしゃたら躊躇せずにフィードバックするとプロダクトの発展に寄与できそうです。

KubeVirt は現実的なシステムの課題におけるコーナーケースを掬い上げてくれるプロダクトかと感じます。

Kubernetes はオーケストレーションの役割だけでも十分優れたものであり、Kata Container 等とは少し異なる視点で、従来型の VM ワークロードがどうしても必要になるというシーンは、特に大規模な企業においては十分考えられるのではないでしょうか。

勿論そういったものは塩漬けにして、切り離して考えるというのも十分取り得る選択肢ですが、いざという時の最後の砦といったところでしょうか。

そういえば nemu (nemu とは) や firecracker (firecracker とは)を選択的に同居させるのはありかみたいな話も少し出ました。QEMU の場合、kubevirt は Kata Container 等と異なりはじめから vanilla QEMU です。

3日目は以上です。

＝＝＝DAY 4 に続く ＝＝＝

KubeCon 4日目最終日のレポートになります。本日も特に Keynoteには触れず、印象的なセッション 2つに絞ります。

Intro + Deep Dive BoF: Telecom User Group and Cloud Native Network Functions (CNF) Testbed

スライドはスケジュールのページ (https://kccnceu19.sched.com/event/MSzj?iframe=no) にはリンクが現時点で貼られていませんが、CNF-Testbed のページには少なくとも貼られています。メーリングリストのアドレス等も記載されています。
https://docs.google.com/presentation/d/1iAgzRp5eFv7LWmpR2u1Wy0LdhvB85SkKJBxXFSNH8XE/edit#slide=id.g5036f143e9_3_113

 Telco の参加者は少なく、phone vendor 寄りの参加者構成だったようですが、TUG のキックオフということで元々各社のネットワーキング、今後の大雑把な方針の共有という意味合いであったのかなと思います。

 個人的には cnf-testbed についてもう少し突っ込んだ話があればと思っておりました。特に最も高密度に Network Function を稼働させられる Pipeline Forwarding (https://tools.ietf.org/html/draft-mkonstan-nf-service-density-00#section-8.4) の具体的な望ましい実装について新情報があればと思っていたので、従来の「memif connections」という言及で片付けたままだったのは残念でした (先述のスライドの 22ページ参照)。

memif 接続であれば VPP 本体のセッションレイヤーの助けが不要、つまり接続ペアを予め定義できるのであれば完全に libmemif プログラミングだけで済ませる事が出来るという意味でベンダーフリーに近いですし、libmemif は VPP を介さないダイレクトな接続に使う時、実質的に共有メモリを使用する IPC のプリミティブな実装に過ぎない物であるという理解です。よって、アプリケーション側が libmemif プログラミング層を必要としてしまうことに目をつぶりさえすれば、十分アリかもしれません。なお、セッションの途中で、FD.io 側が協力してくれている一方で、 VPP の使用を強制している訳ではないことにも言及されていました。

その他に印象的だったのは、従来の VNF 資産を Kubernetes 上で稼働させるオプションについて、KubeVirt (や Mirantis の vertlet等) を使用する想定だったのは非常に驚きました。やむなくそういったケースも掬い上げられるということでしょうが、将来現実の運用シーンで実際にその光景が見られるかどうかは未知数かと感じます。

Latest Kubernetes Scalability Improvements

https://kccnceu19.sched.com/event/MPce

 最近の Kubernetes (スケール時) パフォーマンス改善の話ですが、特に目を引く、Inter-Pod Anti-affinity 設定時の Pod スケジューリングの低速化「< 5 pods/min in 5k-node cluster」に関しては、会場からも「流石にここまで遅いとなると、その真因を知りたい」といった質問が出ました。回答は非常にあっさりしたもので、シンプルに Anti-affinity の symmetric な性質をその主要因として触れるにとどまりました。

1分間に 5Pod 未満しかスケジュール出来無いというのは非常に深刻な物と感じられると思いますので、少し詳細を説明してみます。

 まず、このショッキングな (generic) scheduler のスループット数値の言及は、BenchmarkSchedulingAntiAffinity の {nodes: 5000, existingPods: 1000, minPods: 1000} に関する結果と考えて良さそうです (※1)。

 つまり、5,000 Node において 1,000 Pod が既にスケジューリングされた状態からスタートし、概ね追加で 1,000 Pod を画一的な Inter-Pod Anti-Affinity 設定付きでスケジューリングするのに要する時間を計測する事になります。Inter-Pod Anti-Affinity は画一で、各 Node に 1 Pod 以上が結果として乗らないような内容になっています。つまり、2,500 ノード 〜 3,500 ノード (※2) に対する Predicate 実行となり、平均的には 3,000 ノードに対しての Predicate 実行のスループットと言えそうです。よって inner loop のスループットの「Before」値の平均は概ね 64ミリ秒/Node (※3) と言えます。そしてinner loopである、「1 Nodeに対する Predicate 実行」時間を短縮する為に、

• (a). MatchInterPodAffinity における探索スペースの削減
• (b). eCache のロック競合の改善

の 2点が具体的に取り組まれました主なポイントでしょう。(a) に関しては、まず Babak Salamat 氏による 2018年4月の以下の改善が最も寄与率が高いようです。当時の計測で、スループットが 20x と書かれています。 (https://github.com/kubernetes/kubernetes/pull/62211)

その上で計測時間の 8% が satisfiesExistingPodsAntiAffinity 、残るほぼ全てが satisfiesPodsAffinityAntiAffinity により費やされているという状況だったようですので、

• 前者の改善 (参考: https://github.com/kubernetes/kubernetes/pull/66948#issuecomment-411242572)
• 後者の改善 (参考: https://github.com/kubernetes/kubernetes/pull/67788#issuecomment-416829503)

の内、後者の改善が次に寄与率が高かったもののようです。スループットが 11x と書かれています。右記リンク先のコメントをご覧下さい: https://github.com/kubernetes/kubernetes/pull/66948#issuecomment-412239621

 (b) に関してですが、https://github.com/kubernetes/kubernetes/pull/65714#issuecomment-404725375 (※4) で言及されているように、eCache のパフォーマンス改善も大いに関係してきます。なお、eCache は昨年初夏頃までにどんどん複雑になってきていたのを、シンプルな実装に戻す流れになったかと思います。

 参考: eCache 自体を消そうという Issue

• https://github.com/kubernetes/kubernetes/issues/71013
• https://github.com/kubernetes/kubernetes/pull/71003

なお、プレゼンで触れていた pod 数制限については、SIG-Scalability の設定しているスケールのゴールとして以下を確認できます。
https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md#scaling-and-performance-goals