Kubernetes Reference
Run the full Cloud Health Office platform on Docker Desktop Kubernetes — the same service shape, namespace, and reference manifests used for cloud-deployment evaluation. No Azure account needed.
The primary Quick Start is the shortest local Kubernetes path. This reference guide adds deeper troubleshooting, teardown, resource guidance, and common kubectl workflows for the same production-shaped local deployment.
What You Get
| Component | Count | Notes |
|---|---|---|
| Microservices | 30+ | Claims, Members, Eligibility, Payments, FHIR, Appeals, Capitation, encounters, provider workflows, and supporting services. |
| Portal | 1 | Blazor Server UI you can expose on your own portal host after deployment |
| MongoDB | 1 | StatefulSet with persistent storage |
| Redis | 1 | Data-protection key store and caching |
| Namespace | cloudhealthoffice | Matches the reference cloud layout |
All services communicate over Kubernetes DNS (service-name.cloudhealthoffice) — the same service-discovery pattern used by the reference cloud deployment.
Prerequisites
| Tool | How to Check | Install |
|---|---|---|
| Docker Desktop 4.x+ | docker --version | docker.com |
| Kubernetes enabled | kubectl cluster-info | Docker Desktop > Settings > Kubernetes > Enable |
| kubectl | kubectl version --client | Bundled with Docker Desktop |
| bash 4+ | bash --version | macOS: brew install bash |
| curl | curl --version | Pre-installed on macOS/Linux |
| jq (optional) | jq --version | brew install jq |
The full platform runs 30+ pods. Allocate at least 6 CPU cores and 16 GB memory; 24 GB is recommended in Docker Desktop (Settings > Resources). First build pulls .NET 8 SDK + runtime images — budget ~8 GB disk for images.
1. Enable Kubernetes in Docker Desktop
Turn on Kubernetes and verify the cluster
- Open Docker Desktop > Settings > Kubernetes
- Check Enable Kubernetes
- Click Apply & Restart — wait for the green indicator
# Verify context
kubectl config current-context
# Expected: docker-desktop
# Verify cluster
kubectl cluster-info
# Expected: Kubernetes control plane is running at https://127.0.0.1:6443
2. Configure Credentials (Optional)
Add real Azure AD and Stripe keys for full portal login
The deploy script works out of the box with stub values — all services start and API endpoints work. For real Azure AD sign-in and Stripe payments:
cp .env.local.example .env.local
# Edit .env.local with your Azure AD app registration and Stripe test keys
Without .env.local, the portal UI loads but Azure AD sign-in won’t work. API endpoints function normally with the X-Tenant-ID header.
3. Build & Deploy
One command deploys the entire platform
./scripts/deploy-local.sh
This builds Docker images for all 30+ services plus the portal, creates the cloudhealthoffice namespace, deploys MongoDB and Redis, creates local Kubernetes secrets, seeds demo data, and deploys the microservices using the repository's reference manifests with local patches.
First run: ~10–15 minutes (image builds). Subsequent runs: ~2 minutes.
| Flag | What it does |
|---|---|
--skip-build | Deploy only (images already built) |
--only-build | Build images without deploying |
Watch the rollout
In a separate terminal:
watch kubectl get pods -n cloudhealthoffice
All pods should reach Running / 1/1 Ready within 2–3 minutes after images are built.
4. Access the Platform
Port-forward to access services locally
Services run inside the cluster on ClusterIP. Use port-forwarding to reach them (open each in a separate terminal, or append & to background):
# Portal (Blazor Server UI)
kubectl port-forward -n cloudhealthoffice svc/portal 8080:80
# Core API services
kubectl port-forward -n cloudhealthoffice svc/claims-service 5001:80
kubectl port-forward -n cloudhealthoffice svc/benefit-plan-service 5002:80
kubectl port-forward -n cloudhealthoffice svc/member-service 5003:80
kubectl port-forward -n cloudhealthoffice svc/provider-service 5004:80
kubectl port-forward -n cloudhealthoffice svc/eligibility-service 5005:80
kubectl port-forward -n cloudhealthoffice svc/payment-service 5006:80
# MongoDB (for direct access)
kubectl port-forward -n cloudhealthoffice svc/mongodb 27017:27017
| Service | Local URL |
|---|---|
| Portal | http://localhost:8080 |
| Claims API + Swagger | http://localhost:5001/swagger |
| Benefit Plans / Adjudication | http://localhost:5002/swagger |
| Members | http://localhost:5003/swagger |
| Providers | http://localhost:5004/swagger |
| Eligibility | http://localhost:5005/swagger |
| Payments | http://localhost:5006/swagger |
5. Seed Demo Data & Test Adjudication
Run the full claims lifecycle end-to-end
After port-forwarding Claims (5001) and Benefit Plan (5002):
CLAIMS_URL=http://localhost:5001 \
BENEFIT_URL=http://localhost:5002 \
./scripts/seed-local.sh --tenant demo
This seeds NCCI edits, creates a benefit plan, submits a claim, runs adjudication, and writes the adjudication result back to the claim.
For the shortest walkthrough, see the primary Quick Start guide.
6. Verify System Health
Check pod status and health endpoints
# All pods
kubectl get pods -n cloudhealthoffice
# All services
kubectl get svc -n cloudhealthoffice
# Portal logs
kubectl logs -n cloudhealthoffice -l app=portal --tail=50
# Claims service logs
kubectl logs -n cloudhealthoffice -l app=claims-service --tail=50
# Find errors across all services
kubectl logs -n cloudhealthoffice --all-containers --tail=20 | grep -i error
You now have the microservices architecture running locally with the same namespace, service DNS pattern, and health probes used by the reference deployment path. A payer production rollout still needs environment-specific security, ingress, identity, data, and operational validation.
How This Maps to a Cloud Deployment
| Aspect | Local (Docker Desktop) | Reference cloud deployment |
|---|---|---|
| Namespace | cloudhealthoffice | cloudhealthoffice |
| Service DNS | svc.cloudhealthoffice | svc.cloudhealthoffice |
| K8s manifests | Same files, imagePullPolicy patched | Always (pulls from ACR) |
| Container port | 8080 | 8080 |
| Secrets | Local stubs via deploy-local.sh | Azure Key Vault |
| Database | MongoDB StatefulSet (single node) | Azure Cosmos DB (MongoDB API) |
| Redis | Single pod | Azure Cache for Redis |
| Ingress / TLS | None (port-forward) | NGINX + cert-manager + Let's Encrypt |
| Replicas | 1 per service | 2+ with HPA autoscaling |
| Image registry | Local Docker daemon | Azure ACR / GitHub GHCR |
Common Tasks
Rebuild and redeploy a single service
# Rebuild just the claims service
docker build -t clouhealthoffice.azurecr.io/cloudhealthoffice-claims-service:latest \
-f src/services/claims-service/Dockerfile .
# Restart the deployment to pick up the new image
kubectl rollout restart deployment/claims-service -n cloudhealthoffice
kubectl rollout status deployment/claims-service -n cloudhealthoffice
Connect to MongoDB
kubectl port-forward -n cloudhealthoffice svc/mongodb 27017:27017
# In another terminal:
mongosh "mongodb://admin:localdev123@localhost:27017/?authSource=admin"
Scale a service
kubectl scale deployment/claims-service -n cloudhealthoffice --replicas=3
Apply a manifest change
kubectl apply -f src/services/claims-service/k8s/claims-service-deployment.yaml
Troubleshooting
Pods stuck in ImagePullBackOff
Images are built locally but the manifest says imagePullPolicy: Always. The deploy script patches this automatically. If you applied a manifest manually:
kubectl patch deployment claims-service -n cloudhealthoffice \
-p '{"spec":{"template":{"spec":{"containers":[{"name":"claims-service","imagePullPolicy":"IfNotPresent"}]}}}}'
Pods in CrashLoopBackOff
Usually a missing secret or MongoDB not ready yet:
# Check what's failing
kubectl describe pod -n cloudhealthoffice -l app=claims-service
kubectl logs -n cloudhealthoffice -l app=claims-service --previous
# Verify secrets exist
kubectl get secrets -n cloudhealthoffice
MongoDB not starting
kubectl describe statefulset mongodb -n cloudhealthoffice
kubectl logs -n cloudhealthoffice mongodb-0
If PVC issues on Docker Desktop: Settings > Kubernetes > Reset Kubernetes Cluster.
Port-forward drops
Port-forwards disconnect when pods restart. Re-run the command, or use kubefwd for automatic forwarding.
Services can't reach each other
kubectl run -n cloudhealthoffice dns-test --rm -it --image=busybox -- \
nslookup claims-service.cloudhealthoffice
Docker Desktop running slow
Increase resources in Docker Desktop > Settings > Resources: 4+ CPU cores, 8+ GB memory.
Tear Down
Stop local workloads (keep the MongoDB PVC)
kubectl scale deployment --all --replicas=0 -n cloudhealthoffice
kubectl scale statefulset mongodb --replicas=0 -n cloudhealthoffice
The PVC remains while the workloads are scaled down. Re-run ./scripts/deploy-local.sh --skip-build to restore the local manifests and replica counts.
Before moving real traffic, complete the Production Readiness Checklist and the Backup & Disaster Recovery Runbook. The local single-node MongoDB PVC survives ordinary pod restarts, but it is not a production backup or high-availability design.
Full reset (delete everything including data)
kubectl delete namespace cloudhealthoffice
docker volume prune -f
Deleting the namespace requests deletion of namespaced PVCs. Whether an underlying volume remains depends on the storage class reclaim policy; do not treat it as recoverable unless an independent backup has been tested.
Next Steps
Primary Quick Start
Short path for deploying local Kubernetes and validating claims plus CRD discovery.
View guide →Deployment Reference
Move from local Kubernetes to a reviewed cloud deployment path with gated CI/CD, environment-specific security, and payer validation.
Deployment guide →Architecture
Deep dive into the microservices architecture, service mesh, and data flow.
Architecture guide →CMS-0057-F Compliance
Verify your health plan's compliance readiness with Patient Access, Provider Access, and Prior Auth APIs.
Compliance guide →