StudyTrails http://www.studytrails.com Learn Java, Spring, AWS and R Tue, 12 Nov 2019 05:17:28 +0000 en-US hourly 1 https://wordpress.org/?v=5.2.4 http://www.studytrails.com/wp-content/uploads/2018/07/cropped-icon5-32x32.png StudyTrails http://www.studytrails.com 32 32 Kubernetes Selector (Kubernetes course – 13) http://www.studytrails.com/devops/kubernetes/kubernetes-selector-kubernetes-course-13/ http://www.studytrails.com/devops/kubernetes/kubernetes-selector-kubernetes-course-13/#respond Tue, 12 Nov 2019 05:16:36 +0000 http://www.studytrails.com/?p=17025 In the previous post we saw what labels are and what are the best practices to select them. In this

The post Kubernetes Selector (Kubernetes course – 13) appeared first on StudyTrails.

]]>

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 selector allows you to select an object by using its label by matching label against the label name or an operator that acts on the label name.

Kubernetes selector example

Here’s the yaml file – The first object is a pod. It has 3 labels – name, stage and owner. The labels combine to tell us that it is a kubernetes-static-website owned by the digital team and in a canary stage. Canary deployment is where you release an application to a subset of users or servers.

Kubernetes selector

The second pod is the kuberentes-static-website owned by the analytics team and in a production stage. The purpose of labeling the pods will be clear now. Lets say you want to target a service to a particular pod. To do that you will specify a selector that helps you select the required pod. In this case we use the selector to select the pod owned by the digital team and in canary stage. We will now use the kubectl tool to create the resources.

kubectl.exe apply -f labels_demo.yml

The selectors where specified as a map. There are certain resources that allow specifying a selector as a set as well. That is, it allows us to select based on values in a set. The resources that support these are Job, Deployment, Replica Set and DaemonSet. Lets look at an example of a ReplicaSet to see how it works.

The file labels_replicaset.yml contains a replicaset. It specifies a template with stage canary and owner analytics. We use two different kinds of selectors to select pods that are targeted by this ReplicaSet. In MatchLabels we specify key value pairs of labels that we want to use to target the pods and in MatchExpression we use a key, a value and an operator. The operator could be In, NotIn, Exists and DoesNotExist. In our example we use the name in MatchLabels and in the MatchExpression we tell Kubernetes to target pods that contains production or canary as stage and whose owner is not in digital. The clauses in MatchLabels and MatchExpression are Anded together

When we create the ReplicaSet using this YAML, it creates only one pod and not two. What’s going on? If you look at the MatchExpression again you would notice that not only does it select the pod specified in the template but it also selects the pod that we created earlier. i.e the ReplicaSet selects the production-analytics pod that we created earlier. The ReplicaSet includes all pods that matches the selectors and not just the ones that it has created.

We now quickly look at some example of how to use the selectors in the kubectl tool. To get all pods in canary stage type in

kubectl get pods -l "stage=canary"

-l is used the specify selectors. To get all pods in canary whose owner is not digital

kubectl get pods -l "stage=canary,owner notin (digital)"

To get all pods in either canary or production and owned by digital

kubectl get pods -l "stage in (canary,production), owner=digital"

This finishes our post on labels and selectors , in the next post, which is also the last post of this section, we will look at Controllers.

The post Kubernetes Selector (Kubernetes course – 13) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-selector-kubernetes-course-13/feed/ 0
Kubernetes Labels and annotations (Kubernetes Course – 12) http://www.studytrails.com/devops/kubernetes/course/kubernetes-labels-and-annotations-kubernetes-course-12/ http://www.studytrails.com/devops/kubernetes/course/kubernetes-labels-and-annotations-kubernetes-course-12/#respond Fri, 08 Nov 2019 23:16:39 +0000 http://www.studytrails.com/?p=17018 In the previous post we talked about Namespaces. In this post I will cover Kubernetes Labels and annotations. Difference between

The post Kubernetes Labels and annotations (Kubernetes Course – 12) appeared first on StudyTrails.

]]>

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 selector while querying for the object. Annotation on the other hand is only used to provide additional information for the object.

Kubernetes Labels

Kubernetes labels allow adding additional information to Kubernetes objects and also allow selecting those objects using selectors. Lets look at an example. Open up the yaml that we used to deploy the static website.

Kubernetes Labels and annotations

The deployment consists of a deploymentSpec which contains podTemplateSpec. The podTemplateSpec describes what pods will be created. In the metadata of the podTemplateSpec we specify that the pod should have a label whose key is ‘app’ and value is ‘static-website’. We can also see in the yaml that the DeploySpec contains a selector that uses this label to find out which pods are affected by this deployment. In a way the label ties the pod or the replicaset to the deployment.
It is generally a best practice to use labels that can help identify, manage and organize objects. Labels are generally the most efficient way to give a structure to a Kubernetes cluster since there in inherently no structure in the cluster and it can be thought of as a loose collection of pods and services.

Recommended Kubernetes Labels


Kubernetes recommends certain labels such as app.kubernetes.io/name – for the name of the applications, app.kubernetes.io/instance – for the name of the instance. This is different from the application name since you can have multiple instances of the same application. For example, you can have multiple instances of wordpress. /version – for the current version of the application . /component – the part of the architecture e.g. a database. /part-of – the parent of this application. /managed-by – tool used to manage the application e.g. Helm.
These are the labels recommended by Kubernetes.

Kubernetes Labels and annotations

Good practices for Kubernetes labels

There are some good practices around labels. The first is to make sure that labels are used and they follow the same convention throughout the company. The second is to create a list of mandatory labels for any application deployed on Kubernetes. The list can contain labels such as application id, version, stage, release and owner. In addition to the mandatory list we can create a list of optional labels. This should be an exhaustive list so that any team can pick from it.

Kubernetes annotations


Annotations are used to add additional information to the objects. These include information such as build info, user info such as email addresses, monitoring info. for example, Prometheus uses annotations to store configuration information
This post gave an introduction to labels, in the next post we will deploy a set of applications containing various labels and then use selectors to select applications based on those labels.

The post Kubernetes Labels and annotations (Kubernetes Course – 12) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/course/kubernetes-labels-and-annotations-kubernetes-course-12/feed/ 0
Kubernetes namespace (Kubernetes course – 11) http://www.studytrails.com/devops/kubernetes/course/kubernetes-namespace-kubernetes-course-11/ http://www.studytrails.com/devops/kubernetes/course/kubernetes-namespace-kubernetes-course-11/#respond Wed, 06 Nov 2019 06:09:29 +0000 http://www.studytrails.com/?p=17008 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

The post Kubernetes namespace (Kubernetes course – 11) appeared first on StudyTrails.

]]>

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. 

Kubernetes namespaces

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

  1. Create logical partition within the cluster
  2. Controlled access to resources such as pods, services etc.
  3. Limit resource consumption for that namespace.
  4. 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

We can also use a  yaml to create a namespace. Lets do that next. Here’s the yml file that creates the development namespace

apiVersion: v1
kind: Namespace
metadata:
  name: development

we use kubectl apply and the filename to create the namespace. We can then describe the namespace using the describe command.

We will see how to deploy the Kubernetes static website that we created in the earlier video. To recap its a simple static website with an index.html that says Hello Kubernetes. We have created a docker image with that website. To make things more interesting though, lets create a quota that fixes a quota for  the total amount of memory in a namespace and the total number of pods in the namespace. To create the Resource Quota we create an object of type Resource Quota. Here’s how the file looks . 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: development-quota
  namespace: development
spec:
  hard:
    memory: "200Mi"
    pods: "2"

The type is ResourceQuota and we specify the namespace that the quota applies to. We can specify the namespace here or to the kubectl client . The specification gives the quota which is 200 mebibyte and number of pods is 2. We apply the ResourceQuota.

Once the quota is applied, we create the static website. Here’s the yml for the website. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubernetes-static-website
spec:
  selector: 
    matchLabels:
      app: static-website
  replicas: 3
  template: 
    metadata:
      labels:
        app: static-website
    spec:
      containers:
      - name: static-website
        image: kubernetes-static-website:latest
        imagePullPolicy: Never
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "50Mi"

It creates two replicas. We apply the deployment in the development namespace. We also need to specify the memory required. Note that the deployment will fail if we dont specify the memory since there is a quota attached to it. We now create the deployment.

This finishes our introduction to namespace. We have seen how we can set quota to namespace using the ResourceQuota object. In the later post we will look at how to restrict users from accessing different namespaces using RBAC or Role Based Authentication Control. In the next post lets look at Labels, annotations and selectors. See you in the next video and don’t forget to practice what you have learned today. The source code for all the videos are available on my github page.

The post Kubernetes namespace (Kubernetes course – 11) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/course/kubernetes-namespace-kubernetes-course-11/feed/ 0
Kubernetes Pod (Kubernetes course – 10) http://www.studytrails.com/devops/kubernetes/kubernetes-pod-kubernetes-course-10/ http://www.studytrails.com/devops/kubernetes/kubernetes-pod-kubernetes-course-10/#respond Mon, 04 Nov 2019 23:24:44 +0000 http://www.studytrails.com/?p=17002 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.

The post Kubernetes Pod (Kubernetes course – 10) appeared first on StudyTrails.

]]>

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. 

Kubernetes pod example

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. 

Kubernetes Pod


 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.

The post Kubernetes Pod (Kubernetes course – 10) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-pod-kubernetes-course-10/feed/ 0
Kubernetes Object (Kubernetes course – 9 ) http://www.studytrails.com/devops/kubernetes/kubernetes-course-9-kubernetes-object/ http://www.studytrails.com/devops/kubernetes/kubernetes-course-9-kubernetes-object/#respond Sun, 03 Nov 2019 00:03:43 +0000 http://www.studytrails.com/?p=16978 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

The post Kubernetes Object (Kubernetes course – 9 ) appeared first on StudyTrails.

]]>

In the previous post we looked at Kubernetes architecture, in this very short post lets look at Kubernetes object. 

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.

The post Kubernetes Object (Kubernetes course – 9 ) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-course-9-kubernetes-object/feed/ 0
Kubernetes Architecture (Kubernetes course – 8 ) http://www.studytrails.com/devops/kubernetes/kubernetes-course-8-kubernetes-architecture/ http://www.studytrails.com/devops/kubernetes/kubernetes-course-8-kubernetes-architecture/#respond Fri, 25 Oct 2019 03:12:34 +0000 http://www.studytrails.com/?p=16959 Welcome to this post on Kubernetes Architecture! In the last post we deployed a simple containerized static website to Kubernetes.

The post Kubernetes Architecture (Kubernetes course – 8 ) appeared first on StudyTrails.

]]>

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.

Kubernetes Architecture
Kubernetes Architecture


We refer to Kubernetes as a cluster since it contains multiple nodes. Each node can be an independent physical machine or a Virtual instance. For example, in AWS a m2.medium is one node and we would use multiple such instances to form a cluster.

Kubernetes architecture components

The cluster is divided into two major parts. The control plane and the worker nodes. kubectl or kube-ctl is the command line client used to communicate with Kuberentes.

Kubernetes control plane

The control plane is also known as the master. A single master node is enough to run a cluster, however for higher availability more than one master node can also be installed.

Kubernetes API Server

The first component in the control plane is called the API server. It exposes a restful API to manage Kubernetes objects such as pods, services and ingress. We will understand what those components are later but for now all that we need to know is that the API is our window into the Kubernetes cluster. Every action that we want to perform on the cluster goes via the API. In fact, the API is also the only way by which the various components of Kubernetes can talk to each other and can access the shared state

In the previous post we used a command line client called kubectl to deploy our static webiste. kubectl accomplishes the deployment by firing a series of requests to the API. The API definition is exposed on the master using swagger at the /swagger endpoint and OpenAPI at the /openapi/v2 endpoint. The API server serves REST operations. It is accessible from outside the cluster whereas the nodes and containers may not be accessible from outside the cluster.

Kubernetes cluster store – etcd

The next important component is the cluster state store. The state of the cluster is stored in a key-value storage known as etcd. etcd stores the cluster state in a consistent and fault tolerant way. Any change to configuration is persisted in etcd and then propagated to the other components.
etcd functions as a distributed data store and uses the concept of leader election. etcd therefore is most stable if it uses an odd number of nodes. Internally etcd is implemented as an immutable key value store. Any change to key value pair is stored as a new entry with a new version.In production systems it is important to backup etcd. The etcd client tool provides a backup utility that can be used.

Kubernetes Controller Manager Server

The third component in the control plane is the Controller Manager Server or kube-controller-manager. It performs lifecycle functions such as namespace creation or garbage collection. It also performs certain business logic such as scaling of pods. It is run as a daemon and is responsible for regulating the state of the system. The controller manager is a single binary that includes multiple controllers such as the
1. Node controller which manages various aspects of the nodes, such as responding when the nodes go down.
2. Replication Controller – Maintains the number of pods as specified in the replication controller object.
3. Endpoints Controller – Creates the endpoint object that joins services to pods.
4. Service account and Token Controllers that creates default account.
The controller watches some object for the systems desired state and it watches the systems actual state too. It then sends instructions to try and make the systems current state to be more like the desired state.

Kubernetes Scheduler

The last component of the control plane is the Scheduler. It is responsible for figuring out which node a particular pod should run on. It looks for pods that haven’t been scheduled and nodes that have capacity to host that pods. It considers various factors such as hardware or software constraints or data locality when assigning nodes to pods. It then tell those nodes to run the pods. Although the default Kubernetes installation provides a scheduler it is possible to use a user-provided scheduler.

Kubernetes worker nodes

Next lets look at the components present in the nodes. Each node contains Kubelet, container runtime and the kube proxy.

Kubelet

A kubelet is responsible for running the containers that a user specifies. The fundamental unit of execution is called a pod. A pod contains one or more containers and volumes. The kubelet runs a pod based on the specification provided by the user. This specification is known as PodSpec. The Containers that the kubelet runs are isolated from each other and also from the host. It is the kubelet that ultimately decides what pod can or cannot run on a given node and not the scheduler.

Kubernetes Container Runtime

Container Runtime – The nodes run a container runtime that is responsible for downloading images and running containers. This container runtime implements a container runtime interface or CRI that specifies requirements for a container runtime to integrate with kubelet. The most widely known container runtime is Docker, however the container runtime interface supports interchangeable container runtimes. Internally the kubelet communicates with the container runtime over unix sockets using the gRPC framework where the kubelet is the client and the CRI is a server. in CRI the pod environment is called PodSandBox. Before starting a pod, the kubelet creates the PodSandBox and sets up networking. The Kubelet is responsible for maintaining the lifecycle of the containers through RPC.

Kube proxy

The final component in the node is the kube proxy. The kube proxy allows to balance load between the various pods in the node. The main task of kube proxy is to program the iptables so that it captures the traffic to the service’s clusterIP and port and forwards the request to one of the service’s pods.

We have covered a lot of material in this post. We will go through some of the components in detail in the later posts. As we progress through the course, you will get more familiar with the various components. It would be worth coming back to this post after a while just to get reoriented.

The next short post introduces what Kubernetes objects are.

The post Kubernetes Architecture (Kubernetes course – 8 ) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-course-8-kubernetes-architecture/feed/ 0
Static website on Kubernetes (Kubernetes Course – 7 ) http://www.studytrails.com/devops/kubernetes/kubernetes-course-7-static-website-on-kubernetes/ http://www.studytrails.com/devops/kubernetes/kubernetes-course-7-static-website-on-kubernetes/#respond Wed, 23 Oct 2019 03:15:57 +0000 http://www.studytrails.com/?p=16946 In this post I will guide you through the process of deployment of a static website on Kubernetes on Minikube.

The post Static website on Kubernetes (Kubernetes Course – 7 ) appeared first on StudyTrails.

]]>

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 website on Kubernetes – create docker image

The first step is creating the docker image. We will use the docker Runtime from Minikube so that the image is available to Kubernetes. In production you would have Kubernetes download the image from a repository. To use the docker Runtime type in minikube.exe docker-env . It will give you the steps to setup the environment variables so that your docker points to the Runtime from Minikube. The screenshot shows how we have done it. Make sure that when you type in docker.exe images you see the images from Kubernetes.

Docker runtime from Minikube

The static website for us is a plain HTML page that has a single header that says Hello Kubernetes.

To create the image we first create the Dockerfile which uses httpd as the base. httpd or apache server sets /usr/local/apache2/htdocs as the base directory for the website. We copy the index.html file to this directory. When the docker container starts it will start the Apache Webserver and serve pages from this directory.

To build the image type in docker build -t , which is the tag name, kubernetes-static-website followed by dot. Docker will look for the dockerfile in current directory and use it to build the image. If you type in docker images, you should now be able to see the image. We will now deploy the image.

Static website in Kubernetes – create YAML files

To deploy we use the static_website_deployment.yml file. Lets look at what the file contains.

The content might not make sense now, but we will go through its details later on. For now, you need to understand that it is written in YAML format. The keyword kind tells Kuberentes that this file contains Deployment information and Service Information. The deployment specifies the image that will be deployed. In this case its the kubernetes_static_website image that we just created. The YAML also specifies that we need two instances or replicas of the website. We tell Kuberentes to open up port 80 from the container. imagePullPolicy is set to Never since we do not want to download the image from the repository.

We also specify a service in addition to the deployment. Service creates network rules to allow access to port 80 on the container that we opened. In this case we created a service of type NodePort since we want the website to be available outside the clusters. We will cover services in details in a later section. The service says that the website will be available at port 30500. In production we will create a service, an ingress controller and a load balancer to make the website available to end user. This website will be highly available since it has multiple replicas. We can also easily scale the application by increasing the replicas and Kubernetes will take care of adding the new replicas to the load balancer or the ingress controller. The steps to deploy the application are same as what we saw earlier, but let me repeat them here for sake of completeness.

> kubectl get deployments
> kubectl get pods
> kubectl apply -f static_website_deployment.yml
> kubectl get deployments
> kubectl get pods
> kubectl get services

Hope you had fun creating your first deployment in Kubernetes. Don’t worry if it doesn’t make much sense right now. We will cover each of the concepts that you saw here in great details later on.

In the next Section we will look at the architecture of Kubernetes and understand some of the key concepts.

The post Static website on Kubernetes (Kubernetes Course – 7 ) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-course-7-static-website-on-kubernetes/feed/ 0
Minikube on windows (Kubernetes course – 6 ) http://www.studytrails.com/devops/kubernetes/kubernetes-course-6-minikube-on-windows/ http://www.studytrails.com/devops/kubernetes/kubernetes-course-6-minikube-on-windows/#respond Tue, 22 Oct 2019 01:09:31 +0000 http://www.studytrails.com/?p=16932 In the previous post we saw an introduction to Kubernetes. Before we go into the architecture of Kubernetes let us

The post Minikube on windows (Kubernetes course – 6 ) appeared first on StudyTrails.

]]>

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 of installing Kubernetes on minikube is to try out Kubernetes on local machine before going through the process of installing it on a production cluster. It also provides a development environment on a laptop. The steps to install Minikube can be found on its github page. In this post we will use minikube on windows machine. The installation for any other platform is very straight forward so you should hopefully have no problem installing it. You can follow the course even if you chose not to install it, however, for a deeper understanding I would recommend that you try the steps out as you see them in the post.

Minikube on windows – Installation steps

Minikube on windows

We will use the Oracle Virtual Box to install Minikube. To install Virtual box follow the steps on https://www.virtualbox.org/wiki/Downloads . Note that on a windows 8 or 10 machine, if you use Virtual Box you would need to disable Hyper V. A simple search on google with the search string ‘turn off hyper v’ should give you couple of links that show how to disable it. Once you install Virtual box and disable Hyper V install minikube by following the steps on the github page.

The last piece of software that we need is Docker tools. We need that not for Kubernetes but for building the sample app container that we will deploy on Kubernetes.

I have also installed ubuntu for windows since it gives a nice terminal to work with. You can download that or use PowerShell.

I have installed minikube using chocolatey which is a package manager for windows. Once its installed open up the terminal and type in ‘minikube start’. This downloads and starts minikube on your local machine. The download is around 170 to 200 MB. After the download finishes, minikube might take a while to start.

This is how the terminal looks after minikube has started. To see whether minikube has started successfully type in ‘minikube.exe status’. It says that minikube has been installed, the kubernetes cluster has been installed and kubectl is correctly configured.

Kubectl and config file

You must be wondering what kubectl is. kubectl also sometimes called as kube-ctl is a Kubernetes command line client. It allows you to talk to Kubernetes cluster and perform operations on it. If you look into your home directory you should be able to see a directory called .kube. This directory has a file named config. This file contains credentials that allows the kubectl client to authenticate to the cluster. The file contains the information about the cluster that you want to connect to. You can use the client to connect to different clusters and we will see in the later posts, how to do that. Our Kubectl client uses a client certificate and key instead of a username and password to authenticate. We will see different ways in which we can authenticate to the Kubernetes cluster.

Kubernetes config file

If you have followed the installation steps, you should have a working single node cluster on your laptop. Congratulations on installing your first Kubernetes cluster! In the next post we will install our first application on Kubernetes and after that we will go back to theory and understand the Kubernetes architecture and its various components. So see you in the next post!

The post Minikube on windows (Kubernetes course – 6 ) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-course-6-minikube-on-windows/feed/ 0
What is Kubernetes? (Kubernetes Course – 5 ) http://www.studytrails.com/devops/kubernetes/what-is-kubernetes/ http://www.studytrails.com/devops/kubernetes/what-is-kubernetes/#respond Tue, 22 Oct 2019 01:06:16 +0000 http://www.studytrails.com/?p=16926 In the previous post we saw a brief overview of containers and we also understood why the industry is moving

The post What is Kubernetes? (Kubernetes Course – 5 ) appeared first on StudyTrails.

]]>
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.

What is Kubernetes?

Lets begin by defining what Kubernetes is. It is an open source system for managing containerized applications and provides mechanisms to deploy, maintain and scale them across multiple hosts spread across on premise and cloud. It is more than a container orchestration platform because it also takes care of managing the compute, network and storage infrastructure.

Let me explain that with an example. Imagine an application consisting of 10 different containerized RESTful APIs written in different languages such as Java, PHP and NodeJS. You need to deploy these containers such that :
1) They are deployed in multiple servers to handle load balancing and high availablilty.
2) They can be scaled as required.
3) They can be upgraded without any downtime or with minimal downtime.
4) The services can easily talk to each other and discover each others end points.
5) The deployment as well as number of replicas can be maintained as code.
6) The whole platform can be maintained as code and accross bare metal and cloud platforms.

To get a better feel about what Kubernetes can do, lets read some of the case studies as highlighted on their website.

The first case study is from box. They are a content management company and have more than 50 million users. As they were expanding they wanted to find a solution to run their workloads accross on premise and public cloud. To do that they have started migrating their infrastructure to microservices and have been an early adapter as well as contributor to Kubernetes. The advantage as in their own words is “Our Infrastucture was so antiquated it was taking us more than six months to deploy a new microservice. Today, a microservice takes less than five days to deploy”

The second case study is from Huawei. It is a multinational telecommunications equipment manufacturing company. They have more than 800 applications in 100K+ VMs to server 180000 employees. With increase in number of applications the efficiency of VM based apps becomes limiting. They migrated to Kuberenetes and at the end of 2016 they had more than 4000 nodes with tens of thousands of containers maintained as platform as a service. According to them “the global development cycles decreased from weeks to minutes, and the efficiency of application delivery has improved 10-fold’

I hope you are as excited about learning Kubernetes as I am to walk you through it. My aim is to introduce you to all aspects of Kubernetes and also help you to try out some of the core functionalities. We begin my setting up a single node cluster on the laptop using minikube. See you in the next lecture!

The post What is Kubernetes? (Kubernetes Course – 5 ) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/what-is-kubernetes/feed/ 0
Monolithic to Microservices (Kubernetes Course – 4 ) http://www.studytrails.com/devops/kubernetes/kubernetes-course-4-monolithic-to-microservices/ http://www.studytrails.com/devops/kubernetes/kubernetes-course-4-monolithic-to-microservices/#respond Sun, 20 Oct 2019 07:16:59 +0000 http://www.studytrails.com/?p=16921 The last topic before we start looking at Kubernetes is to understand why the world is moving from Monolithic to

The post Monolithic to Microservices (Kubernetes Course – 4 ) appeared first on StudyTrails.

]]>
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.

Monolithic to Mircroservices

A few years back we had huge monolithic applications that were deployed as huge standalone applications on dedicated servers. For example, consider a banking website. Traditionally you would have a single web frontend that talks to a huge backend which in turns talks to a database. To achieve high availability you would have to horizontally scale the application to multiple servers . Every time something changes in the application, you would have to test and redeploy the whole thing. Also, the code passed through multiple environments such as developers machine, test environment, staging, production and so on. Each of these environments would have minor differences and there was no guarantee that the application would behave in the same way in all the environments.

People then realized that instead of building a single monolithic application, it was prudent to build smaller applications or services that talk to each other via RESTful API or messaging to accomplish the same functionality. Also, with smaller services it was possible to deploy them independently. With the advent of services, the industry also moved to containers since now it was possible to deploy those services along with their dependencies as containers onto a platform that allowed the containers to be created and scaled easily.

Currently, most enterprise applications are moving towards a microservices architecture with applications deployed as containers on an enterprise container platform such as Kubernetes which is hosted on premise or in the cloud with provides such as AWS, google cloud or Azure.

In the next Post we will see an introduction to Kubernetes and then in later video delve into its details.

The post Monolithic to Microservices (Kubernetes Course – 4 ) appeared first on StudyTrails.

]]>
http://www.studytrails.com/devops/kubernetes/kubernetes-course-4-monolithic-to-microservices/feed/ 0