I used to define my custom resources using apiserver-builder, which is currently deprecated and recommended to use kubebuilder instead.
I tried to generate my resources using kubebuilder, but i found sigs.k8s.io/controller-runtime version in Gopkg.toml is v0.1.1, which is based on k8s 1.10.1 .
Then i searched in controller-runtime repository, the latest version is v0.1.7, which is based on k8s 1.11.2 .
I am wondering when could kubebuilder/controller-runtime update to k8s 1.12.x? Or if kubebuilder still maintained?
Yes, the kubernetes-sigs/controller-runtime is still actively being developed on and is maintained.
I am wondering when could kubebuilder/controller-runtime update to k8s 1.12.x?
The best way to ask the maintainers to make this happen would be to ask on the #kubebuilder channel on the Kubernetes Slack, or create an issue on the repo.
Related
I didn't notice my GKE cluster is in Rapid channel. Until today I want to add Node Pool.
It shows Node version "1.17.5-gke.6" is unsupported.
https://cloud.google.com/kubernetes-engine/docs/release-notes-rapid#may_27_2020
My questions are:
How to downgrade GKE master version
How to update a GKE cluster don't use rapid channel
I can't find anything about that in gcloud cli, official documents and stackoverflow.
When you create a cluster you have two options to choose from
A. Release channel [Rapid/Regular/Stable]
B. Static version
1.How to downgrade GKE master version.
From documentation, it mentions that if you are in release channel [Rapid/Regular/Stable], downgrading is not possible.
With static version it is possible to downgrade with the following limitations.
2.How to update a GKE cluster to not use rapid channel.
This is not possible and it will give the following error
Migrating off of releaseChannel RAPID is not supported.
More information can be also found here in regards to the migration between different release channels.
I have production stage hosted in Google Kubernetes Engine with Kubernetes version 1.12.9-gke.15.
My team is planning to upgrade it to Kubernetes version 1.13.11-gke.5.
A capture of list of Kubernetes version
I have read some articles to upgrade Kubernetes. However, they use kubeadm not GKE.
How to update api versions list in Kubernetes here's a example that use GKE.
If you guys have experience in upgrading kubernetes cluster in GKE or even kubeadm. Please share what should i do before upgrading the version ?
Should i upgrade the version to 1.13.7-gke.24 and then to 1.13.9-gke.3 and so on ?
You first should check if you are not using any depreciated features. For example check the Changelogs for version 1.12 and 1.13 to make sure you won't loose any functionality after the upgrade.
You will have to remember that if you have just one master node you will loose access to if for few minutes while control plane is being updated. After master node is set then worker nodes will follow.
There is a great post about Kubernetes best practices: upgrading your clusters with zero downtime, which talks about location for nodes and a beta option being Regional
When creating your cluster, be sure to select the “regional” option:
And that’s it! Kubernetes Engine automatically creates your nodes and masters in three zones, with the masters behind a load-balanced IP address, so the Kubernetes API will continue to work during an upgrade.
And they explain how does Rolling update works and how to do them.
Also you might consider familiarizing yourself with documentation for Cluster upgrades, as it discusses how automatic and manual upgrades work on GKE.
As you can see from your current version 1.12.9-gke.15 you cannot upgrade to 1.14.6-gke.1. You will need to upgrade to 1.13.11-gke.5 and once this is done you will be able to upgrade to latest GKE version.
GCP Kubernetes is upgraded manually and generally does not require you to do much. But if you are you looking for manual upgrade options maybe this will help.
https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster
A point worth mentioning is too, make sure you have persistence volumes for services that require to do so viz. like DB, etc And for these, you will have to back them up manually.
When the storage version of a Kubernetes API resource changes, is it still necessary to manually read and write back resources as describe here or does the apiserver now deal with this automatically?
For example, if I wanted to remove the deprecated extensions/v1beta1 version of deployments from my cluster and migrate to apps/v1 would it be enough to specify --storage-versions=extensions=apps/v1 on the apiserver and then ‘wait for a bit’ before setting something like ---runtime-config=api/all=true,extensions/v1beta1/deployments=false? Or would I have to use the update-storage-objects.sh script after setting --storage-versions=extensions=apps/v1?
Additionally, would specifying --storage-versions=extensions=apps/v1 cause any issues for ingress resources that still use API version extensions/v1beta1 but have no conversion to apps/v1?
does the apiserver now deal with this automatically?
No, the api-server does not do it automatically, you need to do it manually.
Regarding the upgrade between API versions, all necessary steps are described in the official documentation:
This is an infrequent event, but it requires careful management. There
is a sequence of steps to upgrade to a new API version.
Turn on the new API version.
Upgrade the cluster’s storage to use the new version.
Upgrade all config files. Identify users of the old API version endpoints.
Update existing objects in the storage to new version by running cluster/update-storage-objects.sh.
Turn off the old API version.
Step 4 is not only about storage but also about all resources related to the old version which you have in the cluster.
Additionally, would specifying --storage-versions=extensions=apps/v1 cause any issues for ingress resources that still use API version extensions/v1beta1 but have no conversion to apps/v1?
Versioning of each type of resource is independent. Storage and Ingress are different resources so there are no relations between their versions and different versions should not affect them in any way.
The recommended method for doing this is still in flux. Removing API versions is currently prohibited: https://github.com/kubernetes/kubernetes/issues/52185
Im usually upgrading the cluster with a new API version then upgrade the config files but not removing the old API. Only once I had to remove a old API version due to a bug. You can do this by running kubectl get apiservice to list all available versions then kubectl delete apiservice some_api and you don't have to set any other flag.
I'm a bit confused about what version of kubernetes I need and what method to use to deploy it.
I have deployed 1.5 the manual way. But there is a fix we need (PR-41597). This fix doesn't seem to have been merge in 1.5 but it is in 1.6.
But I can't find any way to install 1.6 without kubeadm. The documentation clearly states that kubeadm should not be used in production. And the kubeadm way does not allow for upgrades anyway. So I would prefer to stay away from kubeadm.
So I either have to get that fix merged in 1.5 or find a way to install 1.6 without kubeadm. Am I missing something here? Any help would be much appreciated. Thanks.
There are plenty of ways to install Kubernetes 1.6:
https://kubernetes.io/docs/getting-started-guides
For example, CoreOS's CloudFormation installer supports 1.6: https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html#announcement-to-regular-users-of-kube-aws
As does Canonical's Juju templates: https://jujucharms.com/canonical-kubernetes/
If you need more specific assistance, please share more about your target environment (cloud/bare metal, OS, etc.).
A fairly low-level set of instructions can be found in https://github.com/kelseyhightower/kubernetes-the-hard-way; this may help you to tailor your own setup process.
For CentOS specifically, your best bet might be Kargo. This doesn't yet support 1.6, but it is active, so it should receive a 1.6 patch soon.
I began to try Google Container Engine recently. I would you like to upgrade the Kubernetes Cluster to the latest version available, if possible without downtime. Is there any way to do this?
Unfortunately, the best answer we currently have is to create a new cluster and move your resources over, then delete the old one.
We are very actively working on making cluster upgrades reliable (both nodes and the master), but upgrades are unlikely to work for the majority of currently existing clusters.
We now have a checked-in upgrade tool for master and nodes: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/cluster/gce/upgrade.sh