Support Kubernetes multi-network
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 11.5k
- Forks
- 1.4k
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 53
Description
**Issue type**
- Feature request
**Support for Kubernetes multi-network**
We would like Linkerd2 to support multi-network in Kubernetes. For context:
Spec: https://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR7UdTPAG_RNydhVE1Kx54kFQ/edit
Reference implementation: https://github.com/intel/multus-cni
Roughly this works by having a management network which is the existing pod network, and additional networks that are created independent of Kubernetes and are only known to the K8s API as annotations to pods and services. Endpoints objects for services are created by an extra controller (still at prototype level - see https://github.com/K8sNetworkPlumbingWG/k8s-net-attach-def-controller).
From the Linkerd point of view, I think the changes required are:
1. Some careful configuration of the network and Linkerd so that the proxy only picks up traffic for the correct network (not a code change, just config documentation).
2. For outbound connections, Linkerd should explicitly bind to the same source IP address as the pod bound to (since there may be multiple IPs in play).
3. For incoming connections, Linkerd should explicitly connect to the correct IP, based on the IP on the incoming request (before iptables got its hands on it). It may already do what I would hope.
It's quite possible that my limited Rust knowledge has led me to miss that it already does what we want in at least some of these cases, which would obviously be great news.
**Next steps**
I'd like to understand
- if there is an objection to this in principle;
- if anybody else has done anything in this area.
In due course, I hope to prototype this and see how hard it seems to be, with perhaps a PR down the line.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked multi-network specification and the Multus CNI reference implementation, then review Linkerd's current proxy networking behavior against the three proposed changes. A useful outcome would establish whether the behavior already exists, document the required network configuration, and prototype or specify source-IP binding for outbound and incoming connections.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, rust
- Domain
- devops, distributed-systems, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100