Kubernetes APIs
- Kubernetes exposes different sets of REST APIs for different Purposes.
- These APIs serve as a foundation for the declarative configuration schema for the system, Which the kubectl tool uses to create, update, delete and get API Objects.
- Kubernetes also stores its serialized state in etcd in terms of the API Resources.
- Kubernetes APIs are in constant development, so Kubernetes follows the strict API Versioning & to simplify extending of APIs API groups are implemented
API Versioning
- Kubernetes supports multiple API Versions, each at different API path such as api/v1 or /apis/extensions/v1beta1
- Different API Versions imply different levels of stability & support
Alpha level
- Version name consists of alpha e.g (v1alpha1)
- May be buggy, These features are disabled by default
- Support for feature may be dropped at any time without notice
- API changes may be incompatible in later versions
Beta level
- Version name consists of beta e.g (v2beta3)
- Code is well tested. These features are enabled by default
- Support for overall feature will not be dropped, but details may change
Stable level
-
Version name will in in the format of vX where x is an integer
-
Stable versions of features will appear in released software for many subsequent versions
-
To get all the available api versions in your Kubernetes cluster execute
kubectl api-versions
API groups
- API group is specified in the apiVersion field of the Kubernetes Object
- There are several API groups in use
- core group: referred as legacy group. It is at the REST path api/v1 and uses apiVersion: v1
- named groups: They are at the REST path /apis/$GROUP_NAME/$VERSION and use apiVersion: $GROUPNAME/$VERSION e.g (apiVersion: batch/v1)
note: reference from OpenShift blog
Kubernetes Objects
- Kubernetes Objects are persistent entities in Kubernetes. Kubernetes uses these entities to represent state of your cluster
- They can describe
- What containerized applications are running (and On which nodes)
- Resources available to those applications
- Policies around how those applications behave
- You can work with Kubernetes Objects for create, modify and delete using
- kubectl cli
- API Directly from Client Libraries
- Every Kubernetes object includes two nested object fields that govern the configuration
Object Spec
- In this you need to describe the desired state for the object.
- Can be considered as input
Object Status
- Actual status of the object supplied by Kubernetes system
- Can be considered as output
Names
- All objects in the Kubernetes REST API are identified by Name and UID (Unique Identifier)
- Only one object of a given kind can have a given name at a time. If you delete the object , you can make a new object with same name.
- Max length of 253 characters
- Generally lower case alphanumeric characters, – and .
- In the below example tomcat-demo is for Pod name and tomcat for Container name
apiVersion: v1
kind: Pod
metadata:
name: tomcat-demo
spec:
containers:
- name: tomcat
image: tomcat:8
ports:
- containerPort: 8080
UIDs
- Kubernetes systems-generated string to uniquely identify objects.
kubectl get <object> -oyaml | grep uid
Kubernetes Workloads
- Kubernetes Workloads are classified as Pods & Controllers.
Pods
- It is atomic unit of Kubernetes Application.
- Pod has Container(s), Storage resources, a unique Network IP
- In Kubernetes Pods can be created directly.
- Pod workloads do not maintain desired state, But controllers can.
- If you are running multiple containers in the Pod, they share same IP Address and port space, have the same host name and can communicate over IPC.
- Pods are describe by declarative Pod manifest.
- Since Pod is a Kubernetes Object, it will have Object Spec and Status.
- Navigate to here. I’m using the 1.16 version. In the Workloads APIS section section, select Pod v1 core
- Now the spec definition is define over here. Based on this spec, I would be creating a tomcat pod
- create a file name tomcat-pod.yml with below content
apiVersion: v1
kind: Pod
metadata:
name: tomcat
spec:
containers:
- image: tomcat:8
name: tomcat
ports:
- containerPort: 8080
name: http
protocol: TCP
- Execute below commands and observe the results
kubectl apply -f tomcat-pod.yml
kubectl get pods
kubectl get pod tomcat
kubectl describe pods tomcat
kubectl port-forward tomcat 8080:8080
kubectl exec tomcat date
kubectl delete -f tomcat-pod.yml
Controllers
- Available Controllers are
- ReplicaSet
- ReplicationController
- Deployments
- StatefulSets
- DaemonSet
- CronJob