chore: trim full-wide space

Update content/ja/docs/concepts/security/rbac-good-practices.md

Update content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md

Co-authored-by: inukai <[email protected]>

Update content/ja/docs/setup/best-practices/certificates.md

Co-authored-by: inukai <[email protected]>

Update content/ja/docs/setup/best-practices/certificates.md

Co-authored-by: inukai <[email protected]>

Update content/ja/docs/setup/best-practices/certificates.md

Co-authored-by: inukai <[email protected]>

Update content/ja/docs/setup/best-practices/certificates.md

Co-authored-by: inukai <[email protected]>

Update content/ja/docs/setup/best-practices/certificates.md

Co-authored-by: inukai <[email protected]>

Update content/ja/docs/setup/best-practices/certificates.md

Co-authored-by: inukai <[email protected]>

Author: Okabe-Junya

content/ja/docs/concepts/overview/working-with-objects/annotations.md

@@ -7,7 +7,6 @@ weight: 60
 <!-- overview -->
 ユーザーは、識別用途でない任意のメタデータをオブジェクトに割り当てるためにアノテーションを使用できます。ツールやライブラリなどのクライアントは、このメタデータを取得できます。
 
-
 <!-- body -->
 ## オブジェクトにメタデータを割り当てる
 
@@ -39,7 +38,7 @@ weight: 60
 
 * 他のエコシステムのコンポーネントからの関連オブジェクトのURLなど、ユーザーやツール、システムの出所情報。
 
-* 軽量ロールアウトツールのメタデータ。　例えば設定やチェックポイントなど。
+* 軽量ロールアウトツールのメタデータ。例えば設定やチェックポイントなど。
 
 * 情報をどこで確認できるかを示すためのもの。例えばチームのウェブサイト、責任者の電話番号や、ページャー番号やディレクトリエンティティなど。
 

content/ja/docs/concepts/overview/working-with-objects/namespaces.md

@@ -9,9 +9,6 @@ weight: 45
 Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。
 この仮想クラスターをNamespaceと呼びます。
 
-
-
-
 <!-- body -->
 
 ## 複数のNamespaceを使う時
@@ -32,7 +29,7 @@ Namespaceは、複数のユーザーの間でクラスターリソースを分
 Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。
 
 {{< note >}}
-　　プレフィックス`kube-`を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。
+プレフィックス`kube-`を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。
 {{< /note >}}
 
 ### Namespaceの表示

content/ja/docs/concepts/scheduling-eviction/pod-overhead.md

@@ -8,19 +8,15 @@ weight: 30
 
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
-
 PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。
 
-
-
-
 <!-- body -->
 
 Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。
 
 Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。
 
-## Podのオーバーヘッドの有効化　{#set-up}
+## Podのオーバーヘッドの有効化 {#set-up}
 
 クラスター全体で`PodOverhead`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっていること（1.18時点ではデフォルトでオンになっています）と、`overhead`フィールドを定義する`RuntimeClass`が利用されていることを確認する必要があります。
 

content/ja/docs/concepts/scheduling-eviction/scheduling-framework.md

@@ -97,7 +97,7 @@ NormalizeScoreプラグインが途中でエラーを返した場合、Schedulin
 
 ### Reserve {#reserve}
 
-Reserve拡張を実装したプラグインには、ReserveとUnreserve　という2つのメソッドがあり、それぞれ`Reserve`
+Reserve拡張を実装したプラグインには、ReserveとUnreserveという2つのメソッドがあり、それぞれ`Reserve`
 と`Unreserve`と呼ばれる2つの情報スケジューリングフェーズを返します。
 実行状態を保持するプラグイン（別名「ステートフルプラグイン」）は、これらのフェーズを使用して、Podに対してNodeのリソースが予約されたり予約解除された場合に、スケジューラーから通知を受け取ります。
 

content/ja/docs/concepts/security/rbac-good-practices.md

@@ -63,7 +63,7 @@ Kubernetesは、すべてのクラスターに必要とは限らないアクセ
 冗長なエントリや特権昇格の可能性がないか、定期的にKubernetes RBAC設定を確認することが不可欠です。
 攻撃者が削除されたユーザーと同じ名前のユーザーアカウントを作成できる場合、特にそのユーザーに割り当てられた権限を自動的に継承できます。
 
-## Kubernetes RBAC - 特権昇格リスク　{#privilege-escalation-risks}
+## Kubernetes RBAC - 特権昇格リスク {#privilege-escalation-risks}
 
 Kubernetes RBAC内には、ユーザーやサービスアカウントがクラスター内で特権昇格したり、クラスター外のシステムに影響を与えたりすることができる権限がいくつかあります。
 

content/ja/docs/concepts/workloads/autoscaling.md

@@ -57,7 +57,7 @@ HPAと異なり、VPAはデフォルトでKubernetesに付属していません
 HPAが機能するにはクラスターに[Metrics Server](https://github.com/kubernetes-sigs/metrics-server)がインストールされている必要があります。
 {{< /note >}}
 
-現時点では、VPAは4つの異なるモードで動作できます:　
+現時点では、VPAは4つの異なるモードで動作できます:
 
 {{< table caption="VPAの異なるモード" >}}
 モード | 説明

content/ja/docs/concepts/workloads/controllers/job.md

@@ -249,7 +249,7 @@ Jobで実行するのに適したタスクは主に3種類あります:
 - `Indexed`: Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
   - Podアノテーション`batch.kubernetes.io/job-completion-index`。
   - Podホスト名の一部として、`$(job-name)-$(index)`の形式になっています。
-    インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。この設定方法の詳細は[Pod間通信を使用したJob](https://kubernetes.io/docs/tasks/job/job-with-pod-to-pod-communication/)を参照してください。　
+    インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。この設定方法の詳細は[Pod間通信を使用したJob](https://kubernetes.io/docs/tasks/job/job-with-pod-to-pod-communication/)を参照してください。
   - コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`。
 
   各インデックスに1つずつ正常に完了したPodがあると、Jobは完了したとみなされます。このモードの使い方については、[静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。
@@ -433,11 +433,11 @@ Jobオブジェクトは、Podの確実な並列実行をサポートするた
 並列計算にはいくつかのパターンがあり、それぞれに長所と短所があります。
 トレードオフの関係にあるのは:
 
-- 各作業項目に1つのJobオブジェクト vs. すべての作業項目に1つのJobオブジェクト。  
-　後者は大量の作業項目を処理する場合に適しています。  
-　前者は大量のJobオブジェクトを管理するため、ユーザーとシステムにオーバーヘッドをかけることになります。
+- 各作業項目に1つのJobオブジェクト vs. すべての作業項目に1つのJobオブジェクト。
+後者は大量の作業項目を処理する場合に適しています。
+前者は大量のJobオブジェクトを管理するため、ユーザーとシステムにオーバーヘッドをかけることになります。
 - 作成されるPod数が作業項目数と等しい、 vs. 各Podが複数の作業項目を処理する。
-　前者は通常、既存のコードやコンテナへの変更が少なくて済みます。
+前者は通常、既存のコードやコンテナへの変更が少なくて済みます。
   後者は上記と同じ理由で、大量の作業項目を処理する場合に適しています。
 - ワークキューを利用するアプローチもいくつかあります。それを使うためには、キューサービスを実行し、既存のプログラムやコンテナにワークキューを利用させるための改造を行う必要があります。
   他のアプローチは既存のコンテナ型アプリケーションに適用しやすいです。

content/ja/docs/reference/access-authn-authz/rbac.md

@@ -7,7 +7,6 @@ weight: 70
 <!-- overview -->
 Role Based Access Control(RBAC)は、組織内の個々のユーザーのRoleをベースに、コンピューターまたはネットワークリソースへのアクセスを制御する方法です。
 
-
 <!-- body -->
 RBAC認可は{{< glossary_tooltip term_id="api-group" >}} `rbac.authorization.k8s.io`を使用して認可の決定を行い、Kubernetes APIを介して動的にポリシーを構成できるようにします。
 
@@ -195,7 +194,7 @@ Bindingの`roleRef`を変更しようとすると、バリデーションエラ
 
 KubernetesのAPIでは、ほとんどのリソースはPodであれば`pods`のように、オブジェクト名の文字列表現を使用して表されます。RBACは、関連するAPIエンドポイントのURLに表示されるものとまったく同じ名前を使用するリソースを参照します。
 一部のKubernetes APIには、Podのログなどの
-_subresource_　が含まれます。Podのログのリクエストは次のようになります。
+_subresource_ が含まれます。Podのログのリクエストは次のようになります。
 
 ```http
 GET /api/v1/namespaces/{namespace}/pods/{name}/log

content/ja/docs/reference/glossary/api-eviction.md

@@ -4,7 +4,7 @@ id: api-eviction
 date: 2021-04-27
 full_link: /ja/docs/concepts/scheduling-eviction/api-eviction/
 short_description: >
-  APIを起点とした退避は、Eviction　APIを使用してEvictionオブジェクトを作成し、Podの正常終了を起動させるプロセスです。
+  APIを起点とした退避は、Eviction APIを使用してEvictionオブジェクトを作成し、Podの正常終了を起動させるプロセスです。
 aka:
 tags:
 - operation

content/ja/docs/setup/best-practices/certificates.md

@@ -50,11 +50,11 @@ kubeadmを使用してKubernetesをインストールする場合、ほとんど
 
 必要な認証局:
 
-| パス                    | デフォルトCN                | 説明                             |
+| パス                   | デフォルトCN              | 説明                             |
 |------------------------|---------------------------|----------------------------------|
-| ca.crt,key             | kubernetes-ca             | Kubernetes全体の認証局　　　        |
-| etcd/ca.crt,key        | etcd-ca                   | etcd用　　　　　　　　　　　　　　   |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用　　　 |
+| ca.crt,key             | kubernetes-ca             | Kubernetes全体の認証局           |
+| etcd/ca.crt,key        | etcd-ca                   | etcd用                           |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用 |
 
 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。
 次の例は、前の表で示されたCAのキーと証明書を示しています:
@@ -74,7 +74,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
 
 必要な証明書:
 
-| デフォルトCN                    | 親認証局                   | 組織 　　　　　　| 種類                                   | ホスト名 (SAN)                                          |
+| デフォルトCN                  | 親認証局                  | 組織           | 種類                                   | ホスト名 (SAN)                                      |
 |-------------------------------|---------------------------|----------------|----------------------------------------|-----------------------------------------------------|
 | kube-etcd                     | etcd-ca                   |                | server, client                         | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
 | kube-etcd-peer                | etcd-ca                   |                | server, client                         | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
@@ -93,7 +93,7 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
 
 ここで`種類`は、一つまたは複数のx509の鍵用途にマッピングされており、これは[CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest)の`.spec.usages`にも記載されています:
 
-| 種類   | 鍵の用途  　　　                                                                     |
+| 種類   | 鍵の用途                                                                        |
 |--------|---------------------------------------------------------------------------------|
 | server | digital signature, key encipherment, server auth                                |
 | client | digital signature, key encipherment, client auth                                |
@@ -116,7 +116,7 @@ kubeadm利用者のみ:
 証明書は推奨パスに配置するべきです([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様)。
 パスは場所に関係なく与えられた引数で特定されます。
 
-| デフォルトCN                   | 鍵の推奨パス        　　　　　　 | 証明書の推奨パス    　　　　　   | コマンド        | 鍵を指定する引数               | 証明書を指定する引数                          |
+| デフォルトCN                 | 鍵の推奨パス                 | 証明書の推奨パス            | コマンド       | 鍵を指定する引数             | 証明書を指定する引数                      |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
 | etcd-ca                      |     etcd/ca.key                         | etcd/ca.crt                 | kube-apiserver |                              | --etcd-cafile                             |
 | kube-apiserver-etcd-client                  | apiserver-etcd-client.key    | apiserver-etcd-client.crt   | kube-apiserver | --etcd-keyfile               | --etcd-certfile                           |
@@ -135,7 +135,7 @@ kubeadm利用者のみ:
 
 サービスアカウント用の鍵ペアについても同様です。
 
-| 秘密鍵のパス 　　　　            |　公開鍵のパス 　　　           | コマンド                 | 引数                             |
+| 秘密鍵のパス                 |公開鍵のパス                 | コマンド                | 引数                                 |
 |------------------------------|-----------------------------|-------------------------|--------------------------------------|
 |  sa.key                      |                             | kube-controller-manager | service-account-private              |
 |                              | sa.pub                      | kube-apiserver          | service-account-key                  |