Kubernetes Manifests
Relevant source files
The following files were used as context for generating this wiki page:
The Kubernetes Manifests in the MCB project provide a structured framework for deploying the Memory Context Browser as a scalable, high-availability service. These manifests define the orchestration requirements for the MCP server, including its dependencies, scaling policies, and network security configurations. By leveraging Kustomize, the project supports environment-specific overrides, primarily targeting production-grade deployments with robust monitoring and auto-scaling capabilities.
The deployment infrastructure is designed to support the core features of natural language code search, persistent memory, and architecture validation by ensuring the underlying services (such as Milvus, Redis, and PostgreSQL) are correctly integrated within the cluster.
Sources: k8s/README.md:1-15, README.md:10-30
Deployment Architecture
The MCB Kubernetes architecture follows a standard multi-tier pattern where traffic enters through an Ingress controller and is distributed across a set of pods managed by a Deployment controller. The system is designed to scale horizontally between 2 and 10 replicas based on resource utilization and request volume.
Core Components
The deployment is composed of several standard Kubernetes resources:
- Deployment: Manages the MCB application pods, including health checks (Liveness, Readiness, and Startup probes).
- Service: Provides internal load balancing for the pods.
- HPA (Horizontal Pod Autoscaler): Automatically adjusts the number of replicas based on CPU, Memory, and custom metrics.
- ConfigMap & Secrets: Manage environmental variables and sensitive credentials for external providers (e.g., OpenAI, Gemini).
The diagram shows the traffic flow from the internet through the Kubernetes networking stack to the application pods and their backend dependencies.
Sources: k8s/README.md:17-40, k8s/kustomization.yaml:45-48
Configuration and Secrets Management
MCB uses a combination of Kustomize configMapGenerator and secretGenerator to manage environment-specific settings. This allows for a clean separation between application logic and environment configuration.
Secret Categories
The system requires several categories of secrets to function, ranging from database credentials to AI provider API keys:
| Secret Name | Type | Key Literals |
|---|---|---|
mcp-redis-secret | Opaque | redis-url |
mcp-database-secret | Opaque | database-url |
mcp-encryption-secret | Opaque | master-key |
mcp-auth-secret | Opaque | jwt-secret |
mcp-providers-secret | Opaque | openai-api-key, gemini-api-key |
Sources: k8s/kustomization.yaml:26-42
Environment Overrides
Kustomize enables strategic merge patches to inject environment variables into the main Deployment. For example, the ENVIRONMENT variable is sourced directly from a ConfigMap generated during the build process.
Sources: k8s/kustomization.yaml:50-65
Auto-scaling and Resource Management
The project implements aggressive auto-scaling to handle semantic search and indexing workloads. The HPA (HorizontalPodAutoscaler) is configured to monitor both standard and custom metrics.
Scaling Thresholds
- CPU Utilization: Targets 70% average utilization.
- Memory Utilization: Targets 80% average utilization.
- Throughput: Scales at 100 requests per pod.
- Concurrency: Scales at 50 active connections per pod.
Sources: k8s/README.md:73-82
Resource Constraints
To ensure cluster stability, the manifests define explicit resource requests and limits:
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 2000m
memory: 4Gi
Sources: k8s/README.md:84-90
Health Monitoring and Metrics
The MCB server exposes a dedicated metrics endpoint at /api/context/metrics, which is intended to be scraped by a ServiceMonitor for Prometheus integration.
Health Probes
The deployment uses three types of health checks targeting the /api/alive endpoint:
- Liveness: Checked every 10 seconds to ensure the process is running.
- Readiness: Checked every 5 seconds to ensure the pod can accept traffic.
- Startup: Allows for 6 failed attempts during the initial boot sequence.
Sources: k8s/README.md:92-97, tests/e2e/admin-functional.spec.ts:31-40
Key Metrics
The following metrics are exported for monitoring cluster health:
mcp_http_requests_total: Total HTTP request count.mcp_active_connections: Current concurrent connections.mcp_cache_hit_ratio: Efficiency of the Redis cache.
Sources: k8s/README.md:99-105
Security and RBAC
Deployment security is enforced through multiple Kubernetes primitives:
- RBAC: A dedicated
ServiceAccountwith minimal permissions is defined inrbac.yaml. - NetworkPolicy: Controls traffic flow between the MCB pods and their dependencies (PostgreSQL, Redis, Milvus).
- SecurityContext: The application is configured to run as a non-root user.
- TLS: Automated certificate management via
cert-managerfor the Ingress resource.
Sources: k8s/kustomization.yaml:13-22, k8s/README.md:126-132
Summary
The Kubernetes manifests for MCB provide a production-ready deployment strategy focusing on scalability and security. By integrating HPA with custom Prometheus metrics and utilizing Kustomize for secret management, the project ensures that the high-performance MCP server can maintain natural language code search and persistent memory services under varying loads while adhering to Clean Architecture principles in a containerized environment.