第8章 デプロイメント
8.1. Deployment および DeploymentConfig オブジェクトについて
OpenShift Container Platform の Deployment および DeploymentConfig API オブジェクトは、一般的なユーザーアプリケーションに対する詳細な管理を行うためのよく似ているものの、異なる 2 つの方法を提供します。これらは、以下の個別の API オブジェクトで設定されています。
-
アプリケーションの特定のコンポーネントの必要な状態を Pod テンプレートとして記述する
DeploymentまたはDeploymentConfigオブジェクト。 -
デプロイメントオブジェクトには、1 つ以上の レプリカセット が使用され、これには Pod テンプレートとしてのデプロイメントの特定の時点の状態のレコードが含まれます。同様に、DeploymentConfigオブジェクトには、レプリカセットの前に 1 つ以上の レプリケーションコントローラー が必要です。 - 1 つまたは複数の Pod。 特定バージョンのアプリケーションのインスタンスを表します。
DeploymentConfig オブジェクトによって提供される特定の機能または動作が必要でない場合、Deployment オブジェクトを使用します。
8.1.1. デプロイメントのビルディングブロック
デプロイメントおよびデプロイメント設定は、それぞれビルディングブロックとして、ネイティブ Kubernetes API オブジェクトの ReplicaSet および ReplicationController の使用によって有効にされます。
ユーザーは、Deployment または DeploymentConfig オブジェクトが所有するレプリカセット、レプリケーションコントローラー、または Pod を操作する必要はありません。デプロイメントシステムは変更を適切に伝播します。
既存のデプロイメントストラテジーが特定のユースケースに適さない場合で、デプロイメントのライフサイクル期間中に複数の手順を手動で実行する必要がある場合は、カスタムデプロイメントストラテジーを作成することを検討してください。
以下のセクションでは、これらのオブジェクトの詳細情報を提供します。
8.1.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: Always8.1.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
8.1.2. デプロイメント
Kubernetes は、Deployment という OpenShift Container Platform のファーストクラスのネイティブ API オブジェクトを提供します。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
8.1.3. DeploymentConfig オブジェクト
レプリケーションコントローラーでビルドする OpenShift Container Platform は DeploymentConfig オブジェクトの概念を使用したソフトウェアの開発およびデプロイメントライフサイクルの拡張サポートを追加します。最も単純な場合に、DeploymentConfig オブジェクトは新規アプリケーションコントローラーのみを作成し、それに Pod を起動させます。
ただし、DeploymentConfig オブジェクトの OpenShift Container Platform デプロイメントは、イメージの既存デプロイメントから新規デプロイメントに移行する機能を提供し、レプリケーションコントローラーの作成前後に実行されるフックも定義します。
DeploymentConfig デプロイメントシステムは以下の機能を提供します。
-
アプリケーションを実行するためのテンプレートである
DeploymentConfigオブジェクト。 - イベントへの対応として自動化されたデプロイメントを駆動するトリガー。
- 直前のバージョンから新規バージョンに移行するためのユーザーによるカスタマイズが可能なデプロイメントストラテジー。ストラテジーは、デプロイメントプロセスと一般的に呼ばれる Pod 内で実行されます。
- デプロイメントのライフサイクル中の異なる時点でカスタム動作を実行するためのフックのセット (ライフサイクルフック)。
- デプロイメントの失敗時に手動または自動でロールバックをサポートするためのアプリケーションのバージョン管理。
- レプリケーションの手動および自動スケーリング。
DeploymentConfig オブジェクトを作成すると、レプリケーションコントローラーが、DeploymentConfig オブジェクトの Pod テンプレートとして作成されます。デプロイメントが変更されると、最新の Pod テンプレートで新しいレプリケーションコントローラーが作成され、デプロイメントプロセスが実行されて以前のレプリケーションコントローラーのスケールダウン、および新規レプリケーションコントーラーのスケールアップが行われます。
アプリケーションのインスタンスは、作成時にサービ出力ダーバランサーやルーターに対して自動的に追加/削除されます。アプリケーションが正常なシャットダウン機能をサポートしている限り、アプリケーションが TERM シグナルを受け取ると、実行中のユーザー接続が通常通り完了できるようにすることができます。
OpenShift Container Platform 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
8.1.4. Deployment および DeploymentConfig オブジェクトの比較
Kubernetes Deployment および OpenShift Container Platform でプロビジョニングされる DeploymentConfig オブジェクトの両方が OpenShift Container Platform でサポートされていますが、DeploymentConfig オブジェクトで提供される特定の機能または動作が必要でない場合、Deployment を使用することが推奨されます。
以下のセクションでは、使用するタイプの決定に役立つ 2 つのオブジェクト間の違いを詳述します。
8.1.4.1. 設計
Deployment と DeploymentConfig オブジェクトの重要な違いの 1 つとして、ロールアウトプロセスで各設計で選択される CAP theorem (原則) のプロパティーがあります。DeploymentConfig オブジェクトは整合性を優先しますが、Deployments オブジェクトは整合性よりも可用性を優先します。
DeploymentConfig オブジェクトの場合、デプロヤー Pod を実行するノードがダウンする場合、ノードの置き換えは行われません。プロセスは、ノードが再びオンラインになるまで待機するか、手動で削除されます。ノードを手動で削除すると、対応する Pod も削除されます。つまり、kubelet は関連付けられた Pod も削除するため、Pod を削除してロールアウトの固定解除を行うことはできません。
一方、Deployment ロールアウトはコントローラーマネージャーから実行されます。コントローラーマネージャーはマスター上で高可用性モードで実行され、リーダー選択アルゴリズムを使用して可用性を整合性よりも優先するように設定します。障害の発生時には、他の複数のマスターが同時に同じデプロイメントに対して作用する可能性がありますが、この問題は障害の発生直後に調整されます。
8.1.4.2. デプロイメント固有の機能
ロールオーバー
Deployment オブジェクトのデプロイメントプロセスは、すべての新規ロールアウトにデプロイヤー Pod を使用する DeploymentConfig オブジェクトとは対照的に、コントローラーループによって実行されます。つまり、Deployment オブジェクトにはできるだけ多くのアクティブなレプリカセットを指定することができ、最終的にデプロイメントコントローラーが以前のすべてのレプリカセットをスケールダウンし、最新のものをスケールアップします。
DeploymentConfig オブジェクトでは、実行できるデプロイヤー Pod は最大 1 つとなっています。複数のデプロイヤーが最新のレプリケーションコントローラーであると考えると、複数のデプロイヤーが競合する可能性があります。これにより、2 つのレプリケーションコントローラーのみを一度にアクティブにできます。最終的には、これにより Deployment オブジェクトのロールアウトが速くなります。
比例スケーリング
デプロイメントコントローラーのみが Deployment オブジェクトが所有する新旧レプリカセットのサイズについての信頼できる情報源であるため、継続中のロールアウトをスケーリングできます。追加のレプリカはレプリカセットのサイズに比例して分散されます。
DeploymentConfig オブジェクトは、コントローラーが新規レプリケーションコントローラーのサイズに関してデプロイヤープロセスに問題があるためにロールアウトが続行されている場合にスケーリングできません。
ロールアウト中の一時停止
Deployment はいつでも一時停止できます。つまり、継続中のロールアウトも一時停止できます。ただし、現時点ではデプロイヤー Pod を一時停止することはできません。ロールアウトの途中でデプロイメントを一時停止しようとすると、デプロイヤープロセスは影響を受けず、完了するまで続行されます。
8.1.4.3. DeploymentConfig オブジェクト固有の機能
自動ロールバック
現時点で、デプロイメントでは、問題の発生時の最後に正常にデプロイされたレプリカセットへの自動ロールバックをサポートしていません。
トリガー
Deployment の場合、デプロイメントの Pod テンプレートに変更があるたびに新しいロールアウトが自動的にトリガーされるので、暗黙的な設定変更トリガーが含まれます。Pod テンプレートの変更時に新たなロールアウトが不要な場合には、デプロイメントを以下のように停止します。
$ oc rollout pause deployments/<name>
ライフサイクルフック
Deployment ではライフサイクルフックをサポートしていません。
カスタムストラテジー
Deployment はユーザー指定のカスタムデプロイメントストラテジーをサポートしません。