gcp-gke-deployment-strategies

What this skill does

# GKE Deployment Strategies

## Purpose

Deploy applications to GKE with zero-downtime updates using rolling deployments and health checks. This skill covers deployment configuration, monitoring rollout progress, rollback procedures, and Spring Boot health probe integration.

## When to Use

Use this skill when you need to:
- Deploy a new version of an application to GKE
- Configure rolling update strategies for zero-downtime deployments
- Set up liveness and readiness probes for Spring Boot apps
- Monitor rollout progress and verify deployment health
- Roll back failed deployments
- Implement blue-green deployment patterns
- Debug deployment issues

Trigger phrases: "deploy to GKE", "rolling update", "rollback deployment", "configure health probes", "zero-downtime deployment"

## Table of Contents

- [Purpose](#purpose)
- [When to Use](#when-to-use)
- [Quick Start](#quick-start)
- [Instructions](#instructions)
  - [Step 1: Configure Rolling Update Strategy](#step-1-configure-rolling-update-strategy)
  - [Step 2: Configure Spring Boot Health Probes](#step-2-configure-spring-boot-health-probes)
  - [Step 3: Deploy Application](#step-3-deploy-application)
  - [Step 4: Monitor Rollout Progress](#step-4-monitor-rollout-progress)
  - [Step 5: Verify Health Checks Passing](#step-5-verify-health-checks-passing)
  - [Step 6: View Rollout History](#step-6-view-rollout-history)
  - [Step 7: Rollback If Needed](#step-7-rollback-if-needed)
- [Examples](#examples)
- [Requirements](#requirements)
- [See Also](#see-also)

## Quick Start

Standard zero-downtime rolling update:

```bash
# 1. Configure rolling update strategy
kubectl apply -f deployment.yaml  # With maxSurge: 50%, maxUnavailable: 0%

# 2. Update image
kubectl set image deployment/supplier-charges-hub \
  supplier-charges-hub-container=new-image:v2.0.0 \
  -n wtr-supplier-charges

# 3. Monitor rollout
kubectl rollout status deployment/supplier-charges-hub \
  -n wtr-supplier-charges

# 4. Verify (or rollback if needed)
kubectl rollout undo deployment/supplier-charges-hub \
  -n wtr-supplier-charges
```

## Instructions

### Step 1: Configure Rolling Update Strategy

Set up zero-downtime deployments with proper surge and unavailability settings:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: supplier-charges-hub
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 50%          # Can create 1 extra pod (2 * 50% = 1)
      maxUnavailable: 0%     # Zero downtime - no pods removed until new ones ready
  minReadySeconds: 10        # Wait 10s after pod is ready before proceeding
  progressDeadlineSeconds: 300  # Fail rollout if not complete in 5 min
  revisionHistoryLimit: 3    # Keep last 3 revisions for rollback
  selector:
    matchLabels:
      app: supplier-charges-hub
  template:
    metadata:
      labels:
        app: supplier-charges-hub
    spec:
      containers:
      - name: supplier-charges-hub-container
        image: europe-west2-docker.pkg.dev/.../supplier-charges-hub:latest
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 15
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 15
          failureThreshold: 3
```

**Strategy Explanation:**
- `maxSurge: 50%` - Allows 1 extra pod during rollout (temporary spike in resources)
- `maxUnavailable: 0%` - No pods removed until replacement is ready (zero downtime)
- `minReadySeconds: 10` - Prevents premature progression if pod is flaky
- `progressDeadlineSeconds: 300` - Detects stuck rollouts after 5 minutes

### Step 2: Configure Spring Boot Health Probes

Enable Spring Boot Actuator health endpoints that Kubernetes will check:

```yaml
# application.yml
management:
  endpoint:
    health:
      probes:
        enabled: true
      show-details: always
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  health:
    livenessState:
      enabled: true
    readinessState:
      enabled: true
```

**Health Endpoint Distinctions:**

| Probe | Path | Purpose | Failure Action |
|-------|------|---------|----------------|
| **Liveness** | `/actuator/health/liveness` | Is the app broken? | Restart pod |
| **Readiness** | `/actuator/health/readiness` | Can the app serve requests? | Stop traffic |
| **Startup** | `/actuator/health/liveness` | Slow startup complete? | Wait before liveness checks |

### Step 3: Deploy Application

Apply your deployment manifest:

```bash
kubectl apply -f deployment.yaml -n wtr-supplier-charges
```

Kubernetes will immediately start the rollout with your configured strategy.

### Step 4: Monitor Rollout Progress

Track the deployment update in real-time:

```bash
# Watch rollout status (blocks until complete)
kubectl rollout status deployment/supplier-charges-hub \
  -n wtr-supplier-charges \
  --timeout=5m

# Or check status without waiting
kubectl get deployment supplier-charges-hub \
  -n wtr-supplier-charges \
  -o wide
```

**Expected Output During Rollout:**
```
NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
supplier-charges-hub   2/2     1            2           5m
  # Shows: 1 new pod being created, 2 old pods still serving traffic
```

### Step 5: Verify Health Checks Passing

Check that pods are actually ready:

```bash
# View detailed pod status
kubectl get pods -n wtr-supplier-charges -o wide

# Check health probe status
kubectl describe pod <pod-name> -n wtr-supplier-charges | grep -A 5 "Readiness"

# Test health endpoint manually
kubectl exec deployment/supplier-charges-hub -n wtr-supplier-charges -- \
  curl -s localhost:8080/actuator/health/readiness | jq .
```

### Step 6: View Rollout History

Track previous deployments for rollback capability:

```bash
# List all revisions
kubectl rollout history deployment/supplier-charges-hub \
  -n wtr-supplier-charges

# Details of specific revision
kubectl rollout history deployment/supplier-charges-hub \
  -n wtr-supplier-charges \
  --revision=1
```

### Step 7: Rollback If Needed

If deployment fails or has issues, quickly rollback:

```bash
# Rollback to previous version
kubectl rollout undo deployment/supplier-charges-hub \
  -n wtr-supplier-charges

# Rollback to specific revision
kubectl rollout undo deployment/supplier-charges-hub \
  -n wtr-supplier-charges \
  --to-revision=2

# Monitor rollback status
kubectl rollout status deployment/supplier-charges-hub \
  -n wtr-supplier-charges
```

## Examples

### Example 1: Complete Deployment with Rolling Update

```yaml
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: supplier-charges-hub
  namespace: wtr-supplier-charges
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 0%
  minReadySeconds: 10
  progressDeadlineSeconds: 300
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: supplier-charges-hub
  template:
    metadata:
      labels:
        app: supplier-charges-hub
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "/actuator/prometheus"
    spec:
      serviceAccountName: app-runtime
      containers:
      - name: supplier-charges-hub-container
        image: europe-west2-docker.pkg.dev/ecp-artifact-registry/wtr-supplier-charges-container-images/supplier-charges-hub:v1.2.3
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        env:
        - name: SPRING_PROFILES_ACTIVE
          value: "labs"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: http
            scheme: HTTP
          initialDelaySeconds: 20
          periodSeconds: 15
          ti