第3章. Kubernetes上のデータベースをハードな方法で実現する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
第1章で説明したように、Kubernetesはステートレスワークロードのために設計された。このことは、Kubernetesが最も得意とするのはステートレスワークロードであることを意味している。このため、Kubernetes上でステートフルなワークロードを実行しようとすべきではないと主張する人もおり、代わりに何をすべきかについてさまざまな推奨を耳にすることがある:"マネージドサービスを使え "とか、"オンプレミスのデータセンターにあるレガシーデータベースにデータを残しておけ "とか、あるいは "クラウドでデータベースを稼動させるが、コンテナではなく従来の仮想マシンで稼動させろ "とか。
これらの推奨は依然として実行可能な選択肢ではあるが、本書における我々の主な目標の1つは、Kubernetesでデータインフラを実行することが実行可能な選択肢であるだけでなく、好ましい選択肢になったことを示すことである。Christopher Bradford氏の記事"A Case for Databases on Kubernetes from a Former Skeptic "では、Kubernetesでステートフルなワークロードを実行することに懐疑的だった彼が、開発やテストのワークロードのためにKubernetes上でデータインフラを実行することを不承不承受け入れ、本番環境でKubernetes上でデータベースをデプロイすることを熱狂的に支持するようになるまでの道のりが述べられている。この道のりは、Data on Kubernetesコミュニティ(DoKC)の多くの典型だ。2020年の半ばまでに、Boris Kurktchievは、彼の記事「3 Reasons to Bring Stateful Applications to Kubernetes」の中で、Kubernetes上でステートフルなワークロードを管理することが実行可能であり、さらには成熟の域に達しているというコンセンサスの高まりを挙げることができた。
この変化はどのようにして生まれたのか?ここ数年、Kubernetesコミュニティは、Kubernetes上でクラウドネイティブな方法でステートを管理する機能をサポートする機能を追加する方向にフォーカスを移してきた。前章で紹介したKubernetes PersistentVolumeサブシステムやCSIの採用など、このシフトの大きな部分を占めるのがストレージ要素だ。この章では、このストレージ基盤の上にステートフルなアプリケーションを構築するためのKubernetesリソースを見て、この部分を完結させる。特に、特定のタイプのステートフル・アプリケーション、すなわちデータインフラに焦点を当てる。
困難な道
困難な道を行く」という言葉は、安易な選択肢を避け、永続的な意味を持つ結果を達成するために必要な細かな作業に打ち込むことを意味するようになった。歴史上、あらゆるパイオニアたちは、血と汗と涙の犠牲を払って、後の世代に少しでも生きやすくしてあげたという自負を持っていることでよく知られている。こうした長老たちは、自分たちが経験しなければならなかったことの深さを弟子たちが理解できないと嘆くのをよく耳にする。
テクノロジーの世界でもそれは同じだ。APIや「コードなし」 ...