From 26ceb76eb92731fe3c8cca06e16c655dba9c8c99 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Sun, 24 May 2020 01:15:31 +0900 Subject: [PATCH 1/6] ja-trans: Translate concepts/policy/resource-quotas.md into Japanese #19282 --- content/ja/docs/concepts/policy/_index.md | 5 + .../docs/concepts/policy/resource-quotas.md | 554 ++++++++++++++++++ 2 files changed, 559 insertions(+) create mode 100755 content/ja/docs/concepts/policy/_index.md create mode 100644 content/ja/docs/concepts/policy/resource-quotas.md diff --git a/content/ja/docs/concepts/policy/_index.md b/content/ja/docs/concepts/policy/_index.md new file mode 100755 index 0000000000..1fa1c815ba --- /dev/null +++ b/content/ja/docs/concepts/policy/_index.md @@ -0,0 +1,5 @@ +--- +title: "リソースのポリシー" +weight: 90 +--- + diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md new file mode 100644 index 0000000000..e11feb50c7 --- /dev/null +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -0,0 +1,554 @@ +--- +reviewers: +title: リソースクォータ +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +複数のユーザーやチームが決められた数のノードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきます。 + +リソースクォータはこの問題に対処するための管理者向けツールです。 + +{{% /capture %}} + + +{{% capture body %}} + +`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。 + +リソースクォータは下記のように働きます。 + +- 異なる名前空間のクラスターで異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 +- 管理者は各名前空間において1つの`ResourceQuota`を作成します。 +- ユーザーが名前空間内でリソース(Pod, Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードウェアリソースのリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 +- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 +- `cpu`や`memory`といったコンピューターリソース対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を教養するために、`LimitRanger`という管理コントローラーを使用してください。この問題を解決する例は[walkthrough](/ja/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 + +名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 + +- 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。 +- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかける。 "production"という名前空間は制限をかけない。 + +クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。 + +リソースの競合もクォータの変更も、作成済みのリソースには影響しません。 + +## リソースクォータを有効にする + +多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときも有効になります。 + +特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその特定の名前空間に適用されます。 + +## リソースクォータの計算 + +特定の名前空間において、[コンピュートリソース](/ja/docs/user-guide/compute-resources)の合計に上限を設定できます。 + +下記のリソースタイプがサポートされています。 + + +| リソース名 | 説明 | +| --------------------- | ----------------------------------------------------------- | +| `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 | +| `limits.memory` | 停止していない状態の全てのPodで、メモリの合計がこの値を超えることができません。 | +| `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 | +| `requests.memory` | 停止していない状態の全てのPodで、メモリリクエストの合計がこの値を超えることができません。 | + +### 拡張リソースのためのリソースクォータ + +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/ja/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 + +拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 + +GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で、ユーザーが名前空間内でリクエストされるGPUの上限を4に指定するとき、下記のようにリソースクォータを定義します。 + +* `requests.nvidia.com/gpu: 4` + +さらなる詳細は[リソースクォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 + + +## ストレージのリソースクォータ + +特定の名前空間において[ストレージリソース](/ja/docs/concepts/storage/persistent-volumes/)の総数に上限をかけることができます。 + +さらに、関連するストレージクラスに基づいて、ストレージリソースの消費量に上限をかけることもできます。 + +| リソース名 | 説明 | +| --------------------- | ----------------------------------------------------------- | +| `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 | +| `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | +| `.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | + +例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。 + +* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` +* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` + +Kubernetes v1.8において、ローカルのエフェメラルストレージに対するリソースクォータのサポートがα版の機能として追加されました。 + +| リソース名 | 説明 | +| ------------------------------- |----------------------------------------------------------- | +| `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 | +| `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 | + +## オブジェクト数に対するクォータ Object Count Quota + +Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。 + +* `count/.` + +オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。 + +* `count/persistentvolumeclaims` +* `count/services` +* `count/secrets` +* `count/configmaps` +* `count/replicationcontrollers` +* `count/deployments.apps` +* `count/replicasets.apps` +* `count/statefulsets.apps` +* `count/jobs.batch` +* `count/cronjobs.batch` +* `count/deployments.extensions` + +Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 + +`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります!また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 + +Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。 + +下記のタイプのリソースがサポートされています。 + +| リソース名 | 説明 | +| ------------------------------- | ------------------------------------------------- | +| `configmaps` | 名前空間内で存在可能なConfigMapの総数。 | +| `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | +| `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 | +| `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 | +| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/ja/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | +| `services` | 名前空間内で存在可能なServiceの総数。 | +| `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 | +| `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 | +| `secrets` | 名前空間内で存在可能なSecretの総数。 | + +例えば、`Pod`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`Pod`のリソースクォータを設定したい場合があります。 + +## クォータのスコープについて + +各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。 + +スコープがリソースクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセットに以外のリソースクォータ上でリソースを指定するとバリデーションエラーになります。 + +| スコープ | 説明 | +| ----- | ----------- | +| `Terminating` | `.spec.activeDeadlineSeconds >= 0`であるPodに一致します。 | +| `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 | +| `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 | +| `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 | + +`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `Pod` + +`Terminating`, `NotTerminating`, `NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: + +* `cpu` +* `limits.cpu` +* `limits.memory` +* `memory` +* `pods` +* `requests.cpu` +* `requests.memory` + +### PriorityClass毎のリソースクォータ + +{{< feature-state for_k8s_version="1.12" state="beta" >}} + +Podは特定の[Podの優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 + +リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。 + +この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。 + +- クラスター内のPodは3つの優先度クラスのうち1つをもちます。それは"low", "medium", "high"です。 +- 1つのリソースクォータのオブジェクトは優先度毎に作成されます。 + +下記のYAMLを`quota.yml`というファイルに保存します。 + +```yaml +apiVersion: v1 +kind: List +items: +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-high + spec: + hard: + cpu: "1000" + memory: 200Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["high"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-medium + spec: + hard: + cpu: "10" + memory: 20Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["medium"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-low + spec: + hard: + cpu: "5" + memory: 10Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["low"] +``` + +`kubectl create`を実行してYAMLの内容を適用させます。 + +```shell +kubectl create -f ./quota.yml +``` + +```shell +resourcequota/pods-high created +resourcequota/pods-medium created +resourcequota/pods-low created +``` + +`kubectl describe quota`を実行して`Used`クォータが`0`であることを確認します。 + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 1k +memory 0 200Gi +pods 0 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに記述します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: high-priority +spec: + containers: + - name: high-priority + image: ubuntu + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello; sleep 10;done"] + resources: + requests: + memory: "10Gi" + cpu: "500m" + limits: + memory: "10Gi" + cpu: "500m" + priorityClassName: high +``` + +`kubectl create`を使ってマニフェストを適用させます。 + +```shell +kubectl create -f ./high-priority-pod.yml +``` + +`pods-high`という名前のプライオリティーが"high"のクォータにおける"Used"項目の値が変更され、それ以外の2つの値は変更されていないことを確認してください。 + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 500m 1k +memory 10Gi 200Gi +pods 1 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。 + +* `In` +* `NotIn` +* `Exist` +* `DoesNotExist` + +## リクエスト vs リミット + +コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。 + +`requests.cpu`もしくは`requests.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、`limits.cpu`もしくは`limits.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な制限を行います。 + +## クォータの確認と設定 {#viewing-and-setting-quotas} + +kubectlでは、クォータの作成、更新、確認をサポートしています。 + +```shell +kubectl create namespace myspace +``` + +```shell +cat < compute-resources.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: compute-resources +spec: + hard: + requests.cpu: "1" + requests.memory: 1Gi + limits.cpu: "2" + limits.memory: 2Gi + requests.nvidia.com/gpu: 4 +EOF +``` + +```shell +kubectl create -f ./compute-resources.yaml --namespace=myspace +``` + +```shell +cat < object-counts.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-counts +spec: + hard: + configmaps: "10" + persistentvolumeclaims: "4" + pods: "4" + replicationcontrollers: "20" + secrets: "10" + services: "10" + services.loadbalancers: "2" +EOF +``` + +```shell +kubectl create -f ./object-counts.yaml --namespace=myspace +``` + +```shell +kubectl get quota --namespace=myspace +``` + +```shell +NAME AGE +compute-resources 30s +object-counts 32s +``` + +```shell +kubectl describe quota compute-resources --namespace=myspace +``` + +```shell +Name: compute-resources +Namespace: myspace +Resource Used Hard +-------- ---- ---- +limits.cpu 0 2 +limits.memory 0 2Gi +requests.cpu 0 1 +requests.memory 0 1Gi +requests.nvidia.com/gpu 0 4 +``` + +```shell +kubectl describe quota object-counts --namespace=myspace +``` + +```shell +Name: object-counts +Namespace: myspace +Resource Used Hard +-------- ---- ---- +configmaps 0 10 +persistentvolumeclaims 0 4 +pods 0 4 +replicationcontrollers 0 20 +secrets 1 10 +services 0 10 +services.loadbalancers 0 2 +``` + +また、kubectlは`count/.`というシンタックスを用いることにより、名前空間に依存した全ての主要なリソースに対するオブジェクト数のクォータをサポートしています。 + +```shell +kubectl create namespace myspace +``` + +```shell +kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +``` + +```shell +kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +``` + +```shell +kubectl describe quota --namespace=myspace +``` + +```shell +Name: test +Namespace: myspace +Resource Used Hard +-------- ---- ---- +count/deployments.extensions 1 2 +count/pods 2 3 +count/replicasets.extensions 1 4 +count/secrets 1 4 +``` + +## クォータとクラスター容量 + +`ResourceQuotas`はクラスター容量に依存しません。それはユニット数の絶対値で表されます。そのためクラスターにノードを追加した時、`ResourceQuotas`は各名前空間においてさらなるリソース消費を行う能力を自動で追加*しません* + +下記のようなより複雑なポリシーが必要な状況があります。 + + - 複数チーム間でクラスターリソースの総量を分けあう。 + - 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。 + - 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。 + +このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。 + +リソースクォータは集約されたクラスターリソースを分割するが、ノードに対して何の制限も行わないことを注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 + +## デフォルトで優先度クラスの消費を制限する + +特定の優先度を持つPod、例えば"cluster-services"は、条件に一致するクォータオブジェクトが存在するときのみ名前空間上でのPodの使用を許可したい場合があります。 + +このメカニズムにおいて、オペレーターは限られた数の名前空間に対して、一定以上の高い優先度クラスの使用を制限することができ、デフォルトではこのような優先度クラスを全ての名前空間は使用することができません。 + +これを強制するために、kube-apiserverの`--admission-control-config-file`というフラグを使って下記の設定ファイルに対してパスを渡す必要がります。 + +{{< tabs name="example1" >}} +{{% tab name="apiserver.config.k8s.io/v1" %}} +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: apiserver.config.k8s.io/v1 + kind: ResourceQuotaConfiguration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` +{{% /tab %}} +{{% tab name="apiserver.k8s.io/v1alpha1" %}} +```yaml +# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。 +apiVersion: apiserver.k8s.io/v1alpha1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + # v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。 + apiVersion: resourcequota.admission.k8s.io/v1beta1 + kind: Configuration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` +{{% /tab %}} +{{< /tabs >}} + +なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間において存在可能です。 + +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` + +さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。 + +## 例 + +[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。 + +{{% /capture %}} + +{{% capture whatsnext %}} + +さらなる情報は[リソースクォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 + +{{% /capture %}} From 086fd58a53deebaf050bca7119f353007163797e Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 27 May 2020 23:38:16 +0900 Subject: [PATCH 2/6] ja-trans: Improve Japanese translation in concepts/policy/resource-quotas.md #19282 --- content/ja/docs/concepts/policy/resource-quotas.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index e11feb50c7..d8611fb677 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -93,7 +93,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ | `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 | | `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 | -## オブジェクト数に対するクォータ Object Count Quota +## オブジェクト数に対するクォータ Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。 @@ -345,7 +345,7 @@ pods 0 10 `requests.cpu`もしくは`requests.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、`limits.cpu`もしくは`limits.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な制限を行います。 -## クォータの確認と設定 {#viewing-and-setting-quotas} +## リソースクォータの確認と設定 {#viewing-and-setting-quotas} kubectlでは、クォータの作成、更新、確認をサポートしています。 From ebd0b4c8319cb2dc366de8502add8162dba69ad1 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 00:31:17 +0900 Subject: [PATCH 3/6] ja-trans: Improve Japanese translation in concepts/policy/resource-quotas.md #19282 --- .../docs/concepts/policy/resource-quotas.md | 66 ++++++++++--------- .../concepts/storage/persistent-volumes.md | 2 +- 2 files changed, 35 insertions(+), 33 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index d8611fb677..cd8296f23c 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -20,16 +20,18 @@ weight: 10 リソースクォータは下記のように働きます。 -- 異なる名前空間のクラスターで異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 -- 管理者は各名前空間において1つの`ResourceQuota`を作成します。 -- ユーザーが名前空間内でリソース(Pod, Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードウェアリソースのリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 +- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 +- 管理者は各名前空間で1つの`ResourceQuota`を作成します。 +- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 -- `cpu`や`memory`といったコンピューターリソース対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を教養するために、`LimitRanger`という管理コントローラーを使用してください。この問題を解決する例は[walkthrough](/ja/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 +- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 + +`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 - 32GiB RAM、16コアのキャパシティーを持つクラスターで、Aチームに20GiB、10コアを割り当て、Bチームに10GiB、4コアを割り当て、将来の割り当てのために2GiB、2コアを予約しておく。 -- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかける。 "production"という名前空間は制限をかけない。 +- "testing"という名前空間に対して1コア、1GiB RAMの使用制限をかけ、"production"という名前空間には制限をかけない。 クラスターの総キャパシティーが、その名前空間のクォータの合計より少ない場合、リソースの競合が発生する場合があります。このとき、リソースの先着順で処理されます。 @@ -37,13 +39,13 @@ weight: 10 ## リソースクォータを有効にする -多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときも有効になります。 +多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。 -特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその特定の名前空間に適用されます。 +特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。 ## リソースクォータの計算 -特定の名前空間において、[コンピュートリソース](/ja/docs/user-guide/compute-resources)の合計に上限を設定できます。 +特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。 下記のリソースタイプがサポートされています。 @@ -51,13 +53,13 @@ weight: 10 | リソース名 | 説明 | | --------------------- | ----------------------------------------------------------- | | `limits.cpu` | 停止していない状態の全てのPodで、CPUリミットの合計がこの値を超えることができません。 | -| `limits.memory` | 停止していない状態の全てのPodで、メモリの合計がこの値を超えることができません。 | +| `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 | | `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 | -| `requests.memory` | 停止していない状態の全てのPodで、メモリリクエストの合計がこの値を超えることができません。 | +| `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 | ### 拡張リソースのためのリソースクォータ -上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/ja/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`lmits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 @@ -65,7 +67,7 @@ GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で * `requests.nvidia.com/gpu: 4` -さらなる詳細は[リソースクォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 +さらなる詳細は[クォータの確認と設定](#viewing-and-setting-quotas)を参照してください。 ## ストレージのリソースクォータ @@ -115,7 +117,7 @@ Kubernetes v1.9では下記のシンタックスを使用して、名前空間 Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 -`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります!また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 +`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。 @@ -127,19 +129,19 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース | `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | | `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 | | `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 | -| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/ja/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | +| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | | `services` | 名前空間内で存在可能なServiceの総数。 | | `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 | | `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 | | `secrets` | 名前空間内で存在可能なSecretの総数。 | -例えば、`Pod`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`Pod`のリソースクォータを設定したい場合があります。 +例えば、`pods`のリソースクォータは`Pod`の総数をカウントし、特定の名前空間内で作成された`Pod`の総数の最大数を設定します。またユーザーが多くのPodを作成し、クラスターのPodのIPが枯渇する状況を避けるために`pods`のリソースクォータを名前空間に設定したい場合があります。 ## クォータのスコープについて 各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。 -スコープがリソースクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセットに以外のリソースクォータ上でリソースを指定するとバリデーションエラーになります。 +スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。 | スコープ | 説明 | | ----- | ----------- | @@ -148,9 +150,9 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 | | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 | -`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `Pod` +`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods` -`Terminating`, `NotTerminating`, `NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: +`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: * `cpu` * `limits.cpu` @@ -164,13 +166,13 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース {{< feature-state for_k8s_version="1.12" state="beta" >}} -Podは特定の[Podの優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 +Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。 この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。 -- クラスター内のPodは3つの優先度クラスのうち1つをもちます。それは"low", "medium", "high"です。 +- クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。 - 1つのリソースクォータのオブジェクトは優先度毎に作成されます。 下記のYAMLを`quota.yml`というファイルに保存します。 @@ -223,7 +225,7 @@ items: values: ["low"] ``` -`kubectl create`を実行してYAMLの内容を適用させます。 +`kubectl create`を実行してYAMLの内容を適用します。 ```shell kubectl create -f ./quota.yml @@ -269,7 +271,7 @@ memory 0 20Gi pods 0 10 ``` -プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに記述します。 +プライオリティーが"high"であるPodを作成します。下記の内容を`high-priority-pod.yml`というファイルに保存します。 ```yaml apiVersion: v1 @@ -292,7 +294,7 @@ spec: priorityClassName: high ``` -`kubectl create`を使ってマニフェストを適用させます。 +`kubectl create`でマニフェストを適用します。 ```shell kubectl create -f ./high-priority-pod.yml @@ -343,7 +345,7 @@ pods 0 10 コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。 -`requests.cpu`もしくは`requests.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、`limits.cpu`もしくは`limits.memory`に対するクォータを指定したとき、コンテナはそれらのリソースに対する明示的な制限を行います。 +クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。 ## リソースクォータの確認と設定 {#viewing-and-setting-quotas} @@ -480,15 +482,15 @@ count/secrets 1 4 このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。 -リソースクォータは集約されたクラスターリソースを分割するが、ノードに対して何の制限も行わないことを注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 +リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 ## デフォルトで優先度クラスの消費を制限する -特定の優先度を持つPod、例えば"cluster-services"は、条件に一致するクォータオブジェクトが存在するときのみ名前空間上でのPodの使用を許可したい場合があります。 +例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。 -このメカニズムにおいて、オペレーターは限られた数の名前空間に対して、一定以上の高い優先度クラスの使用を制限することができ、デフォルトではこのような優先度クラスを全ての名前空間は使用することができません。 +このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。 -これを強制するために、kube-apiserverの`--admission-control-config-file`というフラグを使って下記の設定ファイルに対してパスを渡す必要がります。 +これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。 {{< tabs name="example1" >}} {{% tab name="apiserver.config.k8s.io/v1" %}} @@ -503,7 +505,7 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` @@ -522,14 +524,14 @@ plugins: limitedResources: - resource: pods matchScopes: - - scopeName: PriorityClass + - scopeName: PriorityClass operator: In values: ["cluster-services"] ``` {{% /tab %}} {{< /tabs >}} -なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間において存在可能です。 +なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。 ```yaml scopeSelector: @@ -549,6 +551,6 @@ plugins: {{% capture whatsnext %}} -さらなる情報は[リソースクォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 +さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 {{% /capture %}} diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 3e55db7066..e8aeb996f3 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -400,7 +400,7 @@ PVは[ノードアフィニティ](/docs/reference/generated/kubernetes-api/{{< CLIにはPVに紐付いているPVCの名前が表示されます。 -## 永続ボリューム要求 +## 永続ボリューム要求 {#persistentvolumeclaims} 各PVCにはspecとステータスが含まれます。これは、仕様とクレームのステータスです。 From 74655522d1e24a44a9cfb47374921b0171ffc239 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 00:33:19 +0900 Subject: [PATCH 4/6] ja-trans: Improve Japanese translation in concepts/policy/resource-quotas.md #19282 --- content/ja/docs/concepts/policy/resource-quotas.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index cd8296f23c..8b09a53c6c 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -347,7 +347,7 @@ pods 0 10 クォータに`requests.cpu`や`requests.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な要求を行います。同様に、クォータに`limits.cpu`や`limits.memory`の値が指定されている場合は、コンテナはそれらのリソースに対する明示的な制限を行います。 -## リソースクォータの確認と設定 {#viewing-and-setting-quotas} +## クォータの確認と設定 {#viewing-and-setting-quotas} kubectlでは、クォータの作成、更新、確認をサポートしています。 @@ -472,7 +472,7 @@ count/secrets 1 4 ## クォータとクラスター容量 -`ResourceQuotas`はクラスター容量に依存しません。それはユニット数の絶対値で表されます。そのためクラスターにノードを追加した時、`ResourceQuotas`は各名前空間においてさらなるリソース消費を行う能力を自動で追加*しません* +`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。 下記のようなより複雑なポリシーが必要な状況があります。 From 94228a9a81e1bfba8fe25c8a6a2efac5da0720b4 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 22:39:11 +0900 Subject: [PATCH 5/6] ja-trans: Fix Japanese translation in concepts/policy/_index.md #19282 --- content/ja/docs/concepts/policy/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/policy/_index.md b/content/ja/docs/concepts/policy/_index.md index 1fa1c815ba..c4990938e1 100755 --- a/content/ja/docs/concepts/policy/_index.md +++ b/content/ja/docs/concepts/policy/_index.md @@ -1,5 +1,5 @@ --- -title: "リソースのポリシー" +title: "ポリシー" weight: 90 --- From 3903fcc9bdda4fad37cd04168c15d078ff04bdf0 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Wed, 3 Jun 2020 22:43:57 +0900 Subject: [PATCH 6/6] ja-trans: Fix page link in ja/docs/concepts/policy/_index.md #19282 --- content/ja/docs/concepts/policy/resource-quotas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index 8b09a53c6c..ea73d05832 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -26,7 +26,7 @@ weight: 10 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 - `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 -`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. +`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。