I'm trying to add a second network interface in Docker containers (with only Docker, I simply add my container to another "docker network" using the docker network command) in Kubernetes such that containers are also able to communicate together through this second interface.
The thing is that it is not possible to simply call the docker network command. I get the following error: Container sharing network namespace with another container or host cannot be connected to any other network.
This error seems logic to me as the network is not managed the same way with Kubernetes (all containers in a pod share their IP if I understood correctly). But now the question is: how can I add a second network interface easily to my container (or to my pod)?
I did some research and I found that Kubernetes is able to use CNI and that it could be my solution. But I was unable to have it working (don't know if the error is on my side or because everything is continuously evolving). I also searched for other solutions in the Kubernetes documentation, but I don't know if one of them can make me happy in an easy way :)
Thanks for your help!
P.S.: For a bit more context, I am creating containers with an application that needs to have two working interfaces (I cannot modify this application to use only one NIC) and I'm trying to have it working on my laptop (local Kubernetes/Docker installation) without needing replication on multiple nodes.
This is probably not going to be available by Kubernetes since network is not a first class object. It makes more sense for your application to work off of a single interface.
Another option is for you to manage your own network namespace and keep this container(s) out of the scope of Kubernetes. So all the network plugging will have to be done by you including scheduling of this.
Related
What I am doing right now:
I own many VPS which I use to deploy applications with Docker compose, most of the machines come from different subnets and have a public static IP address.
For each new application I would pick a random VPS, assign the new application's subdomain's DNS with the VPS' IP address and deploy my application in this VPS behind an Nginx proxy (jwilder Nginx).
This approach is in my opinion very comfortable since jwilder's Nginx does almost the work for me and I only have to assign the correct DNS.
What I want to achieve:
For the purpose of learning, I would like to take the machines and make a Kubernetes cluster out of them, so I could learn more about this technology. My idea is that I only have to assign new subdomain's DNS to one single point, which also plays the role of a load balancer and pass the traffic to corresponding pods.
To redirect traffic to a new application I only have to configure the load balancer.
My problem:
I know this question is not very precise since I don't know a lot of Kubernetes. Moreover, my servers are not from a cloud provider like Google or AWS and I, therefore, can not use their solutions. They are not even from a single cloud provider, most of them are of my university and some are from a private cloud provider.
Could anybody tell me how can I achieve this?
I think the answer is kubeadm, you can install it on your own pc or vm.
It is gonna create a single control-plane cluster which could be joined by other of your vms and create a kubernetes cluster.
kubeadm helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices
kubeadm is designed to be a simple way for new users to start trying Kubernetes out, possibly for the first time, a way for existing users to test their application on and stitch together a cluster easily, and also to be a building block in other ecosystem and/or installer tool with a larger scope.
Your cluster pods will communicate via CNI.
CNI was created as a minimal specification, built alongside a number of network vendor engineers to be a simple contract between the container runtime and network plugins
I am trying to move a currently docker based app to Kubernetes.
My app inspects network traffic that passes through it, and because of that it needs an accessible External IP, and it needs to accept traffic on all ports, not just some.
Right now, I am using docker with a macvlan network driver in order to attach docker containers to multiple interfaces and allow them to inspect traffic that way.
After research, I've found that the only way to access pods in Kubernetes is using Services, but services only allow that through some specific ports, because it is mostly intended for "server" type applications, and not "forwarder"/"sniffer" type which is what I am looking for.
Is Kubernetes a good fit for this type of application? Does it offer tools to cope with this problem?
Is Kubernetes a good fit for this type of application? Does it offer tools to cope with this problem?
Being a good fit is more of an opinion, the pods in Kubernetes have their own PodCidr that is not exposed to the outside world and a sniffer doesn't quite fit in either a service or a job definition which are the typical workloads in Kubernetes.
Having said, it can be done if you can use your custom CNI plugin that supports macvlan
You can also use something like Multus that supports the macvlan plugin.
I know that when running a container, I could set the --network argument whose value could be any from the results of docker network ls.
However, I have seen that some run containers like this:
$ docker run --network=container:CONTAINERID IMAGE
I have searched this usage but got no docs to explain it.
I have done some experiments and find that the container using another container's network shares the same network stack and it seems that the two containers are on the same host and they could call each other using localhost.
So when running a container by setting --network=container:CONTAINERID, does it mean that the two containers share the same network stack?
Exactly what you thought, the new container is given the same network namespace as CONTAINERID. So yes, same network stack. As you identified, this means that containers can contact each other via localhost, it also means that you need to be careful with port mappings, as each container will need a unique port within the namespace.
It is documented in the docker run reference here.
--network="bridge" : Connect a container to a network
'bridge': create a network stack on the default
Docker bridge
'none': no networking
# -----> 'container:<name|id>': reuse another container's
network stack
'host': use the Docker host network stack
'<network-name>|<network-id>': connect to a
user-defined network
So Kubernetes has a pretty novel network model, that I believe is based on what it perceives to be a shortcoming with default Docker networking. While I'm still struggling to understand: (1) what it perceives the actual shortcoming(s) to be, and (2) what Kubernetes' general solution is, I'm now reaching a point where I'd like to just implement the solution and perhaps that will clue me in a little better.
Whereas the rest of the Kubernetes documentation is very mature and well-written, the instructions for configuring the network are sparse, largely incoherent, and span many disparate articles, instead of being located in one particular place.
I'm hoping someone who has set up a Kubernetes cluster before (from scratch) can help walk me through the basic procedures. I'm not interested in running on GCE or AWS, and for now I'm not interested in using any kind of overlay network like flannel.
My basic understanding is:
Carve out a /16 subnet for all your pods. This will limit you to some 65K pods, which should be sufficient for most normal applications. All IPs in this subnet must be "public" and not inside of some traditionally-private (classful) range.
Create a cbr0 bridge somewhere and make sure its persistent (but on what machine?)
Remove/disable the MASQUERADE rule installed by Docker.
Some how configure iptables routes (again, where?) so that each pod spun up by Kubernetes receives one of those public IPs.
Some other setup is required to make use of load balanced Services and dynamic DNS.
Provision 5 VMs: 1 master, 4 minions
Install/configure Docker on all 5 VMs
Install/configure kubectl, controller-manager, apiserver and etcd to the master, and run them as services/daemons
Install/configure kubelet and kube-proxy on each minion and run them as services/daemons
This is the best I can collect from 2 full days of research, and they are likely wrong (or misdirected), out of order, and utterly incomplete.
I have unbridled access to create VMs in an on-premise vCenter cluster. If changes need to be made to VLAN/Switches/etc. I can get infrastructure involved.
How many VMs should I set up for Kubernetes (for a small-to-medium sized cluster), and why? What exact corrections do I need to make to my vague instructions above, so as to get networking totally configured?
I'm good with installing/configuring all the binaries. Just totally choking on the network side of the setup.
For a general introduction into kubernetes networking, I found http://www.slideshare.net/enakai/architecture-overview-kubernetes-with-red-hat-enterprise-linux-71 pretty helpful.
On your items (1) and (2): IMHO they are nicely described in https://github.com/kubernetes/kubernetes/blob/master/docs/admin/networking.md#docker-model .
From my experience: What is the Problem with the Docker NAT type of approach? Sometimes you need to configure e.g. into the software all the endpoints of all nodes (172.168.10.1:8080, 172.168.10.2:8080, etc). in kubernetes you can simply configure the IP's of the pods into each others pod, Docker complicates it using NAT indirection.
See also Setting up the network for Kubernetes for a nice answer.
Comments on your other points:
1.
All IPs in this subnet must be "public" and not inside of some traditionally-private (classful) range.
The "internal network" of kubernetes normally uses private IP's, see also slides above, which uses 10.x.x.x as example. I guess confusion comes from some kubernetes texts that refer to "public" as "visible outside of the node", but they do not mean "Internet Public IP Address Range".
For anyone who is interested in doing the same, here is my current plan.
I found the kube-up.sh script which installs a production-ish quality Kubernetes cluster on your AWS account. Essentially it creates 1 Kubernetes master EC2 instance and 4 minion instances.
On the master it installs etcd, apiserver, controller manager, and the scheduler. On the minions it installs kubelet and kube-proxy. It also creates an auto-scaling group for the minions (nice), and creates a whole slew of security- and networking-centric things on AWS for you. If you run the script and it fails creating the AWS S3 bucket, create a bucket of the same exact name manually and then re-run the script.
When the script is finished you will have Kubernetes up and running and ready for near-production usage (I keep saying "near" and "production-ish" because I'm too new to Kubernetes to know what actually constitutes a real deal productionalized cluster). You will need the AWS CLI installed and configured with a user that has full admin access to your AWS account (it goes ahead and creates IAM roles, etc.).
My game plan will be to:
Get comfortable working with Kubernetes on AWS
Keep hounding the Kubernetes team on Slack to help me understand how Kubernetes works under the hood
Reverse engineer the kube-up.sh script so that I can get Kubernetes running on premise (vCenter)
Blog about this process
Update this answer with a link to said blog.
Give me some time and I'll follow through.
I am going through an article weave net driver and was trying my hands on it. I was able to use the default weavemesh driver for container-to-container communication on single host. The issue comes when i try to create multiple networks using weave network driver plugin. I get the following error.
[ankit#local-machine]$ docker network create -d weave netA
Error response from daemon: failed to parse pool request for address space "GlobalDefault" pool "" subpool "": cannot find address space GlobalDefault (most likely the backing datastore is not configured)
Now, as i understand from docker documentation at Getting Started with Docker Multi-host Networking , It needs a key value store to be configured. I was wondering if my understanding is correct? Is there any way to create multiple networks over weave network to achieve network isolation. I want to be able to segregate network traffic for one container from another container running on the same box.
There is a new weave 1.4 plugin docker networking without cluster store plugin announcement recently which says it supports docker networking without external cluster store. how does it exactly work. its not very clear if it could be used to create multiple networks over weave.
This issue asked:
Did you start the docker daemon with --cluster-store?
You need to pass peers ips to weave launch-router $peers when starting docker with --cluster-store and --cluster-advertise.
The doc mentions:
The Weave plugin actually provides two network drivers to Docker
one named weavemesh that can operate without a cluster store and
one named weave that can only work with one (like Docker’s overlay driver).
Hence the need to Set up a key-value store first.
If you are using the weave plugin, your understanding is correct.
PR 1738 has more on the new weave 1.4+ ability to operate without a keystore with the weavemesh driver. Its doc does mention:
If you do create additional networks using the weavemesh driver, containers attached to them will be able to communicate with containers attached to weave; there is no isolation between those networks.
But PR 1742 is still open "Allow user to specify a subnet range for each docker host".