为何Ingress的servicePort可指定Service的port与targetPort？

Hey there, let's break down your questions step by step—this is a super common point of confusion when getting started with Kubernetes networking, so you're not alone!

First: Why both servicePort: 80 and servicePort: 8080 worked in your Ingress? #

Wait, let's clarify the expected behavior first. Normally, the servicePort field in an Ingress should reference the port value defined in your Service (in your case, that's 80). But if you found that specifying 8080 also worked, here's why that might be happening:

• Some Ingress controllers (like the ingress-nginx you're using) have a fallback behavior: if the specified servicePort doesn't match any of the Service's port entries, they might try to match against the targetPort instead. This is a convenience feature, but it's not the standard Kubernetes behavior.
• Double-check your Service definition—if you accidentally had an extra port entry with port: 8080 (even if you didn't include it in your snippet), that would also explain it. But assuming your Service is exactly as you shared, it's likely the controller's fallback logic at play.

That said, the best practice is to always reference the Service's port value (or even better, use a named port for clarity) in your Ingress, not the targetPort. Named ports make your config more readable and resilient if you ever change port numbers later. For example:

# Service spec with named port
ports:
- name: http
  port: 80
  targetPort: 8080

# Ingress spec using the named port
backend:
  serviceName: app
  servicePort: http

Second: Why does a Service expose both port and targetPort instead of just one? #

This separation is all about flexibility and decoupling—let's break down the purpose of each:

• port: This is the "front door" of the Service within the Kubernetes cluster. It's the port that other services, pods, or tools inside the cluster use to send traffic to this Service. Think of it as the Service's internal "public" port.
• targetPort: This is the port that your backend application pods are actually listening on. Your app might be configured to run on 8080 (like many Java apps, Node.js dev servers, etc.), but you want the Service to present a standard port (like 80) to the rest of the cluster.

Here are the key benefits of separating them:

• Decouple service exposure from app configuration: If you later change your app to listen on a different port (say, 9090), you only need to update the targetPort in the Service—you don't have to change every other service that connects to this one (since they still use the Service's port: 80).
• Standardize port usage across your cluster: You can have multiple Services all exposing port 80 to the cluster, even if their backend apps run on different ports (8080, 3000, etc.). This makes it easier for developers and tools to remember how to connect to services.
• Support multiple ports per Service: If your app exposes multiple endpoints (e.g., a HTTP API on 8080 and a metrics endpoint on 9090), you can define multiple port entries in the Service, each with their own port (cluster-facing) and targetPort (pod-facing) values.

Let's use your example to make it concrete:

• Your Service listens on port 80 inside the cluster. Any pod in the cluster can send traffic to app:80 to reach your app.
• The Service then forwards that traffic to port 8080 on your backend pods, where your app is actually running.

This separation keeps your architecture flexible and makes it easier to manage changes without breaking dependencies.

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