ClusterIP
The default Kubernetes Service type. It exposes an application using an internal cluster IP address.
Key Topics
- • Internal communication
- • Default Service type
- • Stable endpoint
- • Pod load balancing
Learn how Kubernetes applications communicate using Services, DNS, service discovery, ClusterIP, NodePort, LoadBalancer, Ingress, Gateway API, and Network Policies.
Kubernetes Networking
Pod Networking
Kubernetes Services
DNS & Service Discovery
Ingress & Gateway API
Network Policies
Introduction
Kubernetes provides a networking model that allows workloads to communicate across the cluster. Pods receive their own IP addresses, but Pods can be created, removed, and replaced over time.
Kubernetes Services provide stable network endpoints for groups of Pods. This allows applications to communicate without needing to track individual Pod IP addresses.
Kubernetes networking also includes DNS, external traffic routing, load balancing, Gateway and Ingress resources, and Network Policies for controlling traffic between workloads.
Kubernetes Services
Services provide stable network access to applications running in one or more Pods. Kubernetes provides several Service types for different networking requirements.
The default Kubernetes Service type. It exposes an application using an internal cluster IP address.
Key Topics
NodePort exposes a Service on a port across cluster nodes, allowing traffic to reach the Service through a node IP address and assigned port.
Key Topics
LoadBalancer exposes a Service externally using a load balancer implementation, commonly integrated with a cloud provider or another supported implementation.
Key Topics
ExternalName maps a Kubernetes Service name to an external DNS name without creating a proxy to backend Pods.
Key Topics
ClusterIP
ClusterIP is the default Kubernetes Service type. It provides an internal IP address that can be used by workloads inside the cluster to communicate with an application.
The Service uses selectors to identify backend Pods and provides a stable endpoint even when individual Pods are replaced.
ClusterIP Service Example
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIPNodePort
A NodePort Service exposes an application on a port across the cluster nodes. Traffic can reach the Service by connecting to a node address and the assigned NodePort.
NodePort builds on the ClusterIP model and can be useful when you need external access or want to integrate Kubernetes with another load balancing solution.
NodePort Service Example
apiVersion: v1
kind: Service
metadata:
name: nginx-nodeport
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
nodePort: 30080
type: NodePortLoadBalancer
A LoadBalancer Service is used to expose an application through an external load balancer implementation. The exact behavior depends on the Kubernetes environment and the load balancer integration available to the cluster.
This Service type is commonly used to provide external connectivity to applications running inside Kubernetes.
LoadBalancer Example
apiVersion: v1
kind: Service
metadata:
name: nginx-loadbalancer
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
type: LoadBalancerService Discovery
Pods are designed to be replaceable resources. When Pods are recreated, their IP addresses can change.
Kubernetes Services provide stable network identities, while DNS allows applications to discover Services using names instead of directly tracking individual backend Pods.
Service Discovery Flow
Application Pod
│
│ DNS Lookup
▼
nginx-service
│
▼
Kubernetes Service
│
┌─────┼─────┐
▼ ▼ ▼
Pod Pod PodExternal Traffic
Ingress can route HTTP and HTTPS traffic from outside a cluster to Kubernetes Services based on rules such as hosts and paths.
The Kubernetes project also provides the Gateway API, which offers more advanced and extensible traffic management capabilities.
Ingress is still supported, but the Kubernetes project recommends Gateway for newer networking use cases where its capabilities are appropriate.
Ingress Traffic Flow
Internet
│
▼
Ingress / Gateway
│
▼
Kubernetes Service
│
┌───┼───┐
▼ ▼ ▼
Pod Pod PodNetwork Security
NetworkPolicy resources allow you to define rules that control permitted network traffic between Pods and between workloads and external networks.
NetworkPolicy behavior depends on the networking implementation used by the Kubernetes cluster, so you should confirm that your cluster networking solution supports NetworkPolicy enforcement.
NetworkPolicy Example
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- IngressCore Concepts
Each Pod receives its own IP address within the cluster network, allowing workloads to communicate according to the Kubernetes networking model.
Services provide stable network endpoints while the Pods behind those Services can change over time.
Kubernetes DNS allows workloads to discover Services using predictable names instead of relying directly on changing Pod IP addresses.
Ingress and Gateway API resources can provide controlled access to Services from outside the Kubernetes cluster.
NetworkPolicy resources define rules for controlling allowed traffic between Pods and between workloads and external networks.
Kubernetes routes Service traffic to the backend endpoints associated with the Service.
kubectl
Use kubectl to inspect Services, networking resources, endpoints, and policies inside your Kubernetes cluster.
kubectl get servicesDisplay Services in the current namespace.
kubectl get pods -o wideDisplay Pods with additional networking information.
kubectl get ingressDisplay Ingress resources.
kubectl get networkpolicyDisplay NetworkPolicy resources.
kubectl describe service nginx-serviceView detailed information about a Service.
kubectl get endpointslicesView EndpointSlice resources used for Service backends.
kubectl apply -f service.yamlCreate or update a Service from a YAML manifest.
kubectl get svc -ADisplay Services across all namespaces.
Learning Roadmap
Follow these steps to understand how Kubernetes workloads discover and communicate with each other.
Learn how Pods communicate inside a Kubernetes cluster and why Pod IP addresses are not usually used directly for application discovery.
Create internal Services that provide stable access to application Pods.
Understand different approaches for exposing Kubernetes workloads outside the cluster.
Use Kubernetes Services and DNS names to allow applications to find each other.
Learn how HTTP and HTTPS traffic can be routed from outside the cluster to Kubernetes Services.
Use Network Policies and platform-specific networking capabilities to control workload communication.
Best Practices
Use Kubernetes Services to provide stable access to workloads instead of depending directly on individual Pod IP addresses.
Ensure Service selectors match the intended application Pods and use consistent labels across workloads.
Select ClusterIP, NodePort, LoadBalancer, or ExternalName according to your application's connectivity requirements.
Use Network Policies where supported and follow least-privilege networking principles.
Allow applications to discover internal Services using Kubernetes DNS names rather than hard-coded IP addresses.
Use an appropriate external traffic solution such as Gateway API, Ingress, or LoadBalancer depending on your environment and requirements.
Continue Learning
Learn Kubernetes architecture, clusters, nodes, Pods, Deployments, Services, and kubectl fundamentals.
⚙️Learn how Kubernetes manages applications using Pods, Deployments, ReplicaSets, StatefulSets, and Jobs.
🐳Learn Docker containers, images, Dockerfiles, volumes, and networking before moving deeper into Kubernetes.
Next Step
Practice creating Services, connecting applications using DNS, exposing workloads, and applying networking controls to understand how Kubernetes applications communicate in real environments.