DevOps & Config Tools

Kubernetes Service Generator

Create the Service that connects clients to your pods. Choose the type, internal ClusterIP, NodePort, a cloud LoadBalancer, a headless service for stable pod names or an ExternalName alias, list the ports, and add cloud load balancer annotations, allowed client ranges, session affinity or local traffic policy. The tool explains how the service is reached once applied.

  • Runs in your browser
  • No sign-up
  • Free to use
Start from an example

targetPort can be a number or the named port of the container.

Options

    How to use Kubernetes Service Generator

    1. Enter the service name, namespace and type.
    2. Give the labels of the target pods.
    3. List the ports as name, port and target port.
    4. Add load balancer options and copy the YAML.

    Kubernetes Service Generator features

    Every type

    ClusterIP, NodePort, LoadBalancer, headless and ExternalName.

    Ports

    Named ports, target ports by name or number, nodePort range check, UDP.

    Cloud annotations

    AWS NLB or internal, Google Cloud internal, Azure internal.

    Access control

    loadBalancerSourceRanges for allowed client networks.

    Traffic policy

    externalTrafficPolicy: Local to keep client IPs.

    Session affinity

    ClientIP stickiness with a timeout.

    When to use Kubernetes Service Generator

    • Exposing an API inside the cluster.
    • Publishing a TCP service through a cloud load balancer.
    • Giving StatefulSet pods stable DNS names.
    • Pointing an internal name at an external database.

    Kubernetes Service Generator FAQ

    Which type should I use?

    ClusterIP for traffic inside the cluster (most services), an Ingress for HTTP from outside, LoadBalancer for non-HTTP traffic from outside, NodePort for simple or on-premise setups.

    What is a headless service?

    A service with clusterIP: None. DNS returns the pod IPs directly, which StatefulSets use for names such as postgres-0.postgres.

    What does externalTrafficPolicy: Local do?

    Traffic is only sent to pods on the node that received it, which keeps the client IP and saves a hop, but nodes without pods get no traffic.

    Why limit source ranges?

    A LoadBalancer is reachable from the internet. loadBalancerSourceRanges restricts it to the networks you list.

    How do I reach the service?

    Inside the cluster as name.namespace.svc.cluster.local on the service port; the notes show the exact address.

    Is anything uploaded?

    No. The YAML is generated in your browser.

    How Services route traffic

    Pods come and go and change IP addresses, so clients need a stable address. A Service provides it: it selects pods by their labels and forwards traffic sent to its own address and port to one of them. The type of Service decides where that address is reachable from.

    ClusterIP, the default, gives the Service a virtual IP inside the cluster and a DNS name. NodePort additionally opens a port between 30000 and 32767 on every node. LoadBalancer asks the cloud provider for an external load balancer in front of those node ports. ExternalName creates only a DNS alias for a host outside the cluster.

    Ports map the Service port to the container port. A target port can be a number or the name of a container port, which lets the container change its port without touching the Service. The generator validates port names, which Kubernetes limits to 15 characters, and the nodePort range.

    Load balancers have provider-specific options set through annotations: a Network Load Balancer or an internal-only balancer on AWS, internal balancers on Google Cloud and Azure. Without source ranges, a public load balancer accepts connections from anywhere, so the tool reminds you to restrict it or to use an Ingress for HTTP.

    Headless services skip the virtual IP altogether; DNS returns the IPs of the ready pods, and StatefulSet pods get stable individual names, which databases and clustered systems rely on.

    Other useful tools