Lift the need for explicit master IP + credentials

[opaugam]

Not sure how this works but POST 10.0.0.2 over TLS does not let me in, meaning I can't do stuff in the cluster from within a pod (which sucks).

[satoshi75nakamoto]

@opaugam have you looked at: kubernetes/kubernetes#7101 yet?

When it lands, you'll be able to create a "my-pod-creator" service account, and use that identity to authenticate to the https endpoint.

[stphung]

@opaugam would this be why an image I am using which depends on paugamo/pod is blocking on a curl call to the k8s RO service?

ps shows the following:

curl -f http://10.0.0.1/api/v1beta3/namespaces/default/pods/ochopod.default.hello-ochopod-2015-05-05-23-13-22-tvzdo

Eventually this leads to a timeout

[satoshi75nakamoto]

@stphung did you ever get this working correctly?

[stphung]

@preillyme I didn't, the RO service isn't reachable from within a container from what I could tell which makes it difficult to implement the ochopod interfaces. We haven't tried looking around to see if there are any other alternatives on how we can bridge this gap yet.

[satoshi75nakamoto]

@stphung have you seen this issue: kubernetes/kubernetes#4567

Now that the "secrets" type has been merged, and we have namespaces, It doesn't make sense to give blanket readonly access to objects. So, it's been deprecated.

So, there's now a flag added to the master that disables its creation. If you need it we can tell you how to get it back, but we discourage new uses.

Once service-accounts lands, we can give people that need it a way to automatically generate policy and credentials for things in pods. So then we can delete kubernetes-ro altogether.