2021.01.20

Kubernetes Operatorに対応するEDB Postgres

文:

タグ

CONTENTS

この記事をシェア:

Facebook Twitter LINE

PostgreSQLのエンタープライズ向けサブスクリプションで最大の実績を持つEnterpriseDBより、KubernetesのOperatorに対応するソリューションのロードマップが公開されました。

本日はEDBがなぜKubernetesに対応するのか?そして、Operatorが必要とされる理由、そもそもOperatorとは?をまとめてみました。

なぜデータベースもKubernetes?

コンテナを使⽤した本番環境は複数のホストでクラスタ構成を組み利⽤される事が通常です。
これは、コンテナ単体では可⽤性が低く、データも揮発性が⾼いといわれるため、複数のコンテナをグループにまとめて管理することで、サービスの停止が許されない本番環境でも高い可⽤性を担保することを⽬的にしています。
また、数百個、時には数万ともなるコンテナを1つ1つ管理していては管理⾯での負担が⾮常に⾼くなるため、Podと呼ばれるグループ単位の管理や⼤規模に展開を行える自動化された運用の仕組みが求められます。

Kubernetes の Operator とは?

Operatorの目標は、これまで人の手で行われていた運用の知識をソフトウェアに組み込むことです(運用のコード化 = IaC : Infrastructure as Code)。

以前は、この運用の知識はシステム管理者により、シェルスクリプトのさまざまな組み合わせ、またはAnsibleのような自動化ソフトウェアにより実現されていました。これはKubernetesクラスターの外側にあり、統合するのが困難でした。

Operatorは、Kubernetesに運用の知識をネイティブに統合することにより、Kubernetesクラスター内で実行されているソフトウェアのデプロイ(インストールから構成)および運用(再構成、更新、バックアップ、フェイルオーバー、復元など)におけるアクティビティを実装および自動化します。

Operatorはコミュニティにより多数公開されており、OperatorHubより検索・取得・利用することができます。

Operator Hub
https://operatorhub.io/

Kubernetes Operatorの自動化レベル

Operatorでは、提供するアプリケーションまたはワークロードのライフサイクル管理機能に関してさまざまなレベルがあります。自動化レベルは、ユーザーがOperatorに期待できる機能を表現するための指標として見ることができます。

OPERATOR CAPABILITIES: https://operatorframework.io/operator-capabilities/

Level1 : Basic Install

利用技術:HELM, ANSIBLE, GO

ワークロードのインストール

  • Operatorがオペランドをデプロイするか、クラスター外のリソースを構成します
  • Operatorは、管理対象リソースが正常な状態に達するのを待ちます
  • Operatorは、カスタムリソースのステータスブロックを利用して、アプリケーションまたは管理対象リソースの準備状況をユーザーに伝えます

ワークロードの構成

  • Operatorは、カスタムリソースの仕様セクションを介して構成を提供します
  • Operatorは、構成と更新を管理対象リソースのステータスと調整します

Level2 : Seamless Upgrades

利用技術:HELM, ANSIBLE, GO

管理対象ワークロードのアップグレード

  • オペランドは、演算子をアップグレードする過程でアップグレードできます。
  • CRの変更の一環としてオペランドをアップグレードできます
  • Operatorは、以前はOperatorの古いバージョンによって管理されていた、古いバージョンのオペランドをアップグレードする方法を理解しています。

Operatorのアップグレード

  • Operatorはシームレスにアップグレードでき、古いバージョンのオペランドを引き続き管理するか、更新することができます
  • Operatorは、CRのステータスセクションで、サポートされていないバージョンのオペランドを管理できないことを伝えます

Level3 : Full Lifecycle

利用技術:ANSIBLE, GO

Operatorは、以下のライフサイクル管理機能の1つ以上を提供します。

  • Operatorは、オペランドのバックアップを作成する機能を提供します
  • Operatorはオペランドのバックアップを復元できます
  • Operatorは、オペランドで複雑な再構成フローを調整します
  • Operatorは、クラスター化されたオペランドのフェイルオーバーとフェイルバックを実装します
  • Operatorは、クラスタ化されたオペランドへのメンバーの追加/削除をサポートします
  • Operatorは、オペランドのアプリケーション対応のスケーリングを可能にします

Level4 : Deep Insights

利用技術:ANSIBLE, GO

モニタリング

  • Operatorがその状態に関するメトリックを公開
  • 演算子は、オペランドに関するヘルスとパフォーマンスのメトリックを公開します

アラートとイベント

  • オペランドは有用なアラートを送信します
  • カスタムリソースはカスタムイベントを発行します


メータリング

  • Operatorはオペレーターメータリングを活用します

Level5 : Auto Pilot

利用技術:ANSIBLE, GO

自動スケーリング

  • Operatorは、オペランドメトリックに基づいて、負荷が増加した場合にオペランドをスケールアップします
  • Operatorは、オペランドメトリックに基づいて、オペランドを特定の負荷以下に縮小します
  • 自動修復
  • Operatorは、オペランドのメトリック/アラート/ログに基づいて、異常なオペランドを自動的に修復できます
  • Operatorは、オペランドのメトリックに基づいて、オペランドが異常な状態に移行するのを防ぐことができます

オートチューニング

  • Operatorは、オペランドを特定のワークロードパターンに自動的に調整できます
  • Operatorは、ワークロードを最適なノードに動的にシフトします

異常検出

  • Operatorは、標準のパフォーマンスプロファイルからの逸脱を判断します

まとめ

Kubernetes Operatorを利用することでコンテナ管理のデプロイから運用までのライフサイクルが自動化できるため、注目度の高い技術になります。EDB社ではこのOperatorへの対応をいち早く開始し、2021年のはじめに第2世代のアーキテクチャをリリースする予定です。

コンテナでのデータベースはエンタープライズレベルでの利用となると信頼性の面で導入をためらう方も多かったのではないでしょうか、EDB Postgres のKubernetes Operatorではこの不安を払拭して、より高いレベルの信頼性を発揮することが期待されています。ぜひ、今後もEDB社のリリースには注目ください。

EDB Japan ブログサイト
https://edbjapan.com/

文:

タグ

今解決したいDXの
お困りごとなんですか?

DXの知識、導入事例を知りたい DXの知識、導入事例を知りたい セミナーに参加する

今取り組むべき事業のDX推進や、本当に活用できるコンテナ製品の導入プランをご紹介しています。お気軽に無料ウェビナーにご参加ください。

何から手をつけていいか分からない 何から手をつけていいか分からない サービスソリューションをみる

DX推進に取り組みたいが詳しい人材がいない。
まずどこから始めればいいのか、どういう方法があるのかイメージが掴め切れていない。

自社の具体的な導入を検討している 自社の具体的な導入を検討している 各種お問い合わせへ

コンテナ製品のご提案や人材育成支援も行います。事業のDX推進でお困りの方は、こちらからお問い合わせください。