Kubernetes

Kubernetes Pod Allocation in a Multi-OS Cluster

Kubernetes Pod Allocation in a Multi-OS Cluster

This week we saw the announcement of the public preview of Windows Server Containers on Azure Kubernetes Service (AKS). Windows support in AKS has been something we’ve been waiting for, for a while now and is excellent news for those trying to lift and shift Windows applications into containers. As we’ve discussed previously, if you can, using Linux containers is always going to give you the fastest start-up time and fewer complications, however not everyone can re-write their apps in .
Locking Down Application Access in AKS

Locking Down Application Access in AKS

When you deploy a service in AKS that is of type load balancer, or you create an Ingress, AKS will automatically create an NSG rule for you . This rule is applied to the NSG that is attached to your nodes NICs and will open up your services port to “All”. If your planning on publishing your application to be accessed by anyone then this is fine. However, if you want to lock access to your application down to specific users then this can be a bit of a pain.
Use Azure Monitor Metrics in Kubernetes with Prometheus and Promitor

Use Azure Monitor Metrics in Kubernetes with Prometheus and Promitor

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.
Using Managed Identity with Kubernetes in Azure

Using Managed Identity with Kubernetes in Azure

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.
Access Azure Key Vault from your Kubernetes Pods

Access Azure Key Vault from your Kubernetes Pods

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).