Skip to main content
Yoryantra
Home/Tools
← Back to Tools

Kubernetes Service Port Mapper

Map Service ports to selected workload ports and Ingress backends across Kubernetes manifests.

Paste Services with workload and Ingress manifests to trace declared traffic paths.

Mapping Settings

Port fields

porttargetPortnodePortcontainerPorthost

Checks

Parsing stays in this browser. EndpointSlices, Pod readiness, cloud load balancers, and live traffic are not queried.

Output

Kubernetes service port mapping output will appear here.
Manifest text is parsed in this browser. Live EndpointSlices, readiness, network policy, kube-proxy behavior, DNS, and cloud networking are outside the mapping.

Follow the port path in the right order

A Service receives traffic on spec.ports[].port and sends it to targetPort. If targetPort is omitted, Kubernetes defaults it to the Service port. A named targetPort resolves against a named port on selected Pods; a numeric targetPort does not require the Pod manifest to declare containerPort.

That distinction matters during static review: a missing numeric containerPort declaration is not proof that routing will fail, while a named targetPort with no matching named Pod port is a much stronger signal.

Selectors are namespace-sensitive

A normal Service selects Pods by label equality inside its own namespace. A matching label set found in another namespace is not a backend for that Service.

Selectorless Services are different

A Service without a selector can be backed by manually managed EndpointSlices. Static workload-label matching therefore does not classify selectorless Services as broken.

Exposure type changes the meaning of a port

  • ClusterIP exposes the Service on a cluster-internal virtual IP by default.
  • NodePort adds a port on nodes; the configured cluster range can differ from the common default range.
  • LoadBalancer asks an implementation or cloud integration to provision external load balancing and normally builds on Service networking underneath.
  • ExternalName is DNS indirection rather than a proxy to selected Pods.
  • Headless Services use clusterIP: None and rely on DNS/endpoints rather than the normal virtual IP.

Ingress references are checked as namespaced backends

Standard Ingress backends name a Service and either a numeric or named Service port. The mapping checks that the referenced Service exists in the same namespace and that the requested Service port is declared in the pasted set. It also reads defaultBackend in addition to rule paths.

What a static mapping still cannot prove

Matching YAML does not prove that Pods are Ready, EndpointSlices contain usable endpoints, the application listens on the target port, NetworkPolicy allows the flow, kube-proxy or a service mesh is healthy, or a cloud load balancer has finished provisioning.

Kubernetes documents Service selectors, targetPort defaulting, named ports, multi-port Services, selectorless Services, and EndpointSlices in the Service documentation.

Port-mapping details that often cause confusion

Is targetPort required?

No. If it is omitted, Kubernetes uses the Service port value as the targetPort.

Must a Pod declare containerPort for numeric Service routing?

No. A numeric targetPort can reach the Pod IP and port even when containerPort is not declared. The declaration is still useful documentation and is required for named-port resolution.

Does a matching selector guarantee an endpoint?

No. Pod readiness and EndpointSlice state are runtime facts. The comparison here only establishes that pasted Pod-template labels could match the Service selector.

Can an Ingress point to a Service in another namespace?

Standard Ingress Service backends are namespaced with the Ingress. Cross-namespace routing needs a different mechanism or controller-specific feature.