As of February 8, 2025 the version 3 and version 4 images are retired and are no longer supported or maintained. Customers still using these versions should upgrade to the latest version (version 5). For details on this retirement and how to upgrade, refer to this Knowledge article.
If this case applies to you, try using the following StatefulSet YAML File:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: molecule
labels:
app: molecule
spec:
selector:
matchLabels:
app: molecule
serviceName: "molecule-service"
replicas: 3
template:
metadata:
labels:
app: molecule
spec:
terminationGracePeriodSeconds: 900
volumes:
- name: molecule-storage
persistentVolumeClaim:
claimName: nfs-claim
securityContext:
fsGroup: 1000
containers:
- image: boomi/molecule:release # Change image to boomi/cloud:release for Boomi Cloud
imagePullPolicy: Always
name: atom-node
ports:
- containerPort: 9090
protocol: TCP
resources:
limits:
cpu: "1000m"
memory: "1024Mi"
requests:
cpu: "500m"
memory: "768Mi"
volumeMounts:
- name: molecule-storage
mountPath: "/mnt/boomi"
readinessProbe:
periodSeconds: 10
initialDelaySeconds: 10
httpGet:
path: /_admin/readiness
port: 9090
livenessProbe:
periodSeconds: 60
httpGet:
path: /_admin/liveness
port: 9090
env:
- name: BOOMI_ATOMNAME
value: "boomi-molecule-nfs"
- name: ATOM_LOCALHOSTID
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: BOOMI_ACCOUNTID
valueFrom:
secretKeyRef:
name: boomi-secret
key: account
- name: INSTALL_TOKEN
valueFrom:
secretKeyRef:
name: boomi-secret
key: token
- name: basic runtime_VMOPTIONS_OVERRIDES
value:
- name: runtime_PROPERTIES_OVERRIDES
value:
Notes:
When using EFS, the runtime Storage Interface (CSI) driver must be deployed to the Cluster to integrate with Amazon EFS. This driver needs to be referenced by both the Storage Class and Persistent Volume configuration files. More on how to do this here.
During a Pod scaledown, Boomi will try to gracefully offboard the cluster node(s) ensuring any running processes complete and remove the cluster node from the platform. The offboarding process involves a series of steps to ensure proper termination of the process and clean up. The amount of time to wait before assuming offboarding has failed is controlled by the Advanced Property 'Async Message Poller Timeout for runtime cluster Scale Down'.
As part of the offboarding process, one of the steps involves waiting for any currently running processes to complete. You can set how long this step should wait before forcefully terminating processes using the Advanced Property 'Force Restart Override for runtime cluster Scale Down'. Forcefully terminated processes will still show an error in Process Reporting, but the error indicates the process was terminated due to the basic runtime stopping. Note that the 'Force Restart Override for runtime cluster Scale Down' must be less than the 'Async Message Poller Timeout for runtime cluster Scale Down' value, or the latter value will be used instead.
Kubernetes also provides a Pod lifecycle hook 'terminationGracePeriodSeconds' that determines how long it will wait for a Pod to shutdown before forcefully terminating it. The property 'terminateGracePeriodSeconds' can be found in the statefulSet.yaml file and in general the value should greater than the values set for the Boomi properties {'Async Message Poller Timeout for runtime cluster Scale Down' and 'Force Restart Override for runtime cluster Scale Down'}
You need to consider the values of all of the above as part of your Boomi deployment on Kubernetes, the Boomi Reference Architecture sets the terminationGracePeriodSeconds to 900 seconds (15 minutes). And the 'Async Message Poller Timeout for runtime cluster Scale Down' and 'Force Restart Override for runtime cluster Scale Down' both default to 600,000 milliseconds (10 minutes). You should determine if these values are appropriate for your implementation, based on the time you wish to wait for running processes to successfully complete, then set all the parameters accordingly. Note the default values for the properties 'Async Message Poller Timeout for runtime cluster Scale Down' and 'Force Restart Override' for runtime cluster Scale Down' are set to 10 minutes but the value for 'Async Message Poller Timeout for runtime cluster Scale Down' should be greater than 'Force Restart Override'. For offboarding, "terminationGracePeriodSeconds" should be greater than "Async Message Poller Timeout for Cluster Scale Down" should be greater than "Force Restart Override for Cluster Scale Down". This dialogue also applies to offboarding a node (example a EC2 instance). If the EC2 k8 node was being scaled down, then kubernetes is smart enough to stop the pods running on that node as well (which in turn will kick off the offboarding logic in our runtime.
Note for the offboarding logic the property 'Force Restart after 'X' Minutes' is not used, 'Force Restart Override for Cluster Scale Down' is used.
You can learn more about the offboarding process from the Community Article about Offboarding Nodes - runtime cluster/Cloud Elasticity.
Due to dependency requirement in the SAP connector and the SAP JCo V2 connector external libraries these are only compatible with the version 5 RHEL images. If you need to use the SAP connector or the SAP JCo V2 connector in a Boomi container based runtime then you must use the version 5 RHEL image. Note that you will still need to follow the Additional basic runtime configuration instructions from the SAP connector help guide or the SAP JCo V2 connector help guide to add the required external libraries.