0

Currently, we run kops based cluster of the version 15. We are planning to upgrade it to the version 16 first and then further. However, api versions for various kubernetes services in yaml's will also need to change. How would you address this issue before the cluster upgrade? Is there any way to enumerate all objects in the cluster with incompatible api versions or what would be the best approach for it? I suspect the objects created by kops, e.g. kube-system objects will be upgraded automatically.

Viji
  • 412
  • 4
  • 15
  • Hello, have you checked this blog post by any chance? https://www.tauceti.blog/post/kubernetes-upgrade-nodes-1.15-1.16/ – Dawid Kruk Dec 15 '20 at 12:13

1 Answers1

0

When you upgrade the cluster, the API server will take care to upgrade all existing resources in the cluster. The problem arise when you want to deploy more resources and after the upgrade these are still using the old API versions. In this case your deployment (say kubectl apply) will fail.

I.e nothing already running in the cluster will break. But future deployments will if they still use old versions.

The resources managed by kOps already use new API versions.

Ole Markus With
  • 1,017
  • 1
  • 8
  • 10
  • Ole, thanks for your answer, but I needed to know how I can enumerate all resources that were deployed with apis that will be obsolete in the next version, e.g. see current api versions for all deployed objects and compare them with the api version that will be used in the next kube version (after upgrade). I.e. I want to update my yaml files before the kubernetes upgrade to avoid such problems when running kubectl create -f anydeployment.yaml – Viji Jan 12 '21 at 12:56
  • Sorry for being unclear. The versions you talk about is for the API only. Once deployed to the cluster it doesn't exist as a fixed API version anymore. Just as a resource object. You can request an existing resource as any supported versoin. e.g you can do both `kubectl get hpa.v2beta2.autoscaling -o yaml` and `kubectl get hpa.v1.autoscaling -o yaml` and the response will be on the specified API version. I.e you cannot use anything server-side verify your yaml files. The good news is that as of 1.19, the API server will warn if you try to create/apply deprecated resource versions. – Ole Markus With Jan 13 '21 at 12:04
  • In that case, before the cluster (kubernetes) upgrade, you need to update yaml files to api versions, which are supported both the current cluster version and the next cluster (kubernetes) version. As far as I can see I need to manually dig across documentation for a particular kubernetes version and update yaml files on this basis. – Viji Jan 15 '21 at 17:44