Introduce kubernetes containers #112
Conversation
|
|
||
| Copy the source Dockerfile down and do the build: | ||
| ``` | ||
| # docker build --rm -t <username>/kube-apiserver . |
There was a problem hiding this comment.
No need to specify --rm - it defaults to true
|
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? |
|
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. |
|
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 |
|
Agreed. Just seems a bit overkill right now when you look at the amount of config done in the Dockerfile. |
|
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? |
|
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. |
|
@scollier bump |
|
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 |
DirectXMan12
changed the title
|
reviewing now. |
|
all the images built succesfully after being tagged properly. Is there a master README that states what order these should be started in? |
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
force-pushed
the
master
branch
from
c623082
to
9ba9f44
Compare
|
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? |
|
@DirectXMan12 got it. When launching the first container, the api server, it died out immediately: |
|
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. |
|
@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. |
|
@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. |
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
force-pushed
the
master
branch
from
9ba9f44
to
25ba6a2
Compare
|
@scollier I've updated the dockerfiles to pull configuration from |
|
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. |
|
@scollier Yeah, I can make time to work through any issues you might have. Just let me know what works for you. |
|
These built: master, controller-manager, node, scheduler. These did not build: proxy - needs fedora/kubernetes-node 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. |
|
Hi @DirectXMan12, checking in here. |
|
Sorry, I've been super busy. I'll see if I can update the PR this week. The |
|
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 |
This introduces containers for both the master and node services for Kubernetes.