Merge pull request #48064 from SpiffyEight77/docs/fix-typos

[ja] fix some typos in documentation

README-ja.md

@@ -169,7 +169,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 
 ## ドキュメントに貢献する {#contributing-to-the-docs}
 
-GitHubの画面右上にある**Fork**ボタンをクリックすると、GitHubアカウントに紐付いた本リポジトリのコピーが作成されます。このコピーのことを*フォーク*と呼びます。フォークリポジトリの中では好きなように変更を加えることができます。加えた変更をこのリポジトリに反映したい好きなタイミングで、フォークリポジトリからPull Reqeustを作成してください。
+GitHubの画面右上にある**Fork**ボタンをクリックすると、GitHubアカウントに紐付いた本リポジトリのコピーが作成されます。このコピーのことを*フォーク*と呼びます。フォークリポジトリの中では好きなように変更を加えることができます。加えた変更をこのリポジトリに反映したい好きなタイミングで、フォークリポジトリからPull Requestを作成してください。
 
 Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。Pull Requestの所有者は作成者であるため、**自分自身で作成したPull Requestを編集し、フィードバックに対応するのはあなたの責任です。**
 

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

@@ -73,7 +73,7 @@ Podの各コンテナは、次の1つ以上を指定できます。
 ### CPUの意味 {#meaning-of-cpu}
 
 CPUリソースの制限と要求は、*cpu*単位で測定されます。
-Kuberenetesにおける1つのCPUは、クラウドプロバイダーの**1 vCPU/コア**およびベアメタルのインテルプロセッサーの**1 ハイパースレッド**に相当します。
+Kubernetesにおける1つのCPUは、クラウドプロバイダーの**1 vCPU/コア**およびベアメタルのインテルプロセッサーの**1 ハイパースレッド**に相当します。
 
 要求を少数で指定することもできます。
 `spec.containers[].resources.requests.cpu`が`0.5`のコンテナは、1CPUを要求するコンテナの半分のCPUが保証されます。

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

@@ -44,7 +44,7 @@ kubectl get services  --all-namespaces --field-selector metadata.namespace!=defa
 
 ## 連結されたセレクター
 [ラベル](/docs/concepts/overview/working-with-objects/labels)や他のセレクターと同様に、フィールドセレクターはコンマ区切りのリストとして連結することができます。  
-下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。  
+下記の`kubectl`コマンドは、`status.phase`が`Running`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。  
 
 ```shell
 kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

content/ja/docs/concepts/policy/resource-quotas.md

@@ -136,7 +136,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
 | `configmaps` | 名前空間内で存在可能なConfigMapの総数。  |
 | `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
 | `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。  |
-| `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 |
+| `replicationcontrollers` | 名前空間内で存在可能なReplicationControllerの総数。 |
 | `resourcequotas` | 名前空間内で存在可能なResourceQuotaの総数。 |
 | `services` | 名前空間内で存在可能なServiceの総数。 |
 | `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 |

content/ja/docs/reference/using-api/deprecation-policy.md

@@ -45,7 +45,7 @@ APIの要素が特定バージョンのAPIグループに追加されると、
 大幅に挙動が変更されることはありません。
 
 {{< note >}}
-歴史的な理由により、「core」(グループ名なし)と「extentions」という2つの「monolithic」APIグループがあります。
+歴史的な理由により、「core」(グループ名なし)と「extensions」という2つの「monolithic」APIグループがあります。
 リソースはこれらのレガシーなAPIグループからより特定のドメインに特化したAPIグループに段階的に移行されます。
 {{< /note >}}
 

content/ja/docs/setup/production-environment/_index.md

@@ -84,7 +84,7 @@ no_list: true
 
 プロダクション用のKubernetesクラスターの認証認可をセットアップするにあたって、いくつかの考慮事項があります。
 
-- *認証モードの設定*: Kubermetes APIサーバー ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))の起動時に、*--authorization-mode*フラグを使用しサポートされた認証モードを設定しなければいけません。例えば、*/etc/kubernetes/manifests*配下の*kube-adminserver.yaml*ファイルで*--authorization-mode*フラグにNodeやRBACを設定することで、認証されたリクエストに対してノードやRBACの認証を許可することができます。
+- *認証モードの設定*: Kubernetes APIサーバー ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))の起動時に、*--authorization-mode*フラグを使用しサポートされた認証モードを設定しなければいけません。例えば、*/etc/kubernetes/manifests*配下の*kube-adminserver.yaml*ファイルで*--authorization-mode*フラグにNodeやRBACを設定することで、認証されたリクエストに対してノードやRBACの認証を許可することができます。
 - *ユーザー証明書とロールバインディングの作成(RMAC)*: RBAC認証を使用している場合、ユーザーはクラスター証明機関により署名された証明書署名要求(CSR)を作成でき、各ユーザーにRolesとClusterRolesをバインドすることができます。詳細は[証明書署名要求](/docs/reference/access-authn-authz/certificate-signing-requests/)をご覧ください。
 - *属性を組み合わせたポリシーの作成(ABAC)*: ABAC認証を使用している場合、特定のリソース（例えばPod）、Namespace、またはAPIグループにアクセスするために、選択されたユーザーやグループに属性の組み合わせで形成されたポリシーを割り当てることができます。より多くの情報は[Examples](/docs/reference/access-authn-authz/abac/#examples)をご覧ください。
 - *アドミッションコントローラーの考慮事項*: APIサーバーを経由してくるリクエストのための追加の認証形式に[Webhookトークン認証](/ja/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)があります。Webhookや他の特別な認証形式はAPIサーバーへアドミッションコントローラーを追加し有効化される必要があります。

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

@@ -229,7 +229,7 @@ Address 1: 10.244.2.8
 
 Podの順序インデックス、ホスト名、SRVレコード、そしてAレコード名は変化していませんが、Podに紐付けられたIPアドレスは変化する可能性があります。このチュートリアルで使用しているクラスターでは、IPアドレスは変わりました。このようなことがあるため、他のアプリケーションがStatefulSet内のPodに接続するときには、IPアドレスで指定しないことが重要です。
 
-StatefulSetの有効なメンバーを探して接続する必要がある場合は、headless ServiceのCNAME(`nginx.default.svc.cluster.local`)をクエリしなければなりません。CNAMEに紐付けられたSRVレコードには、StatefulSet内のRunnningかつReadyなPodだけが含まれます。
+StatefulSetの有効なメンバーを探して接続する必要がある場合は、headless ServiceのCNAME(`nginx.default.svc.cluster.local`)をクエリしなければなりません。CNAMEに紐付けられたSRVレコードには、StatefulSet内のRunningかつReadyなPodだけが含まれます。
 
 アプリケーションがlivenessとreadinessをテストするコネクションのロジックをすでに実装している場合、PodのSRVレコード(`web-0.nginx.default.svc.cluster.local`、`web-1.nginx.default.svc.cluster.local`)をPodが安定しているものとして使用できます。PodがRunning and Readyな状態に移行すれば、アプリケーションはPodのアドレスを発見できるようになります。