-
Notifications
You must be signed in to change notification settings - Fork 40k
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 init containers to pods #23567
Add init containers to pods #23567
Conversation
I would have preferred #831 first. |
@@ -1429,6 +1429,20 @@ type PodSpec struct { | |||
// List of volumes that can be mounted by containers belonging to the pod. | |||
// More info: http://releases.k8s.io/HEAD/docs/user-guide/volumes.md | |||
Volumes []Volume `json:"volumes,omitempty" patchStrategy:"merge" patchMergeKey:"name"` | |||
// List of initialization containers belonging to the pod. | |||
// Init containers are executed in order prior to containers being started. If any | |||
// init container fails, the pod is considered to have failed and is handled according |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failed pods aren't restarted by Kubelet. Only failed containers are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok. Not the approach I'd recommend for initializing volumes. |
Specifically because? I'm envisioning the "filling volumes" usecase
|
For our use case 831 is less useful because we have no way to block
one container on another from the outside. What specifically around
831 makes it more useful? The FUSE / arbitrary volume implementation
use case?
|
Opened a proposal under #23666, this is a prototype PR until that is approved. |
da6275a
to
ae88cc1
Compare
7a1bc1b
to
a94f4d3
Compare
8b5c1aa
to
4c1c393
Compare
|
Also
All sorts of goodness this weekend. |
b289fc6
to
321abb6
Compare
Found a failure mode (caught by the e2e test checking the message) - init containers are only ready when they have a recorded container that is terminated with exit code 0. Was introduced in the status rebase (the new code was incorrect, the old code was correct). PTAL. |
@k8s-bot test this github issue: #IGNORE (bot got stuck last night) |
@k8s-bot test this issue #IGNORE (node e2e never started, looks like job was terminated early). |
I guess kubelet though it was ready because of the absence of a probe in the previous version. LGTM, feel free to re-apply label when you've squashed the last fix commit. |
321abb6
to
2a53330
Compare
GCE e2e build/test passed for commit 2a53330. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 2a53330. |
Automatic merge from submit-queue |
Congratulations to all! |
I need to update the proposal and merge it. On Wed, May 18, 2016 at 9:02 AM, Prashanth B notifications@github.com
|
Best way to get agreement on any proposal |
Shipping code wins. On Wed, May 18, 2016 at 12:55 PM, Prashanth B notifications@github.com
|
Automatic merge from submit-queue Proposal for implementing init containers Addresses #1589. Implemented in #23567. Docs in kubernetes/website#679 ```release-note Init containers enable pod authors to perform tasks before their normal containers start. Each init container is started in order, and failing containers will prevent the application from starting. ```
This implements #1589 as per proposal #23666
Incorporates feedback on #1589, creates parallel structure for InitContainers and Containers, adds validation for InitContainers that requires name uniqueness, and comments on a number of implications of init containers.
This is a complete alpha implementation.
This change is