whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

resolve conflict

Browse Source
This commit is contained in:
inductor
2020-06-15 02:59:15 +09:00
parent c9472ad4b6 ce768c84b7
commit 298382169c
2451 changed files with 127381 additions and 564546 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+5 -5
View File
@@ -1,10 +1,10 @@
---
title: CronJob
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
@@ -24,9 +24,9 @@ CronJobリソースのためのマニフェストを作成する場合、その
cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## CronJobの制限
@@ -50,4 +50,4 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/daemonset.md
+5 -5
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: DaemonSet
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
_DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピーを稼働させることを保証します。Nodeがクラスターに追加されるとき、PodがNode上に追加されます。Nodeがクラスターから削除されたとき、それらのPodはガーベージコレクターにより除去されます。DaemonSetの削除により、DaemonSetが作成したPodもクリーンアップします。
@@ -18,10 +18,10 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。
さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## DaemonSet Specの記述
@@ -168,4 +168,4 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ
フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/deployment.md
+5 -5
View File
@@ -5,11 +5,11 @@ feature:
description: >
Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
_Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
@@ -19,10 +19,10 @@ _Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/
Deploymentによって作成されたReplicaSetを管理しないでください。ユーザーのユースケースが下記の項目をカバーできていない場合はメインのKubernetesリポジトリーにイシューを作成することを検討してください。
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ユースケース
@@ -1015,4 +1015,4 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに
[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があるためです。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/garbage-collection.md
+8 -7
View File
@@ -1,16 +1,16 @@
---
title: ガベージコレクション
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## オーナーとその従属オブジェクト {#owners-and-dependents}
@@ -134,16 +134,17 @@ Kubernetes1.7以前では、Deploymentに対するカスケード削除におい
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/replicaset.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
reviewers:
title: ReplicaSet
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## ReplicaSetがどのように動くか
@@ -313,4 +313,4 @@ ReplicaSetは[_ReplicationControllers_](/docs/concepts/workloads/controllers/rep
この2つは、ReplicationControllerが[ラベルについてのユーザーガイド](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)に書かれているように、集合ベース(set-based)のセレクター要求をサポートしていないことを除いては、同じ目的を果たし、同じようにふるまいます。
このように、ReplicaSetはReplicationControllerよりも好まれます。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/statefulset.md
+15 -14
View File
@@ -1,18 +1,18 @@
---
reviewers:
title: StatefulSet
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。
{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## StatefulSetの使用
@@ -102,7 +102,7 @@ StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with
ユーザーは、StatefulSetの`.spec.template.metadata.labels`のラベルと一致させるため、StatefulSetの`.spec.selector`フィールドをセットしなくてはなりません。Kubernetes1.8以前では、`.spec.selector`フィールドは省略された場合デフォルト値になります。Kubernetes1.8とそれ以降のバージョンでは、ラベルに一致するPodセレクターの指定がない場合はStatefulSetの作成時にバリデーションエラーになります。
## Podアイデンティティー
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
StatefulSetのPodは、順番を示す番号、安定したネットワークアイデンティティー、安定したストレージからなる一意なアイデンティティーを持ちます。
そのアイデンティティーはどのNode上にスケジュール(もしくは再スケジュール)されるかに関わらず、そのPodに紐付きます。
### 順序インデックス
@@ -113,8 +113,8 @@ N個のレプリカをもったStatefulSetにおいて、StatefulSet内の各Pod
StatefulSet内の各Podは、そのStatefulSet名とPodの順序番号から派生してホストネームが割り当てられます。
作成されたホストネームの形式は`$(StatefulSet名)-$(順序番号)`となります。先ほどの上記の例では、`web-0,web-1,web-2`という3つのPodが作成されます。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を使うことができます。
このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
StatefulSetは、Podのドメインをコントロールするために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を使うことができます。
このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。
各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。
[制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。
@@ -133,7 +133,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
### 安定したストレージ
Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1Gibのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。
Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1Gibのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。
注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。
削除する場合は手動で行わなければなりません。
@@ -161,8 +161,9 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM
`OrderedReady`なPod管理はStatefulSetにおいてデフォルトです。これは[デプロイとスケーリングの保証](#deployment-and-scaling-guarantees)に記載されている項目の振る舞いを実装します。
#### 並行なPod管理Parallel Pod Management
`並行`なPod管理は、StatefulSetコントローラーに対して、他のPodが起動や停止される前にそのPodが完全に起動し準備完了になるか停止するのを待つことなく、Podが並行に起動もしくは停止するように指示します。
#### 並行なPod管理
`Parallel`なPod管理は、StatefulSetコントローラーに対して、他のPodが起動や停止される前にそのPodが完全に起動し準備完了になるか停止するのを待つことなく、Podが並行に起動もしくは停止するように指示します。
## アップデートストラテジー
@@ -178,7 +179,7 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
#### パーティション
`RollingUpdate`というアップデートストラテジーは、`.spec.updateStrategy.rollingUpdate.partition`を指定することにより、パーティションに分けることができます。もしパーティションが指定されていたとき、そのパーティションの値と等しいか、大きい番号を持つPodが更新されます。パーティションの値より小さい番号を持つPodは更新されず、たとえそれらのPodが削除されたとしても、それらのPodは以前のバージョンで再作成されます。もしStatefulSetの`.spec.updateStrategy.rollingUpdate.partition`が、`.spec.replicas`より大きい場合、`.spec.template`への更新はPodに反映されません。
`RollingUpdate`というアップデートストラテジーは、`.spec.updateStrategy.rollingUpdate.partition`を指定することにより、パーティションに分けることができます。もしパーティションが指定されていたとき、そのパーティションの値と等しいか、大きい番号を持つPodが更新されます。パーティションの値より小さい番号を持つPodは更新されず、たとえそれらのPodが削除されたとしても、それらのPodは以前のバージョンで再作成されます。もしStatefulSetの`.spec.updateStrategy.rollingUpdate.partition`が、`.spec.replicas`より大きい場合、`.spec.template`への更新はPodに反映されません。
多くのケースの場合、ユーザーはパーティションを使う必要はありませんが、もし一部の更新を行う場合や、カナリー版のバージョンをロールアウトする場合や、段階的ロールアウトを行う場合に最適です。
#### 強制ロールバック
@@ -191,11 +192,11 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
そのテンプレートを戻したあと、ユーザーはまたStatefulSetが異常状態で稼働しようとしていたPodをすべて削除する必要があります。StatefulSetはその戻されたテンプレートを使ってPodの再作成を始めます。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
* [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
{{% /capture %}}
content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+8 -7
View File
@@ -1,11 +1,11 @@
---
reviewers:
title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources)
content_template: templates/concept
content_type: concept
weight: 65
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
@@ -14,12 +14,12 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs
α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## TTLコントローラー
@@ -45,12 +45,13 @@ TTLコントローラーが、TTL値が期限切れかそうでないかを決
Kubernetesにおいてタイムスキューを避けるために、全てのNode上でNTPの稼働を必須とします([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)を参照してください)。クロックは常に正しいものではありませんが、Node間におけるその差はとても小さいものとなります。TTLに0でない値をセットするときにこのリスクに対して注意してください。
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}