Translate concepts/overview/components and related glossaries in Japa…

…nase (kubernetes#16034)

* Translate concepts/overview/components and related glossaries in Japanese

* Revise sentences based on suggestion by reviewers

content/ja/docs/concepts/overview/components.md

@@ -1,6 +1,5 @@
 ---
-reviewers:
-title: Kubernetesコンポーネント
+title: Kubernetesのコンポーネント
 content_template: templates/concept
 weight: 20
 card: 
@@ -9,18 +8,18 @@ card:
 ---
 
 {{% capture overview %}}
-
-このページでは、Kubernetesクラスターの機能を提供するために必要になる様々なコンポーネントを説明します。（実行ファイル形式で提供される）
-
+このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。
 {{% /capture %}}
 
 {{% capture body %}}
 
-## マスターコンポーネント
+## Masterコンポーネント
 
-マスターコンポーネントは、クラスターのコントロールプレーンです。マスターコンポーネントはクラスターに関する全体的な決定を行い（例えばスケジューリングなど）、クラスターのイベントを検知し、それらに応答します（例えば、レプリケーションコントローラーの'replicas'フィールドが充足されていない場合、新しいPodを立ち上げます）。
+Masterコンポーネントは、クラスターのコントロールプレーンを提供します。
+Masterコンポーネントは、クラスターに関する(スケジューリングなどの)グローバルな決定を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replica`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。
 
-マスターコンポーネントは、クラスター内のどのマシン上でも動かすことが出来ます。しかし、話を簡単にするために、環境構築を行うスクリプトは通常、全てのマスターコンポーネントを同じマシン上で稼働させ、ユーザーのコンテナはそのマシンでは稼働させません。複数マスターマシン構成の構築例は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。
+Masterコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのMasterコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。
+マルチMaster VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。
 
 ### kube-apiserver
 
@@ -38,70 +37,76 @@ card:
 
 {{< glossary_definition term_id="kube-controller-manager" length="all" >}}
 
-コントローラーには下記のものがあります:
+コントローラーには以下が含まれます。
 
-  * ノードコントローラー: ノードがダウンした場合に、通知と応答を行います。
-  * レプリケーションコントローラー: それぞれのレプリケーションコントローラーオブジェクト内に、正しい数のポッドが存在しているかを管理します。
-  * エンドポイントコントローラー: エンドポイントを設定します。（これは、サービスとPodを結合するということです）
-  * サービスアカウント & トークンコントローラー: 新しい名前空間にデフォルトアカウントとAPIアクセストークンを作成します。
+  * ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。
+  * レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。
+  * エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。
+  * サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。
 
-### クラウドコントローラーマネージャー（cloud-controller-manager）
+### cloud-controller-manager
 
-[クラウドコントローラーマネージャー](/docs/tasks/administer-cluster/running-cloud-controller/)は、基盤となるクラウドサービスと連携するコントローラーを動かします。クラウドコントローラーマネージャーはKubernetes 1.6でリリースされたアルファの機能です。
+[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。
+cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。
 
-クラウドコントローラーマネージャーは、クラウドサービス固有の制御ループのみを動かします。これらの制御ループは kube-controller-manager から無効にしなければなりません。無効にするには、kube-controller-managerの起動時に、`--cloud-provider`フラグに`external`を指定します。
+cloud-controller-managerは、クラウドプロバイダー固有のコントローラーループのみを実行します。これらのコントローラーループはkube-controller-managerで無効にする必要があります。 kube-controller-managerの起動時に `--cloud-provider` フラグを `external` に設定することで、コントローラーループを無効にできます。
 
-クラウドコントローラーマネージャーは、クラウドベンダー固有のコードと、Kubernetes本体のコードを独立して開発することを可能にします。以前のリリースでは、Kubernetes本体のコードがクラウドサービス固有のコードに機能的に依存していました。将来のリリースでは、クラウドベンダー固有のコードはクラウドベンダー自身が保持し、Kubernetesが稼働している時にクラウドコントローラーマネージャーに紐付けられるようになっていきます。
+cloud-controller-managerを使用すると、クラウドベンダーのコードとKubernetesコードを互いに独立して進化させることができます。以前のリリースでは、コアKubernetesコードは、機能的にクラウドプロバイダー固有のコードに依存していました。将来のリリースでは、クラウドベンダーに固有のコードはクラウドベンダー自身で管理し、Kubernetesの実行中にcloud-controller-managerにリンクする必要があります。
 
-以下のコントローラーがクラウドサービスとの依存関係を持っています:
+次のコントローラーには、クラウドプロバイダーへの依存関係があります。
 
-  * ノードコントローラー: クラウドから応答が無くなった後、ノードが削除されていないかを確認します。
-  * ルートコントローラー: クラウド基盤にルーティング情報を設定します。
-  * サービスコントローラー: クラウドサービス上のロードバランサーを作成、更新、削除します。
-  * ボリュームコントローラー: ボリュームを作成、アタッチ、マウント、またクラウドサービスと連携し、ボリュームを編成します。
+  * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。
+  * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。
+  * Serviceコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
+  * Volumeコントローラー：Volumeを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてVolumeを調整したりします。
 
 ## ノードコンポーネント
 
-ノードコンポーネントは全てのノード上で稼働し、稼働中Podの管理、Kubernetes実行環境を提供します。
+ノードコンポーネントはすべてのノードで実行され、実行中PodのメンテナンスおよびKubernetesランタイム環境の提供を行います。
 
 ### kubelet
 
 {{< glossary_definition term_id="kubelet" length="all" >}}
 
 ### kube-proxy
 
-[kube-proxy](/docs/admin/kube-proxy/)は、ホスト上のネットワークルールを管理し、コネクションの転送を行うことで、Kubernetesサービスの抽象化を可能にします。
+{{< glossary_definition term_id="kube-proxy" length="all" >}}
 
 ### コンテナランタイム
 
-コンテナランタイムは、コンテナを稼働させる責務を持つソフトウェアです。
-Kubernetesはいくつかのランタイムをサポートしています: [Docker](http://www.docker.com)、[containerd](https://containerd.io)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet)、また[Kubernetes CRI (コンテナランタイムインターフェース)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)の実装があります。
+{{< glossary_definition term_id="container-runtime" length="all" >}}
 
 ## アドオン
 
-アドオンは、クラスターの機能群を実装したPodとサービスです。そのPodは、Deployment、レプリケーションコントローラーなどによって管理されるでしょう。名前空間に属するアドオンオブジェクトは、`kube-system`名前空間に作られます。
+アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。
+アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。
 
-一部のアドオンを下記に示します。その他の利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/)を確認してください。
+いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。
 
 ### DNS
 
-厳密には他のアドオンは必須ではありませんが、多数の実例が依存しているため、全てのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。
+クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。
+
+クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。
 
-クラスターDNSはDNSサーバーで、あなたの環境で動いている他のDNSサーバーに加え、Kubernetesサービスで利用するDNSレコードも扱います。
+Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。
 
-Kubernetesから起動されたコンテナは、DNSの検索対象として、自動的にこのDNSサーバーを含めます。
 
 ### Web UI (ダッシュボード)
 
-[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、汎用のKubernetesのクラスターを管理するためのWebベースのUIです。ユーザーはこれを用いて、クラスター上で稼働しているアプリケーション、またクラスターそのものの管理、トラブルシュートが可能です。
+[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。
 
 ### コンテナリソース監視
 
-[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列のメトリクスをセントラルなデータベースに記録し、そのデータを閲覧するUIを提供します。
+[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。
 
-### クラスターレベルロギング
+### クラスターレベルログ
 
-[クラスターレベルロギング](/docs/concepts/cluster-administration/logging/)機構は、コンテナのログを、検索、閲覧のインターフェースを持ったセントラルなログ保管場所に保存します。
+[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。
 
 {{% /capture %}}
-
+{{% capture whatsnext %}}
+* [ノード](/docs/concepts/architecture/nodes/) について学ぶ
+* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) について学ぶ
+* etcdの公式 [ドキュメント](https://etcd.io/docs/) を読む
+{{% /capture %}}

content/ja/docs/reference/glossary/container-runtime.md

@@ -0,0 +1,22 @@
+---
+title: コンテナランタイム
+id: container-runtime
+date: 2019-06-05
+full_link: /docs/reference/generated/container-runtime
+short_description: >
+ コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
+
+aka:
+tags:
+- fundamental
+- workload
+---
+ コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
+
+<!--more-->
+
+Kubernetesは次の複数のコンテナランタイムをサポートします。
+[Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/),
+[rktlet](https://github.com/kubernetes-incubator/rktlet) および全ての
+[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)
+実装。

content/ja/docs/reference/glossary/daemonset.md

@@ -0,0 +1,20 @@
+---
+title: DaemonSet
+id: daemonset
+date: 2018-04-12
+full_link: /docs/concepts/workloads/controllers/daemonset
+short_description: >
+  Podのコピーがクラスター内の一連のNodeに渡って実行されることを保証します。
+
+aka: 
+tags:
+- fundamental
+- core-object
+- workload
+---
+  {{< glossary_tooltip text="Pod" term_id="pod" >}}のコピーが{{< glossary_tooltip text="クラスター" term_id="cluster" >}}内の一連のNodeに渡って実行されることを保証します。
+
+<!--more--> 
+
+通常{{< glossary_tooltip term_id="node" >}}で実行する必要があるログコレクターや監視エージェントなどのシステムデーモンをデプロイするために使用します。
+

content/ja/docs/reference/glossary/deployment.md

@@ -0,0 +1,19 @@
+---
+title: Deployment
+id: deployment
+date: 2018-04-12
+full_link: /docs/concepts/workloads/controllers/deployment/
+short_description: >
+  複製されたアプリケーションを管理するAPIオブジェクト。
+
+aka: 
+tags:
+- fundamental
+- core-object
+- workload
+---
+ 複製されたアプリケーションを管理するAPIオブジェクト。
+
+<!--more--> 
+
+各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。

content/ja/docs/reference/glossary/etcd.md

@@ -15,5 +15,6 @@ tags:
 
 <!--more--> 
 
-あなたのKubernetesクラスター情報を守るため、etcdのデータのバックアッププランを持っておいて下さい。etcdに関するより詳細な情報は、[etcdドキュメント](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)を確認してください。
+etcdをKubernetesのデータストアとして使用する場合、必ずデータの[バックアップ](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)計画を作成して下さい。
 
+公式[ドキュメント](https://etcd.io/docs/)でetcdに関する詳細な情報を見つけることができます。

content/ja/docs/reference/glossary/kube-apiserver.md

@@ -4,14 +4,14 @@ id: kube-apiserver
 date: 2018-04-12
 full_link: /docs/reference/generated/kube-apiserver/
 short_description: >
-  Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。
+  マスター上でKubernetes APIを公開するコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドです。
 
 aka: 
 tags:
 - architecture
 - fundamental
 ---
- Kubernetes APIを外部に提供する、マスター上のコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドになります。
+ マスター上でKubernetes APIを公開するコンポーネントです。これがKubernetesコントロールプレーンのフロントエンドです。
 
 <!--more--> 
 

content/ja/docs/reference/glossary/kube-controller-manager.md

@@ -15,5 +15,5 @@ tags:
 
 <!--more--> 
 
-論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は、それぞれ別のプロセスですが、複雑になるのを避けるため、一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
+論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は、それぞれ別のプロセスですが、複雑さを軽減するために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
 

content/ja/docs/reference/glossary/kube-proxy.md

@@ -0,0 +1,20 @@
+---
+title: kube-proxy
+id: kube-proxy
+date: 2018-04-12
+full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+short_description: >
+  `kube-proxy`はクラスター内の各Nodeで動作しているネットワークプロキシです。
+
+aka:
+tags:
+- fundamental
+- networking
+---
+ [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) はクラスター内の各Nodeで動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。
+
+<!--more-->
+
+kube-proxyは、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。
+
+kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。

content/ja/docs/reference/glossary/kubelet.md

@@ -15,5 +15,5 @@ tags:
 
 <!--more--> 
 
-Kubeletは、様々な機構から提供されるPodSpecs情報を受け取り、それらのPodSpecs情報に記述されているコンテナが正常に稼働していることを保証します。Kubeletは、Kubernetes外で作成されたコンテナは管理しません。
+Kubeletは、様々なメカニズムで提供されるPodSpecs情報を受け取り、それらのPodSpecs情報に記述されているコンテナが正常に稼働していることを保証します。Kubeletは、Kubernetes外で作成されたコンテナは管理しません。