Percona Kubernates Operator for Percona XtraDB Cluster(PKO)を使ってみる

この記事は最終更新から4年以上経過しています。内容が古くなっている可能性があります。

かつてはステートフルなソフトウェアではKubernatesは難しいということも言われていましたが、最近ではデータベース界隈でも利用が活発化しているように感じます。

MySQLでもα版ですがOperatorを公開していたり、MariaDBでは同社のDBaaSでKubernatesを利用していたりします。

そのような中、Perconaは専用OperatorであるPercona Kubernates Operator for Percona XtraDB Cluster(PKO)GA版としてリリースしています。

今回はそんなPKOについてご紹介したいと思います。

目次

Custom ResourceとOperatorについて

KubernatesのOperatorについて簡単にご説明します。

KubernatesではPod, ReplicaSet, Deploymentというようなリソースと呼ばれる定義を登録する事で複数のコンテナをルールに基づいて動作させたり、スケジューラジョブを実行したりという事を行います。
実際には各リソースには対応するコントローラと呼ばれるプログラムが存在し、リソース定義(マニフェスト)に記述されたあるべき状態になるように半自動的に管理・運用されます。

初期状態で存在するリソース(コアリソース)で十分ニーズが満たせる場合も多くありますが、高可用性要件を持つデータベース等、複雑な運用が必要な場合、既存のリソースで対応できないことがあります。

そのような場合には、要件に合わせたCustom ResourceとCustom Resourceを管理するためのOperatorを作成する必要があります。

PKOはKubernates上で動作するPercona XtraDB Clusterのノード数、状態の監視、障害復旧のプロセスの自動化等を実現するためのCustom ResourceとOperatorです。

検証環境について

今回、検証環境としてのKubernates ClusterはOracle Cloud Infrastructure Container Engine for Kubernetes(OKE) を利用しました。

数ステップですぐ利用を開始でき、非常に簡単ですので興味があればお試しください。

https://docs.cloud.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke.htm

クイックスタートに従い3ノードのワーカーノードを持つOKEを起動しました。

なお、実はPKOはOKE上での動作をテストしていません(ただし恐らく動作するでしょうとの記載があります)。

https://www.percona.com/doc/kubernetes-operator-for-pxc/System-Requirements.html

The following platforms are supported:

  • OpenShift 3.11
  • OpenShift 4.2
  • Google Kubernetes Engine (GKE) 1.13
  • GKE 1.15
  • Amazon Elastic Kubernetes Service (EKS) 1.15
  • Minikube 1.16

Other Kubernetes platforms may also work but have not been tested.

あくまで今回検証用途ということでご理解頂き、もし本番利用されたい方は上記にご注意ください。

以降の内容は、OKEのセットアップ、kubectlの準備が完了し、操作が可能である事を前提とします。

PKOの入手~デプロイ~接続確認

ドキュメントに沿ってデプロイまで行います。

早速以下のコマンドでPKOを入手します。

ここではpxcというネームスペースを作成し、切り替えます。

以下の一連のコマンドを実行すると、デフォルトの状態でPKOの各リソースが起動します。

全てのリソースを確認してみましょう。

図にすると以下の状態です。

クライアント用イメージをデプロイして接続出来ることを確認します。

とても簡単にフルスタックなPXC環境を用意することができました。

PKOのマニフェスト

PKOのリポジトリ以下で基本的にユーザが修正する必要があるのは deploy ディレクトリ以下のマニフェストファイルのみです。
deployディレクトリには以下のファイルが含まれています。

このマニフェストを修正する事で、Kubernatesワーカノードのリソースが許す限りユーザ好みの設定にカスタマイズ可能となっています。

まず修正する必要があるものとして、secrets.yamlがあります。
これにはMySQLユーザのパスワード情報が含まれていますので、必要に応じて修正します。

Kubernatesの仕様上、Secretに含まれるパスワードはbase64エンコードされているため見ただけでは元のパスワードはわかりませんが、
簡単にデコードできますので、実運用時は kubesec 等のツールでマニフェストを暗号化する必要があります。

パスワードはデプロイ後に変更可能です。

次にcr.yamlを確認しましょう。

PKOが提供するCustom Resourceのオプションのリファレンスを確認しつつカスタムしていくこととなります。

最初はupdate関連のセクションが定義されています。
v1.5.0から実装されたSmartUpdate機能がデフォルトで有効です。

これは自動的に最新のマイナーリリースへアップデートしてくれるという非常に便利な機能です。
インターネットに接続していない環境でも、versionServiceEndpointに指定されたPercona社が実行しているバージョン通知サービスと同等のソフトウェアをクラスタ内で実行することも可能です。
理由によりバージョンロックしたい場合はapplyにバージョン番号を指定すると該当バージョン以上にアップデートしないという動作になります。
興味がありましたらマニュアルをご確認ください。

次にpxcセクションではデータベースノードの設定を行います。
複数のパラメータがありますが、configuration(=my.cnfに設定するパラメータ)、resources(=メモリ・CPUの割当)は構築時に変更する事になるでしょう。

Podのスケジューリングポリシはデフォルトでは 同じワーカノード(=ホスト名)にポッドを配置しない という設定です。
マルチリージョン/ゾーン、データベース用のKubernatesワーカノードが存在する場合などはaffinityを修正する必要がでてきます。

設定値はこちらのブログで紹介されています。

kubectl drainを実行し、計画的に縮退運転する場合に最大で1ノードまで許容されるという設定となっています。
3ノード以上の構成などでは増やしてみても良いかもしれません。

ボリュームに関する設定は以下です。
resources.requests.storageのサイズは必ず変更することになるでしょう。
storageClassNameにはクラウドプロバイダによってより高速なディスクが指定可能であったりします。
OKEの場合はこちらに記載があります
なお、OKEでは最低50GiBからですので、6Giと設定されていても50GiBが割り当てられていました。

さらに下部にはhaproxy, proxysqlのセクションがあります。
デフォルトではhaproxyが有効なようですが、HAProxyを実装したチケット内で紹介されている実装の経緯についてのリンクは非公開でした(涙)
各セクションのenabledを有効化することでどちらを使用するか選択できるようになっています。
pxcセクションとは異なり概ねKubernatesとしてのパラメータで構成されているようです。

proxysqlを選択した場合、設定保存用DB(Percona XtraDB Cluster)がサイドカーコンテナとして起動します。
このノードはワークロード上ほとんどスペックを必要としませんが、よりシンプルな仕組みを望まれる場合はhaproxyを選択するのもよいでしょう。
PKO上のProxySQLについてはこちらのブログで紹介されています。

その他としてPMMの監視を開始することも可能です。
以下はPMM ClientのDocker imageに関する設定であることにご注意ください(別途PMM Serverの起動が必要です)。

最後にbackupセクションがあります。
backupは、CronJobリソースとして定期的に実行することも可能であり、またkubectl apply -f deploy/backup.yamlとしてオンデマンドで取得することも可能です。
デフォルトではS3(および互換ストレージ)にバックアップを保存する設定(storages.type = s3)となっています。
ストレージのサイズ、スケジュール等は環境に合わせて修正することとなりそうです。
また、バックアップをどのノードで実行するかという点は運用上意識する必要がありますので、Affinity, TaintsとTolerations
などのスケジューリング設定も調整する必要がでてくるでしょう。

まとめ

今回はPKOのデプロイとマニフェストについてご紹介しました。
ご紹介しきれなかった内容も含め、PKOをデプロイするだけで以下の機能を実現できます。

  • 高可用性(フェイルオーバ・スイッチオーバ・セルフヒーリング)
  • データベースプロキシ
  • スケジュールされたリモート送信可能なバックアップジョブ
  • 監視クライアントの実装
  • 半自動的なアップグレード

ユーザ数も順調に伸びていると見受けられ、Issueも活発に動いているようです。

https://jira.percona.com/projects/K8SPXC/issues/

もし手元にKubernatesを触れる環境がありましたら、ぜひ今のうちに検証してみてはいかがでしょうか。


Percona

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次