After upgrading the Kubernetes version, I get the error:
Error: failed decoding rader into objects: unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta2"
After I did some research in StackOverflow and more similar issues on the net I found two ways to overcome:
Downgrade Kubernetes version - this solution is out of the question for now.
adding the following line to --runtime-config=apps/v1beta1=true,apps/v1beta2=true,extensions/v1beta1/daemonsets=true,extensions/v1beta1/deployments=true,extensions/v1beta1/replicasets=true,extensions/v1beta1/networkpolicies=true,extensions/v1beta1/podsecuritypolicies=true to /etc/kubernetes/manifest/kube-apiserver.yaml file.
I understood that this file located inside the docker image of the api-server itself, so I looked for this specific image but I found 3 images named
kube-apiserver-ip-xx.xx.xx.xxx.eu-west-1.compute.internal and the file kube-apiserver.yaml missing for all 3 of them.
So I continued with my research and find out that the file actually located inside the master and not in the pods.
In addition to the above, the build process is also using tiller which I cannot know if it's related to this issue and maybe even required some additional adaptions on the tiller config. I read in some posts that I need to change the master node but I don't understand how can I find this specific node using kubectl. So in summary I have two questions:
1.whether the tiller may effect the process of my desired solution?
2.where can I find the master node of the api-server and how can i get the access to it (i.e. which kubectl commands etc.).
I still a beginner with Kubernetes, helm and tiller so apologies for my ignorance. gratitude
David and Taybur are right but I would like to share some useful tips regarding this topic. As I mentioned earlier in the comments in order to minimize the probability of errors while changing the apiVersion of your files you can use the kubectl convert command:
Convert config files between different API versions. Both YAML and JSON formats are accepted.
The command takes filename, directory, or URL as input, and convert it into format of version specified by --output-version flag. If target version is not specified or not supported, convert to latest version.
Also, the below command will list all the resource types with their latest supported API versions:
for kind in `kubectl api-resources | tail +2 | awk '{ print $1 }'`; do kubectl explain $kind; done | grep -e "KIND:" -e "VERSION:"And you can always check the API reference if needed.
As you know API version might be different or updated based on the k8s cluster version. So far i have understood, you have a helm chart which was deployed earlier and after upgrading the k8s cluster, you are getting this API version mismatch while redeploying it. you have not mentioned the k8s version you're running now after upgrading. So to solve this issue, you have to find out the exact api version for statefulset.Which can be done by using the below command.
kubectl api-resources |grep statefulsetsYou will get output with columns and one of them are APIGROUP which will be apps.
Now try to get the api-versions from the below command.
kubectl api-versions |grep appsyou will get the exact version which can be further verify using below command.
kubectl explain statefulsetsthe output will have the VERSION field which is the supported api version for statefulsets.
Now edit your helm chart's deployment.yml file and change apiVersion with the new api version that you got from the command and redeploy.
Kubernetes 1.16 removed the "beta" versions of several resources in favor of stable versions. Kubernetes only supports the three most recent releases, and as I'm writing this 1.19 is the current version, so no current supported version of Kubernetes (1.17, 1.18, or 1.19) supports apiVersion: apps/v1beta2 at all.
You need to find the specific StatefulSet declaration in your Helm chart and change its version to apiVersion: apps/v1. This may work without further changes; if not, you'll probably get a validation error when you try to install the release. You will likely hit similar issues with Deployments.
This is not related to the (Helm v2) Tiller process, and you should not try to work around this by making changes to the cluster configuration. I've found Helm v2 to be a little finicky around some kinds of changes and you may need to helm del --purge your existing installation before attempting a redeploy.