diff options
| author | Kubernetes Submit Queue <k8s-merge-robot@users.noreply.github.com> | 2016-09-03 09:11:15 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-09-03 09:11:15 -0700 |
| commit | f1f7f2e6f42e198ac7c8d1257068dddc14b01aad (patch) | |
| tree | 7e24c46de21e66e9d5d7915a5d4e2d65ef821ddf | |
| parent | 9bff312b3dccd8de754cce77f4cda0627c0f484f (diff) | |
| parent | 40d31aca4282817172fc90c912d4285e6945942b (diff) | |
Merge pull request #31861 from YuPengZTE/devNote
Automatic merge from submit-queue
The first letter is small
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
<!-- Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access)
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`.
-->
```release-note
```
| -rw-r--r-- | resource-qos.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/resource-qos.md b/resource-qos.md index af84b648..b2a43c97 100644 --- a/resource-qos.md +++ b/resource-qos.md @@ -228,7 +228,7 @@ Pod OOM score configuration - OOM_SCORE_ADJ: -998 *Kubelet, Docker* - OOM_SCORE_ADJ: -999 (won’t be OOM killed) - - Hack, because these critical tasks might die if they conflict with guaranteed containers. in the future, we should place all user-pods into a separate cgroup, and set a limit on the memory they can consume. + - Hack, because these critical tasks might die if they conflict with guaranteed containers. In the future, we should place all user-pods into a separate cgroup, and set a limit on the memory they can consume. ## Known issues and possible improvements |
