<p>I'm trying to create a deployment along with a service and then access the service <strong>immediately</strong> as soon as the rollout is complete:</p>

<pre><code>&gt; kubectl create -f my-deployment.yaml
&gt; kubectl create -f my-service.yaml
&gt; kubectl rollout status deployment/my-deployment --watch --timeout 10m # This usually takes ~30 seconds

deployment "my-deployment" successfully rolled out

&gt; curl "my-service" # This happens inside a pod, so the service DNS name should be available
</code></pre>

<p>Sometimes this works, but there seems to be a race condition -- if the <code>curl</code> command happens too quickly, it seems the socket fails to connect and I get a connection timeout.</p>

<p>This seems like the behavior I would get if there were no ready pods, as per this question: <a href="https://stackoverflow.com/questions/54569216/what-happens-when-a-service-receives-a-request-but-has-no-ready-pods">What happens when a service receives a request but has no ready pods?</a></p>

<p>I expected that the completion of the rollout meant that the service was guaranteed to be ready to go. Is this not the case? Is there some Kubernetes command to "wait" for the service to be available? (I notice that services don't have conditions, so you can't do <code>kubectl wait</code>...)</p>

<p>To know if a service is ready you can check if an endpoints object exists with the name of the service and if that endpoint object has IPs or not. If IPs are there that means service is ready. But there is no guarantee that it will still not fail because there can be a network issue in your infrastructure.</p>
<p>K8s primitives that manage pods, such as Deployment, only take pod status into account for decision making, such as advancement during a rolling update.</p>
<p>For example, during deployment rolling update, a new pod becomes ready. On the other hand, service, network policy, and load-balancer are not yet ready for the new pod due to whatever reason (e.g. slowness in API machinery, endpoints controller, kube-proxy, iptables, or infrastructure programming). This may cause service disruption or loss of backend capacity. In extreme cases, if rolling update completes before any new replacement pod actually starts serving traffic, this will cause service outage.</p>
<p>Here is the <a href="https://github.com/kubernetes/enhancements/blob/f1a799d5f4658ed29797c1fb9ceb7a4d0f538e93/keps/sig-network/0007-pod-ready%2B%2B.md" rel="nofollow noreferrer">proposal</a> to improve pod readiness which is motivated by the above problem.</p>
