Architecture & Concepts
This page explains the core architecture and foundational concepts of Kubernetes clusters in KubeRaya.
Understanding these concepts will help you design clusters correctly, troubleshoot issues faster, and make informed decisions when deploying workloads.
This page focuses on how components are structured and how they behave, not step-by-step actions.
High-Level Architecture Overview
Each Kubernetes cluster in KubeRaya is:
- Deployed within a single Cloud Zone (region)
- Operated using a fully managed control plane
- Backed by Virtual Machine–based worker nodes
- Integrated with CloudRaya infrastructure through platform-managed networking
CloudRaya follows standard Kubernetes architecture principles while abstracting infrastructure and networking complexity from users.
Core Cluster Components
Managed Control Plane
The Kubernetes control plane (master node) is fully managed by CloudRaya.
It is responsible for:
- Cluster state management
- Scheduling workloads
- API server operations
- Maintaining cluster health
Users do not need to install, patch, or manage control plane components.
This reduces operational overhead while preserving standard Kubernetes behavior.
Worker Nodes
Worker nodes are Virtual Machines that run your container workloads.
Each worker node:
- Belongs to a specific Kubernetes cluster
- Runs Kubernetes node components
- Hosts Pods and containers
- Uses platform-managed private networking
You are responsible for:
- Choosing node size and capacity
- Scaling worker nodes
- Managing workloads running on nodes
Platform-Managed Networking
Kubernetes clusters in KubeRaya use platform-managed networking, which is separate from user-managed VPC networking.
This networking model:
- Is handled internally by the CloudRaya platform
- Provides private communication between cluster components
- Is abstracted from direct user configuration
- Does not require VPC or subnet management
This ensures consistent behavior while reducing networking complexity for users.
Kubernetes-Native Load Balancing
KubeRaya uses Kubernetes-native service mechanisms.
Services are exposed using standard Kubernetes Service objects.
Important clarifications:
- Kubernetes services do not use CloudRaya VM Load Balancers
- Load balancing behavior follows Kubernetes specifications
- Public IPs are provisioned only when required by Kubernetes services
This preserves portability and avoids vendor-specific coupling.
Cluster Scope and Isolation
Each Kubernetes cluster is isolated by design:
- Clusters do not share worker nodes
- Clusters do not share control planes
- Clusters do not communicate unless explicitly configured
Isolation occurs at:
- Infrastructure level
- Networking level
- Kubernetes control plane level
This makes clusters suitable for production, staging, and development environments.
Networking Behavior Overview
Kubernetes networking in KubeRaya follows standard Kubernetes expectations:
- Pods communicate using internal cluster networking
- Nodes communicate using private connectivity
- External traffic is opt-in, not automatic
Common exposure methods include:
- Internal services (
ClusterIP) - Node-based access (
NodePort) - External services (
LoadBalancer)
Designing service exposure remains an important responsibility of the user.
Security Responsibilities
Security in Kubernetes follows a shared responsibility model.
CloudRaya Responsibilities
- Control plane availability
- Infrastructure isolation
- Platform-level network enforcement
User Responsibilities
- Namespace and workload design
- RBAC configuration
- Service exposure decisions
- Application-level security controls
This model aligns with common cloud provider and Kubernetes best practices.
What This Architecture Enables
This architecture allows you to:
- Deploy standard Kubernetes workloads
- Scale applications predictably
- Integrate with CI/CD pipelines
- Maintain strong isolation between environments
- Avoid infrastructure lock-in
It also ensures compatibility with common Kubernetes tools and practices.
Related Guides
📄 Kubernetes Networking Basics