<p>I am using Helm v3.3.0, with a Kubernetes 1.16.</p>
<p>The cluster has the <a href="https://svc-cat.io/docs/" rel="nofollow noreferrer">Kubernetes Service Catalog</a> installed, so external services implementing the Open Service Broker API spec can be instantiated as K8S resources - as <code>ServiceInstance</code>s and <code>ServiceBinding</code>s.</p>
<p><code>ServiceBinding</code>s reflect as K8S <code>Secret</code>s and contain the binding information of the created external service. These secrets are usually mapped into the Docker containers as environment variables or volumes in a K8S <code>Deployment</code>.</p>
<p>Now I am using Helm to deploy my Kubernetes resources, and I read <a href="https://helm.sh/docs/topics/charts/#operational-aspects-of-using-dependencies" rel="nofollow noreferrer">here</a> that...</p>
<blockquote>
<p>The [Helm] install order of Kubernetes types is given by the enumeration InstallOrder in <a href="https://github.com/helm/helm/blob/release-3.3/pkg/releaseutil/kind_sorter.go" rel="nofollow noreferrer">kind_sorter.go</a></p>
</blockquote>
<p>In that file, the order does neither mention <code>ServiceInstance</code> nor <code>ServiceBinding</code> as resources, and that would mean that Helm installs these resource types <strong>after</strong> it has installed any of its InstallOrder list - in particular <code>Deployment</code>s. That seems to match the output of <code>helm install --dry-run --debug</code> run on my chart, where the order indicates that the K8S Service Catalog resources are applied last.</p>
<p><strong>Question:</strong> What I cannot understand is, why my <code>Deployment</code> does <strong>not</strong> fail to install with Helm.
After all my <code>Deployment</code> resource seems to be deployed before the <code>ServiceBinding</code> is. And it is the <code>Secret</code> generated out of the <code>ServiceBinding</code> that my <code>Deployment</code> references. I would expect it to fail, since the <code>Secret</code> is not there yet, when the <code>Deployment</code> is getting installed. But that is not the case.</p>
<p>Is that just a timing glitch / lucky coincidence, or is this something I can rely on, and why?</p>
<p>Thanks!</p>

FloW
<p>So to answer my own question (and thanks to @dawid-kruk and the folks on Service Catalog Sig on Slack):</p>
<ul>
<li>In fact, the initial start of my <code>Pod</code>s (the ones referencing the <code>Secret</code> created out of the <code>ServiceBinding</code>) fails! It fails because the <code>Secret</code> is actually not there the moment K8S tries to start the pods.</li>
<li>Kubernetes has a self-healing mechanism, in the sense that it tries (and retries) to reach the target state of the cluster as described by the various deployed resources.</li>
<li>By Kubernetes retrying to get the pods running, eventually (when the <code>Secret</code> is finally there) all conditions will be satisfied to make the pods start up nicely. Therefore, eventually, evth. is running as it should.</li>
</ul>
<p>How could this be streamlined? One possibility would be for Helm to include the custom resources <code>ServiceBinding</code> and <code>ServiceInstance</code> into its ordered list of installable resources and install them early in the installation phase.</p>
<p>But even without that, Kubernetes actually deals with it just fine. The order of installation (in this case) really does not matter. And that is a good thing!</p>
