aks

Last year I wrote a post about Enabling NAP with Terraform. While the post is still valid, I wanted to write about an scenario that many of you might be facing: Enabling NAP when bringing your own VNET. So let’s learn how to create an AKS cluster and enable Node Autoprovisioning (NAP) with Terraform when bringing your own VNET.

Let’s learn how to create an AKS cluster and enable Static Egress Gateway with Terraform. Static Egress Gateway in AKS provides a solution for configuring fixed source IP addresses for outbound traffic from your AKS workloads. This means you can use a specific range for egress traffic from specific workloads, whcih can be useful for scenarios like whitelisting IP addresses in a firewall.

Let’s learn how to create an AKS cluster and enable Node Autoprovisioning (NAP) with Terraform. Note: Since at the time of writing NAP is a preview feature, we will use the azapi provider to enable it. Creating an AKS cluster and enable Node Autoprovisioning (NAP) # Create a file called main.tf with the following contents:

Azure Kubernetes Service (AKS) Automatic is a new SKU that simplifies the management of your AKS clusters. With this SKU, Azure ensures that your cluster is production ready with built-in best practice and a great code to kubernetes experience. Creating an AKS Automatic cluster # Creating an AKS cluster with the Automatic SKU is as simple as running the following Azure CLI command:

In this post I’ll show you how to setup Workload Identity in an AKS cluster using terraform and then deploy a pod with Azure CLI that you will use to login to Azure. Long story short: once workload identity is configured and enabled, kubernetes will inject 3 environment variables needed to login with Azure CLI:

When you deploy an Azure Kubernetes Service with a node pool composed by spot virtual machines, you are running a cluster with the risk of losing nodes based on the configuration you set. Eviction may occur based on capacity or max price. In this post I’ll show you how to deploy an AKS cluster with such configuration and simulate a node eviction. The exercise will help you understand the resiliency of your solution and how to query related events with log analytics.

When deploying an AKS cluster, even if you configure RBAC or AAD integration, local accounts will be enabled by default. This means that, given the right set of permitions, a user will be able to run the az get-credentials command with the --admin flag which will give you a non-audtibale access to the cluster.

If you deployed a private volume claim using the managed-premium storage class, then ran out of space and now you are searching how to expand the disk to a larger disk, this is how you can do it from scratch: manage-premium storage class is a premium storage class that allows volume expansion: allowVolumeExpansion: true.

In my previous post AKS: Open Service Mesh & mTLS, I described how to deploy an AKS cluster with Open Service Mesh enabled, and how: Easy is to onboard applications onto the mesh by enabling automatic sidecar injection of Envoy proxy. OSM enables secure service to service communication. This time I’ll show you that Open Service Mesh (OSM) also provides a nice feature for controlling traffic between microservices: Traffic Access Control based on the SMI specifications.

Open Service Mesh (OSM) is a lightweight and extensible cloud native service mesh, easy to install and configure and with features as mTLS to secure your microservice environments. Now that Open Service Mesh (OSM) integration with Azure Kubernetes Service (AKS) is GA (Check the announcement) I’ll show you not only to deploy it but also how to add your microservices to the mesh so communication between them is encrypted.

Disclaimer: this is just a Proof of Concept. If you deploy Azure Kubernetes Service clusters with availability zones, you’ll probaly need a high available storage solution. In such situation you may use Azure Files as an external storage solution. But what if you need something that performs better? Or something running inside your cluster?

Today I’ll show you how to use Container Insights and Azure Monitor to check your AKS cluster for pods without requests and limits. You’ll need to use the following tables and fields: KubePodInventory: Table that stores kubernetes cluster’s Pod & container information ClusterName: ID of the kubernetes cluster from which the event was sourced Computer: Computer/node name in the cluster that has this pod/container. Namespace: Kubernetes Namespace for the pod/container ContainerName:This is in poduid/containername format. Perf: Performance counters from Windows and Linux agents that provide insight into the performance of hardware components operating systems and applications. ObjectName: Name of the performance object. CounterName: Name of the performance counter. CounterValue: The value of the counter And take a close look at the following Objects and Counters:

This post will show you the steps you’ll have to take to deploy an Azure Files Storage with a Private Endpoint and use it to create volumes for an Azure Kubernetes Service cluster: Create a bicep file to declare the Azure resources # You’ll have to declare the following resources:

When configuring Azure Kubernetes Service with Azure Container Network Interface (CNI), every pod gets an IP address of the subnet you’ve configured. So how do you plan you address space? What factors should you consider? Each node consumes one IP. Each pod consumes one IP. Each internal LoadBalancer Service you anticipate consumes one IP. Azure reserves 5 IP addresses within each subnet. The Max pods per node is 250. The Max pods per nodes lower limit is 10. 30 pods is the minimum per cluster. Max nodes per cluster is 1000. When a cluster is upgraded a new node is added as part of the process which requires a minimum of one additional block of IP addresses to be available. Your node count is then n + 1. When you scale a cluster an additional node is added. Your node count is then n + number-of-additional-scaled-nodes-you-anticipate + 1. With all that in mind the formula to calculate the number of IPs required for your cluster should look like this:

This morning I saw this tweet from Mr Brendan Burns: AKS Cost Monitoring and Governance With Kubecost https://t.co/OStwIBsuPp — brendandburns (@brendandburns) April 30, 2021 And I’m sure that once you also read through it, you’ll learn that you have to take several steps in order to achieve AKS Cost Monitoring and Governance With Kubecost.

a couple of weeks ago I was trying to deploy MongoDB in AKS using the MongoDB Enterprise Operator and had trouble finding a simple tutorial to make the thing work. This post intends to fill that gap with a straight to the point approach. Prerequisites # Be sure to deploy AKS with a set of nodes with at least 8GB of RAM. I used Standard_D3_v2

What if I tell you that it’s possible to connect you AKS pods to an Azure Key Vault using identities but without having to use credentials in an explicit way? Well with AAD Pod Identities you can enable your Kubernetes applications to access Azure cloud resources securely using Azure Active Directory (AAD) including Azure Key Vault.

Durante el mes de Octubre tuve la suerte de grabar en LinkedIn Learning mi primer curso online sobre Kubernetes. Aun me queda mucho por aprender y mejorar en este formato, ya que mientras grabas los cursos no recibes feedback inmediato como sí ocurre cuando das una charla o haces una presentación.

Recently I learned about GitOps which is a way to manage your Kubernetes clusters and the applications you run on top using Git. The idea is that you can declaratively describe the desired state of your systems in Git and roll out changes as soon as merges occur. You can immediately see the main benefits of such an approach: Your Git repositories become the single source of truth for both your infrastructure and application code, allowing the teams to increase productivity and stability (you get the Git log to audit changes).

Two weeks ago I got an email message from Microsoft Azure explaining that Azure Kubernetes Services had been patched but that I had to restart my nodes (reboot the clusters) to complete the operation. The first thing you need to know is that, when things like this happens, the Azure platform creates a file called /var/run/reboot-required in each of the nodes of your cluster.