First Japanese l10n work for release-1.16 (#18790)

* Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710) * Translate concepts/services-networking/connect-applications-service/ into Japanese * Apply review * Translate content/ja/docs/tasks/_index.md into Japanese (#17789) * add task index * huge page * ja-docs: Update kops Installation Steps (#17804) * Update /ja/docs/tasks/tools/install-minikube/ (#17711) * Update /ja/docs/tasks/tools/install-minikube/ * Apply review * Apply review * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160) * copy from content/en/docs/tasks/configure-pod-container/ to ja * translate assign-cpu-resource.md in Japanese * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update assign-cpu-resource.md ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく * fix translation "Pod scheduling is based on requests." の箇所。 requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述 * Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794) * ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * little fix (#18135) * update index (#18136) * Update /ja/docs/setup/_index.md (#18139) * Update /ja/docs/tasks/tools/install-kubectl/ (#18137) * update /docs/ja/tasks/tools/install-kubectl/ * fix mongon * apply reveiw * Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141) * Update feature agete * tidy up feature gates list * translate new lines * table caption * blank * する -> します * apply review * fix broken link * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * update translation * remove line * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * rollpack * Update /ja/docs/concepts/services-networking/service/ (#18138) * update /ja/docs/concepts/services-networking/service/ * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * consider Endpoints as a Kubernetes resource * full * Update content/ja/docs/concepts/_index.md (#18145) * Update concepts * control plane * apply review * fix bold (#18165) * Update /ja/docs/concepts/overview/components.md (#18153) * update /ja/docs/concepts/overview/components.md * some japanese docs are already there * translate prepend * apply upstream changes (#18278) * Translate concepts/services-networking/ingress into Japanese #17741 (#18234) * ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * Update pod overview in Japanese (#18277) * Update pod-overview * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ノード * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796) * ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans:conetent/ja/casestudies/nav (#18450) * Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395) * Translate tasks/debug-application-cluster/debug-service/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Change all `Pods` to `Pod` and `Endpoints` to `Endpoint` * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Updated content pointed out in review * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review * Apply suggestions form review * Apply suggestions from review * Apply suggestions from review * Apply suggestions from code review Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200) * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese * Apply suggestions from code review between L1 an L120 by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update CustomResourceDefinition not to localize into Japanese * Revert the link to customresourcedefinitions to English Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py and inductor Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply a suggestion from review by inductor * Apply a suggestion from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173) * copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese Guaranteed, Burstable, BestEffortは用語として存在するので訳さない Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285) * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Translated kubectl cheet sheet. * Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Modify translation for casestudies (#18767) * modify terminology * add ten * update translation * update * update * update * fix typo (#18769) * remove english comment (#18770) * ja-trans:conetent/ja/casestudies/spotify (#18451) * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Updated with the proposal from inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Updated with inductor 's proposal Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate Japanese headers (#18776) * translate headers * add index for references * Update content/ja/docs/setup/production-environment/tools/_index.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * translate controller Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * ja-docs: translate install-kubeadm into Japanese (#18198) * ja-docs: translate install-kubeadm into Japanese * translate table title in install-kubeadm to Japanese * update kubeadm install doc * remove extra spaces * fix translation miss * translate url title into japanese * fix translation miss * remove line break in sentence and translate title * remove extra line break * remove extra line break * fix translation miss Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com>
2020-01-21 13:39:36 +09:00
parent 3da672600e
commit 0c86e6515a
55 changed files with 4602 additions and 364 deletions
@@ -7,7 +7,7 @@ weight: 40

 {{% capture overview %}}

-本セクションは、Kubernetesシステムの各パートと、クラスターを表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。
+本セクションは、Kubernetesシステムの各パートと、{{< glossary_tooltip text="クラスター" term_id="cluster" length="all" >}}を表現するためにKubernetesが使用する抽象概念について学習し、Kubernetesの仕組みをより深く理解するのに役立ちます。

 {{% /capture %}}

@@ -17,7 +17,7 @@ weight: 40

 Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使用して、実行したいアプリケーションやその他のワークロード、使用するコンテナイメージ、レプリカ(複製)の数、どんなネットワークやディスクリソースを利用可能にするかなど、クラスターの *desired state* (望ましい状態)を記述します。desired sate (望ましい状態)をセットするには、Kubernetes APIを使用してオブジェクトを作成します。通常はコマンドラインインターフェイス `kubectl` を用いてKubernetes APIを操作しますが、Kubernetes APIを直接使用してクラスターと対話し、desired state (望ましい状態)を設定、または変更することもできます。

-一旦desired state (望ましい状態)を設定すると、*Kubernetes コントロールプレーン* が働き、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。
+一旦desired state (望ましい状態)を設定すると、Pod Lifecycle Event Generator([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))を使用した*Kubernetes コントロールプレーン*が機能し、クラスターの現在の状態をdesired state (望ましい状態)に一致させます。そのためにKubernetesはさまざまなタスク(たとえば、コンテナの起動または再起動、特定アプリケーションのレプリカ数のスケーリング等)を自動的に実行します。Kubernetesコントロールプレーンは、クラスターで実行されている以下のプロセスで構成されています。

 * **Kubernetes Master** :[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)、[kube-scheduler](/docs/admin/kube-scheduler/) の3プロセスの集合です。これらのプロセスはクラスター内の一つのノード上で実行されます。実行ノードはマスターノードとして指定します。
 * クラスター内の個々の非マスターノードは、それぞれ2つのプロセスを実行します。
@@ -26,7 +26,7 @@ Kubernetesを機能させるには、*Kubernetes API オブジェクト* を使

 ## Kubernetesオブジェクト

-Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクト概要](/docs/concepts/abstractions/overview/) をご覧ください。
+Kubernetesには、デプロイ済みのコンテナ化されたアプリケーションやワークロード、関連するネットワークとディスクリソース、クラスターが何をしているかに関するその他の情報といった、システムの状態を表現する抽象が含まれています。これらの抽象は、Kubernetes APIのオブジェクトによって表現されます。詳細については、[Kubernetesオブジェクトについて知る](/docs/concepts/overview/working-with-objects/kubernetes-objects/)をご覧ください。

 基本的なKubernetesのオブジェクトは次のとおりです。

@@ -35,19 +35,19 @@ Kubernetesには、デプロイ済みのコンテナ化されたアプリケー
 * [Volume](/docs/concepts/storage/volumes/)
 * [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/)

-上記に加え、Kubernetesにはコントローラーと呼ばれる多くの高レベルの抽象概念が含まれています。コントローラーは基本オブジェクトに基づいて構築され、以下のような追加の機能と便利な機能を提供します。
+Kubernetesには、[コントローラー](/docs/concepts/architecture/controller/)に依存して基本オブジェクトを構築し、追加の機能と便利な機能を提供する高レベルの抽象化も含まれています。これらには以下のものを含みます:

-* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
+* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
 * [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)
+* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
+* [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)
 * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)

 ## Kubernetesコントロールプレーン

 Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。

-たとえば、Kubernetes APIを使用してDeploymentオブジェクトを作成する場合、システムには新しいdesired state (望ましい状態)が提供されます。Kubernetesコントロールプレーンは、そのオブジェクトの作成を記録します。そして、要求されたアプリケーションの開始、およびクラスターノードへのスケジューリングにより指示を完遂します。このようにしてクラスターの実際の状態を望ましい状態に一致させます。
+たとえば、Kubernetes APIを使用してDeploymentを作成する場合、システムには新しいdesired state (望ましい状態)が提供されます。Kubernetesコントロールプレーンは、そのオブジェクトの作成を記録します。そして、要求されたアプリケーションの開始、およびクラスターノードへのスケジューリングにより指示を完遂します。このようにしてクラスターの実際の状態を望ましい状態に一致させます。

 ### Kubernetesマスター

@@ -59,11 +59,6 @@ Kubernetesのマスターは、クラスターの望ましい状態を維持す

 クラスターのノードは、アプリケーションとクラウドワークフローを実行するマシン(VM、物理サーバーなど)です。Kubernetesのマスターは各ノードを制御します。運用者自身がノードと直接対話することはほとんどありません。

-#### オブジェクトメタデータ
-
-
-* [Annotations](/ja/docs/concepts/overview/working-with-objects/annotations/)
-
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -1,4 +1,4 @@
 ---
-title: "Kubernetes アーキテクチャー"
+title: "Kubernetesのアーキテクチャー"
 weight: 30
 ---
@@ -0,0 +1,5 @@
+---
+title: "クラスターの管理"
+weight: 100
+---
+
@@ -0,0 +1,5 @@
+---
+title: "設定"
+weight: 80
+---
+
@@ -1,5 +1,4 @@
 ---
-title: "Containers"
+title: "コンテナ"
 weight: 40
 ---
-
@@ -0,0 +1,223 @@
+---
+title: カスタムリソース
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+*カスタムリソース* はKubernetes APIの拡張です。このページでは、いつKubernetesのクラスターにカスタムリソースを追加するべきなのか、そしていつスタンドアローンのサービスを利用するべきなのかを議論します。カスタムリソースを追加する2つの方法と、それらの選択方法について説明します。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## カスタムリソース
+
+*リソース* は、[Kubernetes API](/docs/reference/using-api/api-overview/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。
+
+*カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
+
+カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/user-guide/kubectl-overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
+
+## カスタムコントローラー
+
+カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供します。カスタムリソースを *カスタムコントローラー* と組み合わせることで、カスタムリソースは真の _宣言的API_ を提供します。
+
+[宣言的API](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetesオブジェクトを理解する)は、リソースのあるべき状態を _宣言_ または指定することを可能にし、Kubernetesオブジェクトの現在の状態を、あるべき状態に同期し続けるように動きます。
+コントローラーは、構造化データをユーザーが指定したあるべき状態と解釈し、その状態を管理し続けます。
+
+稼働しているクラスターのライフサイクルとは無関係に、カスタムコントローラーをデプロイ、更新することが可能です。カスタムコントローラーはあらゆるリソースと連携できますが、カスタムリソースと組み合わせると特に効果を発揮します。[オペレーターパターン](https://coreos.com/blog/introducing-operators.html)は、カスタムリソースとカスタムコントローラーの組み合わせです。カスタムコントローラーにより、特定アプリケーションのドメイン知識を、Kubernetes APIの拡張に変換することができます。
+
+## カスタムリソースをクラスターに追加するべきか？
+
+新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。
+
+| APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: |
+| ------------------------------ | ---------------------------- |
+| APIが[宣言的](#宣言的API) | APIが[宣言的](#宣言的API)モデルに適さない |
+| 新しいリソースを`kubectl`を使い読み込み、書き込みしたい| `kubectl`のサポートは必要ない |
+| 新しいリソースをダッシュボードのような、Kubernetes UIで他のビルトインリソースと同じように管理したい | Kubernetes UIのサポートは必要ない |
+| 新しいAPIを開発している | APIを提供し、適切に機能するプログラムが既に存在している |
+| APIグループ、名前空間というような、RESTリソースパスに割り当てられた、Kubernetesのフォーマット仕様の制限を許容できる([API概要](/ja/docs/concepts/overview/kubernetes-api/)を参照) | 既に定義済みのREST APIと互換性を持っていなければならない |
+| リソースはクラスターごとか、クラスター内の名前空間に自然に分けることができる | クラスター、または名前空間による分割がリソース管理に適さない。特定のリソースパスに基づいて管理したい |
+| [Kubernetes APIサポート機能](#一般的な機能)を再利用したい | これらの機能は必要ない |
+
+### 宣言的API
+
+宣言的APIは、通常、下記に該当します:
+
+ - APIは、比較的少数の、比較的小さなオブジェクト(リソース)で構成されている
+ - オブジェクトは、アプリケーションの設定、インフラストラクチャーを定義する
+ - オブジェクトは、比較的更新頻度が低い
+ - 人は、オブジェクトの情報をよく読み書きする
+ - オブジェクトに対する主要な手続きは、CRUD(作成、読み込み、更新、削除)になる
+ - 複数オブジェクトをまたいだトランザクションは必要ない: APIは今現在の状態ではなく、あるべき状態を表現する
+
+命令的APIは、宣言的ではありません。
+APIが宣言的ではない兆候として、次のものがあります:
+
+ - クライアントから"これを実行"と命令がきて、完了の返答を同期的に受け取る
+ - クライアントから"これを実行"と命令がきて、処理IDを取得する。そして処理が完了したかどうかを、処理IDを利用して別途問い合わせる
+ - リモートプロシージャコール(RPC)という言葉が飛び交っている
+ - 直接、大量のデータを格納している(例、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い)
+ - 高帯域アクセス(持続的に毎秒数十リクエスト)が必要
+ - エンドユーザーのデータ(画像、PII、その他)を格納している、またはアプリケーションが処理する大量のデータを格納している
+ - オブジェクトに対する処理が、CRUDではない
+ - APIをオブジェクトとして簡単に表現できない
+ - 停止している処理を処理ID、もしくは処理オブジェクトで表現することを選択している
+
+## ConfigMapとカスタムリソースのどちらを使うべきか?
+
+下記のいずれかに該当する場合は、ConfigMapを使ってください:
+
+* `mysql.cnf`、`pom.xml`のような、十分に文書化された設定ファイルフォーマットが既に存在している
+* 単一キーのConfigMapに、設定ファイルの内容の全てを格納している
+* 設定ファイルの主な用途は、クラスター上のPodで実行されているプログラムがファイルを読み込み、それ自体を構成することである
+* ファイルの利用者は、Kubernetes APIよりも、Pod内のファイルまたはPod内の環境変数を介して利用することを好む
+* ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい
+
+{{< note >}}
+センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください
+{{< /note >}}
+
+下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください:
+
+* 新しいリソースを作成、更新するために、Kubernetesのクライアントライブラリー、CLIを使いたい
+* kubectlのトップレベルサポートが欲しい(例、`kubectl get my-object object-name`)
+* 新しい自動化の仕組みを作り、新しいオブジェクトの更新をウォッチしたい、その更新を契機に他のオブジェクトのCRUDを実行したい、またはその逆を行いたい
+* オブジェクトの更新を取り扱う、自動化の仕組みを書きたい
+* `.spec`、`.status`、`.metadata`というような、Kubernetes APIの慣習を使いたい
+* オブジェクトは、制御されたリソースコレクションの抽象化、または他のリソースのサマリーとしたい
+
+## カスタムリソースを追加する
+
+Kubernetesは、クラスターへカスタムリソースを追加する2つの方法を提供しています:
+
+- CRDはシンプルで、プログラミングなしに作成可能
+- [APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、プログラミングが必要だが、データがどのように格納され、APIバージョン間でどのように変換されるかというような、より詳細なAPIの振る舞いを制御できる
+
+Kubernetesは、さまざまなユーザーのニーズを満たすためにこれら2つのオプションを提供しており、使いやすさや柔軟性が損なわれることはありません。
+
+アグリゲートAPIは、プロキシーとして機能するプライマリAPIサーバーの背後にある、下位のAPIServerです。このような配置は[APIアグリゲーション](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA)と呼ばれています。ユーザーにとっては、単にAPIサーバーが拡張されているように見えます。
+
+CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類のリソースを作成できます。CRDを使うには、APIアグリゲーションを理解する必要はありません。
+
+どのようにインストールされたかに関わらず、新しいリソースはカスタムリソースとして参照され、ビルトインのKubernetesリソース(Podなど)とは区別されます。
+
+## CustomResourceDefinition
+
+[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。
+
+これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。
+
+新しいカスタムリソースをどのように登録するか、新しいリソースタイプとの連携、そしてコントローラーを使いイベントを処理する方法例について、[カスタムコントローラー例](https://github.com/kubernetes/sample-controller)を参照してください。
+
+## APIサーバーアグリゲーション
+
+通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、また[CRD](#customresourcedefinition)を通じて、同じ方法でカスタムリソースも管理できます。
+
+[アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。
+
+## カスタムリソースの追加方法を選択する
+
+CRDは簡単に使えます。アグリゲートAPIはより柔軟です。ニーズに最も合う方法を選択してください。
+
+通常、CRDは下記の場合に適しています:
+
+* 少数のフィールドしか必要ない
+* そのリソースは社内のみで利用している、または小さいオープンソースプロジェクトの一部で利用している(商用プロダクトではない)
+
+### 使いやすさの比較
+
+CRDは、アグリゲートAPIと比べ、簡単に作れます。
+
+| CRD                        | アグリゲートAPI |
+| -------------------------- | --------------- |
+| プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要。ユーザーはCRDコントローラーとしてどの言語でも選択可能 |
+| 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある |
+| CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない |
+| 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 |
+
+### 高度な機能、柔軟性
+
+アグリゲートAPIは、例えばストレージレイヤーのカスタマイズのような、より高度なAPI機能と他の機能のカスタマイズを可能にします。
+
+| 機能 | 詳細 | CRD | アグリゲートAPI |
+| ---- | ---- | --- | --------------- |
+| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 |
+| デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.16でベータ)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9)を通じて可能 | はい |
+| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい |
+| カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい |
+| カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい |
+| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい |
+| サブリソースの状態 | <ul><li>より詳細なアクセスコントロール: ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む</li><li>カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソースがspecと、statusでセクションが分離している必要がある)</li></ul> | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい |
+| その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい |
+| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい |
+| プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい |
+| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(スワッガー)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい |
+
+### 一般的な機能
+
+CRD、またはアグリゲートAPI、どちらを使ってカスタムリソースを作った場合でも、Kubernetesプラットフォーム外でAPIを実装するのに比べ、多数の機能が提供されます:
+
+| 機能 | 何を実現するか |
+| ---- | -------------- |
+| CRUD | 新しいエンドポイントが、HTTP、`kubectl`を通じて、基本的なCRUD処理をサポート |
+| Watch | 新しいエンドポイントが、HTTPを通じて、KubernetesのWatch処理をサポート |
+| Discovery | kubectlやダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 |
+| json-patch | 新しいエンドポイントが`Content-Type: application/json-patch+json`を用いたPATCHをサポート |
+| merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート |
+| HTTPS | 新しいエンドポイントがHTTPSを利用 |
+| ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 |
+| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可機構を再利用(例、RBAC) |
+| ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック |
+| Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 |
+| UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 |
+| 未設定 vs 空設定 | クライアントは、フィールドの未設定とゼロ値を区別することができる |
+| クライアントライブラリーの生成 | Kubernetesは、一般的なクライアントライブラリーと、タイプ固有のクライアントライブラリーを生成するツールを提供 |
+| ラベルとアノテーション | ツールがコアリソースとカスタムリソースの編集方法を知っているオブジェクト間で、共通のメタデータを提供 |
+
+## カスタムリソースのインストール準備
+
+クラスターにカスタムリソースを追加する前に、いくつか認識しておくべき事項があります。
+
+### サードパーティのコードと新しい障害点
+
+CRDを作成しても、勝手に新しい障害点が追加されてしまうことはありませんが（たとえば、サードパーティのコードをAPIサーバーで実行することによって）、パッケージ（たとえば、チャート）またはその他のインストールバンドルには、多くの場合、CRDと新しいカスタムリソースのビジネスロジックを実装するサードパーティコードが入ったDeploymentが含まれます。
+
+アグリゲートAPIサーバーのインストールすると、常に新しいDeploymentが付いてきます。
+
+### ストレージ
+
+カスタムリソースは、ConfigMapと同じ方法でストレージの容量を消費します。多数のカスタムリソースを作成すると、APIサーバーのストレージ容量を超えてしまうかもしれません。
+
+アグリゲートAPIサーバーも、メインのAPIサーバーと同じストレージを利用するかもしれません。その場合、同じ問題が発生しえます。
+
+### 認証、認可、そして監査
+
+CRDでは、APIサーバーのビルトインリソースと同じ認証、認可、そして監査ロギングの仕組みを利用します。
+
+もしRBACを使っている場合、ほとんどのRBACのロールは新しいリソースへのアクセスを許可しません。(クラスター管理者ロール、もしくはワイルドカードで作成されたロールを除く)新しいリソースには、明示的にアクセスを許可する必要があります。多くの場合、CRDおよびアグリゲートAPIには、追加するタイプの新しいロール定義がバンドルされています。
+
+アグリゲートAPIサーバーでは、APIサーバーのビルトインリソースと同じ認証、認可、そして監査の仕組みを使う場合と使わない場合があります。
+
+## カスタムリソースへのアクセス
+
+Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、GoとPythonのライブラリーはサポートしています。
+
+カスタムリソースは、下記のような方法で操作できます:
+
+- kubectl
+- kubernetesの動的クライアント
+- 自作のRESTクライアント
+- [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ
+* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ
+
+{{% /capture %}}
@@ -1,5 +1,4 @@
 ---
-title: "Overview"
+title: "概要"
 weight: 20
 ---
-
@@ -8,7 +8,15 @@ card:
 ---

 {{% capture overview %}}
+Kubernetesをデプロイすると、クラスターが展開されます。
+{{< glossary_definition term_id="cluster" length="all" prepend="クラスターは、">}}
+
 このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。
+
+すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。
+
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
+
 {{% /capture %}}

 {{% capture body %}}
@@ -106,7 +114,8 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ

 {{% /capture %}}
 {{% capture whatsnext %}}
-* [ノード](/docs/concepts/architecture/nodes/) について学ぶ
-* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) について学ぶ
-* etcdの公式 [ドキュメント](https://etcd.io/docs/) を読む
+* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ
+* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ
+* [kube-scheduler](/ja/docs/concepts/scheduling/kube-scheduler/)について学ぶ
+* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む
 {{% /capture %}}
@@ -1,5 +1,5 @@
 ---
-title: "Working with Kubernetes Objects"
+title: "Kubernetesのオブジェクトについて"
 weight: 40
 ---

@@ -0,0 +1,74 @@
+---
+title: スケジューラーのパフォーマンスチューニング
+content_template: templates/concept
+weight: 70
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="1.14" state="beta" >}}
+
+[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。
+
+クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。
+
+このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## スコア付けするノードの割合
+
+Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するための機構があります。この機構では100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。
+
+`percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1alpha1
+kind: KubeSchedulerConfiguration
+algorithmSource:
+  provider: DefaultProvider
+
+...
+
+percentageOfNodesToScore: 50
+```
+
+{{< note >}} 
+割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。
+{{< /note >}}
+
+**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。  
+
+
+### percentageOfNodesToScoreのチューニング
+
+`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。
+
+この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
+
+クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。
+
+### スケジューラーはどのようにノードを探索するか
+
+このセクションでは、この機能の内部の詳細を理解したい人向けになります。
+
+クラスター内の全てのノードに対して平等にPodの割り当ての可能性を持たせるため、スケジューラーはラウンドロビン方式でノードを探索します。複数のノードの配列になっているイメージです。スケジューラーはその配列の先頭から探索を開始し、`percentageOfNodesToScore`によって指定された数のノードを検出するまで、割り当て可能かどうかをチェックしていきます。次のPodでは、スケジューラーは前のPodの割り当て処理でチェックしたところから探索を再開します。
+
+ノードが複数のゾーンに存在するとき、スケジューラーは様々なゾーンのノードを探索して、異なるゾーンのノードが割り当て可能かどうかのチェック対象になるようにします。例えば2つのゾーンに6つのノードがある場合を考えます。
+
+```
+Zone 1: Node 1, Node 2, Node 3, Node 4
+Zone 2: Node 5, Node 6
+```
+
+スケジューラーは、下記の順番でノードの割り当て可能性を評価します。
+
+```
+Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
+```
+
+全てのノードのチェックを終えたら、1番目のノードに戻ってチェックをします。
+
+{{% /capture %}}
@@ -0,0 +1,420 @@
+---
+title: サービスとアプリケーションの接続
+content_template: templates/concept
+weight: 30
+---
+
+
+{{% capture overview %}}
+
+## コンテナを接続するためのKubernetesモデル
+
+継続的に実行され、複製されたアプリケーションの準備ができたので、ネットワーク上で公開することが可能になります。
+Kubernetesのネットワークのアプローチについて説明する前に、Dockerの「通常の」ネットワーク手法と比較することが重要です。
+
+デフォルトでは、Dockerはホストプライベートネットワーキングを使用するため、コンテナは同じマシン上にある場合にのみ他のコンテナと通信できます。
+Dockerコンテナがノード間で通信するには、マシンのIPアドレスにポートを割り当ててから、コンテナに転送またはプロキシする必要があります。
+これは明らかに、コンテナが使用するポートを非常に慎重に調整するか、ポートを動的に割り当てる必要があることを意味します。
+
+複数の開発者間でポートを調整することは大規模に行うことは非常に難しく、ユーザーが制御できないクラスターレベルの問題にさらされます。
+Kubernetesでは、どのホストで稼働するかに関わらず、Podが他のPodと通信できると想定しています。
+すべてのPodに独自のクラスタープライベートIPアドレスを付与するため、Pod間のリンクを明示的に作成したり、コンテナポートをホストポートにマップしたりする必要はありません。
+これは、Pod内のコンテナがすべてlocalhostの相互のポートに到達でき、クラスター内のすべてのPodがNATなしで相互に認識できることを意味します。
+このドキュメントの残りの部分では、このようなネットワークモデルで信頼できるサービスを実行する方法について詳しく説明します。
+
+このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。
+同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Podをクラスターに公開する
+
+前の例でネットワークモデルを紹介しましたが、再度ネットワークの観点に焦点を当てましょう。
+nginx Podを作成し、コンテナポートの仕様を指定していることに注意してください。
+
+{{< codenew file="service/networking/run-my-nginx.yaml" >}}
+
+これにより、クラスター内のどのノードからでもアクセスできるようになります。
+Podが実行されているノードを確認します:
+
+```shell
+kubectl apply -f ./run-my-nginx.yaml
+kubectl get pods -l run=my-nginx -o wide
+```
+```
+NAME                        READY     STATUS    RESTARTS   AGE       IP            NODE
+my-nginx-3800858182-jr4a2   1/1       Running   0          13s       10.244.3.4    kubernetes-minion-905m
+my-nginx-3800858182-kna2y   1/1       Running   0          13s       10.244.2.5    kubernetes-minion-ljyd
+```
+
+PodのIPを確認します:
+
+```shell
+kubectl get pods -l run=my-nginx -o yaml | grep podIP
+    podIP: 10.244.3.4
+    podIP: 10.244.2.5
+```
+
+クラスター内の任意のノードにSSH接続し、両方のIPにcurl接続できるはずです。
+コンテナはノードでポート80を使用**していない**ことに注意してください。
+また、Podにトラフィックをルーティングする特別なNATルールもありません。
+つまり、同じcontainerPortを使用して同じノードで複数のnginx Podを実行し、IPを使用してクラスター内の他のPodやノードからそれらにアクセスできます。
+Dockerと同様に、ポートは引き続きホストノードのインターフェイスに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。
+
+興味があれば、これを[どのように達成するか](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
+
+## Serviceを作成する
+
+そのため、フラットでクラスター全体のアドレス空間でnginxを実行するPodがあります。
+理論的には、これらのPodと直接通信することができますが、ノードが停止するとどうなりますか？
+Podはそれで死に、Deploymentは異なるIPを持つ新しいものを作成します。
+これは、Serviceが解決する問題です。
+
+Kubernetes Serviceは、クラスター内のどこかで実行されるPodの論理セットを定義する抽象化であり、すべて同じ機能を提供します。
+作成されると、各Serviceには一意のIPアドレス(clusterIPとも呼ばれます)が割り当てられます。
+このアドレスはServiceの有効期間に関連付けられており、Serviceが動作している間は変更されません。
+Podは、Serviceと通信するように構成でき、Serviceへの通信は、ServiceのメンバーであるPodに自動的に負荷分散されることを認識できます。
+
+2つのnginxレプリカのサービスを`kubectl exposed`で作成できます:
+
+```shell
+kubectl expose deployment/my-nginx
+```
+```
+service/my-nginx exposed
+```
+
+これは次のyamlを`kubectl apply -f`することと同等です:
+
+{{< codenew file="service/networking/nginx-svc.yaml" >}}
+
+この仕様は、`run：my-nginx`ラベルを持つ任意のPodのTCPポート80をターゲットとするサービスを作成し、抽象化されたサービスポートでPodを公開します(`targetPort`:はコンテナがトラフィックを受信するポート、`port`:は抽象化されたServiceのポートであり、他のPodがServiceへのアクセスに使用する任意のポートにすることができます)。
+サービス定義でサポートされているフィールドのリストは[Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) APIオブジェクトを参照してください。
+
+Serviceを確認します:
+
+```shell
+kubectl get svc my-nginx
+```
+```
+NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
+my-nginx   ClusterIP   10.0.162.149   <none>        80/TCP    21s
+```
+
+前述のように、ServiceはPodのグループによってサポートされています。
+これらのPodはエンドポイントを通じて公開されます。
+Serviceのセレクターは継続的に評価され、結果は`my-nginx`という名前のEndpointオブジェクトにPOSTされます。
+Podが終了すると、エンドポイントから自動的に削除され、Serviceのセレクターに一致する新しいPodが自動的にエンドポイントに追加されます。
+エンドポイントを確認し、IPが最初のステップで作成されたPodと同じであることを確認します:
+
+```shell
+kubectl describe svc my-nginx
+```
+```
+Name:                my-nginx
+Namespace:           default
+Labels:              run=my-nginx
+Annotations:         <none>
+Selector:            run=my-nginx
+Type:                ClusterIP
+IP:                  10.0.162.149
+Port:                <unset> 80/TCP
+Endpoints:           10.244.2.5:80,10.244.3.4:80
+Session Affinity:    None
+Events:              <none>
+```
+```shell
+kubectl get ep my-nginx
+```
+```
+NAME       ENDPOINTS                     AGE
+my-nginx   10.244.2.5:80,10.244.3.4:80   1m
+```
+
+クラスター内の任意のノードから、`<CLUSTER-IP>:<PORT>`でnginx Serviceにcurl接続できるようになりました。
+Service IPは完全に仮想的なもので、ホスト側のネットワークには接続できないことに注意してください。
+この仕組みに興味がある場合は、[サービスプロキシー](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)の詳細をお読みください。
+
+## Serviceにアクセスする
+
+Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
+前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
+{{< note >}}
+サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
+{{< /note >}}
+
+
+### 環境変数
+
+ノードでPodが実行されると、kubeletはアクティブな各サービスの環境変数のセットを追加します。
+これにより、順序付けの問題が発生します。
+理由を確認するには、実行中のnginx Podの環境を調べます(Pod名は環境によって異なります):
+
+```shell
+kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
+```
+```
+KUBERNETES_SERVICE_HOST=10.0.0.1
+KUBERNETES_SERVICE_PORT=443
+KUBERNETES_SERVICE_PORT_HTTPS=443
+```
+
+サービスに言及がないことに注意してください。これは、サービスの前にレプリカを作成したためです。
+これのもう1つの欠点は、スケジューラーが両方のPodを同じマシンに配置し、サービスが停止した場合にサービス全体がダウンする可能性があることです。
+2つのPodを強制終了し、Deploymentがそれらを再作成するのを待つことで、これを正しい方法で実行できます。
+今回は、サービスはレプリカの「前」に存在します。
+これにより、スケジューラーレベルのサービスがPodに広がり(すべてのノードの容量が等しい場合)、適切な環境変数が提供されます:
+
+```shell
+kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
+
+kubectl get pods -l run=my-nginx -o wide
+```
+```
+NAME                        READY     STATUS    RESTARTS   AGE     IP            NODE
+my-nginx-3800858182-e9ihh   1/1       Running   0          5s      10.244.2.7    kubernetes-minion-ljyd
+my-nginx-3800858182-j4rm4   1/1       Running   0          5s      10.244.3.8    kubernetes-minion-905m
+```
+
+Podは強制終了されて再作成されるため、異なる名前が付いていることに気付くでしょう。
+
+```shell
+kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
+```
+```
+KUBERNETES_SERVICE_PORT=443
+MY_NGINX_SERVICE_HOST=10.0.162.149
+KUBERNETES_SERVICE_HOST=10.0.0.1
+MY_NGINX_SERVICE_PORT=80
+KUBERNETES_SERVICE_PORT_HTTPS=443
+```
+
+### DNS
+
+Kubernetesは、DNS名を他のServiceに自動的に割り当てるDNSクラスターアドオンサービスを提供します。
+クラスターで実行されているかどうかを確認できます:
+
+```shell
+kubectl get services kube-dns --namespace=kube-system
+```
+```
+NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
+kube-dns   ClusterIP   10.0.0.10    <none>        53/UDP,53/TCP   8m
+```
+
+実行されていない場合は、[有効にする](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it)ことができます。
+このセクションの残りの部分では、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバー(CoreDNSクラスターアドオン)があることを前提としているため、標準的な方法(gethostbynameなど)を使用してクラスター内の任意のPodからServiceに通信できます。
+curlアプリケーションを実行して、これをテストしてみましょう:
+
+```shell
+kubectl run curl --image=radial/busyboxplus:curl -i --tty
+```
+```
+Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
+Hit enter for command prompt
+```
+
+次に、Enterキーを押して`nslookup my-nginx`を実行します:
+
+```shell
+[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
+Server:    10.0.0.10
+Address 1: 10.0.0.10
+
+Name:      my-nginx
+Address 1: 10.0.162.149
+```
+
+## Serviceを安全にする
+
+これまでは、クラスター内からnginxサーバーにアクセスしただけでした。
+サービスをインターネットに公開する前に、通信チャネルが安全であることを確認する必要があります。
+これには、次のものが必要です:
+
+* https用の自己署名証明書(既にID証明書を持っている場合を除く)
+* 証明書を使用するように構成されたnginxサーバー
+* Podが証明書にアクセスできるようにする[Secret](/docs/concepts/configuration/secret/)
+
+これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
+これにはツールをインストールする必要があります。
+これらをインストールしたくない場合は、後で手動の手順に従ってください。つまり:
+
+```shell
+make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
+kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
+```
+```
+secret/nginxsecret created
+```
+```shell
+kubectl get secrets
+```
+```
+NAME                  TYPE                                  DATA      AGE
+default-token-il9rc   kubernetes.io/service-account-token   1         1d
+nginxsecret           Opaque                                2         1m
+```
+以下は、(Windows上など)makeの実行で問題が発生した場合に実行する手動の手順です:
+
+```shell
+# 公開秘密鍵ペアを作成します
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
+# キーをbase64エンコードに変換します
+cat /d/tmp/nginx.crt | base64
+cat /d/tmp/nginx.key | base64
+```
+前のコマンドの出力を使用して、次のようにyamlファイルを作成します。
+base64でエンコードされた値はすべて1行である必要があります。
+
+```yaml
+apiVersion: "v1"
+kind: "Secret"
+metadata:
+  name: "nginxsecret"
+  namespace: "default"
+data:
+  nginx.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
+  nginx.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
+```
+ファイルを使用してSecretを作成します:
+
+```shell
+kubectl apply -f nginxsecrets.yaml
+kubectl get secrets
+```
+```
+NAME                  TYPE                                  DATA      AGE
+default-token-il9rc   kubernetes.io/service-account-token   1         1d
+nginxsecret           Opaque                                2         1m
+```
+
+次に、nginxレプリカを変更して、シークレットの証明書とServiceを使用してhttpsサーバーを起動し、両方のポート(80と443)を公開します:
+
+{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
+
+nginx-secure-appマニフェストに関する注目すべき点:
+
+- 同じファイルにDeploymentとServiceの両方が含まれています。
+- [nginxサーバー](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)はポート80のHTTPトラフィックと443のHTTPSトラフィックを処理し、nginx Serviceは両方のポートを公開します。
+- 各コンテナは`/etc/nginx/ssl`にマウントされたボリュームを介してキーにアクセスできます。
+  これは、nginxサーバーが起動する*前に*セットアップされます。
+
+```shell
+kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
+```
+
+この時点で、任意のノードからnginxサーバーに到達できます。
+
+```shell
+kubectl get pods -o yaml | grep -i podip
+    podIP: 10.244.3.5
+node $ curl -k https://10.244.3.5
+...
+<h1>Welcome to nginx!</h1>
+```
+
+最後の手順でcurlに`-k`パラメーターを指定したことに注意してください。
+これは、証明書の生成時にnginxを実行しているPodについて何も知らないためです。
+CNameの不一致を無視するようcurlに指示する必要があります。
+Serviceを作成することにより、証明書で使用されるCNameを、Service検索中にPodで使用される実際のDNS名にリンクしました。
+これをPodからテストしましょう(簡単にするために同じシークレットを再利用しています。PodはServiceにアクセスするためにnginx.crtのみを必要とします):
+
+{{< codenew file="service/networking/curlpod.yaml" >}}
+
+```shell
+kubectl apply -f ./curlpod.yaml
+kubectl get pods -l app=curlpod
+```
+```
+NAME                               READY     STATUS    RESTARTS   AGE
+curl-deployment-1515033274-1410r   1/1       Running   0          1m
+```
+```shell
+kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt
+...
+<title>Welcome to nginx!</title>
+...
+```
+
+## Serviceを公開する
+
+アプリケーションの一部では、Serviceを外部IPアドレスに公開したい場合があります。
+Kubernetesは、NodePortとLoadBalancerの2つの方法をサポートしています。
+前のセクションで作成したServiceはすでに`NodePort`を使用しているため、ノードにパブリックIPがあれば、nginx HTTPSレプリカはインターネット上のトラフィックを処理する準備ができています。
+
+```shell
+kubectl get svc my-nginx -o yaml | grep nodePort -C 5
+  uid: 07191fb3-f61a-11e5-8ae5-42010af00002
+spec:
+  clusterIP: 10.0.162.149
+  ports:
+  - name: http
+    nodePort: 31704
+    port: 8080
+    protocol: TCP
+    targetPort: 80
+  - name: https
+    nodePort: 32453
+    port: 443
+    protocol: TCP
+    targetPort: 443
+  selector:
+    run: my-nginx
+```
+```shell
+kubectl get nodes -o yaml | grep ExternalIP -C 1
+    - address: 104.197.41.11
+      type: ExternalIP
+    allocatable:
+--
+    - address: 23.251.152.56
+      type: ExternalIP
+    allocatable:
+...
+
+$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
+...
+<h1>Welcome to nginx!</h1>
+```
+
+クラウドロードバランサーを使用するようにサービスを再作成しましょう。
+`my-nginx`サービスの`Type`を`NodePort`から`LoadBalancer`に変更するだけです:
+
+```shell
+kubectl edit svc my-nginx
+kubectl get svc my-nginx
+```
+```
+NAME       TYPE        CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
+my-nginx   ClusterIP   10.0.162.149   162.222.184.144    80/TCP,81/TCP,82/TCP  21s
+```
+```
+curl https://<EXTERNAL-IP> -k
+...
+<title>Welcome to nginx!</title>
+```
+
+`EXTERNAL-IP`列のIPアドレスは、パブリックインターネットで利用可能なものです。
+`CLUSTER-IP`は、クラスター/プライベートクラウドネットワーク内でのみ使用できます。
+
+AWSでは、type `LoadBalancer`はIPではなく(長い)ホスト名を使用するELBが作成されます。
+実際、標準の`kubectl get svc`の出力に収まるには長すぎるので、それを確認するには`kubectl describe service my-nginx`を実行する必要があります。
+次のようなものが表示されます:
+
+```shell
+kubectl describe service my-nginx
+...
+LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
+...
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+Kubernetesは、複数のクラスターおよびクラウドプロバイダーにまたがるフェデレーションサービスもサポートし、可用性の向上、フォールトトレランスの向上、サービスのスケーラビリティの向上を実現します。
+詳細については[フェデレーションサービスユーザーガイド](/docs/concepts/cluster-administration/federation-service-discovery/)を参照してください。
+
+{{% /capture %}}
@@ -0,0 +1,403 @@
+---
+title: Ingress
+content_template: templates/concept
+weight: 40
+---
+
+{{% capture overview %}}
+{{< feature-state for_k8s_version="v1.1" state="beta" >}}
+{{< glossary_definition term_id="ingress" length="all" >}}
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 用語
+
+まずわかりやすくするために、このガイドでは次の用語を定義します。
+
+- ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
+
+- クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。  
+  
+- エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
+
+- クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
+
+- Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
+
+## Ingressとは何か
+
+Ingressはクラスター外からクラスター内{{< link text="Service" url="/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
+
+```none
+    internet
+        |
+   [ Ingress ]
+   --|-----|--
+   [ Services ]
+```
+
+IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように構成できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
+
+Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開するときは、[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを使用することが多いです。
+
+## Ingressを使用する上での前提条件
+
+Ingressの機能を提供するために[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)を用意する必要があります。Ingressリソースを作成するのみでは何の効果もありません。
+
+[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。ユーザーはいくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択できます。
+
+理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすべきです。しかし実際には、いくつかのIngressコントローラーは微妙に異なる動作をします。
+
+{{< note >}}
+Ingressコントローラーのドキュメントを確認して、選択する際の注意点について理解してください。
+{{< /note >}}
+
+## Ingressリソース
+
+Ingressリソースの最小構成の例は下記のとおりです。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: Ingress
+metadata:
+  name: test-ingress
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /testpath
+        backend:
+          serviceName: test
+          servicePort: 80
+```
+
+他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナーの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。  
+Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを使うことが多いです。その例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。  
+[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶために、ユーザーが使用するIngressコントローラーのドキュメントを確認してください。
+
+Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。
+
+### Ingressのルール
+
+各HTTPルールは下記の情報を含みます。
+
+* オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
+* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
+* [Serviceドキュメント](/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
+
+Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
+
+### デフォルトのバックエンド
+
+ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
+
+IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
+
+## Ingressのタイプ
+
+### 単一ServiceのIngress
+ユーザーは単一のServiceを公開できるという、Kubernetesのコンセプトがあります([Ingressの代替案](#alternatives)を参照してください)。
+また、Ingressでこれを実現できます。それはルールを設定せずに*デフォルトのバックエンド* を指定することにより可能です。
+
+{{< codenew file="service/networking/ingress.yaml" >}}
+
+`kubectl apply -f`を実行してIngressを作成し、その作成したIngressの状態を確認することができます。
+
+```shell
+kubectl get ingress test-ingress
+```
+
+```
+NAME           HOSTS     ADDRESS           PORTS     AGE
+test-ingress   *         107.178.254.228   80        59s
+```
+
+`107.178.254.228`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
+
+{{< note >}}
+IngressコントローラーとロードバランサーがIPアドレス割り当てるのに1、2分ほどかかります。この間、ADDRESSの情報は`<pending>`となっているのを確認できます。
+{{< /note >}}
+
+### リクエストのシンプルなルーティング
+
+ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによって、ユーザーはロードバランサーの数を少なくできます。例えば、下記のように設定します。
+
+```none
+foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
+                                 / bar    service2:8080
+```
+
+Ingressを下記のように設定します。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: Ingress
+metadata:
+  name: simple-fanout-example
+  annotations:
+    nginx.ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - path: /foo
+        backend:
+          serviceName: service1
+          servicePort: 4200
+      - path: /bar
+        backend:
+          serviceName: service2
+          servicePort: 8080
+```
+
+Ingressを`kubectl apply -f`によって作成したとき:
+
+```shell
+kubectl describe ingress simple-fanout-example
+```
+
+```
+Name:             simple-fanout-example
+Namespace:        default
+Address:          178.91.123.132
+Default backend:  default-http-backend:80 (10.8.2.3:8080)
+Rules:
+  Host         Path  Backends
+  ----         ----  --------
+  foo.bar.com
+               /foo   service1:4200 (10.8.0.90:4200)
+               /bar   service2:8080 (10.8.0.91:8080)
+Annotations:
+  nginx.ingress.kubernetes.io/rewrite-target:  /
+Events:
+  Type     Reason  Age                From                     Message
+  ----     ------  ----               ----                     -------
+  Normal   ADD     22s                loadbalancer-controller  default/test
+```
+
+IngressコントローラーはService(`service1`、`service2`)が存在する限り、Ingressの条件を満たす実装固有のロードバランサーを構築します。
+構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
+
+{{< note >}}
+ユーザーが使用している[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、ユーザーはdefault-http-backend[Service](/docs/concepts/services-networking/service/)の作成が必要な場合があります。
+{{< /note >}}
+
+### 名前ベースの仮想ホスティング
+
+名前ベースの仮想ホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。
+
+```none
+foo.bar.com --|                 |-> foo.bar.com service1:80
+              | 178.91.123.132  |
+bar.foo.com --|                 |-> bar.foo.com service2:80
+```
+
+下記のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: service1
+          servicePort: 80
+  - host: bar.foo.com
+    http:
+      paths:
+      - backend:
+          serviceName: service2
+          servicePort: 80
+```
+
+rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースの仮想ホストなしにマッチさせることができます。
+
+例えば、下記のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: Ingress
+metadata:
+  name: name-virtual-host-ingress
+spec:
+  rules:
+  - host: first.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: service1
+          servicePort: 80
+  - host: second.foo.com
+    http:
+      paths:
+      - backend:
+          serviceName: service2
+          servicePort: 80
+  - http:
+      paths:
+      - backend:
+          serviceName: service3
+          servicePort: 80
+```
+
+### TLS
+
+TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。現在Ingressは単一のTLSポートである443番ポートのみサポートし、TLS終端を行うことを想定しています。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。下記が例となります。
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: testsecret-tls
+  namespace: default
+data:
+  tls.crt: base64 encoded cert
+  tls.key: base64 encoded key
+type: kubernetes.io/tls
+```
+
+IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`sslexample.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
+
+```yaml
+apiVersion: networking.k8s.io/v1beta1
+kind: Ingress
+metadata:
+  name: tls-example-ingress
+spec:
+  tls:
+  - hosts:
+    - sslexample.foo.com
+    secretName: testsecret-tls
+  rules:
+    - host: sslexample.foo.com
+      http:
+        paths:
+        - path: /
+          backend:
+            serviceName: service1
+            servicePort: 80
+```
+
+{{< note >}}
+Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://git.k8s.io/ingress-nginx/README.md#https)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
+{{< /note >}}
+
+### 負荷分散
+
+Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
+
+Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+
+## Ingressの更新
+
+リソースを編集することで、既存のIngressに対して新しいホストを追加することができます。
+
+```shell
+kubectl describe ingress test
+```
+
+```
+Name:             test
+Namespace:        default
+Address:          178.91.123.132
+Default backend:  default-http-backend:80 (10.8.2.3:8080)
+Rules:
+  Host         Path  Backends
+  ----         ----  --------
+  foo.bar.com
+               /foo   service1:80 (10.8.0.90:80)
+Annotations:
+  nginx.ingress.kubernetes.io/rewrite-target:  /
+Events:
+  Type     Reason  Age                From                     Message
+  ----     ------  ----               ----                     -------
+  Normal   ADD     35s                loadbalancer-controller  default/test
+```
+
+```shell
+kubectl edit ingress test
+```
+
+このコマンドを実行すると既存の設定をYAMLフォーマットで編集するエディターが表示されます。新しいホストを追加するために、リソースを修正してください。
+
+```yaml
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: service1
+          servicePort: 80
+        path: /foo
+  - host: bar.baz.com
+    http:
+      paths:
+      - backend:
+          serviceName: service2
+          servicePort: 80
+        path: /foo
+..
+```
+
+変更を保存した後、kubectlはAPIサーバー内のリソースを更新し、Ingressコントローラーに対してロードバランサーの再設定を指示します。
+
+変更内容を確認してください。
+
+```shell
+kubectl describe ingress test
+```
+
+```
+Name:             test
+Namespace:        default
+Address:          178.91.123.132
+Default backend:  default-http-backend:80 (10.8.2.3:8080)
+Rules:
+  Host         Path  Backends
+  ----         ----  --------
+  foo.bar.com
+               /foo   service1:80 (10.8.0.90:80)
+  bar.baz.com
+               /foo   service2:80 (10.8.0.91:80)
+Annotations:
+  nginx.ingress.kubernetes.io/rewrite-target:  /
+Events:
+  Type     Reason  Age                From                     Message
+  ----     ------  ----               ----                     -------
+  Normal   ADD     45s                loadbalancer-controller  default/test
+```
+
+修正されたIngressのYAMLファイルに対して`kubectl replace -f`を実行することで、同様の結果を得られます。
+
+## アベイラビリティーゾーンをまたいだ障害について
+
+障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。
+
+## 将来追加予定の内容
+
+Ingressと関連するリソースの今後の開発については[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)で行われている議論を確認してください。様々なIngressコントローラーの開発については[Ingress リポジトリー](https://github.com/kubernetes/ingress/tree/master)を確認してください。
+
+## Ingressの代替案 {#alternatives}
+
+Ingressリソースに直接関与しない複数の方法でServiceを公開できます。
+
+下記の2つの使用を検討してください。
+* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
+* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ
+* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
+{{% /capture %}}
@@ -134,6 +134,13 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設

 ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。

+### エンドポイントスライス
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。
+
+エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
+
 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}

 Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
@@ -149,12 +156,6 @@ Serviceにおいてプロキシーを使う理由はいくつかあります。
 * いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
 * アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。

-### バージョン互換性
-
-Kubernetes v1.0から、[user-spaceプロキシーモード](#proxy-mode-userspace)を利用できるようになっています。  
-v1.1ではiptablesモードでのプロキシーを追加し、v1.2では、kube-proxyにおいてiptablesモードがデフォルトとなりました。  
-v1.8では、ipvsプロキシーモードが追加されました。
-
 ### user-spaceプロキシーモード {#proxy-mode-userspace}

 このモードでは、kube-proxyはServiceやEndpointオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。  
@@ -389,12 +390,11 @@ spec:
    port: 80
    targetPort: 9376
  clusterIP: 10.0.171.239
-  loadBalancerIP: 78.11.24.19
  type: LoadBalancer
 status:
  loadBalancer:
    ingress:
-    - ip: 146.148.47.155
+    - ip: 192.0.2.127
 ```

 外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。  
@@ -437,9 +437,6 @@ metadata:
        cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
-
-Kubernetes1.7.0から1.7.3のMasterに対しては、`cloud.google.com/load-balancer-type: "internal"`を使用します。  
-さらなる情報については、[docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)を参照してください。  
 {{% /tab %}}
 {{% tab name="AWS" %}}
 ```yaml
@@ -481,6 +478,15 @@ metadata:
 [...]
 ```
 {{% /tab %}}
+{{% tab name="Tencent Cloud" %}}
+```yaml
+[...]
+metadata:
+  annotations:
+    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
+[...]
+```
+{{% /tab %}}
 {{< /tabs >}}


@@ -630,13 +636,11 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
        # ELBに追加される予定のセキュリティーグループのリスト
 ```

-#### AWSでのNetwork Load Balancerのサポート [α版] {#aws-nlb-support}
+#### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support}

-{{< warning >}}
-これはα版の機能で、プロダクション環境でのクラスターでの使用はまだ推奨しません。
-{{< /warning >}}
+{{< feature-state for_k8s_version="v1.15" state="beta" >}}

-Kubernetes v1.9.0から、ServiceとAWS Network Load Balancer(NLB)を組み合わせることができます。AWSでのネットワークロードバランサーを使用するためには、`service.beta.kubernetes.io/aws-load-balancer-type`というアノテーションの値を`nlb`に設定してください。
+AWSでNetwork Load Balancerを使用するには、値を`nlb`に設定してアノテーション`service.beta.kubernetes.io/aws-load-balancer-type`を付与します。

 ```yaml
    metadata:
@@ -681,6 +685,38 @@ spec:

 {{< /note >}}

+#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション
+
+以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        # 指定したノードでロードバランサーをバインドします
+        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)
+        # 既存のロードバランサーのID
+        service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx
+
+        # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません
+        service.kubernetes.io/service.extensiveParameters: ""
+
+        # LBリスナーのカスタムパラメーター
+        service.kubernetes.io/service.listenerParameters: ""
+
+        # ロードバランサーのタイプを指定します
+        # 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer)
+        service.kubernetes.io/loadbalance-type: xxxxx
+        # パブリックネットワーク帯域幅の課金方法を指定します
+        # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth)
+        service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx
+        # 帯域幅の値を指定します(値の範囲：[1-2000] Mbps)。
+        service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
+        # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
+        # そうでない場合、すべてのノードが登録されます
+        service.kubernetes.io/local-svc-only-bind-node-with-pod: true
+```
+
 ### ExternalName タイプ {#externalname}

 ExternalNameタイプのServiceは、ServiceをDNS名とマッピングし、`my-service`や`cassandra`というような従来のラベルセレクターとはマッピングしません。  
@@ -708,6 +744,12 @@ IPアドレスをハードコードする場合、[Headless Service](#headless-s
 `my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。  
 後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointを追加し、Serviceの`type`を変更します。

+{{< warning >}}
+HTTPやHTTPSなどの一般的なプロトコルでExternalNameを使用する際に問題が発生する場合があります。ExternalNameを使用する場合、クラスター内のクライアントが使用するホスト名は、ExternalNameが参照する名前とは異なります。
+
+ホスト名を使用するプロトコルの場合、この違いによりエラーまたは予期しない応答が発生する場合があります。HTTPリクエストには、オリジンサーバーが認識しない`Host:`ヘッダーがあります。TLSサーバーは、クライアントが接続したホスト名に一致する証明書を提供できません。
+{{< /warning >}}
+
 {{< note >}}
 このセクションは、[Alen Komljen](https://akomljen.com/)による[Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/)というブログポストを参考にしています。

@@ -905,5 +947,6 @@ Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLo

 * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
+* [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。

 {{% /capture %}}
@@ -1,5 +1,5 @@
 ---
-title: "Storage"
+title: "ストレージ"
 weight: 70
 ---

@@ -1,5 +1,5 @@
 ---
-title: "Workloads"
+title: "ワークロード"
 weight: 50
 ---

@@ -1,5 +1,4 @@
 ---
-title: "Controllers"
+title: "コントローラー"
 weight: 20
 ---
-
@@ -0,0 +1,999 @@
+---
+title: Deployment
+feature:
+  title: 自動化されたロールアウトとロールバック
+  description: >
+    Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymnetのエコシステムを活用してください。
+
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+_Deployment_ コントローラーは[Pod](/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。  
+
+ユーザーはDeploymentにおいて_理想的な状態_ を定義し、Deploymentコントローラーは指定された頻度で現在の状態を理想的な状態に変更させます。ユーザーはDeploymentを定義して、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。
+
+{{< note >}}
+Deploymentによって作成されたReplicaSetを管理しないでください。ユーザーのユースケースが下記の項目をカバーできていない場合はメインのKubernetesリポジトリーにイシューを作成することを検討してください。
+{{< /note >}}
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## ユースケース
+
+下記の項目はDeploymentの典型的なユースケースです。
+
+* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。  
+* DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
+* Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
+* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
+* PodTemplateSpecに対する複数の修正を適用するために[Deploymentを停止(Pause)し](#pausing-and-resuming-a-deployment)、それを再開して新しいロールアウトを開始する。
+* 今後必要としない[古いReplicaSetのクリーンアップ](#clean-up-policy)
+
+## Deploymentの作成 {#creating-a-deployment}
+
+下記の内容はDeploymentの例です。これは`nginx`Podのレプリカを3つ持つReplicaSetを作成します。
+
+{{< codenew file="controllers/nginx-deployment.yaml" >}}
+
+この例において、
+
+* `nginx-deployment`という名前のDeploymentが作成され、`.metadata.name`フィールドで名前を指定します。
+* Deploymentは3つのレプリカPodを作成し、`replicas`フィールドによってレプリカ数を指定します。
+* `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。このケースにおいて、ユーザーはPodテンプレートにて定義されたラベル(`app: nginx`)を選択します。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
+    {{< note >}}
+    `matchLabels`フィールドは、キーとバリューのペアのマップとなります。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しいです。
+    `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
+    {{< /note >}}
+* `template`フィールドは、下記のサブフィールドを持ちます。:
+  * Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられる
+  * PodTemplateの仕様もしくは、`.template.spec`フィールドは、このPodは`nginx`という名前のコンテナーを1つ稼働させ、それは`nginx`というさせ、[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.7.9を使うことを示します
+  * 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます
+
+  上記のDeploymentを作成するために、以下に示すステップにしたがってください。
+  作成を始める前に、ユーザーのKubernetesクラスターが稼働していることを確認してください。
+
+  1. 下記のコマンドを実行してDeploymentを作成してください。
+
+      {{< note >}}
+      実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
+      {{< /note >}}
+
+    ```shell
+    kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
+    ```
+
+  2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。Deploymentがまだ作成中の場合、コマンドの実行結果は下記のとおりです。
+    ```shell
+    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    nginx-deployment   3         0         0            0           1s
+    ```
+    ユーザーのクラスターにおいてDeploymentを調査するとき、下記のフィールドが出力されます。
+
+      * `NAME` クラスター内のDeploymentの名前を表示する
+      * `DESIRED` アプリケーションの理想的な_replicas_ の値を表示する: これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
+      * `CURRENT` 現在稼働中のレプリカ数
+      * `UP-TO-DATE` 理想的な状態にするために、アップデートが完了したレプリカ数
+      * `AVAILABLE` ユーザーが利用可能なレプリカ数
+      * `AGE` アプリケーションが稼働してからの時間
+
+    上記のyamlの例だと、`.spec.replicas`フィールドの値によると、理想的なレプリカ数は3です。
+
+  3. Deploymentのロールアウトステータスを確認するために、`kubectl rollout status deployment.v1.apps/nginx-deployment`を実行してください。コマンドの実行結果は下記のとおりです。
+    ```shell
+    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+    deployment.apps/nginx-deployment successfully rolled out
+    ```
+
+  4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は下記のとおりです。
+    ```shell
+    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    nginx-deployment   3         3         3            3           18s
+    ```
+    Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
+
+  5. Deploymentによって作成されたReplicaSet (`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は下記のとおりです。
+
+    ```shell
+    NAME                          DESIRED   CURRENT   READY   AGE
+    nginx-deployment-75675f5897   3         3         3       18s
+    ```
+    ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
+
+  6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は下記のとおりです。
+    ```shell
+    NAME                                READY     STATUS    RESTARTS   AGE       LABELS
+    nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
+    nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
+    nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
+    ```
+    作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。
+
+  {{< note >}}
+  Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
+  {{< /note >}}
+
+### pod-template-hashラベル
+
+{{< note >}}
+このラベルを変更しないでください。
+{{< /note >}}
+
+`pod-template-hash`ラベルはDeploymentコントローラーによってDeploymentが作成し適用した各ReplicaSetに対して追加されます。
+
+このラベルはDeploymentが管理するReplicaSetが重複しないことを保証します。このラベルはReplicaSetの`PodTemplate`をハッシュ化することにより生成され、生成されたハッシュ値はラベル値としてReplicaSetセレクター、Podテンプレートラベル、ReplicaSetが作成した全てのPodに対して追加されます。
+
+## Deploymentの更新
+
+{{< note >}}
+Deploymentのロールアウトは、DeploymentのPodテンプレート(この場合`.spec.template`)が変更された場合にのみトリガーされます。例えばテンプレートのラベルもしくはコンテナーイメージが更新された場合です。Deploymentのスケールのような更新では、ロールアウトはトリガーされません。
+{{< /note >}}
+
+Deploymentを更新するには下記のステップに従ってください。
+
+1. nginxのPodで、`nginx:1.7.9`イメージの代わりに`nginx:1.9.1`を使うように更新します。
+
+    ```shell
+    kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment image updated
+    ```
+
+    また、Deploymentを`編集`して、`.spec.template.spec.containers[0].image`を`nginx:1.7.9`から`nginx:1.9.1`に変更することができます。
+
+    ```shell
+    kubectl edit deployment.v1.apps/nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment edited
+    ```
+
+2. ロールアウトのステータスを確認するには、下記のコマンドを実行してください。
+
+    ```shell
+    kubectl rollout status deployment.v1.apps/nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+    ```
+    もしくは
+    ```
+    deployment.apps/nginx-deployment successfully rolled out
+    ```
+
+更新されたDeploymentのさらなる情報を取得するには、下記を確認してください。
+
+* ロールアウトが成功したあと、`kubectl get deployments`を実行してDeploymentを確認できます。
+    実行結果は下記のとおりです。
+    ```
+    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    nginx-deployment   3         3         3            3           36s
+    ```
+
+* Deploymentが新しいReplicaSetを作成してPodを更新させたり、新しいReplicaSetのレプリカを3にスケールアップさせたり、古いReplicaSetのレプリカを0にスケールダウンさせるのを確認するには`kubectl get rs`を実行してください。
+
+    ```shell
+    kubectl get rs
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    NAME                          DESIRED   CURRENT   READY   AGE
+    nginx-deployment-1564180365   3         3         3       6s
+    nginx-deployment-2035384211   0         0         0       36s
+    ```
+
+* `get pods`を実行させると、新しいPodのみ確認できます。
+
+    ```shell
+    kubectl get pods
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    NAME                                READY     STATUS    RESTARTS   AGE
+    nginx-deployment-1564180365-khku8   1/1       Running   0          14s
+    nginx-deployment-1564180365-nacti   1/1       Running   0          14s
+    nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
+    ```
+
+    次にPodを更新させたいときは、DeploymentのPodテンプレートを再度更新するだけです。
+
+    Deploymentは、Podが更新されている間に特定の数のPodのみ停止状態になることを保証します。デフォルトでは、目標とするPod数の少なくとも25%が停止状態になることを保証します(25% max unavailable)。
+
+    また、DeploymentはPodが更新されている間に、目標とするPod数を特定の数まで超えてPodを稼働させることを保証します。デフォルトでは、目標とするPod数に対して最大でも25%を超えてPodを稼働させることを保証します(25% max surge)。
+
+    例えば、上記で説明したDeploymentの状態を注意深く見ると、最初に新しいPodが作成され、次に古いPodが削除されるのを確認できます。十分な数の新しいPodが稼働するまでは、Deploymentは古いPodを削除しません。また十分な数の古いPodが削除しない限り新しいPodは作成されません。少なくとも2つのPodが利用可能で、最大でもトータルで4つのPodが利用可能になっていることを保証します。
+
+* Deploymentの詳細情報を取得します。
+  ```shell
+  kubectl describe deployments
+  ```
+  実行結果は下記のとおりです。
+  ```
+  Name:                   nginx-deployment
+  Namespace:              default
+  CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
+  Labels:                 app=nginx
+  Annotations:            deployment.kubernetes.io/revision=2
+  Selector:               app=nginx
+  Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
+  StrategyType:           RollingUpdate
+  MinReadySeconds:        0
+  RollingUpdateStrategy:  25% max unavailable, 25% max surge
+  Pod Template:
+    Labels:  app=nginx
+     Containers:
+      nginx:
+        Image:        nginx:1.9.1
+        Port:         80/TCP
+        Environment:  <none>
+        Mounts:       <none>
+      Volumes:        <none>
+    Conditions:
+      Type           Status  Reason
+      ----           ------  ------
+      Available      True    MinimumReplicasAvailable
+      Progressing    True    NewReplicaSetAvailable
+    OldReplicaSets:  <none>
+    NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)
+    Events:
+      Type    Reason             Age   From                   Message
+      ----    ------             ----  ----                   -------
+      Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
+      Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
+      Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
+      Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
+      Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
+      Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
+      Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
+    ```
+    最初にDeploymentを作成した時、ReplicaSet(nginx-deployment-2035384211)を作成してすぐにレプリカ数を3にスケールするのを確認できます。Deploymentを更新すると新しいReplicaSet(nginx-deployment-1564180365)を作成してレプリカ数を1にスケールアップし、古いReplicaSeetを2にスケールダウンさせます。これは常に最低でも2つのPodが利用可能で、かつ最大4つのPodが作成されている状態にするためです。Deploymentは同じローリングアップ戦略に従って新しいReplicaSetのスケールアップと古いReplicaSetのスケールダウンを続けます。最終的に新しいReplicaSetを3にスケールアップさせ、古いReplicaSetを0にスケールダウンさせます。
+
+### ロールオーバー (リアルタイムでの複数のPodの更新)
+
+Deploymentコントローラーにより、新しいDeploymentが観測される度にReplicaSetが作成され、理想とするレプリカ数のPodを作成します。Deploymentが更新されると、既存のReplicaSetが管理するPodのラベルが`.spec.selector`にマッチするが、テンプレートが`.spec.template`にマッチしない場合はスケールダウンされます。最終的に、新しいReplicaSetは`.spec.replicas`の値にスケールアップされ、古いReplicaSetは0にスケールダウンされます。
+
+Deploymentのロールアウトが進行中にDeploymentを更新すると、Deploymentは更新する毎に新しいReplicaSetを作成してスケールアップさせ、以前にスケールアップしたReplicaSetのロールオーバーを行います。Deploymentは更新前のReplicaSetを古いReplicaSetのリストに追加し、スケールダウンを開始します。
+
+例えば、5つのレプリカを持つ`nginx:1.7.9`のDeploymentを作成し、`nginx:1.7.9`の3つのレプリカが作成されているときに5つのレプリカを持つ`nginx:1.9.1`に更新します。このケースではDeploymentは作成済みの`nginx:1.7.9`の3つのPodをすぐに削除し、`nginx:1.9.1`のPodの作成を開始します。`nginx:1.7.9`の5つのレプリカを全て作成するのを待つことはありません。
+
+### ラベルセレクターの更新
+
+通常、ラベルセレクターを更新することは推奨されません。事前にラベルセレクターの使い方を計画しておきましょう。いかなる場合であっても更新が必要なときは十分に注意を払い、変更時の影響範囲を把握しておきましょう。
+
+{{< note >}}
+`apps/v1`API バージョンにおいて、Deploymentのラベルセレクターは作成後に不変となります。
+{{< /note >}}
+
+* セレクターの追加は、Deployment Specのテンプレートラベルも新しいラベルで更新する必要があります。そうでない場合はバリデーションエラーが返されます。この変更は重複がない更新となります。これは新しいセレクターは古いセレクターを持つReplicaSetとPodを選択せず、結果として古い全てのReplicaSetがみなし子状態になり、新しいReplicaSetを作成することを意味します。
+* セレクターの更新により、セレクターキー内の既存の値が変更されます。これにより、セレクターの追加と同じふるまいをします。
+* セレクターの削除により、Deploymentのセレクターから存在している値を削除します。これはPodテンプレートのラベルに関する変更を要求しません。既存のReplicaSetはみなし子状態にならず、新しいReplicaSetは作成されませんが、削除されたラベルは既存のPodとReplicaSetでは残り続けます。
+
+## Deploymentのロールバック {#rolling-back-a-deployment}
+
+Deploymentのロールバックを行いたい場合があります。例えば、Deploymentがクラッシュ状態になりそれがループしたりする不安定なときです。デフォルトではユーザーがいつでもロールバックできるようにDeploymentの全てのロールアウト履歴がシステムに保持されます(リビジョン履歴の上限は設定することで変更可能です)。
+
+{{< note >}}
+Deploymentのリビジョンは、Deploymentのロールアウトがトリガーされた時に作成されます。これはDeploymentのPodテンプレート(`.spec.template`)が変更されたときのみ新しいリビジョンが作成されることを意味します。Deploymentのスケーリングなど、他の種類の更新においてはDeploymentのリビジョンは作成されません。これは手動もしくはオートスケーリングを同時に行うことができるようにするためです。これは過去のリビジョンにロールバックするとき、DeploymentのPodテンプレートの箇所のみロールバックされることを意味します。
+{{< /note >}}
+
+* `nginx:1.9.1`の代わりに`nginx:1.91`というイメージに更新して、Deploymentの更新中にタイプミスをしたと仮定します。
+
+    ```shell
+    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment image updated
+    ```
+
+* このロールアウトはうまくいきません。ユーザーロールアウトのステータスを見ることでロールアウトがうまくいくか確認できます。
+
+    ```shell
+    kubectl rollout status deployment.v1.apps/nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
+    ```
+
+* ロールアウトのステータスの確認は、Ctrl-Cを押すことで停止できます。ロールアウトがうまく行かないときは、[Deploymentのステータス](#deployment-status)を読んでさらなる情報を得てください。
+
+* 古いレプリカ数(`nginx-deployment-1564180365` and `nginx-deployment-2035384211`)が2になっていることを確認でき、新しいレプリカ数(nginx-deployment-3066724191)は1になっています。
+
+    ```shell
+    kubectl get rs
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    NAME                          DESIRED   CURRENT   READY   AGE
+    nginx-deployment-1564180365   3         3         3       25s
+    nginx-deployment-2035384211   0         0         0       36s
+    nginx-deployment-3066724191   1         1         0       6s
+    ```
+
+* 作成されたPodを確認していると、新しいReplicaSetによって作成された1つのPodはコンテナイメージのpullに失敗し続けているのがわかります。
+
+    ```shell
+    kubectl get pods
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    NAME                                READY     STATUS             RESTARTS   AGE
+    nginx-deployment-1564180365-70iae   1/1       Running            0          25s
+    nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
+    nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
+    nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
+    ```
+
+    {{< note >}}
+    Deploymentコントローラーは、この悪い状態のロールアウトを自動的に停止し、新しいReplicaSetのスケールアップを止めます。これはユーザーが指定したローリングアップデートに関するパラメータ(特に`maxUnavailable`)に依存します。デフォルトではKubernetesがこの値を25%に設定します。
+    {{< /note >}}
+
+* Deploymentの詳細情報を取得します。
+    ```shell
+    kubectl describe deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    Name:           nginx-deployment
+    Namespace:      default
+    CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
+    Labels:         app=nginx
+    Selector:       app=nginx
+    Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
+    StrategyType:       RollingUpdate
+    MinReadySeconds:    0
+    RollingUpdateStrategy:  25% max unavailable, 25% max surge
+    Pod Template:
+      Labels:  app=nginx
+      Containers:
+       nginx:
+        Image:        nginx:1.91
+        Port:         80/TCP
+        Host Port:    0/TCP
+        Environment:  <none>
+        Mounts:       <none>
+      Volumes:        <none>
+    Conditions:
+      Type           Status  Reason
+      ----           ------  ------
+      Available      True    MinimumReplicasAvailable
+      Progressing    True    ReplicaSetUpdated
+    OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
+    NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
+    Events:
+      FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
+      --------- --------    -----   ----                    -------------   --------    ------              -------
+      1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
+      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
+      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
+      22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
+      21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
+      21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
+      13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
+      13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
+    ```
+
+  これを修正するために、Deploymentを安定した状態の過去のリビジョンに更新する必要があります。
+
+### Deploymentのロールアウト履歴の確認
+
+ロールアウトの履歴を確認するには、下記の手順に従って下さい。
+
+1. 最初に、Deploymentのリビジョンを確認します。
+    ```shell
+    kubectl rollout history deployment.v1.apps/nginx-deployment
+    ```
+    実行結果は下記のとおりです。
+    ```
+    deployments "nginx-deployment"
+    REVISION    CHANGE-CAUSE
+    1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
+    2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+    3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
+    ```
+
+    `CHANGE-CAUSE`はリビジョンの作成時にDeploymentの`kubernetes.io/change-cause`アノテーションからリビジョンにコピーされます。下記の手段により`CHANGE-CAUSE`メッセージを指定できます。
+
+    * `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`の実行によりアノテーションを追加する。
+    * リソースの変更時に`kubectl`コマンドの内容を記録するために`--record`フラグを追加する。
+    * リソースのマニフェストを手動で編集する。
+
+2. 各リビジョンの詳細を確認するためには下記のコマンドを実行してください。
+    ```shell
+    kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployments "nginx-deployment" revision 2
+      Labels:       app=nginx
+              pod-template-hash=1159050644
+      Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+      Containers:
+       nginx:
+        Image:      nginx:1.9.1
+        Port:       80/TCP
+         QoS Tier:
+            cpu:      BestEffort
+            memory:   BestEffort
+        Environment Variables:      <none>
+      No volumes.
+    ```
+
+### 過去のリビジョンにロールバックする {#rolling-back-to-a-previous-revision}
+現在のリビジョンから過去のリビジョン(リビジョン番号2)にロールバックさせるには、下記の手順に従ってください。
+
+1. 現在のリビジョンから過去のリビジョンにロールバックします。
+    ```shell
+    kubectl rollout undo deployment.v1.apps/nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment
+    ```
+    その他に、`--to-revision`を指定することにより特定のリビジョンにロールバックできます。
+
+    ```shell
+    kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment
+    ```
+
+    ロールアウトに関連したコマンドのさらなる情報は[`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)を参照してください。
+
+    Deploymentが過去の安定したリビジョンにロールバックされました。Deploymentコントローラーによって、リビジョン番号2にロールバックする`DeploymentRollback`イベントが作成されたのを確認できます。
+
+2. ロールバックが成功し、Deploymentが正常に稼働していることを確認するために、下記のコマンドを実行してください。
+    ```shell
+    kubectl get deployment nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    nginx-deployment   3         3         3            3           30m
+    ```
+3. Deploymentの詳細情報を取得します。
+    ```shell
+    kubectl describe deployment nginx-deployment
+    ```
+    実行結果は下記のとおりです。
+    ```
+    Name:                   nginx-deployment
+    Namespace:              default
+    CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
+    Labels:                 app=nginx
+    Annotations:            deployment.kubernetes.io/revision=4
+                            kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+    Selector:               app=nginx
+    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
+    StrategyType:           RollingUpdate
+    MinReadySeconds:        0
+    RollingUpdateStrategy:  25% max unavailable, 25% max surge
+    Pod Template:
+      Labels:  app=nginx
+      Containers:
+       nginx:
+        Image:        nginx:1.9.1
+        Port:         80/TCP
+        Host Port:    0/TCP
+        Environment:  <none>
+        Mounts:       <none>
+      Volumes:        <none>
+    Conditions:
+      Type           Status  Reason
+      ----           ------  ------
+      Available      True    MinimumReplicasAvailable
+      Progressing    True    NewReplicaSetAvailable
+    OldReplicaSets:  <none>
+    NewReplicaSet:   nginx-deployment-c4747d96c (3/3 replicas created)
+    Events:
+      Type    Reason              Age   From                   Message
+      ----    ------              ----  ----                   -------
+      Normal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
+      Normal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
+      Normal  DeploymentRollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
+      Normal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0
+    ```
+
+## Deploymentのスケーリング {#scaling-a-deployment}
+下記のコマンドを実行させてDeploymentをスケールできます。
+
+```shell
+kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
+```
+
+実行結果は下記のとおりです。
+```
+deployment.apps/nginx-deployment scaled
+```
+
+クラスター内で[水平Podオートスケーラー](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、ユーザーが稼働させたいPodのレプリカ数の最小値と最大値を設定できます。
+
+```shell
+kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
+```
+実行結果は下記のとおりです。
+```
+deployment.apps/nginx-deployment scaled
+```
+
+### 比例スケーリング
+
+Deploymentのローリングアップデートは、同時に複数のバージョンのアプリケーションの稼働をサポートします。ユーザーやオートスケーラーがロールアウト中(更新中もしくは一時停止中)のDeploymentのローリングアップデートを行うとき、Deploymentコントローラーはリスクを削減するために既存のアクティブなReplicaSetのレプリカのバランシングを行います。これを*比例スケーリング* と呼びます。
+
+レプリカ数が10、[maxSurge](#max-surge)=3、[maxUnavailable](#max-unavailable)=2であるDeploymentが稼働している例です。
+
+* Deployment内で10のレプリカが稼働していることを確認します。
+  ```shell
+  kubectl get deploy
+  ```
+  実行結果は下記のとおりです。
+
+  ```
+  NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+  nginx-deployment     10        10        10           10          50s
+  ```
+
+* クラスター内で、解決できない新しいイメージに更新します。
+* You update to a new image which happens to be unresolvable from inside the cluster.
+    ```shell
+    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
+    ```
+
+    実行結果は下記のとおりです。
+    The output is similar to this:
+    ```
+    deployment.apps/nginx-deployment image updated
+    ```
+
+* イメージの更新は新しいReplicaSet nginx-deployment-1989198191へのロールアウトを開始させます。しかしロールアウトは、上述した`maxUnavailable`の要求によりブロックされます。ここでロールアウトのステータスを確認します。
+    ```shell
+    kubectl get rs
+    ```
+      実行結果は下記のとおりです。
+    ```
+    NAME                          DESIRED   CURRENT   READY     AGE
+    nginx-deployment-1989198191   5         5         0         9s
+    nginx-deployment-618515232    8         8         8         1m
+    ```
+
+* 次にDeploymentのスケーリングをするための新しい要求が発生します。オートスケーラーはDeploymentのレプリカ数を15に増やします。Deploymentコントローラーは新しい5つのレプリカをどこに追加するか決める必要がでてきます。比例スケーリングを使用していない場合、5つのレプリカは全て新しいReplicaSetに追加されます。比例スケーリングでは、追加されるレプリカは全てのReplicaSetに分散されます。比例割合が大きいものはレプリカ数の大きいReplicaSetとなり、比例割合が低いときはレプリカ数の小さいReplicaSetとなります。残っているレプリカはもっとも大きいレプリカ数を持つReplicaSetに追加されます。レプリカ数が0のReplicaSetはスケールアップされません。
+
+上記の例では、3つのレプリカが古いReplicaSetに追加され、2つのレプリカが新しいReplicaSetに追加されました。ロールアウトの処理では、新しいレプリカ数のPodが正常になったと仮定すると、最終的に新しいReplicaSetに全てのレプリカを移動させます。これを確認するためには下記のコマンドを実行して下さい。
+
+    ```shell
+    kubectl get deploy
+    ```
+    実行結果は下記のとおりです。
+    ```
+    NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    nginx-deployment     15        18        7            8           7m
+    ```
+  　ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
+    ```shell
+    kubectl get rs
+    ```
+    実行結果は下記のとおりです。
+    ```
+    NAME                          DESIRED   CURRENT   READY     AGE
+    nginx-deployment-1989198191   7         7         0         7m
+    nginx-deployment-618515232    11        11        11        7m
+    ```
+
+## Deployment更新の一時停止と再開 {#pausing-and-resuming-a-deployment}
+
+ユーザーは1つ以上の更新処理をトリガーする前に更新の一時停止と再開ができます。これにより、不必要なロールアウトを実行することなく一時停止と再開を行う間に複数の修正を反映できます。
+
+* 例えば、作成直後のDeploymentを考えます。  
+  Deploymentの詳細情報を確認します。
+  ```shell
+  kubectl get deploy
+  ```
+  実行結果は下記のとおりです。
+  ```
+  NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+  nginx     3         3         3            3           1m
+  ```
+  ロールアウトのステータスを確認します。
+  ```shell
+  kubectl get rs
+  ```
+  実行結果は下記のとおりです。
+  ```
+  NAME               DESIRED   CURRENT   READY     AGE
+  nginx-2142116321   3         3         3         1m
+  ```
+
+* 下記のコマンドを実行して更新処理の一時停止を行います。
+    ```shell
+    kubectl rollout pause deployment.v1.apps/nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment paused
+    ```
+
+* 次にDeploymentのイメージを更新します。
+    ```shell
+    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment image updated
+    ```
+
+* 新しいロールアウトが開始されていないことを確認します。
+    ```shell
+    kubectl rollout history deployment.v1.apps/nginx-deployment
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployments "nginx"
+    REVISION  CHANGE-CAUSE
+    1   <none>
+    ```
+* Deploymentの更新に成功したことを確認するためにロールアウトのステータスを確認します。
+    ```shell
+    kubectl get rs
+    ```
+    実行結果は下記のとおりです。
+    ```
+    NAME               DESIRED   CURRENT   READY     AGE
+    nginx-2142116321   3         3         3         2m
+    ```
+
+* ユーザーは何度も更新を行えます。例えばDeploymentが使用するリソースを更新します。
+    ```shell
+    kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment resource requirements updated
+    ```
+    一時停止する前の初期状態では更新処理は機能しますが、Deploymentが一時停止されている間は新しい更新処理は反映されません。
+
+* 最後に、Deploymentの稼働を再開させ、新しいReplicaSetが更新内容を全て反映させているのを確認します。
+    ```shell
+    kubectl rollout resume deployment.v1.apps/nginx-deployment
+    ```
+    実行結果は下記のとおりです。
+    ```
+    deployment.apps/nginx-deployment resumed
+    ```
+* 更新処理が完了するまでロールアウトのステータスを確認します。
+    ```shell
+    kubectl get rs -w
+    ```
+    実行結果は下記のとおりです。
+    ```
+    NAME               DESIRED   CURRENT   READY     AGE
+    nginx-2142116321   2         2         2         2m
+    nginx-3926361531   2         2         0         6s
+    nginx-3926361531   2         2         1         18s
+    nginx-2142116321   1         2         2         2m
+    nginx-2142116321   1         2         2         2m
+    nginx-3926361531   3         2         1         18s
+    nginx-3926361531   3         2         1         18s
+    nginx-2142116321   1         1         1         2m
+    nginx-3926361531   3         3         1         18s
+    nginx-3926361531   3         3         2         19s
+    nginx-2142116321   0         1         1         2m
+    nginx-2142116321   0         1         1         2m
+    nginx-2142116321   0         0         0         2m
+    nginx-3926361531   3         3         3         20s
+    ```
+* 最新のロールアウトのステータスを確認します。
+    ```shell
+    kubectl get rs
+    ```
+
+    実行結果は下記のとおりです。
+    ```
+    NAME               DESIRED   CURRENT   READY     AGE
+    nginx-2142116321   0         0         0         2m
+    nginx-3926361531   3         3         3         28s
+    ```
+{{< note >}}
+一時停止したDeploymentの稼働を再開させない限り、ユーザーはDeploymentのロールバックはできません。
+{{< /note >}}
+
+## Deploymentのステータス {#deployment-status}
+
+Deploymentは、そのライフサイクルの間に様々な状態に遷移します。新しいReplicaSetへのロールアウト中は[進行中](#progressing-deployment)になり、その後は[完了](#complete-deployment)し、また[失敗](#failed-deployment)にもなります。
+
+### Deploymentの更新処理 {#progressing-deployment}
+
+下記のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。
+
+* Deploymentが新しいReplicaSetを作成する。
+* Deploymentが新しいReplicaSetをスケールアップさせている。
+* Deploymentが古いReplicaSetをスケールダウンさせている。
+* 新しいPodが準備中もしくは利用可能な状態になる(少なくとも[MinReadySeconds](#min-ready-seconds)の間は準備中になります)。
+
+ユーザーは`kubectl rollout status`を実行してDeploymentの進行状態を確認できます。
+
+### Deploymentの更新処理の完了 {#complete-deployment}
+
+Deploymentが下記の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。
+
+* Deploymentの全てのレプリカが、指定された最新のバージョンに更新される。これはユーザーが指定した更新処理が完了したことを意味します。
+* Deploymentの全てのレプリカが利用可能になる。
+* Deploymentの古いレプリカが1つも稼働していない。
+
+`kubectl rollout status`を実行して、Deploymentの更新が完了したことを確認できます。ロールアウトが正常に完了すると`kubectl rollout status`の終了コードが0で返されます。
+
+```shell
+kubectl rollout status deployment.v1.apps/nginx-deployment
+```
+実行結果は下記のとおりです。
+```
+Waiting for rollout to finish: 2 of 3 updated replicas are available...
+deployment.apps/nginx-deployment successfully rolled out
+$ echo $?
+0
+```
+
+### Deploymentの更新処理の失敗 {#failed-deployment}
+
+新しいReplicaSetのデプロイが完了せず、更新処理が止まる場合があります。これは主に下記の要因によるものです。
+
+* 不十分なリソースの割り当て
+* ReadinessProbeの失敗
+* コンテナイメージの取得ができない
+* 不十分なパーミッション
+* リソースリミットのレンジ
+* アプリケーションランタイムの設定の不備
+
+このような状況を検知する1つの方法として、Deploymentのリソース定義でデッドラインのパラメータを指定します([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentの更新が停止したことを示す前にDeploymentコントローラーが待つ秒数を示します。
+
+下記の`kubectl`コマンドでリソース定義に`progressDeadlineSeconds`を設定します。これはDeploymentの更新が止まってから10分後に、コントローラーが失敗を通知させるためです。
+
+```shell
+kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
+```
+実行結果は下記のとおりです。
+```
+deployment.apps/nginx-deployment patched
+```
+一度デッドラインを超過すると、DeploymentコントローラーはDeploymentの`.status.conditions`に下記のDeploymentConditionを追加します。
+
+* Type=Progressing
+* Status=False
+* Reason=ProgressDeadlineExceeded
+
+ステータスの状態に関するさらなる情報は[Kubernetes APIの規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)を参照してください。
+
+{{< note >}}
+Kubernetesは停止状態のDeploymentに対して、ステータス状態を報告する以外のアクションを実行しません。高レベルのオーケストレーターはこれを利用して、状態に応じて行動できます。例えば、前のバージョンへのDeploymentのロールバックが挙げられます。
+{{< /note >}}
+
+{{< note >}}
+Deploymentを停止すると、Kubernetesはユーザーが指定したデッドラインを超えたかどうかチェックしません。ユーザーはロールアウトのとゆうでもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
+{{< /note >}}
+
+設定したタイムアウトの秒数が小さかったり、一時的なエラーとして扱える他の種類のエラーが原因となり、Deploymentで一時的なエラーが出る場合があります。例えば、リソースの割り当てが不十分な場合を考えます。Deploymentの詳細情報を確認すると、下記のセクションが表示されます。
+
+```shell
+kubectl describe deployment nginx-deployment
+```
+実行結果は下記のとおりです。
+```
+<...>
+Conditions:
+  Type            Status  Reason
+  ----            ------  ------
+  Available       True    MinimumReplicasAvailable
+  Progressing     True    ReplicaSetUpdated
+  ReplicaFailure  True    FailedCreate
+<...>
+```
+
+`kubectl get deployment nginx-deployment -o yaml`を実行すると、Deploymentのステータスは下記のようになります。
+
+```
+status:
+  availableReplicas: 2
+  conditions:
+  - lastTransitionTime: 2016-10-04T12:25:39Z
+    lastUpdateTime: 2016-10-04T12:25:39Z
+    message: Replica set "nginx-deployment-4262182780" is progressing.
+    reason: ReplicaSetUpdated
+    status: "True"
+    type: Progressing
+  - lastTransitionTime: 2016-10-04T12:25:42Z
+    lastUpdateTime: 2016-10-04T12:25:42Z
+    message: Deployment has minimum availability.
+    reason: MinimumReplicasAvailable
+    status: "True"
+    type: Available
+  - lastTransitionTime: 2016-10-04T12:25:39Z
+    lastUpdateTime: 2016-10-04T12:25:39Z
+    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
+      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
+    reason: FailedCreate
+    status: "True"
+    type: ReplicaFailure
+  observedGeneration: 3
+  replicas: 2
+  unavailableReplicas: 2
+```
+
+最後に、一度Deploymentの更新処理のデッドラインを越えると、KubernetesはDeploymentのステータスと進行中の状態を更新します。
+
+```
+Conditions:
+  Type            Status  Reason
+  ----            ------  ------
+  Available       True    MinimumReplicasAvailable
+  Progressing     False   ProgressDeadlineExceeded
+  ReplicaFailure  True    FailedCreate
+```
+
+Deploymentか他のリソースコントローラーのスケールダウンを行うか、使用している名前空間内でリソースの割り当てを増やすことで、リソースの割り当て不足の問題に対処できます。割り当て条件を満たすと、DeploymentコントローラーはDeploymentのロールアウトを完了させ、Deploymentのステータスが成功状態になるのを確認できます(`Status=True`と`Reason=NewReplicaSetAvailable`)。
+
+```
+Conditions:
+  Type          Status  Reason
+  ----          ------  ------
+  Available     True    MinimumReplicasAvailable
+  Progressing   True    NewReplicaSetAvailable
+```
+
+`Status=True`の`Type=Available`は、Deploymentが最小可用性の状態であることを意味します。最小可用性は、Deploymentの更新戦略において指定されているパラメータにより決定されます。`Status=True`の`Type=Progressing`は、Deploymentのロールアウトの途中で、更新処理が進行中であるか、更新処理が完了し、必要な最小数のレプリカが利用可能であることを意味します(各TypeのReason項目を確認してください。このケースでは、`Reason=NewReplicaSetAvailable`はDeploymentの更新が完了したことを意味します)。
+
+`kubectl rollout status`を実行してDeploymentが更新に失敗したかどうかを確認できます。`kubectl rollout status`はDeploymentが更新処理のデッドラインを超えたときに0以外の終了コードを返します。
+
+```shell
+kubectl rollout status deployment.v1.apps/nginx-deployment
+```
+実行結果は下記のとおりです。
+```
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+error: deployment "nginx" exceeded its progress deadline
+$ echo $?
+1
+```
+
+### 失敗したDeploymentの操作
+
+更新完了したDeploymentに適用した全てのアクションは、更新失敗したDeploymentに対しても適用されます。スケールアップ、スケールダウンができ、前のリビジョンへのロールバックや、Deploymentのテンプレートに複数の更新を適用させる必要があるときは一時停止もできます。
+
+## 古いリビジョンのクリーンアップポリシー {#clean-up-policy}
+
+Deploymentが管理する古いReplicaSetをいくつ保持するかを指定するために、`.spec.revisionHistoryLimit`フィールドを設定できます。この値を超えた古いReplicaSetはバックグラウンドでガーベージコレクションの対象となって削除されます。デフォルトではこの値は10です。
+
+{{< note >}}
+このフィールドを明示的に0に設定すると、Deploymentの全ての履歴を削除します。従って、Deploymentはロールバックできません。
+{{< /note >}}
+
+## カナリアパターンによるデプロイ
+
+Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたいとき、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
+
+## Deployment Specの記述
+
+他の全てのKubernetesの設定と同様に、Deploymentは`apiVersion`、`kind`や`metadata`フィールドを必要とします。設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
+
+Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。
+
+### Podテンプレート
+
+`.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
+
+`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/pod-overview/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
+
+Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
+
+[`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)が`Always`に等しいときのみ許可されます。これはテンプレートで指定されていない場合のデフォルト値です。
+
+### レプリカ数
+
+`.spec.replias`は理想的なPodの数を指定するオプションのフィールドです。デフォルトは1です。
+
+### セレクター {#selector}
+
+`.spec.selector`は必須フィールドで、Deploymentによって対象とされるPodの[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/)を指定します。
+
+`.spec.selector`は`.spec.template.metadata.labels`と一致している必要があり、一致しない場合はAPIによって拒否されます。
+
+`apps/v1`バージョンにおいて、`.spec.selector`と`.metadata.labels`が指定されていない場合、`.spec.template.metadata.labels`の値に初期化されません。そのため`.spec.selector`と`.metadata.labels`を明示的に指定する必要があります。また`apps/v1`のDeploymentにおいて`.spec.selector`は作成後に不変になります。
+
+Deploymentのテンプレートが`.spec.template`と異なる場合や、`.spec.replicas`の値を超えてPodが稼働している場合、Deploymentはセレクターに一致するラベルを持つPodを削除します。Podの数が理想状態より少ない場合Deploymentは`.spec.template`をもとに新しいPodを作成します。
+
+{{< note >}}
+ユーザーは、Deploymentのセレクターに一致するラベルを持つPodを、直接作成したり他のDeploymentやReplicaSetやReplicationControllerによって作成するべきではありません。作成した場合は最初のDeploymentが、ラベルに一致する新しいPodを作成したとみなしてしまいます。Kubernetesはユーザーがこれを行ってもエラーなどを出さず、処理を止めません。
+{{< /note >}}
+
+セレクターが重複する複数のコントローラーを持つとき、そのコントローラーは互いに競合状態となり、正しくふるまいません。
+
+### 更新戦略
+
+`.spec.strategy`は古いPodから新しいPodに置き換える際の更新戦略を指定します。`.spec.strategy.type`は"Recreate"もしくは"RollingUpdate"を指定できます。デフォルトは"RollingUpdate"です。
+
+#### Deploymentの再作成
+
+`.spec.strategy.type==Recreate`と指定されているとき、既存の全てのPodは新しいPodが作成される前に削除されます。
+
+#### Deploymentのローリングアップデート
+
+`.spec.strategy.type==RollingUpdate`と指定されているとき、Deploymentは[ローリングアップデート](/docs/tasks/run-application/rolling-update-replication-controller/)によりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
+
+##### maxUnavailable
+
+`.spec.strategy.rollingUpdate.maxUnavailable`はオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り捨てされて計算されます。`.spec.strategy.rollingUpdate.maxSurge`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
+
+例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると古いReplicaSetはすぐに理想状態の70%にスケールダウンされます。一度新しいPodが稼働できる状態になると、古いReplicaSetはさらにスケールダウンされ、続いて新しいReplicaSetがスケールアップされます。この間、利用可能なPodの総数は理想状態のPodの少なくとも70%以上になるように保証されます。
+
+##### maxSurge
+
+`.spec.strategy.rollingUpdate.maxSurge`はオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り上げで計算されます。`MaxUnavailable`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。
+
+例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると新しいReplicaSetはすぐに更新されます。このとき古いPodと新しいPodの総数は理想状態の130%を超えないように更新されます。一度古いPodが削除されると、新しいReplicaSetはさらにスケールアップされます。この間、利用可能なPodの総数は理想状態のPodに対して最大130%になるように保証されます。
+
+### progressDeadlineSeconds
+
+`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
+
+この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。
+
+### minReadySeconds {#min-ready-seconds}
+
+`.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
+
+### rollbackTo
+
+`.spec.rollbackTo`は、`extensions/v1beta1`と`apps/v1beta1`のAPIバージョンにおいて非推奨で、`apps/v1beta2`以降のAPIバージョンではサポートされません。かわりに、[前のリビジョンへのロールバック](#rolling-back-to-a-previous-revision)で説明されているように`kubectl rollout undo`を使用するべきです。
+
+### リビジョン履歴の保持上限
+
+Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。
+
+`.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymnetの更新頻度と安定性に依存します。
+
+さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。
+
+### paused
+
+`.spec.paused`はオプションのboolean値で、Deploymentの一時停止と再開のための値です。一時停止されているものと、そうでないものとの違いは、一時停止されているDeploymentはPodTemplateSpecのいかなる変更があってもロールアウトがトリガーされないことです。デフォルトではDeploymentは一時停止していない状態で作成されます。
+
+## Deploymentの代替案
+### kubectl rolling update
+
+[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)によって、同様の形式でPodとReplicationControllerを更新できます。しかしDeploymentの使用が推奨されます。なぜならDeploymentの作成は宣言的であり、ローリングアップデートが更新された後に過去のリビジョンにロールバックできるなど、いくつかの追加機能があります。
+
+{{% /capture %}}
@@ -1,5 +1,4 @@
 ---
-title: "Pods"
+title: "Pod"
 weight: 10
 ---
-
@@ -17,11 +17,11 @@ card:
 {{% capture body %}}
 ## Podについて理解する

-*Pod* は、Kubernetesの基本的なビルディングブロックとなります。Kubernetesオブジェクトモデルの中で、ユーザーが作成し、デプロイ可能なシンプルで最も最小のユニットです。単一のPodはクラスター上で稼働する単一のプロセスを表現します。
+*Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。

-単一のPodは、アプリケーションコンテナ（いくつかの場合においては複数のコンテナ）や、ストレージリソース、ユニークなネットワークIPや、コンテナがどのように稼働すべきか統制するためのオプションをカプセル化します。単一のPodは、ある単一のDeploymentのユニット(単一のコンテナもしくはリソースを共有する、密接に連携された少数のコンテナ群を含むような*Kubernetes内でのアプリケーションの単一のインスタンス*) を表現します。  
+Podは、アプリケーションのコンテナ(いくつかの場合においては複数のコンテナ)、ストレージリソース、ユニークなネットワークIP、およびコンテナの実行方法を管理するオプションをカプセル化します。Podはデプロイメントの単位、すなわち*Kubernetesのアプリケーションの単一インスタンス* で、単一の{{< glossary_tooltip term_id="container" >}}または密結合なリソースを共有する少数のコンテナで構成される場合があります。

-> [Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他のコンテナランタイムも同様にサポートしています。    
+[Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他の[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)も同様にサポートしています。

 Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。

@@ -30,11 +30,10 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで
 * **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。  これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。  
 -- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。

-[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。  
-さらなる情報を得たい場合は、下記のページを参照ください。  
+[Kubernetes Blog](http://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。  

-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)  
-* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
+  * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)  
+  * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)

 各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。
 Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。  
@@ -50,7 +49,6 @@ Podは凝集性の高いサービスのユニットを構成するような複
 ユーザーは、コンテナ群が密接に連携するような、特定のインスタンスにおいてのみこのパターンを使用するべきです。
 例えば、ユーザーが共有ボリューム内にあるファイル用のWebサーバとして稼働するコンテナと、下記のダイアグラムにあるような、リモートのソースからファイルを更新するような分離された*サイドカー* コンテナを持っているような場合です。

-
 {{< figure src="/images/docs/pod.svg" alt="Podのダイアグラム" width="50%" >}}

 Podは、Podによって構成されたコンテナ群のために2種類の共有リソースを提供します。 *ネットワーキング* と*ストレージ* です。
@@ -61,24 +59,24 @@ Podは、Podによって構成されたコンテナ群のために2種類の共

 #### ストレージ

-単一のPodは共有されたストレージ*ボリューム* のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。  
+単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。  
 単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。

 ## Podを利用する

 ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
-これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一のNode上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、Nodeが故障するまでNode上に残り続けます。
+これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時（ユーザーによって直接的、またはコントローラーによって間接的に作成された場合）、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。

 {{< note >}}
 単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
 {{< /note >}}

-Podは、Podそれ自体によって自己修復しません。もし、稼働されていないNode上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、Nodeのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。  
+Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。  
 このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。

 ### Podとコントローラー

-単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしNodeが故障した場合、コントローラーは異なるNode上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。
+単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしノードが故障した場合、コントローラーは異なるノード上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。

 1つまたはそれ以上のPodを含むコントローラーの例は下記の通りです。

@@ -115,7 +113,8 @@ spec:
 {{% /capture %}}

 {{% capture whatsnext %}}
-* Podの振る舞いに関して学ぶには下記を参照してください。
-  * [Podの停止](/docs/concepts/workloads/pods/pod/#termination-of-pods)
-  * [Podのライフサイクル](/docs/concepts/workloads/pods/pod-lifecycle/)
+* [Pod](/ja/docs/concepts/workloads/pods/pod/)について更に学びましょう
+* Podの振る舞いに関して学ぶには下記を参照してください
+   * [Podの停止](/ja/docs/concepts/workloads/pods/pod/#podの終了)
+   * [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
 {{% /capture %}}