Azure Kubernetes从v1.22升级至v1.27后,Terraform部署Helm Chart失败寻求解决方案
从你的日志和描述来看,主要遇到了两个核心问题,咱们一步步来解决:
问题1:local-exec删除Pod时出现NotFound错误
日志里的这类报错:
Error from server (NotFound): pods "srv-management-databases-tewapp-7df58b9979-ps8hl" not found
原因很明确:你的Terraflow流程中,Helm已经先销毁了timeseries_management_service、databases_management_service、worksites_management_service这几个Release对应的Pod,但后续null_resource的脚本还在尝试删除platform命名空间下的所有Pod,包括已经不存在的那些,导致命令执行失败。
解决方法
给kubectl delete命令添加--ignore-not-found=true参数,这样即使目标Pod不存在,命令也不会返回错误。修改你的local-exec命令如下:
kubectl --kubeconfig=./.kube/aks-dev get po -n platform | tail -n +2 | awk '{print $1}' | xargs kubectl --kubeconfig=./.kube/aks-dev delete pod -n platform --ignore-not-found=true
问题2:CronJob API版本不兼容
日志里的核心报错:
unable to build kubernetes objects from current release manifest: resource mapping not found for name: "srv-monitoring-rabbitmq" namespace: "platform" from "": no matches for kind "CronJob" in version "batch/v1beta1"
Kubernetes从1.21版本开始弃用batch/v1beta1版本的CronJob API,1.25版本则完全移除了该API。你的AKS升级后版本≥1.25,所以必须使用batch/v1版本的API。
你提到修改了模板里的apiVersion但没效果,大概率是因为你的Chart依赖了Bitnami的子Chart,而旧版本的Bitnami Chart仍在使用batch/v1beta1,或者你的自定义配置被Bitnami的默认配置覆盖了。可以试试以下几个方向:
解决方向1:升级Bitnami Chart版本
Bitnami的主流Chart在较新版本中已经适配了Kubernetes 1.25+,将CronJob的API版本更新为batch/v1。检查并升级你使用的Bitnami Chart到最新兼容版本。
解决方向2:通过Terraform强制覆盖API版本
如果暂时无法升级Bitnami Chart,可以在helm_release资源中通过set参数强制覆盖CronJob的API版本。比如针对RabbitMQ的监控Release:
resource "helm_release" "srv_monitoring_rabbitmq" { # 其他原有配置... # 根据实际Chart的参数路径调整,这里假设是metrics下的CronJob set { name = "metrics.cronjob.apiVersion" value = "batch/v1" } }
其他涉及CronJob的Release(比如srv_vendor_campbell、srv_vendor_capetti)也需要做类似的配置。
解决方向3:确认依赖版本兼容性
确保你的Terraform Helm Provider版本(你升级到了~>3.13.1,这个版本是兼容的)和kubectl客户端版本与AKS集群版本匹配,建议kubectl版本和集群版本的差距不超过一个小版本。
额外优化建议
尽量避免用null_resource的local-exec批量删除Pod,这种方式容易出现时序问题。如果是为了让Pod加载新配置,可以通过Helm的滚动更新机制触发重启,比如在helm_release中添加一个动态变化的注解:
resource "helm_release" "behavior" { # 其他原有配置... set { name = "podAnnotations.restartTrigger" value = timestamp() } }
每次执行terraform apply时,timestamp()会生成新值,自动触发Pod滚动重启,更符合Kubernetes和Helm的最佳实践。
备注:内容来源于stack exchange,提问作者DavidM Uby

