I want to upgrade my cluster to use the newest version of Kubernetes. I see Google Container Engine has the following tool:
https://cloud.google.com/container-engine/docs/clusters/upgrade?hl=en
However, after I upgrade my cluster and everything finishes successfully, when I see my cluster on the web console I still see the old version (1.9.3). When you create a new cluster version is 1.0.1, so I expect my cluster to upgrade to that version. I also tried upgrading to 0.21.4 with the same results.
Is there something I'm doing wrong?
The web console may be reporting your initial cluster version rather than the current version of you master and nodes. If you want to see all of the versions for your cluster, try running
gcloud beta container clusters --zone=<zone> describe <cluster-name> | grep -i version
and it should print out something like
currentMasterVersion: 0.21.4
currentNodeVersion: 0.19.3
initialClusterVersion: 0.19.3
If your initial cluster version was 0.19.3 then your master won't have been upgraded to 1.0.x yet (but you should have received a notice that you will be upgraded soon).
Once your master has been upgraded, you can follow the instructions at the link you found to upgrade your nodes to the same version as your master.
Related
I am trying to setup a kubernetes cluster but apparently the nfs-client-provisioner has issues with the newer versions of kubernetes. Therefore I need to install the latest version of 1.19.
I am creating the kubernetes via kubeadm and I am using crio as the runtime. I am also running the whole thing on ubuntu 20.04. I know that I need to install version 1.19.7 of kubeadm, kubelet and kubectl but whatabout the cri-o?
As per official documentation from Kubernetes the CRI-O version needs to match your Kubernetes version.
https://v1-19.docs.kubernetes.io/docs/setup/production-environment/container-runtimes/#cri-o
So CRI-O 1.19 version should be compatible with the Kubernetes version you want to install.
I am using kOps to perform a manual cluster upgrade (from 1.17 to 1.18) as explained at https://kops.sigs.k8s.io/operations/updates_and_upgrades/#upgrading-kubernetes
I've noticed that kOps does not update the ami-image defined at spec.image at ig nodes, that means after cluster upgrade nodes are going to use the same base OS despite the kubernetes upgrade. But if you install 1.18 from scratch kOps uses the latest image available for that version.
should i update the version and configure it the same as the one kOps would use in case of an installation from scratch?
In 1.18 ami has moved from Debian to Ubuntu, should i take any precautions due to the change of operating system?
if you edit the manifests directly and do "kops update" etc ... then you need to also update the images, another alternative is to let kops do it for you by running "kops upgrade cluster " it will update the remote state and set the correct defaults etc ..
regarding the image change, i don't see any major issues there, what you can do is grab the current ami and do "sort of rollbacks" by replacing the image and updating the cluster ( or applying previous version of the manifest assuming you have s3 revisions on the state )
There was a bug up until kOps 1.18.2 where Ubuntu images were considered "custom" and therefore not upgraded by kops upgrade. See this bug
As of 1.18.2, you should see upgrades for Ubuntu as well.
There is no particular need to take any precaution when switching from Debian to Ubuntu unless you are using kOps hooks that would be Debian. kOps will take care of this change for you.
I know that you can start minikube with a different K8s version with --kubernetes-version.
But how can I let minikube list all versions which it supports?
I had a look at the command reference of start, but could not find a way up to now.
In my case I would like to know which one is the latest v1.17.X version which is supported.
On the github release page I found that v1.17.12 is today the latest version in the 17.x series. But it would be nice, if I minikube or kubectl could tell me this.
#Esteban Garcia is right but I would like to expand on this topic a bit more with the help of the official documentation:
By default, minikube installs the latest stable version of Kubernetes
that was available at the time of the minikube release. You may select
a different Kubernetes release by using the --kubernetes-version
flag, for example:
minikube start --kubernetes-version=v1.11.10
minikube follows the Kubernetes Version and Version Skew Support
Policy, so we guarantee support for the latest build for the last
3 minor Kubernetes releases. When practical, minikube aims to support
older releases as well so that users can emulate legacy environments.
For up to date information on supported versions, see
OldestKubernetesVersion and NewestKubernetesVersion in
constants.go.
The following command may be helpful:
minikube config defaults kubernetes-version
We have the version 1.12.10-gke.22 of kubernetes master, but we needed change to a 1.15.9-gke.24.
We running the command to clusters upgrade :
gcloud container clusters upgrade <cluster-name> --master --cluster-version 1.15.9-gke.24 --zone us-central1-c
And we receive the response:
Master cannot be upgraded to "1.15.9-gke.24": cannot upgrade the master more than a minor version at a time.
In Google Cloud Platform console, we have the message:
Any ideas or solutions? Thanks
Some of our customers experienced the same error. They cannot upgrade from 1.12.10-gke.22 because the 1.13 upgrade is not available.
The fix is in the works currently. Meanwhile to workaround the issue you can create a cluster with master version 1.15.9-gke.24 and migrate your workloads from the old cluster.
I am experimenting with the managed Azure Kubernetes service. I was able to start with the standard 1.8.3 version and then upgraded to 1.9.6. After the upgrade, I noticed that the Kubernetes dashboard still shows 1.8.3 as the version. Is the dashboard supposed to be automatically upgraded or do I have to upgrade it manually?
Never mind. I see that, as of today (4/20/2018), the most recent version of the Kubernetes dashboard is still 1.8.3 so it didn't need to be upgraded.