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
1
一連のリソースに対するラベルのクエリー。matchLabelsmatchExpressions の結果は論理的に結合されます。
2
セレクターに一致するラベルでリソースを指定する等価ベースのセレクター
3
キーをフィルターするセットベースのセレクター。これは、tier と同等のキー、frontend と同等の値のリソースをすべて選択します。

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
1
実行する Pod のコピー数です。
2
実行する Pod のラベルセレクターです。
3
コントローラーが作成する Pod のテンプレートです。
4
Pod のラベルにはラベルセレクターからのものが含まれている必要があります。
5
パラメーター拡張後の名前の最大長さは 63 文字です。

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 オブジェクトは、以下の詳細を定義します。

  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 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

1
設定変更トリガーにより、デプロイメント設定の Pod テンプレートに変更があると検出されるたびに、新規のレプリケーションコントローラーが作成されます。
2
イメージ変更トリガーにより、新規デプロイメントが、バッキングイメージの新規バージョンが名前付きイメージストリームで利用可能になる際には常に作成されます。
3
デフォルトの Rolling ストラテジーにより、デプロイメント間のダウンタイムなしの移行が行われます。

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. 設計

DeploymentDeploymentConfig オブジェクトの重要な違いの 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 ではライフサイクルフックをサポートしていません。

カスタムストラテジー

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

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

会社概要

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

© 2024 Red Hat, Inc.