Kubernetes:Service
lastmod 2026-02-26created 2023-07-037 edits
About
Subicura.com_-k8s-guide-_pod-service.png
ClusterIP
ClusterIP assigns a new IP inside the cluster and provides a load balancer that targets multiple Pods. It also registers the service name with the internal domain name server, so Pods can communicate with each other by service name.
NodePort
CluterIP can only be accessed from inside the cluster. Let's create a NodePort service so it can be accessed from outside the cluster (the node).
Kubernetes-nodeport.png
Example
An example of connecting a service port using NginX. See Kubectl:run#Connecting a service with NodePort for details.
ClusterIP vs NodePort
| ClusterIP | NodePort | |
| Access scope | Inside the cluster only | Also accessible from outside the cluster |
| Access method | | <NodeIP> |
| Node port | None | Assigned from the 30000-32767 range |
| Purpose | Communication between internal microservices | External exposure (for development/testing) |
Summary
- ClusterIP — only other Pods inside the cluster can access it via my-nginx-svc:8080
- NodePort — the above + direct access from outside the cluster via <WorkerNodeIP>:31234
In production, if external exposure is needed, LoadBalancer or Ingress is usually used rather than NodePort.
LoadBalancer
The drawback of NodePort is that when a node goes away, traffic cannot automatically be routed through another node. For example, with 3 nodes you can connect via NodePort through any of the 3, but you cannot tell which nodes are alive.
To automatically reach a live node, you need a Load Balancer that targets all nodes. If the browser sends requests to the Load Balancer instead of directly to the NodePort, and the Load Balancer takes care of reaching a live node, the drawback of NodePort goes away.
| LoadBalancer and NodePort |
| LoadBalancer includes the functionality of NodePort by default. |