Merge remote-tracking branch 'upstream/dev-1.17-ja.2' into fix-21489

2020-06-14 23:52:46 +09:00 · 2020-06-14 23:52:46 +09:00 · 0da357e044
parent 5674b4072b c52d91ea75
commit 0da357e044
17 changed files with 688 additions and 738 deletions
--- a/content/ja/case-studies/sos/index.html
+++ b/content/ja/case-studies/sos/index.html
@ -26,12 +26,12 @@ logo: sos_featured_logo.png
  <div class="col1" style="width:100%"">
    <h2>課題</h2>
 SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては
-3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
+3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
 <br><br>
    <h2>ソリューション</h2>
- 標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャーに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
+ 標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
 <br><br>
 <h2>影響</h2>
 Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
@ -42,14 +42,14 @@ logo: sos_featured_logo.png
 <div class="banner2">
  <div class="banner2text">
 「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
+<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
  </div>
 </div>
 <section class="section2">
 <div class="fullcol">
  <h2>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。</h2>
 SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。<br><br>
- ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
+ ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
 <br><br>
 Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」
@ -60,7 +60,7 @@ logo: sos_featured_logo.png
  <div class="banner3text">
 「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
+<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
  </div>
 </div>
@ -70,13 +70,13 @@ logo: sos_featured_logo.png
 技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」<br><br>
-プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャーに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャーをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。
+プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。
 </div>
 </section>
 <div class="banner4" style="background-image: url('/images/CaseStudy_sos_banner4.jpg');width:100%">
  <div class="banner4text">
 「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
+ <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
  </div>
 </div>
@ -95,7 +95,7 @@ logo: sos_featured_logo.png
 <div class="banner5" >
  <div class="banner5text">
 「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span></div>
+<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span></div>
 </div>
 <div class="fullcol">
--- a/content/ja/docs/concepts/architecture/_index.md
+++ b/content/ja/docs/concepts/architecture/_index.md
@ -1,4 +1,4 @@
 ---
-title: "Kubernetesのアーキテクチャー"
+title: "Kubernetesのアーキテクチャ"
 weight: 30
 ---
--- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@ -28,7 +28,7 @@ Kubernetesオブジェクトを操作するには、作成、変更、または
 ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。
-`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesから与えられ、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
+`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。
 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合（statusが変わる）、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。
@ -50,7 +50,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
 出力結果は、下記に似た形になります:
-```shell
+```
 deployment.apps/nginx-deployment created
 ```
@ -64,7 +64,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
 * `spec` - オブジェクトの望ましい状態
 `spec`の正確なフォーマットは、Kubernetesオブジェクトごとに異なり、オブジェクトごとに特有な入れ子のフィールドを持っています。[Kubernetes API リファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)が、Kubernetesで作成出来る全てのオブジェクトに関するspecのフォーマットを探すのに役立ちます。
-例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[こちら](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
+例えば、`Pod`オブジェクトに関する`spec`のフォーマットは[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を、また`Deployment`オブジェクトに関する`spec`のフォーマットは[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)をご確認ください。
 {{% /capture %}}
--- a/content/ja/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md
@ -16,7 +16,7 @@ Kubernetesのネットワークのアプローチについて説明する前に
 Dockerコンテナがノード間で通信するには、マシンのIPアドレスにポートを割り当ててから、コンテナに転送またはプロキシする必要があります。
 これは明らかに、コンテナが使用するポートを非常に慎重に調整するか、ポートを動的に割り当てる必要があることを意味します。
-複数の開発者間でポートを調整することは大規模に行うことは非常に難しく、ユーザーが制御できないクラスターレベルの問題にさらされます。
+コンテナを提供する複数の開発者やチーム間でポートの割り当てを調整することは、規模的に大変困難であり、ユーザが制御できないクラスターレベルの問題にさらされます。
 Kubernetesでは、どのホストで稼働するかに関わらず、Podが他のPodと通信できると想定しています。
 すべてのPodに独自のクラスタープライベートIPアドレスを付与するため、Pod間のリンクを明示的に作成したり、コンテナポートをホストポートにマップしたりする必要はありません。
 これは、Pod内のコンテナがすべてlocalhostの相互のポートに到達でき、クラスター内のすべてのPodがNATなしで相互に認識できることを意味します。
@ -204,9 +204,7 @@ 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クラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。
 このセクションの残りの部分では、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバー(CoreDNSクラスターアドオン)があることを前提としているため、標準的な方法(gethostbynameなど)を使用してクラスター内の任意のPodからServiceに通信できます。
 curlアプリケーションを実行して、これをテストしてみましょう:
 ```shell
 kubectl run curl --image=radial/busyboxplus:curl -i --tty
@ -254,7 +252,21 @@ kubectl get secrets
 ```
 NAME                  TYPE                                  DATA      AGE
 default-token-il9rc   kubernetes.io/service-account-token   1         1d
-nginxsecret           Opaque                                2         1m
+nginxsecret           kubernetes.io/tls                     2         1m
 ```
 configmapも作成します:
 ```shell
 kubectl create configmap nginxconfigmap --from-file=default.conf
 ```
 ```
 configmap/nginxconfigmap created
 ```
 ```shell
 kubectl get configmaps
 ```
 ```
 NAME             DATA   AGE
 nginxconfigmap   1      114s
 ```
 以下は、(Windows上など)makeの実行で問題が発生した場合に実行する手動の手順です:
@ -274,6 +286,7 @@ kind: "Secret"
 metadata:
  name: "nginxsecret"
  namespace: "default"
  type: kubernetes.io/tls
 data:
  nginx.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
  nginx.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
@ -287,7 +300,7 @@ kubectl get secrets
 ```
 NAME                  TYPE                                  DATA      AGE
 default-token-il9rc   kubernetes.io/service-account-token   1         1d
-nginxsecret           Opaque                                2         1m
+nginxsecret           kubernetes.io/tls                     2         1m
 ```
 次に、nginxレプリカを変更して、シークレットの証明書とServiceを使用してhttpsサーバーを起動し、両方のポート(80と443)を公開します:
@ -332,7 +345,7 @@ 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
+kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt
 ...
 <title>Welcome to nginx!</title>
 ...
@ -414,7 +427,8 @@ LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
 {{% capture whatsnext %}}
-Kubernetesは、複数のクラスターおよびクラウドプロバイダーにまたがるフェデレーションサービスもサポートし、可用性の向上、フォールトトレランスの向上、サービスのスケーラビリティの向上を実現します。
+* 詳細: [Serviceを利用したクラスター内のアプリケーションへのアクセス](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
-詳細については[フェデレーションサービスユーザーガイド](/docs/concepts/cluster-administration/federation-service-discovery/)を参照してください。
+* 詳細: [Serviceを使用してフロントエンドをバックエンドに接続する](/ja/docs/tasks/access-application-cluster/connecting-frontend-backend/)
 * 詳細: [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
 {{% /capture %}}
--- a/content/ja/docs/concepts/services-networking/ingress.md
+++ b/content/ja/docs/concepts/services-networking/ingress.md
@ -13,13 +13,13 @@ weight: 40
 ## 用語
-まずわかりやすくするために、このガイドでは次の用語を定義します。
+簡単のために、このガイドでは次の用語を定義します。
 * ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
-* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードのセットです。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはパブリックインターネットとして公開されていません。  
+* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードの集合です。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはインターネットに公開されていません。
-* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。エッジルーターはクラウドプロバイダーやハードウェアの物理的な一部として管理されたゲートウェイとなります。
+* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。クラウドプロバイダーが管理するゲートウェイや、物理的なハードウェアの一部である場合もあります。
-* クラスターネットワーク: 物理的または論理的なリンクのセットで、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
+* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
-* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodのセットを特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に言及がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つと想定されます。
+* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodの集合を特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に指定がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つものとして扱われます。
 ## Ingressとは何か
@ -33,17 +33,17 @@ weight: 40
   [ Services ]
 ```
-IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように構成できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
+IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
-Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開するときは、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを使用することが多いです。
+Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。
 ## Ingressを使用する上での前提条件
-Ingressの機能を提供するために[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)を用意する必要があります。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-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択してください。
-理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすべきです。しかし実際には、いくつかのIngressコントローラーは微妙に異なる動作をします。
+理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすはずです。しかし実際には、各Ingressコントローラーは微妙に異なる動作をします。
 {{< note >}}
 Ingressコントローラーのドキュメントを確認して、選択する際の注意点について理解してください。
@ -51,7 +51,7 @@ Ingressコントローラーのドキュメントを確認して、選択する
 ## Ingressリソース
-Ingressリソースの最小構成の例は下記のとおりです。
+Ingressリソースの最小構成の例は以下のとおりです。
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
@ -70,16 +70,13 @@ spec:
          servicePort: 80
 ```
-他の全てのKubernetesリソースと同様に、Ingressは`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/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コントローラーのドキュメントを確認してください。
 設定ファイルの利用に関する一般的な情報は、[アプリケーションのデプロイ](/ja/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ルールは下記の情報を含みます。
+各HTTPルールは以下の情報を含みます。
 * オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
 * パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
@ -96,12 +93,11 @@ IngressオブジェクトでHTTPリクエストが1つもホスト名とパス
 ## Ingressのタイプ
 ### 単一ServiceのIngress
-ユーザーは単一のServiceを公開できるという、Kubernetesのコンセプトがあります([Ingressの代替案](#alternatives)を参照してください)。
+Kubernetesには、単一のServiceを公開できるようにする既存の概念があります（[Ingressの代替案](#alternatives)を参照してください）。ルールなしで*デフォルトのバックエンド* を指定することにより、Ingressでこれを実現することもできます。
 また、Ingressでこれを実現できます。それはルールを設定せずに*デフォルトのバックエンド* を指定することにより可能です。
 {{< codenew file="service/networking/ingress.yaml" >}}
-`kubectl apply -f`を実行してIngressを作成し、その作成したIngressの状態を確認することができます。
+`kubectl apply -f`を実行してIngressを作成すると、その作成したIngressの状態を確認することができます。
 ```shell
 kubectl get ingress test-ingress
@ -112,7 +108,7 @@ NAME           HOSTS     ADDRESS           PORTS     AGE
 test-ingress   *         203.0.113.123     80        59s
 ```
-`203.0.113.123`はIngressコントローラーによって割り当てられたIPで、このIngressを利用するためのものです。
+`203.0.113.123`はIngressコントローラーによって割り当てられたIPで、作成したIngressを利用するためのものです。
 {{< note >}}
 IngressコントローラーとロードバランサーがIPアドレス割り当てるのに1、2分ほどかかります。この間、ADDRESSの情報は`<pending>`となっているのを確認できます。
@ -120,14 +116,14 @@ IngressコントローラーとロードバランサーがIPアドレス割り
 ### リクエストのシンプルなルーティング
-ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによって、ユーザーはロードバランサーの数を少なくできます。例えば、下記のように設定します。
+ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによってロードバランサーの数を少なくすることができます。例えば、以下のように設定します。
 ```none
 foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
                                 / bar    service2:8080
 ```
-Ingressを下記のように設定します。
+Ingressを以下のように設定します。
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
@ -180,12 +176,12 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
 {{< note >}}
-ユーザーが使用している[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、ユーザーはdefault-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
+使用する[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。
 {{< /note >}}
-### 名前ベースの仮想ホスティング
+### 名前ベースのバーチャルホスティング
-名前ベースの仮想ホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。
+名前ベースのバーチャルホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。
 ```none
 foo.bar.com --|                 |-> foo.bar.com service1:80
@ -193,7 +189,7 @@ foo.bar.com --|                 |-> foo.bar.com service1:80
 bar.foo.com --|                 |-> bar.foo.com service2:80
 ```
-下記のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
+以下のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
@ -216,9 +212,9 @@ spec:
          servicePort: 80
 ```
-rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースの仮想ホストなしにマッチさせることができます。
+rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースのバーチャルホストなしにマッチさせることができます。
-例えば、下記のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
+例えば、以下のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
@ -248,7 +244,7 @@ spec:
 ### 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を使用するための証明書と秘密鍵を含む値となります。下記が例となります。
+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
@ -285,7 +281,7 @@ spec:
 ```
 {{< note >}}
-Ingressコントローラーによって、サポートされるTLSの機能に違いがあります。利用する環境でTLSがどのように動作するかを理解するために、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
+サポートされるTLSの機能はIngressコントローラーによって違いがあります。利用する環境でTLSがどのように動作するかを理解するためには、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
 {{< /note >}}
 ### 負荷分散
@ -386,9 +382,8 @@ Ingressと関連するリソースの今後の開発については[SIG Network]
 ## Ingressの代替案 {#alternatives}
-Ingressリソースに直接関与しない複数の方法でServiceを公開できます。
+Ingressリソースを直接含まない複数の方法でサービスを公開できます。
 下記の2つの使用を検討してください。
 * [Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)
 * [Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)
--- a/content/ja/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ja/docs/concepts/workloads/pods/init-containers.md
@ -1,97 +1,76 @@
 ---
-title: Initコンテナ(Init Containers)
+title: Initコンテナ
 content_template: templates/concept
 weight: 40
 ---
 {{% capture overview %}}
-このページでは、Initコンテナについて概観します。Initコンテナとは、アプリケーションコンテナの前に実行され、アプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含んだ特別なコンテナです。
+このページでは、Initコンテナについて概観します。Initコンテナとは、{{< glossary_tooltip text="Pod" term_id="pod" >}}内でアプリケーションコンテナの前に実行される特別なコンテナです。
 Initコンテナにはアプリケーションコンテナのイメージに存在しないセットアップスクリプトやユーティリティーを含めることができます。
 Initコンテナは、Podの仕様のうち`containers`という配列（これがアプリケーションコンテナを示します）と並べて指定します。
 {{% /capture %}}
 この機能はKubernetes1.6からβ版の機能として存在しています。InitコンテナはPodSpec内で、アプリケーションの`containers`という配列と並べて指定されます。そのベータ版のアノテーション値はまだ扱われ、PodSpecのフィールド値を上書きします。しかしながら、それらはKubernetesバージョン1.6と1.7において廃止されました。Kubernetesバージョン1.8からはそのアノテーション値はサポートされず、PodSpecフィールドの値に変換する必要があります。
 {{% capture body %}}
-## Initコンテナを理解する
+## Initコンテナを理解する {#understanding-init-containers}
-単一の[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)は、Pod内に複数のコンテナを稼働させることができますが、Initコンテナもまた、アプリケーションコンテナが稼働する前に1つまたは複数稼働できます。
+単一の{{< glossary_tooltip text="Pod" term_id="pod" >}}は、Pod内にアプリケーションを実行している複数のコンテナを持つことができますが、同様に、アプリケーションコンテナが起動する前に実行されるInitコンテナも1つ以上持つことができます。
 Initコンテナは下記の項目をのぞいて、通常のコンテナと全く同じものとなります。
 * Initコンテナは常に完了するまで稼働します。
 * 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。
-もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`が`Never`の場合、再起動されません。
+もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`がNeverの場合、再起動されません。
-単一のコンテナをInitコンテナとして指定するためには、PodSpecにそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトのJSON配列として指定してください。
+PodにInitコンテナを指定するためには、Podの仕様にそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトの配列として指定してください。
 Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。
-### 通常のコンテナとの違い
+### 通常のコンテナとの違い {#differences-from-regular-containers}
-Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは微妙に異なり、下記の[Resources](#resources)にて説明します。また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。
+Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。
-もし複数のInitコンテナが単一のPodに対して指定された場合、それらのInitコンテナは1つずつ順番に実行されます。各Initコンテナは次のコンテナが完了できる前に完了しなくてはなりません。全てのInitコンテナが実行完了した時、KubernetesはPodを初期化し、通常通りアプリケーションコンテナを稼働させます。
+また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。
-## Initコンテナは何に使用できるか?
+複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。
-Initコンテナはアプリケーションコンテナのイメージとは分離されているため、コンテナの起動に関連したコードにおいていくつかの利点があります。  
+## Initコンテナを使用する {#using-init-containers}
-* セキュリティの理由からアプリケーションコンテナのイメージに含めたくないユーティリティーを含んだり実行できます。
+Initコンテナはアプリケーションコンテナのイメージとは分離されているため、コンテナの起動に関連したコードにおいていくつかの利点があります。
 * アプリケーションのイメージに存在していないセットアップ用のユーティリティーやカスタムコードを含むことができます。例えば、セットアップ中に`sed`、`awk`、`python`や、`dig`のようなツールを使うための他のイメージから、アプリケーションのイメージを作る必要がなくなります。
 * アプリケーションイメージをひとまとめにしてビルドすることなく、アプリケーションのイメージ作成と、デプロイ処理を独立して行うことができます。
 * アプリケーションコンテナと別のファイルシステムビューを持つために、Linuxの名前空間を使用します。その結果、アプリケーションコンテナがアクセスできない箇所へのシークレットなアクセス権限を得ることができます。
 * Initコンテナはアプリケーションコンテナの実行の前に完了しますが、その一方で、複数のアプリケーションコンテナは並列に実行されます。そのためInitコンテナはいくつかの前提条件をセットされるまで、アプリケーションコンテナの起動をブロックしたり遅らせることができます。
-### 使用例
+* Initコンテナはアプリケーションのイメージに存在しないセットアップ用のユーティリティーやカスタムコードを含むことができます。例えば、セットアップ中に`sed`、`awk`、`python`や、`dig`のようなツールを使うためだけに、別のイメージを元にしてアプリケーションイメージを作る必要がなくなります。
 * アプリケーションイメージをビルドする役割とデプロイする役割は、共同で単一のアプリケーションイメージをビルドする必要がないため、それぞれ独立して実施することができます。
 * Initコンテナは同一Pod内のアプリケーションコンテナと別のファイルシステムビューで稼働することができます。その結果、アプリケーションコンテナがアクセスできない{{< glossary_tooltip text="Secret" term_id="secret" >}}に対するアクセス権限を得ることができます。
 * Initコンテナはアプリケーションコンテナが開始する前に完了するまで実行されるため、Initコンテナを使用することで、特定の前提条件が満たされるまでアプリケーションコンテナの起動をブロックしたり遅らせることができます。前提条件が満たされると、Pod内の全てのアプリケーションコンテナを並行して起動することができます。
 * Initコンテナはアプリケーションコンテナイメージの安全性を低下させるようなユーティリティーやカスタムコードを安全に実行することができます。不必要なツールを分離しておくことで、アプリケーションコンテナイメージのアタックサーフィスを制限することができます。
-ここではInitコンテナの使用例を挙げます。  
+### 例 {#examples}
-* シェルコマンドを使って単一のServiceが作成されるのを待機します。
+Initコンテナを活用する方法について、いくつかのアイデアを次に示します。
-      for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
+* シェルコマンドを使って単一の{{< glossary_tooltip text="Service" term_id="service">}}が作成されるのを待機する。
  ```shell
  for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
  ```
-* コマンドを使って下位のAPIからこのPodをリモートサーバに登録します。
+* 以下のようなコマンドを使って下位のAPIからPodの情報をリモートサーバに登録する。
  ```shell
  curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
  ```
-      `curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
+* 以下のようなコマンドを使ってアプリケーションコンテナの起動を待機する。
  ```shell
  sleep 60
  ```
-* `sleep 60`のようなコマンドを使ってアプリケーションコンテナが起動する前に待機します。
+* gitリポジトリを{{< glossary_tooltip text="Volume" term_id="volume" >}}にクローンする。
 * ボリュームにあるgitリポジトリをクローンします。
 * メインのアプリケーションコンテナのための設定ファイルを動的に生成するために、いくつかの値を設定ファイルに移してテンプレートツールを稼働させます。例えば、設定ファイルにそのPodのPOD_IPを移して、Jinjaを使ってメインのアプリケーションコンテナの設定ファイルを生成します。
-さらに詳細な使用例は、[StatefulSetsのドキュメント](/ja/docs/concepts/workloads/controllers/statefulset/)と[Production Pods guide](/docs/tasks/configure-pod-container/configure-pod-initialization/)にまとまっています。
+* いくつかの値を設定ファイルに配置し、メインのアプリケーションコンテナのための設定ファイルを動的に生成するためのテンプレートツールを実行する。例えば、そのPodの`POD_IP`の値を設定ファイルに配置し、Jinjaを使ってメインのアプリケーションコンテナの設定ファイルを生成する。
-### Initコンテナの使用
+#### Initコンテナの具体的な使用方法 {#init-containers-in-use}
-下記のKubernetes1.5用のyamlファイルは、2つのInitコンテナを含む単一のシンプルなポッドの概要となります。
+下記の例は2つのInitコンテナを含むシンプルなPodを定義しています。
-最初のInitコンテナの例は、`myservies`、2つ目のInitコンテナは`mydb`の起動をそれぞれ待ちます。2つのコンテナの実行が完了するとPodの起動が始まります。
+1つ目のInitコンテナは`myservies`の起動を、2つ目のInitコンテナは`mydb`の起動をそれぞれ待ちます。両方のInitコンテナの実行が完了すると、Podは`spec`セクションにあるアプリケーションコンテナを実行します。
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  name: myapp-pod
  labels:
    app: myapp
  annotations:
    pod.beta.kubernetes.io/init-containers: '[
        {
            "name": "init-myservice",
            "image": "busybox:1.28",
            "command": ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        },
        {
            "name": "init-mydb",
            "image": "busybox:1.28",
            "command": ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
        }
    ]'
 spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
 ```
 古いアノテーション構文がKubernetes1.6と1.7において有効ですが、1.6では新しい構文にも対応しています。Kubernetes1.8以降では新しい構文を使用する必要があります。KubernetesではInitコンテナの宣言を`spec`に移行させました。
 ```yaml
 apiVersion: v1
@ -108,39 +87,13 @@ spec:
  initContainers:
  - name: init-myservice
    image: busybox:1.28
-    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
+    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
-    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
+    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
 ```
-Kubernetes1.5での構文は1.6においても稼働しますが、1.6の構文の使用を推奨します。Kubernetes1.6において、API内でInitコンテナのフィールド作成されます。ベータ版のアノテーションはKubernetes1.6と1.7において有効ですが、1.8以降ではサポートされません。
+次のコマンドを実行して、このPodを開始できます。
 下記のyamlファイルは`mydb`と`myservice`というServiceの概要です。
 ```yaml
 kind: Service
 apiVersion: v1
 metadata:
  name: myservice
 spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
 ---
 kind: Service
 apiVersion: v1
 metadata:
  name: mydb
 spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
 ```
 このPodは、下記のコマンドによって起動とデバッグすることが可能です。
 ```shell
 kubectl apply -f myapp.yaml
@ -149,6 +102,7 @@ kubectl apply -f myapp.yaml
 pod/myapp-pod created
 ```
 そして次のコマンドでステータスを確認します。
 ```shell
 kubectl get -f myapp.yaml
 ```
@ -157,6 +111,7 @@ NAME        READY     STATUS     RESTARTS   AGE
 myapp-pod   0/1       Init:0/2   0          6m
 ```
 より詳細な情報は次のコマンドで確認します。
 ```shell
 kubectl describe -f myapp.yaml
 ```
@ -194,12 +149,41 @@ Events:
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634
 ```
 このPod内のInitコンテナのログを確認するためには、次のコマンドを実行します。
 ```shell
 kubectl logs myapp-pod -c init-myservice # 1つ目のInitコンテナを調査する
 kubectl logs myapp-pod -c init-mydb      # 2つ目のInitコンテナを調査する
 ```
-一度`mydq`と`myservice` Serviceを起動させると、Initコンテナが完了して`myapp-pod`が作成されるのを確認できます。
+この時点で、これらのInitコンテナは`mydb`と`myservice`という名前のServiceの検出を待機しています。
 これらのServiceを検出させるための構成は以下の通りです。
 ```yaml
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: myservice
 spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
 ---
 apiVersion: v1
 kind: Service
 metadata:
  name: mydb
 spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
 ```
 `mydb`および`myservice`というServiceを作成するために、以下のコマンドを実行します。
 ```shell
 kubectl apply -f services.yaml
@ -209,68 +193,63 @@ service/myservice created
 service/mydb created
 ```
 Initコンテナが完了し、`myapp-pod`というPodがRunning状態に移行したことが確認できます。
 ```shell
 kubectl get -f myapp.yaml
 NAME        READY     STATUS    RESTARTS   AGE
 myapp-pod   1/1       Running   0          9m
 ```
-この例は非常にシンプルですが、ユーザー独自のInitコンテナを作成するためのインスピレーションを提供するでしょう。
+このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。
-## Initコンテナのふるまいに関する詳細
+## Initコンテナのふるまいに関する詳細 {#Detailed behavior}
-単一のPodが起動している間、ネットワークとボリュームが初期化されたのちに、Initコンテナは順番に起動されます。各Initコンテナは次のInitコンテナが起動する前に完了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値をもとにリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、そのInitコンテナの`restartPolicy`は`OnFailure`となります。
+Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
-Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initializing`という値はtrueとなります。
+Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。
-もしそのPodが[再起動](#pod-restart-reasons)されたとき、全てのInitコンテナは再度実行されなくてはなりません。
+もしそのPodが[再起動](#pod-restart-reasons)されたとき、全てのInitコンテナは必ず再度実行されます。
-Initコンテナのスペックに対する変更はコンテナのイメージフィールドのみに限定されます。
+Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。
-Initコンテナのイメージフィールド値の変更は、そのPodの再起動することと等しいです。
+Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。
-Initコンテナは何度も再起動、リトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れるべきです。
+Initコンテナは何度も再起動およびリトライ可能なため、べき等（Idempotent）である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。
-Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に強要されます。
+Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。
-Initコンテナがずっと失敗し続けたままの状態を防ぐために、Podに`activeDeadlineSeconds`、コンテナに`livenessProbe`の設定をそれぞれ使用してください。`activeDeadlineSeconds`の設定はInitコンテナにも適用されます。
+Initコンテナがずっと失敗し続けたままの状態を防ぐために、Podに`activeDeadlineSeconds`を、コンテナに`livenessProbe`をそれぞれ設定してください。`activeDeadlineSeconds`の設定はInitコンテナが実行中の時間にも適用されます。
-あるPod内の各アプリケーションコンテナとInitコンテナの名前はユニークである必要があります。他のコンテナと同じ名前を共有していた場合、バリデーションエラーが返されます。
+Pod内の各アプリケーションコンテナとInitコンテナの名前はユニークである必要があります。他のコンテナと同じ名前を共有していた場合、バリデーションエラーが返されます。
-### リソース
+### リソース {#resources}
 Initコンテナの順序と実行を考えるとき、リソースの使用に関して下記のルールが適用されます。
-* 全てのInitコンテナの中で定義された最も高いリソースリクエストとリソースリミットが、*有効なInitリクエストとリミット* になります。
+* 全てのInitコンテナの中で定義された最も高いリソースリクエストとリソースリミットが、*有効なinitリクエスト／リミット* になります。
-* Podのリソースの*有効なリクエストとリミット* は、下記の2つの中のどちらか高い方となります。
+* Podのリソースの*有効なリクエスト／リミット* は、下記の2つの中のどちらか高い方となります。
-  * そのリソースの全てのアプリケーションコンテナのリクエストとリミットの合計
+  * リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計
-  * そのリソースの有効なInitリクエストとリミット
+  * リソースに対する有効なinitリクエスト／リミット
-* スケジューリングは有効なリクエストとリミットに基づいて実行されます。これはInitコンテナがそのPodの生存中に使われない初期化のためのリソースを保持することができることを意味しています。
+* スケジューリングは有効なリクエスト／リミットに基づいて実行されます。つまり、InitコンテナはPodの生存中には使用されない初期化用のリソースを確保することができます。
-* Podの*有効なQosティアー* は、Initコンテナとアプリケーションコンテナで同様です。
+* Podの*有効なQos（quality of service）ティアー* は、Initコンテナとアプリケーションコンテナで同様です。
 クォータとリミットは有効なPodリクエストとリミットに基づいて適用されます。
-Podレベルのcgroupsは、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
+Podレベルのコントロールグループ（cgroups）は、スケジューラーと同様に、有効なPodリクエストとリミットに基づいています。
-### Podの再起動の理由
+### Podの再起動の理由 {#pod-restart-reasons}
-単一のPodは再起動可能で、Initコンテナの再実行も引き起こします。それらは下記の理由によるものです。
+以下の理由によりPodは再起動し、Initコンテナの再実行も引き起こす可能性があります。
-* あるユーザーが、そのPodのInitコンテナのイメージを変更するようにPodSpecを更新する場合。アプリケーションコンテナのイメージの変更はそのアプリケーションコンテナの再起動のみ行われます。
+* ユーザーが、そのPodのInitコンテナのイメージを変更するようにPodの仕様を更新する場合。アプリケーションコンテナのイメージの変更はそのアプリケーションコンテナの再起動のみ行われます。
 * そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。
-* `restartPolicy`が`Always`と設定されているとき、単一Pod内の全てのコンテナが停止され、再起動が行われた時と、ガーベージコレクションによりInitコンテナの完了記録が失われた場合。
+* `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、再起動が行われた場合。およびガーベージコレクションによりInitコンテナの完了記録が失われた場合。
 ## サポートと互換性
 ApiServerのバージョン1.6.0かそれ以上のバージョンのクラスターは、`.spec.initContainers`フィールドを使ったInitコンテナの機能をサポートしています。  
 それ以前のバージョンでは、α版かβ版のアノテーションを使ってInitコンテナを使用できます。また、`.spec.initContainers`フィールドは、Kubernetes1.3.0かそれ以上のバージョンでInitコンテナを使用できるようにするためと、ApiServerバージョン1.6において、1.5.xなどの古いバージョンにロールバックできるようにするために、α版かβ版のアノテーションにミラーされ、存在するPodのInitコンテナの機能が失われることが無いように安全にロールバックできるようにします。
 ApiServerとKubeletバージョン1.8.0かそれ以上のバージョンでは、α版とβ版のアノテーションは削除されており、廃止されたアノテーションは`.spec.initContainers`フィールドへの移行が必須となります。
 {{% /capture %}}
 {{% capture whatsnext %}}
-* [Initコンテナを持っているPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
+* [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。
 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。
 {{% /capture %}}
--- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
@ -52,7 +52,7 @@ PodCondition配列の各要素には、次の6つのフィールドがありま
  * `PodScheduled`: PodがNodeにスケジュールされました。
  * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。
-  * `Initialized`: すべての[init containers](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
+  * `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
  * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
--- a/content/ja/docs/contribute/_index.md
+++ b/content/ja/docs/contribute/_index.md
@ -11,49 +11,35 @@ weight: 80
 ドキュメントやウェブサイトに貢献したい方、ご協力お待ちしています。
 はじめての方、久しぶりの方、開発者でもエンドユーザでも、はたまたタイポを見逃せない方でもどなたでも貢献可能です。
-ドキュメントのスタイルガイドについては[こちら](/docs/contribute/style/style-guide/)。
+{{% /capture %}}
 {{% capture body %}}
-## コントリビューターの種類
+## はじめに
- _メンバー_ は、すでに [CLA に署名](/docs/contribute/start#sign-the-cla)しており、本プロジェクトに何度も貢献している方です。
+どなたでも、問題を説明するissueや、ドキュメントの改善を求めるissueを作成し、プルリクエスト(PR)を用いて変更に貢献することができます。
-  [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)を読んで、会員規約をご確認ください。
+一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。
- _レビュアー_ は、ドキュメントのPRレビューへ関心を示しており、承認者によりすでにGitHubグループ、およびGitHubレポジトリーの`OWNERS`ファイルに追加されているメンバーです。
+役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
 - _承認者_ は、本プロジェクトに継続してコミットできているメンバーです。Kubernetes organizationを代表して、PRをマージしたり、コンテンツを公開することができます。
  また、Kubernetes コミュニティにおいて、SIG Docsを代表することもできますが、リリースの調整などのように、相応の時間をコミットすることも求められます。
-## ドキュメントへの貢献方法
+Kubernetesのドキュメントは、GitHubのリポジトリーにあります。
 どなたからの貢献も歓迎しますが、Kubernetesコミュニティの効果的な運用のためには、gitとGitHubを基本的に使いこなせる必要があります。
-以下に挙げたものは、どなたでも可能なこと、Kubernetes organizationメンバーであれば可能なこと、SIG Docsのプロセスにアクセスでき、かつ慣れていないとできないことにわかれています。
+ドキュメンテーションに関わるには:
 継続的に貢献していけば、ノウハウや組織的決断を理解する手助けとなるでしょう。
-これがKubernetesドキュメントへ貢献する方法の全てではないですが、手始めには良いでしょう。
+1. CNCFの[Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)にサインしてください。
 2. [ドキュメンテーションのリポジトリー](https://github.com/kubernetes/website)と、ウェブサイトの[静的サイトジェネレーター](https://gohugo.io)に慣れ親しんでください。
 3. [コンテンツの改善](https://kubernetes.io/docs/contribute/start/#improve-existing-content)と[変更レビュー](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests)の基本的なプロセスを理解していることを確認してください。
- [どなたでも](/docs/contribute/start/)
+## 貢献するためのベストプラクティス
  - issue を作成する
 - [メンバー](/docs/contribute/start/)
  - 既存のドキュメントを改善する
  - 改善のアイデアを[Slack](http://slack.k8s.io/)もしくは[SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)に投げる
  - ドキュメントのアクセシビリティを改善する
  - PRにフィードバックをする
  - 事例やブロクを書く
 - [レビュアー](/docs/contribute/intermediate/)
  - 新機能のドキュメントを作成する
  - issueの選別、分類をする
  - PRをレビューする
  - 図表や、グラフィック資産、埋め込み可能な動画などを作成する
  - 多言語対応
  - ドキュメントの代表者として別のレポジトリに貢献する
  - コード内にある、ユーザが使う文字列を編集する
  - コードのコメントやGodocを改善する
 - [承認者](/docs/contribute/advanced/)
  - PRを承認、マージすることでコントリビューターが作成したコンテンツを公開する
  - Kubernetesのリリースチームに、ドキュメントを代表して参加する
  - スタイルガイドの改善を提案する
  - ドキュメントテストの改善を提案する
  - Kubernetesのウェブサイトやその他ツールの改善を提案する
 - 明快で意味のあるGitコミットメッセージを書いてください。
 - PRがマージされたときにissueを参照し、自動的にissueをクローズする_Github Special Keywords_を必ず含めるようにしてください。
 - タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。
 - あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。
 - 追加文献 : 
    - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
    - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
    - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )
 ## その他の貢献方法
@ -61,3 +47,12 @@ weight: 80
 - 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/blob/master/contributors/guide/contributor-cheatsheet/README-ja.md)を読んでください。
 {{% /capture %}}
 {{% capture whatsnext %}}
 - ドキュメントへの貢献の基本について、さらに知りたい場合は、[貢献の開始](/docs/contribute/start/)を参照してください。
 - 変更を提案をする際は、[Kubernetesドキュメンテーションスタイルガイド](/docs/contribute/style/style-guide/)に従ってください。
 - SIG Docsについて、さらに知りたい場合は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
 - Kubernetesドキュメントのローカライズについて、さらに知りたい場合は、[Kubernetesドキュメントのローカライズ](/docs/contribute/localization/)を参照してください。
 {{% /capture %}}
--- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@ -6,63 +6,36 @@ weight: 30
 {{% capture overview %}}
-<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices.  With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">`kubeadm`ツールは、ベストプラクティスに準拠した実用最小限のKubernetesクラスターをブートストラップする手助けをします。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。
 lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/ja/docs/reference/access-authn-authz/bootstrap-tokens/).
-Because you can install kubeadm on various types of machine (e.g. laptop, server,
+`kubeadm`ツールは、次のようなときに適しています。
 Raspberry Pi, etc.), it's well suited for integration with provisioning systems
 such as Terraform or Ansible.
-kubeadm's simplicity means it can serve a wide range of use cases:
+- 新しいユーザーが初めてKubernetesを試すためのシンプルな方法が必要なとき。
 - 既存のユーザーがクラスターのセットアップを自動化し、アプリケーションをテストする方法が必要なとき。
 - より大きなスコープで、他のエコシステムやインストーラーツールのビルディングブロックが必要なとき。
- New users can start with kubeadm to try Kubernetes out for the first time.
+`kubeadm`は、ラップトップ、クラウドのサーバー群、Raspberry Piなどの様々なマシンにインストールして使えます。クラウドとオンプレミスのどちらにデプロイする場合でも、`kubeadm`はAnsibleやTerraformなどのプロビジョニングシステムに統合できます。
 - Users familiar with Kubernetes can spin up clusters with kubeadm and test their applications.
 - Larger projects can include kubeadm as a building block in a more complex system that can also include other installer tools.
 kubeadm is designed to be a simple way for new users to start trying
 Kubernetes out, possibly for the first time, a way for existing users to
 test their application on and stitch together a cluster easily, and also to be
 a building block in other ecosystem and/or installer tool with a larger
 scope.
 You can install _kubeadm_ very easily on operating systems that support
 installing deb or rpm packages. The responsible SIG for kubeadm,
 [SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle), provides these packages pre-built for you,
 but you may also build them from source for other OSes.
 ### kubeadmの成熟度
 kubeadm's overall feature state is **GA**. Some sub-features, like the configuration
 file API are still under active development. The implementation of creating the cluster
 may change slightly as the tool evolves, but the overall implementation should be pretty stable.
 Any commands under `kubeadm alpha` are by definition, supported on an alpha level.
 ### サポート期間
 Kubernetes releases are generally supported for nine months, and during that
 period a patch release may be issued from the release branch if a severe bug or
 security issue is found. Here are the latest Kubernetes releases and the support
 timeframe; which also applies to `kubeadm`.
 | Kubernetes version | Release month  | End-of-life-month |
 |--------------------|----------------|-------------------|
 | v1.13.x            | December 2018  | September 2019    |
 | v1.14.x            | March 2019     | December 2019     |
 | v1.15.x            | June 2019      | March 2020        |
 | v1.16.x            | September 2019 | June 2020         |
 {{% /capture %}}
 {{% capture prerequisites %}}
- One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
+このガイドを進めるには、以下の環境が必要です。
- 2 GB or more of RAM per machine. Any less leaves little room for your
+
-   apps.
+- UbuntuやCentOSなど、deb/rpmパッケージと互換性のあるLinux OSが動作している1台以上のマシンがあること。
- 2 CPUs or more on the control-plane node
+- マシンごとに2GiB以上のRAMが搭載されていること。それ以下の場合、アプリ実行用のメモリーがほとんど残りません。
- Full network connectivity among all machines in the cluster. A public or
+- コントロールプレーンノードとして使用するマシンには、最低でも2CPU以上あること。
-   private network is fine.
+- クラスター内の全マシン間に完全なネットワーク接続があること。パブリックネットワークとプライベートネットワークのいずれでも使えます。
 また、新しいクラスターで使いたいKubernetesのバージョンをデプロイできるバージョンの`kubeadm`を使用する必要もあります。
 [Kubernetesのバージョンとバージョンスキューポリシー](/ja/docs/setup/release/version-skew-policy/#supported-versions)は、`kubeadm`にもKubernetes全体と同じように当てはまります。Kubernetesと`kubeadm`がサポートするバージョンを理解するには、上記のポリシーを確認してください。このページは、Kubernetes {{< param "version" >}}向けに書かれています。
 kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。一部のサブ機能はまだ活発に開発が行われています。クラスター作成の実装は、ツールの進化に伴ってわずかに変わるかもしれませんが、全体の実装は非常に安定しているはずです。
 {{< note >}}
 `kubeadm alpha`以下のすべてのコマンドは、定義通り、アルファレベルでサポートされています。
 {{< /note >}}
 {{% /capture %}}
@ -70,96 +43,66 @@ timeframe; which also applies to `kubeadm`.
 ## 目的
-* Install a single control-plane Kubernetes cluster or [high availability cluster](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
+* シングルコントロールプレーンのKubernetesクラスターまたは[高可用性クラスター](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)をインストールする
-* Install a Pod network on the cluster so that your Pods can
+* クラスター上にPodネットワークをインストールして、Podがお互いに通信できるようにする
  talk to each other
-## 説明
+## 手順
-### kubeadmのインストール
+### ホストへのkubeadmのインストール
-See ["Installing kubeadm"](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+「[kubeadmのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)」を読んでください。
 {{< note >}}
-If you have already installed kubeadm, run `apt-get update &&
+すでにkubeadmがインストール済みである場合は、最新バージョンのkubeadmを取得するために`apt-get update && apt-get upgrade`や`yum update`を実行してください。
 apt-get upgrade` or `yum update` to get the latest version of kubeadm.
-When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
+アップグレード中、kubeletが数秒ごとに再起動します。これは、kubeadmがkubeletにするべきことを伝えるまで、crashloopの状態で待機するためです。このcrashloopは期待通りの通常の動作です。コントロールプレーンの初期化が完了すれば、kubeletは正常に動作します。
 kubeadm to tell it what to do. This crashloop is expected and normal.
 After you initialize your control-plane, the kubelet runs normally.
 {{< /note >}}
 ### コントロールプレーンノードの初期化
-The control-plane node is the machine where the control plane components run, including
+コントロールプレーンノードとは、{{< glossary_tooltip term_id="etcd" >}}(クラスターのデータベース)や{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}({{< glossary_tooltip text="kubectl" term_id="kubectl" >}}コマンドラインツールが通信する相手)などのコントロールプレーンのコンポーネントが実行されるマシンです。
 etcd (the cluster database) and the API server (which the kubectl CLI
 communicates with).
-1. (Recommended) If you have plans to upgrade this single control-plane kubeadm cluster
+1. (推奨)シングルコントロールプレーンの`kubeadm`クラスターを高可用性クラスターにアップグレードする予定がある場合、`--control-plane-endpoint`を指定して、すべてのコントロールプレーンノードとエンドポイントを共有する必要があります。エンドポイントにはDNSネームやロードバランサーのIPアドレスが使用できます。
-to high availability you should specify the `--control-plane-endpoint` to set the shared endpoint
+1. Podネットワークアドオンを選んで、`kubeadm init`に引数を渡す必要があるかどうか確認してください。選んだサードパーティーのプロバイダーによっては、`--pod-network-cidr`をプロバイダー固有の値に設定する必要がある場合があります。詳しくは、[Podネットワークアドオンのインストール](#pod-network)を参照してください。
-for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer.
+1. (オプション)バージョン1.14から、`kubeadm`はよく知られたドメインソケットのパスリストを用いて、Linux上のコンテナランタイムの検出を試みます。異なるコンテナランタイムを使用する場合やプロビジョニングするノードに2つ以上のランタイムがインストールされている場合、`kubeadm init`に`--cri-socket`引数を指定してください。詳しくは、[ランタイムのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)を読んでください。
-1. Choose a Pod network add-on, and verify whether it requires any arguments to
+1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertize-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
-be passed to kubeadm initialization. Depending on which
+1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。
 third-party provider you choose, you might need to set the `--pod-network-cidr` to
 a provider-specific value. See [Installing a Pod network add-on](#pod-network).
 1. (Optional) Since version 1.14, kubeadm will try to detect the container runtime on Linux
 by using a list of well known domain socket paths. To use different container runtime or
 if there are more than one installed on the provisioned node, specify the `--cri-socket`
 argument to `kubeadm init`. See [Installing runtime](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
 1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
 with the default gateway to set the advertise address for this particular control-plane node's API server.
 To use a different network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
 to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
 must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
 1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
 connectivity to gcr.io registries.
-To initialize the control-plane node run:
+コントロールプレーンノードを初期化するには、次のコマンドを実行します。
 ```bash
 kubeadm init <args>
 ```
-### Considerations about apiserver-advertise-address and ControlPlaneEndpoint
+### apiserver-advertise-addressとControlPlaneEndpointに関する検討
-While `--apiserver-advertise-address` can be used to set the advertise address for this particular
+`--apiserver-advertise-address`は、この特定のコントロールプレーンノードのAPIサーバーへのadvertise addressを設定するために使えますが、`--control-plane-endpoint`は、すべてのコントロールプレーンノード共有のエンドポイントを設定するために使えます。
 control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint
 for all control-plane nodes.
-`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses.
+`--control-plane-endpoint`はIPアドレスを受け付けますが、IPアドレスへマッピングされるDNSネームも使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。
 Please contact your network administrator to evaluate possible solutions with respect to such mapping.
-Here is an example mapping:
+以下にマッピングの例を示します。
 ```
 192.168.0.102 cluster-endpoint
 ```
-Where `192.168.0.102` is the IP address of this node and `cluster-endpoint` is a custom DNS name that maps to this IP.
+ここでは、`192.168.0.102`がこのノードのIPアドレスであり、`cluster-endpoint`がこのIPアドレスへとマッピングされるカスタムDNSネームです。このように設定することで、`--control-plane-endpoint=cluster-endpoint`を`kubeadm init`に渡せるようになり、`kubeadm join`にも同じDNSネームを渡せます。後で`cluster-endpoint`を修正して、高可用性が必要なシナリオでロードバランサーのアドレスを指すようにすることができます。
 This will allow you to pass `--control-plane-endpoint=cluster-endpoint` to `kubeadm init` and pass the same DNS name to
 `kubeadm join`. Later you can modify `cluster-endpoint` to point to the address of your load-balancer in an
 high availability scenario.
-Turning a single control plane cluster created without `--control-plane-endpoint` into a highly available cluster
+kubeadmでは、`--control-plane-endpoint`を渡さずに構築したシングルコントロールプレーンのクラスターを高可用性クラスターに切り替えることはサポートされていません。
 is not supported by kubeadm.
-### 詳細
+### 詳細な情報
-For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm/).
+`kubeadm init`の引数のより詳細な情報は、[kubeadmリファレンスガイド](/docs/reference/setup-tools/kubeadm/kubeadm/)を参照してください。
-For a complete list of configuration options, see the [configuration file documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
+設定オプションの全リストは、[設定ファイルのドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)で確認できます。
-To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
+コントロールプレーンコンポーネントやetcdサーバーのliveness probeへのオプションのIPv6の割り当てなど、コントロールプレーンのコンポーネントをカスタマイズしたい場合は、[カスタムの引数](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)に示されている方法で各コンポーネントに追加の引数を与えてください。
-To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
+`kubeadm init`を再び実行する場合は、初めに[クラスターの破壊](#tear-down)を行う必要があります。
-If you join a node with a different architecture to your cluster, make sure that your deployed DaemonSets
+もし異なるアーキテクチャのノードをクラスターにjoinさせたい場合は、デプロイしたDaemonSetがそのアーキテクチャ向けのコンテナイメージをサポートしているか確認してください。
 have container image support for this architecture.
-`kubeadm init` first runs a series of prechecks to ensure that the machine
+初めに`kubeadm init`は、マシンがKubernetesを実行する準備ができているかを確認する、一連の事前チェックを行います。これらの事前チェックはエラー発生時には警告を表示して終了します。次に、`kubeadm init`はクラスターのコントロールプレーンのコンポーネントをダウンロードしてインストールします。これには数分掛かるかもしれません。出力は次のようになります。
 is ready to run Kubernetes. These prechecks expose warnings and exit on errors. `kubeadm init`
 then downloads and installs the cluster control plane components. This may take several minutes.
 The output should look like:
 ```none
 [init] Using Kubernetes version: vX.Y.Z
@ -229,8 +172,7 @@ as root:
  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
 ```
-To make kubectl work for your non-root user, run these commands, which are
+kubectlをroot以外のユーザーでも実行できるようにするには、次のコマンドを実行します。これらのコマンドは、`kubectl init`の出力の中にも書かれています。
 also part of the `kubeadm init` output:
 ```bash
 mkdir -p $HOME/.kube
@ -238,172 +180,140 @@ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config
 ```
-Alternatively, if you are the `root` user, you can run:
+あなたが`root`ユーザーである場合は、代わりに次のコマンドを実行します。
 ```bash
 export KUBECONFIG=/etc/kubernetes/admin.conf
 ```
-Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
+`kubeadm init`が出力した`kubeadm join`コマンドをメモしておいてください。[クラスターにノードを追加する](#join-nodes)ために、このコマンドが必要になります。
 need this command to [join nodes to your cluster](#join-nodes).
-The token is used for mutual authentication between the control-plane node and the joining
+トークンは、コントロールプレーンノードと追加ノードの間の相互認証に使用します。ここに含まれるトークンには秘密の情報が含まれます。このトークンを知っていれば、誰でもクラスターに認証済みノードを追加できてしまうため、取り扱いには注意してください。`kubeadm token`コマンドを使用すると、これらのトークンの一覧、作成、削除ができます。詳しくは[kubeadmリファレンスガイド](/docs/reference/setup-tools/kubeadm/kubeadm-token/)を読んでください。
 nodes. The token included here is secret. Keep it safe, because anyone with this
 token can add authenticated nodes to your cluster. These tokens can be listed,
 created, and deleted with the `kubeadm token` command. See the
 [kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm-token/).
 ### Podネットワークアドオンのインストール {#pod-network}
 {{< caution >}}
-This section contains important information about installation and deployment order. Read it carefully before proceeding.
+このセクションには、ネットワークのセットアップとデプロイの順序に関する重要な情報が書かれています。先に進む前に以下のすべてのアドバイスを熟読してください。
 **Pod同士が通信できるようにするには、{{< glossary_tooltip text="Container Network Interface" term_id="cni" >}}(CNI)をベースとするPodネットワークアドオンをデプロイしなければなりません。ネットワークアドオンをインストールする前には、Cluster DNS(CoreDNS)は起動しません。**
 - Podネットワークがホストネットワークと決して重ならないように気をつけてください。もし重なると、様々な問題が起こってしまう可能性があります。(ネットワークプラグインが優先するPodネットワークとホストのネットワークの一部が衝突することが分かった場合、適切な代わりのCIDRを考える必要があります。そして、`kubeadm init`の実行時に`--pod-network-cidr`にそのCIDRを指定し、ネットワークプラグインのYAMLでは代わりにそのCIDRを使用してください)
 - デフォルトでは、`kubeadm`は[RBAC](/docs/reference/access-authn-authz/rbac/)(role based access control)の使用を強制します。PodネットワークプラグインがRBACをサポートしていて、またそのデプロイに使用するマニフェストもRBACをサポートしていることを確認してください。
 - クラスターでIPv6を使用したい場合、デュアルスタック、IPv6のみのシングルスタックのネットワークのいずれであっても、PodネットワークプラグインがIPv6をサポートしていることを確認してください。IPv6のサポートは、CNIの[v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0)で追加されました。
 {{< /caution >}}
-You must install a Pod network add-on so that your Pods can communicate with
+CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/docs/concepts/services-networking/networkpolicies/)もサポートしています。
 each other.
-**The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed.
+利用できる[ネットワークアドオンとネットワークポリシーアドオン](/docs/concepts/cluster-administration/addons/#networking-and-network-policy)のリストを確認してください。
 kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
-Several projects provide Kubernetes Pod networks using CNI, some of which also
+Podネットワークアドオンをインストールするには、コントロールプレーンノード上またはkubeconfigクレデンシャルを持っているノード上で、次のコマンドを実行します。
 support [Network Policy](/ja/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/ja/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
 - IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
 - [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9.
 Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/ja/docs/reference/access-authn-authz/rbac/).
 Make sure that your network manifest supports RBAC.
 Also, beware, that your Pod network must not overlap with any of the host networks as this can cause issues.
 If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR replacement and use that during `kubeadm init` with `--pod-network-cidr` and as a replacement in your network plugin’s YAML.
 You can install a Pod network add-on with the following command on the control-plane node or a node that has the kubeconfig credentials:
 ```bash
 kubectl apply -f <add-on.yaml>
 ```
-You can install only one Pod network per cluster.
+インストールできるPodネットワークは、クラスターごとに1つだけです。以下の手順で、いくつかのよく使われるPodネットワークプラグインをインストールできます。
 Below you can find installation instructions for some popular Pod network plugins:
 {{< tabs name="tabs-pod-install" >}}
 {{% tab name="Calico" %}}
-For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
+[Calico](https://docs.projectcalico.org/latest/introduction/)は、ネットワークとネットワークポリシーのプロバイダーです。Calicoは柔軟なさまざまなネットワークオプションをサポートするため、自分の状況に適した最も効果的なオプションを選択できます。たとえば、ネットワークのオーバーレイの有無や、BGPの有無が選べます。Calicoは、ホスト、Pod、(もしIstioとEnvoyを使っている場合)サービスメッシュレイヤー上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用しています。Calicoは、`amd64`、`arm64`、`ppc64le`を含む複数のアーキテクチャで動作します。
-For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64`, `arm64`, and `ppc64le` only.
+デフォルトでは、Calicoは`192.168.0.0/16`をPodネットワークのCIDRとして使いますが、このCIDRはcalico.yamlファイルで設定できます。Calicoを正しく動作させるためには、これと同じCIDRを`--pod-network-cidr=192.168.0.0/16`フラグまたはkubeadmの設定を使って、`kubeadm init`コマンドに渡す必要があります。
 ```shell
-kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
+kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
 ```
 {{% /tab %}}
 {{% tab name="Cilium" %}}
-For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
+Ciliumを正しく動作させるためには、`kubeadm init`に `--pod-network-cidr=10.217.0.0/16`を渡さなければなりません。
-To deploy Cilium you just need to run:
+Ciliumのデプロイは、次のコマンドを実行するだけでできます。
 ```shell
 kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
 ```
-Once all Cilium Pods are marked as `READY`, you start using your cluster.
+すべてのCilium Podが`READY`とマークされたら、クラスターを使い始められます。
 ```shell
 kubectl get pods -n kube-system --selector=k8s-app=cilium
 ```
-The output is similar to this:
+
 出力は次のようになります。
 ```
 NAME           READY   STATUS    RESTARTS   AGE
 cilium-drxkl   1/1     Running   0          18m
 ```
-Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
+Ciliumはkube-proxyの代わりに利用することもできます。詳しくは[Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free)を読んでください。
 For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
 KubernetesでのCiliumの使い方に関するより詳しい情報は、[Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/)を参照してください。
 {{% /tab %}}
 {{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
+[Contiv-VPP](https://contivpp.io/)は、[FD.io VPP](https://fd.io/)をベースとするプログラマブルなCNF vSwitchを採用し、機能豊富で高性能なクラウドネイティブなネットワーキングとサービスを提供します。
 offering feature-rich & high-performance cloud-native networking and services.
-It implements k8s services and network policies in the user space (on VPP).
+Contiv-VPPは、k8sサービスとネットワークポリシーを(VPP上の)ユーザースペースで実装しています。
-Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
+こちらのインストールガイドを参照してください: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
 {{% /tab %}}
 {{% tab name="Flannel" %}}
 `flannel`を正しく動作させるためには、`--pod-network-cidr=10.244.0.0/16`を`kubeadm init`に渡す必要があります。
-For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16` to `kubeadm init`.
+オーバーレイネットワークに参加しているすべてのホスト上で、ファイアウォールのルールが、UDPポート8285と8472のトラフィックを許可するように設定されていることを確認してください。この設定に関するより詳しい情報は、Flannelのトラブルシューティングガイドの[Firewall](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls)のセクションを参照してください。
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+Flannelは、Linux下の`amd64`、`arm`、`arm64`、`ppc64le`、`s390x`アーキテクチャ上で動作します。Windows(`amd64`)はv0.11.0でサポートされたとされていますが、使用方法はドキュメントに書かれていません。
 to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
 please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
 Make sure that your firewall rules allow UDP ports 8285 and 8472 traffic for all hosts participating in the overlay network.
 see [here
 ](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls).
 Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` under Linux.
 Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented.
 ```shell
 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
 ```
-For more information about `flannel`, see [the CoreOS flannel repository on GitHub
+`flannel`に関するより詳しい情報は、[GitHub上のCoreOSのflannelリポジトリ](https://github.com/coreos/flannel)を参照してください。
 ](https://github.com/coreos/flannel).
 {{% /tab %}}
 {{% tab name="Kube-router" %}}
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+Kube-routerは、ノードへのPod CIDRの割り当てをkube-controller-managerに依存しています。そのため、`kubeadm init`時に`--pod-network-cidr`フラグを使用する必要があります。
 to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
 please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
+Kube-routerは、Podネットワーク、ネットワークポリシー、および高性能なIP Virtual Server(IPVS)/Linux Virtual Server(LVS)ベースのサービスプロキシーを提供します。
-Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
+Kube-routerを有効にしたKubernetesクラスターをセットアップするために`kubeadm`ツールを使用する方法については、公式の[セットアップガイド](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md)を参照してください。
 For information on setting up Kubernetes cluster with Kube-router using kubeadm, please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
 {{% /tab %}}
 {{% tab name="Weave Net" %}}
-Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+Weave Netを使用してKubernetesクラスターをセットアップするより詳しい情報は、[アドオンを使用してKubernetesを統合する](https://www.weave.works/docs/net/latest/kube-addon/)を読んでください。
 to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
 please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/).
+Weave Netは、`amd64`、`arm`、`arm64`、`ppc64le`プラットフォームで追加の操作なしで動作します。Weave Netはデフォルトでharipinモードをセットします。このモードでは、Pod同士はPodIPを知らなくても、Service IPアドレス経由でアクセスできます。
 Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` without any extra action required.
 Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
 if they don't know their PodIP.
 ```shell
 kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
 ```
 {{% /tab %}}
 {{< /tabs >}}
-Once a Pod network has been installed, you can confirm that it is working by
+Podネットワークがインストールされたら、`kubectl get pods --all-namespaces`の出力結果でCoreDNS Podが`Running`状態であることをチェックすることで、ネットワークが動作していることを確認できます。そして、一度CoreDNS Podが動作すれば、続けてノードを追加できます。
 checking that the CoreDNS Pod is Running in the output of `kubectl get pods --all-namespaces`.
 And once the CoreDNS Pod is up and running, you can continue by joining your nodes.
-If your network is not working or CoreDNS is not in the Running state, checkout our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
+もしネットワークやCoreDNSが`Running`状態にならない場合は、`kubeadm`の[トラブルシューティングガイド](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)をチェックしてください。
 ### コントロールプレーンノードの隔離
-By default, your cluster will not schedule Pods on the control-plane node for security
+デフォルトでは、セキュリティ上の理由により、クラスターはコントロールプレーンノードにPodをスケジューリングしません。たとえば、開発用のKubernetesシングルマシンのクラスターなどで、Podをコントロールプレーンノードにスケジューリングしたい場合は、次のコマンドを実行します。
 reasons. If you want to be able to schedule Pods on the control-plane node, e.g. for a
 single-machine Kubernetes cluster for development, run:
 ```bash
 kubectl taint nodes --all node-role.kubernetes.io/master-
 ```
-With output looking something like:
+出力は次のようになります。
 ```
 node "test-01" untainted
@ -411,31 +321,29 @@ taint "node-role.kubernetes.io/master:" not found
 taint "node-role.kubernetes.io/master:" not found
 ```
-This will remove the `node-role.kubernetes.io/master` taint from any nodes that
+このコマンドは、コントロールプレーンノードを含むすべてのノードから`node-role.kubernetes.io/master`taintを削除します。その結果、スケジューラーはどこにでもPodをスケジューリングできるようになります。
 have it, including the control-plane node, meaning that the scheduler will then be able
 to schedule Pods everywhere.
 ### ノードの追加 {#join-nodes}
-The nodes are where your workloads (containers and Pods, etc) run. To add new nodes to your cluster do the following for each machine:
+ノードは、ワークロード(コンテナやPodなど)が実行される場所です。新しいノードをクラスターに追加するためには、各マシンに対して、以下の手順を実行してください。
-* SSH to the machine
+* マシンへSSHする
-* Become root (e.g. `sudo su -`)
+* rootになる(例: `sudo su -`)
-* Run the command that was output by `kubeadm init`. For example:
+* `kubeadm init`実行時に出力されたコマンドを実行する。たとえば、次のようなコマンドです。
-``` bash
+```bash
 kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>
 ```
-If you do not have the token, you can get it by running the following command on the control-plane node:
+トークンがわからない場合は、コントロールプレーンノードで次のコマンドを実行すると取得できます。
-``` bash
+```bash
 kubeadm token list
 ```
-The output is similar to this:
+出力は次のようになります。
-``` console
+```console
 TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
 8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
                                                   signing          token generated by     bootstrappers:
@ -443,42 +351,41 @@ TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION
                                                                                           default-node-token
 ```
-By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired,
+デフォルトでは、トークンは24時間後に有効期限が切れます。もし現在のトークンの有効期限が切れた後にクラスターにノードを参加させたい場合は、コントロールプレーンノードで次のコマンドを実行することで、新しいトークンを生成できます。
 you can create a new token by running the following command on the control-plane node:
-``` bash
+```bash
 kubeadm token create
 ```
-The output is similar to this:
+このコマンドの出力は次のようになります。
-``` console
+```console
 5didvk.d09sbcov8ph2amjw
 ```
-If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the control-plane node:
+もし`--discovery-token-ca-cert-hash`の値がわからない場合は、コントロールプレーンノード上で次のコマンドチェーンを実行することで取得できます。
-``` bash
+```bash
 openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'
 ```
-The output is similar to this:
+出力は次のようになります。
-``` console
+```console
 8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
 ```
 {{< note >}}
-To specify an IPv6 tuple for `<control-plane-host>:<control-plane-ip>`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
+IPv6タプルを`<control-plane-host>:<control-plane-ip>`に指定するためには、IPv6アドレスをブラケットで囲みます。たとえば、`[fd00::101]:2073`のように書きます。
 {{< /note >}}
-The output should look something like:
+出力は次のようになります。
 ```
 [preflight] Running pre-flight checks
-... (log output of join workflow) ...
+... (joinワークフローのログ出力) ...
 Node join complete:
 * Certificate signing request sent to control-plane and response
@ -488,154 +395,134 @@ Node join complete:
 Run 'kubectl get nodes' on control-plane to see this machine join.
 ```
-A few seconds later, you should notice this node in the output from `kubectl get
+数秒後、コントロールプレーンノード上で`kubectl get nodes`を実行すると、出力内にこのノードが表示されるはずです。
 nodes` when run on the control-plane node.
-### (任意)コントロールプレーンノード以外のマシンからのクラスター操作
+### (オプション)コントロールプレーンノード以外のマシンからのクラスター操作
-In order to get a kubectl on some other computer (e.g. laptop) to talk to your
+他のコンピューター(例: ラップトップ)上のkubectlがクラスターと通信できるようにするためには、次のようにして、administratorのkubeconfigファイルをコントロールプレーンノードからそのコンピューター上にコピーする必要があります。
 cluster, you need to copy the administrator kubeconfig file from your control-plane node
 to your workstation like this:
-``` bash
+```bash
 scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
 kubectl --kubeconfig ./admin.conf get nodes
 ```
 {{< note >}}
-The example above assumes SSH access is enabled for root. If that is not the
+上の例では、rootユーザーに対するSSH接続が有効であることを仮定しています。もしそうでない場合は、`admin.conf`ファイルを誰か他のユーザーからアクセスできるようにコピーした上で、代わりにそのユーザーを使って`scp`してください。
 case, you can copy the `admin.conf` file to be accessible by some other user
 and `scp` using that other user instead.
-The `admin.conf` file gives the user _superuser_ privileges over the cluster.
+`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、一部の権限をホワイトリストに加えたユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name <CN>`コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限をホワイトリストに加えます。
 This file should be used sparingly. For normal users, it's recommended to
 generate an unique credential to which you whitelist privileges. You can do
 this with the `kubeadm alpha kubeconfig user --client-name <CN>`
 command. That command will print out a KubeConfig file to STDOUT which you
 should save to a file and distribute to your user. After that, whitelist
 privileges by using `kubectl create (cluster)rolebinding`.
 {{< /note >}}
-### (任意) APIサーバーをlocalhostへプロキシ
+### (オプション)APIサーバーをlocalhostへプロキシする
-If you want to connect to the API Server from outside the cluster you can use
+クラスターの外部からAPIサーバーに接続したいときは、次のように`kubectl proxy`コマンドが使えます。
 `kubectl proxy`:
 ```bash
 scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
 kubectl --kubeconfig ./admin.conf proxy
 ```
-You can now access the API Server locally at `http://localhost:8001/api/v1`
+これで、ローカルの`http://localhost:8001/api/v1`からAPIサーバーにアクセスできるようになります。
-## クラスターの削除 {#tear-down}
+## クリーンアップ {#tear-down}
-To undo what kubeadm did, you should first [drain the
+テストのためにクラスターに破棄可能なサーバーを使用した場合、サーバーのスイッチをオフにすれば、以降のクリーンアップの作業は必要ありません。クラスターのローカルの設定を削除するには、`kubectl config delete-cluster`を実行します。
 node](/ja/docs/reference/generated/kubectl/kubectl-commands#drain) and make
 sure that the node is empty before shutting it down.
-Talking to the control-plane node with the appropriate credentials, run:
+しかし、もしよりきれいにクラスターのプロビジョンをもとに戻したい場合は、初めに[ノードのdrain](/docs/reference/generated/kubectl/kubectl-commands#drain)を行い、ノードが空になっていることを確認した後、ノードの設定を削除する必要があります。
 ### ノードの削除
 適切なクレデンシャルを使用してコントロールプレーンノードに削除することを伝えます。次のコマンドを実行してください。
 ```bash
 kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
 kubectl delete node <node name>
 ```
-Then, on the node being removed, reset all kubeadm installed state:
+その後、ノードが削除されたら、`kubeadm`のインストール状態をすべてリセットします。
 ```bash
 kubeadm reset
 ```
-The reset process does not reset or clean up iptables rules or IPVS tables. If you wish to reset iptables, you must do so manually:
+リセットプロセスでは、iptablesのルールやIPVS tablesのリセットやクリーンアップは行われません。iptablesをリセットしたい場合は、次のように手動でコマンドを実行する必要があります。
 ```bash
 iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
 ```
-If you want to reset the IPVS tables, you must run the following command:
+IPVS tablesをリセットしたい場合は、次のコマンドを実行する必要があります。
 ```bash
 ipvsadm -C
 ```
-If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
+クラスターのセットアップを最初から始めたいときは、`kubeadm init`や`kubeadm join`を適切な引数を付けて実行すればいいだけです。
 appropriate arguments.
-More options and information about the
+### コントロールプレーンのクリーンアップ
 [`kubeadm reset command`](/ja/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
-## クラスターの維持 {#lifecycle}
+コントロールホスト上で`kubeadm reset`を実行すると、ベストエフォートでのクリーンアップが実行できます。
-Instructions for maintaining kubeadm clusters (e.g. upgrades,downgrades, etc.) can be found [here.](/ja/docs/tasks/administer-cluster/kubeadm)
+このサブコマンドとオプションに関するより詳しい情報は、[`kubeadm reset`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/)リファレンスドキュメントを読んでください。
-## 他アドオンの参照 {#other-addons}
+{{% /capture %}}
-See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons,
+{{% capture discussion %}}
 including tools for logging, monitoring, network policy, visualization &amp;
 control of your Kubernetes cluster.
 ## 次の手順 {#whats-next}
-* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
+* [Sonobuoy](https://github.com/heptio/sonobuoy)を使用してクラスターが適切に動作しているか検証する。
-* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm)
+* <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
-* Learn more about Kubernetes [concepts](/ja/docs/concepts/) and [`kubectl`](/ja/docs/user-guide/kubectl-overview/).
+* `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
-* Configure log rotation. You can use **logrotate** for that. When using Docker, you can specify log rotation options for Docker daemon, for example `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`. See [Configure and troubleshoot the Docker daemon](https://docs.docker.com/engine/admin/) for more details.
+* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/docs/user-guide/kubectl-overview/)についてもっと学ぶ。
-* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
+* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
-of Pod network add-ons.
+* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。
-## フィードバック {#feedback}
+### フィードバック {#feedback}
-* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* バグを見つけた場合は、[kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)で報告してください。
-* For support, visit kubeadm Slack Channel:
+* サポートを受けたい場合は、[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)Slackチャンネルを訪ねてください。
-  [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
+* General SIG Cluster Lifecycle development Slackチャンネル:
 * General SIG Cluster Lifecycle Development Slack Channel:
  [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
-* SIG Cluster Lifecycle [SIG information](#TODO)
+* SIG Cluster Lifecycle [SIG information](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle#readme)
-* SIG Cluster Lifecycle Mailing List:
+* SIG Cluster Lifecycleメーリングリスト:
  [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
 ## バージョン互換ポリシー {#version-skew-policy}
-The kubeadm CLI tool of version vX.Y may deploy clusters with a control plane of version vX.Y or vX.(Y-1).
+バージョンvX.Yの`kubeadm`ツールは、バージョンvX.YまたはvX.(Y-1)のコントロールプレーンを持つクラスターをデプロイできます。また、`kubeadm` vX.Yは、kubeadmで構築された既存のvX.(Y-1)のクラスターをアップグレートできます。
 kubeadm CLI vX.Y can also upgrade an existing kubeadm-created cluster of version vX.(Y-1).
-Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be able to deploy vX.(Y+1) clusters.
+未来を見ることはできないため、kubeadm CLI vX.YはvX.(Y+1)をデプロイすることはできません。
-Example: kubeadm v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
+例: `kubeadm` v1.8は、v1.7とv1.8のクラスターをデプロイでき、v1.7のkubeadmで構築されたクラスターをv1.8にアップグレートできます。
 v1.8.
-These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
+kubeletとコントロールプレーンの間や、他のKubernetesコンポーネント間のバージョンの差異に関する詳しい情報は、以下の資料を確認してください。
-* Kubernetes [version and version-skew policy](/ja/docs/setup/release/version-skew-policy/)
+* Kubernetes[バージョンスキューサポートポリシー](/ja/docs/setup/release/version-skew-policy/)
-* Kubeadm-specific [installation guide](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
+* Kubeadm特有の[インストールガイド](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
 ## kubeadmは様々なプラットフォームで動く
 kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x
 following the [multi-platform
 proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md).
 Multiplatform container images for the control plane and addons are also supported since v1.12.
 Only some of the network providers offer solutions for all platforms. Please consult the list of
 network providers above or the documentation from each provider to figure out whether the provider
 supports your chosen platform.
 ## 制限事項 {#limitations}
-The cluster created here has a single control-plane node, with a single etcd database
+### クラスターのレジリエンス {#resilience}
 running on it. This means that if the control-plane node fails, your cluster may lose
 data and may need to be recreated from scratch.
-Workarounds:
+ここで作られたクラスターは、1つのコントロールプレーンノードと、その上で動作する1つのetcdデータベースしか持ちません。つまり、コントロールプレーンノードが故障した場合、クラスターのデータは失われ、クラスターを最初から作り直す必要があるかもしれないということです。
-* Regularly [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
+対処方法:
  etcd data directory configured by kubeadm is at `/var/lib/etcd` on the control-plane node.
-* Use multiple control-plane nodes by completing the
+* 定期的に[etcdをバックアップ](https://coreos.com/etcd/docs/latest/admin_guide.html)する。kubeadmが設定するetcdのデータディレクトリは、コントロールプレーンノードの`/var/lib/etcd`にあります。
-  [HA setup](/ja/docs/setup/independent/ha-topology) instead.
+
 * 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、より高い可用性を提供するクラスターのトポロジーの選択について説明してます。
 ### プラットフォームの互換性 {#multi-platform}
 kubeadmのdeb/rpmパッケージおよびバイナリは、[multi-platform proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md)に従い、amd64、arm(32ビット)、arm64、ppc64le、およびs390x向けにビルドされています。
 マルチプラットフォームのコントロールプレーンおよびアドオン用のコンテナイメージも、v1.12からサポートされています。
 すべてのプラットフォーム向けのソリューションを提供しているネットワークプロバイダーは一部のみです。それぞれのプロバイダーが選択したプラットフォームをサポートしているかどうかを確認するには、前述のネットワークプロバイダーのリストを参照してください。
 ## トラブルシューティング {#troubleshooting}
-If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
+kubeadmに関する問題が起きたときは、[トラブルシューティングドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を確認してください。
 {{% /capture %}}
--- a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@ -99,7 +99,7 @@ etcdポートはコントロールプレーンノードに含まれています
 使用するPodネットワークプラグイン（以下を参照）のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。
-## ランタイムのインストール
+## ランタイムのインストール {#installing-runtime}
 v1.6.0以降、KubernetesはデフォルトでCRI(Container Runtime Interface)の使用を有効にしています。
--- a/content/ja/docs/setup/release/version-skew-policy.md
+++ b/content/ja/docs/setup/release/version-skew-policy.md
@ -10,7 +10,7 @@ weight: 30
 {{% capture body %}}
-## サポートされるバージョン
+## サポートされるバージョン {#supported-versions}
 Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](http://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)を参照してください。
--- a/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-init-containers.md
@ -1,11 +1,11 @@
 ---
-title: Init Containerのデバッグ
+title: Initコンテナのデバッグ
 content_template: templates/task
 ---
 {{% capture overview %}}
-このページでは、Init Containerの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを`<pod-name>`、Init Containerを`<init-container-1>`および`<init-container-2>`として参照しています。
+このページでは、Initコンテナの実行に関連する問題を調査する方法を説明します。以下のコマンドラインの例では、Podを`<pod-name>`、Initコンテナを`<init-container-1>`および`<init-container-2>`として参照しています。
 {{% /capture %}}
@ -13,14 +13,14 @@ content_template: templates/task
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* [Init Container](/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
+* [Initコンテナ](/ja/docs/concepts/abstractions/init-containers/)の基本を理解しておきましょう。
-* [Init Containerを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
+* [Initコンテナを設定](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)しておきましょう。
 {{% /capture %}}
 {{% capture steps %}}
-## Init Containerのステータスを確認する
+## Initコンテナのステータスを確認する
 Podのステータスを表示します:
@ -28,7 +28,7 @@ Podのステータスを表示します:
 kubectl get pod <pod-name>
 ```
-たとえば、`Init：1/2`というステータスは、2つのInit Containerのうちの1つが正常に完了したことを示します。
+たとえば、`Init：1/2`というステータスは、2つのInitコンテナのうちの1つが正常に完了したことを示します。
 ```
 NAME         READY     STATUS     RESTARTS   AGE
@ -37,15 +37,15 @@ NAME         READY     STATUS     RESTARTS   AGE
 ステータス値とその意味の例については、[Podのステータスを理解する](#understanding-pod-status)を参照してください。
-## Init Containerの詳細を取得する
+## Initコンテナの詳細を取得する
-Init Containerの実行に関する詳細情報を表示します:
+Initコンテナの実行に関する詳細情報を表示します:
 ```shell
 kubectl describe pod <pod-name>
 ```
-たとえば、2つのInit Containerを持つPodでは、次のように表示されます:
+たとえば、2つのInitコンテナを持つPodでは、次のように表示されます:
 ```
 Init Containers:
@ -75,7 +75,7 @@ Init Containers:
    ...
 ```
-また、Pod Specの`status.initContainerStatuses`フィールドを読むことでプログラムでInit Containerのステータスにアクセスすることもできます。:
+また、Pod Specの`status.initContainerStatuses`フィールドを読むことでプログラムでInitコンテナのステータスにアクセスすることもできます。:
 ```shell
@ -85,15 +85,15 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
 このコマンドは生のJSONで上記と同じ情報を返します。
-## Init Containerのログにアクセスする
+## Initコンテナのログにアクセスする
-ログにアクセスするには、Init Container名とPod名を渡します。
+ログにアクセスするには、Initコンテナ名とPod名を渡します。
 ```shell
 kubectl logs <pod-name> -c <init-container-2>
 ```
-シェルスクリプトを実行するInit Containerは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。
+シェルスクリプトを実行するInitコンテナは、実行時にコマンドを出力します。たとえば、スクリプトの始めに`set -x`を実行することでBashで同じことができます。
 {{% /capture %}}
@ -101,15 +101,15 @@ kubectl logs <pod-name> -c <init-container-2>
 ## Podのステータスを理解する
-`Init：`で始まるPodステータスはInit Containerの実行ステータスを要約します。以下の表は、Init Containerのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。
+`Init：`で始まるPodステータスはInitコンテナの実行ステータスを要約します。以下の表は、Initコンテナのデバッグ中に表示される可能性のあるステータス値の例をいくつか示しています。
 ステータス | 意味
 ------ | -------
-`Init:N/M` | Podは`M`個のInit Containerを持ち、これまでに`N`個完了しました。
+`Init:N/M` | Podは`M`個のInitコンテナを持ち、これまでに`N`個完了しました。
-`Init:Error` | Init Containerが実行に失敗しました。
+`Init:Error` | Initコンテナが実行に失敗しました。
-`Init:CrashLoopBackOff` | Init Containerが繰り返し失敗しました。
+`Init:CrashLoopBackOff` | Initコンテナが繰り返し失敗しました。
-`Pending` | PodはまだInit Containerの実行を開始していません。
+`Pending` | PodはまだInitコンテナの実行を開始していません。
-`PodInitializing` or `Running` | PodはすでにInit Containerの実行を終了しています。
+`PodInitializing` or `Running` | PodはすでにInitコンテナの実行を終了しています。
 {{% /capture %}}
--- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md
@ -4,8 +4,8 @@ title: Serviceのデバッグ
 ---
 {{% capture overview %}}
-新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、`Service`が適切に機能しないというものです。
+新規にKubernetesをインストールした環境でかなり頻繁に発生する問題は、Serviceが適切に機能しないというものです。
-`Deployment`を実行して`Service`を作成したにもかかわらず、アクセスしようとしても応答がありません。
+Deployment（または他のワークロードコントローラー）を通じてPodを実行し、サービスを作成したにもかかわらず、アクセスしようとしても応答がありません。
 何が問題になっているのかを理解するのに、このドキュメントがきっと役立つでしょう。
@ -14,47 +14,20 @@ title: Serviceのデバッグ
 {{% capture body %}}
 ## 規則
 このドキュメントでは全体を通して、実行可能なさまざまなコマンドが示されます。
 中には`Pod`内で実行する必要があるコマンドもあれば、Kubernetesの`ノード`上で実行する必要があるコマンドや、`kubectl`とクラスターの認証情報がある場所であればどこでも実行できるコマンドもあります。
 期待される内容を明確にするために、このドキュメントでは次の規則を使用します。
 コマンド"COMMAND"が`Pod`内で実行され、"OUTPUT"を出力すると期待される場合:
 ```shell
 u@pod$ COMMAND
 OUTPUT
 ```
 コマンド"COMMAND"が`Node`上で実行され、"OUTPUT"を出力すると期待される場合:
 ```shell
 u@node$ COMMAND
 OUTPUT
 ```
 コマンドが"kubectl ARGS"の場合:
 ```shell
 kubectl ARGS
 OUTPUT
 ```
 ## Pod内でコマンドを実行する
-ここでの多くのステップでは、クラスターで実行されている`Pod`が見ているものを確認する必要があります。
+ここでの多くのステップでは、クラスターで実行されているPodが見ているものを確認する必要があります。
-これを行う最も簡単な方法は、インタラクティブなalpineの`Pod`を実行することです。
+これを行う最も簡単な方法は、インタラクティブなalpineのPodを実行することです。
 ```none
 kubectl run -it --rm --restart=Never alpine --image=alpine sh
 / #
 ```
 {{< note >}}
 コマンドプロンプトが表示されない場合は、Enterキーを押してみてください。
 {{< /note >}}
-使用したい実行中の`Pod`が既にある場合は、以下のようにしてその`Pod`内でコマンドを実行できます。
+使用したい実行中のPodが既にある場合は、以下のようにしてそのPod内でコマンドを実行できます。
 ```shell
 kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
@ -62,20 +35,21 @@ kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>
 ## セットアップ
-このドキュメントのウォークスルーのために、いくつかの`Pod`を実行しましょう。
+このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。
-おそらくあなた自身の`Service`をデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
+おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。
 ```shell
 kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
-                        --labels=app=hostnames \
+                      --replicas=3
-                        --port=9376 \
+```
-                        --replicas=3
+```none
 deployment.apps/hostnames created
 ```
 `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。
 {{< note >}}
-これは、次のYAMLで`Deployment`を開始した場合と同じです。
+これは、次のYAMLでDeploymentを開始した場合と同じです。
 ```yaml
 apiVersion: apps/v1
@ -85,58 +59,101 @@ metadata:
 spec:
  selector:
    matchLabels:
-      app: hostnames
+      run: hostnames
  replicas: 3
  template:
    metadata:
      labels:
-        app: hostnames
+        run: hostnames
    spec:
      containers:
      - name: hostnames
        image: k8s.gcr.io/serve_hostname
        ports:
        - containerPort: 9376
          protocol: TCP
 ```
 "run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。
 {{< /note >}}
-`Pod`が実行中であることを確認してください。
+Podが実行されていることを確認できます。
 ```shell
-kubectl get pods -l app=hostnames
+kubectl get pods -l run=hostnames
 ```
 ```none
 NAME                        READY     STATUS    RESTARTS   AGE
 hostnames-632524106-bbpiw   1/1       Running   0          2m
 hostnames-632524106-ly40y   1/1       Running   0          2m
 hostnames-632524106-tlaok   1/1       Running   0          2m
 ```
-## Serviceは存在するか？
+Podが機能していることも確認できます。
-
+Pod IP アドレスリストを取得し、直接テストできます。
 賢明な読者は、`Service`をまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。
 では、存在しない`Service`にアクセスしようとするとどうなるでしょうか？
 この`Service`を名前で利用する別の`Pod`があると仮定すると、次のような結果が得られます。
 ```shell
-u@pod$ wget -O- hostnames
+kubectl get pods -l run=hostnames \
    -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
 ```
 ```none
 10.244.0.5
 10.244.0.6
 10.244.0.7
 ```
 このウォークスルーに使用されるサンプルコンテナは、ポート9376でHTTPを介して独自のホスト名を提供するだけですが、独自のアプリをデバッグする場合は、Podがリッスンしているポート番号を使用する必要があります。
 Pod内から実行します。
 ```shell
 for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
    wget -qO- $ep
 done
 ```
 次のように表示されます。
 ```
 hostnames-0uton
 hostnames-bvc05
 hostnames-yp2kp
 ```
 この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。
 なにが起きているかを確認するために`kubectl logs`が役立ちます、Podに直接に入りデバッグする場合は `kubectl exec`が必要になります。
 これまでにすべての計画が完了していると想定すると、Serviceが機能しない理由を調査することができます。
 ## Serviceは存在するか？
 賢明な読者は、Serviceをまだ実際に作成していないことにお気付きかと思いますが、これは意図的です。これは時々忘れられるステップであり、最初に確認すべきことです。
 存在しないServiceにアクセスしようとするとどうなるでしょうか？
 このServiceを名前で利用する別のPodがあると仮定すると、次のような結果が得られます。
 ```shell
 wget -O- hostnames
 ```
 ```none
 Resolving hostnames (hostnames)... failed: Name or service not known.
 wget: unable to resolve host address 'hostnames'
 ```
-そのため、最初に確認するのは、その`Service`が実際に存在するかどうかです。
+最初に確認するのは、そのServiceが実際に存在するかどうかです。
 ```shell
 kubectl get svc hostnames
 ```
 ```none
 No resources found.
 Error from server (NotFound): services "hostnames" not found
 ```
-犯人がいましたので、`Service`を作成しましょう。
+Serviceを作成しましょう。
-前と同様に、これはウォークスルー用です。ご自身の`Service`の詳細を使用することもできます。
+前と同様に、これはウォークスルー用です。ご自身のServiceの詳細を使用することもできます。
 ```shell
 kubectl expose deployment hostnames --port=80 --target-port=9376
 ```
 ```none
 service/hostnames exposed
 ```
@ -144,11 +161,16 @@ service/hostnames exposed
 ```shell
 kubectl get svc hostnames
 ```
 ```none
 NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
 hostnames   ClusterIP   10.0.1.175   <none>        80/TCP    5s
 ```
-前と同様に、これは次のようなYAMLで`Service`を開始した場合と同じです。
+これで、Serviceが存在することがわかりました。
 {{< note >}}
 前と同様に、これは次のようなYAMLでServiceを開始した場合と同じです。
 ```yaml
 apiVersion: v1
@ -165,35 +187,45 @@ spec:
    targetPort: 9376
 ```
-これで、`Service`が存在することが確認できました。
+構成の全範囲をハイライトするため、ここで作成したServiceはPodとは異なるポート番号を使用します。
 多くの実際のServiceでは、これらのポートは同じになる場合があります。
 {{< /note >}}
-## サービスはDNSによって機能しているか？
+## サービスはDNS名によって機能しているか？
-同じ`Namespace`の`Pod`から次のコマンドを実行してください。
+クライアントがサービスを使用する最も一般的な方法の1つは、DNS名を使用することです。
 同じNamespaceのPodから次のコマンドを実行してください。
 ```shell
-u@pod$ nslookup hostnames
+nslookup hostnames
 ```
 ```none
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
 Name:      hostnames
 Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
 ```
-これが失敗した場合、おそらく`Pod`と`Service`が異なる`Namespace`にあるため、ネームスペースで修飾された名前を試してください。
+これが失敗した場合、おそらくPodとServiceが異なるNamespaceにあるため、ネームスペースで修飾された名前を試してください。(Podの中からもう一度)
 ```shell
-u@pod$ nslookup hostnames.default
+nslookup hostnames.default
 ```
 ```none
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
 Name:      hostnames.default
 Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
 ```
-これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じ`Namespace`でアプリと`Service`を実行する必要があります。
+これが機能する場合、クロスネームスペース名を使用するようにアプリケーションを調整するか、同じNamespaceでアプリとServiceを実行する必要があります。
 これでも失敗する場合は、完全修飾名を試してください。
 ```shell
-u@pod$ nslookup hostnames.default.svc.cluster.local
+nslookup hostnames.default.svc.cluster.local
 ```
 ```none
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
 Name:      hostnames.default.svc.cluster.local
@ -201,18 +233,20 @@ Address 1: 10.0.1.175 hostnames.default.svc.cluster.local
 ```
 ここでのサフィックス"default.svc.cluster.local"に注意してください。
-"default"は、操作している`Namespace`です。
+"default"は、操作しているNamespaceです。
-"svc"は、これが`Service`であることを示します。
+"svc"は、これがServiceであることを示します。
 "cluster.local"はクラスタードメインであり、あなたのクラスターでは異なる場合があります。
-クラスター内の`ノード`からも試すこともできます。
+クラスター内のノードからも試すこともできます。
 {{< note >}}
-10.0.0.10は私のDNS `Service`であり、あなたのクラスターでは異なるかもしれません。
+10.0.0.10はクラスターのDNSサービスのIPであり、あなたのクラスターでは異なるかもしれません。
 {{< /note >}}
 ```shell
-u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
+nslookup hostnames.default.svc.cluster.local 10.0.0.10
 ```
 ```none
 Server:         10.0.0.10
 Address:        10.0.0.10#53
@ -220,16 +254,22 @@ Name:   hostnames.default.svc.cluster.local
 Address: 10.0.1.175
 ```
-完全修飾名では検索できるのに、相対名ではできない場合、`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。
+完全修飾名では検索できるのに、相対名ではできない場合、Podの`/etc/resolv.conf`ファイルが正しいことを確認する必要があります。
 Pod内から実行します。
 ```shell
-u@pod$ cat /etc/resolv.conf
+cat /etc/resolv.conf
 ```
 次のように表示されます。
 ```
 nameserver 10.0.0.10
 search default.svc.cluster.local svc.cluster.local cluster.local example.com
 options ndots:5
 ```
-`nameserver`行はクラスターのDNS `Service`を示さなければなりません。
+nameserver行はクラスターのDNS Serviceを示さなければなりません。
 これは、`--cluster-dns`フラグで`kubelet`に渡されます。
 `search`行には、`Service`名を見つけるための適切なサフィックスを含める必要があります。
@ -242,14 +282,17 @@ options ndots:5
 `options`行では、DNSクライアントライブラリーが検索パスをまったく考慮しないように`ndots`を十分に高く設定する必要があります。
 Kubernetesはデフォルトでこれを5に設定します。これは、生成されるすべてのDNS名をカバーするのに十分な大きさです。
-### ServiveはDNSに存在するか？
+### DNS名で機能するServiceはありますか？ {#does-any-service-exist-in-dns}
-上記がまだ失敗する場合、DNSルックアップが`Service`に対して機能していません。
+上記がまだ失敗する場合、DNSルックアップがServiceに対して機能していません。
 一歩離れて、他の何が機能していないかを確認しましょう。
-Kubernetesマスターの`Service`は常に機能するはずです。
+KubernetesマスターのServiceは常に機能するはずです。
 Pod内から実行します。
 ```shell
-u@pod$ nslookup kubernetes.default
+nslookup kubernetes.default
 ```
 ```none
 Server:    10.0.0.10
 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
@ -257,31 +300,34 @@ Name:      kubernetes.default
 Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
 ```
-これが失敗した場合、このドキュメントのkube-proxyセクションに移動するか、あるいは、このドキュメントの先頭に戻って最初からやり直し、あなた自身の`Service`をデバッグする代わりにDNSをデバッグする必要があるかもしれません。
+これが失敗する場合は、このドキュメントの [kube-proxy](#is-the-kube-proxy-working)セクションを参照するか、このドキュメントの先頭に戻って最初からやり直してください。ただし、あなた自身のServiceをデバッグするのではなく 、DNSサービスをデバッグします。
 ## ServiceはIPでは機能するか？
-DNSが機能することを確認できると仮定すると、次にテストするのは`Service`が機能しているかどうかです。
+DNSサービスが正しく動作できると仮定すると、次にテストするのはIPによってServiceが動作しているかどうかです。
-上述の`kubectl get`で確認できる`Service`のIPに、クラスター内のノードからアクセスします。
+上述の`kubectl get`で確認できるIPに、クラスター内のPodからアクセスします。
 ```shell
-u@node$ curl 10.0.1.175:80
+for i in $(seq 1 3); do
-hostnames-0uton
+    wget -qO- 10.0.1.175:80
-
+done
 u@node$ curl 10.0.1.175:80
 hostnames-yp2kp
 u@node$ curl 10.0.1.175:80
 hostnames-bvc05
 ```
-`Service`が機能している場合は、正しい応答が得られるはずです。
+次のように表示されます。
 ```
 hostnames-0uton
 hostnames-bvc05
 hostnames-yp2kp
 ```
 Serviceが機能している場合は、正しい応答が得られるはずです。
 そうでない場合、おかしい可能性のあるものがいくつかあるため、続けましょう。
-## Serviceは正しいか？
+## Serviceは正しく定義されているか？
-馬鹿げているように聞こえるかもしれませんが、`Service`が正しく定義され`Pod`のポートとマッチすることを二度、三度と確認すべきです。
+馬鹿げているように聞こえるかもしれませんが、Serviceが正しく定義されPodのポートとマッチすることを二度、三度と確認すべきです。
-`Service`を読み返して確認しましょう。
+Serviceを読み返して確認しましょう。
 ```shell
 kubectl get service hostnames -o json
@ -297,7 +343,7 @@ kubectl get service hostnames -o json
        "resourceVersion": "347189",
        "creationTimestamp": "2015-07-07T15:24:29Z",
        "labels": {
-            "app": "hostnames"
+            "run": "hostnames"
        }
    },
    "spec": {
@ -311,7 +357,7 @@ kubectl get service hostnames -o json
            }
        ],
        "selector": {
-            "app": "hostnames"
+            "run": "hostnames"
        },
        "clusterIP": "10.0.1.175",
        "type": "ClusterIP",
@ -323,98 +369,102 @@ kubectl get service hostnames -o json
 }
 ```
-* アクセスしようとしているポートは`spec.ports[]`に定義されていますか？
+* アクセスしようとしているServiceポートは`spec.ports[]`のリストのなかに定義されていますか？
-* `targetPort`は`Pod`に対して適切ですか(多くの`Pod`は`Service`とは異なるポートを使用することを選択します)？
+* `targetPort`はPodに対して適切ですか(いくつかのPodはServiceとは異なるポートを使用します)？
 * `targetPort`を数値で定義しようとしている場合、それは数値(9376)、文字列"9376"のどちらですか？
-* `targetPort`を名前で定義しようとしている場合、`Pod`は同じ名前でポートを公開していますか？
+* `targetPort`を名前で定義しようとしている場合、Podは同じ名前でポートを公開していますか？
-* ポートの`protocol`は`Pod`のものと同じですか？
+* ポートの`protocol`はPodに適切ですか？
 ## ServiceにEndpointsがあるか？
-ここまで来たということは、`Service`は存在し、DNSによって名前解決できることが確認できているでしょう。
+ここまで来たということは、Serviceは正しく定義され、DNSによって名前解決できることが確認できているでしょう。
-ここでは、実行した`Pod`が`Service`によって実際に選択されていることを確認しましょう。
+ここでは、実行したPodがServiceによって実際に選択されていることを確認しましょう。
-以前に、`Pod`が実行されていることを確認しました。再確認しましょう。
+以前に、Podが実行されていることを確認しました。再確認しましょう。
 ```shell
-kubectl get pods -l app=hostnames
+kubectl get pods -l run=hostnames
 ```
 ```none
 NAME              READY     STATUS    RESTARTS   AGE
 hostnames-0uton   1/1       Running   0          1h
 hostnames-bvc05   1/1       Running   0          1h
 hostnames-yp2kp   1/1       Running   0          1h
 ```
 `-l run=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
-"AGE"列は、これらの`Pod`が約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
+"AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。
-`-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。
+"RESTARTS"列は、これらのポッドが頻繁にクラッシュしたり、再起動されていないことを示しています。 頻繁に再起動すると、断続的な接続性の問題が発生する可能性があります。
-Kubernetesシステム内には、すべての`Service`のセレクターを評価し、結果を`Endpoints`オブジェクトに保存するコントロールループがあります。
+再起動回数が多い場合は、[ポッドをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)を参照してください。
 Kubernetesシステム内には、すべてのServiceのセレクターを評価し、結果をEndpointsオブジェクトに保存するコントロールループがあります。
 ```shell
 kubectl get endpoints hostnames
 NAME        ENDPOINTS
 hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
 ```
-これにより、Endpointsコントローラーが`Service`の正しい`Pod`を見つけていることを確認できます。
+これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。
-`hostnames`行が空白の場合、`Service`の`spec.selector`フィールドが実際に`Pod`の`metadata.labels`値を選択していることを確認する必要があります。
+`ENDPOINTS`列が`<none>`の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。
-よくある間違いは、タイプミスまたは他のエラー、たとえば`Service`が`run=hostnames`を選択しているのに`Deployment`が`app=hostnames`を指定していることです。
+よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。
 ## Podは機能しているか？
-この時点で、`Service`が存在し、`Pod`を選択していることがわかります。
+この時点で、Serviceが存在し、Podを選択していることがわかります。
-`Pod`が実際に機能していることを確認しましょう。`Service`メカニズムをバイパスして、`Pod`に直接アクセスすることができます。
+このウォークスルーの最初に、Pod自体を確認しました。
 Podが実際に機能していることを確認しましょう。Serviceメカニズムをバイパスして、上記EndpointsにリストされているPodに直接アクセスすることができます。
 {{< note >}}
-これらのコマンドは、`Service`ポート(80)ではなく、`Pod`ポート(9376)を使用します。
+これらのコマンドは、Serviceポート(80)ではなく、Podポート(9376)を使用します。
 {{< /note >}}
 Pod内から実行します。
 ```shell
-u@pod$ wget -qO- 10.244.0.5:9376
+for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
    wget -qO- $ep
 done
 ```
 次のように表示されます。
 ```
 hostnames-0uton
 pod $ wget -qO- 10.244.0.6:9376
 hostnames-bvc05
 u@pod$ wget -qO- 10.244.0.7:9376
 hostnames-yp2kp
-```
+ ```
-`Endpoints`リスト内の各`Pod`は、それぞれの自身のホスト名を返すはずです。
+Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。
-そうならない(または、あなた自身の`Pod`の正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
+そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。
 `kubectl logs`が役立つかもしれません。あるいは、`kubectl exec`で直接`Pod`にアクセスし、そこでサービスをチェックしましょう。
-もう1つ確認すべきことは、`Pod`がクラッシュしたり、再起動されていないことです。
+## kube-proxyは機能しているか？ {#is-the-kube-proxy-working}
 頻繁に再起動されていると、断続的な接続の問題が発生する可能性があります。
-```shell
+ここに到達したのなら、Serviceは実行され、Endpointsがあり、Podが実際にサービスを提供しています。
-kubectl get pods -l app=hostnames
+この時点で、Serviceのプロキシーメカニズム全体が疑わしいです。
 NAME                        READY     STATUS    RESTARTS   AGE
 hostnames-632524106-bbpiw   1/1       Running   0          2m
 hostnames-632524106-ly40y   1/1       Running   0          2m
 hostnames-632524106-tlaok   1/1       Running   0          2m
 ```
 再起動回数が多い場合は、[Podをデバッグする](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/#podのデバッグ)方法の詳細をご覧ください。
 ## kube-proxyは機能しているか？
 ここに到達したのなら、`Service`は実行され、`Endpoints`があり、`Pod`が実際にサービスを提供しています。
 この時点で、`Service`のプロキシーメカニズム全体が疑わしいです。
 ひとつひとつ確認しましょう。
 Serviceのデフォルト実装、およびほとんどのクラスターで使用されるものは、kube-proxyです。
 kube-proxyはそれぞれのノードで実行され、Serviceの抽象化を提供するための小さなメカニズムセットの1つを構成するプログラムです。
 クラスターがkube-proxyを使用しない場合、以下のセクションは適用されず、使用しているServiceの実装を調査する必要があります。
 ### kube-proxyは実行されているか？
-`kube-proxy`が`ノード`上で実行されていることを確認しましょう。
+`kube-proxy`がノード上で実行されていることを確認しましょう。
-以下のような結果が得られるはずです。
+ノードで実行されていれば、以下のような結果が得られるはずです。
 ```shell
-u@node$ ps auxw | grep kube-proxy
+ps auxw | grep kube-proxy
 root  4194  0.4  0.1 101864 17696 ?    Sl Jul04  25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
 ```
 ```none
 root  4194  0.4  0.1 101864 17696 ?    Sl Jul04  25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2
 ```
 次に、マスターとの接続など、明らかな失敗をしていないことを確認します。
 これを行うには、ログを確認する必要があります。
-ログへのアクセス方法は、`ノード`のOSに依存します。
+ログへのアクセス方法は、ノードのOSに依存します。
 一部のOSでは/var/log/kube-proxy.logのようなファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
 次のように表示されます。
@ -431,39 +481,23 @@ I1027 22:14:54.040154    5063 proxier.go:294] Adding new service "kube-system/ku
 I1027 22:14:54.040223    5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP
 ```
-マスターに接続できないことに関するエラーメッセージが表示された場合、`ノード`の設定とインストール手順をダブルチェックする必要があります。
+マスターに接続できないことに関するエラーメッセージが表示された場合、ノードの設定とインストール手順をダブルチェックする必要があります。
 `kube-proxy`が正しく実行できない理由の可能性の1つは、必須の`conntrack`バイナリが見つからないことです。
 これは、例えばKubernetesをスクラッチからインストールするなど、クラスターのインストール方法に依存して、一部のLinuxシステムで発生する場合があります。
 これが該当する場合は、`conntrack`パッケージを手動でインストール(例: Ubuntuでは`sudo apt install conntrack`)する必要があり、その後に再試行する必要があります。
-### kube-proxyはiptablesルールを書いているか？
+kube-proxyは、いくつかのモードのいずれかで実行できます。 上記のログの`Using iptables Proxier`という行は、kube-proxyが「iptables」モードで実行されていることを示しています。
 最も一般的な他のモードは「ipvs」です。 古い「ユーザースペース」モードは、主にこれらに置き換えられました。
-`kube-proxy`の主な責務の1つは、`Service`を実装する`iptables`ルールを記述することです。
+#### Iptables mode
 それらのルールが書かれていることを確認しましょう。
-kube-proxyは、"userspace"モード、"iptables"モード、または"ipvs"モードで実行できます。
+「iptables」モードでは、ノードに次のようなものが表示されます。
 あなたが"iptables"モードまたは"ipvs"モードを使用していることを願います。
 続くケースのいずれかが表示されるはずです。
 #### Userspace
 ```shell
-u@node$ iptables-save | grep hostnames
+iptables-save | grep hostnames
 -A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577
 -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
 ```
-
+```none
 `Service`の各ポート毎(この例では1つ)に2つのルールがあるはずです。
 "KUBE-PORTALS-CONTAINER"と"KUBE-PORTALS-HOST"です。
 これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、もう一度ログを確認してください。
 "userspace"モードを使用する必要がある人ほとんどないため、ここではこれ以上の時間を費やしません。
 #### Iptables
 ```shell
 u@node$ iptables-save | grep hostnames
 -A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
 -A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376
 -A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
@ -476,13 +510,18 @@ u@node$ iptables-save | grep hostnames
 -A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR
 ```
-`KUBE-SERVICES`に1つのルールがあり、`KUBE-SVC-(hash)`のエンドポイント毎に1つまたは2つのルールがあり(`SessionAffinity`に依存)、エンドポイント毎に1つの`KUBE-SEP-(hash)`チェーンがあり、 そしてそれぞれの`KUBE-SEP-(hash)`チェーンにはいくつかのルールがあるはずです。
+各サービスのポートごとに、 `KUBE-SERVICES`に1つのルールと1つの` KUBE-SVC- <hash> `チェーンが必要です。
-正確なルールは、あなたの正確な構成(NodePortとLoadBalancerを含む)によって異なります。
+Podエンドポイントごとに、その `KUBE-SVC- <hash>`に少数のルールがあり、少数のルールが含まれる1つの `KUBE-SEP- <hash>`チェーンがあるはずです。
 正確なルールは、正確な構成（NodePortとLoadBalancerを含む）に基づいて異なります。
-#### IPVS
+#### IPVS mode
 「ipvs」モードでは、ノードに次のようなものが表示されます。
 ```shell
-u@node$ ipvsadm -ln
+ipvsadm -ln
 ```
 ```none
 Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
 ...
@ -493,39 +532,66 @@ TCP  10.0.1.175:80 rr
 ...
 ```
 各Serviceの各ポートに加えて、NodePort、External IP、およびLoad Balancer IPに対して、kube-proxyは仮想サーバーを作成します。
 Pod endpointごとに、対応する実サーバーが作成されます。
 この例では, サービスhostnames(`10.0.1.175:80`) は3つのendpoints(`10.244.0.5:9376`,`10.244.0.6:9376`, `10.244.0.7:9376`)を持っています。
 IPVSプロキシーは、各Serviceアドレス(Cluster IP、External IP、NodePort IP、Load Balancer IPなど)毎の仮想サーバーと、Serviceのエンドポイントが存在する場合に対応する実サーバーを作成します。
 この例では、hostnames Service(`10.0.1.175:80`)は3つのエンドポイント(`10.244.0.5:9376`、`10.244.0.6:9376`、`10.244.0.7:9376`)を持ち、上と似た結果が得られるはずです。
-### kube-proxyはプロキシしているか？
+#### Userspace mode
-上記のルールが表示されていると仮定すると、もう一度IPを使用して`Service`へのアクセスを試してください。
+まれに、「userspace」モードを使用している場合があります。
 ノードから実行します。
 ```shell
-u@node$ curl 10.0.1.175:80
+iptables-save | grep hostnames
 ```
 ```none
 -A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577
 -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577
 ```
 サービスの各ポートには2つのルールが必要です（この例では1つだけ）-「KUBE-PORTALS-CONTAINER」と「KUBE-PORTALS-HOST」です。
 「userspace」モードを使用する必要はほとんどないので、ここでこれ以上時間を費やすことはありません。
 ### kube-proxyはプロキシしているか？
 上記のいずれかが発生したと想定して、いずれかのノードからIPでサービスにアクセスをしています。
 ```shell
 curl 10.0.1.175:80
 ```
 ```none
 hostnames-0uton
 ```
 もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。
 もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。
-上記の`iptables-save`の出力を振り返り、`kube-proxy`が`Service`に使用しているポート番号を抽出します。
+上記の`iptables-save`の出力を振り返り、`kube-proxy`がServiceに使用しているポート番号を抽出します。
 上記の例では"48577"です。このポートに接続してください。
 ```shell
-u@node$ curl localhost:48577
+curl localhost:48577
 ```
 ```none
 hostnames-yp2kp
 ```
 もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。
-```shell
+```none
 Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376]
 ```
 これらが表示されない場合は、`-v`フラグを4に設定して`kube-proxy`を再起動してから、再度ログを確認してください。
-### PodはService IPを介して自分自身にアクセスできない
+### エッジケース: PodがService IP経由で自身に到達できない。 {#a-pod-fails-to-reach-itself-via-the-service-ip}
 これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。
 これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。
 `Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。
 これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。
@ -537,20 +603,21 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9
 次のような表示がされるはずです。この例では、`hairpin-mode`は`promiscuous-bridge`に設定されています。
 ```shell
-u@node$ ps auxw|grep kubelet
+ps auxw | grep kubelet
 ```
 ```none
 root      3392  1.1  0.8 186804 65208 ?        Sl   00:51  11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
 ```
 * 実際に使われている`hairpin-mode`を確認します。
 これを行うには、kubeletログを確認する必要があります。
-ログへのアクセス方法は、NodeのOSによって異なります。
+ログへのアクセス方法は、ノードのOSによって異なります。
 一部のOSでは/var/log/kubelet.logなどのファイルですが、他のOSでは`journalctl`を使用してログにアクセスします。
 互換性のために、実際に使われている`hairpin-mode`が`--hairpin-mode`フラグと一致しない場合があることに注意してください。
 kubelet.logにキーワード`hairpin`を含むログ行があるかどうかを確認してください。
 実際に使われている`hairpin-mode`を示す以下のようなログ行があるはずです。
-```shell
+```none
 I0629 00:51:43.648698    3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
 ```
@ -559,6 +626,8 @@ I0629 00:51:43.648698    3252 kubelet.go:380] Hairpin mode set to "promiscuous-b
 ```shell
 for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
 ```
 ```none
 1
 1
 1
@ -569,9 +638,10 @@ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; don
 `cbr0`ブリッジが使用され適切に構成されている場合、以下が表示されます。
 ```shell
-u@node$ ifconfig cbr0 |grep PROMISC
+ifconfig cbr0 |grep PROMISC
 ```
 ```none
 UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
 ```
 * 上記のいずれも解決しない場合、助けを求めてください。
@ -579,9 +649,9 @@ UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
 ## 助けを求める
 ここまでたどり着いたということは、とてもおかしなことが起こっています。
-`Service`は実行中で、`Endpoints`があり、`Pod`は実際にサービスを提供しています。
+Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。
-DNSは動作していて、`iptables`ルールがインストールされていて、`kube-proxy`も誤動作していないようです。
+DNSは動作していて、`kube-proxy`も誤動作していないようです。
-それでも、あなたの`Service`は機能していません。
+それでも、あなたのServiceは機能していません。
 おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！
 [Slack](/docs/troubleshooting/#slack)または
--- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
@ -33,7 +33,7 @@ Podが長期間`Unknown`または`Terminating`の状態になっていること
 {{% capture whatsnext %}}
-[Init Containerのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
+[Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)の詳細
 {{% /capture %}}
--- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
@ -85,7 +85,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">
-                <p>最初のDeploymentには、DockerコンテナにパッケージされたNode.jsアプリケーションを使用します。Node.jsアプリケーションを作成してDockerコンテナをデプロイするには、<a href="/ja/docs/tutorials/hello-minikube/">Hello Minikubeチュートリアル</a>の指示に従ってください。</p>
+                <p>最初のDeploymentには、DockerコンテナにパッケージされたNode.jsアプリケーションを使用します。(まだNode.jsアプリケーションを作成してデプロイしていない場合、<a href="/ja/docs/tutorials/hello-minikube/">Hello Minikubeチュートリアル</a>の通りにやってみましょう。)</p>
                <p>Deploymentが何であるかがわかったので、オンラインチュートリアルに行き、最初のアプリケーションをデプロイしましょう！</p>
--- a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md
@ -69,7 +69,17 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
        NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
        my-service   LoadBalancer   10.3.245.137   104.198.205.71   8080/TCP   54s
-    注意: 外部IPアドレスが\<pending\>と表示されている場合は、しばらく待ってから同じコマンドを実行してください。
+    {{< note >}}
    `type=LoadBalancer`のServiceは外部のクラウドプロバイダーによってサポートされており、ここでは扱いません。詳細は[こちらのページ](/ja/docs/concepts/services-networking/service/#loadbalancer)を参照してください。
    {{< /note >}}
    {{< note >}}
    外部IPアドレスが\<pending\>と表示されている場合は、しばらく待ってから同じコマンドを実行してください。
    {{< /note >}}
 1. Serviceに関する詳細な情報を表示します:
@ -131,11 +141,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
 Serviceを削除する場合、次のコマンドを実行します:
-        kubectl delete services my-service
+    kubectl delete services my-service
 Deployment、ReplicaSet、およびHello Worldアプリケーションが動作しているPodを削除する場合、次のコマンドを実行します:
-        kubectl delete deployment hello-world
+    kubectl delete deployment hello-world
 {{% /capture %}}
--- a/content/ja/training/_index.html
+++ b/content/ja/training/_index.html
@ -1,7 +1,7 @@
 ---
-title: Training
+title: トレーニング
-bigheader: Kubernetes Training and Certification
+bigheader: Kubernetesのトレーニングと資格
-abstract: Training programs, certifications, and partners.
+abstract: トレーニングプログラム、資格、及びパートナーについて。
 layout: basic
 cid: training
 class: training
@ -17,8 +17,8 @@ class: training
        <img src="/images/training/kubernetes-ckad-white.svg"/>
      </div>
      <div class="cta-text">
-        <h2>Build your cloud native career</h2>
+        <h2>あなたのクラウドネイティブなキャリアを創る</h2>
-        <p>Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.</p>
+        <p>Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。</p>
      </div>
    </div>
  </div>
@ -27,37 +27,37 @@ class: training
 <section>
  <div class="main-section padded">
    <center>
-      <h2>Take a free course on edX</h2>
+      <h2>edXで無料コースを受講する</h2>
    </center>
  <div class="col-container">
    <div class="col-nav">
      <center>
        <h5>
-          <b>Introduction to Kubernetes <br> &nbsp;</b>
+          <b>Kubernetes入門<br> &nbsp;</b>
        </h5>
-        <p>Want to learn Kubernetes? Get an in-depth primer on this powerful system for managing containerized applications.</p>
+        <p>Kubernetesを学びたいですか？コンテナ化されたアプリケーションを管理するための強力なシステムに入門しましょう。</p>
        <br>
-        <a href="https://www.edx.org/course/introduction-to-kubernetes" target="_blank" class="button">Go to Course</a>
+        <a href="https://www.edx.org/course/introduction-to-kubernetes" target="_blank" class="button">コースに行く</a>
      </center>
    </div>
    <div class="col-nav">
      <center>
        <h5>
-          <b>Introduction to Cloud Infrastructure Technologies</b>
+          <b>クラウドインフラ技術入門</b>
        </h5>
-        <p>Learn the fundamentals of building and managing cloud technologies directly from The Linux Foundation, the leader in open source.</p>
+        <p>オープンソースのリーダーであるThe Linux Foundationから直接、クラウドテクノロジーの構築と管理の基本を学びます。</p>
        <br>
-        <a href="https://www.edx.org/course/introduction-to-cloud-infrastructure-technologies" target="_blank" class="button">Go to Course</a>
+        <a href="https://www.edx.org/course/introduction-to-cloud-infrastructure-technologies" target="_blank" class="button">コースに行く</a>
      </center>
    </div>
    <div class="col-nav">
      <center>
        <h5>
-          <b>Introduction to Linux</b>
+          <b>Linux入門</b>
        </h5>
-        <p>Never learned Linux? Want a refresh? Develop a good working knowledge of Linux using both the graphical interface and command line across the major Linux distribution families.</p>
+        <p>Linuxを学ぶのは初めてですか？知識を更新したいですか？主要なLinuxディストリビューションでGUIとCLIの両方を使用し、Linuxの実用的な知識を深めます。</p>
        <br>
-        <a href="https://www.edx.org/course/introduction-to-linux" target="_blank" class="button">Go to Course</a>
+        <a href="https://www.edx.org/course/introduction-to-linux" target="_blank" class="button">コースに行く</a>
      </center>
    </div>
  </div>
@ -66,10 +66,10 @@ class: training
 <div class="padded lighter-gray-bg">
  <div class="main-section two-thirds-centered">
    <center>
-      <h2>Learn with the Linux Foundation</h2>
+      <h2>Linux Foundationと共に学ぶ</h2>
-      <p>The Linux Foundation offers instructor-led and self-paced courses for all aspects of the Kubernetes application development and operations lifecycle.</p>
+      <p>Linux Foundationは、Kubernetesアプリケーションの開発と運用のライフサイクルのあらゆる側面について、インストラクター主導の自己学習コースを提供しています。</p>
      <br/><br/>
-      <a href="https://training.linuxfoundation.org/training/course-catalog/?_sft_technology=kubernetes" target="_blank" class="button">See Courses</a>
+      <a href="https://training.linuxfoundation.org/training/course-catalog/?_sft_technology=kubernetes" target="_blank" class="button">コースを見る</a>
    </center>
  </div>
 </div>
@ -77,27 +77,27 @@ class: training
 <section>
  <div class="main-section padded">
    <center>
-        <h2>Get Kubernetes Certified</h2>
+        <h2>Kubernetes認定資格を受験する</h2>
    </center>
    <div class="col-container">
      <div class="col-nav">
        <center>
          <h5>
-            <b>Certified Kubernetes Application Developer (CKAD)</b>
+            <b>認定Kubernetesアプリケーション開発者(Certified Kubernetes Application Developer, CKAD)</b>
          </h5>
-          <p>The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.</p>
+          <p>認定Kubernetesアプリケーション開発者(CKAD)試験は、ユーザーがKubernetes向けにクラウドネイティブアプリケーションを設計、構築、構成、公開できることを証明します。</p>
          <br>
-          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Go to Certification</a>
+          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">試験を受ける</a>
        </center>
      </div>
      <div class="col-nav">
        <center>
          <h5>
-            <b>Certified Kubernetes Administrator (CKA)</b>
+            <b>認定Kubernetes管理者(Certified Kubernetes Administrator, CKA)</b>
          </h5>
-          <p>The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.</p>
+          <p>認定Kubernetes管理者(CKA)プログラムは、保有者がKubernetes管理者の責務を実行するためのスキル、知識、および能力を持っていることを保証します。</p>
          <br>
-          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Go to Certification</a>
+          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">試験を受ける</a>
        </center>
      </div>
    </div>
@ -107,12 +107,12 @@ class: training
 <div class="padded lighter-gray-bg">
  <div class="main-section two-thirds-centered">
    <center>
-      <h2>Kubernetes Training Partners</h2>
+      <h2>Kubernetesトレーニングパートナー</h2>
-      <p>Our network of Kubernetes Training Partners provide training services for Kubernetes and cloud native projects.</p>
+      <p>Kubernetesトレーニングパートナーネットワークは、Kubernetesおよびクラウドネイティブプロジェクトのトレーニングサービスを提供します。</p>
    </center>
  </div>
  <div class="main-section landscape-section">
    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
  </div>
-</div>
+</div>