<p>If you want to place a pod on each node you can use DaemonSet. DaemonSets are configured to distribute the application to each node. For detailed information;</p>
<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/</a></p>
<p>You can find out if DaemonSet is what you need by looking specifically at this title;</p>
<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#deployments" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#deployments</a></p>

CC BY-SA 4.0
2022-07-18T10:50:40.597Z
2022-07-18T10:50:40.597Z
yildirim
<p>The scheduler placing your pods on one or two nodes, until they're out of resources, could be a &quot;normal&quot; behavior depending on your cluster scheduler policy.</p>
<p>You could try to use an <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity" rel="nofollow noreferrer">antiAffinity rule</a>, or a <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/" rel="nofollow noreferrer">topologySpreadConstraints</a>, placing your pods on all 4 nodes.</p>
<p>The following sample, from Kubernetes docs, would use topology key 'kubernetes.io/hostname', which should spread your pods on different nodes:</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: kubernetes.io/hostname
</code></pre>
<p>The <code>requiredDuringSchedulingIgnoredDuringExecution</code> would prevent the Kubernetes scheduler from ever starting a replicas on a node that already has a Pod that belongs to your deployment.</p>
<p>We could do something similar with a <code>topologySpreadConstraints</code>:</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-store
</code></pre>

CC BY-SA 4.0
2022-07-24T08:02:37.500Z
The OP didn't include a copy of their manifest, but one can likely safely assume that given they are talking about "deployments" that they are deploying a ReplicaSet (the default for deployment.apps) not a DaemonSet, which means that there would only be spec.replicas pods deployed, regardless of the node count. Only a DaemonSet would deploy as many replicas as there are nodes, subject to node affinity/topology constraints.
Kyanar
CC BY-SA 4.0
2022-07-24T12:58:30.017Z
There are no mentions to replicas in initial question. Question is: why is it spreading on two nodes. There is no mention of a requirement to run "1 replica per node" either. Very much sounds like OP wants to know why, adding replicas, they're not spreading.
SYN
CC BY-SA 4.0
2022-07-17T17:53:53.973Z
2022-07-17T17:53:53.973Z
SYN
<p>I am a beginner in kubernetes. I have a cluster running with 4 nodes. All the nodes are currently running fine. They are not tainted, or drained. Every time I deploy a deployment it will only deploy it across 2 nodes instead of 4 nodes. I am trying to look for kube-scheduler logs, but because I am using Oracle Cloud OKE service (kubernetes service for Oracle cloud). They don't make kube-scheduler logs available to customers. What tests or what verifications do I need to do?</p>

<kubernetes><deployment>
K8s cluster not deploying deployments across all the nodes
hxugox97
# K8s cluster not deploying deployments across all the nodes

(Asked by: username_0 on 2022-07-13)

I am a beginner in kubernetes. I have a cluster running with 4 nodes. All the nodes are currently running fine. They are not tainted, or drained. Every time I deploy a deployment it will only deploy it across 2 nodes instead of 4 nodes. I am trying to look for kube-scheduler logs, but because I am using Oracle Cloud OKE service (kubernetes service for Oracle cloud). They don't make kube-scheduler logs available to customers. What tests or what verifications do I need to do?

**Tags:** kubernetes, deployment


---

## 2 answers

### Answer by username_1 on 2022-07-18. Score: 2

If you want to place a pod on each node you can use DaemonSet. DaemonSets are configured to distribute the application to each node. For detailed information;

<https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/>

You can find out if DaemonSet is what you need by looking specifically at this title;

<https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#deployments>


---

### Answer by username_2 on 2022-07-17. Score: 1

The scheduler placing your pods on one or two nodes, until they're out of resources, could be a "normal" behavior depending on your cluster scheduler policy.
You could try to use an antiAffinity rule, or a topologySpreadConstraints, placing your pods on all 4 nodes.
The following sample, from Kubernetes docs, would use topology key 'kubernetes.io/hostname', which should spread your pods on different nodes:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: kubernetes.io/hostname

The requiredDuringSchedulingIgnoredDuringExecution would prevent the Kubernetes scheduler from ever starting a replicas on a node that already has a Pod that belongs to your deployment.
We could do something similar with a topologySpreadConstraints:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-store

> **Comments:**
> **username_3**: The OP didn't include a copy of their manifest, but one can likely safely assume that given they are talking about "deployments" that they are deploying a ReplicaSet (the default for deployment.apps) not a DaemonSet, which means that there would only be spec.replicas pods deployed, regardless of the node count. Only a DaemonSet would deploy as many replicas as there are nodes, subject to node affinity/topology constraints.  
> **username_2**: There are no mentions to replicas in initial question. Question is: why is it spreading on two nodes. There is no mention of a requirement to run "1 replica per node" either. Very much sounds like OP wants to know why, adding replicas, they're not spreading.  

---

