Catalog controller pod crashes with panic error
What happened:
Tried to create service instances and servicebindings which runs into pod crash, eventually after 5 to 6 restarts everything works fine.
NAME READY STATUS RESTARTS AGE
catalog-catalog-controller-manager-95cc6fdc8-p6lt5 1/1 Running 6 10h
we see the pod restart happens around 6 times as above.
This works fine with 0.3.0-beta.2 version of catalog.
What you expected to happen:
Should be a clean run for provisioning. But we see the below error.
I0624 16:40:57.966721 1 controller_instance.go:3008] ServiceBinding testproject-1/testproject-1 triggered to reconciliation
E0624 16:40:57.966838 1 runtime.go:78] Observed a panic: "assignment to entry in nil map" (assignment to entry in nil map)
goroutine 275 [running]:
k8s.io/apimachinery/pkg/util/runtime.logPanic(0x197e3c0, 0x1e81a40)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/runtime/runtime.go:74 +0xa3
k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0x0, 0x0, 0x0)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/runtime/runtime.go:48 +0x82
panic(0x197e3c0, 0x1e81a40)
/usr/local/go/src/runtime/panic.go:679 +0x1b2
github.com/kubernetes-sigs/service-catalog/pkg/controller.(*controller).triggerServiceBindingReconciliation(0xc000508900, 0xc000ef6900)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller_instance.go:3010 +0x21e
github.com/kubernetes-sigs/service-catalog/pkg/controller.(*controller).processProvisionSuccess(0xc000508900, 0xc000ef6900, 0x0, 0x0, 0x0)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller_instance.go:2708 +0x1bd
github.com/kubernetes-sigs/service-catalog/pkg/controller.(*controller).reconcileServiceInstanceAdd(0xc000508900, 0xc000ef6000, 0x40a000, 0x0)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller_instance.go:668 +0xa91
github.com/kubernetes-sigs/service-catalog/pkg/controller.(*controller).reconcileServiceInstance(0xc000508900, 0xc000ef6000, 0x0, 0x0)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller_instance.go:336 +0x347
github.com/kubernetes-sigs/service-catalog/pkg/controller.(*controller).reconcileServiceInstanceKey(0xc000508900, 0xc000f14f00, 0x21, 0xc000f1e530, 0x0)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller_instance.go:306 +0x2f4
github.com/kubernetes-sigs/service-catalog/pkg/controller.worker.func1.1(0x1f142a0, 0xc000596fc0, 0xc0009ba4c0, 0x1, 0xf, 0x1be83a6, 0xf, 0x1000772500)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller.go:394 +0xff
github.com/kubernetes-sigs/service-catalog/pkg/controller.worker.func1()
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller.go:412 +0x8a
k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0xc00097ef40)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:155 +0x5e
k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0xc00097ef40, 0x1e9e3c0, 0xc000950ea0, 0xc0000f4001, 0x0)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:156 +0xa3
k8s.io/apimachinery/pkg/util/wait.JitterUntil(0xc00097ef40, 0x3b9aca00, 0x0, 0x1, 0x0)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:133 +0xe2
k8s.io/apimachinery/pkg/util/wait.Until(...)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:90
github.com/kubernetes-sigs/service-catalog/pkg/controller.createWorker.func1(0x1f142a0, 0xc000596fc0, 0x1be83a6, 0xf, 0xf, 0x1, 0xc0009ba4c0, 0x0, 0xc00046ce60)
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller.go:310 +0x9f
created by github.com/kubernetes-sigs/service-catalog/pkg/controller.createWorker
/go/src/github.com/kubernetes-sigs/service-catalog/pkg/controller/controller.go:309 +0xbe
panic: assignment to entry in nil map [recovered]
panic: assignment to entry in nil map
goroutine 275 [running]:
k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0x0, 0x0, 0x0)
/go/pkg/mod/k8s.io/[email protected]/pkg/util/runtime/runtime.go:55 +0x105
panic(0x197e3c0, 0x1e81a40)
How to reproduce it (as minimally and precisely as possible):
Kubernetes version: v1.15, v1.18
catalog : 0.3.0
Note: This did not occur in 0.3.0-beta.2 version
Install service catalog with helm and try to create serviceinstance/ bindings
Anything else we need to know?:
Environment:
kubectl version): 1.15 to 1.18kubectl get cm -n kube-system extension-apiserver-authentication -o yaml and look for requestheader-XXX fields--set any extra values?Can I please know if there is any update on the above issue?
Bumping this issue. We're not able to make sense of the panic stack.
The panic error caused above is because of the assignment into the map after doing deep copy, this may be because of the line added here https://github.com/kubernetes-sigs/service-catalog/blob/v0.3.0/pkg/controller/controller_instance.go#L3010 , which assumes there is a map, where key can be inserted.
If the serviceinstanes, servicebinding don't have the annotation we run into the problem, Not sure if this is bug by the service catalog 0.3.0. But adding some dummy annotations helped fix the problem.
The panic error caused above is because of the assignment into the map after doing deep copy, this may be because of the line added here https://github.com/kubernetes-sigs/service-catalog/blob/v0.3.0/pkg/controller/controller_instance.go#L3010 , which assumes there is a map, where key can be inserted.
If the serviceinstanes, servicebinding don't have the annotation we run into the problem, Not sure if this is bug by the service catalog 0.3.0. But adding some dummy annotations helped fix the problem.
I've try this, problem solved!!! thanks.
Hi, I've got the same issue. Is it possible to add a test to check whether the annotation field is empty or not ?