dapr
app-port documentation does not describe the usage of the -1 value and where it's used
What content needs to be created or modified?
In the documentation for the --app-port parameter (aka APP_PORT environment variable), there is no documentation of how the value "-1" is handled, nor is there any indication of disparity in functionality between use in local DAPR vs use in Kubernetes annotations.
Describe the solution you'd like
I need a clear and concise description of how the -1 parameter value is used, and whether it's even supported for use with Kubernetes injected sidecars. The Publish and Subscribe quickstart documentation suggests that omitting the explicit value of -1 uses a default value, being -1, to indicate that 2-way communication between the publishing checkout component and its sidecar is not required. I've verified this behavior first hand in a separate application using local DAPR for testing and development. However, when deploying this same application to Kubernetes, I see different behavior: the side car fails to load, and upon inspecting the args passed to daprd, I see that my explicitly specified dapr.io/app-port value of -1 is replaced with an empty string that breaks the invocation of daprd.
Where should the new material be placed?
Material should be placed in the relevant sections for app-port in the following documents:
The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos
As I've been unable to ascertain the specified behavior for the app-port regarding disparity between local usage and Kubernetes usage, I'm unable to provide a PR at this time.
Additional context
Example description of failed Kubernetes pod when app-port is set to -1:
Name: myclient-75b5ddbf74-btjjb
Namespace: cesimdc
Priority: 0
Node: shfcapphost1-vm/10.0.0.7
Start Time: Sun, 29 May 2022 00:36:04 -0600
Labels: app=myclient
app.kubernetes.io/instance=myclient
app.kubernetes.io/name=myclient
pod-template-hash=75b5ddbf74
Annotations: dapr.io/app-id: myclient
dapr.io/app-port: -1
dapr.io/config: myclientappconfig
dapr.io/enabled: true
Status: Running
IP: 10.0.0.7
IPs:
IP: 10.0.0.7
Controlled By: ReplicaSet/myclient-75b5ddbf74
Containers:
myclient:
Container ID: containerd://7204ae6ce7400e51795c72b27da420d6793a425eed19fb0719ab5a873b9eb5a7
Image: ****redacted****/****redacted****:0.3.2117-prerelease
Image ID: docker.io/****redacted****/****redacted****@sha256:dc2a9df3c554eb0ffe9ed4b36c5e8312a260b9b0c38ff6285266642fe042c9d0
Ports: 4411/UDP, 9000/UDP
Host Ports: 4411/UDP, 9000/UDP
State: Running
Started: Sun, 29 May 2022 00:36:05 -0600
Ready: True
Restart Count: 0
Environment:
DAPR_HTTP_PORT: 3500
****redacted****
DAPR_GRPC_PORT: 50001
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-v45nh (ro)
daprd:
Container ID: containerd://b43cde5b68104828a1c3a1b778aef518b1853aff989922c2cf31e01568638541
Image: docker.io/daprio/daprd:1.6.0
Image ID: docker.io/daprio/daprd@sha256:db7ce4723d61566a2e6be24bd7d136e317023cf11ee78b9c6f55c00ec0c6223f
Ports: 3500/TCP, 50001/TCP, 50002/TCP, 9090/TCP
Host Ports: 3500/TCP, 50001/TCP, 50002/TCP, 9090/TCP
Command:
/daprd
Args:
--mode
kubernetes
--dapr-http-port
3500
--dapr-grpc-port
50001
--dapr-internal-grpc-port
50002
--dapr-listen-addresses
[::1],127.0.0.1
--dapr-public-port
3501
--app-port ### NOTE: Whitespace below, where -1 is expected. This breaks the argument generation.
--app-id
myclient
--control-plane-address
dapr-api.default.svc.cluster.local:80
--app-protocol
http
--placement-host-address
dapr-placement-server.default.svc.cluster.local:50005
--config
myclientappconfig
--log-level
info
--app-max-concurrency
-1
--sentry-address
dapr-sentry.default.svc.cluster.local:80
--enable-metrics=true
--metrics-port
9090
--dapr-http-max-request-size
-1
--dapr-http-read-buffer-size
-1
--dapr-graceful-shutdown-seconds
-1
--enable-mtls
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: Sun, 29 May 2022 00:39:13 -0600
Finished: Sun, 29 May 2022 00:39:18 -0600
Ready: False
Restart Count: 5
Liveness: http-get http://:3501/v1.0/healthz delay=3s timeout=3s period=6s #success=1 #failure=3
Readiness: http-get http://:3501/v1.0/healthz delay=3s timeout=3s period=6s #success=1 #failure=3
Environment:
NAMESPACE: cesimdc
DAPR_TRUST_ANCHORS: -----BEGIN CERTIFICATE-----
****redacted****
-----END CERTIFICATE-----
DAPR_CERT_CHAIN: -----BEGIN CERTIFICATE-----
****redacted****
-----END CERTIFICATE-----
DAPR_CERT_KEY: -----BEGIN EC PRIVATE KEY-----
****redacted****
-----END EC PRIVATE KEY-----
SENTRY_LOCAL_IDENTITY: cesimdc:default
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-v45nh (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
kube-api-access-v45nh:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 4m46s (x3 over 5m16s) kubelet Liveness probe failed: Get "http://10.0.0.7:3501/v1.0/healthz": dial tcp 10.0.0.7:3501: connect: connection refused
Warning Unhealthy 4m46s (x4 over 5m16s) kubelet Readiness probe failed: Get "http://10.0.0.7:3501/v1.0/healthz": dial tcp 10.0.0.7:3501: connect: connection refused
Normal Killing 4m46s kubelet Container daprd failed liveness probe, will be restarted
Normal Pulled 4m45s (x4 over 5m21s) kubelet Container image "docker.io/daprio/daprd:1.6.0" already present on machine
Normal Created 4m45s (x4 over 5m21s) kubelet Created container daprd
Normal Started 4m45s (x4 over 5m21s) kubelet Started container daprd
Warning BackOff 11s (x26 over 5m9s) kubelet Back-off restarting failed container
To clarify my original submission, -1 is identified as the default value with C:\dapr\dapr.exe run --help.
I think there is some confusion. If you want to use the default values in Kubernetes you must omit the flags. You cannot use -1 here. Note that there is no default for app port - by omitting the flag you disable that feature.
You either have to explicitly set the app port (if you expect Dapr to talk to your app), or omit the flag.
The CLI might use -1 has a way to automatically allocate a random free port (unclear), but this is not supported in Kubernetes (and cannot be supported there).
Hi @berndverst . The underlying issue at the time was that I had wanted to be able to run applications in my Kubernetes cluster that aren't servers and don't require the DAPR side car to communicate with the application, but I did want the application to be able to communicate with the DAPR side car. It sounds like to achieve this, I need to override the invocation command for the DAPR sidecar somehow ?
@alexmarshall132 if your applications aren't servers (because you don't use input bindings, don't receive pubsub events, don't expect these to be invoked via service invocation) you will still need a sidecar - but the sidecar must not be configured to listen to an app port.
All you have to do is remove / omit the dapr.io/app-port and dapr.io/app-protocol annotations.
This way the Dapr sidecar gets injected, but it won't fail to start because your app isn't exposing a server.
Your app can then still call the Dapr sidecar via the default Dapr gRPC and HTTP ports (50001 and 3500 respectively).
So do not include dapr.io/app-port and set it to -1, just complete remove this annotation and everything will work.
