The API Server provides a single surface area over all cluster resources, and is the sole client interacting with the underlying configuration storage, ensuring consistency. It also serves as the single point of entry for both internal operations with other cluster components and external operations, with interactions taking place over a REST API.
API objects represent the desired state of an individual cluster object. They're comprised of:
apiVersionspecifies the version of the resource, used for backwards compatibility despite further change. In addition, API is tagged alpha, beta and stable to represent stability level.
kindspecifies the resource type.
groupdefines the API group to which the resource type belongs and forms part of the API resource's path, e.g.:
core(the core group, or legacy) is where resources defined before groups were introduced live, such as Pod, Namespace, Node, PersistentVolume and PersistentVolumeClaim.
rbac.authorization.k8s.iocontains Role, RoleBinding, etc.
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx
Imperative actions mutate the persistent objects and are inherently unpredictable. Declarative configuration allows resources to be brought in line with a desired state.
Find available API groups:
Find available resources:
kubectl api-resources kubectl api-resources --api-group=apps
Explain the available fields and value documentation:
kubectl explain pods kubectl explain pods.spec.containers
Additional HTTP methods are used in some implementation:
LOGstreams logs from a container within a pod.
EXECexecutes a command within a container to get the output.
WATCHyields a stream of change notifications.
Paths contain versions. Requests to API groups besides
core will be to
/api/:version/:resourceType /api/:version/namespaces/:namespace/:resourceType/:resourceName /apis/:groupName/:version/:resourceType /apis/:groupName/:version/namespaces/:namespace/:resourceType/:resourceName
Request processing is typical for a web application, bar admission control:
- Connection, usually with HTTPS.
- Authentication using an authentication module.
- Authorisation via an authorisation module.
- Admission control passes the request through Admission Controllers, which are able to mutate or validate the incoming request before admission.
kubectl proxy exposes access to the API without requiring additional authentication, and can be useful for troubleshooting access to the cluster.