<p>A <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">service</a> dispatches to multiple replicas of a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">deployment</a> (default round-robin).</p>

<p>The backend instances temporarily have to go offline, i.e. they will close their port 80, take some time, and then open the port again.</p>

<p><code>deployment.yaml</code> is using <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/" rel="nofollow noreferrer"><code>readinessProbe</code></a> to regularly check which backend instances are ready to serve requests.</p>

<p>But what happens in the following scenario?</p>

<pre><code>1) readiness check backend A: OK
2) backend A goes offline
3) requests to service is forwarded to backend A
4) readiness check backend A: fail
</code></pre>

<p>Will the service send the request again but to another backend instance, or is it lost?</p>

<p>It depends on the type of Service. </p>

<p>If the Service is a ClusterIP or NodePort, it's instantiated as iptables rules. Packets destined for the now offline pod will be undeliverable, causing the request to timeout. </p>

<p>If the Service is a LoadBalancer, the implementation is an application, like nginx or an equivalent. It will watch for timeouts, and generally speaking- though dependent on configuration- will retry, allowing the request to make it to an online pod.</p>
