如何在Kubernetes中通过Nginx动态路由实现主节点到工作节点的API通信

Got it, let's walk through how to implement this dynamic routing setup in Kubernetes—your Nginx regex idea is exactly the right starting point, we just need to hook it into K8s' service discovery and deployment model properly. Here's a step-by-step breakdown:

First, you need to ensure each worker node's API is deployed as a Pod tied to that specific node, and has a Kubernetes Service that follows the naming pattern worker-{node-name}-api-service (since your Nginx config uses worker-$1-api-service).

1.1 Deploy API Pods Tied to Specific Worker Nodes #

Create a Deployment for each worker node's API, using nodeSelector to force the Pod onto the correct node. Replace newyork with your actual worker node hostname, and adjust the image/ports to match your API:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-api-newyork
  namespace: operations-portal
spec:
  replicas: 1
  selector:
    matchLabels:
      app: node-api
      node-name: newyork
  template:
    metadata:
      labels:
        app: node-api
        node-name: newyork
    spec:
      nodeSelector:
        kubernetes.io/hostname: newyork  # Matches the worker node's hostname
      containers:
        - name: node-api
          image: your-node-api-image:latest
          ports:
            - containerPort: 4003

Repeat this for every worker node (chicago, tokyo, etc.), updating the name, node-name label, and nodeSelector value each time.

1.2 Create a Service for Each API #

Next, create a ClusterIP Service for each API Pod, named to match your Nginx proxy pattern. For the newyork node:

apiVersion: v1
kind: Service
metadata:
  name: worker-newyork-api-service
  namespace: operations-portal
spec:
  selector:
    app: node-api
    node-name: newyork
  ports:
    - protocol: TCP
      port: 4003
      targetPort: 4003

This Service will route traffic to the API Pod on the newyork node. Again, repeat this for all worker nodes, updating the Service name and selector to match each node.

We'll use a Kubernetes ConfigMap to manage the Nginx routing config, making it easy to update without rebuilding images.

2.1 Create the Nginx ConfigMap #

Save your proxy rule into a ConfigMap. We'll add a few optional but useful proxy settings for reliability:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-nodeapi-config
  namespace: operations-portal
data:
  nodeapi.conf: |
    location ~ ^/nodeapi/(.*)$ {
        proxy_set_header Host $host:$server_port;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://worker-$1-api-service.operations-portal.svc.cluster.local:4003;
        # Optional: Add timeout settings to avoid hanging requests
        proxy_connect_timeout 30s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
    }

Now, deploy your Nginx + Angular frontend to the master node. You'll need an image that includes your Angular static files (usually built into an Nginx base image) and mount the ConfigMap we created to add the dynamic routing rules.

3.1 Frontend Deployment YAML #

This Deployment will run on the master node (note the tolerations to bypass the default master node taint):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-angular-frontend
  namespace: operations-portal
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-angular
  template:
    metadata:
      labels:
        app: nginx-angular
    spec:
      nodeSelector:
        node-role.kubernetes.io/master: ""  # Targets the master node
      tolerations:
        - key: "node-role.kubernetes.io/master"
          operator: "Exists"
          effect: "NoSchedule"  # Allows Pod to run on tainted master node
      containers:
        - name: nginx-angular
          image: your-nginx-angular-image:latest  # Your custom image with Angular files
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-nodeapi-config
              mountPath: /etc/nginx/conf.d/nodeapi.conf
              subPath: nodeapi.conf  # Mounts only the specific config file
      volumes:
        - name: nginx-nodeapi-config
          configMap:
            name: nginx-nodeapi-config

3.2 Expose the Frontend Service #

Finally, create a Service to make your frontend accessible. Use NodePort if you're accessing it directly via the master node IP, or LoadBalancer if you have a cloud load balancer available:

apiVersion: v1
kind: Service
metadata:
  name: nginx-angular-service
  namespace: operations-portal
spec:
  type: NodePort
  selector:
    app: nginx-angular
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080  # Optional: Specify a static port (adjust as needed)

Verify everything works by sending a request to your frontend URL:

curl http://<master-node-ip>:30080/nodeapi/newyork/Uploadvideo

Check the Nginx Pod logs to confirm the request was forwarded to the correct Service, and check the API Pod logs on the newyork node to ensure it received the request.

• DNS Reliability: Ensure Kubernetes CoreDNS is running correctly—Nginx relies on K8s DNS to resolve the Service names like worker-newyork-api-service.operations-portal.svc.cluster.local.
• Naming Consistency: Double-check that your worker node hostnames, API Pod labels, and Service names all match the worker-{node-name}-api-service pattern. Any mismatch will break the routing.
• Scaling: If you ever need multiple replicas of an API on a node, just update the Deployment's replicas count—Kubernetes will load-balance traffic through the Service.

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