<p>Here is a transcript:</p>

<pre><code>LANELSON$ kubectl --kubeconfig foo get -a jobs
No resources found.
</code></pre>

<p>OK, fine; even with the <code>-a</code> option, no jobs exist.  Cool!  Oh, let's just be paranoid and check for one that we know was created.  Who knows?  Maybe we'll learn something:</p>

<pre><code>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
</code></pre>

<p>Er, um, what?</p>

<p>In this second case, I just happen to know the name of a job that was created, so I ask for it directly.  I would have thought that <code>kubectl get -a jobs</code> would have returned it in its output.  Why doesn't it?</p>

<p>Of course what I'd <em>really</em> like to do is get the logs of one of the pods that the job created, but <code>kubectl get -a pods</code> doesn't show any of that job's terminated pods either, and of course I don't know the name of any of the pods that the job would have spawned.</p>

<p>What is going on here?</p>

<p>Kubernetes 1.7.4 if it matters.</p>

<p>The answer is that Istio <a href="https://istio.io/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection" rel="nofollow noreferrer">automatic sidecar injection</a> happened to be "on" in the environment (I had no idea, nor should I have).  When this happens, you can <a href="https://istio.io/docs/setup/kubernetes/sidecar-injection.html#overriding-automatic-injection" rel="nofollow noreferrer">opt out of it</a>, but otherwise all workloads are affected by default (!).  If you don't opt out of it, and Istio's presence causes your Job not to be created for any reason, then your Job is technically <em>uninitialized</em>.  If a resource is uninitialized, then it does not show up in <code>kubectl get</code> lists.  To make an uninitialized resource show up in <code>kubectl get</code> lists, you need to include the <code>--include-uninitialized</code> option to <code>get</code>.  So once I issued <code>kubectl --kubeconfig foo get -a --include-uninitialized jobs</code>, I could see the failed jobs.</p>

<p>My higher-level takeaway is that the initializer portion of Kubernetes, currently in alpha, is not at all ready for prime time yet.</p>
