TechyPilots Info
TechyPilots.INFO
Home/Tutorials/Kubernetes/Services and Networking
Kubernetes Tutorial

Kubernetes Services and Networking

Learn how Kubernetes applications communicate using Services, DNS, service discovery, ClusterIP, NodePort, LoadBalancer, Ingress, Gateway API, and Network Policies.

Level: Beginner to Intermediate
Topics: Services & Networking

Kubernetes Networking

Application Connectivity

Pod Networking

Kubernetes Services

DNS & Service Discovery

Ingress & Gateway API

Network Policies

Introduction

How Kubernetes applications communicate

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

Kubernetes Service types

Services provide stable network access to applications running in one or more Pods. Kubernetes provides several Service types for different networking requirements.

01

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
02

NodePort

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

  • Node IP access
  • External connectivity
  • Static port
  • ClusterIP foundation
03

LoadBalancer

LoadBalancer exposes a Service externally using a load balancer implementation, commonly integrated with a cloud provider or another supported implementation.

Key Topics

  • External traffic
  • Cloud integration
  • Load balancing
  • Public applications
04

ExternalName

ExternalName maps a Kubernetes Service name to an external DNS name without creating a proxy to backend Pods.

Key Topics

  • DNS alias
  • External services
  • CNAME record
  • Service abstraction

ClusterIP

Internal application communication

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: ClusterIP

NodePort

Expose applications through cluster nodes

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: NodePort

LoadBalancer

Expose workloads using a load balancer

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: LoadBalancer

Service Discovery

Use stable names instead of Pod IP addresses

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   Pod

External Traffic

Ingress and Gateway API

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 Pod

Network Security

Control traffic with Network Policies

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:
    - Ingress

Core Concepts

Kubernetes networking concepts

01

Pod Networking

Each Pod receives its own IP address within the cluster network, allowing workloads to communicate according to the Kubernetes networking model.

02

Service Discovery

Services provide stable network endpoints while the Pods behind those Services can change over time.

03

DNS

Kubernetes DNS allows workloads to discover Services using predictable names instead of relying directly on changing Pod IP addresses.

04

Ingress and Gateway

Ingress and Gateway API resources can provide controlled access to Services from outside the Kubernetes cluster.

05

Network Policies

NetworkPolicy resources define rules for controlling allowed traffic between Pods and between workloads and external networks.

06

Service Routing

Kubernetes routes Service traffic to the backend endpoints associated with the Service.

kubectl

Useful networking commands

Use kubectl to inspect Services, networking resources, endpoints, and policies inside your Kubernetes cluster.

kubectl get services

Display Services in the current namespace.

kubectl get pods -o wide

Display Pods with additional networking information.

kubectl get ingress

Display Ingress resources.

kubectl get networkpolicy

Display NetworkPolicy resources.

kubectl describe service nginx-service

View detailed information about a Service.

kubectl get endpointslices

View EndpointSlice resources used for Service backends.

kubectl apply -f service.yaml

Create or update a Service from a YAML manifest.

kubectl get svc -A

Display Services across all namespaces.

Learning Roadmap

How to learn Kubernetes networking

Follow these steps to understand how Kubernetes workloads discover and communicate with each other.

Step 1

Understand Pod Networking

Learn how Pods communicate inside a Kubernetes cluster and why Pod IP addresses are not usually used directly for application discovery.

Step 2

Learn ClusterIP Services

Create internal Services that provide stable access to application Pods.

Step 3

Explore NodePort and LoadBalancer

Understand different approaches for exposing Kubernetes workloads outside the cluster.

Step 4

Learn Service Discovery

Use Kubernetes Services and DNS names to allow applications to find each other.

Step 5

Understand Ingress and Gateway

Learn how HTTP and HTTPS traffic can be routed from outside the cluster to Kubernetes Services.

Step 6

Apply Network Security

Use Network Policies and platform-specific networking capabilities to control workload communication.

Best Practices

Kubernetes networking best practices

Use Services for Discovery

Use Kubernetes Services to provide stable access to workloads instead of depending directly on individual Pod IP addresses.

Use Labels Carefully

Ensure Service selectors match the intended application Pods and use consistent labels across workloads.

Choose the Correct Service Type

Select ClusterIP, NodePort, LoadBalancer, or ExternalName according to your application's connectivity requirements.

Secure Network Traffic

Use Network Policies where supported and follow least-privilege networking principles.

Use DNS for Service Discovery

Allow applications to discover internal Services using Kubernetes DNS names rather than hard-coded IP addresses.

Plan External Access

Use an appropriate external traffic solution such as Gateway API, Ingress, or LoadBalancer depending on your environment and requirements.

Next Step

Build and connect Kubernetes applications

Practice creating Services, connecting applications using DNS, exposing workloads, and applying networking controls to understand how Kubernetes applications communicate in real environments.