From 73725a0882c25642fb94f61fd5f68e160416148c Mon Sep 17 00:00:00 2001 From: Michal Rostecki Date: Mon, 13 Dec 2021 19:12:54 +0100 Subject: [PATCH] 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 --- ...-add-dual-stack-support-to-netpol-agent.md | 57 +++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 docs/adrs/002-add-dual-stack-support-to-netpol-agent.md diff --git a/docs/adrs/002-add-dual-stack-support-to-netpol-agent.md b/docs/adrs/002-add-dual-stack-support-to-netpol-agent.md new file mode 100644 index 0000000000..bf0fc4cee5 --- /dev/null +++ b/docs/adrs/002-add-dual-stack-support-to-netpol-agent.md @@ -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)