error: unable to recognize "mongo-statefulset.yaml": no matches for kind "StatefulSet" in version "apps/v1beta1"

user_9931754 0
Viewed 2625

https://codelabs.developers.google.com/codelabs/cloud-mongodb-statefulset/index.html?index=..%2F..index#5

error: unable to recognize "mongo-statefulset.yaml": no matches for kind "StatefulSet" in version "apps/v1beta1"

The following command causes the above response in google cloud shell:

kubectl apply -f mongo-statefulset.yaml

I am working on deploying the stateful set MongoDB sidecar and following the instructions to a t in this demo but I received the following error. Does anyone have an explanation for the error? Or know a way to deploy stateful set mongo db in gke?

mongo-statefulset.yaml

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
 name: mongo
spec:
 serviceName: "mongo"
 replicas: 3
 template:
   metadata:
     labels:
       role: mongo
       environment: test
   spec:
     terminationGracePeriodSeconds: 10
     containers:
       - name: mongo
         image: mongo
         command:
           - mongod
           - "--replSet"
           - rs0
           - "--smallfiles"
           - "--noprealloc"
         ports:
           - containerPort: 27017
         volumeMounts:
           - name: mongo-persistent-storage
             mountPath: /data/db
       - name: mongo-sidecar
         image: cvallance/mongo-k8s-sidecar
         env:
           - name: MONGO_SIDECAR_POD_LABELS
             value: "role=mongo,environment=test"
 volumeClaimTemplates:
 - metadata:
     name: mongo-persistent-storage
     annotations:
       volume.beta.kubernetes.io/storage-class: "fast"
   spec:
     accessModes: [ "ReadWriteOnce" ]
     resources:
       requests:
         storage: 100Gi

Changing the yaml file with v1 in apiVersion returns a similar error:

error: unable to recognize "mongo-statefulset.yaml": no matches for kind "StatefulSet" in version "v1"
google-kubernetes-engine mongodb
2 Answers

Explanation:

apiVersion of particular kubernetes resource is subject to change in time. The fact that once StatefulSet used apiVersion: apps/v1beta1 doesn't mean that it will use it forever.

As dany L already suggested in his answer, apps/v1beta1 most probably has already been deprecated in the version of kubernetes you're using. The mentioned changes in supported api versions were introduced quite a long time ago (date of publication of the article is Thursday, July 18, 2019) so chances are that you're using a version newer than 1.15.

I'd like to put it also in the body of the answer to make it clearly visible without a need to additionally searching through the docs. So what actually happen when 1.16 was released was (among other major changes):

StatefulSet in the apps/v1beta1 and apps/v1beta2 API versions is no longer served

  • Migrate to use the apps/v1 API version, available since v1.9. Existing persisted data can be retrieved/updated via the new version.

Solution:

Workaround, create your cluster with 1.15 version and it should work.

As to the above workaround I agree that this is a workaround and of course it will work but this is not a recommended approach. New kubernetes versions are developed and released for some reason. Apart from changes in APIs, many other important things are introduced, bugs are fixed, existing funcionalities are improved as well as new ones are added. So there is no point in using something that soon will be deprecated anyway.

Instead of that you should use the currently supported/required apiVersion for the particular kubernetes resource, in your case StatefulSet.

The easiest way to check what apiVersion supports StatefulSet in your kubernetes installation is by running:

kubectl explain statefulset

which will tell you (among many other interesting things) which apiVersion it is supposed to use:

KIND:     StatefulSet
VERSION:  apps/v1
...

To summarize your particular case:

If you're using kubernetes newer than 1.15, edit your mongo-statefulset.yaml and replace apiVersion: apps/v1beta1 with currently supported apiVersion: apps/v1.

user_117141140

Possible explanation.

Workaround, create your cluster with 1.15 version and it should work.

user_92537780
Related