Zero‑Downtime Deployments for .NET 8 Microservices with Kubernetes, Argo Rollouts, and Istio

Why zero‑downtime matters for .NET 8 microservices

Imagine a user placing an order at 23:59 and the service restarts at midnight, causing the transaction to fail. In high‑traffic e‑commerce or fintech environments a single second of unavailability can translate into thousands of dollars lost. .NET 8 introduces performance improvements that make microservices attractive, but without a robust deployment strategy the gains disappear the moment a new version is rolled out. Achieving true zero‑downtime requires orchestration at three levels: container runtime, Kubernetes rollout engine, and traffic routing mesh.

Prerequisites and system requirements

Before diving into the pipeline you need a Kubernetes cluster (1.27+ recommended), Helm 3, and a namespace dedicated to the service. Argo Rollouts 1.5+ and Istio 1.20+ must be installed in the cluster. Your CI pipeline should produce a Docker image tagged with the semantic version, for example myapp:1.4.2. The .NET SDK 8.0 and the Docker engine (20.10+) are required on the build agent.

Dockerfile for a .NET 8 API

The following Dockerfile builds a minimal Linux container using the official SDK and runtime images. The multi‑stage build keeps the final image under 60 MB, which speeds up rollouts.

FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build<br/>WORKDIR /src<br/>COPY *.csproj ./<br/>RUN dotnet restore<br/>COPY . .<br/>RUN dotnet publish -c Release -o /app --no-restore<br/><br/>FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS runtime<br/>WORKDIR /app<br/>COPY --from=build /app .<br/>EXPOSE 80<br/>ENTRYPOINT ["dotnet","MyApp.dll"]

Argo Rollout manifest with canary strategy

Argo Rollouts replaces the native Deployment object and adds progressive traffic shifting. The example below defines a 30‑second pause after 10 % of pods are upgraded, then proceeds to 50 % and finally 100 %.

apiVersion: argoproj.io/v1alpha1<br/>kind: Rollout<br/>metadata:<br/>  name: myapp-rollout<br/>  namespace: production<br/>spec:<br/>  replicas: 6<br/>  strategy:<br/>    canary:<br/>      steps:<br/>      - setWeight: 10<br/>      - pause: {duration: 30s}<br/>      - setWeight: 50<br/>      - pause: {duration: 30s}<br/>      - setWeight: 100<br/>  selector:<br/>    matchLabels:<br/>      app: myapp<br/>  template:<br/>    metadata:<br/>      labels:<br/>        app: myapp<br/>    spec:<br/>      containers:<br/>      - name: myapp<br/>        image: myregistry.azurecr.io/myapp:1.4.2<br/>        ports:<br/>        - containerPort: 80

Istio VirtualService for traffic split

Istio’s VirtualService works hand‑in‑hand with Argo Rollouts. The subset definitions reference the same label used by the rollout, allowing Istio to direct a configurable percentage of requests to the new version while the rest continue to hit the stable pods.

apiVersion: networking.istio.io/v1beta1<br/>kind: DestinationRule<br/>metadata:<br/>  name: myapp-destination<br/>  namespace: production<br/>spec:<br/>  host: myapp.production.svc.cluster.local<br/>  subsets:<br/>  - name: v1<br/>    labels:<br/>      version: v1<br/>  - name: v2<br/>    labels:<br/>      version: v2<br/><br/>---<br/>apiVersion: networking.istio.io/v1beta1<br/>kind: VirtualService<br/>metadata:<br/>  name: myapp-virtualservice<br/>  namespace: production<br/>spec:<br/>  hosts:<br/>  - myapp.production.svc.cluster.local<br/>  http:<br/>  - route:<br/>    - destination:<br/>        host: myapp.production.svc.cluster.local<br/>        subset: v1<br/>      weight: 90<br/>    - destination:<br/>        host: myapp.production.svc.cluster.local<br/>        subset: v2<br/>      weight: 10

Step‑by‑step rollout workflow

1. Push the Docker image to the registry.
2. Apply the DestinationRule and VirtualService (if not already present).
3. Run kubectl apply -f rollout.yaml. Argo Rollout controller creates the new ReplicaSet, updates the Service selector, and reports progress in the kubectl argo rollouts get rollout myapp-rollout output.
4. Istio automatically respects the weight values defined by the Rollout’s setWeight steps, ensuring that only the intended fraction of traffic sees the new version.
5. If health checks fail, Argo Rollouts aborts the remaining steps and rolls back, while Istio instantly reverts traffic to 100 % on the stable subset.

Practical tips for production stability

• Keep readiness probes simple: return 200 only after the .NET app has opened its listening port and loaded critical configuration.
• Use a sidecar health check (Envoy) to surface latency spikes to the rollout controller.
• Store the rollout history in a ConfigMap; a GitOps pipeline can compare the current manifest with the last successful version and auto‑rollback if drift is detected.
• Limit the maximum number of concurrent canary pods to one per node to avoid resource contention on small clusters.

Monitoring and observability

Prometheus metrics exported by the .NET runtime (e.g., dotnet_counter) combined with Istio’s telemetry give you a real‑time view of request latency per subset. Grafana dashboards can trigger alerts when the 95th‑percentile latency of the canary exceeds the stable baseline by more than 20 % for two consecutive minutes, prompting an automatic rollback via Argo’s webhook.

Conclusion

Zero‑downtime deployments for .NET 8 microservices become achievable when Kubernetes, Argo Rollouts, and Istio are orchestrated as a single pipeline. The Dockerfile keeps images lightweight, the rollout manifest drives progressive traffic shifts, and Istio guarantees that users never see a broken endpoint. By following the step‑by‑step workflow and the monitoring checklist, teams can ship new features every sprint without sacrificing SLA commitments.

Sources

• Microsoft Docs – .NET 8 release notes
• Argo Rollouts – Official documentation
• Istio – Traffic Management guide

Author: Mahmut Sarıkaya — sarikayadev.com