fleet functionality K8s does not have #945
Conversation
|
s/depricated/deprecated/ |
| @@ -0,0 +1,25 @@ | |||
| # Depricated functionality | |||
|
|
|||
| Despite their many functional similarities, some features just don't exist in in Kubernetes like they did in the fleet. | |||
pop
changed the title
|
So the last header of this doc "ExecStop" kinda does exist via the pod spec.container.lifecycle.exec. I'll mention that there's no explicit way to tell Kubernetes how to shutdown your container but you can pre-empt it with that. |
- Added information about `lifetime.preStop`. - Added information about grouping pods and handling dependencies.
|
|
||
| ## Container Dependencies | ||
|
|
||
| Using systemd service dependencies fleet is able to outline dependencies. Containers can be started in a specific order and only *after* services they depend on have begun. |
There was a problem hiding this comment.
I would de-emphasise this - it only works in a basic way when the units are colocated (i.e. intra-cluster dependencies do not work - coreos/fleet#464). It's also something that works at the systemd unit level and in itself has nothing to do with containers.
|
|
||
| [comment]: # (TODO: Include an example?) | ||
|
|
||
| ## Graceful Exit Command (ExecStop) |
There was a problem hiding this comment.
ExecStop in fleet is somewhat broken, tbh: coreos/fleet#1000. I think this also warrants calling out.
| @@ -0,0 +1,62 @@ | |||
| # Deprecated functionality | |||
|
|
|||
| Despite many functional similarities, some fleet features do not exist in Kubernetes. Thankfully there are usually workarounds for almost every use-case. | |||
There was a problem hiding this comment.
I would prefer something along the lines of "While the systems are largely similar in functionality, some specific fleet features do not have direct equivalents in Kubernetes. Fortunately, workarounds exist for almost every use case. Several of these analogues are outlined below."
|
This content seems fine. |
|
|
||
| Fleet uses systemd service dependencies to outline a *limited* dependency graph. When units are co-located then containers may be specified to start in a specific order; only beginning a service *after* others it depends on have begun. This is not really a fleet feature but rather a systemd feature; it is limited by the design and feature-set of systemd | ||
|
|
||
| While this has been [discussed at length in the Kubernetes community][pod-deps-discussion] it has not been implemented in Kubernetes as of early 2017. There are two workarounds for this in Kubernetes: |
There was a problem hiding this comment.
I think we should essentially say most use cases can be solved by crash loops on a pod and init containers. I don't think pod deps will ever be implemented.
|
|
||
| More information can be found at the [Kubernetes Pods user guide][prestop] | ||
|
|
||
| **Note:** The `preStop` directive is not a replacement for ExecStop. After a grace-period the container will still be killed via `SIGTERM`. |
There was a problem hiding this comment.
this isn't totally true. You can set the graceful shutdown time to nearly forever terminationGracePeriodSeconds
https://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod
|
superseded in #991 |
This is a work in progress. Feedback and discussion encouraged.
References documentation needed to transition toward Kubernetes from fleet.
cc: @joshix