-
Notifications
You must be signed in to change notification settings - Fork 68
🐛 Make deployments HA-ready with configurable replica count and update upgrade-e2e test cases #2371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| # High Availability (HA) configuration for OLMv1 | ||
pedjak marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| # Sets replicas to 2 for both operator-controller and catalogd to enable HA setup | ||
| # This is used in experimental-e2e.yaml to test multi-replica deployments | ||
| # | ||
| # Pod anti-affinity is configured as "preferred" (not "required") to ensure: | ||
| # - In multi-node clusters: replicas are scheduled on different nodes for better availability | ||
| # - In single-node clusters (like kind): both replicas can still be scheduled on the same node | ||
| options: | ||
| operatorController: | ||
| deployment: | ||
| replicas: 2 | ||
| catalogd: | ||
| deployment: | ||
| replicas: 2 | ||
|
|
||
| # Pod anti-affinity configuration to prefer spreading replicas across different nodes | ||
| # Uses preferredDuringSchedulingIgnoredDuringExecution (soft constraint) to allow | ||
| # scheduling on the same node when necessary (e.g., single-node kind clusters for e2e tests) | ||
| deployments: | ||
| templateSpec: | ||
| affinity: | ||
| podAntiAffinity: | ||
| preferredDuringSchedulingIgnoredDuringExecution: | ||
| - weight: 100 | ||
| podAffinityTerm: | ||
| labelSelector: | ||
| matchExpressions: | ||
| - key: control-plane | ||
| operator: In | ||
| values: | ||
| - operator-controller-controller-manager | ||
| - catalogd-controller-manager | ||
| topologyKey: kubernetes.io/hostname | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,11 +12,11 @@ metadata: | |
| namespace: {{ .Values.namespaces.olmv1.name }} | ||
| spec: | ||
| minReadySeconds: 5 | ||
| replicas: 1 | ||
| replicas: {{ .Values.options.catalogd.deployment.replicas }} | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we already have node anti affinity configured to make sure these replicas do not end up on the same node? If not, we need that as well (but only when replicas > 1).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. However, I will point out that this may cause an issue on our single-node
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point! I added podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: control-plane
operator: In
values:
- operator-controller-controller-manager
- catalogd-controller-manager
topologyKey: kubernetes.io/hostname |
||
| strategy: | ||
| type: RollingUpdate | ||
| rollingUpdate: | ||
| maxSurge: 1 # Allow temporary 2 pods (1 + 1) for zero-downtime updates | ||
| maxSurge: 1 # Allow temporary extra pod for zero-downtime updates | ||
| maxUnavailable: 0 # Never allow pods to be unavailable during updates | ||
| selector: | ||
| matchLabels: | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.