Learning Caddy - Kubernetes Deployment

#Introduction

Kubernetes is the standard for container orchestration, and Caddy can be one of its components — as an internal proxy or as an ingress controller. Episode 28 covers deploying Caddy on Kubernetes from scratch: basic resources, ingress, ConfigMap, and certificates.

#Basic Resources

#Deployment and Service

apiVersion: apps/v1
kind: Deployment
metadata:
  name: caddy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: caddy
  template:
    metadata:
      labels:
        app: caddy
    spec:
      containers:
        - name: caddy
          image: caddy:2
          ports:
            - containerPort: 80
            - containerPort: 443
          volumeMounts:
            - name: caddyfile
              mountPath: /etc/caddy
            - name: data
              mountPath: /data
      volumes:
        - name: caddyfile
          configMap:
            name: caddy-config
        - name: data
          persistentVolumeClaim:
            claimName: caddy-data

apiVersion: v1
kind: Service
metadata:
  name: caddy
spec:
  selector:
    app: caddy
  ports:
    - name: http
      port: 80
    - name: https
      port: 443
  type: LoadBalancer

#ConfigMap and PVC

#Caddyfile in a ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: caddy-config
data:
  Caddyfile: |
    app.example.com {
        reverse_proxy app-service:3000
    }
 
    web.example.com {
        reverse_proxy web-service:3000
    }

#PVC for Certificates

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: caddy-data
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

#Caddy as an Ingress

#The Ingress Controller Role

Caddy can act as the ingress: the entry point for all cluster traffic, routing to various services:

{
    email admin@example.com
}
 
api.example.com {
    reverse_proxy api-service:3000
}
 
admin.example.com {
    basicauth * {
        admin $2y$10$hash
    }
    reverse_proxy admin-service:8080
}
 
static.example.com {
    root * /srv
    file_server
}

#TLS Termination

#Certificates and cert-manager

#Caddy vs cert-manager

• Caddy manages its own certificates via ACME — a Caddyfile ConfigMap is enough.
• cert-manager is the standard Kubernetes approach for cluster-wide certificates.

#Shared Storage

#Service Discovery

#K8s Service DNS

A Caddyfile in the cluster uses Service names — Kubernetes DNS translates them:

app.example.com {
    reverse_proxy app-service.default.svc.cluster.local:3000
}

#Headless Services

#Helm Chart

#Using an Existing Chart

• Community charts like caddy-ingress-controller provide a ready-to-use ingress setup.
• A chart bundles the Deployment, Service, ConfigMap, and PVC in one package.

#Creating Your Own Chart

helm upgrade --install caddy . applies a chart to the cluster. helm upgrade supports rollback if a new configuration causes problems — a good operational practice.

#Conclusion

Episode 28 covered Kubernetes: Deployments and Services for Caddy, the Caddyfile in a ConfigMap with a PVC for certificates, Caddy's role as an ingress with TLS termination, cert-manager integration, service discovery via K8s DNS, and using and creating Helm charts.

Key takeaways:

• The Caddyfile is stored in a ConfigMap and mounted into the pod.
• A PVC with ReadWriteMany mode shares certificates across pods.
• Caddy can be both the ingress and the TLS manager.
• Service names become hostnames in the Caddyfile.
• Headless services enable granular load balancing.
• Helm charts package the deployment for upgrades and rollbacks.

In the next episode, episode 29, we'll cover Caddy plugins & modules — the module system, popular plugins like caddy-dns and caddy-rate-limit, creating custom builds with xcaddy, and the basics of plugin development in Go.