K8sのデプロイメント＆レプリカセットーパート１

このブログでは、 デプロイメントと レプリカセットのK8sオブジェクトについて説明します。デプロイメントを理解するために、まずはレプリカセットから始めます（その理由はすぐに分かります）。以下は、この記事の流れです。

- レプリカセットとは何か、なぜ必要なのか — レプリカセットによる実践例 — デプロイメントとは何か、なぜ必要なのか — デプロイメントによる実践例

例えば、マークが1つのPOD内でビジネスアプリケーションのホスティングを開始したとします。

この1台のPODは、入ってくるリクエストの量が少ないので、すべてのリクエストを簡単に処理することができます。Markはの業務は順調に進んでおり、アプリケーションの全体的な性能に満足しています。

ビジネスが成長し、マークのアプリケーションに多くのリクエストが来るようになったら、どうなるのでしょうか？

受信リクエストの量が増えてくると、ある時点から、単一のPODでは受信リクエストの負荷に対応できなくなることがほとんどです。また、信頼性、パフォーマンス、スケーリングなどについても懸念が生じるでしょう。

確かに、手動でPodを増やすのはどうでしょうか？

考えてみると、リクエストが増えたり減ったりするたびに、いつどのようにスケールするかを管理するのは大変かもしれませんね。スケールしたノードがクラッシュしたり、さらにスケールアップやスケールダウンが必要になった場合、どのように管理すればいいのでしょうか？

そうですね、ではPODのスケーリングはどのように管理すればいいのでしょうか？

通常、私たちはPOD内のアプリケーションをレプリカセットと呼ばれるもので実行します。これらのPODのレプリカ（オリジナルのPODの同一コピー）は、K8sクラスタの同一または異なるワーカーノードに存在する可能性があります。ここで起こることは、入ってくるリクエストが1つのPODに行くのではなく、レプリカセット内の異なるPODに分散されることです。

クライアントのリクエストは、K8sサービスオブジェクトと呼ばれるものに届きます。このオブジェクトは、与えられたレプリカセット（以前はレプリカコントローラと呼ばれている）内の様々なレプリカPODに、アプリケーションへの受信リクエストの負荷を分散することを容易にします。