I follow the document with The Kubebuilder Book create a sample project.
and when i try running the controller by command make run, follow this step, but I meat an error here.
ERROR controllers.CronJob unable to update CronJob status {"controller": "cronjob-application", "request": "default/cronjob-sample", "error": "the server could not find the requested resource (put cronjobs.batch.sun.kubebuilder.io cronjob-sample)"}
environment:
Kubelet Version: v1.14.2
Kube-Proxy Version: v1.14.2
how can I resolve this problem?
thanks.
/kind bug
/triage support
did you miss the // +kubebuilder:subresource:status on the API object?
I hit the same problem. the domain i use is "mycrontab"
error is
2019-06-04T11:33:41.514+1000 ERROR controllers.CronJob unable to update CronJob status {"cronjob": "default/cronjob-sample", "error": "the server could not find the requested resource (put cronjobs.batch.mycrontab cronjob-sample)"}
crd was created successfully
$ k get crd
NAME CREATED AT
cronjobs.batch.mycrontab 2019-06-04T01:30:20Z
Here are comments from kuberbuilder
// +kubebuilder:rbac:groups=batch.mycrontab,resources=cronjobs,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=batch.mycrontab,resources=cronjobs/status,verbs=get;update;patch
// +kubebuilder:rbac:groups=batch,resources=jobs,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=batch,resources=jobs/status,verbs=get
After i check cronjob_types.go , add below, issue is fixed
// +kubebuilder:subresource:status
type CronJob struct {
I believe the book was updated too. https://book.kubebuilder.io/cronjob-tutorial/api-design.html
thank you, this issue is fixed. but why my crontroller always log here, don't continue. And will not create any job.
E0605 09:40:45.572289 12509 client_go_adapter.go:318] descriptor Desc{fqName: "cronjob-application_depth", help: "Current depth of workqueue: cronjob-application", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_depth" is not a valid metric name
E0605 09:40:45.573483 12509 client_go_adapter.go:328] descriptor Desc{fqName: "cronjob-application_adds", help: "Total number of adds handled by workqueue: cronjob-application", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_adds" is not a valid metric name
E0605 09:40:45.574926 12509 client_go_adapter.go:339] descriptor Desc{fqName: "cronjob-application_queue_latency", help: "How long an item stays in workqueuecronjob-application before being requested.", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_queue_latency" is not a valid metric name
E0605 09:40:45.576317 12509 client_go_adapter.go:350] descriptor Desc{fqName: "cronjob-application_work_duration", help: "How long processing an item from workqueuecronjob-application takes.", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_work_duration" is not a valid metric name
E0605 09:40:45.577485 12509 client_go_adapter.go:363] descriptor Desc{fqName: "cronjob-application_unfinished_work_seconds", help: "How many seconds of work cronjob-application has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_unfinished_work_seconds" is not a valid metric name
E0605 09:40:45.578755 12509 client_go_adapter.go:374] descriptor Desc{fqName: "cronjob-application_longest_running_processor_microseconds", help: "How many microseconds has the longest running processor for cronjob-application been running.", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_longest_running_processor_microseconds" is not a valid metric name
E0605 09:40:45.580159 12509 client_go_adapter.go:384] descriptor Desc{fqName: "cronjob-application_retries", help: "Total number of retries handled by workqueue: cronjob-application", constLabels: {}, variableLabels: []} is invalid: "cronjob-application_retries" is not a valid metric name
2019-06-05T09:40:45.581+0800 INFO controller-runtime.controller Starting EventSource {"controller": "cronjob-application", "source": "kind source: /, Kind="}
2019-06-05T09:40:45.581+0800 INFO controller-runtime.controller Starting EventSource {"controller": "cronjob-application", "source": "kind source: /, Kind="}
2019-06-05T09:40:45.581+0800 INFO setup starting manager
2019-06-05T09:40:45.687+0800 INFO controller-runtime.controller Starting Controller {"controller": "cronjob-application"}
2019-06-05T09:40:45.788+0800 INFO controller-runtime.controller Starting workers {"controller": "cronjob-application", "worker count": 1}
2019-06-05T09:40:54.414+0800 DEBUG controllers.CronJob job count {"cronjob": "default/cronjob-sample-1", "active jobs": 0, "successful jobs": 0, "failed jobs": 0}
2019-06-05T09:40:54.462+0800 DEBUG controllers.CronJob no upcoming scheduled times, sleeping until next {"cronjob": "default/cronjob-sample-1", "now": "2019-06-05T09:40:54.462+0800", "next run": "2019-06-05T09:41:00.000+0800"}
2019-06-05T09:40:54.462+0800 DEBUG controllers.CronJob job count {"cronjob": "default/cronjob-sample-1", "active jobs": 0, "successful jobs": 0, "failed jobs": 0}
2019-06-05T09:40:54.507+0800 DEBUG controllers.CronJob no upcoming scheduled times, sleeping until next {"cronjob": "default/cronjob-sample-1", "now": "2019-06-05T09:40:54.507+0800", "next run": "2019-06-05T09:41:00.000+0800"}
2019-06-05T09:41:00.001+0800 DEBUG controllers.CronJob job count {"cronjob": "default/cronjob-sample-1", "active jobs": 0, "successful jobs": 0, "failed jobs": 0}
@DirectXMan12
I saw the same error:
"error": "the server could not find the requested resource (put cronjobs.batch.sun.kubebuilder.io cronjob-sample)"}
Adding the // +kubebuilder:subresource:status comment above the CronJob struct in cronjob_types.go, and then running make manifests per https://book-v1.book.kubebuilder.io/basics/status_subresource.html resolved the error for me:
// +kubebuilder:subresource:status
type CronJob struct {
make manifests
status subresource in CRD after running make manifests:
spec:
...
subresources:
status: {}
...
The +kubebuilder:subresource:status is already in the book, so I think we're good there. As for the failure to create jobs, you'll probably need to wait the full minute to see jobs, since it's set to run every minute. I can succesfully reproduce job creation on my end by make run-ing the controller.
Going to close this for now, but I'm happy to re-open if you have further questions
The +kubebuilder:subresource:status is already in the book
Wouldn't it be useful to add to the auto-generated code? Or don't add Status field automatically?
Most helpful comment
/triage support
did you miss the
// +kubebuilder:subresource:statuson the API object?