Deployment best practices
- Last Updated: August 25, 2026
- 4 minute read
- Hybrid Data Pipeline
- Version 5.0
- Documentation
The following best practices help you prepare a production-ready deployment of the Hybrid Data Pipeline Helm chart. Each practice addresses a specific area of operational governance and provides guidance for securing, sizing, and managing your Kubernetes deployment.
- Image governance
- Secret management
- Shared storage hardening
- Logging strategy
- Cluster governance and identity boundaries
- Network exposure
- PostgreSQL resilience
- Compute and storage sizing
- Plugin and initialization governance
- Pod security baseline
- Minimum release gate
Image governance
- Supply
hdp.image.repositoryandhdp.image.tagfrom a customer-approved registry. - Mirror and govern publicly sourced defaults (for example Fluent Bit and PostgreSQL images).
- Prefer digest pinning for production releases.
Secret management
- Do not duplicate credentials in rendered artifacts or configuration files.
- Treat Base64 as encoding only. Enforce encryption at rest (etcd/KMS) and least-privilege Secret access.
- Restrict who can read or update
hdp-secretsand related TLS Secrets.
For details on creating required Secrets, see Creating Kubernetes Secrets for required credentials.
Shared storage hardening
/hdpshare and /logs) with
strict access controls.- Allow write access only to trusted operational identities.
- Protect TLS key material and plugin/driver paths with strict access controls, audit, and backup governance.
- Use storage classes and policies that support your security and retention requirements.
For details on the shared file location, see Obtaining configuration and certificate files to install components
Logging strategy
- Persistent log PVC Enable with
hdp.persistence.logs.enabled=true. Enforce retention policies, access restrictions, and backup controls. - Fluent Bit sidecar collection Enable with
hdp.logCollection.enabled=true. Define explicit outputs, avoidstdoutin production, and route logs to approved destinations.
For details on configuring logs, see Managing and accessing system logs.
Cluster governance and identity boundaries
- Use namespace isolation, strict service account usage standards, and controlled token exposure.
- Disable unnecessary token mounting where feasible in your cluster baseline.
- Enforce admission policies, privileged-role separation, and centralized audit controls at cluster level.
Network exposure
- Ingress mode Use an approved ingress class, managed certificates, and strict ingress annotations and policies. Ensure AGIC is properly configured with TLS enabled.
- Headless external-gateway mode Ensure upstream controls for TLS termination, DNS, WAF, and sticky-session behavior are in place.
hdp.hdpingressconfiguration mode is set to
true.PostgreSQL resilience
postgresql.architecture: standalone. For production
deployments, evaluate and configure the following:- Replication mode and read replica settings
- PodDisruptionBudget values
- Anti-affinity and topology spread constraints
- Failover posture
postgresql:
architecture: replication
primary:
podAntiAffinityPreset: "soft"
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/component: primaryFor details on PostgreSQL configuration, see PostgreSQL replication. For scheduling options, see Advanced pod scheduling.
Compute and storage sizing
- Configure
hdp.resources,hdp.jvmHeap, and PVC sizes from validated capacity planning. - Keep JVM heap below memory limits with safe headroom to reduce OOM risk.
- Add monitoring and alerting for memory pressure, PVC capacity, and restart anomalies.
hdp:
resources:
requests:
memory: 4096Mi
cpu: 2000m
limits:
memory: 4096Mi
cpu: 2000m
jvmHeap: 3072mFor details on resource allocation, see Allocating resources.
Plugin and initialization governance
- Require pre-production validation for all initialization-related changes.
- Maintain auditable approval and rollback procedures for plugin deployments.
- Version-control custom plugins and drivers alongside your manifest files.
For details on deploying plugins, see Integrating data store connectors and authentication plugins.
Pod security baseline
- Non-root execution
- Read-only root filesystem
- Dropped capabilities
- RuntimeDefault seccomp profile
Document any required exceptions centrally and review them periodically. For details on read-only root filesystem configuration, see Mounting the root filesystem as read-only.
Minimum release gate
- Image sources approved and pinned Confirm all runtime images come from approved private registries and are pinned by tag or digest per policy.
- Secrets encrypted at rest and access reviewed Confirm all chart Secrets are in Kubernetes Secrets with encryption at rest enabled and least-privilege access reviewed.
- Shared storage permissions validated Confirm
/hdpshareand/logsaccess controls enforce least-privilege write access and auditable ownership. - Logging mode selected and verified Confirm exactly one log strategy is enabled (PVC or Fluent Bit) and the selected path is validated end-to-end.
- External exposure model validated Confirm only one external access model is active with required TLS, DNS, and WAF controls in place.
- PostgreSQL resilience profile approved Confirm PostgreSQL architecture and disruption settings (PDB, replication posture, scheduling spread) are approved for production resilience goals.
- Capacity and PVC sizing load-tested Confirm Hybrid Data Pipeline resources, JVM heap, and PVC sizes are validated by production-like load and growth testing.
- Cluster governance controls verified Confirm cluster-level admission policy, identity governance, privileged-role separation, and audit controls are enforced for the target namespace.