Deployment Strategies Repo

This repository demonstrates multiple Kubernetes deployment strategies using Kustomize overlays and Argo Rollouts, with CI/CD examples and basic monitoring/analysis hooks. It includes a sample Node.js app (v1 and v2) and environment-specific overlays for dev, staging, and prod.

Table of Contents

• Overview
• Repository Structure
• Prerequisites
• Application Overview
• Deployment Strategies
  • Big-Bang (Recreate)
  • Rolling Update
  • Blue-Green
  • Canary
• Environments and Overlays
• How to Render and Deploy
• CI/CD Workflows
• Monitoring and Automated Analysis
• Rollback Procedures
• Local Development & Testing
• Troubleshooting

Overview

This repo is intended for learning and reference. It shows how to model different deployment strategies using:

• Kustomize bases and overlays
• Strategy-specific manifests (Argo Rollouts for canary/blue-green; native Deployment for rolling/recreate)
• Environment overlays to tune replica counts, images, and behavior
• Simple Makefile commands to build and deploy
• GitHub Actions examples for CI and CD

Repository Structure

Key paths:

• app/ — Node.js demo application (v1 and v2 endpoints)
• k8s/base — Common configuration (ConfigMap, Secret)
• k8s/strategies — Strategy manifests:
  • big-bang.yaml — Recreate strategy (aka Big-Bang)
  • rolling.yaml — Rolling update strategy
  • blue-green.yaml — Argo Rollouts Blue-Green
  • canary.yaml — Argo Rollouts Canary
• k8s/overlays
  • dev/ — Uses Big-Bang + dev patch
  • staging/ — Uses Canary + staging patch
  • prod/ — Uses Blue-Green + prod patch
• k8s/kustomization.yml — Aggregates base, overlays, strategies (for discovery)
• kustomization.yaml — Root kustomization to render from project root
• Makefile — Convenience targets for rendering and deploying overlays
• .github/workflows — CI and CD examples
• monitoring/ — Prometheus and analysis example configs
• scripts/ — Example deploy/rollback shell scripts

Prerequisites

• kubectl (connected to the right cluster/context)
• kustomize (v4+)
• Docker (to build images if needed)
• Node.js 18+ and npm (for app and tests)
• For canary/blue-green: Argo Rollouts CRD installed in the cluster
  • See: https://argo-rollouts.readthedocs.io/
• Optional: Prometheus for automated analysis hooks

Application Overview

The demo Node.js app exposes simple routes and has two versions:

• app/src/app-v1.js
• app/src/app-v2.js

Tests live in app/tests/test.js. Dockerfile builds the app. CI can build and push images tagged with commit SHA.

Deployment Strategies

Below are concise descriptions, when to use them, traffic flow, and where they are defined in this repo.

1) Big-Bang (Recreate)

• What: All old Pods are terminated, then new Pods are created (downtime likely).
• Use when: Non-critical systems, stateful migrations requiring exclusive access, or simplest approach in dev.
• Implementation here:
  • Manifest: k8s/strategies/big-bang.yaml (apps/v1 Deployment with strategy: Recreate)
  • Dev overlay patch: k8s/overlays/dev/big-bang-patch.yaml (sets replicas, image and env)
• Traffic: Single Service targets the new Pods once they are up.
• Pros: Simple, predictable; Cons: Downtime during switch.

2) Rolling Update

• What: Gradually replace old Pods with new Pods.
• Use when: Default strategy for many stateless apps; minimal extra infra.
• Implementation here:
  • Manifest: k8s/strategies/rolling.yaml (standard Deployment rollingUpdate) [present in repo]
• Traffic: Single Service keeps pointing at the Deployment selector; traffic shifts as Pods roll.
• Pros: Low overhead; Cons: Harder to instantly rollback traffic; mixed versions during rollout.

3) Blue-Green (via Argo Rollouts)

• What: Maintain two environments: active (blue) and preview (green). Switch traffic at once when validated.
• Use when: You need quick cutover with the ability to validate new version before promotion.
• Implementation here:
  • Rollout: k8s/strategies/blue-green.yaml
  • Services: app-bluegreen-svc (active), app-bluegreen-preview-svc (preview)
  • Prod patch: k8s/overlays/prod/blue-green-patch.yaml (replicas, image, env)
• Traffic: Clients hit activeService. New version runs behind previewService until promotion.
• Pros: Near-zero downtime, easy rollback by switching back; Cons: Requires extra capacity.

4) Canary (via Argo Rollouts)

• What: Gradually shift a percentage of traffic to the new version, observe metrics, then promote or rollback.
• Use when: You want to de-risk production changes with progressive exposure and metric-based decisions.
• Implementation here:
  • Rollout: k8s/strategies/canary.yaml (weights and pauses)
  • Staging patch: k8s/overlays/staging/canary-patch.yaml (different weights/pauses and image v2)
  • Services: app-canary-svc (stable), app-canary-canary-svc (canary)
• Traffic: Weighted between stableService and canaryService according to steps.
• Pros: Safer validation in live or staging; Cons: Requires traffic splitting and metric analysis.

Environments and Overlays

• dev: Big-Bang strategy; minimal replicas; image tag v1 by default.
• staging: Canary strategy with stepped rollout to validate v2.
• prod: Blue-Green strategy for controlled promotion of v2 with more replicas.

Overlay files:

• k8s/overlays/dev/kustomization.yaml (+ big-bang-patch.yaml)
• k8s/overlays/staging/kustomization.yaml (+ canary-patch.yaml)
• k8s/overlays/prod/kustomization.yaml (+ blue-green-patch.yaml)

How to Render and Deploy

Using kustomize directly:

• Render all from root:
  • kustomize build .
• Render an overlay:
  • kustomize build k8s/overlays/dev
  • kustomize build k8s/overlays/staging
  • kustomize build k8s/overlays/prod
• Apply an overlay:
  • kubectl apply -k k8s/overlays/dev
  • kubectl apply -k k8s/overlays/staging
  • kubectl apply -k k8s/overlays/prod

Using Makefile helpers:

• make render-all — Render root kustomization (aggregates k8s)
• make kustomize-dev|staging|prod — Render overlay to stdout
• make deploy-dev|staging|prod — Apply overlay to current kube-context

Note: For canary/blue-green, ensure Argo Rollouts CRD/controller is installed before applying manifests.

CI/CD Workflows

• .github/workflows/ci-build-test.yml — Example CI pipeline to build and test Node app.
• .github/workflows/cd-deploy.yml — Example CD pipeline:
  • Builds and pushes Docker image tag your-repo/app:${GITHUB_SHA}
  • Deploys manifests (example targets canary.yaml)
  • Uses environment protection rules for main vs branches

Adjust image registry/repo and permissions as needed.

Monitoring and Automated Analysis

• monitoring/ contains Prometheus config samples and an analysis.yaml example pattern.
• For canary, Argo Rollouts can integrate metric analysis during pauses to auto-promote or rollback.
• You can extend analysis templates to query Prometheus, error rates, latency, etc.

Rollback Procedures

• Scripts: scripts/rollback.sh — an example placeholder.
• Argo Rollouts:
  • Blue-Green: revert activeService to previous ReplicaSet or click Rollback in UI/CLI.
  • Canary: set weight back to 0 or abort the rollout to revert to stable.
• kubectl:
  • For Deployments (big-bang/rolling), use: kubectl rollout undo deployment/

Local Development & Testing

• Run tests: make test (or cd app && npm ci && npm test)
• Build Docker image locally: docker build -t your-repo/app:dev ./app
• Run kustomize locally to inspect rendered YAML before applying.

Troubleshooting

• CRDs not found: Install Argo Rollouts before applying canary/blue-green.
• Image pull errors: Ensure image repository/tag exists and cluster can pull (secrets).
• RBAC/permissions: Verify your kube-context has rights to create Rollouts and Services.
• Namespace mismatches: Overlays default to namespace: default; adjust as needed in overlays.