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

Add hyper container runtime #13079

Closed
wants to merge 4 commits into from
Closed

Conversation

feiskyer
Copy link
Member

Add hyper container runtime for kubernetes.

Hyper is a Hypervisor-agnostic Docker Engine that allows you to run Docker images on any hypervisor (KVM, Xen, etc.).

Technically speaking, Hyper = Hypervisor + Kernel + Docker Image

By containing applications within separate VM instances and kernel spaces, Hyper is able to offer an excellent Hardware-enforced Isolation, which is much needed in multi-tenant environments.

Hyper also promises Immutable Infrastructure by eliminating the middle layer of Guest OS, along with the hassle to configure and manage them.

See https://hyper.sh for more documentation.

Task list:

  • hyper client
  • hyper container runtime
  • kubelet exec
  • kubelet attach
  • pull image with credentials

There will be another commit on kubelet logs, since hyper doesn't support hyper log now.

Note that host network, socat-based port-forwarding and privileged containers is not supported.

@k8s-bot
Copy link

k8s-bot commented Aug 24, 2015

Can one of the admins verify that this patch is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

@feiskyer feiskyer force-pushed the kubelet/hyper branch 4 times, most recently from 9fb80a1 to 38dbabb Compare August 24, 2015 07:39
@thockin
Copy link
Member

thockin commented Aug 24, 2015

Cool!

WRT this as a patch - I think the hardest part is going to be sure that we're happy with the interface between core kubelet and runtimes. Since it's been on my plate this week, things like the networking tie-ins to runtimes is less-than-obvious.

Now that we have potentially 3 implementations of runtime, we should pause and think about abstractions.

@feiskyer
Copy link
Member Author

@thockin The interface between core kublet and runtimes is ok except networking. Although it works well for current kubernetes networking model, it is very difficult to do things like multi-tenant networking.

@feiskyer feiskyer force-pushed the kubelet/hyper branch 2 times, most recently from 9d9ac63 to 29d9564 Compare August 26, 2015 02:01
@feiskyer feiskyer changed the title [WIP] Add hyper container runtime Add hyper container runtime Aug 26, 2015
@bgrant0607
Copy link
Member

cc @kubernetes/goog-node

@yujuhong
Copy link
Contributor

Now that we have potentially 3 implementations of runtime, we should pause and think about abstractions.

We have some pod-level abstraction in kubelet/container, but we'd like to improve them.

We probably want to discuss this PR in the node team meeting, so I am assigning it to @dchen1107 for now.

@yujuhong yujuhong added [deprecated--DO NOT USE]old-team/master sig/node Categorizes an issue or PR as relevant to SIG Node. labels Aug 26, 2015
@k8s-github-robot k8s-github-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Aug 27, 2015
@k8s-github-robot
Copy link

Labelling this PR as size/XXL

@feiskyer
Copy link
Member Author

@yujuhong @dchen1107

Have you discussed this PR in the node team meeting?

for name, volume := range volumeMap {
glog.V(4).Infof("Hyper: volume %s %s", name, volume.GetPath())
v := make(map[string]string)
v["name"] = name
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: might be good to make "name","source", etc constants to avoid magic strings all over.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pmorie Thanks for suggestion, commits updated.

@yujuhong
Copy link
Contributor

@feiskyer, @dchen1107 was out last week. We'll talk about this either today or tomorrow.

@feiskyer
Copy link
Member Author

feiskyer commented Sep 7, 2015

@thockin @dchen1107 @yujuhong What's the progress of node team meeting?

@dchen1107
Copy link
Member

Thanks for your pr, and really nice work by implementing today's Container Runtime interface. But I am hesitated to take this as is for now:

  1. I am not very happy with today's Runtime API. You must notice it already you have to duplicate most of code for SyncPod for both rkt and docker support including all those Kubernetes defined policy: StartPolicy, PullPolicy, etc. Runtime API is in today's shape due to many reasons, and it is not final one yet. One reason is mismatching network model between docker and rkt. Both docker and rkt are evolving, which help us to get right level of abstraction between Kubernetes and runtime. But not today.

  2. Can we make this as part of contrib (https://github.com/kubernetes/contrib) instead of Kubernetes core? There are many features missing here, and you already listed a bunch of them. But there should be more. How does cAdvisor integrate with this model?

  3. We are working on adding a bunch of resource management related features: such as qos, overcommit. What are the impact with this new Runtime? cc @bgrant0607 @davidopp

  4. Who should be the maintainer of this runtime? Can we have unittests for this? Can we have integration tests? Can we enable e2e for a new runtime. CoreOS rkt team is working with us closely to have all those tests I listed above. How about this one?

On another hand, I love this since I believe it could enable new usecases for the customer. Is it possible you give a demo to our community hangout every Friday 10:00am? If there are big demanding on this, we could re prioritize this?

cc/ @bgrant0607 @thockin @brendandburns

@brendandburns
Copy link
Contributor

First off, let me say that it would be awesome to have support for hyper and I would love to see a demo of this at community meeting sometime.

I think the right way forward for this PR (and other PRs like this in the future) is to implement a client/server version of the container runtime, so that container runtimes can be run outside of the kubelet process and implementations can be built in the kubernetes/contrib tree rather than the core tree.

To that end, I have filed #13768.

@feiskyer if you are up for it, we would be happy to merge an implementation of such a client/server interface (if you can build it...)

And then you can use that as the basis for integrating hyper into kubernetes. (and it can also be the basis for additional experimental container runtimes)

Let me know what you think of this, I would be happy to help with design, reviews, etc.

Best!
--brendan

@feiskyer
Copy link
Member Author

  1. I am not very happy with today's Runtime API. You must notice it already you have to duplicate most of code for SyncPod for both rkt and docker support including all those Kubernetes defined policy: StartPolicy, PullPolicy, etc. Runtime API is in today's shape due to many reasons, and it is not final one yet. One reason is mismatching network model between docker and rkt. Both docker and rkt are evolving, which help us to get right level of abstraction between Kubernetes and runtime. But not today.

I think so, there should be an abstraction that most pod management codes could be reused accross all container runtimes.

  1. Can we make this as part of contrib (https://github.com/kubernetes/contrib) instead of Kubernetes core? There are many features missing here, and you already listed a bunch of them. But there should be more. How does cAdvisor integrate with this model?

Currently, kubelet container runtime is strongly binding to Kubernetes core. I don't think it's easy to make a runtime as part of contrib. If you have any way, please tell me.

cAdvisor is not working with hyper, since hyper is vm-based. I think a new plugin/agent for Heapster is more appropriate.

  1. We are working on adding a bunch of resource management related features: such as qos, overcommit. What are the impact with this new Runtime? cc @bgrant0607 @davidopp

Hyper is still on quick evolving, more features can be added to hyper if needed.

  1. Who should be the maintainer of this runtime? Can we have unittests for this? Can we have integration tests? Can we enable e2e for a new runtime. CoreOS rkt team is working with us closely to have all those tests I listed above. How about this one?

Hyper team is the maintainer of this runtime. We could work togather on setting up all the tests needed.

On another hand, I love this since I believe it could enable new usecases for the customer. Is it possible you give a demo to our community hangout every Friday 10:00am? If there are big demanding on this, we could re prioritize this?

I could show some hyper demos on community hangout, please tell me how to join community hangout. By the way, is every Friday 10:00am US-Pacific time?

cc/ @bgrant0607 @thockin @brendandburns @dchen1107

@feiskyer
Copy link
Member Author

@brendandburns It's a great idea of making a c/s version of the container runtime and I'm very glad to be up for it.

@dchen1107
Copy link
Member

Yes, community hangout is every Friday 10:00am US-Pacific time. I can put your demo to hangout schedule. How about Sept 18th?

@feiskyer
Copy link
Member Author

@dchen1107 Time is ok, how can I join community hangout?

@dchen1107
Copy link
Member

@feiskyer
Copy link
Member Author

@dchen1107 Thanks.

@dchen1107
Copy link
Member

@feiskyer I am assuming you cannot access hangout link I provided above without any issue, and the demo is tomorrow at 10:am PST.

Also could you please send me your personal email address to dawnchen@google.com? I want to invite you to our discussion on Container Runtime interface. Thanks!

@feiskyer
Copy link
Member Author

@dchen1107 Thanks for tip, I can access hangout without any issue.

@feiskyer feiskyer force-pushed the kubelet/hyper branch 5 times, most recently from 65942fb to 5451a2e Compare September 21, 2015 01:27
Hyper is a hypervisor-agnostic docker engine, see https://hyper.sh for more documentation.
@k8s-github-robot k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 30, 2015
@k8s-github-robot k8s-github-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Dec 22, 2015
@feiskyer
Copy link
Member Author

I'm closing this because of #17048

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/node Categorizes an issue or PR as relevant to SIG Node. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants