Backwards support for old Kubernetes versions

[lujiajing1126]

Requirement - what kind of business use case are you trying to solve?

Support Kubernetes v1.16.

It is normally not an easy task to upgrade Kubernetes cluster.

Problem - what in Jaeger blocks you from solving the requirement?

In the latest release, I noticed that we have to use Kubernetes > 1.19 as mentioned in #1456 .

Proposal - what do you suggest to solve the problem or improve the existing situation?

Is that still possible to support legacy versions?

Any open questions to address

It seems the apiextensions.k8s.io/v1beta1 crd is supported from v1.16 from the document

So the breaking change is caused by networking.k8s.io/v1 API usage?

[jpkrohling]

@rubenvp8510, can we revert the networking changes? Or was it required for some reason?

[rubenvp8510]

The network changes are not only on the version of the API (networking.k8s.io/v1beta1 => networking.k8s.io/v1), the Ingress definition also changed a little bit (https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122) , if we want to use the new version (to be compatible with 1.22) we need those changes.

In order to be compatible with both old/new APIs we need to do extra work.

[lujiajing1126]

The network changes are not only on the version of the API (networking.k8s.io/v1beta1 => networking.k8s.io/v1), the Ingress definition also changed a little bit (https://kubernetes.io/docs/reference/using-api/deprecation-guide/#ingress-v122) , if we want to use the new version (to be compatible with 1.22) we need those changes.

In order to be compatible with both old/new APIs we need to do extra work.

I will try to investigate the possibilities and cost to keep the backward compatibility.

[pavolloffay]

Now the readme documents which k8s verisons are supported.