Pointing a Domain Name to Azure Kubernetes (AKS) with a Static IP
There are several ways to do this. I will start with the most basic way to demonstrate how this could be done and then gradually demonstrate more advanced ways. I will point a domain name to a Kubernetes service that will host multiple WordPress websites. This is a great way to learn Kubernetes, AKS, and Helm.
Note: I will be using CloudFlare for this demonstration. This is the quickest way for me to update and change my domain name’s DNS. The other benefit here is that CloudFlare can be pointed to Azure Kubernetes Service (AKS) through Terraform. I won’t demonstrate that in this tutorial but it’s good to know.
Tutorials
- Use a Static IP Address to Point
- Traefik Ingress (Coming Soon!)
Use a Static IP Address to Point (Easiest)
This seems to be a very reliable and easy way to point a domain name to an IP Address that is used by Azure Kubernetes (AKS). The benefit here is that you can create an additional IP Address (~ $3.50/month) that persists in Azure. Even if you tear down the AKS service with Terraform it can easily be re-created and set back up very easily. It’s important to know that the default inbound and outbound IP addresses are removed when a Kubernetes cluster is deleted. By creating an additional Static IP Address you can avoid this caveat. This works, however, there is a cost associated with each IP Address and that can get rather costly.
General Flow
I will point the domain name milsim.org to an Azure Kubernetes Service (AKS).
CloudFlare -> Azure Static IP Address -> Load Balancer (AKS) -> Kubernetes Service
Step 1: Create Public Static IP Address
Assuming you already have a Kubernetes cluster you will need to create a Static IP Address in the Standard SKU.
This resulted in a Public Static IP Address being created with the IP: 20.59.192.19
Step 2: Point CloudFlare to Static IP Address
This could be at any DNS registrar but I will use CloudFlare for this example. All I’m doing is pointing an “A” record to the newly created IP address.
Step 3: Grant Kubernetes Service Principal Access to Load Balancer
You will need to first get the guid of the service principal and then grant it Network Contributor access. What this actually does is allows the AKS cluster to create “Frontend IP Configurations”, “Health Probes”, and “Load Balancing Rules”.
Get Service Principal of Azure Kubernetes Service (AKS)
The service principal Client ID will be a guid that you can use when granting appropriate access.
|
1 |
az aks show --name (kubernetes-cluster-name) --resource-group www --query servicePrincipalProfile.clientId -o tsv |
Grant “Network Contributor” Access to Azure Kubernetes (AKS)
|
1 2 3 4 |
az role assignment create \ --assignee (guid) \ --role "Network Contributor" \ --scope /subscriptions/(subscription id)/resourceGroups/(resource group - "www") |
Step 4: Verify Load Balancer
With Network Contributor access, AKS will create “Frontend IP Configurations”, “Health Probes”, and “Load Balancing Rules” in the Load Balancer. It’s important to verify that this is there.
Frontend IP Configuration
Health Probes
Load Balancing Rule
Step 5: Pod Annotations
I have the standard Bitnami/WordPress Helm charts locally on my machine. There is already a namespace that I created called “www” in Kubernetes. Basically, that’s where all of the WordPress websites will be installed.
WARNING: I’m not going to follow best practices here. Annotations can be passed in through a value in the values.yaml file. However, I want to make sure it’s clear how this works, so I’m going to use some hackery so it’s easier to learn. If you read more into the values.yaml and look at the options it’s very clear what should be done. The loadBalancerIP specification value should be passed in on a variable in values.yaml and could also be included in a Continous Integration (CI) pipeline.
Verifying Templates with Helm
I will need to modify the svc.yaml file in the WordPress charts. I can point an IP address to this Kubernetes service through annotations and specifications.
Annotation
This annotation tells Kubernetes which resource group to use.
service.beta.kubernetes.io/azure-load-balancer-resource-group: www
Specification
This specifies the exact IP address that will be used which happens to be our newly creates Public Static IP Address.
loadBalancerIP: 20.59.192.19
Verifying Helm Templates
Before deploying I recommend running the helm template command to verify that this builds and outputs the correct Kubernetes manifestation. A co-worker once said, “Inspect what you expect.”.
helm template milsimorg .\wp-milsimorg\ -n www
Install Helm Charts
At this point we can install the helm chart. My helm chart is in the “wp-milsimorg” folder and my helm installation is called “milsimorg”.
helm install milsimorg .\wp-milsimorg\ -n www
Step 5: Verify
As you can see below, the Load Balancer was capable of creating the service with the external IP address.
kubectl get all -n www
