Kubernetesに永続ストレージを追加する際の課題

Kubernetes の採用は爆発的に増加していますが、宣伝されているにもかかわらず、Kubernetes はまだ初期段階にあり、ほとんどの IT インフラストラクチャの不可欠な部分になるにはまだ長い道のりがあります。

同時に、ほとんどの企業や IT ショップでは、Kubernetes の分野に参入する際に、Kubernetes のこの魔法のような新しい世界を探索しようとしているだけです。開発者がプラットフォームで作業を開始する前に、管理者、運用チーム、または DevOps が、従来型でありながら重要なデータ管理コンポーネントを追加するための基盤を構築する必要があります。永続ストレージは、Kubernetes デプロイメントに必要なコンポーネントの良い例ですが、実装するのは簡単ではありません。

ステートレスに永続性を追加する

企業が満たすべき重要な要件は、開発者が永続ストレージの内部の仕組みを気にすることなく、Kubernetes クラスターにデータを保存できることです。

「アプリケーション開発者や DevOps チームはデータ管理者ではありません。DBA にアプリケーション開発者の役割を担わせたくないのと同じように、アプリケーション開発者に DBA の役割を担わせたくありません」と、Enterprise Management Associates (EMA) のアナリスト、John L. Myers 氏は語ります。 「アプリケーション開発者に、コンテナ化されたアプリケーションを展開するたびにゼロから作成することなく、API 経由で永続的なデータ管理レイヤーにアクセスする機会を提供したいのです。」

ただし、Kubernetes の構造上、ステートフル ボリュームへのデプロイメントには適していません。

「コンテナは永続性を持つように設計されたことはないが、企業はワークロードを変更したり、状態を維持したり、異なるワークロードにさらに多くのハードウェアを使用したりするために永続性を必要としている」とコンステレーション・リサーチのアナリスト、ホルガー・ミューラー氏は述べた。 「これは、企業におけるコンテナ設計の欠陥です。企業にとって重要なものはすべて永続的である必要があるからです。」

ただし、Kubernetes には永続ストレージを設定するためのいくつかのオプションが用意されています。たとえば、Kubernetes は、コンテナ オーケストレーション プラットフォームにマウントされたボリューム上で、静的にも動的にもデータを提供する方法を提供する、と MapR の製品管理ディレクターである Suzy Visvanathan 氏は述べています。 「これにより、ユーザーは必要なときに柔軟にストレージを消費できるようになります。」

ただし、Kubernetes が提供する柔軟なボリューム プラグインを使用すると、外部プロバイダーが Kubernetes と統合できるようになりますが、問題もあります。 Visvanathan 氏は、Container Storage Interface (CSI) モデルが導入される前は、プラグインの依存関係が問題であったと述べています。 Apache Mesos、Red Hat、OpenShift、Docker、Amazon Elastic Container Service (EKS)、Google Kubernetes Engine (GKE) for Kubernetes などのクラウド ソリューションを使用すると、オーケストレーション レイヤーは Kubernetes 自体と明示的に統合されます。

「CSI モードにより、外部ストレージ ソリューションを Kubernetes と統合することがはるかに簡単になります」と Visvanathan 氏は述べています。

拡張機能

多くの企業は常に、コンテナ リソースを共有する多数のユーザーに対応するために Kubernetes を拡張することを検討しています。ただし、永続ストレージ コンポーネントをどのように拡張するかは大きな課題です。たとえば、従来のストレージ ソリューションとその構成が必ずしも最適であるとは限りません。

「Kubernetes を使用すると、本番環境でコンテナをすばやく簡単に拡張できます。そのための課題は、それに合わせて拡張できるデータ プラットフォームを提供することです」と MapR の Visvanathan 氏は述べています。 「従来のストレージ オプションでは、この規模に対応できません。Kubernetes に従来のセキュリティ対策を後から導入すると、状況はさらに悪化します。」

「新しい永続ストレージの代替手段は、通常、単一ノードのソリューションであり、クラスター化されていても、グローバルにアドレス指定可能な名前空間やハイブリッド/マルチクラウドのモビリティは提供されません」とMapRのVisvanathan氏は指摘しています。

「Kubernetes は、クラウド スタイルの弾力性と、オンプレミス、ハイブリッド、マルチクラウドの展開など、好みのクラウド モデルを選択できる機能のために使用されています」と Visvanathan 氏は述べています。 「永続ストレージでも同じ目標を達成する必要があります。」

「同時に、内部ストレージを備えたサーバーにコンテナを展開すると、スケーリングがより簡単になります」と、Diamanti の製品マーケティング ディレクターの Sean Roth 氏は述べています。

「保管スペースの拡張は混乱を招き、予想外の大きな追加費用が発生する可能性がある」とロス氏は言う。 「Kubernetes 永続ストレージの主な課題は、主にスケーリングから生じます。コンテナ ストレージ インフラストラクチャに DIY アプローチを採用すると、混乱が生じ、コストがかかる可能性があります。」

最終的に、企業は増加するサーバー間でストレージ使用量のバランスを取る必要があります。 Roth 氏は、Kubernetes デプロイメント全体の共有ストレージに利用可能なリソースは、ネットワーク ファイル システム (NFS) または Ceph や GlusterFS などのオープン ソース クラスター ファイル システム プロトコルで構成できると述べました。

ボリューム統合

上で概説した課題にもかかわらず、Kubernetes は継続的に改善されている幅広いストレージ統合オプションを提供しています。たとえば、Kubernetes は、Kubernetes 上で呼び出されたときに、データを静的にも動的にも提供する方法を提供すると Visvanathan 氏は述べています。 「これにより、ユーザーは必要なときにストレージを消費する柔軟性が得られます。」

実際、Kubernetes のボリューム ストレージ ドライバー オプションにより、永続ストレージ用の複数の異なるメカニズムの使用が容易になると、CloudPassage のポリシー エンジニアリング スペシャリストである Ash Wilson 氏は述べ、一部のボリューム ドライバーは IaaS (サービスとしてのインフラストラクチャ) プラットフォームに固有であり、一部の開発者は基盤となるクラウド インフラストラクチャを理解していないと付け加えました。

「これらのボリューム ストレージ ドライバー オプションは優れていますが、どれがアプリケーションのニーズに最も適しているかを適切に評価して判断するには長い時間がかかります」とウィルソン氏は述べています。 「Kubernetes の永続ストレージのセキュリティ保護に関連するタスクは、多くの場合、ドライバーに固有のものであるため、アーキテクチャ プロセス中にセキュリティを考慮する必要があります。」

ベアメタルサーバーの展開

MapR の Visvanathan 氏は、「Kubernetes の仮想化構造は、永続ストレージを設定する際のベアメタル サーバーの展開にも適しています。これは、コンテナーがオペレーティング システムの下にあるハードウェアではなく、オペレーティング システムを仮想化するためです。」と考えています。

「コンテナは本質的にベアメタルアプリケーションを展開する理想的な方法であり、Kubernetes はコンテナの作成と管理を簡素化します」と Visvanathan 氏は述べています。 「Kubernetes の永続ストレージもベアメタルで最適に提供されるという概念の自然な延長です。コンテナが弾力性を持つようになると、仮想化サーバーは追加のメリットを提供しなくなるため、付加価値のない単なる追加レイヤーになってしまいます。」

安全上の考慮事項

「Kubernetes で実行されるアプリケーションのユーザー アクセス権を決定する際の最大のハードルの 1 つは、Kubernetes ワークロードの動的でステートレスな性質です。実際、Kubernetes ストレージに関する主なセキュリティ上の懸念は、アクセス制御を維持し、権限を承認して、関連するコンテナーとサービスのみが機密データにアクセスできるようにすることです」と、Aqua Security のマーケティング担当副社長である Rani Osnat 氏は述べています。

「これを実現するにはいくつかの方法があるが、それらはアプリケーション コンテキストを持ち、特定のサービスに関連付けられたセキュリティ ポリシーと結び付けられる必要がある」と Osnat 氏は述べた。

Kubernetes 永続ストレージを保護するために提供されるセキュリティ ツールも進化し続けるはずです。つまり、すべてをタイムリーに改善する必要があるということです。

「短命なワークロードでは、特に監査やコンプライアンスの目的で適切なセキュリティ情報を取得することが困難になる可能性があります。これには、アジャイル プロセスを遅らせるのではなく、ツールの進化が必要になる可能性があります」と CloudPassage の Wilson 氏は述べています。 「ストレージ メカニズムの追跡、監査、保護にも同様の課題があります。ツールは、アプリケーション配信プロセスを遅らせることなく、セキュリティ ニーズを満たすように進化する必要があります。」

翻訳者紹介:

Liu Zhihong、IT業界で17年の経験。 NTTデータ、オラクル、中国紙幣鋳造グループ、中国電信クラウドコンピューティング支社に勤務し、クラウドコンピューティングおよびその他の関連するIT研究開発業務に従事。 1 つのソフトウェア著作権を独立して所有しています。現在、電子業界の出版社に勤務。