A ClusterIP Service provides internal cluster communication through a Service IP and DNS name. It commonly connects one Pod, such as a frontend, to backend Pods elsewhere in the cluster. section 6.4.1 section 1.4.3
Configure and verify a ClusterIP Service by checking these operational details:
- Select backend Pods with matching labels, such as app=internal-svc or app=nginx. section 6.4.1 section 5.1.4
- Expose a Service port and map it to the container targetPort; one Service can define multiple port mappings. section 6.4.1
- Use the Service name and DNS instead of addressing individual Pod IPs; distinct Services can expose the same port because they have distinct identities. section 6.4.1 section 1.4.3
- Distinguish ClusterIP from NodePort and LoadBalancer when reviewing how an application is exposed. section 9.3.5
Create a declarative Service manifest
Generate a starting YAML file with `kubectl create svc clusterip internal-svc --tcp 8080:80 --dry-run=client -o yaml > svc.yaml`. The resulting specification uses `port: 8080`, `targetPort: 80`, `protocol: TCP`, a selector such as `app: internal-svc`, and `type: ClusterIP`. Apply it with `kubectl create -f svc.yaml`, then verify it with `kubectl get svc`. section 6.4.1
spec:
ports:
- name: 8080-80
port: 8080
protocol: TCP
targetPort: 80
- name: search
port: 9200
protocol: TCP
targetPort: 9200
selector:
app: internal-svc
type: ClusterIP
status:
loadBalancer: {}
Inspect the manifest to see how ports, target ports, selectors, and the ClusterIP type combine in one Service definition. section 6.4.1
