Introduction to K8S APIs and Objects.

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)

Preview

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
  • 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About continuous learner

devops & cloud enthusiastic learner