セッション動画

はい、ではよろしくお願いします。

簡単に自己紹介ですが、すだかずきと言います。@superbrothersというIDでTwitterやGitHubをやっています。Preferred Networksという会社のエンジニアで、ほかにScalar, Inc.というと会社で技術アドバイザをやっていたり、Kubernetes Meetup Tokyoの主催やCNCFのアンバサダーをやっています。

今日はKubernetesに入るかもしれない機能を話していきます。入るかもしれないし、入らないかもしれないので、ここで聞いた機能に期待してこの先の業務に生かそうという場合は、入るかどうかわからないので注意してください。入ったとしてもベータに昇格しないで削除される可能性もあるので、そのあたりも注意してください。

インパクトの大きい再作成なし更新、SSHなしでシステムログ表示

最初がIn-Place Update of Pod Resourceです。青山さんが話していたものと一緒ですが、再作成なしにリソースの要求や制限を更新できるというものです。「止めたくないものもあるよね」という感じですね。ほかにPod resizeサブリソースというのが増えるので、Podリソースを変更するときにそれを使って書くというところが変わります。古くから取り組まれている機能で、入ったらすごくインパクトが大きいので期待しています。

次がUse kubectl to view logs of system services on nodesです。これは提案がマージ済みでアルファターゲット1.26に入っているので、次のバージョンでリリースに含まれる予定になっています。これはkubeletのログをノードへのSSHなしに見られるものです。kubectlで見えるようにしたいということですね。systemd-journalとvar/log以下のログが見られます。kubectl node-logs というサブコマンドが増えて、このように入力して表示されます。

kubectl node-logs --role master -q kubelet -q crio

自分も知りませんでしたが、kubelet自体は昔からログビューア機能を実は持っていたらしいです。ただ、これを使うクライアントがなかったので、今回こういうふうに実装された感じです。systemd-journalを見るサポートの機能はこれに合わせて今回追加されたものです。ただし、kubeletは実装的にはjournalctlをexecするようになっているので、実装をミスるとセキュリティホールになりそうでちょっと怖いです。Goでjournalログを読むライブラリがあったら、そっちに変えたほうがいいんじゃないかと思っています。

キーストーン指定は保留、ユーザー属性は取得できるように

次は、Keystone containers KEPというものです。これは、KFPがまだマージされていなくて、アルファターゲットも未定になっています。

この機能は、Podに図のようなフィールドが入るという感じで、どのコンテナがKeystoneなのか、つまり重要なのかというのをマークできるものです。アプリケーションコンテナが終了したらサイドカーの状態に関わらず、Podの終了処理が開始されるという機能です。

現状は、Jobでアプリケーションコンテナが終了しても、サイドカーコンテナが終了しないとJobが完了状態にならないという問題があって、ワークアラウンドとして、アプリケーションコンテナが終了したらサイドカーに何かしらのシグナルを送ってサイドカーを終わらせるといったテクニックがあるんですけど、こんなことしたくないよね、というものになっています。もともとSidecar KEPというまた別のKEPがあったのですが、実装が複雑だったのでもうちょっとシンプルにしたものをということでこれが用意されました。入りそうだったのですが、「このインターフェースでこの機能に絞って入れちゃって大丈夫かな」みたいな議論が今起きていまして、Sidecar WGでもう少し議論してからということになっています。

次です。Auth API to get self user attributesというもので、提案はすでにマージ済みでこれもアルファターゲットは1.26になっています。これは自分の属性を取得する、つまり自分自身が誰かというのを取得するためにSubjectAttributesReviewというAPIが追加され、それを使う機能として kubectl auth whoami というコマンドが追加されるというものです。このような感じで使います。

ここでは Usernameが kubernetes-admin、Groupsが system:masteres の authenticated になっていることがわかります。これはkindで作ったクラスタですけれども、こんな感じでわかります。Kubernetesにはユーザーを表わすリソースがなくて、X509証明書やIDトークンなどからユーザー情報を取得してその中に書いてある属性を信頼して使います。それに何が書かれているか、Kubernetesは何を見て何をどう判断するかというのを知ることができる機能がなかったので、今回これが作られました。非常に便利なのではと思っています。

PLEGポーリングはイベント受信へ、CELバリデーション

次がKubelet Evented PLEG for Better Performanceです。これはKEPマージ済みで、アルファターゲットは1.26になっています。PLEGがポーリングからイベントを受け取るように変わって PLEG is not healthy が起きにくくなります。Kubeletを運用している人は見たことあるかもしれませんが、この PLEG is not healthy は負荷の高いノードなどでよく起こります。Kubeletはコンテナランタイムをポーリングしていて、このコンテナランタイム側で起こったイベントをKubernetes側に知らせないといけないのでそれを受け取るようにしていますが、今まではそれがポーリングで実装されていました。ただ、ポーリングというのはコストが高いので、コンテナランタイム側にイベントを取得できるようなAPIを増やして、それを使ってポーリングの頻度を下げようというものです。

具体的には、CRI Runtime ServiceにGetContainerEventsというAPIができることになっています。今は1 Pod、1 goroutineで1秒ごとにコンテナランタイムを叩いていたんですが、リスト要求が300秒に1回になることで、かなりkubeletの負荷やコンテナランタイムの負荷が下がります。このイベントは、コンテナランタイムの負荷が高くなると、このリストの取得で遅延がどんどんたまっていった結果として起きるエラーです。

次は、CEL for Admission Controlです。CELを使ってビルトインリソースも含めて柔軟にバリデーションできるようになるというものです。ちょっと前にCRDを使ってバリデーションできる機能が入ったのですが、これが全リソースでできるようになります。これはマージ済みで、アルファターゲットも次のバージョンになっています。普通はAdmission Webhookで検証しますが、Admission WebhookはWebhookサーバが必要なので、運用もしないといけなくて、あまりしたくないよね、というところです。こういう感じのリソースを作ってできるようになります。

SupplementalGroups の挙動変更を提案

次が最後です。Fine-grained SupplementalGroups controlで、これはKEPもアルファターゲットも未定ですが、PodSecurityContextのSupplementalGroupsでコンテナイメージの内容を問わず上書きを強制するものです。

これは私も知らなかったのですが、SupplementalGroupというのは指定したLinuxグループで上書きしてくれるわけではなくて、追加するという実装になっています。なので、こういう感じでグループが3000、4000と5000で UIDが一致している場合には、本当はグループに5000だけを使ってほしいのですが3000、4000、5000になってしまいます。これを避けて5000だけにする機能を追加することになっています。まだKEPに入っていないですが、これを実現するためのruncラッパを追加提供しているので、気になる人は使ってみてください。

Preferred Networksは採用をしていますので、興味がある方はご連絡ください。

ご清聴、ありがとうございました。