Kubernetes n个独立标识Pod的部署路由与故障隔离需求问询

Got it, let's break down how to meet each of your requirements step by step using standard Kubernetes tools:

1. 实现独立域名路由到每个Deployment #

To route traffic to each Deployment via unique domains (like http://building-1-building), you’ll use an Ingress Controller (we’ll use NGINX Ingress as the most common example) paired with dedicated Services for each Deployment.

Step 1: Create a unique Service for each Deployment #

Each Deployment needs its own Service to expose it internally. Here’s an example for building-2-deployment:

apiVersion: v1
kind: Service
metadata:
  name: building-2-service
spec:
  selector:
    app: building-2 # Matches the unique label on this Deployment's Pods
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Repeat this for every building-n-deployment, updating the name and selector to match each Deployment’s unique label.

Step 2: Configure Ingress for domain routing #

Create an Ingress resource that maps each domain to its corresponding Service:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: buildings-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    # Add SSL or other custom annotations here if needed
spec:
  rules:
    - host: building-1-building.your-domain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: building-1-service
                port:
                  number: 80
    - host: building-2-building.your-domain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: building-2-service
                port:
                  number: 80
    # Extend this list for building-3 through building-n

Once applied, each domain will route directly to its associated Deployment, ensuring fully independent traffic flow.

2. 保障Deployment故障时的独立性 #

Kubernetes handles this natively—you just need to ensure each Deployment is a fully isolated resource:

• Use unique labels for each Deployment: Every Deployment’s Pod template should have a unique label (like app: building-1, app: building-2), and the Deployment’s selector should only match that label.
• Separate ReplicaSets: Each Deployment manages its own ReplicaSet. If a Pod in building-2-deployment fails, only that ReplicaSet will trigger a restart/rebuild of the failed Pod. Other Deployments’ Pods remain completely unaffected.

Example Deployment YAML for reference:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: building-2-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: building-2
  template:
    metadata:
      labels:
        app: building-2
    spec:
      containers:
        - name: building-container
          image: your-app-image:latest
          ports:
            - containerPort: 80
          # Add health checks to detect failures faster
          livenessProbe:
            httpGet:
              path: /health
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5

With this setup, failures in one Deployment’s Pods won’t impact any others.

3. 销毁替换需求（基于常见场景补充） #

Since your full requirement was cut off, here are two common approaches for safely replacing a Deployment or its Pods:

• Rolling update for image/config changes: If you need to update the app in building-2-deployment, just edit the Deployment’s image (or apply a new YAML with updated specs). Kubernetes will automatically roll out new Pods and terminate old ones without downtime (if you have multiple replicas):

  kubectl set image deployment/building-2-deployment building-container=your-new-image:v2
  

• Restart or rebuild the entire Deployment: To instantly restart all Pods in building-2-deployment (e.g., for config changes that don’t trigger a rollout):

  kubectl rollout restart deployment/building-2-deployment
  

  To completely destroy and recreate the Deployment:

  kubectl delete deployment building-2-deployment
  kubectl apply -f building-2-deployment.yaml
  

Both operations only affect the target Deployment—others remain running as normal.

内容的提问来源于stack exchange，提问作者grabbag