Kubernetes abstracts all cluster components into API resources. Once instantiated, these resources become objects managed by the control plane. Resources are generally categorized by their functional scope:

Wrokload Resources Manage container lifecycles and scaling: Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, CronJob. (Note: ReplicationController is deprecated).

Networking & Traffic Routing Handle service discovery and load distribution: Service, Ingress, EndpointSlice.

Configuration & Storage Provide external data and persistent storage: Volume, PersistentVolume, PersistentVolumeClaim, ConfigMap, Secret. The Container Storage Interface (CSI) enables integration with external storage providers. Special volumes like DownwardAPI expose cluster metadata directly to containers.

Cluster-Scoped Resources Operate across all namespaces: Namespace, Node, ClusterRole, ClusterRoleBinding, CustomResourceDefinition.

Policy & Metadata Resources Govern resource consumption and scaling: LimitRange, HorizontalPodAutoscaler, PodTemplate, ResourceQuota.

Most configuration and workload resources are namespace-scoped, while cluster-level resources apply globally.

Structure of a Kubernetes Manifest

Kubernetes objects are typically declared using YAML manifests. A standard manifest contains five top-level fields:

• apiVersion: The API group and version (e.g., apps/v1, v1). If no group is specified, it defaults to the core API group.
• kind: The type of resource being created.
• metadata: Identifying information including name, namespace, labels, and annotations.
• spec: The desired state configuration defined by the user.
• status: The current observed state, automatically populated and managed by the Kubernetes control plane. Users should never define this field.

Discovering API Versions and Field Documentation

To determine the corect apiVersion for a resource, query the cluster's registered API groups:

kubectl api-versions

Output varies by cluster version but typically includes groups like apps/v1, batch/v1, networking.k8s.io/v1, and v1 (core).

For detailed field documentation, use the explain command:

kubectl explain pod
kubectl explain deployment.spec.replicas

Different resources belong to different API groups, so verifying the version ensures compatibility with your cluster.

Interpreting Field Types in Documentation

The kubectl explain output uses specific type notations:

• <string>: Text value
• <Object>: Nested configuration block
• <map[string]string>: Key-value pairs (e.g., labels, annotations)
• <[]string>: Array of strings
• <[]Object>: Array of nested objects
• <boolean>: True/false flag
• <integer>: Numeric value
• -required-: Mandatory field that must be provided

Practical Manifest Example

The following YAML defines a multi-container Pod with an application container and a sidecar utility:

apiVersion: v1
kind: Pod
metadata:
  name: web-sidecar-example
  namespace: development
  labels:
    component: api-gateway
    environment: staging
  annotations:
    maintainer: platform-team
spec:
  containers:
    - name: primary-app
      image: nginx:1.25-alpine
      ports:
        - containerPort: 80
    - name: log-shipper
      image: busybox:1.36
      command: ['/bin/sh', '-c', 'while true; do echo heartbeat; sleep 60; done']
      resources:
        requests:
          cpu: '50m'
          memory: '32Mi'
        limits:
          cpu: '100m'
          memory: '64Mi'

Apply the manifest to the cluster:

kubectl apply -f web-sidecar-example.yaml

Verify the Pod status:

kubectl get pods -n development -l component=api-gateway

Inspect detailed events and container states:

kubectl describe pod web-sidecar-example -n development

Stream logs from a specific container within the Pod:

kubectl logs web-sidecar-example -c primary-app -n development

Remove the resource using the same manifest file:

kubectl delete -f web-sidecar-example.yaml