⌂ Home

Multi-Port Services

Interactive guide to named ports, service port mapping, and exposing multi-port applications clearly.

Many applications expose more than one interface: app traffic, admin endpoints, metrics, or health ports. Multi-port Services organize those interfaces cleanly.

Core Model

Understand the Concept First

Multiple app interfaces

Applications often need more than one exposed port for different responsibilities.

Named ports required

When a Service exposes multiple ports, each one needs a unique name.

Clear service mapping

Port naming makes Service-to-Pod relationships easier to reason about and debug.

Visual Architecture

Interactive Multi-Port Service Diagrams

Single-Port Service (Simple) Client Pod Port 8080 Service: my-app Port Configuration port: 8080 targetPort: 80 Port 80 Backend Pods Pod 1 container:80 Pod 2 container:80 Single-Port Service Characteristics • Simple configuration with one port exposed • Port naming is optional (but recommended) • Suitable for applications with one interface (e.g., web server only) • Traffic flows: Client → Service Port 8080 → Pod Container Port 80 Multi-Port Service Architecture HTTP Client Metrics Client Admin Client 8080 9090 8081 Service: my-app (Multi-Port) name: http port: 8080 → targetPort: 8080 name: metrics port: 9090 → targetPort: 9090 name: admin port: 8081 → targetPort: 8081 :8080 :9090 :8081 Backend Pods Pod: app-pod-1 http: 8080 metrics: 9090 admin: 8081 Multi-Port Service Benefits • Separate interfaces for different responsibilities (HTTP traffic, monitoring metrics, admin operations) • Named ports required for clarity and valid configuration • Each port name must be unique within the Service • Enables protocol separation and targeted access control via NetworkPolicies Named Port Mapping Flow Service Specification kind: Service metadata: name: my-app-service spec: selector: app: myapp ports: - name: http port: 80 targetPort: http - name: metrics port: 9090 targetPort: metrics - name: admin port: 8081 targetPort: admin Pod Specification kind: Pod spec: containers: - name: app-container image: myapp:1.0 ports: - name: http containerPort: 8080 - name: metrics containerPort: 9090 - name: admin containerPort: 8081 Named Port Resolution Service targetPort name matches Pod containerPort name → Kubernetes automatically resolves to the correct port number
Hover over components to see detailed explanations. Switch between views to understand single-port vs multi-port configurations.
Lifecycle Flow

Multi-Port Mapping Flow

1

Pod defines ports

Container ports are declared, often with names like http or metrics.

2

Service selects backend Pods

Labels and selectors identify the application Pods.

3

Service maps each port

Each service port is mapped to the correct targetPort.

4

Clients reach the right interface

Traffic on each named port reaches the intended backend function.

Port names are not cosmetic in multi-port Services; they are part of making the model understandable and valid.
YAML and Commands

Examples You Can Recognize Quickly

Multi-Port Service Example
ports:
- name: http
  port: 8080
  targetPort: 8080
- name: custom
  port: 9090
  targetPort: 9090
Useful Commands
kubectl get svc multi-port-service
kubectl describe svc multi-port-service
Decision Guide

Single-Port vs Multi-Port Service

Aspect Single-port Service Multi-port Service
Port entries One Many
Need for naming Optional in simple cases Required and important for clarity
Typical app fit Simple web or API service Apps with metrics, admin, HTTPS, or multiple interfaces
If your application exposes multiple interfaces, make those interfaces explicit in the Service instead of hiding them in assumptions.
Use It Well

Practice and Real-World Thinking

App plus metrics

Expose user traffic and Prometheus metrics on distinct ports.

Protocol separation

Use separate ports for web, HTTPS, or admin APIs.

Troubleshooting clarity

Named ports make service descriptions and debugging output much easier to understand.