Kubernetes | Creating your first deployment
Containerisation gets more and more important in our current live as a software developer. Docker alone brings a lot of value to the process, but you can add even more value to it by combining it with a container orchestration platform like Kubernetes. With the help of Kubernetes it is now possible to autoscale or to create a desired state of Replicasets or even LoadBalancing is possible.
To understand how this works, we need to take a look at the hierarchy on which Kubernetes is built on.
The smallest thing in Kubernetes is the Pod. In one pod, there are normally one or two containers. The next bigger thing are the Replica Sets. These contain a specific number of Pods in them. A special thing about them is, that the desired number of Pods is always guaranteed. If one Pod in a RS fails, it will start a new one automatically. The Deployment is the last step. It contains a Replica Set and handles the Load Balancing and Networking. It has also the function to rollback to a desired state of the deployment. For example, if you change something on your deployment and update it, you have a feature to rollback to your last deployment.
Create the Deployment
First of all, you have to specify the apiVersion. On a deployment, it is normally apps/v1. Next you have to define the kind as a Deployment. Under Metadata you have to define your name and the labels are most likly the same as the name. It is good practise to set also an app label with your desired name.
The next important thing is defining the Replicaset. Under Spec, you specify the number of pods you want to have in your RS. The selector is important to select the right pods for the RS. The labels on the selector must be equal to the ones of the pod you want to deploy.
The last step are the Pods. Under the template metadata, you specify the name and the labels. As mentioned before, these must match the labels of the selector of the RS.
Under containers, you define the container name and the image. They don’t need to be equal every time. The container Port is the port, onwhich the Container listens internally.
Useful links: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Create the Service
As you might have seen, Kubernetes needs services to be able to communicate with its containers over the host machine. To create such a service we have to create a second YAML file.
Like before, we have to define the apiVersion. Since this is the kind Service, the apiVersion is v1. Then we have to set the metadata. The spec is the really interesting part. The type needs to be a NodePort to be able to communicate with the host machine. The TargetPort is the port thats connecting to the pod. It needs to be the same as the port defined in the deployment.yaml. The NodePort is the port that the host machine can communicate to the service. It needs to be in the range 30000–32767. The Port is just the connection between the two other Ports and can be pretty much anything in this example.
Useful Links: https://kubernetes.io/docs/concepts/services-networking/service/
When you have defined these two things, you’re ready to start your deployment and service. But how do you do that?
Start your Deployment
To start your yaml files, just type:
$ kubectl apply -f nginx-deployment.yaml
$ kubectl apply -f nginx-service.yamlMake sure, that the NodePort of the Service is not already allocated.
If everything worked as it should, you should now be able to see the Nginx starting site on your localhost:30001.
For more information about Kubernetes visit: https://kubernetes.io
Good Udemy Course: https://www.udemy.com/share/101to4AEATdV5WQHoB/
