よくある質問(FAQ)

KubernetesでPostgreSQLを実行する

PostgreSQLのようなステートフルなワークロードはKubernetesで実行できないことは誰もが知っています。なぜ逆なのですか?

2021年9月のindependent research survey commissioned by the Data on Kubernetes Communityでは、回答者の半分がほとんどの本番ワークロードをKubernetesで実行していることが明らかになりました。 90% は Kubernetes はステートフル ワークロードに対応できると考えており、70% は本番環境でデータベースを実行しています。 Postgresのようなデータベース。ただし、彼らによると、知識のギャップ(一般的にKubernetesとクラウドネイティブは急な学習曲線があります)やKubernetesオペレーターの品質など、重要な課題が残っています。後者が、CloudNativePGのようなオペレーターがプロジェクトの成功に大きく貢献すると考えている理由です。

私たちのようなデータベースの熱狂的な人にとって、本当のゲームチェンジャーは

*Kubernetes 1.14 in April 2019* でのローカル永続ボリュームのサポートの導入です。

CloudNativePGは、不変のアプリケーションコンテナ上に構築されています。どういう意味ですか?

マイクロサービス アーキテクチャ パターンによると、コンテナーは単一のアプリケーションまたはプロセスを実行するように設計されています。その結果、このようなコンテナイメージは、メインアプリケーションを単一のエントリポイント(いわゆるPID 1プロセス)として実行するように構築されます。

Kubernetesの用語では、アプリケーションはワークロードと呼ばれます。ワークロードは、Web アプリケーションサーバーのようにステートレスにすることも、データベースのようにステートフルにすることもできます。この概念をPostgreSQLにマッピングすると、不変のアプリケーションコンテナは、実行され、不変のコンテナイメージ内の単一の特定のバージョンに関連付けられた単一の「postgres」プロセスです。

SSHやsystemd、syslogなどの他のプロセスは許可されません。

不変アプリケーションコンテナは、コンテナを解釈して使用するための非常に一般的な方法である可変システムコンテナとは対照的です。

不変とは、コンテナがその存続期間中に変更されないことを意味します。更新、パッチ、構成の変更はありません。アプリケーションコードを更新するかパッチを適用する必要がある場合は、新しいイメージをビルドして再デプロイします。不変性により、展開がより安全になり、反復可能になります。

詳細については、 *"Why EDB chose immutable application containers"* を参照してください。

クラウドネイティブとはどういう意味ですか?

クラウドネイティブコンピューティング財団は、 *Cloud Native* “という用語を定義しています。ただし、2ndQuadrantでクラウドネイティブPostgreSQL / CloudNativePGオペレーターが開始されて以来、開発チームはクラウドネイティブを3つの主な概念として解釈しています。

1.人々、原則とプロセスに基づいた、既存の健全で本物の繁栄したDevOps文化。より安全で効率的で魅力的な方法でビジネスに価値を

2.イミュータブルアプリケーションコンテナに基づくマイクロサービスアーキテクチャ

3.これらのコンテナ(Kubernetesなど)を管理およびオーケストレーションする方法

現在、コンテナオーケストレーションの事実上の標準は、クラウドネイティブアプリケーションの展開、管理、スケーラビリティを自動化するKubernetesです。

私たちの共感を呼ぶクラウドネイティブの別の定義は、 *"Kubernetes Patterns", published by O'Reilly* でIbryamとHußによって定義されたものです。

コンテナ化されたマイクロサービスを大規模に自動化する原則、パターン、ツール

PostgreSQLをコンテナとして実行する代わりに演算子を使用する必要があるのはなぜですか?

KubernetesでPostgreSQLを実行するための最も基本的なアプローチは、Kubernetesでの展開の最小単位であるポッドを使用し、レプリカのないPostgresコンテナを実行することです。 Postgresデータディレクトリをホストするボリュームはポッドにマウントされ、通常はネットワークストレージにあります。この場合、Kubernetesは問題が発生した場合にポッドを再起動するか、別のKubernetesノードに移動します。

最も洗練されたアプローチは、演算子を使用してPostgreSQLを実行することです。オペレーターはKubernetesコントローラーの拡張であり、複雑なアプリケーションがビジネス継続性コンテキストでどのように機能するかを定義します。オペレーターパターンは、この目的のためのKubernetesの現在最先端です。オペレーターは、自動化されたプログラム的な方法で人間のオペレーターの作業をシミュレートします。

Postgresは複雑なアプリケーションであり、オペレーターはクラスターを展開する(最初のステップ)だけでなく、予期しないイベントに適切に対応する必要があります。典型的な例はフェイルオーバーです。

オペレーターは、自己修復、スケーラビリティ、レプリケーション、高可用性、バックアップ、リカバリ、更新、アクセス、リソース制御、ストレージ管理などの機能をKubernetesに依存しています。また、ログ管理および監視インフラストラクチャへのPostgreSQLクラスターの統合も容易になります。

CloudNativePGでは、宣言的な構成を介してPostgreSQLクラスターの目的の状態を定義できます。 Kubernetesは、Kubernetesコントローラーによって開始される調整ループを通じて、インフラストラクチャの現在の状態が目的の状態と一致することを継続的に確認します。望ましい状態と実際の状態が一致しない場合、調整ループが自己修復手順をトリガーします。そこで、CloudNativePGのようなオペレーターが登場します。

CloudNativePGは完全に宣言型のオペレーターだとおっしゃいます。どういう意味ですか?

最も簡単な方法は、命令型構成との違いを強調する例を使用して宣言型構成を説明することです。命令的なコンテキストでは、状態は順番に実行される一連のタスクとして定義されます。したがって、最初のインスタンスを作成し、レプリケーションを構成し、2番目のインスタンスをクローニングし、3番目のインスタンスを作成することにより、3ノードのPostgreSQLクラスターを取得できます。

宣言型アプローチでは、システムの状態は構成を使用して定義されます。つまり、2つのレプリカを持つPostgreSQL 13クラスターがあります。このアプローチにより、変更管理操作が非常に簡素化され、これらがGitなどのソース制御システムに保存されると、Infrastructure as Code機能が有効になります。また、Kubernetesはリクエストがいつでも満たされるようにするため、デプロイよりも先に進みます。

KubernetesでPostgreSQLを実行するために必要なスキルは何ですか?

KubernetesでPostgreSQLを実行するには、DevOpsチームでPostgreSQLとKubernetesの両方のスキルが必要です。最高のエクスペリエンスは、データベース管理者が Kubernetes のコア概念に精通し、Kubernetes 管理者と対話できるときです。

クラウドネイティブPostgreSQLを最大限に活用して、CNCF認定プログラムから「Certified Kubernetes Administrator(CKA)」ステータスを取得したいと考えているすべての人へのアドバイスです。

CloudNativePGがStatefulSetを使用しないのはなぜですか?

CloudNativePGはStatefulSet リソースに依存せず、動的プロビジョニング用に選択されたストレージクラスを活用して、基になるPVCを直接管理します。この決定の詳細と理由については、

カスタムポッドコントローラー セクションを参照してください。

高可用性

オペレーターポッドが停止した場合、または一定時間利用できない場合、PostgreSQLクラスターはどうなりますか?

とりわけ、CloudNativePGオペレーターは、自己修復機能を担当します。そのため、オペレーターの停止中には利用できない場合があります。

ただし、停止がPostgreSQLクラスターを実行しているノードに影響しないと仮定すると、データベースは関連するKubernetesサービスを介して通常の操作を提供し続けます。さらに、各PostgreSQLポッド内で実行される

インスタンスマネージャーのインプレース更新

は引き続き動作し、ロギング、メトリックのエクスポート、WALファイルの継続的なアーカイブなどのアクセサリサービスを含むデータベースサーバーが稼働していることを確認します。

要約すると:

オペレーターの停止は、必ずしもPostgreSQLデータベースの停止を意味するものではありません。これは、 DBAやシステム管理者なしでデータベースを実行するようなものです。