v1.9 patch (#6690)

* Merge branch 'master' of https://github.com/kubernetes/website into release-1.9

* 'master' of https://github.com/kubernetes/website:
  [maintenance] December link fixes (#6680)
  Update audit.md (#6381)
  Fixed typo
  concepts/policy/pod-security-policy.md: fix broken links.
  Fixed a typo `illgal`
  Add glossory entry for ReplicaSet

# Conflicts:
#	docs/concepts/policy/pod-security-policy.md
#	docs/tasks/debug-application-cluster/audit.md

* Spelling correction and sentence capitalization.

- Corrected the spelling error for storing, was put in as 'stoing'.
- Capitalized list items.
- Added '.' at end of sentences in the list items.

* Workaround for Jekyllr frontmatter

* fix typo

* Update access-cluster.md with a comment that for IPv6
the user should use [::1] for the localhost

cn/docs/tutorials/stateful-application/web.yaml

@@ -1,4 +1,3 @@
----
 apiVersion: v1
 kind: Service
 metadata:

cn/docs/tutorials/stateful-application/webp.yaml

@@ -1,4 +1,3 @@
----
 apiVersion: v1
 kind: Service
 metadata:
@@ -42,4 +41,4 @@ spec:
       accessModes: [ "ReadWriteOnce" ]
       resources:
         requests:
-          storage: 1Gi
+          storage: 1Gi

cn/docs/user-guide/multi-pod.yaml

@@ -1,4 +1,3 @@
----
 apiVersion: v1
 kind: Pod
 metadata:

docs/concepts/api-extension/custom-resources.md

@@ -48,24 +48,24 @@ When creating a new API, consider whether to [aggregate your API with the Kubern
 #### Declarative APIs
 
 In a Declarative API, typically:
- - your API consists of a relatively small number of relatively small objects (resources).
- - the objects define configuration of applications or infrastructure
- - the objects are updated relatively infrequently
- - humans often need to read and write the objects
- - the main operations on the objects are CRUD-y (creating, reading, updating and deleting)
- - transactions across objects are not required: the API represents a desired state, not an exact state.
+ - Your API consists of a relatively small number of relatively small objects (resources).
+ - The objects define configuration of applications or infrastructure.
+ - The objects are updated relatively infrequently.
+ - Humans often need to read and write the objects.
+ - The main operations on the objects are CRUD-y (creating, reading, updating and deleting).
+ - Transactions across objects are not required: the API represents a desired state, not an exact state.
 
 Imperative APIs are not declarative. 
 Signs that your API might not be declarative include:
- - the client says "do this", and then gets a synchornous response back when it is done.
- - the client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request.
- - you talk about Remote Procedure Calls (RPCs)
- - directly stoing large amounts of data (e.g. > a few kB per object, or >1000s of objects)
- - high bandwidth access (10s of requests per second sustained) needed
- - store end-user data (such as images, PII, etc) or other large-scale data processed by applications
- - the natural operations on the objects are not CRUD-y.
- - the API is not easily modeled as objects.
- - you chose to represent pending operations with an operation ID or operation object.
+ - The client says "do this", and then gets a synchornous response back when it is done.
+ - The client says "do this", and then gets an operation ID back, and has to check a separate Operation objects to determine completion of the request.
+ - You talk about Remote Procedure Calls (RPCs).
+ - Directly storing large amounts of data (e.g. > a few kB per object, or >1000s of objects).
+ - High bandwidth access (10s of requests per second sustained) needed.
+ - Store end-user data (such as images, PII, etc) or other large-scale data processed by applications.
+ - The natural operations on the objects are not CRUD-y.
+ - The API is not easily modeled as objects.
+ - You chose to represent pending operations with an operation ID or operation object.
 
 ### Should I use a configMap or a custom resource?
 
@@ -102,7 +102,7 @@ Aggregated APIs are subordinate APIServers that sit behind the primary API serve
 
 Custom Resource Definitions (CRDS) allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
 
-Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods)
+Regardless of whether they are installed via CRDs or AA, the new resources are called Custom Resources to distinguish them from built-in Kubernetes resources (like pods).
 
 ## CustomResourceDefinitions
 
@@ -215,9 +215,9 @@ Kubernetes [client libraries](/docs/reference/client-libraries/) can be used to
 
 When you add a custom resource, you can access it using:
   - kubectl
-  - the kubernetes dynamic client
-  - a REST client that you write
-  - a client generated using Kubernetes client generation tools (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
+  - The kubernetes dynamic client.
+  - A REST client that you write.
+  - A client generated using Kubernetes client generation tools (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
 
 {% endcapture %}
 

docs/concepts/policy/psp.yaml → docs/concepts/policy/example-psp.yaml

@@ -1,8 +1,10 @@
 apiVersion: extensions/v1beta1
 kind: PodSecurityPolicy
 metadata:
-  name: permissive
+  name: example
 spec:
+  privileged: false  # Don't allow privileged pods!
+  # The rest fills in some required fields.
   seLinux:
     rule: RunAsAny
   supplementalGroups:
@@ -11,10 +13,5 @@ spec:
     rule: RunAsAny
   fsGroup:
     rule: RunAsAny
-  hostPorts:
-  - min: 8000
-    max: 8080
   volumes:
   - '*'
-  allowedCapabilities:
-  - '*'