CODEWITHSUNDEEP
azureazure-aks
letthefireflieslive
letthefireflieslive

Reputation: 12694

What you cannot do when you use AKS over self-managed kubernetes cluster?

I'm deciding if I should provide use vanilla kubernetes or use Azure Kubernetes Service for my CI build agents.

What control will I lose if used AKS; SSH inside cluster? turning on and off the VMS? How about the cost, I see that AKS use the VM pricing, is there something beyond that

Upvotes: 0

Views: 717

Answers (1)

Anton Matsiuk
Anton Matsiuk

Reputation: 690

There are several limitations which come to my mind, but neither of them should restrict your use case:

  1. You lose control over master nodes (control plane). Shouldn't be an issue in your use case, and I hardly imagine where this may be a limitation. You still can SSH into worker nodes in AKS.
  2. You lose fine-grained control over size of worker nodes. Node pools become an abstraction to control size of the VMs. In a self-managed cluster you can attach VMs of completely different size to the cluster. In AKS all the nodes in the same pool must be of the same size (but you can create several node pools with different VM sizes).
  3. It's not possible to choose node's OS in AKS (it's Ubuntu-based).
  4. You're not flexible in choosing network plugins for k8s. It's either kubenet or Azure CNI. But that's fine as long as you're not using some weird applications which requre L2 networking, more info here

There are definitely benefits of AKS:

  1. You're not managing control plane which is a real pain reliever.
  2. AKS can scale its nodes dynamically, which may be a good option for bursty workloads like build agents, but also imposes additional delay during node scaling procedure.
  3. Cluster (control and data planes) upgrades are just couple of clicks in azure portal.
  4. Control plane is free in AKS (in contrast e.g. to EKS in Amazon), you pay only for the worker nodes, you can calculate your price here

Upvotes: 1

Related Questions