6.2. デプロイメントの理解
Red Hat OpenShift Service on AWS の Deployment
および DeploymentConfig
API オブジェクトは、一般的なユーザーアプリケーションに対する詳細な管理を行うためのよく似ているものの、異なる 2 つの方法を提供します。これらは、以下の個別の API オブジェクトで構成されています。
-
アプリケーションの特定のコンポーネントの必要な状態を記述する、Pod テンプレートとしての
Deployment
またはDeploymentConfig
。 -
Deployment
オブジェクトには、1 つ以上の レプリカセット が使用され、これには Pod テンプレートとしてのデプロイメントの特定の時点の状態のレコードが含まれます。同様に、DeploymentConfig
オブジェクトには、1 つ以上の レプリケーションコントローラー (以前はレプリカセットでした) が含まれます。 - 1 つまたは複数の Pod。 特定バージョンのアプリケーションのインスタンスを表します。
DeploymentConfig
オブジェクトで特定の機能または動作を指定する必要がない場合、Deployment
オブジェクトを使用します。
Red Hat OpenShift Service on AWS 4.14 では、DeploymentConfig
オブジェクトは非推奨になりました。DeploymentConfig
オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。
代わりに、Deployment
オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。
6.2.1. デプロイメントのビルディングブロック
デプロイメントおよびデプロイメント設定は、それぞれビルディングブロックとして、ネイティブ Kubernetes API オブジェクトの ReplicaSet
および ReplicationController
の使用によって有効にされます。
ユーザーは、Deployment
または DeploymentConfig
オブジェクトによって所有されるレプリカセット、レプリケーションコントローラー、または Pod を操作する必要はありません。デプロイメントシステムは変更を適切に伝播します。
既存のデプロイメントストラテジーが特定のユースケースに適さない場合で、デプロイメントのライフサイクル期間中に複数の手順を手動で実行する必要がある場合は、カスタムデプロイメントストラテジーを作成することを検討してください。
以下のセクションでは、これらのオブジェクトの詳細情報を提供します。
6.2.1.1. レプリカセット
ReplicaSet
は、指定された数の Pod レプリカが特定の時点で実行されるようにするネイティブの Kubernetes API オブジェクトです。
カスタム更新のオーケストレーションが必要な場合や、更新が全く必要のない場合にのみレプリカセットを使用します。それ以外はデプロイメントを使用します。レプリカセットは個別に使用できますが、Pod 作成/削除/更新のオーケストレーションにはデプロイメントでレプリカセットを使用します。デプロイメントは、自動的にレプリカセットを管理し、Pod に宣言的更新を加えるので、作成するレプリカセットを手動で管理する必要はありません。
以下は、ReplicaSet
定義の例になります。
apiVersion: apps/v1 kind: ReplicaSet metadata: name: frontend-1 labels: tier: frontend spec: replicas: 3 selector: 1 matchLabels: 2 tier: frontend matchExpressions: 3 - {key: tier, operator: In, values: [frontend]} template: metadata: labels: tier: frontend spec: containers: - image: openshift/hello-openshift name: helloworld ports: - containerPort: 8080 protocol: TCP restartPolicy: Always
6.2.1.2. レプリケーションコントローラー
レプリカセットと同様に、レプリケーションコントローラーは、Pod の指定された数のレプリカが常に実行されるようにします。Pod が終了または削除された場合に、レプリケーションコントローラーは定義した数になるまでインスタンス化する数を増やします。同様に、必要以上の数の Pod が実行されている場合には、定義された数に一致させるために必要な数の Pod を削除します。レプリカセットとレプリケーションコントローラーの相違点は、レプリカセットではセットベースのセレクター要件をサポートし、レプリケーションコントローラーは等価ベースのセレクター要件のみをサポートする点です。
レプリケーションコントローラー設定は以下で構成されています。
- 必要なレプリカ数 (これはランタイム時に調整可能)。
-
レプリケートされた Pod の作成時に使用する
Pod
定義。 - 管理された Pod を識別するためのセレクター。
セレクターは、レプリケーションコントローラーが管理する Pod に割り当てられるラベルセットです。これらのラベルは、Pod
定義に組み込まれ、レプリケーションコントローラーがインスタンス化します。レプリケーションコントローラーは、必要に応じて調節するために、セレクターを使用して、すでに実行中の Pod 数を判断します。
レプリケーションコントローラーは、追跡もしませんが、負荷またはトラフィックに基づいて自動スケーリングを実行することもありません。この場合は、レプリカ数を外部の自動スケーラーで調整する必要があります。
レプリケーションコントローラーを直接作成するのではなく、DeploymentConfig
を使用してレプリケーションコントローラーを作成します。
カスタムオーケストレーションが必要な場合や、更新が必要ない場合は、レプリケーションコントローラーの代わりにレプリカセットを使用します。
以下は、レプリケーションコントローラー定義の例です。
apiVersion: v1 kind: ReplicationController metadata: name: frontend-1 spec: replicas: 1 1 selector: 2 name: frontend template: 3 metadata: labels: 4 name: frontend 5 spec: containers: - image: openshift/hello-openshift name: helloworld ports: - containerPort: 8080 protocol: TCP restartPolicy: Always
6.2.2. デプロイメント
Kubernetes は、Deployment
と呼ばれるファーストクラスのネイティブ API オブジェクトタイプを Red Hat OpenShift Service on AWS に提供します。Deployment
オブジェクトは、Pod テンプレートとして、アプリケーションの特定のコンポーネントで希望する状態を記述します。デプロイメントは、Pod のライフサイクルをオーケストレーションするレプリカセットを作成します。
たとえば、以下のデプロイメント定義はレプリカセットを作成し、1 つの hello-openshift
Pod を起動します。
デプロイメントの定義
apiVersion: apps/v1 kind: Deployment metadata: name: hello-openshift spec: replicas: 1 selector: matchLabels: app: hello-openshift template: metadata: labels: app: hello-openshift spec: containers: - name: hello-openshift image: openshift/hello-openshift:latest ports: - containerPort: 80
6.2.3. DeploymentConfig オブジェクト
Red Hat OpenShift Service on AWS 4.14 では、DeploymentConfig
オブジェクトは非推奨になりました。DeploymentConfig
オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。
代わりに、Deployment
オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。
レプリケーションコントローラーでビルドする Red Hat OpenShift Service on AWS は、DeploymentConfig
オブジェクトの概念を使用したソフトウェアの開発およびデプロイメントライフサイクルの拡張サポートを追加します。最も単純な場合に、DeploymentConfig
オブジェクトは新規レプリケーションコントローラーを作成し、それに Pod を起動させます。
ただし、DeploymentConfig
オブジェクトの Red Hat OpenShift Service on AWS デプロイメントは、イメージの既存デプロイメントから新規デプロイメントに移行する機能を提供し、レプリケーションコントローラーの作成前後におけるフックの実行も定義します。
DeploymentConfig
デプロイメントシステムは以下の機能を提供します。
-
アプリケーションを実行するためのテンプレートである
DeploymentConfig
オブジェクト。 - イベントへの対応として自動化されたデプロイメントを駆動するトリガー。
- 直前のバージョンから新規バージョンに移行するためのユーザーによるカスタマイズが可能なデプロイメントストラテジー。ストラテジーは、デプロイメントプロセスと一般的に呼ばれる Pod 内で実行されます。
- デプロイメントのライフサイクル中の異なる時点でカスタム動作を実行するためのフックのセット (ライフサイクルフック)。
- デプロイメントの失敗時に手動または自動でロールバックをサポートするためのアプリケーションのバージョン管理。
- レプリケーションの手動および自動スケーリング。
DeploymentConfig
オブジェクトを作成すると、レプリケーションコントローラーが、DeploymentConfig
オブジェクトの Pod テンプレートとして作成されます。デプロイメントが変更されると、最新の Pod テンプレートで新しいレプリケーションコントローラーが作成され、デプロイメントプロセスが実行されて以前のレプリケーションコントローラーのスケールダウン、および新規レプリケーションコントーラーのスケールアップが行われます。
アプリケーションのインスタンスは、作成時にサービスローダーバランサーやルーターに対して自動的に追加/削除されます。アプリケーションが正常なシャットダウン機能をサポートしている限り、アプリケーションが TERM
シグナルを受け取ると、実行中のユーザー接続は確実に通常通りに完了することができます。
Red Hat OpenShift Service on AWS DeploymentConfig
オブジェクトは、以下の詳細を定義します。
-
ReplicationController
定義の要素。 - 新規デプロイメントの自動作成のトリガー。
- デプロイメント間の移行ストラテジー。
- ライフサイクルフック。
デプロイヤー Pod は、デプロイメントがトリガーされるたびに、手動または自動であるかを問わず、(古いレプリケーションコントローラーの縮小、新規レプリケーションコントローラーの拡大およびフックの実行などの) デプロイメントを管理します。デプロイメント Pod は、デプロイメントのログを維持するためにデプロイメントの完了後は無期限で保持されます。デプロイメントが別のものに置き換えられる場合、以前のレプリケーションコントローラーは必要に応じて簡単なロールバックを有効にできるように保持されます。
DeploymentConfig
定義の例
apiVersion: apps.openshift.io/v1 kind: DeploymentConfig metadata: name: frontend spec: replicas: 5 selector: name: frontend template: { ... } triggers: - type: ConfigChange 1 - imageChangeParams: automatic: true containerNames: - helloworld from: kind: ImageStreamTag name: hello-openshift:latest type: ImageChange 2 strategy: type: Rolling 3
6.2.4. Deployment および DeploymentConfig オブジェクトの比較
Kubernetes Deployment
オブジェクトおよび Red Hat OpenShift Service on AWS に提供される DeploymentConfig
オブジェクトの両方が Red Hat OpenShift Service on AWS でサポートされていますが、DeploymentConfig
オブジェクトで提供される特定の機能または動作が必要でない場合は、Deployment
オブジェクトを使用することが推奨されます。
以下のセクションでは、使用するタイプの決定に役立つ 2 つのオブジェクト間の違いを詳述します。
Red Hat OpenShift Service on AWS 4.14 では、DeploymentConfig
オブジェクトは非推奨になりました。DeploymentConfig
オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。
代わりに、Deployment
オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。
6.2.4.1. 設計
Deployment
と DeploymentConfig
オブジェクトの重要な違いの 1 つとして、ロールアウトプロセスで各設計で選択される CAP theorem (原則) のプロパティーがあります。DeploymentConfig
オブジェクトは整合性を優先しますが、Deployments
オブジェクトは整合性よりも可用性を優先します。
DeploymentConfig
オブジェクトの場合、デプロヤー Pod を実行するノードがダウンする場合、ノードの置き換えは行われません。プロセスは、ノードが再びオンラインになるまで待機するか、手動で削除されます。ノードを手動で削除すると、対応する Pod も削除されます。つまり、kubelet は関連付けられた Pod も削除するため、Pod を削除してロールアウトの固定解除を行うことはできません。
一方、Deployment ロールアウトはコントローラーマネージャーから実行されます。コントローラーマネージャーはマスター上で高可用性モードで実行され、リーダー選択アルゴリズムを使用して可用性を整合性よりも優先するように設定します。障害の発生時には、他の複数のマスターが同時に同じデプロイメントに対して作用する可能性がありますが、この問題は障害の発生直後に調整されます。
6.2.4.2. デプロイメント固有の機能
ロールオーバー
Deployment
オブジェクトのデプロイメントプロセスは、すべての新規ロールアウトにデプロイヤー Pod を使用する DeploymentConfig
オブジェクトとは対照的に、コントローラーループで実行されます。つまり、Deployment
オブジェクトにはできるだけ多くのアクティブなレプリカセットを指定することができ、最終的にデプロイメントコントローラーが以前のすべてのレプリカセットをスケールダウンし、最新のものをスケールアップします。
DeploymentConfig
オブジェクトでは、実行できるデプロイヤー Pod は最大 1 つとなっています。複数のデプロイヤーがある場合は競合が生じ、それぞれが最新のレプリケーションコントローラーであると考えるコントローラーをスケールアップしようとします。これにより、2 つのレプリケーションコントローラーのみを一度にアクティブにできます。最終的には、Deployment
オブジェクトのロールアウトが速くなります。
比例スケーリング
デプロイメントコントローラーのみが Deployment
オブジェクトが所有する新旧のレプリカセットのサイズに関する信頼できる情報源であるため、継続中のロールアウトのスケーリングが可能です。追加のレプリカはレプリカセットのサイズに比例して分散されます。
DeploymentConfig
オブジェクトは、コントローラーが新規レプリケーションコントローラーのサイズに関してデプロイヤープロセスと競合するためにロールアウトが続行されている場合にスケーリングできません。
ロールアウト中の一時停止
Deployment はいつでも一時停止できます。つまり、継続中のロールアウトも一時停止できます。ただし、現時点ではデプロイヤー Pod を一時停止できません。ロールアウトの途中でデプロイメントを一時停止しようとすると、デプロイヤープロセスは影響を受けず、完了するまで続行されます。
6.2.4.3. DeploymentConfig オブジェクト固有の機能
自動ロールバック
現時点で、デプロイメントでは、問題の発生時の最後に正常にデプロイされたレプリカセットへの自動ロールバックをサポートしていません。
トリガー
Deployment の場合、デプロイメントの Pod テンプレートに変更があるたびに新しいロールアウトが自動的にトリガーされるので、暗黙的な設定変更トリガーが含まれます。Pod テンプレートの変更時に新たなロールアウトが不要な場合には、デプロイメントを以下のように停止します。
$ oc rollout pause deployments/<name>
ライフサイクルフック
Deployment ではライフサイクルフックをサポートしていません。
カスタムストラテジー
デプロイメントでは、ユーザーが指定するカスタムデプロイメントストラテジーをサポートしていません。