<p>I assume there are no stupid questions, so here is one that I could not find a direct answer to.</p>
<p><strong>The situation</strong></p>
<p>I currently have a Kubernetes-cluster running 1.15.x on AKS, deployed and managed through Terraform. AKS recently Azure announced that they would retire the 1.15 version of Kubernetes on AKS, and I need to upgrade the cluster to 1.16 or later. Now, as I understand the situation, upgrading the cluster directly in Azure would have no consequences for the content of the cluster, I.E nodes, pods, secrets and everything else currently on there, but I can not find any proper answer to what would happen if I upgrade the cluster through Terraform.</p>
<p><strong>Potential problems</strong></p>
<p>So what could go wrong? In my mind, the worst outcome would be that the entire cluster would be destroyed, and a new one would be created. No pods, no secrets, nothing. Since there is so little information out there, I am asking here, to see if there are anyone with more experience with Terraform and Kubernetes that could potentially help me out.</p>
<p>To summary:</p>
<p><strong>Terraform versions</strong></p>
<pre><code>Terraform v0.12.17
+ provider.azuread v0.7.0
+ provider.azurerm v1.37.0
+ provider.random v2.2.1
</code></pre>
<p><strong>What I'm doing</strong></p>
<pre><code>§ terraform init 

//running terrafrom plan with new Kubernetes version declared for AKS

§ terraform plan 

//Following changes are announced by Terraform:



An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  #module.mycluster.azurerm_kubernetes_cluster.default will be updated in-place...

         ...
         ~ kubernetes_version              = &quot;1.15.5&quot; -&gt; &quot;1.16.13&quot;
         ...


Plan: 0 to add, 1 to change, 0 to destroy.
</code></pre>
<p><strong>What I want to happen</strong></p>
<p>Terraform will tell Azure to upgrade the existing AKS-service, not destroy before creating a new one. I assume that this will happen, as Terraform announces that it will &quot;update in-place&quot;, instead of adding new and/or destroying existing clusters.</p>

aaursand
<p>I found this question today and thought I'd add my experience as well. I made the following changes:</p>
<ol>
<li>Changed the <code>kubernetes_version</code> under <code>azurerm_kubernetes_cluster</code> from &quot;1.16.15&quot; -&gt; &quot;1.17.16&quot;</li>
<li>Changed the <code>orchestrator_version</code> under <code>default_node_pool</code> from &quot;1.16.15&quot; -&gt; &quot;1.17.16&quot;</li>
<li>Increased the <code>node_count</code> under <code>default_node_pool</code> from 1 -&gt; 2</li>
</ol>
<p>A <code>terraform plan</code> showed that it was going to <em>update in-place</em>. I then performed a <code>terraform apply</code> which completed successfully. <code>kubectl get nodes</code> showed that an additional node was created, but both nodes in the pool were still on the old version. After further inspection in Azure Portal it was found that only the k8s cluster version was upgraded and not the version of the node pool. I then executed <code>terraform plan</code> again and again it showed that the <code>orchestrator_version</code> under <code>default_node_pool</code> was going to be <em>updated in-place</em>. I then executed <code>terraform apply</code> which then proceeded to upgrade the version of the node pool. It did that whole thing where it creates an additional node in the pool (with the new version) and sets the status to <code>NodeSchedulable</code> while setting the existing node in the pool to <code>NodeNotSchedulable</code>. The <code>NodeNotSchedulable</code> node is then replaced by a new node with the new k8s version and eventually set to <code>NodeSchedulable</code>. It did this for both nodes. Afterwards all nodes were upgraded without any noticeable downtime.</p>
