Containerized MID Server Autoscaling
Summarize
Summary of Containerized MID Server Autoscaling
Containerized MID Server Autoscaling allows for the deployment and management of MID Servers using Kubernetes, specifically leveraging the Horizontal Pod Autoscaler (HPA) for automatic scaling. This capability ensures that MID Servers can dynamically adjust their number of replicas based on workload demand, enhancing performance and resource efficiency.
Show less
Key Features
- StatefulSet Deployment: MID Servers can be deployed as stateful applications with customizable parameters including name, headless service name, and persistent volume claims (PVC).
- Persistent Storage: The PVC enables the storage of important configuration and metadata files, ensuring continuity during scaling operations.
- Autoscaling with HPA: HPA monitors CPU and memory usage to automatically adjust the number of MID Server replicas, enhancing responsiveness to workload changes.
- YAML Configuration: Deployment requests can be exported and applied as YAML files, facilitating version control and configuration management.
Key Outcomes
By implementing Containerized MID Server Autoscaling, customers can expect:
- Improved resource management through automated scaling based on real-time demand.
- Seamless continuity and state preservation of MID Servers during scaling operations.
- Efficient deployment and configuration management using YAML files, allowing for easier updates and adjustments.
- Enhanced flexibility in deployment environments by allowing changes to be detected and applied automatically during startup.
MID Servers can be deployed via StatefulSet with any number of replicas. They can scale automatically by leveraging Kubernetes Horizontal Pod Autoscaler (HPA). Horizontal Pod Autoscaler automatically updates a workload resource (such as a Deployment or StatefulSet) to match demand.
![]() |
- Name
- Headless service name
- Persistent volume claim (PVC)
- Parameters, such as storage class, access modes, and storage request
- The resource request/limit
The PVC declares the desired persistent volume where the MID Server stores config.xml, meta data files, and several of its sub-folders.
During workload fluctuations, a pod with a running MID Server container can be removed and replaced by a new one. StatefulSet ensures the same persistent volume is attached to the new pod, which allows the MID Server to resume its state.
The only sub-folders that can be mounted to the persistent volume are those that are initially empty with a new MID Server installation. The config.xml file and other meta data files must be backed up when the pod is shut down and restored during start-up.
Deployment requests exported as YAML files can be used to create a StatefulSet workload and new MID Server pods in the Kubernetes cluster.
When you make changes to the deployment YAML file and re-apply it, the existing pods of the deployment are recreated. With StatefulSet deployment, the configuration files are restored from the backup folder. The init script must detect the deployment environment changes and apply them to the configuration files before MID server is started.
HPA Autoscaling activation
HPA Autoscaling can be activated for any existing StatefulSet workload by creating an HPA controller.
When you create a deployment request, you can choose either HPA version 1 or version 2.
When creating a deployment request on the instance with an HPA configuration, apply the exported YAML file and HPA autoscaling begins working immediately.
