Expose Services

By default, Kubernetes services are not accessible from the internet. This is intentional.

Kubernetes is designed to expose applications only when you explicitly choose to, using well-defined service types and networking constructs.

This guide explains how service exposure works in Kubernetes, when to use each method, and how this model fits within CloudRaya’s infrastructure.

What “Expose a Service” Means in Kubernetes

Exposing a service means making an application reachable beyond its pod network.

This can mean:

• Accessible by other services inside the cluster
• Accessible by nodes in the cluster
• Accessible from outside the cluster (public access)

Kubernetes provides multiple exposure levels, each with different security and networking implications.

Kubernetes Service Types Overview

Kubernetes exposes applications using Service objects.

The service type determines who can reach your application.

ClusterIP — Internal-Only Services (Default)

ClusterIP is the default service type.

Characteristics

• Accessible only inside the cluster
• Uses internal DNS (.svc.cluster.local)
• No public IP
• Most secure option

When to Use

• Backend APIs
• Databases
• Internal services
• Microservice-to-microservice communication

Example

apiVersion: v1
kind: Service
metadata:
  name: backend-api
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

Accessed internally as:

backend-api.default.svc.cluster.local

NodePort — Direct Node Exposure (Advanced / Limited Use)

NodePort exposes a service on a fixed port across all worker nodes.

Characteristics

• Accessible via <NodeIP>:<NodePort>
• Requires open firewall rules
• No traffic routing or TLS handling
• Harder to manage at scale

When to Use

• Testing or debugging
• Temporary access
• Non-production scenarios

When NOT to Use

• Production public services
• Applications requiring TLS
• Internet-facing workloads

LoadBalancer — External Access (KubeRaya)

LoadBalancer is the recommended way to expose public services in KubeRaya.

Important Clarification (CloudRaya-Specific)

• This is Kubernetes-native LoadBalancer
• NOT the CloudRaya VM Load Balancer service
• Provisioned automatically by Kubernetes integration

Characteristics

• Kubernetes requests an external IP
• Traffic is routed to backend pods
• Clean separation between infra and workloads
• Scales naturally with Kubernetes

Example

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Result:

• Kubernetes provisions an external IP
• Service becomes accessible publicly
• No manual IP attachment required

Ingress — HTTP/HTTPS Routing (Recommended for Web Apps)

Ingress provides layer-7 routing on top of LoadBalancer.

Characteristics

• Host-based routing
• Path-based routing
• TLS termination
• Multiple services behind one entry point

Typical Flow

Internet
  ↓
Ingress Controller (LoadBalancer)
  ↓
Service (ClusterIP)
  ↓
Pods

When to Use

• Websites
• APIs
• Multi-service applications
• Domain-based routing

Ingress is the preferred production pattern for web workloads.

Ingress & TLS Security

Ingress is typically used together with TLS to secure HTTP traffic.

To understand how to:

• Terminate HTTPS at the Ingress layer
• Use TLS certificates safely
• Avoid common Ingress security misconfigurations

📄 See: Ingress & TLS Security

Domain Names & Public Access

Internal Services

• Use Kubernetes DNS
• No domain purchase required
• .svc.cluster.local

Public Services

• Domain must be purchased separately
• DNS record points to:
  • LoadBalancer IP
  • Ingress IP

Example:

api.example.com → LoadBalancer IP → Ingress → Service → Pods

CloudRaya does not automatically provide public domains.

Security Considerations

Exposing a service means increasing its attack surface.

Best Practices

• Use ClusterIP by default
• Expose only what is necessary
• Prefer Ingress over NodePort
• Apply TLS for public endpoints
• Restrict access using:
  • Kubernetes RBAC
  • Network policies
  • Application-level authentication

Public access should always be intentional and controlled.

Common Exposure Patterns

Internal-Only Application

Pods → ClusterIP → Internal DNS

Public API

Internet → LoadBalancer → Service → Pods

Web Application

Internet → Ingress → Service → Pods

When to Expose a Service

Expose a service when:

• Users need public access
• External systems integrate with your app
• APIs must be reachable from outside

Do not expose services simply for convenience.

Related Guides

📄 Kubernetes Overview

📄 Networking in Kubernetes

📄 Ingress & TLS Security

📄 Cluster Architecture & Concepts

📄 Kubernetes Security Basics

📄 Kubernetes Best Practices