From 7b4b91831ed1b7d3cf2eef440762cb49ce2781ba Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:33:14 +0900 Subject: [PATCH 1/6] Fix em tags: content/ja/docs/concepts/configuration/manage-resources-containers.md --- .../docs/concepts/configuration/manage-resources-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index bb2ccb7c20..0d59ecd319 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/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` From 20c11beb32172ffe9e5169d938585d0d9ad65e90 Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:35:43 +0900 Subject: [PATCH 2/6] Fix em tags: content/ja/docs/concepts/configuration/overview.md --- content/ja/docs/concepts/configuration/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 5f2fd15120..ee63e066d8 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/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)を使います。 From 1a337324553fd60b64d88bb3cd27f6c046e9ac5b Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:36:59 +0900 Subject: [PATCH 3/6] Fix em tags: content/ja/docs/concepts/containers/runtime-class.md --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 67334995eb..bc4e285c66 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/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`フィールドによって定義されます。 From 8c4b1d3e86256611cc636e6d21809a6c613f56cb Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:38:15 +0900 Subject: [PATCH 4/6] Fix em tags: content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index c1c0c95b6d..6bc7af0dab 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/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`のようなラベルです。 From f0c13220f181f71adc290f7116b6a46798664e7b Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:40:13 +0900 Subject: [PATCH 5/6] Fix em tags: content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md --- .../ja/docs/concepts/scheduling-eviction/kube-scheduler.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index 9f2b86a425..cbd833ba3d 100644 --- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/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を異なるプロファイルを実行するように設定することもできます。 From edac091e452d7df998cedb3f8956f326f38bca24 Mon Sep 17 00:00:00 2001 From: bells17 Date: Sun, 6 Jun 2021 18:42:20 +0900 Subject: [PATCH 6/6] Fix em tags: content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 8235e113ae..ba78ba15fa 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/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証明書ベースの認証には対応していません。