ADD: cni support for the docker executor.#586
ADD: cni support for the docker executor.#586andreaspeters wants to merge 3 commits intoapache:masterfrom
Conversation
|
Friendly ping :-) |
bmahler
left a comment
There was a problem hiding this comment.
This could use a more clear overview of the approach and its limitations, shouldn't we be using docker network plugins?
https://docs.docker.com/engine/extend/plugins_network/#use-network-driver-plugins
That seems like the right way to do this? Whereas the approach taken in this patch looks problematic and looks like a hack? We're doing CNI stuff after we've docker run the container?
| Try<std::tuple<Subprocess, std::string>> cni = attachCNI(task); | ||
| if (!cni.isError()) { | ||
| Subprocess cniSub = std::get<0>(cni.get()); | ||
| std::string cniNetworkName = std::get<1>(cni.get()); | ||
|
|
||
| WIFEXITED(cniSub.status().get().get()); | ||
| Try<std::string> cniIP = attachCNISuccess(cniSub); | ||
| if (cniIP.isError()) { | ||
| LOG(ERROR) << cniIP.error(); | ||
| } else { | ||
| useCNI = true; | ||
| setIPAddresses(cniIP.get(), false); | ||
| } | ||
| } |
There was a problem hiding this comment.
hm.. this looks like a bad design? docker run has already been called, and then we attach CNI? This means the workload could have started and failed to perform networking operations? It seems like the correct way to do this is to perform CNI work while setting up the container, whereas this looks like a hack where it's set up after the container has been started already?
There was a problem hiding this comment.
We can only add CNI if the container is already running since there is no way for us to "infiltrate" the container during the startup.
There are up to one second where the workload could have connection issues. But the container will not fail (crash). That's a point we have to write as notice.
My personal opinion is: Docker inc. should add CNI support to there engine. But they will not and on the other hand they also do not care there network plugins. 🤷🏻♂️ At least with these CNI implementation we can use a wide range of new network interfaces with our docker executor and does not have to use unmaintained docker network plugins.
| // function to attach or detach CNI from/to the container | ||
| Try<std::tuple<Subprocess, std::string>> commandCNI( | ||
| const mesos::ContainerInfo& container, | ||
| const string command) |
There was a problem hiding this comment.
feels like these should probably just return a Future of whatever information you want? not clear what the string here would represent
There was a problem hiding this comment.
It returns the CNI name in line 1011. We need it in line 335. But maybe I also misunderstand you. 😅
There is no official "Docker Inc" way to support CNI. They prefer to use there own docker-network plugin. Problem with that is, the plugins are pretty old. Some of them are even not in development anymore but still on the official list. 🤷🏻♂️ |
With this PR I would like to add support for CNI (ContainerNetworkInterface) to the Docker Executor. As far as possible, I have followed the CNI implementation of the Mesos Containerizer.
The following parameters and their default values are added to the Docker Executor:
How is CNI used with Docker?
By setting a name on the mesosproto NetworkInfo object which matches the CNI name in the CNI configuration.
Here is an example of a CNI configuration:
How does the Docker Executor work?
If the name of the mesosproto NetworkInfo object has been set, the executor checks whether a CNI configuration exists for it. If this is the case, it is used to create a network interface in the container. If no CNI configuration exists, an error message appears in the stderr file in the sandbox directory. As the name can also be a Docker Network Plugin, the container is started in any case. If there is no Docker Network Plugin with the name, the container runs without an additional network interface.
How can the CNI support be tested?
I have added a test that can be used via the Mesos Test Tool.
mesos-tests --verbose --gtest_filter="DockerCniTest.*”