diff options
| author | Kubernetes Submit Queue <k8s-merge-robot@users.noreply.github.com> | 2016-09-27 07:32:16 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-09-27 07:32:16 -0700 |
| commit | 7ed7dd3eb37ef2ea95cc49c77a87264e9e7a32a5 (patch) | |
| tree | 5fadd5b15bf25ab2e97a4241eec3017c7b662b43 | |
| parent | 5271cf41aae7a73e7e2436323eb6e9fa1067a510 (diff) | |
| parent | 490fb6ff1e707a3665a3165af52fa68f1461bfce (diff) | |
Merge pull request #33471 from YuPengZTE/devVS
Automatic merge from submit-queue
The VS and dot is seprated
| -rw-r--r-- | access.md | 2 | ||||
| -rw-r--r-- | admission_control_resource_quota.md | 2 | ||||
| -rw-r--r-- | service_accounts.md | 4 |
3 files changed, 4 insertions, 4 deletions
@@ -254,7 +254,7 @@ In the Enterprise Profile: In the Simple Profile: - There is a single `namespace` used by the single user. -Namespaces versus userAccount vs Labels: +Namespaces versus userAccount vs. Labels: - `userAccount`s are intended for audit logging (both name and UID should be logged), and to define who has access to `namespace`s. - `labels` (see [docs/user-guide/labels.md](../../docs/user-guide/labels.md)) diff --git a/admission_control_resource_quota.md b/admission_control_resource_quota.md index 8265c9a9..4727dc0c 100644 --- a/admission_control_resource_quota.md +++ b/admission_control_resource_quota.md @@ -121,7 +121,7 @@ If a third-party wants to track additional resources, it must follow the resource naming conventions prescribed by Kubernetes. This means the resource must have a fully-qualified name (i.e. mycompany.org/shinynewresource) -## Resource Requirements: Requests vs Limits +## Resource Requirements: Requests vs. Limits If a resource supports the ability to distinguish between a request and a limit for a resource, the quota tracking system will only cost the request value diff --git a/service_accounts.md b/service_accounts.md index bef22c40..795f5212 100644 --- a/service_accounts.md +++ b/service_accounts.md @@ -113,9 +113,9 @@ system external to Kubernetes. Kubernetes does not dictate how to divide up the space of user identifier strings. User names can be simple Unix-style short usernames, (e.g. `alice`), or -may be qualified to allow for federated identity (`alice@example.com` vs +may be qualified to allow for federated identity (`alice@example.com` vs. `alice@example.org`.) Naming convention may distinguish service accounts from -user accounts (e.g. `alice@example.com` vs +user accounts (e.g. `alice@example.com` vs. `build-service-account-a3b7f0@foo-namespace.service-accounts.example.com`), but Kubernetes does not require this. |