このページでは、コンテナオーケストレーター デプロイオプションを使用する AlloyDB Omni バージョン 18.4.0 について説明します。別のデプロイオプションを選択してください。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

このページでは、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 パッケージのユーザーは、 ENABLE_DIGEST_IMAGE_REFS 環境変数を true に設定することで、ダイジェスト参照を手動で有効にできます。 OLM のサブスクリプション構成または Helm チャートの enableDigestImageRefs 値を使用します。

始める前に

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 クラスタの場合は、cert-manager をこのフラグでインストールします: --set global.leaderElection.namespace=cert-manager

cert-manager の既知の競合状態により、証明書の発行が失敗する可能性があります。この問題が発生する可能性を減らすには、推奨設定で 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）など、さまざまな方法でインストールできます。

Helm

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

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

helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.9.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 をインストールする手順は次のとおりです。

[AlloyDB Omni Operator] ページに移動します。
[Install] をクリックします。まだ行っていない場合は、手順に沿って OLM Operator と OperatorHub.io カタログのみをインストールします。
alloydb-omni-system Namespace がまだ存在しない場合は作成します。
```
kubectl create ns alloydb-omni-system
```

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

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

デフォルトの証明書 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 をインストールする手順は次のとおりです。

Red Hat OpenShift ウェブコンソールにログインします。
オフラインまたは切断されたユーザーの場合は、必要なイメージをプライベートレジストリに手動でミラーリングする必要があります。これには、SHA ダイジェストを保持する oc image mirror などのツールを使用します。ImageDigestMirrorSet を構成して、パブリック gcr.io リポジトリからプライベートレジストリへのイメージ pull をリダイレクトする必要があります。これにより、AlloyDB Omni Operator は不変の SHA256 ダイジェストを使用して必要なイメージを pull できます。
OpenShift ウェブコンソールで、[Operators] > [OperatorHub] に移動します。 [AlloyDB Omni Operator] は、[Certified] カタログと [Community] カタログに表示されます。
[AlloyDB Omni Operator] ペインで、[Install] をクリックします。
次のコマンドを実行して、デフォルトの証明書 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 サーバーの実行に必要なすべてのストレージリソースとコンピューティングリソースが含まれています。

重要: alloydb-omni-system Namespace にデータベースクラスタを作成しないでください。この Namespace を使用しないことで分離とセキュリティが強化され、同じ 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.4.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を使用して接続するをご覧ください。

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

イメージ pull Secret

コンテナイメージに非公開レジストリを使用している場合は、データベースクラスタのイメージ pull Secret を指定できます。AlloyDB Omni Operator は、イメージ pull Secret をデータベースクラスタのサービスアカウント（ DB_CLUSTER_NAME-sa）に伝播します。

イメージ pull Secret を構成するには、データベースクラスタの仕様で Secret 名を指定します。Secret は、データベースクラスタと同じ Namespace に存在する必要があります。

spec:
  primarySpec:
    serviceAccount:
      imagePullSecrets:
      - name: PULL_SECRET_NAME

PULL_SECRET_NAME は、イメージ pull Secret の名前に置き換えます。

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

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

通常のスケーリング

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

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

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

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

ダウンタイムの少ないスケーリングを有効にします。データベースクラスタに enableLDTM アノテーションを追加します。
```
kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true
```
DB_CLUSTER_NAME は、実際のデータベースクラスタの名前に置き換えます。
更新されたスケーリング仕様を適用します。マニフェストの primarySpec.resources の cpu 値と memory 値を更新して、変更を適用します。
```
kubectl apply -f db-cluster.yaml
```
スケーリングプロセスをモニタリングします。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 スケーリングオペレーションが失敗した場合は、手動でロールバックする必要があります。