I have been working with docker to run my scripts on chrome-node and firefox -node and debug with the selenium-hub image where it runs smoothly, but when I use the same with k8s the whole system slows down. Why is this happening, any idea. I am using minikubes for kubernetes and docker toolbox and docker compose for docker.
Thanks,
There would definitely be an additional overhead when you start Kubernetes using minikube locally, compared to just starting a Docker container on the host.
In order to have a Kubernetes cluster, minikube creates a VM on the machine where the Kubernetes components will run in addition to the Docker container.
Anyway, minikube is not a production way for running Kubernetes. It is mostly meant for local development and testing. Therefore, you shouldn't evaluated kubernetes performance based on a minikube installation.
Related
Issue:
I want my web-server to have either a Kubernetes config and a Docker-Compose config.
I run them on a MacBook (no native containers support), so at the moment I
run docker-compose on Docker Desktop
run kubectl on a Minikube VM
(I stick to Minikube because of the convenient commands like minikube ip & minikube service, that I rely on in my scripts)
This makes slow and inconvenient to switch from one setup to the other (suspend Minikube, start Docker Desktop, rebuild the images, re-run the services; and vice-versa).
They won't share built images or containers, and they run in different environments.
Attempt
I tried running docker-compose on Docker from the Minikube VM.
Works fine, but I cannot connect to the service, because there is no tunnelling or port-forwarding from the Host machine to the Minikube machine
(while compose takes care of the inner forwarding from $(minikube ip):8081 to docker-container-webserver:8080.
Question
How to open the connection from the Host machine (browser) to the container (web-server) running inside Minikube?
I tried minikube tunnel but it didn't seem to help (it is designed to work with Kubernetes LoadBalancer services).
While playing around with Docker and orchestration (kubernetes) I had to install and use minikube to create a simple sandbox environment. At the beginning I thought that minikube installs some kind of VM and run the "minified" kubernetes environment inside the same, however, after the installation listing my local Docker running containers I found minikube running as a container!!
Why minikube itself run as a Docker container? and how can it runs other containers?
Experimental Docker support looks to have been added in minikube 1.7.0, and started becoming the default runtime in minikube 1.9.0. As I'm writing this, current is 1.15.1.
The minikube documentation on the "docker" driver notes, particularly on a native-Linux host, there is not an intermediate virtual machine: if you can run Kubernetes in a container, it can use the entire host system's resources without special configuration or partitioning. The previous minikube-on-VirtualBox installation required preallocating memory and disk to the VM, and it was easy to get those settings wrong. Even on non-Linux hosts, if you're running Docker Desktop, sharing its hidden Linux VM can improve resource utilization, and you don't need to decide to allocate exactly 2 GB RAM to Docker Desktop and exactly 4 GB to the minikube VM.
For a long time it's been possible, but discouraged, to run a separate Docker daemon inside a Docker container; similarly, it's possible, but usually discouraged, to run a multi-process init system in a container. If you do both of these things then you can have the core Kubernetes components (etcd, apiserver, kubelet, ...) inside a single container pretending to be a Kubernetes node. It also helps here that Kubernetes already knows how to pull Docker images, which minimizes some of the confusing issues with running Docker in Docker.
Most tutorials I've seen for developing with Kubernetes locally use Minikube. In the latest Edge release of Docker for Windows, you can also enable Kubernetes. I'm trying to understand the differences between the two and which I should use.
Minikube lets you choose the version of Kubernetes you want, can Docker for Windows do that? I don't see a way to configure it.
Minikube has CLI commands to enable the dashboard, heapster, ingress and other addons. I'm not sure why because my undertstanding is that these are simply executing kubectl apply -f http://....
With Minikube I can do a minikube ip to get the cluster IP address for ingress, how can I do this with Docker for Windows?
Is there anything else different that I should care about.
I feel like you largely understand the space, and mostly have answers to your questions already. You might find Docker for Mac vs. Docker Toolbox an informative read, even if it's about the Mac equivalent rather than Windows and about Docker packaged as a VM rather than Kubernetes specifically.
In fact you are stuck with the specific version of Kubernetes the Docker Edge desktop distribution publishes.
is answered in the question.
I believe NodePort-type Services are published on your host's IP address; there isn't an intermediate VM address like there is with Docker Toolbox.
Docker Toolbox and minikube always use a full-blown virtual machine with an off-the-shelf hypervisor. The Docker desktop application might use a lighter-weight virtualization engine if one is available.
Kubernetes can involve some significant background work. If you're using Kubernetes-in-Docker it's hard to "turn off" Kubernetes and still have Docker available; but if you have a separate minikube VM you can just stop it.
Here is a part from Docker documentation:
Kubernetes is only available in Docker for Windows 18.02 CE Edge.
Kubernetes support is not included in Docker for Windows 18.02 CE
Stable. To find out more about Stable and Edge channels and how to
switch between them, see General configuration.
Docker for Windows 18.02 CE Edge includes a standalone Kubernetes
server and client, as well as Docker CLI integration. The Kubernetes
server runs locally within your Docker instance, is not configurable,
and is a single-node cluster.
The Kubernetes server runs within a Docker container on your local
system, and is only for local testing. When Kubernetes support is
enabled, you can deploy your workloads, in parallel, on Kubernetes,
Swarm, and as standalone containers. Enabling or disabling the
Kubernetes server does not affect your other workloads.
See Docker for Windows > Getting started to enable Kubernetes and
begin testing the deployment of your workloads on Kubernetes.
If you have enough CPU and RAM resources, you can easily have both, minikube and docker-for-desktop on the same machine and switch between them by selecting the context, e.g.:
> kubectl config get-contexts
> kubectl config use-context docker-for-desktop
There is no place at the moment to choose the Kubernetes version for docker-for-desktop. It is preselected in the Docker distribution package.
Unfortunately, version of docker inside the minikube is a step behind compared to available on the docker website, and some features could be missing, but if you are interested in Kubernetes environment, it doesn't really matter in most cases.
Some of the features of Kubernetes rely on external resources and could be unavailable for you in case of local installation. For example, you need an ability to create Cloud Load Balancer to use some types of the Ingress or Service objects.
But other resources can be easily started inside the minikube, or docker-for-desktop using kubectl create/apply.
To expose your cluster resources externally, you can use Webhook Relay Ingress controller.
Here is a link to the installation manual.
I've used Docker Swarm - I can put the management and the agents in docker containers. Can I do the same with Kubernetes?
I don't want to pollute my machine.
All of the master components in Kubernetes run inside of containers.
Due to limitations of Docker, the kubelet agent has been difficult to get running in a container. The Kubernetes folks have been working on this for the last year (see kubernetes#4869), and with Docker 1.10 it looks like it is getting close to working.
Looking at Rancher, what is the performance like? I guess my main question, is everything deployed in Rancher docker in docker? After reading http://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ I trying to stay away from that idea. It looks like the Rancher CI pipeline with Docker/Jenkins is docker in docker, but what about the rest? If i setup a docker-compose or deploy something from their catalog, is it all docker in docker? I've read through their documentation and this simple question has still just flown over my head. Any guidance would be much appreciated.
Thank you
Rancher itself is not deployed with Docker in Docker (DinD). The main components of Rancher, rancher/server and rancher/agent are both normal containers. The server, in a normal deployment, runs the orchestration piece and a few other key services for the catalog, Docker Machine provisioning, websocket-proxy and MySQL. All of these can be broken out if desired, but for simplicity of getting started, its all in one. We use s6 to manage the orchestration and database processes.
The rancher/agent container is privileged and requires the user to bind mount the hosts Docker socket. We package a Docker binary in the container and use it to communicate with the host on startup. It is similar to the way a Mac talks to Boot2docker, the binary is just a client talking to a remote Docker daemon. Once the agent is bootstrapped, it communicates back to the Rancher server container over a websocket connection. When containers and stacks are deployed Rancher server sends events to the agents which then call the hosts Docker daemon for deployment. The deployed containers are running as normal Docker containers on the host, just as if the user typed docker run .... In fact, a neat feature of Rancher is that if you do type docker run ... on the host, the resulting container will show up in the Rancher UI.
The Jenkins entry in the Rancher catalog, when using the Swarm plugin is doing a host bind mount of the Docker socket as well. We have some early experiments that used DinD to test out some concepts with Jenkins, but those were not released.