[講演] Kubernetesの課題解決に向けた取り組み (Open Source Summit Japan 2021)

2022年4月20日公開

2021年12月14日(火)～15日(水)にオンラインで開催された「Open Source Summit Japan 2021」において、NECソリューションイノベータ 毛利　唯子が、「Kubernetes failover improvement: Self-healing of Pod with Persistent Volume when Kubernetes Node is Down」というテーマで発表を行いました。

Open Source Summit Japanは、Linux Foundationが日本で開催する大規模なカンファレンスで、オープンソース エコシステムが一堂に会します。技術者やオープンソース リーダー企業が、コラボレーションと情報共有のために、そして最新のオープンソース技術を学ぶために、あるいは革新的なオープン ソリューションを使った競争力の付け方を見つけるために集結します。Open Source Summit Japan 2021には、同時開催のAutomotive Linux Summitを含め、約430名、約30カ国から参加者がありました。

本講演では、Kubernetesの利用者が直面している運用時の課題と、開発コミュニティでの課題解決に向けた対応、オープンソースコミュニティにおける開発の難しさについてご紹介しました。リアルタイムで50名の方に参加いただきました。

タイトル：「Kubernetes failover improvement: Self-healing of Pod with Persistent Volume when Kubernetes Node is Down」

講演動画：YouTube - https://youtu.be/PyRtFXDofYI

Kubernetes利用者が直面している運用時の課題

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースのプラットフォームです。アプリケーションコンテナは、密接に結合した他のアプリケーションコンテナとPodと呼ばれるグループを構成します。Podは、ワーカーノードと呼ばれる仮想マシンや物理マシン上に構成されたノード上で実行されます。複数のワーカーノードは、Kubernetes クラスタを構成します。

Kubernetes クラスタのワーカーノードのひとつがハードウェア故障等によりダウンした際、Kubernetes コントローラはその障害ノード上の Pod 群を他のノード上で再作成します。しかし、永続化ボリューム(PV: Persistent Volume)を持つPodの場合、現状の実装では、障害ノード上で古い Pod の PVがデタッチできないため、PV 付き Podの再作成は常に失敗してしまう課題があります。

Kubernetes 利用者の多くは、ノード障害発生時に回避策として手動操作や非公式ツールを使用して PV 付き Pod の強制削除を行っています。本来は こうしたケースでも Kubernetes 自体が自動的かつ正常に PV 付き Pod を削除してほしいという要望をたくさんのお客様から聞きます。

Kubernetes 開発コミュニティにおける現在の議論

Kubernetes開発コミュニティでは、この課題を解決しようと、以前からKubernetes Enhancement Proposals (KEP)と呼ばれるKubernetesの新機能提案が出されていたものの、解決策が決まらないままフェードアウトしています。2021年12月時点では、2019年に出された KEP #1116 で議論が続いています。Podをノードへスケジューリングさせないための機能のTaintsを利用した、以下のような解決策が提案されています。

オープンソースコミュニティにおける開発の難しさ

PV 付き Podの課題は、KEPは2019年に投稿されたため、3年間も議論が続いていることになります。このKEPに限らず、オープンソースコミュニティにおいては、多くの機能提案が行われても、議論が長引きなかなか実装に進まないケースや、時には実装に至らず議論がフェードアウトするケースが少なくありません。今回ご紹介したKEPを例に挙げ、なぜこれほどまでも議論が長引き、結論を出すのに時間がかかるのか、その原因を考察し、対応策を紹介しました。

1. ユースケースが整理されていない
       - 本KEPは「ノードがダウンした場合」のKubernetesの挙動を扱っています。ノードダウンと一口に言っても、例えばハードウェアが故障した場合やOSの不具合、ネットワーク障害によってノードとKubernetesコントローラが通信できない場合など様々なケースがあります。
2.  
3. 複数のプロジェクトに影響が及ぶ
       - 本KEPが提案する機能はストレージを扱うプロジェクトとノードを扱うプロジェクトという2つのプロジェクトに影響を与えます。したがって、本KEPの承認には両プロジェクトの合意が必要になります。
4.  
5. リリースサイクルの問題
       - Kubernetesのリリースサイクルは4ヶ月です。また、「Enhancements Freeze」と呼ばれる締め切りがあり、KEPはリリースサイクル開始から3週間以内という非常に短い期間で承認される必要があります。本KEPは前述のとおり複数のプロジェクトに影響を与えることもあり、短期間で議論を収束させることは非常に難しいです。またEnhancements Freezeを過ぎると開発者はバグ修正やドキュメント修正等の作業に忙しくなるため、次のリリースサイクルが始まるまではKEPの議論に時間を費やすのが難しいという状況がよく見られます。
6.  

このような点を踏まえて、本KEPにおいては、技術的な観点でのレビューに加え、KEPの承認に必要なプロセスを確認し、不足している作業をコメントしたり、KEP投稿者と直接連絡を取って進捗報告を確認したりする等、リリースサイクル内での承認を目的として積極的に活動しました。また、OSSコミュニティでの開発活動においては、企業が業者に開発業務を発注して開発を行うようなやり方と違い、開発者同士に金銭的対価の関係はありません。したがって、開発の完遂責任はありません。極端に言えば、提案したKEPを途中で放り出しても誰もそれを責めることはできないのです。そのことに留意して、たとえKEPの更新が滞っていても、それを督促するようなことはせず、「あなたが対応することが難しいようなら私の方で引き取ります」といったコメントをするなど、OSS開発コミュニティのマナーを持って接するよう気を付けました。

このような取り組みを行い、多くのKubernetes 利用者が恩恵を得られる本KEPの仕様策定に協力しました。

（本KEPはOpen Source Summit Japan 2021で発表を行った後、仕様修正の上 無事承認されました。また、この実装はKubernetes v1.24.0の新機能のひとつとして5月3日にリリースされました）

講演者

OSS貢献活動へ戻る