kubernetes/kubernetes

Duplicate Tolerations

rgarcia89 opened this issue · 7 comments

rgarcia89 commented

What would you like to be added?

I have encountered an issue where duplicate tolerations exist within the tolerations array of Kubernetes Deployment YAML. Despite being duplicates, these tolerations are not being ignored as I would have expected, which in my case led to duplicate metric samples produced by the kube-state-metrics.

A validation check within the Kubernetes API server to reject manifests with duplicate tolerations, ensuring adherence to Kubernetes best practices and avoiding potential issues related to duplicate toleration definitions would be great.

The whole thing was noticed after the update to prometheus v2.52.0 which includes a new check for duplicates during the scrape phase. I created the following issue for that prometheus/prometheus#14089

I have meanwhile also created an issue for the kube-state-metrics project requesting some changes in order to tackle such situations in the future. kubernetes/kube-state-metrics#2390

Steps to reproduce:

  1. ) Deploy the following deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  labels:
    app: something
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: test-container
        image: nginx
      tolerations:
       - key: CriticalAddonsOnly
         operator: Exists
       - key: CriticalAddonsOnly
         operator: Exists

2.) Check the tolerations of the scheduled pod for instance:

...
       tolerations:
       - key: CriticalAddonsOnly
         operator: Exists
       - key: CriticalAddonsOnly
         operator: Exists
...

Why is this needed?

Duplicate tolerations are not being ignored and are applied to resources, potentially resulting in unintended behaviors.

k8s-ci-robot commented

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

rgarcia89 commented

/sig api-machinery
/sig architecture

AxeZhan commented

/cc