Native Kubernetes Resources: Everything You Need to Know
By Jun Nguyen7 min read1499 words

Native Kubernetes Resources: Everything You Need to Know

Technology
Kubernetes

If you’ve ever wondered “What resources come built into Kubernetes?” or found yourself confused about which resources require additional installations, you’re not alone. Let me walk you through every native Kubernetes resource that’s available right out of the box—no custom resource definitions (CRDs) or third-party extensions needed.

Why This Matters

Understanding native Kubernetes resources is crucial for several reasons:

  • You know what’s immediately available without installing anything extra
  • You can distinguish between core K8s features and add-ons (like ArgoCD’s ApplicationSet)
  • You build more portable applications that work across any standard Kubernetes cluster

So let’s dive in and explore the ~50+ built-in resources that Kubernetes provides.

The Core Resources: Where Everything Begins

The

v1
API group contains the foundational building blocks of Kubernetes. These are the resources you’ll interact with most frequently.

Workload Resources: Running Your Applications

At the heart of Kubernetes sits the Pod—the smallest deployable unit that contains one or more containers. Every application you run ultimately becomes a Pod. You’ll also find the legacy ReplicationController here, though it’s been superseded by Deployments (more on those later).

Service & Networking: Connecting Everything

Your applications need to talk to each other, and that’s where Services come in. They expose your Pods as network services through different types: ClusterIP for internal communication, NodePort for external access via node ports, and LoadBalancer for cloud-provided load balancers.

Behind the scenes, Endpoints track the actual IP addresses and ports for service backends. For larger scale deployments, EndpointSlices provide a more scalable alternative that distributes endpoint information more efficiently.

Configuration & Storage: Separating Code from Config

Modern cloud-native applications embrace the twelve-factor principle of configuration management, and Kubernetes delivers with ConfigMaps (for non-sensitive configuration) and Secrets (for passwords, tokens, and keys).

For persistent data, you have PersistentVolumes (PVs) representing cluster-level storage resources, and PersistentVolumeClaims (PVCs) representing user requests for that storage. This abstraction lets developers request storage without knowing the underlying infrastructure details.

Namespacing & Resource Management

Namespaces create virtual clusters within your physical cluster, enabling multi-tenancy and resource isolation. You can enforce limits with ResourceQuotas (controlling total resource consumption) and LimitRanges (setting default, minimum, and maximum resource constraints for individual resources).

Identity and Observability

ServiceAccounts provide identities for processes running in Pods, enabling fine-grained access control. Meanwhile, Events capture cluster activities for debugging and monitoring.

Don’t forget about Nodes—the worker machines that make up your cluster—and Bindings, which associate Pods with specific Nodes.

Apps API: The Workload Controllers You Actually Use

The

apps/v1
API group contains the controllers that manage your workloads in production.

The Big Four Controllers

Deployments are what you’ll use 99% of the time for stateless applications. They provide declarative updates for Pods and manage ReplicaSets under the hood.

Speaking of which, ReplicaSets maintain a stable set of replica Pods, though you’ll rarely create these directly—Deployments handle them for you.

For stateful applications that need stable network identities and persistent storage, StatefulSets are your go-to choice. Think databases, distributed systems, or anything where pod identity matters.

DaemonSets ensure that specific Pods run on every node (or a subset of nodes). This is perfect for infrastructure concerns like log collectors, monitoring agents, or network plugins.

Behind the scenes, ControllerRevisions store the revision history for StatefulSets and DaemonSets, enabling rollbacks when things go wrong.

Batch Operations: Jobs and Scheduled Tasks

The

batch/v1
API group handles workloads that run to completion rather than running indefinitely.

Jobs execute Pods until they successfully complete—perfect for data processing, backups, or one-time migrations. CronJobs take this further by running Jobs on a schedule, just like the classic Unix cron daemon. Need to run a report every night at 2 AM? CronJob has you covered.

Networking in Depth

The

networking.k8s.io/v1
API provides sophisticated networking capabilities.

NetworkPolicies act as firewalls for your Pods, defining rules for pod-to-pod communication. By default, Kubernetes allows all traffic between Pods, but NetworkPolicies let you implement zero-trust networking.

Ingress resources provide HTTP and HTTPS routing to Services, acting as a sophisticated reverse proxy. The IngressClass resource lets you specify which ingress controller should handle your Ingress rules—useful when running multiple ingress controllers in the same cluster.

RBAC: Who Can Do What

The

rbac.authorization.k8s.io/v1
API implements Role-Based Access Control.

Roles define permissions within a namespace, while RoleBindings grant those permissions to users, groups, or ServiceAccounts. For cluster-wide permissions, you have ClusterRoles and ClusterRoleBindings.

This four-resource system provides granular access control: “User Alice can read Pods in the development namespace” or “ServiceAccount monitoring-sa can list nodes cluster-wide.”

Storage Management

The

storage.k8s.io/v1
API handles dynamic provisioning and storage management.

StorageClasses define different “classes” of storage—think fast SSD versus slow HDD, or regional versus multi-regional storage. When you create a PVC, you can specify a StorageClass, and Kubernetes will dynamically provision the appropriate storage.

VolumeAttachments track which volumes are attached to which nodes, while the CSI (Container Storage Interface) resources—CSIDriver, CSINode, and CSIStorageCapacity—enable integration with external storage systems following the CSI standard.

Operational Policies and Scaling

Several API groups handle operational concerns:

Policy API (
policy/v1
)

PodDisruptionBudgets (PDBs) protect your applications during voluntary disruptions like node drains or cluster upgrades. You specify how many Pods must remain available, and Kubernetes respects these limits during maintenance operations.

Autoscaling API (
autoscaling/v1, v2
)

HorizontalPodAutoscalers (HPAs) automatically scale your Pods based on CPU, memory, or custom metrics. Traffic spike at 2 PM every day? HPA scales up. Traffic drops at night? HPA scales down. You define the target metrics, and HPA does the rest.

Scheduling API (
scheduling.k8s.io/v1
)

PriorityClasses let you assign priority levels to Pods. When resources are scarce, lower-priority Pods can be evicted to make room for higher-priority ones.

Advanced and System Resources

Several API groups handle more specialized concerns:

  • Certificates API: CertificateSigningRequests for X.509 certificate management
  • Node API: RuntimeClasses for selecting container runtimes (Docker, containerd, CRI-O)
  • Coordination API: Leases for distributed leader election
  • Admission API: ValidatingWebhookConfiguration and MutatingWebhookConfiguration for extending the API server with custom validation and mutation logic
  • Flow Control API: FlowSchemas and PriorityLevelConfigurations for API server request prioritization

The Meta-Resource: CustomResourceDefinitions

Here’s where things get interesting. The

apiextensions.k8s.io/v1
API includes CustomResourceDefinitions (CRDs), which let you define your own resource types.

This is how tools like ArgoCD add resources like

ApplicationSet
and
Application
to your cluster. CRDs are native to Kubernetes, but the custom resources they define are not—it’s a subtle but important distinction.

Quick Reference by Use Case

Let me organize these by how you’ll actually use them:

Running Applications:

  • Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet

Networking & Access:

  • Service, Ingress, NetworkPolicy, Endpoints, EndpointSlice

Configuration:

  • ConfigMap, Secret, ServiceAccount

Storage:

  • PersistentVolume, PersistentVolumeClaim, StorageClass

Access Control:

  • Role, RoleBinding, ClusterRole, ClusterRoleBinding

Scaling & Reliability:

  • HorizontalPodAutoscaler, PodDisruptionBudget

Batch Processing:

  • Job, CronJob

Cluster Management:

  • Namespace, Node, ResourceQuota, LimitRange

Discovering Resources in Your Cluster

Want to explore what’s available in your specific cluster? Here are some handy commands:

# List all API resources
kubectl api-resources

# Show only core (v1) resources
kubectl api-resources --api-group=""

# Filter by API group
kubectl api-resources --api-group=apps
kubectl api-resources --api-group=batch
kubectl api-resources --api-group=networking.k8s.io

# Check resource documentation
kubectl explain deployment
kubectl explain job
kubectl explain ingress

# Try a custom resource (only works if installed)
kubectl explain applicationset  # Requires ArgoCD

The

kubectl explain
command is particularly useful—if it returns information, the resource is available. If it returns an error, you need to install the corresponding CRD first.

What About ApplicationSet and Other Add-ons?

Here’s a common source of confusion: when you see

kind: ApplicationSet
in a manifest, that’s not a native Kubernetes resource. It’s a custom resource defined by ArgoCD’s CRDs.

Native Kubernetes resources:

  • ✅ Deployment
  • ✅ Service
  • ✅ ConfigMap
  • ✅ Secret
  • ✅ Job

ArgoCD custom resources (require ArgoCD installation):

  • ❌ ApplicationSet
  • ❌ Application
  • ❌ AppProject

This distinction matters when building portable applications or troubleshooting cluster issues. If someone says “it doesn’t work in our cluster,” check whether they have the required CRDs installed.

Wrapping Up

Kubernetes ships with approximately 50+ native resource types covering everything from basic workload management to sophisticated networking, storage, and security policies. Understanding these resources gives you a solid foundation for working with any Kubernetes cluster.

The beauty of Kubernetes is its extensibility—while these native resources cover most use cases, CRDs let you extend the platform with domain-specific resources when needed. But always start with native resources when possible; they’re battle-tested, well-documented, and universally supported.

Now you know exactly what’s built into Kubernetes and what requires additional installation. Happy clustering! 🚀

Pro Tip: Bookmark the official Kubernetes API reference for detailed documentation on every resource. And remember: when in doubt,

kubectl explain
is your friend.