GlossaryStorage

Storage

Kubernetes storage is the set of mechanisms, such as volumes, PersistentVolumes, and StorageClasses, that keep data available beyond the lifecycle of an individual pod or container.

Table of Contents

Table of Contents

Further Reading

No items found.
No items found.
No items found.
No items found.
No items found.
No items found.

How Kubernetes storage works

Containers are ephemeral, so anything written inside them disappears when they stop. Kubernetes storage provides places for data to survive.

It is the foundation for stateful applications and for testing workflows that need to keep results.

  1. An administrator defines StorageClasses for different storage types.
  2. A workload requests storage with a PersistentVolumeClaim.
  3. Kubernetes provisions or binds a matching PersistentVolume.
  4. Pods mount the volume and read or write data.
  5. Data stays on the volume after the pod ends.

Common types of Kubernetes storage

Each type fits a different need.

Type What it is Lifespan
EmptyDir Scratch space for a pod Deleted when the pod stops
PersistentVolume (PV) Cluster-level storage resource Independent of pods
PersistentVolumeClaim (PVC) A workload’s request for storage Until the claim is deleted
StorageClass Defines storage tiers and provisioning Cluster configuration
ConfigMap and Secret Configuration and sensitive data Until deleted

Why storage matters for testing

Test pods are short-lived by design. Without persistent storage, logs, screenshots, and reports vanish as soon as a run ends.

  • Traceability: keep a full history of executions
  • Debugging: review artifacts after pods are gone
  • Trend analysis: compare results across runs
  • Collaboration: distributed teams share the same results
  • Compliance: retain evidence for audits

Consider a SaaS team whose end-to-end tests fail overnight. With stored screenshots and logs, the morning shift sees exactly what broke without rerunning anything.

Common challenges with storage

  • Cost: large artifacts grow storage bills
  • Performance: slow storage can lengthen test runs
  • Retention: old data piles up without cleanup policies
  • Access control: sensitive test data needs protection
  • Portability: storage classes differ between clouds

How storage relates to Testkube

Testkube stores test artifacts, logs, and reports so teams can analyze outcomes after pods are terminated.

  • Complete history: every execution kept for comparison over time
  • Central access: artifacts available in the dashboard, CLI, and API
  • Storage choice: works with your cluster’s storage classes
  • Cloud storage: runs on AWS, Google Cloud, and Azure storage options
  • Retention policies: cleanup rules control how long data is kept

Frequently Asked Questions (FAQs)

What kind of data does Testkube store?

Logs, test outputs, execution metadata, and artifacts such as screenshots and reports.

Can I use my own storage class with Testkube?

Yes. Testkube can use the storage classes that match your Kubernetes storage policies.

Does Testkube delete stored test data automatically?

It depends on configuration. Cleanup policies can remove old data on a schedule.

How can I access stored test artifacts?

Through the Testkube dashboard, CLI, or API after each run.

What happens without persistent storage?

Artifacts and logs are lost when pods are deleted, which makes debugging and trend analysis hard.

How does storage affect test performance?

Slow storage can lengthen runs that write large artifacts. Use storage classes with enough throughput.

Related Terms and Concepts

No items found.