<p>I have one <code>kubernetes master</code> and three <code>kubernetes nodes</code>. I made one pod which is running on specific node. I want to run that pod on 2 nodes. how can I achieve this? do <code>replica</code> concept help me? if yes how?</p>

<p><strong>Yes</strong>, you can assign pods to one or more nodes of your cluster, and here are some options to achieve this:</p>
<p><a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector" rel="nofollow noreferrer"><strong>nodeSelector</strong></a></p>
<blockquote>
<p>nodeSelector is the simplest recommended form of node selection constraint. nodeSelector is a field of PodSpec. It specifies a map of key-value pairs. For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well). The most common usage is one key-value pair.</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity" rel="nofollow noreferrer"><strong>affinity and anti-affinity</strong></a></p>
<blockquote>
<p>Node affinity is conceptually similar to nodeSelector -- it allows you to constrain which nodes your pod is eligible to be scheduled on, based on labels on the node.</p>
<p>nodeSelector provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity feature, greatly expands the types of constraints you can express. The key enhancements are</p>
<ol>
<li>The affinity/anti-affinity language is more expressive. The language offers more matching rules besides exact matches created with a logical AND operation;</li>
<li>you can indicate that the rule is &quot;soft&quot;/&quot;preference&quot; rather than a hard requirement, so if the scheduler can't satisfy it, the pod will still be scheduled;</li>
<li>you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located</li>
</ol>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/" rel="nofollow noreferrer"><strong>DaemonSet</strong></a></p>
<blockquote>
<p>A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.</p>
<p>Some typical uses of a DaemonSet are:</p>
<ul>
<li>running a cluster storage daemon on every node</li>
<li>running a logs collection daemon on every node</li>
<li>running a node monitoring daemon on every node</li>
</ul>
</blockquote>
<p>Please check <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/" rel="nofollow noreferrer">this</a> link to read more about how to assign pods to nodes.</p>
