|
| 1 | +# KEP-4004: Deprecate the kubeProxyVersion field of v1.Node |
| 2 | + |
| 3 | +<!-- toc --> |
| 4 | +- [Release Signoff Checklist](#release-signoff-checklist) |
| 5 | +- [Summary](#summary) |
| 6 | +- [Motivation](#motivation) |
| 7 | + - [Goals](#goals) |
| 8 | + - [Non-Goals](#non-goals) |
| 9 | +- [Proposal](#proposal) |
| 10 | + - [Risks and Mitigations](#risks-and-mitigations) |
| 11 | +- [Design Details](#design-details) |
| 12 | + - [Versioned API Change: NodeStatus v1 core](#versioned-api-change-nodestatus-v1-core) |
| 13 | + - [NodeStatus Internal Representation](#nodestatus-internal-representation) |
| 14 | + - [Test Plan](#test-plan) |
| 15 | + - [Prerequisite testing updates](#prerequisite-testing-updates) |
| 16 | + - [Unit tests](#unit-tests) |
| 17 | + - [Integration tests](#integration-tests) |
| 18 | + - [e2e tests](#e2e-tests) |
| 19 | + - [Graduation Criteria](#graduation-criteria) |
| 20 | + - [Alpha](#alpha) |
| 21 | + - [Beta](#beta) |
| 22 | + - [GA](#ga) |
| 23 | + - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy) |
| 24 | + - [Version Skew Strategy](#version-skew-strategy) |
| 25 | +- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire) |
| 26 | + - [Feature Enablement and Rollback](#feature-enablement-and-rollback) |
| 27 | + - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning) |
| 28 | + - [Monitoring Requirements](#monitoring-requirements) |
| 29 | + - [Dependencies](#dependencies) |
| 30 | + - [Scalability](#scalability) |
| 31 | + - [Troubleshooting](#troubleshooting) |
| 32 | +- [Implementation History](#implementation-history) |
| 33 | +- [Drawbacks](#drawbacks) |
| 34 | +- [Alternatives](#alternatives) |
| 35 | +<!-- /toc --> |
| 36 | + |
| 37 | +## Release Signoff Checklist |
| 38 | + |
| 39 | +Items marked with (R) are required *prior to targeting to a milestone / release*. |
| 40 | + |
| 41 | +- [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) |
| 42 | +- [ ] (R) KEP approvers have approved the KEP status as `implementable` |
| 43 | +- [ ] (R) Design details are appropriately documented |
| 44 | +- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) |
| 45 | + - [ ] e2e Tests for all Beta API Operations (endpoints) |
| 46 | + - [ ] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) |
| 47 | + - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free |
| 48 | +- [ ] (R) Graduation criteria is in place |
| 49 | + - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) |
| 50 | +- [ ] (R) Production readiness review completed |
| 51 | +- [ ] (R) Production readiness review approved |
| 52 | +- [ ] "Implementation History" section is up-to-date for milestone |
| 53 | +- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] |
| 54 | +- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes |
| 55 | + |
| 56 | + |
| 57 | +[kubernetes.io]: https://kubernetes.io/ |
| 58 | +[kubernetes/enhancements]: https://git.k8s.io/enhancements |
| 59 | +[kubernetes/kubernetes]: https://git.k8s.io/kubernetes |
| 60 | +[kubernetes/website]: https://git.k8s.io/website |
| 61 | + |
| 62 | +## Summary |
| 63 | + |
| 64 | +Deprecate the `status.nodeInfo.kubeProxyVersion` field of v1.Node |
| 65 | + |
| 66 | +## Motivation |
| 67 | + |
| 68 | +This field is not accurate, the field is set by kubelet, which does not actually know the kube-proxy version, |
| 69 | +or even if kube-proxy is running. |
| 70 | + |
| 71 | +### Goals |
| 72 | + |
| 73 | +- Mark `status.nodeInfo.kubeProxyVersion` deprecated. |
| 74 | +- Find any places use it and get them to stop. |
| 75 | +- Make kubelet stop setting the field. |
| 76 | + |
| 77 | +### Non-Goals |
| 78 | + |
| 79 | +## Proposal |
| 80 | + |
| 81 | +The proposal is to deprecate the `kubeProxyVersion` field of `NodeStatus`, and to stop setting it in the future. |
| 82 | + |
| 83 | +This field was used by the GCP cloud provider up until 1.28 for the legacy built-in cloud provider ([kubernetes #117806], and up until 1.29 for the external cloud-provider ([cloud-provider-gcp #533]). It may also be used by other components. Thus, we will use a feature gate to protect it until all components are fixed. |
| 84 | + |
| 85 | +[kubernetes #117806]: https://github.com/kubernetes/kubernetes/pull/117806 |
| 86 | +[cloud-provider-gcp #533]: https://github.com/kubernetes/cloud-provider-gcp/pull/533 |
| 87 | + |
| 88 | +### Risks and Mitigations |
| 89 | + |
| 90 | +## Design Details |
| 91 | + |
| 92 | +### Versioned API Change: NodeStatus v1 core |
| 93 | + |
| 94 | +Mark the kubeProxyVersion field as Deprecated. |
| 95 | + |
| 96 | +``` |
| 97 | +// Deprecated: KubeProxy Version reported by the node. |
| 98 | +KubeProxyVersion string `json:"kubeProxyVersion" protobuf:"bytes,8,opt,name=kubeProxyVersion"` |
| 99 | +``` |
| 100 | + |
| 101 | +### NodeStatus Internal Representation |
| 102 | + |
| 103 | +Mark the kubeProxyVersion field as Deprecated. |
| 104 | + |
| 105 | +``` |
| 106 | +// Deprecated: KubeProxy Version reported by the node. |
| 107 | +KubeProxyVersion string |
| 108 | +``` |
| 109 | + |
| 110 | +### Test Plan |
| 111 | + |
| 112 | +[x ] I/we understand the owners of the involved components may require updates to |
| 113 | +existing tests to make this code solid enough prior to committing the changes necessary |
| 114 | +to implement this enhancement. |
| 115 | + |
| 116 | +##### Prerequisite testing updates |
| 117 | + |
| 118 | + |
| 119 | +##### Unit tests |
| 120 | + |
| 121 | +- Add a test to `TestVersionInfo` in `pkg/kubelet/nodestatus` to see if FeatureGate behaves as expected when it is turned on or off. |
| 122 | +- If DisableNodeKubeProxyVersion FeatureGate is enabled: |
| 123 | + - `status.nodeInfo.kubeProxyVersion` will be empty. |
| 124 | +- Else: |
| 125 | + - `status.nodeInfo.kubeProxyVersion` will be not empty . |
| 126 | + |
| 127 | +##### Integration tests |
| 128 | + |
| 129 | +- N/A |
| 130 | + |
| 131 | +##### e2e tests |
| 132 | + |
| 133 | + - N/A |
| 134 | + |
| 135 | +### Graduation Criteria |
| 136 | + |
| 137 | +#### Alpha |
| 138 | + |
| 139 | +- Created the feature gate, disabled by default. |
| 140 | +- Started looking for components that might be using the deprecated field. |
| 141 | + |
| 142 | +#### Beta |
| 143 | + |
| 144 | +- Make sure that upgrades to the Beta version will work across supported levels of [version skew](https://kubernetes.io/releases/version-skew-policy/). |
| 145 | + |
| 146 | +#### GA |
| 147 | + |
| 148 | +- No issues reported during two releases. |
| 149 | + |
| 150 | +### Upgrade / Downgrade Strategy |
| 151 | + |
| 152 | +N/A |
| 153 | + |
| 154 | +### Version Skew Strategy |
| 155 | + |
| 156 | +## Production Readiness Review Questionnaire |
| 157 | + |
| 158 | +### Feature Enablement and Rollback |
| 159 | + |
| 160 | +###### How can this feature be enabled / disabled in a live cluster? |
| 161 | + |
| 162 | +- [x] Feature gate (also fill in values in `kep.yaml`) |
| 163 | + - Feature gate name: DisableNodeKubeProxyVersion |
| 164 | + - Components depending on the feature gate: kubelet |
| 165 | + |
| 166 | +###### Does enabling the feature change any default behavior? |
| 167 | + |
| 168 | +Yes, it makes kubelet stop setting `node.status.nodeInfo.kubeProxyVersion`. |
| 169 | + |
| 170 | +###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)? |
| 171 | + |
| 172 | +Yes. Using the featuregate is the only way to enable/disable this feature. |
| 173 | + |
| 174 | +###### What happens if we reenable the feature if it was previously rolled back? |
| 175 | + |
| 176 | +The feature should continue to work just fine. |
| 177 | + |
| 178 | +###### Are there any tests for feature enablement/disablement? |
| 179 | + |
| 180 | +No, we don't need to test what happens when the value of the field changes, because our goal is to make sure no one is looking at the value at all, so no components should notice if the value changes. |
| 181 | + |
| 182 | +### Rollout, Upgrade and Rollback Planning |
| 183 | + |
| 184 | +###### How can a rollout or rollback fail? Can it impact already running workloads? |
| 185 | + |
| 186 | +If there is a component that we didn't know about using kubeProxyVersion, then it may fail in some unknown way when the administrator upgrades to a version with that field disabled. It should be possible to just roll back in this case. |
| 187 | + |
| 188 | +###### What specific metrics should inform a rollback? |
| 189 | + |
| 190 | +N/A |
| 191 | + |
| 192 | +###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested? |
| 193 | + |
| 194 | +N/A |
| 195 | + |
| 196 | +###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.? |
| 197 | + |
| 198 | +No |
| 199 | + |
| 200 | +### Monitoring Requirements |
| 201 | + |
| 202 | +* N/A |
| 203 | + |
| 204 | +### Dependencies |
| 205 | + |
| 206 | +###### Does this feature depend on any specific services running in the cluster? |
| 207 | + |
| 208 | +### Scalability |
| 209 | + |
| 210 | +###### Will enabling / using this feature result in any new API calls? |
| 211 | + |
| 212 | +No |
| 213 | + |
| 214 | +###### Will enabling / using this feature result in introducing new API types? |
| 215 | + |
| 216 | +No |
| 217 | + |
| 218 | +###### Will enabling / using this feature result in any new calls to the cloud provider? |
| 219 | + |
| 220 | +No |
| 221 | + |
| 222 | +###### Will enabling / using this feature result in increasing size or count of the existing API objects? |
| 223 | + |
| 224 | +No |
| 225 | + |
| 226 | +###### Will enabling / using this feature result in increasing time taken by any operations covered by existing SLIs/SLOs? |
| 227 | + |
| 228 | +No |
| 229 | + |
| 230 | +###### Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components? |
| 231 | + |
| 232 | +No |
| 233 | + |
| 234 | +###### Can enabling / using this feature result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)? |
| 235 | + |
| 236 | +No |
| 237 | + |
| 238 | +### Troubleshooting |
| 239 | + |
| 240 | +###### How does this feature react if the API server and/or etcd is unavailable? |
| 241 | + |
| 242 | +###### What are other known failure modes? |
| 243 | + |
| 244 | +###### What steps should be taken if SLOs are not being met to determine the problem? |
| 245 | + |
| 246 | +## Implementation History |
| 247 | + |
| 248 | +\- 2023-05-15: Initial draft KEP |
| 249 | + |
| 250 | +## Drawbacks |
| 251 | + |
| 252 | +## Alternatives |
| 253 | + |
0 commit comments