はじめに
本ドキュメントでは、Kubernetes 1.19.0のCHANGELOGをベースにSIG Storageに関する機能について紹介します。
がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。
新着情報 (What's New)
CSI Migration - AzureDisk and vSphere(beta)
In-treeのVolume plugin と関連する全てのcloud providerはKubernetes coreの外に移動されます。
CSI migration機能により、全てのボリュームのオペレーションを各々のCSI driverへルーティングすることで、レガシーAPIを使用している既存のVolumeは、コードが削除されても機能し続けることができます。
AzureDiskとvSphereのこの機能の実装はベータに昇格しました。
Storage capacity tracking
これまで、Kubernetesのスケジューラは、追加の永続ストレージがクラスタ内のどこでも利用可能且つ無限の容量をもっているという想定でした。
トポロジーの制約により前者には対応しましたが、しかし、今までのPod スケジューリングは、ストレージの残り容量が新しいPodをスタートさせるのに十分でない可能性があることを考慮していませんでした。
ストレージ容量のトラッキング(アルファ機能)は、CSIドライバー向けにストレージ容量をレポートするAPIを追加することで、KubernetesのスケジューラがPodの新しいノードを選択する際に、この情報を使えるようになりました。
この機能は、容量が制限されるLocal Volumeや他のVolumeタイプのダイナミックプロビジョニングをサポートするための、足がかりとして提供します。
CSI Volume health monitoring
アルファバージョンのCSI ヘルスモニタリングがKubernetes 1.19でリリースされました。
この機能により、CSIドライバーは下位レイヤーのストレージからの異常なボリュームの状態をKubernetesと共有できるようになり、PVCやPodのイベントへ報告できます。
この機能は、Kubernetesにて個々のボリュームのヘルスイシューに対しプログラムでの検出と解決を行うための、足がかりとして提供します。
General ephemeral volumes
Kubernetesは、ライフサイクルがPodに関連づけられているスクラッチスペース(組み込みの"empty dir"のボリュームタイプ)や、Pod内にデータをロードするため(組み込みのConfigMapとSecretのボリュームタイプや"CSI inline volumes")に使用できるvolume pluginsをサポートします。
この新しいgeneric ephemeral volumes のアルファ機能では、ダイナミックプロビジョニングをサポートする既存のストレージドライバーをボリュームのライフサイクルがPodに結び付けられたephemeral volumeとして使用できるようになりました。
これを利用して、rootディスクが異なるスクラッチストレージ(例えば persistent memory)や、ノード上で分かれているローカルディスクを提供できます。
ボリュームプロビジョニングのためのStorageClassの全てのパラメータはサポートされています。
Storage capacity trackingやSnapshot/Restore, Volumeのサイズ変更など、PersistentVolumeClaimの全ての機能はサポートされています
Immutable Secrets and ConfigMaps (beta)
SecretとConfigMap volumeはimmutableとしてマークできます。
これにより、クラスタ内に多くのSecretとConfigMap volumeがある場合に、API サーバの負荷を大幅に削減できます。
詳細については、ConfigMapとSecretをご参照ください。
CSI Proxy for Windows
Windows向けCSI Proxyが1.19でベータに昇格しました。
CSI Proxyは、Windowsのコンテナが特権のストレージ操作を実行できるようにすることで、CSI ドライバーがWindows上で実行できるようにしました。
ベータでは、Windows用のCSI Proxyはダイレクトアタッチトディスク(DAS)とSMBを使用するストレージドライバーをサポートしました。
既知の問題点 (Known Issues)
新しく登場したアルファ機能のStorage capacity trackingは、ボリュームのbinding modeWaitForFirstConsumer
の制限の影響を受けることが知られています #94217
WaitForFirstConsumer
は、最初にボリュームが消費されるまでBindingを遅延させるモードです。このモードでは複数のボリュームをもつPodの場合に失敗することがあります。
(例)
- 最初のボリュームが作成
- ノードにアクセス可能なトポロジセグメントに十分なスペースがないため、2番目のボリュームの作成が失敗
- Podは再スケジューリングされるが、最初のボリュームがあるため、同じノードに配置
- 2と同様にボリュームの作成に失敗
アップグレード前に絶対に確認が必要な変更点 (Urgent Upgrade Notes)
(No, really, you MUST read this before you upgrade)
- ACTION REQUIRED: coreのmaster baseイメージ(kube-contoller-manager)をdebian から distrolessへ変更してください。もし、スクリプトを使用するFlex Volumeのサポートが必要な場合には、必要なパッケージ(bashなど)を持った独自イメージをビルドしてください。 (#91329, @dims) [SIG Cloud Provider, Release, Storage and Testing]
- Azure blob disk(kind:
Shared
,Dedicated
)は非推奨になりました。kind: Managed
をkubernetes.io/azure-disk
のStorage Classで使用する必要があります。 (#92905, @andyzhangx) [SIG Cloud Provider and Storage]
Changes by Kind
非推奨 (Deprecation)
- vSphere in-tree volumeからvSphere CSI dirverへのマイグレーションが追加されました。これにより、in-tree vSphere volume pluginは非推奨になり、将来のバージョンで削除されます。(#90911, @divyenpatel) [SIG API Machinery, Node and Storage]
- vSphereにKubernetesをセルフデプロイしているユーザは、CSIMigration+CSIMigrationvSphereを有効にし、vSphere CSI Driver(https://github.com/kubernetes-sigs/vsphere-csi-driver )をインストールし、その際の既存のPodとPVCの中断を回避する必要があります。ユーザは新しいボリューム向けにvSphere CSI Driverを直接起動する必要があります。
- vSphereボリュームのCSI Migrationでは、vSphere vCenter/ESXiの最小バージョンが7.0u1、HWバージョンがVMバージョン15が必要です。
- vSANのraw policyのパラメータはin-tree vSphere Volume Pluginで非推奨となり、将来のバージョンで削除される予定です。
- volume capabilityとstaging target fieldsはnodeExpansionのCSIコールで確認されます。 NodeStageとNodePublishの間で呼び出されるNodeExpandVolumeの動作はCSIボリュームでは非推奨です。 CSI driverでは、node EXPAND_VOLUME機能がある場合、NodePublishの後にNodeExpandVolumeの呼び出しをサポートする必要があります。 (#86968, @gnufied) [SIG Storage]
- Feat: azure disk migrationは1.19でベータになりました。Feature gates のCSIMigrationはベータでデフォルトOnおよびCSIMigrationAzureDiskはベータでデフォルトOff(AzureDisk CSI Driverをインストールする必要があるため)となります。in-tree AzureDisk Plugin "kubernetes.io/azure-disk" は非推奨となり1.23で削除される予定です。ユーザはCSIMigration+CSIMigrationAzureDiskを有効にして、AzureDisk CSI Driver (https://github.com/kubernetes-sigs/azuredisk-csi-driver )をインストールし、その際の既存のPodとPVCの中断を回避する必要があります。ユーザは新しいボリューム向けにAzureDisk CSI Driverを直接起動する必要があります。(#90896, @andyzhangx) [SIG Cloud Provider and Storage]
- storage.k8s.io/v1beta1が非推奨になり、storage.k8s.io/v1 となりました。(#90671, @deads2k) [SIG Storage]
API周りの変更 (API Change)
- 新しいアルファレベルのフィールドとして、CSIDriversがボリュームの所有権とパーミッションの変更をサポートするかどうかを指定できるSupportsFsGroupが導入されました。このフィールドを利用するためには、
CSIVolumeSupportFSGroup
feature gate を有効にする必要があります。(#92001, @huffmanca) [SIG API Machinery, CLI and Storage] -
GenericEphemeralVolume
feature gateのもと新しいアルファ機能となったGeneric ephemeral volumesは、EmptyDir
ボリュームより柔軟な代替手段を提供します。EmptyDir
として同様に
、Kubernetesによってい各Podのボリュームが自動で作成・削除されます。しかし、通常のプロビジョニングプロセス(PersistentVolumeClaim)が使用されるため、サードパーティのストレージベンダーがストレージを提供することができ、通常のボリュームの機能が全て動作します。また、ボリュームは必ず空にする必要はありせん。例えば、SnapshotからのRestoreがサポートされています。 (#92784, @pohly) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing]
機能 (Feature)
- Azure file driverのタグをサポートしました。(#92825, @ZeroMagic) [SIG Cloud Provider and Storage]
- Azure disk driverのタグをサポートしました。(#92356, @andyzhangx) [SIG Cloud Provider and Storage]
- Cloud node-controllerがInstanceV2を使用するようになりました。 (#91319, @gongguan) [SIG Apps, Cloud Provider, Scalability and Storage]
- Feat: azure shared diskのサポートを追加しました。 (#89511, @andyzhangx) [SIG Cloud Provider and Storage]
- Feat: azure diskのapi-versionが変わりました。 (#89250, @andyzhangx) [SIG Cloud Provider and Storage]
- Feat: Azure shared diskがサポートされ、azure diskのStorageClassに新しいフィールド(
maxShares
)が追加されました。(#89328, @andyzhangx) [SIG Cloud Provider and Storage] -
CSIMigrationvSphere
feature gatesがベータになりました。ユーザーはCSIMigration + CSIMigrationvSphereを有効にし、vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver )をインストールした後、ワークロードをin-tree vSphere plugin ”kubernetes.io/vsphere-volume” からvSphere CSI Driverへ移動する必要があります。(#92816, @divyenpatel) [SIG Cloud Provider and Storage]- Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15
- azure-sdk v40.2.0へアップデートされました。 (#89105, @andyzhangx) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Storage and Testing]
ドキュメンテーション (Documentation)
SIG Storage関連はなし
失敗しているテスト (Failing Test)
SIG Storage関連はなし
バグまたはリグレッション (Bug or Regression)
- in-treeのソースからのPVはCSIPersistentVolumeSourceへ変換される際、NodeAffinityの要求値が順序づけされます(#88987, @jiahuif) [SIG Storage]
csi-translation-lib中のZonesのフィルターリスト(filteredZones)の並び替えを行っています。これにより、このオブジェクトの比較が容易になりテストコード(TestAddTopology)が楽になりました。
- API Serverに到達できない場合やkubeletに適切なクレデンシャルが設定される前に、CSINodeの初期化でkubeletがクラッシュしなくなりました (#89589, @jsafrane) [SIG Storage]
- CSI driverがFailedPreconditionエラーを返した場合、volume expansionをリトライしない (#92986, @gnufied) [SIG Node and Storage]
- 変更されたConfigMapまたはSecretのSubPathのボリュームマウントを使っているコンテナの再起動に関する問題を修正しました。(#89629, @fatedier) [SIG Architecture, Storage and Testing]
- 停止中のxfsのマウントによるxfs_repairのバグを修正しました。(#89444, @gnufied) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
- Azure FileのCSI translationに関するバグを修正しました。 (#90162, @rfranzke) [SIG Release and Storage]
- max count テーブル中にアイテムがない場合、ディスクのアタッチエラーが発生するバグを修正しました。 (#89768, @andyzhangx) [SIG Cloud Provider and Storage]
- Azure diskのmax countの最大値を修正しました。(#92331, @andyzhangx) [SIG Cloud Provider and Storage]
- Azure disk & file のマウント時の初期化の遅延を修正しました。(#93052, @andyzhangx) [SIG Cloud Provider and Storage]
- iSCSIとFibreChannel volume pluginのmountOptionのバグを修正しました。 (#89172, @jsafrane) [SIG Storage]
- Fixed using of a read-only iSCSI volume in multiple pods.
- 複数のPodでのRead-onlyのiSCSI volumeの使用について修正しました(#91738, @jsafrane) [SIG Storage and Testing]
iSCSI volume pluginではPodにマウントされる前にボリュームメタデータをグローバルマウントディレクトリにマウントします。この状況で2つ目のPodが同一ノードの同じボリュームを利用する場合、kubeletはメタデータを壊さないようにする必要があります。
- informerを使いCSI volumeのアタッチメントのスケーリングに関する問題を修正しました。 (#91307, @yuga711) [SIG API Machinery, Apps, Node, Storage and Testing]
- ディレクトリ以外のhostpathタイプがHostPathFileと認識されるバグを修正しHostPathTypeのe2eテストを追加しました。(#64829, @dixudx) [SIG Apps, Storage and Testing]
- 外部ストレージのe2eテストスイートにてVolumeSnapshotClassの入力が明示的に提供されている場合、VolumeSnapshotClassからsnapshot provisionerを選択するようにexternal driverを修正しました。(#90878, @saikat-royc) [SIG Storage and Testing]
- ボリュームの拡張や作成時にPVCが要求するサイズのオーバーフローを防止します。(#90907, @gnufied) [SIG Cloud Provider and Storage]
- v1.18.0-rc.1のWindows Volumeのマウントのバグ修正を取り込みました。 (#89319, @mboersma) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Storage]
その他 (Cleanup or Flake)
- fsTypeが指定されていない場合に、cinderのfsTypeの値を
ext4
に設定します。 (#90608, @huffmanca) [SIG Storage] - Podからは使われているがdelay bindingモードでバインドされていないPVCの場合、WaitingForPodScheduledイベントを発行します。(#91455, @cofyc) [SIG Storage]
- ボリューム操作のエラー時のイベントのスパムを削減します。(#89794, @msau42) [SIG Storage]
所感
KubernetesのPersistent Storage関連のコードがin-treeからCSIへの移行が加速してきました。
これに関連し、Kubernetes v1.19ではAzure, vSphereのCSI Migrationがベータになり、これに関する機能追加や修正が多く取り込まれています。
また、アルファですがGeneral ephemeral volumesも登場し、empty dirやConfigMap, Secretなどにも利用できるvolume pluginも新たに登場してきました。
いよいよ、in-treeのストレージ関連のコードがなくなる日が近いと感じるバージョンです。