kubernetes · adtac · Jun 12, 2019 · Feb 28, 2020 · Apr 20, 2020 · Apr 21, 2020
diff --git a/README-ja.md b/README-ja.md
@@ -3,72 +3,64 @@
 [![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
 [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
-ようこそ！このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！
+このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！
 
-## ドキュメントに貢献する
-
-GitHubの画面右上にある**Fork**ボタンをクリックすると、お使いのGitHubアカウントに紐付いた本リポジトリのコピーが作成され、このコピーのことを*フォーク*と呼びます。フォークリポジトリの中ではお好きなように変更を加えていただいて構いません。加えた変更をこのリポジトリに追加したい任意のタイミングにて、フォークリポジトリからPull Reqeustを作成してください。
-
-Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。
-Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。**
-また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。
-さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。
-レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。
-
-Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください:
-
-* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/)
-* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/)
-* [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/)
-* [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/)
-
-## Dockerを使ってローカル環境でWebサイトを動かす
-
-ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[Hugo](https://gohugo.io)を動かすのに特化した[Docker](https://docker.com)イメージを使うことです。
+## Hugoを使ってローカル環境でWebサイトを動かす
 
-> Windows上で環境を作る場合は[Chocolatey](https://chocolatey.org)を使ってインストール可能な追加のツールが必要になります。 `choco install make`
+Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
 
-> Dockerを使わずに環境を構築したい場合は、[Hugoをローカル環境で動かす](#hugoをローカル環境で動かす)をご覧ください。
-
-既に[Dockerが動いている環境](https://www.docker.com/get-started)であれば、以下のコマンドを使って`kubernetes-hugo`イメージをローカルでビルドします:
+Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
 
 ```bash
-make docker-image
+git clone https://github.com/kubernetes/website.git
+cd website
+git submodule update --init --recursive
+hugo server --buildFuture
 ```
 
-イメージが作成されたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
+これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
 
-```bash
-make docker-serve
-```
+## SIG Docsに参加する
 
-お使いのブラウザにて http://localhost:1313 にアクセスすることでWebサイトが開きます。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
+[コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。
 
-## Hugoをローカル環境で動かす
+本プロジェクトのメンテナーには以下の方法で連絡することができます:
 
-Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L9)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
+- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja)
+- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
-Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
+## ドキュメントに貢献する
 
-```bash
-make serve
-```
+GitHubの画面右上にある**Fork**ボタンをクリックすると、お使いのGitHubアカウントに紐付いた本リポジトリのコピーが作成され、このコピーのことを*フォーク*と呼びます。フォークリポジトリの中ではお好きなように変更を加えていただいて構いません。加えた変更をこのリポジトリに追加したい任意のタイミングにて、フォークリポジトリからPull Reqeustを作成してください。
 
-これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
+Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。
+Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。**
+また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。
+さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。
+レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。
 
-## コミュニティ内での議論、貢献、サポートなどについて
+Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください:
 
-[コミュニティのページ](http://kubernetes.io/community/)をご覧になることで、Kubernetesコミュニティとの関わり方を学ぶことができます。
+* [Kubernetesのドキュメントへの貢献](https://kubernetes.io/ja/docs/contribute/)
+* [ページコンテントタイプ](https://kubernetes.io/docs/contribute/style/page-content-types/)
+* [ドキュメントのスタイルガイド](https://kubernetes.io/docs/contribute/style/style-guide/)
+* [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/)
 
-本プロジェクトのメンテナーには以下の方法で連絡することができます:
+## 翻訳された`README.md`一覧
 
-- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja)
-- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+| Language  | Language |
+|---|---|
+|[中国語](README-zh.md)|[韓国語](README-ko.md)|
+|[フランス語](README-fr.md)|[ポーランド語](README-pl.md)|
+|[ドイツ語](README-de.md)|[ポルトガル語](README-pt.md)|
+|[ヒンディー語](README-hi.md)|[ロシア語](README-ru.md)|
+|[インドネシア語](README-id.md)|[スペイン語](README-es.md)|
+|[イタリア語](README-it.md)|[ウクライナ語](README-uk.md)|
+|[日本語](README-ja.md)|[ベトナム語](README-vi.md)|
 
 ### 行動規範
 
-Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。
+Kubernetesコミュニティへの参加については、[CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)によって管理されています。
 
 ## ありがとうございます！
 

diff --git a/README.md b/README.md
@@ -41,7 +41,7 @@ Furthermore, in some cases, one of your reviewers might ask for a technical revi
 For more information about contributing to the Kubernetes documentation, see:
 
 * [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
-* [Using Page Templates](https://kubernetes.io/docs/contribute/style/page-templates/)
+* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
 * [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
 

diff --git a/config.toml b/config.toml
@@ -237,7 +237,7 @@ no = 'Sorry to hear that. Please <a href="https://github.com/USERNAME/REPOSITORY
 
 [[params.links.user]]
 	name = "Youtube"
-	url = "https://youtbue.com/kubernetescommunity"
+	url = "https://youtube.com/kubernetescommunity"
 	icon = "fab fa-youtube"
   desc = "Youtube community videos"
 

diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md
@@ -66,7 +66,7 @@ The nodes in a cluster are the machines (VMs, physical servers, etc) that run yo
 
 
 If you would like to write a concept page, see
-[Page Content Types](/docs/home/contribute/style/page-content-types/#concept)
+[Page Content Types](/docs/contribute/style/page-content-types/#concept)
 for information about the concept page types.
 
 
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md
@@ -99,7 +99,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
 * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
 * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
 * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
-* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB.
+* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services.
 * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
 * `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
 * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
@@ -433,4 +433,4 @@ Alibaba Cloud does not require the format of node name, but the kubelet needs to
 
 ### Load Balancers  
 
-You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
+You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
@@ -60,7 +60,7 @@ metadata:
   name: game-demo
 data:
   # property-like keys; each key maps to a simple value
-  player_initial_lives: 3
+  player_initial_lives: "3"
   ui_properties_file_name: "user-interface.properties"
   #
   # file-like keys
@@ -131,7 +131,7 @@ spec:
 
 A ConfigMap doesn't differentiate between single line property values and
 multi-line file-like values.
-What matters how Pods and other objects consume those values.
+What matters is how Pods and other objects consume those values.
 For this example, defining a volume and mounting it inside the `demo`
 container as `/config` creates four files:
 
@@ -168,7 +168,7 @@ ConfigMaps can hold data that other parts of the system should use for configura
 To consume a ConfigMap in a volume in a Pod:
 
 1. Create a config map or use an existing one. Multiple Pods can reference the same config map.
-1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configmap.localObjectReference` field set to reference your ConfigMap object.
+1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object.
 1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear.
 1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`.
 

diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
@@ -61,6 +61,8 @@ you can do one of the following:
 - omit the `imagePullPolicy` and the tag for the image to use.
 - enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
 
+When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
+
 ## Multi-architecture Images with Manifests
 
 As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.

diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -178,7 +178,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
 
 | Feature | Description | CRDs | Aggregated API |
 | ------- | ----------- | ---- | -------------- |
-| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes.  Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation).  Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
+| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes.  Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation).  Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
 | Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
 | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
 | Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |

diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -223,7 +223,7 @@ Here are some examples of device plugin implementations:
 * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
 * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
 * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
-* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
+* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
 
 
 ## {{% heading "whatsnext" %}}

diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
 They adapt it to support new types and new kinds of hardware.
 
 Most cluster administrators will use a hosted or distribution
-instance of Kubernetes. As a result, most Kubernetes users will need to
+instance of Kubernetes. As a result, most Kubernetes users will not need to
 install extensions and fewer will need to author new ones.
 
 ## Extension Patterns