remove ctrl-h (#19067)

kubernetes · Feb 12, 2020 · c6dd3dd · c6dd3dd
1 parent 03ba254
commit c6dd3dd
Show file tree

Hide file tree

Showing 7 changed files with 9 additions and 9 deletions.
diff --git a/content/ja/docs/concepts/configuration/assign-pod-node.md b/content/ja/docs/concepts/configuration/assign-pod-node.md
@@ -83,7 +83,7 @@ nodeSelectorを以下のように追加します:
 
 ## Nodeの隔離や制限
 Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。
-これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。
+これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。
 この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。
 これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。
 

diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md
@@ -116,7 +116,7 @@ spec:
 
 ### *集合ベース(Set-based)* の要件(requirement)
 
-*集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。  
+*集合ベース(Set-based)* のラベルの要件は値のセットによってキーをフィルタリングします。  
 `in`、`notin`、`exists`の3つのオペレーターをサポートしています(キーを特定するのみ)。    
 
 例えば:  

diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md
@@ -13,7 +13,7 @@ weight: 40
 
 ## 用語
 
-まずわかりやすくするために、このガイドでは次の用語を定義します。
+まずわかりやすくするために、このガイドでは次の用語を定義します。
 
 - ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
 
@@ -86,7 +86,7 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/
 
 * オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
 * パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
-* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
+* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
 
 Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
 

diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md
@@ -105,7 +105,7 @@ nodeAffinity:
 
 さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。
 
-### TaintsとTolerations
+### TaintsとTolerations
 
 DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。  
 下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。

diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md
@@ -28,7 +28,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 
 下記の項目はDeploymentの典型的なユースケースです。
 
-* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。  
+* ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。  
 * DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
 * Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
 * より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する

diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -26,7 +26,7 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs
 TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。  
 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。
 
-TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
+TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
 
 * Jobがその終了後にいくつか時間がたった後に自動的にクリーンアップできるように、そのリソースマニフェストにこの値を指定します。
 * この新しい機能を適用させるために、存在していて既に終了したリソースに対してこのフィールドをセットします。

diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md
@@ -8,7 +8,7 @@ weight: 30
 
 このページでは、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
 コントローラーを使用して、レプリカを持つステートフルアプリケーションを実行する方法を説明します。
-ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。
+ここでの例は、非同期レプリケーションを行う複数のスレーブを持つ、単一マスターのMySQLです。
 
 **この例は本番環境向けの構成ではない**ことに注意してください。
 具体的には、MySQLの設定が安全ではないデフォルトのままとなっています。
@@ -76,7 +76,7 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
 {{< codenew file="application/mysql/mysql-services.yaml" >}}
 
 ヘッドレスサービスは、StatefulSetコントローラーが
-StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
+StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
 この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの
 同じ名前空間内の他のPodは、`<pod-name>.mysql`を名前解決することでPodにアクセスできます。