Mounting custom Kubernetes resources in Dynamic Engine environments
Customizing Dynamic Engine environments through Kubernetes resource mounting: ConfigMap for non-sensitive configuration, Secret for credentials, volumes for files and certificates, PersistentVolumeClaim for persistent storage, and securityContext for user permissions.
These customization patterns allow you to easily use your custom Kubernetes resources in Dynamic Engine environments for Job and Route tasks running.
These patterns are not mutually exclusive; you can combine them to inject different forms of Kubernetes resources into your Dynamic Engine environment. For example:
- ConfigMap: Non-sensitive configuration (API endpoints, log levels, feature flags)
- Secret as environment variables: Credentials and API keys
- Secret as volumes: Certificates, keystores, and file-based configuration
- PersistentVolumeClaim: Persistent storage shared across pods
- securityContext: Run containers as non-root users with specific user or group identities
Prerequisites and Important considerations
-
You have met the requirements listed in Default Helm deployment.
-
Your Dynamic Engine version must be 1.2.0 or later.
-
A Dynamic Engine environment has been assigned to your Dynamic Engine.
-
Resource creation: You are responsible for creating the ConfigMap, Secrets, and PersistentVolumeClaims before applying the Dynamic Engine configuration. The Dynamic Engine services do not validate the existence of these resources.
-
Namespace: All resources must be created in the same namespace as your Dynamic Engine environment, default to qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID.
No global additionalSpec: No global additionalSpec is available under configuration. You must specify it separately for jobDeployment (Data Integration and Big Data Job tasks) and dataServiceRouteDeployment (Data Service and Route tasks) if you want to apply the same configuration to both.
Activation: You must set enabled: true under additionalSpec to activate the custom configuration.