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

Introduce kubernetes containers #112

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@DirectXMan12
Copy link

commented Jun 25, 2015

This introduces containers for both the master and node services for Kubernetes.


Copy the source Dockerfile down and do the build:
```
# docker build --rm -t <username>/kube-apiserver .

This comment has been minimized.

Copy link
@ncdc

ncdc Jul 20, 2015

No need to specify --rm - it defaults to true

@ncdc

This comment has been minimized.

Copy link

commented Jul 20, 2015

Since the 3 images share the same content, what would you think about creating a base image for the master so you only have to build it once, and then have the 3 images inherit from it, setting the entrypoint per image?

@Rio

This comment has been minimized.

Copy link

commented Jul 20, 2015

I don't think that that is really needed. When you build the images on the same machine the caching mechanism will speed up the build.

@ncdc

This comment has been minimized.

Copy link

commented Jul 20, 2015

I agree it's not necessary. But from a DRY perspective, if you want to change something in all 3 images that isn't specific to each image (e.g. change FROM fedora to FROM fedora:22), you have to do it in 3 places instead of just 1.

@Rio

This comment has been minimized.

Copy link

commented Jul 20, 2015

Agreed. Just seems a bit overkill right now when you look at the amount of config done in the Dockerfile.

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Jul 20, 2015

I'm also on the fence about whether or not it makes sense to have three separate Dockerfiles just for different entrypoints. What do you think?

@scollier

This comment has been minimized.

Copy link
Member

commented Jul 26, 2015

sorry for the delay here, I've been traveling and will be traveling next week. However, I'll try to fit a review in then.

@ncdc

This comment has been minimized.

Copy link

commented Sep 8, 2015

@scollier bump

@DirectXMan12 DirectXMan12 force-pushed the DirectXMan12:master branch from fdf2ffb to b5f959f Sep 8, 2015

@DirectXMan12 DirectXMan12 reopened this Sep 8, 2015

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Sep 8, 2015

I reworked this a bit, so that there is a "base" master and node container, with a container based on the corresponding base container for each service (e.g. the kubernetes-node container contains the kubernetes-node package, and the kubernetes-kubelet container is FROM that container, but contains further packages and details specific to kubelet)

@DirectXMan12 DirectXMan12 changed the title Introduce kubernetes-master containers Introduce kubernetes containers Sep 8, 2015

@scollier

This comment has been minimized.

Copy link
Member

commented Sep 10, 2015

reviewing now.

@scollier

This comment has been minimized.

Copy link
Member

commented Sep 10, 2015

all the images built succesfully after being tagged properly. Is there a master README that states what order these should be started in?

Introduce kubernetes-master containers
This commit introduces containers for the Kubernetes master
services.  The master container contains the requistite package(s)
for the master services.  There is a container for each service
(apiserver, controller-manager, and scheduler) that contains an
entrypoint for convinience (these containers are based off of the
master container).

@DirectXMan12 DirectXMan12 force-pushed the DirectXMan12:master branch from c623082 to 9ba9f44 Sep 10, 2015

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Sep 10, 2015

The images can be started in any order -- the other services will continue looking for the API server if they can't find it initially. Should I add a README stating that?

@scollier

This comment has been minimized.

Copy link
Member

commented Sep 10, 2015

@DirectXMan12 got it.

When launching the first container, the api server, it died out immediately:

$ docker logs cd4
F0910 13:31:48.221476       1 server.go:223] No --service-cluster-ip-range specified
@scollier

This comment has been minimized.

Copy link
Member

commented Sep 23, 2015

Hey @DirectXMan12 wanna discuss this? Happy to help troubleshoot. I didn't reply properly to your question about the README. I think the more instructions you can provide in a README, the better. Much appreciated.

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Sep 23, 2015

@scollier -- sorry about that, I though I had hit reply when you originally posted, but it appears I did not. The images have to be launched with the appropriate arguments for launching kubernetes -- for instance, in the example above, you have to specify what range of IPs you want to use for containers in the cluster. I thought I mentioned in the READMEs that you need to pass arguments for kubernetes, but I can try and clarify if it's unclear.

@scollier

This comment has been minimized.

Copy link
Member

commented Sep 23, 2015

@DirectXMan12 would help to have default options to pass in order to stand up a basic configuration. Then people can evaluate it quickly, and customize if later if needed.

Introduce kubernetes-node containers
This commit introduces containers for the Kubernetes node
services.  The node container contains the requistite package
to install the node service.  There is a container for each service
(kubelet and kube-proxy) that contain additional packages required to run
each service, as well as an atomic run label and an entrypoint for convinience
(these containers are based off of the node container).

Additionally, the non-base containers (i.e. all containers besides the
base master and node containers) have a default endpoint which pulls
configuration data from `/etc/kubernetes`.  This has the advantage of
allowing existing configuration to be reused (by mounting
`/etc/kubernetes:/etc/kubernetes:ro`), and of providing sensible
defaults when no options are given.

@DirectXMan12 DirectXMan12 force-pushed the DirectXMan12:master branch from 9ba9f44 to 25ba6a2 Sep 29, 2015

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Sep 29, 2015

@scollier I've updated the dockerfiles to pull configuration from /etc/kubernetes. If the user does not mount /etc/kubernetes themselves, the default one installed by the kubernetes-{master,node} packages will be used. This provides sensible defaults for a one-node cluster if the user wants to try out kube without specifying options. The endpoint is set up to also accept command-line options as well, so you can still pass options like that as well.

@scollier

This comment has been minimized.

Copy link

commented on kubernetes/apiserver/Dockerfile in 25ba6a2 Feb 12, 2016

Does this container still exist? I didn't see it on the Docker Hub.

@scollier

This comment has been minimized.

Copy link
Member

commented Feb 12, 2016

Hey @DirectXMan12 sorry for extremely long delay on this. If time permits for you, i'd like to work through this. Let me know. There was a thread about this on atomic-devel wanting a status. So I can def carve out some time to work through this.

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Feb 15, 2016

@scollier Yeah, I can make time to work through any issues you might have. Just let me know what works for you.

@scollier

This comment has been minimized.

Copy link
Member

commented Feb 15, 2016

@DirectXMan12

These built:

master, controller-manager, node, scheduler.

These did not build:

proxy - needs fedora/kubernetes-node image
kubelet - needs fedora/kubernetes-node image
apiserver - needs fedora/kubernetes-master image

Where are those fedora/kubernetes-* images hosted? Should we include those dockerfiles here? Are they based off of Fedora?

After I get good builds, then I can try to launch.

One other note is that for f23, we moved to dnf from yum.

@scollier

This comment has been minimized.

Copy link
Member

commented Feb 22, 2016

Hi @DirectXMan12, checking in here.

@DirectXMan12

This comment has been minimized.

Copy link
Author

commented Feb 23, 2016

Sorry, I've been super busy. I'll see if I can update the PR this week. The fedora/kubernetes-master and fedora/kubernetes-node images are intended to be built first, and then used as the foundation for the other images.

@cgwalters

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2016

Is it worth having different images for each one? It isn't too hard to specify the command in a manifest or systemd unit file ExecStart etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.