|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
SUSE Rancher Primeプロジェクトにおけるリソースクォータの仕組み
Rancherのリソースクォータは、 Kubernetesのネイティブバージョンと同じ機能を含んでいます。しかし、Rancherでは、リソースクォータが拡張され、プロジェクトに適用できるようになっています。
標準のKubernetesデプロイメントでは、リソースクォータは個々のネームスペースに適用されます。ただし、単一アクションで同時にネームスペースにクォータを適用することはできません。代わりに、リソースクォータを複数回適用する必要があります。
次の図では、Kubernetesの管理者がRancherなしでリソースクォータを強制しようとしています。管理者は、クラスター内のすべてのネームスペースに同じCPUとメモリ制限を設定するリソースクォータを適用したいと考えています(Namespace 1-4)。しかし、Kubernetesの基本バージョンでは、各ネームスペースには一意のリソースクォータが必要です。管理者は、同じ仕様が設定された4つの異なるリソースクォータを作成し(Resource Quota 1-4)、それらを個別に適用しなければなりません。
基本Kubernetes:各ネームスペースに適用されている一意のリソースクォータ
Rancherではリソースクォータが少し異なります。Rancherでは、プロジェクトにリソースクォータを適用し、その後クォータが各ネームスペースに伝播し、Kubernetesがネイティブバージョンのリソースクォータを使用して制限を強制します。特定のネームスペースのクォータを変更したい場合は、上書きすることができます。
-
プロジェクト制限:
この値のセットは、プロジェクト内のすべてのネームスペースで共有される各指定リソースの合計制限を構成します。
-
ネームスペースデフォルト制限:
この値のセットは、各指定リソースに対して各ネームスペースで利用可能なデフォルトのクォータ制限を構成します。 上書きなしでプロジェクト内にネームスペースが作成されると、この制限は自動的にネームスペースにバインドされ、強制されます。
次の図では、Rancherの管理者がプロジェクト内のすべてのネームスペースに対して同じCPUおよびメモリ制限を設定するリソースクォータを適用したいと考えています(Namespace 1-4)。しかし、Rancherでは、管理者は個々のネームスペースではなくプロジェクト(Project Resource Quota)に対してリソースクォータを設定できます。このクォータには、プロジェクト全体(Project Limit)と個々のネームスペース(Namespace Default Limit)の両方のリソース制限が含まれています。Rancherは、作成時に`Namespace Default Limit`クォータを各ネームスペース(Namespace Resource Quota)に伝播させます。
Rancher:各ネームスペースへのリソースクォータの伝播
Rancher UIの*内*で作成されたネームスペースのための、より微妙な機能を強調しましょう。クォータがプロジェクトレベルで削除される場合は、何らかの上書きが存在する場合があるにもかかわらず、そのプロジェクトに含まれるすべてのネームスペースからも削除されます。さらに、プロジェクトレベルでクォータの既存のネームスペースのデフォルト制限を更新しても、その値はプロジェクト内の既存のネームスペースに伝播されません。更新された値は、そのプロジェクト内で新たに作成されたネームスペースにのみ適用されます。既存のネームスペースのデフォルト制限を更新するには、新しいデフォルト値でプロジェクトレベルでクォータを削除し、その後再作成することができます。これにより、プロジェクト内のすべての既存のネームスペースに新しいデフォルト値が適用されます。
プロジェクト内にネームスペースを作成する前に、Rancherはプロジェクトの利用可能なリソースの量と要求されたリソースの量を比較します。これは、デフォルトまたは上書きされた制限から来るかどうかに関係なく行われます。 要求されたリソースがそのリソースのプロジェクト内の残りの容量を超える場合、Rancherはそのリソースの残りの容量をネームスペースに割り当てます。
しかし、これはRancherのUIの*外*で作成されたネームスペースには当てはまりません。`kubectl`を介して作成されたネームスペースの場合、Rancherはプロジェクト内に残っている容量を超えるリソースに対して*ゼロ*の量を持つリソースクォータを割り当てます。
`kubectl`を介して既存のプロジェクトにネームスペースを作成するには、`field.cattle.io/projectId`アノテーションを使用します。デフォルトの要求クォータ制限を上書きするには、`field.cattle.io/resourceQuota`アノテーションを使用します。
Rancherは、プロジェクトクォータで定義されたリソースの制限のみを上書きすることに注意してください。
apiVersion: v1
kind: Namespace
metadata:
annotations:
field.cattle.io/projectId: [your-cluster-ID]:[your-project-ID]
field.cattle.io/resourceQuota: '{"limit":{"limitsCpu":"100m", "configMaps": "50"}}'
name: my-ns
この例では、プロジェクトのクォータにconfigMapsがリソースのリストに含まれていない場合、Rancherはこの上書きの`configMaps`を無視します。
ユーザーは、プロジェクトに組み込まれていないリソースの追加のカスタム制限を構成するために、`extended`マップを使用するか、同じ目的のために特定のネームスペースに専用の`ResourceQuota`オブジェクトを作成することをお勧めします。リソースクォータはネイティブのKubernetesオブジェクトであり、Rancherはクォータを持つプロジェクトに属するネームスペース内のユーザー定義のクォータを無視します。これにより、ユーザーはより多くの制御を得ることができます。
以下の表は、2つのクォータタイプの主な違いを説明しています。
| Rancherリソースクォータ | Kubernetesリソースクォータ |
|---|---|
プロジェクトとネームスペースに適用されます。 |
ネームスペースのみに適用されます。 |
プロジェクト内のすべてのネームスペース用にリソースプールを作成します。 |
個々のネームスペースに静的なリソース制限を適用します。 |
伝播を通じてネームスペースにリソースクォータを適用します。 |
割り当てられたネームスペースのみに適用されます。 |