Using the in-cluster container registry v1.4.0 (LTS)

Related installation phase: Phase 4: Preparing your environment

Prerequisites

• A running Kubernetes cluster meeting the system requirements.
• All cluster nodes deployed on a private subnet with no public IPs (see Security considerations).
• The EDB Postgres AI Operator already installed on the cluster (see Install the EDB Postgres AI Operator).
• edbctl installed and configured on your management workstation.
• kubectl installed and authenticated against the cluster.
• yq (Command-line YAML processor).

The EDB Postgres AI Operator embeds a container registry, defined by the HMRegistry custom resource definition, that can run alongside the operator itself. Enabling the registry doesn't require syncing any additional artifacts beyond the operator image.

Use this registry for air-gapped or fully internal deployments where you either don't have or don't want to maintain a private registry external to HM. After installing the operator, you sync EDB images into the in-cluster registry once, and the rest of the platform pulls from it.

If you have a private registry external to HM that meets your security and operational requirements, prefer it over the in-cluster registry. See Syncing images to a local private registry for that flow.

Security considerations

Create the HMRegistry

HMRegistry is a custom resource that deploys an in-cluster Open Container Initiative (OCI) image registry intended for Hybrid Manager (HM) workloads. The operator provisions a ConfigMap, Deployment, PVC, and Service for the registry, and on OpenShift it also patches image.config.openshift.io/cluster so the cluster's container runtime trusts the registry's NodePort/ClusterIP endpoint as an insecure source.

Create a local file called hm-registry.yaml and add the following content:

apiVersion: edbpgai.edb.com/v1alpha1
kind: HMRegistry
metadata:
  name: hm-registry
  annotations:
    biganimal.enterprisedb.io/deletion-protect: "enabled"
spec:
  mode: Insecure
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1000m
      memory: 4Gi
  storage:
    pvc:
      size: 120Gi

Now run:

kubectl apply -f hm-registry.yaml

You can now follow the creation of the HMRegistry via:

kubectl get hmregistries.edbpgai.edb.com

When finished, you will see output that looks similar to this:

$ kubectl get hmregistries.edbpgai.edb.com hm-registry
NAME          PHASE   MESSAGE               CRI URI           KUBE URI
hm-registry   Ready   HMRegistry is ready   localhost:30183   hm-registry-service.edbpgai-bootstrap.svc.cluster.local:5000

And the Operator will be managing a corresponding ConfigMap, Deployment, PVC, and Service, in the edbpgai-bootstrap namespace. You can see these via:

kubectl get cm,deployment,pods,pvc,svc -n edbpgai-bootstrap

Loading images into HMRegistry

Required Information:

• Release Version: The tag of Hybrid Manager (HM) you intend to install (example:v1.4.0).
• EDB Token: Your access token for docker.enterprisedb.com.

1. Define the EDB release version

   → WrapCopy

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

2. In a separate shell, run

   → WrapCopy

   kubectl port-forward svc/hm-registry-service 5000:5000 -n $EDB_OPERATOR_NAMESPACE

3. Define EDB credentials (Source)

   → WrapCopy

   export CS_EDB_TOKEN=<your-edb-repos-token>
   export EDB_SOURCE_REGISTRY=pgai-platform

4. Sync images into the HMRegistry

   → WrapCopy

   edbctl image sync-to-local-registry \
       --version "${EDBPGAI_RELEASE}" \
       --source-registry-username "${EDB_SOURCE_REGISTRY}" \
       --source-registry-password "${CS_EDB_TOKEN}" \
       --destination-registry-uri "localhost:5000" \
       --insecure-destination-registry

5. Terminate the port-forward running in the separate shell with ctrl-c.

Configure the HybridControlPlane to use the HMRegistry

Update the HybridControlPlane custom resource like so:

kubectl patch hybridcontrolplanes edbpgai --type=merge --patch-file=/dev/stdin <<EOF
  spec:
    hmRegistryRef:
      name: hm-registry
EOF

The Operator then automatically inspects the hm-registry custom resource to find the CRI URI of the registry, and updates the spec.imageRegistry key of the edpbgai HybridControlPlane resource accordingly. No further configuration is necessary.

Switching back to a registry external to HM

If you no-longer wish to use the in-cluster registry, you will need to do the following:

1. Remove the reference to hm-registry from the HybridControlPlane resource

   → WrapCopy

   kubectl patch hybridcontrolplanes edbpgai --type=json -p '[{"op":"remove","path":"/spec/hmRegistryRef"}]'

2. Update HybridControlPlane resource with your container registry URI

   → WrapCopy

   kubectl patch hybridcontrolplanes edbpgai --type=merge --patch-file=/dev/stdin <<EOF
     spec:
       imageRegistry: <your_container_registry_uri>
   EOF

   You may also need to consult Configuring Image Discovery.

3. Disable the deletion-protection on the in-cluster registry

   → WrapCopy

   kubectl patch hmregistries.edbpgai.edb.com hm-registry --type=merge --patch-file=/dev/stdin <<EOF
     metadata:
       annotations:
         biganimal.enterprisedb.io/deletion-protect: disabled
   EOF

4. Delete the hm-registry HMRegistry instance

   → WrapCopy

   kubectl delete hmregistries.edbpgai.edb.com hm-registry

   This will destroy everything associated with the in-cluster HMRegistry in the edbpgai-bootstrap namespace: ConfigMap, Deployment, PVC, and Service.