Introduction to Kubernetes-Part#2
Kubernetes(K8S) 101, We are covering Kubernetes objects this week. Kubernetes Objects are the entities that we defined in Kubernetes objects. It’s defined in
To work with Kubernetes objects–whether to create, modify, or delete them–you’ll need to use the
Kubernetes API. Using
kubectl CLI interface also Kubernetes objects can be defined. Ultimately it uses Kubernetes API in the backend to make those calls.
Describing Kubernetes Objects
The basic Kubernetes Objects are as follows:
Pod : It’s usually a group of one or more containers for a single application. It has application containers, storage and a network with other configurations to run the containers.
Service - Service is a logical gateway which connects to single or multiple pods. Pods are mainly stateless and volatile and an application should not be mapped to a physical pod address. Instead, we need to define Service in Kubernetes which would allow clients to reach the application via these services. Kubernetes internally would keep track of active pods assigned to that service ensuring the service availability.
Volume - Volume in Kubernetes is the same as a volume in Docker. The major difference here is that Volume in Kubernetes gets applied to the whole pod which could have multiple containers. It’s mainly used to make the application stateful by retaining the data across the container restarts and in case any containers are destroyed.
Namespace - a virtual cluster (a single physical cluster can run multiple virtual ones) intended for environments with many users spread across multiple teams or projects, for isolation of concerns. Resources inside a namespace must be unique and cannot access resources in a different namespace. Also, a namespace can be allocated a resource quota to avoid consuming more than its share of the physical cluster’s overall resources.
Deployment - describes the desired state of a pod or a replica set, in a YAML file. The deployment controller then gradually updates the environment (for example, creating or deleting replicas) until the current state matches the desired state specified in the deployment file. For example, if the YAML file defines 2 replicas for a pod but only one is currently running, an extra one will get created. Note that replicas managed via a deployment should not be manipulated directly, only via new deployments
We are concluding this week’s article here. Next, we would continue witth understanding various configuration options which it provides.
In case you are looking for a way to migrate your existing applications to Kubernetes, we @Datavizz helps an enterprise to create an enterprise migration strategy to migrate your product to Cloud Native application stack.