KUBERNETES

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 https://www.youtube.com/watch?v=X48VuDVv0do

 Credits to the owner of this course over Youtube .This is notes made for my reference using her tutorial

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Course Content :

The first part gives you great introduction to Kubernetes . 

• We will start with the basics of what Kubernetes actually is what problem it solves .
• K8 Architecture
• You will learn how you can use Kubernetes by showcasing all the main components 
• We we learn to install Minikube for a local kubernetes cluster 
• And we go by the main command of creating , debugging, deleting pops using Kubectl -- which is Kubernetes command line tool .
• I will explain Kubernetes YAML configuration files which we will use to create and configure components .
• Then we will go through a practical use case where we will deploy a simple application setup in Kubernetes cluster locally to get your first hands on experience with Kubenetes and feel more confident about the tool .
• In the second part we will go into a more advance concept like organizing your components using namespaces . How to make your app accessible from outside using Kubernetes Ingress and learn about Helm which is the Package Manage for Kubernetes . 
• In addition we will look at three components in more detail 

1. How to persists data in Kubernetes using Volumes .
2.  How to deploy stateful applications like Databases using Stateful set components 
3. And lastly we will look into different Kubernetes service types for different use cases .
   

 

What Kubernetes Is ?

• Kubernetes is an Open source Container Orchestration framework - Which was originally developed by Google . 
• So on the foundation it manages containers , be it Docker container or any other technology . 
• Which means helps you manage containerized applications . It manages 100 or 1000s of containers and it helps you manage them in different environments . Like (Physical Machine / Virtual Machines and Cloud Environment ) . Even Hybrid deployment environment .

 

The rise of micro services caused the use of container technologies . Because container usually offer the perfect host for small , independent application , that are now comprise of 100s of even 1000s of containers

 

Now managing all those containers in multiple environments using Scripts and Self Made tools can be really complex and sometime even impossible . That specific scenarios gave raise to the need of having containers orchestration tool . 

What are the feature do orchestration tools offer ?

• High Availability  -- The application has no downtime .
  
• Scalability or High Performance -- Application has high performance . It loads fast and the users have a very high response time from the application .
• Disaster Recovery  - Backup and restore -- It basically means your infrastructure has some problems like the data is being lost or something bad happens in the server center  . The infrastructure should have some method to pickup the data and restore it to the latest date . and the application does not lose any data .

 All these features are something like container orchestration tool like Kubernetes offer .

 

Most basic fundamental components of Kubernetes . That is just enough for you to get started with Kubernetes either as a DevOps engineer or a software developer . Kubernetes has a tons of components but mostly you will be working with just a hand full of them .

So I am going to build a case of a simple Java Script Application - with a simple database . I am going to show step by step how each component of Kubernetes  helps you to deploy your application . And what is the role of each of these components.

1. Node and Pod :

Lets start with the basic Node or Worker Node and in Kubernetes terms a Node - which is a simple server it can be a Physical or a Virtual Machine .

And the basic component or the smallest Unit of a Kubernetes is a  Pod . 

Pod is basically an Abstraction over a Container . If you are familiar with Docker containers or container images , what this Pod does is it creates this running environment or a layer on top of the  container . Reason is the Kubernetes wants to abstract away the container run time or container technologies so that you can replace them if you want to and also because you do not have to work with docker directly or with the container technology.

You only have to interact with the Kubernetes Layer .

So we have an application Pod which is our own application and that will may be use a Database . Pod with its own container .

And this is also an important concept here . Pod is usually meant to run one application container inside of it . You can run multiple container application inside one Pod But is usually the case when you have one main application container and then a help container some side service that has to run inside of that Pod. 

Now lets see how they communicate with each other in Kubernetes world

Now Kubernetes offer out of the Box a Virtual Network . Each Pod gets its own IP address.

Not the container . The Pod gets the IP address . Now Each Pod can communicate with each other with its IP address . It is an internal IP Address and not the public one . So my application container can communicate with the Database using the IP Address . However Pod components in Kubernetes also have an important concept are Ephemeral (Which means they can die very easily ). And when that happens.

 

For example if I lose a Database Container , because the container crashed or the application crashed inside . The nodes the server that I am running them on ran out resources the Pod will die and a new one will get created in its place . And when that happens it gets assigned with a New IP Address . Which obviously is inconvenient if you are communicating with the database using the IP Address . Now you will have to adjust it every time when the Pod restarts . Because of that another component in Kubernetes "Service" is used

Service and Ingress :

• Service is basically a Static IP Address or Permanent IP Address . That can be attached to each pod . So my Web App Pod will have its own service and my database will its own service .
  
  
  

And the good thing here is that the life cycle of the Pod and the service is not connected so ever if the Pod dies . Its Service or the IP address will stay. So you do not have to change that in the End Point .

And now you would want your application to be accessible via a browser right and for this you will have to create an external service

External Service is something that opens the communication from external sources . But obviously you do not want your database to be open to the Public request . And for that you will create something called an Internal service .

So this is a type of service that you specify when creating one. However , if you notice the URL of the External Service is not very practical .

Basically you have in http protocol a Node IP address - of the node not the service

And the port no of the service which is good for test purposes if you want to test something very fast. And not for the end product .

Usually you would want your URL to look like this. 

If you want to talk to your application with a secure protocol and a domain name. And for that we have another component of Kubernetes called Ingress

So instead of service the request first goes to Ingress , it does the forwarding then to service

So now we saw some of the basic components of Kubernetes . And as you see this is a very simple setup . One server with a couple of containers running and some services  . Nothing really special where Kubernetes  advance or cool features come forward. But we are going to get there step by step .

As I said Pods communicate with each other using a service . My application will have a database end point lets call it Mongo db service that it used to communicate with the database .

But where do you configure these database or the End Points  , Usually you will do it in Application Properties file or some kind of external environmental variable . But basically it is inside of the build image of the application . For example if the service or the service name gets changed to mongo db you would have to adjust that URL in the application . Usually you will have to rebuild the application with a new version , you have to push it to the repository and now that you have to pull that new image to your Pod and restart the whole thing . So little bit tedious for  a small change like database URL .

And for that purpose , Kubernetes has a component called ConfigMap

ConfigMap :  so what it does is your external basic configuration of your application . ConfigMap usually would contain configuration such the URLs of the database or some other services that it use . And in Kubernetes you just connect it to the Pod .  So that Pod actually gets that data what ConfigMap contains . And now if you change the name of the service .

You just adjust the ConfigMap and that's it , you do not have to build a new image . You do not have to go through this whole cycle .

Not Pod of the  external configuration it could be

1. Mongo-db
2. User
3. Pwd
   

which may also change in the application deployment process .

But putting a Password credentials in a plain text format in a ConfigMap will be insecure , even though it is an external configuration . For these purpose , Kubernetes has another component called "Secret"

Secret : Secret is just like ConfigMap but the difference is that it is used to store secret data, credentials for example and it is stored not ina plain text format of course but in a base64 encoded format .

Secret would contain things like credentials .

You can put database users also in Config Map but what is important is that Passwords Certificate things that you don't want other people to have access to would go in the secret . And just like ConfigMap you just connect it to a Pod so that . The Pod can actually see those data and read from the secret . You can use the data from ConfigMap or Secret inside of your application Pod , using for example Environmental Variables or even as a properties file .

And now to look at we have almost looked at mostly used , Kubernetes basic components .

We have looked at the Pod , we have seen how services are used , what is Ingress component useful for and have also seen external configuration using ConfigMap and secrets .

And now let see very important concept which is Data Storage , how it works in Kubernetes . 

Data Storage :  So we have this database Pod that our application uses and it has some data or generates some data , this setup that you see now

If the database container or the Pod gets restarted the data would be gone and that is problematic , because you want you data to be reliable and persistent for a long term .

And what you can do is by another component of Kubernetes called Volumes .

And how it work is it basically attaches a Physical storage , a Hard drive to your Pod .and then it can be on the local machine , same server node . where your Pod is running .

Or it can be on a Remote storage  . Meaning outside of the Kubernetes Cluster . It could be your cloud storage or it could be your on=premise storage which is not a part of your Kubernetes Cluster  . So you just have an external reference on it.

Now if the container of the Pod gets restarted , all the data all the data will be there, persistent .

It is important to understand the distinction between the Kubernetes Cluster and all of its components and the storage . Regardless of whether it is a local or remote storage . Think of this storage as an external hard drive plugin into the Kubernetes cluster . Because Kubenetes it self does not manage any data persistence , which mean you as a Kubernetes user or Administrator are responsible for backing up the data , replicating and managing it making sure it is kept on a proper hardware etc , because it is not taking care of Kubernetes .

Now you see everything is working perfectly and users can access the application through a browser. 

With this setup what happens if my Application Pod dies . Or i need to restart Pod because I build a New container Image . Basically I will have down time for my user to reach my application . And it is a bad think if this happens in Production . So instead of just relying in in just one application Pod or one Database Pod  , we are replicating on multiple servers , so we will have another node where were we would have a replica or a clone of our application would run which will also be connected to the service

Remember what we said about service . A service is a persistent static IP address with a DNS name so you don't need to adjust the end point when Pod dies . 

A Service is also a Load balancer which means . which means the service will catch the request and forward it to a Pod which is less busy .

it has both of these functionalities. But in order to make the second replica of my application Pod . You wouldn't create a second Pod but instead you will define a blue print for my application pod and specify how many replica of that pod that you would like to run .

This blue Print or component is called Deployment  which is an another component of Kubernetes. But in practice you will not be working with Pods or you will not be creating Pods , you will be creating deployments because there you can specify how many replica you would want . Which will help you to scale up and scale down with number of replicas you need .

With Pod we said that Pod is a layer of Abstraction , on top of containers , Deployment is another abstraction on top of Pods.

This makes it very convenient to interact with the Pods . So if once the App Pod die the service will forward the request to another one .

So your application will still be accessible for the user . So now you are probably wondering what about the database Pod . If your database Pod dies your application as well will not be accessible . So we need a database replica as well . 

However we cannot replicate database using Deployment and the reason for that is that the database has a state which is its data , which means if we have clones and replicas of the database they should access the same data storage

And there you need some kind of mechanism that manages which Pods are currently writing to that storage , or which Pods are reading from the storage to avoid data inconsistencies and that mechanism in addition to replicating feature is offered  by another Kubernetes Feature called "StatefulSet "

"StatefulSet " This component is specifically meant for application like databases . So MySQL mongo DB , elastic search or any other stateful application or databases should be created using Statefulsets and not Deployments .

It is a very important distinction . And Statefulsets just like deployment will take care of replicating the Pods for scaling them up or scaling them down . By making sure that Database reads and writes are synchronized so that no database inconsistency are offered.

However i need to mention here that deploying database application using Statefulset in Kubernetes cluster is not easy and is bit tedious . So it definitely more difficult than working with deployments .

That's why it is a common practice to host the database application outside of Kubernetes cluster . And just have the deployment or Stateless Applications which does not have any problem inside of Kubernetes cluster and communicate with external database . So now that we have two replicas of my Application Pod and Two replicas of my database Pod . They are now load balances and our setup is more robust .

Which means if the Node 1, the whole Node was actually rebooted or crashed and nothing could run on it we will simply have a second node which application and database Pods running on it and the application would be still accessible by the user .

Until this two replica gets recreated . So you can avoid application down time .

Yes there are lot more components that Kubernetes Offers but these are the most used components 

BASIC ARCHITECTURE OF KUBERNETES

We are going to look at two types of nodes that Kubernetes operates on 

• Master
• Slave

And we are going to see what is the difference between those . Which role they have inside of a cluster. And we will go into the basics of how Kubernetes does what it does . And how the cluster is self managed and self healing and automated . And how you as an operator of  Kubernetes end up having much less manual effort. 

NODE PROCESSES

We are going to start off with this basic setup of one Node with two application Pods running on it.

one of the main k=components of Kubernetes architecture is its work nodes or nodes . And each node will have multiple application Pods or containers running on that node . 

And the way Kubernetes does is using 3 processes which must be installed in each Node . That are used to schedule and Manage those Pods . So Node are the cluster server that actually does  the work sometime also called the worker nodes.

Processes 

1 Process that needs to run on every Node is the "Container Runtime"

"Container Runtime" :  In our example we have Docker for applications will be running in container and a container runtime needs to be installed on every node . The process that actually schedules those Pods , and containers underneath is Kublet which is process of Kubernetes it self . Unlike container run time that has interface , it interacts with both the "Container Runtime" and Nodes / Machines itself because . because at the end of the day the kublet is responsible for taking that configuration and running a Pod or start a Pod with container inside . And then assigning resource from that node to that container . Like CPU RAM and storage resources.

Usually Kubernetes cluster is made up of multiple nodes which also must have - Container Runtime and Kublet services installed and you can then hundreds of those worker nodes which will run other Pods , containers and replicas of the existing Pods like my app and database Pods in this example , The way the communication between them works is using services which is sort of load balancer which directly catches the request directed to the Pod for the application like database for example and forward it to respective Pod .

The third process which are responsible for forwarding the request from services  to Pods - Kube-Proxy --  And also must me installed on every node .

Kube -Proxy has intelligent request forwarding logic inside . It also makes sure that the communication works in a expected way . For example my app is making a request to the database instead of service randomly forwarding the request any replica  , it will actually forward it to the replica that is running on the same node , the Pod that initiated the request , this way avoid the network overhead. 

Important two Kubernetes process - Kublet and Kube-proxy must be installed on all worker nodes . Along with an independent container run time. In order for the Kubernetes cluster to function properly . Now the question is how do you interact with this cluster

1. Do you decide in which node the new application Pod or a database Pod should be scheduled .
2. Or if a replica Pod dies what process monitors it 
3. Who reschedules it and / restarts it again  .
4. Or when we another server how does it join the cluster to become another node and get Pods and another components created on it.

All these managing processes is done by Master Nodes. 

Master Processes : So Master servers have completely different processes running on it and these are the four processes running on every Master Node that control the cluster state and the worker nodes as well. 

1. First service is the API server.

So you as a user want to deploy a new application in a Kubernetes cluster you interact with the API service using some client , it could be UI like kubernetes dashboard, Can be command line tool like Kubelet or a Kubernetes API . So API server is like a Cluster gateway which gets the initial request of any updates into the cluster , even the queries . So it acts as a Gate-Keeper for authentication to make sure only authorized request gets through the cluster .

That means whenever you want schedule new Pods