Containerized MID Server Autoscaling
Summarize
Summary of Containerized MID Server Autoscaling
ServiceNow's Containerized MID Server can be deployed using Kubernetes StatefulSet, allowing for scalable and stateful MID Server instances. This deployment supports automatic scaling through Kubernetes Horizontal Pod Autoscaler (HPA), which adjusts the number of MID Server replicas based on CPU and memory demand. This autoscaling capability ensures that MID Server resources dynamically match workload needs.
Show less
Key Features
- StatefulSet Deployment: MID Servers are deployed as stateful applications, preserving persistent data such as
config.xmland metadata files via Persistent Volume Claims (PVCs). This persistence ensures MID Servers maintain their state even when pods are replaced during scaling events. - Persistent Volume Management: The PVC defines storage parameters including storage class, access modes, and storage requests. Only initially empty sub-folders can be mounted to the persistent volume, and configuration and metadata files must be backed up on pod shutdown and restored on startup.
- Deployment Configuration: Deployment requests are exported as YAML files, which can be applied to create or update StatefulSet workloads. Changes to the YAML trigger recreation of pods, with configuration restoration handled by the StatefulSet init script adapting to environment changes before the MID Server starts.
- Horizontal Pod Autoscaler (HPA): HPA can be enabled for any StatefulSet to manage autoscaling automatically based on resource usage. Customers can select HPA version 1 or 2 during deployment requests, and applying the YAML configuration activates autoscaling immediately.
Practical Benefits for ServiceNow Customers
- Automatic Scaling: Efficient resource utilization by automatically scaling MID Server instances up or down in response to workload demands, minimizing manual intervention.
- State Preservation: StatefulSet and PVC ensure MID Server configurations and metadata persist across pod restarts, providing reliability and continuity.
- Flexible Deployment Management: YAML-based deployment allows easy updates and management of MID Server instances within Kubernetes clusters.
- Immediate Autoscaling Activation: Enabling HPA with deployment requests or on existing StatefulSets allows customers to quickly leverage Kubernetes autoscaling capabilities for MID Servers.
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.