CloudNative Days Tokyo 2019 2 日目参加レポート
CloudNative Days Tokyo 2019 2 日目に参加してきたのでそのレポートです。仕事の都合で午後からの参加となったので、そこだけ書いています。
ちなみに 1 日目のレポートはこちら。
Session
セッションまとめ。
SODA - The Open Autonomous Data Platform For Cloud Native (OpenSDS)
OpenSDS の中の人の合同セッション。SODA プロジェクトと呼ばれる、ストレージサイドとそのストレージを利用するコンテナ・VM サイドの間がごちゃごちゃしてきてるから統一的に開発しようぜという取り組みの話。
オンプレ・パブリッククラウドに関わらずストレージが実際に提供されるまでには、ストレージドライバからデータの圧縮、暗号化、利用サイドのプラグインなど多くの開発が必要でその工数を軽減するために SODA が生まれたと言っていました。もともと OpenSDS はコントロールプレーン (エコシステム) の管理だけをしていたようなのですが、このような経緯でデータプレーン (ストレージ) も管理してくれるようになったそうです。こうしたインターフェースが定義されることによって抽象化されるので、ベンダーロックインも無くなるし開発も楽になるし良さそうですね。あと移行が楽そうですね。昨日の Airbnb の話に通じるものがある気がします。
デモでは OpenSDS のダッシュボードの紹介と、実際に osdsctl を叩いて Ceph からボリュームを作成したりなどしていました。そしてここで作ったボリュームを OpenStack の Cinder や Kubernetes の PVC から利用する例がありました。当然どちらも Plugin が必要ですが良さげでした。
Cluster API で簡単 Kubernetes on OpenStack
NEC の方のセッション。レベル感は Cluster API の入門 +α くらいでしたが、個人的な認識では「クラスタ作ってくれるやつ」程度だったので丁度良かったです。
Cluster API は sig-cluster-lifecycle で進められているもので、Kubernetes から宣言的に Kubernetes のクラスタを作ろうという取り組みです。クラスタ (ノード) を作るというからには当然 CloudProvider がいるわけで、今回は OpenStack を使った話でした。CloudProvider 実装は結構多くのクラウドをサポートしているようでしたが、特に VMware が頑張っているらしく vSphere と AWS の開発がとても活発だそうです。次点で RedHat の Baremetal だそうですがこちらは Kubernetes SIG 傘下にはまだ入っていないようですね。その次に OpenStack あたりが来るらしいです。vSphere, AWS の開発が活発すぎてそれらの動向も追わないといけないので大変そうでした。
使い方的には clusterctl コマンドを使用して Create するだけです。背後の処理の流れとしては、対象のクラスタを作成する前に、まず Cluster API 用の Custom Controller がデプロイされた Bootstrap クラスタが立ち上がります (kind を使うのが良さそうでした)。次にそのクラスタが CloudProvider に対してリクエストを送って仮想マシンなり何なりを払い出してもらい、対象のクラスタを kubeadm で構築します。構築が終わると Bootstrap クラスタのコンポーネント群は対象のクラスタに移行され、kubeconfig だけを残して消滅するという流れでした。OpenStack CloudProvider は仮想ネットワークや Security Group などの作成処理は行わないので別途作っておく必要があるようでそこは面倒そうでした。ここも自動化しよう、といった趣旨の議論は生まれるらしいのですが大抵放って置かれて自然消滅しているそうです (笑)。
デモでは実際にクラスタを作成してスケールイン・アウトする例を見せてくれました。クラスタは Kubernetes の Resource として管理されるので、MachineSet (ReplicaSet 的なもの) のノード数を増減させることによってそれを実現できていました。スケールインするのを見た感じ OpenStack のノードが消えてから Kubernetes の方も消えるという感じだったので、上で動いてる Pod とかはちゃんと Drain されるのかな？という疑問が残っています (メモってたのに質問し忘れた...)。ちなみに MachineDeployment を利用したイメージのローリングアップデートはスピーカーの方もうまくいったことがないようです (笑)。
Cluster API 自体は個人的にとても好きになりましたが、成熟度はそこまで高くなさそうなので本番導入されるのはかなり先になりそうだなーと感じました。
Kubernetes に audit ログを求めるのは間違っているだろうか
CyberAgent の方のセッション。ログは Pod とかコンポーネントのログだけじゃないんだぜ、audit ログもあるんだぜという話。
kube-apiserver は audit の機能を持っているようでオプションから設定できるようでした。話は大きく 2 つに分かれていて、ログの出力ポリシーと出力媒体の話をしていました。まず audit ログは、どのリソースに対して (WHAT)、いつ (WHEN)、誰が (WHO)、どこから (WHERE)、何が (WHAT) 行われたのかという情報が出力されます。こういったログは全部出すとキリがないのでポリシーを決めて出力を絞ろうというわけです。ローテートの機能もあるようなので良さそうですね。また、audit ログの出力媒体はファイルにしたり Webhook にしたりすることができます。Webhook の方は Dynamic に送信先を変える仕組みもあるそうなので柔軟性はそっちの方がありそうですね。あとこっちの方が CloudNative 感があって良いなと思いました。ここらへんの話は資料が公開されているのでそちらを見たほうが正確で早いです。
ポリシーは出力するタイミング (Audit Stage) を決められるらしく、リクエストを受け付けたときや、レスポンスを返すときなどを指定できるようです。リクエスト受付時に Header だけ返して、本当の処理が終わったタイミングで初めて Body を返すような API もあるようなので、そこはちゃんと認識して出力タイミングを指定しないといけなさそうですね。(関係ないですが Netfilter のログデバッグで苦しんでいたときのことを思い出しました。)
RBAC を audit ログから自動で生成するものもあるようで便利だなと思いました。
資料上がってますね。
How cgroup-v2 and PSI impacts CloudNative?
GMO ペパボの方のセッション。最終セッションでした。PSI という新しめの仕組みが Linux Kernel 4.20 に導入されているようで、それと cgroup のお話です。
序盤は cgroup v1 の基礎で、cgroupfs の操作や各 Subsystem に関する説明がありました。ここらへんは学生の頃 cgroup v1/v2 の調査をしてたり、v1 の memory/cpuset subsystem の拡張を行っていたことがあったので馴染み深い話でした。といっても他の Subsystem はそんなに触っていないので、pids subsystem で Fork 爆弾の対策ができるという話など、そういう使い方ができるのかといった面白い気づきもありました。また、/proc/self/cgroup でプログラムがどの環境で動いているのか判定できるという話も面白かったです。Chef の ohai はこの中に Docker 系の cgroup が入っているか確認して環境を判定しているそうです (コード)。他にも歴史の話や cgroup v2 の基礎の説明がありました。
その後 PSI のデモがありました。PSI は前述の通り Linux Kernel 4.20 で導入された機能であり、それを cgroup v2 の中から利用するという内容でした。ちなみに意外にも PSI は Facebook が開発したようです。PSI 自体は Subsystem ではなく、cgroup のツリー内に xxx.pressure というファイルが追加されて、そのファイルから所属する task (プロセス) の負荷状況を知ることができるというものでした。
最後に cgroup v2 の対応状況の話がありましたが、runc はまだ対応してないようですね。
まとめ
この 2 日間で新しいものを触りたい欲がとても高まりました。今はとりあえず Knative をやりたいですね。
運営の方々、ありがとうございました。
