Merge pull request #34108 from swagmdy/fix-rbac

[ja]fix typo in k8s.io/ja/docs/reference/access-authn-authz/rbac/ #31220
fix typo
2022-06-02 02:25:47 -07:00 · 2022-06-02 14:51:24 +09:00 · 2022-03-24 21:59:51 -07:00 · 2021-12-11 17:16:50 +09:00 · 2021-12-11 15:30:24 +09:00 · 2021-12-11 15:29:04 +09:00
47 changed files with 400 additions and 192 deletions
@@ -35,7 +35,7 @@ Kubernetesには、デプロイ済みのコンテナ化されたアプリケー
 * [Volume](/docs/concepts/storage/volumes/)
 * [Namespace](/ja/docs/concepts/overview/working-with-objects/namespaces/)

-Kubernetesには、[コントローラー](/docs/concepts/architecture/controller/)に依存して基本オブジェクトを構築し、追加の機能と便利な機能を提供する高レベルの抽象化も含まれています。これらには以下のものを含みます:
+Kubernetesには、[コントローラー](/ja/docs/concepts/architecture/controller/)に依存して基本オブジェクトを構築し、追加の機能と便利な機能を提供する高レベルの抽象化も含まれています。これらには以下のものを含みます:

 * [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
 * [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)
@@ -35,7 +35,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る

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

-* [Certificates](/docs/concepts/cluster-administration/certificates/)では、異なるツールチェインを使用して証明書を作成する方法を説明します。
+* [Certificates](/ja/docs/concepts/cluster-administration/certificates/)では、異なるツールチェインを使用して証明書を作成する方法を説明します。

 * [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。

@@ -159,7 +159,7 @@ persistentvolumeclaim/my-pvc created

 `kubectl`についてさらに知りたい場合は、[kubectlの概要](/docs/reference/kubectl/overview/)を参照してください。

-## ラベルを有効に使う
+## ラベルを有効に使う {#using-labels-effectively}

 これまで取り上げた例では、リソースに対して最大1つのラベルを適用してきました。リソースのセットを他のセットと区別するために、複数のラベルが必要な状況があります。

@@ -350,7 +350,7 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled
 さらなる情報は、[kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)、[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)を参照してください。


-## リソースの直接的アップデート
+## リソースの直接的アップデート {#in-place-updates-of-resources}

 場合によっては、作成したリソースに対して処理を中断させずに更新を行う必要があります。

@@ -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/)を読む。
@@ -366,7 +366,7 @@ Kubernetesが使用しないようにする必要があります。
 {{% /tab %}}
 {{< /tabs >}}

-## 拡張リソース
+## 拡張リソース {#extended-resources}

 拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。
 これにより、クラスタオペレータはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
@@ -484,7 +484,7 @@ spec:
        example.com/foo: 1
 ```

-## トラブルシューティング
+## トラブルシューティング {#troubleshooting}

 ### failedSchedulingイベントメッセージが表示され、Podが保留中になる

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


 <!-- body -->
-## 一般的な設定のTips
+## 一般的な設定のTips {#general-configuration-tips}
 - 構成を定義する際には、最新の安定したAPIバージョンを指定してください。

 - 設定ファイルは、クラスターに反映される前にバージョン管理システムに保存されるべきです。これによって、必要に応じて設定変更を迅速にロールバックできます。また、クラスターの再作成や復元時にも役立ちます。
@@ -44,7 +44,7 @@ weight: 10

  *これは順序付けの必要性を意味します* - `Pod`がアクセスしたい`Service`は`Pod`自身の前に作らなければならず、そうしないと環境変数は注入されません。DNSにはこの制限はありません。

- （強くお勧めしますが）[クラスターアドオン](/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスタ全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。
+- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスタ全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。

 - どうしても必要な場合以外は、Podに`hostPort`を指定しないでください。Podを`hostPort`にバインドすると、Podがスケジュールできる場所の数を制限します、それぞれの<`hostIP`、 `hostPort`、`protocol`>の組み合わせはユニークでなければならないからです。`hostIP`と`protocol`を明示的に指定しないと、Kubernetesはデフォルトの`hostIP`として`0.0.0.0`を、デフォルトの `protocol`として`TCP`を使います。

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

 ## コンテナイメージ

-[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が特定のイメージをpullしようとしたときに作用します。
+[imagePullPolicy](/ja/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が特定のイメージをpullしようとしたときに作用します。

 - `imagePullPolicy: IfNotPresent`: ローカルでイメージが見つからない場合にのみイメージをpullします。

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

 - `kubectl apply -f <directory>`を使いましょう。これを使うと、ディレクトリ内のすべての`.yaml`、`.yml`、および`.json`ファイルが`apply`に渡されます。

- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
+- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/ja/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。

 - 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment`や`kubectl expose`を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。

@@ -352,7 +352,7 @@ Podの中のコンテナがSecretを使うために、データボリューム
 Secretは直接Podが参照できるようにはされず、システムの別の部分に使われることもあります。
 例えば、Secretはあなたに代わってシステムの他の部分が外部のシステムとやりとりするために使う機密情報を保持することもあります。

-### SecretをファイルとしてPodから利用する
+### SecretをファイルとしてPodから利用する {#using-secrets-as-files-from-a-pod}

 Podのボリュームとして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が自動的にアタッチされるようにする

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

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

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

@@ -29,5 +29,5 @@ no_list: true

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

-* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
+* [コンテナイメージ](/ja/docs/concepts/containers/images/)についてお読みください。
 * [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。
@@ -50,7 +50,7 @@ FOO_SERVICE_PORT=<サービスが実行されているポート>
 ## {{% heading "whatsnext" %}}


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


@@ -36,7 +36,7 @@ weight: 10
 {{< /caution >}}


-## イメージの更新
+## イメージの更新 {#updating-images}

 デフォルトのpull policyでは、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}はイメージを既に取得済みの場合、イメージのPullをスキップさせる`IfNotPresent`が設定されています。
 常にPullを強制させたい場合は、次のいずれかの方法で実行できます。
@@ -178,7 +178,7 @@ Node構成を制御できる場合、この方法が適しています。

 すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。

-### PodでimagePullSecretsを指定する
+### PodでimagePullSecretsを指定する {#specifying-imagepullsecrets-on-a-pod}

 {{< note >}}
 この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。
@@ -13,7 +13,7 @@ weight: 1
 <!-- body -->

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

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

@@ -22,5 +22,5 @@ weight: 1
 {{< glossary_definition term_id="container-runtime" length="all" >}}

 ## {{% heading "whatsnext" %}}
-* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
+* [コンテナイメージ](/ja/docs/concepts/containers/images/)についてお読みください。
 * [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。
@@ -88,7 +88,7 @@ kube-controller-managerを使用すると、cloud-controller-managerは複数の
 アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。
 アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。

-いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。
+いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/ja/docs/concepts/cluster-administration/addons/) をご覧ください。

 ### DNS

@@ -115,7 +115,7 @@ Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサ
 ## {{% heading "whatsnext" %}}

 * [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ
-* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ
+* [コントローラー](/ja/docs/concepts/architecture/controller/)について学ぶ
 * [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ
 * etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む

@@ -16,9 +16,9 @@ card:
 Kubernetesの中核である {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。
 APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。

-Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
+Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます(例:Pod、Namespace、ConfigMap、Events)。

-ほとんどの操作は、APIを使用している[kubectl](/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。
+ほとんどの操作は、APIを使用している[kubectl](/ja/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/ja/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。
 RESTコールを利用して直接APIにアクセスすることも可能です。

 Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。
@@ -65,7 +65,7 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp
 </table>


-Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しています。このフォーマットに関しては、[Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/des ign-proposals/api-machinery/protobuf.md)デザイン提案を参照してください。また、各スキーマのInterface Definition Language（IDL）ファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
+Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しています。このフォーマットに関しては、[Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)デザイン提案を参照してください。また、各スキーマのInterface Definition Language(IDL)ファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。

 ## 永続性

@@ -79,7 +79,7 @@ APIが、システムリソースと動作について明確かつ一貫した

 APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[有効もしくは無効](/docs/reference/using-api/#enabling-or-disabling)を行える[APIグループ](/docs/reference/using-api/#api-groups)を実装しました。

-APIリソースは、APIグループ、リソースタイプ、ネームスペース（namespacedリソースのための）、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。
+APIリソースは、APIグループ、リソースタイプ、ネームスペース(namespacedリソースのための)、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。

 例えば、同じリソースで`v1`と`v1beta1`の2つのバージョンが有ることを考えてみます。`v1beta1`バージョンのAPIを利用しオブジェクトを最初に作成したとして、`v1beta1`もしくは`v1`どちらのAPIバージョンを利用してもオブジェクトのread、update、deleteができます。

@@ -92,7 +92,7 @@ Kubernetesプロジェクトは、既存のクライアントとの互換性を
 基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
 リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。

-Kubernetesは、公式のKubernetes APIが一度一般提供（GA）に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。さらに、Kubernetesは _beta_ についても可能な限り互換性を維持し続けます。ベータAPIを採用した場合、その機能が安定版になったあとでも、APIを利用してクラスタを操作し続けることができます。
+Kubernetesは、公式のKubernetes APIが一度一般提供(GA)に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。さらに、Kubernetesは _beta_ についても可能な限り互換性を維持し続けます。ベータAPIを採用した場合、その機能が安定版になったあとでも、APIを利用してクラスタを操作し続けることができます。

 {{< note >}}
 Kubernetesは、 _alpha_ APIバージョンについても互換性の維持に注力しますが、いくつかの事情により不可である場合もあります。アルファAPIバージョンを使っている場合、クラスタのアップグレードやAPIが変更された場合に備えて、Kubernetesのリリースノートを確認してください。
@@ -112,5 +112,5 @@ Kubernetes APIは2つの方法で拡張できます。

 - 自分自身で[カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)を追加してKubernetes APIを拡張する方法について学んでください。
 - [Kubernetes APIのアクセス制御](/docs/concepts/security/controlling-access/)では、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
- [APIリファレンス](/ja/docs/reference/kubernetes-api/)を読んで、APIエンドポイント、リソースタイプやサンプルについて学んでください。
- [APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)から、互換性のある変更とは何か, どのようにAPIを変更するかについて学んでください。
+- [APIリファレンス](/docs/reference/kubernetes-api/)を読んで、APIエンドポイント、リソースタイプやサンプルについて学んでください。
+- [APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)から、互換性のある変更とは何か、どのようにAPIを変更するかについて学んでください。
@@ -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 -->

@@ -44,7 +44,7 @@ ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/

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

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

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

@@ -61,7 +61,7 @@ ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/

 ### 拡張リソースのためのリソースクォータ

-上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。
+上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/ja/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。

 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`limits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。

@@ -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が選択されたときのみ、そのリソースクォータが一致し、消費されます。

@@ -218,4 +218,4 @@ DaemonSetのコントローラーは、DaemonSetが中断されるのを防ぐ
 ## {{% heading "whatsnext" %}}

 * [リソース枯渇の対処](/docs/tasks/administer-cluster/out-of-resource/)とどのような設定ができるかについてを読む
-* [Podの優先度](/docs/concepts/configuration/pod-priority-preemption/)を読む
+* [Podの優先度](/ja/docs/concepts/configuration/pod-priority-preemption/)を読む
@@ -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を作成する

@@ -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/)から取得できます。
 これにはツールをインストールする必要があります。
@@ -18,7 +18,7 @@ weight: 40
 * ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
 * クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードの集合です。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはインターネットに公開されていません。
 * エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。クラウドプロバイダーが管理するゲートウェイや、物理的なハードウェアの一部である場合もあります。
-* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
+* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
 * Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodの集合を特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に指定がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つものとして扱われます。

 ## Ingressとは何か
@@ -66,7 +66,7 @@ Ingressリソースの最小構成の例は以下のとおりです。

 {{< codenew file="service/networking/minimal-ingress.yaml" >}}

-他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
+他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。

 Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。

@@ -303,7 +303,7 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ

 ### DNS

-ユーザーは[アドオン](/docs/concepts/cluster-administration/addons/)を使ってKubernetesクラスターにDNS Serviceをセットアップできます(常にセットアップすべきです)。
+ユーザーは[アドオン](/ja/docs/concepts/cluster-administration/addons/)を使ってKubernetesクラスターにDNS Serviceをセットアップできます(常にセットアップすべきです)。

 CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。
 もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。
@@ -86,7 +86,7 @@ DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働さ
 下記の問題について説明します:

 * 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。
- * [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。
+ * [Podプリエンプション(Pod preemption)](/ja/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。

 `ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます(ターゲットホストを選択する前に、元のNodeAffinityが考慮されます)。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。

@@ -55,7 +55,7 @@ Nodeが停止するか、クラスタの残りの部分から切断された場

 ## コンテナのステータス {#container-states}

-Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。
+Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/ja/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。

 Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。

@@ -105,7 +105,7 @@ PodにはPodStatusがあります。それはPodが成功したかどうかの

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

-追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。
+追加のフィードバックやシグナルをPodStatus: _Pod readiness_ に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。

 ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。

@@ -228,7 +228,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
 1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。  
   削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。  
   Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。
-    1. Pod内のコンテナの1つが`preStop`[フック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。
+    1. Pod内のコンテナの1つが`preStop`[フック](/ja/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。
   {{< note >}}
   `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。
   {{< /note >}}
@@ -236,7 +236,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
   {{< note >}}
   Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。
   {{< /note >}}
-1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。
+1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が _始まる_ とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。
 1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。
 1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。
 1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。
@@ -275,6 +275,6 @@ StatefulSetのPodについては、[StatefulSetからPodを削除するための

 * [Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のハンズオンをやってみる

-* [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ
+* [Container lifecycle hooks](/ja/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ

 * APIのPod/コンテナステータスの詳細情報は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)および[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください
@@ -40,7 +40,7 @@ card:

 ### Pull Requestを送るまで

-未翻訳ページの新規翻訳作業と既存ページの修正作業でそれぞれ手順が異なります。
+未翻訳ページの新規翻訳作業と既存ページの修正作業でそれぞれ手順が異なります。いずれの場合も、編集したページに対して、[Hugo](https://gohugo.io)のレンダリングが問題なくできているかどうかをローカル環境で確認しましょう。

 既存ページへの追加修正については、後述の[マイルストーンについて](#milestones)に目を通すことをおすすめします。

@@ -152,6 +152,15 @@ cron「の」ジョブは、「の」が続く事による解釈の難から基
 - 訳で難しい・わからないと感じたらSlackの#kubernetes-docs-jaでみんなに聞く
 - できることを挙手制で、できないときは早めに報告

+### Markdown記法に関する注意事項
+
+- 原則として、翻訳元のMarkdown記法に従うこととするが、記法を変更した方が適切な場合はこの限りではない
+- 強調表現でアンダースコアを使うときは、基本的には前後に空白文字を入れる(例: `これは _斜体_ です`)
+    - 詰めて記述すると、`<em>`や`<strong>`に変換されないことがあるため
+- メイリオフォントは、日本語文字が斜体にならない仕様のため、次のような方法で確認する
+    - ブラウザのフォント設定で、別のフォントに変更する
+    - Firefoxを使う(Firefoxはメイリオでも斜体になるよう対処されている)
+
 ## アップストリームのコントリビューター

 SIG Docsでは、英語のソースに対する[アップストリームへのコントリビュートや誤りの訂正](/docs/contribute/intermediate#localize-content)を歓迎しています。
@@ -20,7 +20,7 @@ Kubernetesのドキュメント上の新しい作業は、ほとんどの場合

 既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。

-1. ページの右側のサイドバーにある**ドキュメントのissueを作成**ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。
+1. 右側のサイドバーにある**ドキュメントのissueを作成**のリンクをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。
 2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。
 3. **Submit new issue**ボタンをクリックします。

@@ -30,7 +30,7 @@ Kubernetesのドキュメント上の新しい作業は、ほとんどの場合

 新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。

- コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**ボタンをクリックする。
+- コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**のリンクをクリックする。
 - [GitHub](https://github.com/kubernetes/website/issues/new/)に移動し、直接issueを作る。

 ## よいissueを作るには
@@ -16,8 +16,8 @@ content_type: concept

 ## APIリファレンス

-* [Kubernetes API概要](/docs/reference/using-api/) - Kubernetes APIの概要です。
-* [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
+* [KubernetesのAPIリファレンス {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+* [Kubernetes APIを使う](/docs/reference/using-api/) - Kubernetes APIの概要です。

 ## APIクライアントライブラリー

@@ -42,10 +42,8 @@ content_type: concept
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
  * [kube-schedulerポリシー](/docs/reference/scheduling/policies)
-  * [kube-schedulerプロファイル](/docs/reference/scheduling/profiles)
+  * [kube-schedulerプロファイル](/docs/reference/scheduling/config#profiles)

 ## 設計のドキュメント

 Kubernetesの機能に関する設計ドキュメントのアーカイブです。[Kubernetesアーキテクチャ](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) と[Kubernetesデザイン概要](https://git.k8s.io/community/contributors/design-proposals)から読み始めると良いでしょう。
-
-
@@ -63,7 +63,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app

 これにより、"app1"と"app2"の2つのグループに属するユーザー名"jbeda"の証明書署名要求が作成されます。

-クライアント証明書の生成方法については、[証明書の管理](/docs/concepts/cluster-administration/certificates/)を参照してください。
+クライアント証明書の生成方法については、[証明書の管理](/ja/docs/concepts/cluster-administration/certificates/)を参照してください。

 ### 静的なトークンファイル

@@ -195,7 +195,35 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6
 このプロトコルのOAuth2の主な拡張機能は、[ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)と呼ばれる、アクセストークンとアクセストークンと一緒に返される追加フィールドです。
 このトークンは、ユーザーの電子メールなどのよく知られたフィールドを持つJSON Web Token(JWT)であり、サーバーによって署名されています。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。

-![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)
+{{< mermaid >}}
+sequenceDiagram
+    participant user as User
+    participant idp as Identity Provider
+    participant kube as Kubectl
+    participant api as API Server
+
+    user ->> idp: 1. IdPにログイン
+    activate idp
+    idp -->> user: 2. access_tokenとid_token、<br>refresh_tokenを提供
+    deactivate idp
+    activate user
+    user ->> kube: 3. Kubectlを使用する場合、<br>--tokenフラグでid_tokenを使用するか、<br>または.kube/configにトークンを追加する
+    deactivate user
+    activate kube
+    kube ->> api: 4. 認可: Bearer...
+    deactivate kube
+    activate api
+    api ->> api: 5. JWT署名は有効か?
+    api ->> api: 6. JWTは期限切れでないか?(iat+exp)
+    api ->> api: 7. ユーザは認可済みか?
+    api -->> kube: 8. 認可後:アクションを実行して結果を返却
+    deactivate api
+    activate kube
+    kube --x user: 9. 結果を返却
+    deactivate kube
+{{< /mermaid >}}
+
+

 1.  IDプロバイダーにログインします
 2.  IDプロバイダーは、`access_token`、`id_token`、`refresh_token`を提供します
@@ -231,15 +259,15 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6

 重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。

-KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。
+KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、[dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。

 IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。

-1.  すべてではないが、[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html）をサポートしていること
+1.  すべてではないが、[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html)をサポートしていること
 2.  廃れていない暗号を用いたTLSで実行されていること
 3.  認証局が署名した証明書を持っていること(認証局が商用ではない場合や、自己署名の場合も可)

-上述の要件#3、認証局署名付き証明書を必要とすることについて、注意事項があります。GoogleやMicrosoftなどのクラウドプロバイダーではなく、独自のIDプロバイダーをデプロイする場合は、たとえ自己署名されていても、`CA`フラグが`TRUE`に設定されている証明書によって署名されたIDプロバイダーのWebサーバー証明書を持っていなければなりません。これは、Go言語のTLSクライアント実装が、証明書検証に関する標準に対して非常に厳格であるためです。認証局をお持ちでない場合は、CoreOSチームの[このスクリプト](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)を使用して、シンプルな認証局と署名付きの証明書と鍵のペアを作成することができます。
+上述の要件#3、認証局署名付き証明書を必要とすることについて、注意事項があります。GoogleやMicrosoftなどのクラウドプロバイダーではなく、独自のIDプロバイダーをデプロイする場合は、たとえ自己署名されていても、`CA`フラグが`TRUE`に設定されている証明書によって署名されたIDプロバイダーのWebサーバー証明書を持っていなければなりません。これは、Go言語のTLSクライアント実装が、証明書検証に関する標準に対して非常に厳格であるためです。認証局をお持ちでない場合は、Dexチームの[このスクリプト](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh)を使用して、シンプルな認証局と署名付きの証明書と鍵のペアを作成することができます。
 または、[この類似のスクリプト](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)を使って、より寿命が長く、よりキーサイズの大きいSHA256証明書を生成できます。

 特定のシステム用のセットアップ手順は、以下を参照してください。
@@ -341,65 +369,169 @@ current-context: webhook
 contexts:
 - context:
    cluster: name-of-remote-authn-service
-    user: name-of-api-sever
+    user: name-of-api-server
  name: webhook
 ```

-クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`authentication.k8s.io/v1beta1` `TokenReview`オブジェクトをリモートサービスにPOSTします。Kubernetesはそのようなヘッダーが不足しているリクエストを作成しようとはしません。
+クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`TokenReview`オブジェクトをリモートサービスにPOSTします。

-Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。
+Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があり、リクエストと同じバージョンの`TokenReview`オブジェクトで応答する**必要があります**。

-POSTボディは、以下の形式になります。
+{{< tabs name="TokenReview_request" >}}
+{{% tab name="authentication.k8s.io/v1" %}}
+{{< note >}}
+Kubernetes APIサーバーは、下位互換のためにデフォルトで`authentication.k8s.io/v1beta1` トークンレビューを送付します。`authentication.k8s.io/v1`トークンレビューの受信を選択するためには、APIサーバーを`--authentication-token-webhook-version=v1`で起動する必要があります。
+{{< /note >}}

-```json
+```yaml
+{
+  "apiVersion": "authentication.k8s.io/v1",
+  "kind": "TokenReview",
+  "spec": {
+    # APIサーバーに送信される不透明なbearerトークン
+    "token": "014fbff9a07c...",
+   
+    # トークンが提示されたサーバーのオーディエンス識別子のオプションリストに関して、
+    # オーディエンス対応トークン認証機能(例えば、OIDCトークン認証機能) は
+    # オプションリスト内の少なくとも１つのオーディエンスが対応しているものであることを確認し、
+    # トークンに対する有効なオーディエンスとこのリストの共通部分をレスポンスステータスに
+    # 返却する必要があります。
+    # これにより、トークンが提示されたサーバーへの認証に有効であることが保障されます。
+    # オーディエンスが指定されていない場合、Kubernetes APIサーバーへの認証のために
+    # トークンを検証する必要があります。
+    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
+  }
+}
+```
+{{% /tab %}}
+{{% tab name="authentication.k8s.io/v1beta1" %}}
+```yaml
 {
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "spec": {
-    "token": "(Bearerトークン)"
+
+    # APIサーバーに送信される不透明なbearerトークン
+    "token": "014fbff9a07c...",
+   
+    # トークンが提示されたサーバーのオーディエンス識別子のオプションリストに関して、
+    # オーディエンス対応トークン認証機能(例えば、OIDCトークン認証機能) は
+    # オプションリスト内の少なくとも１つのオーディエンスが対応しているものであることを確認し、、
+    # トークンに対する有効なオーディエンスとこのリストの共通部分をレスポンスステータスに
+    # 返却する必要があります。
+    # これにより、トークンが提示されたサーバーへの認証に有効であることが保障されます。
+    # オーディエンスが指定されていない場合、Kubernetes APIサーバーへの認証のために
+    # トークンを検証する必要があります。
+    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
 }
 ```
+{{% /tab %}}
+{{< /tabs >}}

-リモートサービスはログインの成功を示すために、リクエストの`status`フィールドを埋めることが期待されます。レスポンスボディの`spec`フィールドは無視され、省略することができます。Bearerトークンの検証に成功すると、以下のようにBearerトークンが返されます。
+リモートサービスはログインの成功を示すために、リクエストの`status`フィールドを埋めることが期待されます。レスポンスボディの`spec`フィールドは無視され、省略することができます。リモートサービスは、トークンが受信したものと同じ`TokenReview` APIバージョンを使用して、レスポンスを返却する必要があります。Bearerトークンの検証に成功すると、以下のようにBearerトークンが返されます。

-```json
+{{< tabs name="TokenReview_response_success" >}}
+{{% tab name="authentication.k8s.io/v1" %}}
+```yaml
 {
-  "apiVersion": "authentication.k8s.io/v1beta1",
+  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
+      # 必須
      "username": "janedoe@example.com",
+      # オプション
      "uid": "42",
-      "groups": [
-        "developers",
-        "qa"
-      ],
+      # オプションのグループメンバーシップ
+      "groups": ["developers", "qa"],
+      # 認証機能が提供するオプションの追加情報です。
+      # これは、ログやAPIオブジェクトに記録されたり、アドミッションのWebhookで
+      # 利用可能になったりするため、機密データを記載するべきではないです。
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
-    }
+    },
+    # オーディエンス対応トークン認証機能が応答できるオプションリストに、
+    # 提供されたトークンが有効だった`spec.audiences`リストのオーディエンスを含みます。
+    # これが省略された場合、トークンはKubernetes APIサーバーへの認証に有効であるとみなされます。
+    "audiences": ["https://myserver.example.com"]
  }
 }
 ```
-
-リクエストに失敗した場合は、以下のように返されます。
-
-```json
+{{% /tab %}}
+{{% tab name="authentication.k8s.io/v1beta1" %}}
+```yaml
 {
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
-    "authenticated": false
+    "authenticated": true,
+    "user": {
+      # 必須
+      "username": "janedoe@example.com",
+      # オプション
+      "uid": "42",
+      # オプションのグループメンバーシップ
+      "groups": ["developers", "qa"],
+      # 認証機能が提供するオプションの追加情報です。
+      # これは、ログやAPIオブジェクトに記録されたり、アドミッションのWebhookで
+      # 利用可能になったりするため、機密データを記載するべきではないです。
+      "extra": {
+        "extrafield1": [
+          "extravalue1",
+          "extravalue2"
+        ]
+      }
+    },
+    # オーディエンス対応トークン認証機能が応答できるオプションリストに、
+    # 提供されたトークンが有効だった`spec.audiences`リストのオーディエンスを含みます。
+    # これが省略された場合、トークンはKubernetes APIサーバーへの認証に有効であるとみなされます。
+    "audiences": ["https://myserver.example.com"]
  }
 }
 ```
+{{% /tab %}}
+{{< /tabs >}}

-HTTPステータスコードは、追加のエラーコンテキストを提供するために使うことができます。
+リクエストに失敗した場合は、以下のように返されます。
+
+{{< tabs name="TokenReview_response_error" >}}
+{{% tab name="authentication.k8s.io/v1" %}}
+```yaml
+{
+  "apiVersion": "authentication.k8s.io/v1",
+  "kind": "TokenReview",
+  "status": {
+    "authenticated": false,
+    # 認証に失敗した詳細をオプションで記載します。
+    # エラーが提供されていない場合、APIは一般的なUnauthorizedメッセージを返却します。
+    # authenticated=trueの場合、エラーフィールドは無視されます。
+    "error": "Credentials are expired"
+  }
+}
+```
+{{% /tab %}}
+{{% tab name="authentication.k8s.io/v1beta1" %}}
+```yaml
+{
+  "apiVersion": "authentication.k8s.io/v1beta1",
+  "kind": "TokenReview",
+  "status": {
+    "authenticated": false,
+    # 認証に失敗した詳細をオプションで記載します。
+    # エラーが提供されていない場合、APIは一般的なUnauthorizedメッセージを返却します。
+    # authenticated=trueの場合、エラーフィールドは無視されます。
+    "error": "Credentials are expired"
+  }
+}
+```
+{{% /tab %}}
+{{< /tabs >}}


 ### 認証プロキシー {#authenticating-proxy}
@@ -629,6 +761,27 @@ users:
      args:
      - "arg1"
      - "arg2"
+
+      # 実行可能ファイルが存在しないと思われる場合にユーザーに表示するテキストを
+      # オプションで設定可能。
+      # installHint:
+      #    現在のクラスターへの認証にexample-client-go-exec-pluginが必要です。
+      #    下記コマンドでインストールすることで可能です。
+      #      macOSの場合: brew install example-client-go-exec-plugin
+      #      Ubuntuの場合: apt-get install example-client-go-exec-plugin
+      #      Fedoraの場合: dnf install example-client-go-exec-plugin
+      installHint: |
+        example-client-go-exec-plugin is required to authenticate
+        to the current cluster.  It can be installed:
+
+        On macOS: brew install example-client-go-exec-plugin
+
+        On Ubuntu: apt-get install example-client-go-exec-plugin
+
+        On Fedora: dnf install example-client-go-exec-plugin
+
+        ...
+
 clusters:
 - name: my-cluster
  cluster:
@@ -29,7 +29,7 @@ RBAC APIは4種類のKubernetesオブジェクト(_Role_、 _ClusterRole_、  _R

 ### RoleとClusterRole

-RBACの _Role_ または _ClusterRole_ には、一連の権限を表すルールが含まれて言います。
+RBACの _Role_ または _ClusterRole_ には、一連の権限を表すルールが含まれています。
 権限は完全な追加方式です(「deny」のルールはありません)。

 Roleは常に特定の{{< glossary_tooltip text="namespace" term_id="namespace" >}}で権限を設定します。
@@ -65,21 +65,21 @@ rules:
 #### ClusterRoleの例

 ClusterRoleを使用してRoleと同じ権限を付与できます。
-ClusterRolesはクラスター単位でスコープされているため、以下へのアクセスの許可もできます。
+ClusterRoleはクラスター単位でスコープされているため、以下へのアクセスの許可もできます。

 * クラスター単位でスコープされているリソースに({{< glossary_tooltip text="node" term_id="node" >}}など)
 * 非リソースエンドポイントに(`/healthz`など)
 * すべてのNamespaceに渡ってNamespaceに属するリソースに(Podなど)。
  例えば、ClusterRoleを使用して特定のユーザーに`kubectl get pods --all-namespaces`の実行を許可できます。

-以下は特定のNamespace、またはすべてのNamespace([バインド](#rolebindingとclusterrolebinding)方法によります)で{{< glossary_tooltip text="secrets" term_id="secret" >}}への読み取りアクセス権を付与するClusterRoleの例です。
+以下は特定のNamespace、またはすべてのNamespace([バインド](#rolebindingとclusterrolebinding)方法によります)で{{< glossary_tooltip text="Secret" term_id="secret" >}}への読み取りアクセス権を付与するClusterRoleの例です。


 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
-  # 「namespace」はClusterRolesがNamespaceに属していないため、省略されています
+  # 「namespace」はClusterRoleがNamespaceに属していないため、省略されています
  name: secret-reader
 rules:
 - apiGroups: [""]
@@ -109,11 +109,11 @@ RoleBindingまたはClusterRoleBindingオブジェクトは有効な
 #### RoleBindingの例 {#rolebinding-example}

 以下はNamespace「default」内でユーザー「jane」に「pod-reader」のRoleを付与するRoleBindingの例です。
-これにより、「jane」にNamespace「default」のポッドの読み取り許可されます。
+これにより、「jane」にNamespace「default」のPodの読み取りが許可されます。

 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# このRoleBindingは「jane」にNamespace「default」のポッドの読み取りを許可する
+# このRoleBindingは「jane」にNamespace「default」のPodの読み取りを許可する
 # そのNamespaceでRole「pod-reader」を既に持っている必要があります。
 kind: RoleBinding
 metadata:
@@ -134,11 +134,11 @@ roleRef:
 RoleBindingはClusterRoleを参照し、ClusterRoleで定義されている権限をRoleBinding内のNamespaceのリソースに権限付与もできます。この種類の参照を利用すると、クラスター全体で共通のRoleのセットを定義して、それらを複数のNamespace内での再利用できます。

 例えば、以下のRoleBindingがClusterRoleを参照している場合でも、
-「dave」(大文字と小文字が区別されるsubject)はRoleBindingのNamespace(メタデータ内)が「development」のため、Namespace「development」のSecretsのみの読み取りができます。
+「dave」(大文字と小文字が区別されるsubject)はRoleBindingのNamespace(メタデータ内)が「development」のため、Namespace「development」のSecretのみの読み取りができます。

 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# このRoleBindingは「dave」にNamespace「development」のSecretsの読み取りを許可する
+# このRoleBindingは「dave」にNamespace「development」のSecretの読み取りを許可する
 # ClusterRole「secret-reader」を既に持っている必要があります。
 kind: RoleBinding
 metadata:
@@ -161,11 +161,11 @@ roleRef:

 クラスター全体に権限を付与するには、ClusterRoleBindingを使用できます。
 以下のClusterRoleBindingはグループ「manager」のすべてのユーザーに
-Secretsの読み取りを許可します。
+Secretの読み取りを許可します。

 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
-# このClusterRoleBindingはグループ「manager」のすべてのユーザーに任意のNamespaceのSecretsの読み取りを許可します。
+# このClusterRoleBindingはグループ「manager」のすべてのユーザーに任意のNamespaceのSecretの読み取りを許可します。
 kind: ClusterRoleBinding
 metadata:
  name: read-secrets-global
@@ -325,7 +325,7 @@ rules:
  verbs: ["get", "list", "watch"]
 ```

-APIグループ`" extensions "`と `" apps "` の両方で、Deploymentsへの読み取り/書き込みを許可します。
+APIグループ`" extensions "`と `" apps "` の両方で、Deploymentへの読み取り/書き込みを許可します。
 (HTTPレベルでURLのリソース部分に`"deployments"`を持つオブジェクトで)

 ```yaml
@@ -500,7 +500,7 @@ APIサーバーは、デフォルトのClusterRoleオブジェクトとClusterRo
 デフォルトのすべてのClusterRoleおよびClusterRoleBindingには、ラベル`kubernetes.io/bootstrapping=rbac-defaults`が付いています。

 {{< caution >}}
-プレフィックスとして`system:`を含む名前で、ClusterRolesおよびClusterRoleBindingsを変更する場合は注意してください。
+プレフィックスとして`system:`を含む名前で、ClusterRoleおよびClusterRoleBindingを変更する場合は注意してください。
 これらのリソースを変更すると、クラスターが機能しなくなる可能性があります。
 {{< /caution >}}

@@ -557,9 +557,9 @@ ClusterRoleを編集すると、変更が[自動調整](#自動調整)によるA

 ### ユーザー向けRole

-一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスタ全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。
+一部のデフォルトClusterRoleにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingを使用してクラスタ全体に付与されることを意図しているRole、そしてRoleBinding(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。

-ユーザー向けのClusterRolesは[ClusterRoleの集約](#集約clusterrole)を使用して、管理者がこれらのClusterRolesにカスタムリソースのルールを含めることができるようにします。ルールを`admin`、`edit`、または`view` Roleに追加するには、次のラベルの一つ以上でClusterRoleを作成します。
+ユーザー向けのClusterRoleは[ClusterRoleの集約](#集約clusterrole)を使用して、管理者がこれらのClusterRoleにカスタムリソースのルールを含めることができるようにします。ルールを`admin`、`edit`、または`view` Roleに追加するには、次のラベルの一つ以上でClusterRoleを作成します。

 ```yaml
 metadata:
@@ -596,7 +596,7 @@ metadata:
 <td>Namespace内のほとんどのオブジェクトへの読み取り/書き込みアクセスを許可します。

 このRoleは、RoleまたはRoleBindingの表示または変更を許可しません。
-ただし、このRoleでは、Secretsにアクセスして、Namespace内の任意のServiceAccountとしてPodsを実行できるため、Namespace内の任意のServiceAccountのAPIアクセスレベルを取得するために使用できます。</td>
+ただし、このRoleでは、Secretにアクセスして、Namespace内の任意のServiceAccountとしてPodを実行できるため、Namespace内の任意のServiceAccountのAPIアクセスレベルを取得するために使用できます。</td>
 </tr>
 <tr>
 <td><b>view</b></td>
@@ -604,7 +604,7 @@ metadata:
 <td>Namespace内のほとんどのオブジェクトを表示するための読み取り専用アクセスを許可します。
 RoleまたはRoleBindingは表示できません。

-Secretsの内容を読み取るとNamespaceのServiceAccountのクレデンシャルにアクセスできるため、このRoleではSecretsの表示は許可されません。これにより、Namespace内の任意のServiceAccountとしてAPIアクセスが許可されます(特権昇格の形式)。</td>
+Secretの内容を読み取るとNamespaceのServiceAccountのクレデンシャルにアクセスできるため、このRoleではSecretの表示は許可されません。これにより、Namespace内の任意のServiceAccountとしてAPIアクセスが許可されます(特権昇格の形式)。</td>
 </tr>
 </table>

@@ -636,7 +636,7 @@ Secretsの内容を読み取るとNamespaceのServiceAccountのクレデンシ
 <tr>
 <td><b>system:node</b></td>
 <td>None</td>
-<td><b>すべてのsecretへの読み取りアクセス、すべてのポッドステータスオブジェクトへの書き込みアクセスなど、</b>kubeletが必要とするリソースへのアクセスを許可します。
+<td><b>すべてのSecretへの読み取りアクセス、すべてのPodStatusオブジェクトへの書き込みアクセスなど、</b>kubeletが必要とするリソースへのアクセスを許可します。

 <tt>system:node</tt>Roleの代わりに<a href="/docs/reference/access-authn-authz/node/">Node authorizer</a>と <a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction admission plugin</a>を使用し、それらで実行するようにスケジュールされたPodに基づいてkubeletへのAPIアクセスを許可する必要があります。

@@ -750,7 +750,7 @@ RBAC APIは、RoleまたはRoleBindingを編集することにより、ユーザ
 1. 変更対象のオブジェクトと同じスコープで、Roleに含まれるすべての権限を既に持っている(ClusterRoleの場合はクラスター全体。Roleの場合は、同じNamespace内またはクラスター全体)。
 2. `rbac.authorization.k8s.io`APIグループの` roles`または`clusterroles`リソースで` escalate` verbを実行する明示的な権限が付与されている。

-たとえば、 `user-1`にクラスター全体でSecretsを一覧表示する権限がない場合、それらにその権限を含むClusterRoleを作成できません。
+たとえば、 `user-1`にクラスター全体でSecretを一覧表示する権限がない場合、それらにその権限を含むClusterRoleを作成できません。
 ユーザーがRoleを作成/更新できるようにするには、以下のいずれかを実施します。

 1. 必要に応じて、RoleオブジェクトまたはClusterRoleオブジェクトを作成/更新できるRoleを付与する。
@@ -762,7 +762,7 @@ RBAC APIは、RoleまたはRoleBindingを編集することにより、ユーザ

 参照されるRoleに含まれるすべての権限を(RoleBindingと同じスコープで)すでに持っている場合、
 *または*参照されたRoleで`bind` verbを実行する認可されている場合のみ、RoleBindingを作成/更新できます。
-たとえば、 `user-1`にクラスター全体でSecretsを一覧表示する権限がない場合、ClusterRoleBindingを作成してもRoleにその権限を付与できません。
+たとえば、 `user-1`にクラスター全体でSecretを一覧表示する権限がない場合、ClusterRoleBindingを作成してもRoleにその権限を付与できません。
 ユーザーがRoleBindingを作成/更新できるようにするには、以下のいずれかを実施します。

 1. 必要に応じて、RoleBindingまたはClusterRoleBindingオブジェクトを作成/更新できるようにする役割を付与する。
@@ -784,6 +784,7 @@ rules:
 - apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
+  # すべてのClusterRoleのバインドを許可するにはresourceNamesを省略します
  resourceNames: ["admin","edit","view"]
 ---
 apiVersion: rbac.authorization.k8s.io/v1
@@ -804,7 +805,7 @@ subjects:
 最初のRoleとRoleBindingをブートストラップするときは、最初のユーザーがまだ持っていない権限を付与する必要があります。
 初期RoleとRoleBindingをブートストラップするには、以下のいずれかを実施します。

-* 「system：masters」グループのクレデンシャルを使用します。このグループは、デフォルトのBindingによって「cluster-admin」スーパーユーザーRoleにバインドされています。
+* 「system:masters」グループのクレデンシャルを使用します。このグループは、デフォルトのBindingによって「cluster-admin」スーパーユーザーRoleにバインドされています。
 * APIサーバーが安全でないポート(`--insecure-port`)を有効にして実行されている場合、そのポートを介してのAPI呼び出しもできます。これにより、認証や認可が実行されません。

 ## コマンドラインユーティリティー
@@ -813,7 +814,7 @@ subjects:

 以下に、単一のNamespace内で権限を定義するRoleオブジェクトをいくつか例として作成します。

-* ユーザーがポッドで `get`、` watch`、および `list`を実行できるように「pod-reader」という名前のRoleを作成します。
+* ユーザーがPodに対して `get`、` watch`、および `list`を実行できるように「pod-reader」という名前のRoleを作成します。

    ```shell
    kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
@@ -847,7 +848,7 @@ subjects:

 以下にClusterRoleをいくつか例として作成します。

-* ユーザーがポッドに対して`get`、` watch`、および `list`を実行できるようにする「pod-reader」という名前のClusterRoleを作成します。
+* ユーザーがPodに対して`get`、` watch`、および `list`を実行できるようにする「pod-reader」という名前のClusterRoleを作成します。

    ```shell
    kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
@@ -915,7 +916,7 @@ subjects:
    kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
    ```

-* クラスター全体で、ClusterRole「system：node-proxier」へのアクセス許可を「system：kube-proxy」という名前のユーザーに付与します。
+* クラスター全体で、ClusterRole「system:node-proxier」へのアクセス許可を「system:kube-proxy」という名前のユーザーに付与します。

    ```shell
    kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
@@ -943,7 +944,7 @@ subjects:

 * RBACオブジェクトのマニフェストファイルをテストとして適用し、行われる変更を表示します。

-    ```
+    ```shell
    kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
    ```

@@ -955,6 +956,10 @@ subjects:

 * RBACオブジェクトのマニフェストファイルを適用し、(Role内の)余分なアクセス許可と(Binding内の)余分なsubjectsを削除します。

+    ```shell
+    kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
+    ```
+
 ## ServiceAccount権限 {#service-account-permissions}

 デフォルトのRBACポリシーは、コントロールプレーンコンポーネント、ノード、
@@ -963,13 +968,13 @@ subjects:

 これにより、必要に応じて特定のServiceAccountに特定のRoleを付与できます。
 きめ細かいRoleBindingはセキュリティを強化しますが、管理にはより多くの労力が必要です。
-より広範な権限は、不必要な(そして潜在的にエスカレートする)APIアクセスをServiceAccountsに与える可能性がありますが、管理が簡単です。
+より広範な権限は、不必要な(そして潜在的にエスカレートする)APIアクセスをServiceAccountに与える可能性がありますが、管理が簡単です。

 アプローチを最も安全なものから最も安全でないものの順に並べると、次のとおりです。

 1. アプリケーション固有のサービスアカウントにRoleを付与する(ベストプラクティス)
-    これには、アプリケーションがpodのspec、そして作成するサービスアカウント(API、アプリケーションマニフェスト、 `kubectl create serviceaccount`などを介して）で`serviceAccountName`を指定する必要があります。
-    たとえば、「my-namespace」内の読み取り専用権限を「my-sa」サービスアカウントに付与します。
+    これには、アプリケーションがPodのspec、そして作成するServiceAccount(API、アプリケーションマニフェスト、 `kubectl create serviceaccount`などを介して）で`serviceAccountName`を指定する必要があります。
+    たとえば、「my-namespace」内の読み取り専用権限をServiceAccount「my-sa」に付与します。

    ```shell
    kubectl create rolebinding my-sa-view \
@@ -978,15 +983,15 @@ subjects:
      --namespace=my-namespace
    ```

-2. あるNamespaceのサービスアカウント「default」にRoleを付与します
+2. あるNamespaceのServiceAccount「default」にRoleを付与します

-    アプリケーションが `serviceAccountName`を指定しない場合、サービスアカウント「default」を使用します。
+    アプリケーションが `serviceAccountName`を指定しない場合、ServiceAccount「default」を使用します。

    {{< note >}}
-  サービスアカウント「default」に付与された権限は、`serviceAccountName`を指定しないNamespace内のすべてのポッドで利用できます。
+    ServiceAccount「default」に付与された権限は、`serviceAccountName`を指定しないNamespace内のすべてのPodで利用できます。
    {{< /note >}}

-    たとえば、「my-namespace」内の読み取り専用権限をサービスアカウント「default」に付与します。
+    たとえば、「my-namespace」内の読み取り専用権限をServiceAccount「default」に付与します。

    ```shell
    kubectl create rolebinding default-view \
@@ -995,12 +1000,12 @@ subjects:
      --namespace=my-namespace
    ```

-    多くの[アドオン](https://kubernetes.io/docs/concepts/cluster-administration/addons/)は、
+    多くの[アドオン](/ja/docs/concepts/cluster-administration/addons/)は、
    Namespace`kube-system`のサービスアカウント「default」として実行されます。
    これらのアドオンをスーパーユーザーアクセスでの実行を許可するには、Namespace`kube-system`のサービスアカウント「default」のcluster-admin権限を付与します。

    {{< caution >}}
-    これを有効にすると、 Namespace`kube-systemにクラスターのAPIへのスーパーユーザーアクセス許可するSecretsが含まれます。
+    これを有効にすると、 Namespace`kube-system`にクラスターのAPIへのスーパーユーザーアクセス許可するSecretが含まれます。
    {{< /caution >}}

    ```shell
@@ -1040,7 +1045,7 @@ subjects:
    権限の分割をまったく考慮しない場合は、すべてのサービスアカウントにスーパーユーザーアクセスを許可できます。

    {{< warning >}}
-    これにより、すべてのアプリケーションにクラスターへのフルアクセスが許可され、Secretsの読み取りアクセス権(または任意のポッドを作成する機能)を持つユーザーに、クラスターへのフルアクセスが許可されます。
+    これにより、すべてのアプリケーションにクラスターへのフルアクセスが許可され、Secretの読み取りアクセス権(または任意のPodを作成する機能)を持つユーザーに、クラスターへのフルアクセスが許可されます。
    {{< /warning >}}

    ```shell
@@ -1087,7 +1092,7 @@ RBACRoleBindingを使用して、permissive ABACポリシーを複製できま
 {{< warning >}}
 次のポリシーでは、**すべて**のサービスアカウントがクラスター管理者としてふるまうことを許可しています。
 コンテナで実行されているアプリケーションは、サービスアカウントのクレデンシャルを自動的に受け取ります。
-secretsの表示や権限の変更など、APIに対して任意のアクションを実行できます。
+Secretの表示や権限の変更など、APIに対して任意のアクションを実行できます。
 これは推奨されるポリシーではありません。

 ```shell
@@ -54,7 +54,8 @@ content_type: concept
 | `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
 | `CSIMigrationAWS` | `false` | Beta | 1.17 | |
 | `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | |
-| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | |
+| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 |
+| `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | |
 | `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | |
 | `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | |
@@ -63,21 +64,25 @@ content_type: concept
 | `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
 | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
+| `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
+| `CSIMigrationvSphereComplete` | `false` | Beta | 1.19 | |
+| `CSIStorageCapacity` | `false` | Alpha | 1.19 | |
+| `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | |
 | `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
-| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
-| `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
+| `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | |
 | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | Beta | 1.10 | |
+| `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.20 |
 | `DryRun` | `false` | Alpha | 1.12 | 1.12 |
 | `DryRun` | `true` | Beta | 1.13 | |
-| `DynamicAuditing` | `false` | Alpha | 1.13 | |
 | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
 | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | Beta | 1.17 | |
 | `EndpointSlice` | `true` | Beta | 1.18 | |
-| `EndpointSliceProxying` | `false` | Alpha | 1.18 | |
+| `EndpointSliceProxying` | `false` | Alpha | 1.18 | 1.18 |
+| `EndpointSliceProxying` | `true` | Beta | 1.19 | |
 | `EphemeralContainers` | `false` | Alpha | 1.16 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
@@ -86,12 +91,14 @@ content_type: concept
 | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 |
-| `EvenPodsSpread` | `true` | Beta | 1.18 | |
+| `GenericEphemeralVolume` | `false` | Alpha | 1.19 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
-| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | |
+| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 |
+| `HugePageStorageMediumSize` | `true` | Beta | 1.19 | |
 | `HyperVContainer` | `false` | Alpha | 1.10 | |
-| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | |
+| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 |
+| `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | |
+| `IPv6DualStack` | `false` | Alpha | 1.16 | |
 | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | Beta | 1.15 | |
 | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
@@ -99,34 +106,36 @@ content_type: concept
 | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
 | `MountContainers` | `false` | Alpha | 1.9 | |
-| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
-| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
+| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 |
+| `NodeDisruptionExclusion` | `true` | Beta | 1.19 | |
+| `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 |
+| `NonPreemptingPriority` | `true` | Beta | 1.19 | |
 | `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 |
 | `PodDisruptionBudget` | `true` | Beta | 1.5 | |
 | `PodOverhead` | `false` | Alpha | 1.16 | - |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | |
-| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
-| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
 | `RunAsGroup` | `true` | Beta | 1.14 | |
 | `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | Beta | 1.14 | |
-| `SCTPSupport` | `false` | Alpha | 1.12 | |
+| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | Beta | 1.19 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
-| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
+| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
+| `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
 | `ServiceTopology` | `false` | Alpha | 1.17 | |
+| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | |
 | `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
 | `StartupProbe` | `true` | Beta | 1.18 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
-| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
-| `StreamingProxyRedirects` | `true` | Beta | 1.6 | |
 | `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
 | `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
 | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
@@ -141,10 +150,9 @@ content_type: concept
 | `TopologyManager` | `true` | Beta | 1.18 | |
 | `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
 | `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
-| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
-| `VolumePVCDataSource` | `true` | Beta | 1.16 | |
 | `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 |
 | `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | - |
+| `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | |
 | `WindowsGMSA` | `false` | Alpha | 1.14 | |
 | `WindowsGMSA` | `true` | Beta | 1.16 | |
 | `WinDSR` | `false` | Alpha | 1.14 | |
@@ -187,6 +195,9 @@ content_type: concept
 | `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
 | `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
 | `CustomPodDNS` | `true` | GA | 1.14 | - |
+| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
+| `CustomResourceDefaulting` | `true` | Beta | 1.16 | 1.16 |
+| `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
 | `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
 | `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | 1.15 |
 | `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
@@ -199,15 +210,19 @@ content_type: concept
 | `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
 | `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
+| `DynamicAuditing` | `false` | Alpha | 1.13 | 1.18 |
+| `DynamicAuditing` | - | Deprecated | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
 | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
-| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
 | `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 |
 | `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
 | `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - |
+| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 |
+| `EvenPodsSpread` | `true` | Beta | 1.18 | 1.18 |
+| `EvenPodsSpread` | `true` | GA | 1.19 | - |
 | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | Alpha | 1.8 | 1.9 |
@@ -241,9 +256,13 @@ content_type: concept
 | `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
 | `PVCProtection` | - | Deprecated | 1.10 | - |
 | `RequestManagement` | `false` | Alpha | 1.15 | 1.16 |
+| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | 1.18 |
+| `ResourceLimitsPriorityFunction` | - | Deprecated | 1.19 | - |
 | `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
 | `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | 1.16 |
 | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
+| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | 1.18 |
+| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
 | `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
 | `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16  |
 | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
@@ -252,6 +271,9 @@ content_type: concept
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
 | `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
+| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
+| `StreamingProxyRedirects` | `true` | Beta | 1.6 | 1.18 |
+| `StreamingProxyRedirects` | - | Deprecated| 1.19 | - |
 | `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
@@ -268,9 +290,6 @@ content_type: concept
 | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
-| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
-| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
-| `VolumeScheduling` | `true` | GA | 1.13 | - |
 | `VolumeSubpath` | `true` | GA | 1.13 | - |
 | `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
 | `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | 1.16 |
@@ -327,13 +346,13 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}の`DataSource`としてカスタムリソースの使用を有効にします。
 - `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。
 - `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
-`APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
+- `APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
 - `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/docs/tutorials/clusters/apparmor/)で確認できます。
- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
+- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/ja/docs/tutorials/clusters/apparmor/)で確認できます。
+- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。詳細は[dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)で確認できます。
 - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。
+- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/ja/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
+- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。クラスター管理者は、メトリクス`serviceaccount_stale_tokens_total`を使用して、拡張トークンに依存するワークロードを監視できます。そのようなワークロードがない場合は、フラグ`--service-account-extend-token-expiration=false`を指定し`kube-apiserver`を起動することで、拡張トークンをオフにします。詳細は[Service Account Token Volumes](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)で確認できます。
 - `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。
 - `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。
 - `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。
@@ -351,33 +370,41 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `CSIMigrationGCEComplete`: GCE-PDのツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックがGCE-PDのツリー内プラグインからPD CSIプラグインにボリューム操作をルーティングできるようにします。CSIMigrationおよびCSIMigrationGCE機能フラグを有効にし、クラスター内のすべてのノードにPD CSIプラグインをインストールおよび設定する必要があります。
 - `CSIMigrationOpenStack`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のCinderプラグインからCinder CSIプラグインにルーティングします。ノードにCinder CSIプラグインがインストールおよび設定されていない場合、ツリー内のCinderプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
 - `CSIMigrationOpenStackComplete`: Cinderのツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックがCinderのツリー内プラグインからCinder CSIプラグインにボリューム操作をルーティングできるようにします。CSIMigrationおよびCSIMigrationOpenStack機能フラグを有効にし、クラスター内のすべてのノードにCinder CSIプラグインをインストールおよび設定する必要があります。
+- `CSIMigrationvSphere`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のvSphereプラグインからvSphere CSIプラグインにルーティングします。ノードにvSphere CSIプラグインがインストールおよび設定されていない場合、ツリー内のvSphereプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。
+- `CSIMigrationvSphereComplete`: vSphereのツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックがvSphereのツリー内プラグインからvSphere CSIプラグインにボリューム操作をルーティングできるようにします。CSIMigrationおよびCSIMigrationvSphere機能フラグを有効にし、クラスター内のすべてのノードにvSphere CSIプラグインをインストールおよび設定する必要があります。
 - `CSINodeInfo`: csi.storage.k8s.ioのCSINodeInfo APIオブジェクトに関連するすべてのロジックを有効にします。
 - `CSIPersistentVolume`: [CSI(Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。
+- `CSIStorageCapacity`: CSIドライバーがストレージの容量情報を公開し、KubernetesのスケジューラーがPodをスケジュールするときにその情報を使用できるようにします。[ストレージ容量](/ja/docs/concepts/storage/storage-capacity/)を参照してください。
  詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。
+- `CSIVolumeFSGroupPolicy`: CSIドライバーが`fsGroupPolicy`フィールドを使用できるようにします。このフィールドは、CSIドライバーによって作成されたボリュームがボリュームのマウント時にボリュームの所有権とアクセス許可の変更をサポートするかどうかを制御します。
 - `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。
 - `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。
 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
+- `CustomResourceSubresources`: [CustomResourceDefinition](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
+- `CustomResourceValidation`: [CustomResourceDefinition](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
+- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
+- `DisableAcceleratorUsageMetrics`: [kubeletによって収集されたアクセラレータメトリクスを無効にします。](/docs/concepts/cluster-administration/system-metrics/)
 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。
+- `DefaultPodTopologySpread`: [デフォルトの配置](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints)に`PodTopologySpread`スケジューリングプラグインの使用を有効にします。
 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。
- `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
+- `DynamicAuditing`(*非推奨*): v1.19より前で動的監査を有効にするために使用されました。
 - `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。
 - `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。
 - `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。
 - `EnableAggregatedDiscoveryTimeout` (*非推奨*): 集約されたディスカバリーコールで5秒のタイムアウトを有効にします。
 - `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。
 - `EphemeralContainers`: 稼働するPodに{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}を追加する機能を有効にします。
- `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。
+- `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Pod Topology Spread Constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)をご覧ください。
 - `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。
 - `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。
- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。
+- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。v1.13以降、この機能はPod PriorityおよびPreemptionによって非推奨になりました。
 - `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。
 - `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。
+- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、Linuxで実行されているkube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/ja/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
+- `WindowsEndpointSliceProxying`: このフィーチャーゲートを有効にすると、Windowsで実行されているkube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/ja/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
+- `GenericEphemeralVolume`: 通常のボリュームのすべての機能をサポートする一時的なインラインボリュームを有効にします (サードパーティのストレージベンダー、ストレージ容量の追跡、スナップショットからの復元などによって提供されます)。[Ephemeral Volumes](/docs/concepts/storage/ephemeral-volumes/)をご覧ください。
 - `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
 - `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。
 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
@@ -386,37 +413,38 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。
 - `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。
 - `KubeletPodResources`: kubeletのPodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)で確認できます。
- `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。
- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
+- `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により、`NodeDisruptionExclusion`と`ServiceNodeExclusion`によって提供される機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。
+- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/ja/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/ja/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
 - `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。
 - `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
 - `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。
 - `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。
 - `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。
 - `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、Podアフィニティを指定する必要があります。
- `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
+- `PodOverhead`: [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。
 - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。
- `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
+- `PodPriority`: [優先度](/ja/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
 - `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
+- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。
 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
- `ResourceLimitsPriorityFunction`: 入力したPodのCPU制限とメモリ制限の少なくとも1つを満たすノードに対して最低スコアを1に割り当てるスケジューラー優先機能を有効にします。その目的は同じスコアを持つノード間の関係を断つことです。
+- `ResourceLimitsPriorityFunction`(*非推奨*): 入力したPodのCPU制限とメモリ制限の少なくとも1つを満たすノードに対して最低スコアを1に割り当てるスケジューラー優先機能を有効にします。その目的は同じスコアを持つノード間の関係を断つことです。
 - `ResourceQuotaScopeSelectors`: リソース割当のスコープセレクターを有効にします。
- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
+- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)で確認できます。
+- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)で確認できます。
 - `RunAsGroup`: コンテナの初期化プロセスで設定されたプライマリグループIDの制御を有効にします。
- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/docs/concepts/containers/runtime-class/)機能を有効にします。
+- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/ja/docs/concepts/containers/runtime-class/)機能を有効にします。
 - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
- `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
+- `SCTPSupport`: Pod、Service、Endpoints、EndpointSlice、およびNetworkPolicy定義で _SCTP_ `protocol`値を有効にします。
+- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/server-side-apply/)のパスを有効にします。
 - `ServiceAccountIssuerDiscovery`: APIサーバーにてサービスアカウント発行者のOIDC検出エンドポイント（発行者とJWKS URL）を有効にします。詳細については、[Podのサービスアカウント設定](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)をご覧ください。
 - `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。
 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
 - `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
+- `SetHostnameAsFQDN`: Podのホスト名として完全修飾ドメイン名（FQDN）を設定する機能を有効にします。[PodのsetHostnameAsFQDNフィールド](/ja/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)を参照してください。
 - `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
@@ -424,11 +452,12 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
 - `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。
 - `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。
+- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。詳細は[TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。
 - `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。
 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
 - `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。
- `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
+- `TopologyManager`: Kubernetesのさまざまなコンポーネントのきめ細かいハードウェアリソース割り当てを調整するメカニズムを有効にします。[ノードのトポロジー管理ポリシーの制御](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
+- `TTLAfterFinished`: [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
 - `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。
@@ -2,7 +2,7 @@
 title: コンテナ
 id: container
 date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /docs/concepts/containers/
 short_description: >
  軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。

@@ -2,7 +2,7 @@
 title: Controller
 id: controller
 date: 2018-04-12
-full_link: /docs/concepts/architecture/controller/
+full_link: /ja/docs/concepts/architecture/controller/
 short_description: >
  クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。

@@ -6,10 +6,9 @@ full_link: /docs/reference/generated/kubelet
 short_description: >
  クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。

-aka: 
+aka:
 tags:
 - fundamental
- core-object
 ---
 クラスター内の各{{< glossary_tooltip text="ノード" term_id="node" >}}で実行されるエージェントです。各{{< glossary_tooltip text="コンテナ" term_id="container" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}で実行されていることを保証します。

@@ -86,6 +86,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # 複数のファイルからリ
 kubectl apply -f ./dir                         # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します
 kubectl apply -f https://git.io/vPieo          # urlで公開されているファイルからリソースを作成します
 kubectl create deployment nginx --image=nginx  # 単一のnginx Deploymentを作成します
+
+# "Hello World"を出力するJobを作成します
+kubectl create job hello --image=busybox -- echo "Hello World" 
+
+# 毎分"Hello World"を出力するCronJobを作成します
+kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"
+
 kubectl explain pods                           # Podマニフェストのドキュメントを取得します

 # 標準入力から複数のYAMLオブジェクトを作成します
@@ -300,6 +307,7 @@ kubectl run nginx --image=nginx                     # nginx Podを実行し、
 kubectl attach my-pod -i                            # 実行中のコンテナに接続します
 kubectl port-forward my-pod 5000:6000               # ローカルマシンのポート5000を、my-podのポート6000に転送します
 kubectl exec my-pod -- ls /                         # 既存のPodでコマンドを実行(単一コンテナの場合)
+kubectl exec --stdin --tty my-pod -- /bin/sh        # 実行中のPodへのインタラクティブシェルとしてアクセス(単一コンテナの場合)
 kubectl exec my-pod -c my-container -- ls /         # 既存のPodでコマンドを実行(複数コンテナがある場合)
 kubectl top pod POD_NAME --containers               # 特定のPodとそのコンテナのメトリクスを表示します
 ```
@@ -50,7 +50,7 @@ kubectl [command] [TYPE] [NAME] [flags]
   * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。

      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。<br/>
-     例: `kubectl get pod -f ./pod.yaml`
+     例: `kubectl get -f ./pod.yaml`

 * `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。<br/>

@@ -116,14 +116,15 @@ kubectl [command] [TYPE] [NAME] [flags]

 以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。

-(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。)
+(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.19.1時点で正確でした。)

 | リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
 |---|---|---|---|---|
-| `bindings` | | | true | Binding|
+| `bindings` | | | true | Binding |
 | `componentstatuses` | `cs` | | false | ComponentStatus |
 | `configmaps` | `cm` | | true | ConfigMap |
 | `endpoints` | `ep` | | true | Endpoints |
+| `events` | `ev` | | true | Event |
 | `limitranges` | `limits` | | true | LimitRange |
 | `namespaces` | `ns` | | false | Namespace |
 | `nodes` | `no` | | false | Node |
@@ -131,14 +132,14 @@ kubectl [command] [TYPE] [NAME] [flags]
 | `persistentvolumes` | `pv` | | false | PersistentVolume |
 | `pods` | `po` | | true | Pod |
 | `podtemplates` | | | true | PodTemplate |
-| `replicationcontrollers` | `rc` | | true| ReplicationController |
+| `replicationcontrollers` | `rc` | | true | ReplicationController |
 | `resourcequotas` | `quota` | | true | ResourceQuota |
 | `secrets` | | | true | Secret |
 | `serviceaccounts` | `sa` | | true | ServiceAccount |
 | `services` | `svc` | | true | Service |
 | `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
 | `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
-| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
+| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
 | `apiservices` | | apiregistration.k8s.io | false | APIService |
 | `controllerrevisions` | | apps | true | ControllerRevision |
 | `daemonsets` | `ds` | apps | true | DaemonSet |
@@ -155,9 +156,15 @@ kubectl [command] [TYPE] [NAME] [flags]
 | `jobs` | | batch | true | Job |
 | `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
 | `leases` | | coordination.k8s.io | true | Lease |
+| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
 | `events` | `ev` | events.k8s.io | true | Event |
 | `ingresses` | `ing` | extensions | true | Ingress |
+| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
+| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
+| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
+| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
 | `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
+| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
 | `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
 | `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
 | `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
@@ -167,7 +174,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 | `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
 | `csidrivers` | | storage.k8s.io | false | CSIDriver |
 | `csinodes` | | storage.k8s.io | false | CSINode |
-| `storageclasses` | `sc` | storage.k8s.io |  false | StorageClass |
+| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
 | `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |

 ## 出力オプション
@@ -110,7 +110,7 @@ and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
 out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).

 For directions on how to detect if addon containers are hitting resource limits, see the
-[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
+[Troubleshooting section of Compute Resources](/ja/docs/concepts/configuration/manage-resources-containers/#troubleshooting).

 ### 少数のノードの起動の失敗を許容する

@@ -469,7 +469,7 @@ spec:

 ## プライベートコンテナレジストリ

-プライベートコンテナレジストリにアクセスするには、[このページ](/docs/concepts/containers/images/)の手順に従ってください。
+プライベートコンテナレジストリにアクセスするには、[このページ](/ja/docs/concepts/containers/images/)の手順に従ってください。

 `ImagePullSecrets` を使用することをおすすめしますが、MinikubeのVM内でアクセス設定したい場合には、`/home/docker` ディレクトリに `.dockercfg` を置くか、または `/home/docker/.docker` ディレクトリに `config.json` を置いてください。

@@ -220,7 +220,7 @@ for production clusters!

 ### 他のアドオンの参照

-See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.
+See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.

 ## クリーンアップ

@@ -162,7 +162,7 @@ To start using your cluster, you need to run the following as a regular user:

 You should now deploy a Pod network to the cluster.
 Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
-  /docs/concepts/cluster-administration/addons/
+  /ja/docs/concepts/cluster-administration/addons/

 You can now join any number of machines by running the following on each node
 as root:
@@ -395,8 +395,8 @@ kubectl delete node <node name>
 * <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
 * `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
 * Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
-* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
-* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
+* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)で確認する。
+* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/ja/docs/concepts/cluster-administration/addons/)で確認する。
 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。

 ### フィードバック {#feedback}
@@ -164,7 +164,7 @@ kubeletは、組み込まれた`dockershim`CRIを通してDockerと連携しま

 * `kubectl`: クラスターにアクセスするためのコマンドラインツールです。

-kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない**ため、kubeadmにインストールするKubernetesコントロールプレーンのバージョンと一致させる必要があります。そうしないと、予期しないバグのある動作につながる可能性のあるバージョン差異(version skew)が発生するリスクがあります。ただし、kubeletとコントロールプレーン間のマイナーバージョン差異(minor version skew)は_1つ_サポートされていますが、kubeletバージョンがAPIサーバーのバージョンを超えることはできません。たとえば、1.7.0を実行するkubeletは1.8.0 APIサーバーと完全に互換性がありますが、その逆はできません。
+kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない**ため、kubeadmにインストールするKubernetesコントロールプレーンのバージョンと一致させる必要があります。そうしないと、予期しないバグのある動作につながる可能性のあるバージョン差異(version skew)が発生するリスクがあります。ただし、kubeletとコントロールプレーン間のマイナーバージョン差異(minor version skew)は _1つ_ サポートされていますが、kubeletバージョンがAPIサーバーのバージョンを超えることはできません。たとえば、1.7.0を実行するkubeletは1.8.0 APIサーバーと完全に互換性がありますが、その逆はできません。

 `kubectl`のインストールに関する詳細情報は、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。

@@ -133,7 +133,7 @@ journalctl -u docker

 ## `coredns`(もしくは`kube-dns`)が`Pending`状態でスタックする

-kubeadmはネットワークプロバイダに依存しないため、管理者は選択した[Podネットワークソリューションをインストール](/docs/concepts/cluster-administration/addons/)をする必要があります。CoreDNSを完全にデプロイする前にPodネットワークをインストールする必要があります。したがって、ネットワークがセットアップされる前の `Pending`状態になります。
+kubeadmはネットワークプロバイダに依存しないため、管理者は選択した[Podネットワークソリューションをインストール](/ja/docs/concepts/cluster-administration/addons/)をする必要があります。CoreDNSを完全にデプロイする前にPodネットワークをインストールする必要があります。したがって、ネットワークがセットアップされる前の `Pending`状態になります。

 ## `HostPort`サービスが動かない

@@ -241,4 +241,4 @@ spec:
    app: iis-2019
 ```

-[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
+[RuntimeClass]: /ja/docs/concepts/containers/runtime-class/
@@ -86,7 +86,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
  アプリケーション名は、選択したKubernetes[名前空間](/docs/tasks/administer-cluster/namespaces/)内で一意である必要があります。
  小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。

- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。
+- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/ja/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。
  コンテナイメージの指定はコロンで終わらせる必要があります。

  クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
@@ -141,7 +141,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー

  ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。
  Secret名は DNSドメイン名の構文に従う必要があります。たとえば、`new.image-pull.secret`です。
-  Secretの内容はbase64エンコードされ、[`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。
+  Secretの内容はbase64エンコードされ、[`.dockercfg`](/ja/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ファイルで指定されている必要があります。
  Secret名は最大253文字で構成されます。

  イメージプルシークレットの作成に成功した場合は、デフォルトで選択されています。作成に失敗した場合は、シークレットは適用されません。
@@ -606,7 +606,7 @@ very

 ### キーを特定のパスとファイルアクセス許可に投影する

-キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secret](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。
+キーをファイル単位で特定のパスとアクセス許可に投影できます。[Secret](/ja/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)のユーザーガイドで構文が解説されています。

 ### マウントされたConfigMapは自動的に更新される

@@ -621,7 +621,7 @@ ConfigMapを[subPath](/docs/concepts/storage/volumes/#using-subpath)ボリュー

 ## ConfigMapとPodsを理解する

-ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secret](/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。
+ConfigMap APIリソースは構成情報をキーバリューペアとして保存します。データはPodで利用したり、コントローラーなどのシステムコンポーネントに提供できます。ConfigMapは[Secret](/ja/docs/concepts/configuration/secret/)に似ていますが、機密情報を含まない文字列を含まない操作する手段を提供します。ユーザーとシステムコンポーネントはどちらも構成情報をConfigMapに保存できます。

 {{< note >}}
 ConfigMapはプロパティーファイルを参照するべきであり、置き換えるべきではありません。ConfigMapをLinuxの`/etc`ディレクトリとそのコンテンツのように捉えましょう。例えば、[Kubernetes Volume](/docs/concepts/storage/volumes/)をConfigMapから作成した場合、ConfigMapのデータアイテムはボリューム内で個別のファイルとして表示されます。
@@ -109,6 +109,6 @@ spec:
 ## {{% heading "whatsnext" %}}

 * [環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
-* [Secretを環境変数として使用する](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細
+* [Secretを環境変数として使用する](/ja/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細
 * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)をご覧ください。

@@ -40,7 +40,7 @@ Kubernetes Deploymentを作成し、PersistentVolumeClaimを使用して既存
 このファイルは/var/lib/mysqlのボリュームマウントを定義してから、20Gのボリュームを要求するPersistentVolumeClaimを作成します。
 この要求は、要件を満たす既存のボリューム、または動的プロビジョナーによって満たされます。

-注：パスワードはYAMLファイル内に定義されており、これは安全ではありません。安全な解決策については[Kubernetes Secret](/docs/concepts/configuration/secret/)を参照してください 。
+注：パスワードはYAMLファイル内に定義されており、これは安全ではありません。安全な解決策については[Kubernetes Secret](/ja/docs/concepts/configuration/secret/)を参照してください 。

 {{< codenew file="application/mysql/mysql-deployment.yaml" >}}
 {{< codenew file="application/mysql/mysql-pv.yaml" >}}
@@ -40,7 +40,7 @@ kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>

 ### StatefulSetのインプレースアップデート

-コマンドライン上でレプリカ数を変更する代わりに、StatefulSetに[インプレースアップデート](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)が可能です。
+コマンドライン上でレプリカ数を変更する代わりに、StatefulSetに[インプレースアップデート](/ja/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)が可能です。

 StatefulSetが最初に `kubectl apply`で作成されたのなら、StatefulSetマニフェストの`.spec.replicas`を更新してから、`kubectl apply`を実行します:

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

 			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>

-			<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
+			<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/ja/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>

 			<p>各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスターの外部に公開されません。Serviceによって、アプリケーションはトラフィックを受信できるようになります。ServiceSpecで<code>type</code>を指定することで、Serviceをさまざまな方法で公開することができます。</p>
 			<ul>
@@ -75,7 +75,7 @@ Google Kubernetes Engine上で動作するKubernetesクラスターを使って

 ### Secret generatorを追加する

-[Secret](/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。
+[Secret](/ja/docs/concepts/configuration/secret/)とは、パスワードやキーのような機密性の高いデータ片を保存するためのオブジェクトです。バージョン1.14からは、`kubectl`がkustomizationファイルを使用したKubernetesオブジェクトの管理をサポートしています。`kustomization.yaml`内のgeneratorによってSecretを作成することができます。

 以下のコマンドを実行して、`kustomization.yaml`の中にSecret generatorを追加します。`YOUR_PASSWORD`の部分を使いたいパスワードに置換してください。

@@ -367,4 +367,4 @@ DeploymentとServiceを削除すると、実行中のPodも削除されます。
 * [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる
 * Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む
-* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
+* [リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
Author	SHA1	Message	Date
Kubernetes Prow Robot	aee59556cd	Merge pull request #34108 from swagmdy/fix-rbac [ja]fix typo in k8s.io/ja/docs/reference/access-authn-authz/rbac/ #31220	2022-06-02 02:25:47 -07:00
Masuda Yuya	cd90392f2d	fix typo	2022-06-02 14:51:24 +09:00
Kubernetes Prow Robot	9d89a2fc84	Merge pull request #30858 from thekuwayama/fix-links__full-width_parenthesis [ja] fix links and full-width symbols in /ja/docs/concepts/overview/kubernetes-api/	2022-03-24 21:59:51 -07:00
thekuwayama	4beab5d9fe	fix full-width comma to half-width comma	2021-12-11 17:16:50 +09:00
thekuwayama	cb2d7d5583	fix full-width parenthesis to half-width parenthesis fix full-width colons to half-width colons	2021-12-11 15:30:24 +09:00
thekuwayama	438738ebae	modify links using ja-links	2021-12-11 15:29:04 +09:00
thekuwayama	d8aeb64a9f	fix broken links	2021-12-11 15:26:14 +09:00
Kubernetes Prow Robot	c2c1c38a3d	Merge pull request #28646 from oke-py/28645 replace links to /docs/concepts/configuration/pod-priority-preemption/ with /ja/docs/	2021-08-25 00:48:40 -07:00
Kubernetes Prow Robot	88dccbeaa0	Merge pull request #28834 from kaitoii11/fix-link fix syntax for link	2021-07-09 01:00:53 -07:00
Kaito Ii	4459ff5dc1	fix syntax for link	2021-07-07 21:36:52 +09:00
Kubernetes Prow Robot	446e44eed2	Merge pull request #28604 from oke-py/28603 replace links to /docs/concepts/configuration/overview/ with /ja/docs/	2021-07-06 23:24:43 -07:00
Kubernetes Prow Robot	c334482d8e	Merge pull request #28800 from oke-py/28799 replace links to /docs/concepts/containers/runtime-class/ with /ja/docs/	2021-07-05 23:06:17 -07:00
Naoki Oketani	3371788b39	replace links to /docs/concepts/containers/runtime-class/ with /ja/docs/	2021-07-05 20:24:17 +09:00
Kubernetes Prow Robot	5bbe46aa79	Merge pull request #28784 from oke-py/28783 replace links to /docs/concepts/containers/images/ with /ja/docs/	2021-07-04 22:10:19 -07:00
Kubernetes Prow Robot	202979e2de	Merge pull request #28651 from oke-py/28650 replace links to /docs/concepts/configuration/secret/ with /ja/docs/	2021-07-04 22:08:19 -07:00
Naoki Oketani	495bee98b3	replace links to /docs/concepts/containers/images/ with /ja/docs/	2021-07-04 14:32:53 +09:00
Kubernetes Prow Robot	4c1373d255	Merge pull request #28761 from oke-py/28760 replace links to /docs/concepts/containers/container-lifecycle-hooks/ with /ja/docs/	2021-07-02 08:34:13 -07:00
Naoki Oketani	562458a002	replace links to /docs/concepts/containers/container-lifecycle-hooks/ with /ja/docs/	2021-07-02 20:03:55 +09:00
Kubernetes Prow Robot	ab7b6e533c	Merge pull request #28338 from s-kawamura-w664/patch-rbac Updated ja/docs/reference/access-authn-authz/rbac.md	2021-07-02 01:48:12 -07:00
Kubernetes Prow Robot	4010e59984	Merge pull request #28542 from oke-py/28541 replace links to /docs/concepts/configuration/manage-resources-containers/ with /ja/docs/	2021-07-01 20:16:12 -07:00
Naoki Oketani	2edae9006b	replace links to /docs/concepts/configuration/secret/ with /ja/docs/	2021-06-27 19:11:23 +09:00
Naoki Oketani	1243c4a052	replace links to /docs/concepts/configuration/pod-priority-preemption/ with /ja/docs/	2021-06-27 16:12:05 +09:00
Naoki Oketani	6f7863677d	replace links to /docs/concepts/configuration/overview/ with /ja/docs/	2021-06-24 21:17:21 +09:00
s-kawamura-w664	189afdbaaa	Updated ja/docs/reference/access-authn-authz/rbac.md	2021-06-24 06:57:55 +00:00
s-kawamura-w664	ea819b4e78	Updated ja/docs/reference/access-authn-authz/rbac.md	2021-06-24 06:48:43 +00:00
Kubernetes Prow Robot	eebe85a577	Merge pull request #28528 from oke-py/28527 replace links to /docs/concepts/cluster-administration/networking/ with /ja/docs/	2021-06-21 19:29:58 -07:00
Kubernetes Prow Robot	0230830470	Merge pull request #28526 from oke-py/28525 replace links to /docs/concepts/cluster-administration/manage-deployment/ with /ja/docs/	2021-06-21 19:27:57 -07:00
Naoki Oketani	bcf4817a29	replace links to /docs/concepts/configuration/manage-resources-containers/ with /ja/docs/	2021-06-22 07:40:05 +09:00
Naoki Oketani	7869a0fab3	replace links to /docs/concepts/cluster-administration/networking/ with /ja/docs/	2021-06-21 20:42:46 +09:00
Naoki Oketani	033bfc993e	replace links to /docs/concepts/cluster-administration/manage-deployment/ with /ja/docs/	2021-06-21 20:28:52 +09:00
Kubernetes Prow Robot	3e882a206d	Merge pull request #28524 from t-inu/issue28456 [ja] Add precautions about Markdown notation	2021-06-20 22:56:51 -07:00
Toshiaki Inukai	42283c1d6a	Add precautions about Markdown notation	2021-06-21 04:14:07 +00:00
Kubernetes Prow Robot	bcf87d50dd	Merge pull request #28508 from oke-py/28507 replace links to /docs/concepts/cluster-administration/certificates/ with /ja/docs/	2021-06-20 18:10:52 -07:00
Kubernetes Prow Robot	0ac1bbda7b	Merge pull request #28506 from oke-py/28505 replace links to /docs/concepts/cluster-administration/addons/ with /ja/docs/	2021-06-20 18:08:51 -07:00
Kubernetes Prow Robot	d5ea7f4ae6	Merge pull request #28498 from oke-py/28497 replace links to /docs/concepts/architecture/controller/ with /ja/docs/	2021-06-20 18:06:51 -07:00
Kubernetes Prow Robot	e33c5d1f4b	Merge pull request #28433 from t-inu/fix-emphasis-2 [ja] Fix emphasis tags in ja/docs/concepts/workloads/pods/pod-lifecycle.md and so on	2021-06-20 18:04:52 -07:00
Naoki Oketani	56d13a3c3e	replace links to /docs/concepts/cluster-administration/certificates/ with /ja/docs/	2021-06-20 15:28:12 +09:00
Naoki Oketani	834e339c5c	replace links to /docs/concepts/cluster-administration/addons/ with /ja/docs/	2021-06-20 15:21:35 +09:00
Naoki Oketani	58e60ad910	replace links to /docs/concepts/architecture/controller/ with /ja/docs/	2021-06-19 15:02:08 +09:00
Kubernetes Prow Robot	585d4b5e63	Merge pull request #28465 from JIIOryo/28278 Update ja/docs/reference/kubectl/cheatsheet.md	2021-06-17 18:10:04 -07:00
Kubernetes Prow Robot	933c1c667d	Merge pull request #28376 from ystkfujii/dev-1.19-ja.2 [ja] Update OpenID Connect Flow diagram	2021-06-17 17:34:05 -07:00
JIIOryo	dc330260fb	Update ja/docs/reference/kubectl/cheatsheet.md	2021-06-18 09:26:19 +09:00
ystkfujii	6db5418900	Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>	2021-06-17 19:54:56 +09:00
Kubernetes Prow Robot	f900aee8eb	Merge pull request #28414 from s-ito-ts/fix_28272 ja/docs/reference/command-line-tools-reference/feature-gates.md	2021-06-16 17:12:19 -07:00
Kubernetes Prow Robot	814edc4745	Merge pull request #28371 from KobayashiD27/patch-2 ja: Make docs/reference/_index.md follow v1.19 of the original text	2021-06-16 16:46:19 -07:00
Kubernetes Prow Robot	fad7afd424	Merge pull request #28336 from t-inu/issue28276 Update ja/docs/reference/glossary/kubelet.md	2021-06-16 16:44:19 -07:00
Toshiaki Inukai	faaab7460d	Fix emphasis tags	2021-06-16 04:03:32 +00:00
ystkfujii	be26d271d9	Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) <kela@inductor.me>	2021-06-16 08:32:24 +09:00
ystkfujii	b29cd78528	Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) <kela@inductor.me>	2021-06-16 08:32:19 +09:00
ystkfujii	5e765cfb44	Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) <kela@inductor.me>	2021-06-16 08:32:12 +09:00
s-ito-ts	70cc6b75f4	ja/docs/reference/command-line-tools-reference/feature-gates.md	2021-06-14 10:15:05 +00:00
ystkfujii	795647ea0b	Update for PR #28376	2021-06-14 17:23:23 +09:00
ystkfujii	e60cd1c1a6	Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: atoato88 <akihito-inou@nec.com>	2021-06-14 15:51:52 +09:00
Kubernetes Prow Robot	53ff8e5b25	Merge pull request #28339 from KobayashiD27/patch-1 ja: Make docs/reference/glossary/container.md follow v1.19 of the original text	2021-06-12 09:21:00 -07:00
Kubernetes Prow Robot	b92041168e	Merge pull request #28305 from s-kawamura-w664/patch-kubectl Updated ja/docs/reference/kubectl/overview.md	2021-06-12 09:15:00 -07:00
Kubernetes Prow Robot	dbb3a96268	Merge pull request #28322 from t-inu/issue28267 Update ja/docs/contribute/suggesting-improvements.md	2021-06-12 08:25:00 -07:00
ystkfujii	757b1fb9a8	Update for issue #28270	2021-06-12 02:00:18 +09:00
Kobayashi Daisuke	c7b7ccae06	ja: Make docs/reference/_index.md follow v1.19 of the original text	2021-06-11 17:31:38 +09:00
Kobayashi Daisuke	d3c5789d9b	ja: Make docs/reference/glossary/container.md follow v1.19 of the original text	2021-06-09 14:50:13 +09:00
Toshiaki Inukai	12d8f0ca4c	Update for 1.19-ja	2021-06-09 02:01:50 +00:00
Toshiaki Inukai	5d5eaee161	Update for 1.19-ja	2021-06-08 06:39:28 +00:00
s-kawamura-w664	6202d214a1	Updated ja/docs/reference/kubectl/overview.md	2021-06-07 08:50:35 +00:00