* Systemd
* Supervisor
* Manejado internamente por un proveedor de nube como parte de sus servicios
* Otros...

Te daré más ejemplos concretos en los próximos capítulos.

## Reinicios { #restarts }

De manera similar a asegurarte de que tu aplicación se ejecute al iniciar, probablemente también quieras asegurarte de que se **reinicie** después de fallos.

### Cometemos Errores { #we-make-mistakes }

### Beispieltools zum automatischen Neustart { #example-tools-to-restart-automatically }

In den meisten Fällen wird dasselbe Tool, das zum **Ausführen des Programms beim Hochfahren** verwendet wird, auch für automatische **Neustarts** verwendet.

Dies könnte zum Beispiel erledigt werden durch:

* Docker
* Kubernetes
* Docker Compose

* Systemd
* Supervisor
* Gerenciado internamente por um provedor de nuvem como parte de seus serviços
* Outros...

Darei exemplos mais concretos nos próximos capítulos.

## Reinicializações { #restarts }

Semelhante a garantir que seu aplicativo seja executado na inicialização, você provavelmente também deseja garantir que ele seja **reiniciado** após falhas.

### Nós cometemos erros { #we-make-mistakes }

///

Alternativ könnte HTTPS von einem Cloud-Anbieter als einer seiner Dienste gehandhabt werden (während die Anwendung weiterhin in einem Container ausgeführt wird).

## Beim Hochfahren ausführen und Neustarts { #running-on-startup-and-restarts }

Normalerweise gibt es ein anderes Tool, das für das **Starten und Ausführen** Ihres Containers zuständig ist.

///

Alternativamente, HTTPS podría ser manejado por un proveedor de la nube como uno de sus servicios (mientras que la aplicación aún se ejecuta en un contenedor).

## Ejecutar en el Inicio y Reinicios { #running-on-startup-and-restarts }

Normalmente hay otra herramienta encargada de **iniciar y ejecutar** tu contenedor.

Podría ser **Docker** directamente, **Docker Compose**, **Kubernetes**, un **servicio en la nube**, etc.

Alternativamente, o HTTPS poderia ser tratado por um provedor de nuvem como um de seus serviços (enquanto ainda executasse o aplicativo em um contêiner).

## Executando na inicialização e reinicializações { #running-on-startup-and-restarts }

Normalmente, outra ferramenta é responsável por **iniciar e executar** seu contêiner.

Ela poderia ser o **Docker** diretamente, **Docker Compose**, **Kubernetes**, um **serviço de nuvem**, etc.

## Changelog since v1.32.0

## Urgent Upgrade Notes 

### (No, really, you MUST read this before you upgrade)

- Fixed a race condition that could result in erroneous volume unmounts for flex volume plugins during kubelet restart. ([#127669](https://github.com/kubernetes/kubernetes/pull/127669), [@olyazavr](https://github.com/olyazavr))
- Fixed a race condition that could result in erroneous volume unmounts for flex volume plugins on kubelet restart. ([#128495](https://github.com/kubernetes/kubernetes/pull/128495), [@olyazavr](https://github.com/olyazavr))

- Added the `ChangeContainerStatusOnKubeletRestart` feature gate, which defaults to disabled. When the feature gate is disabled, `kubelet` does not change the Pod status upon restart, and Pods do not re-run startup probes after the `kubelet` restarts. ([#134746](https://github.com/kubernetes/kubernetes/pull/134746), [@HirazawaUi](https://github.com/HirazawaUi)) [SIG Node and Testing]

- Added a mechanism for configurable container restarts: _container-level restart rules_. This was an alpha feature behind the `ContainerRestartRules` feature gate. ([#132642](https://github.com/kubernetes/kubernetes/pull/132642), [@yuanwang04](https://github.com/yuanwang04)) [SIG API Machinery, Apps, Node and Testing]...