On my cluster (launched from ~head today) running on GCE, this works fine both from a node in the cluster and from inside the fluentd-elasticsearch:1.5 container running on the node:

$ sudo docker exec -i -t 981869 bash
root@fluentd-elasticsearch-kubernetes-minion-685r:/# curl --insecure -H "Authorization: Bearer REDACTED" https://10.0.0.2/validate
[
  {
    "component": "controller-manager",
    "health": "success",
    "msg": "ok",
    "err": "nil"
  },
  {
    "component": "scheduler",
    "health": "success",
    "msg": "ok",
    "err": "nil"
  },
  {
    "component": "etcd-0",
    "health": "success",
    "msg": "{\"action\":\"get\",\"node\":{\"dir\":true,\"nodes\":[{\"key\":\"/registry\",\"dir\":true,\"modifiedIndex\":3,\"createdIndex\":3}]}}\n",
    "err": "nil"
  },
  {
    "component": "node-0",
    "health": "success",
    "msg": "ok",
    "err": "nil"
  },
  {
    "component": "node-1",
    "health": "success",
    "msg": "ok",
    "err": "nil"
  },
  {
    "component": "node-2",
    "health": "success",
    "msg": "ok",
    "err": "nil"
  },
  {
    "component": "node-3",
    "health": "success",
    "msg": "ok",
    "err": "nil"
  }
]

Mmh interesting - the same does not work from a cluster running on AWS & setup via the installer (wget -q -O - https://get.k8s.io | bash).

Is there any provider-specific constraint accessing 10.0.0.2 ? Curling the RO service from within a pod was working great on 0.15 (including AWS) btw.

I don't have access to an AWS cluster. Maybe @justinsb could test it out and see if he can reproduce the failure?

This was recently broken, but I should have fixed it in #7678. Do you know if the version you're running includes that patch?

Note that you have to use a bearer token now for auth (which you can get from a secrets volume whose name I can track down for you if you're not already doing this!)

mh ok thanks for heads up ! I'll retry over the weekend - is the secrets volume goodness described somewhere in the docs ? I can hunt for it..

I found some docs here: #7979

It does sound like maybe this isn't the official way to get a bearer token!

looks purr-fect to me - giving it a try.. thanks !

Mh i think i'm going to wait for #7101 to land instead. Sounds more like the way it should be.

service API @ 10.0.0.2

You should be using the env vars KUBERNETES_RO_SERVICE_HOST and KUBERNETES_RO_SERVICE_PORT, not the ip address directly-- IP address is not guaranteed to be that in every cluster.

But we're deprecating that, anyway-- you already found #7101; also see #5921.

(closing because the other issues mentioned cover this)