部署SQL Server 2019 BDC卡在"等待控制平面就绪"状态求助
排查SQL Server 2019 BDC部署卡在控制平面就绪阶段的问题
兄弟,这种情况绝对是异常状态——你用的是aks-dev-test配置的单节点BDC,而且节点规格是Standard_L8s(8vCPU + 64GB内存),资源完全足够支撑部署,正常情况下控制平面应该在10分钟内就绪,15分钟以上肯定是部署流程卡壳了。下面给你一步步的排查和解决建议:
第一步:确认AKS集群基础状态是否正常
先确保你的AKS集群本身没有问题:
- 用Azure CLI检查集群状态:
看输出里的az aks show --name sqlbigdata --resource-group aksbigdataprovisioningState是不是Succeeded,agentPoolProfiles里的count和vmSize是否和你创建时一致,nodeStatus是否都是Ready。 - 用kubectl直接检查节点状态:
所有节点都应该处于kubectl get nodesReady状态,如果有NotReady或者Unknown,那就是AKS节点本身有问题,先解决这个(比如重启节点或者重新创建AKS集群)。
第二步:检查BDC相关Pod的状态
BDC部署的所有组件都在mssql-cluster命名空间下,先看所有Pod的状态:
kubectl get pods -n mssql-cluster
重点关注以下几种异常状态:
CrashLoopBackOff:Pod反复启动失败,大概率是配置错误或者依赖缺失ImagePullBackOff:镜像拉取失败,可能是网络问题或者镜像仓库权限问题Pending:Pod无法调度,可能是资源不足(但你用的L8s应该不会)或者存储类问题
第三步:查看异常Pod的日志定位问题
针对上面找到的异常Pod,查看具体日志找错误原因:
比如如果控制器Pod(名称类似control-0)出现异常,执行:
kubectl logs control-0 -n mssql-cluster
如果是镜像拉取失败,日志会提示无法拉取某个mcr.microsoft.com的镜像;如果是权限问题,会出现认证失败的错误;如果是存储问题,会提示无法挂载PVC。
第四步:检查服务主体(SP)的权限
你创建SP时用了--skip-assignment,虽然创建AKS时指定了SP,但这个SP需要有足够的权限管理AKS集群所在资源组的资源:
- 先查看当前SP的权限:
az role assignment list --assignee <你的SP AppId> --resource-group aksbigdata - 如果没有
Contributor或者类似的高权限角色,给SP添加权限:
权限不足是BDC部署卡壳的常见原因,因为BDC需要创建存储卷、负载均衡器等资源,SP权限不够会导致这些资源无法创建。az role assignment create --assignee <你的SP AppId> --role Contributor --resource-group aksbigdata
第五步:检查工具版本兼容性
确保你的Azure CLI和azdata-cli是最新的兼容版本,旧版本可能存在已知的部署bug:
- 检查版本:
az --version azdata --version - 如果版本较旧,先升级:
az upgrade # azdata升级根据你的安装方式,比如pip安装的话: pip install --upgrade azdata-cli
第六步:验证BDC配置文件是否正确
你修改了bdc.json里的metadata.name为sqlbigdata,检查一下配置文件有没有其他错误:
- 打开
custom/bdc.json,确认metadata.name和你的AKS集群名称一致 - 检查存储配置部分,比如
storage下的className是否是AKS默认的存储类(可以用kubectl get storageclasses查看默认存储类)
最后:如果以上都无效,尝试清理重部署
如果排查后还是找不到原因,建议清理现有部署重新开始:
- 先删除BDC集群:
azdata bdc delete -n sqlbigdata --force - 删除AKS集群:
az aks delete --name sqlbigdata --resource-group aksbigdata - 重新按照步骤创建SP、AKS集群和BDC,确保每一步都没有错误提示,尤其是SP权限和AKS节点就绪状态。
内容的提问来源于stack exchange,提问作者VMadhav
相关产品推荐
相关产品推荐

