I'm deploying a DAPR-based microservice application to a Kubernetes cluster with DAPR v1.6.0 installed in the default namespace of a Kubernetes cluster. Using a configuration I've gotten to work with numerous other DAPR-based microservices, I'm getting an error when I deploy my myclient to the cluster. I've verified that the myclient container starts correctly in the pod on the app-port that DAPR is expecting. The DAPR sidecar gets injected, but the daprd service fails to start. When I check the logs for the DAPR sidecar, I get the following output:
time="2022-06-03T19:49:00.199303145Z" level=info msg="starting Dapr Runtime -- version 1.6.0 -- commit 4bb25fab444c4f1a1bf0ffd74293dbd4fdcea580" app_id=myclient instance=shfcapphost1-vm scope=dapr.runtime type=log ver=1.6.0
time="2022-06-03T19:49:00.199336045Z" level=info msg="log level set to: info" app_id=myclient instance=shfcapphost1-vm scope=dapr.runtime type=log ver=1.6.0
time="2022-06-03T19:49:00.199430147Z" level=info msg="metrics server started on :9090/" app_id=myclient instance=shfcapphost1-vm scope=dapr.metrics type=log ver=1.6.0
time="2022-06-03T19:49:05.252077029Z" level=fatal msg="error loading configuration: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp: lookup dapr-api.default.svc.cluster.local on 127.0.0.53:53: server misbehaving\"" app_id=myclient instance=shfcapphost1-vm scope=dapr.runtime type=log ver=1.6.0
I've verified that the dapr-api service at dapr-api.default.svc.cluster.local is in fact up and running, as it's used by several other services. My deployment pod annotations look like the following:
spec:
replicas: 1
selector:
matchLabels:
app: myclient
app.kubernetes.io/name: myclient
app.kubernetes.io/instance: **redacted**
template:
metadata:
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "myclient"
dapr.io/app-port: "<redacted>"
dapr.io/config: "myclientappconfig"
Although myclient is shown here, I've verified that the real name is well less than the 63 charactor maximum, even including an appconfig suffix. I've verified that the configuration object does in fact exist and is valid in the cluster. I've verified the configuration of my code running DAPR locally on my development machine. I've exhausted all the avenues I can think of to determine why the DAPR sidecar container would be failing to start. Can anybody provide any insight into this type of error produced by daprd in the DAPR sidecar container in the Kubernetes pod ?
