🥇Kubernetes 用 PostgreSQL オペレーターの概要、私たちの選択と経験

クライアントから次のようなリクエストが増えています。「Amazon RDS のようなものが欲しいが、もっと安くしたい」。「私たちは RDS と同様に、あらゆる場所、あらゆるインフラストラクチャでそれを実現したいと考えています。」このようなマネージドソリューションを Kubernetes に実装するために、PostgreSQL で最も人気のある演算子 (Stolon、Crunchy Data および Zalando の演算子) の現状を調べ、選択を行いました。

この記事は、理論的な観点 (ソリューションのレビュー) と実践的な側面 (何が選択され、その結果何が生じたのか) の両方から得た経験をまとめたものです。しかしその前に、RDS の代替となる可能性のある一般的な要件が何であるかを判断しましょう...

RDSとは

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

設定が簡単。
スナップショットを操作し、スナップショットから復元する機能があります (できればサポートが必要です) PITR);
マスター/スレーブトポロジを作成できます。
拡張子の豊富なリストがあります。
監査とユーザー/アクセス管理を提供します。

一般に、当面のタスクを実装するためのアプローチは非常に異なる場合がありますが、条件付き Ansible を使用する道は私たちに近いものではありません。 (2GIS の同僚も結果として同様の結論に達しました) 彼の試み「Postgres ベースのフェールオーバークラスターを迅速に展開するためのツール」を作成します。)

オペレーターは、Kubernetes エコシステムで同様の問題を解決するための一般的なアプローチです。「Flanta」のテクニカルディレクターは、Kubernetes 内で起動されるデータベースに関連して、それらについてすでに詳しく語っています。ディストルで彼のレポートの一つ.

NB: 単純な演算子をすばやく作成するには、オープンソースユーティリティに注意を払うことをお勧めします。 シェルオペレーター。これを使用すると、Go の知識がなくてもこれを実行できますが、システム管理者にとってより馴染みのある方法 (Bash、Python など) で実行できます。

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

ストロン。
Crunchy Data PostgreSQL オペレーター。
Zalando Postgres オペレーター。

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

演算子の選択

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

Git からのデプロイメントとそれを使用したデプロイメントカスタムリソース;
ポッドのアンチアフィニティのサポート。
ノードアフィニティまたはノードセレクターをインストールします。
公差の設置。
チューニング機能の可用性。
理解可能なテクノロジーやコマンドさえも。

それぞれの点については詳しく説明しませんが (記事全体を読んだ後でも質問がある場合は、コメントで質問してください)、一般的に、これらのパラメーターは、クラスターノードの特殊化をより正確に説明するために必要であることに注意してください。特定の用途に合わせて注文してください。これにより、パフォーマンスとコストの最適なバランスを実現できます。

次に、PostgreSQL 演算子そのものに移りましょう。

1.ストロン

ストーロンイタリアの会社Sorint.labからすでに述べたレポート DBMS の運用者の間で一種の標準として考えられていました。これはかなり古いプロジェクトです。最初の公開リリースは 2015 年 3000 月 (!) に遡り、GitHub リポジトリにはほぼ 40 のスターと XNUMX 人以上の寄稿者がいます。

実際、Stolon は思慮深いアーキテクチャの優れた例です。

このオペレーターのデバイスについては、レポートまたはプロジェクトのドキュメント。一般に、フェールオーバー、透過的なクライアントアクセスのためのプロキシ、バックアップなど、説明されているすべてを実行できると言えば十分です。さらに、プロキシは、以下で説明する他の XNUMX つのソリューションとは異なり、XNUMX つのエンドポイントサービスを介してアクセスを提供します (それぞれに XNUMX つのサービスがあります)。ベースにアクセス中）。

しかし、ストロンカスタムリソースはありませんそのため、Kubernetes で DBMS インスタンスを作成するために「ホットケーキのように」簡単かつ迅速にデプロイすることはできません。管理はユーティリティを通じて行われます stolonctl、デプロイは Helm チャートを通じて行われ、カスタムのものは ConfigMap で定義および指定されます。

一方で、オペレーターは実際にはオペレーターではないことがわかります (結局のところ、CRD は使用しません)。しかしその一方で、K8 のリソースを必要に応じて構成できる柔軟なシステムでもあります。

要約すると、私たち個人としては、データベースごとに個別のグラフを作成するのが最適とは思えませんでした。そこで、代替手段を探し始めました。

2. クランチデータ PostgreSQL オペレーター

Crunchy Data のオペレーター、若いアメリカのスタートアップ企業は、論理的な選択肢のように思えました。その公開の歴史は 2017 年 1300 月の最初のリリースに始まり、それ以来、GitHub リポジトリには 50 個弱のスターと 1.15 人以上の寄稿者が集まりました。 1.18 月の最新リリースは、Kubernetes 3.11 ～ 4.4、OpenShift 1.3 以降および XNUMX 以降、GKE、VMware Enterprise PKS XNUMX 以降で動作することがテストされました。

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

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

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

ただし、Crunchy Data のオペレーターの使用を開始しようとすると、いくつかの問題が明らかになりました。

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

最後の欠点は面白い瞬間につながります。テスト環境では、3 つのディスクで XNUMX つのレプリカを実行することができました。 ローカルストレージそのため、オペレーターは 3 つのレプリカが (実際には動作していなかったにもかかわらず) 動作していると報告しました。

このオペレーターのもう XNUMX つの特徴は、さまざまな補助システムとの既製の統合です。たとえば、pgAdmin と pgBounce は簡単にインストールできます。ドキュメンテーション事前構成された Grafana と Prometheus が考慮されます。最近リリース 4.5.0-beta1 プロジェクトとの統合の改善については別途記載されています pgMonitorのおかげで、オペレーターはすぐに PgSQL メトリクスを明確に視覚化できます。

しかし、Kubernetes で生成されたリソースの奇妙な選択により、別のソリューションを見つける必要が生じました。

3. Zalando Postgres オペレーター

私たちは Zalando 製品を長い間知っています。Zalenium の使用経験があり、もちろん試してみました。パトローニは、PostgreSQL 向けの人気のある HA ソリューションです。会社のものづくりの考え方について Postgres オペレーター著者の一人、アレクセイ・クリューキン氏は放送中にこう語った。 Postgres-火曜日 #5、気に入りました。

これはこの記事で説明されている最も新しいソリューションであり、最初のリリースは 2018 年 1300 月に行われました。ただし、正式リリースの数が少ないにもかかわらず、このプロジェクトは大きな進歩を遂げており、GitHub で 70 個以上のスターを獲得し、最大貢献者数 (XNUMX 人以上) を獲得し、人気ではすでに Crunchy Data のソリューションを上回っています。

このオペレータは「内部では」、実績のあるソリューションを使用しています。

パトローニとゲーム運転に関しては、
ウォーリー - バックアップ用、
Pgバウンサー - 接続プールとして。

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

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

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

Zalando の Postgres Operator を使って練習する

Operator のデプロイは非常に簡単です。GitHub から現在のリリースをダウンロードし、ディレクトリから YAML ファイルを適用するだけです。目録。あるいは、次のように使用することもできますオペレーターハブ.

インストール後は、セットアップについて心配する必要がありますログとバックアップ用のストレージ。これはConfigMapを介して行われます postgres-operator オペレーターをインストールした名前空間内。リポジトリが構成されたら、最初の 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

このマニフェストは、次の形式のサイドカーを含む 3 つのインスタンスのクラスターをデプロイします。 postgres_exporterそこからアプリケーションのメトリクスを取得します。ご覧のとおり、すべては非常に単純で、必要に応じて文字通り無制限の数のクラスターを作成できます。

注目に値する ウェブ管理パネル - postgres-オペレーター-ui。これにはオペレーターが付属しており、クラスターの作成と削除ができるほか、オペレーターが作成したバックアップを操作することもできます。

PostgreSQL クラスターのリスト

バックアップ管理

もう一つの興味深い機能はサポートです。チーム API。この仕組みにより、自動的に PostgreSQL の役割、結果として得られるユーザー名のリストに基づきます。 API を使用すると、ロールが自動的に作成されるユーザーのリストを返すことができます。

問題と解決策

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

nodeSelector のサポートの欠如。
バックアップを無効にできない。
データベース作成機能を使用する場合、デフォルトの権限は表示されません。
定期的に、ドキュメントが不足していたり、古くなったりすることがあります。

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

おそらく、バックアップの登録方法とバックアップバケットをオペレータ UI に接続する方法が必ずしも明確ではないという事実に遭遇するでしょう。ドキュメントではこれについてついでに説明していますが、実際の説明は次のとおりです。 PR:

秘密を作る必要がある。
それをパラメータとしてオペレータに渡します pod_environment_secret_name オペレーター設定を含む CRD 内、または ConfigMap 内 (オペレーターのインストールの決定方法に応じて)。

しかし、結局のところ、これは現時点では不可能です。だからこそ私たちは集めたのですあなたのバージョンのオペレータ追加のサードパーティ開発も含まれます。詳細については、以下を参照してください。

バックアップ用のパラメータをオペレータに渡すと、次のようになります。 wal_s3_bucket AWS S3 のキーにアクセスすると、 すべてをバックアップします: プロダクションの拠点だけでなく、ステージングも行います。これは私たちには合わなかったのです。

演算子を使用する場合の PgSQL の基本的な Docker ラッパーである Spilo のパラメーターの説明で、次のことが判明しました。 WAL_S3_BUCKET 空であるため、バックアップが無効になります。さらに、とても嬉しいことに、 PR準備完了、私たちはすぐにフォークに受け入れました。あとは追加するだけです enableWALArchiving: false PostgreSQL クラスターリソースに接続します。

はい、2 つのオペレーターを実行することで、別の方法で実行する機会がありました。XNUMX つはステージング用 (バックアップなし)、もう XNUMX つは運用用です。しかし、私たちはXNUMXつで間に合わせることができました。

さて、S3 のデータベースへのアクセスを転送する方法を学び、バックアップがストレージに取り込まれ始めました。オペレータ UI でバックアップページを機能させるにはどうすればよいですか?

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

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

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

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

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

そして、私たちに関係のある改善点の最後の点は、パッチ、作成された StatefulSet にノードアフィニティを追加します。当社のクライアントは多くの場合、スポットインスタンスを使用してコストを削減することを好みますが、データベースサービスをホスティングする価値がないことは明らかです。この問題は許容によって解決できますが、ノードアフィニティの存在により、より大きな信頼が得られます。

どうしたの？

上記の問題を解決した結果に基づいて、Zalando の Postgres Operator をフォークしました。あなたのリポジトリ、そんな便利なパッチがまとめられています。さらに利便性を高めるために、 Dockerイメージ.

フォークに受け入れられた PR のリスト:

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

ボーナス！本番移行の成功事例

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

Spilo を使用すると、S3 ストレージ経由でスタンバイクラスターを作成できます。ウォーリー、PgSQL バイナリログが最初に S3 に保存され、次にレプリカによって汲み出されるとき。しかし、持っている場合はどうすればいいですかノー古いインフラストラクチャで Wal-E によって使用されていますか? この問題の解決策はすでにあります提案されましたハブ上で。

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

実際、データベースには数百万行を含むロードされたテーブルがいくつかあり、さらに、それらのテーブルは常に補充され、削除されていました。シンプルなサブスクリプション с copy_data新しいレプリカがマスターからすべてのコンテンツをコピーすると、マスターに追いつくことができなくなります。コンテンツのコピーは XNUMX 週間続けられましたが、マスターには追いつきませんでした。最終的には問題の解決に役立ちました記事 Avito の同僚: 次を使用してデータを転送できます。 pg_dump。このアルゴリズムの (わずかに変更された) バージョンについて説明します。

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

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

マスター — ソースサーバー;
レプリカ1 — 古いプロダクション上のストリーミングレプリカ。
レプリカ2 - 新しい論理レプリカ。

移行計画

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 で最も人気のある XNUMX つの Kubernetes オペレーターを検討した結果、Zalando のプロジェクトを選択しました。いくつかの困難を克服する必要がありましたが、結果は非常に満足できるものでした。そのため、この経験を他の PgSQL インストールにも拡張する予定です。同様のソリューションを使用した経験がある場合は、コメントで詳細を確認できることを嬉しく思います。

PS

私たちのブログもお読みください:

出所： habr.com

Kubernetes 用の PostgreSQL ステートメントの概要、私たちの選択と経験

RDSとは

演算子の選択

1.ストロン

2. クランチデータ PostgreSQL オペレーター

3. Zalando Postgres オペレーター

Zalando の Postgres Operator を使って練習する

問題と解決策

どうしたの？

ボーナス！本番移行の成功事例

移行計画

まとめ

PS

コメントを追加します返信をキャンセル

Kubernetes 用の PostgreSQL ステートメントの概要、私たちの選択と経験

RDSとは

演算子の選択

1.ストロン

2. クランチデータ PostgreSQL オペレーター

3. Zalando Postgres オペレーター

Zalando の Postgres Operator を使って練習する

問題と解決策

どうしたの？

ボーナス！ 本番移行の成功事例

移行計画

まとめ

PS

コメントを追加します 返信をキャンセル

ボーナス！本番移行の成功事例

コメントを追加します返信をキャンセル