My goal for today is installing a simple Hybrid Kubernetes cluster on Microsoft Azure with:
This is something that can’t be accomplished out of the box with the current version of Azure Container Services, but yesterday Brendan Burns confirmed they are working on it!
So how can we install this cluster right now? The answer is ACS-Engine an Open Source project from Microsoft that takes a “cluster definition” in input and returns an ARM template with additional artifacts (i.e. kubectl export files) as output. I advise you to read Part 1 and Part 2 before continuing.
To make thing easier, I’ll reuse some of the artifacts created in Part 1 and Part 2.
acs to store all your working artifactsgit clone https://github.com/Azure/acs-enginecd acs-engine/examples where you can find many cluster definition examples. Here you can see a windows folder, it contains the definition needed: kubernetes-hybrid.jsonImportant note: There is an issue with the current release 0.5.0 that leads to examples in source code not being compatible with it (they are more updated). Here we have 2 solutions:
We will choose the complex one! Joking… I followed the complex but it’s not trivial on macOS at the moment, because you need to clone acs-engine source in $GOPATH/src and needs a separate article on its own. So let’s go for the easy solution.
kubernets-hybrid.json file in your favorite editor and change lines belowfrom:
to:
Wait don’t close the file! We want to use latest Kubernetes version in our cluster right? So add line in bold:
Now we can follow steps in Deploy a Kubernetes Cluster that describes a shortand long way to deploy your cluster.
Here we will follow the short way but before starting I want to highlight some drawbacks here:
Solution 1: We can avoid all these drawbacks creating artifacts once (application, SSH key pair, DNS) and adding their value in template json file used for deployment. I will do this for SSH.
Solution 2: At the end of the first deploy, acs-engine generates a _output folder with generated artifacts. Here there is a file called azuredeploy.parameters.json that contains all values for parameters that can be copied in the cluster definition file used. That’s all.
In previous parts of this article, I created an SSH key pair and I want to use instead of generating a new one. This can be accomplished copying the content of the .pub file in the part below of the json file. Next steps will skip ssh key pair generation because already found in template.
For deploy you need subscription id you are working on that can be easily retrieved with az account show
./acs-engine deploy — subscription-id YOURSUBSCRIPTIONIDHERE — dns-prefix ivank8stest — location westeurope — auto-suffix — api-model ~/acs/acs-engine/examples/windows/kubernetes-hybrid.json
Note: If you want to avoid passing dns-prefix as argument you can add it to template.json file as we did for keyData same trick can be used for any elements in the file. acs-engine is smart enough to skip steps if data are present. i.e. ServicePrincipalProfile creation.
If everything went well you should see something like:
INFO[0526] Finished ARM Deployment (myAcsTest2–676730522).
We did it! Our Hybrid Kubernetes Cluster seems up and running! Let’s test it now.
When deployment is completed you should have a _output folder with a subfolder named as dns-prefix of your super cluster. Go in it.
It contains artifacts generated by acs-engine and kubeconfig is really useful for us as described here in step 9. I will try to make it super simple here.
From your terminal run following command point to your _output folder
It’s up and running and we can use it with our local kubectl!
Everything is up and running, let’s try to deploy some Linux and Windows containers!
We are going to deploy same azure vote app deployed in Part 1, but with a small change in the yaml file needed to deploy on os:linux nodes.
Here is the content of the azure-vote.yaml file with changes highlighted:
You can now deploy it using: kubectl create -f azure-vote.yaml
Leave Kubernetes working and let’s move to…
Here we will use artifacts from Part 2, but condensed in a single iisdeploymentfull.yaml file describing the whole deployment.
Again we can deploy it using: kubectl create -f iisdeploymentfull.yaml
Now we need to wait few minutes to have everything up and running.
Connect to your Kubernetes Dashboard through usual proxy channel: kubectl proxy and open a browser: http://127.0.0.1:8001/ui
From here feel free to navigate in the various sections to check status of your cluster, pods, deployments and services.
From Services you will be able to retrive External Endpoints that you can use to test both iis and azure-vote deployments.
Let’s close this article with a quick scale of both deployments to push our cluster:
kubectl scale deployments/azure-vote-front --replicas 100
kubectl scale deployments/iis --replicas 4
Final result:
As always you can delete everything with a simple Azure CLI 2 command: az group delete --name myAcsTest --yes --no-wait
We did it again! Now we are Azure Kubernetes Masters and we can easily deploy whatever we want!
My adventure will continue with ingress distributed on Linux and Windows nodes, Monitoring, Autoscale on Azure and much more.
Do you want more information about Kubernetes on Azure? Contact us!