From 3a46649e8d51411511961c18ee4ba91f97a5fbf2 Mon Sep 17 00:00:00 2001 From: Tomofumi Hayashi Date: Tue, 23 Apr 2024 16:25:58 +0900 Subject: [PATCH] Update README.md --- README.md | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 3094fbb..0e8fbdf 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,24 @@ -# multus-service - +# multus-service (archived) ## Current Status of Repository -It is now pretty early stage of development, hence everything may be changed without any notification. Please do NOT use it as production. We don't support any question about how-to-use/how-to-deploy until current development status is changed. +In [the NPWG call at April 18](https://docs.google.com/document/d/1oE93V3SgOGWJ4O1zeD1UmpeToa0ZiiO6LqRAmZBPFWM/edit#heading=h.40vwjmncy42s), we decide that this repository is archived. But this does NOT means Kubernetes service for secondary interfaces is impossible. Here is the reason why we decide to close. + +- Insufficient use-cases and feedback + + Secondary network is used varous scenarios, such as to connect isolated network (i.e. closed network), to connect high-speed network and so on. Hence multus-service also needs to apply such various use-cases and we need to gather the use-cases and requirements not only from users also from vendors. We have insufficient use-cases and feedback in NPWG meeting hence we cannot disucss how user want to use the service for secondary network. Kubernetes service functionality is not a single functionality, composition of various functions (i.e. NodePort, headless service, load-balancer and so on), so use-cases and feedback were pretty important. + +- Kubernetes community want to use Gateway API, instead of endpoint/endpointslices API + + [Tim Hockin's LT at KubeCon 2023 NA](https://www.youtube.com/watch?v=Oslwx3hj2Eg) mentions that Kubernetes Gateway API could be replaced with Kubernetes Service API. This repository uses service API, hence this repository is not aligned with current Kubernetes architecture based on Tim Hockin's presentation. So if we need to implement it, Gateway API should be used to align Kubernetes architecture. It should be implemented from scratch, not from this repository. + +- Several community, including Kubernetes community itself, started the discussion about secondary network service + +Currently, Kubernetes sig-network launches [Multi-network WG](https://github.com/kubernetes/community/blob/master/sig-network/README.md) and discusses about multiple network interfaces in Kubernetes Pod, including Service and other Kubernetes functionalities (e.g. NetworkPolicy). So I expects that this working group will provide the design and API for Kubernetes service for secondary network interfaces, not this repository. So if there is someone who really wants this feature, I strongly recommend to join this multi-network WG and provide your use-case scenarios. + +Here are the reasons. So this repository archives is not end of development, just restart the design discussion with use-cases in another working group. Please join the community and discuss about your use-cases in the community if you want the feature. +--- ## Description