replace link to en

Author: riita10069

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

@@ -177,7 +177,7 @@ rules:
 
 ## {{% heading "whatsnext" %}}
 
-[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+[Cloud Controller Manager Administration](/ja/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
 はクラウドコントラーマネージャーの実行と管理を説明しています。
 
 どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？
@@ -186,4 +186,4 @@ rules:
 
 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。
 
-プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
+プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。

content/ja/docs/concepts/architecture/master-node-communication.md

@@ -17,7 +17,7 @@ weight: 20
 ## クラスターからマスターへの通信
 
 クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
-一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
+一般的には、1つ以上の形式のクライアント[認証](/ja/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。
 
 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。

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

@@ -267,7 +267,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}
 `TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
-詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
+詳細は、[ノードのトポロジー管理ポリシーを制御する](/ja/docs/tasks/administer-cluster/topology-manager/)を参照してください。
 
 ## {{% heading "whatsnext" %}}
 

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

@@ -30,7 +30,7 @@ content_type: concept
 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。
-* [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。
+* [Romana](https://romana.io)は、[NetworkPolicy API](/ja/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。
 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。
 
 ## サービスディスカバリ

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

@@ -31,7 +31,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
 
 * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。
 
-* 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
+* 共有クラスターにおける[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
 
 ## クラスターをセキュアにする
 

content/ja/docs/concepts/cluster-administration/manage-deployment.md

@@ -157,7 +157,7 @@ deployment.apps/my-deployment created
 persistentvolumeclaim/my-pvc created
 ```
 
-`kubectl`についてさらに知りたい場合は、[kubectlの概要](/docs/reference/kubectl/overview/)を参照してください。
+`kubectl`についてさらに知りたい場合は、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。
 
 ## ラベルを有効に使う
 
@@ -294,7 +294,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
 
 このコマンドでは"app=nginx"というラベルのついた全てのPodを出力し、Podのtierという項目も表示します(`-L`または`--label-columns`で指定)。
 
-さらなる情報は、[ラベル](/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。
+さらなる情報は、[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。
 
 ## アノテーションの更新
 
@@ -313,7 +313,7 @@ metadata:
 ...
 ```
 
-さらなる情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。
+さらなる情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。
 
 ## アプリケーションのスケール
 
@@ -443,7 +443,7 @@ deployment.apps/my-nginx scaled
 kubectl edit deployment/my-nginx
 ```
 
-できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/docs/concepts/workloads/controllers/deployment/)を参照してください。
+できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/ja/docs/concepts/workloads/controllers/deployment/)を参照してください。
 
 
 

content/ja/docs/concepts/configuration/configmap.md

@@ -192,6 +192,6 @@ immutable: true
 
 ## {{% heading "whatsnext" %}}
 
-* [Secret](/docs/concepts/configuration/secret/)について読む。
+* [Secret](/ja/docs/concepts/configuration/secret/)について読む。
 * [Podを構成してConfigMapを使用する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読む。
 * コードを設定から分離する動機を理解するために[The Twelve-Factor App](https://12factor.net/ja/)を読む。

content/ja/docs/concepts/configuration/manage-resources-containers.md

@@ -51,8 +51,8 @@ Huge PageはLinux固有の機能であり、Nodeのカーネルはデフォル
 
 CPUとメモリーは、まとめて*コンピュートリソース*または単に*リソース*と呼ばれます。
 コンピューティングリソースは、要求され、割り当てられ、消費され得る測定可能な量です。
-それらは[API resources](/docs/concepts/overview/kubernetes-api/)とは異なります。
-Podや[Services](/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
+それらは[API resources](/ja/docs/concepts/overview/kubernetes-api/)とは異なります。
+Podや[Services](/ja/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
 
 ## Podとコンテナのリソース要求と制限
 
@@ -624,9 +624,9 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
 
 ## {{% heading "whatsnext" %}}
 
-* [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う
+* [コンテナとPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う
 
-* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う
+* [コンテナとPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う
 
 * 要求と制限の違いの詳細については、[リソースQoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)を参照する
 

content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -14,7 +14,7 @@ kubeconfigを使用すると、クラスターに、ユーザー、名前空間
 
 デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。
 
-kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。
+kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。
 
 <!-- body -->
 

content/ja/docs/concepts/configuration/secret.md

@@ -311,9 +311,9 @@ stringData:
 
 Secretを作成するには、いくつかのオプションがあります。
 
-- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
-- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
-- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- [create Secret using `kubectl` command](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [create Secret from config file](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [create Secret using kustomize](/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
 
 ## Secretの編集
 
@@ -636,7 +636,7 @@ Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecrets
 - アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します
 - imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。
 
-この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
+この機能は、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
 ```yaml
 apiVersion: v1
 kind: Secret
@@ -662,7 +662,7 @@ kubeletはこの情報をPodのためにプライベートイメージをpullす
 
 #### imagePullSecretを手動で指定する
 
-`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。
+`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/ja/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。
 
 ### imagePullSecretsが自動的にアタッチされるようにする
 
@@ -1006,7 +1006,7 @@ HTTPリクエストを扱い、複雑なビジネスロジックを処理し、
 ### Secret APIを使用するクライアント
 
 Secret APIとやりとりするアプリケーションをデプロイするときには、[RBAC](
-/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー](
+/ja/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー](
 /docs/reference/access-authn-authz/authorization/)を使用して、アクセスを制限すべきです。
 Secretは様々な種類の重要な値を保持することが多く、サービスアカウントのトークンのようにKubernetes内部や、外部のシステムで昇格できるものも多くあります。個々のアプリケーションが、Secretの能力について推論することができたとしても、同じネームスペースの別のアプリケーションがその推定を覆すこともあります。