Kubernetes namespace (Kubernetes course – 11)

What is a Kubernetes namespace? In this post we will be looking at Kubernetes namespace. By definition a Kubernetes namespace allows separation of resources created by users. However, to get an intuition of what namespaces are, imagine a company that has multiple teams and each team has multiple environments.  It is  common for enterprises to have a development, testing, staging and production environment for each team.  We need a way to make sure that applications and services deployed by one team are not visible or accessible to the other teams. One way of doing this is to have multiple Kubernetes cluster, i.e. one per team per environment. Its easy to see how that would not only be a maintenance nightmare but also negates the advantage of moving to Kubernetes in the first place. We want to use the hardware effectively by reducing unused resources and the best way to do that is to run multiple environments for one or more teams in a single cluster. We would then need a good way to logically separate these environments so an application deployed in one environment or team does not get access to other environments. Namespaces in Kubernetes are a great way to create logical partitions within a cluster. Each namespace can be thought of as hosting applications for a single team and for a single environment.  creating a namespace allows Create logical partition within the cluster Controlled access

Read more

Kubernetes Pod (Kubernetes course – 10)

In the previous post we talked about Kubernetes Objects. The most important Kubernetes object is a pod. What is a Kubernetes pod? A Kubernetes pod is the most basic unit that can be deployed to a Kubernetes cluster. A pod consists of one or more containers. The most basic use case for Kubernetes is to deploy a single container per pod, however there are scenarios where you would want multiple containers in a pod.  For example, If you have a container that processes weather data, you could have another container that downloads weather data and puts it in a place that is accessible by both the containers. If a pod hosts multiple containers, they are always located on the same node and are scheduled together.   The pod also has its own unique IP and all containers within the pod share the same IP address and ports. Think of containers within the pod as sharing a linux namespace.  Multiple containers within a pod can access shared data and data can be persisted using persistent volumes, which we will look at later.   The pods are managed by a controller and if one pod crashes, the controller immediately creates a new pod. Horizontal scaling of applications is achieved by creating multiple instances of the pod. The multiple instances are hosted on one or multiple nodes. A ReplicaSet is used to specify the number of instances. The controller ensures that the cluster contains the exact number of instances of the pod as specified in the ReplicaSet. One thing to note about the pod is that it does not store data permanently. The filespace within the pod is available as long as the pod is alive. If a pod dies, its data goes away too and a new pod created will not have the data. To persist data use a Persistent Volume or a StatefulSet which we will look at later.  In the next post we will look at namespaces and some hands on tutorial too so that you can fire up your laptop again and get working.. see you in the next post.

Read more

Kubernetes Object (Kubernetes course – 9 )

In the previous post we looked at Kubernetes architecture, in this very short post lets look at Kubernetes object.  Types of Kubernetes Objects Each entity that can be persisted in Kubernetes is known as a Kubernetes Object. For example pod, container, Service, ServiceAccount , Volume, PersistentVolume, ContainerPort, Namespace, ConfigMap are all objects that can be maintained and persisted. You specify the object using a yaml file and Kubernetes will try to bring its state to that defined in that yaml file.  To create or modify the object you can use the Kubernetes RESTful API or the kubectl client which internally uses the API. Each object has two child objects called spec and status. The spec object is what you specify via the YAML and it is the desired end state of the object and status describes the actual state. The Kubernetes control plane is responsible for bringing the actual state to the desired state.The desired state is sent as a body of the request to the restful API. In most cases you would be writing a YAML file and use kubectl to take that YAML

Read more