Migrating Docker Compose to Kubernetes

A Tale of Two Worlds: Compose vs. Kubernetes

Before we analyze a file, we need to understand the fundamental differences in how Docker Compose and Kubernetes approach networking and storage. They operate on different philosophical levels: one is designed for a single host, the other for a distributed cluster.

This shift from a single-host to a multi-host paradigm is the root of all the modifications we need to make.

Part 1: Deconstructing the Network

Let's break down how networking concepts translate from Compose to Kubernetes.

The Docker Compose Network

In Docker Compose, when you run docker compose up, it typically creates a dedicated bridge network for your application. All services defined in the file are attached to this network.

• Service Discovery: Containers can find each other using their service name as a DNS hostname (e.g., the web service can connect to db). This works because Docker's embedded DNS server resolves these names within the scope of that single network.
• Exposure: Services are exposed to the outside world by mapping a port on the host to a port on the container (ports: "8080:80").

The Kubernetes Network

Kubernetes uses a fundamentally different model. It assumes a flat network, where every pod in the cluster gets its own unique IP address and can communicate with any other pod, regardless of which physical or virtual machine (node) it's on.

• Service Discovery: Pods are ephemeral and their IPs change. To provide a stable endpoint, Kubernetes uses a Service object. A Service gets a stable internal IP (ClusterIP) and a DNS name (e.g., db-service) that automatically load-balances traffic to the correct group of pods.
• Exposure: Exposing your application externally is more sophisticated:
  • Service of type NodePort: Exposes the service on a static port on each node's IP. This is useful for testing but not ideal for production.
  • Service of type LoadBalancer: On a cloud provider, this automatically provisions an external load balancer and points it to your service. This is the standard way to expose a TCP/UDP service.
  • Ingress: An API object that manages external access to HTTP/S services in the cluster. It can provide routing based on hostname or path (e.g., api.example.com -> api-service), and handle TLS termination.

To solidify these concepts, let's turn to a guide.

Part 2: Deconstructing Storage

Now, let's apply the same comparative analysis to storage.

Docker Compose Volumes

In Compose, persistence is typically handled in two ways, both tied to the host machine:

• Named Volumes: (volumes: - db-data:/var/lib/postgresql/data). Docker manages a specific directory on the host's filesystem. This is the preferred method in Compose.
• Bind Mounts: (volumes: - .:/app). This mounts a directory from your host machine directly into the container. Great for development (live code reloading) but a major anti-pattern for production as it creates a tight coupling to a specific host's file structure.

Kubernetes Volumes

Kubernetes completely abstracts storage away from the host.

• PersistentVolume (PV): Represents a "piece of storage" in the cluster. This could be a cloud disk (like an AWS EBS volume), an NFS share, or another storage backend. It's a cluster resource, just like CPU or memory.
• PersistentVolumeClaim (PVC): A request for storage by a user or application. A pod requests a certain size and type of storage, and Kubernetes finds a matching PV to bind to that claim. This is the key abstraction: your pod doesn't need to know what kind of storage it's using, only that it needs it.
• StatefulSet vs. Deployment:
  • Deployment: Used for stateless applications. Pods are interchangeable and can be scaled up or down easily.
  • StatefulSet: Used for stateful applications like databases. It provides pods with stable, unique network identifiers (e.g., db-0, db-1) and stable, persistent storage. Each pod in a StatefulSet gets its own unique PVC.

Let's return to the "Moving Docker Compose to Kubernetes" guide for the storage mapping.

Part 3: The Complete Analysis - A Walkthrough

Now let's put it all together and analyze a real docker-compose.yml file. We will use the example of a simple Node.js application with a MongoDB database.

Here is the original docker-compose.yaml file (from the DigitalOcean tutorial LINK):

# docker-compose.yaml (for analysis)
version: '3.7'

services:
  nodejs:
    build:
      context: .
      dockerfile: Dockerfile
    image: nodejs
    container_name: nodejs
    restart: unless-stopped
    env_file: .env
    ports:
      - "80:8080"
    volumes:
      - .:/home/node/app
      - node_modules:/home/node/app/node_modules
    networks:
      - app-network
    command: ./wait-for.sh db:27017 -- /home/node/app/node_modules/.bin/nodemon app.js

  db:
    image: mongo:4.1.8-xenial
    container_name: db
    restart: unless-stopped
    env_file: .env
    volumes:
      - dbdata:/data/db
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

volumes:
  dbdata:
  node_modules:

Let's audit this file, identifying every piece that needs to change for Kubernetes.

To see what these translated Kubernetes objects look like, the following video provides an excellent side-by-side walkthrough.

version: '3.8'

services:
  db:
    image: mysql:8.0
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - app-net
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress

  wordpress:
    image: wordpress:latest
    volumes:
      - wp_data:/var/www/html
    ports:
      - "8000:80"
    networks:
      - app-net
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_PASSWORD=somewordpress

volumes:
  db_data:
  wp_data:

networks:
  app-net:

Conclusion

You have now learned how to perform a critical analysis of a Docker Compose application, identifying the necessary changes to make it compatible with Kubernetes. This process goes beyond simple translation; it requires a shift in thinking from a single-host model to a distributed, abstract one.

Key Takeaways:

• Networking: Host-bound port mappings (ports) become Service and Ingress objects. Isolated Compose networks become a single, flat pod network where Service objects provide stable DNS endpoints.
• Storage: Host-bound volumes and bind mounts are replaced by the PersistentVolume and PersistentVolumeClaim abstraction, decoupling storage from any single node.
• Application Type: You must identify services as either stateless (Deployment) or stateful (StatefulSet) to manage their lifecycle and data correctly.

In our next and final lesson of this module, we will put this analysis into action. We will use a tool like Kompose to translate a Docker Compose file into Kubernetes manifests, and with the knowledge from today, you'll be able to understand, critique, and refine its output like a pro.