Preconfigure a Rancher RKE2 cluster for use with Hybrid Manager

Preconfigure a Rancher RKE2 cluster for use with Hybrid Manager#

Prerequisites for AI Factory on Hybrid Manager が完了したら、Hybrid ManagerHMで使用するRancher RKE2クラスターをセットアップする準備がほぼ整います。

ただし、最初に、事前構成とインストールの両方が依存するHelmチャートが必要です。

Helmチャートを構成する#

Helmチャートvalues.yamlは、HMプラットフォームのコア構成であり、インストールの中心です。

事前構成プロセスとインストールフェーズを通じて、Helmチャート values.yaml の更新を参照する手順があります。これらは、事前構成後のインストールフェーズを成功させるために重要です。

EDB Helmリポジトリの追加とチャートの取得#

EDB Cloudsmithトークンを必要とするのは、リポジトリを追加し、構成するチャートを取得することです。

EDB CloudsmithからHelmチャートリポジトリを追加します。

helm repo add enterprisedb-edbpgai "https://downloads.enterprisedb.com/<your-EDB-Cloudsmith-token>/pgai-platform/helm/charts/"

…<your-EDB-Cloudsmith-token> は、EDB Cloudsmithリポジトリアクセストークンです。

リポジトリを更新します。

helm repo update

デフォルトのHelmチャート values.yaml ファイルを取得します。

helm show values enterprisedb-edbpgai/edbpgai-bootstrap > values.yaml

RKE2クラスターの作成#

HMを事前構成およびインストールするには、RKE2クラスターが必要です。 HMインストールを成功させるには、RKE2クラスターを正確に事前構成する必要があります。

このガイドの残りの部分では、完全な事前構成プロセスを説明します。

サポートされているRKE2:Kubernetesバージョンのペア#

HMは現在以下をサポートしています
- RKE2 1.31.X with Kubernetes 1.31.X
- RKE2 1.32.X with Kubernetes 1.32.X

これらの構成のいずれを実装するかがわかったら、クラウドベースの展開用のCSPまたは標準のオンプレミスワークフローを使用して、クラスター作成プロセスを開始します。

ノードサイズとリソースの構成#

HMとその関連コンポーネントをサポートするには、Rancher RKE2クラスター内のノードがリソース要件を満たしている必要があります。

HMを実行するワーカーノードに進む前に、これらのマスターノードを設定する方法については、 Rancher RKE2 を参照してください。

ノードのサイジング#

RKE2マスターノードとKubernetesクラスターが作成された後、HMに必要な2セットのワーカーノード、HMコントロールプレーンノードとHM Postgresデータノードに移動できます。

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

HMコントロールプレーンCPワーカーノードは、以下に概要を説明するように、リソース割り当ての最小要件ワーカーノードの数と各CPU、メモリ、およびディスクサイズを満たしている必要があります。

クラスターに必要なテレメトリスタック特にPrometheusとThanosのサイズは、HM CPノードのスケールアップ/アウトを促進する主な要因です。テレメトリスタックは、CPが監視しているPostgresデータベースの数に応じてスケーリングするため、 CPノードは管理対象データベースの数に応じてスケーリングします。

一般的な推奨事項
- 3 CPノードそれぞれが
  - CPU
    - 最小8 vCPU最大10のPostgresデータベースの場合
    - 推奨中規模のクラスター10〜50のPostgresデータベース用に16 vCPU
    - 50 Postgresデータベースの場合:16+ vCP Us
  - メモリ
    - 最小 32 GB RAM 最大10のPostgresデータベースの場合
    - 推奨 64 GB RAM以上大規模なワークロード10-50のPostgresデータベース用
    - 50 Postgresデータベースの場合 64+ GB RAM
  - Disk
    - 最小100 GB SSD最大10のPostgresデータベースの場合
    - 推奨200 GB SSD10-50のPostgresデータベースの場合
    - 50 Postgresデータベースの場合 >200 GB SSD

Postgresデータノード#

小規模なワークロード5〜20のPostgresデータベースの場合、Postgresデータノードの少なくとも3つのワーカーノードをお勧めします。 Postgresデータベースを約20を超えてスケールアップすると、Postgresワークロード用により多くのワーカーノードが必要になり、最終的には増加するPostgresデータベースをサポートするためにさらに多くのCPノードが必要になる場合があります。

一般的な推奨事項
- 6つのPostgresデータノード、それぞれが次のとおりです。
  - CPU:
    - 推奨16 vCPU
  - メモリ:
    - 推奨:ノードごとに32 GBのRAM
  - ディスク:
    - 最小:ノードごとに100 GBの永続ストレージデータベースとロギングに基づいて調整します要件）。最適なパフォーマンスを得るには、高速ディスクSSDを使用します。

GPUノードのプロビジョニングとオペレーターのセットアップAI / MLのオプション#

モデルの展開にGPU機能を活用する予定がある場合は、次の手順に従って、GPUノードをプロビジョニングおよび有効にします。

Rancherマシンプールの回避策#

Rancher UIは、マシンプールを作成するときにGPUを備えた特定のインスタンスタイプを見逃す場合があります。この回避策を使用して、必要なノードをプロビジョニングします。

任意の標準のインスタンスタイプでマシンプールを作成し、初期レプリカ数を0に設定します。

マシンプール構成を手動で更新して、必要なGPUインスタンスタイプg6e.12xlargeなどを指定します。 Rancherは、この更新フェーズ中に不足しているインスタンスタイプを受け入れる必要があります。

マシンプールを目的の数のGPU対応ノードにスケールアップします。

NVIDIA GPU Operatorのインストール#

GPUノードがプロビジョニングされた後、NVIDIA GPU Operatorをインストールして、KubernetesポッドでGPUリソースを利用できるようにする必要があります。

公式の Rancher RKE2 documentation に従って、NVIDIA GPU Operatorをインストールします。

インストール後、これらの新しいノードに適切なラベルを付け、AI / MLモデルの展開に活用できます。

CP vs Postgresデータノードマシンセットのテイントとラベル#

HM CPノードと、PostgresワークロードをホストするHM Postgresデータノードのさまざまなタイプのノードを使用するには、RKE2がそれぞれ独自のテイントとラベルを持つ2つの異なるマシンセットが必要です。

CPノードのテイントとラベル

spec:
    replicas: 3
    template:
    spec:
        metadata:
        labels:
            edbaiplatform.io/control-plane: "true"
    taints:
    - key: edbplatform.io/control-plane
        value: "true"
        effect: NoSchedule

Postgresデータノードのテイントとラベル

spec:
    replicas: 3
    template:
    spec:
        metadata:
        labels:
            edbaiplatform.io/postgres: “true”
        taints:
        - key: edbplatform.io/postgres
            value: "true"
            effect: NoSchedule

ネットワーキング帯域幅#

各ノードに、HM通信と外部データ転送S3バックアップなどを処理するための十分なネットワーク容量があることを確認します。

ベースラインの推奨事項

Component	Recommended bandwidth	Justification
K8s control plane nodes	1 Gbps+ per node	Handles internal Kubernetes traffic, API server requests, logs/metrics, and orchestration tasks.
Worker nodes (HM)	1 Gbps+ per node	For HM control components, PostgreSQL replication, internode communication, and metrics/logs.
External bandwidth	1-20 Gbps (aggregated)	S3 backups and inter-cluster replication may require high throughput.

ネットワーク構成と要件#

基本計画とネットワーキングアーキテクチャ#

Kubernetesクラスターの作成を終了する前に、一連の高レベルのネットワークとファイアウォールの決定を行う必要があります。これらの選択は、展開プロセスの残りの部分の基礎を形成します。クラウドで展開するかオンプレミスで展開するかにかかわらず、全体的なシーケンスは同じですが、メカニズムが異なります。

高レベルのネットワークの決定#

ネットワークの基本的な特性を決定します。

ネットワークスタック ネットワークはIPv4またはデュアルスタックIPv4 + IPv6ですか？
CNI/ネットワークタイプ コンテナネットワークインターフェイスCNI実装を選択します。例標準のSDNオーバーレイCalico、Cilium、FlannelまたはOVNベースのネットワークCalicoを使用した標準のSDNオーバーレイをお勧めします。
DHCP vs static DHCPがノードアドレスを割り当てるかどうか、または静的IPを割り当てる必要があるかどうかを確認します。

クラウドベースの展開の場合、これらの決定は、CSPのクラスター作成ウィザードの管理オプションにマッピングされることがよくあります。

オンプレミス展開の場合、ネットワークチームはVLAN、サブネット、ルーティング、およびDHCPサーバーを構成する必要があります。

IPアドレスとCIDRの計画#

アーキテクチャに基づいて、オーバーラップを回避するようにアドレス空間を注意深く割り当てる必要があります。これはネットワークのブループリントです。

静的IP#

静的IP

API仮想IP HAコントロールプレーン/APIエンドポイント用
イングレス仮想IP MetalLBのようなオンプレミスLB、またはハードウェアLBによって使用されます
デフォルトゲートウェイIP
DNSサーバーIP
NTPサーバーIP

ネットワーク範囲#

マシンネットワークCIDRアンダーレイ/pnetworkの場合。
Management Network CIDR管理アクセス用。
クラスターネットワークCIDR Kubernetes内のポッドIPアドレスの場合。
Service Network CIDR内部Kubernetesサービスの場合。

ダウンストリームクラスタースペース#

プラットフォームで必要な場合、各ダウンストリームクラスターの/16 IPv4ブロックを予約します。

コアクラスターネットワーキング#

ネットワーク計画が整ったら、次のステップは、クラスターの内部通信ファブリックを有効にし、ポッドレベルで保護することです。これには、コンテナネットワークインターフェイスCNIのインストールまたは確認、およびベースラインネットワークポリシーの適用が含まれます。

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

動作するCNIは、ポッドが相互に通信するために、およびネットワークポリシーのために重要です。

すべてのKubernetesクラスターには、ポッド間のネットワーキングを提供するCNIが必要です。

クラウド展開#

EKSAWS デフォルトでAWS VPC CNIを使用します。これは、VPCからポッドにセカンダリIPを割り当てます。これは、AWSネットワーキングおよびセキュリティグループとネイティブに統合されます。高度なネットワークポリシーまたはeBPF機能が必要な場合は、Calicoポリシーのみを追加するか、Ciliumをインストールできます。
GKE Google Cloud デフォルトでGoogleの管理データプレーンを使用します。これは、ネットワークポリシーをサポートし、Googleのファイアウォールと統合します。サードパーティCNIが必要になることはほとんどありません。

オンプレミス展開#

選択したCNI Calico が推奨されますが、ドキュメントに従って正しくインストールおよび構成されていることを確認します。

RKE2は、デフォルトで有効になったCanal Calico + Flannelを同梱して出荷されています。別のCNIを使用するには、インストール中にCanalを無効にし、優先するCNIを展開します。

この手順により、クラスターの内部ネットワークが機能します。

!!!警告

すべてのノードがReady を報告し、ポッドがポッドCIDRからIPを受信し、クロスノードポッドネットワーキングが機能するまで、続行しないでください。

CNIがアクティブになったら、サービスを外部に公開する前に、ベースライン分離ポリシーをすぐに確立します。

各名前空間のデフォルトのdeny ingressポリシーで開始します。
- DNS egress to CoreDNS.
- コントロールプレーン→Postgresデータノード通信の許可ルールを追加します。

メトリックとロギングパイプライン。

これにより、クラスターは安全な最小権限のベースラインから起動します。

クラウドベースの展開の場合、CNIでポリシーの適用を有効にする必要がある場合がありますAWS VPC CNIのCalicoポリシーモードなど。

オンプレミスシナリオの場合、Calico、Cilium、およびOVN-Kはネイティブにネットワークポリシーを適用します。

ロードバランサーを作成する#

HMをクラウドに展開する場合は、適切なロードバランサーコントローラをインストールまたは有効にしてから、 ServiceまたはIngressリソースを適用してロードバランサーの作成をトリガーします。

外部アクセスとファイアウォールルール#

クラスターの内部ネットワークが実行されているので、外部トラフィックが内部で実行されているサービスに到達する方法を構成します。

オンプレミス展開NodePortまたはカスタムLB#

オンプレミス展開の場合、外部アクセスは通常 NodePort サービスを介して提供されます。

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

必要なポートデフォルトのNodePort値

32542 – HMポータルHTTP
30288 – HMポータルHTTPS
30290 – Beacon gRPC
30292 – Spire TLS

これらのデフォルトを変更する必要がある場合は、Helmチャートの parameters.upm-istio-gateway の下のvalues.yaml を更新します。

ingress_http_node_port: <port>
ingress_https_node_port: <port>
ingress_grpc_tls_node_port: <port>
ingress_spire_tls_node_port: <port>

次に、再定義したポートのファイアウォールを開きます。

クラウドベースの展開ロードバランサー#

クラウドEKS、GKEにHMを展開する場合は、Kubernetes Service LoadBalancer またはIngress リソースを使用します。

EKSで、AWSロードバランサーコントローラをインストールします。 GKEでは、コントローラはビルトインされています。

必要なポートクラウドロードバランサー

443 – HMポータルHTTPSイングレス
8444 – HM内部API
9443 – Beacon gRPC API
9445 – Spire TLS

DNS、TLS、およびアプリケーション構成#

外部アクセスパスが定義されると、サービスに使いやすい名前を割り当て、保護できるようになりました。

DNS構成#

ロードバランサーまたはノードポート構成#

オンプレミスで展開する場合、loadBalancerEnabled をtrue に設定しません。代わりに、Helmチャートのvalues.yaml をそれに応じて構成します。

beaconAgent:
  provisioning:
    loadBalancersEnabled: false
    nodePortDomain: "<your-node-port-domain>"

!!!注

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

外部オンプレミスロードバランサー戦略をノードポート戦略と組み合わせて使用する場合、 nodePortDomain は、Postgresノードプールを指すロードバランサーのFQDNを指す必要があります。このようにして、各Postgresインスタンスに対して生成されたURLは機能します。 metallb (https://metallb.io/)などのロードバランサーコントローラが使用されている場合、トラフィックを適切なノードプールサービスに適切にルーティングするには、別の方法で構成する必要があります。

パブリックドメイン名と内部ドメイン名が、前の手順で構成したエントリーポイントをポイントします。

HMのルートドメイン名を決定した後、Helmチャートのparameters の下のvalues.yaml フィールドが構成されていることを確認します。
global.portal_domain_name: "portal.<root_domain> HMポータルのホスト名。
upm-beacon.server_host: "beacon.<root_domain>" ビーコンサーバーAPIが到達可能なホスト名。
transporter-rw-service:domain_name: "transporter.<root_domain>" 内部トランスポーター移行読み取り/書き込みサービスのドメイン名。
transporter-dp-agent:rw_service_url: "transporter.<root_domain>/transporter"" 内部Transporter移行読み取り/書き込みサービスのURL。
クラウドベースのロードバランサーIPまたはnodePortDomain によってカバーされるノードIPを指すポータルドメインportal_domain_nameのDNS Aレコードを作成します。

TLS証明書管理#

TLS certificates を使用してエンドポイントHMポータルなどを保護します。

これには、DNSホスト名をファイナライズする必要がありますので、前の手順を参照して、正しい名前に証明書を発行できるようにします。

デフォルトのフォールバックオプションとして自動生成の自己署名証明書を使用する Custom certificates を強くお勧めします。

HMポータルの Set up a custom cert-manager issuer for the HM Portal をセットアップし、独自の Bring your own private certificate authority をセットアップすることもできます。

ユーザーID構成#

ユーザーIDを構成するには、独自のIdPを実装するか、HMのネイティブユーザー機能を使用するかを選択する必要があります。

本番でのユーザーアクセスを管理するには、HMで set up your identity provider IdP)を行うことを強くお勧めします。

Changing password for native users はデフォルトでサポートされていますが、実稼働環境ではこの方法でユーザーを管理することはお勧めできません。

最初のネイティブユーザーuser0を作成するには、

ユーザーのメールアドレス、ハッシュ、ユーザーID、ユーザーID、およびユーザー名が必要です。

Parameter	Description
email	ユーザーのメールアドレス。コンソールにアクセスするためのユーザーのログイン識別子としても機能します。
hash	パスワードストアのBcryptハッシュ化されたユーザーパスワード。この値を生成するには、 `echo ${password} I htpasswd -BinC 10 userA I cut -d: -f2`を使用します。ここで、実際のパスワードは`${password}`変数の後ろに保存されます。 `userA`は、パスワードのハッシュプロセス中に使用されるユーザー名を表します。構成内の他の場所で使用されていないため、任意のテキストにすることができます。結果のハッシュのみが利用されます。
userID	静的パスワードで構成された各新しいユーザーには、ユーザーの一意の識別子uuidが必要です。 UUIDジェネレータツールでこの値を生成するか、文字のランダムなシーケンスを手動で割り当てることを選択できます。
username	ユーザーの一意のユーザー名。これは、コンソールにログインするためのプライマリ識別子です。 `email`と同じでもかまいません。

次に、Helmチャートのvalues.yaml のpgai:portal:authentication:staticPasswords の下にこれらの値を設定します。

ネットワークセキュリティポリシーの強化#

サービスが公開され、TLS / DNSが構成されたら、ネットワークポリシーとファイアウォールルールを調整して、より厳密な境界を適用します。

ネットワークポリシー#

Kubernetes NetworkPolicy リソースを作成して、相互に通信できるポッドを制御します。これは、コントロールプレーン、データノード、およびその他のシステムコンポーネント間のトラフィックを保護するために重要です。

上り/下りルール#

境界を強化します。ファイアウォールの上り/下りルールを検証および適用して、必要なトラフィックのみがクラスターへの出入りを許可され、他のすべてのアクセスを制限します。

EDB Postgres AI Platformコンテナイメージを顧客所有のレジストリに同期する#

HMのソフトウェアスタックはEDB Cloudsmithレジストリにプッシュされ、ローカルレジストリで使用するアーティファクトを提供します。Rancher RKE2オンプレミスシナリオの顧客管理内部レジストリまたはクラウドサービスプロバイダーCSPレジストリの顧客管理レジストリ AWS Elastic Container Registry ECR、CSPシナリオのRancherのHMの Google Cloud Artifact Registry AR 。

独自の安全で承認されたローカルレジストリを持っており、以下の同期プロセスでローカルコンテナレジストリのURI、ユーザー、およびパスワードを使用します。インストールするEDB PGAIバージョンを知っている必要があります。この情報により、Cloudsmithからのすべてのアーティファクトは、Helmチャートでソフトウェアスタックをインストールまたはアップグレードする前に、ローカルレジストリと内部同期します。

同期プロセスは、コンテナイメージのSHA256を保持して、さまざまな環境全体でイメージのセキュリティと不変性を保証する必要があります。

edbctlを使用して同期する#

edbctl is installed and configured がまだない場合は確認します。
必要な環境変数を構成します。

取得するEDB PGAIリリースを定義します。

export EDBPGAI_RELEASE=<EDB-pgai-release-version>

EDB Cloudsmithアクセストークンを定義します。

export CS_EDB_TOKEN=<your-Cloudsmith-token>

EDB Cloudsmithレジストリソースを定義します。

export EDB_SOURCE_REGISTRY=pgai-platform

ローカルコンテナレジストリ、ユーザー、およびパスワードを定義します。

export LOCAL_REGISTRY_URI=<your_local_container_registry_uri
export LOCAL_REGISTRY_USER=><your_local_registry_user>
export LOCAL_REGISTRY_PWD=<your_local_registry_password_for_your_user>

sync-to-local-registry コマンドを実行します。

edbctl image sync-to-local-registry \
    --destination-registry-uri "${LOCAL_REGISTRY_URI}" \
    --version "${EDBPGAI_RELEASE}" \
    --source-registry-username "${EDB_SOURCE_REGISTRY}" \
    --source-registry-password "${CS_EDB_TOKEN}" \
    --destination-registry-username "${LOCAL_REGISTRY_USER}" \
  --destination-registry-password "${LOCAL_REGISTRY_PWD}"

EDB PGAI Operatorイメージを宛先レジストリに同期します。

edbctl operator sync-to-local-registry \
    --destination-registry-uri "${LOCAL_REGISTRY_URI}" \
    --version "${EDBPGAI_RELEASE}" \
    --source-registry-username "${EDB_SOURCE_REGISTRY}" \
    --source-registry-password "${CS_EDB_TOKEN}" \
    --destination-registry-username "${LOCAL_REGISTRY_USER}" \
    --destination-registry-password "${LOCAL_REGISTRY_PWD}"

ローカルレジストリがEDBのCloudsmithレジストリと同期されました。

HelmチャートにcontainerRegistryURLを設定する#

containerRegistryURL を、Helmチャート values.yaml で同期されたローカルコンテナレジストリのURLに設定してください。

containerRegistryURL: "<your-local-container-registry-url>"

イメージ検出構成#

イメージ検出は、エージェントビーコンで実行され、Postgresイメージを検出するプロセスです。このプロセスは、顧客管理のローカルコンテナレジストリ OCI compliant である必要がある前の手順を参照してください。 OCI準拠のレジストリはHMでサポートされています。

イメージ検出のためのHelmチャートの構成#

HMのイメージ検出を有効にするには、最初にvalues.yaml のbeaconAgent.provisioning:imageDiscovery の値をtrue に変更します。
次に、 beaconAgent.provisioning:imagesetDiscoveryContainerRegistryURL を、HMがPostsgresコンテナイメージを検出するコンテナレジストリであるため、前の手順でEDBイメージを同期したローカルコンテナレジストリに設定します。
証明書の検証なしでTLS接続を確立する予定がある場合は、 imagesetDiscoveryAllowInsecureRegistry オプションをtrue に設定します。

レジストリの資格情報#

イメージ検出プロセスは、Kubernetesイメージプルシークレットを使用してローカルコンテナイメージレジストリで認証します次のステップを参照してください。したがって、使用されるサービスアカウントまたはプリンシパルには、次の権限が必要です。

リポジトリのリスト
リストタグ
タグマニフェストの読み取り

オンプレミスシナリオ前の手順で設定した構成指示については、ローカルの内部コンテナレジストリのドキュメント quay などを参照して、HMがアクセスできるようにコンテナレジストリに必要なレジストリ権限を構成します。

イメージにCSPベースのローカルレジストリAWS Elastic Container Registry、Google CloudのArtifact RegistryARを使用する場合、次の例をガイドとして使用します。

AWS ECR#

EKSでECRを使用する場合、サポートされている認証タイプはeks_managed_identity のみです。 eks_managed_identity を使用する前に、権限 AmazonEC2ContainerRegistryReadOnly を持つロールを作成し、そのロールをEKSクラスターポッドIDに関連付ける必要があります。

EKS_CLUSTER_NAME="<eks_cluster_name>"
EKS_CLUSTER_REGION="<eks_cluster_region>"
IMAGE_DISCOVERY_IAM_ROLE_NAME="<iam_role_name>"

cat <<EOF > ./image-discovery-trust.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF

aws iam create-role --role-name "${IMAGE_DISCOVERY_IAM_ROLE_NAME}" \
    --assume-role-policy-document file://image-discovery-trust.json

aws iam attach-role-policy --role-name "${IMAGE_DISCOVERY_IAM_ROLE_NAME}" \
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly

IMAGE_DISCOVERY_IAM_ROLE_ARN=$(aws iam get-role --role-name ${IMAGE_DISCOVERY_IAM_ROLE_NAME} | jq -r .Role.Arn)
aws eks create-pod-identity-association --cluster-name "${EKS_CLUSTER_NAME}" \
    --namespace upm-beacon \
    --service-account upm-beacon-agent-k8s \
    --role-arn "${IMAGE_DISCOVERY_IAM_ROLE_ARN}" \
    --region "${EKS_CLUSTER_REGION}"

Google Cloud AR#

Google Kubernetes EngineGKEでGoogle Cloud ARを使用する場合、イメージプルシークレットの生成に使用されるサービスアカウントには、次のロールが必要です。

プロジェクトレベルのroles/artifactregistry.reader
プロジェクトレベルのroles/browser 特に、AR内のリポジトリの取得を許可するには、権限 resourcemanager.projects.list が必要です。

gcloud projects add-iam-policy-binding <PROJECT-ID> \
    --member="serviceAccount:<SERVICE-ACCOUNT-NAME>@<PROJECT-ID>.iam.gserviceaccount.com" \
    --role="roles/artifactregistry.reader"

gcloud projects add-iam-policy-binding <PROJECT-ID> \
    --member="serviceAccount:<SERVICE-ACCOUNT-NAME>@<PROJECT-ID>.iam.gserviceaccount.com" \
    --role="roles/browser"

詳細については、 Google Cloud AR roles documentation および Resource Manager roles documentation を参照してください。

シークレット値の設定#

イメージ検出の構成の最後のステップは、parameters.upm-beacon:image_discovery_secret_name を確認することです。これは、イメージ検出用のコンテナレジストリの資格情報を含むKubernetesシークレットの名前です。デフォルトでは、edb-cred です。

名前空間と予備的なシークレット#

HMの名前空間#

HMコンポーネントの専用の名前空間を作成して、分離と管理性を保証します。

オブジェクトストレージと一般的なKubernetesシークレットの準備#

オブジェクトストレージ資格情報例aws_secret_access_key 、データベースアクセストークン、またはその他の機密情報などの必要な資格情報のKubernetesシークレットを作成します。

ImagePullSecret名前空間と必要なシークレット#

edbctlを使用して、ImagePullSecret名前空間と必要なシークレットを作成します。

必要な名前空間を作成し、シークレットをプルします。

edbctl image-pull-secret create \
  --username <container registry username> \
  --passowrd <container registry passowrd> \
  --registry <local registry URI>

現在のKubernetesコンテキストでProceed? [y/N] とプロンプトが表示されたら、 y を選択します。

次の例のようなものが表示されるはずです。

2025/02/10 10:10:10 Creating Kubernetes Namespaces and ImagePullSecrets with the provided credentials...
2025/02/07 15:29:08 Namespaces and ImagePullSecrets creation completed

ImagePullSecretリストを作成します。

edbctl image-pull-secret list

次の出力例のようなものが表示されます。

Current Kubernetes context is: <your-KubeContext>
Namespace edbpgai-bootstrap: exists, all set!
  Secret edb-cred: exists, all set!
Namespace upm-replicator: exists, all set!
  Secret edb-cred: exists, all set!

認証キーとセキュリティキー#

HMとその基になるコンポーネントには、コンポーネント間の適切な通信を保証し、機密データを保護するために、安全な認証メカニズムが必要です。

キーを生成し、シークレットに保存します#

AES-256暗号化キーを生成します。

HMは、AES-256暗号化を使用して、通信中または保存中の機密データたとえば、データベース資格情報、トークンなどを保護します。ランダムなAES-256暗号化キーを生成するには

export AES_256_KEY=$(openssl rand -base64 32)

キーをKubernetesに保存します。

HMおよび関連サービスがキーにアクセスできるようにするには、適切な名前空間にKubernetesシークレットを作成します。

次のコマンドを実行してシークレットを作成します。

kubectl create secret generic hm-auth-key \
    --namespace <hm-namespace-created-above> \
    --from-literal=aes-256-key=$AES_256_KEY

シークレットを確認します。

kubectl get secret hm-auth-key --namespace <hm-namespace>

Helmチャートの更新#

Helmチャート values.yaml で、フィールド parameters.upm-istio-gateway.cooke_aeskey を前の手順で生成したAES-256暗号化キーに設定します。

その他に必要なシークレット#

Migration Portalの保護#

Create custom secrets for Migration Portal 移行ポータルの内部通信を保護する場合。

ストレージとクラスターの準備#

ブロックストレージ構成#

HMは、すべてのプライマリステートフルワークロードにブロックストレージを使用します。 Kubernetesストレージクラスを使用してパフォーマンスとコストを管理する戦略的アプローチをお勧めします。

ワークロードの分離#

カスタムストレージクラスを定義して使用して、ストレージI/Oプロファイルを特定の種類のワークロードに一致させます。

HM component	Storage type	I/O requirement	Example optimization
HM Control Plane (CP)	Internal DBs and microservices (such as Thanos)	Moderate IOPS, High throughput	Standard SSD tier for internal state.
HM Postgres data nodes	Primary database I/O	High IOPS, low latency	Premium/high-performance SSD tier (crucial for production)

スナップショットクラスオプショナルのCSI対応バックエンドのみ#

ボリュームをプロビジョニングするためのストレージクラスに加えて、CSIドライバーがスナップショットをサポートしている場合、Kubernetes VolumeSnapshotClass を構成することもできます。

これは、 PersistentVolume スナップショットを作成および管理する方法を定義します。
通常、1つまたは2つのスナップショットクラスのみが必要ですたとえば、ストレージバックエンドごとに1つなど。
TopoLVM/ローカルCSIを使用したオンプレミススナップショットはサポートされていません。代わりにHMのオブジェクトストアバックアップメカニズムを使用してください。
クラウド展開またはエンタープライズオンプレミスCSIたとえばPortworx、Ceph RBDは、一般にスナップショットをサポートしています。

!!!注

スナップショットはオブジェクトストアのバックアップを補完しますが、それに置き換えられるものではありません。スナップショットを使用して、同じクラスター内の高速なロールバックとリカバリーを行います。長期保持またはディザスターリカバリーにはオブジェクトストアのバックアップを使用します。

ブロックストレージ戦略とオプションのスナップショット戦略の概要を示します。HM CPおよびPostgresデータノードのワークロード用に特定されたストレージクラス前述の手順を参照してください。およびオプションの VolumeSnapshotClasses を確認すると、適切なCSIドライバーをインストールすることにより、ブロックストレージとオプションのスナップショットを実装する準備が整います。。

クラスター前提条件#

クラスターが 動的ボリュームプロビジョニング をサポートしていることを確認します。

クラウド展開では、これは通常デフォルトで有効になっています。
オンプレミス展開では、選択したCSIドライバーTopoLVM、Portworx、Ceph RBDなどが適切にインストールおよび構成されていることを確認します。

CSIドライバーのインストール#

選択されたStorageClassは、必要なコンテナストレージインターフェイスCSIドライバーを指示します。これにより、クラスターは永続ボリュームを動的にプロビジョニングできます。

永続ストレージドライバー必須
- オンプレミスプライマリユースケース ノード接続ストレージの場合は TopoLVM などのローカルCSIドライバー、またはPortworxまたはCeph RBDなどのエンタープライズドライバーを使用します利用可能な場合。
- クラウド展開代替手段 CSPAWS EBS、GCE PDなどから提供されるCSIドライバーを使用します。
スナップショットコントローラオプショナル、CSI対応バックエンドのみ
- CSIドライバーがスナップショットをサポートしている場合、Kubernetes CSIスナップショットコントローラを有効にし、VolumeSnapshotClass を構成できます。これにより、オペレーションリカバリーのための高速なボリュームレベルのスナップショットが可能になります。
- オンプレミスTopoLVM/ローカルCSI) スナップショットはサポートされていません。データ保護のためにHMのビルトインオブジェクトストアのバックアップと復元を使用します。
- オンプレミススナップショットサポートを備えたエンタープライズCSI ドライバーがサポートしている場合、スナップショットコントローラを有効にできます。
- クラウド ほとんどのクラウドCSIドライバーはスナップショットをサポートしています。短期のロールバックにスナップショットを使用できますが、クロスクラスターリカバリーと長期保持にはオブジェクトストアバックアップを使用します。

Helmチャートの更新#

選択したストレージクラスを作成したら、Helmチャート values.yaml を更新します。

global:
  storage_class: <hm-cp-storage-class>

HM内部サービス用。

KMSキーのセットアップ#

透過的データ暗号化TDEを使用する予定がある場合、 configuring a Key Management Store KMSが必要です。

オブジェクトストレージ構成MinIOセットアップ#

HMでは、データ保護とアーカイブのためにS3互換のオブジェクトストレージMinIOのようなが必要です。このバケットには、すべての非ブロックストレージデータが保存されます。

Postgres WALとバックアップポイントインタイムリカバリーの有効化。
管理対象ストレージの場所。
アーカイブされたログとメトリック。

MinIOユーザーとポリシーの作成#

HMプラットフォームの専用のバケット、ユーザー、およびポリシーを設定します。

MinIO Client `mc <https://min.io/docs/minio/linux/reference/minio-mc.html>`_ をダウンロードし、MinIOインスタンスを管理するためのmc クライアントを構成します。
環境変数を定義します。括弧で囲まれた値を、目的の名前と資格情報に置き換えます。

export MINIO_DEPLOYMENT_NAME=<minio_deployment_name> # deployment name to MinIO
export BUCKET_NAME=<minio_bucket_name> # bucket name
export AWS_ACCESS_KEY_ID=<minio_user_name> # user name
export AWS_SECRET_ACCESS_KEY=<minio_user_password> # users password
export MINIO_POLICY_NAME=<minio_policy_name> # policy to MinIO

mc mb コマンドを使用して MinIO bucket を作成します。
新しいユーザーを作成します。

mc admin user add ${MINIO_DEPLOYMENT_NAME} ${AWS_ACCESS_KEY_ID} ${AWS_SECRET_ACCESS_KEY}

MinIOポリシーを1つ作成します。

cat << EOF > policy.json
{
    "Version" : "2012-10-17",
    "Statement": [
        {
            "Effect" : "Allow",
            "Action" : [
                "s3:*"
            ],
            "Resource" : [
                "arn:aws:s3:::${BUCKET_NAME}",
                "arn:aws:s3:::${BUCKET_NAME}/*"
            ]
        }
    ]
}
EOF

ポリシーを適用します。

mc admin policy create ${MINIO_DEPLOYMENT_NAME} ${MINIO_POLICY_NAME} ./policy.json

ユーザーにポリシーをアタッチします。

mc admin policy attach ${MINIO_DEPLOYMENT_NAME} ${MINIO_POLICY_NAME} --user ${AWS_ACCESS_KEY_ID}

バケットアクセスにシークレットを適用する#

バケットへのHMアクセスのための専用ユーザーを準備した後、作成したユーザーをHMに関連付けてオブジェクトストレージへのアクセスを提供する次のシークレットを作成および適用します。

apiVersion: v1
kind: Secret
metadata:
  name: edb-object-storage # name cannot be changed
  namespace: default # namespace cannot be changed
stringData:
    auth_type: credentials

    # Optional: Used only when the object storage servers certificate is not issued by a well-known CA
    #
    # Base64 string of the CA bundle for the certificate used by the object storage server
    aws_ca_bundle_base64: <aws_ca_bundle_base64>

    # Required: Endpoint URL to the object storage
    aws_endpoint_url_s3: <endpoint-url-to-object-storage>

    # Required: AWS Static Credentials - AWS_ACCESS_KEY_ID
    aws_access_key_id: <AWS_ACCESS_KEY_ID>

    # Required: AWS Static Credentials - AWS_SECRET_ACCESS_KEY
    aws_secret_access_key: <AWS_SECRET_ACCESS_KEY>

    # Required: Bucket name
    bucket_name: <bucket_name>

    # Required: Region of the bucket
    aws_region: <aws_region>

    # Optional: true or false
    # When server-side encryption is disabled, set this to true. By default, its value is false, indicating that server-side encryption is enabled.
    server_side_encryption_disabled: <boolean>

インストールに進む#

クラスターが構成されたら、インストールフェーズ[../installing.mdx]に進みます。

Preconfigure a Rancher RKE2 cluster for use with Hybrid Manager

目次

Preconfigure a Rancher RKE2 cluster for use with Hybrid Manager#

Helmチャートを構成する#

EDB Helmリポジトリの追加とチャートの取得#

RKE2クラスターの作成#

サポートされているRKE2:Kubernetesバージョンのペア#

ノードサイズとリソースの構成#

ノードのサイジング#

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

Postgresデータノード#

GPUノードのプロビジョニングとオペレーターのセットアップAI / MLのオプション#

Rancherマシンプールの回避策#

NVIDIA GPU Operatorのインストール#

CP vs Postgresデータノードマシンセットのテイントとラベル#

ネットワーキング帯域幅#

ネットワーク構成と要件#

基本計画とネットワーキングアーキテクチャ#

高レベルのネットワークの決定#

IPアドレスとCIDRの計画#

静的IP#

ネットワーク範囲#

ダウンストリームクラスタースペース#

コアクラスターネットワーキング#

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

クラウド展開#

オンプレミス展開#

ロードバランサーを作成する#

外部アクセスとファイアウォールルール#

オンプレミス展開NodePortまたはカスタムLB#

クラウドベースの展開ロードバランサー#

DNS、TLS、およびアプリケーション構成#

DNS構成#

ロードバランサーまたはノードポート構成#

TLS証明書管理#

ユーザーID構成#

ネットワークセキュリティポリシーの強化#

ネットワークポリシー#

上り/下りルール#

EDB Postgres AI Platformコンテナイメージを顧客所有のレジストリに同期する#

edbctlを使用して同期する#

HelmチャートにcontainerRegistryURLを設定する#

イメージ検出構成#

イメージ検出のためのHelmチャートの構成#

レジストリの資格情報#

AWS ECR#

Google Cloud AR#

シークレット値の設定#

名前空間と予備的なシークレット#

HMの名前空間#

オブジェクトストレージと一般的なKubernetesシークレットの準備#

ImagePullSecret名前空間と必要なシークレット#

認証キーとセキュリティキー#

キーを生成し、シークレットに保存します#

Helmチャートの更新#

その他に必要なシークレット#

Migration Portalの保護#

ストレージとクラスターの準備#

ブロックストレージ構成#

ワークロードの分離#

スナップショットクラスオプショナルのCSI対応バックエンドのみ#

クラスター前提条件#

CSIドライバーのインストール#

Helmチャートの更新#

KMSキーのセットアップ#

オブジェクトストレージ構成MinIOセットアップ#

MinIOユーザーとポリシーの作成#

バケットアクセスにシークレットを適用する#

インストールに進む#