Merge pull request #2192 from Mart-Kuc/MK-topologySpreadConstraints

feat: Add 'topologySpreadConstraints'

chart/Chart.yaml

@@ -2,7 +2,7 @@ apiVersion: v2
 name: versitygw
 description: A Helm chart for deploying the Versity S3 Gateway on Kubernetes
 type: application
-version: 0.3.2
+version: 0.3.3
 sources:
   - https://github.com/versity/versitygw
 icon: https://raw.githubusercontent.com/versity/versitygw/main/webui/web/assets/images/Versity-logo-blue-horizontal.png

chart/README.md

@@ -87,6 +87,7 @@ The `gateway.backend.type` value selects the storage backend. Use `gateway.backe
 | **IAM** | `iam.enabled=true` — flat-file identity and access management stored alongside backend data |
 | **Persistence** | `persistence.enabled=true` — provisions a PVC for backend data and IAM storage; defaults to `10Gi`, or uses a hostPath volume specified by `persistence.hostPath` |
 | **NetworkPolicy** | `networkPolicy.enabled=true` — restricts ingress to selected pods/namespaces; allows all egress |
+| **Scheduling** | `nodeSelector`, `affinity`, `tolerations`, and `topologySpreadConstraints` — control pod placement and spread replicas across nodes/zones for high availability |
 
 ## Scaling and Persistence
 
@@ -102,7 +103,7 @@ When scaling `versitygw` horizontally by setting `replicaCount` greater than 1,
 
 - **POSIX or Internal IAM**: These backends store state locally on the filesystem.
     - Using **ReadWriteOnce (RWO)**: All replicas must be scheduled on the **same Kubernetes node** to share the same volume. This is useful for process-level concurrency (e.g., when using high-performance local block storage) but limits high availability across nodes.
-    - Using **ReadWriteMany (RWX)**: Replicas can be distributed across **multiple nodes** in the cluster. This is the recommended approach for true horizontal scaling and high availability. When using RWX, it is also recommended to use pod anti-affinity (via `affinity` in `values.yaml`) to ensure pods are distributed across nodes/zones.
+    - Using **ReadWriteMany (RWX)**: Replicas can be distributed across **multiple nodes** in the cluster. This is the recommended approach for true horizontal scaling and high availability. When using RWX, it is also recommended to use pod anti-affinity (via `affinity` in `values.yaml`) or topology spread constraints (via `topologySpreadConstraints` in `values.yaml`) to ensure pods are distributed across nodes/zones.
 - **Stateless Backends (S3, Azure)**: If you are using a stateless storage backend (e.g. proxying to another S3 store) **and** you are either not using IAM or using an external IAM provider (e.g. LDAP, Vault), persistence can be safely disabled by setting `persistence.enabled=false`.
 
 ### Deployment Strategy

chart/templates/deployment.yaml

@@ -246,6 +246,10 @@ spec:
       affinity:
         {{- toYaml . | nindent 8 }}
       {{- end }}
+      {{- with .Values.topologySpreadConstraints }}
+      topologySpreadConstraints:
+        {{- toYaml . | nindent 8 }}
+      {{- end }}
       {{- with .Values.tolerations }}
       tolerations:
         {{- toYaml . | nindent 8 }}

chart/values.yaml

@@ -334,6 +334,20 @@ tolerations: []
 
 affinity: {}
 
+# Topology spread constraints to control how pods are distributed across
+# topology domains (e.g. nodes, zones). Useful for spreading replicas for
+# high availability. See:
+# https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/
+# Example:
+#   topologySpreadConstraints:
+#     - maxSkew: 1
+#       topologyKey: topology.kubernetes.io/zone
+#       whenUnsatisfiable: ScheduleAnyway
+#       labelSelector:
+#         matchLabels:
+#           app.kubernetes.io/name: versitygw
+topologySpreadConstraints: []
+
 networkPolicy:
   enabled: false
   # allowIngressFromNamespaces: