Kubernetes is a container management/orchestration solution responsible for configuring, deploying/redeploying ,tracking,monitoring,scheduling ,scaling,handling availaibility and load balancing containerized applications across many server computers . The increase adoption of microservices resulted in increased usage of containers as containers are good for hosting small microservices. A complex of application may have hundereds of services and consquently containers hence container orchestration tools are imperative.

Kubernetes and complimentary projects mentioned below come togather to create a true cloud native platform.

Kuberntes cluster is group or bunch of nodes that run your containerized applications.  kubectl is a command line interface (CLI) for managing operations on your Kubernetes clusters. It does so by communicating with the Kubernetes API which the the entry point to kubernetes cluster.kubectl can be used for any kuberntes cluster (cloud/minkube). 

Key building blocks of kubernetes cluster 

What is kubernetes service

Kubernetes service can be used expose an application running on a set of Pods as a network service. In other words a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). There is no need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes uses server side discovery mechansim .Kubernetes gives Pods their own IP addresses and a single DNS name and a static ip address for a set of Pods, and can load-balance across them.Note that while each pod has its own ip address , pods are ephemeral and can be created  /destroyed frequently. The new pods have new ip address.Hence pods ip address cannot be used. Instead the static internal ip of the service should be used. The set of pods targeted by a service is usually determined by a selector.

Ingress

Ingress becomes the entry point to the kubernetes cluster.External requests go to ingress which forwards requests to service.Ie ingress component is used for routing traffic to kubernetes cluster.In ingress you have routing rules where in host to service mapping can be defined.Host has to be a valid domain address. So typicall from load balancer , the request will go to ingress controller and from ingress controller to service. Different path can lead to different service.

ConfigMap

Exteranal configuration of application eg db url . Hence for configuration changes new images / redeployment need not be done. Note that user id passwords should not be put in configmap. .note that config map is a local volume. It is managed by kuberntes. this can also be used when you want configuration file for your pod. ConfigMap can be created and then mounted into pod/container.

Secrets

Secret is just like config map but it is used to store secret data eg credentials, The data is stored in base64encoded format.

Volumes

A physical storage can be attached to a pod.The storage does not depend on the pod lifecycle . Note that a pod could restart on any worker node so the storage should be accessible to all nodes. The storage can be on local machine or remote (not part kuberntes cluster).Hence for example of db is restarted, all the data is still persisted. Persisten volumes should be thought of as cluster resouce like RAM/CPU that is used to stored data. The type of storage which app needs does not depend on kubernetes. In other words storage is plugin to cluster. Persistent volumes are not name spaced ie avaliable to whole cluster. Typically for databases remote storage is used.  A pod can have multiple volumes.

Storage class

storage class provisions persistent volumes dynamically.

Deployment

Deployments represent a set of multiple, identical Pods with no unique identities. A Deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. In this way, Deployments help ensure that one or more instances of your application are available to serve user requests. Deployments are managed by the Kubernetes Deployment controller.

Deployments use a Pod template, which contains a specification for its Pods. The Pod specification determines how each Pod should look like: what applications should run inside its containers, which volumes the Pods should mount, its labels, and more.

Deployments are well-suited for stateless applications.

Stateful sets

StatefulSets represent a set of Pods with unique, persistent identities and stable hostnames that GKE maintains regardless of where they are scheduled. The state information and other resilient data for any given StatefulSet Pod is maintained in persistent disk storage associated with the StatefulSet.

StatefulSets use a Pod template, which contains a specification for its Pods. The Pod specification determines how each Pod should look: what applications should run inside its containers, which volumes it should mount, its labels and selectors, and more.

StatefulSets are designed to deploy stateful applications and clustered applications that save data to persistent storage, such as Compute Engine persistent disks. StatefulSets are suitable for deploying Kafka, MySQL, Redis, ZooKeeper, and other applications needing unique, persistent identities and stable hostnames.

In stateful sets the pods are not identical. Giving each pod it's own required individual identity is what stateful set does differently compared to deployment. Sticky identity is maintained for each pod in stateful set. Each pod has persistent identifier that is maintained across any rescheduling. Ie when a pod dies and is replaced by another pod, it keeps that identity. In stateful set pods get fixed ordered names. Also each pod gets its own DNS end point from service. when pod restarts while ip address will change yet but name and end point will stay the same ie pods get stikcy identity(across restarts) . ie state and role is maintained across restarts.

Note that is a common practice to host database applications outside of the kuberntes cluster and stateful sets are more tedious compared to deployments. State full applilcations are not perfect for containerized environments.

Namespace in kubernetes

Resources can be organized in name spaces. It can be thought of as a virutal cluster within kuberntes cluster. Name space is useful in large applications where there are many services. It would be difficult to have over all picture of the cluster. You can create database name space, monitoring name space . Name spaces are also useful when there are multiple teams (many teams , same application). Name spaces are also useful for blue/green deployment ie the same cluster you want 2 different versions of application. Also access control can be done via giving a team access only to there name space. You can limit resouces a name space can consume (cpu/ram). 

Note that each name space must have its own configMap /secrets. 

 

What is Minikube?

Minikube is an open source tool that enables you to run Kubernetes on your laptop or other local machine. All the master node process and worker node process run on one machine. 

Advantages of kubernetes