Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-07-18T10:50:40.597Z
Answers: 2022-07-18T10:50:40.597Z
Answers: yildirim
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-07-24T08:02:37.500Z
Answers: 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.
Answers: Kyanar
Answers: CC BY-SA 4.0
Answers: 2022-07-24T12:58:30.017Z
Answers: 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.
Answers: SYN
Answers: CC BY-SA 4.0
Answers: 2022-07-17T17:53:53.973Z
Answers: 2022-07-17T17:53:53.973Z
Answers: SYN
Body: <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>
  
Tags: <kubernetes><deployment>
Title: K8s cluster not deploying deployments across all the nodes
UserDisplayName: hxugox97
ThreadText: # 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](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), or a [topologySpreadConstraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/), 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.  
  
  ---
  
  