<p>As I understand it, kube-proxy runs on every Kubernetes node (it is started on Master and on the Worker nodes)</p>

<p>If I understand correctly, it is also the 'recommended' way to access the API (see: <a href="https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/accessing-the-cluster.md#accessing-the-api-from-a-pod" rel="nofollow">https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/accessing-the-cluster.md#accessing-the-api-from-a-pod</a>)</p>

<p>So, since kube-proxy is already running on every node, is the 'recommended' way to start each pod with a new kube-proxy container in it, or is it possible to 'link' somehow to the running kube-proxy container?</p>

<p>Originally I was using the URL with $KUBERNETES_SERVICE_HOST and the credentials passed as a Secret, on GKE, 
calling </p>

<pre><code>curl https://$USER:$PASSWORD@${KUBERNETES_SERVICE_HOST}/api/v1/namespaces/${NAMESPACE}/endpoints/${SELECTOR}
</code></pre>

<p>and parsing the results, but on K8s deployed on a CoreOS cluster I only seem to be able to authenticate through TLS and certs and the linked proxy seems like a better way.</p>

<p>So, I'm looking for the most efficient / easiest way to connect to the API from a pod to look up the IP of another pod referred to by a Service.</p>

<p>Any suggestion/input?</p>

<p>There are a couple options here, as noted in the doc link you provided.</p>

<p>The preferred method is using <a href="https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/service-accounts.md" rel="noreferrer">Service Accounts</a> to access the API:</p>

<p>The short description is that your service would read the service-account secrets (token / CA-cert) that are mounted into the pod, then inject the token into the http header and validate the apiserver cert using the CA-cert. This somewhat simplifies the description of service accounts, but the above link can provide more detail.</p>

<p>Example using curl and service-account data inside pod:</p>

<pre><code>curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes/api/v1/namespaces
</code></pre>

<p>Another option, mentioned in the link you provided, is to run a side-car container running a "kubectl proxy" in the same pod as your application. </p>

<p>A note of clarification: the "kube-proxy" and "kubectl proxy" are not referring to the same thing. The kube-proxy is responsible for routing "service" requests, kubectl proxy is a cli cmd which opens a local proxy to the Kubernetes API.</p>

<p>What is happening under the covers when running <code>kubectl proxy</code> is that the kubectl command already knows how to use the service-account data, so it will extract the token/CA-cert and establish a connection to the API server for you, then expose an interface locally in the pod (which you can use without any auth/TLS).</p>

<p>This is might be an easier approach as it likely requires no changes to your existing application, short of pointing it to the local kubectl proxy container running in the same pod.</p>

<p>One other side-note: I'm not sure of your exact use-case, but generally it would be preferable to use the Service IP / Service DNS name and allow Kubernetes to handle service discovery, rather than extracting the pod IP itself (the pod IP will change if the pod gets scheduled to a different machine).</p>
