Service YAML Generator

A Kubernetes Service is the stable network front door for a set of pods. Pods come and go — they crash, reschedule and get new IPs — so you almost never talk to a pod directly; you talk to a Service, and the Service keeps a rotating set of endpoints behind one constant name and IP. The Service YAML Generator builds that manifest for you, covering all four Service types, so you can stop memorising the spec and focus on the routing decisions that actually matter.

The form is split the way a Service spec is. You give the Service a name and (optionally) a namespace, then choose the type. For ClusterIP, NodePort and LoadBalancer you add one or more ports and at least one selector; for ExternalName you instead supply an externalName hostname and no selector or ports are needed. Each port row carries a name, the Service port, the targetPort on the pod, an optional nodePort, and a protocol (TCP, UDP or SCTP), so a single Service can expose several named ports cleanly.

Selectors are the heart of a Service: they are label key/value pairs that the Service uses to find its pods. The generator requires at least one selector for the pod-routing types and writes it as a proper matchLabels block. If you are building a StatefulSet or custom DNS you can also set clusterIP to None to produce a headless Service, which returns pod IPs directly instead of a virtual IP. sessionAffinity (ClientIP) and a comma-separated list of externalIPs are also supported for the cases that need them.

Everything is validated as you type. Service and namespace names must be valid RFC 1123 labels, every port must be in the 1 to 65535 range, and any nodePort you supply must fall in the 30000 to 32767 range that Kubernetes reserves for NodePort allocation. ExternalName values are checked as hostnames. The preview only renders a complete document when the input is sound, and an empty field simply disappears from the output rather than leaving a placeholder behind.

The generated manifest follows Kubernetes conventions: apiVersion: v1, kind: Service, then metadata and spec in the expected order, with type, selector and ports nested correctly. You can copy the YAML, download it as service.yaml, or print it. A small statistics strip shows how many ports, selector keys and labels the current Service carries. Because everything runs locally and nothing is uploaded, you can iterate on a Service definition as fast as you like and then apply it yourself with kubectl apply -f service.yaml, ideally after a kubectl apply --dry-run=server check against your cluster.

• All four types — ClusterIP, NodePort, LoadBalancer and ExternalName from one form.
• Dynamic ports — add as many port rows as you need, each with name, port, targetPort, nodePort and protocol.
• Selectors — label key/value rows written as a matchLabels block; required for pod-routing types.
• Headless Services — set clusterIP to None for StatefulSet / direct pod-IP discovery.
• ExternalName — supply a hostname and the generator omits selector and ports automatically.
• Session affinity and external IPs — optional ClientIP affinity and a comma-separated externalIPs list.
• Live YAML preview — updates as you type, with a clean placeholder when empty.
• Validation as you go — RFC 1123 names, port 1 to 65535, nodePort 30000 to 32767, ExternalName hostname.
• Copy / Download / Print — copy to clipboard, download service.yaml, or print.
• Sample loader and live statistics — one click fills a realistic Service; ports, selectors and labels are counted.

1. Name the Service. Type a valid RFC 1123 name and, optionally, a namespace.
2. Pick a type. Choose ClusterIP, NodePort, LoadBalancer or ExternalName.
3. Add a selector. For pod-routing types, add label key/value rows that match your pod labels.
4. Add ports. For each port set the Service port, targetPort (number or name), optional nodePort and protocol.
5. Optional fields. Set clusterIP to None for headless, add sessionAffinity or externalIPs, or (for ExternalName) set externalName.
6. Watch the preview. The YAML appears on the right and updates with every keystroke.
7. Export. Copy, download service.yaml, or print.

Example 1 — ClusterIP. Name web, type ClusterIP, selector app=web, one port 80 -> targetPort 8080 produces a standard internal Service.

Example 2 — NodePort. Type NodePort with port 80, nodePort 30080 exposes the pod on every node at 30080.

Example 3 — LoadBalancer. Type LoadBalancer, port 443 -> targetPort 8443, protocol TCP; the cloud provider provisions a load balancer.

Example 4 — Headless. clusterIP None with a selector makes a headless Service returning pod IPs directly.

Example 5 — ExternalName. Type ExternalName with externalName example.com routes the Service name to that external hostname.

• No schema memorising — the spec is assembled for you.
• Correct types — the right fields appear for ClusterIP/NodePort/LoadBalancer/ExternalName.
• Validated — bad names, ports and nodePorts are caught early.
• Multi-port — several named ports in one Service.
• Headless support — easy None clusterIP for StatefulSets.
• Private — everything runs in the browser.
• Copy, download or print — get the manifest where you need it.