In the past few weeks, I’ve been doing some work on deploying Kubernetes clusters using Azure Container Service Engine aka acs-engine so I thought this might be a great topic to do a multiple parts blog series.
Before diving in, I would like to share credits with my fellow architects Yaron Schneider, Idan Shahar and Itay Shakury who has been doing great work in contributing to the knowledge I will be sharing.
Now, everyone knows I am a big fan of multiple parts deep dive blog series and this time it’s no different. In this series I will be sharing some insights and will be talking about the following topics:
- Why using acs-engine and what are the alternatives in Azure.
- Set up a working acs-engine environment
- Basic K8s cluster deployment.
- Deploying a cluster in a custom VNet and managed disks.
- Deploying a cluster with both Linux and Windows Kubernetes agents.
What is acs-engine?
acs-engine is a Microsoft open source project designed to deploy Docker enabled clusters on top of Azure using the Azure Resource Manager (ARM) API. We are not talking only about Kubernetes here, DC/OS and Swarm can also be deployed but in this series, I will be focusing on K8s deployment.
This series objective is to make the info that is already available in the GitHub repository a bit more approachable. I will be sharing some screenshots, point to specific things to watch for and will try to be “laser focus” as much as possible. I do recommend you dig into the repository as it includes a lot of deployment examples, some of them will be used throughout this series.
The way acs-engine works is pretty straightforward. The input to acs-engine is a cluster definition file (JSON) which describes the desired cluster, including orchestrator, features, and agents. acs-engine will then generate an ARM template (also JSON based) which will be used to deploy the cluster in Azure.
This all sounds very complex, why should I use it?
Let me start by saying this is not complex at all! When I started to use acs-engine, my first thought was “what the hell is that?!” but after playing with it for few days it all became very clear.
So, with that being said, I think the way to answer the question of why using it depends on your requirements and/or constraints. For example, if you need to deploy your cluster into an existing Azure VNet this is the only way to do it. Another example will be deploying the cluster with a specific version. Fear not as we will get to all of this things and some more later on in this series.
Currently, there are 2 valid alternatives for deploying container orchestration clusters in Azure with the first one being good old Azure Container Services (ACS). This deployment model will allow you to deploy any cluster you want (K8s, DC/OS or Docker Swarm) without too much fuss.
On the other side, if you need a specific cluster version, deploy inside a custom VNet or maybe some other customization, you are pretty limited here.
The second option (currently in preview), which is a new one in Azure and is only relevant to Kubernetes is Azure Container Service (AKS). Yeah I know it’s confusing but the “K” here represent Kubernetes. Anyway, this is the newest option for deploying K8s cluster in Azure and it is a fully managed one. You deploy the cluster and from there you do nothing when it comes to maintaining it as Microsoft will do everything for you.
Like with ACS and by the time of writing this post, there are some things you cannot do like deploying into a custom VNet or deploying Windows-based K8s agents pools.
Since this series will not focus on ACS nor AKS, here are some useful links to get you started with those:
In the next post for this series, I will show you what you need in order to prepare your working environment in order to start working with acs-engine.