Hello, here is Part 2 of the Let’s Learn Kubernetes series. If you want to read Part 1, you can follow Let’s Learn Kubernetes – Part 1
Deployment and StatefulSet
In this example, now everything is running perfectly without any issue and the user can access the application via a browser.
When the Application container dies in Node 1, automatically another Application container can handle the requests on Node 2. Even if the Node 1 host can completely fail, in this scenario Node 2 will handle all requests with database operations.
If you are just running the application on a single node and when something goes wrong, you will get downtime and the users can not access your application as well. Do not run a single node in production. You should replicate everything on multiple servers and/or nodes!
Service has two functionalities.
- Static IP: It comes with DNS Name. It means you do not have to adjust anything on the network level when your pod dies.
- Load Balancer: The service is catching all requests and makes a decision to send users’ requests directly to pods which is less busy.
If you want to create a second replica of the application, basically, you can not create pods, we are calling it “Deployment“. You can define blueprints for pods for the application and specify how many pods you want to run. Deployment is another component of Kubernetes. Practically, you are not creating and/or working with pods, you need to create Deployments for replication and scale-up/scale-down needs. The pod means an abstraction layer on the containers and the deployment is another abstraction layer as well.
We cannot replicate the database using a deployment because databases have a state which is data. It means if you have clones or replicas of the database all we need is to access the same shared volume (storage of data) and you need a mechanism to manage which pods will write to data volume and which pods will read a data from the volume. It’s all about Avoid data inconsistencies. You can use another Kubernetes component called StatefulSet. You should use StatefulSet for applications like databases like Redis, MongoDB, ElasticSearch, PostgreSQL, and MySQL, …
The k8s Architecture
There are two types of Kubernetes nodes that operate. One is the master and another one is a slave. Let’s learn what is differences between them and understand the roles each one has inside of the cluster.
All managing processes are done by Master Nodes. Master nodes are really different than nodes. Master nodes control these operations:
- Schedule the pods
- Monitor the pods
- Re-schedule and/or re-start pods
- Accept the new node to join to cluster
All master nodes should install these components.
- API Server: When you deploy a new application, it talks with API Server. We can call API Server as a cluster gateway. It acts also a gatekeeper for authentication. If you have a UI to manage your cluster, it is also talking with API Server as well. API Server also talks with Scheduler to run the new pod(s).
- Scheduler: Scheduler is deciding which pod should run into The node. It knows how many resources you are using and how many resources are available (such as CPU, RAM, etc.). Which node has more resources, Scheduler is running the new pod(s) in it.
- Controller Manager: Checking the states of the cluster and detecting the latest state of pods like crashing or something goes wrong. The Controller Manager tries to re-run failed pods and it talks with Scheduler immediately. The Scheduler decides to run the pod(s) on which node(s).
- etcd: It’s like a brain of Kubernetes cluster and keeping the state changes like KEY:VALUE and it stores this information in it. When you send a request to API Server for checking the states of pods, this information comes through etcd and etcd is keeping all of the information as well. etcd does not store application data, it’s just storing information about the Kubernetes cluster.
Let’s think of a node that is running two different pods in it. One is the application and the other is the database. One of the main Kubernetes architectures are worker servers/nodes.
- Each Node should have multiple Pods on it
- Three processes should be installed on every Node (Container Runtime, kubelet, and Kube Proxy)
Now, you know the Deployment, StatefulSet, and Kubernetes architecture. I hope you enjoyed this article! You can follow me on Twitter (https://twitter.com/flightlesstux) to know when Part 3 is coming…