API Server
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
API objects represent the desired state of an individual cluster object. They're comprised of:
apiVersion
specifies 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.kind
specifies the resource type.group
defines 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.apps
contains Deployment.storage
contains StorageClass.rbac.authorization.k8s.io
contains Role, RoleBinding, etc.
For example:
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.
Discovery
kubectl cluster-info
Resource discovery
Find available API groups:
kubectl 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
API internals
Additional HTTP methods are used in some implementation:
LOG
streams logs from a container within a pod.EXEC
executes a command within a container to get the output.WATCH
yields a stream of change notifications.
Paths contain versions. Requests to API groups besides core
will be to /apis/:groupName
:
/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.
Proxying
kubectl proxy
exposes access to the API without requiring additional authentication, and can be useful for troubleshooting access to the cluster.
Backlinks