101_initial_cluster not compatible Kubernetes 1.16

[fly2F]

helm install ../../helm/vitess -f 101_initial_cluster.yaml

Error: validation failed: [unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1", unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta1", unable to recognize "": no matches for kind "EtcdCluster" in version "etcd.database.coreos.com/v1beta2"]

[fly2F]

Continued deprecation of extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs; these extensions will be retired in 1.16!

All resources under apps/v1beta1 and apps/v1beta2 - use apps/v1 instead

[parthibd]

Faced the same bug today while trying out the examples.

[morgo]

I took a look at this today. There will be a bit of work to do, because the etcd-operator we suggest using also uses the deprecated APIs. It looks like they have a pull request waiting to merge, which worked for me: coreos/etcd-operator#2127

[SanmuWangZJU]

The latest update of etcd-operator was ten months ago, it
seems no one maintains this project.
What can we do to adapt helm3 and k8s 1.16+ ?

[morgo]

We spoke about this on the Vitess monthly call. The logical fix to me, is to switch the default topo to "kubernetes" (see #5703 ). We can then run without the etcd-operator.

The k8s topo is in review now. From there it is hopefully straight forward to fix..

[ErikTMA]

Do you have any ETA on this? I am looking into implementing Vitess for the first time, but I am unsure if I should wait for the fix for Helm3+Kubernetes 1.16 or implement it in an older cluster.

[morgo]

We just merged the k8s topo 3 days ago. We are looking for testers, but @carsonoid mentioned on the Vitess monthly call yesterday he would like to make one more change (compress values before storing in k8s).

Personally, I would recommend trying an older cluster. If you are deploying in production on AWS/GCP/Azure etc. they are still using the older versions too.

[ErikTMA]

That was a fast response :o

I am using digitalocean currently, but not sure if I am going to stick with it in the long haul.

Thanks, I will setup a 1.15 cluster (assuming it works on that)

[carsonoid]

Do you have any ETA on this? I am looking into implementing Vitess for the first time, but I am unsure if I should wait for the fix for Helm3+Kubernetes 1.16 or implement it in an older cluster.

@ErikTMA like @morgo said: I have one small but breaking change I want to make to the k8s topo implementation. But once that's in we plan on moving all the helm examples to use k8s as the default topo which should allow you to use newer clusters and get rid of our dependency on the etcd-operator.

[yiliaofan]

Do you have any ETA on this? I am looking into implementing Vitess for the first time, but I am unsure if I should wait for the fix for Helm3+Kubernetes 1.16 or implement it in an older cluster.

@ErikTMA like @morgo said: I have one small but breaking change I want to make to the k8s topo implementation. But once that's in we plan on moving all the helm examples to use k8s as the default topo which should allow you to use newer clusters and get rid of our dependency on the etcd-operator.

I encountered the same problem above. Thank you for your great work ~
You try to put aside etcd-operator, can you test ok with the latest version of k8s? thank you very much!

[sougou]

I just tested against 1.18, and it works fine. And #6052 is out showing the new way to reshard.