Question posted in
The official documentation can be found here.

Redis – Expressing that a service requires another

I’m new to k8s, so this question might be kind of weird, please correct me as necessary.

I have an application which requires a redis database. I know that I should configure it to connect to <redis service name>.<namespace> and the cluster DNS will get me to the right place, if it exists.

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.

Is the alternative to try to connect early and exit 1, so that the cluster keeps on retrying? Feels like that would work but it’s not very declarative.

Tags:

4

Answers


  1. 0

    This is up to your application code, not something Kubernetes helps nor hinders.

    Login or Signup to reply.
  2. 0

    I think Init Containers is something you could leverage for this use case

    Login or Signup to reply.
  3. 0

    As you’ve seen, YAML objects can not express such dependencies. As suggested by @fabian-lopez, your application container may include an initContainer that would wait for dependencies to be available, before starting their main container.

    Now, if you want a state machine, capable to provision a database, initialize its schema, maybe import some records, and only then create your application: you’re looking for an operator. Then, you may use the operator-sdk ( https://github.com/operator-framework/operator-sdk ), or pretty much anything integrating with some Kubernetes cluster API.

    Login or Signup to reply.
  4. 0

    Design for resiliency

    Modern applications and Kubernetes are (or should be) designed for resiliency. The applications should be designed without single point of failure and be resilient to changes in e.g. network topology. Also see Twelve factor-app: IV. Backing services.

    This means that your Redis typically should be a cluster of e.g. 3 instances. It also means that your app should retry connections 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 currently is connected to might go away and your app need to reconnect, perhaps establish a connection to a different instance in the same cluster.

    SQL Databases and schemas

    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.

    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 Flyway or Liquibase and they can be run as Jobs. 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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search