JDjdean32·Jul 4, 2019Submission
Systemd 242's default persistent mac addresses breaking Kubernetes
4 points · Open discussionflannel-io
flannel
Go2014–2019
flannel-io / flannel
flannel
flannel is a network fabric for containers, designed for Kubernetes
13Distinct people
14Mentions
0Explicit recommenders
9.6KGitHub stars
What to know before exploring
What it is
flannel is a network fabric for containers, designed for Kubernetes
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2014-11-04 17:08:41 UTC to 2019-07-04 09:55:38 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 1 | 2 |
What Hacker News says
14 sourcesI had previously come across an in-tree WireGuard extension for Flannel, https://github.com/coreos/flannel/blob/master/dist/extension....
However, Flannel's WireGuard extension looked way too experimental, and unmaintained. I realise it is also early days for Gravitational Wormhole, but Gravitational Wormhole looks promising.
In Gravitational Wormhole: WireGuard for KubernetesYes, and if you're installing it on all your nodes anyway, you can use it to encrypt a flannel overlay net too.
https://github.com/coreos/flannel/blob/master/dist/extension...
In WireGuard for MacOSit also has a very very simple wireguard plugin that "just works" in my experience. You can read the entire thing in a minute.
https://github.com/coreos/flannel/blob/master/dist/extension...
In Benchmark results of Kubernetes network plugins over 10Gb/s networkThanks for the examples!
https://github.com/coreos/flannel/tree/master/vendor
In Golang: Don't be afraid of makefilesYes, that's an option -- the simplest option would be a single overlay network, with the node-node tunnels encrypted using IPSec or similar (https://github.com/coreos/flannel/issues/6 or https://www.weave.works/documentation/net-latest-how-it-work... or https://github.com/projectcalico/felix/issues/997). I think this would be tricky to configure in GKE though.
With a secret-per-pod, your key material lives in in the etcd on the API server, and gets mounted in a tmpfs on each pod that is given the secret. Only Pods in the Secret's namespace can access the Secret, so if you have RBAC configured correctly it should be possible to lock this down tightly to only the code that needs the Secret. (I'm not sure how to do this in GKE; I'm currently treating each cluster as a single security domain).
In Let’s Encrypt, OAuth 2, and Kubernetes IngressFlannel is actively maintained. But, it is a mature project that doesn't have a ton of active needs.
The most recent release added a major feature: etcd-less mode backed by Kubernetes. https://github.com/coreos/flannel/releases/tag/v0.7.0
In Will CoreOS stop supporting flannel too?I will try and answer networking question.
At scale a single host can be running may be 20 containers and port collision becomes a real problem. So imagine if a container opened a port directly on host -we have to be careful that they don't step
on each other toes.
Even if all containers used some sort of contract about which port they are going to use - there are all sort of corner cases waiting to happen such as ephemeral ports(the port you bind to when you connect externally) taking over a port taken by real server app.
I have seen two approaches being used to solve this problem:
1. Using Smartstack (http://nerds.airbnb.com/smartstack-service-discovery-cloud/) the applications running inside container can run
on any port but the port on which they are externally available is decided by orchestration service. Typically, no one talks to
Read the rest
application
inside container directly but they go through the haproxy configured
on localhost. The advantage is - smartstack can remove a service if it
is failing healthcheck etc.
2. The kubernetes/openshift approach of Software defined networking(https://github.com/coreos/flannel). Although they also integrate with load balancers, so that is not the only way.
I know if someone is just getting started with containers, it seems bit overwhelming to digest all this. But having worked in some large
companies which are using containers at scale, it kinda makes sense.
It's really not that difficult to network containers. We're using flannel [1] on CoreOS. We're using flannel's VXLAN backend to encapsulate container traffic. We're Kubernetes users so every kube pod [2] gets it's own subnet and flannel handles the routing between those subnets, across all CoreOS servers in the cluster.
I was skeptical when we first deployed it but we've found it to be dependable and fast. We're running it in production on six CoreOS servers and 400-500 containers.
We did evaluate Project Calico initially but discovered some performance tests that tipped the scales in favor of flannel. [3] I don't know if Calico has improved since then, however. This was about a year ago.
[1] https://github.com/coreos/flannel
[2] A Kubernetes pod is one or more related containers running on a single server
[3] http://www.slideshare.
Read the rest
AWS has VPCs, allowing you to get a practically unlimited number of private subnets.
In some cloud environments (e.g. DigitalOcean), there's no private subnet shared between hosts, so Kubernetes can't just hand out unique IPs to pods and services. So you need something like Flannel, which can set up a VPC either with UDP encapsulation or VxLAN.
Flannel also has a backend for AWS, but all it does is update the routing table for your VPC. Which can be useful, but can also be accomplished without Flannel. It's also limited to about 50 nodes [1] and only one subnet, as far as I know. I don't see the point of using it myself.
[1] https://github.com/coreos/flannel/issues/164
In Kubernetes 1.3 releasedI'd like to see a better explanation of how this compares to the various Flannel backends (https://github.com/coreos/flannel#backends), and also how this would be plugged into a Kubernetes cluster.
In Introducing the Fan – simpler container networkingIndeed the networking requirements of Kubernetes are very different from that of Docker.
However, it isn't too difficult to setup a Layer 2 unification overlay network. I've had success with flannel[1], it's pretty easy to set up and supports VxLAN.
[1] https://github.com/coreos/flannel
In Kubernetes: The Future of Deployment> we set out to build and deliver Google’s infrastructure to everyone else
This statement rings pretty true as Kubernetes (also known as k8s) has some Google biases. Not all cloud providers will have such an easy time providing all the infrastructure necessary to run CoreOS + k8s smoothly.
For example, Kubernetes assigns each Pod (k8s unit of computation) an IP address, which is only simple to do if your cloud provider supplies something like a /24 private block to your nodes. CoreOS came up with the VXLAN-based Flannel project to make this model more portable[0], but Layer 2 over Layer 3 isn't something I'd like to throw haphazardly into my production environments. Google Compute Engine conveniently provides this setup as an option.
Another example of Google-favoritism is the strong preference of centralized storage--particularly GCEPers
Read the rest
istentDisk. At first I was concerned about centralized storage by default as we know disk locality is a Good Thing (TM), but after reading a paper that claimed networking is improving faster than disks are[2], I felt somewhat better about this. However, it's still pretty obvious that a Google Persistent Disk is the way to go with k8s[3].
That said, I'm really happy that Google has open-sourced this project because it is indeed a functioning, tested, and easy-to-use distributed system. I'm sure that the devs aren't aggressively shutting out other cloud providers and that these biases are probably just a side-effect of their resource allocation process and the problems that they intend to solve (e.g. GCEPersistentDisk used to be a core type instead of a module--it has since gotten better). It's still important to evaluate a technology's biases and potential evolution before throwing your product on it.
[0] https://github.com/coreos/flannel
[1] https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...
[2] http://www.eecs.berkeley.edu/~ganesha/disk-irrelevant_hotos2...
[3] Do you see any other providers here? https://github.com/GoogleCloudPlatform/kubernetes/tree/maste...
Great work! I was exploring the distributed docker networking space yesterday for an open source project I'm working on (https://github.com/pnegahdar/sporedock) and the ones I have currently found are:
Weave - https://github.com/zettio/weave
Ambassadord - https://github.com/progrium/ambassadord
Warmhole - https://github.com/vishvananda/wormhole
QTunnel (not docker specific) - https://github.com/getqujing/qtunnel
Flannel - https://github.com/coreos/flannel
I'd love a comparison write up if you guys ever get to it.
In WeaveDNS – A distributed DNS service for a weave network