Skip to content

Commit ff960d0

Browse files
takaf04takaf04
committed
updated deployment.md in ja
1 parent 5b36550 commit ff960d0

File tree

1 file changed

+36
-34
lines changed

1 file changed

+36
-34
lines changed

‎content/ja/docs/concepts/workloads/controllers/deployment.md

Lines changed: 36 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -31,8 +31,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
3131
* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
3232
* DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
3333
* Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
34-
* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
34+
* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する。
3535
* PodTemplateSpecに対する複数の修正を適用するために[Deploymentを停止(Pause)し](#pausing-and-resuming-a-deployment)、それを再開して新しいロールアウトを開始します。
36+
* [Deploymentのステータス](#deployment-status) をロールアウトが失敗したサインとして利用する。
3637
* 今後必要としない[古いReplicaSetのクリーンアップ](#clean-up-policy)
3738

3839
## Deploymentの作成 {#creating-a-deployment}
@@ -82,7 +83,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
8283
```
8384
クラスターにてDeploymentを調査するとき、以下のフィールドが出力されます。
8485
* `NAME`は、クラスター内にあるDeploymentの名前一覧です。
85-
* `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
86+
* `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。使用可能な数/理想的な数の形式で表示されます。
8687
* `UP-TO-DATE`は、理想的な状態を満たすためにアップデートが完了したレプリカの数です。
8788
* `AVAILABLE`は、ユーザーが利用可能なレプリカの数です。
8889
* `AGE`は、アプリケーションが稼働してからの時間です。
@@ -133,7 +134,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
133134
{{< note >}}
134135
Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。
135136

136-
ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
137+
ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを阻止しないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
137138
{{< /note >}}
138139

139140
### pod-template-hashラベル
@@ -146,7 +147,7 @@ Deploymentに対して適切なセレクターとPodテンプレートのラベ
146147

147148
このラベルはDeploymentが管理するReplicaSetが重複しないことを保証します。このラベルはReplicaSetの`PodTemplate`をハッシュ化することにより生成され、生成されたハッシュ値はラベル値としてReplicaSetセレクター、Podテンプレートラベル、ReplicaSetが作成した全てのPodに対して追加されます。
148149

149-
## Deploymentの更新
150+
## Deploymentの更新 {#updating-a-deployment}
150151

151152
{{< note >}}
152153
Deploymentのロールアウトは、DeploymentのPodテンプレート(この場合`.spec.template`)が変更された場合にのみトリガーされます。例えばテンプレートのラベルもしくはコンテナーイメージが更新された場合です。Deploymentのスケールのような更新では、ロールアウトはトリガーされません。
@@ -589,13 +590,11 @@ Deploymentのローリングアップデートは、同時に複数のバージ
589590
```
590591

591592
* クラスター内で、解決できない新しいイメージに更新します。
592-
* You update to a new image which happens to be unresolvable from inside the cluster.
593593
```shell
594594
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
595595
```
596596

597597
実行結果は以下のとおりです。
598-
The output is similar to this:
599598
```
600599
deployment.apps/nginx-deployment image updated
601600
```
@@ -604,7 +603,8 @@ Deploymentのローリングアップデートは、同時に複数のバージ
604603
```shell
605604
kubectl get rs
606605
```
607-
実行結果は以下のとおりです。
606+
607+
実行結果は以下のとおりです。
608608
```
609609
NAME DESIRED CURRENT READY AGE
610610
nginx-deployment-1989198191 5 5 0 9s
@@ -615,24 +615,26 @@ Deploymentのローリングアップデートは、同時に複数のバージ
615615

616616
上記の例では、3つのレプリカが古いReplicaSetに追加され、2つのレプリカが新しいReplicaSetに追加されました。ロールアウトの処理では、新しいレプリカ数のPodが正常になったと仮定すると、最終的に新しいReplicaSetに全てのレプリカを移動させます。これを確認するためには以下のコマンドを実行して下さい。
617617

618-
```shell
619-
kubectl get deploy
620-
```
621-
実行結果は以下のとおりです。
622-
```
623-
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
624-
nginx-deployment 15 18 7 8 7m
625-
```
626-
　ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
627-
```shell
628-
kubectl get rs
629-
```
630-
実行結果は以下のとおりです。
631-
```
632-
NAME DESIRED CURRENT READY AGE
633-
nginx-deployment-1989198191 7 7 0 7m
634-
nginx-deployment-618515232 11 11 11 7m
635-
```
618+
```shell
619+
kubectl get deploy
620+
```
621+
622+
実行結果は以下のとおりです。
623+
```
624+
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
625+
nginx-deployment 15 18 7 8 7m
626+
```
627+
ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
628+
```shell
629+
kubectl get rs
630+
```
631+
632+
実行結果は以下のとおりです。
633+
```
634+
NAME DESIRED CURRENT READY AGE
635+
nginx-deployment-1989198191 7 7 0 7m
636+
nginx-deployment-618515232 11 11 11 7m
637+
```
636638

637639
## Deployment更新の一時停止と再開 {#pausing-and-resuming-a-deployment}
638640

@@ -752,7 +754,7 @@ Deploymentのローリングアップデートは、同時に複数のバージ
752754
nginx-3926361531 3 3 3 28s
753755
```
754756
{{< note >}}
755-
一時停止したDeploymentの稼働を再開させない限り、Deploymentをロールバックすることはできません。
757+
Deploymentの稼働を再開させない限り、一時停止したDeploymentをロールバックすることはできません。
756758
{{< /note >}}
757759

758760
## Deploymentのステータス {#deployment-status}
@@ -937,13 +939,13 @@ Deploymentが管理する古いReplicaSetをいくつ保持するかを指定す
937939

938940
## カナリアパターンによるデプロイ
939941

940-
Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
942+
Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#canary-deployments-カナリアデプロイ)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
941943

942944
## Deployment Specの記述
943945

944946
他の全てのKubernetesの設定と同様に、Deploymentは`.apiVersion`、`.kind`や`.metadata`フィールドを必要とします。
945-
設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
946-
Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
947+
設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/ja/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
948+
Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
947949
Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。
948950

949951
### Podテンプレート
@@ -992,25 +994,25 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
992994

993995
`.spec.strategy.type==RollingUpdate`と指定されているとき、DeploymentはローリングアップデートによりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
994996

995-
##### maxUnavailable
997+
##### Max Unavailable {##max-unavailable}
996998

997999
`.spec.strategy.rollingUpdate.maxUnavailable`はオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り捨てされて計算されます。`.spec.strategy.rollingUpdate.maxSurge`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
9981000

9991001
例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると古いReplicaSetはすぐに理想状態の70%にスケールダウンされます。一度新しいPodが稼働できる状態になると、古いReplicaSetはさらにスケールダウンされ、続いて新しいReplicaSetがスケールアップされます。この間、利用可能なPodの総数は理想状態のPodの少なくとも70%以上になるように保証されます。
10001002

1001-
##### maxSurge
1003+
##### Max Surge {#max-surge}
10021004

10031005
`.spec.strategy.rollingUpdate.maxSurge`はオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り上げで計算されます。`MaxUnavailable`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
10041006

10051007
例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると新しいReplicaSetはすぐに更新されます。このとき古いPodと新しいPodの総数は理想状態の130%を超えないように更新されます。一度古いPodが削除されると、新しいReplicaSetはさらにスケールアップされます。この間、利用可能なPodの総数は理想状態のPodに対して最大130%になるように保証されます。
10061008

1007-
### progressDeadlineSeconds
1009+
### Progress Deadline Seconds
10081010

10091011
`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。デフォルト値は600です。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
10101012

10111013
この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。
10121014

1013-
### minReadySeconds {#min-ready-seconds}
1015+
### Min Ready Seconds {#min-ready-seconds}
10141016

10151017
`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
10161018

@@ -1020,7 +1022,7 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに
10201022

10211023
`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。
10221024

1023-
さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。
1025+
さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを元に戻すことができません。
10241026

10251027
### paused
10261028

0 commit comments

Comments
 (0)