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