はじめに
背景
Red Hatが提供するKubernetesディストリビューションであるOpenShiftでは、KubernetesにはないOpenShift特有のリソースがあります。Kubernetesと比較したOpenShiftの特徴という記事でも紹介しました。
これまでのあらすじ
この記事はKubernetesしか触ったことがなかった私が、OpenShift特有のリソースについて紹介するシリーズ(？)の続きです。
- Project
- DeploymentConfig ← いまここ
- BuildConfig
- Route
- ImageStream
- ImageStreamTag
今回は、DeploymentConfigを紹介します。さらに、KubernetesにおけるDeploymentとの違いを軽くまとめていきます。
OpenShift DeploymentConfigとは
何もわからないので、ドキュメントの記載を覗いてみましょう。
DeploymentConfig は新規の ReplicationController を作成し、これに Pod を起動させます。
これを読んだKubernetesを知っている人なら、「KubernetesのDeployment、ReplicaSet、Podの関係と同じやんけ」と思う人が多いのではないでしょうか。かくいう私もそう思います。
ドキュメントでは、DeploymentConfigには、主に以下を定義すると書いてあります。
- ReplicationController 定義の要素。
- 新規デプロイメントの自動作成のトリガー。
- デプロイメント間の移行ストラテジー。
- ライフサイクルフック。
2. 新規デプロイメントの自動作成のトリガーについては、Deploymentを使っていると目にしません。DeploymentConfigでは、デプロイメントを新規で作成する際のトリガー(デプロイメントトリガー)を定義することができます。コマンドはoc set triggersらしい。
どのようなデプロイメントトリガーが設定できるかは、こちらのドキュメントに書いています。まとめると、次のようになります。
- ConfigChange: DeploymentConfig の Pod テンプレートで設定の変更を検知。デフォルト。
- ImageChange: イメージストリームタグ1の更新を検知。
Kubernetes Deploymentとの違いは？
トリガーが設定できるのがDeploymentConfigの特長らしいですね。でもこのトリガーとやらを使う予定がない場合は、Kubernetesで見慣れているDeploymentを使えばいいのでしょうか。そもそもなぜDeploymentConfig、Deploymentという似たものが同居しているのでしょうか。
その答えを探りに、我々はStackOverflowへ向かいました。What is the different between openshift deploymentconfig and kubernetes deploymentというドンピシャなタイトルの質問をしている人を見つけました。質問内容も今の段階にぴったりです。
After far as I know:
deploymentconfig → replicationcontroller → pod
vs.deployment → replicaset → pod
Otherwise, do these two resources have additional differences?The more detail the better.
この質問に対して、元Red Hatの方が以下のように回答されています。
A DeploymentConfig (DC) in OpenShift is more or less equivalent to a Kubernetes Deployment, nowadays. Main difference (besides that one is using ReplicationController and the other using ReplicaSet as you rightly pointed out) is that
there are a few things you can do with a DeploymentConfig (around triggers) that you can’t do with a Deployment.
DeploymentConfig’s are first-class citizens in the Web console.
The reason DeploymentConfig’s exist is because we (Red Hat) are innovating. In other words: DeploymentConfig’s predate Deployment’s and while we’re always trying to propose these innovations upstream, they are not always accepted by the community as is. For example, in the case of RBAC, the stuff we had in OpenShift was accepted upstream and that’s why you have the same RBAC resources etc. now in OpenShift and Kubernetes. With DeploymentConfig’s that was not the case. Over time one would expect that DeploymentConfig’s are phased out in favor of Deployment’s but I can’t give you a timeline. If portability is your primary concern, I’d say, use Deployment’s.
知りたかったところは後半部分、”The reason DeploymentConfig’s exist is…”以下に書いていそうです。書いてあることを雑に訳してみます。
- DeploymentConfigの方がDeploymentよりも先行して開発されている
- Deployment + trigger e.t.c
- UpstreamのKubernetesに取り込むよう提案したが、実現しなかった
- 例えばRBACなどは、Red Hatが開発した機能がUpstreamに受け入れられたため、OpenShiftにもKubernetesにも同じリソースが存在する。
- DeploymentConfigはこのようにはならなかったので、OpenShiftにだけある
- 今後
DeploymentConfigは、Deploymentに取って代わられていくだろうが、時期はわからない - 移植性が最重要ならば、
Deploymentを使うのをすすめる
実は冒頭で紹介したドキュメントにはDeployment および DeploymentConfig の比較という説があり、そこにも似たようなことが書いてありますね。
Kubernetes Deployment および OpenShift Container Platform でプロビジョニングされる DeploymentConfig の両方が OpenShift Container Platform でサポートされていますが、DeploymentConfig で提供される特定の機能または動作が必要でない場合、Deployment を使用することが推奨されます。
公式ドキュメントにすら、DeploymentConfig で提供される特定の機能または動作が必要でない場合、Deployment を使用することが推奨と書いてあります。DeploymentConfigの特長(主にトリガー周り)を十分確認して、この機能が不要な場合には、Deploymentを使うのが良さそうです。
デモ
手軽に試したい方は、CRCの利用がおすすめです。利用方法は以下を参照ください。
またコンテナイメージは、以前用意したmkdocsのものを使います。Docker Hubにあげています。
Project作成
なにはともあれ、まずはプロジェクトを作成します。
|
1 |
$ oc new-project mkdocs-demo |
DeploymentConfigの作成
今回使うyamlファイルはこちらです。単純にmkdocsのコンテナを、レプリカ数２でデプロイするものです。spec.triggersには一応ConfigChangeと書いておきます。
apply後、DeploymentConfigが作成されます。TRIGGERED BYのところがconfigになっていますね。そのうちReplicationContorollerもできて、Podも上がってきます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$ oc apply -f mkdocs-dc.yaml deploymentconfig.apps.openshift.io/mkdocs created $ oc get all NAME READY STATUS RESTARTS AGE pod/mkdocs-1-7456z 1/1 Running 0 12s pod/mkdocs-1-b7956 1/1 Running 0 12s pod/mkdocs-1-deploy 0/1 Completed 0 15s NAME DESIRED CURRENT READY AGE replicationcontroller/mkdocs-1 2 2 2 15s NAME REVISION DESIRED CURRENT TRIGGERED BY deploymentconfig.apps.openshift.io/mkdocs 1 2 2 config |
DeploymentConfigの変更
念の為、ConfigChangeトリガーが有効になっているか確かめておきましょう。oc edit dc mkdocsとして、spec.templateの項目を適当に変更してみましょう。私はラベルを追加しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$ oc edit dc mkdocs deploymentconfig.apps.openshift.io/mkdocs edited $ oc get all NAME READY STATUS RESTARTS AGE pod/mkdocs-1-7456z 1/1 Terminating 0 70s pod/mkdocs-1-b7956 1/1 Terminating 0 70s pod/mkdocs-1-deploy 0/1 Completed 0 73s pod/mkdocs-2-deploy 0/1 Completed 0 26s pod/mkdocs-2-sd7wr 1/1 Running 0 22s pod/mkdocs-2-v8pb4 1/1 Running 0 18s NAME DESIRED CURRENT READY AGE replicationcontroller/mkdocs-1 0 0 0 73s replicationcontroller/mkdocs-2 2 2 2 26s NAME REVISION DESIRED CURRENT TRIGGERED BY deploymentconfig.apps.openshift.io/mkdocs 2 2 2 config |
DeploymentConfigのREVISIONが2になりました。それに伴い、ReplicationController、Podも新たに作成されているのがわかります。
さいごに
今回の話をまとめると、以下の通りです。
DeploymentConfigは、ReplicationController、Podを管理するリソース- デプロイメントトリガーなど
DeploymentConfigにしかない機能もあるが、ほとんどDeploymentと同じ - 移植性を重視するなら
Deploymentが推奨
このシリーズ
以上.
コメント