Kubernetes configuration, secrets and scaling for .NET services: KEDA (Kubernetes YAML)

ConfigMap for configuration (Erp__BaseUrl), exposed as env vars and read by IConfiguration as usual.

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# ======================================================================
# Q: How do you handle configuration, secrets and scaling in Kubernetes?
#
# - ConfigMap for configuration (Erp__BaseUrl), exposed as env vars and read by
#   IConfiguration as usual.
# - Kubernetes Secrets are only base64, not encryption. Better: Azure Key Vault
#   through the Secrets Store CSI driver, or directly from the application with
#   Workload Identity (Q15), with no secrets in the cluster at all.
# - Stateless pods: sessions and cache in Redis, shared Data Protection keys
#   (Q38), files in Blob Storage and not on the pod's disk.
# - Migrations as a Kubernetes Job or a pipeline step before the rollout, not at
#   the startup of every pod (Q8).
# - PodDisruptionBudget, so that a node upgrade doesn't take down all replicas
#   at once.
# ======================================================================

# Worker: scaling based on queue length (KEDA), even down to 0
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: erp-sync-worker }
spec:
  scaleTargetRef: { name: erp-sync-worker }
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: azure-servicebus
      metadata:
        topicName: order-events
        subscriptionName: erp-sync
        messageCount: "50"                  # ~1 replica per 50 waiting messages
      authenticationRef: { name: servicebus-workload-identity }