Kubernetes Service Generator
Build a Service of any of the four types, with the selector kept straight from the pod labels it has to match and the port fields explained. The output is checked by our own validator as you type.
service.yaml
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Confusing port and targetPort
port is what clients connect to on the Service, targetPort is the container's port. Swapping them gives a Service that accepts connections and forwards nowhere.
Instead:targetPort must match containerPort, or a named port.
Using a hostPort or NodePort where a Service was enough
hostPort binds the node's port and limits the pod to one replica per node. NodePort exposes it on every node.
Instead:ClusterIP for internal traffic, and an Ingress or LoadBalancer for external.
Setting clusterIP: None without meaning to
That makes it headless: DNS returns pod addresses and there is no load balancing or virtual IP.
Instead:Leave clusterIP unset unless you specifically want per-pod DNS.
The four Service types, and the ports nobody agrees on
A Service is a stable name and address in front of a set of pods that keep changing. Almost every problem with one is either the selector matching nothing, or a misunderstanding about which of the three port numbers does what.
port, targetPort and containerPort
Three numbers, and only two of them matter. port is what clients connect to. targetPort is the port on the pod that traffic is forwarded to, and it defaults to the same value as port when omitted, not to whatever the container declared. containerPort is documentation only: a container can listen on a port it never declared and traffic still arrives.
ports:
- port: 80 clients connect here
targetPort: 8080 forwarded to this pod port
targetPort omitted -> defaults to port (80), NOT to
the containerPort
targetPort: http -> resolved against the container's
declared port NAMES. If nothing
declares that name, no endpoint
is ever created.A NodePort cannot be any number you like
The range is 30000 to 32767 unless the API server was started with a different one. Anyone translating a docker run -p 8080:80 reaches for nodePort 8080 and the object is rejected. Leaving nodePort unset lets the cluster allocate one, which is what you want unless something external is hard-coded to a port.
docker run -p 8080:80 any host port
Service type: NodePort
nodePort: 8080 rejected
nodePort: 30080 fine
nodePort omitted allocated for you
# the true local equivalent of docker -p is:
kubectl port-forward svc/api 8080:80externalTrafficPolicy trades the client IP against balancing
Cluster spreads traffic evenly across pods and SNATs it, so the application sees a node address rather than the client's. Local preserves the source IP and only delivers to nodes actually running a pod, so with fewer pods than nodes the load is uneven and nodes with no pod drop their share until health checks catch up.
Cluster even spread, source IP lost
10 nodes, 3 pods -> traffic hops between
nodes, every pod gets a third
Local source IP kept, uneven spread
10 nodes, 3 pods -> 7 nodes have nothing
to deliver to. The load balancer must
health check them out first.Headless is not broken
clusterIP: None means no virtual IP and no kube-proxy involvement at all. DNS returns every ready pod address directly and the client chooses. That is what a StatefulSet needs for stable per-pod names, and what a gRPC client wants: with a normal ClusterIP, gRPC opens one long-lived connection and stays pinned to a single pod forever, so the Service balances nothing.
spec:
clusterIP: None
dig api.default.svc.cluster.local
10.1.2.3
10.1.2.9 one A record per ready pod
10.1.3.1
# and with a StatefulSet's serviceName:
# api-0.api.default.svc.cluster.local -> one podExternalName does nothing but answer DNS
It returns a CNAME and stops there. No proxying, no ports, no selector, no TLS handling. So a Service on port 80 aliasing an HTTPS endpoint does not work, because there is nothing in the path to rewrite anything. It is a name, and the client connects directly to whatever that name resolves to.
spec:
type: ExternalName
externalName: db.rds.amazonaws.com
# clients connecting to `db` inside the cluster get
# a CNAME to that host and connect straight out.
# Ports listed here are ignored entirely.