Resource management =================== .. raw:: html 一般的なKubernetesクラスターでは、ポッドは無制限のリソースで実行されます。デフォルトでは、必要なだけCPUとRAMを使用できます。 CloudNativePGを使用すると、管理者は、マニフェストの\ ``resources`` セクションを介して、クラスターのポッドによるリソース使用を制御および管理できます。 - ``requests`` 初期要件 - ``limits`` 最大使用量、リソースニーズが動的に増加した場合 たとえば、次のように32MiB 128MiBまでスケーラブルなRAMの初期量と50mのCPU 100mまでスケーラブルを要求できます。 .. code:: yaml resources: requests: memory: "32Mi" cpu: "50m" limits: memory: "128Mi" cpu: "100m" メモリ要求と制限はコンテナに関連付けられますが、ポッドにメモリ要求と制限があると考えると便利です。ポッドのメモリ要求は、ポッド内のすべてのコンテナのメモリ要求の合計です。 ポッドのスケジューリングは、制限ではなく要求にもとづいています。ポッドのメモリ要求を満たすだけの十分な使用可能なメモリがノードにある場合にのみ、ポッドはノードで実行されるようにスケジュールされます。 リソースごとに、コンテナを優先度の高い順に3つのサービス品質QoSクラスに分割します。 - *保証* - *Burstable* - *ベストエフォート* 詳細については、 `Configure Quality of Service for Pods `_ を参照してください。 Kubernetesドキュメントのセクション。 PostgreSQLワークロードの場合、「保証」QoSを設定することをお勧めします。 .. Note:: サービス品質が「保証」に設定されている場合、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リファレンスページの :ref:`“affinityconfiguration" ` リソースの「nodeSelector」および「tolerations」フィールドを参照してください。 次のマニフェストの例を参照できます。 .. code:: yaml 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ドキュメントのセクション。 .. Note:: リソース管理の詳細については、 `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`` をターゲットとする例 .. code:: yaml 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" .. Warning:: 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`` を同期レプリカのフロアより上に設定します。最初に、レプリケーションとクォーラムへの影響を注意深く確認します。