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 pod sandbox image to runtime API #934

Closed
saschagrunert opened this Issue Apr 4, 2019 · 10 comments

Comments

Projects
None yet
4 participants
@saschagrunert
Copy link

saschagrunert commented Apr 4, 2019

Enhancement Description

  • One-line enhancement description (can be used as a release note): The flag --pod-infra-container-image works now for remote runtimes, too. The CRI sends the configured container image to the runtime, which can use it as infra container. Configured remote runtimes have to support this feature and decide on their own if they use it or not.
  • Kubernetes Enhancement Proposal: kubernetes/kubernetes#76144
  • Primary contact (assignee): @saschagrunert
  • Responsible SIGs: sig-node
  • Enhancement target:
    • Stable release target (1.15)
@saschagrunert

This comment has been minimized.

Copy link
Author

saschagrunert commented Apr 4, 2019

/sig node

@k8s-ci-robot k8s-ci-robot added sig/node and removed needs-sig labels Apr 4, 2019

@saschagrunert

This comment has been minimized.

Copy link
Author

saschagrunert commented Apr 4, 2019

@dchen1107 @derekwaynecarr May I ask you what you think about this proposal? :)

@saschagrunert

This comment has been minimized.

Copy link
Author

saschagrunert commented Apr 4, 2019

/kind api-change

@liggitt

This comment has been minimized.

Copy link
Member

liggitt commented Apr 5, 2019

kubernetes/kubernetes#76144 is not a proposal. A design proposal would provide motivation and design details to allow for discussing whether this is something that makes sense to do.

I'll defer to sig-node, but my first thought is that the pause container is an implementation detail, not something fundamental (which is why it hasn't been exposed by an API before). What are the implications for container runtimes that use a different method for reserving a network/ipc namespace for the API-specified containers? Are they now required to run the specified pause container as well?

@saschagrunert

This comment has been minimized.

Copy link
Author

saschagrunert commented Apr 5, 2019

What are the implications for container runtimes that use a different method for reserving a network/ipc namespace for the API-specified containers? Are they now required to run the specified pause container as well?

From my point of view there should be no requirement for the runtime to use it, but it should be preferred. The change is more about making the cluster configuration more consistent in mixed runtime environments. I think the chosen sandbox image for pods belongs to the configuration scope of the kubelet and should not only apply to docker.

@liggitt

This comment has been minimized.

Copy link
Member

liggitt commented Apr 5, 2019

I think the chosen sandbox image for pods belongs to the configuration scope of the kubelet

I'd expect it to be more the configuration scope of the CRI. For example: https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioimage-table

@liggitt

This comment has been minimized.

Copy link
Member

liggitt commented Apr 5, 2019

In any case, this is the sort of discussion that should happen on an actual design proposal

@saschagrunert

This comment has been minimized.

Copy link
Author

saschagrunert commented Apr 5, 2019

I'd expect it to be more the configuration scope of the CRI. For example: https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioimage-table

Yeah currently it is. I think it has to be decided where the responsibility lies regarding the pause image. But If you say it clearly belongs to the configuration of the runtime I am open to withdraw this here.

@kacole2

This comment has been minimized.

Copy link
Member

kacole2 commented Apr 11, 2019

@liggitt thanks for responding here.
Hello @saschagrunert, I'm the Enhancement Lead for 1.15. No feature will be included without a KEP. I see you have a design proposal but there needs to be a proper KEP created and accepted. Instructions
In addition, features cannot go straight to stable without going through graduation criteria which is what the KEP should outline. I'm not going to add this to the 1.15 tracking until we have some of the criteria met. Please give me a nod when it's ready to be included.

@saschagrunert

This comment has been minimized.

Copy link
Author

saschagrunert commented Apr 21, 2019

Closing for sake of wrong scope.

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.