How To Use KubeDB and Postgres Sidecar for Database Integrations in Kubernetes

In contemporary web development, a recurring challenge revolves around harmonizing the convenience and simplicity of using a database with a web application. My name is Viacheslav Aksenov, and in this article, I aim to explore several of the most popular approaches for integrating databases and web applications within the Kubernetes ecosystem. These examples are examined within the context of a testing environment, where constraints are more relaxed. However, these practices can serve as a foundation applicable to production environments as well.

Running a database alongside a microservice aligns with the principles outlined in the Twelve-Factor App methodology. One key factor is "Backing Services" (Factor III), which suggests treating databases, message queues, and other services as attached resources to be attached or detached seamlessly. 

By co-locating the database with the microservice, we adhere to the principle of having a single codebase that includes the application and its dependencies, making it easier to manage, scale, and deploy. 

Additionally, it promotes encapsulation and modularity, allowing the microservice to be self-contained and portable across different environments, following the principles of the Twelve-Factor App. This approach enhances the maintainability and scalability of the entire application architecture.

For this task, you can leverage various tools, and one example is using KubeDB.

In the context of Kubernetes and databases like PostgreSQL, a sidecar is a separate container that runs alongside the main application container within a pod. The sidecar pattern is commonly used to enhance or extend the functionality of the main application container without directly impacting its core logic.

Let's see the example of a configuration for a small Spring Boot Kotlin service that handles cat names.

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cat-svc
  labels:
    app: cat-svc
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cat-svc
  template:
    metadata:
      labels:
        app: cat-svc
        type: http
    spec:
      containers:
        - name: cat-svc
          image: cat-svc:0.0.1
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          readinessProbe:
            httpGet:
              path: /actuator/health
              port: 8080
            initialDelaySeconds: 30
            timeoutSeconds: 10
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /actuator/health
              port: 8080
            initialDelaySeconds: 60
            timeoutSeconds: 10
            periodSeconds: 30
          env:
            - name: PLACES_DATABASE
              value: localhost:5432/cats
            - name: POSTGRES_USER
              value: pwd
            - name: POSTGRES_PASSWORD
              value: postgres
        - name: cat-postgres
          image: postgres:11.1
          ports:
            - name: http
              containerPort: 5432
              protocol: TCP
          env:
            - name: POSTGRES_USER
              value: pwd
            - name: POSTGRES_PASSWORD
              value: postgres
            - name: POSTGRES_DB
              value: cats

FROM gradle:8.3.0-jdk17
COPY . .
EXPOSE 8080
CMD ["gradle", "bootRun"]

And for local run, it is possible to use docker-compose with the following configuration.

docker-compose.yaml:

version: '3.8'
services:
  cat-postgres:
    image: postgres:12.13
    restart: always
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: cats
#    volumes:
#      - ./init.sql:/docker-entrypoint-initdb.d/create_tables.sql - if you want to run any script before an app
#      - ./db-data/:/var/lib/postgresql/data/
  service:
    image: cat-svc:0.0.1
    restart: always
    ports:
      - '8080:8080'
    environment:
      SPRING_PROFILES_ACTIVE: prod
      PLACES_DATABASE: cat-postgres:5432/cats
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres

Migrations

The big thing that has to be decided before using this approach is the migration question. The best option in this approach is to delegate the migration process to any tool that can work within your app infrastructure. For example, for Java World, you could use Flyway or Liquibase.

1. Flyway is a popular open-source database migration tool. It allows you to version control your database schema and apply changes in a structured manner. Flyway supports multiple databases, including PostgreSQL, MySQL, and Oracle.
2. Liquibase is an open-source database migration tool that supports tracking, managing, and applying database changes. It provides a way to define database changes using XML, YAML, or SQL, and it supports various databases.

Pros of Using a PostgreSQL Sidecar in Kubernetes

1. Separation of concerns: Sidecars allow you to separate specific functionalities (e.g., database migrations, backups) from the main application logic. Сompliance with microservice architecture.
2. Simplified deployment: Sidecars can be deployed and managed alongside the main application using the same deployment configurations, simplifying the overall deployment process. You don't need to support separated database for testing the environment. And it leads to decreasing the complexity of tests (you don't need to think about collisions while you are running many CI with tests for the same table)

Cons of Using a PostgreSQL Sidecar in Kubernetes

1. Resource overhead: Running additional containers consumes resources (CPU, memory) on the node, which may impact the overall performance and resource utilization of the Kubernetes cluster. It's best to use as few resources as possible.
2. Startup order: The main application may become dependent on the sidecar for certain functionalities, potentially leading to issues if there are discrepancies or version mismatches between the main application and the sidecar. Arranging containers in a specific order without additional configuration can be somewhat challenging. However, this shouldn't pose a problem in test environments due to the quick startup of the PostgreSQL container. In most scenarios, the PostgreSQL container will initiate before any of your business applications. Even if the application attempts to run before PostgreSQL is ready, it will encounter a failure and be automatically restarted by the default Kubernetes mechanism until the database becomes available.
3. Learning curve: Adopting the sidecar pattern may require a learning curve for development and operations teams, particularly if they are new to the concept of containerized sidecar architectures. Once the setup is complete, new team members should encounter no issues with this approach.