Service
A stable network endpoint that load-balances traffic to a dynamic set of Pods selected by label.
What is Service?
A Service is a Kubernetes abstraction that provides a stable IP address and DNS name for a set of Pods, which themselves have ephemeral IPs that change on restart. The Service controller maintains a set of Endpoints (the IPs of ready Pods matching the selector) and kube-proxy programs iptables or IPVS rules on every node to forward traffic to those endpoints. This decoupling allows Deployments to roll out new Pod versions without clients needing to track individual Pod IPs.
Kubernetes offers four Service types: ClusterIP (the default — cluster-internal VIP only), NodePort (exposes a port on every node's external IP), LoadBalancer (provisions a cloud load balancer with a public IP, billed by the cloud provider), and ExternalName (maps the service to an external DNS name). Headless Services (clusterIP: None) skip the VIP and return individual Pod IPs from DNS, used by StatefulSets and service meshes.
Each LoadBalancer-type Service provisions a dedicated cloud load balancer (ALB, NLB, GLB, or Azure LB). This is a billable resource: on GCP, a regional TCP load balancer costs approximately $18/month plus data processing fees. Organizations with hundreds of Services of type LoadBalancer often consolidate them behind a single Ingress controller to reduce cost.
Example
apiVersion: v1
kind: Service
metadata:
name: web-api
namespace: production
spec:
selector:
app: web-api
ports:
- name: http
port: 80
targetPort: 8080
- name: https
port: 443
targetPort: 8443
type: ClusterIPCost & Waste Implications
Services of type LoadBalancer each provision a cloud load balancer billed at $18–$36/month on most cloud providers, plus data transfer charges. A cluster with 50 LoadBalancer Services that could be consolidated behind one Ingress controller is paying $900–$1,800/month unnecessarily in load balancer fees alone. Orphaned Services (selector pointing to deleted Deployments) waste allocated resources and create stale routing rules.
How KorPro Helps
KorPro detects Services with no matching Pod endpoints (orphaned selectors) and Services of type LoadBalancer that have no traffic flowing through them, flagging them as candidates for cleanup or consolidation.
Scan Your Cluster FreeRelated Terms
Ingress
NetworkingAn API object that configures HTTP/HTTPS routing rules from a single external load balancer to multiple backend Services.
Read definitionPod
Core ConceptsThe smallest deployable unit in Kubernetes — one or more containers that share a network namespace and storage volumes.
Read definitionDeployment
WorkloadsA controller that manages a ReplicaSet to keep a specified number of identical Pod replicas running and handles rolling updates.
Read definitionNetworkPolicy
NetworkingA namespaced resource that defines firewall rules controlling which Pods can send and receive traffic.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.