Tutorial: First Look at Dapr for Microservices Running in Kubernetes

Dapr is a portable, event-driven runtime for distributed systems originally developed by Microsoft. This hands-on guide will walk you through all the steps involved in dealing with state management in Dapr.

Feb 14th, 2020 9:39am by Janakiram MSV

Featued image for: Tutorial: First Look at Dapr for Microservices Running in Kubernetes

Feature image via Pixabay.

In a previous article, I introduced the architecture and building blocks of Dapr, a portable, event-driven runtime for distributed systems originally developed by Microsoft. To appreciate the platform, let’s zoom into the state management building block of Dapr. This hands-on guide will walk you through all the steps involved in dealing with state management in Dapr.

Background

We are going to deploy two microservices written in Node.js and Python in Kubernetes. The services will use Redis as the persistence layer to store the state. Since we use Dapr, we will swap out Redis with etcd while continuing to run the microservices.

To complete this tutorial, you need a Kubernetes cluster running within Minikube or a managed service such as the Azure Kubernetes Service (AKS).

I am running Minikube on my development machine.

Installing Dapr

Download the Dapr CLI for your OS from the releases page of GitHub repository, rename and add the binary to the path.

Run the below command to install Dapr in your Kubernetes environment.

dapr init --kubernetes

1	dapr init --kubernetes

The installer deploys a few Pods in the default Namespace that are a part of Dapr control plane. Like the service mesh, Dapr has a control plane that integrates with Kubernetes and a data plane that runs as a sidecar inside each Pod.

The dapr-operator Pod watches for Pods that have the Dapr Annotations. The dapr-sidecar-injector Pod is responsible for adding the sidecar container to each Pod annotated as “dapr.io/enabled: true”. Finally, the dapr-placement Pod manages the communication across all the sidecar containers injected into the Pods.

Configuring Redis as the Persistence Layer

Since we are dealing with the state store, the next step is to deploy Redis and configuring it as the default state store for the microservices.

Deploy Redis by submitting the below YAML file to Kubernetes. This results in the creation of a Pod and a ClusterIP Service.

apiVersion: v1
kind: Service
metadata:
  name: redis
  labels:
    app: redis
spec:
  ports:
  - port: 6379
    name: redis
    targetPort: 6379
  selector:
    app: redis
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    matchLabels:
      app: redis
  replicas: 1
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis-server
        image: redis:3.2-alpine

apiVersion: v1

kind: Service

metadata:

labels:

app: redis

spec:

ports:

- port: 6379

targetPort: 6379

selector:

app: redis

---

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

selector:

matchLabels:

app: redis

replicas: 1

template:

metadata:

labels:

app: redis

spec:

containers:

- name: redis-server

image: redis:3.2-alpine

kubectl apply -f redis.yaml

1	kubectl apply -f redis.yaml

With the Redis Pod up and running, let’s configure it as a Dapr state store. Create a YAML file with the below specification and apply it.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.redis
  metadata:
  - name: redisHost
    value: redis:6379
  - name: redisPassword
    value: ""

apiVersion: dapr.io/v1alpha1

kind: Component

metadata:

spec:

type: state.redis

metadata:

- name: redisHost

value: redis:6379

- name: redisPassword

value: ""

kubectl apply -f redis-state.yaml

1	kubectl apply -f redis-state.yaml

This creates a Rudr component for Redis. Rudr is a reference implementation of the Open Application Model (OAM) specification jointly created by Microsoft and Alibaba. For more details on OAM and Rudr, refer to this article and the tutorial.

Deploying Microservices That Use Dapr State Store

Let’s start by creating a Pod and Service spec that runs the first microservice written in Node.js. You can take a look at the code for this microservice at Dapr samples repo.

kind: Service
apiVersion: v1
metadata:
  name: nodeapp
  labels:
    app: node
spec:
  selector:
    app: node
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
    nodePort: 32000
  type: NodePort

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodeapp
  labels:
    app: node
spec:
  replicas: 1
  selector:
    matchLabels:
      app: node
  template:
    metadata:
      labels:
        app: node
      annotations:
        dapr.io/enabled: "true"
        dapr.io/id: "nodeapp"
        dapr.io/port: "3000"
    spec:
      containers:
      - name: node
        image: dapriosamples/hello-k8s-node
        ports:
        - containerPort: 3000
        imagePullPolicy: Always

kind: Service

apiVersion: v1

metadata:

labels:

app: node

spec:

selector:

app: node

ports:

- protocol: TCP

port: 80

targetPort: 3000

nodePort: 32000

type: NodePort

---

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: node

spec:

replicas: 1

selector:

matchLabels:

app: node

template:

metadata:

labels:

app: node

annotations:

dapr.io/enabled: "true"

dapr.io/id: "nodeapp"

dapr.io/port: "3000"

spec:

containers:

- name: node

image: dapriosamples/hello-k8s-node

ports:

- containerPort: 3000

imagePullPolicy: Always

Note that the Pod has Annotations for Dapr which act as a hint to inject the sidecar container.

      annotations:
        dapr.io/enabled: "true"
        dapr.io/id: "nodeapp"
        dapr.io/port: "3000"

annotations:

dapr.io/enabled: "true"

dapr.io/id: "nodeapp"

dapr.io/port: "3000"

kubectl apply -f node.yaml

1	kubectl apply -f node.yaml

If you analyze the code, you realize that the microservice is not directly referring to the persistent store in the microservice. Instead, it makes a call to the REST endpoint exposed by Dapr runtime. The sidecar container is responsible for enabling this communication between the microservice and the Dapr runtime.

const daprPort = process.env.DAPR_HTTP_PORT || 3500;
const stateStoreName = `statestore`;
const stateUrl = `http://localhost:${daprPort}/v1.0/state/${stateStoreName}`;

const daprPort = process.env.DAPR_HTTP_PORT || 3500;

const stateStoreName = `statestore`;

const stateUrl = `http://localhost:${daprPort}/v1.0/state/${stateStoreName}`;

Let’s deploy the second microservice written in Python that continuously invokes the API exposed by the first service deployed in the previous step.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pythonapp
  labels:
    app: python
spec:
  replicas: 1
  selector:
    matchLabels:
      app: python
  template:
    metadata:
      labels:
        app: python
      annotations:
        dapr.io/enabled: "true"
        dapr.io/id: "pythonapp"
    spec:
      containers:
      - name: python
        image: dapriosamples/hello-k8s-python

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: python

spec:

replicas: 1

selector:

matchLabels:

app: python

template:

metadata:

labels:

app: python

annotations:

dapr.io/enabled: "true"

dapr.io/id: "pythonapp"

spec:

containers:

- name: python

image: dapriosamples/hello-k8s-python

kubectl apply -f python.yaml

1	kubectl apply -f python.yaml

Since both the Pods are annotated for Dapr, the control plane has injected the sidecar into the Pods.

Checking the logs of the Node Pod shows that the state is being persisted.

NODE_POD=$(kubectl get pods -l app=node -o jsonpath='{.items[0].metadata.name}')
kubectl logs -f $NODE_POD -c node

1 2	NODE_POD=$(kubectl get pods -