@@ -58,13 +58,7 @@ If none of those approvers are still appropriate, then changes to that list
58
58
should be approved by the remaining approvers and/or the owning SIG (or
59
59
SIG Architecture for cross-cutting KEPs).
60
60
-->
61
- # KEP-NNNN: Your short, descriptive title
62
-
63
- <!--
64
- This is the title of your KEP. Keep it short, simple, and descriptive. A good
65
- title can help communicate what the KEP is and should be considered as part of
66
- any review.
67
- -->
61
+ # KEP-4410: Kubernetes Networking reImagined
68
62
69
63
<!--
70
64
A table of contents is helpful for quickly jumping to sections of a KEP and for
@@ -177,14 +171,19 @@ This proposal is to design and implement the KNI [Kubernetes Networking Interfac
177
171
178
172
## Motivation
179
173
180
- <!--
181
- This section is for explicitly listing the motivation, goals, and non-goals of
182
- this KEP. Describe why the change is important and the benefits to users. The
183
- motivation section can optionally provide links to [experience reports] to
184
- demonstrate the interest in a KEP within the wider Kubernetes community.
185
-
186
- [experience reports]: https://github.com/golang/go/wiki/ExperienceReports
187
- -->
174
+ Kubernetes networking has traditionally been challenging to understand for users
175
+ interacting with the Kubernetes API, and there has been considerable flexibility
176
+ in how Container Network Interfaces (CNIs) set up networking within clusters.
177
+ This has resulted in a scenario where things like pod networking (including pod
178
+ to pod networking) is opaque to users, with different implementations taking
179
+ markedly different approaches. This fragmentation and issues with the API have
180
+ negatively impacted adoption in sectors such as telecommunications. Our goal is
181
+ to transform Kubernetes networking by making networks and their components
182
+ actual resources within the Kubernetes API. This will allow for the development
183
+ of shared functionalities and their integration into the API. We anticipate that
184
+ this new approach will enhance support for areas that are currently struggling,
185
+ facilitate the development and promotion of common features, and better define
186
+ and accommodate advanced functionalities and potential areas for expansion.
188
187
189
188
### Goals
190
189
0 commit comments