Hello Kubernetes tutorial should use the Helm installation instead of the dapr init -k approach

[salaboy]

Looking at this tutorial: https://github.com/dapr/quickstarts/tree/master/tutorials/hello-kubernetes , as a Kubernetes user I get scared of using a new CLI to install tools. I recommend switching to installing Dapr using Helm, a mechanism much more familiar to Kubernetes user.

This means changing dapr init -k --dev for the following commands:

Install Dapr

helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm upgrade --install dapr dapr/dapr \
--version=1.13.2 \
--namespace dapr-system \
--create-namespace \
--wait

To install Redis:

helm install redis oci://registry-1.docker.io/bitnamicharts/redis --version 17.11.3 --set "architecture=standalone" --set "master.persistence.size=1Gi"

If dapr init -k --dev is installing more things, for Kubernetes audience we need to make them explicit. Nobody likes installing things on a cluster without knowing exactly what is going on, it makes it more difficult to troubleshoot.

[pdebruin]

I agree that there should be a transparent description of how to deploy Dapr and friends to Kubernetes instead of --dev: Source: https://github.com/dapr/cli/blob/master/pkg/kubernetes/kubernetes.go#L99

• Redis https://github.com/dapr/docs/issues/3985#issuecomment-2171141011
• Zipkin https://docs.dapr.io/operations/observability/tracing/zipkin/
• Statestore & pubsub https://docs.dapr.io/getting-started/tutorials/configure-state-pubsub/ This way, cluster operators can understand what happens, and choose what and where they want to deploy.

[salaboy]

@pdebruin do you want to work with me on these changes ? I am happy to do a simple configuration first but I might need help for more advanced use cases

[joebowbeer]

Redis should be installed with a dedicated release name to avoid conflicts, which is currently dapr-dev-redis in default namespace. (Same applies to zipkin.)

helm install redis oci://registry-1.docker.io/bitnamicharts/redis --version 17.11.3 --set "architecture=standalone" --set "master.persistence.size=1Gi"

Consider using subcharts (umbrella) to make this even easier. Provide one dapr-dev umbrella chart, with redis and zipkin subcharts, and one dapr (non-dev) chart?

[joebowbeer]

@salaboy Have you seen this sweet devcontainer setup for deploying a dapr sample app to a local kind cluster?

https://github.com/Azure-Samples/pubsub-dapr-aks-java?tab=readme-ov-file#local-dev-environment-setup

Alternatively you can use DevContainers and VS Code for local development. Opening the project with VS Code will automatically install all the required tools and extensions using DevContainers.

This worked for me without a hitch.

[salaboy]

@joebowbeer yeah I've seen that and that can totally complement what is proposed here. But it defeats the purpose of being super clear about what Dapr needs to run it basic components. The idea behind running something like this:

helm install redis oci://registry-1.docker.io/bitnamicharts/redis --version 17.11.3 --set "architecture=standalone" --set "master.persistence.size=1Gi"

Is to be super clear that a Redis instance is needed by the hello-kubernetes example experience. The same applies for a parent helm chart. If we try to encapsulate and make it simpler, we make it more complicated for Kubernertes operators.

[joebowbeer]

@salaboy On the one hand, as a Kubernetes user, I do like to know what resources are being installed, but for a quickstart, I like it even more if everything just works right out of the box. Then I'll want to dig in and see what's really going on so I can deploy it for real using GitOps.

Digging in, I see that what I'm pointing you to is (I think) doing what you're suggesting: 😄

printf '\n📀 Deploy Redis\n\n'
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install redis -n default --set architecture=standalone bitnami/redis

printf '\n📀 Init Dapr\n\n'
dapr init --kubernetes --wait --timeout 600

[salaboy]

@joebowbeer yeah.. I do agree with that... I want to make sure that people can get started without obfuscating the Kubernetes experience that they are already used to. For example, we can look at other CNCF projects.

Look at the Cert Manager tutorial to get started -> https://cert-manager.io/docs/tutorials/acme/nginx-ingress/ .

No new CLI is needed besides Helm as the default package manager, and then just kubectl and be super clear about what you are installing and why.

Knative takes it one step further, no Helm and being clear about each Control Plane component that you need to install. https://knative.dev/docs/install/yaml-install/serving/install-serving-with-yaml/ . IMHO, there is no need to go that far, Helm is widely used and Dapr offer helm charts.

Crossplane follows the same approach (Helm + kubectl) -> https://docs.crossplane.io/v1.16/getting-started/provider-gcp/

[joebowbeer]

@salaboy I fully agree that there's a need for a transparent "Getting started with Dapr on Kubernetes", with easy to follow installation steps, similar to what most CNCF projects provide. Any of the Argo Projects, for example.

I also want to point out that most if not all of the quickstart samples in this repo are sample app deployments, intended to showcase specific features using your favorite SDK and runtime configuration. I think there's a difference between these and the ones you reference. I imagine that not all of the users of these quickstarts, who are for example trying Dapr in Kubernetes, are Kubernetes saavy. It's something to consider, anyway.

[msfussell]

Yes, the goal of this quickstart is to teach Dapr APIs not to teach Kubernetes, so we have to get a balance here, between long set up times and seeing Dapr in operation.

[salaboy]

@salaboy I fully agree that there's a need for a transparent "Getting started with Dapr on Kubernetes", with easy to follow installation steps, similar to what most CNCF projects provide. Any of the Argo Projects, for example.

I also want to point out that most if not all of the quickstart samples in this repo are sample app deployments, intended to showcase specific features using your favorite SDK and runtime configuration. I think there's a difference between these and the ones you reference. I imagine that not all of the users of these quickstarts, who are for example trying Dapr in Kubernetes, are Kubernetes saavy. It's something to consider, anyway.

While I understand your point of view and @msfussell too, I believe that by pushing that perspective forward we are completely confusing the Kubernetes community.

Imagine the following situation:

1) Developers do quickstarts in their favorite language and understand the Dapr APIs and SDKs, and they run their applications on Kubernetes for more serious environments after development. So they ask people managing their clusters to look into Dapr 2) Platform teams arrive at the Dapr documentation, and they want to try it out. No tutorial or quickstart is targeting this kind of user, which is Kubernetes-savvy and already used to other CNCF projects. They will first find the hello-kubernetes quickstart; when they see dapr -k to install something, they will run away. If they manage to go past that point, they are out the moment they see that this command installed a Redis instance on their behalf.

I am trying to avoid this at all costs because I keep getting feedback from Kubernetes-savvy users who go to the Dapr site and don't understand what is going on or what it has to do with Kubernetes. While I understand that Dapr can be run outside of Kubernetes, as a CNCF project, we should heavily rely on the Kubernetes angle to explain and talk about Dapr.

[joebowbeer]

@salaboy I agree with you that dapr init -k --dev is not a great path, and that my earlier idea of an umbrella chart probably isn't either. It's better to separate concerns, and to avoid composing or encapsulating dependencies that are not controlled by Dapr.

I think we agree that a "Getting started with Dapr on Kubernetes", with easy to follow installation steps, would be a great thing. I think this corresponds to what you were pointing out in other CNCF projects.

In addition, as someone who is Kubernetes-saavy approaching Dapr, I am familiar with the confusion you mention!

Aside: However, I'm also not certain about the best way to do local development for apps that will be deployed on Kubernetes. There are a lot of different options, including devcontainer with docker in docker, docker out of docker(?), and maybe remote/local "remocal" hybrids. (I'm thinking of Telepresence, mirrored, signadot.) Many of these options do not require the dev to manage their own cluster. Then again, there are other "cluster-forward" approaches, such as Skaffold and Tilt, where the dev does manage their own cluster. Even as a Kubernetes-saavy user, I'm still searching for the best way to do local dev.

[paulyuk]

Hey everyone - @salaboy @joebowbeer @pdebruin. We would love to have a rapid / quick start for hello kubernetes, and yet at the same time do things that are familiar to kubernetes users.

I believe the sweet spot therefore is we keep the dapr init -k --dev as a fast way to install *standard bitnami redis in the cluster, exactly the same as if you did it yourself. But, we should no longer apply a redis.yml anymore as a part of --dev, and leave that to the user to apply explicitly and know what happened. I've been coordinating this kind of change with @yaron2.

The quickstart tutorial therefore would start with the --dev init, but then would have a step to apply the statestore component redis.yml. At the end of the tutorial you would delete the redis deployment of the statestore.

What do you think?

[salaboy]

Hey @paulyuk my opinion is still the same dapr init -k --dev is not familiar to Kubernetes users. We are pushing Kubernetes users to download a new CLI and then run a command that will install things in their clusters that they have no visibility to. How does the proposed solution covers yet at the same time do things that are familiar to kubernetes users ?

[joebowbeer]

@paulyuk I am not sure I understand what you're saying:

I believe the sweet spot therefore is we keep the dapr init -k --dev as a fast way to install *standard bitnami redis in the cluster, exactly the same as if you did it yourself. But, we should no longer apply a redis.yml anymore as a part of --dev, and leave that to the user to apply explicitly and know what happened.

I think --dev currently installs redis and zipkin. I'm not sure if you're proposing that --dev should do something different, or that it be removed.

I agree with @salaboy that those approaching Dapr from k8s may be wary of installing a CLI in order to install something in their cluster. Raw manifests or helm charts are more familiar alternatives. That said, there do exist a lot of CLI's in CNCF projects, for example: argo, cilium, linkerd, vcluster. However, in all of those projects, helm charts and/or raw manifests are also provided.

@salaboy Would a Dapr (krew) plugin for kubectl be helpful? Just wondering.

By the way, Dapr's multi-app support reminds me of the k8s tool Skaffold, which I've used. It might be similar to Tilt, as well, but I haven't used that one.

[salaboy]

@joebowbeer most of CNCF CLIs are helpers to solve some sort of limitations with kubectl or to keep open connections. A krew plugin might help, but that is usually just to simplify steps not to obscure the process. I wouldn't create a plugin to install Dapr for example, neither to automatically install Redis.

Notice the argocd CLI reference commands -> https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd/ . This is just a CLI that will help you with operational concerns to avoid you listing 3 resources to figure out your application status. We can definitely do that.

The vcluster CLI help users to manage vclusters tokens, so they don't need to set up environment variables when they are switching between vclusters -> https://www.vcluster.com/docs/vcluster/#use-your-virtual-cluster. In this case vcluster delete just remove namespaces (vcluster creates 4 namespaces per virtual cluster) so having a CLI to do that for the user makes a lot of sense.

The linkerd one is the odd one -> https://linkerd.io/2.15/reference/cli/install/ it takes the YAML files from the release to install them using kubectl. I think they are doing this because they need to coordinate and wait for resources to be ready before proceeding, something that is complicated if you try to apply a lot of YAML files.

This reinforce my point, that we are doing things in a very odd way compared with other projects. If we want to keep dapr init -k we at least need to have a good tutorial for Kubernetes users highlighted in the Dapr project landing website.

[joebowbeer]

To be thorough,

cilium install is also their recommended way to install, possibly because it runs validation after the install.

vcluster create is advertised as the quickest and easiest way to create a vcluster.

Even so, in all of these cases one doesn't need to scroll far in order to find a helm chart or a manifest.

👉 And in none of these cases does any CLI install 3rd party resources.

I don't have a strong opinion about dapr -k

Regardless of dapr -k, I do want to see Dapr helm chart and/or manifests highlighted in the docs, as suggested.

[salaboy]

@joebowbeer my issue with dapr -k is that you get other things installed.. not the installation of Dapr itself. And yes.. +1 to have the helm chart highlighted in the docs