Merge pull request #28299 from bells17/fix-em-tags

Fix em tags

Author: k8s-ci-robot

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

@@ -237,7 +237,7 @@ kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラ
 
 ### ローカルのエフェメラルストレージの要求と制限設定
 
-ローカルのエフェメラルストレージを管理するためには_ephemeral-storage_パラメーターを利用することができます。
+ローカルのエフェメラルストレージを管理するためには _ephemeral-storage_ パラメーターを利用することができます。
 Podの各コンテナは、次の1つ以上を指定できます。
 * `spec.containers[].resources.limits.ephemeral-storage`
 * `spec.containers[].resources.requests.ephemeral-storage`

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

@@ -58,11 +58,11 @@ weight: 10
 
 ## ラベルの使用
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
 
 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
 
-オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
+オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
 
 - デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。
 

content/ja/docs/concepts/containers/runtime-class.md

@@ -140,7 +140,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
+Podが稼働する時に関連する _オーバーヘッド_ リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
 Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)
 
 PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。

content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -83,7 +83,7 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
 Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。
 
-1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。
+1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。
 2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
 

content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -26,11 +26,11 @@ kube-schedulerは、もし希望するのであれば自分自身でスケジュ
 kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。
 しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。
 
-クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。
+クラスター内でPodに対する割り当て要求を満たしたNodeは _割り当て可能_ なNodeと呼ばれます。
 もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。
 
 スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。
-スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
+スケジューラーは _binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
 
 スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。
 
@@ -52,7 +52,7 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
 
 スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。
 
-1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための_Predicates_とスコアリングのための_Priorities_の設定することができます。
+1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。
 1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。
 
 

content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -55,7 +55,7 @@ kubectl proxy
 
 kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。
 
-UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。
+UIはコマンドを実行しているマシンから _のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。
 
 {{< note >}}
 Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。