-
Notifications
You must be signed in to change notification settings - Fork 256
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Description of the problem/feature request
When trying to satisfy the no-anti-affinity check, I stumbled upon topologySpreadConstraints (since Kubernetes 1.19) which is a good way to control how to spread replicas between different nodes. But implementing this does not meet the no-anti-affinity
check (yet). Is there a specific reason to not include this? If not, I am willing to contribute to this project and include this to the check.
Description of the existing behavior vs. expected behavior
When using this deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 3
selector:
matchLabels:
app: test-app
template:
metadata:
labels:
app: test-app
spec:
serviceAccountName: test-app-service-account
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: test-app
terminationGracePeriodSeconds: 60
containers:
- name: test-app
image: busybox:1.30.1
I still get this error:
<standard input>: (object: test/test-app apps/v1, Kind=Deployment) object has 2 replicas but does not specify inter pod anti-affinity (check: no-anti-affinity, remediation: Specify anti-affinity in your pod specification to ensure that the orchestrator attempts to schedule replicas on different nodes. Using podAntiAffinity, specify a labelSelector that matches pods for the deployment, and set the topologyKey to kubernetes.io/hostname. Refer to https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity for details.)
Additional context
I am willing to contribute.
famaridon, janisz and BarboraAni
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working