Prometheus has become the default metrics collection mechanism for use in a Kubernetes cluster, providing a way to collect the time series metrics for your pods, nodes and clusters. This metric collection allows you to monitor for issues, review performance over time, and also provide metrics to be used by the scaling functionality in Kubernetes. Both the Pod and Cluster auto-scaler can take custom metrics from Prometheus and use these to determine if they can scale out.
If your application is running on a Kubernetes cluster in Azure (AKS, ACS or ACS Engine), then it is likely that you will need to access other Azure resources from your pods that are secured with Azure AD. These operations could include retrieving secrets from Key Vault, files from Blob storage or just interacting with other applications or API’s that use Azure AD as their identity provider. To be able to do this your application needs to be able to provide an identity to access these resources securely.
In any application it is likely you are going to need access to some “secret” data, connection strings, API keys, passwords etc. It is essential that the applications that need them can access these secrets, but that they are also kept secure. One way of doing this is using Azure Keyvault; this is a secure store which can hold secrets, keys and certificates and allow applications to access them securely. Generally, Keyvault Secrets are accessed by the application making a call to the KeyVault API and providing the appropriate credentials (username/password, certificate or managed service identity).
I’ve been making fairly heavy use of Kubernetes on Azure of late, and this has been mostly done using ACS Engine to create the clusters. I need to make use of Windows clusters which is not supported in the AKS PaaS service, so I need to create a custom cluster using ACS-Engine. For those who don’t know, ACS engine is an open source tool, created by Microsoft, that helps generate ARM templates to deploy customer Kubernetes clusters in Azure.
The Open Service Broker API (OSB) project is an industry initiative to create an open, simple and generic way of creating services that can be consumed by cloud-native platforms like Kubernetes, Openshift and so on. Microsoft have released a preview of the Open Service Broker for Azure, which we are going to explore more in this article. First though, let’s understand what OSB and the broker for Azure actually gives us.
Earlier this month at Build Microsoft announced a new feature for ARM templates, the Terraform Resource Provider. If you’re not familiar with Terraform, it’s a way to define cloud infrastructure declaratively much like ARM templates, but one of its big benefits is that it works across cloud providers. If you’re interested in learning more about Terraform in Azure then take a look at my comparison of Terraform vs ARM templates. I’ve had access to the preview of this new feature for ARM templates and wanted to share my experience.
If your looking to run Kubernetes in Azure then the Azure Kubernetes Service is what you’ll generally be looking at, it offers a semi-managed solution with PaaS based management nodes and is by far the simplest and easiest Kubernetes service to use in Azure. If AKS meets all your needs, then no need to read any further, but for some use cases, it may not. AKS is a new service, it’s not gone GA quite yet, and it is still missing some features like the ability to run Windows Containers, support for certain versions of Kubernetes, or maybe you don’t want to run Kubernetes at all and want Swarm or Mesos.