Does Kubernetes beat Docker Swarm?
First, what’s Kubernetes?
It works like Docker with its containers, deploy processes and application scale, but it has some differences:
- Pods are our group of containers.
- Kubernetes does not orchestrate your project system. Keep in mind that orchestrate a system is something like: do task A, then task B, then C. What Kubernetes does is more like choreography: No matter what you get from task A to do task C.
- It has a comfortable dashboard to show your container pods in cluster:
The Kubernetes was started by Google. Its name is a Greek word, meaning “helmsman” or “pilot” and the word is the root of “governor” and “cybernetic”. It has an abbreviation: K8s. Yay! (replaces 8 letters of “ubernete” with 8).
So let’s begin with…
Are there any differences between Docker Swarm and K8s?
Yep! And maybe these differences are what lacks on Docker Swarm for while.
- Replication Controller: allows you to create up to 10 Nginx server, for example, and tell Kubernetes that you always want this quantity running. Even if a Nginx container fails, falls down, explodes, disappear mysteriously for any reason, Kubernetes automatically brings up another Nginx container. There is no need to do something manually.
- When you reach, for example, 70% of your server’s CPU usage, Kubernetes creates another Web container to balance or decrease that usage, also automatically.
- It’s possible to represent more than one namespace indicating, for example, two standalone environments: one for tests and another for production. So, you can tell that the resources for each one do not have any interference.
If you want to test those differences, you can run Minikube as a Kubernetes local machine. Minikube requires that VT-x/AMD-v virtualization is enabled in BIOS on all platforms.
For checking if that this is enabled on Linux, run:
$ cat /proc/cpuinfo | grep ‘vmx\|svm’
If you already have it enabled an output should appear. Download MiniKube via the following link:
In order to run K8s locally, you also need some K8s’s components:
$ curl -Lo kubectl http://storage.googleapis.com/kubernetes-release/release/v1.3.0/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/
At this point we can start the job.
Run the command to build your Kubernetes local cluster:
minikube start
You can see the dashboard by running:
minikube dashboard
And if you want to check if your clusters are really there, run the following:
kubectl get nodes
After all these steps we can test and check if the advantages over Docker Swarm are really good enough. We are going to create a replication controller, so we need to create a configuration file in YAML or JSON format. For that, run the following:
kubectl create -f <FILE_NAME>
replace <FILE_NAME> with any name you want.
A sample file has the following fields as an example:
If you want to view your replication controllers or their details, you can run, respectively:
$ kubectl get rc
$ kubectl describe rc nginx
Keeping up with the standalone environments and the CPU usages, we can also determine the memory usage. You can configure the following command as your own:
$ kubectl run nginx \
— image=nginx \
— replicas=10 \
— requests=cpu=100m,memory=256Mi \
— limits=cpu=200m,memory=512Mi \
— namespace=quota-example
And when you did so, your replicas are able to create its own pods:
$ kubectl get pods — namespace=quota-example
$ kubectl describe quota — namespace=quota-example
See more at: http://kubernetes.io/docs/
If everything ran well, you can now answer this article’s title.
Hope this tiny examples have showed you something more about containers regard to the greatest possibilities with them now-a-days.
