title: Kubernetes unable to access the kube-apiserver from inside pod on node
body: <p>I have configured a vagrant backed kubernetes cluster but I am unable to access the kube-apiserver running on master from within pods running on nodes. I am trying to look up a service from within a pod via the api but it looks like the api keeps dropping the connection.</p>
  
  <p>Using curl from within the pod I get the following output</p>
  
  <pre><code>root@itest-pod-2:/# curl -v \
  --insecure -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  https://$KUBERNETES_SERVICE_HOST:443/api/v1/namespaces/default/services?labelSelector=name%3Dtest-server
  * Hostname was NOT found in DNS cache
  *   Trying 10.245.0.1...
  * Connected to 10.245.0.1 (10.245.0.1) port 443 (#0)
  * successfully set certificate verify locations:
  *   CAfile: none
    CApath: /etc/ssl/certs
  * SSLv3, TLS handshake, Client hello (1):
  * Unknown SSL protocol error in connection to 10.245.0.1:443 
  * Closing connection 0
  curl: (35) Unknown SSL protocol error in connection to 10.245.0.1:443 
  root@itest-pod-2:/# 
  </code></pre>
  
  <p>However if I configure a single machine environment by simply installing all the node components onto the master I am able to contact the api from within a pod.</p>
  
  <pre><code>root@itest-pod-3:/# curl -v --insecure \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  https://$KUBERNETES_SERVICE_HOST:443/api/v1/namespaces/default/services?labelSelector=name%3Dtest-server
  * Hostname was NOT found in DNS cache
  *   Trying 10.245.0.1...
  * Connected to 10.245.0.1 (10.245.0.1) port 443 (#0)
  * successfully set certificate verify locations:
  *   CAfile: none
    CApath: /etc/ssl/certs
  * SSLv3, TLS handshake, Client hello (1):
  * SSLv3, TLS handshake, Server hello (2):
  * SSLv3, TLS handshake, CERT (11):
  * SSLv3, TLS handshake, Server key exchange (12):
  * SSLv3, TLS handshake, Server finished (14):
  * SSLv3, TLS handshake, Client key exchange (16):
  * SSLv3, TLS change cipher, Client hello (1):
  * SSLv3, TLS handshake, Finished (20):
  * SSLv3, TLS change cipher, Client hello (1):
  * SSLv3, TLS handshake, Finished (20):
  * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA
  * Server certificate:
  *    subject: CN=10.0.2.15@1452869292
  *    start date: 2016-01-15 14:48:12 GMT
  *    expire date: 2017-01-14 14:48:12 GMT
  *    issuer: CN=10.0.2.15@1452869292
  *    SSL certificate verify result: self signed certificate (18), continuing anyway.
  &gt; GET /api/v1/namespaces/default/services?labelSelector=name%3Dtest-server HTTP/1.1
  &gt; User-Agent: curl/7.38.0
  &gt; Host: 10.245.0.1
  &gt; Accept: */*
  &gt; Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tdDY3cXUiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImIxNGI4YWE3LWJiOTgtMTFlNS1iNjhjLTA4MDAyN2FkY2NhZiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.HhPnit7Sfv-yUkMW6Cy9ZVbuiV2wt5PLaPSP-uZtaByOPagkb8d-8zBQE8Lx53lqxMFwBmjjxSWl-vKtSGa0ka6rEkq_xWtFJb8uDDlxz_R63R6IJBWB8YhwB7SzPVWgtHohj55D3pL8-r8NOQSQVXFAHaiGTlzmtwiE3CmJv3yBzBLALG0yvtW2YgwrO9jlxCGdFIOKae-5eduiOyZHUimxAgfBkbwSNfSzXYZTJNryfPiDBKZybh9c3Wd-pNsSZyw9gbBhbGFM7EiK9pWsdViQ__fZA2JbxX78YbajWE6CeL4FWLKFu4MuIlnmhLOvOXia_9WXz1B8XJ-MlzclZQ
  &gt; 
  &lt; HTTP/1.1 200 OK
  &lt; Content-Type: application/json
  &lt; Date: Fri, 15 Jan 2016 16:37:40 GMT
  &lt; Content-Length: 171
  &lt; 
  {
    "kind": "ServiceList",
    "apiVersion": "v1",
    "metadata": {
      "selfLink": "/api/v1/namespaces/default/services",
      "resourceVersion": "1518"
    },
    "items": []
  }
  * Connection #0 to host 10.245.0.1 left intact
  </code></pre>
  
  <p>What's confusing me is that the configuration is the same in both cases except that the node components have been installed into the master, which makes me think it is not a misconfiguration of ssl/https so much as it is something to do with the kubernetes network configuration.</p>
  
  <p>I've looked into the logs of the apiserver but I can't see anything related to these dropped connections. </p>
  
  <p>Any help would be greatly appreciated.</p>