Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes cannot run pods without access to public internet #1545

Closed
smarterclayton opened this issue Oct 2, 2014 · 3 comments · Fixed by #1546
Closed

Kubernetes cannot run pods without access to public internet #1545

smarterclayton opened this issue Oct 2, 2014 · 3 comments · Fixed by #1546
Labels
area/kubelet kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/node Categorizes an issue or PR as relevant to SIG Node.

Comments

@smarterclayton
Copy link
Contributor

For environments that cannot access the DockerHub (banks, secure sites), there is no way to even run Kubernetes because you can't pull "kubernetes/pause".

A solution is probably a combination of changing the policy (#1458) for the net container (don't pull if it already exists?) as well as allowing the kubelet to be started with a parameter or env var for which image to use instead of kubernetes/pause:latest ("myregistry:5000/pause/latest").

Since we have people hitting this now I'm going to try to fix both - any potential issues folks see with that?

@smarterclayton smarterclayton added kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. area/kubelet labels Oct 2, 2014
@smarterclayton
Copy link
Contributor Author

(treating this as a bug because public internet access is surprisingly restricted)

@jbeda
Copy link
Contributor

jbeda commented Oct 2, 2014

I've been thinking about this in the context of binary deploys. I'd like to do development on a plane :)

If we run a registry with each cluster (#1319) we could build and do a "docker export" of the pause image as part of building the distribution. We could then "docker import" that into the cluster registry as part of cluster spin up.

We'll will probably want to be able to ship container images around outside of a central registry. This gets more complicated the larger those images get. If we do really-static golang binaries it should be small enough to be workable.

@brendandburns
Copy link
Contributor

At the very least, making the specific container to use as the 'pause'
container flaggable is probably a good idea, then people could substitute
their own private image.

--brendan

On Thu, Oct 2, 2014 at 11:33 AM, Joe Beda notifications@github.com wrote:

I've been thinking about this in the context of binary deploys. I'd like
to do development on a plane :)

If we run a registry with each cluster (#1319
#1319) we could
build and do a "docker export" of the pause image as part of building the
distribution. We could then "docker import" that into the cluster registry
as part of cluster spin up.

We'll will probably want to be able to ship container images around
outside of a central registry. This gets more complicated the larger those
images get. If we do really-static golang binaries it should be small
enough to be workable.


Reply to this email directly or view it on GitHub
#1545 (comment)
.

smarterclayton added a commit to smarterclayton/kubernetes that referenced this issue Oct 2, 2014
Public access to the DockerHub is not guaranteed in all environments,
add a flag to the kubelet that allows it to use a different image (like
one on a private registry) as well as only pull the first time the
image is needed.

Fixes kubernetes#1545
@dchen1107 dchen1107 added the sig/node Categorizes an issue or PR as relevant to SIG Node. label Feb 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubelet kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/node Categorizes an issue or PR as relevant to SIG Node.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants