coreos - Kubernetes: link a pod to kube-proxy -
as understand it, kube-proxy runs on every kubernetes node (it started on master , on worker nodes)
if understand correctly, 'recommended' way access api (see: https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/accessing-the-cluster.md#accessing-the-api-from-a-pod)
so, since kube-proxy running on every node, 'recommended' way start each pod new kube-proxy container in it, or possible 'link' somehow running kube-proxy container?
originally using url $kubernetes_service_host , credentials passed secret, on gke, calling
curl https://$user:$password@${kubernetes_service_host}/api/v1/namespaces/${namespace}/endpoints/${selector}
and parsing results, on k8s deployed on coreos cluster seem able authenticate through tls , certs , linked proxy seems better way.
so, i'm looking efficient / easiest way connect api pod ip of pod referred service.
any suggestion/input?
there couple options here, noted in doc link provided.
the preferred method using service accounts access api:
the short description service read service-account secrets (token / ca-cert) mounted pod, inject token http header , validate apiserver cert using ca-cert. simplifies description of service accounts, above link can provide more detail.
example using curl , service-account data inside pod:
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
another option, mentioned in link provided, run side-car container running "kubectl proxy" in same pod application.
a note of clarification: "kube-proxy" , "kubectl proxy" not referring same thing. kube-proxy responsible routing "service" requests, kubectl proxy cli cmd opens local proxy kubernetes api.
what happening under covers when running kubectl proxy
kubectl command knows how use service-account data, extract token/ca-cert , establish connection api server you, expose interface locally in pod (which can use without auth/tls).
this might easier approach requires no changes existing application, short of pointing local kubectl proxy container running in same pod.
one other side-note: i'm not sure of exact use-case, preferable use service ip / service dns name , allow kubernetes handle service discovery, rather extracting pod ip (the pod ip change if pod gets scheduled different machine).
Comments
Post a Comment