Introduction
Services in Kubernetes are a way to expose your applications to other applications and users. They provide a layer of abstraction between your applications and the underlying infrastructure, making it easier to scale and manage your applications.
When you create a Service, you specify a set of Pods that the Service should expose. Kubernetes will then create a load balancer to distribute traffic across those Pods. This means that you can add or remove Pods without having to update your clients.
ConfigMaps in Kubernetes are used to store non-confidential data, such as database connection strings, configuration files, and environment variables. ConfigMaps can be mounted into Pods as volumes, or they can be consumed as environment variables.
ConfigMaps are a good way to decouple your applications from their environment-specific configuration. This makes your applications more portable and easier to manage.
Secrets in Kubernetes are used to store sensitive data, such as passwords, API keys, and SSH keys. Secrets are encrypted at rest and in transit, so they are protected from unauthorized access.
Secrets can be consumed by Pods in the same way as ConfigMaps. However, it is important to note that Secrets should only be used to store sensitive data.
A simple analogy to understand the difference between Services, ConfigMaps, and Secrets:
Services are like the front door to your house. They allow people to visit your house without having to know where the individual rooms are located.
ConfigMaps are like the blueprints for your house. They contain all of the information needed to build your house, but they are not confidential.
Secrets are like the keys to your house. They should only be given to people who are authorized to enter your house.
Types of Services in Kubernetes:
There are four types of Services in Kubernetes:
ClusterIP: This is the default service type. It exposes a service within the cluster.
NodePort: This service type exposes a service on a static port on each node in the cluster.
LoadBalancer: This service type exposes a service using a load balancer provided by the cloud provider.
ExternalName: This service type maps a service to an external DNS name.
Here is a brief description of each service type:
ClusterIP
A ClusterIP Service exposes a service within the cluster. It is assigned a unique IP address within the cluster, which can be used by other Pods in the cluster to access the service. ClusterIP Services are the most common type of service in Kubernetes.
NodePort
A NodePort Service exposes a service on a static port on each node in the cluster. This allows the service to be accessed from outside the cluster by connecting to the node's IP address and the static port. NodePort Services are useful for exposing services to other networks, such as on-premises networks or the public internet.
LoadBalancer
A LoadBalancer Service exposes a service using a load balancer provided by the cloud provider. The load balancer balances traffic to the service across the Pods that are running the service. LoadBalancer Services are the most common way to expose services to the public internet.
ExternalName
An ExternalName Service maps a service to an external DNS name. This allows you to use Kubernetes to expose services that are running outside of the cluster, such as a database or a web server running on a bare-metal server. ExternalName Services are less common than the other types of services, but they can be useful in certain situations.
Task-1:
Create a Service for your todo-app Deployment from Day 32
Create a Service definition for your todo-app Deployment in a YAML file.
Apply the Service definition to your K8s (minikube) cluster using the
kubectl apply -f service.yml -n <namespace-name>
command.Verify that the Service is working by accessing the todo-app using the Service's IP and Port in your Namespace.
I will be doing this on my EC2 instance where I installed the minikube. Let's start the minikube first using the following command:minikube start --driver=docker
Now by doing kubectl get pods
make sure the deployment from Day-32 is running.
kubectl apply -f service.yml -n <namespace-name>
kubectl get svc -n <namespace>
minikube service <service_name> -n=<namespace> --url
curl -L <service-ip>:<service-port>
curl -L http://192.168.49.2:30080
It's time to create a service.yml file
Applying and verifying it:
Task-2:
Create a ClusterIP Service for accessing the todo-app from within the cluster
Create a ClusterIP Service definition for your todo-app Deployment in a YAML file.
Apply the ClusterIP Service definition to your K8s (minikube) cluster using the
kubectl apply -f cluster-ip-service.yml -n <namespace-name>
command.Verify that the ClusterIP Service is working by accessing the todo-app from another Pod in the cluster in your Namespace.
kubectl get services -n <namespace>
kubectl get pods -n <namespace>
kubectl exec -it <pod-name> -n <namespace> -- bash
wget -O- <cluster-ip>:<service-port>
wget -O- 10.102.44.73:8000
Task-3:
Create a LoadBalancer Service for accessing the todo-app from outside the cluster
Create a LoadBalancer Service definition for your todo-app Deployment in a YAML file.
Apply the LoadBalancer Service definition to your K8s (minikube) cluster using the
kubectl apply -f load-balancer-service.yml -n <namespace-name>
command.Verify that the LoadBalancer Service is working by accessing the todo-app from outside the cluster in your Namespace.
Task 4:
Create a ConfigMap for your Deployment
Create a ConfigMap for your Deployment using a file or the command line
Update the deployment.yml file to include the ConfigMap
Apply the updated deployment using the command:
kubectl apply -f deployment.yml -n <namespace-name>
Verify that the ConfigMap has been created by checking the status of the ConfigMaps in your Namespace.
Creating a configmap.yml and then adjusting the deployment accordingly.
Task 5:
Create a Secret for your Deployment
Create a Secret for your Deployment using a file or the command line
Update the deployment.yml file to include the Secret
Apply the updated deployment using the command:
kubectl apply -f deployment.yml -n <namespace-name>
Verify that the Secret has been created by checking the status of the Secrets in your Namespace
Let's encode the information first. This will automatically be decoded and our end goal of sending the information will be done.
I am grateful that you have reached here. I hope you gained some regarding the above tasks. See you in the next one.