-
Notifications
You must be signed in to change notification settings - Fork 39k
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
Container Runtime Interface/API Planning #28789
Comments
At the SIG Node meeting of July 12, 2016 there was discussion about how this issue includes adding lifecycle hooks that the Kubernetes operator can exploit for various purposes. I do not see that in the initial comment here. What am I missing? |
There will be no On Fri, Jul 15, 2016 at 8:40 AM, Mike Spreitzer notifications@github.com
|
That seems pretty heavy. |
I think wrappers would be possible, but as this is almost certainly a There is a 1:1 relationship between kubelet and the runtime. Maybe, On Fri, Jul 15, 2016 at 11:02 AM, Mike Spreitzer notifications@github.com
|
@thockin are you talking about chaining where my added functionality is in a daemon of mine that, in turn, invokes the regular daemon? If so, is there a big difference between chaining through a UNIX socket vs. chaining through a TCP socket? |
Not really. UNIX seems saner overall, wrt simple auth. On Jul 19, 2016 10:32 AM, "Mike Spreitzer" notifications@github.com wrote:
|
To clarify the "Rkt integrates with Kubernetes via the new API (?). OWNER: CoreOS." item at the end, @yujuhong We do intend to integrate as soon as we reasonably can in order to gain better feature-parity (such as exponential backoff, init containers, etc), and in order to be as well supported of a k8s runtime as we can be. Due to the design of rkt, this might end up taking a bit longer, but we're hopeful we'll be able to have an alpha integration shortly after Hyper and Docker (so Milestone 3.5 :). We would like to be able to have this integration soon enough that we can ensure the interface makes sense for us too. |
I'm adding myself as the owner of I'll try to help out with the other items as well and own some if needs be. |
cc/ @matchstick @thockin Here is the working item and planning we talked about |
Automatic merge from submit-queue Kubelet: add kubeGenericRuntimeManager for new runtime API Part of #28789. Add `kubeGenericRuntimeManager` for kubelet new runtime API #17048. Note that: - To facilitate code reviewing, #28396 is splited into a few small PRs. This is the first part. - This PR also fixes some syntax errors in `api.proto`. - This PR is depending on #29811 (already merged). CC @yujuhong @Random-Liu @kubernetes/sig-node
Automatic merge from submit-queue Kubelet: implement labels for new runtime API Implement labels for new runtime API. Part of #28789 . CC @yujuhong @Random-Liu @kubernetes/sig-node <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/kubernetes/30049) <!-- Reviewable:end -->
Automatic merge from submit-queue Kubelet: generate sandbox/container config for new runtime API Generate sandbox/container config for new runtime API. Part of #28789 . CC @yujuhong @Random-Liu @dchen1107
Automatic merge from submit-queue Kubelet: add --container-runtime-endpoint and --image-service-endpoint Flag `--container-runtime-endpoint` (overrides `--container-runtime`) is introduced to identify the unix socket file of the remote runtime service. And flag `--image-service-endpoint` is introduced to identify the unix socket file of the image service. This PR is part of #28789 Milestone 0. CC @yujuhong @Random-Liu
Automatic merge from submit-queue Kubelet: implement GetPods for new runtime API Implement GetPods for kuberuntime. Part of #28789 . CC @yujuhong @Random-Liu
Provide support for --container-runtime-endpoint and --image-service-endpoint in kubelet. Ref kubernetes#28789
Automatic merge from submit-queue Kubelet: implement GetPodStatus for new runtime API Implement `GetPodStatus()` for new runtime API. Part of #28789 . CC @yujuhong @Random-Liu @dchen1107
Automatic merge from submit-queue Add client-server runtime support to local-up-cluster.sh <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md 2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md 3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes --> **What this PR does / why we need it**: It provides support for using `--container-runtime-endpoint` and `--image-service-endpoint` arguments for kubelet in `local-up-cluster.sh` script. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: ref #28789 **Special notes for your reviewer**: **Release note**: <!-- Steps to write your release note: 1. Use the release-note-* labels to set the release note state (if you have access) 2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. --> ```release-note ``` Provide support for --container-runtime-endpoint and --image-service-endpoint in kubelet. Ref #28789
nice job! 👍 |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This issue is created to help track the progress of the container runtime interface/API. The original issue is #22964
Summary of current status
Add a new container runtime interface #25899 .
To re-iterate a bit, the goals of the API are:
The timeline is merely an estimate now and is subject to changes.
Milestone 0: v1alpha1 of container runtime API (~1 month)
The v1alpha1 API is experimental and supports the core functionalities required by kubelet/kubernetes. Once this milestone is met, developers can start implementing POCs against the API and provide feedback.
Requirements:
Milestone 1: v1alpha2, feature-complete version of the API (~1 month)
Some advanced/controversial features are not addressed in the v1alpha1 API as they require elongated discussions and potential changes to the Kubernetes API. These features should be be addressed in the v1alphaN version of the API.
These features include:
Milestone 3: Hyper and Docker integrated using runtime API/interface (~2 months)
This milestone demonstrates that the API meets the minimal requirements to support a runtime in the kubelet. Note that Docker will remain in the kubelet codebase, but will be refactored to use the internal runtime interface matching the new API.
Requirements:
The integrated runtime should pass all node conformance tests
Milestone 4: Promote the API version to beta (~N months)
Release the beta version of the API.
Requirements:
Other related issues: oci/runc integration #26788
/cc @kubernetes/sig-node @kubernetes/sig-rktnetes @thockin
The text was updated successfully, but these errors were encountered: