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