Where managed cluster ends and our responsibilities begins in Azure Kubernetes service?

10/5/2018

I am wondering where responsibilities of Azure ends and our responsibilities begins?

For example we want to set up pods priority for our pods. But pods started by Azure (kube-dns, kube-proxy, heapter, ...) have priority 0 and we would like them to have highest priority of them all. I know that i can change priority of these services using patch even when i don't have manifest for them but i am not sure if i should do it because Azure started these pods. And i am not sure if it is my responsibility or Azures to support these system pods that are part of managed cluster.

-- user1816532
azure
azure-aks
azure-kubernetes
kubernetes

2 Answers

10/8/2018

For Azure Kubernetes Service, it's Kubernetes implementation on Azure. Azure manages something for Kubernetes, such as the node is the Azure VM. But the core is still the Kubernetes.

Azure Kubernetes Service (AKS) makes it simple to deploy a managed Kubernetes cluster in Azure. AKS reduces the complexity and operational overhead of managing Kubernetes by offloading much of that responsibility to Azure.

For more details, see Azure Kubernetes Service (AKS).

About the Pod Priority, it's the Feature of Kubernetes, also according to the version.

Pods can have priority. Priority indicates the importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible.

Describe as the document, the Pod Priority is the order to schedule the pod, not start up the pod. And you can follow the steps How to use priority and preemption if you want to use the Pod Priority.

-- Charles Xu
Source: StackOverflow

10/20/2018

Thank you for posting this question. I’m on the engineering team of AKS. I’m not going to try to answer the question of exactly where the line is drawn between what Azure supports and what you are expected to maintain. That really is a difficult thing to answer and I don’t feel comfortable giving an insufficient answer. For the most part, you are right, the pods we install, we try to maintain. We have monitors in place for when these pods are misbehaving and we try to automatically mitigate issues as they arise. We do rely on upstream kubernetes addon-manager for these pods and with few exceptions, these pods are listed with an addon mode of Reconcile, which means our changes will overwrite yours.

Anyways, with all that said, I have submitted a pull request that adds pod priority classes for the service and addon pods for 1.11 (and above) clusters. Thank you for the suggestion.

-- user10531606
Source: StackOverflow