What is the difference between port and targetPort?

The port is the port the Service listens on inside the cluster. The targetPort is the port on the pod that traffic is forwarded to. They are often the same but can differ.

When should I use NodePort vs LoadBalancer?

NodePort exposes the service on a static port on every node, useful for on-prem or testing. LoadBalancer provisions a cloud load balancer with an external IP and is preferred in managed cloud environments.

What does the selector do?

The selector matches pod labels. The Service routes traffic to any pod whose labels match every key-value pair in the selector. It must match your deployment's pod template labels.

What is a ClusterIP service?

ClusterIP is the default type. It assigns an internal cluster IP reachable only from within the cluster, ideal for internal microservice communication.

Can I expose multiple ports?

Yes, a Service can list multiple port entries, each with its own name, port, and targetPort. This builder generates a single primary port to keep the manifest simple.

What is the Kubernetes Service YAML Builder?

Builds a Kubernetes Service YAML with selector, port definitions, and service type configuration for exposing deployments internally or externally as ClusterIP, NodePort, or LoadBalancer. It runs free in your browser on Gera Tools, with nothing uploaded.

Kubernetes Service YAML Builder

Name: Kubernetes Service YAML Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Kubernetes Service YAML Builder

A Kubernetes Service provides a stable network endpoint for a set of pods. Because pods are ephemeral and their IPs change, a Service gives them a single virtual IP and DNS name. This builder generates a valid Service manifest for the three common types so you can expose a deployment without hand-writing YAML.

How it works

A Service uses a selector to find pods by their labels, then forwards traffic from its port to each pod’s targetPort. The type field controls reachability:

ClusterIP — internal-only virtual IP (default). Use for microservice-to-microservice calls inside the cluster.
NodePort — opens a static port (30000–32767) on every node, layered on top of a ClusterIP. Useful for on-prem testing or simple external access when you manage your own load balancer.
LoadBalancer — provisions an external cloud load balancer, layered on top of NodePort. The standard production choice on EKS, GKE, and AKS.

The builder assembles apiVersion: v1, kind: Service, metadata, and the spec block from your inputs. For TCP and UDP you set the protocol. For NodePort you can pin a nodePort value within the allowed range.

What each field means

selector — a map of label key-value pairs. Any pod whose labels contain every pair in the selector receives traffic from the Service. The selector must match spec.template.metadata.labels in your Deployment exactly; a typo means zero pods are selected and the Service routes to nothing without raising an error.

port vs targetPort — port is the port clients use to reach the Service inside the cluster. targetPort is the port the container actually listens on. They are often the same number but can differ, for example when you expose port 80 externally but your app listens on 8080.

protocol — TCP is the default and covers HTTP/HTTPS, gRPC, and most application traffic. Set UDP for DNS, DHCP, or real-time media. Services can list both by adding a second port entry.

Common mistakes

Forgetting to set targetPort to match the container port in the Pod spec — the builder defaults them to the same value, which is correct for most workloads.
Using a LoadBalancer Service in a bare-metal or on-prem cluster without a cloud controller — the EXTERNAL-IP stays <pending> forever unless you install MetalLB or a similar implementation.
Setting nodePort outside the 30000–32767 range — the API server will reject the manifest.

Tips and example

Keep selectors specific (for example app: web plus tier: frontend) so the Service only targets the intended pods. After generating, apply with:

kubectl apply -f service.yaml
kubectl get svc my-service

For a LoadBalancer, watch EXTERNAL-IP with kubectl get svc -w until the cloud provider assigns an address. Once assigned, you can point a DNS record at that IP and the Service handles traffic distribution across healthy pods automatically.