I was a big fan of ARM templates: for many years I’m applying ARM templates on a large number of projects for all kinds of customers. I’ve written articles and blog posts about ARM templates. Have given many workshops and started collecting ARM templates used in enterprises ready for production. I’ve written the Best practices with ARM Templates article together with my colleague Peter Groenewegen, which is the most visited blog post of Xpirit and it’s also published by Microsoft. It’s clear I was a big fan of ARM templates. But times are changing.
New releases of Kubernetes follow each other in rapid succession. Azure must support the version of Kubernetes in order to also offer it with AKS.
I would like to know when a new version of Kubernetes will be supported in AKS. This can be checked manually with the Azure CLI. However, I do not want to do this manually every now and then. That’s why I automated the process that checks the latest version of Kubernetes in AKS. The process tweets a message when a new version has been released. In addition, the process also notifies via twitter when a new location in Azure supports AKS. The proces is automated by serverless resources in Azure: with an Azure Function and an Azure Logic app. The twitter account @azureaksupdates notifies about the latest version and latest locations of AKS.
AKS supports RBAC since its General Available.
After visiting the Dashboard of Kubernetes in AKS you will get warnings because the user visiting the dashboard does not have enough rights. This post tells you how to solve this. But let’s create a RBAC enabled cluster first.
Many applications hosted in a Docker container need a volume to store data on or to read from. The data can’t be stored in the Docker container itself because the data will be lost after a restart or when the container crashes. Persistent Storage has an independent lifecycle of a Pod. This blogposts shows the most used possibilities to use persistent storage using Kubernetes on Azure.
This blogpost was not possible without the help of Andreas Lindeboom, my Xebia colleague of XITA. Thanks!
In case of problems with a node of a Kubernetes cluster you probably want to read the logfiles on a Node of the Kubernetes Cluster, as described here. This Kubernetes cluster is created with Azure Container Service (ACS).
You have developed a microservice in .NET Core 2 and want to host it as a Docker Container in Kubernetes. Your Microservice contains settings, some appsettings or connectionstrings for example. These settings differ over environments. You can treat this configuration for Kubernetes on different ways. This blogposts shows you how to handle settings over environments prepared for Continuous Delivery.
When using multiple Kubernetes clusters on Azure Container Service, I see people executing the az acs kubernetes get-credentials command every time they need to reconnect to a different cluster. This works, but is not needed. You can do it easier.