Support multiple image types, e.g. OCI

[euank]

Description

Currently, a Kubernetes Pod's containers are assumed to be Docker images (and to use Docker's discovery).

However, with the progress of the OCI Image Spec, the inclusion of the rkt runtime (which supports docker, OCI, and ACI images), it's clear that now is a good time to consider making it possible to run additional formats.

Existing discussion of this feature have already shown demand and intent to address it eventually, just not urgency.

Ref: An old proposal, a user's request, and a bit more discussion.

This issue could also relate to generalizing image transport (ref kubernetes/kubernetes#15484), but does not necessarily have to.

Progress Tracker

• Before Alpha
  • Write and maintain draft quality doc
    • During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: DOC-LINK
  • Design Approval
    • Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: PROPOSAL-NUMBER
    • Initial API review: PR-NUMBER
    • My Shepherd is: (waiting to be found)
    • My Secondary Contact Point is: (@euank, pending shepherd)
  • Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS
    • Code needs to be disabled by default. Verified by code OWNERS
    • Minimal testing
    • Minimal docs
    • Update release notes
• Before Beta
  • Testing is sufficient for beta
  • User docs with tutorials
    • Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
  • Thorough API review
• Before Stable
  • docs/proposals/foo.md moved to docs/design/foo.md
  • Soak, load testing
  • detailed user docs and examples

FEATURE_STATUS: PENDING

Note: This feature does not currently have a shepherd and it is likely it will not make the v1.4 milestone. I think tentatively marking it v1.5 and trying to get a shepherd and initial proposal a little before the v1.4 release would be a good thing to shoot for.

[idvoretskyi]

@euank @philips folks, have you found the appropriate person to be an assignee?
Are we expecting to have it in 1.4 or in 1.5 (as you mentioned in a note below)?

[soltysh]

I might find some time to help abstracting the kubelet interface which allows accessing different runtimes.

[luxas]

/sub

This is interesting

[idvoretskyi]

@euank @philips any updates on this issue (regarding the responsible SIG, assignee and expected milestone data)?

[euank]

Nothing yet, sorry! I'll hop on a @kubernetes/sig-apps meeting and see if they're interested and, failing at that, I can try to get together a proposal myself.

[adohe-zz]

/cc

[bgrant0607]

@euank The original issue was kubernetes/kubernetes#7203. I can't attend SIG Apps at its current meeting time, but please notify me on any proposal and email me directly, since this presents a tricky backward-compatibility issue for the API.

[idvoretskyi]

@euank thank you for the update!

[euank]

With no takers at this point, I think this is definitely something to bump to 1.5.

We should shoot for having an initial proposal out before 1.4 ships to have a good shot at getting an alpha in 1.5.

[dchen1107]

Do we have the initial proposal ready yet?

[philips]

@dchen1107 We have the old proposal: kubernetes/kubernetes#18308. CoreOS will not have time to do this work in v1.5 either. Can someone else take this up?

[idvoretskyi]

@dchen1107 @kubernetes/sig-node can you clarify the actual status of the feature?

[spiffxp]

@euank @idvoretskyi this needs an alpha-in-1.5, beta-in-1.5, or stable-in-1.5 label if it's going to be included in release notes for kubernetes 1.5; it has no stage listed in this spreadsheet... if it's not going into 1.5, we should remove it from that spreadsheet (yay multiple information sources)

[euank]

De-milestoned, it didn't get picked up in this release. It can be removed from the spreadsheet.

[idvoretskyi]

@euank are you going to continue working on this for the future releases?

[euank]

I don't plan to work on this, though I'd be happy to help review/guide anyone who wants to.

[philips]

Testing and supporting this should be easier now that the Amazon ECR product publicly support OCI Image Spec: https://groups.google.com/a/opencontainers.org/d/msg/dev/ajYuSUnHhXY/ZRMd7XuNBQAJ

[idvoretskyi]

@euank any progress is expected on this feature? If yes, please update the feature description with the new template.

[luxas]

@euank Is this relevant anymore with CRI?

[euank]

Yes, it's relevant. It's entirely independent of CRI.

I'm not currently working on it nor do I know of anyone who is, but with the OCI image spec nearing 1.0, it's possible this'll be more important, cc @philips

[idvoretskyi]

So, any updates on this? Is the progress still expected or this issue has to be closed? @kubernetes/sig-node-feature-requests @calebamiles

[philips]

Update on this, OCI has hit v1.0: https://www.opencontainers.org/blog/2017/07/19/oci-v1-0-bringing-containers-closer-to-standardization

[idvoretskyi]

@philips woohoo!

Will this feature be updated for 1.8?

[philips]

@idvoretskyi Someone needs to do the work to make APIs take an image type field or content-type.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[idvoretskyi]

@yujuhong are you expecting any progress on this feature?

[yujuhong]

@yujuhong are you expecting any progress on this feature?

Nope. The feature has not been implemented yet, so I removed the lifecycle/stale label.
If the policy of the features repository is to not keep inactive (i.e., not being actively worked on) features, feel free to close this instead.

[idvoretskyi]

@yujuhong correct, we'd like to keep here only actively developed features.

Closing now, feel free to reopen anytime when you'll be ready.