Zero‑Downtime Blue/Green Deployments for .NET 8 Microservices on Kubernetes with Argo Rollouts

Why Zero‑Downtime Matters for .NET 8 Microservices

What happens when a live .NET 8 microservice crashes during a release? In a production environment that targets 99.9% availability, even a five‑minute outage can cost thousands of dollars and erode user trust. Modern SaaS platforms therefore demand deployment strategies that keep traffic flowing while new code is validated. Blue/green deployment, combined with Argo Rollouts, gives you deterministic traffic switches, instant rollbacks, and the ability to meet zero‑downtime Service Level Objectives without manual choreography.

Preparing the .NET 8 Service for Kubernetes

The first step is to containerise the .NET 8 API in a way that respects health‑checks and graceful shutdown. Use the official ASP.NET runtime image, expose only the required port, and set the entry point to the compiled DLL. A minimal Dockerfile looks like this:

FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
WORKDIR /src
COPY [\"MyService/MyService.csproj\", \"MyService/\"]
RUN dotnet restore \"MyService/MyService.csproj\"
COPY . .
WORKDIR \"/src/MyService\"
RUN dotnet publish -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT [\"dotnet\",\"MyService.dll\"]

Notice the use of the dotnet publish command with the -c Release flag; this produces a trimmed binary that starts up in under 200 ms on Alpine, an important metric for blue/green swaps where health probes must succeed quickly.

Installing Argo Rollouts on a Cluster

Argo Rollouts extends the native Kubernetes Deployment controller with advanced strategies such as blue/green, canary, and automated analysis. Install it once per cluster with a single kubectl command:

kubectl create -f https://github.com/argoproj/argo-rollouts/releases/download/v1.5.0/install.yaml

The installation creates the rollouts.k8s.io API group and a controller pod that watches Rollout resources. Verify the installation by running kubectl get rollout; you should see an empty list but no errors.

Defining a Blue/Green Rollout for a .NET 8 Service

With the controller in place, describe the rollout in a YAML manifest. The blueGreen block tells Argo which Services represent the active (production) and preview (new version) environments. The example below assumes you already have two Services named myservice-active and myservice-preview:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myservice-rollout
spec:
  replicas: 3
  strategy:
    blueGreen:
      activeService: myservice-active
      previewService: myservice-preview
      autoPromotionEnabled: false
  selector:
    matchLabels:
      app: myservice
  template:
    metadata:
      labels:
        app: myservice
    spec:
      containers:
      - name: myservice
        image: myregistry.azurecr.io/myservice:{{.Values.imageTag}}
        ports:
        - containerPort: 80

Set autoPromotionEnabled to false so you can manually verify the preview pods before traffic is switched. The imageTag placeholder is typically replaced by a CI pipeline that injects the build number or Git SHA.

Traffic Switching with a Service Mesh or Ingress

Argo Rollouts updates the myservice-preview Service to point at the newly created pods. When you are satisfied with health‑probe results, execute:

kubectl argo rollouts promote myservice-rollout

The command swaps the label selector of myservice-active to the preview pods, effectively moving 100 % of traffic in a single API call. If you use an Istio VirtualService, you can achieve the same effect with a weighted routing rule that gradually shifts traffic from the blue to the green version, providing an additional safety net.

Monitoring and Rollback Strategies

During the preview phase, monitor both Kubernetes readiness probes and application‑level metrics such as request latency, error rate, and CPU usage. Argo Rollouts can be configured with metric analysis (using Prometheus or Datadog) to automatically abort a rollout if a threshold is crossed. In practice, a simple rule like “error rate > 0.5 % for five consecutive minutes” triggers an immediate rollback to the previous stable replica set.

Rollback is as easy as running:

kubectl argo rollouts abort myservice-rollout

This restores the original Service selector, terminates the preview pods, and leaves the system in the exact state it was before the deployment began—hence the term zero‑downtime.

Conclusion

Blue/green deployments with Argo Rollouts give .NET 8 teams a reproducible, auditable path to release new microservice versions without interrupting users. By containerising the application correctly, installing the Rollouts controller, defining a clear manifest, and coupling traffic switches with robust health checks, you can meet stringent uptime targets while still moving at the speed of modern CI/CD pipelines.

Sources

Microsoft Docs – .NET 8 Docker images; Kubernetes Documentation – Services and Deployments; Argo Project – Official Rollouts guide.

Author: Mahmut Sarıkaya — sarikayadev.com