Kubernetes-通过Terraform升级Kubernetes集群版本

Question

我假设没有愚蠢的问题，所以这是我找不到直接答案的问题。

情况

我目前有一个在AKS上运行1.15.x的Kubernetes集群，并通过Terraform进行部署和管理。 AKS最近Azure宣布将在AKS上淘汰Kubernetes的1.15版本，我需要将集群升级到1.16或更高版本。现在，据我所知，直接在Azure中升级群集不会对群集的内容，IE节点，吊舱，机密以及当前存在的所有其他内容产生任何影响，但是我找不到任何适当的答案如果我通过Terraform升级群集。

潜在问题

那怎么可能出问题了？在我看来，最糟糕的结果是整个集群将被销毁，而新集群将被创建。没有豆荚，没有秘密，什么都没有。由于那里的信息很少，所以我在这里问，看看是否有人对Terraform和Kubernetes有更多的经验，可能会帮助我。

总结：

Terraform版本

Terraform v0.12.17
+ provider.azuread v0.7.0
+ provider.azurerm v1.37.0
+ provider.random v2.2.1

我在做什么

§ 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              = "1.15.5" -> "1.16.13"
         ...


Plan: 0 to add, 1 to change, 0 to destroy.

我想发生的事情

Terraform将告诉Azure升级现有的AKS服务，而不是在创建新服务之前销毁。我认为这会发生，因为Terraform宣布它将“就地更新”，而不是添加新的和/或破坏现有的集群。

Answer 1

我想说这表明Terraform方法是非破坏性的，即使在升级过程中有时受到监督（但在此示例中仍然是非破坏性的）：https://github.com/terraform-providers/terraform-provider-azurerm/issues/5541

如果您对此更改需要更高的信心，则可以替代地考虑使用基于Azure的升级方法，将更改刷新回到您的状态，并调整代码，直到计划生成不会显示任何无法忍受的内容。您可能需要调整的仅两个与version有关的azurerm_kubernetes_cluster参数。

Answer 2

我今天发现了这个问题，并想我也会添加我的经验。我做了以下更改：

1. 将 kubernetes_version 下的 azurerm_kubernetes_cluster 从“1.16.15”更改为“1.17.16”
2. 将 orchestrator_version 下的 default_node_pool 从“1.16.15”更改为“1.17.16”
3. 将 node_count 下的 default_node_pool 从 1 增加 -> 2

terraform plan 表明它将就地更新。然后我执行了成功完成的 terraform apply。 kubectl get nodes 显示创建了一个额外的节点，但池中的两个节点仍然使用旧版本。在Azure Portal中进一步检查发现只有k8s集群版本升级，节点池版本没有升级。然后我一次又一次地执行 terraform plan，它表明 orchestrator_version 下的 default_node_pool 将就地更新。然后我执行了 terraform apply，然后继续升级节点池的版本。它完成了整个过程，在池中创建了一个附加节点（使用新版本）并将状态设置为 NodeSchedulable，同时将池中的现有节点设置为 NodeNotSchedulable。然后 NodeNotSchedulable 节点被具有新 k8s 版本的新节点替换，并最终设置为 NodeSchedulable。它对两个节点都这样做了。之后所有节点都升级了，没有任何明显的停机时间。