Why Kubernetes’ Real Power Lies in Its API, Not Just Containers

1. Kubernetes’s Core Is Its API Framework, Not Containers

The article argues that the fundamental value of Kubernetes is its generic, cross‑vendor, extensible declarative API framework, not the containers themselves (although containers are the foundation of its success). An example CRD is created manually to illustrate this point, using Kubernetes v1.21.0.

Containers were a breakthrough in 2013, enabling developers to run complex services with a simple docker run command, which opened the door to agile infrastructure. However, the article stresses that containers are not the most important aspect of Kubernetes; efficient workload scheduling is only one of its valuable features.

API Is the Core – Kubernetes provides a standard programming interface (API) for building and using software‑defined infrastructure that is larger than IaaS. The API framework consists of a specification plus implementation, with typed resources watched and reconciled by controllers.

Before Kubernetes, each cloud vendor offered disparate APIs, formats, and semantics, forcing developers to piece together infrastructure manually. Tools like Terraform offered a common format but still required vendor‑specific descriptors.

Kubernetes standardized a cross‑vendor API, exposing resources such as Pods, Services, Ingress, Volumes, and ServiceAccounts through a unified API.

2. Kubernetes API Types

Standard API operations (GET/LIST/PUT/POST/DELETE) manipulate resources; controllers reconcile the actual status to the desired spec. Namespaced resources (e.g., pods, services, networkpolicies) are scoped per namespace, while cluster‑scoped resources (e.g., nodes, clusterroles) are global. The API paths are /api/{version}/namespaces/{namespace}/{resource} for namespaced types and /api/{version}/{resource} for cluster‑scoped types.

Extension APIs (apiextensions) introduce CRDs. A CRD defines a new resource kind, its scope, and version, and Kubernetes automatically generates a REST API for it.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: fruits.example.org
spec:
  group: example.org
  names:
    kind: Fruit
    plural: fruits
    singular: fruit
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              comment:
                type: string
              sweet:
                type: boolean
              weight:
                type: integer
    additionalPrinterColumns:
    - name: sweet
      type: boolean
      jsonPath: .spec.sweet
    - name: weight
      type: integer
      jsonPath: .spec.weight
    - name: comment
      type: string
      jsonPath: .spec.comment

3. Intuitive Analogy: Kubernetes Is a Database, CRD Is a Table, API Is SQL

The article likens Kubernetes to a relational database: the entire cluster is a database, each Kind is a table, properties are columns, and individual resources are rows. CRDs behave like user‑defined tables, allowing arbitrary data (e.g., databases, message queues, certificates) to be stored and managed via the same API.

Creating a CRD is analogous to CREATE TABLE fruits (...);. Creating a custom resource (CR) corresponds to INSERT INTO fruits VALUES (...);. Querying, updating, and deleting CRs map to standard SQL statements ( SELECT, UPDATE, DELETE).

# Create CRD
$ kubectl apply -f fruits-crd.yaml
# Create CRs
$ kubectl apply -f apple-cr.yaml
$ kubectl apply -f banana-cr.yaml
# List CRs (SELECT *)
$ kubectl get fruits
# Delete a CR (DELETE)
$ kubectl delete fruit apple

Labeling and filtering CRs work like indexed columns: you can add a label tastes-good=true to a resource and later retrieve it with kubectl get fruits -l tastes-good=true.

4. Other Topics

Both built‑in and custom APIs are protected by Kubernetes RBAC, allowing fine‑grained authorization. The article provides links to official CRD documentation, a deep dive into RBAC design, and additional reading on Kubernetes architecture and container‑based databases.

Author: Zhao Yanan Source: Distributed Lab