technicallysavvy-blog

[technicallysavvy-blog]

Sample K8s ARM Templates for Infrastructure as Code (IaC) Deployments

I recently rolled off of a customer engagement where I generated a lot of sample infrastructure as code ARM Templates for Kubernetes clusters in Azure (a.k.a. AKS, which is short for Azure Kubernetes Service). These templates mixed in the AKS clusters with networking resources that fall underneath the PaaS side of things (namely Application Gateways and API Management Gateways). Ultimately it was a bit of a learning curve even for me, who has become fairly proficient in cranking out ARM Templates. Some of the feats I had to overcome are as follows: I had to figure out how to pass a SSL cert to an Application Gateway, I had to figure out how to stand up an echo service within a Kubernetes cluster using an internal NGINX ingress controller so the Application Gateway would pass traffic, and how to build an API Management Gateway with the right health check API + health check probe to successfully pass traffic. The easiest thing to do next will be to examine all the code that I've presented to the customer as example code: Reference Architecture with ARM Templates - Azure Kubernetes Service The code itself is outlined in the following way (folder by folder - note the ReadMe's go into this detail as well): 1) setup folder - walks how to set up a local environment (or the Azure Cloud Shell) with PowerShell, the Azure CLI, the Kubernetes CLI, the Helm CLI, enabling Windows Subsystem for Linux (if required), and how to generate a Service Principal for RBAC permissioning on the cluster. 2) keyVault folder - walks through how to set up a Key Vault via code, plus input secrets into the Key Vault for retrieval during the ARM Templates. Using Key Vault means your passwords are never stored in the code you generate, which is a must for all of us in this software defined world. 3) k8s folder - this folder sets up a K8s cluster on Azure using your Service Principal Key Vault secreted password, has the K8s cluster report to an existing Log Analytics workspace, and walks you through how to set up an internal ingress controller. All of this can be adjusted to fit your deployment needs, meaning you can add more pods, increase the node size, etc. 4) appGw folder - this folder sets up a K8s cluster the same way as the k8s folder template files and adds an Application Gateway into the mix. I will call out the specifics for this folder down below related to what I learned over the course of deploying a cluster behind an Application Gateway. 5) apim-appGw folder - this folder sets up a K8s cluster the same way as the k8s folder template files and adds an Application Gateway + API Management Gateway in front of the cluster. Like with the Application Gateway folder, I'll call out specifics for this deployment down below. From there, I wanted to call out the few learnings here in greater detail: 1) Application Gateways require .pfx certs, which in turn require a password. After stumbling through various different deployments using .pem, .cer, etc. for certificate file formats, I found a short sentence on Stack Overflow (that I can't find now), which stated Application Gateways need .pfx certs. Ultimately that makes sense to me, given .pfx certs are used for public and private encryption in most deployments I've supported in former roles. I still wound up getting an error about the password and it being incorrectly being passed whenever I'd try to deploy the Application Gateway. I then did a lot of reading in tech forums and noticed someone tried a deployment where they passed the password through as a regular string (not secure string). I plugged that into my Application Gateway ARM Templates and that worked for each deployment going forward. The password is still not stored in code, it's listed in Key Vault, and passed through as a regular string during the time of deployment. That's not called out too clearly, so hopefully that saves someone some cycles in the future. 2) In order for the Application Gateway's backend health to report healthy using just the K8s cluster, an echo service needed to be deployed on a pod within the cluster. From there, I created a custom probe for the echo API service. I stumbled across the internal NGINX GitHub and altered the following yaml service file to fit my needs: Echo API Service - NGINX The basic gist, is I took out the authorization components of the echo API service yaml definition. Surprisingly, that worked for purposes of standing up baseline K8s infrastructure where all requests hitting the Application Gateway will be sent to the internal ingress controller based upon the rules I configured for this specific deployment. So at the end of this deployment, you will have a 3 node K8s cluster, 1 pod with the echo API service, an internal ingress controller, an Application Gateway, and custom probes that point to the echo API service on the K8s cluster. 3) For the API Management Gateway, I configured a health check API service on the gateway and pointed the Application Gateway to the health check with a custom probe. Note, there are a few things in public preview at the moment related to WAF, Managed Identities for AKS, and making the WAF your internal ingress controller. Since my customer needed a production ready solution, this sample code is current as of July 2019 (and will probably get some revisions as time unfolds). I also anticipate going into detail about the Application Gateway and APIM deployments in a future blog post. For now, bookmark this blog post, clone/save the repo, and give it a whirl!

#kubernetes azurekubernetesservice aks k8s appgateway apimanagement azure

[technicallysavvy-blog]

Greetings!

Hello and welcome! My name is Shannon Kuehn and I'm currently a Cloud Solution Architect (CSA) at Microsoft. I pinch myself daily while performing my regular job duties working with customers, as I work for one of the largest and most prosperous tech firms in the world. My main focus surrounds making sure Azure is successfully adopted by companies embarking upon large scale digital transformations. The cloud has caused a serious disruption in the way customers conduct IT operations, so CSAs act as a guide and trusted advisor. I fall within the apps and infrastructure space and have been finding myself dealing with lines and lines of code, now that we are all working in a software defined world. If you were to have approached me about 10 years ago, told me people would be trusting and migrating to the cloud, plus I would be working AT Microsoft, I would not have believed you. I love how my role has evolved over the past 13+ years, along with the ways I have had opportunities to reinvent myself plus my skillset. The cloud is limitless and Azure is my cloud of choice. The goal of this blog will be to help readers out with making sense of the cloud. The rate of change is tough to stay ahead of (even for me), so I hope I can explain, document, and expand your wealth of knowledge on how to interact with Azure so it can ALSO be YOUR cloud of choice!

#azure cloudsolutionarchitect microsoft cloud