1
1
这就是我一直在使用的:
这将找到具有特定标签的所有部署,并在其中每一个部署上运行kubectl,您可以轻松地将其适应您的需要。唯一的先决条件是,在此任务之前必须有kubectl任务,因此您的代理从AzureDevOps下载kubectl配置。
|
2
0
在花了几个小时的时间试图弄清楚AzureDevOps如何连接到AKS集群之后,我发现它正在使用一个OAuth访问令牌,据我所知。可以使用system.access token变量访问此令牌(如果允许代理作业访问令牌-这是一个配置选项,默认情况下是关闭的)。我无法理解的是如何在脚本中使用这个标记和kubectl,所以我暂时放弃了这条路径。 此外,作业运行在托管的Ubuntu代理上(与Microsoft托管的一样),因此出于安全原因,它可能会避免下载配置文件,即使Microsoft本身认为代理是一次性虚拟机,并且“一次使用后虚拟机将被丢弃”。 see MS docs here . 在托管代理上工作的内容(我仍然建议对生产方案进行一些加密)-使用Azure CLI命令登录并获取群集凭据:
我使用的另一种解决方案是在已经预先配置了kubernetes配置文件的本地代理上运行脚本。为此,我只创建了一个额外的代理作业来运行脚本,所以现在我有:
|