<p>we have a <strong>deamonset</strong> and we want to make it HA (not our deamonset), does the following is applicable for HA for deamaon set also?</p>
<ul>
<li>affinity (anti affinity)</li>
<li>toleration's</li>
<li>pdb</li>
</ul>
<p>we have on each cluster 3 worker nodes
I did it in the past for deployment but not sure what is also applicable for deamonset, this is <strong>not our app</strong> but we need to make sure it is HA as it's critical app</p>
<p><strong>update</strong></p>
<p>Does it make sense to add the following to deamonset, lets say I've 3 worker nodes and I want it to be scheduled only in <code>foo</code> workers nodes?</p>
<pre><code>spec:
  tolerations:
    - effect: NoSchedule
      key: WorkGroup
      operator: Equal
      value: foo
    - effect: NoExecute
      key: WorkGroup
      operator: Equal
      value: foo
  nodeSelector:
    workpcloud.io/group: foo
</code></pre>

Jenney
<p>You have asked two, somewhat unrelated questions.</p>
<blockquote>
<p>does the following is applicable for HA for deamaon set also?</p>
<ul>
<li>affinity (anti affinity)</li>
<li>toleration's</li>
<li>pdb</li>
</ul>
</blockquote>
<p>A <a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/" rel="nofollow noreferrer">daemonset</a> (generally) runs on a policy of &quot;one pod per node&quot; -- you <strong>CAN'T</strong> make it HA (for example, by using autoscaling), and you will (assuming you use defaults) have as many replicas of the daemonset as you have nodes, unless you explicitly specify which nodes you want to want to run the daemonset pods, using things like <code>nodeSelector</code> and/or <code>tolerations</code>, in which case you will have less pods. The documentation page linked above gives more details and has some examples</p>
<blockquote>
<p>this is not our app but we need to make sure it is HA as it's critical app</p>
</blockquote>
<p>Are you asking how to make your critical app HA? I'm going to assume you are.</p>
<p>If the app is as critical as you say, then a few starter recommendations:</p>
<ol>
<li>Make sure you have at least 3 replicas (4 is a good starter number)</li>
<li>Add tolerations if you must schedule those pods on a node pool that has taints</li>
<li>Use node selectors as needed (e.g. for regions or zones, but only if necessary do to something like disks being present in those zones)</li>
<li>Use affinity to group or spread your replicas. Definitely would recommend using a spread so that if one node goes down, the other replicas are still up</li>
<li>Use a <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/" rel="nofollow noreferrer">pod priority</a> to indicate to the cluster that your pods are more important than other pods (beware this may cause issues if you set it too high)</li>
<li>Setup notifications to something like PagerDuty, OpsGenie, etc, so you (or your ops team) are notified if the app goes down. If the app is critical, then you'll want to know it's down ASAP.</li>
<li>Setup <a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets" rel="nofollow noreferrer">pod disruption budgets</a>, and <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/" rel="nofollow noreferrer">horizontal pod autoscalers</a> to ensure an agreed number of pods are always up.</li>
</ol>
