Merge pull request #27963 from kubernetes/dev-1.19-ja.1

First Japanese l10n work for release-1.19

Author: k8s-ci-robot

content/ja/docs/concepts/architecture/cloud-controller.md

@@ -20,7 +20,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ
 
 ## 設計
 
-![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg)
 
 クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。
 

content/ja/docs/concepts/architecture/controller.md

@@ -50,7 +50,11 @@ Jobとは対照的に、クラスターの外部に変更を加える必要が
 
 外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。
 
-(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。)
+(クラスター内のノードを水平にスケールさせる[コントローラー](https://github.com/kubernetes/autoscaler/)が実際に存在します。)
+
+ここで重要な点は、コントローラーが目的の状態を実現するために変更を加えてから、現在の状態をクラスターのAPIサーバーに報告することです。他の制御ループは、その報告されたデータを監視し、独自のアクションを実行できます。
+
+サーモスタットの例では、部屋が非常に寒い場合、別のコントローラーが霜防止ヒーターをオンにすることもあります。Kubernetesクラスターを使用すると、コントロールプレーンは、[Kubernetesを拡張して](/ja/docs/concepts/extend-kubernetes/)実装することにより、IPアドレス管理ツールやストレージサービス、クラウドプロバイダーAPI、およびその他のサービスと間接的に連携します。
 
 ## 目的の状態 vs 現在の状態 {#desired-vs-current}
 
@@ -86,4 +90,3 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作
 * 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ
 * [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ
 * 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。
-

content/ja/docs/concepts/architecture/nodes.md

@@ -275,4 +275,3 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント
 * [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。
 * アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。
 * [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。
-* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。

content/ja/docs/concepts/cluster-administration/cloud-providers.md

@@ -29,8 +29,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
 
 ## クラスターの管理
 
-* [クラスターの管理](/docs/tasks/administer-cluster/cluster-management/)では、クラスターのライフサイクルに関するいくつかのトピックを紹介しています。例えば、新規クラスターの作成、クラスターのマスターやワーカーノードのアップグレード、ノードのメンテナンスの実施(例: カーネルのアップグレード)、稼働中のクラスターのKubernetes APIバージョンのアップグレードについてです。
-
 * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。
 
 * 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
@@ -41,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
 
 * [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
 
-* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。
+* [Kubernetes APIへのアクセス制御](/docs/concepts/security/controlling-access)では、Kubernetesで自身のAPIに対するアクセスコントロールがどのように実装されているかを説明します。
 
 * [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。
 

content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -39,7 +39,7 @@ Kubernetesは、ネットワークの実装に次の基本的な要件を課し
 
 このモデルは全体としてそれほど複雑ではないことに加え、KubernetesがVMからコンテナへのアプリへの移植を簡単にするという要望と基本的に互換性があります。ジョブがVMで実行されていた頃も、VMにはIPがあってプロジェクト内の他のVMと通信できました。これは同じ基本モデルです。
 
-KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
+KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスとMACアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
 
 この実装方法は実際に使われているコンテナランタイムの詳細部分です。
 
@@ -51,6 +51,8 @@ KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内の
 
 この一覧はアルファベット順にソートされており、順序は優先ステータスを意味するものではありません。
 
+{{% thirdparty-content %}}
+
 ### ACI
 
 [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers.
@@ -99,6 +101,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c
 
 BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
 
+### Calico
+
+[Calico](https://docs.projectcalico.org/)は、コンテナ、仮想マシン、ホストベースのワークロードのためのオープンソースのネットワーク及びネットワークセキュリティのソリューションです。Calicoは、純粋なLinuxのeBPFデータプレーンや、Linuxの標準的なネットワークデータプレーン、WindowsのHNSデータプレーンを含む、複数のデータプレーンをサポートしています。Calicoは完全なネットワークスタックを提供していますが、[クラウドプロバイダーのCNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)と組み合わせてネットワークポリシーを提供することもできます。
+
 ### Cilium
 
 [Cilium](https://github.com/cilium/cilium) is open source software for
@@ -129,6 +135,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100
 entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
 network complexity required to deploy Kubernetes at scale within AWS.
 
+### Coil
+
+[Coil](https://github.com/cybozu-go/coil)は、容易に連携できるよう設計されていて、フレキシブルなEgressネットワークを提供することができるCNIプラグインです。
+Coilはベアメタルと比較して低いオーバーヘッドで操作することができ、また外部のネットワークへの任意のEgress NATゲートウェイを定義することができます。
+
 ### Contiv
 
 [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
@@ -266,14 +277,6 @@ stateful ACLs, load-balancers etc to build different virtual networking
 topologies.  The project has a specific Kubernetes plugin and documentation
 at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
 
-### Project Calico
-
-[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
-
-Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)).  Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking.  Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall.
-
-Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
-
 ### Romana
 
 [Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
@@ -287,9 +290,7 @@ or stand-alone.  In either version, it doesn't require any configuration or extr
 to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
 
 
-
 ## {{% heading "whatsnext" %}}
 
 
 ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
-