CNDT 2022、日立のエンジニアによるKubernetesに新機能をマージした経験を語るセッション

CNDT 2022から、日立のエンジニアがKubernetesのストレージスナップショット機能に対してnamespaceを超えて実行する機能を追加した経験を解説したセッションを紹介する。タイトルは「Kubernetesのnamespaceを越えて: namespace跨ぎのsnapshotからのvolumeの作成の今と未来」という長いものだ。

セッション前半は、Kubernetesの境界分離の基本であるnamespaceを超えて永続ボリュームに対して作成されたスナップショットの利用を可能にする機能とKubernetesのメインブランチにマージした経緯を解説し、後半ではデモを交えて実際に別のnamespaceの永続ボリュームに作成されたMySQLのデータを利用するところを見せるという内容である。

プレゼンテーションを行った高橋孝文氏はHitachi Vantara LLC所属、木村将希氏は日立製作所プラットフォームサービス部所属ということで、ストレージとインフラストラクチャーに強いエンジニアの腕の見せどころであろう。

プレゼンテーションを行う木村氏（左）と高橋氏（右）

まずは木村氏がKubernetesのnamespaceの基本的な内容を解説し、ノードの中で実行されるアプリケーションリソースは基本的にnamespaceによって境界分離され、クラスターの中で共有されるリソースはNode、PersistentVolumeなどがあることを説明した。

namespaceとリソースの解説。Podは基本的にnamespaceで分離される

その上でPodが使うPersistentVolumeが実際に作成されるまでのプロセスを解説。ここではnamespaceの中で稼働するPodがPVC（PersistentVolumeClaim）を定義するとそれを検知したCSI Provisionerがボリュームの作成を指示し、バックエンドのストレージにボリュームが作成され、ノードの中でPersistentVolumeが作られ、紐付けされるという流れだ。

PVCからPVが作られるまでを解説

ここでは定義そのものがnamespaceにおいて行われることが前提となっているため、そのスナップショットもnamespaceに紐付いた形になるのはセキュリティ確保とリソース分離の観点からは至極当たり前の構造だ。

PVからスナップショット（VolumeSnapshot）を作成

VolumeSnapshotからPersistentVolumeClaimの作成の流れ。これもnamespace内に閉じている

このスライドではスナップショットからPVCを作成、そしてバックエンドのストレージにおいてもコピーが実行されるまでの流れを解説している。ここでもnamespaceの中での動きであり、このセッションの目的である「namespaceを跨いでPVにアクセス」するところまでは来ていない。

PVCの定義であるdataSourceRefにはnamespaceを指定できない

そしてこの仕様が実際にシステムの中では使いづらいケースがあることを紹介。ここではデータの受け渡しという言い方で表現されている。

PVのデータを複数のnamespaceで利用したい、受け渡したいというニーズがある

ひとつは本番環境のデータを開発目的で使う場合だという。具体例として、テストデータとして使う場合、機械学習などの学習データとして使う場合などが示されている。

本番環境から開発環境へのデータコピーのニーズ

他にも起動イメージや汎用的な初期データなどが挙げられて説明されている。

このニーズに関しては2018年以降複数のコントリビュータから意見が出されており、仕様の検討が続いてきたことを解説した。

複数のエンジニアが同じような機能拡張をコミュニティに提案。検討が続いていた

初期はPVCへの参照を繋ぎ換えるトランスファー方式が検討されていたが、この方式にはエラー発生時のロールバックが複雑になる、アクセスに利用されるシークレットが転送されないなどの課題が露呈し、結局トランスファー方式は採用されなかったことを解説している。

トランスファー＋クローン方式の問題点を解説

ここで現時点において解決案として議論されている機能の解説に移った。

DataSourceの拡張とアクセス許可を実装する形

実装方法も複数存在したが、dataSourceRefにnamespaceフィールドを追加する方式が最適と判断されたことを説明し、Gateway APIのために実装されたReferenceGrantというリソースを使ってnamespaceを超えたアクセスを可能にする仕様として実装されることを解説した。

Gateway APIが利用する仕様を利用して実装

しかしまだ議論は継続しているとして、ネットワークのためのAPIをストレージのために使うことは混乱を招くという意見もあることを紹介した。

ReferenceGrantを使ってnamespaceを指定できる仕様に拡張

まとめとして、2つの変更を使ってnamespaceを跨いでスナップショットにアクセスを行うことを可能にしたことを次のスライドで解説した。

dataSourceの拡張とReferenceGrantを使ってアクセス許可を行う仕様

ここで開発の状況を解説。すでにKubernetesの本体にはマージされているとして1.29で安定版になるだろうと解説した。

namespace跨ぎの仕様開発の状況

そしてデモとしてWordPressを使ってコンテンツとして書き込まれたMySQLをスナップショットとしてコピーし、別のWordPressからアクセスするというプロセスを実行してみせた。

デモ自体は手順に従って進めて行くだけで、完了した結果は確かにPodというnamespaceで作成されたMySQLのデータがDevというnamespaceのWordPressからアクセスできているというものとなっている。

WordPressを使ってスナップショットを利用するデモを実施

最後にまとめとして課題の整理、解決方法、機能の有効化の方法、使い方などを説明した。

このセッションについては複数の評価が存在するだろう。一つはスナップショットを複数のnamespaceからアクセスしたいというニーズを抱えていたデベロッパーにとっては期待していた機能の確認が可能になったことだろう。しかしそれとは別に、Kubernetes本体に新しい機能を追加する際のプロセスや必要な時間、労力、検討がどのように進むのかを知りたいという層も存在するはずだ。このニーズはまだ顕在化していないが、コミュニティの中での動き方を知りたいという人にとっては2018年の5つの拡張案がどのように収束していったのか、議論の方法や検討のポイントなどについてもう少し掘り下げて解説して欲しいと感じたかもしれない。

デモそのものは、定義の流れが指示したように動くということを確認するためには必須だったかもしれないが、それ以上にどのように議論が進んだのかにもっと時間を使って欲しかったというのが筆者の感想だ。

●動画：Kubernetesのnamespaceを越えて: namespace跨ぎのsnapshotからのvolumeの作成の今と未来