このページでは、コンテナオーケストレーターのデプロイオプションを使用して AlloyDB Omni バージョン 18.3.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 オペレーターをインストールします。

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 以降。
- Helm を使用してインストールされた cert-manager サービス。
注: GKE Autopilot クラスタの場合は、次のフラグを使用して cert-manager をインストールします。--set global.leaderElection.namespace=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.8.2 \
--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 オペレータと 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 Subscription リソースを使用してオペレータをインストールします。

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 ウェブコンソールにログインします。
オフラインまたは切断されたユーザーの場合は、oc image mirror などの SHA ダイジェストを保持するツールを使用して、必要なイメージを非公開レジストリに手動でミラーリングする必要があります。公開 gcr.io リポジトリからプライベートレジストリにイメージ pull をリダイレクトするように ImageDigestMirrorSet を構成する必要があります。これにより、AlloyDB Omni Operator は、不変の SHA256 ダイジェストを使用して必要なイメージを pull できます。
OpenShift ウェブコンソールで、[Operators] > [OperatorHub] に移動します。AlloyDB Omni Operator は、認定カタログとコミュニティ カタログに表示されます。
[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 クラスタ内の Operator とデータベースリソース間の競合を回避できます。

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.3.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 マニフェストとその適用方法の詳細については、リソースの管理をご覧ください。

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

データベースクラスタのコンピューティングリソースをスケーリングするには、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 スケーリングオペレーションが失敗した場合は、手動でロールバックする必要があります。