Skip to the content.

Kubernetes - Azure Container Service (AKS)

logo

This document covers deploying Smilr into Kubernetes and specifically into Azure Container Service (AKS) This assumes you have the latest Azure CLI installed (2.0.21+)

Set-up & Creation of AKS

This document is not intended to be a step by step guide for deploying Azure Container Service (AKS), if you do not have AKS setup then there are several guides you can use

NOTE. When creating your AKS cluster it is strongly recommended you enable the “HTTP Application Routing add-on” during creation, or create with the --enable-addons http_application_routing option. This will automatically enable an ingress controller in your cluster and also provide you with an external DNS zone in Azure, with Kubernetes configured to automatically create records in it.


Deploying Smilr to Kubernetes

Once you have AKS deployed and are able to interact with it via kubectl you can start deploying Smilr to it

Pre-requisites

Before starting deploying Smilr into Kubernetes you will need to have an Azure Container Registry (ACR) populated with the Smilr container images.

Refer to the main container guide for details

:page_with_curl: Complete container guide

Notes on Smilr Kubernetes deployment:


Option 1 - Helm (Easiest)

Helm is a package manager for Kubernetes, and a Helm Chart has been created to deploy Smilr. This means you can deploy Smilr with a single command. The chart is called simply ‘smilr’ and is in the helm subdirectory

Helm & Smilr Quick Start

Full details of using the Helm chart are here:

:page_with_curl: Helm Chart Docs


Option 2 - Direct Deployment

Deployment YAML files have been provided to directly stand up Smilr in your Kubernetes cluster. Two scenarios are provided, in both cases the deployment has been split into multiple files.

Before deployment of either scenario the files frontend.yaml and data-api.yaml will require editing to point to your images and the relevant registry (i.e. ACR) & tag you are using. It is assumed you will be deploying to the default namespace

Scenario A - Basic

kube2
Deployment Files for this scenario are in /kubernetes/basic

This method exposes the two Smilr services externally with their own external IP addresses, using the Kubernetes LoadBalancer service type. This has the advantage of not requiring any dependency on an Ingress controller but does require some manual editing of the YAML during deployment.

Note. This scenario also doesn’t persist the data for the MongoDB

The steps for deployment are:

  1. Modify data-api.yaml and frontend.yaml and change the image: section to point to where your Smilr images are held, i.e. your ACR instance

  2. Deploy the data layer
     cd kubernetes/basic
     kubectl apply -f mongodb.yaml
     kubectl apply -f data-api.yaml
     kubectl get svc data-api -w
    

    Wait for service data-api to get an external IP address assigned, once it has, hit CTRL+C stop waiting. Note. This can take about 5-10 minutes in some cases, so be patient.
    Copy the external IP address and edit frontend.yaml modify the API_ENDPOINT env URL to point to the data-api IP which was just assigned. You will need to have /api as part of the URL, e.g. http://{data-api-service-ip}/api

  3. Deploy the frontend
     kubectl apply -f frontend.yaml
     kubectl get svc frontend -w
    

    Wait for service frontend to get an external IP address assigned, once it has, hit CTRL+C stop waiting.
    The frontend service external IP address is where you can access the Smilr app, e.g. by visiting http://{frontend-service-ip}/ in your browser

Scenario B - Advanced

kube1
Deployment Files for this scenario are in /kubernetes/advanced

This method uses a Kubernetes Ingress to provide a single entrypoint into your cluster, and URL path rules to route traffic to the Smilr frontend and data-api as required. This simplifies config as the API endpoint is the same as where the Vue.js SPA is served from so it doesn’t require any fiddling with IP addresses or DNS.

This scenario also uses introduces persistence to MongoDB:

This scenario does require an ingress controller running in your cluster, which if you enabled “HTTP Application Routing” when creating AKS you will already have. If you don’t have this add on, use Helm (e.g. helm install stable/nginx-ingress) but you will need to change the kubernetes.io/ingress.class in ingress.yaml to nginx

The steps for deployment of this scenario are:

  1. Edit ingress-http.yaml or ingress-https.yaml and modify the DNS zone/domain to match the one created with your AKS cluster (in the MC resource group). It will take the form of {random}.{region}.aksapp.io/. You should only need to do this once
  2. Edit data-api.yaml and frontend.yaml and change the image: section to point to where your Smilr images are held, i.e. your ACR instance
  3. Run the following
     cd kubernetes/advanced
     kubectl apply -f mongodb.yaml
     kubectl apply -f data-api.yaml
     kubectl apply -f frontend.yaml
     kubectl apply -f ingress-http.yaml
    

    Note. If you have setup cert-manager for HTTPS support (See appendix below) then use the ingress-https.yaml file instead

  4. The app will be available at http://smilr.{random}.{region}.aksapp.io/ If you want to get the IP of your ingress you can run
     kubectl get svc -l app=addon-http-application-routing-nginx-ingress --all-namespaces -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}{"\n"}'
    

Optional Appendix - Enable HTTPS with cert-manager

If you wish to use HTTPS and have certs issued via Let’s Encrypt the instuctions for setting that up are below

:page_with_curl: Enabling HTTPS with cert-manager

Optional Appendix - Enable sentiment microservice

If you wish to enable sentiment analysis of feedback comments with an additional cognitive microservice, the steps are: