Nav apraksta

Tom Denham e14feb7f8e Backends: Remove Run() from interface as it's not used 8 gadi atpakaļ
.github 0e65fd8b5d Add templates for PRs/Issues 7 gadi atpakaļ
Documentation 008a58373b Merge pull request #717 from t0mmyt/awsvpc-multiaz-rebase 7 gadi atpakaļ
backend e14feb7f8e Backends: Remove Run() from interface as it's not used 7 gadi atpakaļ
dist 0c6d2efc42 Merge pull request #702 from philips/add-bill-of-materials 7 gadi atpakaļ
logos 170fd5de88 logos: resized for readme 9 gadi atpakaļ
network 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
pkg dd396c9ea0 network order functionality changed based on endianess 7 gadi atpakaļ
subnet 2cbd855e63 aws-vpc: add support for multiple route tables 7 gadi atpakaļ
vendor 1b8190be03 glide install 8 gadi atpakaļ
version cbac427350 Version embedding for Go 1.4 and 1.5 9 gadi atpakaļ
.dockerignore a8972ad5cd BUILDS: Overhaul build process 8 gadi atpakaļ
.gitignore 77ea67d61e Add iptables binaries 8 gadi atpakaļ
.travis.yml 56ef07bd0f Makefile: Push tags to flannel-git for all builds 8 gadi atpakaļ
CONTRIBUTING.md c1c060c005 Added boilerplate files 10 gadi atpakaļ
DCO c1c060c005 Added boilerplate files 10 gadi atpakaļ
Dockerfile.amd64 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
Dockerfile.arm 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
Dockerfile.arm64 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
Dockerfile.ppc64le 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
Dockerfile.s390x 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
LICENSE c1c060c005 Added boilerplate files 10 gadi atpakaļ
MAINTAINERS c2171f9dc5 MAINTAINERS: remove steevej 8 gadi atpakaļ
Makefile 01afb49e72 Remove the experimental support for multiple networks. 8 gadi atpakaļ
NOTICE c1c060c005 Added boilerplate files 10 gadi atpakaļ
README.md 54c72aadb3 docs: adding CNI plugin note. 7 gadi atpakaļ
bill-of-materials.json 22d406b596 bill-of-materials: initial commit 7 gadi atpakaļ
bill-of-materials.override.json 22d406b596 bill-of-materials: initial commit 7 gadi atpakaļ
glide.lock dbee0823c2 glide update 8 gadi atpakaļ
glide.yaml dbee0823c2 glide update 8 gadi atpakaļ
license-check.sh a8972ad5cd BUILDS: Overhaul build process 8 gadi atpakaļ
main.go 2cbd855e63 aws-vpc: add support for multiple route tables 7 gadi atpakaļ
packet-01.png 82195b1cc4 diagram: update to reflect name change 10 gadi atpakaļ

README.md

flannel

flannel Logo

Build Status

Flannel is a virtual network that gives a subnet to each host for use with container runtimes.

Platforms like Kubernetes assume that each container (pod) has a unique, routable IP inside the cluster. The advantage of this model is that it reduces the complexity of doing port mapping.

How it works

Flannel runs an agent, flanneld, on each host and is responsible for allocating a subnet lease out of a preconfigured address space. Flannel uses either etcd or the Kubernetes API to store the network configuration, allocated subnets, and auxiliary data (such as host's IP). Packets are forwarded using one of several backend mechanisms.

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

Life of a packet

Getting started

The easiest way to deploy flannel with Kubernetes is to use one of several deployment tools and distributions that network clusters with flannel by default. CoreOS's Tectonic sets up flannel in the Kubernetes clusters it creates using the open source Tectonic Installer to drive the setup process.

Flannel can use the Kubernetes API as its backing store, meaning there's no need to deploy a discrete etcd cluster for flannel. This flannel mode is known as the kube subnet manager.

Adding flannel

Flannel can be added to any existing Kubernetes cluster. It's simplest to add flannel before any pods using the pod network have been started.

For information on deploying flannel manually, using the (currently alpha) Kubernetes installer toolkit kubeadm, see Installing Kubernetes on Linux with kubeadm.

Using flannel

Once applied, the flannel manifest defines three things:

  1. A service account for flannel to use.
  2. A ConfigMap containing both a CNI configuration and a flannel configuration. The network in the flannel configuration should match the pod network CIDR. The choice of backend is also made here and defaults to VXLAN.
  3. A DaemonSet to deploy the flannel pod on each Node. The pod has two containers 1) the flannel daemon itself, and 2) a container for deploying the CNI configuration to a location that the kubelet can read.

When you run pods, they will be allocated IP addresses from the pod network CIDR. No matter which node those pods end up on, they will be able to communicate with each other.

Kubernetes 1.6 requires CNI plugin version 0.5.1 or later.

Documentation

Contact

Contributing

See CONTRIBUTING for details on submitting patches and the contribution workflow.

Reporting bugs

See reporting bugs for details about reporting any issues.

License

Flannel is under the Apache 2.0 license. See the LICENSE file for details.