{"id":437,"date":"2019-10-16T12:17:45","date_gmt":"2019-10-16T19:17:45","guid":{"rendered":"http:\/\/blog.nillsf.com\/?p=437"},"modified":"2019-10-16T12:17:48","modified_gmt":"2019-10-16T19:17:48","slug":"setting-up-keda-and-running-a-first-application","status":"publish","type":"post","link":"https:\/\/blog.nillsf.com\/index.php\/2019\/10\/16\/setting-up-keda-and-running-a-first-application\/","title":{"rendered":"Setting up KEDA and running a first application"},"content":{"rendered":"\n

I’m presenting at a meetup tonight on the topic of Nodeless and Serverless on Kubernetes. My friend and colleague Richard Spitz <\/a>is presenting on nodeless kubernetes and the virtual kubelet<\/a> – while I’ll be taking on the topic of Serverless Kubernetes, with a focus on KEDA<\/a>.<\/p>\n\n\n\n

KEDA (Kubernetes Event Driven Architecture) is a kubernetes component that allows event-driven scale to Kubernetes pods. It is an open-source project, initially developed by Microsoft and Red Hat.<\/p>\n\n\n\n

The challenge KEDA solves, is the link between the Kubernetes horizontal pod autoscaler and event sources. I like to think as it as an interface between my event source (e.g. a queue, a bus or HTTP events) and the amount of pods you have running on your cluster. KEDA will act as the scale to 0 or the scale from 0->1, and KEDA will be the event source for the Horizontal Pod Autoscaler for the scaling beyond 1 pod.<\/p>\n\n\n\n

From a Microsoft perspective, KEDA is integrated very well with Azure Functions. Azure Functions has the option to run on Kubernetes, but you’d then use the default Kubernetes scaling mechanisms. Combining KEDA with Azure Functions allows you to use different scaling metrics to scale in\/out your functions deployment. You don’t have to combine KEDA with Azure Functions, but you can.<\/p>\n\n\n\n

So, why don’t we get started? I’ll all of the below on my Ubuntu 18.04 running on WSL.<\/p>\n\n\n\n

Prerequisites<\/h2>\n\n\n\n

First, let’s go ahead and install .net core 3. We’ll use that later when building our testing application.<\/p>\n\n\n\n

wget -q https:\/\/packages.microsoft.com\/config\/ubuntu\/18.04\/packages-microsoft-prod.deb -O packages-microsoft-prod.deb\nsudo dpkg -i packages-microsoft-prod.deb\nsudo add-apt-repository universe\nsudo apt-get update\nsudo apt-get install apt-transport-https -y\nsudo apt-get update\nsudo apt-get install dotnet-sdk-3.0 -y<\/code><\/pre>\n\n\n\n
Although KEDA doesn’t require using Azure Functions, for our demo we’ll be using Azure functions to setup KEDA real easily (single line command). We’ll install the core runtime on our machine.<\/p>\n\n\n\n
sudo apt-get install azure-functions-core-tools -y<\/code><\/pre>\n\n\n\n
Another prereq, is to have helm on our kubernetes cluster. To keep things easy, I’ll assume you have a Kubernetes cluster on Azure running in AKS. Depending on how you want to run your demo, you can have a clsuter with or without virtual nodes. I’ll be running this with virtual nodes turned on.<\/p>\n\n\n\n
First we’ll get access to our cluster and show our nodes to see if the connection actually works:<\/p>\n\n\n\n
az aks get-credentials -n nf-keda -g KEDA\nkubectl get nodes\nNAME                                STATUS   ROLES   AGE     VERSION\naks-agentpool-32106788-vmss000000   Ready    agent   2d21h   v1.14.6\naks-agentpool-32106788-vmss000001   Ready    agent   2d21h   v1.14.6\naks-agentpool-32106788-vmss000002   Ready    agent   2d21h   v1.14.6\nvirtual-node-aci-linux              Ready    agent   2d21h   v1.13.1-vk-v0.9.0-1-g7b92d1ee-dev<\/code><\/pre>\n\n\n\n
As you can see, I have a virtual node. More on that later, but let’s go ahead and setup helm on our cluster:<\/p>\n\n\n\n
I already had the helm binary on my machine, if you don’t already, go ahead and download the tarbal and move it to a directory that’s on your PATH.<\/p>\n\n\n\n
wget https:\/\/get.helm.sh\/helm-v2.14.3-linux-amd64.tar.gz #look for the latest version here https:\/\/github.com\/helm\/helm\/releases\ntar -zxvf helm*.tar.gz\nsudo mv linux-amd64\/helm \/usr\/local\/bin\/helm<\/code><\/pre>\n\n\n\n
Next up, we need to setup Tiller (as long as we’re using Helm v2 that is. In v3 there’s no more requirement for Tiller, but that’s still in beta).<\/p>\n\n\n\n
If your cluster is RBAC enabled, you’ll need to create a role and rolebinding to make Tiller work correctly. I wrote about this a while ago.<\/a><\/p>\n\n\n\n
kubectl create serviceaccount --namespace kube-system tiller\nkubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller\nhelm init --service-account tiller<\/code><\/pre>\n\n\n\n
To verify Helm installed correctly, you can run helm version<\/code>, which should return the following:<\/p>\n\n\n\n
Client: &version.Version{SemVer:\"v2.14.3\", GitCommit:\"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085\", GitTreeState:\"clean\"}\nServer: &version.Version{SemVer:\"v2.14.3\", GitCommit:\"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085\", GitTreeState:\"clean\"}<\/code><\/pre>\n\n\n\n
Setting up KEDA on an AKS cluster<\/h2>\n\n\n\n
There are a couple of ways to setup Keda. The easiest way I found is to the Azure Functions tooling to install KEDA on our cluster.<\/p>\n\n\n\n
func kubernetes install --namespace keda<\/code><\/pre>\n\n\n\n
This will install KEDA in our cluster. The installation of KEDA will install KEDA and Osiris in our cluster. To see everything that got installed on our cluster, we can check via kubernetes get all --namespace=keda<\/code>, which will return the following (screenshot in stead of text as the output is quiet lengthy).<\/p>\n\n\n\n
\"\"
KEDA is now running in our cluster, and deployed a number of objects.<\/figcaption><\/figure>\n\n\n\n
Let’s now go ahead and build a demo app.<\/p>\n\n\n\n
Building a demo app<\/h2>\n\n\n\n
For the demo app, we’ll be using a pre-built C# application that reads from an Azure Service Bus. This demo is following the following quickstart template<\/a> in the KEDA docs. We’ll do all of this in the keda-bus namespace:<\/p>\n\n\n\n
kubectl create namespace keda-bus<\/code><\/pre>\n\n\n\n
First off, we’ll create a Service Bus namespace with a queue and get it’s connection string.<\/p>\n\n\n\n
BUSNAMESPACE=nfkedabus\nRG=KEDA\nQUEUE=orders\nAUTH=order-consumer\naz servicebus namespace create --name $BUSNAMESPACE --resource-group $RG --sku basic\naz servicebus queue create --namespace-name $BUSNAMESPACE --name $QUEUE --resource-group $RG\naz servicebus queue authorization-rule create --resource-group $RG --namespace-name $BUSNAMESPACE --queue-name $QUEUE --name $AUTH --rights Manage Send Listen\nconn=`az servicebus queue authorization-rule keys list --resource-group $RG --namespace-name $BUSNAMESPACE --queue-name $QUEUE --name $AUTH -o json`\nconnstring=`echo $conn | jq .primaryConnectionString`\nconnstring=`echo \"${connstring\/\/\\\"}\"`<\/code><\/pre>\n\n\n\n
We’re going to use this connection string and store it as a kubernetes secret for use with our demo.<\/p>\n\n\n\n
kubectl create secret generic --from-literal=SERVICEBUS_QUEUE_CONNECTIONSTRING=$connstring --namespace=keda-bus order-secrets<\/code><\/pre>\n\n\n\n
Next up, we’ll create the actual application and scaled-object in KEDA. I’ll be pulling the deployment file straight from GitHub, but you can certainly download it and tweak it (which we’ll do later).<\/p>\n\n\n\n
kubectl apply -f https:\/\/raw.githubusercontent.com\/kedacore\/sample-dotnet-worker-servicebus-queue\/master\/deploy\/deploy-queue-processor.yaml --namespace keda-bus<\/code><\/pre>\n\n\n\n
If we then check everything on our cluster (kubectl get all -n keda-bus<\/code>), we see 3 resources, but no pods).<\/p>\n\n\n\n