kubernetes - Azure DevOps > Helm > Azure Kubernetes 部署 - 删除部署时删除 Azure 文件共享

Question

TL;博士

删除部署时，Kubernetes / Helm 会（不一致地）删除我的 Pod 挂载的 Azure 文件共享。

解释

我最近过渡到使用 Helm 通过 DevOps 发布管道在我的 Azure Kubernetes 集群上部署 Kubernetes 对象。

作为部署的一部分，我已经开始看到一些与我挂载到我的 Pod 的 Azure 文件共享（作为具有关联的持久卷声明和存储类的持久卷）有关的意外行为。

虽然我一直在完成我的部署，但我一直在使用内置的 Helm 任务通过 Azure Devops 发布管道推出部署，这些任务运行良好。当我想要修复/改进流程时，我要么手动删除 Kubernetes 仪表板 (UI) 上的对象，要么使用 Powershell（命令行）删除部署。

例如：

helm delete myapp-prod-73
helm del --purge myapp-prod-73

不是每次，而是更频繁地，我看到底层 Azure 文件共享也被删除，因为我正在完成这个过程。网络上关于此的内容很少，但我还在以下网址看到了一篇概述类似问题的文章：https ://winterdom.com/2018/07/26/kubernetes-azureFile-dynamic-volumes-deleting 。

社区中有没有人遇到过这个问题？

标签： kubernetesazure-devopskubernetes-helmazure-aks

Answer 1

归功于 https://twitter.com/tomasrestrepo为我指明了正确的方向（我上面提到的文章的作者）。

这里的行为是将存储类和持久卷上的回收策略设置为“删除”的结果。当切换到 Helm 时，我开始在测试时按照他们的命令删除/清除版本。我没有意识到的是，删除该版本也意味着 Helm / K8s 也会伸出手并删除基础卷（在本例中为 Azure 文件共享）。这记录在：https ://kubernetes.io/docs/concepts/storage/persistent-volumes/#delete

我将把这个问答留在这里，让其他任何人都巧妙地错过了存储类、持久卷 (PV) 和底层存储在 K8s / Helm 下运行的方式。

注意：我认为由于我手动创建 Azure 文件共享（通过 Azure 门户）并尝试将其挂载为静态卷（根据https://docs.microsoft.com/en -us/azure/aks/azure-files-volume）在我的 Helm Chart 中，但是当版本被删除时（有时一个小时后？），底层卷并没有立即被删除。