The Kubernetes API is the central interface for working with a cluster. Instead of choosing a worker node and starting an application there yourself, you create objects that describe what you want to run. The control plane exposes the API and uses those objects to coordinate the cluster. section 1.2.1 section 4.1
The API is HTTP-based and RESTful. Clients create, read, update, and delete resources using HTTP methods such as POST, GET, PUT or PATCH, and DELETE. A resource has a URI; a deployment collection and an individual deployment have different URIs. An object is the thing represented, while resources are ways to access it—one object can be exposed through more than one resource. section 4.1.1
Check and inspect a cluster
Run `kubectl cluster-info` to check whether the API server responds. Then run `kubectl get nodes` to list Node objects, or `kubectl describe node` to see more detail. These commands let you use the API without writing HTTP requests yourself. section 3.2.3
Application objects are commonly described in YAML or JSON manifests. A manifest states the intended configuration; after an object is created through the API, reading it back can reveal additional fields, including status. Use `kubectl explain pods` to look up available Pod fields while preparing a manifest. section 1.2.4 section 5.2.1
Listing 5.1 A basic pod manifest file
apiVersion: v1 #1
kind: Pod #2
metadata:
name: kiada #3
spec:
containers:
- name: kiada #4
image: luksa/kiada:0.1 #5
ports:
- containerPort: 8080 #6
This small Pod manifest shows `apiVersion`, `kind`, `metadata`, and `spec`: enough to identify the object and describe its container before submitting it to the API. section 5.2.1
Submitting a manifest starts a process, not just a file upload. The API server stores the objects in etcd. Controllers respond to them, the scheduler assigns application instances to nodes, and each node’s Kubelet runs its assigned instances. Controllers and Kubelets continue monitoring the result. Many objects report current state in `status`, alongside the desired configuration in `spec`; events can provide clues when something goes wrong. section 1.2.4 section 4.4
This interface also separates using Kubernetes from managing its control-plane components. With a managed cluster, a provider operates those components while you use the Kubernetes API to deploy applications. Because major cloud providers offer that standard interface, applications built around it are less tied to one provider’s proprietary deployment API. section 1.3.2 section 1.1.3
