Kubernetes or k8s is one of those things we always hear about but does not always come into our daily work. In theory it sounds great, build some containers and deploy or run your applications in them. So why not just use a container service or just a virtual machine to accomplish the same thing? Well Kubernetes is a cluster that lets you group virtual machines together and use them for deployment and improvements as you are working through the lifecycle of your apps. It is really designed for developers doing CI/CD or continuous improvement / continuous deployment. Now here comes the part that gets us ad sysadmins. We have to be able to deploy the infrastructure or help troubleshoot it when things go wonky. So let’s dive in.
What is Kubernetes
A container-orchestration system for automating computer application deployment, scaling, and management. Well, that sounds great for the devs, and if you do some quick google searching you can find entire sections of the internet dedicated to k8s and how it works, what it does. Most of this is going to be explaining things the developers need to know. So what do we as sysadmins need to know about it? Well, the first thing is let’s look at k8s and AKS or Azure Kubernetes Service. When we say Kubernetes that is just describing a basic type of architecture. You could build out a Kubernetes cluster in VMware or AWS or Azure or GCP. Since we like to talk about Microsoft, we are going to stick to that. Now if you did build out your own Kubernetes cluster then you would have to manage all the services and microservices that come with it. To me, that does not really sound like something that would help me. What Azure does is offer a service for this so it is managed. Now you do not have to build or manage the underlying services that make it work. Microsoft likes to call it AKS. What this does is allow you to deploy a managed Kubernetes cluster in Azure. We are essentially offloading that work to Azure. We just have to take care of the nodes. The underlying system is referred to as the Kubernetes masters and they are completely managed by Azure.
Now since this is Azure we have several ways to take care of this. We can create the
You can create an AKS cluster in the Azure portal, with the Azure CLI, or template-driven deployment options such as Resource Manager templates and Terraform. When you deploy an AKS cluster, the Kubernetes master and all nodes are deployed and configured for you. Additional features such as advanced networking, Azure Active Directory integration, and monitoring can also be configured during the deployment process. Windows Server containers are supported in AKS.
Parts, and Pieces
There is alot that goes into making a kubernetes cluster work. Azure takes care of alot of this, however there are some things you need to know about if you are going to jump down this rabbit hole.
With Kubernetes comes great responsibility! ok, maybe that isn’t the exact quote but you get the idea. You can really mess things up for your dev team if you are messing about inside the cluster. One of the ways this is handled is by using either Azure AD or Kubernetes role-based access control. There are special roles when you assign permissions to allow you to see inside the cluster or make changes. like any permissions, you should assign the lowest level needed.
Like any good system, we will have our own terms that make no sense to anyone else. Welcome to clusters and nodes. I hear this getting confused a lot, what is a node? isn’t that just a virtual machine? why not just call it a virtual machine? well, the short answer is because a node is NOT a virtual machine. The cluster will have what is called a node pool, that it will deploy and it will create virtual machines to host those nodes. However, the virtual machine is just the host. The node will get created and then pods will get created inside the nodes. You will have to set how many pods you want on each node. The virtual machine is the infrastructure to run the node just as the node is the infrastructure to run the pod. And then there were workloads. The workloads are what the devs are creating to run on AKS. they will create workloads that will run in the pods. The idea with AKS is that your dev team can deploy and update workloads. During this process, some of the pods will get messed up or crash. instead of the dev having to worry about that and then getting a new container setup, AKS just trashes the pod and makes a new one. It can be the same with a workload that needs more resources, AKS will just create more pods or nodes. This is a major advantage to your dev team and is referred to as scaling. This helps to reduce the cost by only having the resources you need, and expanding those resources when you need them.
Virtual networks and ingress
One of the things you will notice very quickly about AKS and Kubernetes, in general, is that IP addresses are like candy. They just get eaten up. There are 2 models for networking, each one has pros and cons. So make sure you understand what you need from the networking side before you dive in. Kubenet is a more basic model that creates the networks for you and controls access to the nodes and pods by using NAT. if you have limited IP addresses this can be a big help. The other option is called CNI, which makes things much more complicated. Since in this model, all the nodes and pods are accessible and there is no NAT that takes place. You have to make sure you have enough IP’s to allow for networks to be created in advance or to be created by the cluster that does not overlap anything else. Since most of the time we are going to be working with some kind of hybrid network this can get complicated.
After you have your networks worked out, do not forget your firewalls. They will most certainly need to have some changes made to allow your communication.
Overall AKS or Kubernetes can be a great advantage to your dev team, just take the time to really plan out how you will need it setup. Do not get discouraged if you have to tear it down and rebuild it, that is the beauty of it. you can rip it down and replace it when you need to. You will find that eventually you will have to do that anyway as the needs change of your dev team.
Thanks for taking this trip down the rabbit hole