第9章 レプリカセット レプリカセット
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
個々のコンテナをPodとして実行する方法について説明したが、これらのPodは基本的に1回限りのシングルトンである。 多くの場合、さまざまな理由から、特定の時刻にコンテナの複数のレプリカを実行したい:
- 冗長性
-
複数のインスタンスを走らせることで失敗を許容する。
- スケール
-
複数のインスタンスを実行することで、リクエスト処理能力を高める。
- シャーディング
-
異なるレプリカは、計算の異なる部分を並行して処理することができる。
もちろん、複数の異なる(大部分は似ているが)Podマニフェストを使用してPodの複数のコピーを手動で作成することもできますが、そうするのは面倒でエラーが発生しやすくなります。論理的には、複製されたPodのセットを管理するユーザは、それらを定義および管理すべき単一のエンティティとして考えます。ReplicaSetはクラスタ全体のPodマネージャとして機能し、適切なタイプと数のPodが常に実行されていることを保証する。
ReplicaSetsは複製されたPodのセットを簡単に作成・管理できるため、一般的なアプリケーションのデプロイパターンや、インフラレベルでの自己修復アプリケーションの構成要素となる。ReplicaSetsによって管理されるPodは、ノード障害やネットワーク・パーティションなどの特定の障害条件付きで自動的に再スケジュールされる。
ReplicaSetを考える最も簡単な方法は、Cookieカッターと希望する数のCookieを1つのAPIオブジェクトにまとめることである。 ReplicaSetを定義するとき、作成したいPod(「クッキーカッター」)の仕様と、希望するレプリカの数を定義する。さらに、ReplicaSetが管理すべきPodを発見する方法を定義する必要がある。 レプリケートされたPodを管理する実際の行為は、照合ループの一例である。このようなループは、Kubernetesの設計と実装の大部分にとって基本的なものだ。
和解ループ
和解ループの中心となる概念は、望ましい状態と可観測性または現在の状態という概念である。 望ましい状態とは、望む状態のことである。ReplicaSetでは、それは希望するレプリカの数であり、複製するPodの定義である。例えば、"望ましい状態は、kuard サーバを実行している Pod のレプリカが 3 つあることである"。対照的に、現在の状態は現在観測されているシステムの状態である。 例えば、"現在稼働しているkuard Podは2つだけである"。
和解ループは常に実行され、世界の現在の状態を観察し、観察された状態を望ましい状態に一致させようとするアクションを取る。 例えば、先のインスタンスンスンスでは、融和ループは、観察された状態を3つのレプリカの望ましい状態に一致させるために、新しいkuard Podを作成する。
状態を管理する和解ループ・アプローチには多くの利点がある。 それは、本質的に目標駆動型の自己回復システムであり、しかも多くの場合、数行のコードで簡単に表現できることである。 例えば、ReplicaSetの調整ループは単一ループであるが、ReplicaSetをスケールアップまたはスケールダウンするユーザのアクションや、ノードの障害、または不在だったノードがクラスタに再参加することを処理する。