Disable restart of containers in multi-container pods
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--> **Is this a request for help?** (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No **What keywords did you search in Kubernetes issues before filing this one?** (If you have found any duplicates, you should instead reply there.): multi, restart, liveness, restart --- **Is this a BUG REPORT or FEATURE REQUEST?** (choose one): Feature request <!-- If this is a BUG REPORT, please: - Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: - Describe *in detail* the feature/behavior/change you'd like to see. Pods managed by a ReplicationController only allows a restart policy of "Always". When a container in a multi-container pod managed by a ReplicationController crashes, the crashed container is restarted in the existing pod without notifying or restarting the other pods. I'd like to have a way to specify that *any* container crash in the pod should take down and replace the entire pod or at least restart all the other containers. Our use case is as follows: Pods consists of a worker container exposing gRPC APIs (let's call it container A) and a utility container (container B). Container B is connected to a Kubernetes HTTP liveness probe. When that probe is called, A makes a series of gRPC calls to
Posted by madspaulin on Feb 3, 2017, 5:54 AM
Tags
Related issues
- ⚠️ PHP CVEs. Update required!
- I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
- RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
- v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
- I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
- [FEATURE] Link a source control repo as the source for organization skills
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
reliability (Sysadmin)
⚠️ PHP CVEs. Update required!
I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
[FEATURE] Link a source control repo as the source for organization skills
Feature Request: Option to disable paste text collapse in input field
We went down the WASM sandboxing rabbit hole at Gobii when building our agent infra.
Disable restart of containers in multi-container pods
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--> **Is this a request for help?** (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No **What keywords did you search in Kubernetes issues before filing this one?** (If you have found any duplicates, you should instead reply there.): multi, restart, liveness, restart --- **Is this a BUG REPORT or FEATURE REQUEST?** (choose one): Feature request <!-- If this is a BUG REPORT, please: - Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: - Describe *in detail* the feature/behavior/change you'd like to see. Pods managed by a ReplicationController only allows a restart policy of "Always". When a container in a multi-container pod managed by a ReplicationController crashes, the crashed container is restarted in the existing pod without notifying or restarting the other pods. I'd like to have a way to specify that *any* container crash in the pod should take down and replace the entire pod or at least restart all the other containers. Our use case is as follows: Pods consists of a worker container exposing gRPC APIs (let's call it container A) and a utility container (container B). Container B is connected to a Kubernetes HTTP liveness probe. When that probe is called, A makes a series of gRPC calls to
Comments (0)
No comments yet. Start the discussion.