github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-09-13 13:14:05 +00:00
Code Issues Projects Releases Wiki Activity

automated link fixes

Browse Source
This commit is contained in:
Mike Danese
2015-07-14 09:37:37 -07:00
parent 14c3fc5afe
commit 3eff8fce41
96 changed files with 287 additions and 287 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/design/resources.md
View File

@@ -13,7 +13,7 @@ certainly want the docs that go with that version.</h1>
<!-- END MUNGE: UNVERSIONED_WARNING -->
**Note: this is a design doc, which describes features that have not been completely implemented.
User documentation of the current state is [here](../compute-resources.md). The tracking issue for
User documentation of the current state is [here](../user-guide/compute-resources.md). The tracking issue for
implementation of this model is
[#168](https://github.com/GoogleCloudPlatform/kubernetes/issues/168). Currently, only memory and
cpu limits on containers (not pods) are supported. "memory" is in bytes and "cpu" is in
@@ -163,7 +163,7 @@ The following are planned future extensions to the resource model, included here
## Usage data
Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, such as [Pods](../pods.md) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.
Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, such as [Pods](../user-guide/pods.md) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.
Singleton values for observed and predicted future usage will rapidly prove inadequate, so we will support the following structure for extended usage information: