diff --git a/keps/sig-network/2634-kubeproxy-staging/README.md b/keps/sig-network/2634-kubeproxy-staging/README.md new file mode 100644 index 000000000000..25907e8a2071 --- /dev/null +++ b/keps/sig-network/2634-kubeproxy-staging/README.md @@ -0,0 +1,187 @@ +# KEP-2634: Move Kubeproxy package to staging + +- [Release Signoff Checklist](#release-signoff-checklist) +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [Move the internal network dependencies that kube-proxy already has](#move-the-internal-network-dependencies-that-kube-proxy-already-has) + - [Move other dependencies kube-proxy already has inside k/k](#move-other-dependencies-kube-proxy-already-has-inside-kk) + - [Move feature gate package dependency](#move-feature-gate-package-dependency) + - [Move pkg/proxy to kubernetes/kube-proxy](#move-pkgproxy-to-kuberneteskube-proxy) + - [Risks and Mitigations](#risks-and-mitigations) + - [Test Plan](#test-plan) + - [Graduation Criteria](#graduation-criteria) +- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire) + - [Feature Enablement and Rollback](#feature-enablement-and-rollback) + - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) + + +## Release Signoff Checklist +- [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) +- [ ] (R) KEP approvers have approved the KEP status as `implementable` +- [ ] (R) Design details are appropriately documented +- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) +- [ ] (R) Graduation criteria is in place +- [ ] (R) Production readiness review completed +- [ ] (R) Production readiness review approved +- [ ] "Implementation History" section is up-to-date for milestone +- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] +- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes + +[kubernetes.io]: https://kubernetes.io/ +[kubernetes/enhancements]: https://git.k8s.io/enhancements +[kubernetes/kubernetes]: https://git.k8s.io/kubernetes +[kubernetes/website]: https://git.k8s.io/website + +## Summary +kube-proxy packages actually are present inside Kubernetes repo, inside +[pkg/proxy](https://github.com/kubernetes/kubernetes/tree/v1.21.0/pkg/proxy) and +the idea is to move it its own repo, already existing in +[kubernetes/kube-proxy](https://github.com/kubernetes/kube-proxy) repo + + +## Motivation + +We are seeing the rise of a lot of kube-proxy implementations. Although each of them +follow their own dataplane implementation (IPTables, IPVS, eBPF, open flow programming), +every implementation needs to follow the same logic: watching Services, Endpoints and +most recently EndpointSlices. + +Everytime we change the logic from Services, each of those implementations need to make +changes into their code base to be compliant with the new features. Some of them vendor +the whole kubernetes/kubernetes repo, while others copy all the code base to their own +repository. + +Moving pkg/proxy logics to its own repo will allow a better decoupling of the code, +the evolution of proxy features without being tighten to kubernetes main code and also +to future kube-proxy implementations to import this logic without needing to import the +whole Kubernetes code. + +This was also motivated by [kubernetes #92369](https://github.com/kubernetes/kubernetes/issues/92369) + +### Goals + +* Move kube-proxy repo to `kubernetes/kube-proxy` repo +* Decouple kube-proxy from internal kubernetes dependencies + +### Non-Goals +* Implementing interfaces for kube-proxy new implementations (like virtual-kubelet, +but for proxies). This can be addressed on a later KEP + +## Proposal + +kube-proxy already have its own repo. The proposal is to: + +### Move the internal network dependencies that kube-proxy already has +kube-proxy have some internal dependencies, mostly notable in `kubernetes/pkg/utils`. We +can nominate some of them being `iptables`, `ipvs` and `conntrack` packages, but there are +others as well. + +We need to move these dependencies to some repo that does not force kube-proxy to also +vendor the whole kubernetes repo. + +<<[UNRESOLVED repository for network utils ]>> +Although the majority of utils used by kube-proxy can be moved to component-helpers, +some still vendors external dependencies (like `moby/ipvs`). +If we move every pkg/utils used by kube-proxy to component helpers, another project +already vendoring it (like kubectl) might vendor moby/ipvs because of transitive +dependencies. +We need to define if network utils should be moved to its own repo (suggesting kubernetes/net-utils) +or if we can accept that other projects vendoring `component-helpers` are going to vendor the +dependencies of kube-proxy as well +<<[/UNRESOLVED]>> + +### Move other dependencies kube-proxy already has inside k/k +kube-proxy vendors some packages that are used by other parts of kubernetes codebase. +From now, we can point: +* pkg/util/async (async bounder) which is used by pkg/controlplane +* pkg/util/sysctl which is used by pkg/kubelet and kubemark + +### Move feature gate package dependency +Because kube-proxy relies on defined Feature gates, it vendors `pkg/features`. + +This needs to be copied/moved the same way controller manager already does, moving this to +`kubernetes/kube-proxy/pkg/features` and changing on the code, and putting all the feature +gates referenced by kube-proxy there + +### Move pkg/proxy to kubernetes/kube-proxy +The final step is to move pkg/proxy to `kubernetes/kube-proxy/pkg` and let people willing +to vendor kube-proxy to change from kubernetes/kubernetes to this repo. + +### Risks and Mitigations +"If a project vendors Kubernetes to import kubeproxy code, this will break them. +On the bright side, afterwards, these importers will have a much cleaner path to +include kubeproxy code. Before moving forward with this plan, we will identify +and communicate to these projects." - Shameless copied from +[kubectl moving](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/1020-kubectl-staging) + +### Test Plan + +All the existing kube-proxy tests will be migrated to point to the new repo location + +### Graduation Criteria +As this is a file location move, the graduation criteria will be "every tests still passes" + + +## Production Readiness Review Questionnaire + +### Feature Enablement and Rollback + +Not applicable + +###### How can this feature be enabled / disabled in a live cluster? + +- [ ] Feature gate (also fill in values in `kep.yaml`) + - Feature gate name: not applicable + - Components depending on the feature gate: + +###### Does enabling the feature change any default behavior? + +Not applicable + +###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)? + +Not applicable + +###### What happens if we reenable the feature if it was previously rolled back? + +Not applicable + +###### Are there any tests for feature enablement/disablement? + +Not applicable + +### Rollout, Upgrade and Rollback Planning + +Not applicable + +###### How can a rollout fail? Can it impact already running workloads? + +Not applicable + +###### What specific metrics should inform a rollback? + +Not applicable + +###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested? + +Not applicable + +###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.? + +Not applicable + +## Drawbacks + +* This can cause some noise with people already implementing their own kube-proxy and +currently happy about vendoring kubernetes/kubernetes repo +* Put some effort while there's already an alternative being developed (see below) + +## Alternatives + +There's already an effort to evolve kube-proxy, called [kpng](https://github.com/kubernetes-sigs/kpng) +but we believe that the effort of both can run in parallel diff --git a/keps/sig-network/2634-kubeproxy-staging/kep.yaml b/keps/sig-network/2634-kubeproxy-staging/kep.yaml new file mode 100644 index 000000000000..5de5ec4e6199 --- /dev/null +++ b/keps/sig-network/2634-kubeproxy-staging/kep.yaml @@ -0,0 +1,29 @@ +title: Move kubeproxy to staging +kep-number: 2634 +authors: + - "@rikatz" + - "@aojea" + - "@jayunit100" +owning-sig: sig-network +status: implementable +creation-date: 2021-04-18 +reviewers: + - TBD +approvers: + - TBD +prr-approvers: + - TBD +# The target maturity stage in the current dev cycle for this KEP. +stage: stable + +# The most recent milestone for which work toward delivery of this KEP has been +# done. This can be the current (upcoming) milestone, if it is being actively +# worked on. +latest-milestone: "v1.22" + +# The milestone at which this feature was, or is targeted to be, at each stage. +milestone: + stable: "v1.22" + +# The following PRR answers are required at alpha release +# List the feature gate name and the components for which it must be enabled