Skip to content

Deployment

Purpose

Helm chart and deployment scripts for deploying the Virtufin platform (API Gateway, WorkManager, WebSocket Manager) on Kubernetes with Dapr sidecars, configurable per-service versioning, Dapr Components, health probes, and private registry support.

Requirements

Requirement: Helm Chart

The platform SHALL be deployable via a single Helm v2 chart that covers the API Gateway, WorkManager, and WebSocket Manager with Dapr sidecars. Each service SHALL be independently enableable.

Scenario: Full stack install

  • WHEN helm install virtufin . is run
  • THEN all three services, their Dapr sidecars, Dapr Components, and ConfigMaps SHALL be created in the target namespace

Scenario: Single-service install

  • WHEN the chart is installed with all but one service disabled
  • THEN only the enabled service and its Dapr sidecar SHALL be deployed

Requirement: Per-Service Versioning

Each service's Docker image tag SHALL be independently configurable. Services SHALL support replicas, resource limits, and environment variables.

Scenario: Canary deployment

  • WHEN a specific service's image tag is overridden
  • THEN only that deployment SHALL roll out the new image; other services SHALL remain unchanged

Requirement: Dapr Component Management

The Helm chart SHALL create dapr.io/v1alpha1 Component resources for the state store and pub/sub broker. These SHALL reference Redis/Valkey with configurable host, port, password, redelivery count, and dead-letter topic.

Scenario: Production Redis

  • WHEN deployed with a custom state store host and password
  • THEN the Dapr state store component SHALL connect to the specified Redis with authentication

Scenario: Pub/Sub redelivery

  • WHEN a message cannot be processed
  • THEN the pubsub component SHALL redeliver up to the configured maximum count, with a configurable redelivery interval, before routing to the dead-letter topic

Requirement: Dapr Configuration

The Helm chart SHALL create a dapr.io/v1alpha1 Configuration resource with tracing, metrics, and mTLS settings.

Scenario: mTLS enforcement

  • WHEN mTLS is enabled in Dapr config
  • THEN all inter-service communication SHALL be encrypted and authenticated

Scenario: Tracing sampling

  • WHEN tracing is configured with a sampling rate
  • THEN the Dapr sidecar SHALL sample traces at that rate

Requirement: Service Discovery Configuration

The API Gateway's services.json SHALL be generated as a ConfigMap from Helm values, listing each enabled backend service with its gRPC host, port, Dapr app ID, and pubsub/state component names.

Scenario: Service registration

  • WHEN a new backend service is added via Helm values
  • THEN it SHALL appear in the generated services.json ConfigMap without manual intervention

Requirement: Health Probes

Every deployment SHALL configure Kubernetes liveness and readiness probes on the service's HTTP health endpoint. Dapr sidecars SHALL use the service health check path.

Scenario: Readiness gate

  • WHEN a service is starting up and has not completed recovery
  • THEN the readiness probe SHALL fail, preventing the Service from routing traffic to that pod

Requirement: Private Registry

All container images SHALL be pulled from a private Harbor registry using a Kubernetes image pull secret.

Scenario: Image pull

  • WHEN Kubernetes schedules a pod
  • THEN it SHALL authenticate to the private registry using the configured image pull secret

Requirement: Single-Service Deploy/Undeploy

Deployment scripts SHALL support deploying or undeploying individual services without affecting the rest of the release.

Scenario: Remove a single service

  • WHEN the undeploy script is run targeting a specific service
  • THEN only that deployment and service SHALL be removed while other services continue running

Scenario: Deploy a single service

  • WHEN the deploy script is run targeting a specific service
  • THEN only that deployment SHALL be installed or upgraded without redeploying other services