<p>I setup a k8s cluster, which have one master node and one worker node, <code>coredns</code> pod is schedule to worker node and works fine. When I delete worker node, <code>coredns</code> pod is schedule to master node, but have <code>CrashLoopBackOff</code> state, the log of <code>coredns</code> pod as following:</p>
<pre><code>E0118 10:06:02.408608       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.2/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500&amp;resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
E0118 10:06:02.408752       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.2/tools/cache/reflector.go:105: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&amp;resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
[INFO] SIGTERM: Shutting down servers then terminating
[INFO] plugin/health: Going into lameduck mode for 5s
</code></pre>
<p><a href="https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods/" rel="nofollow noreferrer">This article</a> say DNS components must run on a regular cluster node (rather than the Kubernetes master):</p>
<blockquote>
<p>In addition to Kubernetes core components like api-server, scheduler,
controller-manager running on a master machine there are a number of
add-ons which, for various reasons, must run on a regular cluster node
(rather than the Kubernetes master). Some of these add-ons are
critical to a fully functional cluster, such as Heapster, DNS, and UI.</p>
</blockquote>
<p>Can anyone explain why <code>coredns</code> pod can't run on master node?</p>

<p>Starting from scratch Kubernetes idea is to deploy pods on worker nodes. Master nodes are a nodes which controls and manages worker nodes.</p>
<p>When the Kubernetes cluster is first set up, a Taint is set on the master node which automatically prevents any pods from being scheduled on this node. You can see this as well as modify this behavior if required. Best practice is not to deploy application workloads on a master server.</p>
<p>Read useful article: <a href="https://medium.com/@kumargaurav1247/no-pod-on-master-node-why-kubernetes-6afb07b05ce6#:%7E:text=The%20reason,workloads%20on%20a%20master%20server." rel="nofollow noreferrer">master-node-scheduling</a>.</p>
<p>However you can force pods/deployments to be deployed on master nodes by using <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector" rel="nofollow noreferrer">nodeSelector</a>. For example, give your master node a label say dedicated=master and set nodeSelector for your pod to look for this label.</p>
<p>See more: <a href="https://stackoverflow.com/questions/41999756/how-to-force-pods-deployments-to-master-nodes">deployment-on-master-nodes</a>.</p>
