Kubernetes Prow Robot
GitHub
commit
181cdb0f1d
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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)を使います。
|
||||
|
||||
|
|
|
|||
|
|
@ -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`フィールドによって定義されます。
|
||||
|
|
|
|||
|
|
@ -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`のようなラベルです。
|
||||
|
||||
|
|
|
|||
|
|
@ -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を異なるプロファイルを実行するように設定することもできます。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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証明書ベースの認証には対応していません。
|
||||
|
|
|
|||
Loading…
Reference in New Issue