コンテナ オーケストレーターを使用して AlloyDB Omni をインストールする

ドキュメントのバージョンを選択してください。 18.1.0

• 最新（18.4.0）
• 18.4.0
• 18.3.0
• 18.1.0
• 17.10.0
• 17.9.0
• 17.7.0
• 17.5.0
• 16.14.0
• 16.13.0
• 16.11.0
• 16.9.0
• 16.8.0
• 16.3.0
• 15.18.0
• 15.17.0
• 15.15.0
• 15.13.0
• 15.12.0
• 15.7.1
• 15.7.0
• 15.5.5
• 15.5.4
• 15.5.2

このページでは、AlloyDB Omni Kubernetes Operator の概要と、これを使用して AlloyDB Omni を Kubernetes クラスタにデプロイする手順について説明します。このページでは、Kubernetes のオペレーションについて基本的な知識があることを前提としています。

標準の Linux 環境に AlloyDB Omni をインストールする手順については、AlloyDB Omni をインストールするをご覧ください。

概要

AlloyDB Omni を Kubernetes クラスタにデプロイするには、Google が提供する Kubernetes API の拡張機能である AlloyDB Omni Kubernetes Operator をインストールします。

Kubernetes ベースの AlloyDB Omni データベース クラスタを構成して制御するには、他の Kubernetes ベースのデプロイと同様に、宣言型のマニフェスト ファイルを kubectl ユーティリティと組み合わせます。AlloyDB Omni CLI は使用しません。これは、Kubernetes クラスタではなく、個々の Linux マシンへのデプロイを目的としています。

ベースイメージ

バージョン 1.5.0 以降では、AlloyDB Omni Operator Kubernetes イメージは Red Hat の Universal Base Image（UBI）9 をベースに構築されています。この移行により、デプロイのセキュリティ、一貫性、コンプライアンスが強化されます。

SHA ダイジェスト イメージ参照

サプライ攻撃を防ぎ、OpenShift 認定の要件を満たすため、AlloyDB Omni Operator は、すべてのコンテナ イメージ参照にバージョンタグではなく SHA-256 ダイジェストを使用します。

• 自動アップグレード: AlloyDB Omni Operator は、内部の ImageCatalog を使用してこれらのダイジェストを管理し、アップグレードに失敗した場合にデータプレーンのロールバックを確実に実行します。

• 有効化: OpenShift 認定パッケージではデフォルトで有効になっていますが、OLM パッケージまたは Helm パッケージのユーザーは、OLM のサブスクリプション構成または Helm チャートの enableDigestImageRefs 値を使用して、ENABLE_DIGEST_IMAGE_REFS 環境変数を true に設定することで、ダイジェスト参照を手動で有効にできます。

始める前に

AlloyDB Omni Operator を使用して Kubernetes クラスタに AlloyDB Omni をインストールする前に、次の要件を満たしていることを確認してください。

ダウンロード オプションまたはインストール オプションを選択する

一般的な Kubernetes クラスタでワークロードを管理する場合は、Helm または OLM を使用できます。Helm は、Helm チャートを使用して、すべての Kubernetes バリアントにオペレーターを含むワークロードをインストールするユニバーサル パッケージ マネージャーです。OLM は、OpenShift プラットフォームで標準かつ推奨される選択肢であり、専用の OLM バンドルを使用してオペレーターのライフサイクルを管理します。

環境とツールに応じて、次のいずれかのデプロイ方法を選択します。

メディア	ダウンロード場所とインストール ガイド	デプロイ先
Helm チャートを使用した AlloyDB Omni Operator	Kubernetes に AlloyDB Omni をインストールする	お客様所有の Kubernetes コンテナ環境（オンプレミス、パブリック クラウド、GKE、Amazon EKS、Azure AKS など） ヒント: 継続的デリバリー（CD）ツールが Helm と統合されている場合は、このオプションを使用します。
OLM バンドルを使用した AlloyDB Omni Operator	OperatorHub.io	お客様所有の Kubernetes コンテナ環境（オンプレミス、パブリック クラウド、Google Kubernetes Engine、Amazon EKS、Azure AKS など） OLM バンドルを使用するには、オペレーターをインストールする前に Kubernetes クラスタに OLM をインストールします。詳細については、olm.operatorframework.io をご覧ください。 ヒント: 継続的デリバリー（CD）ツールですでに OLM を使用している場合は、このオプションを選択します。
OLM バンドルの OpenShift Operator	OpenShift Container Platform ウェブ コンソール	OpenShift 環境 Kubernetes のバリアントである OpenShift は、オペレーターのパッケージ化とデプロイの標準の組み込みメソッドとして OLM を使用します。

アクセス権の確認

以下に対するアクセス権があることを確認します。

• 次のソフトウェアを実行している Kubernetes クラスタ。

  • Kubernetes バージョン 1.21 以降。
  • cert-manager サービス。Helm を使用してインストールされます。
  注: GKE Autopilot クラスタの場合は、--set global.leaderElection.namespace=cert-manager フラグを指定して cert-manager をインストールします。

• kubectl ユーティリティ。

• helm パッケージ管理システムまたは Operator Lifecycle Manager。

ハードウェアとソフトウェアの要件を満たす

Kubernetes クラスタ内の各ノードには、次のものが必要です。

• 2 個以上の x86 CPU または AMD64 CPU。
• 8 GB 以上の RAM。
• Linux カーネル バージョン 4.18 以降。
• 対照群（cgroup）v2 が有効になっている。

AlloyDB Omni Operator をインストールする

本番環境に AlloyDB Omni をデプロイする場合は、本番環境で AlloyDB Omni を実行するをご覧ください。

AlloyDB Omni Operator は、Helm や Operator Lifecycle Manager（OLM）など、さまざまな方法でインストールできます。

注: AlloyDB Omni Operator の Helm チャートは、Cloud Storage で利用できなくなりました。OCI レジストリからダウンロードする必要があります。

Helm

AlloyDB Omni Operator をインストールする手順は次のとおりです。

注: AlloyDB Omni Operator の Helm チャートは Cloud Storage では使用できません。OCI レジストリからダウンロードする必要があります。

1. OCI レジストリから AlloyDB Omni Operator をインストールします。

   helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
   --version 1.7.0 \
   --create-namespace \
   --namespace alloydb-omni-system \
   $(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
   --timeout 5m
   

   インストールが正常に完了すると、次の出力が表示されます。

   NAME: alloydbomni-operator
   LAST DEPLOYED: CURRENT_TIMESTAMP
   NAMESPACE: alloydb-omni-system
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None
   

OLM

Operator Lifecycle Manager を使用して AlloyDB Omni Operator をインストールする手順は次のとおりです。

1. [AlloyDB Omni Operator] ページに移動します。

2. [Install（インストール）] をクリックします。まだインストールしていない場合は、手順に沿って OLM オペレーターと OperatorHub.io カタログのみをインストールします。

3. alloydb-omni-system Namespace がまだ存在しない場合は、作成します。

   kubectl create ns alloydb-omni-system
   

4. オペレーターがクラスタ スコープになるように OLM OperatorGroup を設定します。

   kubectl apply -f - <<EOF
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: operator-sdk-og
     namespace: alloydb-omni-system
   spec:
     upgradeStrategy: Default
   EOF
   

5. OLM サブスクリプション リソースを使用してオペレーターをインストールします。

   kubectl apply -f - <<EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: my-alloydb-omni-operator
     namespace: alloydb-omni-system
   spec:
     channel: stable
     name: alloydb-omni-operator
     source: operatorhubio-catalog
     sourceNamespace: olm
   EOF
   

6. デフォルトの証明書 ClusterIssuer をインストールします。カスタム証明書発行者を使用している場合、この手順は省略可能です。

   kubectl apply -f - <<EOF
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: alloydbomni-selfsigned-cluster-issuer
   spec:
     selfSigned: {}
   EOF
   

OLM

OLM を使用して Red Hat OpenShift 環境に AlloyDB Omni Operator をインストールする手順は次のとおりです。

1. Red Hat OpenShift ウェブ コンソールにログインします。
2. オフライン ユーザーまたは接続されていないユーザーの場合は、oc image mirror などの SHA ダイジェストを保持するツールを使用して、必要なイメージを非公開レジストリに手動でミラーリングする必要があります。公開 gcr.io リポジトリから非公開レジストリにイメージの pull をリダイレクトするように ImageDigestMirrorSet を構成する必要があります。これにより、AlloyDB Omni Operator は、不変の SHA256 ダイジェストを使用して必要なイメージを pull できます。

3. OpenShift ウェブコンソールで、[Operators] > [OperatorHub] に移動します。AlloyDB Omni Operator は、認定カタログとコミュニティ カタログに掲載されています。

4. [AlloyDB Omni Operator] ペインで、[Install] をクリックします。

5. 次のコマンドを実行して、デフォルトの証明書 ClusterIssuer をインストールします。カスタム証明書発行者を使用している場合、この手順は省略可能です。

   kubectl apply -f - <<EOF
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: alloydbomni-selfsigned-cluster-issuer
   spec:
     selfSigned: {}
   EOF
   

GDC コネクテッド ストレージを構成する

AlloyDB Omni Operator を GDC コネクテッドにインストールするには、GDC コネクテッド クラスタではデフォルトのストレージ クラスが設定されないため、追加の手順でストレージを構成する必要があります。AlloyDB Omni データベース クラスタを作成する前に、デフォルトのストレージ クラスを設定する必要があります。

Symcloud Storage をデフォルトのストレージ クラスとして設定する方法については、Symcloud Storage をデフォルトのストレージ クラスとして設定するをご覧ください。

他のすべてのストレージ クラスのデフォルトを変更する方法については、デフォルトの StorageClass を変更するをご覧ください。

データベース クラスタを作成する

AlloyDB Omni データベース クラスタには、プライマリ サーバー、レプリカ、すべてのデータなど、AlloyDB Omni サーバーの実行に必要なすべてのストレージ リソースとコンピューティング リソースが含まれています。

注: HashiCorp Vault などの外部鍵管理サービス（KMS）を使用して保存データを保護するには、TDE 対応クラスタを作成します。

重要: alloydb-omni-system 名前空間にデータベース クラスタを作成しないでください。この Namespace を使用しないことで分離とセキュリティが強化され、Operator と同じ Kubernetes クラスタ内のデータベース リソース間の競合を回避できます。

Kubernetes クラスタに AlloyDB Omni Operator がインストールされたら、次のようなマニフェストを適用して、Kubernetes クラスタに AlloyDB Omni データベース クラスタを作成できます。

apiVersion: v1
kind: Secret
metadata:
  name: db-pw-DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
  databaseVersion: "18.1.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE

次のように置き換えます。

• DB_CLUSTER_NAME: このデータベース クラスタの名前。例: my-db-cluster

• ENCODED_PASSWORD: デフォルトの postgres ユーザーロールのデータベース ログイン パスワード。base64 文字列としてエンコードされます。例: ChangeMe123 の場合は Q2hhbmdlTWUxMjM=

• CPU_COUNT: このデータベース クラスタ内の各データベース インスタンスで使用できる CPU の数。

• MEMORY_SIZE: このデータベース クラスタのデータベース インスタンスあたりのメモリ量。CPU ごとに 8 GB に設定することをおすすめします。たとえば、このマニフェストの前半で cpu を 2 に設定した場合は、memory を 16Gi に設定することをおすすめします。

• DISK_SIZE: データベース インスタンスあたりのディスクサイズ。例: 10Gi

このマニフェストを適用すると、Kubernetes クラスタに、指定されたメモリ、CPU、ストレージ構成を持つ AlloyDB Omni データベース クラスタが含まれます。新しいデータベース クラスタとのテスト接続を確立するには、事前インストールされた psql を使用して接続するをご覧ください。

注: AlloyDB Omni Operator のバージョン 1.1.0 以降では、管理者パスワードの Secret は設定後に削除されなくなりました。新しく設定した Secret は、AlloyDB Omni データベース クラスタの存続期間中保持する必要があります。

その他のマニフェストの例については、Kubernetes 構成のサンプルをご覧ください。Kubernetes マニフェストとその適用方法の詳細については、リソースの管理をご覧ください。

データベース クラスタをスケーリングする

データベース クラスタのコンピューティング リソースをスケーリングするには、db-cluster.yaml マニフェストの cpu 値と memory 値を更新して変更を適用します。スケーリング プロセスは、通常のスケーリング オペレーションとダウンタイムの短いスケーリング オペレーションのどちらを選択するかによって異なります。

通常のスケーリング

スケーリング仕様を更新し、追加の構成なしでマニフェストを適用すると、データベース Pod がすぐに再起動します。これにより、新しいリソース割り当てが有効になるまでの間、プライマリ インスタンスとスタンバイ インスタンスで短いダウンタイムが発生します。

ダウンタイムの短いスケーリング

少なくとも 1 つのスタンバイがある高可用性（HA）クラスタの場合、低ダウンタイム メンテナンス（LDTM）の準備と切り替え戦略を使用して、スケーリング中のダウンタイムを最小限に抑えることができます。この戦略では、まずスタンバイにスケーリングの変更を適用し、迅速なスイッチオーバーを実行してから、元のプライマリ インスタンスに変更を適用します。LDTM 戦略では、スケールアップまたはスケールダウンできます。

低ダウンタイム スケーリングを有効にしてモニタリングする手順は次のとおりです。

1. ダウンタイムの短いスケーリングを有効にします。データベース クラスタに enableLDTM アノテーションを追加します。

   kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true
   

   DB_CLUSTER_NAME は、実際のデータベース クラスタの名前に置き換えます。

2. 更新されたスケーリング仕様を適用します。マニフェストの primarySpec.resources の cpu 値と memory 値を更新し、変更を適用します。

   kubectl apply -f db-cluster.yaml
   

3. スケーリング プロセスをモニタリングします。LDTMScalingInProgress ステータス条件を確認して、オペレーションをモニタリングします。

   kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "LDTMScalingInProgress")'
   

   DB_CLUSTER_NAME は、実際のデータベース クラスタの名前に置き換えます。

   プロセスの進行中は、ステータスが true になります。スケーリングが完了すると、条件のステータスは false に変わります。

制限事項

• LDTM スケーリングは、少なくとも 1 つのスタンバイがある HA クラスタでのみサポートされます。
• 2 つの LDTM オペレーションを同時に実行することはできません。たとえば、LDTM を使用してデータベース クラスタをスケーリングするか、マイナー バージョンのアップグレードを行うことができますが、両方を同時に行うことはできません。
• LDTM スケーリング オペレーションが失敗した場合は、手動でロールバックする必要があります。

次のステップ

• Kubernetes 構成のサンプルを確認する。
• ストレージと PVC のサイズを計画する。
• AlloyDB Omni を実行して接続します。
• AlloyDB Omni を管理する。
• Kubernetes で高可用性を管理する。
• TDE 対応クラスタを作成する。