4 ms·

>Anyone know why this is? Or, for that matter, why Kubernetes seems to work like this too? Pods are specifically not wanted to be treated as vms, but as a sing

>Anyone know why this is? Or, for that matter, why Kubernetes seems to work like this too? Pods are specifically not wanted to be treated as vms, but as a single application/deployment units. Among other things, if a container goes down you don’t know if it corrupted shared state (leaving sockets open or whatever). So you don’t know if the pod is healthy after restart. Also reviving it might not necessarily work, if the original startup process relied on some boot order. So to guarantee a return to healthy you need to restart the whole thing.

amluto 10mo ago
> Among other things, if a container goes down you don’t know if it corrupted shared state (leaving sockets open or whatever). This is not a thing. A program that opens a socket and crashes does not leak that socket for the lifetime of the network namespace. (Keep in mind that ordinary non-containerized servers usually have exactly one network namespace. If a program crashes, you restart it. Sure, CLOSE_WAIT is a thing, but it’s neither permanent nor usually a big deal.)
- torben-friis 10mo ago
  Fair, it was probably a bad specific example. The general point remains that a container can leave behind inconsistent state (lockfiles, application level stuff in shared volumes, whatever). The larger point is that if something broke by container going down, it is not necessarily solved just by container going back up. Satisfying boot order requirements is another example. The system relies on the "pod healthy/not healthy" contract, with pod-level restart as a fix when unhealthy; Introducing a spectrum of readyness like 'half-broken-but-internally-attempting-rebuild' would make everything more complex, both for the orchestrator deciding when to reset, and for the dev who no longer has a single point of entry for 'make sure that we're ready to go'.
  - amluto 10mo ago
    I’m talking specifically about network namespaces. There are no lockfiles there. There may or may not be a “boot order” but this would be strictly the order of startup of containers within that netns/pod.

amluto 10mo ago

> Among other things, if a container goes down you don’t know if it corrupted shared state (leaving sockets open or whatever). This is not a thing. A program that opens a socket and crashes does not leak that socket for the lifetime of the network namespace. (Keep in mind that ordinary non-containerized servers usually have exactly one network namespace. If a program crashes, you restart it. Sure, CLOSE_WAIT is a thing, but it’s neither permanent nor usually a big deal.)

torben-friis 10mo ago
Fair, it was probably a bad specific example. The general point remains that a container can leave behind inconsistent state (lockfiles, application level stuff in shared volumes, whatever). The larger point is that if something broke by container going down, it is not necessarily solved just by container going back up. Satisfying boot order requirements is another example. The system relies on the "pod healthy/not healthy" contract, with pod-level restart as a fix when unhealthy; Introducing a spectrum of readyness like 'half-broken-but-internally-attempting-rebuild' would make everything more complex, both for the orchestrator deciding when to reset, and for the dev who no longer has a single point of entry for 'make sure that we're ready to go'.
- amluto 10mo ago
  I’m talking specifically about network namespaces. There are no lockfiles there. There may or may not be a “boot order” but this would be strictly the order of startup of containers within that netns/pod.