Kubernetes - 通过 Terraform 升级 Kubernetes 集群版本
Kubernetes - Upgrading Kubernetes-cluster version through Terraform
我认为没有愚蠢的问题，所以这是一个我找不到直接答案的问题。
情况
我目前在 AKS 上有一个 Kubernetes 集群 运行1.15.x，通过 Terraform 部署和管理。 AKS 最近 Azure 宣布他们将淘汰 AKS 上的 1.15 版本的 Kubernetes，我需要将集群升级到 1.16 或更高版本。现在，据我了解情况，直接在 Azure 中升级集群不会对集群的内容、I.E 节点、pods、机密和当前存在的所有其他内容产生任何影响，但我找不到任何合适的答案如果我通过 Terraform 升级集群会发生什么。
潜在问题
那么会出什么问题呢？在我看来，最坏的结果是整个集群都被摧毁，并且会创建一个新的集群。没有 pods，没有秘密，什么都没有。由于那里的信息太少了，我想在这里问一下，看看是否有人对 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 宣布它将“就地更新”，而不是添加新的 and/or 破坏现有集群。
我想说这表明 Terraform 方法是 non-destructive，即使在升级过程中有时会出现疏忽（但在此示例中仍然 non-destructive）：https://github.com/terraform-providers/terraform-provider-azurerm/issues/5541
如果您需要对此更改有更高的信心，那么您可以考虑使用 Azure-based 升级方法，将更改刷新回您的状态，并调整代码直到计划生成没有显示任何无法忍受的内容.处理版本的两个 azurerm_kubernetes_cluster 参数可能就是您需要调整的全部内容。
我今天发现了这个问题，我想我也会补充我的经验。我做了以下更改：
- 将
azurerm_kubernetes_cluster 下的 kubernetes_version 从“1.16.15”更改为“1.17.16”
- 将
default_node_pool 下的 orchestrator_version 从“1.16.15”更改为“1.17.16”
- 将
default_node_pool 下的 node_count 从 1 -> 2 增加
A terraform plan 显示它将就地更新。然后我执行了一个成功完成的 terraform apply。 kubectl get nodes 显示创建了一个额外的节点，但池中的两个节点仍然是旧版本。在Azure Portal中进一步查看，发现只升级了k8s集群版本，并没有升级节点池的版本。然后我一次又一次地执行 terraform plan 它表明 default_node_pool 下的 orchestrator_version 将 就地更新 。然后我执行 terraform apply 然后继续升级节点池的版本。它在池中创建一个附加节点（使用新版本）并将状态设置为 NodeSchedulable，同时将池中的现有节点设置为 NodeNotSchedulable。然后 NodeNotSchedulable 节点被具有新 k8s 版本的新节点替换，并最终设置为 NodeSchedulable。它对两个节点都这样做了。之后所有节点都升级了，没有任何明显的停机时间。
我认为没有愚蠢的问题，所以这是一个我找不到直接答案的问题。
情况
我目前在 AKS 上有一个 Kubernetes 集群 运行1.15.x，通过 Terraform 部署和管理。 AKS 最近 Azure 宣布他们将淘汰 AKS 上的 1.15 版本的 Kubernetes，我需要将集群升级到 1.16 或更高版本。现在，据我了解情况，直接在 Azure 中升级集群不会对集群的内容、I.E 节点、pods、机密和当前存在的所有其他内容产生任何影响，但我找不到任何合适的答案如果我通过 Terraform 升级集群会发生什么。
潜在问题
那么会出什么问题呢？在我看来，最坏的结果是整个集群都被摧毁，并且会创建一个新的集群。没有 pods，没有秘密，什么都没有。由于那里的信息太少了，我想在这里问一下，看看是否有人对 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 宣布它将“就地更新”，而不是添加新的 and/or 破坏现有集群。
我想说这表明 Terraform 方法是 non-destructive，即使在升级过程中有时会出现疏忽（但在此示例中仍然 non-destructive）：https://github.com/terraform-providers/terraform-provider-azurerm/issues/5541
如果您需要对此更改有更高的信心，那么您可以考虑使用 Azure-based 升级方法，将更改刷新回您的状态，并调整代码直到计划生成没有显示任何无法忍受的内容.处理版本的两个 azurerm_kubernetes_cluster 参数可能就是您需要调整的全部内容。
我今天发现了这个问题，我想我也会补充我的经验。我做了以下更改：
- 将
azurerm_kubernetes_cluster下的kubernetes_version从“1.16.15”更改为“1.17.16” - 将
default_node_pool下的orchestrator_version从“1.16.15”更改为“1.17.16” - 将
default_node_pool下的node_count从 1 -> 2 增加
A terraform plan 显示它将就地更新。然后我执行了一个成功完成的 terraform apply。 kubectl get nodes 显示创建了一个额外的节点，但池中的两个节点仍然是旧版本。在Azure Portal中进一步查看，发现只升级了k8s集群版本，并没有升级节点池的版本。然后我一次又一次地执行 terraform plan 它表明 default_node_pool 下的 orchestrator_version 将 就地更新 。然后我执行 terraform apply 然后继续升级节点池的版本。它在池中创建一个附加节点（使用新版本）并将状态设置为 NodeSchedulable，同时将池中的现有节点设置为 NodeNotSchedulable。然后 NodeNotSchedulable 节点被具有新 k8s 版本的新节点替换，并最终设置为 NodeSchedulable。它对两个节点都这样做了。之后所有节点都升级了，没有任何明显的停机时间。