You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* chore: update sourcebot version to 0.1.67 and add deployment strategy configuration
Signed-off-by: Alexander Chernov <alexander@chernov.it>
* Further hardening of values.schema.json
* readme
* changelog
---------
Signed-off-by: Alexander Chernov <alexander@chernov.it>
Co-authored-by: Brendan Kellam <brendan@sourcebot.dev>
Copy file name to clipboardExpand all lines: README.md
+56Lines changed: 56 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -221,6 +221,37 @@ sourcebot:
221
221
existingSecretKey: license-key
222
222
```
223
223
224
+
## Deployment Strategy
225
+
226
+
By default, the chart uses a `RollingUpdate` strategy, which creates the new pod before terminating the old one during upgrades. You can customize the rolling update behavior:
227
+
```yaml
228
+
sourcebot:
229
+
strategy:
230
+
type: RollingUpdate
231
+
rollingUpdate:
232
+
maxUnavailable: 0
233
+
maxSurge: 1
234
+
```
235
+
236
+
On multi-node clusters with `ReadWriteOnce` persistent volumes, the new pod may fail to start if it gets scheduled on a different node than the old pod. To avoid this, you can pin pods to the same node using pod affinity:
237
+
```yaml
238
+
sourcebot:
239
+
affinity:
240
+
podAffinity:
241
+
requiredDuringSchedulingIgnoredDuringExecution:
242
+
- labelSelector:
243
+
matchLabels:
244
+
app.kubernetes.io/name: sourcebot
245
+
topologyKey: kubernetes.io/hostname
246
+
```
247
+
248
+
Alternatively, you can use the `Recreate` strategy, which terminates the old pod before creating the new one. This avoids PVC conflicts but causes brief downtime during upgrades:
249
+
```yaml
250
+
sourcebot:
251
+
strategy:
252
+
type: Recreate
253
+
```
254
+
224
255
## Persistence
225
256
226
257
Each component has its own persistent volume for storing data across pod restarts.
@@ -325,6 +356,31 @@ sourcebot:
325
356
secretName: sourcebot-tls
326
357
```
327
358
359
+
### Zero-downtime upgrades on multi-node clusters
360
+
361
+
Use a `ReadWriteMany` access mode so the old and new pods can mount the PVC simultaneously during rolling updates. This requires a storage class that supports `ReadWriteMany` (e.g., EFS on AWS, Filestore on GCP, Azure Files):
362
+
363
+
```yaml
364
+
sourcebot:
365
+
persistence:
366
+
accessModes:
367
+
- ReadWriteMany
368
+
storageClass: "efs-sc" # example: AWS EFS storage class
369
+
```
370
+
371
+
Alternatively, you can keep `ReadWriteOnce` and use pod affinity to pin pods to the same node:
| sourcebot.tolerations | list |`[]`| Set tolerations for pod scheduling See: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/|
0 commit comments