コンテナとクラウド|Kubernetesレプリケーション・コントローラの仕組み

レプリケーション・コントローラーは、ポッドのライフサイクルを管理し、指定された数の必要なポッドが常に実行されるようにする責任を負います。

Kubernetesクラスタ内で稼働している""ポッド""の正確な数を監督・管理するのは誰なのか疑問に思ったことはありませんか？Kubernetesではさまざまな方法でこれを行うことができますが、一般的なアプローチは""RC""を使用することです。は、Podのライフサイクルを管理し、必要な指定数のPodが任意の時点で実行されていることを保証する役割を担っています。しかしその一方で、自動スケーリングの実行、レディネスとアクティビティのプローブ、その他の高度なレプリケーション機能といった高度なクラスタ機能については責任を負いません。

つまり、RCの責任は限定的であり、特定の要件を満たすために複雑なロジックを必要としない特定の実装に使用されるのが一般的です。必要な数を超えた場合、RCは超過分を削除し、ノードの障害やポッドの終了があっても同じ数が存在するようにします。

単純なことに複雑な解決策は必要ありません。私にとって、これはRCの使い方の完璧な例えです。

RCの作成方法

ほとんどのKubernetesリソースと同様に、YAMLまたはJSONフォーマットを使用してRCを作成し、Kubernetes APIエンドポイントに公開することができます。

$ kubectl create -f rcexample.yaml
 replicationcontroller/rcexample created

では、 rcexample.yaml どのようなものなのか、もう少し深く掘り下げてみたいと思います。

apiVersion: v1
kind: ReplicationController → RCディスクリプタ 
metadata:
 name: rcexample → レプリケーションコントローラ名 
 replicas: 3 → 予想されるポッド数 
 selector: → このRCのポッドセレクター
 app: nginx 
 template: → 新しいポッドを作成するためのテンプレート 
metadata:
 labels: 
 app: nginx 
 spec: 
 containers: 
 - name: nginx 
 image: nginx

さらに詳しく説明すると、このファイルを実行するとrcexampleというRCが作成され、nginxという名前の3つのポッドインスタンスが常に実行されるようになります。app=nginxポッドの1つまたはすべてが実行されていない場合、定義されたポッドテンプレートに基づいて新しいポッドが作成されます。

RCには3つの部分があります：

• 複製品：
• ポッドテンプレート：app=nginx
• ポッドセレクター:app=nginx

RCが常にPodを作成するのを防ぐため、PodテンプレートはPodセレクタと一致する必要があることに注意してください。テンプレートと一致しないポッドセレクタでRCを作成した場合、Kubernetes APIサーバーはエラーを出します。

RC 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

RCを削除するには

$ kubectl delete rc rcexample
 replicationcontroller "rcexample" deleted

RCのサービスの ローリングアップデート ポリシーを使用して、ポッドを1つずつ置き換えることができます。

コンテナを複製するその他の方法

Kubernetesのデプロイメントでコンテナを複製する方法は複数あります。Kubernetesがコンテナプラットフォームの主要な選択肢である主な理由の1つは、信頼性、ロードバランシング、およびネイティブなスケール機能のためにコンテナを複製することです。

上記では、いつでも一定数のポッドが利用できるようにRCを簡単に作成する方法を紹介しました。コピーの数を更新することで、ポッドを手動で拡張できます。

コピーを実現するもうひとつの方法は、"

(kind: ReplicaSet)

RSの機能はRCとほぼ同じです。主な違いは、RSはローリングアップデートポリシーを許可していないことです。

レプリケーションを実装するもうひとつの方法は、"

(kind: Deployment)

デプロイは、コンテナレプリケーションのより高度なアプローチです。機能的には、デプロイは同じ機能を提供しますが、必要に応じて変更をロールアウトおよびロールバックする機能があります。このような機能が実現できるのは、デプロイメントに古いポッドを新しいポッドに置き換える「」仕様があるからです。デプロイメント ポリシーには、""と""の 2 種類を定義できます。デプロイポリシーは次のように指定します：

StrategyType: RollingUpdate

まとめ

コンテナのレプリケーション機能は、ほとんどの組織がKubernetesの採用を検討する主な理由の1つです。レプリケーションによって、ほとんどの重要なアプリケーションが本番環境の最低要件として必要とする信頼性とスケーラビリティを実現できます。

Kubernetesクラスタでレプリケーションを実装するためにどの方法を使用するかを理解することは、アプリケーションアーキテクチャの考慮事項に最適な方法を決定する上で重要です。