In the previous post we saw what labels are and what are the best practices to select them. In this post we will deploy pods with a variety of labels and then look at how to select them in a YAML and through the kubectl tool using Kubernetes Selector. What is a Kubernetes selector Kubernetes […]
In the previous post we talked about Namespaces. In this post I will cover Kubernetes Labels and annotations. Difference between labels and annotations? Kubernetes allows adding additional info to an object using Labels and annotations. The purpose of labels and annotations, however, differ. The label information can be used to select objects by using a […]
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 clusterControlled access to resources such as pods, services etc.Limit resource consumption for that namespace.Give a user admin access to only a particular namespace. The namespace becomes part of the DNS and hence the namespace name has to be DNS compatible. Do not use namespace for resources that differ only slightly such as versions. Labels are better suited for that. Kubernetes comes with three namespaces. The “default” namespace contains objects that are not in any other namespace. “kube-system” contains objects created by kubernetes and kube-public is used for objects that anyone can read. namespace commands While using the kubectl client the objects listed by default are from the default namespace. To list objects from a different namespace use –namespace argument. For example, to list all deployments in the kube-system namespace use
kubectl get deployments --namespace=kube-system
Lets create a new kubernetes namespace. There are two main ways to create namespaces. The first is by directly creating a namespace from the command line. for example.
kubectl create namespace development
creates a namespace called development. To see whether the namespace has been created type in
kubectl get namespaces
to delete a namespace type in
kubectl delete namespace development
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.
In the previous post we looked at Kubernetes architecture, in this very short post lets look at Kubernetes object. 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 file and send it to the API in the control plane. In the next post I will briefly talk about Pods.
Welcome to this post on Kubernetes Architecture! In the last post we deployed a simple containerized static website to Kubernetes. I am sure you are now eager to understand what Kubernetes really is. We will split the architecture into multiple videos and this first video gives a brief overview of the various components of Kubernetes. […]
In this post I will guide you through the process of deployment of a static website on Kubernetes on Minikube. The Source code for all the exercises are on github. This exercise is in the folder called kubernetes_static_website. You should have installed minikube by now. Start minikube if you have not already done so. Static […]
In the previous post we saw an introduction to Kubernetes. Before we go into the architecture of Kubernetes let us look at a small demo of Minikube on windows. Minikube allows you to install a single node cluster of Kubernetes on the local machine. The cluster is installed on a virtual machine . The purpose […]
What is Kubernetes? In the previous post we saw a brief overview of containers and we also understood why the industry is moving towards containers. In this video lets take the next step and understand what Kubernetes is and why it is becoming a platform of choice for container management for both enterprises and startups. […]
Monolithic to microservices The last topic before we start looking at Kubernetes is to understand why the world is moving from Monolithic to Microservices or servers to containers to manage application deployment. To understand that, we need to take a look at how software development has evolved through the years. A few years back we […]