Kubernetes networking and storage architecture is the design that determines how Pods communicate, how traffic enters a cluster, and how application state survives workload replacement.
For small teams, the important decision is not which Kubernetes primitive exists; it is which layer owns each responsibility. Raff separates these concerns clearly: every managed Kubernetes cluster runs inside private networking, public traffic enters through deliberate service paths, and persistent storage is attached independently from the lifecycle of an individual Pod. That separation matters because a workload can be private but still lose state, or persistent but still be exposed through the wrong network path.
Kubernetes itself treats networking and storage as distinct systems. Pods receive network identities and communicate through Services and cluster networking, while PersistentVolumes and StorageClasses give state a lifecycle beyond one container or Pod. This guide maps those layers into one production architecture and shows where VPC boundaries, Services, ingress, NetworkPolicy, PersistentVolumes, storage classes, and backups fit together.
Kubernetes networking separates reachability from exposure
Kubernetes networking starts from a simple operating assumption: workloads should be able to communicate without operators manually wiring addresses between individual containers.
The useful mental model has four traffic layers:
External client ↓ Public entry / ingress ↓ Kubernetes Service ↓ Pod network ↓ Application containers
Each layer solves a different problem.
Pod networking gives each Pod an addressable network identity inside the cluster. Containers within the same Pod share the Pod network namespace, while communication between Pods is handled by the cluster network implementation.
Services provide a stable network identity in front of a changing set of Pods. Pods can be replaced, rescheduled, or scaled while clients continue to use the Service rather than tracking individual Pod addresses.
Ingress or another application-routing layer decides how HTTP or HTTPS traffic reaches one or more Services. It is a traffic-routing concern, not a replacement for Service discovery or private network design.
The cloud network boundary decides where worker nodes and cluster endpoints sit relative to the public internet and other private infrastructure.
A Kubernetes Service therefore gives a stable network identity to a changing set of Pods; it does not make those Pods stateful or automatically secure every traffic path.
Official Kubernetes documentation describes cluster networking as several related problems: container-to-container communication, Pod-to-Pod communication, Pod-to-Service communication, and external-to-Service communication. Keeping those paths separate makes troubleshooting and architecture review much easier than treating “Kubernetes networking” as one feature.
At Raff, the infrastructure rule is to draw the traffic path and the state path separately before choosing Kubernetes primitives. Services and ingress determine how requests reach workloads; PersistentVolumes and backups determine what survives replacement.
Private cloud networking and Kubernetes networking solve different layers
A VPC and a Kubernetes Pod network are related but they are not interchangeable.
A cloud VPC defines the private infrastructure boundary around nodes and adjacent cloud resources. Kubernetes networking defines communication between Pods, Services, and workload endpoints inside that infrastructure.
A simplified production layout looks like this:
Internet ↓ Managed/public cluster endpoint ↓ Private VPC ├── worker node A │ ├── Pod │ └── Pod ├── worker node B │ ├── Pod │ └── Pod └── private cloud services Inside Kubernetes Services → selected Pods NetworkPolicy → allowed Pod traffic
This layered model prevents two common mistakes.
The first is assuming that private worker networking means every workload is automatically isolated from every other workload. Pods inside the same cluster may still communicate according to the cluster network and policy model.
The second is assuming that Kubernetes NetworkPolicy replaces infrastructure controls. NetworkPolicy is a Kubernetes API for controlling allowed traffic between Pods and between Pods and external endpoints when the cluster networking implementation supports enforcement. VPC boundaries and cloud firewalls operate at a different layer.
A useful production design therefore combines:
- private infrastructure networking for nodes and adjacent services
- Kubernetes Services for stable workload discovery
- a deliberate ingress or public-service path for external traffic
- NetworkPolicy where workload-to-workload restrictions are required
- application authentication and authorization above the network layer
This layered approach is more resilient than asking one control to solve every networking problem.
Services and ingress should reflect the intended traffic path
The number of Services in a cluster is not the architecture. The architecture is the set of traffic paths the application intentionally exposes.
For each workload, decide whether it is:
- public to internet clients
- private to other workloads in the same cluster
- private to infrastructure outside the cluster
- reachable only by an administrative path
A typical SaaS application might use:
Internet ↓ Ingress / public entry ↓ web Service ↓ web Pods ↓ private API Service ↓ API Pods ↓ managed database or persistent state
The worker, scheduler, cache, and internal API usually do not need their own public endpoints simply because Kubernetes makes Service creation easy.
This distinction becomes especially important when teams move from Docker Compose. Compose often begins with service names on one host network. Kubernetes introduces a separate Service abstraction because Pods are disposable and may move between nodes.
For teams making that transition, Docker Compose to Managed Kubernetes Migration Checklist covers the broader migration boundary. The networking design should preserve the intended application relationships rather than mechanically exposing every Compose port in Kubernetes.
Persistent storage separates data lifetime from Pod lifetime
Kubernetes is designed around replaceable workloads. Stateful applications need storage whose lifecycle is not tied to one container or Pod.
The core relationship is:
Application Pod ↓ requests storage through PersistentVolumeClaim (PVC) ↓ binds to PersistentVolume (PV) ↓ provisioned according to StorageClass / storage implementation
A PersistentVolumeClaim expresses the workload's storage request. A PersistentVolume represents storage available to the cluster. A StorageClass describes how storage is provisioned and may define characteristics such as the underlying storage type or lifecycle behavior.
This abstraction is valuable because the application can be rescheduled while its storage remains a separate resource.
But persistence is not backup.
A PersistentVolume can protect data from ordinary Pod replacement while still being vulnerable to application corruption, accidental deletion, destructive schema changes, compromised credentials, or failures that affect the storage itself. PersistentVolumes solve storage attachment and lifecycle, not application-consistent backup.
That means stateful architecture needs at least three separate questions:
- What state must survive Pod replacement?
- What state must survive storage loss or operator error?
- How will that state be restored into a working application?
The answer to the first question is usually persistent storage. The answers to the second and third are a backup and recovery design.
Storage location should follow the type of application state
Not all application data belongs on a Kubernetes PersistentVolume.
A production architecture is easier to operate when state is classified before storage is selected.
| State type | Typical location | Why |
|---|---|---|
| Container image | Container registry | Immutable deployment artifact |
| Application code | Image or build artifact | Replaceable with the workload |
| Database records | Managed database or purpose-built database storage | Needs consistency, backups, and controlled recovery |
| Shared customer uploads | Object storage in many architectures | Decouples files from one Pod or node |
| Filesystem-dependent application data | PersistentVolume | Requires mounted durable filesystem semantics |
| Cache data | Cache service or disposable storage | Often rebuildable |
| Logs/metrics | Observability system | Should outlive individual Pods when operationally important |
| Backup archives | Separate recovery destination | Must not share the exact same failure path as live state |
The best Kubernetes storage architecture often uses less cluster-mounted state, not more.
A stateless web/API tier backed by managed databases and object storage is usually easier to scale and replace than a cluster where every workload carries local persistent data. PersistentVolumes remain important for software that genuinely requires durable mounted filesystems, but they should be selected because the application needs those semantics rather than because a volume is available.
For the broader file-placement decision, App Uploads: VM Disk vs Object Storage explains why durable user uploads are often better separated from the application server lifecycle.
The decision framework aligns networking, state, and recovery
The central architecture decision is to classify each workload by traffic exposure and state responsibility.
| Workload characteristic | Networking choice | Storage choice | Recovery implication |
|---|---|---|---|
| Public stateless web/API | Public ingress → Service → Pods | Usually no persistent app volume | Redeploy application; restore external data services separately |
| Private stateless API/worker | Private Service or no public Service | Usually no persistent app volume | Redeploy application |
| Stateful service needing mounted filesystem | Private/public Service as required | PVC/PV via StorageClass | Back up application state and test restore |
| Database | Prefer managed DB when operationally appropriate; otherwise tightly restricted Service | Purpose-built persistent storage | Database-consistent backups and restore testing |
| Shared customer files | Application access path only | Object storage often preferred | Object-versioning/backup policy appropriate to data |
| Cache | Private Service | Disposable or service-managed persistence depending design | Usually rebuild, unless persistence is intentionally required |
Use this sequence when reviewing an architecture:
Choose a public traffic path only when a workload actually needs one. A worker or database should not gain a public endpoint merely for convenience.
Use a stable Service when clients must find changing Pods. Do not encode Pod addresses into application configuration.
Use NetworkPolicy for workload traffic restrictions, not as a substitute for VPC or application security. Enforcement depends on the cluster networking implementation.
Use a PersistentVolume when the application genuinely needs mounted durable filesystem state. Do not make a workload stateful simply because a PVC is easy to create.
Treat backup as a separate recovery system. A healthy PVC is not proof that yesterday's application state can be restored.
One useful number for planning is the cost of durable storage itself. Raff Kubernetes currently prices cluster storage at $0.08/GB-month, so 100 GB of provisioned cluster storage represents an $8/month storage line before application-level backup or database services are considered.
Raff maps the architecture to private networking and persistent storage
Raff managed Kubernetes is designed around the same separation between traffic, compute, and state.
Each Raff Kubernetes cluster operates with private networking for the cluster infrastructure and a managed public endpoint for traffic that should be exposed. Public Kubernetes egress is priced at $0, with unmetered public bandwidth up to 3 Gbps, while private VPC networking provides the infrastructure boundary around cluster resources.
Persistent Kubernetes storage is priced at $0.08/GB-month. That storage is independent of a single Pod's lifecycle, which is the correct foundation for workloads that require mounted state. Teams should still define backup and restore procedures for business-critical data because storage persistence and recoverability are separate requirements.
Raff also exposes VPC and Volumes as separate cloud products. That distinction matters architecturally: Kubernetes networking should not be treated as the only private-network layer in a system, and Kubernetes volumes should not be treated as the only durable-data service available to an application.
For small teams, the useful Raff pattern is:
Public traffic ↓ Managed cluster endpoint ↓ Private Raff VPC ↓ Services and Pods ├── stateless application tiers ├── PVC/PV where mounted state is required └── external managed data/object services where appropriate
Raff currently reports more than 15,000 VMs across the platform and publishes a 99.9% uptime SLA. Those platform signals do not change the workload responsibility boundary: replica design, traffic policy, application health, persistent state, backups, and restore testing remain part of the production architecture.
Production architecture keeps traffic and state failure domains explicit
A Kubernetes design becomes easier to reason about when every important dependency has an explicit failure domain.
Ask what happens when:
- one Pod disappears
- one worker node disappears
- a Service selector is wrong
- ingress configuration sends traffic to the wrong workload
- a NetworkPolicy blocks a dependency
- a volume is detached or unavailable
- application data is deleted logically while storage remains healthy
- a database migration corrupts data
- the cluster must be recreated
The answers should not all be “Kubernetes will handle it.” Kubernetes handles scheduling, reconciliation, service discovery, and resource lifecycle within its configured model. It cannot infer which business data is recoverable, which clients should reach a service, or which restore point is correct.
A useful production review therefore separates four planes:
- Reachability — Pods, Services, DNS, and cluster networking.
- Exposure — ingress, public endpoints, VPC boundaries, and policy.
- Persistence — PersistentVolumes, managed databases, and object storage.
- Recovery — backups, retention, restore procedures, and rollback ownership.
If any one of these planes exists only as an assumption, the architecture has an operational gap.
Kubernetes networking and storage work best as separate design decisions
Kubernetes networking and storage should be designed together, but not collapsed into one concern. Networking decides who can reach a workload and through which path. Storage decides what survives workload replacement. Recovery decides whether important state can be restored after corruption, deletion, or infrastructure loss.
For a small production cluster, start by keeping worker infrastructure private, exposing only required application paths, using Services for stable workload identity, and attaching persistent storage only where filesystem state is genuinely needed. Then design backup and recovery independently from Pod and volume lifecycle.
Continue with Kubernetes Cluster Sizing for worker-capacity planning and Kubernetes Node Pools for placement and scaling boundaries.