KubernetesのPostgreSQLオペレーターのクイックツアー、私たちの選択と経験

ますます多くの場合、次の要求が顧客から寄せられます。「Amazon RDSのようにしたいが、もっと安い」。「私たちはそれをRDSのように望んでいますが、どこでも、どのインフラストラクチャでも。」このようなマネージドソリューションをKubernetesに実装するために、PostgreSQLで最も人気のあるオペレーター（Stolon、Crunchy DataおよびZalandoのオペレーター）の現在の状態を調べて、選択しました。



この記事は、理論的な観点（ソリューションのレビュー）と実践的な観点（何が選択され、何がもたらされたのか）の両方からの私たちの経験です。しかし、最初に、RDSの潜在的な代替品の一般的な要件を決定しましょう...

RDSとは

人々がRDSについて話すとき、私たちの経験では、それらは次のようなマネージドDBMSサービスを意味します。

1. 簡単にカスタマイズ可能。
2. スナップショットを操作してスナップショットから回復する機能があります（できればPITRサポートを使用）。
3. マスタースレーブトポロジを作成できます。
4. 拡張機能の豊富なリストがあります。
5. 監査とユーザー/アクセス管理を提供します。

一般的に言って、タスクの実装へのアプローチは非常に異なる可能性がありますが、条件付きAnsibleを使用したパスは私たちの近くにはありません。（2GISの同僚は、「Postgresに基づいてフェイルオーバークラスターを迅速に展開するためのツール」を作成しようとした結果、同様の結論に達しました。）



オペレーターは、Kubernetesエコシステムでこのような問題を解決するための一般的に受け入れられているアプローチです。Kubernetes内で実行されているデータベースに関連するそれらの詳細は、Flant技術部門によってすでに伝えられています。distol、彼のレポートの1つで。



注意：簡単な演算子をすばやく作成するには、オープンソースのシェル演算子ユーティリティに注意を払うことをお勧めします。これを使用すると、Goの知識がなくてもこれを実行できますが、Bash、Pythonなどのsysadminに馴染みのある方法で実行できます。



PostgreSQLにはいくつかの人気のあるK8s演算子があります。

• ストロン;
• カリカリデータPostgreSQLオペレーター;
• ZalandoPostgresオペレーター。

それらを詳しく見てみましょう。

オペレーターの選択

すでに上で述べた重要な機能に加えて、Kubernetesのインフラストラクチャ運用エンジニアとして、私たちはオペレーターから次のことも期待していました。

• Gitおよびカスタムリソースからデプロイします。
• ポッドの非親和性サポート。
• ノードアフィニティまたはノードセレクタのインストール。
• 許容値の設定;
• チューニングの機会の利用可能性;
• 理解できるテクノロジー、さらにはコマンド。

各ポイントの詳細に立ち入ることなく（記事全体を読んだ後でそれらについて質問がある場合はコメントで尋ねてください）、特定のアプリケーション用にそれらを注文するために、クラスターノードの特殊化のより詳細な説明にこれらのパラメーターが必要であることに一般的に注意します。このようにして、パフォーマンスとコストの最適なバランスを実現できます。



さて、PostgreSQLオペレーター自身のために。

1. Stolon

ストロンでイタリアの会社Sorint.labから、既に述べた報告はされたDBMSのために事業者間のベンチマークの一種と考えられて。これはかなり古いプロジェクトです。最初の公開リリースは2015年11月に行われました（！）。GitHubリポジトリには、約3000のスターと40以上の貢献者がいます。



確かに、Stolonはよく考えられたアーキテクチャの素晴らしい例です。





このオペレーターのデバイスの詳細は、レポートまたはプロジェクトのドキュメントに記載されています。一般に、彼は説明されているすべてを実行できると言えば十分です：フェイルオーバー、透過的なクライアントアクセスのためのプロキシ、バックアップ...さらに、プロキシは、さらに検討されている他の2つのソリューションとは異なり、1つのエンドポイントサービスを介してアクセスを提供します（アクセスするための2つのサービスがあります）ベース）。



ただし、Stolonにはカスタムリソースがないため、「ホットケーキのように」簡単かつ迅速にKubernetesでDBMSインスタンスを作成するような方法で展開することはできません。管理はユーティリティstolonctl、展開、ヘルムチャートを介して実行され、ユーザー設定はConfigMapで定義されます。



一方では、オペレーターはあまりオペレーターではないことがわかります（結局のところ、CRDを使用していません）。しかし一方で、それはあなたが好きなようにK8sのリソースをカスタマイズすることを可能にする柔軟なシステムです。



要約すると、私たち個人としては、データベースごとに個別のチャートを作成することは最適ではないように思われました。したがって、私たちは代替案を探し始めました。

2.カリカリデータPostgreSQLオペレーター

若いアメリカ人のスタートアップであるCrunchyDataのオペレーターは、論理的な代替手段のように見えました。その公開の歴史は2017年3月の最初のリリースから始まり、それ以来、GitHubリポジトリは1300をわずかに下回る星と50以上の貢献者を受け入れています。最新の9月のリリースは、Kubernetes 1.15-1.18、OpenShift 3.11以降および4.4以降、GKEおよびVMware Enterprise PKS1.3以降でテストされています。



Crunchy Data PostgreSQL Operatorアーキテクチャは、次の要件も満たしています。







管理はユーティリティを介して行われますがpgo、Kubernetesのカスタムリソースが生成されます。したがって、オペレーターは潜在的なユーザーとして私たちを喜ばせました：

• CRDを介した制御があります。
• 便利なユーザー管理（これもCRD経由）。
• Crunchy Data Container Suiteの他のコンポーネントとの統合-PostgreSQLコンテナイメージとそれを操作するためのユーティリティ（pgBackRest、pgAudit、contrib拡張機能などを含む）の特殊なコレクション。

ただし、Crunchy Dataから演算子の使用を開始しようとすると、いくつかの問題が明らかになりました。

• 許容の可能性はありませんでした-nodeSelectorのみが提供されます。
• ステートフルアプリケーションをデプロイしたにもかかわらず、作成したポッドはデプロイメントの一部でした。StatefulSetsとは異なり、Deploymentsはディスクを作成できません。

最後の欠点はおかしな瞬間につながります。テスト環境では、1つのローカルストレージディスクで3つのレプリカを実行できました。その結果、オペレーターは3つのレプリカが機能していると報告しました（ただし、そうではありませんでした）。



このオペレーターのもう1つの特徴は、さまざまな補助システムとの既製の統合です。たとえば、pgAdminとpgBounceをインストールするのは簡単で、ドキュメントには事前設定されたGrafanaとPrometheusが含まれています。最近のリリース4.5.0- beta1は、pgMonitorプロジェクトとの統合が改善されたことを個別に示しています。これにより、オペレーターは、PgSQLのメトリックをすぐに視覚的に視覚化できます。



しかし、生成されたKubernetesリソースの奇妙な選択により、別の解決策を見つけることになりました。

3. ZalandoPostgresオペレーター

私たちは長い間Zalandoの製品を知っている：私たちはZaleniumを使用した経験を持っていると、当然のことながら、我々は試してみましたPatroniを- PostgreSQLのための彼らの人気のHAソリューション。その作者の1人であるAlekseyKlyukinが、Postgres-Tuesday＃5にPostgres Operatorを作成するための同社のアプローチについて話し、私たちはそれを気に入りました。 これは、記事で説明されている最も若いソリューションです。最初のリリースは2018年8月に行われました。ただし、正式なリリースの数が少ないにもかかわらず、プロジェクトは長い道のりを歩んできました。GitHubに1300以上の星があり、貢献者の最大数（70以上）で、CrunchyDataのソリューションの人気をすでに上回っています。 このオペレーターの内部では、実績のあるソリューションが使用されます。

• 制御のためのパトロニとスピロ、
• WAL-E-バックアップ用、
• PgBouncer-接続プールとして。

Zalandoのオペレーターアーキテクチャは次のように表示されます







。オペレーターはカスタムリソースを通じて完全に管理され、コンテナーからStatefulSetを自動的に作成します。これは、ポッドにさまざまなサイドカーを追加することでカスタマイズできます。Crunchy Dataのオペレーターと比較すると、これはすべて重要なプラスです。



検討中の3つのオプションから選択したのはZalandoのソリューションであったため、その機能の詳細を、アプリケーションの実践とともに以下に示します。

ZalandoのPostgresオペレーターで練習する

オペレーターのデプロイは非常に簡単です。GitHubから現在のリリースをダウンロードし、manifestsディレクトリからYAMLファイルを適用するだけです。または、OperatorHubを使用することもできます。



インストール後、ログとバックアップ用のストレージの設定について心配する必要があります。これはpostgres-operator、ステートメントをインストールした名前名のConfigMapを介して行われます。リポジトリを構成したら、最初のPostgreSQLクラスターをデプロイできます。



たとえば、標準の展開は次のようになります。

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

このマニフェストは、postgres_exporterの形式のサイドカーを備えた3つのインスタンスのクラスターをデプロイし、そこからアプリケーションメトリックを取得します。ご覧のとおり、すべてが非常に単純であり、必要に応じて、文字通り無制限の数のクラスターを作成できます。Web管理パネル（postgres-operator-ui）



に注意を払う価値があります。オペレーターに付属しており、クラスターを作成および削除したり、オペレーターが作成したバックアップを操作したりできます。PostgreSQLクラスターリストのバックアップ管理 もう1つの興味深い機能は、TeamsAPIのサポートです。このメカニズムにより、PostgreSQLでロールが自動的に作成されます















結果のユーザー名のリストに基づきます。その後、APIを使用すると、役割が自動的に作成されるユーザーのリストを返すことができます。

問題と解決策

ただし、演​​算子を使用すると、すぐにいくつかの重大な欠点が明らかになりました。

1. nodeSelectorのサポートの欠如。
2. バックアップを無効にできない。
3. データベース作成機能を使用する場合、デフォルトの権限は表示されません。
4. 定期的に十分なドキュメントがないか、古くなっています。

幸いなことに、それらの多くは解決できます。最後から始めましょう-ドキュメントの問題。



ほとんどの場合、バックアップを登録する方法と、バックアップバケットをOperatorUIに接続する方法が必ずしも明確ではないという事実に遭遇するでしょう。ドキュメントではこれについて説明していますが、実際の説明はPRにあります。

1. あなたは秘密を作る必要があります。
2. pod_environment_secret_name CRD ConfigMap ( , ).

しかし、結局のところ、これは現在不可能です。そのため、独自のバージョンのオペレーターといくつかの追加のサードパーティ開発を組み合わせました。詳細については、以下を参照してください。



バックアップのパラメーター、つまりwal_s3_bucketAWS S3のアクセスキーをオペレーターに渡すと、オペレーターはすべてをバックアップします。実稼働中のベースだけでなく、ステージングもバックアップします。それは私たちに合いませんでした。



演算子を使用する場合のPgSQLの基本的なDockerラッパーであるSpiloへのパラメーターの説明では、パラメーターをWAL_S3_BUCKET空に渡してバックアップを無効にできることがわかりました。さらに、私たちの大きな喜びとして、既製のPRが見つかり、すぐにフォークに受け入れました。これで、enableWALArchiving: falsePostgreSQLクラスターをリソースに追加するだけで十分です。



はい、2つのオペレーターを実行することで別の方法でそれを行う機会がありました。1つはステージング（バックアップなし）用で、もう1つは本番用です。しかし、それで私たちは1つでうまくいくことができました。



さて、S3のアクセスをデータベースに転送する方法を学び、バックアップがストレージに入り始めました。オペレーターUIでバックアップページを機能させる方法は？







オペレーターUIでは、次の3つの変数を追加する必要があります。

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

その後、バックアップの管理が利用可能になります。これにより、ステージングの作業が簡素化され、追加のスクリプトなしで本番環境からスライスを配信できるようになります。



Teams APIを使用し、オペレーターツールを使用してベースとロールを作成する幅広い機会がもう1つの利点として挙げられました。ただし、作成されたロールにはデフォルトの権限がありませんでした。したがって、読み取り権限を持つユーザーは新しいテーブルを読み取ることができませんでした。



何故ですか？コードに必要なものが含まれているにもかかわらずGRANT、それらが常に使用されるとは限りません。 2つの方法があります：syncPreparedDatabasesとsyncDatabases。 B syncPreparedDatabases-という事実にもかかわらず、preparedDatabases そこに条件があるセクションにdefaultRolesし、defaultUsersロールを作成するために、デフォルトの権限は適用されません。これらの権利が自動的に適用されるように、パッチを準備中です。



そして、私たちに関連する改善の最後の瞬間は、作成されたStatefulSetにノードアフィニティを追加するパッチです。私たちのクライアントは、スポットインスタンスを使用してコストを削減することを好むことが多く、データベースサービスをホストするべきではないことは明らかです。この問題は許容範囲によって解決できますが、ノードアフィニティの存在は多くの自信を与えます。

どうした？

上記の問題を解決した結果、PostgresOperatorをZalandoからリポジトリにフォークしました。リポジトリにはこのような便利なパッチが組み込まれています。また、便宜上、Dockerイメージもアセンブルしました。



フォークされたPRリスト：

• Dockerでオペレーター用の安全で軽量なイメージを構築する。
• バックアップを無効にする;
• 現在のk8sバージョンのリソースバージョンを更新する;
• ノードアフィニティの実装。

コミュニティがこれらのPRをサポートして、次のバージョンのオペレーター（1.6）でアップストリームになるようにすると素晴らしいでしょう。

ボーナス！プロダクション移行のサクセスストーリー

Patroniを使用している場合は、最小限のダウンタイムでライブプロダクションをオペレーターに移行できます。



Spiloを使用すると、PgSQLバイナリログが最初にS3に保存され、次にレプリカによってダウンロードされるときに、Wal-Eを使用してS3ストレージを介してスタンバイクラスターを作成できます。しかし、古いインフラストラクチャにWal-Eがない場合はどうなるでしょうか。この問題の解決策は、Habréですでに提案されています。



PostgreSQLの論理レプリケーションが役に立ちます。ただし、計画が失敗したため、パブリケーションとサブスクリプションの作成方法の詳細については説明しません。



事実、データベースには数百万行のロードされたテーブルがいくつかあり、さらに、それらは絶えず補充および削除されていました。シンプルなサブスクリプション付きcopy_data、新しいレプリカがマスターからすべてのコンテンツをコピーするとき、それは単にマスターに追いついていない。コンテンツのコピーは1週間機能しましたが、マスターに追いつくことはありませんでした。その結果、Avitoの同僚による記事が問題の解決に役立ちましたpg_dump。を使用してデータを転送できます。このアルゴリズムの（わずかに変更された）バージョンについて説明します。



アイデアは、特定のレプリケーションスロットに関連付けられたオフサブスクリプションを作成してから、トランザクション番号を修正できるということです。生産作業用のレプリカがありました。レプリカは一貫したダンプを作成し、マスターから変更を受け取り続けるのに役立つため、これは重要です。



移行プロセスを説明する後続のコマンドでは、次のホスト表記が使用されます。

1. マスター-ソースサーバー;
2. Replica1-古いプロダクションでのストリーミングレプリカ。
3. Replica2は新しい論理レプリカです。

移行計画

1.ウィザードで、publicデータベーススキーマ内のすべてのテーブルへのサブスクリプションを作成しますdbname。

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2.マスターにレプリケーションスロットを作成しましょう。

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3.古いレプリカでレプリケーションを停止します。

psql -h replica1 -c "select pg_wal_replay_pause();"

4.マスターからトランザクション番号を取得します。

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5.古いレプリカをダンプしましょう。これをいくつかのスレッドで実行します。これにより、プロセスが高速化されます。

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6.ダンプを新しいサーバーにアップロードします。

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7.ダンプをダウンロードした後、ストリーミングレプリカでレプリケーションを開始できます。

psql -h replica1 -c "select pg_wal_replay_resume();"

7.新しい論理レプリカでサブスクリプションを作成しましょう。

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8.oidサブスクリプションを取得します。

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9.受け取ったとしましょうoid=1000。トランザクション番号をサブスクリプションに適用してみましょう。

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10.レプリケーションを開始しましょう：

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11.サブスクリプションのステータスを確認します。レプリケーションが機能するはずです。

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12.レプリケーションが開始され、データベースが同期されたら、切り替えることができます。



13.レプリケーションを無効にした後、シーケンスを修正する必要があります。これは、wiki.postgresql.orgの記事に詳しく記載されています。



この計画のおかげで、切り替えは最小限の遅延で完了しました。

結論

Kubernetesオペレーターを使用すると、K8sリソースの作成に限定することで、さまざまなアクティビティを簡素化できます。しかし、彼らの助けを借りて驚くべき自動化を達成したので、それはまた多くの予期しないニュアンスをもたらす可能性があることを覚えておく価値がありますので、あなたのオペレーターを賢く選んでください。



PostgreSQLで最も人気のある3つのKubernetesオペレーターを確認した後、Zalandoのプロジェクトを選択しました。そして、私はそれに関する特定の困難を克服しなければなりませんでしたが、結果は本当に満足していたので、この経験を他のいくつかのPgSQLインストールに拡張する予定です。同様のソリューションを使用した経験がある場合は、コメントで詳細を確認できます。

PS

私たちのブログも読んでください：

• "データベースとKubernetes（レビューとビデオレポート） ";
• «Postgres- №5: PostgreSQL Kubernetes. CI/CD. »;
• « Redis K8s - ».