多端口.NET Core API项目Docker化与K8s Ingress部署方案咨询

Hey there! Let's break down your options for containerizing and deploying your 5 .NET Core API projects on Kubernetes with Ingress—there's a clear winner here, but let's walk through why.

First, let's talk about the "one image to rule them all" approach, where you package all 5 APIs into a single Docker image and run them all in a single Pod. While this might seem simpler at first glance, it's a bad fit for Kubernetes and will cause headaches long-term:

• Wasted resources: You can't scale individual APIs independently. If one API gets slammed with traffic, you have to scale the entire Pod (which includes all 5 APIs), wasting resources on the low-traffic ones.
• Deployment risk: Changing even a single line in one API means rebuilding the entire image and restarting all 5 services. A bug in one API could take down your whole stack, and rollbacks would affect everything too.
• Troubleshooting hell: Logs from all 5 APIs will be mixed together in a single Pod, making it impossible to quickly track down which service is causing an issue. Monitoring metrics will also be blurred across services.
• Against Kubernetes best practices: K8s is designed around single-responsibility Pods—one process per Pod. This lets the platform handle scheduling, self-healing, and scaling efficiently.

This is the far superior approach, aligned with Kubernetes and modern microservice best practices. Here's why it works so well:

• Granular scaling: Scale only the APIs that need it. If API #3 has 10x the traffic of others, you can spin up extra Pods just for that service without wasting resources on the rest.
• Isolated deployments: Update, test, and deploy one API at a time. A bad deploy only affects that single service, not your entire solution. Rollbacks are fast and targeted too.
• Clear observability: Each API has its own logs, metrics, and health checks. When something goes wrong, you can instantly pinpoint which service is the culprit.
• Full Kubernetes leverage: Each API gets its own Deployment and Service, letting K8s handle scheduling, self-healing, and load balancing per service.

Step-by-Step Implementation Example #

Let's outline how to set this up:

1. Build Individual Docker Images #

Create a Dockerfile in each API project's root directory (this is a standard .NET Core example—adjust for your version):

# API Project 1 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 ["APIProject1/APIProject1.csproj", "APIProject1/"]
RUN dotnet restore "APIProject1/APIProject1.csproj"
COPY . .
WORKDIR "/src/APIProject1"
RUN dotnet build "APIProject1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "APIProject1.csproj" -c Release -o /app/publish /p:UseAppHost=false

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

Repeat this for each API, changing the project names and entrypoint DLLs. Build and tag each image separately (e.g., my-api-1:v1, my-api-2:v1).

2. Kubernetes Resources #

Deployments

Create a Deployment for each API (example for API 1):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-1-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api-1
  template:
    metadata:
      labels:
        app: api-1
    spec:
      containers:
      - name: api-1
        image: my-api-1:v1
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 5

Duplicate this for APIs 2-5, updating the name, labels, and image fields.

Services

Create a ClusterIP Service for each API to expose it internally:

apiVersion: v1
kind: Service
metadata:
  name: api-1-service
spec:
  selector:
    app: api-1
  ports:
  - port: 80
    targetPort: 80

Again, duplicate and adjust names for each API.

Ingress

Use an Ingress resource to route external traffic to each API. Here's an example with NGINX Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: your-api-domain.com # Use your cluster's domain or IP
    http:
      paths:
      - path: /api1(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-1-service
            port:
              number: 80
      - path: /api2(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-2-service
            port:
              number: 80
      # Add paths for api3, api4, api5 following the same pattern

Now users can access your-api-domain.com/api1/api/values for the first API, your-api-domain.com/api2/api/values for the second, and so on.

Go with individual images and deployments per API. It's more work upfront, but it pays off massively in maintainability, scalability, and reliability—exactly what Kubernetes is built for.

内容的提问来源于stack exchange，提问作者Abraham Dhanyaraju Arumbaka