Merge pull request #38266 from atoato88/sync-with-japanese-traslation-rule

Conform to the ja translation rule about Controller

Author: k8s-ci-robot

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

@@ -62,7 +62,7 @@ weight: 10
 
 セレクターからリリース固有のラベルを省略することで、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/overview/working-with-objects/labels.md

@@ -94,7 +94,7 @@ Kubernetes APIは現在2タイプのセレクターをサポートしていま
 そしてセレクターを使うAPIタイプは、それらのセレクターの妥当性とそれらが示す意味をドキュメントに記載するべきです。
 
 {{< note >}}
-ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
+ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラーがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
 {{< /note >}}
 
 {{< caution >}}

content/ja/docs/concepts/services-networking/network-policies.md

@@ -210,7 +210,7 @@ Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存
 Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下のユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。
 
 - クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。
-- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。
+- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラーを使用します)。
 - ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。
 - 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。
 - サードパーティによって実行される「ポリシー要求」の作成または管理

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

@@ -707,7 +707,7 @@ Secretsの内容を読み取るとNamespaceのServiceAccountのクレデンシ
 Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}}は、Kubernetesコントロールプレーンに組み込まれている{{< glossary_tooltip term_id="controller" text="controllers" >}}を実行します。
 `--use-service-account-credentials`を指定して呼び出すと、kube-controller-manager個別のサービスアカウントを使用して各コントローラーを起動します。
 組み込みコントローラーごとに、プレフィックス`system:controller:`付きの対応するRoleが存在します。
-コントローラーマネージャーが`--use-service-account-credentials`で開始されていない場合、コントローラマネージャーは、関連するすべてのRoleを付与する必要がある自身のクレデンシャルを使用して、すべてのコントロールループを実行します。
+コントローラーマネージャーが`--use-service-account-credentials`で開始されていない場合、コントローラーマネージャーは、関連するすべてのRoleを付与する必要がある自身のクレデンシャルを使用して、すべてのコントロールループを実行します。
 これらのRoleは次のとおりです。
 
 * `system:controller:attachdetach-controller`

content/ja/docs/reference/using-api/_index.md

@@ -101,7 +101,7 @@ APIサーバー上で`--runtime-config`を設定することで、有効にし
 
 {{< note >}}
 グループやリソースを有効または無効にした場合、
-APIサーバーとコントローラマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。
+APIサーバーとコントローラーマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。
 {{< /note >}}
 
 ## 永続化

content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md

@@ -277,7 +277,7 @@ yum install docker-ce-18.06.1.ce-3.el7.x86_64
 
 ## cloud-controller-managerによってノードが初期化される前にkube-proxyがスケジューリングされる
 
-クラウドプロバイダのシナリオでは、クラウドコントローラマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。
+クラウドプロバイダのシナリオでは、クラウドコントローラーマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。
 
 kube-proxy Podsでは以下のようなエラーが発生します:
 ```
@@ -345,4 +345,4 @@ nodeRegistration:
 ## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
 このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
 
-この問題はバージョン1.19で修正されます。
+この問題はバージョン1.19で修正されます。

content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md

@@ -66,7 +66,7 @@ Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能し
   * リソース制限
 * [Controllers](/ja/docs/concepts/workloads/controllers/)
 
-    Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。:
+    Kubernetesコントローラーは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。:
 
   * ReplicaSet
   * ReplicationController

content/ja/docs/tasks/debug/debug-cluster/_index.md

@@ -60,13 +60,13 @@ kubectl cluster-info dump
 ### 具体的なシナリオ
 
   - apiserver VMのシャットダウンまたはapiserverのクラッシュ
-    - 新しいPod、サービス、レプリケーションコントローラの停止、更新、起動ができない
+    - 新しいPod、サービス、レプリケーションコントローラーの停止、更新、起動ができない
     - Kubernetes APIに依存していない限り、既存のPodやサービスは正常に動作し続けるはずです
   - apiserverのバックアップストレージが失われた
     - apiserverが立ち上がらない
     - kubeletsは到達できなくなりますが、同じPodを実行し、同じサービスのプロキシを提供し続けます
     - apiserverを再起動する前に、手動でapiserverの状態を回復または再現する必要がある
-  - サポートサービス(ノードコントローラ、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ
+  - サポートサービス(ノードコントローラー、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ
     - 現在、これらはapiserverとコロケーションしており、使用できない場合はapiserverと同様の影響があります
     - 将来的には、これらも複製されるようになり、同じ場所に配置されない可能性があります
     - 独自の永続的な状態を持っていない。

content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -6,7 +6,7 @@ weight: 100
 
 <!-- overview -->
 
-Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラ内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせます。
+Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラー内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせます。
 
 このドキュメントはphp-apacheサーバーに対しHorizontal Pod Autoscalerを有効化するという例に沿ってウォークスルーで説明していきます。Horizontal Pod Autoscalerの動作についてのより詳細な情報を知りたい場合は、[Horizontal Pod Autoscalerユーザーガイド](/docs/tasks/run-application/horizontal-pod-autoscale/)をご覧ください。
 

content/ja/docs/tutorials/stateful-application/basic-stateful-set.md

@@ -492,7 +492,7 @@ web-0     1/1       Running   0         10s
 
 StatefulSet内のPodは、順序インデックスの逆順に更新されました。StatefulSetコントローラーは各Podを終了させ、次のPodを更新する前に、新しいPodがRunningかつReadyの状態に変わるまで待機します。ここで、StatefulSetコントローラーは順序インデックスの前のPodがRunningかつReadyの状態になるまで次のPodの更新を始めず、現在の状態へのアップデートに失敗したPodがあった場合、そのPodをリストアすることに注意してください。
 
-すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。
+すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラーはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。
 
 Podを取得して、コンテナイメージを確認してみましょう。