AKS (Kubernetes service) — hard to understand, simple to configure

This is story about my experience to use Azure Kubernetes Service (AKS). One reason to move my solution from Web app for containers to AKS was an issue with performance and some troubles with App plan for Linux, some memory leaks that could not be managed by myself because Azure portal does not provide any simple tools to restart app plan just an example. So, I decided to try AKS on my solution.

I found so many information on internet resources about Kubernetes. Some of them were old, some of them were hard to understand. I was disappointed but I have a will to explain a few tips about configuring AKS that difficult to understand but simple to configure.

First, before configuring I have prepared check list that I need to implement using AKS:

1. To support multi DNS on one IP host.

3. Equal or less price

3. To provide SSL for securing network traffic

Let’s start. I found a good article how to deploy AKS cluster https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal#create-an-aks-cluster. Step by step you can configure AKS cluster using Azure portal. So easy.

Important. If you are planning to configure own custom ingress routing, click disable “Http application routing”.

After deploying I used az aks CLI to connect my laptop to AKS cluster. (https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-macos?view=azure-cli-latest). In my scenario I am using macbook (https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-with-homebrew-on-macos). All necessary thing for connecting our laptop to AKS cluster are configured. Nice link about kubernetes commands https://kubernetes.io/docs/reference/kubectl/kubectl/

Next step is creating Kubernetes manifest files for our microservices. One microservice = one pod. Here is an example of one manifest:

apiVersion: apps/v1beta1

kind: Deployment

metadata:

name: api

spec:

replicas: 1

template:

metadata:

labels:

app: api

spec:

containers:

- image: “ACR/api:dev”

imagePullPolicy: Always

name: api

ports:

- containerPort: 80

resources:

requests:

cpu: 250m

limits:

cpu: 500m

— -

apiVersion: v1

kind: Service

metadata:

name: api-svc

spec:

ports:

- port: 80

protocol: TCP

targetPort: 80

selector:

app: api

type: NodePort

To create this manifest you need to run one command kubectl create -f pod.yaml.

To watch all pod’s process deployment you can use command kubectl decribe pods <name of your pod>.

Before starting this pod you need to grant AKS access to ACR (Azure Container Registry). https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/container-registry/container-registry-auth-aks.md

So our pods are working on http, not using https. To configure SSL you need to install HTTPS ingress controller. Before installing don’t forget to deploy helm tool https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm.

Good article how to install HTTPS ingress controller here https://docs.microsoft.com/en-us/azure/aks/ingress.

The command to install ingress controller is helm install stable/nginx-ingress — set nginx-ingress.dev=false — set rbac.create=true

In article above you can find how to generate certificate and how to use it but what we need to do if we have existing certificate on your company. So, you should have file.key and file.cert. After that you need to create manifest.

apiVersion: v1
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
kind: Secret
metadata:
  name: testsecret
  namespace: default
type: Opaque

Don’t forget to apply this manifest into the kubernetes cluster.

After that you need to create ingress manifest for our routes because our microservices use different dns names and we would like to use only one IP but routing inside between microservices.

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: apidev

annotations:

kubernetes.io/ingress.class: nginx

# Add to generate certificates for this ingress

# kubernetes.io/tls-acme: ‘true’

spec:

rules:

- host: api.portal.com

http:

paths:

- backend:

serviceName: api-svc

servicePort: 80

path: /

- host: dev.portal.com

http:

paths:

- backend:

serviceName: portal

servicePort: 3001

path: /

tls:

- secretName:testsecret

More information about ingress implementation you can find here https://kubernetes.io/docs/concepts/services-networking/ingress/

Azure CLI also gives you a way to view the Kubernetes dashboard in a secure way through az aks browse command by tunnelling the connection into localhost. If you have some issues with privileges you need to create manifest.

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRoleBinding

metadata:

name: kubernetes-dashboard

labels:

k8s-app: kubernetes-dashboard

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

name: cluster-admin

subjects:

- kind: ServiceAccount

name: kubernetes-dashboard

namespace: kube-system

That is all. Happy coding :).