Kubernetes
Kubernetes is a tool that helps manage applications that are packed into containers and run in different environments. It’s needed because as applications become more complex and are made up of many smaller parts (microservices), it can be hard to keep track of them all. Containers also make it easier to deploy applications, but it can be challenging to manage many of them at once.
Kubernetes offers several important features to help manage containers. One of the most important is high availability, which means that the application is always accessible to users, even if some parts of the system fail. Kubernetes also allows for high performance by quickly scaling the application up or down as demand changes, making it more flexible to changing loads.
Another key feature is disaster recovery, which means that if something goes wrong and data is lost, Kubernetes can help restore the application to its latest state. This helps prevent data loss and ensures that the application can run as intended. Overall, Kubernetes helps simplify the management of complex applications made up of many smaller parts, making it easier to deploy and maintain.
Main Kubernetes Components
Nodes & Pods
Kubernetes has two main components that work together: Nodes and Pods.
A Node is simply a server, either a physical or virtual machine, that runs the Kubernetes software. It’s where the containers will be deployed and run.
A Pod is the smallest unit in Kubernetes, and it’s an abstraction over a container. A Pod is meant to run a single application container, and each Pod gets its own IP address. This allows Pods to communicate with each other using that internal IP address.
However, Pods are ephemeral, meaning they can die or be replaced very easily. This can cause problems if you need to communicate with a Pod that is constantly changing its IP address. That’s why Kubernetes has another component called a Service, which helps make Pods more stable and reliable.
In summary, a Node is a server that runs Kubernetes, and a Pod is the smallest unit in Kubernetes that runs an application container. Each Pod gets its own IP address, but because Pods can be ephemeral, Kubernetes has a Service component to help make communication between Pods more reliable.
Service & Ingress
In Kubernetes, a Service is a way to create a permanent, static IP address that can be attached to each Pod. Even if a Pod dies or gets replaced, the Service and its IP address will stay the same. This helps make communication between Pods more reliable.
Get Büşra Erçelik’s stories in your inbox
Join Medium for free to get updates from this writer.
However, to make your application accessible through a browser, you’ll need to create an external Service. This will give your application a URL that can be accessed outside of the Kubernetes cluster. The URL will typically look something like this: https://124.89.101.2:8080, where the IP address is the address of the Node and the port number is the Service port.
But what if you want your application to have a secure protocol (HTTPS) and a domain name like https://my-app.com This is where the Ingress component comes in. Ingress allows you to route traffic into the Kubernetes cluster based on the URL path and domain name. This makes it possible to access your application with a secure protocol and domain name, just like any other website.
So, in summary, a Service in Kubernetes provides a permanent IP address for each Pod, and an external Service makes your application accessible through a browser. Ingress allows you to route traffic into the cluster based on the URL path and domain name, making it possible to access your application with a secure protocol and domain name.
ConfigMap & Secret
In Kubernetes, Pods communicate with each other using a Service. However, if the endpoint of the Service or Service name changes, you would have to manually adjust the URL in your application. This process can be tedious, especially if you have to rebuild and push a new version of your application.
To make this process easier, Kubernetes has a component called ConfigMap. A ConfigMap is used to store external configuration data for your application. This can include settings like URLs, ports, and other non-confidential information. ConfigMaps allow you to update the configuration data without having to rebuild and push a new version of your application.
Kubernetes also has another component called Secret. A Secret is similar to a ConfigMap, but it is used to store sensitive or confidential data, such as passwords, certificates, and other credentials. Unlike ConfigMaps, Secret data is stored in an encrypted format using third-party tools in Kubernetes. This helps ensure that your sensitive data is protected.
So, in summary, ConfigMaps and Secrets are used in Kubernetes to store external configuration data and sensitive information, respectively. ConfigMaps are used for non-confidential data, while Secrets are used for confidential data like passwords and credentials.
Deployment & StatefulSet
To ensure that our application is always accessible, we don’t rely on just one application pod or database pod. Instead, we replicate everything on multiple servers so that we have backups. This is done by creating a blueprint for our application pod called a Deployment, which specifies how many replicas we want to run.
The Service component is used to provide a static IP address and load balancing to forward requests to whichever pod is least busy.
So in practice, we create Deployments rather than individual pods, because Deployments make it easier to interact with pods, replicate them, and scale up or down the number of replicas as needed.
When using Kubernetes, we replicate our application and database pods to prevent downtime in case of pod failure. For applications, we use a Deployment blueprint to define how many replicas of the application pod we want to run. Service is a static IP address and load balancer which forwards requests to the least busy pod. However, we can’t replicate databases using Deployment because databases have a state, which is its data. To manage data inconsistencies, we use another Kubernetes component called StatefulSet. StatefulSet is meant specifically for databases like MySQL, MongoDB, and ElasticSearch. Deploying StatefulSet can be challenging, so many databases are hosted outside the Kubernetes cluster, and only the stateless applications are replicated and scaled inside the cluster.
