Azure DevOps Kubernetes@1登录AKS后kubectl执行失败如何解决

Kubernetes@1 任务的login操作默认只在自身任务的执行上下文里生效，不会自动把鉴权生成的有效kubeconfig注入后续步骤的执行环境：

• 后续bash步骤读取到的KUBECONFIG指向的是系统初始化生成的空白默认配置文件，没有写入AKS集群的API Server地址、鉴权证书等有效信息
• kubectl读取空配置时拿不到正确的集群访问地址，才会触发API Server域名DNS解析失败的报错

两种方案选一种即可：

方案1：直接在Kubernetes@1任务内执行kubectl命令 #

不需要额外拆分独立bash步骤，把要跑的kubectl逻辑直接写在同一个Kubernetes@1任务里，任务会自动用内置的鉴权上下文执行命令，配置示例：

steps:    
- task: Kubernetes@1
  inputs:
    connectionType: 'Kubernetes Service Connection'
    kubernetesServiceEndpoint: 'aks-xxx'
    command: 'get'
    arguments: 'pods'
    # 其余自定义kubectl参数直接追加在arguments字段即可

方案2：显式导出kubeconfig供后续独立步骤复用 #

如果需要在后续多个bash/脚本步骤里用kubectl，就显式指定kubeconfig的输出固定路径，后续步骤主动加载这个配置就行：

steps:    
- task: Kubernetes@1
  name: aksLogin
  inputs:
    connectionType: 'Kubernetes Service Connection'
    kubernetesServiceEndpoint: 'aks-xxx'
    command: 'login'
    useKubectl: true
    # 显式指定kubeconfig输出到流水线工作目录的固定路径
    kubeConfig: $(Pipeline.Workspace)/akskubeconfig

- bash: |
    # 加载有效kubeconfig配置
    export KUBECONFIG=$(Pipeline.Workspace)/akskubeconfig
    kubectl get pod
    # 其余自定义kubectl逻辑直接往后追加即可

注意事项 #

• 不要依赖Kubernetes@1任务隐式生成的临时kubeconfig路径，不同agent操作系统、不同任务版本的临时路径规则不固定，很容易出现空配置、路径不存在的问题
• 用自托管agent的场景，建议在脚本执行完加一句rm -f $(Pipeline.Workspace)/akskubeconfig清理凭据文件，避免集群访问凭据残留在agent机器上
• 用微软托管agent的场景不需要额外清理，流水线执行完临时环境会被完全销毁

内容的提问来源于stack exchange，提问作者Joost Döbken