"network-implementors" repo?

113 views
Skip to first unread message

Dan Winship

unread,
Jul 18, 2023, 11:46:10 AM7/18/23
to kubernetes-sig-network
What do people think about creating a "network-implementors" (exact name
TBD) repo, probably under kubernetes-sigs?

This would give us a place to put documentation specific to
*implementing* Kubernetes networking (and in particular, information
people needed to implement their own networking plugins). Examples
include the service proxy doc I wrote a while back
(https://github.com/kubernetes-sigs/kpng/blob/master/doc/service-proxy.md),
notes on how CloudProviders are expected to program cloud load balancers
so as to work with kube-proxy (see
https://github.com/kubernetes/website/pull/41926#discussion_r1256433546,
https://github.com/kubernetes/enhancements/pull/3460#discussion_r1094740772),
or fiddly details of how NetworkPolicy works (see
https://github.com/kubernetes/website/pull/39875, which is trying to
explain that only from the end-user perspective, but is clearly
*strongly implying* lots of things at implementors).

After the discussion about network reconfiguration, I was also thinking
maybe it would be good to have a wiki(?) containing details about how
networking works with different plugins / platforms. This would help to
make sure we had good documentation of variations between platforms (eg
different ways of assigning pod IPs, different ways of doing LB Service
health checking, etc) and highlight some of the especially
"non-standard" implementation options made by some plugins that we need
to avoid invalidating (eg, clusters where pods get IPs off the node
network instead of having a cluster CIDR; plugins that allow external
traffic to reach ClusterIPs; Cilium's implementation of Services that
involves rewriting connect() calls rather than rewriting packets; etc).
This could also go in the same "network-implementors" repo. (Every
github repo potentially has an associated wiki.) (Maybe we could do it
as markdown files in the repo rather than a wiki but it seems like for
this part, being easily-edited is better than being carefully-reviewed.
Assuming we can make it so that everyone in the kubernetes-sigs org can
edit it, which maybe we can't? Or don't want to?)

-- Dan

Surya Seetharaman

unread,
Jul 18, 2023, 12:52:52 PM7/18/23
to Dan Winship, kubernetes-sig-network
+1 to this idea, much needed!

Best Regards,
-SS


--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/e0e76e0b-2f7d-c28b-537b-098591f2f43d%40redhat.com.

Peter White

unread,
Jul 19, 2023, 7:12:31 AM7/19/23
to kubernetes-sig-network
+1, looks like a very good idea. I see a lot of questions around that this could answer.

Pengfei Ni

unread,
Jul 19, 2023, 8:20:42 AM7/19/23
to Peter White, kubernetes-sig-network
+1. It would be helpful to have a single place to list the differences between network solutions and to document how networking works with different plugins and platforms.


Best regards.


---
Pengfei Ni



Tim Hockin

unread,
Jul 26, 2023, 7:16:21 PM7/26/23
to Pengfei Ni, Peter White, kubernetes-sig-network
Why not k/community/contributors/devel ?

Or, really, why not somewhere in k/k ?
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAJ44hTcPQU8Ew5rn05hQ7mzOD0hfPVCgVNDoKSfh_E%2BEV6D-6Q%40mail.gmail.com.

Tim Hockin

unread,
Jul 26, 2023, 7:24:40 PM7/26/23
to Pengfei Ni, Peter White, kubernetes-sig-network
Reply all
Reply to author
Forward
0 new messages