Kubernetes

Si vous voulez déployer vos applications et services dans un cloud public, vers qui allez-vous vous tourner? Très probablement vers l’un des 3 acteurs majeurs au niveau planétaire. Votre choix se fera sûrement pour des raisons politiques plus que techniques ou financières. Je dédierais sûrement un article à ces choix ultérieurement. Le fait est que pour déployer une nouvelle application dans le cloud, le choix est finalement assez simple. En premier vous avez la solution déjà indiquée : un des mastodontes américains. Problème, vous ne voulez pas forcément donner vos données, vos applications et votre argent à une multinationale, quelle que soit sa position vis-à-vis des questions éthiques et légales. Et dans un climat de défiance envers la globalisation, et une tendance à la relocalisation, il semble un peu hypocrite de s’appuyer sur eux. ...

Almost a sponsored post today, or better : a shared announcement. You probably know that I am following Kubernetes rather closely, especially managed Kubernetes services (AKS, EKS or Openshift for example). One domain where these offerings have been lacking is network and security. It is still a very sensitive subject for our customers, for containers related project, and still for public cloud projects. Security and networking teams have trouble adapting to the public cloud paradigms and architectures. There some fear of loss of control, some base fear of the unknown, and some real worry about how to handle networking and security. Kubernetes (and the other orchestrators) adds another abstraction layer on top of the existing public cloud platforms, which does nothing to alleviate fear, to say nothing about complexity and transparency. There are some very good solutions out there to manage network overlays into Kubernetes. My favourite is Calico, but you may like any of those. I’ll stick with Calico for a simple reason, which you will see below. Microsoft and AWS are both working hard to provide a network overlay into their managed Kubernetes offering. They each chose their own path, but we will get to approximately the same point in a short time. Thanks to Jean Poizat, we have the two announcements. ...

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!