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

Popular posts from this blog

java - WARN : org.springframework.web.servlet.PageNotFound - No mapping found for HTTP request with URI [/board/] in DispatcherServlet with name 'appServlet' -

android - How to create dynamically Fragment pager adapter -

1111. appearing after print sequence - php -