kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1200 from porridge/grammar-typo-fixes 

Automatic merge from submit-queue.

Some grammar an typo fixes.
This commit is contained in:
Kubernetes Submit Queue 2017-10-16 15:09:41 -07:00 committed by GitHub
parent 2ef8a198e9 f661e3b383
commit 73e92c1f37
2 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
sig-scalability/extending_slo.md
View File

@ -26,10 +26,12 @@ This includes current SLOs:
- API call latency - API call latency
- E2e Pod startup latency - E2e Pod startup latency
By churn we understand a measure of amount changes happening in the cluster. It's formal(-ish) definition will follow, but informally it can be thought about as number of user-issued requests per second plus number of pods affected by those requests. By churn we understand a measure of amount changes happening in the cluster. Its formal(-ish) definition will follow, but informally it can be thought about as number of user-issued requests per second plus number of pods affected by those requests.
More formally churn per second is defined as: More formally churn per second is defined as:
```
#Pod creations + #PodSpec updates + #user originated requests in a given second #Pod creations + #PodSpec updates + #user originated requests in a given second
```
The last part is necessary only to get rid of situations when user is spamming API server with various requests. In ordinary circumstances we expect it to be in the order of 1-2. The last part is necessary only to get rid of situations when user is spamming API server with various requests. In ordinary circumstances we expect it to be in the order of 1-2.
## Burst SLOs ## Burst SLOs
@ -39,8 +41,8 @@ This includes the new SLO:
- Pod startup throughput - Pod startup throughput
## Environment ## Environment
Kubernetes cluster in which we benchmark SLOs need to meet following criteria: A Kubernetes cluster in which we benchmark SLOs needs to meet the following criteria:
- Run a single master machine appropriately sized - Run a single appropriately sized master machine
- Main etcd runs as a single instance on the master machine - Main etcd runs as a single instance on the master machine
- Events are stored in a separate etcd instance running on the master machine - Events are stored in a separate etcd instance running on the master machine
- Kubernetes version is at least 1.X.Y - Kubernetes version is at least 1.X.Y
@ -60,7 +62,7 @@ All our performance SLOs should be defined using the following template:
_One-two sentences describing the SLO, that's possible to understand by the majority of the community_ _One-two sentences describing the SLO, that's possible to understand by the majority of the community_
### User Stories ### User Stories
_Few user stories showing in what situations users might be interested in this SLO, and why other ones are not enough_ _A Few user stories showing in what situations users might be interested in this SLO, and why other ones are not enough_
## Full definition ## Full definition
### Test description ### Test description

2
sig-scalability/thresholds.md
View File

@ -20,7 +20,7 @@ future or not.
## Kubernetes thresholds ## Kubernetes thresholds
We start with explicit definition of quantities and thresholds we assume are We start with explicit definition of quantities and thresholds we assume are
satisfied in the cluster. This is followed by an explanations for some of those. satisfied in the cluster. This is followed by an explanation for some of those.
Important notes about the numbers: Important notes about the numbers:
1. In most cases, exceeding these thresholds doesn’t mean that the cluster 1. In most cases, exceeding these thresholds doesn’t mean that the cluster
fails over - it just means that its overall performance degrades. fails over - it just means that its overall performance degrades.