Resource management

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

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

  • requests ：初期要件

  • limits ：リソースのニーズが動的に増加する場合の最大使用量

例、次のように、32MiB（128MiBにスケーラビリティ）のRAMと50mのCPU（100mにスケーラビリティ）の初期RAMを要求できます。

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

メモリリクエストと制限はコンテナに関連付けられていますが、ポッドにメモリリクエストと制限があると考えると便利です。ポッドのメモリリクエストは、ポッド内のすべてのコンテナのメモリリクエストの総和です。

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

リソースごとに、コンテナを優先度の高いオーダーに3つのQuality of Service（QoS）クラスに分割します。

  • 保証

  • バースタブル

  • ベストエフォート

詳細については、Kubernetes文書の Configure Quality of Service for Pods セクションを参照してください。

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

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

  • マニフェストファイルのリソースセクションで、メモリとCPUに必要な値を指定します。 このようにして、 OOM Killed （「OOM」はOut Of Memoryを表します）および CPU throttle またはその他を回避できます。 インスタンスの実行に関するリソース関連の問題。

  • クラスターのポッドを「保証」QoSクラスに割り当てるには、制限と要求を設定する必要があります メモリとCPUの両方を同じ値にします。

  • 必要なPostgreSQLメモリパラメータをポッドリソースと一貫して指定します（あなたがするように） VMまたは物理的マシンのシナリオ-以下を参照）。

  • nodeSelectorを使用して、専用ノードでデータベースサーバポッドをセットアップします。 「nodeSelector」および「tolerations」フィールドを参照してください APIマニュアルページの “affinityconfiguration" リソース。

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

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 メガバイトの場合、コンテナメモリサイズの推奨値は1 ギガバイトです。つまり、ポッド内ではすべてのコンテナがKubernetesが常に保存する合計1 ギガバイトのメモリ。コンテナを期待どおりに動作させることができます。詳細については、 PostgreSQL文書の Resource Consumption セクションを参照してください。