Dropping kubernetes version support in feature version

[aschleifer]

Hi,

version 4.3.0 of the helm chart is dropping support for kubernetes 1.20. I would consider such a change as a breaking change.

In our company we use Renovate bot to automatically merge feature and bugfix version updates for helm charts to our dev clusters.

Unfortunately we are still running on kubernetes 1.20 and such the auto-deployment of this version crashed all our ingresses on our dev clusters.

In my opinion this shouldn't happen as by definition of Semantic Versioning (specifically see https://semver.org/#if-even-the-tiniest-backwards-incompatible-changes-to-the-public-api-require-a-major-version-bump-wont-i-end-up-at-version-4200-very-rapidly) any backwards compatible breaking change should be a major version change.

[k8s-ci-robot]

@aschleifer: This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[longwuyuan]

@aschleifer it happend in unusual circumstances so kindly bear. Project is in feature-freeze phase till December 2022 at least. And all resources are on stabilization efforts to keep things sane and reasonable. These releases are forced due to CVEs and critical bugs or API deprecations.

Things will get better in 2023.

/remove-kind bug

[bmv126]

@aschleifer
Can you share the error message with which deployment failed, so that it can help others who will face similar issue.

[lmad4832]

1.4.0 updates ingress-nginx to use Endpointslices instead of Endpoints. This will cause nginx to have no active endpoints for the ingress objects. Faced the same issue on one of our non-prod clusters which is running v1.20.

[Segaja]

@aschleifer Can you share the error message with which deployment failed, so that it can help others who will face similar issue.

I don't have an exact error messages but all URLs to the clusters resulted in 503 errors

/edit: Sorry for the confusion, but this is my private account and @aschleifer is my work account.

[lmad4832]

@aschleifer Can you share the error message with which deployment failed, so that it can help others who will face similar issue.

W1003 14:35:42.407767 7 controller.go:1112] Service "namespace/service" does not have any active Endpoint. W1003 14:35:42.407777 7 endpointslices.go:81] Error obtaining Endpoints for Service "namespace/service": no object matching key "namespace/service" in local store

The above error will be there for all the ingress objects resulting 503 error.

[longwuyuan]

@lmad4832 , just FYI, one of the aspects here is that K8S v1.25 is the current release of K8S. So need to be in sync with API changes. You can observe that normally it will be current release plus 2 previous releases supported.

The good thing is that the older releases of the ingess-nginx-controller are not removed from the registry. So its possible to check compatibility, dependency, changelog etc and continue to use a version of the controller that works best.

[Segaja]

The good thing is that the older releases of the ingess-nginx-controller are not removed from the registry. So its possible to check compatibility, dependency, changelog etc and continue to use a version of the controller that works best.

I'm not denying that being up-to-date is important and that we should update. But semantic versioning teaches us that as long as the first digit in the version number doesn't change you can upgrade the software (the helm chart in this case) without issues, as the only changes you will get are bugfixes (third digit) and news feature you can use but don't have to (second digit).

A change as we saw here in a minor version number (second digit) is a breakage of this semantic versioning and this is what lead to our issue of auto-updating this on our clusters and then having to fix it.

Again. I fully agree that we as a customer need to update our clusters and then want to use the new versions of the helm charts.

[longwuyuan]

Thanks for understanding. Agreed there is room for improvement and helping avoid such issues. Just hoping the info got out to you that on one hand the entire story is in the Annoucement made and he PRs and the issues. Short comments will not justify. Its just current circumstances. And efforts are underway to stabilize on all fronts so hopefully semver alignment will also occur due to stabilization. This issue is duly noted I think.

[tao12345666333]

yes. please see:

• feat: switch from endpoints to endpointslices #8890 (review)
• feat: switch from endpoints to endpointslices #8890 (comment)

[tao12345666333]

I don't know if enabling the feature gate for endpointslices in v1.20 will make it continue to work

[bmv126]

@tao12345666333 @longwuyuan
https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/ is stable in 1.21.
So it should still work on 1.21 right

Why 1.21 support is removed from supported versions ?
https://github.com/kubernetes/ingress-nginx#support-versions-table

[rikatz]

We are following as much as possible the same semantics of Kubernetes.

It is not sustainable for the project to maintain versions that below, so our commitment is v-4 (eg.: we are on k8s v1.29, so we support from v1.26 to v1.29).

I'm closing this right now, let me know if I have missing some more context
/close

[k8s-ci-robot]

@rikatz: Closing this issue.

In response to this:

We are following as much as possible the same semantics of Kubernetes.

It is not sustainable for the project to maintain versions that below, so our commitment is v-4 (eg.: we are on k8s v1.29, so we support from v1.26 to v1.29).

I'm closing this right now, let me know if I have missing some more context
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.