Change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: I followed the steps in tutorial. At the end of it the annotation-second-scheduler POD got into the pending state. Client Version: v1.17.0 Server Version: v1.17.0 Errors visible in my-scheduler POD: Proposed Solution: Remove lock-object-namespace and lock-object-name from There is no lock-object-namespace namespace, hence my-scheduler won't not work properly. In addition to that, add the following lines to clusterrole system:kube-scheduler: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
It looks to me as if ought to tell the reader to add a new namespace to hold lock objects. Does that sound right? /sig scheduling
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign
could you confirm if you were trying to set up leader election or not?

Discussion:
You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler pod in this list. <ins> ### Enable leader election </ins> To run multiple-scheduler with leader election enabled, you must do the following: First, update the following fields in your YAML file: * `--leader-elect=true` <del> * `--lock-object-namespace=lock-object-namespace` * `--lock-object-name=lock-object-name` </del> <ins> * `--lock-object-namespace=<lock-object-namespace>` * `--lock-object-name=<lock-object-name>` {{< note >}} The control plane creates the lock objects for you, but the namespace must already exist. You can use the `kube-system` namespace. {{< /note >}} </ins> <del> If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example: </del> <ins> If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example: </ins> ``` kubectl edit clusterrole system:kube-scheduler ``` ```yaml <del> - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:kube-scheduler rules: - apiGroups: - "" resourceNames: - kube-scheduler - my-scheduler resources: - endpoints verbs: - delete - get - patch - update </del> <ins> apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:kube-scheduler rules: - apiGroups: - coordination.k8s.io resources: - leases verbs: - create - apiGroups: - coordination.k8s.io resourceNames: - kube-scheduler - my-scheduler resources: - leases verbs: - get - update - apiGroups: - "" resourceNames: - kube-scheduler - my-scheduler resources: - endpoints verbs: - delete - get - patch - update </ins> ``` ## Specify schedulers for pods

name: system:kube-scheduler apiGroup: rbac.authorization.k8s.io --- <ins> apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-scheduler-as-volume-scheduler subjects: - kind: ServiceAccount name: my-scheduler namespace: kube-system roleRef: kind: ClusterRole name: system:volume-scheduler apiGroup: rbac.authorization.k8s.io --- </ins> apiVersion: apps/v1 kind: Deployment metadata: