kubernetesリソースオブジェクト--deployment
本文はkubernetes 1.5.2バージョンに基づいて作成する
コンセプト
Deployment(中国語では配置、スケジューリングを意味する)は、RCとPodをより簡単に更新するメカニズムを提供し、K 8 Sバージョン1.2で実現された.Deploymentで所望のクラスタ状態を記述することによって、Deployment Controllerは現在のクラスタ状態を制御可能な速度で所望のクラスタ状態に徐々に更新する.Deploymentの主な役割はpodの数と健康を保証するためであり、90%の機能はRCと全く同じであり、次世代のRCと見なすことができる.
機能
Deploymentはオンライン配置、スクロールアップグレード、コピー作成、オンラインタスクの一時停止、オンラインタスクの回復、以前のバージョン(成功/安定)にロールバックするDeploymentなどの機能を統合し、ある程度、Deploymentは無人のオンラインを実現し、オンラインプロセスの複雑なコミュニケーション、操作リスクを大幅に低減することができる.
RC全機能:DeploymentはRC全機能を継承している.
イベントとステータスの表示:Deploymentのアップグレードの詳細とステータスを表示できます.
ロールバック:podミラーまたは関連パラメータをアップグレードしたときに問題が発生した場合、ロールバック操作を使用して前の安定したバージョンまたは指定したバージョンにロールバックできます.
バージョンレコード:Deploymentの操作のたびに保存され、後続のロールバック使用が可能になります.
≪一時停止と起動|Pause and Start|emdw≫:アップグレードのたびに、いつでも一時停止および起動できます.
複数のアップグレードスキーム:Recreate--既存のpodをすべて削除し、新しいものを再作成します.RollingUpdate-スクロールアップグレード、段階的に置換されたポリシーをスクロールアップグレードすると、最大使用不可pod数の設定、最小アップグレード間隔の設定など、より多くの追加パラメータがサポートされます.
シーンの操作
Deploymentを使用してPodまたはRSを起動(オンライン/導入)
Deploymentが正常に実行されたかどうかを確認します
Deploymentを更新して対応するPodsを再作成します(たとえば、新しいImageを使用する必要があります)
既存のDeploymentが不安定な場合は、初期の安定したDeploymentバージョンにロールバックします.
Deploymentを一時停止または再開
RCと比較してdeploymentのメリット
DeploymentはRSを使用しており、より高い概念です.
RCは等式ベースのselector(env=devまたはenvironment!=qa)のみをサポートするが、RSは新しい、集合ベースのselector(version in(v 1.0,v 2.0)またはenv notin(dev,qa))もサポートし、複雑なメンテナンス管理に便利である.
Deploymentを使用してPodをアップグレードするには、Podの最終状態を定義するだけで、K 8 Sは必要な操作を実行します.コマンドkubectl rolling-updateを使用してアップグレードを完了することができますが、クライアントとサービス側でRCを複数回インタラクティブに制御して完了するので、REST APIにはrolling-updateのインタフェースがありません.これは自分の管理システムをカスタマイズするのにいくつかの面倒をもたらします.
Deploymentは、より柔軟で強力なアップグレード、ロールバック機能を備えています.
共通コマンド
作成
サブコマンドcreateを使用してDeploymentを作成
注記--recordパラメータ.このパラメータを使用すると、後でオブジェクトを作成する操作が記録され、管理と問題の遡及が容易になります.
配置ステータスの表示
アップグレード
またはサブコマンドeditを使用してspec.replicas/spec.templateを編集します.spec.container.imageフィールド、deploymentの拡張容量とスクロールアップグレードを完了します(これはサブコマンドrolling-updateよりも高速です).
暫定アップグレード
アップグレードを続行
ロールバック
deploymentsバージョンの表示
指定したバージョンにロールバック
アップグレード履歴
例
パラメータの説明
strategyのtype
アップグレードポリシーにはrecreateとrollingUpdateがあります.recreate--既存のpodをすべて削除し、新しいものを再作成します.rollingUpdate-スクロールアップグレード、逐次置換のポリシー、同時にスクロールアップグレードの場合、最大使用不可pod数の設定、最小アップグレード間隔の設定など、より多くの追加パラメータをサポートします.
どのようなポリシーを使用するかは、適用シーンを見る必要があります.recreateポリシーは、アップグレード中にサービスを停止しますが、アプリケーションのバージョンが一致することを保証します.rollingUpdateを使用すると、サービスは中断されませんが、呼び出し時にアプリケーションのバージョンが一致せず、出力内容が一致しません.
maxSurgeとmaxUnavailable
maxSurge:1スクロールアップグレード時にpodが1つ先に起動することを示します
maxUnavailable:1は、スクロールアップグレード時に許可される最大Unavailableのpod個数を表します.replicasが3であるため、アップグレード全体でpod個数が2-4個の間でterminationGracePeriodSeconds
k 8 sはアプリケーションにSIGTERM信号を送信し、アプリケーションを正確かつ優雅に閉じるために使用でき、デフォルトは30秒である.
より優雅に閉じる必要がある場合は、k 8 sが提供するpre-stop lifecycle hookの構成宣言を使用して、SIGTERMを送信する前に実行します.
livenessProbeとreadinesProbe
livenessProbeはK 8 Sがpodが生存していると考えており、存在しない場合はkillを落とし、RSで指定された個数に達するために新たに起動する必要がある.
readinessProbeはK 8 Sでこのpodが起動に成功したと考えられていますが、ここでは各アプリケーションの特性に基づいて、自分で判断し、commandを実行したり、httpGetを行ったりすることができます.たとえばjavaウェブサービスを使用するアプリケーションでは、tomcatの起動に成功すれば対外的にサービスを提供できるわけではありません.springコンテナの初期化、データベース接続などを待つ必要があります.スプリングbootアプリケーションの場合、デフォルトのactuatorには/healthインタフェースがあり、起動成功の判断に使用できます.
ここでreadinessProbe.initialDelaySecondsは、システムが完全に起動するのに要する最小限の時間を設定することができる、livenessProbe.initialDelaySecondsは、システムが完全に起動するのに要する最大時間+数秒に設定できます.
コンセプト
Deployment(中国語では配置、スケジューリングを意味する)は、RCとPodをより簡単に更新するメカニズムを提供し、K 8 Sバージョン1.2で実現された.Deploymentで所望のクラスタ状態を記述することによって、Deployment Controllerは現在のクラスタ状態を制御可能な速度で所望のクラスタ状態に徐々に更新する.Deploymentの主な役割はpodの数と健康を保証するためであり、90%の機能はRCと全く同じであり、次世代のRCと見なすことができる.
機能
Deploymentはオンライン配置、スクロールアップグレード、コピー作成、オンラインタスクの一時停止、オンラインタスクの回復、以前のバージョン(成功/安定)にロールバックするDeploymentなどの機能を統合し、ある程度、Deploymentは無人のオンラインを実現し、オンラインプロセスの複雑なコミュニケーション、操作リスクを大幅に低減することができる.
RC全機能:DeploymentはRC全機能を継承している.
イベントとステータスの表示:Deploymentのアップグレードの詳細とステータスを表示できます.
ロールバック:podミラーまたは関連パラメータをアップグレードしたときに問題が発生した場合、ロールバック操作を使用して前の安定したバージョンまたは指定したバージョンにロールバックできます.
バージョンレコード:Deploymentの操作のたびに保存され、後続のロールバック使用が可能になります.
≪一時停止と起動|Pause and Start|emdw≫:アップグレードのたびに、いつでも一時停止および起動できます.
複数のアップグレードスキーム:Recreate--既存のpodをすべて削除し、新しいものを再作成します.RollingUpdate-スクロールアップグレード、段階的に置換されたポリシーをスクロールアップグレードすると、最大使用不可pod数の設定、最小アップグレード間隔の設定など、より多くの追加パラメータがサポートされます.
シーンの操作
Deploymentを使用してPodまたはRSを起動(オンライン/導入)
Deploymentが正常に実行されたかどうかを確認します
Deploymentを更新して対応するPodsを再作成します(たとえば、新しいImageを使用する必要があります)
既存のDeploymentが不安定な場合は、初期の安定したDeploymentバージョンにロールバックします.
Deploymentを一時停止または再開
RCと比較してdeploymentのメリット
DeploymentはRSを使用しており、より高い概念です.
RCは等式ベースのselector(env=devまたはenvironment!=qa)のみをサポートするが、RSは新しい、集合ベースのselector(version in(v 1.0,v 2.0)またはenv notin(dev,qa))もサポートし、複雑なメンテナンス管理に便利である.
Deploymentを使用してPodをアップグレードするには、Podの最終状態を定義するだけで、K 8 Sは必要な操作を実行します.コマンドkubectl rolling-updateを使用してアップグレードを完了することができますが、クライアントとサービス側でRCを複数回インタラクティブに制御して完了するので、REST APIにはrolling-updateのインタフェースがありません.これは自分の管理システムをカスタマイズするのにいくつかの面倒をもたらします.
Deploymentは、より柔軟で強力なアップグレード、ロールバック機能を備えています.
共通コマンド
作成
サブコマンドcreateを使用してDeploymentを作成
kubectl create -f test-dpm.yaml --record
注記--recordパラメータ.このパラメータを使用すると、後でオブジェクトを作成する操作が記録され、管理と問題の遡及が容易になります.
配置ステータスの表示
kubectl rolloutstatus deployment/lykops-dpm
kubectl describe deployment/lykops-dpm
アップグレード
kubectl set image deployment/lykops-dpm lykops-dpm=app:v1
またはサブコマンドeditを使用してspec.replicas/spec.templateを編集します.spec.container.imageフィールド、deploymentの拡張容量とスクロールアップグレードを完了します(これはサブコマンドrolling-updateよりも高速です).
暫定アップグレード
kubectl rolloutpause deployment/lykops-dpm
アップグレードを続行
kubectl rolloutresume deployment/lykops-dpm
ロールバック
kubectl rolloutundo deployment/lykops-dpm
deploymentsバージョンの表示
kubectl rollouthistory deployments
指定したバージョンにロールバック
kubectl rolloutundo deployment/lykops-dpm --to-revision=2
アップグレード履歴
kubectl describedeployment/lykops-dpm
Name: lykops-dpm
Namespace: default
CreationTimestamp: Tue, 01 Aug 2017 16:56:45 +0800
Labels: app=lykops-dpm
project=lykops
software=apache
version=v1
Selector: app=lykops-dpm,name=lykops-dpm,project=lykops,software=apache,version=v1
Replicas: 3updated | 3 total | 3 available | 0 unavailable
StrategyType: Recreate
MinReadySeconds: 30
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
OldReplicaSets:
NewReplicaSet: lykops-dpm-4183418831 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-2823415590 to 3
28m 28m 1 {deployment-controller } Normal ScalingReplicaSet Scaleddown replica set lykops-dpm-2823415590 to 0
28m 28m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-4001949646 to 3
26m 26m 1 {deployment-controller } Normal ScalingReplicaSet Scaleddown replica set lykops-dpm-4001949646 to 0
26m 26m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-4183418831 to 3
例
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: lykops-dpm
labels:
software: apache
project: lykops
app: lykops-dpm
version: v1
spec:
replicas: 3 #
minReadySeconds: 30 # ， 30s
strategy:
type: recreate #
#rollingUpdate:## replicas 3, ,pod 2-4
# maxSurge: 3 # 3 pod
# maxUnavailable: 1 # Unavailable pod
selector:
matchLabels:
name: lykops-dpm
software: apache
project: lykops
app: lykops-dpm
version: v1
template:
metadata:
labels:
name: lykops-dpm
software: apache
project: lykops
app: lykops-dpm
version: v1
spec:
terminationGracePeriodSeconds: 60 ##k8s SIGTERM ， 、 , 30
containers:
- name: lykops-dpm
image: web:apache
command: [ "sh", "/etc/run.sh" ]
ports:
- containerPort: 80
name: http
protocol: TCP
resources:
requests:
cpu: 0.05
memory: 16Mi
limits:
cpu: 0.1
memory: 32Mi
livenessProbe:#livenessProbe K8S pod ， kill ， ， RS 。
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:#readinessProbe K8S pod ， ， ， command， httpGet。
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
パラメータの説明
strategyのtype
アップグレードポリシーにはrecreateとrollingUpdateがあります.recreate--既存のpodをすべて削除し、新しいものを再作成します.rollingUpdate-スクロールアップグレード、逐次置換のポリシー、同時にスクロールアップグレードの場合、最大使用不可pod数の設定、最小アップグレード間隔の設定など、より多くの追加パラメータをサポートします.
どのようなポリシーを使用するかは、適用シーンを見る必要があります.recreateポリシーは、アップグレード中にサービスを停止しますが、アプリケーションのバージョンが一致することを保証します.rollingUpdateを使用すると、サービスは中断されませんが、呼び出し時にアプリケーションのバージョンが一致せず、出力内容が一致しません.
maxSurgeとmaxUnavailable
maxSurge:1スクロールアップグレード時にpodが1つ先に起動することを示します
maxUnavailable:1は、スクロールアップグレード時に許可される最大Unavailableのpod個数を表します.replicasが3であるため、アップグレード全体でpod個数が2-4個の間でterminationGracePeriodSeconds
k 8 sはアプリケーションにSIGTERM信号を送信し、アプリケーションを正確かつ優雅に閉じるために使用でき、デフォルトは30秒である.
より優雅に閉じる必要がある場合は、k 8 sが提供するpre-stop lifecycle hookの構成宣言を使用して、SIGTERMを送信する前に実行します.
livenessProbeとreadinesProbe
livenessProbeはK 8 Sがpodが生存していると考えており、存在しない場合はkillを落とし、RSで指定された個数に達するために新たに起動する必要がある.
readinessProbeはK 8 Sでこのpodが起動に成功したと考えられていますが、ここでは各アプリケーションの特性に基づいて、自分で判断し、commandを実行したり、httpGetを行ったりすることができます.たとえばjavaウェブサービスを使用するアプリケーションでは、tomcatの起動に成功すれば対外的にサービスを提供できるわけではありません.springコンテナの初期化、データベース接続などを待つ必要があります.スプリングbootアプリケーションの場合、デフォルトのactuatorには/healthインタフェースがあり、起動成功の判断に使用できます.
ここでreadinessProbe.initialDelaySecondsは、システムが完全に起動するのに要する最小限の時間を設定することができる、livenessProbe.initialDelaySecondsは、システムが完全に起動するのに要する最大時間+数秒に設定できます.