MCP Server Deployment Optimization for Single-Node Environments

Issue

The MCP server Helm chart failed to deploy on single-node Kubernetes clusters due to excessive CPU resource requests. The default production configuration required 1500 millicores of CPU (3 replicas × 500m each), but the development cluster only had ~100 millicores available, causing scheduling errors and preventing local testing.

Culprit

The Helm chart was optimized for high-availability production environments, including:

• Replica count: 3 pods for redundancy.
• CPU requests: 500m per pod (totaling 1500m).
• Autoscaling: Enabled, allowing dynamic scaling between 3 and 10 pods.
• Storage class: Hardcoded to a non-existent default (e.g., “standard”), incompatible with development clusters like AKS.

The single-node development environment lacked sufficient resources and used a different storage class (e.g., “managed”), exacerbating the deployment failure.

Solution

To enable local development, the Helm values were adjusted to:

• Reduce replica count from 3 to 1 to minimize CPU usage.
• Lower CPU requests from 500m to 100m per pod (a 90% reduction), aligning with the cluster’s constraints.
• Disable autoscaling to prevent unnecessary pod creation.
• Update storage class to match the development cluster’s default (e.g., “managed”).

Outcome: Successful deployment with 93% less CPU usage and 75% less memory consumption, while preserving core functionality for single-node testing.