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

Question

我认为没有愚蠢的问题，所以这里有一个我找不到直接答案的问题。

情况

我目前有一个在 AKS 上运行 1.15.x 的 Kubernetes 集群，通过 Terraform 进行部署和管理。 AKS 最近 Azure 宣布他们将在 AKS 上淘汰 1.15 版本的 Kubernetes，我需要将集群升级到 1.16 或更高版本。现在，据我了解，直接在 Azure 中升级集群不会对集群的内容、IE 节点、Pod、机密和当前存在的所有其他内容产生任何影响，但我找不到任何正确答案来解决会发生什么如果我通过 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 的升级方法，将更改刷新回您的状态，并调整代码，直到计划生成不会显示任何无法容忍的情况。处理版本的两个 azurerm_kubernetes_cluster 参数可能就是您需要调整的全部。

Answer 2

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

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

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