Skip to content
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 documentation for disk based eviction #1196

Merged
merged 1 commit into from
Sep 21, 2016
Merged

Add documentation for disk based eviction #1196

merged 1 commit into from
Sep 21, 2016

Conversation

derekwaynecarr
Copy link
Member

@derekwaynecarr derekwaynecarr commented Sep 9, 2016

Documents new features in eviction.


This change is Reviewable

@derekwaynecarr
Copy link
Member Author

/cc @vishh @ronnielai

@devin-donnelly
Copy link
Contributor

:lgtm:


Review status: 0 of 1 files reviewed at latest revision, all discussions resolved.


Comments from Reviewable


In future releases, the `kubelet` will support the ability to trigger eviction decisions based on disk pressure.
Each of the above signals support either a literal or percentage based value. The percentage based value
is calculated relative to the total capacity associated with each signal.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this hold for memory.available too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. it holds for all the things.

@timstclair
Copy link

Review pass complete.

### How kubelet ranks pods for eviction in response to inode exhaustion

At this time, it is not possible to know how many inodes were consumed by a particular container. If the `kubelet` observes
inode exhaustion, it will evict pods by ranking them by quality of service. The following issue has been opened in cadvisor
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does it rank pods in the same QoS class?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is addressed under "Known issues" section "How kubelet ranks pods for eviction in response to inode exhaustion", in the future, we want it to rank by consumption when we can know it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be clear, it does not differentiate within a class, so its random.

@vishh
Copy link
Contributor

vishh commented Sep 12, 2016

Review status: 0 of 1 files reviewed at latest revision, 12 unresolved discussions.


docs/admin/out-of-resource.md, line 40 [r1] (raw file):

Previously, timstclair (Tim St. Clair) wrote…

Does this hold for memory.available too?

My understanding is yes. Relevant code [here](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/eviction/helpers.go#L183)

docs/admin/out-of-resource.md, line 49 [r1] (raw file):

`imagefs` is optional. `kubelet` auto-discovers these filesystems using cAdvisor.  `kubelet` does not care about any 
other filesystems. Any other types of configurations are not currently supported by the kubelet. For example, it is
*not OK* to store volumes and logs in a dedicated `imagefs`.

nit: dedicated filesystem instead of imagefs.


docs/admin/out-of-resource.md, line 52 [r1] (raw file):

Previously, yujuhong (Yu-Ju Hong) wrote…

Garbage collection (for both image and containers) is more aggressive than the disk eviction AFAIK. For example, it deletes containers associated with deleted pods, and it also ensure we kept no more than N containers per (pod, container) tuple. Is the plan to fold garbage collection into eviction?

Yes. The plan is to only expose evictions as the feature to end users. GC will be an internal implementation detail.

docs/admin/out-of-resource.md, line 72 [r1] (raw file):

Previously, timstclair (Tim St. Clair) wrote…

Where are these specified? I assume there's a flag / config for it somewhere? What are the defaults?

--eviction-hard is defaulted [here](https://github.com/kubernetes/kubernetes/blob/7523669699be96c49faddc3e7be83d2eae56360e/pkg/apis/componentconfig/v1alpha1/defaults.go#L331). In v1.5 disk evictions will also become opt-out in upstream. Meanwhile, k8s clusters on GCE/GKE already have disk evictions as opt-opt.

docs/admin/out-of-resource.md, line 181 [r1] (raw file):

The `kubelet` responds differently to disk based eviction thresholds if the machine has a
dedicatd `imagefs` configured for the container runtime.

nit: typo - dedicated


docs/admin/out-of-resource.md, line 223 [r1] (raw file):

Previously, timstclair (Tim St. Clair) wrote…

Is this specific to disk-based evictions?

Nope. +1 for moving to a separate section

docs/admin/out-of-resource.md, line 247 [r1] (raw file):

The default `eviction-minimum-reclaim` is `0` for all resources.

What about documentation on inodes based eviction behavior?


docs/admin/out-of-resource.md, line 328 [r1] (raw file):

Previously, yujuhong (Yu-Ju Hong) wrote…

I like simplifying the configuration, just one question. Will eviction only happen when the threshold is met? More aggressive, periodic cleanup, seems desirable IMO.

I assume you are referring to container GC. I wish we had this discussion on a k8s issue given that this feature is already in place. Container GC will eventually happen all the time once logs are pulled out of dead containers and kubelet can checkpoint outside of containers. If you were referring to image GC, there is really no need to GC images unless there is disk pressure. Image locality is helpful for pod startup latency.

docs/admin/out-of-resource.md, line 336 [r1] (raw file):

Previously, timstclair (Tim St. Clair) wrote…

(nit) I don't think this is a proposal anymore?

I don't think the rationale column is necessary here for the documentation.

docs/admin/out-of-resource.md, line 346 [r1] (raw file):

increases within that window rapidly, the `kubelet` may not observe `MemoryPressure` fast enough, and the `OOMKiller`
will still be invoked.  We intend to integrate with the `memcg` notification API in a future release to reduce this
latency, and instead have the kernel tell us when a threshold has been crossed immmediately.

It might be worth mentioning a workaround. For example, set eviction thresholds to <= 75% for example to reduce the occurrence of this issue.


Comments from Reviewable

@devin-donnelly devin-donnelly added this to the 1.4 milestone Sep 14, 2016
@devin-donnelly
Copy link
Contributor

@derekwaynecarr , have you had a chance to address the comments from @vishh and @timstclair yet?

@derekwaynecarr
Copy link
Member Author

@devin-donnelly - I am addressing feedback now.

@derekwaynecarr
Copy link
Member Author

docs/admin/out-of-resource.md, line 72 [r1] (raw file):

Previously, derekwaynecarr (Derek Carr) wrote…

they are specified as flags on the kubelet that are defined later in this doc.

this document does not define defaults.

defaults right now are specific to a commercial offering imo.

actually, we do default eviction on memory. let me update this.

Comments from Reviewable

@derekwaynecarr
Copy link
Member Author

Review status: 0 of 1 files reviewed at latest revision, 12 unresolved discussions.


docs/admin/out-of-resource.md, line 49 [r1] (raw file):

Previously, vishh (Vish Kannan) wrote…

nit: dedicated filesystem instead of imagefs.

fixing

docs/admin/out-of-resource.md, line 247 [r1] (raw file):

Previously, vishh (Vish Kannan) wrote…

What about documentation on inodes based eviction behavior?

i give details under known issues.

docs/admin/out-of-resource.md, line 346 [r1] (raw file):

Previously, vishh (Vish Kannan) wrote…

It might be worth mentioning a workaround. For example, set eviction thresholds to <= 75% for example to reduce the occurrence of this issue.

added text.

Comments from Reviewable

@derekwaynecarr
Copy link
Member Author

@vishh @timstclair -- all comments addressed. PTAL, apologies this is 30 min late.

@derekwaynecarr
Copy link
Member Author

I am also confused by Reviewable... do you know if we are going to turn it off by default now with github reviews being a thing?

@devin-donnelly
Copy link
Contributor

I would prefer to use GitHub's PR Review system from here on out; it's cleaner than Reviewable.

@devin-donnelly
Copy link
Contributor

Thanks for getting to this, @derekwaynecarr .

@timstclair
Copy link

Review status: 0 of 1 files reviewed at latest revision, 12 unresolved discussions.


docs/admin/out-of-resource.md, line 223 [r1] (raw file):

Previously, derekwaynecarr (Derek Carr) wrote…

no, its supported for any resource under pressure, but it was new to 1.4 so got collapsed into this PR. the heading depth confuses this, so i updated it, thanks.

I think the heading depth might still be wrong? Raise `Ranking pods for eviction` and the 2 subsections 1 level?

Comments from Reviewable

@vishh
Copy link
Contributor

vishh commented Sep 17, 2016

LGTM

@vishh vishh self-assigned this Sep 17, 2016
@devin-donnelly
Copy link
Contributor

Review status: 0 of 1 files reviewed at latest revision, 12 unresolved discussions.


docs/admin/out-of-resource.md, line 223 [r1] (raw file):

Previously, timstclair (Tim St. Clair) wrote…

I think the heading depth might still be wrong? Raise Ranking pods for eviction and the 2 subsections 1 level?

I think @timstclair is right--should be ### Ranking pods for eviction and #### With Imagefs and #### Without Imagefs .

Comments from Reviewable

@devin-donnelly
Copy link
Contributor

@derekwaynecarr , would you mind fixing this last comment in Reviewable about the header levels? Then I'll merge.

@derekwaynecarr
Copy link
Member Author

@devin-donnelly -- restructured, headers should be good.

@devin-donnelly
Copy link
Contributor

Looks good. Thanks! I'll merge it into 1.4.

@devin-donnelly devin-donnelly merged commit f5e6c1d into kubernetes:release-1.4 Sep 21, 2016
mikutas pushed a commit to mikutas/k8s-website that referenced this pull request Sep 22, 2022
* add emojivoto policy manifest

This PR adds a new file under `run.linkerd.io` to have a
`emojivoto` policy manifest, that is maintained and updated
based on the changes from `emojivoto.yml` manifest here.

This will make it possible to access the policy manifest from
`run.linkerd.io/emojivoto-policy.yml`

Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants