Kubernetes ReplicationController の仕組み
ReplicationController は、ポッドのライフサイクルを管理し、必要な指定された数のポッドが常に実行されていることを確認する責任があります。
Kubernetes クラスター内で実行されているポッドの正確な数を監視および管理する役割は何なのか考えたことはありますか? Kubernetes はこれを複数の方法で実行できますが、一般的なアプローチの 1 つは ReplicationController (rc) を使用することです。 ReplicationController は、ポッドのライフサイクルを管理し、必要な指定された数のポッドが常に実行されていることを確認する責任があります。一方、自動スケーリング、準備状況および活性プローブの実行、その他の高度なレプリケーション機能などの高度なクラスター機能は担当しません。 Kubernetes クラスター内の他のコンポーネントは、これらの機能をより適切に実行します。
関連性のあるコンテンツ
つまり、ReplicationController の責任は限定されており、通常は、特定の要件 (たとえば、必要なポッド数が指定された数と常に一致すること) を達成するために複雑なロジックを必要としない特定の実装に使用されます。必要な数を超えるポッドがある場合、ReplicationController は余分なポッドを削除し、ノード障害やポッドの終了が発生した場合でも同じ数のポッドが存在するようにします。
シンプルなものには複雑なソリューションは必要ありません。私にとって、これは ReplicationController の使用方法を表す完璧な比喩です。
ReplicationController を作成する方法
ほとんどの Kubernetes リソースと同様に、YAML または JSON 形式を使用して ReplicationController を作成し、それを Kubernetes API エンドポイントにポストできます。
$ kubectl create -f rcexample.yaml
replicationcontroller/rcexample created
ここで、rcexample.yaml
がどのようなものであるかをもう少し詳しく見ていきます。
apiVersion: v1
kind: ReplicationController → rc descriptor
metadata:
name: rcexample → Name of the replication controller
spec:
replicas: 3 → Desired number of pods
selector: → The pod selector for this rc
app: nginx
template: → The template for creating a new pod
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
さらに詳しく説明すると、このファイルを実行して rcexample
という ReplicationController を作成すると、nginx
というポッドの 3 つのインスタンスが常に実行されるようになります。 1 つまたはすべてのポッド app=nginx
が実行されていない場合は、定義されたポッド テンプレートに基づいて新しいポッドが作成されます。
ReplicationController には 3 つの部分があります。
- レプリカ: 3
- ポッドテンプレート: app=nginx
- ポッドセレクター: app=nginx
ReplicationController が無期限にポッドを作成しないように、ポッド テンプレートがポッド セレクターと一致していることに注意してください。テンプレートと一致しないポッド セレクターを使用して ReplicationController を作成すると、Kubernetes API サーバーによってエラーが発生します。
ReplicationController rcexample
が作成されたことを確認するには、次のようにします。
$ kubectl get po
NAME READY STATUS RESTARTS AGE
rcexample-53thy 0/1 Running 0 10s
rcexample-k0xz6 0/1 Running 0 10s
rcexample-q3vkg 0/1 Running 0 10s
ReplicationController を削除するには、次の手順を実行します。
$ kubectl delete rc rcexample
replicationcontroller "rcexample" deleted
ポッドを 1 つずつ置き換えることにより、ReplicationController のサービスに対してローリング アップデート戦略を使用できることに注意してください。
コンテナをレプリケートするその他の方法
Kubernetes デプロイメントでは、コンテナーのレプリケーションを実現する方法が複数あります。 Kubernetes がコンテナ プラットフォームの主な選択肢である主な理由の 1 つは、コンテナを複製して信頼性、負荷分散、およびスケーリングを実現するネイティブ機能です。
上記では、特定の数のポッドを常に利用できるようにする ReplicationController を簡単に作成する方法を説明しました。レプリカの数を更新することで、ポッドを手動でスケールできます。
レプリケーションを実現するもう 1 つの可能なアプローチは、ReplicaSet を使用することです。
(kind: ReplicaSet)
ReplicaSet (rs) の機能は ReplicationController とほぼ同じです。主な違いは、ReplicaSet ではローリング更新戦略が許可されていないことです。
レプリケーションを実現するもう 1 つのアプローチは、Deployments を使用することです。
(kind: Deployment)
デプロイメントは、より高度なコンテナー レプリケーションのアプローチです。機能的には、デプロイメントは同じ機能を提供しますが、必要に応じて変更をロールアウトおよびロールバックできます。この機能が可能になるのは、Deployments に古いポッドを新しいポッドに置き換える StrategyType 仕様があるためです。定義できる展開戦略には、再作成とローリングアップデートの 2 種類があります。以下に示すように展開戦略を指定します。
StrategyType: RollingUpdate
結論
コンテナのレプリケーションは、ほとんどのエンタープライズ コンテナの導入において Kubernetes が考慮される主な理由の 1 つです。レプリケーションにより、最も重要なアプリケーションが実稼働の最小要件として必要とする信頼性と拡張性を実現できます。
Kubernetes クラスターでレプリケーションを実現するためにどの方法を使用するかを理解することは、アプリケーション アーキテクチャの考慮事項にどの方法を組み込むのが最適かを決定するために重要です。