<p>I have 2 Deployment -  A(1 replica) and  B(4 replica)</p>

<p>I have scheduled job in the POD A and on successful completion it hits endpoint present in one of the Pods from Deployment B through the service for Deployment B.</p>

<p>Is there a way I can hit all the endpoints of 4 PODS from Deployment B on successful completion of job?</p>

<p>Ideally one of the pod is notified!! But is this possible as I don't want to use pub-sub for this.</p>

<blockquote>
<p>Is there a way I can hit all the endpoints of 4 PODS from Deployment B on successful completion of job?</p>
<p>But is this possible as I don't want to use pub-sub for this.</p>
</blockquote>
<p>As you say, a pub-sub solution is best for this problem. But you don't want to use it.</p>
<p><strong>Use stable network identity for Service B</strong></p>
<p>To solve this without pub-sub, you need a stable network-identity for the pods in <em>Deployment B</em>. To get this, you need to change to a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a> for your service B.</p>
<blockquote>
<p>StatefulSets are valuable for applications that require one or more of the following.</p>
<ul>
<li>Stable, unique network identifiers.</li>
</ul>
</blockquote>
<p>When B is deployed with a StatefulSet, your job or other applications can reach your pods of B, with a stable network identity that is the same for every version of service B that you deploy. Remember that you also need to deploy a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#headless-services" rel="nofollow noreferrer">Headless Service</a> for your pods.</p>
<p><strong>Scatter pattern:</strong> You can have an application aware (e.g. aware of number of pods of <em>Service B</em>) proxy, possibly as a sidecar. Your job sends the request to this proxy. The proxy then sends a request to all your replicas. As described in <a href="https://rads.stackoverflow.com/amzn/click/com/1491983647" rel="nofollow noreferrer" rel="nofollow noreferrer">Designing Distributed Systems: Patterns and Paradigms</a></p>
<p><strong>Pub-Sub or Request-Reply</strong></p>
<p>If using <em>pub-sub</em>, the job only publish an event. Each pod in B is responsible to subscribe.</p>
<p>In a <em>request-reply</em> solution, the job or a proxy is responsible for watching what pods exists (unless it is a fixed number of pods) in service B, in addition it need to send request to all, if requests fails to any pod (it will happen on deployments sometime) it is responsibly to retry the request to those pods.</p>
<p>So, yes, it is a much more complicated problem in a request-reply way.</p>
