How does Pulumi handle Kubernetes API deprecations these days, e.g.: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/ We have some

apiVersion: extensions/v1beta1

resources that we want to change to, e.g.

apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>

. My experience with Helm is that it kinda fucks up here, because for e.g.: a deployment named

foo

, we can't tell Helm "don't change anything with this resource, just update Tiller with what the new API version is because k8s allows us to access a deployment via both extensions/v1beta1 and apps/v1". The result is we have to rename everything to

foo-v1

, experiencing some downtime because Helm will tear down the old deployment, stand up the new deployment, and often other stuff is also infected with the name via Helm templating so the service, the ingress, etc all get replaced and/or destroyed and recreated as the new name. Is there a way to make Pulumi just... accept that these resources are now

<http://networking.k8s.io/v1|networking.k8s.io/v1>

or

apps/v1

? That is, no update/replace/etc needed.

Pulumi aliases compatible Kubernetes API versions so that you should be able to upgrade from older to newer api versions. Are you seeing this not happen correctly in some case?

Nope, was just curious before I attempted to make the change.

It looks like the list is here: https://github.com/pulumi/pulumi-kubernetes/blob/ed51f394f0ee06bce2079139f9e52ee0c8367d42/pkg/gen/typegen.go#L1206 I do suspect that list is not complete - if you see anything missing - please do open an issue. Also cc @gorgeous-egg-16927.

@white-balloon-205 @gorgeous-egg-16927: https://github.com/pulumi/pulumi-kubernetes/issues/919

Great - thanks!

Thanks for pulling that together. I did just fix a bug with the Ingress deprecation notice that hasn’t yet released, but you can test it out with the

dev

tag. https://github.com/pulumi/pulumi-kubernetes/pull/918 I’ll add entries for the other Kinds soon