Capacity Simulator is a small workload simulation service used to generate controlled CPU and memory pressure for the Capacity Advisor demo. It exists to create realistic enough signals so the advisor can analyze workload behavior and provide sizing recommendations.
This simulator is intentionally simple. It is built to support demos, testing, and short-lived AKS or ACA experiments rather than to behave like a production load platform.
The simulator provides an easy way to trigger resource pressure on demand. That makes it possible to test whether the advisor can observe rising usage, detect pressure conditions, and recommend changes based on the current workload state.
The simulator is useful for:
- Triggering CPU and memory load scenarios.
- Reproducing basic throttling or high-memory situations quickly.
- Supporting short demos without depending on a real business workload.
- Making capacity recommendations easier to validate visually and operationally.
The current version is intentionally small:
- One lightweight service.
- Simple API endpoints to start, stop, and inspect simulation state.
- API-key protection for control operations.
- Deployable as a single container in AKS or ACA.
This keeps the simulator fast to deploy and easy to reason about during demos.
The simulator should remain small and disposable. For demo purposes, lower CPU and memory limits can actually be helpful, because they make it easier to trigger saturation and generate visible pressure earlier in the run.
Kubernetes enforces resource limits at runtime and uses resource requests for scheduling placement, so the simulator can be tuned to hit limits quickly without pretending to be a production-grade load generator.
The simulator can be deployed with standard Kubernetes objects such as Deployment, Service, Ingress, and Secret. Sensitive values like SimulatorApiKey should be passed through Kubernetes Secrets rather than stored directly in the deployment configuration.
If only internal cluster traffic is required, the simulator can be exposed through a Service without a public ingress. If external triggering is needed for a demo or test page, it can also be published through Traefik using a standard Kubernetes Ingress.
The simulator configuration is intentionally small. In the current setup, the main protected setting is:
SimulatorApiKey
That value should be injected as an environment variable from a Kubernetes Secret when deployed to AKS.
The simulator is not the main product. Its job is to make the advisor demo believable and repeatable by producing controlled load conditions that another service can observe and assess.
This separation improves the demo architecture because the advisor evaluates a target workload instead of judging itself. That makes the advisory story more realistic while keeping the overall solution small.
This project is part of a practical AIOps showcase. It is meant to support demos, experiments, and short-lived validation scenarios, especially when a fast proof of concept is more valuable than a heavily engineered long-term setup.