Configuring The Application Tier

Scope

Applies to every DynamoAI product.

Configuring the application tier

The API and UI hold no durable state and need no session affinity or sticky routing; sessions use bearer tokens. The API validates every request against the identity service, so identity availability bounds API availability. Run the identity service with more than one replica where the chart supports it.

Replica count alone does not survive a node drain or a zone loss. Configure all three. The keys below are for the dynamoai-platform chart; deployments on the earlier three-chart generation use the equivalent keys under each chart's deployment values, which your deployment engineer supplies.

api:
  replicas: 3
  pdb:
    enabled: true
    minAvailable: 2
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app.kubernetes.io/name: api

Use whenUnsatisfiable: DoNotSchedule for zone spread. ScheduleAnyway reduces the constraint to a preference the scheduler may ignore, which can place every replica in one zone while appearing correctly configured.

Without a PodDisruptionBudget, a node drain, cluster upgrade, or autoscaler consolidation can evict every replica of a service at once.

When the cluster autoscaler is in use, prefer one node pool per zone. The autoscaler is not zone-aware, and a single multi-zone pool combined with DoNotSchedule spread can leave replicas pending after a zone loss.

Verifying

Check placement after deployment. A deployment can be configured for zone tolerance and not have it.

# Which node each replica landed on
kubectl --context <ctx> -n <ns> get pods \
  -o custom-columns='NAME:.metadata.name,NODE:.spec.nodeName'

# Which zone each node is in
kubectl --context <ctx> get nodes \
  -o custom-columns='NODE:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone'

# Disruption budgets permit at least one disruption
kubectl --context <ctx> -n <ns> get pdb

If replicas share a node, or all sit in one zone, the deployment has pod-level redundancy only regardless of replica count.

Test failover deliberately. Delete a pod, drain a node, and confirm the platform continues to serve. A control that has never been exercised is an assumption.