In this lesson, you will learn how to orchestrate your containerized .NET microservices by defining the essential Kubernetes primitives required for high-availability scaling.
When moving from a single container to a Kubernetes cluster, you need three declarative manifests to handle the lifecycle and traffic management of your ASP.NET Core application: the Deployment, the Service, and the Ingress.
The Deployment
The Deployment is your engine for scaling. Unlike a raw Pod, it manages ReplicaSets, allowing you to scale your .NET service horizontally based on CPU or memory load. Crucially, you must align the readinessProbe and livenessProbe with the health check middleware you previously implemented to ensure the cluster only routes traffic to fully initialized Kestrel instances.
apiVersion: apps/v1
kind: Deployment
metadata:
name: ordering-api
spec:
replicas: 3
selector:
matchLabels:
app: ordering
template:
metadata:
labels:
app: ordering
spec:
containers:
- name: api
image: myregistry/ordering:v1.2
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /health/ready
port: 80
The Service and Ingress
The Service provides a stable internal DNS name (e.g., ordering-svc) for other microservices to discover your API. By using type: ClusterIP, you keep your service internal and secure. To expose your service to the outside world, you use an Ingress object. The Ingress acts as the entry point, handling TLS termination and routing rules that map public URL paths to your internal Service.
When designing these for .NET, ensure your Deployment resource requests/limits are tuned. Because .NET services are often memory-intensive during JIT compilation, providing sufficient headroom prevents the Kubelet from restarting your pods during startup spikes.
By decoupling the workload (Deployment), the service discovery (Service), and the traffic routing (Ingress), you create a robust architecture that allows you to perform rolling updates without downtime, leveraging the graceful shutdown signals your .NET runtime is now prepared to handle.
Key Takeaway: A production-ready .NET microservice relies on a Deployment to scale, a Service for internal discovery, and an Ingress for external traffic, all tied together by well-defined readiness probes.