We are using Kubernetes as the container orchestrator. Deployments to Kubernetes is done using a .yml-file which describes the desired environment. When we are deploying from Azure DevOps, we deploy all services, and Kubernetes will figure out which ones that changed, e.g. a new image or more replicas.

Basic Terminology

Our Kubernetes setup uses pods, deployments, ingresses and services.

Pods

Pods are where our container is hosted. The number of replicas defined in the configuration corresponds to the instances of pods currently running.

Services

Since there can be a variable number of pods for each container, we need some way to a) connect to other pods in our cluster from a second pod, and b) expose some of our pods outside of the cluster. We use services to accomplish both of these tasks. When we define a service, we create an internal hostname with which a service can connect to a collection of pods. Think of it as a load balancer for all instances of a specific service. This uses the default service type ClusterIP.

To expose a service out of our container, we go through an Ingress.

Ingresses

An ingress is an application gateway that sits in front of internal services and routes traffic to them based on some rules.

Deployments

A deployment is used to describe the desired state of the system. Our config is using deployments to instantiate pods and services. If a pod crashes, the deployment will take care of creating a new one so the desired state is always fulfilled.

Setting up Kubernetes with Azure Devops

This guide is an excellent starting point that describes the whole process. The gist is that we define an .yml-file that references all our container images. We create a release pipeline that uses artifacts from each service as input, and replaces tokens in the .yml-file with environment variables from the input artifacts. We are taking this a step further and using Helm (a Kubernetes package manager) to describe our environment.

Note: The replace tokens-task we are using is a task from the marketplace, so the person setting up Azure DevOps must be allowed to install plugins.

The end result is a Helm chart that describes the whole infrastructure and where to find the container images. The release pipeline will also take care of updating Kubernetes' connection to our private docker repository.

Api Management

We are not exposing our ingress out of the Kubernetes cluster. We have created an Azure Api Management Service in the same v-net as the cluster and used Azure-specific annotation on the ingress to create an internally available ip for the ingress. Api Management can then route requests to this internal ip. This guide describes how to set up Api Management, although they are connecting directly to a single machine's ip. We are connecting to an internal ingress LoadBalancer. See Azure-Api-Management for more information about setting it up.