K8s Deploy

Kubernetes Deployment Workflows

Comprehensive deployment strategies using kubectl-mcp-server tools, including Argo Rollouts and Flagger for progressive delivery.

When to Apply

Use this skill when:

• User mentions: "deploy", "release", "rollout", "scale", "update", "upgrade"
• Operations: creating deployments, updating images, scaling replicas
• Strategies: canary, blue-green, rolling update, recreate
• Keywords: "new version", "push to production", "traffic shifting"

Priority Rules

Quick Reference

Standard Deployments

Deploy from Manifest

kubectl_apply(manifest_yaml, namespace)

Deploy with Helm

install_helm_chart(
    name="my-app",
    chart="bitnami/nginx",
    namespace="production",
    values={"replicaCount": 3}
)

Scale Deployment

scale_deployment(name, namespace, replicas=5)

Rolling Update

set_deployment_image(name, namespace, container="app", image="myapp:v2")

rollout_status(name, namespace, resource_type="deployment")

Progressive Delivery

Argo Rollouts (Recommended)

For canary and blue-green deployments with analysis.

List Rollouts

rollouts_list_tool(namespace)

Canary Promotion

rollout_status_tool(name, namespace)

rollout_promote_tool(name, namespace)

Abort Bad Release

rollout_abort_tool(name, namespace)

Retry Failed Rollout

rollout_retry_tool(name, namespace)

See ROLLOUTS.md for detailed Argo Rollouts workflows.

Flagger Canary

For service mesh-integrated canary releases:

flagger_canaries_list_tool(namespace)
flagger_canary_get_tool(name, namespace)

Deployment Strategies

See references/STRATEGIES.md for detailed strategy comparisons.

Rollback Operations

Native Kubernetes

rollback_deployment(name, namespace, revision=0)

rollback_deployment(name, namespace, revision=2)

Helm Rollback

rollback_helm_release(name, namespace, revision=1)

Argo Rollouts Rollback

rollout_abort_tool(name, namespace)

Health Verification

After deployment, verify health:

get_pods(namespace, label_selector="app=myapp")

get_pod_metrics(name, namespace)

get_endpoints(namespace)

Multi-Cluster Deployments

Deploy to specific clusters using context:

install_helm_chart(
    name="app",
    chart="./charts/app",
    namespace="prod",
    context="production-us-east"
)

install_helm_chart(
    name="app",
    chart="./charts/app",
    namespace="prod",
    context="production-eu-west"
)

Example Manifests

See examples/ for ready-to-use deployment manifests:

• examples/canary-rollout.yaml - Argo Rollouts canary
• examples/blue-green.yaml - Blue-green deployment
• examples/hpa-deployment.yaml - Deployment with HPA

Prerequisites

• Argo Rollouts: Required for rollout_* tools

  kubectl create namespace argo-rollouts
  kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

• Flagger: Required for flagger_* tools

  kubectl apply -k github.com/fluxcd/flagger/kustomize/kubernetes

Related Skills

• k8s-gitops - GitOps deployments with Flux/ArgoCD
• k8s-autoscaling - Auto-scale deployments
• k8s-rollouts - Advanced progressive delivery
• k8s-helm - Helm chart operations

Deployment Strategies Reference

Comparison of Kubernetes deployment strategies and when to use each.

Strategy Comparison

Rolling Update (Default)

How it works: 1. New pods created incrementally 2. Old pods terminated as new become ready 3. Controlled by maxSurge and maxUnavailable

Configuration:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

Pros:

• Zero downtime
• Low resource overhead
• Built into Kubernetes

Cons:

• Both versions run simultaneously
• No easy rollback mid-update
• Session affinity issues possible

When to use:

• Standard stateless applications
• Services that tolerate version mixing

Recreate Strategy

How it works: 1. All existing pods terminated 2. New pods created after termination 3. Brief downtime during switch

Configuration:

spec:
  strategy:
    type: Recreate

Pros:

• Clean switch between versions
• No version mixing
• Lower resource cost

Cons:

• Causes downtime
• Slower rollout

When to use:

• Applications that cannot run multiple versions
• Databases or stateful applications
• Development environments

Blue-Green Deployment

How it works: 1. Deploy new version alongside old (green environment) 2. Run tests against green environment 3. Switch traffic instantly via service selector 4. Keep blue available for instant rollback

With Argo Rollouts:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    blueGreen:
      activeService: myapp-active
      previewService: myapp-preview
      autoPromotionEnabled: false

Pros:

• Instant rollback
• Zero downtime
• Full testing before switch

Cons:

• 2x resource cost
• More complex setup

When to use:

• Critical production services
• Applications requiring instant rollback
• Compliance requirements

Canary Deployment

How it works: 1. Deploy new version to small percentage 2. Gradually increase traffic 3. Monitor for errors 4. Auto-rollback on failures

With Argo Rollouts:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 30
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}

Pros:

• Lowest risk
• Real user testing
• Automatic rollback

Cons:

• Slower rollout
• Complex monitoring needed
• Version mixing during rollout

When to use:

• High-traffic applications
• Risk-sensitive deployments
• A/B testing requirements

Traffic Shifting Methods

Service Selector (Basic)

apiVersion: v1
kind: Service
spec:
  selector:
    app: myapp
    version: v2  # Change to switch traffic

Istio VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

Argo Rollouts (Recommended)

Handles traffic shifting automatically based on analysis.

Decision Flow

Need instant rollback?
├── Yes → Blue-Green
└── No
    └── High-risk deployment?
        ├── Yes → Canary
        └── No
            └── Stateful app?
                ├── Yes → Recreate
                └── No → Rolling Update

MCP Server Tools by Strategy

Argo Rollouts Deep Dive

Detailed workflows for progressive delivery with Argo Rollouts.

Rollout Types

Canary Strategy

Gradually shift traffic to the new version:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 25
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}
      - setWeight: 75
      - pause: {duration: 5m}

Blue-Green Strategy

Switch all traffic at once:

strategy:
  blueGreen:
    activeService: my-app-active
    previewService: my-app-preview
    autoPromotionEnabled: false
    prePromotionAnalysis:
      templates:
      - templateName: success-rate

Analysis Templates

Success Rate Analysis

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 30s
    count: 5
    successCondition: result[0] >= 0.95
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status=~"2.*",app="{{args.app}}"}[5m])) /
          sum(rate(http_requests_total{app="{{args.app}}"}[5m]))

MCP Server Tools

# List all rollouts
rollouts_list_tool(namespace="production")

# Get rollout details and status
rollout_get_tool(name="my-app", namespace="production")
rollout_status_tool(name="my-app", namespace="production")

# Promote (advance canary)
rollout_promote_tool(name="my-app", namespace="production")

# Abort (rollback)
rollout_abort_tool(name="my-app", namespace="production")

# Retry failed rollout
rollout_retry_tool(name="my-app", namespace="production")

# Restart rollout (new ReplicaSet)
rollout_restart_tool(name="my-app", namespace="production")

# Check analysis runs
analysis_runs_list_tool(namespace="production")

Common Workflows

Safe Canary Release

1. rollout_status_tool(name, namespace)  # Check current state
2. # Update image in rollout manifest
3. apply_manifest(rollout_yaml, namespace)
4. rollout_status_tool(name, namespace)  # Watch progress
5. # If analysis fails: rollout_abort_tool(name, namespace)
6. # If manual gate: rollout_promote_tool(name, namespace)

Emergency Rollback

rollout_abort_tool(name, namespace)
# Immediately reverts to stable version

Force Full Promotion

rollout_promote_tool(name, namespace, full=True)
# Skips remaining steps

Troubleshooting

Rollout Stuck

rollout_status_tool(name, namespace)
analysis_runs_list_tool(namespace)
get_events(namespace)

Analysis Failing

analysis_runs_list_tool(namespace)
# Check Prometheus query in AnalysisTemplate
# Verify metrics are being collected