这是一个成绩单:
LANELSON$ kubectl --kubeconfig foo get -a jobs
No resources found.
好的;即使使用-a
选项,也不存在任何工作。凉!哦,让我们只是偏执,检查一下我们知道创建的那个。谁知道?也许我们会学到一些东西:
LANELSON$ kubectl --kubeconfig foo get -a job emcc-poc-emcc-broker-mp-populator
NAME DESIRED SUCCESSFUL AGE
emcc-poc-emcc-broker-mp-populator 1 0 36m
是,关于什么?
在第二种情况下,我碰巧知道创建的作业的名称,所以我直接要求它。我原本以为kubectl get -a jobs
会在输出中返回它。为什么不呢?
当然,我真正想做的是获取作业创建的其中一个pod的日志,但kubectl get -a pods
也没有显示任何该作业的终止pod,当然我不知道任何名称这个工作会产生的豆荚。
这里发生了什么?
Kubernetes 1.7.4如果重要的话。
答案是Istio automatic sidecar injection碰巧在环境中“开启”(我不知道,也不应该)。发生这种情况时,您可以使用opt out of it,但是默认情况下所有工作负载都会受到影响(!)。如果您不选择退出,并且Istio的存在导致您的作业无法以任何理由创建,那么您的作业在技术上是未初始化的。如果资源未初始化,则它不会显示在kubectl get
列表中。要在kubectl get
列表中显示未初始化的资源,您需要在--include-uninitialized
中包含get
选项。所以,一旦我发布了kubectl --kubeconfig foo get -a --include-uninitialized jobs
,我就能看到失败的工作。
我的更高级别的内容是Kubernetes的初始化部分,目前处于alpha状态,尚未准备好迎接黄金时段。