Deployment Strategies Using Kubernetes in .NET Microservices: Product and Order Services

Deploying .NET microservices using Kubernetes provides a scalable, resilient, and manageable infrastructure. Kubernetes offers various deployment strategies to ensure that updates are rolled out smoothly, minimizing downtime and risks. In this blog, we will explore different Kubernetes deployment strategies and implement them for two .NET microservices: Product and Order services.

Embark on a journey of continuous learning and exploration with DotNet-FullStack-Dev. Uncover more by visiting our https://dotnet-fullstack-dev.blogspot.com reach out for further information.

Kubernetes Deployment Strategies

Kubernetes supports several deployment strategies, including:

• Recreate
• Rolling Update
• Blue-Green Deployment
• Canary Deployment
• A/B Testing

We will discuss each strategy and provide examples using the Product and Order services.

Setting Up the Environment

Before diving into the deployment strategies, ensure you have the following setup:

• Kubernetes cluster (e.g., Minikube, AKS, EKS, GKE)
• Docker installed
• kubectl installed
• .NET Core SDK installed
• Docker images for Product and Order services

Example .NET Microservices

For simplicity, let’s assume we have two .NET Core Web API projects: ProductService and OrderService. Each service has a Dockerfile for containerization.

ProductService Dockerfile

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["ProductService/ProductService.csproj", "ProductService/"]
RUN dotnet restore "ProductService/ProductService.csproj"
COPY . .
WORKDIR "/src/ProductService"
RUN dotnet build "ProductService.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "ProductService.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "ProductService.dll"]

OrderService Dockerfile

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["OrderService/OrderService.csproj", "OrderService/"]
RUN dotnet restore "OrderService/OrderService.csproj"
COPY . .
WORKDIR "/src/OrderService"
RUN dotnet build "OrderService.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "OrderService.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "OrderService.dll"]

1. Recreate Deployment Strategy

The recreate strategy terminates all running instances of the previous version and then starts the new version. This can cause downtime.

Deployment YAML for ProductService

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: product-service
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: product-service
    spec:
      containers:
      - name: product-service
        image: your-docker-repo/product-service:latest
        ports:
        - containerPort: 80

OrderService Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-service
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: your-docker-repo/order-service:latest
        ports:
        - containerPort: 80

2. Rolling Update Deployment Strategy

The rolling update strategy updates instances of the application gradually, ensuring that some instances are always available.

Deployment YAML for ProductService

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: product-service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: product-service
    spec:
      containers:
      - name: product-service
        image: your-docker-repo/product-service:latest
        ports:
        - containerPort: 80

OrderService Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: order-service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: your-docker-repo/order-service:latest
        ports:
        - containerPort: 80

3. Blue-Green Deployment Strategy

Blue-green deployment involves running two identical environments. The new version (green) is deployed alongside the old version (blue), and traffic is switched from blue to green once the green environment is ready.

This requires additional setup, such as an ingress controller to manage traffic switching.

Example Ingress for Blue-Green Deployment

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: product-service-ingress
spec:
  rules:
  - host: product-service.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: product-service-green
            port:
              number: 80

4. Canary Deployment Strategy

Canary deployment gradually routes a small percentage of traffic to the new version while keeping most traffic on the old version. This allows testing the new version with minimal risk.

Example Service for Canary Deployment

apiVersion: v1
kind: Service
metadata:
  name: product-service
spec:
  selector:
    app: product-service
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

ProductService Deployment YAML for Canary

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-service-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: product-service
      version: canary
  template:
    metadata:
      labels:
        app: product-service
        version: canary
    spec:
      containers:
      - name: product-service
        image: your-docker-repo/product-service:canary
        ports:
        - containerPort: 80

5. A/B Testing

A/B testing is similar to canary but involves running two or more versions simultaneously, comparing their performance and user acceptance. This requires sophisticated routing rules to distribute traffic based on user profiles or other criteria.

Conclusion

Deploying .NET microservices using Kubernetes provides flexibility and reliability. Each deployment strategy has its own advantages and use cases. By understanding and implementing these strategies, you can ensure smooth updates and maintain high availability for your services. With Kubernetes, you can automate and manage your deployment process effectively, making your microservices architecture robust and scalable.

These strategies, when applied to the Product and Order services, demonstrate how Kubernetes can handle different deployment scenarios, ensuring minimal downtime and a smooth user experience.