About this tool
Generate ClusterIP, NodePort or LoadBalancer Service manifests with validated names, selectors and port mappings.
This generator produces a valid Kubernetes core/v1 Service manifest — ClusterIP, NodePort or LoadBalancer — with the same validation the API server applies: RFC 1035 names (lowercase, max 63 characters, starting with a letter), ports 1-65535, nodePorts inside the default 30000-32767 range, and mandatory port names on multi-port services. It is for developers and SREs who want copy-paste-ready YAML without a round-trip of kubectl apply errors.
Open Kubernetes Service YAML Generator on AltFTool — it loads instantly in your browser.
Paste or upload your source content.
Choose the target format or conversion mode.
Copy or download the converted result.
Name, namespace, selector, port and nodePort rules are enforced exactly as k8s.io/apimachinery does.
Requires a name on every port once you add a second one — the rule people most often hit at apply time.
Omits targetPort when it equals port and quotes selector values, producing clean diff-friendly manifests.
ClusterIP (the default) gives the Service a virtual IP reachable only inside the cluster; NodePort additionally opens the same port — from the 30000-32767 range by default — on every node's IP; LoadBalancer builds on NodePort and asks the cloud provider to provision an external load balancer. Most external traffic in production actually enters through an Ingress or Gateway backed by one LoadBalancer Service.
30000-32767 by default, set by the kube-apiserver --service-node-port-range flag. If you leave nodePort empty the control plane auto-allocates a free port from that range; requesting one outside it is rejected at admission.
port is what the Service itself listens on (clients connect to service-name:port), while targetPort is the container port the traffic is forwarded to; it defaults to the same value as port. targetPort can also be a named port from the pod spec — a string of up to 15 lowercase characters — which lets containers move ports without editing the Service.
The most common cause is a selector mismatch: the Service spec.selector must be a subset of the pod labels, compared exactly, and a typo like app=web vs app=webapp silently selects nothing. Check kubectl get endpoints <service> — an empty ENDPOINTS column means no pod matched, and comparing kubectl get pods --show-labels against the selector usually reveals the difference.