Networking

Networking is a core part of how Kubernetes workloads communicate, both internally and externally.

In KubeRaya, Kubernetes networking follows standard Kubernetes behavior while being handled by the CloudRaya platform. This provides predictable traffic flow, clear isolation, and explicit control over service exposure.

This guide explains how networking works inside a Kubernetes cluster in KubeRaya, how services are exposed, and what you should understand before deploying applications.

Kubernetes Networking Model in KubeRaya

Each Kubernetes cluster in KubeRaya operates within its own cluster network boundary, managed by the platform.

Key Characteristics

• Kubernetes clusters use platform-managed networking
• Worker nodes use private connectivity
• Pod-to-pod communication follows Kubernetes networking rules
• Public exposure is explicit, never automatic
• Traffic flow is controlled by Kubernetes service definitions

This model aligns with standard Kubernetes expectations while abstracting underlying infrastructure details from users.

Core Networking Components

Understanding these components helps you reason about traffic flow inside the cluster.

Nodes

• Nodes are Virtual Machines
• Nodes provide compute capacity for workloads
• Nodes communicate using private connectivity managed by the platform

Pods

• Pods receive internal cluster IP addresses
• Pods can communicate with each other inside the cluster
• Pod IPs are not intended for direct external access

Services

Services define how traffic reaches pods. They provide stable endpoints and load balancing even when pods are recreated or rescheduled.

Service Types and Traffic Exposure

KubeRaya supports standard Kubernetes service types.

ClusterIP (Internal Only)

• Default service type
• Accessible only inside the cluster
• Commonly used for:
  • Internal APIs
  • Backend services
  • Databases

This is the recommended option when no external access is required.

NodePort

• Exposes a service through a port on each node

• Accessible via:

  NodeIP:NodePort

• Mainly used for:

  • Testing
  • Debugging
  • Temporary access

NodePort is not recommended for production external exposure.

LoadBalancer (External Access)

• Exposes services externally using Kubernetes-native load balancing
• Defined using standard Kubernetes Service objects
• Designed for production workloads

Public access exists only when you explicitly define a LoadBalancer service.

How External Traffic Flows

A typical external traffic flow looks like this:

Internet
  ↓
Kubernetes Service(Load Balancer)
  ↓
Worker Nodes
  ↓
Pods

CloudRaya handles the underlying infrastructure integration, while Kubernetes controls routing and service behavior.

Network Isolation and Security

Kubernetes networking is isolated by design.

Default Isolation

• Pods communicate only as defined by Kubernetes services
• No public access unless explicitly configured
• Clusters are isolated from each other

Recommended Security Practices

• Use ClusterIP for internal services
• Expose only required services
• Avoid NodePort for production access
• Combine Kubernetes networking with:
  • Strong service design
  • Proper access controls
  • VPN access when secure remote access is required

📄 See: Kubernetes Security Basics

DNS and Service Discovery

Kubernetes provides built-in DNS for service discovery.

• Services are reachable by name
• No need to track pod IPs
• Enables loosely coupled microservices

Example:

http://my-service.my-namespace.svc.cluster.local

This works automatically inside the cluster.

When to Expose Services

You should expose services externally only when:

• The service is intended for public access
• Security boundaries are clearly defined
• You understand the traffic flow and impact

For most workloads:

• Internal APIs → ClusterIP
• Public APIs → LoadBalancer

📄 See: Expose Services in Kubernetes

Related Guides

📄 Kubernetes Overview

📄 Cluster Architecture & Concepts

📄 Expose Services in Kubernetes

📄 Kubernetes Security Basics

📄 Kubernetes Best Practices