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.
Related
When I run my docker container using Docker Desktop for Windows I am able to connect to it using
docker run -p 5051:5000 my_app
http://0.0.0.0:5051
However when I open another terminal and do this
minikube docker-env | Invoke-Expression
and build and run the same container using the same run command as above
I cannot connect to the running instance.
Should I be running and testing the containers using Docker Desktop, then using minikube to store the images only (for Kubernetes)? Or can you run them and test them as well through minikube?
That's because on your second attempt, the container is not running on the host but on the minikube VM. You'll be able to access it using the minikube VM IP.
To get the minikube ip you can run minikube ip
Why ?
Invoking minikube docker-env sets all the docker env variable on your host to match the minikube environment. This means that when you run a container after that, it is run with the docker daemon on the minikube VM.
I asked you if there are any specific reasons to use Docker Desktop and Minikube together on a single machine as these are two competitive solutions which basically enable you to perform similar tasks and achieve same goals.
This article nicely explains differences between these two tools.
Docker-for-windows uses Type-1 hypervisor, such as Hyper-V, which are
better compared to Type-2 hypervisors, such as VirtualBox, while
Minikube supports both hypervisors. Unfortunately, there are a couple
of limitations in which technology you are using, since you cannot
have Type-1 or Type-2 hypervisors running at the same time on your
machine
If you use Docker Desktop and Minikube at the same time I assume you're using Type-1 hypervisor, such as mentioned Hyper-V, but keep in mind that even if they use the same hypervisor, both tools create their own instances of virtual machine. Basically you are not supposed to use those two tools together expecting that they will work as a kind of hybrid that lets you manage single container environment.
First check what hypervisor you are using exactly. If you're using Hyper-V, simple Get-VM command in Powershell (more details in this article) should tell you what you currently have.
#mario no, I didn't know minikube had a docker daemon until recently
which is why I have both
Yes, Minikube has built in docker environment (in fact it sets everything up, but yes, it also sets up container runtime) so basically you don't need to install docker additionally, and as #Marc ABOUCHACRA already suggested in his answer, Minikube runs the whole environment (single node k8s cluster with docker runtime) on a separate VM. Linux version has an option --vm-driver=none which allows you to use your host container runtime and set-up k8s components on it, but this is not the case with Windows version - here you can only use one of two currently supported hypervisors: Hyper-V or VirtualBox (ref).
I wouldn't say that Docker Destkop runs everything on your host. It also uses Type-1 hypervisor to run the container runtime environment. Please check the Get-VM command on your computer and it should be clear what VMs you have and created by which tool.
I know that containers are a form of isolation between the app and the host (the managed running process). I also know that container images are basically the package for the runtime environment (hopefully I got that correct). What's confusing to me is when they say that a Docker image doesn't retain state. So if I create a Docker image with a database (like PostgreSQL), wouldn't all the data get wiped out when I stop the container and restart? Why would I use a database in a Docker container?
It's also difficult for me to grasp LXC. On another question page I see:
LinuX Containers (LXC) is an operating system-level virtualization
method for running multiple isolated Linux systems (containers) on a
single control host (LXC host)
What does that exactly mean? Does it mean I can have multiple versions of Linux running on the same host as long as the host support LXC? What else is there to it?
LXC and Docker, Both are completely different. But we say both are container holders.
There are two types of Containers,
1.Application Containers: Whose main motto is to provide application dependencies. These are Docker Containers (Light Weight Containers). They run as a process in your host and gets all the things done you want. They literally don't need any OS Image/ Boot Up thing. They come and they go in a matter of seconds. You cannot run multiple process/services inside a docker container. If you want, you can do run multiple process inside a docker container, but it is laborious. Here, resources (CPU, Disk, Memory, RAM) will be shared.
2.System Containers: These are fat Containers, means they are heavy, they need OS Images
to launch themselves, at the same time they are not as heavy as Virtual Machines, They are very similar to VM's but differ in architecture a bit.
In this, Let us say Ubuntu as a Host Machine, if you have LXC installed and configured in your ubuntu host, You can run a Centos Container, a Ubuntu(with Differnet Version), a RHEL, a Fedora and any linux flavour on top of a Ubuntu Host. You can also run multiple process inside an LXC contianer. Here also resoucre sharing will be done.
So, If you have a huge application running in one LXC Container, it requires more resources, simultaneously if you have another application running inside another LXC container which require less resources. The Container with less requirement will share the resources with the container with more resource requirement.
Answering Your Question:
So if I create a Docker image with a database (like PostgreSQL), wouldn't all the data get wiped out when I stop the container and restart?
You won't create a database docker image with some data to it(This is not recommended).
You run/create a container from an image and you attach/mount data to it.
So, when you stop/restart a container, data will never gets lost if you attach that data to a volume as this volume resides somewhere other than the docker container (May be a NFS Server or Host itself).
Does it mean I can have multiple versions of Linux running on the same host as long as the host support LXC? What else is there to it?
Yes, You can do this. We are running LXC Containers in our production.
Scenario:
I need to build a web-app, from which I can run/sop/delete/etc. containers in a cluster. So I installed Kubernetes and tested the API from the console. Everything seems working and looks fine.
Following the Docs, they write about Docker, but do I need it necessarily?
I mean I had to disable Hyper-V to make Minikube work, and after a reboot, Docker (which usually starts at startup) says that "something went wrong.. bla bla" .. but I can create deployments and proxys on Minikube.
This is somehow confusing.
Can someone explain this please for dummies?
Technically, you need a container runtime which respects CRI (Container Runtime Interface).
That is why you have CRI-O, which provides an integration path between OCI conformant runtimes and the kubelet.
See "CRI-O, the Project to Run Containers without Docker, Reaches 1.0" by Susan Hall.
The project “opens the door for plugging alternative container runtimes in the kubelet more easily, instead of relying on the default docker runtime.
Those new runtimes may include virtual machines-based ones, such as runv and Clear Containers, or standard Linux containers runtimes like rkt,” Red Hat senior engineer Antonio Murdaca wrote on the Project Atomic blog.
But in your case, your issue is to make Minikube work with HyperV: see "Minikube on Windows 10 with Hyper-V" from Jock Reed.
The trick is to create a new (External) Virtual network switch, named "Primary Virtual Switch", and to start Minikube with:
minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch"
If you're running minikube on OSX or Linux, you can configure Docker to use the minikube environment by running
eval $(minikube docker-env)
When you do this, you don't need a separate Docker desktop application. You're still technically using both Docker and Kubernetes, but you won't be using the setup with the "whale" icon on OSX.
Fundamentally Kubernetes takes responsibility for launching and managing Docker containers. (Or potentially other things, but almost always Docker containers.) It's a more complicated and more powerful tool along the same lines as Docker Compose and Docker Swarm. Minikube is very small Kubernetes cluster that runs inside a virtual machine; if you run kubectl get nodes you will see the single VM node, and that includes a copy of Docker.
As mentioned above, you need any runtime container. Kubernetes and docker are part of ecosystem. Both have different responsibilities, kubernetes handle cluster health and docker run application containers.
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 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.