1 / 19

OpenShift Networking

A Practical Guide: From Kubernetes Fundamentals to OpenShift Enhancements
Presenter
Your Name
Date
December 2, 2024
Duration
30-45 minutes
Press → or Space to begin
Introduction

OpenShift Networking

A Practical Guide: From Kubernetes Fundamentals to OpenShift Enhancements

👥 Who This Is For

  • Application Teams
    Onboarding to OpenShift or recently onboarded
  • Red Hat Consultants
    Reusable content for client engagements
  • Anyone confused by container networking
    We'll make it intuitive

🎯 What You'll Learn Today

  • How networking actually works in OpenShift/Kubernetes
  • Why there are "three networks" in your cluster
  • How to control traffic flow with policies and egress rules
  • Practical demos you can replicate
💼
App Team
🎓
Consultant
🧑‍💻
Learner
The Challenge

The Networking Problem We're Solving

⚠️ Traditional Networking Challenges

  • Static Infrastructure:
    VMs with fixed IPs, manual firewall rules
  • Tight Coupling:
    Applications hardcode IP addresses
  • Limited Scalability:
    Adding capacity requires network team involvement

🎯 Container Platform Requirements

  • Dynamic Workloads:
    Pods created/destroyed constantly
  • Service Discovery:
    Apps need to find each other automatically
  • Network Isolation:
    Multi-tenant security without VM overhead
⚙️
Traditional
⚡
Transform
🔄
Modern
Foundational Concept

Three Networks in One Cluster

The Mental Model That Makes Everything Clear

🔷 The Three-Layer Model

  • 1. Node Network (The Foundation)
    Physical/virtual machine network • Example: 10.0.0.0/16
  • 2. Pod Network (The Overlay)
    Software-defined network for containers • Example: 10.128.0.0/14
  • 3. Service Network (The Virtual Layer)
    Stable virtual IPs for service discovery • Example: 172.30.0.0/16

💡 Why Three Separate Networks?

  • Isolation: Pods can scale without consuming node IPs
  • Portability: Pod network is platform-managed, not tied to infrastructure
  • Stability: Services provide unchanging endpoints despite pod churn
Kubernetes Fundamentals

Pod Networking

How Containers Communicate

📦 Core Principles

  • Every pod gets a unique IP address
    No port conflicts between containers
  • All pods can communicate without NAT
    Flat network model within boundaries
  • Pod IPs are ephemeral
    Restart a pod = new IP • Never hardcode pod IPs!

🔌 Container Network Interface (CNI)

  • Plugin architecture for pod networking
  • OpenShift default: OVN-Kubernetes
  • Assigns IP, configures namespace, sets up routing
Kubernetes Fundamentals

Service Networking

Stable Endpoints for Dynamic Workloads

🎯 The Service Problem

  • Pod IPs change constantly
    Scaling, restarts, failures all create new IPs
  • Applications need stable endpoints
    Can't update config every time a pod restarts
  • Load balancing required
    Distribute traffic across multiple replicas

🔄 Service Objects: The Solution

  • Virtual IP (VIP) from Service CIDR
    Example: backend-service → 172.30.45.100
  • DNS automatically configured
  • Load balances across healthy pod endpoints
External Access

NodePort Traffic Flow

How External Traffic Reaches Your Pods

🌐 NodePort Mechanics

  • Port range: 30000-32767
    Every node listens on the same port
  • External Client → Node IP:30080
    Traffic redirected to Service VIP internally
  • Service VIP → Pod IP
    Same load balancing as ClusterIP

⚡ Key Characteristics

  • Works on any node (even if pod not on that node)
  • Source IP preservation depends on externalTrafficPolicy
  • Most production uses Routes/Ingress instead
OpenShift Enhancement

OVN-Kubernetes Architecture

The Engine Behind OpenShift Networking

⚙️ What is OVN-Kubernetes?

  • Open Virtual Network (OVN)
    Software-defined networking solution
  • Replaces kube-proxy
    Better performance at scale
  • Default in OpenShift 4.x
    Production-tested and supported

✨ Key Advantages

  • OVS flows instead of iptables (faster)
  • Native NetworkPolicy enforcement
  • EgressIP, EgressFirewall, Multicast support
Security

Network Policies

Microsegmentation for Kubernetes

🔒 What are NetworkPolicies?

  • Firewall rules for pods
    Control ingress/egress at pod level
  • Label-based selection
    Dynamic, not IP-based
  • Default-allow becomes default-deny
    Once applied, explicit rules required

🎯 Common Use Cases

  • Isolate namespaces from each other
  • Restrict database access to specific apps
  • Block egress to internet except for specific services
Enterprise Integration

Egress IP Configuration

Stable Source IPs for External Systems

🌐 The Egress IP Problem

  • Default behavior: Pods egress using node IP
    Changes if pod moves to different node
  • External systems require IP whitelisting
    Databases, APIs, legacy systems
  • Compliance requirements
    Audit trails need stable source IPs

✅ EgressIP Solution

  • Assign stable IP to namespace or specific pods
  • Automatically moves with pod (HA)
  • Requires coordination with network team
Putting It All Together

Complete Traffic Flow

External Client to Pod and Back

🔄 The Journey of a Request

  • 1. External Client → Route (Ingress)
    DNS resolves to OpenShift router
  • 2. Router → Service VIP
    HAProxy forwards to backend service
  • 3. Service VIP → Pod IP
    OVN-K load balances to pod
  • 4. Pod → External System (Egress)
    Uses EgressIP if configured

🛡️ Security Layers Applied

  • NetworkPolicy enforcement at pod boundaries
  • TLS termination at router (optional)
Kubernetes Fundamentals

Pod Networking

How Containers Communicate

📦 Core Principles

  • Every pod gets a unique IP address
    No port conflicts between containers
  • All pods can communicate without NAT
    Flat network model within boundaries
  • Pod IPs are ephemeral
    Restart a pod = new IP • Never hardcode pod IPs!

🔌 Container Network Interface (CNI)

  • Plugin architecture for pod networking
  • OpenShift default: OVN-Kubernetes
  • Assigns IP, configures namespace, sets up routing
Kubernetes Fundamentals

Service Networking

Stable Endpoints for Dynamic Workloads

🎯 The Service Problem

  • Pod IPs change constantly
    Scaling, restarts, failures all create new IPs
  • Applications need stable endpoints
    Can't update config every time a pod restarts
  • Load balancing required
    Distribute traffic across multiple replicas

🔄 Service Objects: The Solution

  • Virtual IP (VIP) from Service CIDR
    Example: backend-service → 172.30.45.100
  • DNS automatically configured
  • Load balances across healthy pod endpoints
External Access

NodePort Traffic Flow

How External Traffic Reaches Your Pods

🌐 NodePort Mechanics

  • Port range: 30000-32767
    Every node listens on the same port
  • External Client → Node IP:30080
    Traffic redirected to Service VIP internally
  • Service VIP → Pod IP
    Same load balancing as ClusterIP

⚡ Key Characteristics

  • Works on any node (even if pod not on that node)
  • Source IP preservation depends on externalTrafficPolicy
  • Most production uses Routes/Ingress instead
OpenShift Enhancement

OVN-Kubernetes Architecture

The Engine Behind OpenShift Networking

⚙️ What is OVN-Kubernetes?

  • Open Virtual Network (OVN)
    Software-defined networking solution
  • Replaces kube-proxy
    Better performance at scale
  • Default in OpenShift 4.x
    Production-tested and supported

✨ Key Advantages

  • OVS flows instead of iptables (faster)
  • Native NetworkPolicy enforcement
  • EgressIP, EgressFirewall, Multicast support
Security

Network Policies

Microsegmentation for Kubernetes

🔒 What are NetworkPolicies?

  • Firewall rules for pods
    Control ingress/egress at pod level
  • Label-based selection
    Dynamic, not IP-based
  • Default-allow becomes default-deny
    Once applied, explicit rules required

🎯 Common Use Cases

  • Isolate namespaces from each other
  • Restrict database access to specific apps
  • Block egress to internet except for specific services
Enterprise Integration

Egress IP Configuration

Stable Source IPs for External Systems

🌐 The Egress IP Problem

  • Default behavior: Pods egress using node IP
    Changes if pod moves to different node
  • External systems require IP whitelisting
    Databases, APIs, legacy systems
  • Compliance requirements
    Audit trails need stable source IPs

✅ EgressIP Solution

  • Assign stable IP to namespace or specific pods
  • Automatically moves with pod (HA)
  • Requires coordination with network team
Putting It All Together

Complete Traffic Flow

External Client to Pod and Back

🔄 The Journey of a Request

  • 1. External Client → Route (Ingress)
    DNS resolves to OpenShift router
  • 2. Router → Service VIP
    HAProxy forwards to backend service
  • 3. Service VIP → Pod IP
    OVN-K load balances to pod
  • 4. Pod → External System (Egress)
    Uses EgressIP if configured

🛡️ Security Layers Applied

  • NetworkPolicy enforcement at pod boundaries
  • TLS termination at router (optional)
Planning & Architecture

IP Address Pools

Understanding CIDR Allocation

📊 Default OpenShift IP Pools

  • Node Network: Your infrastructure
    Example: 10.0.0.0/16 (datacenter network)
  • Pod Network: 10.128.0.0/14
    Default provides 1,048,576 pod IPs
  • Service Network: 172.30.0.0/16
    65,536 service VIPs available

⚠️ Critical Planning Considerations

  • No overlap between networks or external systems
  • Size appropriately - cannot expand easily
  • Consider multi-cluster scenarios
Service Discovery

Service Types Comparison

Choosing the Right Service Type

🎯 Service Type Overview

  • ClusterIP (default): Internal only
    Most common for microservices
  • NodePort: Exposes on every node
    Good for testing, rarely used in prod
  • LoadBalancer: Cloud provider integration
    Or MetalLB for bare metal
  • Headless: No VIP, direct pod IPs
    For StatefulSets and client-side load balancing

🚀 OpenShift Addition: Routes

  • HTTP/HTTPS traffic with hostname-based routing
  • TLS termination and path-based routing
Advanced Topics

Service Mesh Layer

When Standard Networking Isn't Enough

🕸️ What is Service Mesh?

  • Sidecar proxies for every pod
    Intercepts all network traffic
  • mTLS everywhere
    Zero-trust security by default
  • Advanced traffic management
    Canary, A/B testing, circuit breaking

🤔 When Do You Need It?

  • 20+ microservices with complex communication
  • Zero-trust security requirements
  • Deep observability needed (not just logs)
External Access

NodePort Traffic Flow

How External Traffic Reaches Your Pods

🌐 NodePort Mechanics

  • Port range: 30000-32767
    Every node listens on the same port
  • External Client → Node IP:30080
    Traffic redirected to Service VIP internally
  • Service VIP → Pod IP
    Same load balancing as ClusterIP

⚡ Key Characteristics

  • Works on any node (even if pod not on that node)
  • Source IP preservation depends on externalTrafficPolicy
  • Most production uses Routes/Ingress instead
OpenShift Enhancement

OVN-Kubernetes Architecture

The Engine Behind OpenShift Networking

⚙️ What is OVN-Kubernetes?

  • Open Virtual Network (OVN)
    Software-defined networking solution
  • Replaces kube-proxy
    Better performance at scale
  • Default in OpenShift 4.x
    Production-tested and supported

✨ Key Advantages

  • OVS flows instead of iptables (faster)
  • Native NetworkPolicy enforcement
  • EgressIP, EgressFirewall, Multicast support
Security

Network Policies

Microsegmentation for Kubernetes

🔒 What are NetworkPolicies?

  • Firewall rules for pods
    Control ingress/egress at pod level
  • Label-based selection
    Dynamic, not IP-based
  • Default-allow becomes default-deny
    Once applied, explicit rules required

🎯 Common Use Cases

  • Isolate namespaces from each other
  • Restrict database access to specific apps
  • Block egress to internet except for specific services
Enterprise Integration

Egress IP Configuration

Stable Source IPs for External Systems

🌐 The Egress IP Problem

  • Default behavior: Pods egress using node IP
    Changes if pod moves to different node
  • External systems require IP whitelisting
    Databases, APIs, legacy systems
  • Compliance requirements
    Audit trails need stable source IPs

✅ EgressIP Solution

  • Assign stable IP to namespace or specific pods
  • Automatically moves with pod (HA)
  • Requires coordination with network team
Putting It All Together

Complete Traffic Flow

External Client to Pod and Back

🔄 The Journey of a Request

  • 1. External Client → Route (Ingress)
    DNS resolves to OpenShift router
  • 2. Router → Service VIP
    HAProxy forwards to backend service
  • 3. Service VIP → Pod IP
    OVN-K load balances to pod
  • 4. Pod → External System (Egress)
    Uses EgressIP if configured

🛡️ Security Layers Applied

  • NetworkPolicy enforcement at pod boundaries
  • TLS termination at router (optional)
Planning & Architecture

IP Address Pools

Understanding CIDR Allocation

📊 Default OpenShift IP Pools

  • Node Network: Your infrastructure
    Example: 10.0.0.0/16 (datacenter network)
  • Pod Network: 10.128.0.0/14
    Default provides 1,048,576 pod IPs
  • Service Network: 172.30.0.0/16
    65,536 service VIPs available

⚠️ Critical Planning Considerations

  • No overlap between networks or external systems
  • Size appropriately - cannot expand easily
  • Consider multi-cluster scenarios
Service Discovery

Service Types Comparison

Choosing the Right Service Type

🎯 Service Type Overview

  • ClusterIP (default): Internal only
    Most common for microservices
  • NodePort: Exposes on every node
    Good for testing, rarely used in prod
  • LoadBalancer: Cloud provider integration
    Or MetalLB for bare metal
  • Headless: No VIP, direct pod IPs
    For StatefulSets and client-side load balancing

🚀 OpenShift Addition: Routes

  • HTTP/HTTPS traffic with hostname-based routing
  • TLS termination and path-based routing
Advanced Topics

Service Mesh Layer

When Standard Networking Isn't Enough

🕸️ What is Service Mesh?

  • Sidecar proxies for every pod
    Intercepts all network traffic
  • mTLS everywhere
    Zero-trust security by default
  • Advanced traffic management
    Canary, A/B testing, circuit breaking

🤔 When Do You Need It?

  • 20+ microservices with complex communication
  • Zero-trust security requirements
  • Deep observability needed (not just logs)
Stateful Applications

Headless Services

DNS-Based Pod Discovery

🎯 What Are Headless Services?

  • No ClusterIP assigned
    ClusterIP: None in the manifest
  • DNS returns individual pod IPs
    Not a single VIP
  • Used with StatefulSets
    Each pod gets stable hostname

💾 Common Use Cases

  • Databases with replication (MongoDB, Cassandra)
  • Clustered applications (Kafka, Elasticsearch)
  • Client-side load balancing scenarios
Hands-On Demonstrations

Live Demos

See It In Action

🔒 Demo 1: NetworkPolicy Enforcement

  • Create two namespaces with pods
  • Show open communication (default)
  • Apply policy to block cross-namespace traffic
  • Add targeted allow rule

🌐 Demo 2: EgressIP Configuration

  • Show default egress (uses node IP)
  • Apply EgressIP configuration
  • Demonstrate stable external source IP

🔄 Demo 3: Service Discovery

  • Deploy multi-replica app with ClusterIP service
  • Show DNS resolution and load balancing
$ oc apply -f networkpolicy.yaml
networkpolicy.created
 
$ oc get pods
NAME READY STATUS
frontend-1 1/1 Running
 
$ oc logs frontend-1
▶️
External Access

Routes and Ingress

Application-Layer Traffic Management

🚪 OpenShift Routes

  • HTTP/HTTPS with hostname-based routing
    myapp.apps.cluster.example.com
  • HAProxy router pods
    Runs on infrastructure nodes
  • TLS termination options
    Edge, passthrough, re-encrypt

🎯 Advanced Features

  • Path-based routing (/api, /admin)
  • Blue-green deployments with traffic splitting
  • Rate limiting and custom annotations
🪧
Route Selector
↑
/api
API Service
←
/web
Web Service
→
/admin
Admin Service
🔒
TLS Enabled
Practical Skills

Troubleshooting Network Issues

Essential Commands and Techniques

🔍 Common Issues

  • Pod can't reach service
    Check NetworkPolicy, DNS, endpoints
  • External traffic not reaching pod
    Route config, service exists, pod ready
  • EgressIP not working
    Node labels, IP availability

🛠️ Essential Commands

  • oc get svc,endpoints - Check service mapping
  • oc get networkpolicy -A - View all policies
  • oc debug node/<node> - Node-level debugging
  • oc run netshoot --image=nicolaka/netshoot - Network tools
$ oc get pods -n myapp
NAME READY STATUS
frontend-1 1/1 Running
backend-1 0/1 CrashLoopBackOff
$ oc logs backend-1
Error: Connection refused
$ oc describe pod backend-1
Events: Failed to pull image
🔍
Hands-On Demonstrations

Live Demos

See It In Action

🔒 Demo 1: NetworkPolicy Enforcement

  • Create two namespaces with pods
  • Show open communication (default)
  • Apply policy to block cross-namespace traffic
  • Add targeted allow rule

🌐 Demo 2: EgressIP Configuration

  • Show default egress (uses node IP)
  • Apply EgressIP configuration
  • Demonstrate stable external source IP

🔄 Demo 3: Service Discovery

  • Deploy multi-replica app with ClusterIP service
  • Show DNS resolution and load balancing
$ oc apply -f networkpolicy.yaml
networkpolicy.created
 
$ oc get pods
NAME READY STATUS
frontend-1 1/1 Running
 
$ oc logs frontend-1
▶️
External Access

Routes and Ingress

Application-Layer Traffic Management

🚪 OpenShift Routes

  • HTTP/HTTPS with hostname-based routing
    myapp.apps.cluster.example.com
  • HAProxy router pods
    Runs on infrastructure nodes
  • TLS termination options
    Edge, passthrough, re-encrypt

🎯 Advanced Features

  • Path-based routing (/api, /admin)
  • Blue-green deployments with traffic splitting
  • Rate limiting and custom annotations
Practical Skills

Troubleshooting Network Issues

Essential Commands and Techniques

🔍 Common Issues

  • Pod can't reach service
    Check NetworkPolicy, DNS, endpoints
  • External traffic not reaching pod
    Route config, service exists, pod ready
  • EgressIP not working
    Node labels, IP availability

🛠️ Essential Commands

  • oc get svc,endpoints - Check service mapping
  • oc get networkpolicy -A - View all policies
  • oc debug node/<node> - Node-level debugging
  • oc run netshoot --image=nicolaka/netshoot - Network tools
$ oc get pods -n myapp
NAME READY STATUS
frontend-1 1/1 Running
backend-1 0/1 CrashLoopBackOff
$ oc logs backend-1
Error: Connection refused
$ oc describe pod backend-1
Events: Failed to pull image
🔍
Summary

Key Takeaways

What to Remember

🧠 Mental Model

  • Three networks, three purposes
    Node (infrastructure), Pod (application), Service (abstraction)
  • Pods are ephemeral → Never hardcode pod IPs
  • Services provide stability → Always use for discovery

🎯 Decision Framework

  • NetworkPolicy: Production clusters, multi-tenant, regulated environments
  • EgressIP: External systems require IP whitelisting
  • Service Mesh: 20+ microservices, zero-trust, advanced traffic mgmt

⚠️ Common Pitfalls

  • Overlapping CIDRs
  • Too-small pod CIDR
  • Untested NetworkPolicies
🧠
✓
3 Networks
✓
Security
✓
Routing
Next Steps

Resources & Next Steps

📚 Official Documentation

🎓 Learning Paths

🚀 Action Items

  • Try demos in your cluster
  • Create NetworkPolicies for your apps
  • Plan EgressIP strategy with network team
📚
Docs
🎓
Training
💪
Practice
🚀
Press P for Presenter Mode

Navigate to Slide

Press 'N' to toggle speaker notes

⌨️ Keyboard Shortcuts

Next Slide / Reveal Bullet → or Space
Previous Slide ← or Backspace
Toggle Speaker Notes N
Expand Diagram D
Fullscreen F
Print / PDF Export Ctrl+P / ⌘+P
Close This Help Esc or ?
Diagram View

Choose a Demo

Select an interactive demonstration
🔒
Network Policy Enforcement
Block pod traffic with deny-all policy
🌐
Egress IP Configuration
Configure stable external source IP
🔄
Service Discovery
DNS resolution and load balancing
Demo