我假设没有愚蠢的问题,所以这是我找不到直接答案的问题。
情况
我目前有一个在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宣布它将“就地更新”,而不是添加新的和/或破坏现有的集群。
答案 0 :(得分:3)
我想说这表明Terraform方法是非破坏性的,即使在升级过程中有时受到监督(但在此示例中仍然是非破坏性的):https://github.com/terraform-providers/terraform-provider-azurerm/issues/5541
如果您对此更改需要更高的信心,则可以替代地考虑使用基于Azure的升级方法,将更改刷新回到您的状态,并调整代码,直到计划生成不会显示任何无法忍受的内容。您可能需要调整的仅两个与version有关的azurerm_kubernetes_cluster参数。
答案 1 :(得分:0)
我今天发现了这个问题,并想我也会添加我的经验。我做了以下更改:
kubernetes_version
下的 azurerm_kubernetes_cluster
从“1.16.15”更改为“1.17.16”orchestrator_version
下的 default_node_pool
从“1.16.15”更改为“1.17.16”node_count
下的 default_node_pool
从 1 增加 -> 2terraform plan
表明它将就地更新。然后我执行了成功完成的 terraform apply
。 kubectl get nodes
显示创建了一个额外的节点,但池中的两个节点仍然使用旧版本。在Azure Portal中进一步检查发现只有k8s集群版本升级,节点池版本没有升级。然后我一次又一次地执行 terraform plan
,它表明 orchestrator_version
下的 default_node_pool
将就地更新。然后我执行了 terraform apply
,然后继续升级节点池的版本。它完成了整个过程,在池中创建了一个附加节点(使用新版本)并将状态设置为 NodeSchedulable
,同时将池中的现有节点设置为 NodeNotSchedulable
。然后 NodeNotSchedulable
节点被具有新 k8s 版本的新节点替换,并最终设置为 NodeSchedulable
。它对两个节点都这样做了。之后所有节点都升级了,没有任何明显的停机时间。