当使用来自 kubernetes(基于 EKS)集群内部kubectl
的映像运行命令时,我希望该命令能够获取环境变量并连接到本地集群以运行命令。具体来说,我正在使用它在集群上运行一些内务处理,但容器只是出错(并最终进入 crashBackoff 循环)。bitnami/kubectl
KUBERNETES_SERVICE_HOST
KUBERNETES_SERVICE_PORT
kubernetes cronjobs
容器日志中的错误消息如下:
与服务器 localhost:8080 的连接被拒绝 - 您是否指定了正确的主机或端口?
这localhost:8080
特别奇怪,因为它从未使用过,并且在我知道的任何地方都没有配置 - 切换到简单的 shell 命令可以让作业成功运行,但 kubectl 拒绝工作。运行env
确认KUBE
变量确实被注入并正确设置。最近唯一的变化是将这些作业移动到由terraform kubernetes cronjob 资源管理,而不是直接通过 YAML 文件管理。每个 cronjob 都与具有适当权限的服务帐户相关联,并且仍然在 cronjob 中正确配置。
作为参考,这里是 cronjob 的略微编辑版本:
resource "kubernetes_cron_job" "test_cronjob" {
provider = kubernetes.region
metadata {
name = "test-cronjob"
namespace = "default"
}
spec {
concurrency_policy = "Allow"
failed_jobs_history_limit = 5
schedule = "*/5 * * * *"
job_template {
metadata {}
spec {
backoff_limit = 2
parallelism = 1
completions = 1
template {
metadata {}
spec {
container {
name = "kubectl"
image = "bitnami/kubectl"
command = ["/bin/sh", "-c", <<-EOT
env && echo "test";
EOT
]
}
restart_policy = "OnFailure"
service_account_name = "sa-test"
}
}
}
}
}
}
此处的错误消息没有多大帮助,这意味着问题在于集群的主机和端口配置错误,但根本问题实际上是缺少凭据,尽管配置了服务帐户。
解释一下,作为作业一部分的 pod 规范包含automount_service_account_token设置,该设置在 Terraform 中默认为 false。我怀疑以前使用默认
YAML
设置的文件管理这些文件时。true
神秘错误的原因是,在没有有效凭据的情况下,
kubectl
似乎回退到尝试“不安全选项”,如文档中所述,默认为 localhost 和端口 8080。它在尝试不安全后报告错误选择作为最后的手段,而不是指出缺乏凭据或给出更有用的未经授权的错误。经过一番挖掘,这似乎实际上是底层client-go
库的一个问题,并且它已经以其他方式浮出水面 看到这个问题。要解决此问题,只需将
automount_service_account_token
back 设置为 true,如下所示: