In this article we are going to understand the main Kubernetes Components that we as Kubernetes Administrators or users will be working with most of the time.
You do not have to deal directly with Docker or any other Container technology in Kubernetes. You only interact with Kubernetes layer.
NOTE: Kubernetes Master Node is now called Control Plane
Pod
Pod is the smallest possible unit in Kubernetes just like Container is smallest unit in Docker. Container are created inside the Pod. Also, there are Shared Volumes and Shared network resources, example - IP Address.
Whenever we create a Container in Kubernetes, we actually create something called Pod and inside that Pod we have our Container.
So when you think about Kubernetes think about Pods as containers but technically Containers are inside the Pods and also you can have multiple Containers inside these Pods but usually you have one Container inside one Pod.
Each Pod in Kubernetes has its own IP Address, through which each Pod can communicate with each other using the IP Address which is an internal IP Address, its not the public IP. Keep in mind that its the Pod who gets IP Address not the Container.
Here is an example of Node having two Pods:
Also an important concept is that Pods are Ephemeral, which means they can die very easily and when that happens, For example if we lose our database container because container crashed because application crashed inside or the Nodes or server we are running them on ran out of resources, the pod will die and a new one will be created in its place and when that happens it will be assigned a new IP address which obviously is inconvenient if you are communicating with a database using IP address because you have to adjust it every time Pod restarts and because of that another component of Kubernetes called Service is used.
Service
Service is basically a static IP address or permanent IP address that can be attached to say each Pod. So in example above my-app will have its own service and database will have its own service and good thing here is that LifeCycle of service and pod are not connected so even if Pods dies the service and its IP address will stay. So you don't have to change that endpoint anymore.
So now you want your application to be accessible through a browser and for this you would have to create an External Service.
External Service is a service that opens the communication from external sources but obviously you wouldn't want to open your database to be open to the public requests and for that you would create something called an Internal service.
Internal Service is a type of Service that you specify on creation.
Ingress
Since the external service's URL, http://116.69.103.5:8080, is not very practical, what you really have is a http protocol with the Node IP address(IP address is of the Node not the Service) and Service's port number. It's for test purposes if you want to test something but not for the end products.
As a result, if you wish to communicate with your application using a secure protocol and a domain name, your URL should typically look like this: "https://myUrl.com".
This is where we use another component of Kubernetes called Ingress.
So instead of Service request first goes to Ingress and it does the forwarding then to the Service.
ConfigMap
We know that Pods communicate with each other using a Service so our application will have Database Endpoint lets say called mongo-db-service that it uses to communicate with Database.
Where do you configure this Database URL or Endpoint?🤔
Well usually you will do it in application properties file or in some kind of external environmental variable but usually its inside of the built image of the application.
For example, If the end point of the service, or service name in this case, changed to mongo-db, you would have to adjust that URL in the application, which usually means rebuilding the application with a new version, pushing it to the repository, and then pulling that new image into your pod and restarting everything.
So that is little bit tedious for just a small change like database URL.
So for this purpose Kubernetes has component called ConfigMap
ConfigMap is basically your external configuration to your application so ConfigMap would usually contain configuration data like URL's of Database or some other services that you use and in Kubernetes you just connect it to the Pod so that Pods actually gets the data that ConfigMap contains.
So, if you change the name of a service or the endpoint of a service, you only need to edit the ConfigMap; you don't need to build a new image or go through the entire cycle.
Secret
Now Database Username and Password, can also be part of the external configuration which may change during the application deployment process but putting a password or other credentials in ConfigMap in plain text format would be insecure even though it's an external configuration so for these purpose Kubernetes have another component called Secret.
Secret is similar to a ConfigMap, but the difference is that it is used to store secret data such as credentials and is stored in Base64 encoded format rather than plain text. However, this format does not automatically make it secure; the secret elements are meant to be encrypted using third-party tools in Kubernetes.
Just like ConfigMap, you link it to your Pod so that it can view and read the data from Secret.
You may use data from ConfigMap or Secret within your application Pod, such as Environment Variables or even as a properties file.
In the next article we'll take a look at the Data Storage concept of Kubernetes and see how it works.
Top comments (0)