<p>I'm new to k8s, so this question might be kind of weird, please correct me as necessary.</p>
<p>I have an application which requires a <code>redis</code> database. I know that I should configure it to connect to <code>&lt;redis service name&gt;.&lt;namespace&gt;</code> and the cluster DNS will get me to the right place, <em>if it exists</em>.</p>
<p>It feels to me like I want to express the relationship between the application and the database. Like I want to say that the application shouldn't be deployable until the database is there and working, and maybe that it's in an error state if the DB goes away. Is that something you'd normally do, and if so - how? I can think of other instances: like with an SQL database you might need to create the tables your app wants to use at init time.</p>
<p>Is the alternative to try to connect early and <code>exit 1</code>, so that the cluster keeps on retrying? Feels like that would work but it's not very declarative.</p>

<h2>Design for resiliency</h2>
<p>Modern applications and Kubernetes are (or should be) designed for resiliency. The applications should be designed without <em>single point of failure</em> and be resilient to changes in e.g. network topology. Also see <a href="https://12factor.net/backing-services" rel="nofollow noreferrer">Twelve factor-app: IV. Backing services</a>.</p>
<p>This means that your Redis typically should be a cluster of e.g. 3 instances. It also means that your app should <strong>retry connections</strong> if connections fails - this can also happens same time after running - since upgrades of a cluster (or rolling upgrade of an app) is done by terminating one instance at a time meanwhile a new instance at a time is launched. E.g. the instance (of a cluster) that your app <strong>currently is connected to might go away</strong> and your app need to reconnect, perhaps establish a connection to a different instance in the same cluster.</p>
<h2>SQL Databases and schemas</h2>
<blockquote>
<p>I can think of other instances: like with an SQL database you might need to create the tables your app wants to use at init time.</p>
</blockquote>
<p>Yes, this is a different case. On Kubernetes your app is typically deployed with at least 2 replicas, or more (for high-availability reasons). You need to consider that when managing schema changes for your app. Common tools to manage the schema are <a href="https://flywaydb.org/" rel="nofollow noreferrer">Flyway</a> or <a href="https://www.liquibase.org/" rel="nofollow noreferrer">Liquibase</a> and they can be run as <a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/" rel="nofollow noreferrer">Jobs</a>. E.g. first launch a Job to create your DB-tables and after that deploy your app. And after some weeks you might want to change some tables and launch a new Job for this schema migration.</p>
