| Filename | Latest commit message | Latest commit date |
|---|---|---|
## Summary Follow-up to #1215 and #1220. Both of those addressed *individual* slow queries; this PR addresses *concurrency* — under today's scraper load the cursor query is fast on average (mean 42ms) but the connection pool saturates and queue depth blows up at the Go HTTP layer. ## Diagnosis `pg_stat_statements` (added in #1215) made this possible to see: ``` max_ms mean_ms calls template 10,755 41.8 94,009 plain cursor pagination, no filter 7,277 214.7 14,770 ILIKE substring filter 7,638 330.8 7,656 ILIKE substring + is_latest filter ``` Mean times are healthy. But `max_exec_time` of 7–10s on the cursor query, combined with sustained ~15 req/s from scrapers (ServiceNow's 148.139.x.x range, anonymous `node` user-agent, etc) saturates `MaxConns=30 × 2 pods = 60`. New requests queue at the Go HTTP layer; nginx-side p99 hits 35s; eventually scrapers time out at 60s, retry, and amplify the queue. Today's two ongoing alerts are both this pattern: - 17:35–17:40 UTC `Availability dropped below 95%` — 4,526 GET requests in 5 min, hundreds of 504s - 18:17 UTC `Publish Endpoint Latency` re-fire — same scraper concurrency dragging the publish path Critically, the symptoms today were also visible during yesterday's incident, but yesterday's broken cursor (#1215) was the dominant cause. After #1215 the cursor is fast individually; concurrency now becomes the next bottleneck. ## Changes ### pgxpool (`internal/database/postgres.go`) | Setting | Before | After | |---------|-------:|------:| | `MaxConns` | 30 | **60** per pod | | `MinConns` | 5 | **10** per pod | | `MaxConnIdleTime` | 30 min | (unchanged) | | `MaxConnLifetime` | 2 h | (unchanged) | 2 pods × 60 = 120 total app connections. Cuts queue depth roughly in half at current scraper load. ### PG cluster (`deploy/pkg/k8s/postgres.go`) - `max_connections: 100 → 200` — required to support the larger pool. 120 (app) + ~10 (PG internals: autovacuum, replication, admin) + 70 headroom. - Added explicit `resources:` block — previously the pod had no resource limits, making node-level OOM behaviour unpredictable. | | Request | Limit | |---|--------:|------:| | memory | 512Mi | **4Gi** | | cpu | 200m | 1500m | ## Resource budget | Node | Now | After | |------|----:|------:| | dy89 (PG node) | 39% mem (~2.4 GiB / 6 GiB) | ~65% mem worst-case (~3.9 GiB) | | 2yxm | 36% mem | unchanged | Both nodes well within capacity. CPU usage <50% on both, plenty of headroom. PG worst-case memory math: - 200 conns × ~15 MB per backend = 3 GiB - + `shared_buffers` 128 MiB - + `maintenance_work_mem`, OS overhead, etc. - ≈ 3–4 GiB total ## Deployment caveat `max_connections` is a postmaster-level setting → CNPG triggers a PG restart on the change. Same in-pod restart shape as the pg_stat_statements deploy yesterday — registry pods see ~30s of DB unavailability, covered by v1.7.1's retry-with-backoff (8 attempts, 1→8s capped). One registry pod may bounce once before recovering, like yesterday. **Time the merge for a low-traffic UTC window.** Order of operations matters within the deploy itself: 1. Pulumi applies the new CNPG spec → PG restarts with `max_connections=200` 2. Rolling deploy of registry pods picks up `MaxConns=60` config 3. New conns are accepted up to 200 limit Pulumi's standard ordering does step 1 before step 2 in this scenario (Pulumi resource graph: CNPG cluster precedes Deployment). If for any reason it doesn't, the worst case is `too many connections` errors during a small window — Self-correcting once the rollout completes. ## Test plan - [x] `go build ./...` clean for app + deploy - [x] `make lint` clean - [x] `go test -race ./internal/database/...` green - [ ] On merge: staging deploy applies the spec change cleanly; PG restarts; pool reaches 60 max - [ ] On prod deploy: same; verify no `too many connections` errors during the rollout window - [ ] After deploy: query `SHOW max_connections` returns 200; query pg_stat_statements after a scraper burst, confirm `max_exec_time` for cursor query no longer hits 10s ## Out of scope - **ILIKE substring search** (`server_name ILIKE '%foo%'`) is unindexable. Three pg_stat_statements variants run with means 141–333ms and max 4–7s. Worth replacing with a `pg_trgm` GIN index or full-text search in a separate PR. - **Per-IP nginx rate limiting** — defends against scraper retry storms regardless of pool size. - **`Cache-Control` on `/v0/servers`** — let nginx absorb scraper-repeated cursors. - **Pre-existing `superfluous WriteHeader` warnings** — separate Huma framework issue. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| pkg | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
| Makefile | ||
| Pulumi.gcpProd.yaml | ||
| Pulumi.gcpStaging.yaml | ||
| Pulumi.local.yaml | ||
| Pulumi.yaml | ||
| README.md | ||
MCP Registry Kubernetes Deployment
This directory contains Pulumi infrastructure code to deploy the MCP Registry service to a Kubernetes cluster. It supports deploying the infrastructure locally (using an existing kubeconfig, e.g. with minikube) or to Google Cloud Platform (GCP).
Quick Start
Local Development
Pre-requisites:
- Pulumi CLI installed
- Access to a Kubernetes cluster via kubeconfig. You can run a cluster locally with minikube.
- Ensure your kubeconfig is configured at the cluster you want to use. For minikube, run
minikube start && minikube tunnel. - Run
make local-upto deploy the stack. - Access the repository via the ingress load balancer. You can find its external IP with
kubectl get svc ingress-nginx-controller -n ingress-nginx. Then runcurl -H "Host: local.registry.modelcontextprotocol.io" -k https://<EXTERNAL-IP>/v0/pingto check that the service is up.
To change config
The stack is configured out of the box for local development. But if you want to make changes, run commands like:
PULUMI_CONFIG_PASSPHRASE="" pulumi config set mcp-registry:environment local
PULUMI_CONFIG_PASSPHRASE="" pulumi config set mcp-registry:githubClientSecret --secret <some-secret-value>
To delete the stack
make local-destroy and deleting the cluster (with minikube: minikube delete) will reset you back to a clean state.
Production Deployment (GCP)
Note: Deployments are automatically handled by GitHub Actions with separate workflows for staging and production:
-
Staging: All merges to the
mainbranch automatically build and deploy the latest code to thestagingenvironment via deploy-staging.yml. Staging always uses the:mainDocker image tag. -
Production: Deployment requires explicit configuration of the Docker image tag in
Pulumi.gcpProd.yamland is triggered automatically via deploy-production.yml when this config file is pushed tomain. This GitOps-style approach provides manual control and an audit trail for production versions.
To deploy a specific version to production:
-
Cut a release (if deploying a new version):
# Via GitHub UI: https://github.com/modelcontextprotocol/registry/releases # Or via gh CLI: gh release create v1.2.3 --generate-notesThis builds Docker images tagged as
1.2.3andlatest(note: image tags do not include the 'v' prefix) -
Update the production image tag in
Pulumi.gcpProd.yaml:# Edit deploy/Pulumi.gcpProd.yaml # Change line: mcp-registry:imageTag: 1.2.3 (note: no 'v' prefix for Docker image tags) git add deploy/Pulumi.gcpProd.yaml git commit -m "Deploy version 1.2.3 to production" git push -
The production deployment workflow will automatically trigger and deploy the specified version
Manual Override: The steps below are preserved if a manual deployment override is needed.
Pre-requisites:
- Pulumi CLI installed
- A Google Cloud Platform (GCP) account
- A GCP Service Account with appropriate permissions
- Create a project:
gcloud projects create mcp-registry-prod - Set the project:
gcloud config set project mcp-registry-prod - Enable the bootstrap APIs needed before Pulumi can run. The remaining APIs
(
cloudresourcemanager,compute,container,logging,monitoring) are adopted as Pulumi-managedprojects.Serviceresources byensureRequiredAPIsinpkg/providers/gcp/provider.go, so they self-heal against drift but still need to be reachable on the very first deploy:gcloud services enable storage.googleapis.com # for the Pulumi state bucket below gcloud services enable cloudresourcemanager.googleapis.com # for the IAM bindings Pulumi creates gcloud services enable container.googleapis.com # for the GKE cluster - Create the Pulumi service account and grant it the roles required to manage
the deploy.
projectIamAdminis needed because the deploy creates IAM bindings on the project (for the default compute SA). The other four are general resource management:gcloud iam service-accounts create pulumi-svc sleep 10 gcloud projects add-iam-policy-binding mcp-registry-prod --member="serviceAccount:pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com" --role="roles/container.admin" gcloud projects add-iam-policy-binding mcp-registry-prod --member="serviceAccount:pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com" --role="roles/compute.admin" gcloud projects add-iam-policy-binding mcp-registry-prod --member="serviceAccount:pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com" --role="roles/storage.admin" gcloud projects add-iam-policy-binding mcp-registry-prod --member="serviceAccount:pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com" --role="roles/storage.hmacKeyAdmin" gcloud projects add-iam-policy-binding mcp-registry-prod --member="serviceAccount:pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com" --role="roles/resourcemanager.projectIamAdmin" gcloud iam service-accounts add-iam-policy-binding $(gcloud projects describe mcp-registry-prod --format="value(projectNumber)")-compute@developer.gserviceaccount.com --member="serviceAccount:pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com" --role="roles/iam.serviceAccountUser" gcloud iam service-accounts keys create sa-key.json --iam-account=pulumi-svc@mcp-registry-prod.iam.gserviceaccount.com - Create a GCS bucket for Pulumi state:
gsutil mb gs://mcp-registry-prod-pulumi-state - Set Pulumi's backend to GCS:
pulumi login gs://mcp-registry-prod-pulumi-state - Get the passphrase file
passphrase.prod.txtfrom the registry maintainers - Init the GCP stack:
PULUMI_CONFIG_PASSPHRASE_FILE=passphrase.prod.txt pulumi stack init gcpProd - Set the GCP credentials in Pulumi config:
# Base64 encode the service account key and set it pulumi config set --secret gcp:credentials "$(base64 < sa-key.json)" - Deploy:
make prod-up - Access the repository via the ingress load balancer. You can find its external IP with:
kubectl get svc ingress-nginx-controller -n ingress-nginx. Then runcurl -H "Host: prod.registry.modelcontextprotocol.io" -k https://<EXTERNAL-IP>/v0/pingto check that the service is up.
Structure
├── main.go # Pulumi program entry point
├── Pulumi.yaml # Project configuration
├── Pulumi.local.yaml # Local stack configuration
├── Pulumi.gcpProd.yaml # GCP production stack configuration
├── Pulumi.gcpStaging.yaml # GCP staging stack configuration
├── Makefile # Build and deployment targets
├── go.mod # Go module dependencies
├── go.sum # Go module checksums
└── pkg/ # Infrastructure packages
├── k8s/ # Kubernetes deployment components
│ ├── backup.go # Database backup configuration
│ ├── cert_manager.go # SSL certificate management
│ ├── deploy.go # Deployment orchestration
│ ├── ingress.go # Ingress controller setup
│ ├── monitoring.go # Metrics and monitoring setup
│ ├── postgres.go # PostgreSQL database deployment
│ └── registry.go # MCP Registry deployment
└── providers/ # Kubernetes cluster providers
├── types.go # Provider interface definitions
├── gcp/ # Google Kubernetes Engine provider
└── local/ # Local kubeconfig provider
Architecture Overview
Deployment Flow
- Pulumi program starts in
main.go - Configuration is loaded from Pulumi config files
- Provider factory creates appropriate cluster provider (GCP or local)
- Cluster provider sets up Kubernetes access
k8s.DeployAll()orchestrates complete deployment:- Certificate manager for SSL/TLS
- Ingress controller for external access
- Database for data persistence
- Backup infrastructure for database
- Monitoring and metrics collection
- MCP Registry application
Configuration
| Parameter | Description | Required |
|---|---|---|
environment |
Deployment environment (local/staging/prod) | Yes |
provider |
Kubernetes provider (local/gcp) | No (default: local) |
githubClientId |
GitHub OAuth Client ID | Yes |
githubClientSecret |
GitHub OAuth Client Secret | Yes |
imageTag |
Docker image tag for production environment | Yes (prod only) |
gcpProjectId |
GCP Project ID (required when provider=gcp) | No |
gcpRegion |
GCP Region (default: us-central1) | No |
Database Backups
The deployment uses K8up (a Kubernetes backup operator) that uses Restic under the hood.
When running locally they are stored in a Minio bucket. In staging and production, backups are stored in a GCS bucket.
Accessing Backup Files
Local Development (MinIO)
# Expose MinIO web console
kubectl port-forward -n minio svc/minio 9000:9000 9001:9001
Then open localhost:9001, login with username minioadmin and password minioadmin, and navigate to the k8up-backups bucket.
Staging and Production (GCS)
Decrypting and Restoring Backups
Backups are encrypted using Restic. To access the backup data:
- Download the backup files from the bucket:
# Local (MinIO) - ensure port-forward is active: kubectl port-forward -n minio svc/minio 9000:9000 9001:9001 AWS_ACCESS_KEY_ID=minioadmin AWS_SECRET_ACCESS_KEY=minioadmin \ aws --endpoint-url http://localhost:9000 s3 sync s3://k8up-backups/ ./backup-files/ # GCS (staging/production) gsutil -m cp -r gs://mcp-registry-{staging|prod}-backups/* ./backup-files/ - Install Restic
- Restore the backup:
PostgreSQL data will be inRESTIC_PASSWORD=password restic -r ./backup-files restore latest --target ./restored-files./restored-files/data/registry-pg-1/pgdata/
Troubleshooting
To configure kubectl to access an existing GKE cluster:
# Login
gcloud auth login
gcloud auth application-default login
# For production
gcloud container clusters get-credentials mcp-registry-prod --zone us-central1-b --project mcp-registry-prod
# For staging
gcloud container clusters get-credentials mcp-registry-staging --zone us-central1-b --project mcp-registry-staging
Check Status
kubectl get pods
kubectl get deployment
kubectl get svc
kubectl get ingress
kubectl get svc -n ingress-nginx
View Logs
kubectl logs -l app=mcp-registry
kubectl logs -l app=postgres
Check Backup Status
kubectl describe schedule.k8up.io
kubectl get backup