Member-only story
DevOps in K8s — API Object Deep Dive
Note, full “DevOps in K8s” mind map is available at: “DevOps in K8s Mind Map”
API Versions
In a K8s cluster, the objects that are persisted are referred to as K8s objects. These objects represent the state of the entire cluster, and they are ultimately stored in etcd.
The resource manifest files that we write in YAML format are submitted to the cluster using kubectl, which creates the corresponding resource objects. However, the process of how these YAML files are transformed into API objects in the cluster is not always clear.
To understand how our YAML files are converted into API objects in a K8s cluster, it’s necessary to explore the design of the declarative API. The K8s API is an HTTP service that primarily uses JSON for serialization (although it also supports Protocol Buffers serialization, which is primarily used for communication between components within the cluster). To ensure scalability, K8s supports multiple API versions under different API paths (such as /api/v1 or /apis/batch), each with varying levels of stability and support:
- Alpha level: For example, v1alpha1 is disabled by default and support for its functionality can be removed at any time, so it should be used with caution.
