第2章 Kubernetesでデータストレージを管理する Kubernetesでデータストレージを管理する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
ステートレスアーキテクチャなど存在しない。すべてのアプリケーションはどこかに状態を保存する。
StorageOS、CEO、アレックス・チルコップ
前章では、Kubernetes上でパワフルでステートフルなデータ集約型アプリケーションが動作する近未来の可能性を描いた。そのためには、永続化、ストリーミング、分析のためのデータインフラが必要になる。このインフラを構築するには、Kubernetesが提供するプリミティブを活用して、クラウド・コンピューティングの3つのコモディティであるコンピュート、Network、ストレージの管理を支援する必要がある。次の数章では、これらのプリミティブをどのように組み合わせれば必要なデータインフラを作成できるのか、ストレージから順に見ていく。
Alex Chircop氏による指摘と同じように、すべてのアプリケーションはその状態をどこかに保存しなければならない。そのためこの章では、Kubernetesがストレージとやり取りするために提供する基本的な抽象化に焦点を当てる。また、クラウドネイティブの原則を体現するKubernetes用のストレージインフラを作成するストレージベンダやオープンソースプロジェクトが提供する新たなイノベーションについても見ていく。
一般化されたコンテナ化アプリケーションの永続性管理から調査を開始し、Kubernetes上のデータ・ストレージを調査するためのジャンプ・ポイントにしよう。
Docker、コンテナ、ステート
分散クラウドネイティブアプリケーションにおける状態管理の問題は、Kubernetesに限ったことではない。検索すれば、ステートフルなワークロードは、MesosやDocker Swarmといった他のコンテナオーケストレーションプラットフォームでも懸念されてきた分野であることがわかるだろう。その一部はコンテナ・オーケストレーションの性質に関係しており、一部はコンテナ自体の性質に起因している。
まず、コンテナについて考えてみよう。コンテナの重要な価値提案のひとつは、その刹那的な性質だ。コンテナは使い捨てで交換可能なように設計されているため、素早く起動し、オーバーヘッド処理に使用するリソースをできるだけ少なくする必要がある。このため、ほとんどのコンテナイメージは、Ubuntuなどの合理化されたLinuxベースのオープンソースオペレーティングシステムを含むベースイメージから構築され、素早く起動し、含まれるアプリケーションorマイクロサービスに不可欠なライブラリのみを組み込む。その名前付けの通り、コンテナは自己完結するように設計されており、すべての依存関係を不変性イメージに組み込み、設定とデータは外部化される。これらの特性によりコンテナはポータブルになり、互換性のあるコンテナ・ランタイムがあればどこでも実行できるようになる。
図 2-1 に示すように、コンテナは、VM ごとにゲスト・オペレーティング・システムを実行する従来の仮想マシンよりもオーバーヘッドが少なく、基盤となるホスト・オペレーティング・システムにシステムコールを実装するハイパーバイザ層が必要である。
図2-1. コンテナ化と仮想化を比較する
コンテナはアプリケーションの移植性を高めたが、データの移植性を高めることはより大きな ...