Resource management

一般的なKubernetesクラスターでは、ポッドは無制限のリソースで実行されます。デフォルトでは、必要なだけCPUとRAMを使用できます。

CloudNativePGを使用すると、管理者は、マニフェストのresources セクションを介して、クラスターのポッドによるリソース使用を制御および管理できます。

requests 初期要件
limits 最大使用量、リソースニーズが動的に増加した場合

たとえば、次のように32MiB 128MiBまでスケーラブルなRAMの初期量と50mのCPU 100mまでスケーラブルを要求できます。

resources:
  requests:
    memory: "32Mi"
    cpu: "50m"
  limits:
    memory: "128Mi"
    cpu: "100m"

メモリ要求と制限はコンテナに関連付けられますが、ポッドにメモリ要求と制限があると考えると便利です。ポッドのメモリ要求は、ポッド内のすべてのコンテナのメモリ要求の合計です。

ポッドのスケジューリングは、制限ではなく要求にもとづいています。ポッドのメモリ要求を満たすだけの十分な使用可能なメモリがノードにある場合にのみ、ポッドはノードで実行されるようにスケジュールされます。

リソースごとに、コンテナを優先度の高い順に3つのサービス品質QoSクラスに分割します。

保証
Burstable
ベストエフォート

詳細については、 Configure Quality of Service for Pods を参照してください。

Kubernetesドキュメントのセクション。

PostgreSQLワークロードの場合、「保証」QoSを設定することをお勧めします。

注釈

サービス品質が「保証」に設定されている場合、CloudNativePGは、 PostgreSQL documentation に従って、 postmaster プロセスの`PG_OOM_ADJUST_VALUE` を`0` に設定します。これにより、 postmaster は`-997` の低いアウトオブメモリOOMスコアを維持できますが、その子プロセスは`0` のOOMスコア調整で実行されます。その結果、OOMキラーがトリガーされると、postmaster より前に子プロセスを終了します。この動作は、PostgreSQLインスタンスをできるだけ長く生かし続けるのに役立ち、エビクションが発生した場合のクリーンシャットダウン手順を有効にします。

Kubernetesのリソース関連の問題を回避するには、クラスターの作成中に「リソース不足」処理のベストプラクティスを参照できます。

マニフェストファイルのリソースセクションでメモリとCPUの必要な値を指定します。この方法により、OOM Killed およびCPU throttle または実行中のインスタンスに関するその他のリソース関連の問題を回避できます。
クラスターのポッドを「保証」QoSクラスに割り当てるには、メモリとCPUの両方の制限と要求を同じ値に設定する必要があります。
ポッドリソースと一貫して必要なPostgreSQLメモリパラメーターを指定しますVMまたは物理マシンのシナリオで行うように、以下を参照してください。
nodeSelectorを使用して、専用ノードにデータベースサーバーポッドをセットアップします。 APIリファレンスページの “affinityconfiguration" リソースの「nodeSelector」および「tolerations」フィールドを参照してください。

次のマニフェストの例を参照できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgresql-resources
spec:
  instances: 3

  postgresql:
    parameters:
      shared_buffers: "256MB"

  resources:
    requests:
      memory: "1024Mi"
      cpu: 1
    limits:
      memory: "1024Mi"
      cpu: 1

  storage:
    size: 1Gi

上記の例では、 256MB の値でshared_buffers パラメーターを指定しました。つまり、データをキャッシュするためにPostgreSQLサーバーに専用のメモリの量です。このパラメーターのデフォルト値は定義されていない場合の128MB です。

shared_buffers の適切な開始値は、システム内のメモリの25%です。例えば shared_buffers が256 MBの場合、コンテナメモリサイズの推奨値は1 GBです。これは、ポッド内ですべてのコンテナが合計1 GBのメモリを持つことを意味し、Kubernetesが常に保持し、コンテナができることを意味します予想通りに動作します。詳細については、 Resource Consumption を参照してください。

PostgreSQLドキュメントのセクション。

注釈

リソース管理の詳細については、 Managing Compute Resources for Containers を参照してください。

Kubernetesドキュメントのページ。

垂直ポッドオートスケーラーVPAとの統合

Cluster CRDは、scale サブリソースとそのインスタンスポッドのラベルセレクターを公開します。これにより、 Cluster は Vertical Pod Autoscaler VPAの有効なtargetRef になるため、VPAはインスタンスポッドを観察し、それらのCPUとメモリの推奨事項を出力できます。

VPAは 推奨専用 モードupdatePolicy.updateMode: Off で実行することをお勧めします。このモードでは、VPAはその推奨事項のみをレポートし、オペレーターは通常のマニフェストの更新を介してCluster のspec.resources に適用できます。 CloudNativePGは、通常のスイッチオーバー対応手順を使用してインスタンスのローリング更新を実行します。 VPAはコンテナごとに推奨事項を生成します。 spec.resources が構成するものであるため、 postgres コンテナ用のものを使用します。

Cluster をターゲットとする例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: cluster-example-vpa
spec:
  targetRef:
    apiVersion: postgresql.cnpg.io/v1
    kind: Cluster
    name: cluster-example
  updatePolicy:
    updateMode: "Off"

警告

CloudNativePG管理の`Cluster` に対して updateMode: Auto 、Recreate 、または`Initial` を使用しないでください。オペレーターはポッド仕様を所有し、Cluster の`spec.resources` を真実のソースとして扱います。実行中のポッドにVPAが書き込むリソースを採用しないため、ライブポッドと宣言された`spec.resources` はサイレントに分岐します。宣言したリソースたとえば、オペレーターがメモリ要求に対して検証した`shared_buffers` 値に対してサイズを設定した調整は、ポッドの実際の制限と一致しなくなりました。また、VPAは、KubernetesエビクションAPIを介してポッドをエビクトし、オペレーターのスイッチオーバー認識シークエンシングをバイパスします。デフォルトのプライマリ`PodDisruptionBudget` は、プライマリのエビクションをブロックするため、VPAは完了する代わりにストールします。代わりに、VPA推奨事項を`Cluster` マニフェストに手動で適用します。

ホリゾンタルポッドオートスケーラーHPAとの統合

scale サブリソースはspec.instances も公開するため、 Horizontal Pod Autoscaler

HPAは、Cluster のインスタンスの数を技術的に変更できます。実際には、これはいくつかの理由からPostgreSQLクラスターには お勧めできません 。

Cluster のスケーリングは、スタンバイレプリカのみを追加または削除します。プライマリの書き込み負荷が軽減されることはありません。スケールサブリソースを介して公開されるセレクターは、反対のワークロードプロファイル書き込み多いプライマリ、読み取り専用レプリカを持つプライマリおよびすべてのレプリカと一致するため、HPAがCPUまたはメモリメトリックから計算するポッドごとの平均は意味がありません。それらのいずれかの信号。レプリカを追加すると、ホットプライマリに対処せずに、平均をさらに薄めるだけです。

HPAは、spec.instances に対するCloudNativePG自身のコンストレインも認識しません。同期レプリカを構成する場合、 maxSyncReplicas + 1 インスタンスより下のスケールダウンは検証Webhookによって拒否され、HPAは満足できない値を再試行し続けます。それでもHPAからspec.instances を駆動する場合は、実際にリードレプリカの負荷を反映するカスタムメトリックに基づいて、 minReplicas を同期レプリカのフロアより上に設定します。最初に、レプリケーションとクォーラムへの影響を注意深く確認します。