Sem descrição

Eugene Yakubovich 248bab3613 Merge pull request #36 from kelseyhightower/docs há 10 anos atrás
Godeps 6951642a1b coreos-inc to coreos move há 10 anos atrás
backend 6951642a1b coreos-inc to coreos move há 10 anos atrás
pkg bee5050e21 Fix GetInterfaceByIP() há 10 anos atrás
subnet 29d66fe3ab Merge pull request #31 from eyakubovich/master há 10 anos atrás
udp 780c909ecd Merge pull request #32 from eyakubovich/master há 10 anos atrás
.gitignore 9ac190644d rename kolach to rudder há 10 anos atrás
CONTRIBUTING.md c1c060c005 Added boilerplate files há 10 anos atrás
DCO c1c060c005 Added boilerplate files há 10 anos atrás
LICENSE c1c060c005 Added boilerplate files há 10 anos atrás
MAINTAINERS c1c060c005 Added boilerplate files há 10 anos atrás
NOTICE c1c060c005 Added boilerplate files há 10 anos atrás
README.md 1d2c264c4f docs: use public git URL in the building Rudder section há 10 anos atrás
build 6951642a1b coreos-inc to coreos move há 10 anos atrás
cover 7361dcdcea Added project deps and scripts há 10 anos atrás
main.go ffe0d6fa64 Reduce number of errors printed on watch timeout. Still need changes in go-etcd há 10 anos atrás
packet-01.png 7bfe590cd3 add a diagram of a packet traversing the network há 10 anos atrás
test d81e4573b5 fix test script and style há 10 anos atrás
version.go 2ecad218c9 updated docs; version fix há 10 anos atrás

README.md

Rudder

Rudder is an overlay network that gives a subnet to each machine for use with Kubernetes.

In Kubernetes every machine in the cluster is assigned a full subnet. The machine A and B might have 10.0.1.0/24 and 10.0.2.0/24 respectively. The advantage of this model is that it reduces the complexity of doing port mapping. The disadvantage is that the only cloud provider that can do this is GCE.

Theory of Operation

To emulate the Kubernetes model from GCE on other platforms we need to create an overlay network on top of the network that we are given from cloud providers. Rudder uses the Universal TUN/TAP device and creates an overlay network using UDP to encapsulate IP packets. The subnet allocation is done with the help of etcd which maintains the overlay to actual IP mappings.

The following diagram demonstrates the path a packet takes as it traverses the overlay network:

Life of a packet

Building Rudder

  • Step 1: Make sure you have Linux headers installed on your machine. On Ubuntu, run sudo apt-get install linux-libc-dev. On Fedora/Redhat, run sudo yum install kernel-headers.
  • Step 2: Git clone the Rudder repo: https://github.com/coreos/rudder.git
  • Step 3: Run the build script: cd rudder; ./build

Alternatively, you can build rudder in a docker container with the following command. Replace $SRC with the absolute path to your rudder source code:

docker run -v $SRC:/opt/rudder -i -t google/golang /bin/bash -c "cd /opt/rudder && ./build"

Configuration

Rudder reads its configuration from etcd. By default, it will read the configuration from /coreos.com/network/config (can be overridden via --etcd-prefix). The value of the config should be a JSON dictionary with the following keys:

  • Network (string): IPv4 network in CIDR format to use for the entire overlay network. This is the only mandatory key.

  • SubnetLen (number): The size of the subnet allocated to each host. Defaults to 24 (i.e. /24) unless the Network was configured to be smaller than a /24 in which case it is one less than the network.

  • SubnetMin (string): The beginning of IP range which the subnet allocation should start with. Defaults to the first subnet of Network.

  • SubnetMax (string): The end of the IP range at which the subnet allocation should end with. Defaults to the last subnet of Network.

Running

Once you have pushed configuration JSON to etcd, you can start Rudder. If you published your config at the default location, you can start Rudder with no arguments. Rudder will acquire a subnet lease, configure its routes based on other leases in the overlay network and start routing packets. Additionally it will monitor etcd for new members of the network and adjust its routing table accordingly.

After Rudder has acquired the subnet and configured the TUN device, it will write out an environment variable file (/run/rudder/subnet.env by default) with subnet address and MTU that it supports.

Key command line options

-etcd-endpoint="http://127.0.0.1:4001": etcd endpoint
-etcd-prefix="/coreos.com/network": etcd prefix
-iface="": interface to use (IP or name) for inter-host communication. Defaults to the interface for the default route on the machine.
-port=8285: UDP port to use for inter-node communications
-subnet-file="/run/rudder/subnet.env": filename where env variables (subnet and MTU values) will be written to
-v=0: log level for V logs. Set to 1 to see messages related to data path

Docker integration

Docker daemon accepts --bip argument to configure the subnet of the docker0 bridge. It also accepts --mtu to set the MTU for docker0 and veth devices that it will be creating. Since Rudder writes out the acquired subnet and MTU values into a file, the script starting Docker daemon can source in the values and pass them to Docker daemon:

source /run/rudder/subnet.env
docker -d --bip=${RUDDER_SUBNET} --mtu=${RUDDER_MTU}

Systemd users can use EnvironmentFile directive in the .service file to pull in /run/rudder/subnet.env

CoreOS integration

On CoreOS it is useful to add Rudder configuration into .service file in the cloud-config as the following snippet demonstrates:

  - name: rudder.service
    command: start
    content: |
      [Unit]
      Requires=etcd.service
      After=etcd.service

      [Service]
      ExecStartPre=-/usr/bin/etcdctl mk /coreos.com/network/config '{"Network":"10.0.0.0/16"}'
      ExecStart=/opt/bin/rudder