K8S - Important Reference Articles on this Blog

The following articles provide a neat and concise reference for creating YAML files for some of the most commonly used Kubernetes resources.

What makes these references particularly useful is that they focus exclusively on the essential YAML elements required for each resource, presented in a compact tabular format that is easy to understand and quick to use during day-to-day Kubernetes administration and development.

Why These References Are Useful

• Quick lookup for Kubernetes YAML structure.
• Focuses only on important fields and attributes.
• Easy to use during interviews, certification preparation, and production work.
• Avoids lengthy official documentation when you only need a YAML reference.
• Provides concise information that is difficult to find in a single place elsewhere on the internet.

Available Kubernetes YAML References

Reference Article	Link
K8S Reference - StatefulSet YAML	Open Article
K8S Reference - Service YAML	Open Article
K8S Reference - PersistentVolumeClaim (PVC) YAML	Open Article
K8S Reference - StorageClass YAML	Open Article
K8S Reference - PersistentVolume (PV) YAML	Open Article

Recommended Reading Order

1. StorageClass YAML
2. PersistentVolume (PV) YAML
3. PersistentVolumeClaim (PVC) YAML
4. Service YAML
5. StatefulSet YAML

This sequence helps build a complete understanding of how storage and networking components work together inside a stateful Kubernetes application.

K8S Reference - StatefulSet YAML

The table below summarizes all important elements used when defining a Kubernetes StatefulSet. Unlike Deployments, StatefulSets provide stable network identities, persistent storage, and ordered deployment behavior, making them ideal for databases and other stateful applications.

Element	Required / Optional	Description	Example Syntax
apiVersion	Required	The API group and version for workloads. For StatefulSets, this is apps/v1.	apiVersion: apps/v1
kind	Required	Defines the resource type.	kind: StatefulSet
metadata.name	Required	The unique name of the StatefulSet controller.	name: mysql
spec.serviceName	Required	The name of the Headless Service that manages the stable DNS and network identity of the StatefulSet Pods.	serviceName: "my-db-service"
spec.replicas	Optional	The number of desired Pod instances. Defaults to 1.	replicas: 3
spec.selector	Required	Tells the StatefulSet controller which Pods it owns and should manage. The selector must exactly match the labels defined inside template.metadata.labels.	selector: matchLabels: app: my-database
spec.template	Required	The Pod blueprint used to create each StatefulSet Pod. This contains labels, container definitions, images, environment variables, ports, volumes, and all standard Pod settings.	Standard Pod spec structure
spec.volumeClaimTemplates	Optional (Highly Recommended)	An array of mini-PVC definitions. Instead of sharing one volume, every Pod automatically receives its own dedicated PersistentVolumeClaim (for example: data-mysql-0, data-mysql-1, data-mysql-2).	volumeClaimTemplates: - metadata: name: data

Important: A StatefulSet almost always works together with a Headless Service and one or more PersistentVolumeClaims. These three components provide stable DNS names, persistent storage, and predictable Pod identities.

Example Pod Names Created:

mysql-0
mysql-1
mysql-2

K8S Reference - Service YAML

The table below summarizes all important elements used when defining a Kubernetes Service resource.

Element	Required / Optional	Description	Example Syntax
apiVersion	Required	The API group. For Services, this is always v1.	apiVersion: v1
kind	Required	Defines the resource type.	kind: Service
metadata.name	Required	The DNS name that other applications inside the cluster will use to talk to this service.	name: my-db-service
spec.ports	Required	A list of network ports to expose. Includes the port (the Service's port) and targetPort (the Pod's actual application port).	- port: 80 targetPort: 8080
spec.selector	Optional (Recommended)	A key-value label pair used to target which Pods receive traffic. Crucial for connecting the Service to your application.	selector: app: my-database
spec.type	Optional	Controls how the Service is exposed: ClusterIP (internal only), NodePort (exposes via host ports), or LoadBalancer (cloud provider external IP). Defaults to ClusterIP.	type: ClusterIP
spec.clusterIP	Optional	Can be set to None to create a Headless Service, which is strictly required when pairing with a StatefulSet to handle direct pod addressing.	clusterIP: None

Tip: The most commonly used Service types are ClusterIP, NodePort, and LoadBalancer. For StatefulSets, remember that a Headless Service (clusterIP: None) is typically required to provide stable network identities to Pods.

K8S Reference - PersistentVolumeClaim (PVC) YAML

A PersistentVolumeClaim (PVC) is a request for storage made by an application. Developers create PVCs instead of dealing directly with disks or storage infrastructure. Kubernetes then finds a matching PersistentVolume (PV) or dynamically provisions one using a StorageClass.

Element	Required / Optional	Description	Example Syntax
apiVersion	Required	Specifies the Kubernetes API version. For PVCs, this is always v1.	apiVersion: v1
kind	Required	Defines the Kubernetes resource type.	kind: PersistentVolumeClaim
metadata.name	Required	The unique name of the claim. Pods, Deployments, and StatefulSets reference this name when mounting storage.	name: my-app-claim
spec.accessModes	Required	Defines how the application intends to access the storage. The requested mode must be supported by the underlying PersistentVolume.	- ReadWriteOnce
spec.resources.requests.storage	Required	Specifies the minimum storage capacity required by the application.	storage: 10Gi
spec.storageClassName	Optional (Recommended)	References a specific StorageClass for dynamic provisioning or acts as a matching tag when binding to a static PersistentVolume.	storageClassName: manual
spec.volumeMode	Optional	Specifies whether the storage should be mounted as a traditional filesystem or exposed as a raw block device. Defaults to Filesystem.	volumeMode: Filesystem

PVC Binding Rule: Kubernetes will only bind a PVC to a PersistentVolume that satisfies all requested requirements, including storage size, accessModes, storageClassName, and volumeMode.

Relationship:

Pod → PVC → PV → Physical Storage

Applications consume storage through PVCs, while Kubernetes handles the mapping to actual disks or cloud storage resources.

K8S Reference - StorageClass YAML

A StorageClass defines how Kubernetes dynamically provisions storage volumes. Instead of manually creating PersistentVolumes, administrators create StorageClasses and allow PersistentVolumeClaims (PVCs) to automatically request storage from the underlying provider.

Element	Required / Optional	Description	Example Syntax
apiVersion	Required	Specifies the Kubernetes API group and version for StorageClass resources.	apiVersion: storage.k8s.io/v1
kind	Required	Defines the Kubernetes resource type.	kind: StorageClass
metadata.name	Required	Name of the StorageClass that application teams will reference inside their PVC manifests.	name: fast-ssd-storage
provisioner	Required	Specifies the storage plugin or CSI driver responsible for physically creating disks.	provisioner: ebs.csi.aws.com
parameters	Optional (Highly Recommended)	Vendor-specific configuration settings such as storage type, performance profile, IOPS limits, throughput, encryption settings, or filesystem choices.	parameters: type: gp3 iops: "3000"
volumeBindingMode	Optional (Recommended)	Controls when storage volumes are created and bound to claims. WaitForFirstConsumer is commonly preferred because it allows Kubernetes to choose storage in the same availability zone as the scheduled Pod.	volumeBindingMode: WaitForFirstConsumer
reclaimPolicy	Optional	Determines what happens to dynamically created storage when the PVC is deleted. Delete removes the underlying disk, while Retain preserves it for manual recovery.	reclaimPolicy: Delete
allowVolumeExpansion	Optional	Allows existing PersistentVolumeClaims to grow in size without deleting and recreating them.	allowVolumeExpansion: true

Best Practice: For cloud environments, use volumeBindingMode: WaitForFirstConsumer and allowVolumeExpansion: true. These settings improve scheduling flexibility and allow storage growth without disrupting applications.

K8S Reference - PersistentVolume (PV) YAML

The following table explains the major fields used when defining a PersistentVolume (PV) in Kubernetes.

Element	Required / Optional	Description	Example Syntax
apiVersion	Required	Specifies the Kubernetes API version. For PersistentVolumes, this is typically v1.	apiVersion: v1
kind	Required	Defines the Kubernetes resource type being created.	kind: PersistentVolume
metadata.name	Required	Unique name used to identify this PersistentVolume inside the cluster.	name: supavolume
spec.capacity.storage	Required	Total storage capacity exposed by this volume.	storage: 10Gi
spec.accessModes	Required	Determines how the storage can be mounted by nodes and Pods.	- ReadWriteOnce
spec.<storage-source>	Required	Defines the actual storage backend. Exactly one storage plugin must be chosen.	hostPath: path: "/mnt/data"
spec.storageClassName	Optional (Recommended)	Associates the PV with a particular StorageClass and enables PVC matching.	storageClassName: manual
spec.persistentVolumeReclaimPolicy	Optional (Recommended)	Controls what happens to the underlying storage after the PVC is deleted.	persistentVolumeReclaimPolicy: Retain
spec.volumeMode	Optional	Determines whether the volume is mounted as a filesystem or exposed as a raw block device.	volumeMode: Filesystem

Important: A PersistentVolume must define exactly one storage backend such as hostPath, nfs, csi, awsElasticBlockStore, azureDisk, or another supported storage plugin.

Kubernetes API Versions (apiVersion) and Common Resource Types

Every Kubernetes resource belongs to an API Group and API Version. The apiVersion field tells Kubernetes which API endpoint should process the resource definition.

Common Kubernetes API Versions

API Version	Common kind Values
v1	Pod, Service, PersistentVolume, PersistentVolumeClaim, ConfigMap, Secret, Namespace
apps/v1	Deployment, StatefulSet, DaemonSet, ReplicaSet
batch/v1	Job, CronJob
networking.k8s.io/v1	Ingress, NetworkPolicy
rbac.authorization.k8s.io/v1	Role, ClusterRole, RoleBinding
storage.k8s.io/v1	StorageClass
autoscaling/v2	HorizontalPodAutoscaler

Checking Supported API Versions

You can check all API versions supported by your Kubernetes cluster by running the following command:

kubectl api-versions

Sample Output

Below is an example response from a Kubernetes cluster:

admissionregistration.k8s.io/v1
apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apps/v1
authentication.k8s.io/v1
authorization.k8s.io/v1
autoscaling/v1
autoscaling/v2
batch/v1
certificates.k8s.io/v1
coordination.k8s.io/v1
discovery.k8s.io/v1
events.k8s.io/v1
flowcontrol.apiserver.k8s.io/v1
monitoring.coreos.com/v1
monitoring.coreos.com/v1alpha1
networking.k8s.io/v1
node.k8s.io/v1
policy/v1
rbac.authorization.k8s.io/v1
scheduling.k8s.io/v1
storage.k8s.io/v1
v1

Understanding API Groups

API Group	Purpose
v1	Core Kubernetes resources such as Pods, Services, ConfigMaps, and Secrets.
apps	Workload controllers such as Deployments, StatefulSets, and DaemonSets.
batch	Batch-processing resources such as Jobs and CronJobs.
networking.k8s.io	Networking resources such as Ingresses and NetworkPolicies.
rbac.authorization.k8s.io	Role-Based Access Control (RBAC) resources.
storage.k8s.io	Storage-related resources such as StorageClasses.
autoscaling	Auto-scaling resources such as HorizontalPodAutoscalers.

Practical Rule: When creating a Kubernetes manifest, always verify that the apiVersion you use exists in the output of kubectl api-versions. API versions may differ across Kubernetes releases, and older versions are eventually deprecated and removed.