Integrating Dapr with Azure Kubernetes Service (AKS): Portability is key

In a recent blog post, we explored how Dapr works and how to test it on a simple local Kubernetes cluster. One of Dapr's key advantages is its component system, which enhances portability. In this post, we'll take our previously daperized demo app and deploy it in an AKS environment, utilizing some of Azure's managed services through Dapr to demonstrate its portability.

Quick Recap on Components

Each Dapr building block (e.g., PubSub) can be used within Dapr by defining a component. A component is an instance of a building block and comes with its own configuration. For example, a PubSub component using RabbitMQ would look like this:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order-pub-sub
spec:
  type: pubsub.rabbitmq
  version: v1
  metadata:
  - name: host
    value: "amqp://localhost:5672"
scopes:
  - orderprocessing
  - checkout

Once an application calls a Dapr sidecar to publish a message, the Dapr sidecar sends it to RabbitMQ, and everything flows as usual from there. Various cloud providers have components to integrate with Dapr. For this blog post, we will focus on AKS and show an example with it.

Talking about requirements

If you want to follow along with this blog post, you will need to have some requirements in place.

• Installed Azure CLI
• Helm or Dapr CLI
• Access to an Azure Subscription

Lets get an AKS Cluster

To quickly set up an AKS cluster, we'll use the Azure az CLI. First, we will create a resource group and then create an AKS cluster inside it.

az group create --name dapr-aks --location germanywestcentral
az aks create --resource-group dapr-aks --name dapr-aks --node-count 2 --generate-ssh-keys --tier free 

The output should look like this:

{
  "id": "/subscriptions/70abc615-f4d6-474a-8c0e-2d30a9d41d84/resourceGroups/dapr-aks",
  "location": "germanywestcentral",
  "managedBy": null,
  "name": "dapr-aks",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
} <!--- Ressource group created-->
The behavior of this command has been altered by the following extension: aks-preview
{
  "aadProfile": null,
  "addonProfiles": null,
   SNIP
  "workloadAutoScalerProfile": {
    "keda": null,
    "verticalPodAutoscaler": null
  }
} <!--- Cluster created-->

With the ressource group and cluster created, we need to connect to the cluster to proceed! This is simply done with

az aks get-credentials -n dapr-aks -g dapr-aks

Lets test connectivty with a simple command:

kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-nodepool1-21855256-vmss000000   Ready    agent   5m53s   v1.28.10
aks-nodepool1-21855256-vmss000001   Ready    agent   5m54s   v1.28.10

Install Dapr 3 options to choose from

Generally speaking, there are three major possibilities to install the Dapr runtime on an AKS cluster each with its own pros and cons. For the sake of completeness, we will cover all three methods: Dapr CLI, Helm, and the AKS-managed Dapr extension. Each method offers a different level of control and convenience. If I were to choose, I'd usually go with the Helm approach for its balance of flexibility and ease of use.

1. Dapr CLI: Quick and straightforward, ideal for development and testing environments.
2. Helm: Offers more customization and is well-suited for production environments.
3. AKS-managed Dapr extension: Simplifies management by offloading maintenance to Azure, though it may have some limitations in customization.

Let's dive into each method in more detail.

Install Dapr runtime with Dapr CLI

As shown in the last blog post, the Dapr CLI already has a built-in functionality to bootstrap the runtime on a Kubernetes cluster. A simple command:

dapr init -k 

will install the runtime with all the necessary services. This time, we won't use the -dev flag, as we don't want any Dapr configuration components to be available in the cluster already.

dapr init -k
⌛  Making the jump to hyperspace...
ℹ️  Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced

ℹ️  Container images will be pulled from Docker Hub
✅  Deploying the Dapr control plane with latest version to your cluster...
✅  Deploying the Dapr dashboard with latest version to your cluster...
✅  Success! Dapr has been installed to namespace dapr-system. To verify, run `dapr status -k' in your terminal. To get started, go here: https://aka.ms/dapr-getting-started

Quickly checking that its deployed

dapr status -k
  NAME                   NAMESPACE    HEALTHY  STATUS   REPLICAS  VERSION  AGE  CREATED
  dapr-sidecar-injector  dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
  dapr-placement-server  dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
  dapr-operator          dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
  dapr-dashboard         dapr-system  True     Running  1         0.14.0   51s  2024-07-18 12:39.25
  dapr-sentry            dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23

And we are good to go! By default, the Dapr CLI is the only method that also installs the dashboard.

Install Dapr runtime with Helm

As suggested by the Dapr CLI command, you can also use Helm to install Dapr. The Dapr CLI actually utilizes the official Helm chart under the hood to deploy the components, making the CLI essentially a convenience wrapper. To install Dapr manually using Helm, there are just a few steps involved.

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

The output should look like this:

"dapr" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "dapr" chart repository
Update Complete. ⎈Happy Helming!⎈
Release "dapr" does not exist. Installing it now.
NAME: dapr
LAST DEPLOYED: Thu Jul 18 12:49:15 2024
NAMESPACE: dapr-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing Dapr: High-performance, lightweight serverless runtime for cloud and edge

Your release is named dapr.

To get started with Dapr, we recommend using our quickstarts:
https://github.com/dapr/quickstarts

For more information on running Dapr, visit:
https://dapr.io

Checking the pods

kubectl get pods -n dapr-system
NAME                                     READY   STATUS    RESTARTS   AGE
dapr-operator-5789c8dc5b-fcxwz           1/1     Running   0          60s
dapr-placement-server-0                  1/1     Running   0          60s
dapr-sentry-774c876df5-wj9xp             1/1     Running   0          60s
dapr-sidecar-injector-867c5f9485-jgxvw   1/1     Running   0          60s

This confirms that everything is up and running, and we are good to go.

Dapr Dashboard

To install the Dapr Dashboard, you'll need to use its official Helm chart as well.

helm install dapr-dashboard dapr/dapr-dashboard --namespace dapr-system
NAME: dapr-dashboard
LAST DEPLOYED: Thu Jul 18 12:55:37 2024
NAMESPACE: dapr-system
STATUS: deployed
REVISION: 1
TEST SUITE: None

Azure Managed Dapr runtime installation

Last but not least, AKS offers a managed Dapr installation that you can utilize as well. This managed option alleviates the need for you to handle the runtime yourself, but it does come with some limitations.

To set it up, you can use the following commands:

az extension add --name k8s-extension
az provider register --namespace Microsoft.KubernetesConfiguration
az feature registration create --namespace Microsoft.KubernetesConfiguration --name ExtensionTypes
az k8s-extension create --cluster-type managedClusters \
--cluster-name dapr-aks \
--resource-group dapr-aks \
--name dapr \
--extension-type Microsoft.Dapr \
--auto-upgrade-minor-version false

Once this is done, you'll have a Dapr runtime managed by AKS. As already seen with the Helm instals, this managed installation does not include the Dapr Dashboard, which you will need to install manually if required.

Setup Service Bus for PubSub

Alright, with the Dapr runtime now set up, we can proceed. Since we’re working in AKS, we'll leverage Azure Service Bus for our PubSub component instead of managing an alternative solution ourselves. To achieve this, follow these three steps:

• Create a Service Bus Namespace
• Create a Queue within that Namespace
• Retrieve the Authorization Key

These steps can be easily accomplished using the Azure CLI. Here’s how you can do it:

# Step 1: Create a Service Bus Namespace
az servicebus namespace create --resource-group dapr-aks --name dapr-aks-orders-bus-ns --location westeurope

# Step 2: Create a Queue in the Namespace
az servicebus queue create --resource-group dapr-aks --namespace-name dapr-aks-orders-bus-ns --name orders

# Step 3: Get the Authorization Key
az servicebus namespace authorization-rule keys list --resource-group dapr-aks --namespace-name dapr-aks-orders-bus-ns --name RootManageSharedAccessKey --query primaryConnectionString --output tsv

{
  "createdAt": "2024-07-10T14:01:58.1974899Z",
  "disableLocalAuth": false,
  "id": "/subscriptions/70abc615-f4d6-474a-8c0e-2d30a9d41d84/resourceGroups/dapr-aks/providers/Microsoft.ServiceBus/namespaces/dapr-aks-orders-bus-ns",
  "location": "westeurope",
  "metricId": "70abc615-f4d6-474a-8c0e-2d30a9d41d84:dapr-aks-orders-bus-ns",
  "minimumTlsVersion": "1.2",
  "name": "dapr-aks-orders-bus-ns",
  "premiumMessagingPartitions": 0,
  "provisioningState": "Succeeded",
  "publicNetworkAccess": "Enabled",
  "resourceGroup": "dapr-aks",
  "serviceBusEndpoint": "https://dapr-aks-orders-bus-ns.servicebus.windows.net:443/",
  SNIP
  "status": "Active",
  "type": "Microsoft.ServiceBus/namespaces/queues",
  "updatedAt": "2024-07-18T14:43:45Z"
}
Endpoint=sb://dapr-aks-orders-bus-ns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=9eq5sPFWFzFVIFzTscAaI2xgZ/1LhbOl++ASbBK9GbY=

The most important part is the Endpoint= in the authorization key output. This will be used to configure the PubSub component in Dapr.

Setup PubSub component in Dapr

Now it’s time to configure Dapr with Azure Service Bus. We need to create a Dapr component in YAML format for our AKS cluster. Here's how you can configure it:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
spec:
  type: pubsub.azure.servicebus.queues
  version: v1
  metadata:
  - name: connectionString # Required when not using Azure Authentication.
    value: "Endpoint=sb://dapr-aks-orders-bus-ns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=9eq5sPFWFzFVIFzTscAaI2xgZ/1LhbOl++ASbBK9GbY="

In this configuration:

• The name of the component is set to pubsub, matching the name used in previous examples. This facilitates the reusability and portability of your Dapr building blocks
• The type is specified as pubsub.azure.servicebus.queues, indicating that we're using Azure Service Bus for PubSub.
• The connectionString is provided to authenticate with Azure Service Bus as fetched previously

This enables the reusability and portability. A sidecar will just emit the event to the component, not knowing whether its redis (as previously) or now Azure Sercive Bus.

Test things

With everything set up, you’re almost ready to see your demo app in action. Here’s what you need to do:

• First, apply the necessary configurations to your AKS cluster:

kubectl apply -f deploy/components.yml
kubectl apply -f src/emailservice/components/subscription.yml

• Second, start the application

dapr run -f dapr.yaml -k

This setup will deploy the same Microservice Demo application as in the latest blog post. The difference now is that instead of Redis, Azure Service Bus handles the PubSub functionality.

• Third, Access the Frontend
• Find the IP address of the LoadBalancer service for the frontend application:

kubectl get service frontend
NAME       TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
frontend   LoadBalancer   10.0.72.187   4.182.85.177   80:30896/TCP   66s

Use the EXTERNAL-IP to access your application through your browser. Once you have navigated through the entire demo and done a checkout, we can validate the that azure service bus is working in two places.

• A) in the azure portal

• B) as last time, in the log of the email service

{"timestamp": 1721314877.7026074, "severity": "INFO", "name": "emailservice-server", "message": "A request to send order confirmation email for order 958d281b-4516-11ef-abe6-8ead7dd66b53 to someone@example.com has been received.", "taskName": null}

More integration with Azure

Azure Service Bus for PubSub is just one example of how Dapr integrates with Azure’s managed services to simplify your architecture. Dapr supports various other Azure services to manage complexity efficiently. Here are a few more examples:

• State Management: Use Azure Blob Storage, Table Storage, SQL Server, CosmosDB, PostgreSQL, or MariaDB.
• PubSub: Besides Azure Service Bus, you can utilize Azure Event Hub, Kafka, or Redis.
• Secrets Management: Integrate seamlessly with Azure Key Vault.
• Configuration: Use PostgreSQL or Redis for configuration management.

These integrations underscore Dapr's commitment to portability. By merely adjusting configurations, you can switch between different managed services without needing to alter your application's code. This flexibility is central to Dapr's design, enabling you to easily adapt your applications to various environments.

Conclusion

In this blog post, we've highlighted Dapr's impressive portability by migrating our daperized demo app from a local Kubernetes cluster to Azure Kubernetes Service (AKS). Through this transition, we leveraged Azure’s managed services via Dapr, showcasing how effortlessly applications can adapt to different environments with minimal changes. Whether transitioning from Redis for PubSub in a local setup to Azure Service Bus in the cloud, Dapr maintains the decoupling and manageability of your microservices, ensuring a smooth and scalable deployment process.