Skip to content
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

[FEATURE_REQUEST] Support topologySpreadConstraints for no-anti-affinity check #894

Open
raweber42 opened this issue Jan 16, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@raweber42
Copy link

raweber42 commented Jan 16, 2025

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
Copy link

+1 I have exactly the same problem

@janisz janisz added the bug Something isn't working label Mar 10, 2025
@janisz
Copy link
Collaborator

janisz commented Mar 10, 2025

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.

I think it should be added. The affinity check was added around 1.19 was released so that's why it could be omitted. It will be grate it you could contribute a patch. For first shot we could skip the check if topologySpreadConstraints is declared unless you have a more sophisticated solution in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants