Master Kubernetes Deployment: Rolling, Blue‑Green, and Canary Strategies Explained

Application Delivery in Kubernetes

Frequent software releases increase business value but also raise the risk of failures. In cloud‑native environments each component may have its own lifecycle, so a reliable delivery strategy is required to keep services stable while iterating quickly.

Service Types in Kubernetes

ClusterIP

Exposes a virtual IP reachable only inside the cluster.

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: wordpress

NodePort

Maps a service port to a static port on each node, allowing external access.

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    nodePort: 31570
  selector:
    app: wordpress

LoadBalancer

Relies on a cloud provider’s load balancer to expose the service publicly.

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: wordpress

Ingress

Provides intelligent routing based on host or path, acting as a cluster‑wide entry point.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: wordpress-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: wordpress
          servicePort: 80

Application Delivery Boundary

In Kubernetes an application’s delivery consists of Service , Deployment/Pod and Volume resources. For example, a WordPress site includes a frontend Service with three Pods and a backend Service with one Pod, all managed by Deployments.

Deployment Strategies

Rolling Update

Kubernetes updates Pods incrementally, replacing old instances with new ones until all are updated. Example Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-demo
  template:
    metadata:
      labels:
        app: go-demo
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        ports:
        - containerPort: 8080

Apply the manifest: kubectl apply -f go-demo-v1.yaml Update the image tag to v2 and re‑apply; Pods are replaced one by one, and both versions may be observed during the transition.

Pros: Simple, low resource overhead. Cons: Slow rollout, no traffic control, risk if the new version has defects.

Blue‑Green Deployment

Deploy both v1 and v2 simultaneously and switch traffic by changing the Service selector.

# go-demo-v1.yaml (replicas: 4, version: v1)
# go-demo-v2.yaml (replicas: 4, version: v2)
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: go-demo
    version: v1   # change to v2 to switch
  type: ClusterIP

Modify the selector from version: v1 to version: v2 and re‑apply. Traffic instantly moves to the new version.

Pros: Immediate traffic switch, easy rollback. Cons: Doubles resource usage, still a 0 % → 100 % switch.

Canary (Gray) Release

Run both versions with different replica counts or weighted Ingress rules, allowing a fraction of traffic to hit the new version.

# go-demo-v1.yaml (replicas: 9, version: v1)
# go-demo-v2.yaml (replicas: 1, version: v2)
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: go-demo
  type: ClusterIP

Create an Ingress with weight annotations to control traffic distribution:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: go-demo
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
      go-demo-v1: 90, go-demo-v2: 10
spec:
  rules:
  - host: go-demo.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: go-demo-v1
          servicePort: 80
      - path: /
        backend:
          serviceName: go-demo-v2
          servicePort: 80

Adjust the weights (e.g., 50:50, then 0:100) to gradually shift traffic. This limits the impact of defects and uses fewer resources than blue‑green.

Pros: Fine‑grained traffic control, lower risk, efficient resource use. Cons: Longer rollout time.

Choosing the Right Strategy

Use rolling updates for development or test environments.

In production, choose rolling or blue‑green when the new version is well‑tested.

When risk must be minimized, adopt canary or gray releases to limit exposure.

Conclusion

Kubernetes provides flexible mechanisms—ClusterIP, NodePort, LoadBalancer, and Ingress—to expose services, and three main deployment patterns—rolling update, blue‑green, and canary—that let teams balance speed, stability, and risk according to their needs.