Gathering your system requirements

目次

Gathering your system requirements#

概要#

前提条件#

結果#

  • *フェーズ3で使用するコンピューティング、ネットワーク、およびストレージインフラストラクチャの検証された高レベルのインベントリ フェーズ3Kubernetesクラスターの展開 *

  • フェーズ4で使用する準備ができているとして検証された多数の要件 :ref:`Preparing your environment <Preparing your environment>` 、およびHM Helmチャートに定義された多数の初期入力 ``values.yaml`` フェーズ4終了時の``values.yaml`` :ref:`Preparing your environment <Preparing your environment>` 。

注釈

EDBのセールスエンジニアリングとプロフェッショナルサービスは、セールスサイクル中または作業ステートメントSoWを介して、詳細な展開要件を伝達および明確にするための主要なリソースです。 公式ドキュメントには、包括的なチェックリストも提供されています。

次のフェーズ フェーズ3 フェーズ3Kubernetesクラスターの展開

アーキテクチャへの接続#

フェーズ2のために以下にリストされている要件は、すべてが汎用的なものではありません。多くは、 ** フェーズ1 アーキテクチャの計画 ** で行われた決定の直接の結果です。

  • ローカリティの決定 は、コントロールプレーンとデータプレーン間のレイテンシー要件を決定します。

  • ディザスターリカバリー目標 は、特定のオブジェクトストレージ構成レプリケーション用の必要性を決定します。

  • アクティブ度アクティブ/アクティブ は、 Postgres Distributedに必要な特殊なネットワーキングが必要かどうかを判断します。

重要

このドキュメントは包括的な技術チェックリストとして機能しますが、 **EDB Professional Services**は、複雑な展開アーキテクチャを検証するための主要なリソースです。フェーズ1の「ターゲット状態」にマルチリージョンの冗長性または高スケールの要件が含まれる場合、インフラストラクチャを調達する前に作業ステートメントSoWを介してこれらの詳細な要件を明確にすることをお勧めします。

導入準備状況チェックリスト#

このチェックリストを使用して、必要なインフラストラクチャコンポーネントをすべて利用できることを高レベルで確認します。

1.管理ワークステーションBastionホスト#

展開をオーケストレーションするには、指定されたマシンが必要です。 これは、ラップトップパブリッククラスターの場合またはクラウドベースのBastionホストプライベートクラスターの場合です。

注釈

Kubernetes API、ポータル、およびPostgreSQLエンドポイントへの安全なプライベートアクセスには、 **Bastion host**またはジャンプホスト/ボックスを強くお勧めします。このホストは、インストールと検証アクティビティのための専用の操作ワークステーションとして機能します。 EDBリモートDBAまたはマネージドサービス契約の場合、専用のBastionは**必須**です。

一般的な要件#

  • オペレーティングシステム Linux AMD64/ARM64またはmacOS。 **注:*Windowsユーザーは WSL2 Linux用Windowsサブシステムを使用する必要があります。

  • ネットワークアクセス *** Kubernetes API: クラスターAPIサーバー通常はポート6443へのネットワーク接続が必要です。* インターネット/レジストリ** Container Registryに到達して、Helmチャートとイメージをプルできる必要があります。

  • ストレージ 最小限構成ファイルと証明書を保持するのに十分な。

必要な工具在庫#

この段階ではこれらのツールをインストールする必要はありません。 ただし、ワークステーション環境で、次のフェーズフェーズ3で次のバイナリのインストールと実行が許可されていることを確認する必要があります。

コアインストールツール

  • edbctl EDBハイブリッドマネージャーCLI

  • kubectl Kubernetes CLI + cnpg プラグイン

  • helm Kubernetesパッケージマネージャー

  • yq コマンドラインYAMLプロセッサー

ユーティリティ

  • curl ダウンロードユーティリティ

  • openssl 証明書管理

  • htpasswd 静的ユーザーを使用する場合にのみ必要

プラットフォームCLI環境に依存します

  • aws AWS CLI

  • gcloud Google Cloud CLI

  • oc OpenShift CLI

操作ツールインストール後

  • pgdcli Postgres Distributed管理

  • sentinel モニタリングとフェイルオーバー管理

2. Kubernetesプラットフォームの検証#

プロビジョニングするクラスターが ** フェーズ1 アーキテクチャの計画 ** フェーズで選択したプラットフォームと一致することを確認します。

サポートされているディストリビューション クラウドサービスプロバイダープラットフォーム Microsoft Azure Amazon EKS Google GKE

オンプレミスプラットフォーム Rancher RKE2 * Red Hat OpenShift RHOS

プロビジョニング制約

  • 専用クラスター クラスターはハイブリッドマネージャー専用である必要があります。他のワークロードとのマルチテナントは サポートされていません 。

  • 関係 1:1 1つのクラスターごとに1つのHM展開。

  • ライフサイクル Kubernetesレイヤーのプロビジョニング、アップグレード、およびスケーリングは自分の責任です。

構成の依存関係#

プラットフォームの選択は、 values.yaml ファイルの特定の値を示します。

次のフェーズに向けてこれらを記録します。

Parameter

YAML Key

Required Value

System Flavor

system

eks, gke, rke2, or rhos

Provider

beaconAgent.provisioning.provider

AWS or GCP (If on cloud)

OpenShift

beaconAgent.provisioning.openshift

Set to true only if using Red Hat OpenShift.

3.コンピューティングノードの要件#

ワーカーノードが ** フェーズ1 アーキテクチャの計画 ** フェーズで定義されたとおりに、目的の展開トポロジの最小サイズとフル機能を満たしていることを確認します。

ハイブリッドマネージャーコンポーネントには、 AMD64/x86-64ノード が必要です。 PostgreSQL自分自身はARM64で実行できますが、混合アーキテクチャクラスターARM64 + AMD64は、HMではサポートされていません。

ノードロールの概要#

Node type

Purpose

Count

Kubernetes nodes

Required label

Control plane

Runs HM control plane & telemetry.

3+

Control or Worker

edbaiplatform.io/control-plane: "true"

Data plane

Runs Postgres databases.

0 or 3+

Worker

edbaiplatform.io/postgres: "true"

AI model (GPU)

Optional: Runs AI/ML workloads.

0 or 2+

Worker

nvidia.com/gpu: "true"

ノードプールAWSノードグループ、RHOSマシンセットなどを使用して、リソースを管理し、必要なラベル/テイントを適用します。

ほとんどの場合、HMはクラウド環境のKubernetesワーカーノードで実行され、管理対象制御ノードへのアクセスがないため。EKSコントロールプレーンアクセスを参照してください。オンプレミスクラスターの制御ノード

see Kubernetes control plane documentation またはワーカーノードで実行できます。

3.1コントロールプレーンノード#

コントロールプレーンのリソース要件は、監視するデータベースの数に応じて増加します。注テレメトリースタックは、モニタリング負荷に応じてスケーリングします。

サイズガイドライン

Resource

Minimum (Up to 10 DBs)

Standard (10–50 DBs)

Large (>50 DBs)

CPU

8 vCPUs

16 vCPUs

16+ vCPUs

Memory

32 GB RAM

64 GB RAM

64+ GB RAM

Disk

100 GB SSD

200 GB SSD

>200 GB SSD

Quantity

3 nodes

3 nodes

3+ nodes

3.2データプレーンノード#

データプレーンノードは、ユーザーがプロビジョニングした PostgreSQL データベースクラスターをホストするようにサイズを調整する必要があります。

  • サイジング 予想されるデータベースワークロード、ストレージ要件、および フェーズ1 アーキテクチャの計画 で定義されたパフォーマンスSLAに完全に依存します。

3.3 AIモデルノード#

  • サイジング 現在の推奨事項では、 Nvidia B200 GPU または同等のサポートされているハードウェアが必要です。

ノードの抽象化#

HMコントロールプレーンが専用リソースで実行され、Postgresワークロードが独立したリソースで実行されるように保証、またはAIワークロードの専用リソースを分割するには、 フェーズ3Kubernetesクラスターの展開 の前にこれらのノードプールに特定の構成を適用する必要があります。

4.ローカルネットワーキング#

ローカルネットワークの要件#

HMは、ローカルネットワーキングロジックについて厳密な意見を持っていません。 アベイラビリティーゾーン間で 低レイテンシーと高帯域幅 を提供する場合、主要なクラウドサービスプロバイダーAWS、Azure、GCPが提供する標準のネットワーキング機能で十分です。

  • オンプレミス 高可用性を保証には、スイッチング、リンクボンディング、およびリンクの冗長性に関するベストプラクティスに従う必要があります。

  • プロトコル IPv4のみ 。 KubernetesはIPv4用に構成する必要があります。 IPv6は、ハイブリッドマネージャー用に完全には製品化されていません。 IPv6が必要な場合、内部通信がIPv4のままであるように、ロードバランサーの背後でマスクする必要があります。

  • 定義されたネットワークアドレス空間CIDR クラスターは、次の個別の非オーバーラップIPレンジで構成する必要があります。 ポッドネットワーク clusterCIDR すべてのポッドにIPが割り当てられるIPレンジ。 サービスネットワークserviceCIDR すべての内部サービスClusterIPに仮想IPが割り当てられるIP範囲。 *ファンクションDNSおよびNTP クラスターの内部DNSサービス通常はCoreDNSが実行されており、内部クラスターサービスたとえばkubernetes.defaultと外部アドレスの両方を解決できる必要があります。

コンテナネットワークインターフェイスCNI

機能的なCNIは、ポッド間ネットワーキングの厳密な要件です。

  • 例 キャリコ、シリウム、フランネル

  • コンテキスト Ciliumは、非常に多くのポッドでより効率的であることが知られています。ただし、 Postgresはハイブリッドマネージャーの中心であるため、データベースI/Oと比較して、極端なポッド密度がボトルネックになることはほとんどありません。スタックを最適化してわずかに良い結果を達成するための追加の努力。顧客のユースケースによっては、それが正当化される場合があります。ただし、多くの場合、優れたソリューションデザインは、インフラストラクチャの制限のほとんどに適応できます。

  • 検証 CNIセットアップとCIDRの割り当てを確認します。

kubectl get nodes -o custom-columns=NAME:.metadata.name,PODCIDR:.spec.podCIDR
kubectl get svc

5.Ingress#

インフラストラクチャ機能に合ったイングレス戦略を選択する必要があります。 次の表は、DNS管理、エンドポイントタイプ、およびSSLターミネーションのサポートされている組み合わせを定義しています。

Scenario

DNS Management

Endpoint Type

Portal SSL/TLS Termination

CSP LB (ELB, ALB)

Manual portal, dynamic postgres

Dynamic via Load Balancer Controller

Istio Ingress Gateway

F5 + F5 K8s Controller

Manual portal, dynamic postgres

Dynamic via Load Balancer Controller

Istio Ingress Gateway

MetalLB

Manual

Dynamic via Load Balancer Controller

Istio Ingress Gateway

NodePort (Conventional LB)

Manual (A record against LB)

Static (manual)

Istio Ingress Gateway

NodePort (No LB)

Manual (Round Robin against Nodes)

Static (manual)

Istio Ingress Gateway

5.1ロードバランサーコントローラー#

ロードバランサーコントローラの例は、AWS Load BalancerコントローラからMetalLBまたはDNS機能とそのF5ロードバランサーコントローラと組み合わせたBigIP F5まであります。

一般要件

  • TCP ロードバランサーは TCPパススルーTCPのみ 用に構成する必要があり、SSLを終端しないでください。 SSLはHM Ingress Gatewayによって終端されます。

  • ファイアウォールの注釈 特定のプロバイダースキームAWSインターネット接続を使用する場合、ロードバランサーを正しくプロビジョニングするための正しいresourceAnnotations がわかっています。

AWSの例のアノテーション

resourceAnnotations:
  - name: istio-ingressgateway
    kind: Service
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing

構成の依存関係

Parameter

YAML Key

Value / Format

Enable LB

beaconAgent.provisioning.loadBalancersEnabled

true

Annotations

resourceAnnotations

Provider-specific list (see below).

スポット検証

コントローラがアクティブであることを確認するには、次のコマンドを使用します。

kubectl get pods -A | grep -i load\|lb\|router\|metallb\|gateway

HMコントロールプレーンポート

以下は、ハイブリッドマネージャーコントロールプレーンのポートです。

Port

Protocol

Description

443

HTTPS

HMポータルHTTPSイングレス

8444

TCP

HM内部API

9443

gRPC

ビーコン gRPC API

9445

TCP

Spire TLS

Postgresポートデータプレーン

適切なロードバランサーが設定されている場合、次はPostgresポートです。

Port

Protocol

Description

5432

TCP

デフォルトPSQL

6432

TCP

PGD接続マネージャーPSQL

5.1.2 NodePort代替#

ロードバランサーが利用できない場合、 NodePort 戦略を使用する必要があります。

  • 構成 HM Helmチャートのvalues.yaml 構成でbeaconAgent.provisioning.loadBalancersEnabled: false を構成し、nodePortDomain を定義する必要があります。

  • コンテキスト デフォルトでは、HMコンポーネントは特定のNodePort値でサービスを公開します。 NodePortを直接使用するか、これらのポートを MetalLB ソフトウェアロードバランサーまたは ハードウェアロードバランサー でフロントして、よりわかりやすいDNS名とフェールオーバーを向上させることができます。

デフォルトのノードポートの割り当て

入力にNodePortを使用する場合、次の特定のポートは NodePort を使用する必要があります。

  • コンストレイン nodePortDomain ベースDNS名を定義する必要があります。

  • コンテキスト HMコンポーネントは、特定のNodePort値でサービスを公開します。 NodePortを直接使用するか、これらのポートのフロントにハードウェアロードバランサーを使用できます。

構成の依存関係

Parameter

YAML Key

Value / Format

Enable LB

beaconAgent.provisioning.loadBalancersEnabled

false

Domain

nodePortDomain

Base DNS domain (e.g., nodes.myorg.com).

デフォルトのノードポートの割り当て

NodePort Variable

Port

Description

ingress_http_node_port

32542

HMポータルHTTP

ingress_https_node_port

30288

HMポータルHTTPS

ingress_grpc_tls_node_port

30290

ビーコン gRPC

ingress_spire_tls_node_port

30292

Spire TLS

ingress_beacon_spire_tls_node_port

30294

ビーコンスパイアTLS

ingress_thanos_query_tls_node_port

30296

ThanosクエリTLSクラスター間メトリック

ingress_fluent_bit_tls_node_port

30298

Fluent-bit TLS クラスター間ログ

enable_server_session

n/a

サーバーストアドセッションを有効にする "true"または"false"

Postgresノードポート

Postgresクラスターは、 NodePortDomain を使用し、ポート範囲30000+ でプロビジョニングされたポートでインクリメントします。

5.2 DNS#

クラスター内と外部アクセスの両方で適切なDNS解決を保証する必要があります。

内部クラスターDNSおよびNTP#

  • CoreDNS クラスターの内部DNSサービス通常はCoreDNSが実行されており、内部クラスターサービスkubernetes.default などと外部インターネットアドレスの両方を解決できる必要があります。

  • NTP: 機能的NTPは、ノード間の時間の同期を保証するために必要です。

  • Container Registry DNSサービスは、コンテナレジストリローカルまたはEDBのDNSエントリを解決できなければなりません。

構成の依存関係#

次のドメインをプロビジョニングおよび制御する必要があります。これらは、次のフェーズでのHM Helmチャート values.yaml の構成への入力です。

Domain Purpose

YAML key

Description

Portal Domain

parameters.global.portal_domain_name

HMポータル UIのホスト名。

Agent Domain

parameters.upm-beacon.server_host

Beacon Server APIが到達可能なホスト名。

Migration Domain

parameters.transporter-rw-service:domain_name

内部Transporter移行サービスのドメイン名。

Migration URL

parameters.transporter-dp-agent:rw_service_url

上記のドメインから派生した完全なURL https://<Migration Domain>/transporter

NodePort Base

beaconAgent.provisioning.nodePortDomain

シナリオBのみ NodePortを使用する場合のPostgresアクセスのベースドメイン。

NodePortアプローチの場合、上記のDNSエントリは、Kubernetesノードでコントロールプレーンラベルが適用されるコンピューティングIPでラウンドロビンである必要があります。

DNS構成戦略#

DNS構成は、Ingressの選択によって異なります。

シナリオAロードバランサー推奨

  • 依存関係 values.yamlで beaconAgent.provisioning.loadBalancersEnabled:が true`であることを確認します。

  • ポータル AWS ELBまたはDNS機能を備えたF5のような最適なロードバランサーコントローラの場合、istio-ingress の結果のロードバランサーIPをポイントするようにDNSを手動で構成します。 KubernetesのイングレスサービスがHTTPS要求のホスト名に従ってトラフィックを適切にルーティングできるように、ドメイン名は ローカルルーティング可能なIP に解決可能である必要があります。

  • Postgres すべてのデータベースのDNSを手動で管理する必要はありません。

Postgres DNSレコードは、ロードバランサーコントローラがそのPostgresクラスター専用の名前空間のサービスのステータスを更新する機能として、自動的に入力されます。

シナリオB:ノードポートの代替

  • 前提条件 ロードバランサーを無効にし、IngressセクションでnodePortDomain を定義しました。

  • ポータル DNSエントリは、 コントロールプレーンノード edbaiplatform.io/control-plane のラベル付けのノードのコンピューティングIPをポイントする ラウンドロビンAレコード である必要があります。

  • Postgres nodePortDomain 値は、すべてのPostgresインスタンスのベースURLとして使用されます。これは、Postgresクラスターが実行されている ワーカーノード のIPアドレスを指す ラウンドロビンDNSレコード である必要があります。

5.3 証明書管理#

安全な通信には、ポータルとAPIエンドポイントのTLS証明書が必要です。 インストールする前に、証明書管理戦略を決定する必要があります。

決定マトリックス#

Option

Description

Typical Use Case

A. Custom cert-manager issuer

既存の`cert-manager`発行者を使用します。

Production (Recommended).

B. Customer CA

独自のCAを使用して内部証明書に署名します。

Enterprises with internal PKI.

C. Customer Certificate

独自の事前生成されたx.509証明書とプライベートキーをKubernetesシークレットとして提供します。

Specific organization-issued cert.

D. Self-signed

インストーラーは自己署名証明書を生成します。

Test/Non-Production only.

戦略別の構成の依存関係#

ストラテジーを選択したら、values.yaml の対応する値を後で、または既に開始している場合はファイルに記録します。

オプションA:カスタム証明書マネージャー発行者

values.yaml でIssuer またはClusterIssuer の種類と名前を指定することにより、証明書の自動処理にcert-managerを活用できます。

Parameter

YAML Key

Value / Format

Issuer kind

parameters.global.portal_certificate_issuer_kind:

<ClusterIssuer or Issuer>

Issuer name

portal_certificate_issuer_name:

<my_issuer>

オプションBカスタムCABYO CA

独自のカスタム証明書マネージャー発行者がない場合は、代わりに独自の認証局CAを使用できます。

  • この戦略では、Kubernetesクラスターを展開した後、Kubernetesシークレットを作成し、values.yaml で指定します。

Parameter

YAML Key

Value / Format

CA Secret

parameters.global.ca_secret_name

Name of the pre-created K8s Secret.

オプションC カスタム証明書BYO証明書

カスタマー証明書マネージャー発行者またはカスタムCAを使用することを選択しない場合、カスタム証明書を使用する必要があります。

  • この戦略では、Kubernetesクラスターを展開した後、Kubernetesシークレットを作成し、values.yaml で指定します。

Parameter

YAML Key

Value / Format

Cert Secret

parameters.global.portal_certificate_secret

Name of the pre-created K8s Secret.

このシークレットには、公開証明書ファイルの証明書チェーン全体と暗号化されていないプライベートキーのエクスポートが必要です。

オプションD 自己署名証明書

構成の依存関係

該当なし、デフォルト

6.ブロックストレージデータベース＆ログ#

永続ストレージボリュームPVCを提供するKubernetes StorageClass を定義する必要があります。

values.yaml の構成は、 HMコントロールプレーン に使用されるデフォルトクラスを定義します。同じストレージクラスは、すべてのPostgresインスタンスの展開のオプションでもあります。ただし、 データプレーン Postgres展開の場合、クラスター内に任意の数の追加ストレージクラスを確立できます。 それらはすべてPostgres展開で使用可能なオプションであり、重要なまたは集中的なワークロードに必要な柔軟性を提供します。

コントロールプレーンの要件#

HMコントロールプレーンのブロックストレージの要求は比較的軽いです。 AWS gp2 の機能とほぼ同等のストレージクラスで十分です。

データプレーンの要件Postgres#

Postgresワークロードは、特定のI/Oパターンによっては、特殊な構成が必要になる場合があります。

  • レイテンシーの感度 Postgresは、一般に生のスループットよりもレイテンシー、特にレイテンシーの 一貫性 に対してより敏感です。

  • 例分析 分析機能は、PVCごとに約 16,000 IOPS 容量で予想通りに実行されます。

  • 例Azure Azureでは、標準レベルと比較して非常に一貫したレイテンシーのため、低IOPS容量をプロビジョニングする場合でも、IOPS対応ストレージプレミアムSSDが非常に優先されます。

重要な考慮事項#

ハイブリッドマネージャーとコンテナ化されたPostgresは、 ローカルストレージ を活用するのに特に適しています。従来のアプリケーションとは異なり、これらのソリューションは、ストレージプロバイダーによってKubernetesクラスター全体で複製されるPVCに厳密には依存しません。 Postgresインスタンスが基になるノードおよびローカルディスクを失った場合、新しいポッドは古いPVCを再マウントする必要はありません。 代わりに、ハイブリッドマネージャーの高可用性HAロジックは、ピアまたはバックアップから新しいノードを再構築します。

構成の依存関係#

構成の依存関係

Parameter

YAML Key

Value / Format

Storage Class

parameters.global.storage_class

The exact name of your K8s StorageClass.

検証#

使用可能なストレージクラスを確認します。

kubectl get sc

6.1ボリュームのスナップショット#

  • オプション 最適なエクスペリエンスに必要です。これがないとバックアップは制限されます。

基になるストレージプロバイダーは ボリュームスナップショットをサポートする必要があります 。プラットフォームのバックアップおよびリカバリー機能を有効にします。

  • メカニズム 機能がKubernetes APIを介して公開されている場合、ハイブリッドマネージャーはボリュームスナップショットを自動的に利用します。

  • 実装ノート *** クラウド: 通常はCSPのCSIドライバーAWS EBS CSIによって処理されますが、多くの場合「スナップショットコントローラ」アドオンのインストールが必要です。* オンプレミス:** ストレージバックエンドはCSIスナップショッター仕様をサポートする必要があり、それにマップするVolumeSnapshotClass を定義する必要があります。

検証#

スナップショットクラスが構成され、使用可能なことを確認します。

kubectl get volumesnapshotclass

7.オブジェクトストレージ#

オブジェクトストレージは、ディザスターリカバリーとデータモビリティのバックボーンです。次の目的で使用されます。

  • VeleroバックアップクラスターDR

  • Postgres WALアーカイブポイントインタイムリカバリー

  • GenAI / AIDBの非構造化データ

  • Lake Keeper用の寄木細工ファイル

一般的な要件#

  • プロトコル 完全な S3互換 である必要があります。

  • 一貫性 複数の場所の展開では、オブジェクトストレージ構成はすべての場所で等しく利用できる必要があります。詳細については、

multi-dc guidance を参照してください。

注釈

default 名前空間に`edb-object-storage` という名前のKubernetes Secretをプロビジョニングする必要があります。 このシークレットの内容は、すべてのクラスターで同一である必要があります。 プロセスのこの時点では、kubectl create secret を実行する必要はありません。 ここでは、生の資格情報APIキー、証明書、パスワードを収集しているため、 Preparing your environment のクラスターに注入する準備が整います。

重要

オブジェクトストレージは完全にハイブリッドマネージャー専用である必要があります。 オブジェクトストレージに存在する以前のデータは、HMの正常なオペレーションを妨げます。 同様に、HMを削除して再インストールした場合、新しいインストールを開始する前にオブジェクトストレージを空にする必要があります。

認証戦略#

プロバイダーがサポートする認証方法を選択します

Provider

Auth Method

Example Use Case

AWS (EKS/ROSA)

Workload Identity (IAM)

Native AWS integration (Recommended).

AWS (Other K8s)

Static Keys

Generic Kubernetes connecting to AWS S3.

Azure Blob

Static Keys

Connect via Connection String/Key.

GCP Storage

Static Keys

Base64-encoded Service Account JSON.

S3 Compatible

Static Keys

On-Premises (MinIO, Ceph, etc.).

構成の依存関係#

構成ファイル#

これらは、フェーズ3で作成するvalues.yaml の影響を受けるキーです。

Parameter

YAML Key

Value / Format

Storage Class

parameters.global.storage_class

The exact name of your K8s StorageClass.

8.コンテナレジストリ#

HMおよびPostgresイメージをホストするには、Kubernetesクラスターからアクセス可能なコンテナレジストリが必要です。

  • 目的 コントロールプレーンとデータプレーンに必要な特定のアプリケーションイメージを提供すること。

  • アクセス要件 クラスターは、このレジストリからイメージをプルできる必要があります。

  • 権限 使用される認証資格情報には、 リポジトリのリスト 、 タグのリスト 、および タグマニフェストの読み取り に対する権限が必要です。

環境がパブリックEDBリポジトリにアクセスできない場合は、アーティファクトをプルし、 edbctl を使用してローカルのプライベートレジストリにプッシュする必要があります。

サポートされているプロバイダーと認証#

Registry provider

Supported Auth

Recommended Auth

Azure (ACR)

Token, Basic

Token

Amazon (ECR)

EKS Managed Identity

EKS Managed Identity

Google (GAR)

Token, Basic

Basic

EDB Repo

Token

Token (PoC/Pilot only!)

構成の依存関係#

プロビジョニングアクション#

  • イメージをローカルコンテナレジストリに同期する プライベートレジストリを使用する場合、edbctl を使用してイメージを同期する必要があります。 * Syncing images to a local private registry

** ガイド edbctl を使用してプラットフォームとオペレーターイメージをミラーリングします。 *

  • シークレット プル資格情報を使用してKubernetesシークレットをプロビジョニングする必要があります。実装の詳細については、 フェーズ4環境の準備 を参照してください。

注釈

イメージ検出の構成 イメージがローカルレジストリに同期したら、それらを見つけるようにインストーラーを構成する必要があります。 これにより、クラスターは正しい場所ローカルレジストリ対パブリックレジストリからアーティファクトをプルします。

**SOP: Image discovery configuration**

** ガイダンス:レジストリミラーとプルポリシーの構成。*

次のフェーズフェーズ3でvalues.yaml に設定するには、これらの特定の値を収集する必要があります。

Parameter

YAML Key

Value / Format

Bootstrap Image

bootstrapImageName

<Registry Domain>/pgai-platform/edbpgai-bootstrap/bootstrap-<K8s_Flavor>

Global Registry

containerRegistryURL

<Registry Domain>/pgai-platform

Discovery Registry

beaconAgent.provisioning.imagesetDiscoveryContainerRegistryURL

<Registry Domain>/pgai-platform

Discovery Auth

beaconAgent.provisioning.imagesetDiscoveryAuthenticationType

<Auth Type> (e.g., token, basic, eks_managed_identity)

TLS Validation

imagesetDiscoveryAllowInsecureRegistry

Set to true if using TL without certificate validation.

9.IDプロバイダーIdP#

ハイブリッドマネージャーは、ユーザー認証を直接提供することを目的としたものではありません**。 外部IDプロバイダーIdPに依存して、ユーザーアクセスを安全に管理します。

9.1外部IdP推奨#

オプショナル 最適なエクスペリエンスとセキュリティのために必要です。

  • メカニズム OIDCを介して既存のディレクトリサービスに接続します。

  • サポートされているバックエンド LDAPまたはSAML。

Preparing your environment フェーズ4用に次の値とアーティファクトを準備する必要があります。

構成の依存関係#

構成ファイル#

Parameter

YAML Key / Resource Name

Value / Format

Client Secret

pgai.portal.authentication.clientSecret

The OIDC client secret string.

Connector Config

pgai.portal.authentication.idpConnectors

List of connector configurations.

Connector Type

...idpConnectors[0].type

Must be ldap or saml (parameters vary by type).

プロビジョニングアクション#

  • CAバンドルシークレット K8sシークレット beaconator-ca-bundle IdPトラストチェーンを含む すべての名前空間 に作成します。

  • Dex Secret K8s Secret upm-dex upm-dex 名前空間に作成します。

9.2 静的ユーザーの代替#

警告

この方法は、運用環境では**強くお勧めしません**。パイロットまたは概念実証アクティビティにのみ使用する必要があります。

  • コンテキスト インストールのために作成される必須の静的User-0 が1つあります。

プロビジョニング時に追加の静的ユーザーを作成できますが、これは安全なパターンではないため、それらを管理するための UIは提供されません 。

  • 最小アクション 必須静的ユーザー User-0 のパスワードを設定する必要があります。

構成の依存関係#

構成ファイル#

このパスを選択する場合、values.yaml で次を構成する必要があります。

Parameter

YAML Key

Value / Format

Password Hash

pgai.portal.authentication.staticPasswords.hash

Bcrypt hash string of the password.

User Email

pgai.portal.authentication.staticPasswords.email

A valid email address (e.g., admin@example.com).

Username

pgai.portal.authentication.staticPasswords.username

The login username (e.g., admin).

User ID

pgai.portal.authentication.staticPasswords.userID

A unique string identifier (e.g., user-0).

10.キー管理サービスKMS#

Postgresデータベースの 透過的データ暗号化TDE を有効にするには、外部キー管理サービスKMSを統合する必要があります。

  • オプション 最適なセキュリティとコンプライアンスのために必要です。

  • メカニズム ハイブリッドマネージャーは、クラウドプロバイダーまたは外部ボールトと統合して、暗号化キーを安全に管理します。

サポートされている認証

  • ワークロードID ネイティブクラウド認証EKS / GKE / AKSで推奨。

  • 資格情報 Kubernetesシークレットに保存されている静的キー。

構成の依存関係#

構成ファイル#

フェーズ4ガイド のvalues.yaml には以下を準備する必要があります。

Parameter

YAML Key

Value / Format

KMS Providers

beaconAgent.transparentDataEncryptionMethods

List of enabled providers (e.g., aws-kms, google-cloud-kms).

Auth Strategy

auth_type (nested under provider)

workloadIdentity or credentials.

  • 認証シークレット credentials モードを使用する場合、特定のKubernetesシークレットをAPIキーでプロビジョニングする必要があります。

構成への影響#

このドキュメントで詳細に説明されているインフラストラクチャ仕様は、フェーズ1でのアーキテクチャの決定と組み合わせて、次のフェーズで使用する値を決定します。

フェーズ3に進む前に、この マスターインベントリ を使用して、必要な値がすべてあることを確認します。

一般&プラットフォーム#

Source

Requirement

YAML Key

Condition

Phase 1

K8s Flavor

system

Required (e.g., eks, gke, rhos)

Phase 1

Provider

beaconAgent.provisioning.provider

Required (e.g., AWS, GCP)

Phase 1

OpenShift

beaconAgent.provisioning.openshift

Required if using RHOS (true)

Phase 1

Location

parameters.upm-beacon.beacon_location_id

Required (String ID)

ネットワーキングとIngress#

Source

Requirement

YAML Key

Condition

Phase 2

Portal Domain

global.portal_domain_name

Required

Phase 2

Agent Domain

upm-beacon.server_host

Required

Phase 2

Migration Domain

transporter-rw-service:domain_name

Required

Phase 2

Migration URL

transporter-dp-agent:rw_service_url

Required

Phase 2

Load Balancer

beaconAgent.provisioning.loadBalancersEnabled

Required (true or false)

Phase 2

LB Annotations

resourceAnnotations

Required if using CSP LB (e.g., AWS)

Phase 2

NodePort Domain

nodePortDomain

Required if loadBalancersEnabled is false

ストレージとレジストリ#

Source

Requirement

YAML Key

Condition

Phase 2

Storage Class

parameters.global.storage_class

Required

Phase 2

Global Registry

containerRegistryURL

Required

Phase 2

Bootstrap Image

bootstrapImageName

Required

Phase 2

Discovery Reg.

beaconAgent.provisioning.imagesetDiscoveryContainerRegistryURL

Required

Phase 2

Registry Auth

`beaconAgent.provisioning.imagesetDiscoveryAuthenticationType `

Required

Phase 2

Insecure TLS

imagesetDiscoveryAllowInsecureRegistry

Optional (If using self-signed registry)

セキュリティとID#

Source

Requirement

YAML Key

Condition

Phase 2

IDP Secret

pgai.portal.authentication.clientSecret

Required (if using OIDC)

Phase 2

IDP Config

pgai.portal.authentication.idpConnectors

Required (if using OIDC)

Phase 2

Static User

pgai.portal.authentication.staticPasswords.*

PoC Only (if no IdP)

Phase 2

TDE Keys

beaconAgent.transparentDataEncryptionMethods

Optional (if using TDE)

証明書 (戦略を1つ選択してください)#

いずれか 戦略A、B、C、またはDを選択し、対応する値を記録します。

Strategy

YAML Key

Description

A. Cert Manager

parameters.global.portal_certificate_issuer_kind

必須。 リソース種類たとえば ClusterIssuer

A. Cert Manager

portal_certificate_issuer_name

必須。 リソース名たとえば letsencrypt-prod

B. BYO CA

parameters.global.ca_secret_name

必須。 CAシークレットの名前。

C. BYO Cert

parameters.global.portal_certificate_secret

必須。 証明書シークレットの名前。

D. Self-signed

N/A

デフォルトの動作 構成は必要ありません。

例 values.yaml#

前の手順で行った決定に従って、values.yaml は既に開始している場合、これらの選択を反映する必要があります。

これは、すべてのオプションを使用してインストールするための運用指向のvalues.yaml の例です。「最適なエクスペリエンスに必要」。 これから始める場合、または既にvalues.yaml を開始している場合、上記の最適なエクスペリエンスに必要なオプションを使用していない場合、構成ファイルは異なる場合があります。

system: <Kubernetes>
bootstrapImageName: <Container Registry Domain>/pgai-platform/edbpgai-bootstrap/bootstrap-<Kubernetes>
bootstrapImageTag: <Version>
containerRegistryURL: "<Container Registry Domain>/pgai-platform"
parameters:
  global:
    portal_domain_name: <Portal Domain>
    storage_class: <Block Storage>
    portal_certificate_issuer_kind: <ClusterIssuer>
    portal_certificate_issuer_name: <my-issuer>
    trust_domain: <Portal Domain>
  upm-beacon:
    beacon_location_id: <Location>
    server_host: <Agent Domain>
  transporter-rw-service:
    domain_name: <Migration Domain>
  transporter-dp-agent:
    rw_service_url: https://<Migration Domain>/transporter
beaconAgent:
  provisioning:
    imagesetDiscoveryAuthenticationType: <Authentication Type for the Container Registry>
    imagesetDiscoveryContainerRegistryURL: "<Container Registry Domain>/pgai-platform"
  transparentDataEncryptionMethods:
    - <available_encryption_method>
pgai:
  portal:
    authentication:
      idpConnectors:
        - config:
            caData: <base64 encyrption of Certificate Authority from SSO provider>
            emailAttr: email
            groupsAttr: groups
            entityIssuer: https://<Portal Domain>/auth/callback
            redirectURI: https://<Portal Domain>/auth/callback
            ssoURL: https://login.microsoft.com/<azure service identifier>/saml2
            usernameAttr: name
          id: azure
          name: Azure
          type: saml
resourceAnnotations:
  - name: istio-ingressgateway
    kind: Service
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-scheme: internal
      service.beta.kubernetes.io/load-balancer-source-ranges: 10.0.0.0/8

次のフェーズ#

これで、完全なインベントリとデプロイメント戦略と、HM Helmチャート values.yaml へのいくつかの入力ができました。途中でファイルをビルドする場合は今すぐ追加します、または Preparing your environment の最後にファイルをビルドするための入力として使用します。

** フェーズ3Kubernetesクラスターの展開 に進んで、Kubernetesクラスターをプロビジョニングおよび展開します。**

目次