Kubernetes API Resources Overview

A high-level overview of Kubernetes API resources

Able Lv
4 min readMay 22, 2022
Photo by Kira auf der Heide on Unsplash

Kubernetes API Overview

The core of Kubernetes’ control plane is the API server. The API server exposes a RESTful API. The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes platform is treated as an API object and has a corresponding entry in the API.

You can use the Kubernetes API to read and write Kubernetes resource objects via a Kubernetes API endpoint (for example: Pods, Namespaces, ConfigMaps, and Events). You can interact with the Kubernetes API directly, or via tools like kubectl.

Kubernetes API Resource Categories

Here is a high-level overview of Kubernetes API resources:

  • Workload Resources are objects you use to manage and run your containers on the cluster.
  • Service Resources are objects you use to “stitch” your workloads together into an externally accessible, load-balanced Service.
  • Config and Storage resources are objects you use to inject initialization data into your applications and to persist data that is external to your container.
  • Policy Resources are objects you use to configure the behavior of other resources within the cluster.
  • Cluster Resources are objects define how the cluster itself is configured; these are typically used only by cluster operators.

Resource Object Components

Resource objects typically have 3 components:

  • Resource ObjectMeta: This is metadata about the resource, such as its name, type, api version, annotations, and labels.
  • ResourceSpec: This is defined by the user and describes the desired state of the system. Fill this in when creating or updating an object.
  • ResourceStatus: This is filled in by the server and reports the current state of the system. In most cases, users don’t need to change this.

Workload Resources

Workload resources are responsible for managing and running your containers on the cluster. Containers are created by Controllers through Pods. Pods run Containers and provide environmental dependencies such as shared or persistent storage Volumes and Configuration or Secret data injected into the container.

The most common Controllers are:

  • Deployments for stateless persistent apps (e.g. HTTP servers). It enables declarative updates for Pods and ReplicaSets.
  • StatefulSets for stateful persistent apps (e.g. databases).
  • Jobs for run-to-completion apps (e.g. batch Jobs).

Other resource types:

  • Pod is a collection of containers that can run on a host.
  • PodTemplate describes a template for creating copies of a predefined pod.
  • ReplicaSet ensures that a specified number of pod replicas are running at any given time.
  • CronJob represents the configuration of a single cron job.
  • HorizontalPodAutoscaler configuration of a horizontal pod autoscaler.
  • PriorityClass defines a mapping from a priority class name to the priority integer value.

Service Resources

Service resources are responsible for stitching your workloads together into an accessible Loadbalanced Service. By default, Workloads are only accessible within the cluster, and they must be exposed externally using a either a LoadBalancer or NodePort Service. For development, internally accessible Workloads can be accessed via proxy through the api master using the kubectl proxy command.

Common resource types:

  • Services for providing a single ip endpoint loadbalanced across multiple Workload replicas.
  • Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. Ingress provides a https(s) endpoint http(s) routed to one or more Services.

Other resource types:

  • Endpoints is a collection of endpoints that implement the actual service.
  • EndpointSlice represents a subset of the endpoints that implement a service.
  • IngressClass represents the class of the Ingress, referenced by the Ingress Spec.

Config and Storage Resources

Config and Storage resources are responsible for injecting data into your applications and persisting data externally to your container.

Common resource types:

  • ConfigMap holds configuration data for pods to consume. It provides text key value pairs injected into the application through environment variables, command line arguments, or files.
  • Secrets holds secret data of a certain type. It provides binary data injected into the application through files
  • Volumes for providing a filesystem external to the Container. Maybe shared across Containers within the same Pod and have a lifetime persisting beyond a Container or Pod.

Other resource types:

  • PersistentVolumeClaim (PVC) is a user’s request for and claim to a persistent volume.
  • PersistentVolume (PV) is a storage resource provisioned by an administrator.
  • StorageClass describes the parameters for a class of storage for which PersistentVolumes can be dynamically provisioned.
  • CSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster.

Policy Resources

Policy Resources resources are objects you use to configure the behavior of other resources within the cluster.

  • LimitRange sets resource usage limits for each kind of resource in a Namespace.
  • ResourceQuota sets aggregate quota restrictions enforced per namespace.
  • NetworkPolicy describes what network traffic is allowed for a set of Pods.
  • PodDisruptionBudget is an object to define the max disruption that can be caused to a collection of pods.

Cluster Resources

Cluster resources are responsible for defining configuration of the cluster itself, and are generally only used by cluster operators.

  • Node is a worker node in Kubernetes.
  • Namespace provides a scope for Names.
  • Event is a report of an event somewhere in the cluster.
  • Lease defines a lease concept.

--

--

Able Lv

Cloud Infrastructure Engineer @Airwallex: Kubernetes, DevOps, SRE, Go, Terraform, Istio, and Cloud-Native stuff