Mirror
/
k3s
mirror of https://github.com/k3s-io/k3s.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: adrs: Dual-stack in network policy agent 

Proposal about implementing dual stack in k3s network policy agent,
kube-router and the procedure of that implementation.

Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
This commit is contained in:
Michal Rostecki 2021-12-13 19:12:54 +01:00
parent 2f3bfc27c0
commit 73725a0882
1 changed files with 57 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
docs/adrs/002-add-dual-stack-support-to-netpol-agent.md Normal file
View File

@ -0,0 +1,57 @@
# 1. Add dual stack support to netpol agent
Date: 2021-12-13
## Status
Accepted
## Context
Currently the network policy agent included in k3s is in fact a copied code of
[kube-router's](https://github.com/cloudnativelabs/kube-router) network policy
controller, which can be found [here](https://github.com/k3s-io/k3s/tree/master/pkg/agent/netpol).
The first and the most important issue is that kube-router lacks support for
dual-stack (and even IPv6 in general in the most of its components). However,
implementing such support is a non-trivial task.
The second issue is that we include a copy of kube-router code in k3s, which
makes it hard to consume updates. Even if we need some changes on top of
upstream code, we should rather use a fork which is easy to rebase with
upstream.
## Decision
We implement a feature of supporting dual stack Kubernetes clusters in network
policy controller in kube-router. We start from network policy controller, as
we don't consume any other kube-router components in k3s.
Once it's done and working, we submit a pull request:
* to [our fork of kube-router](https://github.com/k3s-io/kube-router)
* [upstream](https://github.com/cloudnativelabs/kube-router)
The motivation behind keeping a fork is that:
* upstream might ask for implementing dual-stack in all kube-router
components (which would be understandable)
* acceepting a solution upstream might take long time
Our fork of kube-router is going to be used as a vendored library inside k3s
code. And the currently copied code in k3s in `pkg/agent/netpol` is going to
be removed in favor of using kube-router as a library.
As soon as dual-stack becomes an upstream feature - k3s is going to use
upstream kube-router as a vendored library.
## Consequences
It will increase k3s product portfolio by fully supporting dual-stack
networking.
However, it might also introduce significant amount of work for developers
which could be related to:
* agreeing with proper solution upstream
* maintaining a fork until that happens (rebasing with upstream releases)