Preparing your environment v1.4.0 (LTS)

Overview

Role focus: Site reliability engineer (SRE) / Infrastructure Engineer

Prerequisites

• Phase 1: Planning your architecture (Completed)
• Phase 2: Gathering your system requirements (Completed)
• Phase 3: Deploying your Kubernetes cluster (Completed & Running)

Outcomes

• A Kubernetes cluster configured with necessary secrets (TLS, Auth, Storage, other necessary secrets)

• Any chosen advanced features configured (IDP, multi-location, KMS for TDE)

• A finalized and validated configuration ready for Hybrid Manager (HM) installation—a HybridControlPlane Custom Resource manifest

Next phase: Phase 5: Install Hybrid Manager

Phase 4 guide

Now that your Kubernetes cluster is running, you must prepare it for the HM platform.

This involves:

1. establishing administrative access through a remote management workstation.
2. staging required artifacts and secrets into the cluster,
3. translating your architectural decisions into the final configuration file.

Creating secrets

Create image pull secret

Use edbctl to create the ImagePullSecret. Doing this gives your Kubernetes cluster access to the EDB registry to pull images required for the installation.

edbctl image-pull-secret create

For more CLI options, see edbctl image-pull-secret.

Create component secrets

Use edbctl to create secrets required by all HM components (core, ai, migration, analytics).

edbctl hybrid-manager create-install-secrets

For more CLI options, see edbctl hybrid-manager. To customize your component's secrets, see Customizing secrets.

Create object storage secret

To implement the object storage requirement, you must create the edb-object-storage Kubernetes secret in the default namespace before installation. For provider-specific configuration and a full parameter reference, see Configuring object storage.

Implementing TLS

You must implement the TLS strategy chosen during the Gathering your system requirements phase. Some TLS strategoes require secrets to be created.

SOP: Implementing TLS certificates describes the implementation options.

Configuring advanced features

Configuring multi-location architecture

Deploying HM across multiple locations (multi-DC) requires significant preparation to ensure the primary and secondary clusters can communicate securely.

You must establish trust domains, sync storage secrets, and configure the HM-internal beacon agent to register the secondary location.

Preparation checklist:

1. Network: Ensure connectivity on ports 8444 (SPIRE) and 9445 (Beacon) between clusters.
2. Storage: Synchronize the edb-object-storage secret across all clusters.
3. Identity: Configure SPIRE federation to allow cross-cluster trust.
4. Configuration: Define unique beacon_location_id values and trust domains in your HM configuration.

• SOP: Configuring multiple data centers for Hybrid Manager
  • Guidance: Detailed steps for setting up SPIRE federation and cross-DC wiring.

Implementing KMS for TDE

If you require encryption at rest for your databases (TDE), you should enable the Key Management Service (KMS) provider and create your keys now.

• SOP: Adding KMS support

Depending on the KMS you are using, refer to the guides below to create the corresponding key.

• HashiCorp Vault
• AWS Key Management Service (KMS)
• Google Cloud Key Management Service (Cloud KMS)

Completing environmental preparation

Name your backup folder

1. Create a new folder to store the HM backups for disaster recovery.
2. Assign a unique folder name (e.g., using a UUID generator) and provide it in your HM configuration under spec.globalParameters.internal_backup_folder.
3. The string must be 12 characters comprised of letters and numbers i.e. internal_backup_folder: "a7462dbc7106".

Add required component configuration

The following component-specific parameters should be added to your HM configuration under spec.componentsParameters:

spec:
  componentsParameters:
    edb-migration-portal:
      enable_pdb: "false"
    upm-api-pnxt-metric:
      log_level: "info"
      tsdb_host: "thanos-query.monitoring.svc.cluster.local"
      tsdb_port: "9090"
    upm-api-pnxt-pd:
      log_level: "info"
    upm-beaco-ff-base:
      aes_key_rotation_interval: 2160h
      usage_generator_interval: 24h
    upm-beaco-usages:
      usage_generator_interval: "24h"
    upm-beacon:
      beacon_location_id: <your-location-id>
      server_host: <your-beacon-server-host>
    upm-istio-gateway:
      enable_server_session: "true"
      openshift_console_domain_name: <your-openshift-console-domain>
    upm-prometheus:
      memory: "4Gi"
    upm-thanos:
      memcached_cpu: "500m"
      memcached_memory: "2Gi"
      query_frontend_cpu: "200m"
      query_frontend_memory: "120Mi"
    upm-trust-manager:
      cert_manager_namespace: "cert-manager"

Finalizing the cluster configuration

You now construct or update the final configuration for your HM installation.

This configuration references your system requirements from Phase 2 and the environment settings and feature configurations you prepared here in Phase 4.

Create the HybridControlPlane Custom Resource

Configure your Hybrid Manager installation as a HybridControlPlane Custom Resource, used with the edb-hcp-operator chart. It provides version management and Kubernetes-native resource handling.

• SOP: Install with the Operator guide for a complete HybridControlPlane manifest template and field mapping reference.

Validating the configuration file, secrets, LoadBalancer, and cluster readiness

Before proceeding to deployment, validate both your configuration file and the runtime environment.

Validate configuration syntax

Validate your configuration file before proceeding.

Use kubectl dry-run to validate your HybridControlPlane manifest:

kubectl apply --dry-run=client -f hybridmanager.yaml

If this command completes without error, your manifest syntax is valid.

Bootstrap method: Ensure your values.yaml can be processed by Helm.

First, run add and update the Helm repository:

helm repo add enterprisedb-edbpgai "https://downloads.enterprisedb.com/${EDB_SUBSCRIPTION_TOKEN}/pgai-platform/helm/charts/"
helm repo update

Then validate your values.yaml against the Helm chart:

helm template edbpgai-bootstrap enterprisedb-edbpgai/edbpgai-bootstrap \
  --values values.yaml \
  --version <target-helm-version> > /dev/null

If this command completes without error, your YAML syntax is valid.

Validate secrets

Ensure the secrets referenced in your configuration exist in the cluster. To list the image pull secrets:

edbctl image-pull-secret list

To list the component secrets:

edbctl hybrid-manager list-install-secrets

Validate LoadBalancer

Verify that your cluster can provision an external load balancer service (required for ingress).

kubectl create service loadbalancer test-lb --tcp=80:80
kubectl get svc test-lb

• Success: If the load balancer controller is functioning, the test-lb service will be assigned an external IP or hostname.
• Cleanup: kubectl delete svc test-lb

Run diagnostic tooling

For a comprehensive check of the cluster's readiness, use the diagnostic plugin.

• SOP: Use kubectl-edb-diagnostic.

Next phase

Now that your management workstation is ready, images are synced, secrets are created, advanced features are configured, your HM configuration is finalized, and your configuration file is validated, you are ready to install HM.

Proceed to Phase 5: Installing Hybrid Manager →