チーム間で共有されるクラスターを実行しており、各チームに最小限のリソース、特にメモリを保証したいと考えています。
続いて説明書名前空間で次のものを使用してみました:
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-quota
spec:
hard:
requests.memory: 8Gb
しかし、さらにドキュメントを読んでいくと、これはポッドに 8 GB のメモリがあることを保証するものではないことがわかりました。ポッドの合計値がrequests.memory
8 GB を超えないことを意味するだけです。上記のように 8 GB に設定されていても、4 GB しか使用しておらず、クラスターが他の場所で最大限に使用され、新しいポッドをスケジュールできなかった場合は、新しいポッドを作成できない可能性があります。
また、たとえば、合計メモリが 8Gi しかないクラスターで、値が 16Gi の をResourceQuota
作成することもできます。requests.memory
チームに、そのチームだけが使用できる一定量のメモリを保証する方法はありますか?
答え1
それは単にポッドのリクエストの合計を意味します。メモリ値は8Gbを超えることはできません。
はい、これがResourceQuotaのロジックです。リソース クォータの理解:
リソース クォータは次のように機能します。
ユーザーはポッドにコンピューティング リソース要求を送信します。同じ名前空間内のすべてのポッドにわたるすべてのリソース要求の合計は、名前空間のリソース クォータ ドキュメント内のハード リソース制限を超えてはなりません。以前は、ポッドのリソース制限の合計を取得してリソース クォータを検証していましたが、これはリソース要求を使用するように変更されました。リソース制限のみを指定するポッドでは、リソース要求が定義された制限と一致するようにデフォルト設定されるため、以前に作成されたポッドの下位互換性は保持されます。要求は、スケジュール中にクラスターによって保証されるリソースの最小量であるため、ユーザーは、リソース クォータで要求したリソースと制限に対してのみ課金されます。オーバーコミットの詳細については、「compute-resources」を参照してください。
ポッドを作成すると、名前空間がその名前空間のリソース クォータで指定された制限のいずれかを超える場合、要求は HTTP ステータス コード 403 FORBIDDEN で失敗します。
名前空間でクォータが有効になっていて、クォータが有効になっている各リソースに対してユーザーがポッドでリクエストを指定していない場合、ポッドの POST は HTTP ステータス コード 403 FORBIDDEN で失敗します。ヒント: この問題を回避するには、クォータがチェックされる前に、LimitRange アドミッション コントローラーを使用して制限のデフォルト値を強制します (すると、リソース リクエストはデフォルトで制限と同じになります。アドミッション コントローラーを参照してください)。
ただし、この記事では、リソースを個別に分割する必要があるケースについて少し詳しく説明します。これは、まだ実装されていないものです。
クォータとクラスター容量: 次のような、より複雑なポリシーが求められる場合もあります。
- クラスター リソース全体を複数のチーム間で比例的に分割します。
- 各テナントが必要に応じてリソース使用量を増やすことを許可しますが、偶発的なリソース枯渇を防ぐために十分な制限を設けます。
- 1 つの名前空間からの需要を検出し、ノードを追加し、割り当てを増やします。
このようなポリシーは、クォータの使用状況を監視し、他のシグナルに応じて各名前空間のクォータのハード制限を調整する「コントローラー」を作成することにより、ResourceQuota をビルディング ブロックとして使用して実装できます。
独自のコントローラーにカスタム ロジックを記述する必要があると思います。