第7章 デプロイメント


7.1. デプロイメントの理解

OpenShift Container Platform の Deployment および DeploymentConfig オブジェクトを使用して、アプリケーションの必要な状態を記述し、レプリカセットまたはレプリケーションコントローラーで Pod を管理できます。DeploymentConfig オブジェクトのみが提供する機能が必要でない限り、Deployment オブジェクトを使用します。

Deployment および DeploymentConfig API オブジェクトは、一般的なユーザーアプリケーションに対する詳細な管理を行うための類似の異なる 2 つの方法を提供します。これらは、以下の個別の API オブジェクトで構成されています。

  • アプリケーションの特定のコンポーネントの必要な状態を記述する、Pod テンプレートとしての Deployment または DeploymentConfig。
  • Deployment オブジェクトには、1 つ以上の レプリカセット が使用され、これには Pod テンプレートとしてのデプロイメントの特定の時点の状態のレコードが含まれます。同様に、DeploymentConfig オブジェクトには、1 つ以上の レプリケーションコントローラー (以前はレプリカセットでした) が含まれます。
  • 1 つまたは複数の Pod。特定バージョンのアプリケーションのインスタンスを表します。
重要

OpenShift Container Platform 4.14 以降、DeploymentConfig オブジェクトは非推奨になりました。DeploymentConfig オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。

代わりに、Deployment オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。

7.1.1. デプロイメントのビルディングブロック

デプロイメントおよびデプロイメント設定は、それぞれビルディングブロックとして、ネイティブ Kubernetes API オブジェクトの ReplicaSet および ReplicationController の使用によって有効にされます。

ユーザーは、Deployment または DeploymentConfig オブジェクトによって所有されるレプリカセット、レプリケーションコントローラー、または Pod を操作する必要はありません。デプロイメントシステムは変更を適切に伝播します。

ヒント

既存のデプロイメントストラテジーが特定のユースケースに適さない場合で、デプロイメントのライフサイクル期間中に複数の手順を手動で実行する必要がある場合は、カスタムデプロイメントストラテジーを作成することを検討してください。

以下のセクションでは、これらのオブジェクトの詳細情報を提供します。

7.1.1.1. レプリカセット

指定の数の同一 Pod が OpenShift Container Platform で実行されている状態を維持するには、Kubernetes ReplicaSet オブジェクトを使用できます。デプロイメントはレプリカセットを作成および管理するため、カスタム更新オーケストレーションが必要なか、更新をまったくない場合にのみレプリカセットを使用します。

注記

カスタム更新のオーケストレーションが必要な場合や、更新が全く必要のない場合にのみレプリカセットを使用します。それ以外はデプロイメントを使用します。レプリカセットは個別に使用できますが、Pod 作成/削除/更新のオーケストレーションにはデプロイメントでレプリカセットを使用します。デプロイメントは、自動的にレプリカセットを管理し、Pod に宣言的更新を加えるので、作成するレプリカセットを手動で管理する必要はありません。

以下は、ReplicaSet 定義の例になります。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {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
  • spec.selector は、一連のリソースに対するラベルクエリーです。matchLabels と matchExpressions の結果は論理的に結合されます。
  • spec.selector.matchLabels は、セレクターに一致するラベルを持つリソースを指定する等価ベースのセレクターです。
  • spec.selector.matchExpressions は、キーをフィルターするセットベースのセレクターです。このパラメーターは、tier と同等のキー、frontend と同等の値のリソースをすべて選択します。

7.1.1.2. レプリケーションコントローラー

指定の数の同一 Pod を OpenShift Container Platform で実行し続けるには、レプリケーションコントローラーを使用できます。直接ではなく DeploymentConfig オブジェクトを介して作成し、設定ベースのセレクターやカスタム更新オーケストレーションが必要な場合はレプリカセットを使用します。

レプリカセットと同様に、レプリケーションコントローラーは、Pod の指定された数のレプリカが常に実行されるようにします。Pod が終了または削除された場合に、レプリケーションコントローラーは定義した数になるまでインスタンス化する数を増やします。同様に、必要以上の数の Pod が実行されている場合には、定義された数に一致させるために必要な数の Pod を削除します。レプリカセットとレプリケーションコントローラーの相違点は、レプリカセットではセットベースのセレクター要件をサポートし、レプリケーションコントローラーは等価ベースのセレクター要件のみをサポートする点です。

レプリケーションコントローラー設定は以下で構成されています。

  • 必要なレプリカ数 (これはランタイム時に調整可能)。
  • レプリケートされた Pod の作成時に使用する Pod 定義。
  • 管理された Pod を識別するためのセレクター。

セレクターは、レプリケーションコントローラーが管理する Pod に割り当てられるラベルセットです。これらのラベルは、Pod 定義に組み込まれ、レプリケーションコントローラーがインスタンス化します。レプリケーションコントローラーは、必要に応じて調節するために、セレクターを使用して、すでに実行中の Pod 数を判断します。

レプリケーションコントローラーは、追跡もしませんが、負荷またはトラフィックに基づいて自動スケーリングを実行することもありません。この場合は、レプリカ数を外部の自動スケーラーで調整する必要があります。

注記

レプリケーションコントローラーを直接作成するのではなく、DeploymentConfig を使用してレプリケーションコントローラーを作成します。

カスタムオーケストレーションが必要な場合や、更新が必要ない場合は、レプリケーションコントローラーの代わりにレプリカセットを使用します。

以下は、レプリケーションコントローラー定義の例です。

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1
  selector:
    name: frontend
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
  • spec.replicas は、実行する Pod のコピーの数を指定します。
  • spec.selector は、実行する Pod のラベルセレクターを指定します。
  • spec.template は、コントローラーが作成する Pod のテンプレートを指定します。
  • spec.template.metadata.labels は、Pod がラベルセレクターから含める必要のあるラベルを指定します。
  • spec.template.metadata.labels.name はラベルの名前を指定します。パラメーター拡張後の名前の最大長さは 63 文字です。

7.1.2. デプロイメント

OpenShift Container Platform でアプリケーション Pod を実行し、更新するには、Kubernetes 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

7.1.3. DeploymentConfig オブジェクト

重要

OpenShift Container Platform 4.14 以降、DeploymentConfig オブジェクトは非推奨になりました。DeploymentConfig オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。

代わりに、Deployment オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。

OpenShift Container Platform の DeploymentConfig オブジェクトを使用して、イメージ更新のロールアウト、ライフサイクルフックの実行、自動デプロイメントのトリガー、およびアプリケーションのスケーリングまたはロールバックを実行できます。DeploymentConfig オブジェクトはレプリケーションコントローラーに基づいてビルドされ、アプリケーションのデプロイメントライフサイクルを管理します。

レプリケーションコントローラーでビルドする OpenShift Container Platform は DeploymentConfig オブジェクトの概念を使用したソフトウェアの開発およびデプロイメントライフサイクルの拡張サポートを追加します。最も単純な場合に、DeploymentConfig オブジェクトは新規アプリケーションコントローラーのみを作成し、それに Pod を起動させます。

ただし、DeploymentConfig オブジェクトの OpenShift Container Platform デプロイメントは、イメージの既存デプロイメントから新規デプロイメントに移行する機能を提供し、レプリケーションコントローラーの作成前後に実行されるフックも定義します。

DeploymentConfig デプロイメントシステムは以下の機能を提供します。

  • アプリケーションを実行するためのテンプレートである DeploymentConfig オブジェクト。
  • イベントへの対応として自動化されたデプロイメントを駆動するトリガー。
  • 直前のバージョンから新規バージョンに移行するためのユーザーによるカスタマイズが可能なデプロイメントストラテジー。ストラテジーは、デプロイメントプロセスと一般的に呼ばれる Pod 内で実行されます。
  • デプロイメントのライフサイクル中の異なる時点でカスタム動作を実行するためのフックのセット (ライフサイクルフック)。
  • デプロイメントの失敗時に手動または自動でロールバックをサポートするためのアプリケーションのバージョン管理。
  • レプリケーションの手動および自動スケーリング。

DeploymentConfig オブジェクトを作成すると、レプリケーションコントローラーが、DeploymentConfig オブジェクトの Pod テンプレートとして作成されます。デプロイメントが変更されると、最新の Pod テンプレートで新しいレプリケーションコントローラーが作成され、デプロイメントプロセスが実行されて以前のレプリケーションコントローラーのスケールダウン、および新規レプリケーションコントーラーのスケールアップが行われます。

アプリケーションのインスタンスは、作成時にサービスローダーバランサーやルーターに対して自動的に追加/削除されます。アプリケーションが正常なシャットダウン機能をサポートしている限り、アプリケーションが TERM シグナルを受け取ると、実行中のユーザー接続が通常通り完了できるようにすることができます。

OpenShift Container Platform DeploymentConfig オブジェクトは以下の詳細を定義します。

  1. ReplicationController 定義の要素。
  2. 新規デプロイメントの自動作成のトリガー。
  3. デプロイメント間の移行ストラテジー。
  4. ライフサイクルフック。

デプロイヤー Pod は、デプロイメントがトリガーされるたびに、手動または自動であるかを問わず、(古いレプリケーションコントローラーの縮小、新規レプリケーションコントローラーの拡大およびフックの実行などの) デプロイメントを管理します。デプロイメント Pod は、デプロイメントのログを維持するためにデプロイメントの完了後は無期限で保持されます。デプロイメントが別のものに置き換えられる場合、以前のレプリケーションコントローラーは必要に応じて簡単なロールバックを有効にできるように保持されます。

DeploymentConfig 定義の例

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange
  strategy:
    type: Rolling

  • spec.triggers.type.ConfigChange は、デプロイメント設定の Pod テンプレートで変更が検出されるたびに新しいレプリケーションコントローラーを作成する設定変更トリガーです。
  • spec.triggers.type.ImageChange はイメージ変更トリガーで、バッキングイメージの新規バージョンが名前付きイメージストリームで利用可能になるたびに新規デプロイメントが作成されます。
  • spec.strategy.type.Rolling は、デプロイメント間のダウンタイムなしの移行を行うデフォルトのストラテジーです。

7.1.4. Deployment および DeploymentConfig オブジェクトの比較

Kubernetes Deployment オブジェクトと OpenShift Container Platform DeploymentConfig オブジェクトの両方を使用して、アプリケーションのロールアウトを管理できます。どのオブジェクトを使用するかを決定する前に、設計とサポートされる機能にある 2 つのオブジェクトの違いを理解してください。

DeploymentConfig オブジェクトのみが提供する機能が必要でない限り、Deployment オブジェクトを使用します。

以下のセクションでは、使用するタイプの決定に役立つ 2 つのオブジェクト間の違いを詳述します。

重要

OpenShift Container Platform 4.14 以降、DeploymentConfig オブジェクトは非推奨になりました。DeploymentConfig オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。

代わりに、Deployment オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。

7.1.4.1. 設計

Deployment と DeploymentConfig オブジェクトの重要な違いの 1 つとして、ロールアウトプロセスで各設計で選択される CAP theorem (原則) のプロパティーがあります。DeploymentConfig オブジェクトは整合性を優先しますが、Deployments オブジェクトは整合性よりも可用性を優先します。

DeploymentConfig オブジェクトの場合、デプロヤー Pod を実行するノードがダウンする場合、ノードの置き換えは行われません。プロセスは、ノードが再びオンラインになるまで待機するか、手動で削除されます。ノードを手動で削除すると、対応する Pod も削除されます。つまり、kubelet は関連付けられた Pod も削除するため、Pod を削除してロールアウトの固定解除を行うことはできません。

一方、デプロイメントのロールアウトはコントローラーマネージャーから実行されます。コントローラーマネージャーはマスター上で高可用性モードで実行され、リーダー選択アルゴリズムを使用して可用性を整合性よりも優先するように設定します。障害の発生時には、他の複数のマスターが同時に同じデプロイメントに対して作用する可能性がありますが、この問題は障害の発生直後に調整されます。

7.1.4.2. デプロイメント固有の機能

OpenShift Container Platform の Deployment オブジェクトを使用して、複数のロールアウトセットをロールアウトしたり、更新中に継続中のロールアウトしたり、スクロールアウトを一時停止したりできます。これらの機能は DeploymentConfig オブジェクトとは異なり、アプリケーションの更新をより速く、柔軟性を持たせることができます。

7.1.4.2.1. ロールオーバー

Deployment オブジェクトのデプロイメントプロセスは、すべての新規ロールアウトにデプロイヤー Pod を使用する DeploymentConfig オブジェクトとは対照的に、コントローラーループで実行されます。つまり、Deployment オブジェクトにはできるだけ多くのアクティブなレプリカセットを指定することができ、最終的にデプロイメントコントローラーが以前のすべてのレプリカセットをスケールダウンし、最新のものをスケールアップします。

DeploymentConfig オブジェクトでは、実行できるデプロイヤー Pod は最大 1 つとなっています。複数のデプロイヤーがある場合は競合が生じ、それぞれが最新のレプリケーションコントローラーであると考えるコントローラーをスケールアップしようとします。これにより、2 つのレプリケーションコントローラーのみを一度にアクティブにできます。最終的には、Deployment オブジェクトのロールアウトが速くなります。

7.1.4.2.2. 比例スケーリング

デプロイメントコントローラーのみが Deployment オブジェクトが所有する新旧のレプリカセットのサイズに関する信頼できる情報源であるため、継続中のロールアウトのスケーリングが可能です。追加のレプリカはレプリカセットのサイズに比例して分散されます。

DeploymentConfig オブジェクトは、コントローラーが新規レプリケーションコントローラーのサイズに関してデプロイヤープロセスと競合するためにロールアウトが続行されている場合にスケーリングできません。

7.1.4.2.3. ロールアウト中の一時停止

Deployment はいつでも一時停止できます。つまり、継続中のロールアウトも一時停止できます。ただし、現時点ではデプロイヤー Pod を一時停止できません。ロールアウトの途中でデプロイメントを一時停止しようとすると、デプロイヤープロセスは影響を受けず、完了するまで続行されます。

7.1.4.3. DeploymentConfig オブジェクト固有の機能

OpenShift Container Platform で DeploymentConfig オブジェクトを使用する場合、ライフサイクルフック を設定し、カスタムデプロイメントストラテジーを設定できます。DeploymentConfig オブジェクトは、失敗した場合にレプリカセットの自動ロールバックを提供し、更新の自動ロールアウトも提供します。

これらの機能は DeploymentConfig オブジェクトに固有の機能であり、Kubernetes Deployment オブジェクトでは使用できません。

7.1.4.3.1. 自動ロールバック

現時点で、デプロイメントでは、問題の発生時の最後に正常にデプロイされたレプリカセットへの自動ロールバックをサポートしていません。

7.1.4.3.2. トリガー

Deployment の場合、デプロイメントの Pod テンプレートに変更があるたびに新しいロールアウトが自動的にトリガーされるので、暗黙的な設定変更トリガーが含まれます。Pod テンプレートの変更時に新たなロールアウトが不要な場合には、デプロイメントを以下のように停止します。

$ oc rollout pause deployments/<name>
7.1.4.3.3. ライフサイクルフック

Deployment ではライフサイクルフックをサポートしていません。

7.1.4.3.4. カスタムストラテジー

デプロイメントでは、ユーザーが指定するカスタムデプロイメントストラテジーをサポートしていません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る