What's the difference between the four service types this tool supports?

ClusterIP (the default) gives the Service a stable internal IP reachable only inside the cluster. NodePort additionally opens a fixed port (30000-32767) on every node, reachable from outside. LoadBalancer asks the cloud provider to provision an external load balancer in front of the Service. Headless (ClusterIP: None) skips load-balancing entirely and returns the Pod IPs directly via DNS, most often used with StatefulSets.

Why does the generator require at least one selector label?

A Service without a selector doesn't route to any Pods automatically; it only makes sense paired with a manually managed Endpoints object, which is an advanced, less common setup this simple generator doesn't cover. Requiring a selector keeps the generated manifest immediately useful for the common case of routing to Pods by label.

What does session affinity actually do?

Enabling it sets sessionAffinity: ClientIP, which routes all traffic from the same client IP to the same Pod for up to three hours by default, instead of the usual round-robin/random distribution across all matching Pods.

Is the NodePort field required for NodePort-type Services?

No. If you leave it blank, Kubernetes allocates one automatically from the default 30000-32767 range when you apply the manifest; you only need to set it explicitly if you require a specific, stable port number.

Kubernetes Service Generator - Build Service YAML

Overview

Introduction

Exposing a set of Pods reliably means getting the Service's selector, port, and targetPort exactly right, and the four service types behave differently enough that it's easy to reach for the wrong one.

This tool generates a Service manifest from a form covering all four common types, port mappings, selector labels, and session affinity, entirely client-side.

What Is Kubernetes Service YAML Generator?

A Kubernetes Service YAML generator supporting ClusterIP, NodePort, LoadBalancer, and headless (ClusterIP: None) service types.

It handles repeatable port/targetPort/nodePort mappings, an arbitrary number of selector labels, and an optional client-IP session affinity toggle.

How Kubernetes Service YAML Generator Works

The service type toggle maps directly to spec.type, except for the Headless option, which sets type: ClusterIP together with clusterIP: None, since 'headless' isn't a distinct type value in the Kubernetes API but a special value of clusterIP.

Each port row becomes one entry in spec.ports, with nodePort only emitted when the service type is NodePort and you've supplied a value.

Selector labels are written under spec.selector as a plain key/value map, matched against whatever labels your Pods (for example, from the Deployment Generator) actually carry.

When To Use Kubernetes Service YAML Generator

Use it right after generating a Deployment, to expose its Pods internally (ClusterIP), externally on a fixed node port (NodePort), or via a cloud load balancer (LoadBalancer).

Use the Headless option when Pods need direct, individually addressable DNS records instead of a single virtual IP, the typical StatefulSet pattern.

Often used alongside Kubernetes Deployment YAML Generator, Kubernetes Ingress YAML Generator and Kubernetes Pod YAML Generator.

Features

Advantages

Covers all four practical Service type variants in one form instead of requiring you to remember each one's distinct YAML shape.
Supports multiple port mappings in a single Service, matching real multi-port workloads.
Runs entirely in the browser; nothing about your cluster or service topology is sent anywhere.

Limitations

Doesn't support ExternalName services or manually managed Endpoints/EndpointSlices.
Doesn't validate that the selector labels actually match any real Pods in your cluster, since this tool has no cluster access.
LoadBalancer-specific annotations (for cloud-provider load balancer configuration) aren't covered; add them manually if needed.

Examples

A ClusterIP Service routing port 80 to a Pod's port 8080

Input

name: web, type: ClusterIP, port: 80, targetPort: 8080, selector: app=web

Output

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP

Clients inside the cluster reach the Service on port 80, which forwards to containerPort 8080 on any matching Pod.

Best Practices & Notes

Best Practices

Match selector labels exactly against your Deployment or Pod's metadata.labels, a common typo source when Services silently route to nothing.
Prefer ClusterIP plus an Ingress over NodePort for HTTP(S) traffic in most clusters; reserve NodePort for cases needing a fixed, directly reachable port.
Name each port when a Service exposes more than one, since Ingress and NetworkPolicy resources often need to reference ports by name.

Developer Notes

The tool hand-builds the YAML string directly rather than depending on a YAML serialization library, since the shape is fixed and known in advance. The Headless case is handled as a special branch that overrides the type field's output rather than as a fifth ServiceType value, keeping the underlying Kubernetes API accurate (there is no 'Headless' kind, only a ClusterIP Service with clusterIP set to None). NodePort validation restricts values to the default Kubernetes 30000-32767 allocation range.

Kubernetes Service YAML Generator Use Cases

Exposing a newly generated Deployment's Pods inside the cluster with a stable ClusterIP
Opening a fixed external port on every node for a service that needs direct external access without a load balancer
Requesting a cloud load balancer in front of a Deployment via the LoadBalancer type
Creating a headless Service for direct per-Pod DNS resolution with a StatefulSet

Common Mistakes

Selector labels that don't match any Pod's actual labels, leaving the Service with zero endpoints and traffic silently dropped.
Confusing port (what clients connect to) with targetPort (the container's actual listening port), especially when they differ.
Expecting a NodePort Service to load-balance externally on its own; it still needs an external load balancer or DNS round-robin across node IPs for that.

Tips

Use the Kubernetes Ingress Generator afterward if you need host/path-based HTTP routing in front of this Service instead of exposing it directly.

Kubernetes Service YAML Generator