Add support for new Ingress APIs

[JoshDrake-minted]

Ingress with the extensions/v1beta1 API was deprecated in 1.16. The following two API versions map to the corresponding k8s versions:

API Version	Kubernetes Version
networking.k8s.io/v1beta1	1.14 - 1.18
networking.k8s.io/v1	1.19+

Furthermore, the current Ingress class has the _non_standard_version set to v1beta1, which makes it impossible to override the apiVersion with the parameter when instantiating it.

I'm fairly new to using this library (thanks, by the way!), so I'm unsure how you'd prefer to handle this. If it's relatively straightforward, feel free to provide some high-level guidance and I can work on a PR.

[JoshDrake-minted]

For anyone else reading, a simple workaround is the following:

from avionix.kube.extensions import Ingress

# workaround for being unable to specify newer ingress API versions
class PatchedIngress(Ingress):
    _non_standard_version = ""

ingress = PatchedIngress(
    metadata=metadata,
    api_version='networking.k8s.io/v1',
    spec=IngressSpec(
        rules=rules
    ),
)

[zbrookle]

@JoshDrake-minted I'm actually going to change the logic so that user input takes priority in the event that a user enters a version. That way, even if the package isn't totally up to date, a user can still input whatever version they need. That being said, if you want to make a pull request to update ingress to the most recent structure, that would be great. You'd have to remove the non standard version and then replace it's base class with the networking base class, should be fairly straightforward. The base classes are all declared under avionix/kube/base_objects.py

[ltsonov-cb]

Writing in this thread as our problem seems similar.

We want to utilize Ingress v1, however we also specify default backends and backends in general.
These have a breaking change, where the backend should be defaultBackend and serviceName/servicePort are service.name/service.port.number respectively.

Unfortunately even if I force the version to be v1 as noted above, these values still render with their old name and are rejected on cluster 1.22+.

Is this a supported scenario? Have you considered doing something similar to client-go where objects are versioned in separate packages so one can initialize networking/v1/Ingress or networking/v1beta1/Ingress as needed?

Here is an example of the produced YAML:

kind: Ingress
metadata:
  name: test-ingress-gnji-xslagdwt
  namespace: test-namespace-gnji-cy0tt713
spec:
  backend:
    serviceName: some-service
    servicePort: 8080
  rules:
  - http:
      paths:
      - backend:
          serviceName: some-service
          servicePort: 8080
        path: /foo
      - backend:
          serviceName: some-service
          servicePort: 8080
        path: /bar