From 11b8c88d8e13fd51d7d5fa6287d4bbd52b2c7f6e Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Wed, 15 Jun 2022 04:48:23 +0000
Subject: [PATCH 001/110] Translate docs/concepts/workloads/controllers/job.md
 into Japanese(Line 1-266)

---
 .../concepts/workloads/controllers/job.md     | 665 ++++++++++++++++++
 1 file changed, 665 insertions(+)
 create mode 100644 content/ja/docs/concepts/workloads/controllers/job.md

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
new file mode 100644
index 0000000000000..8d730caba6527
--- /dev/null
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -0,0 +1,665 @@
+---
+reviewers:
+title: Jobs
+content_type: concept
+feature:
+  title: バッチ実行
+  description: >
+    サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを引き換えることもできます。
+weight: 50
+---
+
+<!-- overview -->
+
+Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、タスク（つまりJob）の完成となります。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
+
+単純なケースを言うと、一つのPodが正常に完成するまで実行することを確保するため、一つのJobオブジェクトを作成します。
+一つ目のPodに障害が発生したり、削除されたり（例えばノードのハードウェア障害またノードの再起動が起こした場合）すると、Jobオブジェクトは新しいPodを作成してくれます。
+
+Jobで複数のPodを並行して実行することもできます。
+
+スケジュールに沿ってJob（単一のタスクか複数タスク並行のいずれか）を実行したい場合は [CronJob](https://kubernetes.io/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
+
+<!-- body -->
+
+## 実行例  {#running-an-example-job}
+
+下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完成するまで約10秒かかります。
+
+{{< codenew file="controllers/job.yaml" >}}
+
+このコマンドで実行できます：
+
+```shell
+kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
+```
+
+実行結果はこのようになります：
+
+```
+job.batch/pi created
+```
+
+`kubectl`でJobの状態を確認できます：
+
+```shell
+kubectl describe jobs/pi
+```
+
+実行結果はこのようになります：
+
+```
+Name:           pi
+Namespace:      default
+Selector:       controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
+Labels:         controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
+                job-name=pi
+Annotations:    kubectl.kubernetes.io/last-applied-configuration:
+                  {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
+Parallelism:    1
+Completions:    1
+Start Time:     Mon, 02 Dec 2019 15:20:11 +0200
+Completed At:   Mon, 02 Dec 2019 15:21:16 +0200
+Duration:       65s
+Pods Statuses:  0 Running / 1 Succeeded / 0 Failed
+Pod Template:
+  Labels:  controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
+           job-name=pi
+  Containers:
+   pi:
+    Image:      perl
+    Port:       <none>
+    Host Port:  <none>
+    Command:
+      perl
+      -Mbignum=bpi
+      -wle
+      print bpi(2000)
+    Environment:  <none>
+    Mounts:       <none>
+  Volumes:        <none>
+Events:
+  Type    Reason            Age   From            Message
+  ----    ------            ----  ----            -------
+  Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7
+```
+
+Jobの完成したPodを確認するには、`kubectl get pods`を使います。
+
+Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います：
+
+```shell
+pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
+echo $pods
+```
+
+出力結果はこのようになります：
+
+```
+pi-5rwd7
+```
+
+ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを選出するための表現です。
+
+その中の一つのPodの標準出力を確認するには：
+
+```shell
+kubectl logs $pods
+```
+
+出力結果はこのようになります：
+
+```
+3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
+```
+
+## spec（仕様）の書き方  {#writing-a-job-spec}
+
+他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
+Jobの名前は有効な[DNSサブドメイン名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
+
+Jobには[`.spec`フィールド](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
+
+### Podテンプレート  {#pod-template}
+
+`.spec.template`は`.spec`の唯一の必須フィールドです。
+
+`.spec.template`の値は[podテンプレート](https://kubernetes.io/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、定義仕様が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
+
+Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
+
+[`RestartPolicy`](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`にのみ設定可能です。
+
+### Podセレクター  {#pod-selector}
+
+`.spec.selector` フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
+[独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
+
+
+### Jobの並列実行  {#parallel-jobs}
+
+Jobで実行するのに適したタスクは主に3種類あります：
+
+1. 非並列Job
+   - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
+   - Podが正常に終了すると、Jobの完成となります。
+2. *一定の完成数*が決められた並列Job：
+   - `.spec.completions`に正の値を指定します。
+   - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完成となります。
+   - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
+3. *ワークキュー*を利用した並列Job：
+   - `.spec.completions`の設定はしない、デフォルトは`.spec.parallelism`となります。
+   - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
+   - 各Podは他のPodが完成したかどうか、つまりJobが完成したかどうかを単独で判断できます。
+   - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
+   - 一つ以上のPodが成功に終了し、すべてのPodが終了すると、Jobの成功終了となります。
+   - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
+
+ _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
+
+ _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完成数に設定する必要があります。
+`.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
+
+ _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
+
+各種類Jobの利用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
+
+#### 並列処理の制御
+
+必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
+未設定の場合は、デフォルトで1になります。
+0に設定した際に、増加するまでJobは一時停止されます。
+
+実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
+
+-  _完成数一定_ 並列Jobの場合、実際に並行して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
+-  _ワークキュー_ 並列Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
+- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合、または
+- Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
+  実際並列数は必要並列数より少なくなる可能性があります。
+- 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
+- Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
+
+### 完成モード
+
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
+
+ _完成数一定_ 並列Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完成モードを指定できます：
+
+- `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完成となります。言い換えれば、各Podの完成状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
+- `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
+  - Pod注釈`batch.kubernetes.io/job-completion-index`。
+  - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
+    インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
+  - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
+  
+  インデックスごとに、成功したPodが一つ存在すると、Jobの完成となります。完成モードの使用方法の詳細については、
+  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](https://kubernetes.io/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。
+  めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
+
+## Podとコンテナの障害対策
+
+Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
+`restartPolicy`の詳細については[Podのライフサイクル](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
+
+Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定したPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションが新しいPodの再起動処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
+
+`.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
+
+`.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
+
+### Pod失敗のバックオフポリシー
+
+設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
+
+{{< note >}}
+`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
+{{< /note >}}
+
+## Job termination and cleanup
+
+When a Job completes, no more Pods are created, but the Pods are [usually](#pod-backoff-failure-policy) not deleted either.
+Keeping them around
+allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
+The job object also remains after it is completed so that you can view its status.  It is up to the user to delete
+old jobs after noting their status.  Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
+
+By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the
+`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will be marked as failed and any running Pods will be terminated.
+
+Another way to terminate a Job is by setting an active deadline.
+Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds.
+The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
+Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`.
+
+Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.
+
+Example:
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: pi-with-timeout
+spec:
+  backoffLimit: 5
+  activeDeadlineSeconds: 100
+  template:
+    spec:
+      containers:
+      - name: pi
+        image: perl
+        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+      restartPolicy: Never
+```
+
+Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level.
+
+Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`.
+That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
+
+## Clean up finished jobs automatically
+
+Finished Jobs are usually no longer needed in the system. Keeping them around in
+the system will put pressure on the API server. If the Jobs are managed directly
+by a higher level controller, such as
+[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
+cleaned up by CronJobs based on the specified capacity-based cleanup policy.
+
+### TTL mechanism for finished Jobs
+
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+Another way to clean up finished Jobs (either `Complete` or `Failed`)
+automatically is to use a TTL mechanism provided by a
+[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
+finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of
+the Job.
+
+When the TTL controller cleans up the Job, it will delete the Job cascadingly,
+i.e. delete its dependent objects, such as Pods, together with the Job. Note
+that when the Job is deleted, its lifecycle guarantees, such as finalizers, will
+be honored.
+
+For example:
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: pi-with-ttl
+spec:
+  ttlSecondsAfterFinished: 100
+  template:
+    spec:
+      containers:
+      - name: pi
+        image: perl
+        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+      restartPolicy: Never
+```
+
+The Job `pi-with-ttl` will be eligible to be automatically deleted, `100`
+seconds after it finishes.
+
+If the field is set to `0`, the Job will be eligible to be automatically deleted
+immediately after it finishes. If the field is unset, this Job won't be cleaned
+up by the TTL controller after it finishes.
+
+{{< note >}}
+It is recommended to set `ttlSecondsAfterFinished` field because unmanaged jobs
+(Jobs that you created directly, and not indirectly through other workload APIs
+such as CronJob) have a default deletion
+policy of `orphanDependents` causing Pods created by an unmanaged Job to be left around
+after that Job is fully deleted.
+Even though the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} eventually
+[garbage collects](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
+the Pods from a deleted Job after they either fail or complete, sometimes those
+lingering pods may cause cluster performance degradation or in worst case cause the
+cluster to go offline due to this degradation.
+
+You can use [LimitRanges](/docs/concepts/policy/limit-range/) and
+[ResourceQuotas](/docs/concepts/policy/resource-quotas/) to place a
+cap on the amount of resources that a particular namespace can
+consume.
+{{< /note >}}
+
+
+## Jobパターン  {#job-patterns}
+
+The Job object can be used to support reliable parallel execution of Pods.  The Job object is not
+designed to support closely-communicating parallel processes, as commonly found in scientific
+computing.  It does support parallel processing of a set of independent but related *work items*.
+These might be emails to be sent, frames to be rendered, files to be transcoded, ranges of keys in a
+NoSQL database to scan, and so on.
+
+In a complex system, there may be multiple different sets of work items.  Here we are just
+considering one set of work items that the user wants to manage together &mdash; a *batch job*.
+
+There are several different patterns for parallel computation, each with strengths and weaknesses.
+The tradeoffs are:
+
+- One Job object for each work item, vs. a single Job object for all work items.  The latter is
+  better for large numbers of work items.  The former creates some overhead for the user and for the
+  system to manage large numbers of Job objects.
+- Number of pods created equals number of work items, vs. each Pod can process multiple work items.
+  The former typically requires less modification to existing code and containers.  The latter
+  is better for large numbers of work items, for similar reasons to the previous bullet.
+- Several approaches use a work queue.  This requires running a queue service,
+  and modifications to the existing program or container to make it use the work queue.
+  Other approaches are easier to adapt to an existing containerised application.
+
+
+The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs.
+The pattern names are also links to examples and more detailed description.
+
+|                  Pattern                  | Single Job object | Fewer pods than work items? | Use app unmodified? |
+| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
+| [Queue with Pod Per Work Item]            |         ✓         |                             |      sometimes      |
+| [Queue with Variable Pod Count]           |         ✓         |             ✓               |                     |
+| [Indexed Job with Static Work Assignment] |         ✓         |                             |          ✓          | 
+| [Job Template Expansion]                  |                   |                             |          ✓          |
+
+When you specify completions with `.spec.completions`, each Pod created by the Job controller
+has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).  This means that
+all pods for a task will have the same command line and the same
+image, the same volumes, and (almost) the same environment variables.  These patterns
+are different ways to arrange for pods to work on different things.
+
+This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns.
+Here, `W` is the number of work items.
+
+|             Pattern                       | `.spec.completions` |  `.spec.parallelism` |
+| ----------------------------------------- |:-------------------:|:--------------------:|
+| [Queue with Pod Per Work Item]            |          W          |        any           |
+| [Queue with Variable Pod Count]           |         null        |        any           |
+| [Indexed Job with Static Work Assignment] |          W          |        any           |
+| [Job Template Expansion]                  |          1          |     should be 1      |
+
+[Queue with Pod Per Work Item]: /docs/tasks/job/coarse-parallel-processing-work-queue/
+[Queue with Variable Pod Count]: /docs/tasks/job/fine-parallel-processing-work-queue/
+[Indexed Job with Static Work Assignment]: /docs/tasks/job/indexed-parallel-processing-static/
+[Job Template Expansion]: /docs/tasks/job/parallel-processing-expansion/
+
+## Advanced usage
+
+### Suspending a Job
+
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
+
+When a Job is created, the Job controller will immediately begin creating Pods
+to satisfy the Job's requirements and will continue to do so until the Job is
+complete. However, you may want to temporarily suspend a Job's execution and
+resume it later, or start Jobs in suspended state and have a custom controller
+decide later when to start them.
+
+To suspend a Job, you can update the `.spec.suspend` field of
+the Job to true; later, when you want to resume it again, update it to false.
+Creating a Job with `.spec.suspend` set to true will create it in the suspended
+state.
+
+When a Job is resumed from suspension, its `.status.startTime` field will be
+reset to the current time. This means that the `.spec.activeDeadlineSeconds`
+timer will be stopped and reset when a Job is suspended and resumed.
+
+Remember that suspending a Job will delete all active Pods. When the Job is
+suspended, your [Pods will be terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
+with a SIGTERM signal. The Pod's graceful termination period will be honored and
+your Pod must handle this signal in this period. This may involve saving
+progress for later or undoing changes. Pods terminated this way will not count
+towards the Job's `completions` count.
+
+An example Job definition in the suspended state can be like so:
+
+```shell
+kubectl get job myjob -o yaml
+```
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: myjob
+spec:
+  suspend: true
+  parallelism: 1
+  completions: 5
+  template:
+    spec:
+      ...
+```
+
+The Job's status can be used to determine if a Job is suspended or has been
+suspended in the past:
+
+```shell
+kubectl get jobs/myjob -o yaml
+```
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+# .metadata and .spec omitted
+status:
+  conditions:
+  - lastProbeTime: "2021-02-05T13:14:33Z"
+    lastTransitionTime: "2021-02-05T13:14:33Z"
+    status: "True"
+    type: Suspended
+  startTime: "2021-02-05T13:13:48Z"
+```
+
+The Job condition of type "Suspended" with status "True" means the Job is
+suspended; the `lastTransitionTime` field can be used to determine how long the
+Job has been suspended for. If the status of that condition is "False", then the
+Job was previously suspended and is now running. If such a condition does not
+exist in the Job's status, the Job has never been stopped.
+
+Events are also created when the Job is suspended and resumed:
+
+```shell
+kubectl describe jobs/myjob
+```
+
+```
+Name:           myjob
+...
+Events:
+  Type    Reason            Age   From            Message
+  ----    ------            ----  ----            -------
+  Normal  SuccessfulCreate  12m   job-controller  Created pod: myjob-hlrpl
+  Normal  SuccessfulDelete  11m   job-controller  Deleted pod: myjob-hlrpl
+  Normal  Suspended         11m   job-controller  Job suspended
+  Normal  SuccessfulCreate  3s    job-controller  Created pod: myjob-jvb44
+  Normal  Resumed           3s    job-controller  Job resumed
+```
+
+The last four events, particularly the "Suspended" and "Resumed" events, are
+directly a result of toggling the `.spec.suspend` field. In the time between
+these two events, we see that no Pods were created, but Pod creation restarted
+as soon as the Job was resumed.
+
+### Mutable Scheduling Directives
+
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
+
+{{< note >}}
+In order to use this behavior, you must enable the `JobMutableNodeSchedulingDirectives`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/).
+It is enabled by default.
+{{< /note >}}
+
+In most cases a parallel job will want the pods to run with constraints, 
+like all in the same zone, or all either on GPU model x or y but not a mix of both.
+
+The [suspend](#suspending-a-job) field is the first step towards achieving those semantics. Suspend allows a 
+custom queue controller to decide when a job should start; However, once a job is unsuspended,
+a custom queue controller has no influence on where the pods of a job will actually land.
+
+This feature allows updating a Job's scheduling directives before it starts, which gives custom queue
+controllers the ability to influence pod placement while at the same time offloading actual 
+pod-to-node assignment to kube-scheduler. This is allowed only for suspended Jobs that have never 
+been unsuspended before.
+
+The fields in a Job's pod template that can be updated are node affinity, node selector, 
+tolerations, labels and annotations.
+
+### Specifying your own Pod selector　｛#specifying-your-own-pod-selector｝
+
+Normally, when you create a Job object, you do not specify `.spec.selector`.
+The system defaulting logic adds this field when the Job is created.
+It picks a selector value that will not overlap with any other jobs.
+
+However, in some cases, you might need to override this automatically set selector.
+To do this, you can specify the `.spec.selector` of the Job.
+
+Be very careful when doing this.  If you specify a label selector which is not
+unique to the pods of that Job, and which matches unrelated Pods, then pods of the unrelated
+job may be deleted, or this Job may count other Pods as completing it, or one or both
+Jobs may refuse to create Pods or run to completion.  If a non-unique selector is
+chosen, then other controllers (e.g. ReplicationController) and their Pods may behave
+in unpredictable ways too.  Kubernetes will not stop you from making a mistake when
+specifying `.spec.selector`.
+
+Here is an example of a case when you might want to use this feature.
+
+Say Job `old` is already running.  You want existing Pods
+to keep running, but you want the rest of the Pods it creates
+to use a different pod template and for the Job to have a new name.
+You cannot update the Job because these fields are not updatable.
+Therefore, you delete Job `old` but _leave its pods
+running_, using `kubectl delete jobs/old --cascade=orphan`.
+Before deleting it, you make a note of what selector it uses:
+
+```shell
+kubectl get job old -o yaml
+```
+
+The output is similar to this:
+
+```yaml
+kind: Job
+metadata:
+  name: old
+  ...
+spec:
+  selector:
+    matchLabels:
+      controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
+  ...
+```
+
+Then you create a new Job with name `new` and you explicitly specify the same selector.
+Since the existing Pods have label `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`,
+they are controlled by Job `new` as well.
+
+You need to specify `manualSelector: true` in the new Job since you are not using
+the selector that the system normally generates for you automatically.
+
+```yaml
+kind: Job
+metadata:
+  name: new
+  ...
+spec:
+  manualSelector: true
+  selector:
+    matchLabels:
+      controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
+  ...
+```
+
+The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`.  Setting
+`manualSelector: true` tells the system that you know what you are doing and to allow this
+mismatch.
+
+### Job tracking with finalizers
+
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
+
+{{< note >}}
+In order to use this behavior, you must enable the `JobTrackingWithFinalizers`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/)
+and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
+It is enabled by default.
+
+When enabled, the control plane tracks new Jobs using the behavior described
+below. Jobs created before the feature was enabled are unaffected. As a user,
+the only difference you would see is that the control plane tracking of Job
+completion is more accurate.
+{{< /note >}}
+
+When this feature isn't enabled, the Job {{< glossary_tooltip term_id="controller" >}}
+relies on counting the Pods that exist in the cluster to track the Job status,
+that is, to keep the counters for `succeeded` and `failed` Pods.
+However, Pods can be removed for a number of reasons, including:
+- The garbage collector that removes orphan Pods when a Node goes down.
+- The garbage collector that removes finished Pods (in `Succeeded` or `Failed`
+  phase) after a threshold.
+- Human intervention to delete Pods belonging to a Job.
+- An external controller (not provided as part of Kubernetes) that removes or
+  replaces Pods.
+
+If you enable the `JobTrackingWithFinalizers` feature for your cluster, the
+control plane keeps track of the Pods that belong to any Job and notices if any
+such Pod is removed from the API server. To do that, the Job controller creates Pods with
+the finalizer `batch.kubernetes.io/job-tracking`. The controller removes the
+finalizer only after the Pod has been accounted for in the Job status, allowing
+the Pod to be removed by other controllers or users.
+
+The Job controller uses the new algorithm for new Jobs only. Jobs created
+before the feature is enabled are unaffected. You can determine if the Job
+controller is tracking a Job using Pod finalizers by checking if the Job has the
+annotation `batch.kubernetes.io/job-tracking`. You should **not** manually add
+or remove this annotation from Jobs.
+
+## Alternatives
+
+### Bare Pods
+
+When the node that a Pod is running on reboots or fails, the pod is terminated
+and will not be restarted.  However, a Job will create new Pods to replace terminated ones.
+For this reason, we recommend that you use a Job rather than a bare Pod, even if your application
+requires only a single Pod.
+
+### Replication Controller
+
+Jobs are complementary to [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/).
+A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job
+manages Pods that are expected to terminate (e.g. batch tasks).
+
+As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` is *only* appropriate
+for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
+(Note: If `RestartPolicy` is not set, the default value is `Always`.)
+
+### Single Job starts controller Pod
+
+Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
+of custom controller for those Pods.  This allows the most flexibility, but may be somewhat
+complicated to get started with and offers less integration with Kubernetes.
+
+One example of this pattern would be a Job which starts a Pod which runs a script that in turn
+starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), runs a spark
+driver, and then cleans up.
+
+An advantage of this approach is that the overall process gets the completion guarantee of a Job
+object, but maintains complete control over what Pods are created and how work is assigned to them.
+
+## {{% heading "whatsnext" %}}
+
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Read about different ways of running Jobs:
+   * [Coarse Parallel Processing Using a Work Queue](/docs/tasks/job/coarse-parallel-processing-work-queue/)
+   * [Fine Parallel Processing Using a Work Queue](/docs/tasks/job/fine-parallel-processing-work-queue/)
+   * Use an [indexed Job for parallel processing with static work assignment](/docs/tasks/job/indexed-parallel-processing-static/) (beta)
+   * Create multiple Jobs based on a template: [Parallel Processing using Expansions](/docs/tasks/job/parallel-processing-expansion/)
+* Follow the links within [Clean up finished jobs automatically](#clean-up-finished-jobs-automatically)
+  to learn more about how your cluster can clean up completed and / or failed tasks.
+* `Job` is part of the Kubernetes REST API.
+  Read the {{< api-reference page="workload-resources/job-v1" >}}
+  object definition to understand the API for jobs.
+* Read about [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/), which you
+  can use to define a series of Jobs that will run based on a schedule, similar to
+  the UNIX tool `cron`.

From 34c4dfde8f76efba079a9ed4a176efb28ec53023 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Wed, 15 Jun 2022 05:41:55 +0000
Subject: [PATCH 002/110] append the original English text

---
 .../concepts/workloads/controllers/job.md     | 257 +++++++++++++++++-
 1 file changed, 255 insertions(+), 2 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 8d730caba6527..d78534dd2ae15 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -8,45 +8,92 @@ feature:
     サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを引き換えることもできます。
 weight: 50
 ---
+<!--
+reviewers:
+- erictune
+- soltysh
+title: Jobs
+content_type: concept
+feature:
+  title: Batch execution
+  description: >
+    In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
+weight: 50
+-->
+
 
 <!-- overview -->
 
 Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、タスク（つまりJob）の完成となります。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
+<!--
+A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate.
+As pods successfully complete, the Job tracks the successful completions.  When a specified number of successful completions is reached, the task (ie, Job) is complete.  Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
+-->
 
 単純なケースを言うと、一つのPodが正常に完成するまで実行することを確保するため、一つのJobオブジェクトを作成します。
 一つ目のPodに障害が発生したり、削除されたり（例えばノードのハードウェア障害またノードの再起動が起こした場合）すると、Jobオブジェクトは新しいPodを作成してくれます。
+<!--
+A simple case is to create one Job object in order to reliably run one Pod to completion.
+The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot).
+-->
 
 Jobで複数のPodを並行して実行することもできます。
+<!--
+You can also use a Job to run multiple Pods in parallel.
+-->
 
 スケジュールに沿ってJob（単一のタスクか複数タスク並行のいずれか）を実行したい場合は [CronJob](https://kubernetes.io/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
+<!--
+If you want to run a Job (either a single task, or several in parallel) on a schedule,
+see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/).
+-->
 
 <!-- body -->
 
 ## 実行例  {#running-an-example-job}
+<!--
+Running an example Job
+-->
 
 下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完成するまで約10秒かかります。
+<!--
+Here is an example Job config.  It computes π to 2000 places and prints it out.
+It takes around 10s to complete.
+-->
 
 {{< codenew file="controllers/job.yaml" >}}
 
 このコマンドで実行できます：
+<!--
+You can run the example with this command:
+-->
 
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 ```
 
 実行結果はこのようになります：
+<!--
+The output is similar to this:
+-->
 
 ```
 job.batch/pi created
 ```
 
 `kubectl`でJobの状態を確認できます：
+<!--
+Check on the status of the Job with `kubectl`:
+-->
 
 ```shell
 kubectl describe jobs/pi
 ```
 
 実行結果はこのようになります：
+<!--
+The output is similar to this:
+-->
 
 ```
 Name:           pi
@@ -85,8 +132,14 @@ Events:
 ```
 
 Jobの完成したPodを確認するには、`kubectl get pods`を使います。
+<!--
+To view completed Pods of a Job, use `kubectl get pods`.
+-->
 
 Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います：
+<!--
+To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
+-->
 
 ```shell
 pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
@@ -94,127 +147,327 @@ echo $pods
 ```
 
 出力結果はこのようになります：
+<!--
+The output is similar to this:
+-->
 
 ```
 pi-5rwd7
 ```
 
 ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを選出するための表現です。
+<!--
+Here, the selector is the same as the selector for the Job.  The `--output=jsonpath` option specifies an expression with the name from each Pod in the returned list.
+-->
 
 その中の一つのPodの標準出力を確認するには：
+<!--
+View the standard output of one of the pods:
+-->
 
 ```shell
 kubectl logs $pods
 ```
 
 出力結果はこのようになります：
+<!--
+The output is similar to this:
+-->
 
 ```
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
 ```
 
 ## spec（仕様）の書き方  {#writing-a-job-spec}
+<!--
+Writing a Job spec
+-->
 
 他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
 Jobの名前は有効な[DNSサブドメイン名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
+<!--
+As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
+Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
 
 Jobには[`.spec`フィールド](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
+<!--
+A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
+-->
 
 ### Podテンプレート  {#pod-template}
+<!--
+Pod Template
+-->
 
 `.spec.template`は`.spec`の唯一の必須フィールドです。
+<!--
+The `.spec.template` is the only required field of the `.spec`.
+-->
 
 `.spec.template`の値は[podテンプレート](https://kubernetes.io/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、定義仕様が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
+<!--
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
+-->
 
 Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
+<!--
+In addition to required fields for a Pod, a pod template in a Job must specify appropriate
+labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
+-->
 
 [`RestartPolicy`](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`にのみ設定可能です。
+<!--
+Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
+-->
 
 ### Podセレクター  {#pod-selector}
+<!--
+Pod selector
+-->
 
 `.spec.selector` フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
 [独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
-
+<!--
+The `.spec.selector` field is optional.  In almost all cases you should not specify it.
+See section [specifying your own pod selector](#specifying-your-own-pod-selector).
+-->
 
 ### Jobの並列実行  {#parallel-jobs}
+<!--
+Parallel execution for Jobs 
+-->
 
 Jobで実行するのに適したタスクは主に3種類あります：
+<!--
+There are three main types of task suitable to run as a Job:
+-->
 
 1. 非並列Job
    - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
    - Podが正常に終了すると、Jobの完成となります。
+<!--
+1. Non-parallel Jobs
+   - normally, only one Pod is started, unless the Pod fails.
+   - the Job is complete as soon as its Pod terminates successfully.
+-->
 2. *一定の完成数*が決められた並列Job：
    - `.spec.completions`に正の値を指定します。
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完成となります。
    - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
+<!--
+2. Parallel Jobs with a *fixed completion count*:
+   - specify a non-zero positive value for `.spec.completions`.
+   - the Job represents the overall task, and is complete when there are `.spec.completions` successful Pods.
+   - when using `.spec.completionMode="Indexed"`, each Pod gets a different index in the range 0 to `.spec.completions-1`.
+-->
 3. *ワークキュー*を利用した並列Job：
    - `.spec.completions`の設定はしない、デフォルトは`.spec.parallelism`となります。
+<!--
+3. Parallel Jobs with a *work queue*:
+   - do not specify `.spec.completions`, default to `.spec.parallelism`.
+-->
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
+<!--
+   - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
+-->
    - 各Podは他のPodが完成したかどうか、つまりJobが完成したかどうかを単独で判断できます。
+<!--
+   - each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
+-->
    - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
+<!--
+   - when _any_ Pod from the Job terminates with success, no new Pods are created.
+-->
    - 一つ以上のPodが成功に終了し、すべてのPodが終了すると、Jobの成功終了となります。
+<!--
+   - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
+-->
    - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
+<!--
+   - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output.  They should all be in the process of exiting.
+-->
 
  _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
+<!--
+For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset.  When both are
+unset, both are defaulted to 1.
+-->
 
  _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完成数に設定する必要があります。
 `.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
+<!--
+For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed.
+You can set `.spec.parallelism`, or leave it unset and it will default to 1.
+-->
 
  _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
+<!--
+For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to a non-negative integer.
+-->
 
 各種類Jobの利用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
+<!--
+For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
+-->
 
 #### 並列処理の制御
+<!--
+Controlling parallelism
+-->
 
 必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
 未設定の場合は、デフォルトで1になります。
 0に設定した際に、増加するまでJobは一時停止されます。
+<!--
+The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
+If it is unspecified, it defaults to 1.
+If it is specified as 0, then the Job is effectively paused until it is increased.
+-->
 
 実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
+<!--
+Actual parallelism (number of pods running at any instant) may be more or less than requested parallelism, for a variety of reasons:
+-->
 
 -  _完成数一定_ 並列Jobの場合、実際に並行して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
+<!--
+- For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of remaining completions.   Higher values of `.spec.parallelism` are effectively ignored.
+-->
 -  _ワークキュー_ 並列Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
+<!--
+- For _work queue_ Jobs, no new Pods are started after any Pod has succeeded -- remaining Pods are allowed to complete, however.
+-->
 - Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合、または
+<!--
+- If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react.
+-->
 - Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
   実際並列数は必要並列数より少なくなる可能性があります。
+<!--
+- If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.),
+  then there may be fewer pods than requested.
+-->
 - 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
+<!--
+- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
+-->
 - Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
+<!--
+- When a Pod is gracefully shut down, it takes time to stop.
+-->
 
 ### 完成モード
+<!--
+Completion mode
+-->
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
  _完成数一定_ 並列Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完成モードを指定できます：
+<!--
+Jobs with _fixed completion count_ - that is, jobs that have non null
+`.spec.completions` - can have a completion mode that is specified in `.spec.completionMode`:
+-->
 
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完成となります。言い換えれば、各Podの完成状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
+<!--
+- `NonIndexed` (default): the Job is considered complete when there have been
+  `.spec.completions` successfully completed Pods. In other words, each Pod
+  completion is homologous to each other. Note that Jobs that have null
+  `.spec.completions` are implicitly `NonIndexed`.
+-->
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
+<!--
+- `Indexed`: the Pods of a Job get an associated completion index from 0 to
+  `.spec.completions-1`. The index is available through three mechanisms:
+-->
   - Pod注釈`batch.kubernetes.io/job-completion-index`。
+<!--
+  - The Pod annotation `batch.kubernetes.io/job-completion-index`.
+-->
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
+<!--
+  - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`.
+    When you use an Indexed Job in combination with a
+    {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use
+    the deterministic hostnames to address each other via DNS.
+-->
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
-  
+<!--
+  - From the containarized task, in the environment variable `JOB_COMPLETION_INDEX`.
+-->
+
   インデックスごとに、成功したPodが一つ存在すると、Jobの完成となります。完成モードの使用方法の詳細については、
   [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](https://kubernetes.io/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。
+<!--
+  The Job is considered complete when there is one successfully completed Pod
+  for each index. For more information about how to use this mode, see
+  [Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/).
+-->
   めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
+<!--
+  Note that, although rare, more than one Pod could be started for the same
+  index, but only one of them will count towards the completion count.
+-->
 
 ## Podとコンテナの障害対策
+<!--
+Handling Pod and container failures
+-->
 
 Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
+<!--
+A container in a Pod may fail for a number of reasons, such as because the process in it exited with a non-zero exit code, or the container was killed for exceeding a memory limit, etc.  If this happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays on the node, but the container is re-run.  Therefore, your program needs to handle the case when it is restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`.
+-->
 `restartPolicy`の詳細については[Podのライフサイクル](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
+<!--
+See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`.
+-->
 
 Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定したPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションが新しいPodの再起動処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
+<!--
+An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node (node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the `.spec.template.spec.restartPolicy = "Never"`.  When a Pod fails, then the Job controller starts a new Pod.  This means that your application needs to handle the case when it is restarted in a new pod.  In particular, it needs to handle temporary files, locks, incomplete output and the like caused by previous runs.
+-->
 
 `.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
+<!--
+Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and
+`.spec.template.spec.restartPolicy = "Never"`, the same program may sometimes be started twice.
+-->
 
 `.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
+<!--
+If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be multiple pods running at once.  Therefore, your pods must also be tolerant of concurrency.
+-->
 
 ### Pod失敗のバックオフポリシー
+<!--
+Pod backoff failure policy
+-->
 
 設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
+<!--
+There are situations where you want to fail a Job after some amount of retries
+due to a logical error in configuration etc.
+To do so, set `.spec.backoffLimit` to specify the number of retries before
+considering a Job as failed. The back-off limit is set by default to 6. Failed
+Pods associated with the Job are recreated by the Job controller with an
+exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
+back-off count is reset when a Job's Pod is deleted or successful without any
+other Pods for the Job failing around that time.
+-->
 
 {{< note >}}
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
 {{< /note >}}
+<!--
+{{< note >}}
+If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job
+will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting `restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output from failed Jobs is not lost inadvertently.
+{{< /note >}}
+-->
 
 ## Job termination and cleanup
 

From cf0af7fd3d9b834a12288280575495e0b05da0f1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Wed, 15 Jun 2022 08:38:05 +0000
Subject: [PATCH 003/110] modify the layout

---
 .../concepts/workloads/controllers/job.md     | 234 ++++++++----------
 1 file changed, 102 insertions(+), 132 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index d78534dd2ae15..9d144fccdd6ed 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -1,99 +1,96 @@
----
+<!--
 reviewers:
+- erictune
+- soltysh
 title: Jobs
 content_type: concept
 feature:
-  title: バッチ実行
+  title: Batch execution
   description: >
-    サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを引き換えることもできます。
+    In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
 weight: 50
+-->
 ---
-<!--
 reviewers:
-- erictune
-- soltysh
 title: Jobs
 content_type: concept
 feature:
-  title: Batch execution
+  title: バッチ実行
   description: >
-    In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
+    サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを引き換えることもできます。
 weight: 50
--->
-
+---
 
 <!-- overview -->
 
-Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、タスク（つまりJob）の完成となります。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
 <!--
-A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate.
-As pods successfully complete, the Job tracks the successful completions.  When a specified number of successful completions is reached, the task (ie, Job) is complete.  Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
+A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions.  When a specified number of successful completions is reached, the task (ie, Job) is complete.  Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
 -->
+Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、タスク（つまりJob）の完成となります。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
 
-単純なケースを言うと、一つのPodが正常に完成するまで実行することを確保するため、一つのJobオブジェクトを作成します。
-一つ目のPodに障害が発生したり、削除されたり（例えばノードのハードウェア障害またノードの再起動が起こした場合）すると、Jobオブジェクトは新しいPodを作成してくれます。
 <!--
 A simple case is to create one Job object in order to reliably run one Pod to completion.
 The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot).
 -->
+単純なケースを言うと、一つのPodが正常に完成するまで実行することを確保するため、一つのJobオブジェクトを作成します。
+一つ目のPodに障害が発生したり、削除されたり（例えばノードのハードウェア障害またノードの再起動が起こした場合）すると、Jobオブジェクトは新しいPodを作成してくれます。
 
-Jobで複数のPodを並行して実行することもできます。
 <!--
 You can also use a Job to run multiple Pods in parallel.
 -->
+Jobで複数のPodを並行して実行することもできます。
 
-スケジュールに沿ってJob（単一のタスクか複数タスク並行のいずれか）を実行したい場合は [CronJob](https://kubernetes.io/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
 <!--
-If you want to run a Job (either a single task, or several in parallel) on a schedule,
-see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/).
+If you want to run a Job (either a single task, or several in parallel) on a schedule, see[CronJob](/docs concepts/workloads/controllers/cron-jobs/).
 -->
+スケジュールに沿ってJob（単一のタスクか複数タスク並行のいずれか）を実行したい場合は [CronJob](https://kubernetes.io/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
 
 <!-- body -->
 
-## 実行例  {#running-an-example-job}
 <!--
 Running an example Job
 -->
+## 実行例  {#running-an-example-job}
 
-下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完成するまで約10秒かかります。
 <!--
 Here is an example Job config.  It computes π to 2000 places and prints it out.
 It takes around 10s to complete.
 -->
+下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完成するまで約10秒かかります。
 
 {{< codenew file="controllers/job.yaml" >}}
 
-このコマンドで実行できます：
 <!--
 You can run the example with this command:
 -->
+このコマンドで実行できます：
 
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 ```
 
-実行結果はこのようになります：
 <!--
 The output is similar to this:
 -->
+実行結果はこのようになります：
 
 ```
 job.batch/pi created
 ```
 
-`kubectl`でJobの状態を確認できます：
 <!--
 Check on the status of the Job with `kubectl`:
 -->
+`kubectl`でJobの状態を確認できます：
 
 ```shell
 kubectl describe jobs/pi
 ```
 
-実行結果はこのようになります：
 <!--
 The output is similar to this:
 -->
+実行結果はこのようになります：
 
 ```
 Name:           pi
@@ -131,343 +128,316 @@ Events:
   Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7
 ```
 
-Jobの完成したPodを確認するには、`kubectl get pods`を使います。
 <!--
 To view completed Pods of a Job, use `kubectl get pods`.
 -->
+Jobの完成したPodを確認するには、`kubectl get pods`を使います。
 
-Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います：
 <!--
 To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
 -->
+Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います：
 
 ```shell
 pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
 echo $pods
 ```
 
-出力結果はこのようになります：
 <!--
 The output is similar to this:
 -->
+出力結果はこのようになります：
 
 ```
 pi-5rwd7
 ```
 
-ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを選出するための表現です。
 <!--
 Here, the selector is the same as the selector for the Job.  The `--output=jsonpath` option specifies an expression with the name from each Pod in the returned list.
 -->
+ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを選出するための表現です。
 
-その中の一つのPodの標準出力を確認するには：
 <!--
 View the standard output of one of the pods:
 -->
+その中の一つのPodの標準出力を確認するには：
 
 ```shell
 kubectl logs $pods
 ```
 
-出力結果はこのようになります：
 <!--
 The output is similar to this:
 -->
+出力結果はこのようになります：
 
 ```
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
 ```
 
-## spec（仕様）の書き方  {#writing-a-job-spec}
 <!--
 Writing a Job spec
 -->
+## spec（仕様）の書き方  {#writing-a-job-spec}
 
-他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
-Jobの名前は有効な[DNSサブドメイン名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
 <!--
 As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
 Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
+他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
+Jobの名前は有効な[DNSサブドメイン名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
 
-Jobには[`.spec`フィールド](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
 <!--
 A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
 -->
+Jobには[`.spec`フィールド](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
 
-### Podテンプレート  {#pod-template}
 <!--
 Pod Template
 -->
+### Podテンプレート  {#pod-template}
 
-`.spec.template`は`.spec`の唯一の必須フィールドです。
 <!--
 The `.spec.template` is the only required field of the `.spec`.
 -->
+`.spec.template`は`.spec`の唯一の必須フィールドです。
 
-`.spec.template`の値は[podテンプレート](https://kubernetes.io/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、定義仕様が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
 <!--
 The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
 -->
+`.spec.template`の値は[podテンプレート](https://kubernetes.io/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、定義仕様が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
 
-Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
 <!--
-In addition to required fields for a Pod, a pod template in a Job must specify appropriate
-labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
+In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
 -->
+Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
 
-[`RestartPolicy`](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`にのみ設定可能です。
 <!--
 Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
 -->
+[`RestartPolicy`](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`にのみ設定可能です。
 
-### Podセレクター  {#pod-selector}
 <!--
 Pod selector
 -->
+### Podセレクター  {#pod-selector}
 
-`.spec.selector` フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
-[独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
 <!--
 The `.spec.selector` field is optional.  In almost all cases you should not specify it.
 See section [specifying your own pod selector](#specifying-your-own-pod-selector).
 -->
+`.spec.selector` フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
+[独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
 
-### Jobの並列実行  {#parallel-jobs}
 <!--
 Parallel execution for Jobs 
 -->
+### Jobの並列実行  {#parallel-jobs}
 
-Jobで実行するのに適したタスクは主に3種類あります：
 <!--
 There are three main types of task suitable to run as a Job:
 -->
+Jobで実行するのに適したタスクは主に3種類あります：
 
-1. 非並列Job
-   - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
-   - Podが正常に終了すると、Jobの完成となります。
 <!--
 1. Non-parallel Jobs
    - normally, only one Pod is started, unless the Pod fails.
    - the Job is complete as soon as its Pod terminates successfully.
 -->
-2. *一定の完成数*が決められた並列Job：
-   - `.spec.completions`に正の値を指定します。
-   - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完成となります。
-   - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
+1. 非並列Job
+   - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
+   - Podが正常に終了すると、Jobの完成となります。
 <!--
 2. Parallel Jobs with a *fixed completion count*:
    - specify a non-zero positive value for `.spec.completions`.
    - the Job represents the overall task, and is complete when there are `.spec.completions` successful Pods.
    - when using `.spec.completionMode="Indexed"`, each Pod gets a different index in the range 0 to `.spec.completions-1`.
 -->
-3. *ワークキュー*を利用した並列Job：
-   - `.spec.completions`の設定はしない、デフォルトは`.spec.parallelism`となります。
+2. *一定の完成数*が決められた並列Job：
+   - `.spec.completions`に正の値を指定します。
+   - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完成となります。
+   - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
 <!--
 3. Parallel Jobs with a *work queue*:
    - do not specify `.spec.completions`, default to `.spec.parallelism`.
 -->
-   - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
+3. *ワークキュー*を利用した並列Job：
+   - `.spec.completions`の設定はしない、デフォルトは`.spec.parallelism`となります。
 <!--
    - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
 -->
-   - 各Podは他のPodが完成したかどうか、つまりJobが完成したかどうかを単独で判断できます。
+   - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
 <!--
    - each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
 -->
-   - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
+   - 各Podは他のPodが完成したかどうか、つまりJobが完成したかどうかを単独で判断できます。
 <!--
    - when _any_ Pod from the Job terminates with success, no new Pods are created.
 -->
-   - 一つ以上のPodが成功に終了し、すべてのPodが終了すると、Jobの成功終了となります。
+   - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
 <!--
    - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
 -->
-   - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
+   - 一つ以上のPodが成功に終了し、すべてのPodが終了すると、Jobの成功終了となります。
 <!--
    - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output.  They should all be in the process of exiting.
 -->
+   - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
 
- _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
 <!--
-For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset.  When both are
-unset, both are defaulted to 1.
+For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset.  When both are unset, both are defaulted to 1.
 -->
+ _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
 
- _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完成数に設定する必要があります。
-`.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
 <!--
-For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed.
-You can set `.spec.parallelism`, or leave it unset and it will default to 1.
+For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed. You can set `.spec.parallelism`, or leave it unset and it will default to 1.
 -->
+ _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完成数に設定する必要があります。
+`.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
 
- _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
 <!--
 For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to a non-negative integer.
 -->
+ _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
 
 各種類Jobの利用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
 <!--
 For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
 -->
 
-#### 並列処理の制御
 <!--
 Controlling parallelism
 -->
+#### 並列処理の制御
 
-必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
-未設定の場合は、デフォルトで1になります。
-0に設定した際に、増加するまでJobは一時停止されます。
 <!--
 The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
 If it is unspecified, it defaults to 1.
 If it is specified as 0, then the Job is effectively paused until it is increased.
 -->
+必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
+未設定の場合は、デフォルトで1になります。
+0に設定した際に、増加するまでJobは一時停止されます。
 
-実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
 <!--
 Actual parallelism (number of pods running at any instant) may be more or less than requested parallelism, for a variety of reasons:
 -->
+実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
 
--  _完成数一定_ 並列Jobの場合、実際に並行して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 <!--
 - For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of remaining completions.   Higher values of `.spec.parallelism` are effectively ignored.
 -->
--  _ワークキュー_ 並列Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
+-  _完成数一定_ 並列Jobの場合、実際に並行して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 <!--
 - For _work queue_ Jobs, no new Pods are started after any Pod has succeeded -- remaining Pods are allowed to complete, however.
 -->
-- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合、または
+-  _ワークキュー_ 並列Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
 <!--
 - If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react.
 -->
-- Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
-  実際並列数は必要並列数より少なくなる可能性があります。
+- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合、または
 <!--
 - If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.),
   then there may be fewer pods than requested.
 -->
-- 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
+- Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
+  実際並列数は必要並列数より少なくなる可能性があります。
 <!--
 - The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
 -->
-- Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
+- 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
 <!--
 - When a Pod is gracefully shut down, it takes time to stop.
 -->
+- Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
 
-### 完成モード
 <!--
 Completion mode
 -->
+### 完成モード
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
- _完成数一定_ 並列Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完成モードを指定できます：
 <!--
-Jobs with _fixed completion count_ - that is, jobs that have non null
-`.spec.completions` - can have a completion mode that is specified in `.spec.completionMode`:
+Jobs with _fixed completion count_ - that is, jobs that have non null `.spec.completions`- can have a completion mode that is specified in `.spec.completionMode`:
 -->
+ _完成数一定_ 並列Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完成モードを指定できます：
 
+<!--
+- `NonIndexed` (default): the Job is considered complete when there have been `.spec.completions` successfully completed Pods. In other words, each Pod completion is homologous to each other. Note that Jobs that have null `.spec.completions` are implicitly `NonIndexed`.
+-->
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完成となります。言い換えれば、各Podの完成状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 <!--
-- `NonIndexed` (default): the Job is considered complete when there have been
-  `.spec.completions` successfully completed Pods. In other words, each Pod
-  completion is homologous to each other. Note that Jobs that have null
-  `.spec.completions` are implicitly `NonIndexed`.
+- `Indexed`: the Pods of a Job get an associated completion index from 0 to `.spec.completions-1`. The index is available through three mechanisms:
 -->
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
 <!--
-- `Indexed`: the Pods of a Job get an associated completion index from 0 to
-  `.spec.completions-1`. The index is available through three mechanisms:
+  - The Pod annotation `batch.kubernetes.io/job-completion-index`.
 -->
   - Pod注釈`batch.kubernetes.io/job-completion-index`。
 <!--
-  - The Pod annotation `batch.kubernetes.io/job-completion-index`.
+  - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`. When you use an Indexed Job in combination with a {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use the deterministic hostnames to address each other via DNS.
 -->
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
-<!--
-  - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`.
-    When you use an Indexed Job in combination with a
-    {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use
-    the deterministic hostnames to address each other via DNS.
--->
-  - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
 <!--
   - From the containarized task, in the environment variable `JOB_COMPLETION_INDEX`.
 -->
+  - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
 
-  インデックスごとに、成功したPodが一つ存在すると、Jobの完成となります。完成モードの使用方法の詳細については、
-  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](https://kubernetes.io/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。
 <!--
-  The Job is considered complete when there is one successfully completed Pod
-  for each index. For more information about how to use this mode, see
-  [Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/).
--->
-  めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
-<!--
-  Note that, although rare, more than one Pod could be started for the same
-  index, but only one of them will count towards the completion count.
+  The Job is considered complete when there is one successfully completed Pod for each index. For more information about how to use this mode, see [Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/).Note that, although rare, more than one Pod could be started for the same index, but only one of them will count towards the completion count.
 -->
+  インデックスごとに、成功したPodが一つ存在すると、Jobの完成となります。完成モードの使用方法の詳細については、
+  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](https://kubernetes.io/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
 
-## Podとコンテナの障害対策
 <!--
 Handling Pod and container failures
 -->
+## Podとコンテナの障害対策
 
-Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
 <!--
 A container in a Pod may fail for a number of reasons, such as because the process in it exited with a non-zero exit code, or the container was killed for exceeding a memory limit, etc.  If this happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays on the node, but the container is re-run.  Therefore, your program needs to handle the case when it is restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`.
 -->
-`restartPolicy`の詳細については[Podのライフサイクル](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
+Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
 <!--
 See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`.
 -->
+`restartPolicy`の詳細については[Podのライフサイクル](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
 
-Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定したPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションが新しいPodの再起動処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
 <!--
 An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node (node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the `.spec.template.spec.restartPolicy = "Never"`.  When a Pod fails, then the Job controller starts a new Pod.  This means that your application needs to handle the case when it is restarted in a new pod.  In particular, it needs to handle temporary files, locks, incomplete output and the like caused by previous runs.
 -->
+Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定したPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションが新しいPodの再起動処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
 
-`.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
 <!--
-Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and
-`.spec.template.spec.restartPolicy = "Never"`, the same program may sometimes be started twice.
+Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and `.spec.template.spec.restartPolicy = "Never"`, the same program may sometimes be started twice.
 -->
+`.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
 
-`.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
 <!--
 If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be multiple pods running at once.  Therefore, your pods must also be tolerant of concurrency.
 -->
+`.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
 
-### Pod失敗のバックオフポリシー
 <!--
 Pod backoff failure policy
 -->
+### Pod失敗のバックオフポリシー
 
-設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
 <!--
-There are situations where you want to fail a Job after some amount of retries
-due to a logical error in configuration etc.
-To do so, set `.spec.backoffLimit` to specify the number of retries before
-considering a Job as failed. The back-off limit is set by default to 6. Failed
-Pods associated with the Job are recreated by the Job controller with an
-exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
-back-off count is reset when a Job's Pod is deleted or successful without any
-other Pods for the Job failing around that time.
+There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set `.spec.backoffLimit` to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time.
 -->
+設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
 
-{{< note >}}
-`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
-{{< /note >}}
 <!--
 {{< note >}}
-If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job
-will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting `restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output from failed Jobs is not lost inadvertently.
+If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting `restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output from failed Jobs is not lost inadvertently.
 {{< /note >}}
 -->
+{{< note >}}
+`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
+{{< /note >}}
 
 ## Job termination and cleanup
 

From 3776516e1301a0bd5d3bffe689e7db6dcc4b7eba Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Thu, 16 Jun 2022 09:27:31 +0000
Subject: [PATCH 004/110] deleted reviewers block, modified the links and
 commited the suggestion

---
 .../concepts/workloads/controllers/job.md     | 61 +++++++++----------
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9d144fccdd6ed..b38f2c397dca4 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -11,13 +11,12 @@ feature:
 weight: 50
 -->
 ---
-reviewers:
 title: Jobs
 content_type: concept
 feature:
   title: バッチ実行
   description: >
-    サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを引き換えることもできます。
+    サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを置き換えることもできます。
 weight: 50
 ---
 
@@ -26,24 +25,24 @@ weight: 50
 <!--
 A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions.  When a specified number of successful completions is reached, the task (ie, Job) is complete.  Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
 -->
-Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、タスク（つまりJob）の完成となります。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
+Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、そのタスク(つまりJob)は完了したとみなされます。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
 
 <!--
 A simple case is to create one Job object in order to reliably run one Pod to completion.
 The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot).
 -->
-単純なケースを言うと、一つのPodが正常に完成するまで実行することを確保するため、一つのJobオブジェクトを作成します。
-一つ目のPodに障害が発生したり、削除されたり（例えばノードのハードウェア障害またノードの再起動が起こした場合）すると、Jobオブジェクトは新しいPodを作成してくれます。
+単純なケースを言うと、確実に一つのPodが正常に完了するまで実行されるよう、一つのJobオブジェクトを作成します。
+一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成してくれます。
 
 <!--
 You can also use a Job to run multiple Pods in parallel.
 -->
-Jobで複数のPodを並行して実行することもできます。
+Jobで複数のPodを並列で実行することもできます。。
 
 <!--
 If you want to run a Job (either a single task, or several in parallel) on a schedule, see[CronJob](/docs concepts/workloads/controllers/cron-jobs/).
 -->
-スケジュールに沿ってJob（単一のタスクか複数タスク並行のいずれか）を実行したい場合は [CronJob](https://kubernetes.io/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
+スケジュールに沿ってJob(単一のタスクか複数タスク並列のいずれか)を実行したい場合は [CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
 
 <!-- body -->
 
@@ -56,14 +55,14 @@ Running an example Job
 Here is an example Job config.  It computes π to 2000 places and prints it out.
 It takes around 10s to complete.
 -->
-下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完成するまで約10秒かかります。
+下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完了するまで約10秒かかります。
 
 {{< codenew file="controllers/job.yaml" >}}
 
 <!--
 You can run the example with this command:
 -->
-このコマンドで実行できます：
+このコマンドで実行できます:
 
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
@@ -72,7 +71,7 @@ kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 <!--
 The output is similar to this:
 -->
-実行結果はこのようになります：
+実行結果はこのようになります:
 
 ```
 job.batch/pi created
@@ -81,7 +80,7 @@ job.batch/pi created
 <!--
 Check on the status of the Job with `kubectl`:
 -->
-`kubectl`でJobの状態を確認できます：
+`kubectl`でJobの状態を確認できます:
 
 ```shell
 kubectl describe jobs/pi
@@ -90,7 +89,7 @@ kubectl describe jobs/pi
 <!--
 The output is similar to this:
 -->
-実行結果はこのようになります：
+実行結果はこのようになります:
 
 ```
 Name:           pi
@@ -131,12 +130,12 @@ Events:
 <!--
 To view completed Pods of a Job, use `kubectl get pods`.
 -->
-Jobの完成したPodを確認するには、`kubectl get pods`を使います。
+Jobの完了したPodを確認するには、`kubectl get pods`を使います。
 
 <!--
 To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
 -->
-Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います：
+Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います:
 
 ```shell
 pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
@@ -146,7 +145,7 @@ echo $pods
 <!--
 The output is similar to this:
 -->
-出力結果はこのようになります：
+出力結果はこのようになります:
 
 ```
 pi-5rwd7
@@ -155,7 +154,7 @@ pi-5rwd7
 <!--
 Here, the selector is the same as the selector for the Job.  The `--output=jsonpath` option specifies an expression with the name from each Pod in the returned list.
 -->
-ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを選出するための表現です。
+ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを指定するための表現です。
 
 <!--
 View the standard output of one of the pods:
@@ -178,7 +177,7 @@ The output is similar to this:
 <!--
 Writing a Job spec
 -->
-## spec（仕様）の書き方  {#writing-a-job-spec}
+## Job spec(仕様)の書き方  {#writing-a-job-spec}
 
 <!--
 As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
@@ -205,7 +204,7 @@ The `.spec.template` is the only required field of the `.spec`.
 <!--
 The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
 -->
-`.spec.template`の値は[podテンプレート](https://kubernetes.io/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、定義仕様が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
+`.spec.template`の値は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、仕様の定義がが{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
 
 <!--
 In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
@@ -215,7 +214,7 @@ Podの必須フィールド以外、Job定義ファイルにあるPodテンプ
 <!--
 Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
 -->
-[`RestartPolicy`](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`にのみ設定可能です。
+[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`のみ設定可能です。
 
 <!--
 Pod selector
@@ -226,7 +225,7 @@ Pod selector
 The `.spec.selector` field is optional.  In almost all cases you should not specify it.
 See section [specifying your own pod selector](#specifying-your-own-pod-selector).
 -->
-`.spec.selector` フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
+`.spec.selector`フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
 [独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
 
 <!--
@@ -237,7 +236,7 @@ Parallel execution for Jobs
 <!--
 There are three main types of task suitable to run as a Job:
 -->
-Jobで実行するのに適したタスクは主に3種類あります：
+Jobで実行するのに適したタスクは主に3種類あります:
 
 <!--
 1. Non-parallel Jobs
@@ -246,23 +245,23 @@ Jobで実行するのに適したタスクは主に3種類あります：
 -->
 1. 非並列Job
    - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
-   - Podが正常に終了すると、Jobの完成となります。
+   - Podが正常に終了すると、Jobの完了となります。
 <!--
 2. Parallel Jobs with a *fixed completion count*:
    - specify a non-zero positive value for `.spec.completions`.
    - the Job represents the overall task, and is complete when there are `.spec.completions` successful Pods.
    - when using `.spec.completionMode="Indexed"`, each Pod gets a different index in the range 0 to `.spec.completions-1`.
 -->
-2. *一定の完成数*が決められた並列Job：
+2. *一定の完了数*が決められた並列Job：
    - `.spec.completions`に正の値を指定します。
-   - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完成となります。
+   - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
    - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
 <!--
 3. Parallel Jobs with a *work queue*:
    - do not specify `.spec.completions`, default to `.spec.parallelism`.
 -->
-3. *ワークキュー*を利用した並列Job：
-   - `.spec.completions`の設定はしない、デフォルトは`.spec.parallelism`となります。
+3. *ワークキュー*を利用した並列Job:
+   - `.spec.completions`の設定はせず、デフォルトは`.spec.parallelism`となります。
 <!--
    - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
 -->
@@ -278,7 +277,7 @@ Jobで実行するのに適したタスクは主に3種類あります：
 <!--
    - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
 -->
-   - 一つ以上のPodが成功に終了し、すべてのPodが終了すると、Jobの成功終了となります。
+   - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは成功終了とみなされます。
 <!--
    - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output.  They should all be in the process of exiting.
 -->
@@ -292,7 +291,7 @@ For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.para
 <!--
 For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed. You can set `.spec.parallelism`, or leave it unset and it will default to 1.
 -->
- _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完成数に設定する必要があります。
+ _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
 `.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
 
 <!--
@@ -327,15 +326,15 @@ Actual parallelism (number of pods running at any instant) may be more or less t
 <!--
 - For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of remaining completions.   Higher values of `.spec.parallelism` are effectively ignored.
 -->
--  _完成数一定_ 並列Jobの場合、実際に並行して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
+-  _完成数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 <!--
 - For _work queue_ Jobs, no new Pods are started after any Pod has succeeded -- remaining Pods are allowed to complete, however.
 -->
--  _ワークキュー_ 並列Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
+-  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
 <!--
 - If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react.
 -->
-- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合、または
+- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合
 <!--
 - If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.),
   then there may be fewer pods than requested.

From a49267f673a74c4ce01d2f61843d361b7fce3a2a Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Mon, 20 Jun 2022 09:24:18 +0000
Subject: [PATCH 005/110] removed the original English text and fixed the links

---
 .../concepts/workloads/controllers/job.md     | 233 +-----------------
 1 file changed, 4 insertions(+), 229 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index b38f2c397dca4..a3568823119dc 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -1,15 +1,3 @@
-<!--
-reviewers:
-- erictune
-- soltysh
-title: Jobs
-content_type: concept
-feature:
-  title: Batch execution
-  description: >
-    In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
-weight: 50
--->
 ---
 title: Jobs
 content_type: concept
@@ -22,73 +10,41 @@ weight: 50
 
 <!-- overview -->
 
-<!--
-A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions.  When a specified number of successful completions is reached, the task (ie, Job) is complete.  Deleting a Job will clean up the Pods it created. Suspending a Job will delete its active Pods until the Job is resumed again.
--->
 Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、そのタスク(つまりJob)は完了したとみなされます。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
 
-<!--
-A simple case is to create one Job object in order to reliably run one Pod to completion.
-The Job object will start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node reboot).
--->
 単純なケースを言うと、確実に一つのPodが正常に完了するまで実行されるよう、一つのJobオブジェクトを作成します。
 一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成してくれます。
 
-<!--
-You can also use a Job to run multiple Pods in parallel.
--->
 Jobで複数のPodを並列で実行することもできます。。
 
-<!--
-If you want to run a Job (either a single task, or several in parallel) on a schedule, see[CronJob](/docs concepts/workloads/controllers/cron-jobs/).
--->
 スケジュールに沿ってJob(単一のタスクか複数タスク並列のいずれか)を実行したい場合は [CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
 
 <!-- body -->
 
-<!--
-Running an example Job
--->
 ## 実行例  {#running-an-example-job}
 
-<!--
-Here is an example Job config.  It computes π to 2000 places and prints it out.
-It takes around 10s to complete.
--->
 下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完了するまで約10秒かかります。
 
 {{< codenew file="controllers/job.yaml" >}}
 
-<!--
-You can run the example with this command:
--->
 このコマンドで実行できます:
 
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 ```
 
-<!--
-The output is similar to this:
--->
 実行結果はこのようになります:
 
 ```
 job.batch/pi created
 ```
 
-<!--
-Check on the status of the Job with `kubectl`:
--->
 `kubectl`でJobの状態を確認できます:
 
 ```shell
 kubectl describe jobs/pi
 ```
 
-<!--
-The output is similar to this:
--->
 実行結果はこのようになります:
 
 ```
@@ -127,14 +83,8 @@ Events:
   Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7
 ```
 
-<!--
-To view completed Pods of a Job, use `kubectl get pods`.
--->
 Jobの完了したPodを確認するには、`kubectl get pods`を使います。
 
-<!--
-To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
--->
 Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います:
 
 ```shell
@@ -142,298 +92,123 @@ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].met
 echo $pods
 ```
 
-<!--
-The output is similar to this:
--->
 出力結果はこのようになります:
 
 ```
 pi-5rwd7
 ```
 
-<!--
-Here, the selector is the same as the selector for the Job.  The `--output=jsonpath` option specifies an expression with the name from each Pod in the returned list.
--->
 ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを指定するための表現です。
 
-<!--
-View the standard output of one of the pods:
--->
 その中の一つのPodの標準出力を確認するには：
 
 ```shell
 kubectl logs $pods
 ```
 
-<!--
-The output is similar to this:
--->
 出力結果はこのようになります：
 
 ```
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
 ```
 
-<!--
-Writing a Job spec
--->
 ## Job spec(仕様)の書き方  {#writing-a-job-spec}
 
-<!--
-As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
-Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
--->
 他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
-Jobの名前は有効な[DNSサブドメイン名](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
+Jobの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
 
-<!--
-A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
--->
 Jobには[`.spec`フィールド](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
 
-<!--
-Pod Template
--->
 ### Podテンプレート  {#pod-template}
 
-<!--
-The `.spec.template` is the only required field of the `.spec`.
--->
 `.spec.template`は`.spec`の唯一の必須フィールドです。
 
-<!--
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
--->
 `.spec.template`の値は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、仕様の定義がが{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
 
-<!--
-In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
--->
 Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
 
-<!--
-Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
--->
 [`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`のみ設定可能です。
 
-<!--
-Pod selector
--->
 ### Podセレクター  {#pod-selector}
 
-<!--
-The `.spec.selector` field is optional.  In almost all cases you should not specify it.
-See section [specifying your own pod selector](#specifying-your-own-pod-selector).
--->
 `.spec.selector`フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
 [独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
 
-<!--
-Parallel execution for Jobs 
--->
 ### Jobの並列実行  {#parallel-jobs}
 
-<!--
-There are three main types of task suitable to run as a Job:
--->
 Jobで実行するのに適したタスクは主に3種類あります:
 
-<!--
-1. Non-parallel Jobs
-   - normally, only one Pod is started, unless the Pod fails.
-   - the Job is complete as soon as its Pod terminates successfully.
--->
 1. 非並列Job
    - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
    - Podが正常に終了すると、Jobの完了となります。
-<!--
-2. Parallel Jobs with a *fixed completion count*:
-   - specify a non-zero positive value for `.spec.completions`.
-   - the Job represents the overall task, and is complete when there are `.spec.completions` successful Pods.
-   - when using `.spec.completionMode="Indexed"`, each Pod gets a different index in the range 0 to `.spec.completions-1`.
--->
 2. *一定の完了数*が決められた並列Job：
    - `.spec.completions`に正の値を指定します。
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
    - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
-<!--
-3. Parallel Jobs with a *work queue*:
-   - do not specify `.spec.completions`, default to `.spec.parallelism`.
--->
 3. *ワークキュー*を利用した並列Job:
    - `.spec.completions`の設定はせず、デフォルトは`.spec.parallelism`となります。
-<!--
-   - the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
--->
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
-<!--
-   - each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
--->
    - 各Podは他のPodが完成したかどうか、つまりJobが完成したかどうかを単独で判断できます。
-<!--
-   - when _any_ Pod from the Job terminates with success, no new Pods are created.
--->
    - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
-<!--
-   - once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
--->
    - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは成功終了とみなされます。
-<!--
-   - once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output.  They should all be in the process of exiting.
--->
    - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
 
-<!--
-For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset.  When both are unset, both are defaulted to 1.
--->
  _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
 
-<!--
-For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed. You can set `.spec.parallelism`, or leave it unset and it will default to 1.
--->
  _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
 `.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
 
-<!--
-For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to a non-negative integer.
--->
  _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
 
 各種類Jobの利用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
-<!--
-For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
--->
 
-<!--
-Controlling parallelism
--->
 #### 並列処理の制御
 
-<!--
-The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
-If it is unspecified, it defaults to 1.
-If it is specified as 0, then the Job is effectively paused until it is increased.
--->
 必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
 未設定の場合は、デフォルトで1になります。
 0に設定した際に、増加するまでJobは一時停止されます。
 
-<!--
-Actual parallelism (number of pods running at any instant) may be more or less than requested parallelism, for a variety of reasons:
--->
 実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
 
-<!--
-- For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of remaining completions.   Higher values of `.spec.parallelism` are effectively ignored.
--->
 -  _完成数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
-<!--
-- For _work queue_ Jobs, no new Pods are started after any Pod has succeeded -- remaining Pods are allowed to complete, however.
--->
 -  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
-<!--
-- If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react.
--->
 - Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合
-<!--
-- If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.),
-  then there may be fewer pods than requested.
--->
 - Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
   実際並列数は必要並列数より少なくなる可能性があります。
-<!--
-- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
--->
 - 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
-<!--
-- When a Pod is gracefully shut down, it takes time to stop.
--->
 - Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
 
-<!--
-Completion mode
--->
 ### 完成モード
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
-<!--
-Jobs with _fixed completion count_ - that is, jobs that have non null `.spec.completions`- can have a completion mode that is specified in `.spec.completionMode`:
--->
  _完成数一定_ 並列Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完成モードを指定できます：
 
-<!--
-- `NonIndexed` (default): the Job is considered complete when there have been `.spec.completions` successfully completed Pods. In other words, each Pod completion is homologous to each other. Note that Jobs that have null `.spec.completions` are implicitly `NonIndexed`.
--->
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完成となります。言い換えれば、各Podの完成状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
-<!--
-- `Indexed`: the Pods of a Job get an associated completion index from 0 to `.spec.completions-1`. The index is available through three mechanisms:
--->
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
-<!--
-  - The Pod annotation `batch.kubernetes.io/job-completion-index`.
--->
   - Pod注釈`batch.kubernetes.io/job-completion-index`。
-<!--
-  - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`. When you use an Indexed Job in combination with a {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use the deterministic hostnames to address each other via DNS.
--->
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
-<!--
-  - From the containarized task, in the environment variable `JOB_COMPLETION_INDEX`.
--->
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
 
-<!--
-  The Job is considered complete when there is one successfully completed Pod for each index. For more information about how to use this mode, see [Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/).Note that, although rare, more than one Pod could be started for the same index, but only one of them will count towards the completion count.
--->
   インデックスごとに、成功したPodが一つ存在すると、Jobの完成となります。完成モードの使用方法の詳細については、
-  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](https://kubernetes.io/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
+  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
 
-<!--
-Handling Pod and container failures
--->
 ## Podとコンテナの障害対策
 
-<!--
-A container in a Pod may fail for a number of reasons, such as because the process in it exited with a non-zero exit code, or the container was killed for exceeding a memory limit, etc.  If this happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays on the node, but the container is re-run.  Therefore, your program needs to handle the case when it is restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`.
--->
 Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
-<!--
-See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`.
--->
-`restartPolicy`の詳細については[Podのライフサイクル](https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
-
-<!--
-An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node (node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the `.spec.template.spec.restartPolicy = "Never"`.  When a Pod fails, then the Job controller starts a new Pod.  This means that your application needs to handle the case when it is restarted in a new pod.  In particular, it needs to handle temporary files, locks, incomplete output and the like caused by previous runs.
--->
+`restartPolicy`の詳細については[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
+
 Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定したPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションが新しいPodの再起動処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
 
-<!--
-Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and `.spec.template.spec.restartPolicy = "Never"`, the same program may sometimes be started twice.
--->
 `.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
 
-<!--
-If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be multiple pods running at once.  Therefore, your pods must also be tolerant of concurrency.
--->
 `.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
 
-<!--
-Pod backoff failure policy
--->
 ### Pod失敗のバックオフポリシー
 
-<!--
-There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set `.spec.backoffLimit` to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time.
--->
 設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
 
-<!--
-{{< note >}}
-If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting `restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output from failed Jobs is not lost inadvertently.
-{{< /note >}}
--->
 {{< note >}}
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
 {{< /note >}}

From 80be08ff88ed44872a341772e1a59a6837647339 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Mon, 20 Jun 2022 09:48:32 +0000
Subject: [PATCH 006/110] synchronise the modification in the original English
 text

---
 .../concepts/workloads/controllers/job.md     | 66 ++++++++++++++++---
 1 file changed, 58 insertions(+), 8 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index a3568823119dc..2dc895059a216 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -41,13 +41,8 @@ job.batch/pi created
 
 `kubectl`でJobの状態を確認できます:
 
-```shell
-kubectl describe jobs/pi
-```
-
-実行結果はこのようになります:
-
-```
+{{< tabs name="Check status of Job" >}}
+{{< tab name="kubectl describe job pi" codelang="bash" >}}
 Name:           pi
 Namespace:      default
 Selector:       controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
@@ -81,7 +76,62 @@ Events:
   Type    Reason            Age   From            Message
   ----    ------            ----  ----            -------
   Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7
-```
+{{< /tab >}}
+{{< tab name="kubectl get job pi -o yaml" codelang="bash" >}}
+apiVersion: batch/v1
+kind: Job
+metadata:
+  annotations:
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":{"spec":{"containers":[{"command":["perl","-Mbignum=bpi","-wle","print bpi(2000)"],"image":"perl","name":"pi"}],"restartPolicy":"Never"}}}}
+  creationTimestamp: "2022-06-15T08:40:15Z"
+  generation: 1
+  labels:
+    controller-uid: 863452e6-270d-420e-9b94-53a54146c223
+    job-name: pi
+  name: pi
+  namespace: default
+  resourceVersion: "987"
+  uid: 863452e6-270d-420e-9b94-53a54146c223
+spec:
+  backoffLimit: 4
+  completionMode: NonIndexed
+  completions: 1
+  parallelism: 1
+  selector:
+    matchLabels:
+      controller-uid: 863452e6-270d-420e-9b94-53a54146c223
+  suspend: false
+  template:
+    metadata:
+      creationTimestamp: null
+      labels:
+        controller-uid: 863452e6-270d-420e-9b94-53a54146c223
+        job-name: pi
+    spec:
+      containers:
+      - command:
+        - perl
+        - -Mbignum=bpi
+        - -wle
+        - print bpi(2000)
+        image: perl
+        imagePullPolicy: Always
+        name: pi
+        resources: {}
+        terminationMessagePath: /dev/termination-log
+        terminationMessagePolicy: File
+      dnsPolicy: ClusterFirst
+      restartPolicy: Never
+      schedulerName: default-scheduler
+      securityContext: {}
+      terminationGracePeriodSeconds: 30
+status:
+  active: 1
+  ready: 1
+  startTime: "2022-06-15T08:40:15Z"
+{{< /tab >}}
+{{< /tabs >}}
 
 Jobの完了したPodを確認するには、`kubectl get pods`を使います。
 

From 3e0907286c88597be357adc653f2c23b1e69aea6 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:54:31 +0900
Subject: [PATCH 007/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 2dc895059a216..4fcf2f129293e 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -10,7 +10,7 @@ weight: 50
 
 <!-- overview -->
 
-Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完成数に達すると、そのタスク(つまりJob)は完了したとみなされます。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
+Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完了数に達すると、そのタスク(つまりJob)は完了したとみなされます。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
 
 単純なケースを言うと、確実に一つのPodが正常に完了するまで実行されるよう、一つのJobオブジェクトを作成します。
 一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成してくれます。

From cd4bd62cc566bf71e955e4836213cd7a24df3762 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:55:32 +0900
Subject: [PATCH 008/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 4fcf2f129293e..a0d162311f302 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -198,7 +198,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 3. *ワークキュー*を利用した並列Job:
    - `.spec.completions`の設定はせず、デフォルトは`.spec.parallelism`となります。
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
-   - 各Podは他のPodが完成したかどうか、つまりJobが完成したかどうかを単独で判断できます。
+   - 各Podは他のPodが完了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
    - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
    - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは成功終了とみなされます。
    - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。

From 25e7b1151a16efab781fe06fe98bb033fa9ac7bf Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:55:49 +0900
Subject: [PATCH 009/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index a0d162311f302..fc0f6911a6610 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -205,7 +205,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
  _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
 
- _完成数一定_ 並列Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
+ _完了数一定_ 並列Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
 `.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
 
  _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。

From 85ff497cfb36bd3b56d41adde9e7b1eb37075742 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:56:00 +0900
Subject: [PATCH 010/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index fc0f6911a6610..a6752bd60521c 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -220,7 +220,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
 
--  _完成数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完成数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
+-  _完了数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 -  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
 - Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合
 - Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、

From b9c7127470877c8cea10c21d999bad22d33e9847 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:56:12 +0900
Subject: [PATCH 011/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index a6752bd60521c..4bfa8faebd29c 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -228,7 +228,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 - 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
 - Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
 
-### 完成モード
+### 完了モード
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 

From f59fcdc60be5d00a89ca394acc10870f4040f4e5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:57:00 +0900
Subject: [PATCH 012/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 4bfa8faebd29c..ea256bc5ca115 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -232,7 +232,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
- _完成数一定_ 並列Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完成モードを指定できます：
+ _完了数一定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
 
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完成となります。言い換えれば、各Podの完成状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。

From 487e1faa4f6c01ca14553715c7d8d2573d1453aa Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:57:15 +0900
Subject: [PATCH 013/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ea256bc5ca115..9a6fa4f5559ca 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -234,7 +234,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
  _完了数一定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
 
-- `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完成となります。言い換えれば、各Podの完成状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
+- `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
   - Pod注釈`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。

From 58c03a22fbe7fac97ee5a9e62f016abfd2d54df8 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:57:31 +0900
Subject: [PATCH 014/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9a6fa4f5559ca..ccfef82e88125 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -235,7 +235,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
  _完了数一定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
 
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
-- `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完成インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
+- `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
   - Pod注釈`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。

From 94c9c6934cab1d3dd44835a14194f00fb42ca9d5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:57:45 +0900
Subject: [PATCH 015/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ccfef82e88125..afcbe46386637 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -241,7 +241,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
 
-  インデックスごとに、成功したPodが一つ存在すると、Jobの完成となります。完成モードの使用方法の詳細については、
+  インデックスごとに、成功したPodが一つ存在すると、Jobの完了となります。完了モードの使用方法の詳細については、
   [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
 
 ## Podとコンテナの障害対策

From cf2dac1977fccbd6f13f947cbb9a8c6d83872230 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:57:59 +0900
Subject: [PATCH 016/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index afcbe46386637..772a5824584b3 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -242,7 +242,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
 
   インデックスごとに、成功したPodが一つ存在すると、Jobの完了となります。完了モードの使用方法の詳細については、
-  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完成数にカウントされるのはそのうちの一つだけです。
+  [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完了数にカウントされるのはそのうちの一つだけです。
 
 ## Podとコンテナの障害対策
 

From 1061e477f94d05fd5e491ebc2cb8b3e53dacf64c Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:58:14 +0900
Subject: [PATCH 017/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 772a5824584b3..9662f691583fc 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -236,7 +236,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
-  - Pod注釈`batch.kubernetes.io/job-completion-index`。
+  - Podアノテーション`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。

From a9bd115765c85256ad5de7897ad3b101453748b2 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:58:46 +0900
Subject: [PATCH 018/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9662f691583fc..4bcc625b7ba47 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -13,7 +13,7 @@ weight: 50
 Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完了数に達すると、そのタスク(つまりJob)は完了したとみなされます。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
 
 単純なケースを言うと、確実に一つのPodが正常に完了するまで実行されるよう、一つのJobオブジェクトを作成します。
-一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成してくれます。
+一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成します。
 
 Jobで複数のPodを並列で実行することもできます。。
 

From f7883ae3dd9fc1e07c92764cebd350b8bd949cc5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:59:05 +0900
Subject: [PATCH 019/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 4bcc625b7ba47..d46c695f0ec12 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -23,7 +23,7 @@ Jobで複数のPodを並列で実行することもできます。。
 
 ## 実行例  {#running-an-example-job}
 
-下記にJobの定義例を記載しています。πの2000桁まで計算して出力するJobで、完了するまで約10秒かかります。
+下記にJobの定義例を記載しています。πを2000桁まで計算して出力するJobで、完了するまで約10秒かかります。
 
 {{< codenew file="controllers/job.yaml" >}}
 

From 8e921144e5867a013a4ff71ae51448240843ccf1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:59:31 +0900
Subject: [PATCH 020/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index d46c695f0ec12..9fe5753d075c2 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -167,7 +167,7 @@ kubectl logs $pods
 他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
 Jobの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
 
-Jobには[`.spec`フィールド](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
+Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
 
 ### Podテンプレート  {#pod-template}
 

From a680a39c5e4a607f1379552152f5fb744e8b2079 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 18:59:51 +0900
Subject: [PATCH 021/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9fe5753d075c2..54ffa7633c194 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -173,7 +173,7 @@ Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/deve
 
 `.spec.template`は`.spec`の唯一の必須フィールドです。
 
-`.spec.template`の値は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)で、ネストされていることと`apiVersion`と`kind`フィールドが不要になったことを除いて、仕様の定義がが{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
+`.spec.template`は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)です。ネストされていることと`apiVersion`や`kind`フィールドが不要になったことを除いて、仕様の定義が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
 
 Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
 

From d846a8030f08fe55fb035b3fb8845cde2bcdd4c8 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:00:18 +0900
Subject: [PATCH 022/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 54ffa7633c194..56c09f588775f 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -175,7 +175,7 @@ Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/deve
 
 `.spec.template`は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)です。ネストされていることと`apiVersion`や`kind`フィールドが不要になったことを除いて、仕様の定義が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
 
-Podの必須フィールド以外、Job定義ファイルにあるPodテンプレートでは、ラベル([podセレクター](#pod-selector)を参照)と再起動ポリシーを適切な値に指定する必要があります。
+Podの必須フィールドに加えて、Job定義ファイルにあるPodテンプレートでは、適切なラベル([podセレクター](#pod-selector)を参照)と適切な再起動ポリシーを指定する必要があります。
 
 [`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`のみ設定可能です。
 

From b9dee1665ba27415d0cfcafdf2e4aa65559e8c5b Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:00:42 +0900
Subject: [PATCH 023/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 56c09f588775f..48f3fefafc79f 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -181,7 +181,7 @@ Podの必須フィールドに加えて、Job定義ファイルにあるPodテ
 
 ### Podセレクター  {#pod-selector}
 
-`.spec.selector`フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがいいです。
+`.spec.selector`フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがよいです。
 [独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
 
 ### Jobの並列実行  {#parallel-jobs}

From 78fe0bbcd468af472225fbf2213f6d5dfdd56eb1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:02:02 +0900
Subject: [PATCH 024/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 48f3fefafc79f..5f88a3017e4ea 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -15,7 +15,7 @@ Jobは一つ以上のPodを作成し、指定された数のPodが正常に終
 単純なケースを言うと、確実に一つのPodが正常に完了するまで実行されるよう、一つのJobオブジェクトを作成します。
 一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成します。
 
-Jobで複数のPodを並列で実行することもできます。。
+Jobで複数のPodを並列で実行することもできます。
 
 スケジュールに沿ってJob(単一のタスクか複数タスク並列のいずれか)を実行したい場合は [CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
 

From 353574e6a426b274dc0bad8bb1535a4fac113797 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:02:21 +0900
Subject: [PATCH 025/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 5f88a3017e4ea..5641d3fa25f63 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -194,7 +194,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 2. *一定の完了数*が決められた並列Job：
    - `.spec.completions`に正の値を指定します。
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
-   - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスをアサインされます。
+   - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスがアサインされます。
 3. *ワークキュー*を利用した並列Job:
    - `.spec.completions`の設定はせず、デフォルトは`.spec.parallelism`となります。
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。

From e28c3390e4b272b83301ec3e5a3ac6c0b2d89750 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:06:24 +0900
Subject: [PATCH 026/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 5641d3fa25f63..fb3fd36dd5786 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -192,7 +192,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
    - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
    - Podが正常に終了すると、Jobの完了となります。
 2. *一定の完了数*が決められた並列Job：
-   - `.spec.completions`に正の値を指定します。
+   - `.spec.completions`に0以外の正の値を指定します。
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
    - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスがアサインされます。
 3. *ワークキュー*を利用した並列Job:

From e38a53ce67b0a772d937121bf25b57de29ef4073 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:06:41 +0900
Subject: [PATCH 027/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index fb3fd36dd5786..4f324262708a2 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -190,7 +190,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 1. 非並列Job
    - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
-   - Podが正常に終了すると、Jobの完了となります。
+   - Podが正常に終了すると、Jobはすぐに完了します。
 2. *一定の完了数*が決められた並列Job：
    - `.spec.completions`に0以外の正の値を指定します。
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。

From 294f758376bd29ea8c099422ecf3af0cdc044582 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 20 Jun 2022 19:08:05 +0900
Subject: [PATCH 028/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 4f324262708a2..9e00bf6a7a614 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -196,7 +196,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
    - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスがアサインされます。
 3. *ワークキュー*を利用した並列Job:
-   - `.spec.completions`の設定はせず、デフォルトは`.spec.parallelism`となります。
+   - `.spec.completions`の指定をしない場合、デフォルトは`.spec.parallelism`となります。
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
    - 各Podは他のPodが完了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
    - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。

From 86420649944bd9ab216fdd8e5c5a77cc08a5dce1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Tue, 12 Jul 2022 10:19:07 +0000
Subject: [PATCH 029/110] Translate docs/concepts/workloads/controllers/job.md
 into Japanese(Line 266-470)

---
 .../concepts/workloads/controllers/job.md     | 220 +++++++-----------
 1 file changed, 81 insertions(+), 139 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9e00bf6a7a614..ed765c862dbbd 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -212,7 +212,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 各種類Jobの利用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
 
-#### 並列処理の制御
+#### 並列処理の制御  {#controlling-parallelism}
 
 必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
 未設定の場合は、デフォルトで1になります。
@@ -228,7 +228,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 - 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
 - Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
 
-### 完了モード
+### 完了モード  {#completion-mode}
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
@@ -244,7 +244,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
   インデックスごとに、成功したPodが一つ存在すると、Jobの完了となります。完了モードの使用方法の詳細については、
   [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完了数にカウントされるのはそのうちの一つだけです。
 
-## Podとコンテナの障害対策
+## Podとコンテナの障害対策  {#handling-pod-and-container-failures}
 
 Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
 `restartPolicy`の詳細については[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
@@ -255,7 +255,7 @@ Podがノードからキックされた（ノードがアップグレード、
 
 `.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
 
-### Pod失敗のバックオフポリシー
+### Pod失敗のバックオフポリシー  {#pod-backoff-failure-policy}
 
 設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
 
@@ -263,25 +263,22 @@ Podがノードからキックされた（ノードがアップグレード、
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
 {{< /note >}}
 
-## Job termination and cleanup
+## Jobの終了と後片付け  {#job-termination-and-cleanup}
 
-When a Job completes, no more Pods are created, but the Pods are [usually](#pod-backoff-failure-policy) not deleted either.
-Keeping them around
-allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
-The job object also remains after it is completed so that you can view its status.  It is up to the user to delete
-old jobs after noting their status.  Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
+Jobが完了すると、それ以上Podは作成されませんが、[通常](#pod-backoff-failure-policy)Podが削除されることもありません。
+これらを残しておくと、完了したPodのログを確認でき、エラーや警告などの診断出力を確認できます。
+またJobオブジェクトはJob終了後も残し、状態を確認することができます。古いJobの状態を把握した上で、削除するかどうかはユーザー次第です。Jobを削除するには`kubectl` (例：`kubectl delete jobs/pi`または`kubectl delete -f ./job.yaml`)を使います。`kubectl`でJobを削除する場合、Jobが作成したPodも全部削除されます。
 
-By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the
-`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will be marked as failed and any running Pods will be terminated.
+デフォルトでは、Jobは中断されることなく実行できますが、Podが失敗した場合(`restartPolicy=Never`)、またはコンテナがエラーで終了した場合(`restartPolicy=OnFailure`)のみ、前述の`.spec.backoffLimit`で決まった回数まで再試行します。`.spec.backoffLimit`に達すると、Jobが失敗とマークされ、実行中のPodもすべて終了されます。
 
-Another way to terminate a Job is by setting an active deadline.
-Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds.
-The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
-Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`.
+Jobを終了させるもう一つの方法は、活動期間を設定することです。
+Jobの`.spec.activeDeadlineSeconds`フォールドに秒数を設定することで、活動期間を設定できます。
+Podがいくつ作成されても、`activeDeadlineSeconds`はJobの存続する時間に適用されます。
+Jobが`activeDeadlineSeconds`に達すると、実行中のすべてのPodは終了され、Jobの状態は`type: Failed`になり、理由は`reason: DeadlineExceeded`になります。
 
-Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.
+ここで要注意なのは、Jobの`.spec.activeDeadlineSeconds`は`.spec.backoffLimit`よりも優先されます。したがって、失敗して再試行しているPodが一つ以上持っているJobは、`backoffLimit`に達していなくても、`activeDeadlineSeconds`で指定された設定時間に達すると、追加のPodをデプロイしなくなります。
 
-Example:
+例えば:
 
 ```yaml
 apiVersion: batch/v1
@@ -300,35 +297,25 @@ spec:
       restartPolicy: Never
 ```
 
-Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level.
+Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)は両方とも`activeDeadlineSeconds`フィールドを持っているので注意してください。適切なレベルで設定していることを確認してください。
 
-Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`.
-That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
+また`restartPolicy`はJob自体ではなく、Podに適用されることも注意してください: Jobの状態は`type: Failed`になると、自動的再起動されることはありません。
+つまり、`.spec.activeDeadlineSeconds`と`.spec.backoffLimit`によって引き起こされるJob終了メカニズムは、永久的なJob失敗につながり、手動で介入して解決する必要があります。
 
-## Clean up finished jobs automatically
+## 終了したJobの自動片付け  {#clean-up-finished-jobs-automatically}
 
-Finished Jobs are usually no longer needed in the system. Keeping them around in
-the system will put pressure on the API server. If the Jobs are managed directly
-by a higher level controller, such as
-[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
-cleaned up by CronJobs based on the specified capacity-based cleanup policy.
+終了したJobは通常システムに残す必要はありません。残ったままにしておくとAPIサーバーに負担をかけることになります。Jobが上位コントローラーにより直接管理されている場合、例えば[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)の場合、Jobは指定された容量ベースの片付けポリシーに基づき、CronJobにより片付けられます。
 
-### TTL mechanism for finished Jobs
+### 終了したJobのTTLメカニズム  {#ttl-mechanism-for-finished-jobs}
 
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 
-Another way to clean up finished Jobs (either `Complete` or `Failed`)
-automatically is to use a TTL mechanism provided by a
-[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
-finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of
-the Job.
+終了したJob(状態は`Complete`か`Failed`になったJob)を自動的に片付けるもう一つの方法は
+[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースを片付けることができます。
 
-When the TTL controller cleans up the Job, it will delete the Job cascadingly,
-i.e. delete its dependent objects, such as Pods, together with the Job. Note
-that when the Job is deleted, its lifecycle guarantees, such as finalizers, will
-be honored.
+TTLコントローラーでJobを片付ける場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Jobのライフサイクル保証、例えばFinalizersなど、は考えられるので注意してください。
 
-For example:
+例えば:
 
 ```yaml
 apiVersion: batch/v1
@@ -346,117 +333,80 @@ spec:
       restartPolicy: Never
 ```
 
-The Job `pi-with-ttl` will be eligible to be automatically deleted, `100`
-seconds after it finishes.
+Job`pi-with-ttl`は終了してからの`100`秒後に自動的に削除されるようになっています。
 
-If the field is set to `0`, the Job will be eligible to be automatically deleted
-immediately after it finishes. If the field is unset, this Job won't be cleaned
-up by the TTL controller after it finishes.
+このフィールドに`0`を設定すると、Jobは終了後すぐに削除されるようになります。このフィールドに何も設定しないと、Jobは終了してもTTLコントローラーより片付けられません。
 
 {{< note >}}
-It is recommended to set `ttlSecondsAfterFinished` field because unmanaged jobs
-(Jobs that you created directly, and not indirectly through other workload APIs
-such as CronJob) have a default deletion
-policy of `orphanDependents` causing Pods created by an unmanaged Job to be left around
-after that Job is fully deleted.
-Even though the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} eventually
-[garbage collects](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
-the Pods from a deleted Job after they either fail or complete, sometimes those
-lingering pods may cause cluster performance degradation or in worst case cause the
-cluster to go offline due to this degradation.
-
-You can use [LimitRanges](/docs/concepts/policy/limit-range/) and
-[ResourceQuotas](/docs/concepts/policy/resource-quotas/) to place a
-cap on the amount of resources that a particular namespace can
-consume.
+`ttlSecondsAfterFinished`フィールドを設定することが推奨されます。管理されていないJob(CronJobなどの、他のワークロードAPIを経由せずに、直接作成したJob)は`orphanDependents`というデフォルトの削除ポリシーがあるため、Jobが完全に削除されても、属しているPodが残ってしまうからです。
+{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスタのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスタがオフラインになることがあります。
+
+[LimitRanges](/ja/docs/concepts/policy/limit-range/)と[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)で、指定する名前空間が消費できるリソースの量に上限を設定することができます。
 {{< /note >}}
 
 
 ## Jobパターン  {#job-patterns}
 
-The Job object can be used to support reliable parallel execution of Pods.  The Job object is not
-designed to support closely-communicating parallel processes, as commonly found in scientific
-computing.  It does support parallel processing of a set of independent but related *work items*.
-These might be emails to be sent, frames to be rendered, files to be transcoded, ranges of keys in a
-NoSQL database to scan, and so on.
+Jobオブジェクトは、Podの確実な並列実行をサポートするために使用されます。科学技術計算でよく見られるような、密接に通信を行う並列処理をサポートするようには設計されていません。独立だが関連性のある一連の*作業項目*の並列処理をサポートします。例えば送信すべき電子メール、レンダリングすべきフレーム、トランスコードすべきファイル、スキャンすべきNoSQLデータベースのキーの範囲、などなどです。
 
-In a complex system, there may be multiple different sets of work items.  Here we are just
-considering one set of work items that the user wants to manage together &mdash; a *batch job*.
+複雑なシステムでは、異なる作業項目のセットが複数存在する場合があります。ここでは、ユーザーが一斉に管理したい作業項目のセットが一つだけの場合 &mdash; つまり*バッチJob*だけを考えます。
 
-There are several different patterns for parallel computation, each with strengths and weaknesses.
-The tradeoffs are:
+並列計算にはいくつかのパターンがあり、それぞれに長所と短所があります。
+兼ね合うべき要素は:
 
-- One Job object for each work item, vs. a single Job object for all work items.  The latter is
-  better for large numbers of work items.  The former creates some overhead for the user and for the
-  system to manage large numbers of Job objects.
-- Number of pods created equals number of work items, vs. each Pod can process multiple work items.
-  The former typically requires less modification to existing code and containers.  The latter
-  is better for large numbers of work items, for similar reasons to the previous bullet.
-- Several approaches use a work queue.  This requires running a queue service,
-  and modifications to the existing program or container to make it use the work queue.
-  Other approaches are easier to adapt to an existing containerised application.
+- 各作業項目に1つのJobオブジェクト、 vs. すべての作業項目に1つのJobオブジェクト。  
+　後者は大量の作業項目を処理する場合に適しています。  
+　前者は大量のJobオブジェクトを管理するため、ユーザーとシステムにオーバーヘッドをかけることになります。
+- 作成されるPod数が作業項目数と等しい、 vs. 各Podが複数の作業項目を処理する。
+　前者は通常、既存のコードやコンテナへの変更が少なくて済みます。
+  後者は上記と同じ理由で、大量の作業項目を処理する場合に適しています。
+- ワークキューを利用するアプローチもいくつかあります。それを使うためには、キューサービスを実行し、　既存のプログラムやコンテナにワークキューを利用させるための改造を行う必要があります。
+  他のアプローチは既存のコンテナ型アプリケーションに適用しやすいです。
 
 
-The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs.
-The pattern names are also links to examples and more detailed description.
+ここでは、上記のトレードオフをまとめてあり、それぞれ2～4列目に対応しています。
+またパターン名のところは、例やより詳しい説明が書いてあるページへのリンクになっています。
 
-|                  Pattern                  | Single Job object | Fewer pods than work items? | Use app unmodified? |
+|                  パターン                  | 単一Jobオブジェクト | Podが作業項目より少ない？ | アプリを修正せずに使用できる？ |
 | ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
-| [Queue with Pod Per Work Item]            |         ✓         |                             |      sometimes      |
-| [Queue with Variable Pod Count]           |         ✓         |             ✓               |                     |
-| [Indexed Job with Static Work Assignment] |         ✓         |                             |          ✓          | 
-| [Job Template Expansion]                  |                   |                             |          ✓          |
+| [作業項目ごとにPodを持つキュー]            |         ✓         |                             |      時々      |
+| [Pod数可変のキュー]           |         ✓         |             ✓               |                     |
+| [静的な処理の割り当てを使用したインデックス付きJob] |         ✓         |                             |          ✓          | 
+| [Jobテンプレート拡張]                  |                   |                             |          ✓          |
 
-When you specify completions with `.spec.completions`, each Pod created by the Job controller
-has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).  This means that
-all pods for a task will have the same command line and the same
-image, the same volumes, and (almost) the same environment variables.  These patterns
-are different ways to arrange for pods to work on different things.
+`.spec.completions`で完成数を指定する場合、Jobコントローラーより作成された各Podは同一の[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。これは、このタスクのすべてのPodが同じコマンドライン、同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持つことを意味します。これらのパターンは、Podが異なる作業をするためのさまざまな配置方法になります。
 
-This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns.
-Here, `W` is the number of work items.
+この表は、各パターンで必要な`.spec.parallelism`と`.spec.completions`の設定を示しています。
+ここで、`W`は作業項目の数を表しています。
 
-|             Pattern                       | `.spec.completions` |  `.spec.parallelism` |
+|             パターン                       | `.spec.completions` |  `.spec.parallelism` |
 | ----------------------------------------- |:-------------------:|:--------------------:|
-| [Queue with Pod Per Work Item]            |          W          |        any           |
-| [Queue with Variable Pod Count]           |         null        |        any           |
-| [Indexed Job with Static Work Assignment] |          W          |        any           |
-| [Job Template Expansion]                  |          1          |     should be 1      |
+| [作業項目ごとにPodを持つキュー]            |          W          |        任意           |
+| [Pod数可変のキュー]           |         null        |        任意           |
+| [静的な処理の割り当てを使用したインデックス付きJob] |          W          |        任意           |
+| [Jobテンプレート拡張]                  |          1          |     1であるべき      |
 
-[Queue with Pod Per Work Item]: /docs/tasks/job/coarse-parallel-processing-work-queue/
-[Queue with Variable Pod Count]: /docs/tasks/job/fine-parallel-processing-work-queue/
-[Indexed Job with Static Work Assignment]: /docs/tasks/job/indexed-parallel-processing-static/
-[Job Template Expansion]: /docs/tasks/job/parallel-processing-expansion/
+[作業項目ごとにPodを持つキュー]: /docs/tasks/job/coarse-parallel-processing-work-queue/
+[Pod数可変のキュー]: /docs/tasks/job/fine-parallel-processing-work-queue/
+[静的な処理の割り当てを使用したインデックス付きJob]: /ja/docs/tasks/job/indexed-parallel-processing-static/
+[Jobテンプレート拡張]: /docs/tasks/job/parallel-processing-expansion/
 
-## Advanced usage
+## 上級な使用方法  {#advanced-usage}
 
-### Suspending a Job
+### Jobの一時停止  {#suspending-a-job}
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
-When a Job is created, the Job controller will immediately begin creating Pods
-to satisfy the Job's requirements and will continue to do so until the Job is
-complete. However, you may want to temporarily suspend a Job's execution and
-resume it later, or start Jobs in suspended state and have a custom controller
-decide later when to start them.
+Jobが作成されると、JobコントローラーはJobの要件を満たすために直ちにPodの作成を開始し、Jobが完了するまで作成し続けます。しかし、Jobの実行を一時的に中断して後で再開したい場合、または一時停止状態のJobを再開し、再開時間は後でカスタムコントローラーに判断させたい場合はあると思います。
 
-To suspend a Job, you can update the `.spec.suspend` field of
-the Job to true; later, when you want to resume it again, update it to false.
-Creating a Job with `.spec.suspend` set to true will create it in the suspended
-state.
+Jobを一時停止するには、Jobの`.spec.suspend`フィールドをtrueに修正し、後でまた再開したい場合にはfalseに修正すればいいです。
+`.spec.suspend`をtrueに設定してJobを作成すると、一時停止状態のままで作成されます。
 
-When a Job is resumed from suspension, its `.status.startTime` field will be
-reset to the current time. This means that the `.spec.activeDeadlineSeconds`
-timer will be stopped and reset when a Job is suspended and resumed.
+一時停止状態のJobを再開すると、`.status.startTime`フィールドの値は現在時刻にリセットされます。これはつまり、Jobが一時停止して再開すると、`.spec.activeDeadlineSeconds`タイマーは停止してリセットされることになります。
 
-Remember that suspending a Job will delete all active Pods. When the Job is
-suspended, your [Pods will be terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
-with a SIGTERM signal. The Pod's graceful termination period will be honored and
-your Pod must handle this signal in this period. This may involve saving
-progress for later or undoing changes. Pods terminated this way will not count
-towards the Job's `completions` count.
+Jobを中断すると、稼働中のPodは全部削除されることを忘れないでください。Jobが中断されると、PodはSIGTERM信号を受信して[終了されます](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。Podのグレースフル終了の猶予期間がカウントダウンされ、この期間内に、Podはこの信号を処理しなければなりません。場合により、プロセスの保存や、操作の取り消しなどの処理が含まれます。この方法で終了したPodは`completions`数にカウントされません。
 
-An example Job definition in the suspended state can be like so:
+下記は一時停止状態のままで作成されたJobの定義例になります:
 
 ```shell
 kubectl get job myjob -o yaml
@@ -476,8 +426,7 @@ spec:
       ...
 ```
 
-The Job's status can be used to determine if a Job is suspended or has been
-suspended in the past:
+Jobのstatusセクションで、Jobが停止中なのか、過去に停止したことがあるかを判断できます:
 
 ```shell
 kubectl get jobs/myjob -o yaml
@@ -496,13 +445,9 @@ status:
   startTime: "2021-02-05T13:13:48Z"
 ```
 
-The Job condition of type "Suspended" with status "True" means the Job is
-suspended; the `lastTransitionTime` field can be used to determine how long the
-Job has been suspended for. If the status of that condition is "False", then the
-Job was previously suspended and is now running. If such a condition does not
-exist in the Job's status, the Job has never been stopped.
+Jobのcondition.typeが"Suspended"で、statusが"True"になった場合、Jobは一時停止中になります。`lastTransitionTime`フィールドで、どのぐらい中断されたかを判断できます。statusが"False"になった場合、Jobは一時停止状態でしたが、今は実行されていることになります。conditionが書いていない場合、Jobは一度も停止していないことになります。
 
-Events are also created when the Job is suspended and resumed:
+Jobが一時停止して再開した場合、Eventsも作成されます:
 
 ```shell
 kubectl describe jobs/myjob
@@ -521,12 +466,9 @@ Events:
   Normal  Resumed           3s    job-controller  Job resumed
 ```
 
-The last four events, particularly the "Suspended" and "Resumed" events, are
-directly a result of toggling the `.spec.suspend` field. In the time between
-these two events, we see that no Pods were created, but Pod creation restarted
-as soon as the Job was resumed.
+最後の4つのイベント、特に"Suspended"と"Resumed"のイベントは、`.spec.suspend`フィールドの値が変更されまくったために発生したものになります。この2つのイベントの間に、Podは作成されていないですが、Jobが再開された瞬間に、Podの作成も再開されました。
 
-### Mutable Scheduling Directives
+### Mutable Scheduling Directives  {#mutable-scheduling-directives}
 
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
@@ -552,7 +494,7 @@ been unsuspended before.
 The fields in a Job's pod template that can be updated are node affinity, node selector, 
 tolerations, labels and annotations.
 
-### Specifying your own Pod selector　｛#specifying-your-own-pod-selector｝
+### Specifying your own Pod selector  {#specifying-your-own-pod-selector}
 
 Normally, when you create a Job object, you do not specify `.spec.selector`.
 The system defaulting logic adds this field when the Job is created.
@@ -621,7 +563,7 @@ The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010
 `manualSelector: true` tells the system that you know what you are doing and to allow this
 mismatch.
 
-### Job tracking with finalizers
+### Job tracking with finalizers  {#job-tracking-with-finalizers}
 
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
@@ -662,16 +604,16 @@ controller is tracking a Job using Pod finalizers by checking if the Job has the
 annotation `batch.kubernetes.io/job-tracking`. You should **not** manually add
 or remove this annotation from Jobs.
 
-## Alternatives
+## Alternatives  {#alternatives}
 
-### Bare Pods
+### Bare Pods  {#bare-pods}
 
 When the node that a Pod is running on reboots or fails, the pod is terminated
 and will not be restarted.  However, a Job will create new Pods to replace terminated ones.
 For this reason, we recommend that you use a Job rather than a bare Pod, even if your application
 requires only a single Pod.
 
-### Replication Controller
+### Replication Controller  {#replication-controller}
 
 Jobs are complementary to [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/).
 A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job
@@ -681,7 +623,7 @@ As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `
 for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
 (Note: If `RestartPolicy` is not set, the default value is `Always`.)
 
-### Single Job starts controller Pod
+### Single Job starts controller Pod  {#single-job-starts-controller-pod}
 
 Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
 of custom controller for those Pods.  This allows the most flexibility, but may be somewhat

From ffe2ea0b33e8d9994024fb8a100d77df14cf072f Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:24:14 +0900
Subject: [PATCH 030/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ed765c862dbbd..4a0b98f3a9761 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -198,7 +198,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 3. *ワークキュー*を利用した並列Job:
    - `.spec.completions`の指定をしない場合、デフォルトは`.spec.parallelism`となります。
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
-   - 各Podは他のPodが完了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
+   - 各Podは他のPodがすべて終了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
    - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
    - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは成功終了とみなされます。
    - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。

From d1950b7f95d60ce4ecaab5dd95ef609cc0121940 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:24:34 +0900
Subject: [PATCH 031/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 4a0b98f3a9761..0eea9961b736a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -199,7 +199,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
    - `.spec.completions`の指定をしない場合、デフォルトは`.spec.parallelism`となります。
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
    - 各Podは他のPodがすべて終了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
-   - Jobに属する _任意_ のPodが成功に終了すると、新しいPodは作成されません。
+   - Jobに属する _任意_ のPodが正常に終了すると、新しいPodは作成されません。
    - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは成功終了とみなされます。
    - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
 

From 2683432b0acf88ac146ce51fefc06a4ccf58098e Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:24:48 +0900
Subject: [PATCH 032/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 0eea9961b736a..d2ae2e1a9409c 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -200,7 +200,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
    - Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
    - 各Podは他のPodがすべて終了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
    - Jobに属する _任意_ のPodが正常に終了すると、新しいPodは作成されません。
-   - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは成功終了とみなされます。
+   - 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは正常に完了します。
    - 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
 
  _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。

From 1ac5e895f2890ed438136a8e88864b2335e5af04 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:25:06 +0900
Subject: [PATCH 033/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index d2ae2e1a9409c..1346594572258 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -210,7 +210,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
  _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
 
-各種類Jobの利用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
+各種類のJobの使用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
 
 #### 並列処理の制御  {#controlling-parallelism}
 

From ce99d1da90e3f490ca01aa0ef79a6b65cffb5400 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:25:24 +0900
Subject: [PATCH 034/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 1346594572258..855fb9c9b3d2e 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -216,7 +216,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
 未設定の場合は、デフォルトで1になります。
-0に設定した際に、増加するまでJobは一時停止されます。
+0に設定した際には、増加するまでJobは一時停止されます。
 
 実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
 

From bb7c0caacc306655437fdb9851654d6f64319745 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:25:43 +0900
Subject: [PATCH 035/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 855fb9c9b3d2e..1f61c4884b3cc 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -218,7 +218,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 未設定の場合は、デフォルトで1になります。
 0に設定した際には、増加するまでJobは一時停止されます。
 
-実際並列数（任意時点で実行されているPod数）は下記の理由により、必要並列数と異なる可能性があります：
+実際の並列数(任意の瞬間に実行されているPod数)は、さまざまな理由により、必要並列数と異なる可能性があります:
 
 -  _完了数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 -  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。

From 6ce819f019cbc847ec03f6d1460f2dd9f3664f80 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:25:59 +0900
Subject: [PATCH 036/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 1f61c4884b3cc..1f3b492095271 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -222,7 +222,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 -  _完了数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 -  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
-- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合
+- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合。
 - Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
   実際並列数は必要並列数より少なくなる可能性があります。
 - 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。

From 8e79687142d8b66858e6f6fbf0aa9f3f97837730 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:26:16 +0900
Subject: [PATCH 037/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 1f3b492095271..9ee1340b8e2cb 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -223,8 +223,8 @@ Jobで実行するのに適したタスクは主に3種類あります:
 -  _完了数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 -  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
 - Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合。
-- Jobコントローラーは何らかの理由で（`ResourceQuota`の不足、権限の不足など）、Podを作成できない場合、
-  実際並列数は必要並列数より少なくなる可能性があります。
+- Jobコントローラーが何らかの理由で(`ResourceQuota`の不足、権限の不足など)、Podを作成できない場合、
+  実際の並列数は必要並列数より少なくなる可能性があります。
 - 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
 - Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
 

From e1bb80456f7ad61aba7cdbd239b78aab3f46f08b Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:26:33 +0900
Subject: [PATCH 038/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9ee1340b8e2cb..7fee34da46041 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -225,7 +225,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 - Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合。
 - Jobコントローラーが何らかの理由で(`ResourceQuota`の不足、権限の不足など)、Podを作成できない場合、
   実際の並列数は必要並列数より少なくなる可能性があります。
-- 同じJobでのPod障害が多すぎる場合、Jobコントローラーは新しいPodの作成を抑制する可能性はあります。
+- 同じJobで過去に発生した過度のPod障害が原因で、Jobコントローラーは新しいPodの作成を抑制することがあります。
 - Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
 
 ### 完了モード  {#completion-mode}

From afc9caf3ab745b92f292e0934ff7b9b00a342ae9 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 12 Jul 2022 19:27:11 +0900
Subject: [PATCH 039/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 7fee34da46041..5c341fedf5d7e 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -191,7 +191,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 1. 非並列Job
    - 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
    - Podが正常に終了すると、Jobはすぐに完了します。
-2. *一定の完了数*が決められた並列Job：
+2. *固定の完了数*を持つ並列Job:
    - `.spec.completions`に0以外の正の値を指定します。
    - Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
    - `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスがアサインされます。

From 7ea4b05783a6939194706b0de366495811aaa913 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:20:15 +0900
Subject: [PATCH 040/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 5c341fedf5d7e..3ff6e73a24271 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -249,7 +249,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
 `restartPolicy`の詳細については[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
 
-Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定したPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションが新しいPodの再起動処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
+Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定されたときにPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションは新しいPodで再起動された場合の処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
 
 `.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
 

From 6879c3e2ebf3746df12d44f972a8b1433b090c17 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:21:07 +0900
Subject: [PATCH 041/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 3ff6e73a24271..a0f290217ad08 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -257,7 +257,7 @@ Podがノードからキックされた（ノードがアップグレード、
 
 ### Pod失敗のバックオフポリシー  {#pod-backoff-failure-policy}
 
-設定の論理エラーなどにより、Jobが数回再試行しても失敗するとそのまま終了状態に進んでほしい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属する失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。Jobに属するPodが削除された場合、または一つのPodが成功した時に、同じJobに属する他のPodがその時点で失敗していない場合に、バックオフ数はリセットされます。
+設定の論理エラーなどにより、Jobが数回再試行した後に失敗状態にしたい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属していて失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。
 
 {{< note >}}
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。

From 3b88e3b68a2e7e5642a92add1ee05364d3f744c0 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:23:29 +0900
Subject: [PATCH 042/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index a0f290217ad08..05a06a4241b6c 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -260,7 +260,7 @@ Podがノードからキックされた（ノードがアップグレード、
 設定の論理エラーなどにより、Jobが数回再試行した後に失敗状態にしたい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属していて失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。
 
 {{< note >}}
-`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定するほうがオススメです。
+`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。
 {{< /note >}}
 
 ## Jobの終了と後片付け  {#job-termination-and-cleanup}

From b0c83756d8e352bf721dff57dec9bd3baf6f8733 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:23:59 +0900
Subject: [PATCH 043/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 05a06a4241b6c..7c4c7e44719d2 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -205,7 +205,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
  _非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
 
- _完了数一定_ 並列Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
+ _完了数固定_ Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
 `.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
 
  _ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。

From 9f7d2854731e5d533424cd0b7e6ae843ed80af68 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:24:20 +0900
Subject: [PATCH 044/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 7c4c7e44719d2..f0e3e9873fbe9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -220,7 +220,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 実際の並列数(任意の瞬間に実行されているPod数)は、さまざまな理由により、必要並列数と異なる可能性があります:
 
--  _完了数一定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
+-  _完了数固定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
 -  _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
 - Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合。
 - Jobコントローラーが何らかの理由で(`ResourceQuota`の不足、権限の不足など)、Podを作成できない場合、

From 667fef0ac3f3cad9bee445917538b277ad7353d7 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:24:34 +0900
Subject: [PATCH 045/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index f0e3e9873fbe9..aaf7acad90ac1 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -232,7 +232,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
- _完了数一定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
+ _完了数固定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
 
 - `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。

From cea96d188b1b8e6719d9bc93aa276b333dd4a12c Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:24:49 +0900
Subject: [PATCH 046/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index aaf7acad90ac1..b894f6375e62e 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -234,7 +234,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
  _完了数固定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
 
-- `NonIndexed`（デフォルト）：　`.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
+- `NonIndexed`(デフォルト): `.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
   - Podアノテーション`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。

From 4dd23519f4ec00377febeaf28ef6845f34f4230e Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:25:32 +0900
Subject: [PATCH 047/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index b894f6375e62e..69fa312776323 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -235,7 +235,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
  _完了数固定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
 
 - `NonIndexed`(デフォルト): `.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
-- `Indexed`： Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
+- `Indexed`: Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
   - Podアノテーション`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。

From 2bc0d84a766dd297b90a1fd034784dbc120ab2bd Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:27:11 +0900
Subject: [PATCH 048/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 69fa312776323..3dfdf78eba1c9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -237,7 +237,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 - `NonIndexed`(デフォルト): `.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`: Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
   - Podアノテーション`batch.kubernetes.io/job-completion-index`。
-  - Podホスト名の一部として、`$(job-name)-$(index)`と書きます。
+  - Podホスト名の一部として、`$(job-name)-$(index)`の形式になっています。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
 

From a88e0060e452af756cd35d550332410019d5228c Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 14 Jul 2022 17:28:04 +0900
Subject: [PATCH 049/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 3dfdf78eba1c9..51f96244d7984 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -239,7 +239,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
   - Podアノテーション`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`の形式になっています。
     インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
-  - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`で定義します。
+  - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`。
 
   インデックスごとに、成功したPodが一つ存在すると、Jobの完了となります。完了モードの使用方法の詳細については、
   [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完了数にカウントされるのはそのうちの一つだけです。

From b1881454c171d6bfcefc756ddb121a429b2ce5a1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Thu, 28 Jul 2022 00:51:46 +0000
Subject: [PATCH 050/110] Translate docs/concepts/workloads/controllers/job.md
 into Japanese(Line 471-595)

---
 .../concepts/workloads/controllers/job.md     | 179 ++++++------------
 1 file changed, 60 insertions(+), 119 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 51f96244d7984..3f503f1facd78 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -313,7 +313,7 @@ Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts
 終了したJob(状態は`Complete`か`Failed`になったJob)を自動的に片付けるもう一つの方法は
 [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースを片付けることができます。
 
-TTLコントローラーでJobを片付ける場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Jobのライフサイクル保証、例えばFinalizersなど、は考えられるので注意してください。
+TTLコントローラーでJobを片付ける場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Jobのライフサイクル保証、例えばFinalizerなど、は考えられるので注意してください。
 
 例えば:
 
@@ -468,64 +468,41 @@ Events:
 
 最後の4つのイベント、特に"Suspended"と"Resumed"のイベントは、`.spec.suspend`フィールドの値が変更されまくったために発生したものになります。この2つのイベントの間に、Podは作成されていないですが、Jobが再開された瞬間に、Podの作成も再開されました。
 
-### Mutable Scheduling Directives  {#mutable-scheduling-directives}
+### 可変スケジューリング命令  {#mutable-scheduling-directives}
 
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
 {{< note >}}
-In order to use this behavior, you must enable the `JobMutableNodeSchedulingDirectives`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/).
-It is enabled by default.
+この機能を使うためには、[APIサーバー](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)上で`JobMutableNodeSchedulingDirectives`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
+デフォルトで有効になっています。
 {{< /note >}}
 
-In most cases a parallel job will want the pods to run with constraints, 
-like all in the same zone, or all either on GPU model x or y but not a mix of both.
+ほとんどの場合、並列Jobは、すべてのPodが同じゾーンで実行される、またはすべてGPUモデルxかyのいずれかで実行され、両方を混在されることがない、などの制約を持って実行することを望みます。
 
-The [suspend](#suspending-a-job) field is the first step towards achieving those semantics. Suspend allows a 
-custom queue controller to decide when a job should start; However, once a job is unsuspended,
-a custom queue controller has no influence on where the pods of a job will actually land.
+[suspend](#suspending-a-job)フィールドは、これらの機能を実現するための第一歩です。Suspendはキューコントローラーをカスタマイズすることにより、作業の開始時間を決定することができます；しかし、Jobの一時停止が解除されると、カスタムキューコントローラーは、Job内のPodの実際の配置場所には影響を与えません。
 
-This feature allows updating a Job's scheduling directives before it starts, which gives custom queue
-controllers the ability to influence pod placement while at the same time offloading actual 
-pod-to-node assignment to kube-scheduler. This is allowed only for suspended Jobs that have never 
-been unsuspended before.
+この機能により、Jobが開始される前にスケジューリング命令を更新でき、カスタムキューコントローラーががPodの配置に影響を与えることができると同時に、実際のPodとノードの割り当てをkube-schedulerにオフロードすることができます。これは一時停止されたJobの中で、一度も一時停止解除されたことのないJobに対してのみ許可されます。
 
-The fields in a Job's pod template that can be updated are node affinity, node selector, 
-tolerations, labels and annotations.
+JobのPodテンプレートで更新可能なフィールドはnodeAffinity、nodeSelector、tolerations、labelsとannotationsになります。 
 
-### Specifying your own Pod selector  {#specifying-your-own-pod-selector}
+### 自分のPodセレクターを指定  {#specifying-your-own-pod-selector}
 
-Normally, when you create a Job object, you do not specify `.spec.selector`.
-The system defaulting logic adds this field when the Job is created.
-It picks a selector value that will not overlap with any other jobs.
+Jobオブジェクトを作成する際には通常、`.spec.selector`を指定しません。Jobが作成された際に、システムのデフォルトロジックは、他のJobと重ならないようなセレクタの値を選択し、このフィールドに追加します。
 
-However, in some cases, you might need to override this automatically set selector.
-To do this, you can specify the `.spec.selector` of the Job.
+しかし、場合によっては、この自動設定されたセレクタをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 
-Be very careful when doing this.  If you specify a label selector which is not
-unique to the pods of that Job, and which matches unrelated Pods, then pods of the unrelated
-job may be deleted, or this Job may count other Pods as completing it, or one or both
-Jobs may refuse to create Pods or run to completion.  If a non-unique selector is
-chosen, then other controllers (e.g. ReplicationController) and their Pods may behave
-in unpredictable ways too.  Kubernetes will not stop you from making a mistake when
-specifying `.spec.selector`.
+その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクタを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、一方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
+一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属されたPodも予測できない挙動をする可能性があります。`.spec.selector`を間違って設定しても、Kubernetesはエラーメッセージは出ません。
 
-Here is an example of a case when you might want to use this feature.
+下記はこの機能の使用例を紹介しています。
 
-Say Job `old` is already running.  You want existing Pods
-to keep running, but you want the rest of the Pods it creates
-to use a different pod template and for the Job to have a new name.
-You cannot update the Job because these fields are not updatable.
-Therefore, you delete Job `old` but _leave its pods
-running_, using `kubectl delete jobs/old --cascade=orphan`.
-Before deleting it, you make a note of what selector it uses:
+`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしいですが、次に新しく作成されたPodは別のテンプレートを使用したい、Job名も変更したいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属するPodが実行されたまま_、`old`Jobを削除しました。削除する前に、どのセレクタを使用しているかについて調べました:
 
 ```shell
 kubectl get job old -o yaml
 ```
 
-The output is similar to this:
+出力結果はこのようになります:
 
 ```yaml
 kind: Job
@@ -539,12 +516,9 @@ spec:
   ...
 ```
 
-Then you create a new Job with name `new` and you explicitly specify the same selector.
-Since the existing Pods have label `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`,
-they are controlled by Job `new` as well.
+次に、`new`という名前で新しくJobを作成し、同じセレクタを指定しました。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされることができます。
 
-You need to specify `manualSelector: true` in the new Job since you are not using
-the selector that the system normally generates for you automatically.
+通常システムが自動的に生成するセレクタを使用しないため、新しいJobで `manualSelector: true`を指定する必要があります。
 
 ```yaml
 kind: Job
@@ -559,96 +533,63 @@ spec:
   ...
 ```
 
-The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`.  Setting
-`manualSelector: true` tells the system that you know what you are doing and to allow this
-mismatch.
+新しいJobは`a8f3d00d-c6d2-11e5-9f87-42010af00002`ではなく、別のuid を持つことになります。`manualSelector: true`を設定することで、自分は何をしているかを知っていて、またこのミスマッチを許容することをシステムに伝えます。
 
-### Job tracking with finalizers  {#job-tracking-with-finalizers}
+### FinalizerによるJob追跡  {#job-tracking-with-finalizers}
 
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
 {{< note >}}
-In order to use this behavior, you must enable the `JobTrackingWithFinalizers`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/)
-and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
-It is enabled by default.
-
-When enabled, the control plane tracks new Jobs using the behavior described
-below. Jobs created before the feature was enabled are unaffected. As a user,
-the only difference you would see is that the control plane tracking of Job
-completion is more accurate.
+この機能を使うためには、[APIサーバー](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)で`JobTrackingWithFinalizers`
+[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
+デフォルトで有効になっています。
+
+有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして、唯一に実感できる違いは、コントロールプレーンのJob完了ステータス追跡はより正確になったということです。
 {{< /note >}}
 
-When this feature isn't enabled, the Job {{< glossary_tooltip term_id="controller" >}}
-relies on counting the Pods that exist in the cluster to track the Job status,
-that is, to keep the counters for `succeeded` and `failed` Pods.
-However, Pods can be removed for a number of reasons, including:
-- The garbage collector that removes orphan Pods when a Node goes down.
-- The garbage collector that removes finished Pods (in `Succeeded` or `Failed`
-  phase) after a threshold.
-- Human intervention to delete Pods belonging to a Job.
-- An external controller (not provided as part of Kubernetes) that removes or
-  replaces Pods.
-
-If you enable the `JobTrackingWithFinalizers` feature for your cluster, the
-control plane keeps track of the Pods that belong to any Job and notices if any
-such Pod is removed from the API server. To do that, the Job controller creates Pods with
-the finalizer `batch.kubernetes.io/job-tracking`. The controller removes the
-finalizer only after the Pod has been accounted for in the Job status, allowing
-the Pod to be removed by other controllers or users.
-
-The Job controller uses the new algorithm for new Jobs only. Jobs created
-before the feature is enabled are unaffected. You can determine if the Job
-controller is tracking a Job using Pod finalizers by checking if the Job has the
-annotation `batch.kubernetes.io/job-tracking`. You should **not** manually add
-or remove this annotation from Jobs.
-
-## Alternatives  {#alternatives}
-
-### Bare Pods  {#bare-pods}
-
-When the node that a Pod is running on reboots or fails, the pod is terminated
-and will not be restarted.  However, a Job will create new Pods to replace terminated ones.
-For this reason, we recommend that you use a Job rather than a bare Pod, even if your application
-requires only a single Pod.
+この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスタ内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンタを保持します。
+しかし、Podは以下のように削除されることもあります:
+- Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクター二より削除されます。
+- 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクター二より削除されます。 
+- 人為的にJobに属するPodを削除します。
+- 外部コントローラー(Kubernetesの一部として提供されていない)よりPodを削除したり置き換えたりします。
+
+クラスタで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーにより作成されたPodは`batch.kubernetes.io/job-tracking`Finalizerを持っています。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
+
+Jobコントローラーは、新しいJobに対してのみ新しいアルゴリズムを使用します。この機能が有効になる前に作成されたJobは影響を受けません。JobコントローラーがPod FinalizerでJob追跡しているかどうかは、Jobが`batch.kubernetes.io/job-tracking`というアノテーションを持っているかどうかで判断できます。
+このアノテーションを手動で追加または削除しては**いけません**。
+
+## 代替案  {#alternatives}
+
+### 単なるPod  {#bare-pods}
+
+Podが動作しているノードが再起動または故障した場合、Podは終了し、再起動されません。しかし、終了したPodを置き換えるため、Jobが新しいPodを作成します。このため、たとえアプリケーションが1つのPodしか必要としない場合でも、単なるPodではなくJobを使用することをお勧めします。 
 
 ### Replication Controller  {#replication-controller}
 
-Jobs are complementary to [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/).
-A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job
-manages Pods that are expected to terminate (e.g. batch tasks).
+Jobsは[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)を補完するものです。
+Replication Controllerは、終了することが想定されていないPod(Webサーバーなど)を管理し、Jobは終了することが想定されているPod(バッチタスクなど)を管理します。
+
+[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`か`Never`と設定されているPodに*のみ*適用されます。(注意:`RestartPolicy`が設定されていない場合、デフォルト値は`Always`になります)
+
 
-As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` is *only* appropriate
-for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
-(Note: If `RestartPolicy` is not set, the default value is `Always`.)
+### シングルJobによるコントローラーPodの起動  {#single-job-starts-controller-pod}
 
-### Single Job starts controller Pod  {#single-job-starts-controller-pod}
+もう一つのパターンは、一つのJobが一つPodを作り、そのPodがカスタムコントローラーのような役割を果たし、他のPodを作ります。これは最も柔軟性がありますが、使い始めるにはやや複雑で、Kubernetesとの統合もあまりできません。
 
-Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
-of custom controller for those Pods.  This allows the most flexibility, but may be somewhat
-complicated to get started with and offers less integration with Kubernetes.
+このパターンの一例としては、Sparkマスターコントローラーを起動するスクリプトがあり、そのスクリプトを実行するPodをJobで起動し、([spark事例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)、sparkドライバーを実行して片付ける、ということが挙げられます。
 
-One example of this pattern would be a Job which starts a Pod which runs a script that in turn
-starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), runs a spark
-driver, and then cleans up.
 
-An advantage of this approach is that the overall process gets the completion guarantee of a Job
-object, but maintains complete control over what Pods are created and how work is assigned to them.
+この方法のメリットは、Jobオブジェクトで実行されているので、プロセスが完了する保障があると同時に、どのPodを作成し、どのように仕事を割り当てるかを完全に制御できることです。
 
 ## {{% heading "whatsnext" %}}
 
-* Learn about [Pods](/docs/concepts/workloads/pods).
-* Read about different ways of running Jobs:
-   * [Coarse Parallel Processing Using a Work Queue](/docs/tasks/job/coarse-parallel-processing-work-queue/)
-   * [Fine Parallel Processing Using a Work Queue](/docs/tasks/job/fine-parallel-processing-work-queue/)
-   * Use an [indexed Job for parallel processing with static work assignment](/docs/tasks/job/indexed-parallel-processing-static/) (beta)
-   * Create multiple Jobs based on a template: [Parallel Processing using Expansions](/docs/tasks/job/parallel-processing-expansion/)
-* Follow the links within [Clean up finished jobs automatically](#clean-up-finished-jobs-automatically)
-  to learn more about how your cluster can clean up completed and / or failed tasks.
-* `Job` is part of the Kubernetes REST API.
-  Read the {{< api-reference page="workload-resources/job-v1" >}}
-  object definition to understand the API for jobs.
-* Read about [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/), which you
-  can use to define a series of Jobs that will run based on a schedule, similar to
-  the UNIX tool `cron`.
+* [Pods](/ja/docs/concepts/workloads/pods/)について学ぶ。
+* Jobのさまざまな実行方法について学ぶ:
+   * [ワークキューを用いた粒度の粗い並列処理](/docs/tasks/job/coarse-parallel-processing-work-queue/)
+   * [ワークキューを用いた粒度の粗い並列処理](/docs/tasks/job/fine-parallel-processing-work-queue/)
+   * [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/) を使う(beta段階)
+   * テンプレートを元に複数のJobを作成: [拡張機能を用いた並列処理](/docs/tasks/job/parallel-processing-expansion/)
+* [終了したJobの自動片付け](#clean-up-finished-jobs-automatically)のリンクから、クラスタが完了または失敗したJobをどのように片付けるかをご確認ください。
+* `Job`はKubernetes REST APIの一部です。Job APIを理解するために、{{< api-reference page="workload-resources/job-v1" >}}オブジェクトの定義をお読みください。
+* UNIXツールの`cron`と同様に、スケジュールに基づいて実行される一連のJobを定義するために使用できる[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)についてお読みください。

From 822c6c628c1fd5209d1225d08d0a8b833f546be7 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Thu, 28 Jul 2022 23:41:33 +0000
Subject: [PATCH 051/110] Synchronize with the original text

---
 content/ja/docs/concepts/workloads/controllers/job.md | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 3f503f1facd78..1c0a06ffeb2cf 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -61,7 +61,7 @@ Pod Template:
            job-name=pi
   Containers:
    pi:
-    Image:      perl
+    Image:      perl:5.34.0
     Port:       <none>
     Host Port:  <none>
     Command:
@@ -115,7 +115,7 @@ spec:
         - -Mbignum=bpi
         - -wle
         - print bpi(2000)
-        image: perl
+        image: perl:5.34.0
         imagePullPolicy: Always
         name: pi
         resources: {}
@@ -292,7 +292,7 @@ spec:
     spec:
       containers:
       - name: pi
-        image: perl
+        image: perl:5.34.0
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
 ```
@@ -328,7 +328,7 @@ spec:
     spec:
       containers:
       - name: pi
-        image: perl
+        image: perl:5.34.0
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
 ```
@@ -542,7 +542,6 @@ spec:
 {{< note >}}
 この機能を使うためには、[APIサーバー](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)で`JobTrackingWithFinalizers`
 [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
-デフォルトで有効になっています。
 
 有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして、唯一に実感できる違いは、コントロールプレーンのJob完了ステータス追跡はより正確になったということです。
 {{< /note >}}

From cf799b5ee86a0e50d719b82c563b607b6f95eb89 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 08:52:20 +0900
Subject: [PATCH 052/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 1c0a06ffeb2cf..45f444bf65b1a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -246,7 +246,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 ## Podとコンテナの障害対策  {#handling-pod-and-container-failures}
 
-Pod内のコンテナは、その中のプロセスは0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナは強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
+Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナが強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
 `restartPolicy`の詳細については[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
 
 Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定されたときにPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションは新しいPodで再起動された場合の処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。

From 02c970865c38a50306e15f6977abe331cf923cfc Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 08:52:40 +0900
Subject: [PATCH 053/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 45f444bf65b1a..141b196ad27d6 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -249,7 +249,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナが強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
 `restartPolicy`の詳細については[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
 
-Podがノードからキックされた（ノードがアップグレード、再起動、削除されたなど）、または`.spec.template.spec.restartPolicy = "Never"`と設定されたときにPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションは新しいPodで再起動された場合の処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
+Podがノードからキックされた(ノードがアップグレード、再起動、削除されたなど)、または`.spec.template.spec.restartPolicy = "Never"`と設定されたときにPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションは新しいPodで再起動された場合の処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
 
 `.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
 

From bb1f2b245a17a211757ca62f28611d65ecb82a66 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 08:53:02 +0900
Subject: [PATCH 054/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 141b196ad27d6..1ee2a28f34789 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -257,7 +257,7 @@ Podがノードからキックされた(ノードがアップグレード、再
 
 ### Pod失敗のバックオフポリシー  {#pod-backoff-failure-policy}
 
-設定の論理エラーなどにより、Jobが数回再試行した後に失敗状態にしたい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属していて失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し（10秒、20秒、40秒…）、最大6分まで増加します。
+設定の論理エラーなどにより、Jobが数回再試行した後に失敗状態にしたい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属していて失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し(10秒、20秒、40秒…)、最大6分まで増加します。
 
 {{< note >}}
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。

From 8e211eb97b5cf8ec04c7bcda86c25801ef36476e Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:23:59 +0900
Subject: [PATCH 055/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 1ee2a28f34789..e5768a7525498 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -267,7 +267,7 @@ Podがノードからキックされた(ノードがアップグレード、再
 
 Jobが完了すると、それ以上Podは作成されませんが、[通常](#pod-backoff-failure-policy)Podが削除されることもありません。
 これらを残しておくと、完了したPodのログを確認でき、エラーや警告などの診断出力を確認できます。
-またJobオブジェクトはJob終了後も残し、状態を確認することができます。古いJobの状態を把握した上で、削除するかどうかはユーザー次第です。Jobを削除するには`kubectl` (例：`kubectl delete jobs/pi`または`kubectl delete -f ./job.yaml`)を使います。`kubectl`でJobを削除する場合、Jobが作成したPodも全部削除されます。
+またJobオブジェクトはJob完了後も残っているため、状態を確認することができます。古いJobの状態を把握した上で、削除するかどうかはユーザー次第です。Jobを削除するには`kubectl` (例：`kubectl delete jobs/pi`または`kubectl delete -f ./job.yaml`)を使います。`kubectl`でJobを削除する場合、Jobが作成したPodも全部削除されます。
 
 デフォルトでは、Jobは中断されることなく実行できますが、Podが失敗した場合(`restartPolicy=Never`)、またはコンテナがエラーで終了した場合(`restartPolicy=OnFailure`)のみ、前述の`.spec.backoffLimit`で決まった回数まで再試行します。`.spec.backoffLimit`に達すると、Jobが失敗とマークされ、実行中のPodもすべて終了されます。
 

From 8182534a318d798298cb45353e509d69302f35af Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:24:35 +0900
Subject: [PATCH 056/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index e5768a7525498..6d8e31385c132 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -272,7 +272,7 @@ Jobが完了すると、それ以上Podは作成されませんが、[通常](#p
 デフォルトでは、Jobは中断されることなく実行できますが、Podが失敗した場合(`restartPolicy=Never`)、またはコンテナがエラーで終了した場合(`restartPolicy=OnFailure`)のみ、前述の`.spec.backoffLimit`で決まった回数まで再試行します。`.spec.backoffLimit`に達すると、Jobが失敗とマークされ、実行中のPodもすべて終了されます。
 
 Jobを終了させるもう一つの方法は、活動期間を設定することです。
-Jobの`.spec.activeDeadlineSeconds`フォールドに秒数を設定することで、活動期間を設定できます。
+Jobの`.spec.activeDeadlineSeconds`フィールドに秒数を設定することで、活動期間を設定できます。
 Podがいくつ作成されても、`activeDeadlineSeconds`はJobの存続する時間に適用されます。
 Jobが`activeDeadlineSeconds`に達すると、実行中のすべてのPodは終了され、Jobの状態は`type: Failed`になり、理由は`reason: DeadlineExceeded`になります。
 

From 986082e72b4748b6323146d3160b013489aad831 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:26:17 +0900
Subject: [PATCH 057/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 6d8e31385c132..be2b9e45915e9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -304,7 +304,7 @@ Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts
 
 ## 終了したJobの自動片付け  {#clean-up-finished-jobs-automatically}
 
-終了したJobは通常システムに残す必要はありません。残ったままにしておくとAPIサーバーに負担をかけることになります。Jobが上位コントローラーにより直接管理されている場合、例えば[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)の場合、Jobは指定された容量ベースの片付けポリシーに基づき、CronJobにより片付けられます。
+終了したJobは通常システムに残す必要はありません。残ったままにしておくとAPIサーバーに負担をかけることになります。Jobが上位コントローラーにより直接管理されている場合、例えば[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)の場合、Jobは指定された容量ベースのクリーンアップポリシーに基づき、CronJobによりクリーンアップされます。
 
 ### 終了したJobのTTLメカニズム  {#ttl-mechanism-for-finished-jobs}
 

From 9a07de2ffbbd4b033be45727510b208e86617e03 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:26:37 +0900
Subject: [PATCH 058/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index be2b9e45915e9..ab8d22bcaeb3b 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -310,7 +310,7 @@ Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts
 
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 
-終了したJob(状態は`Complete`か`Failed`になったJob)を自動的に片付けるもう一つの方法は
+終了したJob(状態が`Complete`か`Failed`になったJob)を自動的にクリーンアップするもう一つの方法は
 [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースを片付けることができます。
 
 TTLコントローラーでJobを片付ける場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Jobのライフサイクル保証、例えばFinalizerなど、は考えられるので注意してください。

From 66a66d65e2bbda1e0b69519d76e8d9c617863c82 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:26:47 +0900
Subject: [PATCH 059/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ab8d22bcaeb3b..68565db99a7b8 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -311,7 +311,7 @@ Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 
 終了したJob(状態が`Complete`か`Failed`になったJob)を自動的にクリーンアップするもう一つの方法は
-[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースを片付けることができます。
+[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースをクリーンアップすることができます。
 
 TTLコントローラーでJobを片付ける場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Jobのライフサイクル保証、例えばFinalizerなど、は考えられるので注意してください。
 

From 2a5e9a8a310c5d03c0a0559ce95c6ce364bbdc7d Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:27:09 +0900
Subject: [PATCH 060/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 68565db99a7b8..3988fca067411 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -263,7 +263,7 @@ Podがノードからキックされた(ノードがアップグレード、再
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。
 {{< /note >}}
 
-## Jobの終了と後片付け  {#job-termination-and-cleanup}
+## Jobの終了とクリーンアップ  {#job-termination-and-cleanup}
 
 Jobが完了すると、それ以上Podは作成されませんが、[通常](#pod-backoff-failure-policy)Podが削除されることもありません。
 これらを残しておくと、完了したPodのログを確認でき、エラーや警告などの診断出力を確認できます。

From c85bd7af44ec09ee12fb53c59f3855995944de62 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:27:27 +0900
Subject: [PATCH 061/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 3988fca067411..310fd1b44af8a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -299,7 +299,7 @@ spec:
 
 Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)は両方とも`activeDeadlineSeconds`フィールドを持っているので注意してください。適切なレベルで設定していることを確認してください。
 
-また`restartPolicy`はJob自体ではなく、Podに適用されることも注意してください: Jobの状態は`type: Failed`になると、自動的再起動されることはありません。
+また`restartPolicy`はJob自体ではなく、Podに適用されることも注意してください: Jobの状態は`type: Failed`になると、自動的に再起動されることはありません。
 つまり、`.spec.activeDeadlineSeconds`と`.spec.backoffLimit`によって引き起こされるJob終了メカニズムは、永久的なJob失敗につながり、手動で介入して解決する必要があります。
 
 ## 終了したJobの自動片付け  {#clean-up-finished-jobs-automatically}

From 339028306eb047bd3679eb204c8a66f35c1b1f78 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:27:43 +0900
Subject: [PATCH 062/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 310fd1b44af8a..4cd6e08879640 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -302,7 +302,7 @@ Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts
 また`restartPolicy`はJob自体ではなく、Podに適用されることも注意してください: Jobの状態は`type: Failed`になると、自動的に再起動されることはありません。
 つまり、`.spec.activeDeadlineSeconds`と`.spec.backoffLimit`によって引き起こされるJob終了メカニズムは、永久的なJob失敗につながり、手動で介入して解決する必要があります。
 
-## 終了したJobの自動片付け  {#clean-up-finished-jobs-automatically}
+## 終了したJobの自動クリーンアップ  {#clean-up-finished-jobs-automatically}
 
 終了したJobは通常システムに残す必要はありません。残ったままにしておくとAPIサーバーに負担をかけることになります。Jobが上位コントローラーにより直接管理されている場合、例えば[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)の場合、Jobは指定された容量ベースのクリーンアップポリシーに基づき、CronJobによりクリーンアップされます。
 

From c1e406395c24420eb2446596b0c50f4f180caf43 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:28:17 +0900
Subject: [PATCH 063/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 4cd6e08879640..32c25fb430f8a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -335,7 +335,7 @@ spec:
 
 Job`pi-with-ttl`は終了してからの`100`秒後に自動的に削除されるようになっています。
 
-このフィールドに`0`を設定すると、Jobは終了後すぐに削除されるようになります。このフィールドに何も設定しないと、Jobは終了してもTTLコントローラーより片付けられません。
+このフィールドに`0`を設定すると、Jobは終了後すぐに自動削除の対象になります。このフィールドに何も設定しないと、Jobが終了してもTTLコントローラーによるクリーンアップはされません。
 
 {{< note >}}
 `ttlSecondsAfterFinished`フィールドを設定することが推奨されます。管理されていないJob(CronJobなどの、他のワークロードAPIを経由せずに、直接作成したJob)は`orphanDependents`というデフォルトの削除ポリシーがあるため、Jobが完全に削除されても、属しているPodが残ってしまうからです。

From 5f4bb6597c995d5ec1003681a6ca6fdb0d384113 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:29:18 +0900
Subject: [PATCH 064/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 32c25fb430f8a..c78f070e03a0a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -339,7 +339,7 @@ Job`pi-with-ttl`は終了してからの`100`秒後に自動的に削除され
 
 {{< note >}}
 `ttlSecondsAfterFinished`フィールドを設定することが推奨されます。管理されていないJob(CronJobなどの、他のワークロードAPIを経由せずに、直接作成したJob)は`orphanDependents`というデフォルトの削除ポリシーがあるため、Jobが完全に削除されても、属しているPodが残ってしまうからです。
-{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスタのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスタがオフラインになることがあります。
+{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスターのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスターがオフラインになることがあります。
 
 [LimitRanges](/ja/docs/concepts/policy/limit-range/)と[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)で、指定する名前空間が消費できるリソースの量に上限を設定することができます。
 {{< /note >}}

From 56da3a4d90e723190375b2a7c8918bb15bb2199b Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Fri, 29 Jul 2022 09:30:12 +0900
Subject: [PATCH 065/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index c78f070e03a0a..24588c567c392 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -313,7 +313,7 @@ Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts
 終了したJob(状態が`Complete`か`Failed`になったJob)を自動的にクリーンアップするもう一つの方法は
 [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースをクリーンアップすることができます。
 
-TTLコントローラーでJobを片付ける場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Jobのライフサイクル保証、例えばFinalizerなど、は考えられるので注意してください。
+TTLコントローラーでJobをクリーンアップする場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Finalizerなどの、Jobのライフサイクル保証は守られることに注意してください。
 
 例えば:
 

From a037e22da3d5e597f21c71e7573a954df24059cf Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Fri, 29 Jul 2022 09:30:07 +0000
Subject: [PATCH 066/110] modified some typo

---
 .../concepts/workloads/controllers/job.md     | 33 ++++++++++++-------
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 24588c567c392..05df0f1b61cf9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -150,13 +150,13 @@ pi-5rwd7
 
 ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを指定するための表現です。
 
-その中の一つのPodの標準出力を確認するには：
+その中の一つのPodの標準出力を確認するには:
 
 ```shell
 kubectl logs $pods
 ```
 
-出力結果はこのようになります：
+出力結果はこのようになります:
 
 ```
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
@@ -232,7 +232,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
- _完了数固定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます：
+ _完了数固定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます:
 
 - `NonIndexed`(デフォルト): `.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
 - `Indexed`: Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
@@ -259,6 +259,15 @@ Podがノードからキックされた(ノードがアップグレード、再
 
 設定の論理エラーなどにより、Jobが数回再試行した後に失敗状態にしたい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属していて失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し(10秒、20秒、40秒…)、最大6分まで増加します。
 
+再実行回数の算出方法は以下の2通りです:
+- `.status.phase = "Failed"`で設定されたPod数を計算します。
+- `restartPolicy = "OnFailure"`と設定された場合、`.status.phase`が`Pending`または`Running`であるPodに属するすべてのコンテナで再試行する回数を計算します。
+
+どちらかの計算が`.spec.backoffLimit`に達した場合、Jobは失敗とみなされます。
+
+[`JobTrackingWithFinalizers`](#job-tracking-with-finalizers)機能が無効な場合、
+失敗したPodの数は、API内にまだ存在するPodのみに基づいています。
+
 {{< note >}}
 `restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。
 {{< /note >}}
@@ -267,7 +276,7 @@ Podがノードからキックされた(ノードがアップグレード、再
 
 Jobが完了すると、それ以上Podは作成されませんが、[通常](#pod-backoff-failure-policy)Podが削除されることもありません。
 これらを残しておくと、完了したPodのログを確認でき、エラーや警告などの診断出力を確認できます。
-またJobオブジェクトはJob完了後も残っているため、状態を確認することができます。古いJobの状態を把握した上で、削除するかどうかはユーザー次第です。Jobを削除するには`kubectl` (例：`kubectl delete jobs/pi`または`kubectl delete -f ./job.yaml`)を使います。`kubectl`でJobを削除する場合、Jobが作成したPodも全部削除されます。
+またJobオブジェクトはJob完了後も残っているため、状態を確認することができます。古いJobの状態を把握した上で、削除するかどうかはユーザー次第です。Jobを削除するには`kubectl` (例:`kubectl delete jobs/pi`または`kubectl delete -f ./job.yaml`)を使います。`kubectl`でJobを削除する場合、Jobが作成したPodも全部削除されます。
 
 デフォルトでは、Jobは中断されることなく実行できますが、Podが失敗した場合(`restartPolicy=Never`)、またはコンテナがエラーで終了した場合(`restartPolicy=OnFailure`)のみ、前述の`.spec.backoffLimit`で決まった回数まで再試行します。`.spec.backoffLimit`に達すると、Jobが失敗とマークされ、実行中のPodもすべて終了されます。
 
@@ -339,7 +348,7 @@ Job`pi-with-ttl`は終了してからの`100`秒後に自動的に削除され
 
 {{< note >}}
 `ttlSecondsAfterFinished`フィールドを設定することが推奨されます。管理されていないJob(CronJobなどの、他のワークロードAPIを経由せずに、直接作成したJob)は`orphanDependents`というデフォルトの削除ポリシーがあるため、Jobが完全に削除されても、属しているPodが残ってしまうからです。
-{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスターのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスターがオフラインになることがあります。
+{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクト](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスターのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスターがオフラインになることがあります。
 
 [LimitRanges](/ja/docs/concepts/policy/limit-range/)と[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)で、指定する名前空間が消費できるリソースの量に上限を設定することができます。
 {{< /note >}}
@@ -485,7 +494,7 @@ Events:
 
 JobのPodテンプレートで更新可能なフィールドはnodeAffinity、nodeSelector、tolerations、labelsとannotationsになります。 
 
-### 自分のPodセレクターを指定  {#specifying-your-own-pod-selector}
+### 独自のPodセレクターを指定  {#specifying-your-own-pod-selector}
 
 Jobオブジェクトを作成する際には通常、`.spec.selector`を指定しません。Jobが作成された際に、システムのデフォルトロジックは、他のJobと重ならないようなセレクタの値を選択し、このフィールドに追加します。
 
@@ -496,7 +505,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 
 下記はこの機能の使用例を紹介しています。
 
-`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしいですが、次に新しく作成されたPodは別のテンプレートを使用したい、Job名も変更したいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属するPodが実行されたまま_、`old`Jobを削除しました。削除する前に、どのセレクタを使用しているかについて調べました:
+`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしいですが、次に新しく作成されたPodは別のテンプレートを使用したい、Job名も変更したいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属するPodが実行されたまま_、`old`Jobを削除しました。削除する前に、どのセレクタを使用しているかをメモしておきます:
 
 ```shell
 kubectl get job old -o yaml
@@ -546,14 +555,14 @@ spec:
 有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして、唯一に実感できる違いは、コントロールプレーンのJob完了ステータス追跡はより正確になったということです。
 {{< /note >}}
 
-この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスタ内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンタを保持します。
+この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンタを保持します。
 しかし、Podは以下のように削除されることもあります:
-- Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクター二より削除されます。
+- Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
 - 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクター二より削除されます。 
 - 人為的にJobに属するPodを削除します。
 - 外部コントローラー(Kubernetesの一部として提供されていない)よりPodを削除したり置き換えたりします。
 
-クラスタで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーにより作成されたPodは`batch.kubernetes.io/job-tracking`Finalizerを持っています。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
+クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーにより作成されたPodは`batch.kubernetes.io/job-tracking`Finalizerを持っています。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
 
 Jobコントローラーは、新しいJobに対してのみ新しいアルゴリズムを使用します。この機能が有効になる前に作成されたJobは影響を受けません。JobコントローラーがPod FinalizerでJob追跡しているかどうかは、Jobが`batch.kubernetes.io/job-tracking`というアノテーションを持っているかどうかで判断できます。
 このアノテーションを手動で追加または削除しては**いけません**。
@@ -576,7 +585,7 @@ Replication Controllerは、終了することが想定されていないPod(Web
 
 もう一つのパターンは、一つのJobが一つPodを作り、そのPodがカスタムコントローラーのような役割を果たし、他のPodを作ります。これは最も柔軟性がありますが、使い始めるにはやや複雑で、Kubernetesとの統合もあまりできません。
 
-このパターンの一例としては、Sparkマスターコントローラーを起動するスクリプトがあり、そのスクリプトを実行するPodをJobで起動し、([spark事例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)、sparkドライバーを実行して片付ける、ということが挙げられます。
+このパターンの一例としては、Sparkマスターコントローラーを起動するスクリプトがあり、そのスクリプトを実行するPodをJobで起動し、([spark事例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)、sparkドライバーを実行してクリーンアップする、ということが挙げられます。
 
 
 この方法のメリットは、Jobオブジェクトで実行されているので、プロセスが完了する保障があると同時に、どのPodを作成し、どのように仕事を割り当てるかを完全に制御できることです。
@@ -589,6 +598,6 @@ Replication Controllerは、終了することが想定されていないPod(Web
    * [ワークキューを用いた粒度の粗い並列処理](/docs/tasks/job/fine-parallel-processing-work-queue/)
    * [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/) を使う(beta段階)
    * テンプレートを元に複数のJobを作成: [拡張機能を用いた並列処理](/docs/tasks/job/parallel-processing-expansion/)
-* [終了したJobの自動片付け](#clean-up-finished-jobs-automatically)のリンクから、クラスタが完了または失敗したJobをどのように片付けるかをご確認ください。
+* [終了したJobの自動クリーンアップ](#clean-up-finished-jobs-automatically)のリンクから、クラスターが完了または失敗したJobをどのようにクリーンアップするかをご確認ください。
 * `Job`はKubernetes REST APIの一部です。Job APIを理解するために、{{< api-reference page="workload-resources/job-v1" >}}オブジェクトの定義をお読みください。
 * UNIXツールの`cron`と同様に、スケジュールに基づいて実行される一連のJobを定義するために使用できる[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)についてお読みください。

From f7117a7e45ac34ab0c83926bb563c093a11df88d Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 08:55:59 +0900
Subject: [PATCH 067/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 05df0f1b61cf9..ded8817eda2e9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -361,7 +361,7 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 複雑なシステムでは、異なる作業項目のセットが複数存在する場合があります。ここでは、ユーザーが一斉に管理したい作業項目のセットが一つだけの場合 &mdash; つまり*バッチJob*だけを考えます。
 
 並列計算にはいくつかのパターンがあり、それぞれに長所と短所があります。
-兼ね合うべき要素は:
+トレードオフの関係にあるのは:
 
 - 各作業項目に1つのJobオブジェクト、 vs. すべての作業項目に1つのJobオブジェクト。  
 　後者は大量の作業項目を処理する場合に適しています。  

From 22c678a702b25b1a1183478d5de73f25d2e18f90 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 08:56:20 +0900
Subject: [PATCH 068/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ded8817eda2e9..e15fb85658c24 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -369,7 +369,7 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 - 作成されるPod数が作業項目数と等しい、 vs. 各Podが複数の作業項目を処理する。
 　前者は通常、既存のコードやコンテナへの変更が少なくて済みます。
   後者は上記と同じ理由で、大量の作業項目を処理する場合に適しています。
-- ワークキューを利用するアプローチもいくつかあります。それを使うためには、キューサービスを実行し、　既存のプログラムやコンテナにワークキューを利用させるための改造を行う必要があります。
+- ワークキューを利用するアプローチもいくつかあります。それを使うためには、キューサービスを実行し、既存のプログラムやコンテナにワークキューを利用させるための改造を行う必要があります。
   他のアプローチは既存のコンテナ型アプリケーションに適用しやすいです。
 
 

From 8cd2a87ab3bca35927b54bed894949649394b04d Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 08:56:50 +0900
Subject: [PATCH 069/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index e15fb85658c24..52f7d962a18d0 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -383,7 +383,7 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 | [静的な処理の割り当てを使用したインデックス付きJob] |         ✓         |                             |          ✓          | 
 | [Jobテンプレート拡張]                  |                   |                             |          ✓          |
 
-`.spec.completions`で完成数を指定する場合、Jobコントローラーより作成された各Podは同一の[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。これは、このタスクのすべてのPodが同じコマンドライン、同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持つことを意味します。これらのパターンは、Podが異なる作業をするためのさまざまな配置方法になります。
+`.spec.completions`で完了数を指定する場合、Jobコントローラーより作成された各Podは同一の[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。これは、このタスクのすべてのPodが同じコマンドライン、同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持つことを意味します。これらのパターンは、Podが異なる作業をするためのさまざまな配置方法になります。
 
 この表は、各パターンで必要な`.spec.parallelism`と`.spec.completions`の設定を示しています。
 ここで、`W`は作業項目の数を表しています。

From 12c3754f6f4bd6ce72ff82df7de8efed421e3b1a Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 08:57:29 +0900
Subject: [PATCH 070/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 52f7d962a18d0..deb32366ce420 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -400,7 +400,7 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 [静的な処理の割り当てを使用したインデックス付きJob]: /ja/docs/tasks/job/indexed-parallel-processing-static/
 [Jobテンプレート拡張]: /docs/tasks/job/parallel-processing-expansion/
 
-## 上級な使用方法  {#advanced-usage}
+## 高度な使い方  {#advanced-usage}
 
 ### Jobの一時停止  {#suspending-a-job}
 

From bae4512b91fd22bb1ce7533476fd3507d3e23fe5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 08:57:41 +0900
Subject: [PATCH 071/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index deb32366ce420..dc59f9b30dbb9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -408,7 +408,7 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 
 Jobが作成されると、JobコントローラーはJobの要件を満たすために直ちにPodの作成を開始し、Jobが完了するまで作成し続けます。しかし、Jobの実行を一時的に中断して後で再開したい場合、または一時停止状態のJobを再開し、再開時間は後でカスタムコントローラーに判断させたい場合はあると思います。
 
-Jobを一時停止するには、Jobの`.spec.suspend`フィールドをtrueに修正し、後でまた再開したい場合にはfalseに修正すればいいです。
+Jobを一時停止するには、Jobの`.spec.suspend`フィールドをtrueに修正し、後でまた再開したい場合にはfalseに修正すればよいです。
 `.spec.suspend`をtrueに設定してJobを作成すると、一時停止状態のままで作成されます。
 
 一時停止状態のJobを再開すると、`.status.startTime`フィールドの値は現在時刻にリセットされます。これはつまり、Jobが一時停止して再開すると、`.spec.activeDeadlineSeconds`タイマーは停止してリセットされることになります。

From d2c4ccf186fede7c5d798ae73ef42f965504d5d3 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 08:58:30 +0900
Subject: [PATCH 072/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index dc59f9b30dbb9..482c85805a2a4 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -413,7 +413,7 @@ Jobを一時停止するには、Jobの`.spec.suspend`フィールドをtrueに
 
 一時停止状態のJobを再開すると、`.status.startTime`フィールドの値は現在時刻にリセットされます。これはつまり、Jobが一時停止して再開すると、`.spec.activeDeadlineSeconds`タイマーは停止してリセットされることになります。
 
-Jobを中断すると、稼働中のPodは全部削除されることを忘れないでください。Jobが中断されると、PodはSIGTERM信号を受信して[終了されます](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。Podのグレースフル終了の猶予期間がカウントダウンされ、この期間内に、Podはこの信号を処理しなければなりません。場合により、プロセスの保存や、操作の取り消しなどの処理が含まれます。この方法で終了したPodは`completions`数にカウントされません。
+Jobを中断すると、稼働中のPodは全部削除されることを忘れないでください。Jobが中断されると、PodはSIGTERMシグナルを受信して[終了されます](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。Podのグレースフル終了の猶予期間がカウントダウンされ、この期間内に、Podはこのシグナルを処理しなければなりません。場合により、その後のために処理状況を保存したり、変更を元に戻したりする処理が含まれます。この方法で終了したPodは`completions`数にカウントされません。
 
 下記は一時停止状態のままで作成されたJobの定義例になります:
 

From 2dcb80bc50b5ae6c954c383dfd3cab3e42a705c0 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:00:04 +0900
Subject: [PATCH 073/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 482c85805a2a4..ac7a85105ea2a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -475,7 +475,7 @@ Events:
   Normal  Resumed           3s    job-controller  Job resumed
 ```
 
-最後の4つのイベント、特に"Suspended"と"Resumed"のイベントは、`.spec.suspend`フィールドの値が変更されまくったために発生したものになります。この2つのイベントの間に、Podは作成されていないですが、Jobが再開された瞬間に、Podの作成も再開されました。
+最後の4つのイベント、特に"Suspended"と"Resumed"のイベントは、`.spec.suspend`フィールドの値を切り替えた直接の結果です。この2つのイベントの間に、Podは作成されていないことがわかりますが、Jobが再開されるとすぐにPodの作成も再開されました。
 
 ### 可変スケジューリング命令  {#mutable-scheduling-directives}
 

From fb45d8f4159c9efa2ca98e7ea3743a3ba53534a6 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:00:58 +0900
Subject: [PATCH 074/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ac7a85105ea2a..2732b6dec5b09 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -490,7 +490,7 @@ Events:
 
 [suspend](#suspending-a-job)フィールドは、これらの機能を実現するための第一歩です。Suspendはキューコントローラーをカスタマイズすることにより、作業の開始時間を決定することができます；しかし、Jobの一時停止が解除されると、カスタムキューコントローラーは、Job内のPodの実際の配置場所には影響を与えません。
 
-この機能により、Jobが開始される前にスケジューリング命令を更新でき、カスタムキューコントローラーががPodの配置に影響を与えることができると同時に、実際のPodとノードの割り当てをkube-schedulerにオフロードすることができます。これは一時停止されたJobの中で、一度も一時停止解除されたことのないJobに対してのみ許可されます。
+この機能により、Jobが開始される前にスケジューリング命令を更新でき、カスタムキューコントローラーがPodの配置に影響を与えることができると同時に、実際のPodとノードの割り当てをkube-schedulerにオフロードすることができます。これは一時停止されたJobの中で、一度も一時停止解除されたことのないJobに対してのみ許可されます。
 
 JobのPodテンプレートで更新可能なフィールドはnodeAffinity、nodeSelector、tolerations、labelsとannotationsになります。 
 

From 82bc4eeeb4ad153d369e4b69e6e06e9d352eec3c Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:01:31 +0900
Subject: [PATCH 075/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 2732b6dec5b09..6cc201d2f31f5 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -500,7 +500,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 
 しかし、場合によっては、この自動設定されたセレクタをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 
-その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクタを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、一方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
+その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクタを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
 一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属されたPodも予測できない挙動をする可能性があります。`.spec.selector`を間違って設定しても、Kubernetesはエラーメッセージは出ません。
 
 下記はこの機能の使用例を紹介しています。

From 7b3b2bbc62fb73972500ee3558db62e50f00167e Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:02:13 +0900
Subject: [PATCH 076/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 6cc201d2f31f5..dfd75167c9a5a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -501,7 +501,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 しかし、場合によっては、この自動設定されたセレクタをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 
 その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクタを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
-一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属されたPodも予測できない挙動をする可能性があります。`.spec.selector`を間違って設定しても、Kubernetesはエラーメッセージは出ません。
+一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属しているPodが予測できない挙動をする可能性があります。Kubernetesは`.spec.selector`を間違って設定しても止めることはしません。
 
 下記はこの機能の使用例を紹介しています。
 

From 428bde3966d7bf51be655eda4cfef4b957c648d5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:03:10 +0900
Subject: [PATCH 077/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index dfd75167c9a5a..27d6d72161018 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -505,7 +505,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 
 下記はこの機能の使用例を紹介しています。
 
-`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしいですが、次に新しく作成されたPodは別のテンプレートを使用したい、Job名も変更したいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属するPodが実行されたまま_、`old`Jobを削除しました。削除する前に、どのセレクタを使用しているかをメモしておきます:
+`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしい一方で、新しく作成されたPodは別のテンプレートを使用したい、Job名も変更したいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属しているPodが実行されたまま_、`old`Jobを削除します。削除する前に、どのセレクタを使用しているかをメモしておきます:
 
 ```shell
 kubectl get job old -o yaml

From d03861254915d02a77c53a64f0c087b4337107c5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:03:30 +0900
Subject: [PATCH 078/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 27d6d72161018..18371335e90c4 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -525,7 +525,7 @@ spec:
   ...
 ```
 
-次に、`new`という名前で新しくJobを作成し、同じセレクタを指定しました。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされることができます。
+次に、`new`という名前で新しくJobを作成し、同じセレクタを指定します。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされることができます。
 
 通常システムが自動的に生成するセレクタを使用しないため、新しいJobで `manualSelector: true`を指定する必要があります。
 

From 000d0a80d4cb9bb54df816f12efc36fc136ad48b Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:03:50 +0900
Subject: [PATCH 079/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 18371335e90c4..5a7b15a0d4549 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -559,7 +559,7 @@ spec:
 しかし、Podは以下のように削除されることもあります:
 - Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
 - 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクター二より削除されます。 
-- 人為的にJobに属するPodを削除します。
+- Jobに属するPodの人為的な削除。
 - 外部コントローラー(Kubernetesの一部として提供されていない)よりPodを削除したり置き換えたりします。
 
 クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーにより作成されたPodは`batch.kubernetes.io/job-tracking`Finalizerを持っています。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。

From 4c7822fdcca5a3f1e053552589bec1cd8bfad3de Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:04:32 +0900
Subject: [PATCH 080/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 5a7b15a0d4549..9e57a629b4b63 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -558,7 +558,7 @@ spec:
 この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンタを保持します。
 しかし、Podは以下のように削除されることもあります:
 - Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
-- 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクター二より削除されます。 
+- 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクターにより削除されます。 
 - Jobに属するPodの人為的な削除。
 - 外部コントローラー(Kubernetesの一部として提供されていない)よりPodを削除したり置き換えたりします。
 

From 7a36df02c12c9ae9a385d576589f8472e72cf74d Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:04:49 +0900
Subject: [PATCH 081/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9e57a629b4b63..0a984f2b5e720 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -560,7 +560,7 @@ spec:
 - Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
 - 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクターにより削除されます。 
 - Jobに属するPodの人為的な削除。
-- 外部コントローラー(Kubernetesの一部として提供されていない)よりPodを削除したり置き換えたりします。
+- 外部コントローラー(Kubernetesの一部として提供されていない)によるPodの削除や置き換え。
 
 クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーにより作成されたPodは`batch.kubernetes.io/job-tracking`Finalizerを持っています。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
 

From 45c2f8975894bf643f5c59e7cfbe977902ebf9ec Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:05:47 +0900
Subject: [PATCH 082/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 0a984f2b5e720..fe929bd122062 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -585,7 +585,7 @@ Replication Controllerは、終了することが想定されていないPod(Web
 
 もう一つのパターンは、一つのJobが一つPodを作り、そのPodがカスタムコントローラーのような役割を果たし、他のPodを作ります。これは最も柔軟性がありますが、使い始めるにはやや複雑で、Kubernetesとの統合もあまりできません。
 
-このパターンの一例としては、Sparkマスターコントローラーを起動するスクリプトがあり、そのスクリプトを実行するPodをJobで起動し、([spark事例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)、sparkドライバーを実行してクリーンアップする、ということが挙げられます。
+このパターンの一例としては、Sparkマスターコントローラーを起動し、sparkドライバーを実行してクリーンアップするスクリプトを実行するPodをJobで起動する([sparkの例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)が挙げられます。
 
 
 この方法のメリットは、Jobオブジェクトで実行されているので、プロセスが完了する保障があると同時に、どのPodを作成し、どのように仕事を割り当てるかを完全に制御できることです。

From 137f1e19b3c3ddd7e5d83f4547981b5846a8b379 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:06:12 +0900
Subject: [PATCH 083/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index fe929bd122062..0954063fbe05f 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -595,7 +595,7 @@ Replication Controllerは、終了することが想定されていないPod(Web
 * [Pods](/ja/docs/concepts/workloads/pods/)について学ぶ。
 * Jobのさまざまな実行方法について学ぶ:
    * [ワークキューを用いた粒度の粗い並列処理](/docs/tasks/job/coarse-parallel-processing-work-queue/)
-   * [ワークキューを用いた粒度の粗い並列処理](/docs/tasks/job/fine-parallel-processing-work-queue/)
+   * [ワークキューを用いた粒度の細かい並列処理](/docs/tasks/job/fine-parallel-processing-work-queue/)
    * [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/) を使う(beta段階)
    * テンプレートを元に複数のJobを作成: [拡張機能を用いた並列処理](/docs/tasks/job/parallel-processing-expansion/)
 * [終了したJobの自動クリーンアップ](#clean-up-finished-jobs-automatically)のリンクから、クラスターが完了または失敗したJobをどのようにクリーンアップするかをご確認ください。

From dcb904f034ef532eda88acb8101c61b47515c29f Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:16:57 +0900
Subject: [PATCH 084/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: atoato88 <akihito-inou@nec.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 0954063fbe05f..2209ff3c773b5 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -599,5 +599,5 @@ Replication Controllerは、終了することが想定されていないPod(Web
    * [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/) を使う(beta段階)
    * テンプレートを元に複数のJobを作成: [拡張機能を用いた並列処理](/docs/tasks/job/parallel-processing-expansion/)
 * [終了したJobの自動クリーンアップ](#clean-up-finished-jobs-automatically)のリンクから、クラスターが完了または失敗したJobをどのようにクリーンアップするかをご確認ください。
-* `Job`はKubernetes REST APIの一部です。Job APIを理解するために、{{< api-reference page="workload-resources/job-v1" >}}オブジェクトの定義をお読みください。
+* `Job`はKubernetes REST APIの一部です。JobのAPIを理解するために、{{< api-reference page="workload-resources/job-v1" >}}オブジェクトの定義をお読みください。
 * UNIXツールの`cron`と同様に、スケジュールに基づいて実行される一連のJobを定義するために使用できる[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)についてお読みください。

From 12e7de8d447f2642711be92f52035daf15ca8bc1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 2 Aug 2022 09:19:07 +0900
Subject: [PATCH 085/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 2209ff3c773b5..faca9288601ba 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -269,7 +269,7 @@ Podがノードからキックされた(ノードがアップグレード、再
 失敗したPodの数は、API内にまだ存在するPodのみに基づいています。
 
 {{< note >}}
-`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。しかし、Jobの実行ファイルのデバッグ作業がこれにより難しくなる可能性はありますので、失敗したJobからの出力が不注意で失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。
+`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。これにより、Jobの実行ファイルのデバッグ作業が難しくなる可能性があります。失敗したJobからの出力が不用意に失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。
 {{< /note >}}
 
 ## Jobの終了とクリーンアップ  {#job-termination-and-cleanup}

From d0fd39bb289a5de8ef8dd23b5ff3499e124dc556 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Tue, 2 Aug 2022 00:21:59 +0000
Subject: [PATCH 086/110] modified some translations

---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index faca9288601ba..c324d5cf6bcf5 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -269,7 +269,7 @@ Podがノードからキックされた(ノードがアップグレード、再
 失敗したPodの数は、API内にまだ存在するPodのみに基づいています。
 
 {{< note >}}
-`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。これにより、Jobの実行ファイルのデバッグ作業が難しくなる可能性があります。失敗したJobからの出力が不用意に失われないように、Jobのデバッグ作業やロギングシステムを使用する場合、`restartPolicy = "Never"`と設定することをお勧めします。
+`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。これにより、Jobの実行ファイルのデバッグ作業が難しくなる可能性があります。失敗したJobからの出力が不用意に失われないように、Jobのデバッグ作業をする際は`restartPolicy = "Never"`を設定するか、ロギングシステムを使用することをお勧めします。
 {{< /note >}}
 
 ## Jobの終了とクリーンアップ  {#job-termination-and-cleanup}

From 2727f1009a5a41283a260d69185781a42e0b19b2 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Tue, 2 Aug 2022 00:34:30 +0000
Subject: [PATCH 087/110] modified the image version

---
 content/ja/examples/controllers/job.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/examples/controllers/job.yaml b/content/ja/examples/controllers/job.yaml
index b448f2eb81daf..d8befe89dba46 100644
--- a/content/ja/examples/controllers/job.yaml
+++ b/content/ja/examples/controllers/job.yaml
@@ -7,7 +7,7 @@ spec:
     spec:
       containers:
       - name: pi
-        image: perl
+        image: perl:5.34.0
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
   backoffLimit: 4

From 8c891b457ca14b5c7466b24e6c29940531f780b1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:31:19 +0900
Subject: [PATCH 088/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index c324d5cf6bcf5..9898bdc0a616a 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -486,7 +486,7 @@ Events:
 デフォルトで有効になっています。
 {{< /note >}}
 
-ほとんどの場合、並列Jobは、すべてのPodが同じゾーンで実行される、またはすべてGPUモデルxかyのいずれかで実行され、両方を混在されることがない、などの制約を持って実行することを望みます。
+ほとんどの場合、並列Jobは、すべてのPodが同じゾーン、またはすべてのGPUモデルxかyのいずれかであるが、両方の混在ではない、などの制約付きで実行することが望ましいです。
 
 [suspend](#suspending-a-job)フィールドは、これらの機能を実現するための第一歩です。Suspendはキューコントローラーをカスタマイズすることにより、作業の開始時間を決定することができます；しかし、Jobの一時停止が解除されると、カスタムキューコントローラーは、Job内のPodの実際の配置場所には影響を与えません。
 

From 70a53497cacfe9d01572060007b65c51ecfdfe44 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:31:58 +0900
Subject: [PATCH 089/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9898bdc0a616a..ad251a908068b 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -488,7 +488,7 @@ Events:
 
 ほとんどの場合、並列Jobは、すべてのPodが同じゾーン、またはすべてのGPUモデルxかyのいずれかであるが、両方の混在ではない、などの制約付きで実行することが望ましいです。
 
-[suspend](#suspending-a-job)フィールドは、これらの機能を実現するための第一歩です。Suspendはキューコントローラーをカスタマイズすることにより、作業の開始時間を決定することができます；しかし、Jobの一時停止が解除されると、カスタムキューコントローラーは、Job内のPodの実際の配置場所には影響を与えません。
+[suspend](#suspending-a-job)フィールドは、これらの機能を実現するための第一歩です。Suspendは、カスタムキューコントローラーがJobをいつ開始すべきかを決定することができます。しかし、Jobの一時停止が解除されると、カスタムキューコントローラーは、Job内のPodの実際の配置場所には影響を与えません。
 
 この機能により、Jobが開始される前にスケジューリング命令を更新でき、カスタムキューコントローラーがPodの配置に影響を与えることができると同時に、実際のPodとノードの割り当てをkube-schedulerにオフロードすることができます。これは一時停止されたJobの中で、一度も一時停止解除されたことのないJobに対してのみ許可されます。
 

From 11ab3f5a1d963472cf05b9f85e8c092b2863f655 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:32:16 +0900
Subject: [PATCH 090/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index ad251a908068b..b3d605386c937 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -496,7 +496,7 @@ JobのPodテンプレートで更新可能なフィールドはnodeAffinity、no
 
 ### 独自のPodセレクターを指定  {#specifying-your-own-pod-selector}
 
-Jobオブジェクトを作成する際には通常、`.spec.selector`を指定しません。Jobが作成された際に、システムのデフォルトロジックは、他のJobと重ならないようなセレクタの値を選択し、このフィールドに追加します。
+Jobオブジェクトを作成する際には通常、`.spec.selector`を指定しません。Jobが作成された際に、システムのデフォルトロジックは、他のJobと重ならないようなセレクターの値を選択し、このフィールドに追加します。
 
 しかし、場合によっては、この自動設定されたセレクタをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 

From da0d9565d60971cf03082e72caaecc0e52e1a2f1 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:32:39 +0900
Subject: [PATCH 091/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index b3d605386c937..05251040dedf6 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -498,7 +498,7 @@ JobのPodテンプレートで更新可能なフィールドはnodeAffinity、no
 
 Jobオブジェクトを作成する際には通常、`.spec.selector`を指定しません。Jobが作成された際に、システムのデフォルトロジックは、他のJobと重ならないようなセレクターの値を選択し、このフィールドに追加します。
 
-しかし、場合によっては、この自動設定されたセレクタをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
+しかし、場合によっては、この自動設定されたセレクターをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 
 その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクタを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
 一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属しているPodが予測できない挙動をする可能性があります。Kubernetesは`.spec.selector`を間違って設定しても止めることはしません。

From 15367f240894bd5d3fd30c5d51233a7eccc91e6a Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:35:29 +0900
Subject: [PATCH 092/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 05251040dedf6..912e96d54a9c3 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -500,7 +500,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 
 しかし、場合によっては、この自動設定されたセレクターをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 
-その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクタを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
+その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクターを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
 一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属しているPodが予測できない挙動をする可能性があります。Kubernetesは`.spec.selector`を間違って設定しても止めることはしません。
 
 下記はこの機能の使用例を紹介しています。

From 06d55da7c54f6e351b67a6109c7af7f56fce163f Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:35:52 +0900
Subject: [PATCH 093/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 912e96d54a9c3..31702fa60d609 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -501,7 +501,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 しかし、場合によっては、この自動設定されたセレクターをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
 
 その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクターを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
-一意でないセレクタを選択した場合、他のコントローラ(例えばReplicationController)や属しているPodが予測できない挙動をする可能性があります。Kubernetesは`.spec.selector`を間違って設定しても止めることはしません。
+一意でないセレクターを選択した場合、他のコントローラー(例えばReplicationController)や属しているPodが予測できない挙動をする可能性があります。Kubernetesは`.spec.selector`を間違って設定しても止めることはしません。
 
 下記はこの機能の使用例を紹介しています。
 

From bf8b5d758187b58ea744e1541d0824fa1e74503e Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:37:07 +0900
Subject: [PATCH 094/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 31702fa60d609..d438afd98f392 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -505,7 +505,7 @@ Jobオブジェクトを作成する際には通常、`.spec.selector`を指定
 
 下記はこの機能の使用例を紹介しています。
 
-`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしい一方で、新しく作成されたPodは別のテンプレートを使用したい、Job名も変更したいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属しているPodが実行されたまま_、`old`Jobを削除します。削除する前に、どのセレクタを使用しているかをメモしておきます:
+`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしい一方で、作成する残りのPodには別のテンプレートを使用し、そのJobには新しい名前を付けたいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属しているPodが実行されたまま_、`old`Jobを削除します。削除する前に、どのセレクターを使用しているかをメモしておきます:
 
 ```shell
 kubectl get job old -o yaml

From ebfc5b557e47b0a51349e6b283734e9c0046597c Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:37:40 +0900
Subject: [PATCH 095/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index d438afd98f392..a65295cb116df 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -525,7 +525,7 @@ spec:
   ...
 ```
 
-次に、`new`という名前で新しくJobを作成し、同じセレクタを指定します。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされることができます。
+次に、`new`という名前で新しくJobを作成し、同じセレクターを明示的に指定します。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされます。
 
 通常システムが自動的に生成するセレクタを使用しないため、新しいJobで `manualSelector: true`を指定する必要があります。
 

From 71a1d016642ace7acb25712b4081b27156459cb4 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:37:57 +0900
Subject: [PATCH 096/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index a65295cb116df..545ecb9516266 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -527,7 +527,7 @@ spec:
 
 次に、`new`という名前で新しくJobを作成し、同じセレクターを明示的に指定します。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされます。
 
-通常システムが自動的に生成するセレクタを使用しないため、新しいJobで `manualSelector: true`を指定する必要があります。
+通常システムが自動的に生成するセレクターを使用しないため、新しいJobで `manualSelector: true`を指定する必要があります。
 
 ```yaml
 kind: Job

From a7be95bccd5895510d3d8e1a2094ff259537fc71 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:38:14 +0900
Subject: [PATCH 097/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 545ecb9516266..bd8db26beb57f 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -542,7 +542,7 @@ spec:
   ...
 ```
 
-新しいJobは`a8f3d00d-c6d2-11e5-9f87-42010af00002`ではなく、別のuid を持つことになります。`manualSelector: true`を設定することで、自分は何をしているかを知っていて、またこのミスマッチを許容することをシステムに伝えます。
+新しいJobは`a8f3d00d-c6d2-11e5-9f87-42010af00002`ではなく、別のuidを持つことになります。`manualSelector: true`を設定することで、自分は何をしているかを知っていて、またこのミスマッチを許容することをシステムに伝えます。
 
 ### FinalizerによるJob追跡  {#job-tracking-with-finalizers}
 

From fd5d27ef15e8658ca68558aff3bf3651b5200ea2 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:38:48 +0900
Subject: [PATCH 098/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index bd8db26beb57f..82155dc38d459 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -552,7 +552,7 @@ spec:
 この機能を使うためには、[APIサーバー](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)で`JobTrackingWithFinalizers`
 [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
 
-有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして、唯一に実感できる違いは、コントロールプレーンのJob完了ステータス追跡はより正確になったということです。
+有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして実感できる唯一の違いは、コントロールプレーンのJob完了ステータス追跡がより正確になるということだけです。
 {{< /note >}}
 
 この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンタを保持します。

From b84ff5cfaa5b91081853345105e3fb0d9a5281a0 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:39:03 +0900
Subject: [PATCH 099/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 82155dc38d459..620f84e15f231 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -555,7 +555,7 @@ spec:
 有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして実感できる唯一の違いは、コントロールプレーンのJob完了ステータス追跡がより正確になるということだけです。
 {{< /note >}}
 
-この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンタを保持します。
+この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンターを保持します。
 しかし、Podは以下のように削除されることもあります:
 - Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
 - 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクターにより削除されます。 

From f95d0ce091d5c361bf6550bacd6d2e7438271bcb Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:39:20 +0900
Subject: [PATCH 100/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 620f84e15f231..c3b6c4141214f 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -556,7 +556,7 @@ spec:
 {{< /note >}}
 
 この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンターを保持します。
-しかし、Podは以下のように削除されることもあります:
+しかし、Podは以下のような理由で削除されることもあります:
 - Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
 - 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクターにより削除されます。 
 - Jobに属するPodの人為的な削除。

From c289d13749d3b56befc1f94a25bad02b761eab75 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:40:08 +0900
Subject: [PATCH 101/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index c3b6c4141214f..19eaba790e739 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -557,8 +557,8 @@ spec:
 
 この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンターを保持します。
 しかし、Podは以下のような理由で削除されることもあります:
-- Nodeがダウンしたときに、孤立した(Orphan)Podはガベージコレクターにより削除されます。
-- 閾値に達すると、終了したPod(`Succeeded`または`Failed`フェーズを問わず)はガベージコレクターにより削除されます。 
+- Nodeがダウンしたときに、孤立した(Orphan)Podを削除するガベージコレクター。
+- 閾値に達すると、(`Succeeded`または`Failed`フェーズで)終了したPodを削除するガベージコレクター。 
 - Jobに属するPodの人為的な削除。
 - 外部コントローラー(Kubernetesの一部として提供されていない)によるPodの削除や置き換え。
 

From 91c598df987751e1ead6a87edff3838c44eb9876 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 08:47:05 +0900
Subject: [PATCH 102/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 19eaba790e739..29bb1548031e8 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -575,7 +575,7 @@ Podが動作しているノードが再起動または故障した場合、Pod
 
 ### Replication Controller  {#replication-controller}
 
-Jobsは[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)を補完するものです。
+Jobは[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)を補完するものです。
 Replication Controllerは、終了することが想定されていないPod(Webサーバーなど)を管理し、Jobは終了することが想定されているPod(バッチタスクなど)を管理します。
 
 [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`か`Never`と設定されているPodに*のみ*適用されます。(注意:`RestartPolicy`が設定されていない場合、デフォルト値は`Always`になります)

From 8d1d59dd5b6e5a406d29cf167dc676d45af1b8c3 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Thu, 4 Aug 2022 09:00:29 +0900
Subject: [PATCH 103/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 29bb1548031e8..84b0ac2ace5b2 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -588,7 +588,7 @@ Replication Controllerは、終了することが想定されていないPod(Web
 このパターンの一例としては、Sparkマスターコントローラーを起動し、sparkドライバーを実行してクリーンアップするスクリプトを実行するPodをJobで起動する([sparkの例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)が挙げられます。
 
 
-この方法のメリットは、Jobオブジェクトで実行されているので、プロセスが完了する保障があると同時に、どのPodを作成し、どのように仕事を割り当てるかを完全に制御できることです。
+この方法のメリットは、全処理過程でJobオブジェクトが完了する保証がありながらも、どのPodを作成し、どのように作業を割り当てるかを完全に制御できることです。
 
 ## {{% heading "whatsnext" %}}
 

From 8fe44bf66bab275a2bc141033524ef1058f7dbb9 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Mon, 8 Aug 2022 15:41:06 +0900
Subject: [PATCH 104/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 84b0ac2ace5b2..5bf27eda0f4b9 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -562,7 +562,7 @@ spec:
 - Jobに属するPodの人為的な削除。
 - 外部コントローラー(Kubernetesの一部として提供されていない)によるPodの削除や置き換え。
 
-クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーにより作成されたPodは`batch.kubernetes.io/job-tracking`Finalizerを持っています。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
+クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーは`batch.kubernetes.io/job-tracking`Finalizerを持つJobを作成します。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
 
 Jobコントローラーは、新しいJobに対してのみ新しいアルゴリズムを使用します。この機能が有効になる前に作成されたJobは影響を受けません。JobコントローラーがPod FinalizerでJob追跡しているかどうかは、Jobが`batch.kubernetes.io/job-tracking`というアノテーションを持っているかどうかで判断できます。
 このアノテーションを手動で追加または削除しては**いけません**。

From e97936cefdecb30f3dab174670b51c2aac8e4fa2 Mon Sep 17 00:00:00 2001
From: ziyi-xie <kai-shii@nec.com>
Date: Mon, 8 Aug 2022 06:46:17 +0000
Subject: [PATCH 105/110] fixed some typo

---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 5bf27eda0f4b9..6a0346cb9b37c 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -562,7 +562,7 @@ spec:
 - Jobに属するPodの人為的な削除。
 - 外部コントローラー(Kubernetesの一部として提供されていない)によるPodの削除や置き換え。
 
-クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーは`batch.kubernetes.io/job-tracking`Finalizerを持つJobを作成します。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
+クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーは`batch.kubernetes.io/job-tracking`Finalizerを持つPodを作成します。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
 
 Jobコントローラーは、新しいJobに対してのみ新しいアルゴリズムを使用します。この機能が有効になる前に作成されたJobは影響を受けません。JobコントローラーがPod FinalizerでJob追跡しているかどうかは、Jobが`batch.kubernetes.io/job-tracking`というアノテーションを持っているかどうかで判断できます。
 このアノテーションを手動で追加または削除しては**いけません**。

From b27d4c22f2e97de7094a7a1a38eeb5ee6636fdeb Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 9 Aug 2022 08:29:49 +0900
Subject: [PATCH 106/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 6a0346cb9b37c..6da3587f48f01 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -342,7 +342,7 @@ spec:
       restartPolicy: Never
 ```
 
-Job`pi-with-ttl`は終了してからの`100`秒後に自動的に削除されるようになっています。
+Job `pi-with-ttl`は終了してからの`100`秒後に自動的に削除されるようになっています。
 
 このフィールドに`0`を設定すると、Jobは終了後すぐに自動削除の対象になります。このフィールドに何も設定しないと、Jobが終了してもTTLコントローラーによるクリーンアップはされません。
 

From 1f0814a428f5c7be2d966c87661d68cdf2558a12 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 9 Aug 2022 08:30:10 +0900
Subject: [PATCH 107/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 6da3587f48f01..9e77d69d139bd 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -348,7 +348,7 @@ Job `pi-with-ttl`は終了してからの`100`秒後に自動的に削除され
 
 {{< note >}}
 `ttlSecondsAfterFinished`フィールドを設定することが推奨されます。管理されていないJob(CronJobなどの、他のワークロードAPIを経由せずに、直接作成したJob)は`orphanDependents`というデフォルトの削除ポリシーがあるため、Jobが完全に削除されても、属しているPodが残ってしまうからです。
-{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクト](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスターのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスターがオフラインになることがあります。
+{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスターのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスターがオフラインになることがあります。
 
 [LimitRanges](/ja/docs/concepts/policy/limit-range/)と[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)で、指定する名前空間が消費できるリソースの量に上限を設定することができます。
 {{< /note >}}

From 7424f5ec28f938e38ce21b3848876193caa377c6 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 9 Aug 2022 08:30:29 +0900
Subject: [PATCH 108/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 9e77d69d139bd..2b48402e84236 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -356,7 +356,7 @@ Job `pi-with-ttl`は終了してからの`100`秒後に自動的に削除され
 
 ## Jobパターン  {#job-patterns}
 
-Jobオブジェクトは、Podの確実な並列実行をサポートするために使用されます。科学技術計算でよく見られるような、密接に通信を行う並列処理をサポートするようには設計されていません。独立だが関連性のある一連の*作業項目*の並列処理をサポートします。例えば送信すべき電子メール、レンダリングすべきフレーム、トランスコードすべきファイル、スキャンすべきNoSQLデータベースのキーの範囲、などなどです。
+Jobオブジェクトは、Podの確実な並列実行をサポートするために使用されます。科学技術計算でよく見られるような、密接に通信を行う並列処理をサポートするようには設計されていません。独立だが関連性のある一連の*作業項目*の並列処理をサポートします。例えば送信すべき電子メール、レンダリングすべきフレーム、トランスコードすべきファイル、スキャンすべきNoSQLデータベースのキーの範囲、などです。
 
 複雑なシステムでは、異なる作業項目のセットが複数存在する場合があります。ここでは、ユーザーが一斉に管理したい作業項目のセットが一つだけの場合 &mdash; つまり*バッチJob*だけを考えます。
 

From 142e7f9cde268727edce058662280975b7aa446a Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 9 Aug 2022 08:30:46 +0900
Subject: [PATCH 109/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 2b48402e84236..1680b82fe5e75 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -363,7 +363,7 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 並列計算にはいくつかのパターンがあり、それぞれに長所と短所があります。
 トレードオフの関係にあるのは:
 
-- 各作業項目に1つのJobオブジェクト、 vs. すべての作業項目に1つのJobオブジェクト。  
+- 各作業項目に1つのJobオブジェクト vs. すべての作業項目に1つのJobオブジェクト。  
 　後者は大量の作業項目を処理する場合に適しています。  
 　前者は大量のJobオブジェクトを管理するため、ユーザーとシステムにオーバーヘッドをかけることになります。
 - 作成されるPod数が作業項目数と等しい、 vs. 各Podが複数の作業項目を処理する。

From f7a404a889f26dfd4cfffb60e9da97d0a27410a5 Mon Sep 17 00:00:00 2001
From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com>
Date: Tue, 9 Aug 2022 08:31:03 +0900
Subject: [PATCH 110/110] Update
 content/ja/docs/concepts/workloads/controllers/job.md

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
---
 content/ja/docs/concepts/workloads/controllers/job.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md
index 1680b82fe5e75..2b54250346e0b 100644
--- a/content/ja/docs/concepts/workloads/controllers/job.md
+++ b/content/ja/docs/concepts/workloads/controllers/job.md
@@ -492,7 +492,7 @@ Events:
 
 この機能により、Jobが開始される前にスケジューリング命令を更新でき、カスタムキューコントローラーがPodの配置に影響を与えることができると同時に、実際のPodとノードの割り当てをkube-schedulerにオフロードすることができます。これは一時停止されたJobの中で、一度も一時停止解除されたことのないJobに対してのみ許可されます。
 
-JobのPodテンプレートで更新可能なフィールドはnodeAffinity、nodeSelector、tolerations、labelsとannotationsになります。 
+JobのPodテンプレートで更新可能なフィールドはnodeAffinity、nodeSelector、tolerations、labelsとannotationsです。 
 
 ### 独自のPodセレクターを指定  {#specifying-your-own-pod-selector}