Allow opt-in anit-affinity in Pepr Controller Deployment #2078
Comments
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 30, 2025
## Description
Expose `podAntiAffinity` from the helm chart to ensure the Admission
Controller pods are scheduled on different nodes for greater
availability during node recycling or failures.
```bash
> k get po -n pepr-system -o wide -l pepr.dev/controller=admission
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pepr-static-test-785995b8d4-5lm5r 1/1 Running 0 99s 10.42.1.3 k3d-multiserver-server-1 <none> <none>
pepr-static-test-785995b8d4-d86wn 1/1 Running 0 99s 10.42.2.4 k3d-multiserver-server-2 <none> <none>
> k get deploy -n pepr-system pepr-static-test -ojsonpath="{.spec.template.spec.affinity}" | jq
{
"podAntiAffinity": {
"requiredDuringSchedulingIgnoredDuringExecution": [
{
"labelSelector": {
"matchExpressions": [
{
"key": "pepr.dev/controller",
"operator": "In",
"values": [
"admission"
]
}
]
},
"topologyKey": "kubernetes.io/hostname"
}
]
}
}
```
## Related Issue
Fixes #2078
<!-- or -->
Relates to #
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Other (security config, docs update, etc)
## Checklist before merging
- [x] Unit,
[Journey](https://github.com/defenseunicorns/pepr/tree/main/journey),
[E2E Tests](https://github.com/defenseunicorns/pepr-excellent-examples),
[docs](https://github.com/defenseunicorns/pepr/tree/main/docs),
[adr](https://github.com/defenseunicorns/pepr/tree/main/adr) added or
updated as needed
- [x] [Contributor Guide
Steps](https://docs.pepr.dev/main/contribute/#submitting-a-pull-request)
followed
Signed-off-by: Case Wylie <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Path to deploy the Admission deployment with anti-affinity
Related to: defenseunicorns/uds-core#342
Describe the solution you'd like
So if one node goes down, the webhook still has a pod to forward the requests to and admission in not blocked.
Describe alternatives you've considered
(optional) A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: