Containers

Cloud and containers, two buzzwords of the IT world put together. What can go wrong? This post is a refresh on a previous one (https://cloudinthealps.mandin.net/2017/03/24/containers-azure-and-servicefabric/) with a focus on containers, rather than the other micro-services architectures. As usual, I’ll speak mainly of the solutions provided by Microsoft Azure, but they usually have an equivalent within Google Cloud Platform or Amazon Web Services, and probably other more boutique providers. And let’s be more specific, considering what happened in the container orchestrator world in the recent weeks. I am of the general opinion that this war is already over, and Kubernetes has won. Let’s focus on how to run/use/execute a Kubernetes cluster. First step : you want to try out Kubernetes on your own. The ideal starter pack would be called Minikube ( https://github.com/kubernetes/minikube) . I already wrote about it, the good thing about it is that you can run a Kubernetes installation on your laptop, in a few minutes. No need to worry about setting up any cluster and configurations you do not understand at all. You might want to play out a bit with Kubernetes the hard way, in order to be able to understand the underlying components. But that is not necessary if you only want to focus on the running pods themselves. Now you are ready to run a production workload Kubernetes Cluster. And you would like to handle everything on your own. There are many ways to get there. First, you want to deploy your own cluster, not manually but on your own terms. There is a solution, kubeadm (https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/), that will help you along the way, without having to do everything by hand. This is a solution that is compatible with any underlying hardware, cloud, virtual or physical. On Azure specifically, there are two concurrent solutions to build your Kubernetes cluster : ACS (https://azure.microsoft.com/en-us/services/container-service/) & ACS-engine ( https://github.com/Azure/acs-engine). ACS (Azure Container Service) is mostly a deployment assistant, that will ask you the relevant questions on your K8s deployment, and then create and launch the corresponding ARM template. After that, you’re on your own. And you may download the template, edit it and re-use it anytime you want! ACS-Engine is a command line customizable version of ACS, with more power to it :) I feel that both are Azure dedicated versions of Kubeadm, but they do not add value to your production. They still are good ways to quickly deploy your tailored cluster! BTW, if you go to the official webpage for ACS, it now just speaks about AKS, and you’ll have to dig a bit deeper to find out about the other orchestrators ;) What if you could have your K8s cluster, be able to run your containers, and just have to manage the clustering and workload details? There is a brilliant solution called AKS (https://azure.microsoft.com/en-us/services/containerservice/) , and no it does not stand for Azure K8S Service… It actually means Azure Container Service. Don’t ask. With that solution you just have to take care of your worker nodes, and the running workloads. Azure will manage the control plane for you. Nothing to do on the etcd & control nodes. Cherry on the top : you only pay for the IaaS cost of the worker nodes, the rest is free! In my opinion, it’s the best solution today, it offers you a wide flexibility and control on your cluster, at a very low cost, and lets you focus on what is important : running your containers. One last contestant to join the ring : Azure Container Instances (https://azure.microsoft.com/en-us/services/containerinstances/). This solution is still in Preview, but might become a strong player soon. The idea is that you just care about running your container, and nothing else. For now it is a plugin for an actual K8S cluster, that will present itself as a dedicated worker node, where you can force a pod to run. I did not have time to fully test the solution and see where the limits and constraints are, but we’ll probably hear from this team again soon.

This week, I had my first troubles with GitHub while trying to push all the updates I did to “Kubernetes, the hard way” to use Azure. Long story short, I did have to ditch everything I did write for the new guide, and start over, as there were too many new commits from Kelsey’s guide. This misadventure pushed me to do several things : Create and maintain my own fork of Kelsey’s guide : https://github.com/frederimandin/kubernetes-the-hard-way Rewrite this guide, and make it work on Azure Use Visual Studio Code, with the GitHub and Markdown plugins. As it was also a first… some pain was involved. Go several steps beyond, in order to play a bit more with K8S The first two steps are done and commited, as you may see on GitHub. It did take a smaller amount of work than expected, as most of the commands I wrote for the previous guide were still usable. I did have to redeploy the test K8S cluster to confirm that everything was fine. Please, if you have some spare time, do not hesitate to use this guide, and give me some feedback! Then I tried several test, in addition to the ones included in the guide. First I deployed a container from the Docker public Registry : https://hub.docker.com/r/apurvajo/mariohtml5/ This went quite well, and I had the infinite mario running for several hours, and accessible from the outside world on its own port. At that point I got lost… I started to update this blog, and realized that the website was not using HTTPS. I figured now would be good time to do it, and I thought about using Let’s Encrypt (https://letsencrypt.org). As it was my first time, it took me a while to find out what to do exactly. Actually, the easiest way was to just activate the extension for the web app on Azure, and follow the guide. We are now securely discussing on https://cloudinthealps.mandin.net :) That was fun, but I still have not started to play with Helm (https://www.helm.sh), which was the original idea. Ill have to postpone that activity and blog about it later!

Following my recent ventures in the Kubernetes world (http://cloudinthealps.mandin.net/2017/08/23/kubernetes-thehard-way-azcli-style/), I now had a functional Kubernetes cluster, on Azure, built with my own sweat and brain. But that was not the original goal. The original goal was to try and play with Azure Container Instances, and its Kubernetes connector https://azure.microsoft.com/fr-fr/resources/videos/using-kubernetes-with-azure-containerinstances/ Following the guide on GitHub was relatively straightforward and painless (https://github.com/Azure/aci-connectork8s), but I encountered two small issues. One was that I am not completely comfortable yet with all things K8s, and I had to read a bit about taints, to understand why the current ACI connector is not used by the K8s scheduler by default. Not a big deal, and a good way to get to know more about K8s. The second one was maybe due to the fact that I had never used ACI before, maybe not. I logged it into the GitHub project as an issue (https://github.com/Azure/aci-connector-k8s/issues/33) to make sure that it is taken into consideration. Short story was that I was missing a registered Provider in my subscription. However the error message did not pop up in kubectl output, but only on the Activity log in Azure portal. Another good occasion to learn an dig into some tools.

Finally a tech post! I have been busy this week, on command lines and Kubernetes. The starting point was the recent announce for Azure Container Instances and the related Kubernetes conenctor : https://github.com/azure/aci-connector-k8s I admit I did try what Corey Sanders showed in his show : https://channel9.msdn.com/Shows/Tuesdays-WithCorey/Tuesdays-with-Corey-Azure-Container-Instances-with-WINDOWS-containers. However what I found interesting and wanted to try was the ACI connecter to Kubernetes, and how we would work with that. Of course we have a test Kubernetes cluster here, that someone from our tema built, but it felt too easy just to add the connector. Also I am not comfortable yet with Kubernetes and I wanted to get my hands dirty and know more about the inner workings of a k8s cluster. I remembered a quote from the Geek Whisperers’ show featuring Kelsey Hightower. He said that he wrote a guide to build a K8s cluster from the ground up, without any shortcuts. The guide is found there : https://github.com/kelseyhightower/kubernetes-the-hard-way The downside is that the guide is aimed at Google Cloud Platform, and I am an Azure guy. And there was my pet project for this week : adapt the guide for Azure, using only Azure CLI commands! There was one final trick for me to learn : store and share all that on GitHub. As I never had to work with Git by myself, it was also a good way to learn the moves. So, lots of new stuff learnt : • Create a K8s cluster from scratch • GitHub, and Git • Making progress on Azure CLI • A good refresh and Azure infrastructure The project is hosted there : https://github.com/frederimandin/Kubernetes-the-azcli-way There are many following steps to work on : • Integrating properly with Kelsey’s guide • Testing my own guide again • Adding ACI connector to my cluster and play with it (and write about it of course!) I’ll keep you posted, of course!

Today I will try to gather some explanations about containers, how they are implemented or used on Azure, and how this all relates to micro-services and Azure Service Fabric. First let’s share some basic knowledge and definitions. Containers in a nutshell To make a very long story short, a container is a higher level virtual machine. You just pack your application and its dependencies in it, and let it run. The good thing about those is that you do not have to pack the whole underlying OS in there. This gives us lightweight packages, which could be around 50MB for a web server for example. Originally, containers were designed to be stateless. You were supposed to keep permanent data out of those, and be able to spin out as many instances of your applications to run in parallel, without having to bother about data. This is not completely true about most deployments. Today many containers are used as lightweight virtual machines, to run multiple identical services, each with its instance. For example, if you need a monitoring poller for each new customer you have, you might package this in a container and run one instance for each client, where you just have to configure the specifics for this client. It’s simple, modular and quick. The stateless versus stateful containers is a long standing one, see [link to statefull vs stateless] Orchestration Just like in virtualization, the case is mostly not about the container technology and limits, but rather about the tools to orchestrate that. Vmware vCenter versus Microsoft SCVMM anyone? You may run containers manually above Linux or Windows, with some limitations, but the point is not to have a single OS instance running several services. The point is to have a framework where you can integrate that container and instantiate it without having to tinker with all the details : high-availability, load-balancing, registration into a catalog/registry etc. The video below is very good at explaining that : The Illustrated Children’s Guide to Kubernetes ...