Migrate Ingress type to networking.k8s.io/v1beta1

[cmluciano]

The deprecation process for the Ingress extensions type is almost complete and 1.15 will persist Ingress types in the new networking.k8s.io/v1beta1 . This report is to track ingress-gce moving to the new api group similar to the ingress-nginx PR.

cc @bowei @freehan

[snebel29]

Hi,
I'm working in a tool called kwatchman that uses controller machinery, I was about to implement the ingress resource when realize that from 1.14 the new api group networking.k8s.io for ingress is available, and extensionsv1beta1 is deprecated, of course you still can use the deprecated api group but at some point this will be removed.

Given that for a while clusters from 1.11 will exists, I was wondering how others are dealing with such cases to be as transparent as possible for users and came here...

I wonder if go-client offers a way to discover the cluster version at runtime and then you just use conditionals for using the old and/or new api group types, or a strict new version of the controller has to be deployed as requirement, etc.. I guess for an old enough deployed controller this will have to happen anyway, as the new type won't be available in the controller.

I will keep digging on my own, but out of curiosity do you have any plan already in mind? how do you handle such cases?

Thanks

[aledbf]

@snebel29 we (ingress-nginx) check the k8s version https://github.com/kubernetes/ingress-nginx/blob/master/internal/ingress/controller/store/store.go#L270 for the informer and switched everything to networking.k8s.io internally in the ingress controller using a helper https://github.com/kubernetes/ingress-nginx/blob/930e37a0b520cfde5f880cca809d1b7cbe300db5/internal/ingress/controller/store/store.go#L910 for clusters running k8s < 1.14.0

[snebel29]

Oh, this is great @aledbf !
thank you so much for such a good and quick answer.

Saludos y gracias

[rramkumar1]

This was completed in #806. @bowei can this be closed?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cmluciano]

I think this should be good to go

/close

[k8s-ci-robot]

@cmluciano: Closing this issue.

In response to this:

I think this should be good to go

/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.