Azure Container Services: Who patches, updates,... (Kubernetes)

1
votes

This may sound like a n00b question, and maybe it is, but some things with the Azure Container Services puzzle me a little. I have managed to get a Kubernetes Cluster up and running on Azure inside a Resource Group, so for starters I am set and done.

Now my questions are the following:

  • Who will take care of patching and upgrading the Master and Agent VMs?
  • Who will take care of patching and updating the Kubernetes Components?
  • Will I need to take care of backing up the etcd database myself?
  • Do I get an SLA with the Kubernetes Cluster, or is everything on top of the VM SLAs all up to me (i.e. making sure Kubernetes behaves)?

I have the feeling the answers to these questions are "me", "me", "yes" and "no", which would make me ask myself whether the ACS is just a set of Resource Manager Templates, or where's the added value? Am I right on my assumptions, or where am I wrong?

2
azurekubernetesazure-resource-manageretcdazure-container-service

2 Answers

3
votes

I'm on the Azure Container Service team, and your statement:

"ACS is just a set of Resource Manager Templates"

Is more or less correct at this moment in time (Jan. 2017)

Over the course of the next few months, we will be improving support for all of the scenarios you mentioned: * Backup * Upgrade * Health maintainence and repair

And this applies not just to Kubernetes but also to DC/OS and Docker Swarm which are also supported in ACS.

Please let me know if I can help with more information.

0
votes

State as of December 30th, 2016, this will change over the next couple of months.

I actually asked Microsoft these questions and received the following answers:

  • It's up to me to patch and upgrade the VMs Kubernetes runs on, i.e. the master and agent VMs
  • It's not yet decided by the Azure team how to take care of Kubernetes upgrades, but there will at least be documentation on how to do it, either via automatic upgrades, or how to do it manually (which currently is rather complicated)
  • In a vanilla deployment etcd runs on the master VM, storing everything on that machine's disk, which in turn is stored in a storage account in Azure. This means your etcd data is fairly safe, even if etcd is not run in a H/A fashion (using 3 or more dedicated VMs just to run etcd). Note: This is my interpretation of this question, I didn't get a clear answer on this one.
  • Regarding SLA on Kubernetes: This is totally not clear yet, but will be addressed (nor not) before Kubernetes on Azure goes GA.

All in all: Things are still moving around a little, but it looks quite promising. Perhaps somebody else is looking for this kind of information, and thus I posted an answer to my own question.