What is this article about?

The article explains how parts of the Nautix platform are migrated from Docker Compose to Kubernetes, and how this directly fulfills CCIE Automation blueprint requirements for packaging and deploying solutions.

Why is Kubernetes a natural next step after Docker Compose?

Kubernetes provides a more robust and scalable operational model with declarative deployments, built-in health checks, self-healing, service discovery, and native handling of configuration and secrets.

What role does kind play in the setup?

kind is used to run a full Kubernetes cluster locally inside Docker, making it well suited for labs, testing, and learning without requiring external infrastructure.

How are secrets handled in the Kubernetes solution?

Secrets are stored as native Kubernetes Secret objects and referenced directly by Deployments, ensuring sensitive values are not committed to source control.

How does Kubernetes improve platform resilience?

By using readiness and liveness probes, Kubernetes can automatically control traffic and restart failing pods, resulting in a more resilient platform by default.

Sicra helps organizations design and adopt modern container and Kubernetes-based platforms, focusing on secure operations, scalability, and controlled deployments. Read more about "Cloud (Azure, AWS, Google)" here > Read more about "Secure software development" here > Read more about "Access management – Identity and Access Management (IAM)" here > Read more about "Project management" here >

[My journey to CCIE Automation #10] From Docker Compose to Kubernetes

(This article was originally published on Bluetree.no. Following the merger of Sicra and Bluetree, content from Bluetree has now been migrated to Sicra.)

[My journey to CCIE Automation #10] From Docker Compose to Kubernetes is part of a series documenting my CCIE Automation journey. In the previous post, I focused on secure coding practices in Python. In this post, I take the next step by migrating parts of the platform from Docker Compose to Kubernetes.

Blog #10

Up until now, Nautix has been running using Docker Compose. That worked well in the early stages, but for Blueprint 4.3 – Package and deploy a solution by using Kubernetes, it was time to take the next step.

In this post, I’ll show how I migrated parts of Nautix to Kubernetes, running locally on my development laptop, and how that maps directly to the CCIE Automation blueprint.

Why Kubernetes?

Docker Compose is great for local development, but Kubernetes gives you:

Declarative deployments
Built-in health checking and self-healing
Native secrets and configuration management
Service discovery and load balancing
A consistent operational model across environments

Local Kubernetes setup using kind

For local development, I chose kind (Kubernetes IN Docker).

Why kind?

Lightweight and fast
Runs entirely inside Docker
Perfect for labs and experimentation
Uses real Kubernetes APIs and tooling

Forutsetninger

Docker Desktop (with WSL2 integration)
kubectl
kind

Create a kind cluster with ingress support

I created the cluster with explicit port mappings so the ingress controller could be reached from my laptop:

# kind-nautix.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 80
hostPort: 80
- containerPort: 443
hostPort: 443

Create the cluster:

kind create cluster --name nautix --config kind-nautix.yaml

Install ingress-nginx:

kubectl apply -f \
https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

At this point, I had a fully functional Kubernetes cluster running locally.

Namespace: isolating Nautix

First, I created a dedicated namespace:

apiVersion: v1
kind: Namespace
metadata:
name: nautix

kubectl apply -f k8s/00-namespace.yaml
kubectl config set-context --current --namespace=nautix

Namespaces are a simple but powerful concept — they provide isolation and make it much easier to reason about resources.

Handling secrets

In Docker Compose, secrets often end up in .env files.
In Kubernetes, secrets are first-class objects.

Instead of committing secrets to Git, I created them imperatively using kubectl:

kubectl create secret generic nautix-secrets \
--from-literal=VAULT_DEV_ROOT_TOKEN_ID=root-token \
-n nautix

This creates a native Kubernetes Secret that can be safely referenced by Deployments without storing sensitive values in source control.

Deploying the Inventory service

The Inventory service is a stateless Flask API, making it a perfect candidate for a Deployment.

Inventory Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: inventory
namespace: nautix
spec:
replicas: 1
selector:
matchLabels:
app: inventory
template:
metadata:
labels:
app: inventory
spec:
containers:
- name: inventory
image: nautix-inventory:dev
ports:
- containerPort: 8000
readinessProbe:
httpGet:
path: /healthz
port: 8000
initialDelaySeconds: 3
livenessProbe:
httpGet:
path: /healthz
port: 8000
initialDelaySeconds: 10

Inventory Service

apiVersion: v1
kind: Service
metadata:
name: inventory
namespace: nautix
spec:
selector:
app: inventory
ports:
- port: 8000
type: ClusterIP

The Deployment manages pod lifecycle and replicas, while the Service provides a stable network endpoint inside the cluster.

Deploying Vault with persistent storage

Vault runs in dev mode for this lab, but I still wanted to demonstrate volumes and persistent storage.

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: vault-data
namespace: nautix
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi

Vault Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: vault
namespace: nautix
spec:
replicas: 1
selector:
matchLabels:
app: vault
template:
metadata:
labels:
app: vault
spec:
containers:
- name: vault
image: vault:1.8.7
ports:
- containerPort: 8200
env:
- name: VAULT_DEV_LISTEN_ADDRESS
value: "0.0.0.0:8200"
- name: VAULT_DEV_ROOT_TOKEN_ID
valueFrom:
secretKeyRef:
name: nautix-secrets
key: VAULT_DEV_ROOT_TOKEN_ID
volumeMounts:
- name: data
mountPath: /vault/file
volumes:
- name: data
persistentVolumeClaim:
claimName: vault-data

Vault Service

apiVersion: v1
kind: Service
metadata:
name: vault
namespace: nautix
spec:
selector:
app: vault
ports:
- port: 8200
type: ClusterIP

Exposing services with Ingress

To expose the services externally, I used host-based routing via Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nautix
namespace: nautix
spec:
ingressClassName: nginx
rules:
- host: inventory.nautix.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: inventory
port:
number: 8000
- host: vault.nautix.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: vault
port:
number: 8200

Med riktige host-oppføringer på laptopen min kunne jeg nå nå:

http://inventory.nautix.local
http://vault.nautix.local

Spinning everything up

With the appropriate host entries on my laptop, I could now access:

kubectl apply -f k8s/

Verify:

kubectl get pods
kubectl get svc
kubectl get ingress

At this point, both Inventory and Vault were running fully inside Kubernetes.

Managing pod lifecycle with kubectl

This is where Kubernetes really shines.

Scaling

kubectl scale deploy inventory --replicas=3
kubectl get pods -l app=inventory

Logs

kubectl logs deploy/inventory
kubectl logs -f deploy/inventory

Self-healing

kubectl delete pod <inventory-pod>

The pod is automatically recreated — no manual intervention required.

Health checks and self-healing

Instead of Docker Compose depends_on, Kubernetes uses readiness and liveness probes.

Readiness controls whether traffic is sent to a pod
Liveness controls when a pod should be restarted

This makes the platform far more resilient by default.

Closing thoughts

By migrating even a small part of Nautix to Kubernetes, I was able to demonstrate every requirement in Blueprint 4.3 using real workloads:

Declarative deployments
Secure secret handling
Persistent storage
Ingress routing
Health checks
Scaling and lifecycle management
Full control via kubectl

Useful Links

Blog series

Need Assistance?

We are happy to have a non-binding conversation.