replace link to en

2022-01-01 01:42:28 +09:00
parent ff4e472dcf
commit 82a201cf3f
62 changed files with 97 additions and 97 deletions
@@ -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/)を見てください。
@@ -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サーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
@@ -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" %}}

@@ -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/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。

 ## サービスディスカバリ
@@ -31,7 +31,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る

 * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。

-* 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
+* 共有クラスターにおける[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。

 ## クラスターをセキュアにする

@@ -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/)を参照してください。



@@ -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/)を読む。
@@ -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)を参照する

@@ -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 -->

@@ -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の能力について推論することができたとしても、同じネームスペースの別のアプリケーションがその推定を覆すこともあります。

@@ -19,7 +19,7 @@ no_list: true
 <!-- body -->

 ## コンテナイメージ {#container-images}
-[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
+[コンテナイメージ](/ja/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。

 設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。

@@ -50,7 +50,7 @@ FOO_SERVICE_PORT=<サービスが実行されているポート>
 ## {{% heading "whatsnext" %}}


-* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
-* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
+* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細
+* [コンテナライフサイクルイベントへのハンドラー紐付け](/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン


@@ -161,4 +161,4 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 * [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
-* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
+* [オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)について学ぶ
@@ -8,7 +8,7 @@ weight: 20

 アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。追加のAPIは、[service-catalog](/docs/concepts/extend-kubernetes/service-catalog/)のような既製のソリューション、または自分で開発したAPIのいずれかです。

-アグリゲーションレイヤーは、[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。
+アグリゲーションレイヤーは、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。



@@ -27,7 +27,7 @@ Kubernetesは自動化のために設計されています。追加の作業、
 ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。

 Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
-オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
+オペレーターはKubernetes APIのクライアントで、[Custom Resource](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。

 ## オペレーターの例 {#example}

@@ -3,7 +3,7 @@ title: フィールドセレクター(Field Selectors)
 weight: 60
 ---

-_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。  
+_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。  
 フィールドセレクタークエリの例は以下の通りです。  

 * `metadata.name=my-service`
@@ -9,7 +9,7 @@ weight: 20

 クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。

-たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。
+たとえば、同じ[名前空間](/ja/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。

 ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。

@@ -6,7 +6,7 @@ weight: 10

 <!-- overview -->

-デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。
+デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/ja/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。

 <!-- body -->

@@ -50,7 +50,7 @@ LimitRangeに対する競合や変更は、すでに作成済みのリソース
 制限の使用例については、以下のページを読んでください。

 - [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
+- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
 - [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
 - [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
 - [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
@@ -44,7 +44,7 @@ ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/

 ## リソースクォータの計算

-特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。
+特定の名前空間において、[コンピュートリソース](/ja/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。

 下記のリソースタイプがサポートされています。

@@ -152,7 +152,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
 | `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
 | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
 | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
-| `PriorityClass` | 指定された[優先度クラス](/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |
+| `PriorityClass` | 指定された[優先度クラス](/ja/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |

 `BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します:

@@ -201,7 +201,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ

 {{< feature-state for_k8s_version="v1.17" state="stable" >}}

-Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
+Podは特定の[優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。

 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。

@@ -66,5 +66,5 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
 * [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
 * ボリュームを使用するPodのスケジューリングについて以下で学んでください。
  * [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
-  * [ストレージ容量の追跡](/ja//docs/concepts/storage/storage-capacity/)
+  * [ストレージ容量の追跡](/ja//ja/docs/concepts/storage/storage-capacity/)
  * [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)
@@ -40,7 +40,7 @@ kubectl get pods -n kube-system | grep kube-scheduler

 スケジューリング性能を改善するため、kube-schedulerは割り当て可能なノードが十分に見つかるとノードの検索を停止できます。大規模クラスターでは、すべてのノードを考慮する単純なアプローチと比較して時間を節約できます。

-クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。
+クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/ja/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。

 [スケジューラーはどのようにノードを探索するか](#how-the-scheduler-iterates-over-nodes)で処理を詳しく説明しています。

@@ -191,7 +191,7 @@ Kubernetesはユーザーまたはコントローラーが明示的に指定し
 自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。
 {{< /note >}}

-[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。
+[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。

  * `node.kubernetes.io/unreachable`
  * `node.kubernetes.io/not-ready`
@@ -281,7 +281,7 @@ Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。
 ### WindowsのPodにはどのプロファイルを適用すればよいですか?

 Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。
-特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
 したがって、現段階では標準化されたセキュリティポリシーは存在しません。

 ### サンドボックス化されたPodはどのように扱えばよいでしょうか?
@@ -62,7 +62,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
 つまり、同じcontainerPortを使用して同じノードで複数のnginx Podを実行し、IPを使用してクラスター内の他のPodやノードからそれらにアクセスできます。
 Dockerと同様に、ポートは引き続きホストノードのインターフェイスに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。

-興味があれば、これを[どのように達成するか](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
+興味があれば、これを[どのように達成するか](/ja/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。

 ## Serviceを作成する

@@ -203,7 +203,7 @@ NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
 kube-dns   ClusterIP   10.0.0.10    <none>        53/UDP,53/TCP   8m
 ```

-このセクションの残りの部分は、寿命の長い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クラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/ja/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。

 ```shell
 kubectl run curl --image=radial/busyboxplus:curl -i --tty
@@ -232,7 +232,7 @@ Address 1: 10.0.162.149

 * https用の自己署名証明書(既にID証明書を持っている場合を除く)
 * 証明書を使用するように構成されたnginxサーバー
-* Podが証明書にアクセスできるようにする[Secret](/docs/concepts/configuration/secret/)
+* Podが証明書にアクセスできるようにする[Secret](/ja/docs/concepts/configuration/secret/)

 これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
 これにはツールをインストールする必要があります。
@@ -98,4 +98,4 @@ IPv6が有効になった外部ロードバランサーをサポートしてい

 ## {{% heading "whatsnext" %}}

-* [IPv4/IPv6デュアルスタックのネットワークを検証する](/docs/tasks/network/validate-dual-stack)
+* [IPv4/IPv6デュアルスタックのネットワークを検証する](/ja/docs/tasks/network/validate-dual-stack)
@@ -127,6 +127,6 @@ EndpointSliceを使用する実装では、エンドポイントを複数のス

 ## {{% heading "whatsnext" %}}

-* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
+* [EndpointSliceの有効化](/ja/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む

@@ -139,6 +139,6 @@ spec:

 ## {{% heading "whatsnext" %}}

-* [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。
+* [Serviceトポトジーを有効にする](/ja/docs/tasks/administer-cluster/enabling-service-topology)を読む。
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。

@@ -38,7 +38,7 @@ CronJobは、クラスターがアイドル状態になりそうなときにJob

 {{< codenew file="application/job/cronjob.yaml" >}}

-([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
+([Running Automated Tasks with a CronJob](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).

 ## CronJobの制限 {#cron-job-limitations}

@@ -105,7 +105,7 @@ nodeAffinity:

 ### TaintsとTolerations

-DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
+DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。

 | Toleration Key                           | Effect     | Version | Description |
 | ---------------------------------------- | ---------- | ------- | ----------- |
@@ -151,7 +151,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`

 ### 静的Pod Pods

-Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
+Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。

 ### Deployment

@@ -562,7 +562,7 @@ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
 deployment.apps/nginx-deployment scaled
 ```

-クラスター内で[水平Podオートスケーラー](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、稼働させたいPodのレプリカ数の最小値と最大値を設定できます。
+クラスター内で[水平Podオートスケーラー](/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、稼働させたいPodのレプリカ数の最小値と最大値を設定できます。

 ```shell
 kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
@@ -94,7 +94,7 @@ spec:

 * nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。
 * webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。
-* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
+* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。

 StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。

@@ -159,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle

 StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。

-上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
+上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/ja/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。

 もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。

@@ -205,6 +205,6 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
 ## {{% heading "whatsnext" %}}


-* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
-* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
+* [ステートフルなアプリケーションのデプロイ](/ja/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
+* [StatefulSetを使ったCassandraのデプロイ](/ja/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
 * [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
@@ -89,7 +89,7 @@ PodにはPodStatusがあります。それはPodが成功したかどうかの

 * `PodScheduled`: PodがNodeにスケジュールされました。
 * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
-* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
+* `Initialized`: すべての[Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
 * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。

 フィールド名         | 内容