diff --git a/README-ja.md b/README-ja.md index 30983de78a..70d508d01a 100644 --- a/README-ja.md +++ b/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を編集し、フィードバックに対応するのはあなたの責任です。** diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index 623b9e3041..cb66cdb8cb 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/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が保証されます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index b3f87105d9..e1cffc45f5 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/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 diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index 89e8b3f7b8..0cdae70bd1 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/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の総数。 | diff --git a/content/ja/docs/reference/using-api/deprecation-policy.md b/content/ja/docs/reference/using-api/deprecation-policy.md index b1df9121eb..b2cef343f6 100644 --- a/content/ja/docs/reference/using-api/deprecation-policy.md +++ b/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 >}} diff --git a/content/ja/docs/setup/production-environment/_index.md b/content/ja/docs/setup/production-environment/_index.md index 84d84ccd18..23b29650f2 100644 --- a/content/ja/docs/setup/production-environment/_index.md +++ b/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サーバーへアドミッションコントローラーを追加し有効化される必要があります。 diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md index 2697c0e0fe..0d498709e2 100644 --- a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/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のアドレスを発見できるようになります。