Implementing canary deployments is a powerful strategy to introduce new versions of your Go services on Kubernetes with minimal risk. This guide provides practical steps to set up and manage canary deployments effectively.

What Are Canary Deployments?

Canary deployments involve rolling out a new version of a service to a small subset of users before a full deployment. This approach helps detect issues early and ensures stability.

Prerequisites

  • A running Kubernetes cluster
  • kubectl configured to access your cluster
  • Existing Go service container images
  • Basic knowledge of Kubernetes deployments and services

Setting Up the Base Deployment

Create a standard deployment manifest for your Go service. This deployment will serve as the stable version.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-service
  template:
    metadata:
      labels:
        app: go-service
    spec:
      containers:
      - name: go-service
        image: yourregistry/go-service:v1
        ports:
        - containerPort: 8080

Creating a Service

Expose your deployment with a Kubernetes service to enable traffic routing.

apiVersion: v1
kind: Service
metadata:
  name: go-service
spec:
  selector:
    app: go-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Deploying the Canary Version

Deploy the new version as a separate deployment with a different label.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-service-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-service
      version: canary
  template:
    metadata:
      labels:
        app: go-service
        version: canary
    spec:
      containers:
      - name: go-service
        image: yourregistry/go-service:v2
        ports:
        - containerPort: 8080

Adjusting Traffic with a Canary Ingress

Use an ingress controller or service mesh to route a small percentage of traffic to the canary deployment. For example, with Istio or NGINX ingress, configure traffic splitting.

Example: NGINX Ingress with Traffic Splitting

Configure your ingress to send, for example, 10% of traffic to the canary deployment and 90% to the stable deployment.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-service-ingress
spec:
  rules:
  - host: yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: go-service
            port:
              number: 80
  # Additional configuration needed for traffic splitting depends on your ingress controller

Monitoring and Validation

Monitor the canary deployment closely using logs, metrics, and health checks. Ensure that the new version performs as expected before increasing traffic.

Progressively Increasing Traffic

Gradually shift more traffic from the stable deployment to the canary. Repeat this process until the canary version handles all traffic successfully.

Full Rollout and Cleanup

Once confident, update the stable deployment to the new version and remove the canary deployment.

kubectl delete deployment go-service-canary
kubectl set image deployment/go-service go-service=yourregistry/go-service:v2

Best Practices

  • Automate traffic shifting with CI/CD pipelines
  • Implement robust monitoring and alerting
  • Use feature flags for granular control
  • Test canary deployments in staging environments first

By following these steps, you can deploy updates safely and efficiently, minimizing downtime and user impact.