dapr/dapr

Kubernetes -darp service is created as Headless

andrey-dubnik opened this issue · 9 comments

In what area(s)?

/area runtime

What version of Dapr?

1.4.

Expected Behavior

Service should be created as a Cluster IP rather than Headless which would actually enable the load balancer on port 80->3500

Actual Behavior

curl -v -H 'dapr-app-id: echoserver' http://echoserver-dapr.default:3500/
HTTP-200

curl -v -H 'dapr-app-id: echoserver' http://echoserver-dapr.default:80/
curl: (56) Recv failure: Connection reset by peer

Steps to Reproduce the Problem

NAMESPACE=default
OPERATION=apply

cat <<EOF | kubectl ${OPERATION} -n ${NAMESPACE} -f -
---
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: echoserver-opa
spec:
  type: middleware.http.opa
  version: v1
  metadata:

    # causes segment violation
    # - name: defaultStatus
    #   value: 403

    - name: rego
      value: |
        package http
        default allow = {
            "allow": false,
            "status_code": 301,
            "additional_headers": {
                "Location": "https://my.redirect.site"
            }
        }
---
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: echoserver-config
spec:
  httpPipeline:
    handlers:
    - name: echoserver-opa
      type: middleware.http.opa
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: echoserver
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echoserver
  template:
    metadata:
      labels:
        app: echoserver
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "echoserver"
        dapr.io/config: "echoserver-config"
        # kuma.io/sidecar-injection: "disabled"
        dapr.io/app-port: "8080"
        dapr.io/log-level: "debug"
        dapr.io/sidecar-listen-addresses: "0.0.0.0"
    spec:
      containers:
      - image: gcr.io/google_containers/echoserver:1.10
        imagePullPolicy: Always
        name: echoserver
        ports:
        - containerPort: 8080
      serviceAccountName: echoserver
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: echoserver
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    dapr.io/app-id: echoserver
    prometheus.io/path: /
    prometheus.io/port: "9090"
    prometheus.io/scrape: "true"
  labels:
    dapr.io/enabled: "true"
  name: echoserver-dapr-cluster
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: Deployment
    name: echoserver
    uid: d133a353-9c0f-430d-a307-416f1ac168e2
spec:
  ports:
  - name: dapr-http
    port: 80
    protocol: TCP
    targetPort: 3500
  - name: dapr-grpc
    port: 50001
    protocol: TCP
    targetPort: 50001
  - name: dapr-internal
    port: 50002
    protocol: TCP
    targetPort: 50002
  - name: dapr-metrics
    port: 9090
    protocol: TCP
    targetPort: 9090
  selector:
    app: echoserver
  sessionAffinity: None
  type: ClusterIP
EOF

Calling the ClusterIP service results in Dapr success

curl -v -H 'dapr-app-id: echoserver' http://echoserver-dapr-cluster.default/
HTTP-200

Thanks for opening this - actually, the 80:3500 port (and also 50001:50001) is a relic of old. Dapr to Dapr communications occur over dapr-internal and these services should not be accessible by other cluster services. The service is headless in order to provide an endpoint slice response to gRPC DNS queries that Dapr dispatches when doing Service Invocation.

Thanks for the answer. What about he case where I like non dapr service to talk to dapr?

Then you can create your own service manually. wdyt?

This is what I did indeed - created the Cluster IP service manually and pointed it to 80->3500.

My use case is actually a bit wider as I'm trying to merge Dapr with the Kuma mesh. Due to the mesh not having L7 authorisation flavour and Darp having a good cloud service abstraction + middleware with L7 it makes a great fit.

If 3500 is going to stay as a HTTP port then I can stick to creating own service and assume this is going to be something to stay like that?

i also have this require, https://carlos.mendible.com/2020/04/05/kubernetes-nginx-ingress-controller-with-dapr/ can't work,i want to request dapr-service,but dapr-service is Headless and None ClusterIP

  • path: /backend-service-dapr(/|$)(.*)
    backend:
    serviceName: backend-service-dapr
    servicePort: 80

For that case I guess you need to do 2 things:

  1. enable the sidecar to listen to 0.0.0.0
annotations:
        ...
        dapr.io/sidecar-listen-addresses: "0.0.0.0"
  1. create a service with the cluster IP pointing 80 -> 3500 (change echoserver to whatever your app is)
apiVersion: v1
kind: Service
metadata:
  name: echoserver
spec:
  ports:
  - name: http
    port: 80
    targetPort: 3500
    protocol: TCP
  selector:
    app: echoserver

For that case I guess you need to do 2 things:

  1. enable the sidecar to listen to 0.0.0.0
annotations:
        ...
        dapr.io/sidecar-listen-addresses: "0.0.0.0"
  1. create a service with the cluster IP pointing 80 -> 3500 (change echoserver to whatever your app is)
apiVersion: v1
kind: Service
metadata:
  name: echoserver
spec:
  ports:
  - name: http
    port: 80
    targetPort: 3500
    protocol: TCP
  selector:
    app: echoserver

thanks,it works well,i have be bother some days,well,thank you

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.